Sunday, June 3, 2018

Windows reuse shellcode based on socket's lifetime

I've always been a big fan of the old sockets reuse techniques: findtag, findport, etc.; each with its advantages and disadvantages. This type of shellcodes usually demand multiple requirements. The main one is that the exploited process must own the socket descriptor/handle and many many times this is not possible. In addition, even if you find the right socket another thread could use it before and disrupt the process. Other hurdle is that each shellcode should be tuned for each particular exploit most of the time. For instance, by using findtag you need to know the exact amount of bytes that the application must read before being exploited in orden to send the appropiate tag at the correct offset.

In spite of these drawbacks, using these as well as other ingenious techniques to reuse sockets, whenever possible, can make the difference between getting a shell or not, especially if a restrictive firewall prevents incoming/outgoing connections (which would foil the "typical" bind/reverse stagers). 

In this post I'd like to share a new idea? to locate the socket that it might be useful in certain scenarios. Specifically I think it can be interesting in services where a normal TCP connection is relatively short: DNS services, printer/logging daemons, etc. Please leave me a comment if you have seen this or a similar shellcode in the wild.

The idea is to take advantage of the service timeout to extend the lifetime of the connection to make it distinguishable from others sockets. After that idle time we can use the getsockopt API along with SO_CONNECT_TIME (SOL_SOCKET option) to go through all the handles and identify the socket whose lifetime exceeds X seconds.  In a DNS service, for instance, where a normal TCP query could last less than one second, would be sufficient to wait several seconds after the 3-way handshake.

The following scheme illustrates this.

Here is the x86 asm shellcode PoC. The full code is hosted in my GitHub. I have used as template the stager_reverse_tcp stager available in Metasploit which is based on the Hash API code of Stephen Fewer. Just tested with a SCADA exploit.

Note that after each loop there are 2 checks. The first one at offset 0x000000C9 just see if the handle is valid (0xFFFFFFFF if it's not). The second one (at offset 0x000000CE) to verify if the lifetime is greater than the number of seconds embedded in the shellcode (10 in this case). Note too that a valid non-connected socket, for instance, one returned by the socket() API, could reach this second check but due to the nature of the socket the number of seconds associated with it will be 0. 

What advantages does this shellcode have over other existing techniques? Well, one of them is that  it does not depend on the attacker IP or its source port (like findport does), so it is NAT immune. Another one is that it doesn't need to read each socket buffer as findtag does which sometimes could result in a crash of the application.

On the other side, this shellcode will be valid only for a very small range of targets where the aforementioned requirements are met. Besides the shellcode could be prone to certain false positives. For example, if a legitimate connection dies abruptly that would generate a long lifetime socket which can be singled out mistakenly for our shellcode instead of the one we are looking for.

1 comment: