lunes, 11 de julio de 2016

DoS con Slowloris.pl

Buenas hackers en esta PoC, os muestro esta genial herramienta que permite realizar un ataque de denegación de servicio a un servidor Linux. Esto genera que ese servicio sea inaccesible a los usuarios legítimos. En este caso mantiene conexiones abiertas el máximo tiempo posible a base del envío de peticiones http a una tasa de datos muy baja.. Para esta prueba de concepto se realizará en un entorno virtualizado controlado, usando una máquina atacante Kali Linux y un servidor Ubuntu como víctima.


Slowloris.pl esta escrita en perl y disponible en Github


Requirimientos y los pasos a seguir

 
How use Slowloris

Requirements:
# sudo apt-get update  
# sudo apt-get install perl
# sudo apt-get install libwww-mechanize-shell-perl
# sudo apt-get install perl-mechanize


1)Download slowloris.pl
2)Open Terminal
2)# cd /thePathToYourSlowloris.plFile
3)# ./slowloris.pl
4)# perl slowloris.pl -dns (Victim URL or IP) -options



Done


Laera Loris"

Documento de ayuda

 
TITLE
    Slowloris

VERSION
    Version 0.7 Beta

DATE
    06/17/2009

AUTHOR
    RSnake <h@ckers.org> with threading from John Kinsella

ABSTRACT
    Slowloris both helps identify the timeout windows of a HTTP server or
    Proxy server, can bypass httpready protection and ultimately performs a
    fairly low bandwidth denial of service. It has the added benefit of
    allowing the server to come back at any time (once the program is killed),
    and not spamming the logs excessively. It also keeps the load nice and low
    on the target server, so other vital processes don't die unexpectedly, or
    cause alarm to anyone who is logged into the server for other reasons.

AFFECTS
    Apache 1.x, Apache 2.x, dhttpd, GoAhead WebServer, others...?

NOT AFFECTED
    IIS6.0, IIS7.0, lighttpd, nginx, Cherokee, Squid, others...?

DESCRIPTION
    Slowloris is designed so that a single machine (probably a Linux/UNIX
    machine since Windows appears to limit how many sockets you can have open
    at any given time) can easily tie up a typical web server or proxy server
    by locking up all of it's threads as they patiently wait for more data.
    Some servers may have a smaller tolerance for timeouts than others, but
    Slowloris can compensate for that by customizing the timeouts. There is an
    added function to help you get started with finding the right sized
    timeouts as well.

    As a side note, Slowloris does not consume a lot of resources so modern
    operating systems don't have a need to start shutting down sockets when
    they come under attack, which actually in turn makes Slowloris better than
    a typical flooder in certain circumstances. Think of Slowloris as the HTTP
    equivalent of a SYN flood.

  Testing
    If the timeouts are completely unknown, Slowloris comes with a mode to
    help you get started in your testing:

   Testing Example:
    ./slowloris.pl -dns www.example.com -port 80 -test

    This won't give you a perfect number, but it should give you a pretty good
    guess as to where to shoot for. If you really must know the exact number,
    you may want to mess with the @times array (although I wouldn't suggest
    that unless you know what you're doing).
 
 HTTP DoS
    Once you find a timeout window, you can tune Slowloris to use certain
    timeout windows. For instance, if you know that the server has a timeout
    of 3000 seconds, but the the connection is fairly latent you may want to
    make the timeout window 2000 seconds and increase the TCP timeout to 5
    seconds. The following example uses 500 sockets. Most average Apache
    servers, for instance, tend to fall down between 400-600 sockets with a
    default configuration. Some are less than 300. The smaller the timeout the
    faster you will consume all the available resources as other sockets that
    are in use become available - this would be solved by threading, but
    that's for a future revision. The closer you can get to the exact number
    of sockets, the better, because that will reduce the amount of tries (and
    associated bandwidth) that Slowloris will make to be successful. Slowloris
    has no way to identify if it's successful or not though.

   HTTP DoS Example:
    ./slowloris.pl -dns www.example.com -port 80 -timeout 2000 -num 500 -tcpto
    5

  HTTPReady Bypass
    HTTPReady only follows certain rules so with a switch Slowloris can bypass
    HTTPReady by sending the attack as a POST verses a GET or HEAD request
    with the -httpready switch.

   HTTPReady Bypass Example
    ./slowloris.pl -dns www.example.com -port 80 -timeout 2000 -num 500 -tcpto
    5 -httpready
 
  Stealth Host DoS
    If you know the server has multiple webservers running on it in virtual
    hosts, you can send the attack to a seperate virtual host using the -shost
    variable. This way the logs that are created will go to a different
    virtual host log file, but only if they are kept separately.

   Stealth Host DoS Example:
    ./slowloris.pl -dns www.example.com -port 80 -timeout 30 -num 500 -tcpto 1
    -shost www.virtualhost.com

  HTTPS DoS
    Slowloris does support SSL/TLS on an experimental basis with the -https
    switch. The usefulness of this particular option has not been thoroughly
    tested, and in fact has not proved to be particularly effective in the
    very few tests I performed during the early phases of development. Your
    mileage may vary.

   HTTPS DoS Example:
    ./slowloris.pl -dns www.example.com -port 443 -timeout 30 -num 500 -https

  HTTP Cache
    Slowloris does support cache avoidance on an experimental basis with the
    -cache switch. Some caching servers may look at the request path part of
    the header, but by sending different requests each time you can abuse more
    resources. The usefulness of this particular option has not been
    thoroughly tested. Your mileage may vary.

   HTTP Cache Example:
    ./slowloris.pl -dns www.example.com -port 80 -timeout 30 -num 500 -cache

Issues
    Slowloris is known to not work on several servers found in the NOT
    AFFECTED section above and through Netscalar devices, in it's current
    incarnation. They may be ways around this, but not in this version at this
    time. Most likely most anti-DDoS and load balancers won't be thwarted by
    Slowloris, unless Slowloris is extremely distrubted, although only
    Netscalar has been tested.

    Slowloris isn't completely quiet either, because it can't be. Firstly, it
    does send out quite a few packets (although far far less than a typical
    GET request flooder). So it's not invisible if the traffic to the site is
    typically fairly low. On higher traffic sites it will unlikely that it is
    noticed in the log files - although you may have trouble taking down a
    larger site with just one machine, depending on their architecture.

    For some reason Slowloris works way better if run from a *Nix box than
    from Windows. I would guess that it's probably to do with the fact that
    Windows limits the amount of open sockets you can have at once to a fairly
    small number. If you find that you can't open any more ports than ~130 or
    so on any server you test - you're probably running into this "feature" of
    modern operating systems. Either way, this program seems to work best if
    run from FreeBSD.

    Once you stop the DoS all the sockets will naturally close with a flurry
    of RST and FIN packets, at which time the web server or proxy server will
    write to it's logs with a lot of 400 (Bad Request) errors. So while the
    sockets remain open, you won't be in the logs, but once the sockets close
    you'll have quite a few entries all lined up next to one another. You will
    probably be easy to find if anyone is looking at their logs at that point
    - although the DoS will be over by that point too.

What is a slow loris?
    What exactly is a slow loris? It's an extremely cute but endangered mammal
    that happens to also be poisonous. Check this out:

    http://www.youtube.com/watch?v=rLdQ3UhLoD4
 

Proof of concept 


Un saludo Naivenom

2 comentarios:

  1. Buenas, el referido ataque no se trata de consumir el ancho de banda sino de mantener conexiones abiertas el máximo tiempo posible a base de justamente lo contrario, el envío de peticiones http a una tasa de datos muy baja.

    ResponderEliminar

Google Analytics