Main link for download: bt4-pre-final.iso
MD5 Cheksum: b0485da6194d75b30cda282ceb629654
Size: 1390 Megabytes
Image for Disk label: bt4-label.png
You can find the official announcement at: http://remote-exploit.org/backtrack_download.html
June 23, 2009
BackTrack 4 Pre Release Now Available
The folks over at Remote Exploit have released the latest version of the extremely popular penetration testing LiveCD LiveDVD, Backtrack. With over 300 updated tools included in this release, auditors, investigators and security researchers should all find something to like. The DVD ISO is about 1.4 Gigabytes in size, and with reports of missing bandwidth, it may take awhile to finish the download. Download information below:
Main link for download: bt4-pre-final.iso
MD5 Cheksum: b0485da6194d75b30cda282ceb629654
Size: 1390 Megabytes
Image for Disk label: bt4-label.png
You can find the official announcement at: http://remote-exploit.org/backtrack_download.html
Main link for download: bt4-pre-final.iso
MD5 Cheksum: b0485da6194d75b30cda282ceb629654
Size: 1390 Megabytes
Image for Disk label: bt4-label.png
You can find the official announcement at: http://remote-exploit.org/backtrack_download.html
June 18, 2009
Slowloris: A New Way To DoS
Two days ago, a new exploit was released (via milw0rm) that highlights a new way of performing a DoS (Denial of Service) attack with a relatively low bandwidth requirement. Oftentimes, DoS attacks are simply a matter of which side has the fastest connection.
It is relatively simple to set up a SYN flood, for example, and if you have the faster connection, there's a pretty good chance you'll keep your victim offline until your victim adjusts their connection or yours is forcibly adjusted (e.g., by your ISP once it detects your DoS). There have been variations of this attack, such as Smurf, which uses broadcast addresses to amplify the traffic, but this recent exploit plays on the "kindness" of the webserver so to speak.
Essentially, it sends a connection request to the victim's webserver, much like any other normal request that a browser would send. However, it doesn't quite finish the request, but rather leaves off the last carriage return, and instead sends another header. The webserver will wait to receive the rest of the header, which never comes. Instead, new headers are sent, keeping the connection open and preventing other users from using that thread to connect with.
As might be expected, not a lot of bandwidth is needed to accomplish this attack, just enough to keep the webserver 'expectant' of more data, so to speak. As most webservers have a preset limit for the amount of incoming requests that it will accept at a time, send the traffic as described above will fill up the connection queue, preventing legitimate users from sending their own connection requests, and effectively taking the webserver offline with much less effort than is normally required. Interestingly, this attack is effective on Apache and others, but not on Microsoft IIS 6 & 7. You can find the exploit here: http://www.milw0rm.com/exploits/8976.
Right now, this isn't much of a patch to defend against this. It will almost certainly involve patching the way Apache and similar webservers process incoming connections, likely by limiting the amount of time a connection has to transmit its header information before dropping the connection entirely. Hopefully, this will get patched soon - with 47% of webservers being Apache, it has a lot to lose if this isn't fixed quickly.
Happy Hacking!
-Juno
It is relatively simple to set up a SYN flood, for example, and if you have the faster connection, there's a pretty good chance you'll keep your victim offline until your victim adjusts their connection or yours is forcibly adjusted (e.g., by your ISP once it detects your DoS). There have been variations of this attack, such as Smurf, which uses broadcast addresses to amplify the traffic, but this recent exploit plays on the "kindness" of the webserver so to speak.
Essentially, it sends a connection request to the victim's webserver, much like any other normal request that a browser would send. However, it doesn't quite finish the request, but rather leaves off the last carriage return, and instead sends another header. The webserver will wait to receive the rest of the header, which never comes. Instead, new headers are sent, keeping the connection open and preventing other users from using that thread to connect with.
As might be expected, not a lot of bandwidth is needed to accomplish this attack, just enough to keep the webserver 'expectant' of more data, so to speak. As most webservers have a preset limit for the amount of incoming requests that it will accept at a time, send the traffic as described above will fill up the connection queue, preventing legitimate users from sending their own connection requests, and effectively taking the webserver offline with much less effort than is normally required. Interestingly, this attack is effective on Apache and others, but not on Microsoft IIS 6 & 7. You can find the exploit here: http://www.milw0rm.com/exploits/8976.
Right now, this isn't much of a patch to defend against this. It will almost certainly involve patching the way Apache and similar webservers process incoming connections, likely by limiting the amount of time a connection has to transmit its header information before dropping the connection entirely. Hopefully, this will get patched soon - with 47% of webservers being Apache, it has a lot to lose if this isn't fixed quickly.
Happy Hacking!
-Juno
Subscribe to:
Posts (Atom)