sábado, 13 de julio de 2019

Pasar de SSL a HTTP utilizando 3 erres

Esto de utilizar las 3 erres en seguridad es algo que le comento a la gente más cercana a mi y que se basa en utilizar la regla que todas y todos conocemos de reducir (complejidad del ataque), reutilizar (ataques anteriores), reciclar (ataques para un uso futuro). El caso es que el artículo de hoy me viene bastante bien para explicar esto mismo a la par que os muestro algo que muchos sabréis pero que nunca está de más dejarlo por aquí escrito.


También suelo comentar el por qué me parece que el perfil de un SysAdmin es posiblemente el perfil más potente para la seguridad, y es que conocer un sistema es fundamental para así saber cómo atacarlo reduciendo complejidad en los ataques.. Así que vamos a ello.

La primera referencia que vamos a utilizar es un artículo de este blog que publiqué el mes pasado:

Implementar Let's Encrypt en tu servidor

Para este artículo vamos a tener que suponer algo que ya se da en la mayoría de sitios webs, que es que utilicen SSL. Con Let's Encrypt es sencillo, ya lo vimos.

Es una buena recomendación utilizar SSL en nuestros servidores webs, pero es una recomendación aún mejor configurar nuestro servidor de una manera lo suficientemente segura como para complicar en todo lo posible un ataque que nos puedan realizar. ¿Por qué lo digo? Porque no nos basta con implementar el certificado SSL y dejarlo así, no, tendríamos que realizar alguna configuración extra.

Vamos a ponernos en la piel de un atacante que haya realizado los siguientes pasos:

1. Utiliza un ataque como el expuesto en VAGO para acceder a un servidor.
2. Escala privilegios como se expuso en VAGO o bien:
    2.2. Si es un Windows:
           2.2.1. Hackeándolo primero:
                     2.2.1.1. Normal way
                     2.2.1.2. Ocultando el payload en un videoclip
                     2.2.1.3. Camuflando nuestro payload con Hércules
      2.3. Escalando privilegios
            2.3.1. Escalando privilegios con SUID
        
(Aquí se ve lo de reutilizar ataques o artículos mejor dicho xD)

Es cierto que el atacante tendría que, primero, acceder a nuestro servidor de la forma que fuese y después escalar privilegios, pero ojo que esto no es tan raro en los ataques que se suelen producir.

Ahora pensemos. Estamos dentro del servidor y como root ¿Qué podemos hacer? No me vale el "de todo" o "todo lo que queramos". No, yo estoy preguntando por cosas concretas ¿Cómo seguiríamos el ataque si lo que queremos es obtener el mayor número de datos y/o perjudicar de la mayor forma posible el servidor al que hemos accedido? Reutilicemos una idea que hemos dado antes:

"suponer algo que ya se da en la mayoría de sitios webs, que es que utilicen SSL"

Esto es interesante pues es lo que más nos podemos encontrar, es lo que tiene una mayor probabilidad de estar. Sí, que también podríamos tratar de acceder a la base de datos, pero puede que las contraseñas estén almacenadas con el salt+hash. Podríamos buscar archivos confidenciales, pero lo que va a estar casi seguro es SSL. Vamos a idear entonces un ataque en función a esto que estamos comentando.

Configuración por defecto, fuente de males

Supongamos que los que hayan implementado SSL han utilizado Let's Encrypt ¿Recordaís que mensaje veríamos al utilizar el certbot?

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/dominio2.com/fullchain.pem. Your
   cert will expire on 2019-09-17. To obtain a new or tweaked version
   of this certificate in the future, simply run certbot again. To
   non-interactively renew *all* of your certificates, run "certbot
   renew"


Este mensaje, lo que nos dice es dónde se ha almacenado el certificado, pero vamos a hacer hincapié en que es muy importante guardar de la forma más segura posible este certificado, ya que si cayese en malas manos, esa persona podría descifrar todo el tráfico SSL...a eso vamos.

Si lo dejásemos en su ruta por defecto, tendremos que ser conscientes que, si alguien entra en nuestro servidor y consigue escalar privilegios, no tendría más que buscar en la ruta por defecto y encontraría el certificado sin muchos problemas, pues siempre es constante

/etc/letsencrypt/live/

Lo que cambia es las carpetas, dentro de este directorio en el que lo metamos. No obstante, el atacante se encontraría un pequeño problema pero que es sencillo de solucionar.

El problema que se encontraría es que si ha escalado privilegios, no sabrá la contraseña de root, por lo que al pasarse a su máquina el certificado se podría encontrar algún inconveniente. No obstante, esto lo solucionaría muy fácilmente:

1. Creando un usuario con su respectivo directorio
2. Pasar el certificado a ese directorio y cambiar permisos de ser necesario 
3. Pasar el certificado dentro del directorio del nuevo usuario que hemos creado. Esto lo podemos hacer con rsync y asarlo a nuestra máquina.

Tras y mientras nos pasamos el cert, podríamos escoger a un usuario que utilice la web del servidor que hemos vulnerado y, de ser posible, realizar un ataque Man In The Middle y capturaremos su tráfico. Lo dejamos durante un tiempo, por ejemplo 1 día. Después de este tiempo, abrimos la captura con, por ejemplo, Wireshark.


Veremos que hay contenido cifrado al ir bajo HTTPS. No nos debería de preocupar, pues tenemos el certificado, por lo que lo importaremos a Wireshark.


En Wireshark, nos iremos a Edit>Preferences>Protocols>SSL y ahí añadiremos una configuración similar a la que veis en la anterior captura. Cuando lo añadamos, aceptamos y volvemos a la captura de tráfico.


Ahora sí que veríamos el contenido en claro de la petición. En este caso no hay mucho, pero podría ser un formulario con un login sin problema, por lo que obtendríamos la password. Tras eso, obligados estaríamos de comprobar si la víctima utiliza la misma contraseña para más de un sitio.

Esta especie de pivoting de un ataque a otro, nos puede llegar a ser de bastante utilidad en una auditoría, además de que, con un sólo ataque (este que estoy exponiendo en este artículo en el cual nos estamos ayudando de otros ataques ya existentes) estaríamos exponiendo varios fallos de seguridad o malas prácticas y configuraciones que, a la hora de elaborar el informe, nos vendrá muy bien.

¿Hackeamos el Mundo?

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...