PyLoris 3.2

What is so special about PyLoris?

One common method for performing a Denial of Service attack is called flooding. By rounding up a large number of computers, and telling them all to send or request a large amount of data from a server simultaneously. The purpose of these requests are not to gather large amounts of information; rather, the intent is merely to overwhelm the capabilities of the server. In a situation like this, a server could fail because of the bandwidth restrictions of the internet service provider, the memory limitations of the server, the lack of hard drive space to store the data being sent, or the inability of the CPU to process the data fast enough. The common thread between these four issues is that these are finite resources that have been given to the server. PyLoris is different from this form of attack because it does not prey of any physical resource; instead, it overwhelms an artificial resource--connections.
In order for prevent these types the aformentioned form of attacks, applications will limit their own utilization of system resources. If a process is going to use too much CPU, hard disk space, or memory, they will slow down and throttle requests--thereby ensuring the server's stability. Unfortunately, a number of web servers invent another form of resource--total connection count--with the idea that the connection count is linearly related to the utilization of other resources. This assumption is invalid; in the case of PyLoris, connections are relatively low in regards to CPU, memory, and network utilization. The offshoot of this is that web servers imposing restrictions on the total number of connections will reject connections well before they hit their physical resources' limits. Essentially developers have invented an artificial resource that causes a bottleneck far before any other physical limitation would.

What are the methods for mitigating this form of attack?

The typical responses to this attack come in various forms, but usually fall into one of three forms:

1. Keeping a tally of connections for the number of connections made by a client. This counter would be incremented each time a connection is made, and decrememented once every specified time interval. Any client over a certain number would be flagged as an alert, while any client over a larger limit would be automatically banned for a specified time.
   • A high number of requests in a short amount of time from a single client would not be able to bring down your server
   • Large companies or clusters behind NAT would set off a DoS trigger
   • Doesn't protect against an attack like PyLoris + TOR
2. Keeping track of the number of concurrent connections. A counter would be kept for each client, incremented on connect, and decremented on disconnect. Clients over a certain number would be flagged, while clients over a larger number would be automatically banned for a specified time.
   • A high number of concurrent connections from a single client would not be able to bring down your server
   • Large companies or clusters behind NAT would set off a DoS trigger
   • Doesn't protect against an attack like PyLoris + TOR
3. Connection serialization. Web browsers have a configurable option for the number of connections to make per server. Circuits could incorporate a similar option; if the server is set to a maximum of 8 concurrent requests per client and a client makes 10, the server accepts all 10 requests, starts to fulfill the first 8, dealing with the extra 2 only after 2 connections have completed.
   • Protects against an attack like PyLoris.
   • Large companies or clusters behind NAT would still be able to use the service
   • Large companies or clusters behind NAT would be throttled
   • Abusers are not banned
   • Doesn't protect against an attack like PyLoris + TOR
4. Put the web server behind another device that collects full requests and passes them on only when they are complete.
   • Protects against an attack like PyLoris + TOR
   • Large companies or clusters behind NAT would still be able to use the service
   • Abusers are not banned
   • Cost is more than the average website owner has to spend
   • Introducing more hardware could introduce more vulnerabilities

How could one remove these artificial limitations?

The unfortunate reality is that none of the aformentioned mitigating tactics actually address the problem of artificial limitations. In order to do this, developers will need to work on the following areas:

1. Remove the artificial limitation: Developers should impose restrictions on the actual resource they are trying to protect, not arbitratily create an unrelated one.
2. Reduce the memory and CPU footprint of inactive or incomplete connections: Windows limits TCP/IP connections by the amount of memory they use. A default installation of Linux sets the maximum number of file descriptors at 205199--orders of magnitude higher than the maximum number of allowed connections in the default installations of certain web servers will allow. If the resource utilization of a connection is on par with what the underlying Operating System uses, then the capabilities of these web servers will once again be restricted to the physical resources of the machine.
3. Limit applications based on physical resources. A misconfigured web server with connections set too high can cause the entire operating system to crash. If developers were to restrict their applications' resources, many attacks would have a much smaller impact.

Why should I use PyLoris instead of Slowloris?

While the basic forms of PyLoris and Slowloris are functionally similar, PyLoris and Slowloris were developed with two entirely different motives in mind. Slowloris, developed by RSnake, was designed to showcase a particulary devastating form of Denial of Service attack. PyLoris, on the other hand, is designed to be a fully functional performance testing tool. With PyLoris you can:

• Test the capability of your web server to handle incoming connections
• Discover how your well your firewall policies work against DoS and DDoS attacks
• Assess your Load Balancer or Content Service Switch handles high loads
• Test the web servers of your embedded devices for flaws
• Harness SOCKS proxies and TOR to audit your network infrastructure and tests vulnerabilities from multiple routes
• Perform the Slowloris attack against non HTTP protocls
• Build and distribute attack scripts with ScriptLoris and libloris
  
  Click : Download

Read more »

ByteDOS v3.2 Attack tool

ByteDOS v3.2

Attack tool.

- How to use:

1. Open ByteDOS (You can download on this page!)
2. Click IP Scanner button. Then input the site you want attack. Remember the IP.
3. Click  DoS/DDoS, After new windows open...
4. Inset proxy if you want to use proxy! (google.com)
5. Select flood method. Syn Flooding Attack:  
6. Inset IP Host
7. Inset Opened Port
8. Click Blue Button
9. Do it Together if you want the result!
   
   Click: Download

Read more »

Slowloris Apache killer

Welcome to Slowloris - the low bandwidth, yet greedy and poisonous HTTP client!
Written by RSnake with help from John Kinsella, and a dash of inspiration from Robert E Lee.

UPDATE 2: Video presentation of Slowloris at DefCon (the middle section of the presentation) can be seen here: Hijacking Web 2.0 Sites with SSLstrip and SlowLoris -- Sam Bowne and RSnake at Defcon 17.
UPDATE: Amit Klein pointed me to a post written by Adrian Ilarion Ciobanu written in early 2007 that perfectly describes this denial of service attack. It was also described in 2005 in the "Programming Model Attacks" section of Apache Security. So although there was no tool released at that time these two still technically deserves all the credit for this. I apologize for having missed these.
In considering the ramifications of a slow denial of service attack against particular services, rather than flooding networks, a concept emerged that would allow a single machine to take down another machine's web server with minimal bandwidth and side effects on unrelated services and ports. The ideal situation for many denial of service attacks is where all other services remain intact but the webserver itself is completely inaccessible. Slowloris was born from this concept, and is therefore relatively very stealthy compared to most flooding tools.
Slowloris holds connections open by sending partial HTTP requests. It continues to send subsequent headers at regular intervals to keep the sockets from closing. In this way webservers can be quickly tied up. In particular, servers that have threading will tend to be vulnerable, by virtue of the fact that they attempt to limit the amount of threading they'll allow. Slowloris must wait for all the sockets to become available before it's successful at consuming them, so if it's a high traffic website, it may take a while for the site to free up it's sockets. So while you may be unable to see the website from your vantage point, others may still be able to see it until all sockets are freed by them and consumed by Slowloris. This is because other users of the system must finish their requests before the sockets become available for Slowloris to consume. If others re-initiate their connections in that brief time-period they'll still be able to see the site. So it's a bit of a race condition, but one that Slowloris will eventually always win - and sooner than later.
Slowloris also has a few stealth features built into it. Firstly, it can be changed to send different host headers, if your target is a virtual host and logs are stored seperately per virtual host. But most importantly, while the attack is underway, the log file won't be written until the request is completed. So you can keep a server down for minutes at a time without a single log file entry showing up to warn someone who might watching in that instant. Of course once your attack stops or once the session gets shut down there will be several hundred 400 errors in the web server logs. That's unavoidable as Slowloris sits today, although it may be possible to turn them into 200 OK messages instead by completing a valid request, but Slowloris doesn't yet do that.
HTTPReady quickly came up as a possible solution to a Slowloris attack, because it won't cause the HTTP server to launch until a full request is recieved. This is true only for GET and HEAD requests. As long as you give Slowloris the switch to modify it's method to POST, HTTPReady turns out to be a worthless defense against this type of attack.
This is NOT a TCP DoS, because it is actually making a full TCP connection, not a partial one, however it is making partial HTTP requests. It's the equivalent of a SYN flood but over HTTP. One example of the difference is that if there are two web-servers running on the same machine one server can be DoSed without affecting the other webserver instance. Slowloris would also theoretically work over other protocols like UDP, if the program was modified slightly and the webserver supported it. Slowloris is also NOT a GET request flooder. Slowloris requires only a few hundred requests at long term and regular intervals, as opposed to tens of thousands on an ongoing basis.
Interestingly enough, in testing this has been shown in at least one instance to lock up database connections and force other strange issues and errors to arise that can allow for fingerprinting and other odd things to become obvious once the DoS is complete and the server attempts to clean itself up. I would guess that this issue arises when the webserver is allowed to open more connections than the database is, causing the database to fail first and for longer than the webserver.
Slowloris lets the webserver return to normal almost instantly (usually within 5 seconds or so). That makes it ideal for certain attacks that may just require a brief down-time. As described in this blog post, DoS is actually very useful for certain types of attacks where timing is key, or as a diversionary tactic, etc....
This affects a number of webservers that use threaded processes and ironically attempt to limit that to prevent memory exhaustion - fixing one problem created another. This includes but is not necessarily limited to the following:

• Apache 1.x
• Apache 2.x
• dhttpd
• GoAhead WebServer
• WebSense "block pages" (unconfirmed)
• Trapeze Wireless Web Portal (unconfirmed)
• Verizon's MI424-WR FIOS Cable modem (unconfirmed)
• Verizon's Motorola Set-Top Box (port 8082 and requires auth - unconfirmed)
• BeeWare WAF (unconfirmed)
• Deny All WAF (unconfirmed)

There are a number of webservers that this doesn't affect as well, in my testing:

• IIS6.0
• IIS7.0
• lighttpd
• Squid
• nginx
• Cherokee (verified by user community)
• Netscaler
• Cisco CSS (verified by user community)

This is obviously not a complete list, and there may be a number of variations on these web-servers that are or are not vulnerable. I didn't test every configuration or variant, so your mileage may vary. This also may not work if there is an upstream device that somehow limits/buffers/proxies HTTP requests. Please note though that Slowloris only represents one variant of this attack and other variants may have different impacts on other webservers and upstream devices. This command should work on most systems, but please be sure to check the options as well:
perl slowloris.pl -dns example.com
Requirements: This is a Perl program requiring the Perl interpreter with the modules IO::Socket::INET, IO::Socket::SSL, and GetOpt::Long. Slowloris works MUCH better and faster if you have threading, so I highly encourage you to also install threads and threads::shared if you don't have those modules already. You can install modules using CPAN:

perl -MCPAN -e 'install IO::Socket::INET'
perl -MCPAN -e 'install IO::Socket::SSL'

Windows users: You probably will not be able to successfuly execute a Slowloris denial of service from Windows even if you use Cygwin. I have not had any luck getting Slowloris to successfuly deny service from within Windows, because Slowloris requires more than a few hundred sockets to work (sometimes a thousand or more), and Windows limits sockets to around 130, from what I've seen. I highly suggest you use a *NIX operating system to execute Slowloris from for the best results, and not from within a virtual machine, as that could have unexpected results based on the parent operating system.
Version: Slowloris is currently at version 0.7 - 06/17/2009
Download: slowloris.pl
Getting started: perldoc slowloris.pl
Issues: For a complete list of issues look at the Perl documentation, which explains all of the things to think about when running this denial of service attack.
Thanks: Thank you to John Kinsella for the help with threading and id and greyhat for help with testing.


Click : Download

Read more »

Hight Orbit Ion Cannon

What Is HOIC?

Anonymous is on a destruction spree lately—after Megaupload was killed, their reaction was swift and powerful. They made it look easy—and that's because thanks to the HOIC (High Orbit Ion Cannon), it is. Here's the newest hacker superweapon.

It's the newest way Anonymous is attacking websites...

Anonymous relies on the mob, corralled by a vanguard of elites. It may have a serious brain trust at the top, but Anonymous' power—like any other popular movement—lies in its ability to arm the unskilled. When Anon wants to knock down a website, it organizes a heap of followers around one target, armed with software (HOIC) that overloads a server with fake visitors—a simulated flood of malicious traffic that pushes a site to its breaking point. And once a website is down, this software keeps it down.

...and is basically the old LOIC...

Last year it was all about the Low Orbit Ion Cannon—an easy to use tool preferred by 4chan and Anonymous miscreants who wanted to attack websites. The LOIC made hacking so easy, all you needed was fingers, eyeballs, and a basic understanding of some written language:

The idea behind LOIC is that it can allow you to participate in attacks even if you've no clue how to hack. Just download a copy of LOIC (available for Windows, Mac, and Linux!), punch in the target information like a URL or an IP address and zap.

It was the hacking equivalent of microwaving your dinner. Now, it's evolved and pumped way the hell up.

...that is still just as easy to use...

A child could use the HOIC—and that's what makes it so dangerous. Pretty much anyone with eyeballs and a bone to pick can find HOIC via Google, install it in a couple of minutes, and be ready to go. All you need to do is type in a target website and click fire.

...but blasts websites better than ever...

The HOIC has some diabolical tricks up its sleeve. First, it cranks out more dummy traffic—meant to overwhelm and crash a server with more fake "visitors" than it can handle—with a magnitude that outstrips anything the LOIC was capable of: one Anon told me he's able to fire off as much as 2 MB per second using HOIC. Part of the supercharging comes from the use of "boosters"—custom scripts that spread malicious traffic across a range of target sub-pages, rather than just one. For example: instead of hitting EvilSite.com, a booster will knock EvilSite.com/about.html, EvilSite.com/news.html, etc, all forged to look like the traffic is coming from a variety of spots. Think shotgun versus pistol.

...while keeping Anonymous safe(r).

"Most good firewalls have been written to block loic attacks," another Anon tells me, owing to the fact that it's been a 4chan standby for years. HOIC, on the other hand, is a newer weapon, and sites are less likely to be prepared for it. The use of boosters also confuses online defenses, turning a focused, easy to trace beam into an overwhelming scattershot. But HOIC can't turn any Anon into a lone wolf—an operative who actively uses the newest cannon said at least 50 users are necessary to give their targeted site enough of a walloping to take it down and keep it down.

Click to Download : Download

Read more »