Security Art Work

Al hilo del post donde se empezó a analizar la distribución HoneyDrive me ha parecido curioso mostraros una de las funcionalidades que nos ofrece el primer honeypot que estuvimos viendo: Kippo.

Esta utilidad, ubicada en el directorio /opt/kippo/utils/ es el script en Python playlog.py. Como su propio nombre indica, es un reproductor de logs; en este caso, muestra todo aquello que teclea uno de los atacantes que ha conseguido acceso a nuestro Honeypot. Para ejecutarlo basta con pasarle una de las sesiones de las capturas, ubicadas en el directorio /opt/kippo/log/tty/.

/opt/kippo/utils# ./playlog.py ../log/tty/20140618-131141-6038.log

El resultado es como el que se muestra en el siguiente video:

Como puede verse, se muestra una especie de grabación de lo que el atacante ha hecho al entrar en nuestro honeypot vía SSH, así como los resultados que va obteniendo. Además, incluye también lo que teclea cuando supuestamente se ha cerrado la conexión con nuestro servicio ficticio.

Aparte de esta curiosa utilidad, el honeypot Kippo nos facilita otras como, por ejemplo, createfs.py, que permite generar una estructura de ficheros y directorios a gusto del consumidor. En paralelo a estas herramientas, HoneyDrive nos ofrece unos scripts localizados en /opt/kippo-scripts/ para observar diferentes estadísticas y datos de lo obtenido por el Honeypot.

En el siguiente post mostraremos los resultados obtenidos en el despliegue de Kippo, aunque esperamos que sea en un entorno más amigable que mostrando el contenido de los ficheros. Estén atentos a su canal de emisión y recepción favorito.

Como ayer adelantábamos, estuvimos compartiendo mesa redonda con Esteban Gándara, uno de los padres de la nueva LSP, y como también comentamos ayer, aprovechamos para preguntarle sobre el papel de la seguridad “informática” en esta nueva Ley o, más concretamente, en el Reglamento de Desarrollo asociado… Dijimos que iba a dar juego para otro post, aquí lo tenéis :)

Personalmente, me impresionaron y mucho dos cosas de Gándara, al que no conocía en persona: la primera, su conocimiento sobre Seguridad Privada; aunque parecerá algo obvio pensando que es el máximo responsable del CNP en la materia, escucharlo hablar y responder a las dudas que todos planteábamos te dejaba con la boca abierta… Y la segunda, al hilo de las explicaciones y respuestas que daba al auditorio, su capacidad para explicar estos temas de forma amena, demostrando algo que a muchos nos parecía hasta ayer imposible: hablar de una Ley, con sus disposiciones, títulos, preámbulos y todo eso, sin hacerse en absoluto pesado ni tirar de términos que sólo los juristas conocen y que nosotros, comunes mortales, jamás entenderemos… Chapeau!!

Dejando de un lado el continente y centrándonos en el contenido, el Comisario Jefe de la UCSP dejó una cosa muy clara: la seguridad informática no es seguridad privada. La nueva Ley abre las puertas a que empresas de seguridad “clásicas” presten servicios de lo que denominan seguridad informática, pero como “nuestra seguridad” no es “seguridad privada” el Reglamento apenas regulará temas que nos conciernen. La LSP, como cualquier legislación, está acotada a un ámbito concreto del que no se va a salir y, en este caso, no se mojará en nuestro sector; sí que ha abierto las puertas a introducirse en él a empresas de seguridad “clásicas” -algo que en teoría no podían hacer, pero que en la práctica podían hacer de mil maneras-, pero poco más…

Además, el dejar fuera a seguridad “informática” había sido algo completamente consciente: por un lado, nuestras actividades no están alineadas con el concepto de Seguridad Privada, como comentaba, y además, el impacto que se podría causar en el sector si de la noche a la mañana se regula en la LSP podría ser de aúpa… Creo que estamos todos de acuerdo en que si esto se hace de la noche a la mañana no sería muy positivo, pero en algún momento habrá que plantearlo, no sé si en la LSP o en otra Ley, planificarlo correctamente y abordar el desbarajuste que tenemos ahora mismo en nuestro sector.

Al hilo de lo anterior, Gándara estaba de acuerdo -o eso me pareció- en que el sector necesita algún tipo de regulación, dada la importancia de la seguridad TIC hoy en día: una Ley de Ciberseguridad o como la quieran llamar en su momento, que sería estupenda pero que NO tiene nada que ver con la LSP ni con Seguridad Privada. Podría ser del Ministerio del Interior, del Ministerio de Defensa, de Presidencia o de cualquier sitio, porque en ciberseguridad muchos trabajamos en varios frentes menos acotados que en Seguridad Privada, pero ya se verá… si se ve.

El Reglamento de Desarrollo que algún día se publicará lo que vendrá a hacer es detallar las directrices de la Ley: básicamente, las empresas de seguridad “informática” podremos -algo completamente voluntario, al contrario de lo que sucede en Seguridad Privada- darnos de alta en un registro del Ministerio del Interior. Aparte de pagar las tasas, este registro obligará a, de una forma u otra, remitir las alertas (no sabemos cuáles, ni cómo, ni dónde…) al MIR de manera periódica y poco más. Si no se remiten no pasará nada: se sanciona a la empresa y punto :)

¿Y qué obtenemos a cambio, si esto es voluntario? Aparentemente un cierto reconocimiento: el sello de la UCSP, del Ministerio o de quien corresponda dando fe de que estamos dados de alta y reconocidos, y por tanto cubrimos nuestras obligaciones al respecto. ¿Esto nos diferenciará de la competencia, por ejemplo comercialmente? No lo sé, pero si todos estamos dados de alta en el registro, tengo mis reservas. En cualquier caso, toca esperar a la publicación del Reglamento de Desarrollo y a partir de ahí resolveremos alguna duda…

Para acabar, y como curiosidad, estuvimos comentando por qué nos llaman “seguridad informática”, a lo que la respuesta fue que es el término más extendido en el sector (frente a seguridad TIC, seguridad lógica, seguridad de la información, ciberseguridad…). En esto no estoy muy de acuerdo, pero bueno: sepamos que para “los de seguridad física” seguiremos siendo “los de seguridad informática” (y dando gracias que no nos llaman otra cosa… eso sí, o nosotros a ellos ;)

Esta tarde los compañeros de AVADISE organizan, en la Universidad Politécnica de Valencia, una jornada sobre la Ley de Seguridad Privada (Ley 5/2014, de 4 de abril de 2014): la nueva LSP. Vamos a participar en una mesa redonda junto a representantes del SEPROSE (Guardia Civil) y la UCSP (Cuerpo Nacional de Policía) a la que han invitado a diferentes representantes de la Seguridad Privada, en el sentido más amplio de ésta. Y este amplio sentido incluye, por supuesto, la ciberseguridad, seguridad informática, seguridad de la información… o como ahora le llamemos a “esto”.

La nueva LSP se publicó hace algo más de dos meses y en ella se hace referencia directa a los servicios de seguridad informática (en muchos blogs de seguridad se habló del tema en su momento); el Reglamento de Desarrollo regulará ciertos ámbitos de nuestra actividad, lo cual a priori, al menos bajo mi punto de vista, es muy interesante (otra cosa será lo que el Reglamento depare en su momento, que ya discutiremos).

La anterior LSP data de 1992; 22 añitos han pasado entre una y otra, periodo que desde un punto de vista legal no es nada (ahí tenemos la Ley de Enjuiciamiento Criminal, con alguna revisión pero que data de 1882 -sí, 1882-) pero que, en seguridad, es una eternidad. A principios de los 90 no sabíamos lo que era el phishing, el grooming, el timo nigeriano ni nada de eso -al menos no con esos nombres-; no teníamos media casa conectada a Internet (con suerte un módem que encendíamos por la noche con miedo a la factura telefónica para tirar a una BBS o a algún dialup de estrangis); no teníamos móviles, ni tabletas, ni USB ni nada parecido. Parece claro que las cosas han cambiado bastante, y la legislación tiene que ir adaptándose a ello, a los nuevos delitos -o a los delitos clásicos cometidos con nuevos medios- y, especialmente, a los nuevos roles en el mundo de la seguridad.

Y es que no es de recibo que para vigilar el perímetro físico de una fábrica de cerámica se requiera un determinado perfil y para auditar las tripas de la tecnología sobre la que se basa una central nuclear no se pida nada oficial. No se trata de comenzar de nuevo el flame de si esto lo puede/debe hacer un Ingeniero Informático, un CISA, un CPP, un Director de Seguridad Privada o un tipo de Cuenca que se tiene que llamar Paco. Se trata de que alguien con la suficiente autoridad determine de una u otra forma quién puede hacerlo y bajo qué circunstancias (y con qué responsabilidades, que muchas veces nos gusta olvidarnos de este tema) y a partir de ahí discutiremos.

Sé que el CCN está trabajando ya en un esquema de acreditación de personas para definir roles de trabajo en el ámbito de la seguridad, al margen de certificaciones generalmente estadounidenses que nos pueden gustar más o menos, pero no son “nuestras”. Desconozco los detalles y el estado de esta iniciativa, también interesante (si alguien los sabe, se agradecerán ;), y por supuesto no sé si la LSP tratará de aprovechar este trabajo -no lo sé, pero lo intuyo-. En cualquier caso, tendremos que estar atentos a ambas líneas, porque provienen justamente de dos de los actores que bajo mi punto de vista deben marcar las pautas de ciberseguridad en España, cada uno en su ámbito de actuación, por encima de empresas, asociaciones, grupos de interés y demás (escuchando la opinión de éstos, por supuesto, pero con independencia).

Esperaremos a ver qué nos depara el Reglamento de Desarrollo; aprovechando que esta tarde estará por la jornada Esteban Gándara, Comisario Jefe de la UCSP y uno de los padres de la criatura, pediré pistas sobre el rol de la seguridad informática en ese nuevo Reglamento. Seguro que da para algún post más :)

Para este miércoles tenemos una entrada de Antonio Sanz, Ingeniero Superior de Telecomunicaciones y Master en ICT por la Universidad de Zaragoza.

Actualmente es el Responsable de Sistemas y Seguridad del I3A (Instituto de Investigación en Ingeniería de Aragón), y trabaja como perito en informática forense. Posee las certificaciones CISA, CISM, CHFI e ITILf, y sus áreas de interés actuales son la respuesta ante incidentes, la informática forense y el cibercrimen. Tuitea como @antoniosanzalc y es un imprescindible en cuestiones de ciberseguridad, cibercrimen y APTs entre otros aspectos, dándole una perspectiva geopolítica sumamente interesante.

El fin de vida de Windows XP ha traído, está trayendo (y traerá) muchos quebraderos de cabeza tanto a administradores de sistemas como a los expertos en seguridad. En este artículo se pretende ofrecer soluciones y consejos basados en nuestra experiencia en el I3A (Instituto de Investigación en Ingeniería) de la Universidad de Zaragoza.

El primer paso a seguir es definir el objetivo del proyecto y los parámetros de partida. El objetivo principal no debería ser reemplazar Windows XP por otro sistema operativo, sino apoyar los procesos de negocio (en nuestro caso la investigación realizada por nuestros miembros). Ese apoyo se traduce directamente en este caso en una gestión del riesgo, orientada a controlar y reducir el mismo hasta niveles aceptables.

Como parte de los parámetros iniciales se tiene que el proyecto debería terminar lo antes posible (de forma óptima a principios de Abril, cuando se daba por finalizado el soporte). Por razones obvias de la coyuntura económica actual, el gasto a realizar debería de ser el mínimo posible.

[Read more…]

El “Cloaking” es una técnica de posicionamiento Web (Black Hat SEO) por la que se pretende engañar a los motores de búsqueda y mejorar así la posición de ciertos resultados. Consiste en mostrar un contenido de la Web diferente para el usuario y para el bot que la rastrea con el fin de manipular lo que éste indexa. Para entender mejor este tipo de técnicas os recomiendo la lectura de la saga “Técnicas SEO para gente de moral relajada” en “Un informático en el lado del mal”.

Recientemente hemos identificado un aumento de ataques contra CMS Joomla para explotar posibles vulnerabilidades con motivo de llevar a cabo la técnica de “Cloaking” descrita anteriormente, con el objetivo de favorecer sitios Web de venta de determinadas sustancias “médicas” (las típicas farmacias online). En este caso, en el que hablamos de sitios vulnerados por terceros, el “Cloaking” se complica un poco más.

Un escenario de “Cloaking” que podemos encontrarnos, por ejemplo, es aquel en el que si hacemos una determinada búsqueda en Google sobre una página legítima, aparentemente no vulnerada y ajena totalmente a lo que pudiera ser una farmacia online, nos muestra, que en parte del contenido que tiene cacheado aparezcan términos como “viagra”,”pills”,“drugs”, etc. provocando cierto daño reputacional a dicha página.

Por ejemplo, lanzando un dork como:

site:midominio intext:”viagra”,”pills”,”drugs”

sobre un dominio objetivo, es posible que nos indexen resultados como los siguientes, de páginas que han sido comprometidas para tal fin:

Si visitamos una de estas webs afectadas como un usuario normal, el contenido de la misma es legítimo a ojos del usuario, y no se ve por ninguna parte ningún tipo de contenido relacionado con las palabras mencionadas (viagra, drugs…) que sí aparecen cacheadas tras hacer la búsqueda. Sin embargo, si el sitio se visita con un user-agent de Googlebot, el contenido de esta página cambia y es entonces cuando se muestran enlaces a sitios relacionados con la venta de sustancias ilegales o similares. Un ejemplo real de lo que nos hemos encontrado es el siguiente:

A la izquierda se muestra un fragmento de la Web cuando lo visita un usuario cualquiera, con un user-agent habitual, aparentemente todo normal. A la derecha se muestra el mismo fragmento de la Web cuando lo visita el robot de Google. Como se ve, aparecen ciertas líneas (en verde) con el texto “buying viagra from boots”, “red viagra pills”…etc, y redirigen a sitios como:

hxxp://www. xxxxxxxx. org/search-results-viagra-buy-online/
hxxp://www. xxxxxxxxx. org/buying-viagra-from-boots/
hxxp://xxxxxx.com/red-viagra-pills/
[…]

Bien, los atacantes a través de dicha técnica aprovechan la visibilidad y buena reputación que puedan tener las páginas de las que se aprovechan para posicionar las suyas.

Como se ha comentado al inicio de este post, hemos detectado en las últimas semanas una campaña de explotación de sitios Joomla para llevar a cabo la técnica descrita. La mayoría de los sitios afectados usan versiones vulnerables y muy antiguas de Joomla (rama 1.5) aunque una de las principales vías de entrada que hemos detectado en este caso ha sido a través de versiones vulnerables del componente EXtplorer (com_extplorer). Este componente es explotable a través de diversos tipos de vulnerabilidades pero la que se está usando de forma masiva para este tipo de ataques es la denominada “eXtplorer v2.1 Arbitrary File Upload Vulnerability” descubierta por Brendan Coles a finales de 2012 y para la cual hay exploit público desde enero de 2013. Las versiones de eXtplorer afectadas a este bypass de la autenticación en este caso son la 2.1.2, 2.1.1, 2.10 y 2.1.0RC5.

Hemos encontrado de manera repetida que los atacantes han aprovechado estos Joomla vulnerables para subir un fichero malicioso llamado joomla_rss.php, y modificar el fichero application.php para que referencie a joomla_rss.php (ver imagen siguiente en la que se muestra la línea modificada del fichero application.php que referencia a joomla_rss.php, dentro de la función ‘render()’). Ambos en la carpeta includes.

Debajo podemos ver parte de la función render() en el fichero application.php:

Una línea correcta para este fichero sería:

JResponse::setBody($document→render($caching, $params));

El fichero joomla_rss.php tiene un aspecto similar a este y su funcionalidad es devolver determinadas páginas a ciertas IP o bots, es decir, es el causante de insertar/esconder los spam-links en la página afectada.

Otros ficheros maliciosos no relacionados directamente con esta técnica de “Cloaking” pero que también hemos encontrado de manera repetida en algunos Joomla han sido cpanel_config.php o jindex.php. Ambos presentan un aspecto similar a código siguiente:

Este tipo de shell aprovecha el contenido que se pasa en las cookies de una petición para ejecutarlo, pudiendo ejecutar cualquier tipo de parámetro en el equipo, o subir por ejemplo otros ficheros maliciosos. Una sencilla PoC metiendo un print a continuación evidencia el funcionamiento de la misma:

En definitiva, parece ser que los atacantes ven un filón en los componentes vulnerables de Joomla y continuamente escanean Internet en búsqueda de los mismos. Recientemente desde Spiderlabs alertaban también de otra vía de entrada masiva para comprometer sitios Joomla a través del JCE, que muy probablemente también estén usando para “Cloaking” o cualquier otro tipo de actividad maliciosa.

Para finalizar, recomendar actualizar siempre a las últimas versiones, componentes incluidos y usar solo los componentes, módulos y plugins estrictamente necesarios para los requerimientos de la Web. Recomendable usar también algún tipo de solución IPS/IDS o WAF tipo ModSecurity. La solución no pasa únicamente por eliminar los ficheros maliciosos.

En entradas anteriores ya se ha hablado sobre Dionaea, un honeypot de baja interacción que ofrece una gran variedad de servicios de red. El principal problema al que nos enfrentamos a la hora de desplegar un honeypot es como personalizar los servicios emulados para hacerlos indetectables ante herramientas de escaneado. Cuanto más le cueste a un atacante detectar que se encuentra ante un honeypot, más posibilidades tendremos de analizar su metodología, capturar exploits, binarios, etc.

Vamos a instalar Dionaea y modificar algunos de sus servicios para que no sean identificados por el escáner de red más utilizado, Nmap.

Podemos obtener Dionaea desde la página del proyecto. En la propia página se encuentran los pasos necesarios para su instalación. En nuestro caso hemos utilizado Ubuntu 12.04 como sistema operativo base. Los servicios activos por defecto en la instalación del honeypot son:

Una vez instalado Dionaea, lanzamos un escáner con Nmap para ver qué servicios son identificados y asociados con Dionaea gracias a su capacidad de fingerprinting:

# nmap -v -O -sV -sT -sU 192.168.100.10

En el resumen de la salida del escaneado mostrado a continuación se puede observar como algunos de los servicios los ha identificado y asociado a Dionaea. Uno de los primeros pasos en un test de intrusión es el descubrimiento de los activos de una red y sus servicios, por lo que si un atacante analiza la red con Nmap, detectará la existencia de este honeypot y probablemente cese el ataque y no conseguiremos capturar toda la información que quisiéramos.

Nota: La versión de Nmap utilizada es la 6.00. Otras versiones pueden modificar la capacidad de detección en función de las firmas o huellas que incorpore.

PORT     	STATE         	SERVICE      	VERSION 
21/tcp		open         	 ftp		Dionaea honeypot ftpd 
80/tcp   	open          	http		? 
135/tcp  	open          	msrpc		? 
443/tcp  	open          	ssl/https	? 
445/tcp  	open          	microsoft-ds 	Dionaea honeypot smbd 
1433/tcp	 open          	ms-sql-s     	Dionaea honeypot MS-SQL server 
3306/tcp 	open          	mysql        	MySQL 5.0.54 
5060/tcp 	open          	sip          	(SIP end point; Status: 200 OK)
5061/tcp 	open          	ssl/sip      	(SIP end point; Status: 200 OK) 
69/udp   	open|filtered 	tftp 
5060/udp 	open          	sip          	(SIP end point; Status: 200 OK)

Para personalizar los servicios y que no sean detectados por Nmap, primero hay que saber en qué se basa Nmap para identificarlos. Cuando Nmap intenta descubrir el producto que se encuentra tras un servicio, compara las cadenas de respuesta del servicio con los patrones incluidos en el fichero “nmap-service-probes” (localizado en /usr/share/nmap/). En la URL http://nmap.org/book/vscan-technique.html podemos ver el proceso seguido por Nmap para la detección de servicios. Por tanto, si conseguimos identificar y modificar los servicios de Dionaea en función de estos patrones, podemos conseguir que el servicio no sea identificado como Dionaea, o bien simular cualquier otro producto. Por ejemplo, podemos pasar de un servidor Apache a un IIS o un Tomcat.

Vamos a buscar en el fichero nmap-service-probes el servicio FTP de Dionaea y nos encontraremos con la siguiente línea:

match ftp m|^220 Welcome to the ftp service\r\n| p/Dionaea honeypot ftpd/

Esta línea contiene un mensaje de bienvenida característico de Dionaea, el cual es mostrado a un cliente FTP cuando se conecta al servicio y, además, el producto al que está asociado (Dionaea). Por tanto, tendremos que modificar este mensaje para que Nmap no pueda asociarlo a Dionaea. Hay que editar el fichero /usr/lib/dionaea/python/dionaea/ftp.py para cambiar este mensaje.

Este fichero escrito en Python es la implementación que realiza Dionaea de un servidor FTP. Cada servicio implementado por el honeypot se estructura en módulos, algo que va a facilitar bastante la personalización de estos servicios.

Podemos aprovecharnos de las huellas contenidas en el fichero nmap-service-probes y modificar el mensaje para que represente a un servidor ProFTPD, así que vamos a cambiar el mensaje inicial de Dionaea en ftp.py por uno de ProFTPD:

self.reply(WELCOME_MSG, "Welcome to the ftp service")
self.reply(WELCOME_MSG, "ProFTPD 1.2.8 Server")

El siguiente servicio que vamos a modificar es microsoft-ds (SMB/CIFS). En este caso, si buscamos el patrón correspondiente en nmap-service-probes, se puede ver como busca una coincidencia en la respuesta del servidor durante el establecimiento de la conexión. Esta coincidencia o patrón es:

\x00\x34\0W\0O\0R\0K\0G\0R\0O\0U\0P\0\0\0H\0O\0M\0E\0U\0S\0E\0R\0-\0.\0.\0.\0.\0.\0.

Este se corresponde con los campos que representan el nombre del dominio y del equipo, es decir, si el nombre del dominio es WORKGROUP y el nombre del equipo es HOMEUSER-XXXXXX, donde X es cualquier carácter alfanumérico, entonces el servicio es identificado como un servicio de Dionaea.

Para camuflar el servicio de compartición de ficheros e impresoras de Windows, tan solo hay que modificar los valores de los campos OemDomainName y ServerName en el fichero /usr/lib/dionaea/python/dionaea/smb/include/smbfields.py. Vamos a cambiar los siguientes valores y conseguiremos evitar que sea identificado:

OemDomainName: WORKGROUP → MIDOMINIO
ServerName: HOMEUSER-3AF6FE → EQUIPO-TEST	 

El tercer servicio identificado es el sistema de base de datos Microsoft SQL Server en el puerto 1433. Si buscamos este servicio en el fichero de patrones de Nmap, se puede ver una cadena en hexadecimal:

match ms-sql-s m|^\x04\x01\x00\x2b\x00\x00\x00\x00\x00\x00\x1a\x00\x06\x01\x00\x20\x00
   \x01\x02\x00\x21\x00\x01\x03\x00\x22\x00\x00\x04\x00\x22\x00\x01\xff\x08\x00\x02\x10
   \x00\x00\x02\x00\x00| p/Dionaea honeypot MS-SQL server/ 

Esta cadena se corresponde con la respuesta del honeypot a un paquete TDS (Tabular Data Streams) de pre-login en el proceso de conexión al servicio de base de datos. Si se realiza una captura de paquetes con un sniffer y analizamos las conexiones, podemos ver como esta cadena es la correspondiente al campo Token Type (en codificación hexadecimal) que tiene el valor 0x00.

Si cambiamos el valor 0x00 del campo Token Type, conseguiremos evitar la detección ante un escaneo de Nmap. Este campo se modifica en el fichero /usr/lib/dionaea/python/dionaea/mssql/mssql.py. Vamos a cambiar el valor establecido por 0xAA, que se corresponde con un mensaje de error, aunque podemos poner cualquier otro. Una lista de los valores aceptados para este campo los podemos encontrar en FreeTDS.

r.VersionToken.TokenType = 0x00 → 0xAA

Por ultimo, el servicio HTTPS no es identificado en el escaneo, pero basta con acceder a la URL del servidor web y echar un vistazo al certificado que presenta:

El certificado es emitido por Nephentes Development Team, los creadores del honeypot precursor de Dionaea (Nephentes), además de mostrar la URL del proyecto Dionaea. Así que debemos generar un certificado con algo más de “credibilidad” y sustituir al generado por defecto. Debido a que el certificado es generado en tiempo de compilación, hay que modificar los datos del certificado en el fichero dionaea/src/connection.c antes de compilar el honeypot.

Tras modificar los datos anteriores en los servicios, volvemos a realizar un escaneo de puertos al honeypot:

PORT     	STATE         	SERVICE       VERSION 
21/tcp		open          	ftp		ProFTPD 1.2.8 
80/tcp   	open          	http		? 
135/tcp  	open          	msrpc		? 
443/tcp  	open          	ssl/https	? 
445/tcp  	open          	microsoft-ds	? 
1433/tcp	open          	ms-sql-s	? 
3306/tcp 	open          	mysql         	MySQL 5.0.54 
5060/tcp 	open          	sip           	(SIP end point; Status: 200 OK) 
5061/tcp 	open          	sip-tls		? 
69/udp   	open|filtered	tftp 
5060/udp 	open          	sip           	(SIP end point; Status: 200 OK) 

Como se puede ver, los servicios descritos ya no son identificados como servicios de Dionaea, por lo que hemos conseguido evitar que un escaneo simple de Nmap detecte nuestro honeypot. Si realmente se quiere utilizar el honeypot para detectar ataques no automatizados y engañar a un atacante, entonces habrá que realizar una personalización más detallada de los servicios del honeypot para que generen un entorno mucho más realista y con mayores similitudes al servicio real que se intenta emular.

En esta ocasión me gustaría hablar de uno de los retos que solucioné hace poco y que encontré bastante interesante. En éste, debíamos conseguir acceder a la zona privada de una página web protegida con htaccess que contenía un blind SQL injection (vulnerabilidad ampliamente conocida, pero si alguien no la conoce, en Internet hay multitud de información, como por ejemplo https://www.owasp.org/index.php/Blind_SQL_Injection).

En MySQL disponemos de la función load_file, la cual nos permite acceder a un fichero siempre y cuando tengamos el privilegio FILE. Así que lo primero que debemos hacer es comprobar los permisos del usuario con que se están ejecutando las consultas.

Antes de continuar, me gustaría aclarar que todas las consultas se pueden hacer de forma manual, o con scripts realizados por uno mismo, pero hay veces que existen herramientas que nos facilitan mucho la tarea y se puede obtener el mismo resultado mucho más rápido. Como por ejemplo con sqlmap (http://sqlmap.org/), que sirve para explotar vulnerabilidades SQL injection.

[Read more…]

Para aquellos que os habéis enfrentado alguna vez a un análisis forense de memoria RAM, lo más seguro es que conozcáis Volatility. Esta potente herramienta desarrollada en Python permite obtener hasta la marca de café que beben los usuarios/atacantes que han hecho uso de un determinado equipo.

Como todo en la vida, se puede utilizar la mejor raqueta del mercado, pero uno no golpeará como Nadal, o se puede disponer de las mejores zapatillas de running pero uno nunca será Carl Lewis. Con Volatility pasa un poco lo mismo: no es una herramienta sencilla y tratar de encontrar un “bicho” o hallar evidencias de una intrusión no es trivial. Sí que es verdad que listar los procesos, obtener sus DLLs o incluso ver las conexiones establecidas en un momento determinado por la máquina es relativamente sencillo. Lo que ya no lo es tanto es la interpretación de la información que Volatility nos devuelve.

Es por eso que tras bucear por la estupenda wiki del proyect, e ir leyendo los diferentes posts o artículos recopilados por sus autores uno puede ir aprendiendo pequeños “trucos” sobre cómo detectar contextos anómalos y comportamientos específicos del malware. Con esta idea nace VolWrapper, una envolvente para Volatility escrita en Python que permite analizando la salida de los diferentes comandos de esta, identificar posibles anomalías presentes en la captura.

¿Cómo funciona VolWrapper? Pues simplemente redirigiendo la salida de la aplicación a la entrada de VolWrapper mediante una pipe.

root@hal9000:/home/ramado volatility  -f imagecapture.raw --profile 
   Win7SP1x86 dlllist | ./volWrapperV0.1.py

En estos momentos la envolvente soporta tan solo 3 comandos identificando situaciones anómalas para cada una de ellas: dlllist, psscan, pslist:

• Dlllist lista las librerías dll cargadas en cada uno de los procesos de la máquina. A menudo el malware pude trabajar en user space, inyectándose en un determinado proceso a través de estos métodos, por lo que durante la acción forense es recomendable revisar las diferentes librerías residentes en memoria. Este trabajo puede ser tedioso, por lo que en este punto entra en acción VolWrapper mostrando mediante una leyenda de colores información sobre las diferentes Dlls identificadas. Puede alertarnos de librerías fuera de los directorios tradicionales como system32, de capacidades de comunicación o de cifrado, incluso proporcionarnos una descripción de la funcionalidad de la dll.

  Esto no quiere decir que mágicamente no señale donde está el problema, pero sí que puede ser un soporte para cribar un montón de información que de otra manera podría suponer mucho tiempo de estudio. Ejemplo de ejecución (pinchar en la imagen para verla a tamaño completo):

  #volatility –f imagecapture.raw –profile Win7SP1x8 dlllist | ./volWrapperV0.1.py –c 
  

  

  Por ejemplo, de esta manera podemos identificar rápidamente si un proceso que aparentemente tiene una funcionalidad concreta como es notepad.exe está utilizando librerías de cifrado de datos o de comunicación, situación en un principio anómala. A su vez permite también centrarnos en todas aquellas librerías que a priori no están presentes en una instalación por defecto de un entorno Windows (listadas de color negro), centrando nuestra atención en ellas.

• Pslist permite obtener los procesos en ejecución en un momento determinado de la captura analizada. Una posible anomalía en cuanto a los resultados listados por Volatility puede ser procesos huérfanos, es decir sin PID padre aparente. Esta situación puede deberse a que un rootkit puede estar ocultando el verdadero proceso padre. VolWrapper permite identificar mediante un código de colores los procesos sospechosos.

  

• Psscan es similar al anterior, siendo un apoyo a psxview.

Resumiendo, la idea de la herramienta es ir ampliándola incorporando todas aquellas situaciones anómalas que identifiquen la presencia de algún artefacto. Por ahora tan solo soporta estos tres métodos pero irá creciendo, permitiendo a gente con menos conocimientos realizar un forense de RAM de forma más sencilla. Tenéis la herramienta en el siguiente enlace https://github.com/ramado78/volWrapper y en breve la añadiremos a la sección de herramientas “self-made” en SAW ;)

En este primer artículo vamos a explicar la instalación de este firewall basado en FreeBSD (), así como las múltiples opciones de instalación de paquetes que contiene. PFsense deriva de otra distribución anterior llamada monowall, más centrada en instalación de equipos embebidos (se ejecuta por completo en memoria RAM), ya que PFsense se puede instalar prácticamente en cualquier PC y tiene la capacidad de poder ser instalado en un disco duro.

Entre las funciones más destacables de PFsense se encuentran:

• Firewall: Filtrado (por IP, protocolo, puerto etc…), Limitación de conexiones, enrutamientos por regla, creación de alias.
• Tabla de estado: informa del estado de los servicios y conexiones.
• NAT (Network Address Translation): con cuatro tipos de configuraciones.
• Multi-WAN: Se pueden agregar varias conexiones de Internet con diferentes proveedores para poder usar balanceo de carga, usándose para distribuir equitativamente el ancho de banda o utilizar otra conexión en caso de que un ISP falle.
• Servidor VPN: con OpenVPN, IPsec o PPTP.
• PPPoE Server.
• Gráficos RDP.
• Soporte de DNS dinámico.
• Servidor DHCP.
• Portal cautivo, servidor Radius, Proxy Squid, IDS/IPS Snort etc.

[Read more…]