Knowledge Base

Ask A Question

Questions

3

Ethernal blue problem

I have this problem with windows/smb/ms17_010_eternalblue I use Linux kali 4.14.0-kali3-amd64 #1 SMP Debian 4.14.12-2kali1 (2018-01-08) x86_64 GNU/Linux [*] Started reverse TCP handler on "Lhost:port" [*] "Rhost IP:port" - Connecting to target for exploitation. [+] "Rhost IP:port" - Connection established for exploitation. [+] "Rhost IP:port" - Target OS selected valid for OS indicated by SMB reply [*] "Rhost IP:port" - CORE raw buffer dump (38 bytes) [*] "Rhost IP:port" - 0x00000000 57 69 6e 64 6f 77 73 20 37 20 55 6c 74 69 6d 61 Windows 7 Ultima [*] "Rhost IP:port" - 0x00000010 74 65 20 37 36 30 31 20 53 65 72 76 69 63 65 20 te 7601 Service [*] "Rhost IP:port" - 0x00000020 50 61 63 6b 20 31 Pack 1 [+] "Rhost IP:port" - Target arch selected valid for arch indicated by DCE/RPC reply [*] "Rhost IP:port" - Trying exploit with 12 Groom Allocations. [*] "Rhost IP:port" - Sending all but last fragment of exploit packet [*] "Rhost IP:port" - Starting non-paged pool grooming [+] "Rhost IP:port" - Sending SMBv2 buffers [+] "Rhost IP:port" - Closing SMBv1 connection creating free hole adjacent to SMBv2 buffer. [*] "Rhost IP:port" - Sending final SMBv2 buffers. [*] "Rhost IP:port" - Sending last fragment of exploit packet! [*] "Rhost IP:port" - Receiving response from exploit packet [-] "Rhost IP:port" - Did not receive a response from exploit packet [*] "Rhost IP:port" - Sending egg to corrupted connection. [-] "Rhost IP:port" - Errno::ECONNRESET: Connection reset by peer [*] Exploit completed, but no session was created.

Posted by Jhon Dale about a year ago

8

memcached DrDoS cmty check

I have been working on and testing the following check (text content to be improved). The following has been working well so far in my test environment. I have seen at least response instance where I did not receive a STAT command back but it was early in my testing so it may have been a poorly formed request on my end. What I'm running into within my test environment is that the memcached service on 11211 is only showing as TCP in the UI and the system is listening on 11211/udp and tcp on the test server. The check below (unless I miss-understand the logic) should only trigger if the query is successful on UDP. The signature is firing and the proof shows 11211 TCP. If the same port 11211 is available on both TCP and UDP does the UI fail to show one or does my check potentially have an error? I'm also looking to see if the XML schema has any hints to further restrict the NetworkService to be UDP only. *I'm open to any improvements. ``` <VulnerabilityCheck id="cmty-memcached-amplification" scope="endpoint" potential="0"> <NetworkService type="memcached"/> <UDPCheck> <UDPRequestResponse> <UDPRequest><value format="base64">AAEAAAABAABzdGF0cw0KCg==</value></UDPRequest> <UDPResponse><regex ctags="REG_DOT_NEWLINE,REG_MULTILINE">STAT</regex></UDPResponse> </UDPRequestResponse> </UDPCheck> </VulnerabilityCheck> ``` [cmty-memcached-amplification.xml](https://github.com/BrianWGray/cmty-nexpose-checks/blob/master/cmty-memcached-amplification.xml) [cmty-memcached-amplification.vck](https://github.com/BrianWGray/cmty-nexpose-checks/blob/master/cmty-memcached-amplification.vck) [memcached-restrict.sol](https://github.com/BrianWGray/cmty-nexpose-checks/blob/master/memcached-restrict.sol)

Posted by BrianWGray about a year ago