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

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).

Blue Team Debian - Frenando los ataques más comunes en red

Autor: @elchicodepython

Introducción

Antes de comenzar me gustaría comentar que todos los caminos llevan a Roma y hay mil formas de llegar al mismo punto en un sistema GNU/Linux. Con este manual no estoy diciendo ni que esta sea la manera ideal ni la única para llegar al punto de mitigar estos ataques en redes locales, sino que estoy tratando de explicar detalladamente como defenderte según he aprendido a defenderme yo.

Wordpress, Temas y Botnets

By @elchicodepython (Samuel López)

Cada vez más escucho a más personas decir barbaridades del estilo ¡cómo me voy a infectar con un tema si es solo la parte gráfica! No me preocuparía tanto de no ser porque es en el propio sector del desarrollo web donde lo estoy escuchando actualmente. Esto tiene una explicación y es debido a que como la tendencia en pequeños mercados a abaratar costes muchas veces llega a un punto de desarrollo insostenible.