[RSnake] has developed a denial of service technique that can take down servers more effectively. Traditionally, performing a denial of service attack entailed sending thousands of requests to a server, these requests needlessly tie up resources until the server fails. This repetitive attack requires the requests to happen in quick succession, and is usually a distributed effort. However, [RSnake]’s new technique has a client open several HTTP sessions and keeps them open for as long as possible. Most servers are configured to handle only a set number of connections; the infinite sessions prevent legitimate requests from being handled, shutting down the site. This vulnerability is present on webservers that use threading, such as Apache.
A positive side effect of the hack is that the server does not crash, only the HTTP server is affected. His example perl implementation, slowloris, is able to take down an average website using only one computer. Once the attack stops, the website will come back online immediately.
Update: Reader [Motoma] sent in a python implementation of slowloris called pyloris
Last week at Black Hat DC, [Moxie Marlinspike] presented a novel way to hijack SSL. You can read about it in this Forbes article, but we highly recommend you watch the video. sslstrip can rewrite all https links as http, but it goes far beyond that. Using unicode characters that look similar to / and ? it can construct URLs with a valid certificate and then redirect the user to the original site after stealing their credentials. The attack can be very difficult for even above average users to notice. This attack requires access to the client’s network, but [Moxie] successfully ran it on a Tor exit node.
If you are an Atmel fan, you may enjoy this webserver built around the ATmega88. Since it has full TCP and HTTP support, communication can be done using a standard web browser on any system. We also noticed that the code uses AVR Libc and the processor can be replaced with an ATmega168, both used on the Arduino platform. Honestly, we think the most interesting part about this project is the firmware. The author has assumed that the webserver will only be sending one packet per request and the code is optimized for this setup. This leaves around 50% of the memory for the web application.