viernes, 15 de diciembre de 2017

Mamá, mi web me mina !!!



By @RaulRenales

Estos días se está hablando mucho de unas 5000 webs que al visitarlas minan a favor de los dueños de las mismas. Se estima que existen unos 1.65 millones de equipos afectados por esta práctica. El objetivo de este artículo es revisar los aspectos técnicos que rodean a esta situación y poner un poco de luz sobre el asunto.

jueves, 14 de diciembre de 2017

AutoIT, creando un señuelo para los malos


By @RaulRenales


Tras dos artículos previos presentando el lenguaje AutoIt y realizando algunos ejemplos para ver la panorámica del lenguaje llegamos a la tercera entrega en la que crearemos una pequeña aplicación que nos permite crear puertos y permanecer a la espera de si son utilizados, básicamente intentaremos vigilar algunos puertos comunes y permitir crear puertos a medida.

lunes, 11 de diciembre de 2017

AutoIT, segundo asalto


By @RaulRenales


En artículos anteriores presentamos que es AutoIT y creamos nuestro primer ejemplo para ver como funciona este lenguaje de script que está orientado a administradores de sistemas y que es uno de los lenguajes utilizados en la creación de Malware.


En esta segunda entrega vamos a dar una vuelta por la panorámica del lenguaje realizando algunos ejemplos, el objetivo es coger algo de soltura de cara al tercer artículo en el que realizaremos un script que levante puertos y gestione eventos sobre ellos a modo de HoneyPot.

jueves, 7 de diciembre de 2017

AutoIT, ¿Que es?¿Como funciona? ... y ¿Por que lo usa el Malware Bancario Brasileño?


By @RaulRenales


Recientemente me pareció curiosa la siguiente noticia, “AutoIt Scripting utilizado por Overlay Malware para eludir la detección AV”, en la que se explicaba como el equipo X-Force de IBM había detectado el uso de scripts de AUTOIT en malware usado para el robo de sesiones de acceso a bancos brasileños, el objetivo de usar este tipo de scripts es simple y llanamente emular las acciones humanas para evadir el control de los Antivirus.

domingo, 3 de diciembre de 2017

Talleres avanzados sobre Bases de Datos

Talleres de formación sobre bases de datos

El próximo 16 de diciembre arrancará un nuevo curso de formación relacionada con Bases de datos y su importancia desde el punto de vista de la seguridad. La formación constara  de 4 semanas y se realizará los sábados por la mañana en el CMI Eduardo Guitián.


Los talleres, que se repartirán entre diciembre y enero, tratarán de guiar a sus asistentes en la instalación y configuración de servidores de bases de datos, el manejo de los lenguajes SQL y las connotaciones de seguridad que este tipo de sistemas conlleva.

viernes, 1 de diciembre de 2017

Trasteando con Javascript desde el CMD





By @RaulRenales

Últimamente ando liado buscándole la vuelta de tuerca a JavaScript, como ya sabéis de episodios anteriores me gusta esconder en archivos SVG regalitos que puedan ser ejecutados a la carga de la imagen. La pasada semana jugábamos con js creando un pequeño keylogger que funcionaba a la maravilla, esta semana voy a dejar un poco de lado las imágenes svg y voy a contar una cosa curiosa que me he encontrado trasteando, usar javascript como payload en cargas a CMD.

lunes, 27 de noviembre de 2017

Img con keylogger



Recientemente he leído una noticia que me llamo mucho la atención, "482 de los sitios web más populares registran cada pulsación de teclado realizada por sus usuarios" en la que se denunciaban mas de 480 sitios web que graban las pulsaciones de teclado de sus visitantes con el objetivo de aprender sobre ellos y como no ofrecernos mejores ofertas con un marketing muy agresivo.

jueves, 16 de noviembre de 2017

HoneyCon 2017



El pasado 11 de noviembre se clausuró la tercera edición del congreso de seguridad informática ciudad de Guadalajara, conocido popularmente como Honey Con. Como todos los años es un momento álgido en la vida de la asociación Honey Sec en el que intentamos compartir conocimiento, experiencias y buenos momentos con amigos y gente que quiere acercarse al mundo de la ciberseguridad.

Este año el congreso ha crecido tanto en número de participantes, casi un millar, como en el de eventos ofertados durante 3 días. También cambió el formato y se incluyen novedades como la olimpiada de programación para institutos y un CTF en colaboración con el INCIBE.

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.