viernes, 22 de septiembre de 2017

OptionsBleed


Logo de HeartBleed.


Todos conocíamos HeartBleed dado el enorme revuelo e impacto que tuvo cuando fue redescubierto. Ahora de la mano de Apache llega OptionBleed con CVE: CVE-2017-9798. Una vulnerabilidad similar en tanto a que es otro Memory Leak fácilmente explotable.

Esta vulnerabilidad afecta a casi todos los servidores Apache por lo que si tienes uno te recomendamos actualizar, aplicar el parche, o la solución alternativa que prefieras. No es una vulnerabilidad que se de “por defecto” sino por un error de tratamiento de un fallo de configuración en la directiva Limit de HTACCESS.

No obstante tiene especial gravedad puesto que para explotar la vulnerabilidad solo es necesario realizar una petición OPTIONS a un servidor vulnerable varias veces.

elchicodepython@honeysec:~# wget -S --method=OPTIONS http://localhost
--2017-09-20 20:50:49--  http://localhost/
Resolviendo localhost (localhost)... ::1, 127.0.0.1
Conectando con localhost (localhost)[::1]:80... conectado.
Petición HTTP enviada, esperando respuesta...
  HTTP/1.1 200 OK
  Date: Wed, 20 Sep 2017 20:50:49 GMT
  Server: Apache/2.4.10 (Debian)
  Allow: OPTIONS,POST,GET,HEAD,,HEAD,,HEAD,,HEAD
  Content-Length: 0
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Content-Type: text/html
Longitud: 0 [text/html]
Grabando a: “index.html”

Como podemos ver en la respuesta la cabecera Allow que le indica al cliente que métodos tiene permitidos tiene más datos de los que debería: ,,HEAD,,HEAD,,HEAD 

Además de estos datos puede devolver información de memoria como en el ejemplo de la Web: blog.segu-info.com.ar/2017/09/optionsbleed-bug-similar-heartbleed.html

Para replicar la vulnerabilidad es necesario disponer de un servidor Apache sin la última actualización y sin la aplicación del parche.

Dentro de la configuración de un archivo .htaccess deberemos incluir la directiva Limit mal formulada. Esta directiva espera métodos HTTP como son POST, PUT, GET, DELETE…

Si especificamos un método inexistente como puede ser

<Limit honeysec.info>
</Limit>


Cuando realicemos una solicitud OPTIONS que podemos realizer de la siguiente forma:
wget -S --method=OPTIONS <url>
Nos encontraremos con que entre las opciones puede haber más datos. Es posible que en la primera petición no encontremos información pero si repetimos la petición N veces dentro de la cabecera Allow podemos encontrar respuestas distintas.
Para solucionar la vulnerabilidad podemos comprobar que no tenemos errores en las directivas Limit, aplicar el parche ubicado en la siguiente URL https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/server/core.c?r1=1805223&r2=1807754&pathrev=1807754&view=patch, o, aplicar la actualización correspondiente cuando esté disponible para nuestro sistema operativo. Los principales ya tienen paquetes con el parche aplicado.

También existe una posibilidad alternativa de evitar el parche y la explotación del bug que he comprobado y es por medio del módulo allowmethods que deberemos habilitarlo previamente con la directiva a2enmod allowmethods. Finalmente dentro del directorio que pretendamos proteger en Apache aplicamos la siguiente instrucción señalada en negrita. De esta manera permitimos únicamente los métodos GET POST y HEAD. Excluyendo así el resto de los métodos entre ellos el método OPTIONS que explota esta vulnerabilidad.

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride all
        Require all granted
        AllowMethods GET POST HEAD
</Directory>

elchicodepython@honeysec:~# wget -S --method=OPTIONS http://localhost
--2017-09-20 21:20:40--  http://localhost/
Resolviendo localhost (localhost)... ::1, 127.0.0.1
Conectando con localhost (localhost)[::1]:80... conectado.
Petición HTTP enviada, esperando respuesta... 
  HTTP/1.1 405 Method Not Allowed
  Date: Wed, 20 Sep 2017 21:20:40 GMT
  Server: Apache/2.4.10 (Debian)
  Allow: 
  Content-Length: 300
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Content-Type: text/html; charset=iso-8859-1

Como podemos ver en la respuesta la vulnerabilidad aunque esté presente no puede explotarse pues la respuesta es un Error 405: Método no permitido.

Por: @elchicodepython

domingo, 18 de junio de 2017

Cómo cubrir las pistas y no dejar rastro detrás en el sistema de destino




DISCLAIMER: Honeysec no se hace responsable de cualquier uso que se le pueda dar a las herramientas que aparecen en el siguiente artículo, incluidos ataques a cualquier dispositivo móvil o tablet. Estas herramientas han sido publicadas con propósitos educativos y sin ninguna garantía.

Consultar los archivos de registro es el primer paso que un administrador de sistemas revisará para ver  qué ha ocurrido en su sistema. Cada inicio de sesión sin éxito, inicio de sesión correcto y evento de seguridad se registra en los archivos de registro. Por lo tanto, lo primero que debemos hacer es asegurarnos de que no hay rastro de nuestras actividades maliciosas en esos archivos de registro.


Eliminación de registros de eventos con Metasploit/ Meterpreter

En las versiones más recientes de meterpreter de Metasploit, hay un script llamado clearev para borrar todos los registros de eventos. Este programa entrará en los registros de eventos en un sistema Windows y borrará TODOS los registros. Esto podría parecer un poco sospechoso para el administrador del sistema, pero la mayoría de los administradores del sistema no están vigilantes.

Como mínimo, eliminará nuestra conexión y / o intento de conexión de los archivos de registro. Por supuesto, puede haber otra evidencia dejada detrás tal como registros del router y registros del IDS.

En primer lugar, utilizar Metasploit para comprometer el sistema y obtener una  sesión de meterpreter.



Una vez que obtenemos una sesión de meterpreter en el sistema, escribimos lo siguiente:

  • meterpreter > clearev



Como se puede ver en esta captura de pantalla , todos los registros de eventos de Aplicación, Sistema y Seguridad se han borrado de los archivos de registro del objetivo.


Eliminación de registros de sucesos en equipos Linux

En los sistemas Linux, los archivos de registro se almacenan en el directorio /var /log. Podemos abrir y ver ese archivo de texto plano que contiene mensajes de registro abriéndolo con cualquier editor de texto.
  • kwrite /var/log/messages

Antes de abandonar el sistema comprometido, abriremos este archivo en nuestro editor de texto favorito, revisaremos y borraremos cuidadosamente  las entradas relacionadas específicamente con nuestra actividad en el equipo comprometido.


Borrado del historial de comandos

Finalmente, antes de abandonar el equipo linux comprometido, queremos asegurarnos de que nuestro historial de comandos se borra. Recordar, que la  shell de bash en la que estamos escribiendo guardará nuestros últimos 500 comandos. Un administrador del sistema podría rastrear todos nuestros comandos y detectar  nuestras actividades en el sistema y potencialmente utilizarlas como evidencia.

Para ver nuestro historial, podemos usar el comando more:

  • more ~/.bash_history

El tamaño de nuestro archivo de historial está determinado por la variable de entorno HISTSIZE. Podemos comprobar el tamaño de la variable HISTSIZE escribiendo:

  • echo $HISTSIZE

Entonces podríamos ponerlo a cero escribiendo:

  • export HISTSIZE=0

Ahora, nuestra shell no almacenará nada de nuestro historial. Recordar, hacer este cambio a cero antes de iniciar el ataque y para que no se almacenen ningún comando, pero si ya han escrito algunos comandos, tendremos que  cerrar sesión y volver a iniciar la sesión para borrar el historial después de establecer el HISTSIZE en cero.


Machacar el archivo del historial

A veces no tendremos tiempo suficiente para borrar el archivo de historial o cambiar la variable HISTSIZE. De prisa, podemos simplemente destruir nuestro archivo del historial escribiendo:

  • shred -zu root/.bash_history

Para comprobar si nuestro historial ha sido machacado, podemos ver el archivo de historial escribiendo:

  • more /root/.bashhistory

Happy Hacking.






domingo, 4 de junio de 2017

ByPaseando Captchas mal implementados.

Querido SimSimi, no soy un Bot sino un script de Python ;) 
Por: Samuel López Saura, @elchicodepython.



En este artículo vamos a ver y a explotar una implementación real muy pobre de un Captcha en un entorno de producción. El otro día jugando con unas librerías de Python para hacer Web Scrapping me propuse a modo juego crear un controlador para poder implementar bots en Whatsapp al igual que ya existían en Telegram para automatizar determinadas tareas de envío de mensajes repetitivos o cualquier otro uso. 




Divagando se me ocurrió conectarlo con SimSimi y dejar que SimSimi recibiera los mensajes que yo recibiese y respondiera por mi. Pensé en utilizarlo para cuando no quisiera continuar una conversación dejar que SimSimi la continuase. No obstante dadas las respuestas se iba a quedar en algo Just For Fun. SimSimi tiene una API para hacer uso de él pero es de pago y dado que no le iba a sacar ningún beneficio en principio no era factible. Así que de igual manera con más Web Scrapping nos comunicaríamos con SimSimi. Cuando recibiéramos un mensaje por Whatsapp. Se lo mandaríamos a SimSimi, esperaríamos su respuesta y cuando hubiera respondido responderíamos por whatsapp con la respuesta de SimSimi. Para manejar todo esto hice uso de la librería Selenium, el navegador Firefox y el lenguaje de programación Python3.


Todo parecía perfecto. Utilizando este método no tendría que pagar la API y podría hacer uso de SimSimi todo lo que quisiera. 

Pero al parecer al llegar a 20 mensajes saltaba una limitación en la que nos pedían escribir un número que encontraríamos en un vídeo que tendríamos que ver. Todo parecía haberse acabado pues mi script en Python en principio no sería capaz de entender el número del vídeo. 

No obstante el vídeo era público y estaba en youtube. Y cómo era público, (es decir, todo el mundo podía verlo sin necesitar especificamente el link) el resto de los vídeos de ese canal también lo eran. 
Con lo que me encontré con la irisoria cantidad de 5 vídeos con 5 pines distintos. (que además tenían los mismos números pero en otro orden) 

Además cada vez que saltaba la limitación SimSimi decía la misma frase. En otras palabras, la condición a la que estábamos esperando era cuando SimSimi diga

         Send a password(4 digit number) to talk more. 
         The video may give you the numbers 

Mira el último Link de la página cuyo hipervínculo empiece por https://youtu.be, dame su atributo href y en el diccionario de pines, que hemos guardado según hemos ido viendo los vídeos y anotando sus URL y su pin, dame su valor. 

a[href^="https://youtu.be 


Ahora que ya tengo el pin. Responde con el Pin y sigue funcionando.

 


En resumen a la hora de utilizar un captcha hay que cumplir unas especificaciones como que no se pueda leer leyendo el código de la página, que sea aleatorio, no se limite a unas posibilidades, etc... Si no podemos cumplir por nuestra cuenta o no queremos invertir en ello el tiempo necesario siempre podemos adquirir el servicio de un tercero que haga implementaciones adecuadas antes que hacer desastres de este tipo que se puedan saltar en cuestión de minutos. (y digo minutos porque hay que ver los vídeos para sacar los pines).

domingo, 21 de mayo de 2017

WAF BYPASS



DISCLAIMER: Honeysec no se hace responsable de cualquier uso que se le pueda dar a las herramientas que aparecen en el siguiente articulo, incluidos ataques a cualquier dispositivo móvil o tablet. Estas herramientas han sido publicadas con propósitos educativos y sin ninguna garantía.



 By: @txambe



Un firewall de aplicación web (WAF) es un dispositivo, un complemento de servidor o un filtro que aplica un conjunto de reglas a una conversación de HTTP. Por lo general, estas normas protegen contra amenazas comunes, como Scripting (XSS), inyección de SQL (SQLI) y otras vulnerabilidades relacionadas con aplicaciones web comunes.