La pasada semana estuvimos mi compañero Amine y yo en el congreso de Seguridad RootedCON 2015 en Madrid. No hace falta que os hablemos de la importancia de estas conferencias a nivel nacional y, cada vez más, a nivel internacional (al menos en habla hispana).

Desde el pasado jueves 5 hasta el sábado 7, nos juntamos en el Centro de Congresos Príncipe Felipe unos cuantos compañeros de la profesión, estudiantes, cazatalentos de empresas de seguridad, miembros de las FCSE y todo tipo de “gente rarita” interesada por, sobretodo la Seguridad técnica, pero cada vez más presente, todo un abanico de diferentes tipos de seguridad.

Bueno, vamos al grano que hay mucha tela que cortar. Trataremos de haceros un breve resumen de cada una de las charlas a las que tuvimos la posibilidad de asistir, para que tengáis una idea de lo que se ha cocido este año por el congreso del candado.

[Read more…]

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.

Volvemos a la carga con uno de nuestros temas preferidos: los honeypots.

En este caso vamos a ver que nos ofrece HoneyDrive, una distribución Linux orientada a la seguridad TI y, en particular, al despliegue y control de herramientas de tipo Honeypot.

HoneyDrive ha sido creada por Ioannis “Ion” Koniaris de Bruteforce Lab, desarrollador de otras aplicaciones relacionadas con el mundo de los Honeypots como Kippo-Graph o Honeyd-Viz, que también analizaremos en profundidad más adelante.

La distribución se basa en una máquina virtual Xubuntu Desktop 12.04 en formato OVA (Open Virtual Appliance) que puede descargarse desde SourceForge.

Instalación

Vamos a desplegar la máquina virtual en nuestro entorno de virtualización. En este caso, usaremos el entorno recomendado por el propio Ion: VirtualBox-4.3 y la forma de desplegar es mediante la opción de “Importar servicios virtualizados” y seleccionando el fichero .ova (este proceso tarda un rato. Paciencia). No hay que definir los parámetros de la máquina virtual. Estos vienen predefinidos en la appliance. Tras el despliegue, procedemos a arrancarla. Accedemos con el usuario HoneyDrive y la contraseña “honeydrive”.

Pasos previos

Antes de ponernos a analizar que tenemos por delante, se deben configurar algunos aspectos como:

• La interfaz de red. Por ahora la he configurado con una interfaz de tipo “Adaptador sólo-anfitrión” asociada a la interfaz vboxnet0 que he creado previamente en el menú Archivo-> Preferencias-> Red-> Red solo-anfitrión-> Añadir
• Para que Honeydrive tenga Internet, deberemos configurar como Gateway nuestro equipo mediante:

sudo route add default gw < ip_vboxnet0 >

• Además, se debe configurar el reenvío de tramas en el equipo físico mediante:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

echo 1 > /proc/sys/net/ipv4/ip_forward

• Cambiamos el teclado del Anglosajón al nuestro ejecutando:

sudo dpkg-reconfigure keyboard-configuration

• Cambiamos el password del usuario honeydrive por otro mediante el comando "passwd"
• Es importante echar un vistazo al fichero README.txt alojado en el escritorio de nuestro Honeydrive. En él se encuentra información esencial y útil sobre las aplicaciones instaladas como pueden ser: ficheros de configuración, credenciales de acceso, scripts de arranque, etc.

Nuestro primer honeypot: Kippo

Como primera tarea, vamos a probar el honeypot Kippo. Se trata de un honeypot que emula un servicio SSH con el objetivo de obtener las credenciales usadas por los atacantes contra este tipo de servicios. En el fichero README.txt se muestran varios directorios y ficheros relacionados Kippo: script de arranque, directorio de descargas y de logs, fichero de credenciales “válidas”, de accesos a la base de datos, etc. Además, existe el fichero /opt/kippo/kippo.cfg donde se pueden configurar varios parámetros como puerto, IP, hostname, banner a mostrar, etc.

Vamos a probar Kippo:

En el sistema Honeydrive, arrancamos el honeypot desde el directorio /opt/kippo mediante el comando ./start.sh



Desde nuestro equipo, lanzamos un nmap simple y vemos que hay un servidor SSH a la escucha en el puerto 22/tcp (de los otros servicios ya hablaremos).



Nos conectamos a él.



En el primer intento hemos introducido la contraseña 1234 y no ha funcionado. En el segundo, hemos probado con 123456 y hemos podido acceder. Además, ha sido posible ejecutar comandos sobre el sistema supuestamente comprometido.

En el fichero /opt/kippo/log/kippo.log podemos ver con detalle todas las acciones llevadas a cabo. Incluidas las credenciales introducidas anteriormente.

En el fichero /opt/kippo/data/userdb.txt podemos comprobar las credenciales permitidas. En este caso root/123456

En el siguiente post de la serie, probaremos una forma más amigable de comprobar la actividad sobre nuestro Kippo y seguiremos indagando sobre HoneyDrive.

Hace un tiempo, por necesidades en el trabajo buscaba algo que me permitiera encapsular un payload de Metasploit y que éste no fuese detectado por los antivirus. En otras ocasiones he usado los “requetecifrados” con las múltiples opciones que permiten las herramientas msfpayload y msfencode. Otras veces me ha valido con las diversas herramientas que facilita SET (Social Engineering Toolkit) de Metasploit. Sin embargo, tras realizar varias pruebas, un antivirus actualizado detectaba el troyanete que iba dentro y saltaba enseguida. Quizás no elegía correctamente las opciones…

Así que buscando por Internet herramientas de evasión de antivirus enseguida me topé con VEIL. Si, lo sé, hemos estado todo el verano oyendo (y huyendo) de él, pero no, no es ese Veil…
Veil es una aplicación que cumple el propósito buscado: Empaquetar un payload de Metasploit y que los Antivirus no lo detecten. Está implementada en Python y, desde hace poco, está incluida en la distribución Kali Linux. Vamos con ella:

Descarga

Veil, desarrollada por @christruncer, se puede descargar desde la web del proyecto o puede hacerse un clonado de todos los ficheros mediante git:

#git clone https://github.com/veil-evasion/Veil.git

Instalación

La instalación no es muy enrevesada pero, como siempre, tenemos que andar con ojo con las dependencias. En este caso, Veil dispone de un instalador que permite la descarga e instalación de las dependencias (Wine, Python, PyInstaller, etc) en un Siguiente, Siguiente. Para ello se debe ejecutar el fichero /ruta_elegida/Veil/setup/setup.sh y responder a lo que nos vaya preguntando (son preguntas triviales). Cuando nos proponga descargar e instalar una serie de módulos, le diremos que sí.

Uso

Una vez instalado, vamos a hacernos un troyanete sencillo. Arrancamos Veil:

#python /ruta_elegida/Veil/Veil.py

y accedemos a la pantalla principal.

Las opciones son bastante simples y están explicadas, así que no hay escusa para no probarlas. Ahora vamos con el asunto principal, así que seleccionamos use.

A continuación se muestra la lista de payloads que hubiese aparecido si hubiésemos elegido la opción list. En ella se distinguen 18 payloads diferentes, agrupados por el lenguaje empleado para programarlo (c, c#, python…) y una valoración sobre la “calidad” del payload (poor, normal o excellent).

Vamos a elegir uno de los Excellent, ¿no? Y ya que estamos en un entorno Python y es un lenguaje que nos gusta, vamos a elegir el payload python/AESVirtualAlloc (opción 10).

La siguiente pantalla nos muestra las opciones del payload, que vamos a dejar tal y como están. Luego tenemos otra lista de opciones también muy básica.

Seleccionamos la opción que nos interesa: generate.

En la siguiente pantalla dejamos la opción por defecto para elegir el shellcode que queremos: msfvenom (opción 1) que según parece es una conjunción de los ya nombrados msfpayload y msfencode y seguimos.

Ahora toca elegir el payload que queremos que se ejecute. Por defecto nos ofrece nuestro gran amigo Meterpreter, pero puede seleccionarse cualquiera de los disponibles. Presionando el tabulador, se van mostrando las diferentes opciones. No os compliquéis, el seleccionado (windows/meterpreter/reverse_tcp) funciona muy bien. Si por cualquier causa os falla al probarlo, simplemente probad suerte con otro.

Bien, ya vamos acabando. Una vez elegido el payload, nos pedirá la IP y el puerto de LHOST, el equipo que recibirá la conexión inversa con Meterpreter. Luego nos dará la opción de añadir algún parámetro opcional de msfvenom, pero lo dejaremos como está. Pulsamos de nuevo enter y comienza la generación del shellcode.

Nos da la opción de ponerle un nombre al fichero resultante. Por ahora lo dejaremos con el nombre por defecto, luego ya se lo cambiáis si queréis (nominas2013.exe es mi preferido ;)

La siguiente pantalla ya es la última. Se nos ofrece la opción de usar Pyinstaller, el cual hemos instalado antes y con el que se genera un paquete .exe con todas las dependencias; o usar Py2Exe, el cual genera los tres ficheros necesarios para luego empaquetar el ejecutable.

Como hasta ahora, no nos complicamos y que lo haga él. Seleccionamos la opción 1 y finalizamos. En este momento empiezan a salir varios mensajes por consola mientras genera el ejecutable y finalmente, muestra un resumen de todo. En este se puede ver la ruta en la que ha dejado el resultado.

Cabe destacar el mensaje que se muestra al finalizar el proceso: No lo subas a una web de scanners antivirus (tipo VirusTotal). Estas Webs suelen mandar una firma de todos los archivos que se analizan a las casas de Antivirus, así que no os autotroleéis…

Pruebas

Vamos a ser rápidos. Probaremos en un precioso Windows7 con AVG actualizado a ver qué pasa…

Para la prueba debemos poner a escuchar nuestro equipo. Una forma sencilla que ya conocéis es mediante el handler de Metasploit. No hace falta añadir ninguna opción ya que el puerto por defecto es el 4444/TCP. Tampoco necesitamos ningún payload, ya va empaquetado en el ejecutable que hemos preparado. Lo lanzamos y esperamos…

Ejecutamos nuestro regalito en el Windows 7. Simplemente crea un proceso payload13.exe que no hace nada y no aparece ningún mensaje del Antivirus.

¡Tachán! Ya tenemos nuestro Meterpreter ejecutándose y controlado desde nuestra máquina.

Lanzamos el comando shell como prueba de que estamos ejecutándolo en la máquina Windows 7.

Dando una vuelta por el portal de The Honeynet Project me encontré con la noticia de una nueva versión de HoneyProxy, la 1.1. Vamos a tratar de hacer una pequeña introducción a esta herramienta y ver qué posibilidades nos ofrece.

La primera fase, la de instalación, es bastante rápida. Nos basaremos en que esta se realiza en un sistema Debian, pero no difiere mucho de otros sistemas Unix o incluso de la instalación en Windows. Basta con descargar el fichero.zip desde la Web del proyecto e instalar algunas dependencias.

La aplicación está desarrollada en Python por lo que necesitaremos instalar los paquetes python-pip y python-twisted. Seguidamente instalaremos los paquetes que necesita Python mediante pip. La instrucción sería la siguiente:

#pip install pyOpenSSL pyasn1 Twisted Autobahn

Una vez solventadas las dependencias, descomprimimos el archivo.zip y arrancamos la aplicación ejecutando el fichero honeyproxy.py

Como vemos en la imagen, una de las nuevas mejoras en esta versión de HoneyProxy es que levanta un pequeño servidor Web desde el cual es muy sencillo gestionarlo visualmente. Éste genera una URL de acceso única para la presente sesión, aunque desde el propio servidor puede accederse a través de http://localhost:8081.

Como vemos, el proxy que debe configurarse en los clientes Web o en el sistema que gestione dichas conexiones, ya sean HTTP como HTTPS, será la IP del servidor y uno de los puertos usados típicamente para Proxies, el 8080/TCP.

Un primer vistazo a la interfaz Web nos muestra un menú con 3 opciones.

La primera, Show Traffic, es una consola donde se puede observar de forma simple, dinámica y clasificados según el tipo de contenido, cada uno de los elementos que van siendo solicitados por los clientes Web y gestionados por HoneyProxy.

Pero si debemos destacar algo de esta sección, sin duda es la sencillez y la potencia de los filtros y marcadores por colores que pueden ser usados para el análisis del tráfico capturado. En ella destaca la posibilidad de aplicar tags como =<filtro> para realizar búsquedas sensibles a Mayúsculas (case-sensitive) o !<filtro> para obtener todos los resultados que no coincidan con una condición concreta. Finalmente, señalar la posibilidad de uso de nuestras grandes amigas: las Expresiones Regulares.

La siguiente sección es la que abarca los Informes o Reports. En ella es posible obtener, en diferentes formatos, información sobre la navegación de los usuarios de nuestro HoneyProxy.

Existen varios reportes interesantes como pagetree, con el que es posible generar una lista de los sitios visitados en estructura de árbol, o como post_extract, que muestra las solicitudes tipo POST que normalmente son usadas para transmitir, entre otros datos importantes, las credenciales de acceso a aplicaciones Web.

Pero si alguno destaca por encima del resto es el visual traffic_per_host. Como su nombre indica, desglosa el tráfico por cada servidor o host visitado, pero lo hace en forma de “gráfica de quesitos”, lo que permite un rápido primer análisis de los portales Web más consultados, así como su porcentaje respecto al total.

Destacar la posibilidad que ofrece la herramienta para usuarios avanzados donde se permite la interacción directa con el código fuente que genera cada uno de los tipos de reportes, tal y como se puede observar a la derecha de la imagen.

Finalmente, tenemos la opción Show Dumped Files, donde se muestra, en forma de lista de links accesibles, todos los ficheros solicitados por los usuarios.

Como se indica en la propia aplicación, es posible acceder a todos estos ficheros a través del directorio <ruta_instalación_honeyproxy>/dump/sites y poder realizar así cualquier procesamiento sobre ellos.

Un último punto interesante a destacar es la posibilidad de realizar todos estos análisis sobre tráfico de conexiones que hacen uso de SSL (HTTPS). HoneyProxy ofrece a los clientes Web su propio certificado para iniciar la relación de confianza entre ambos sistemas.

Como pequeña muestra, un acceso mediante HTTPS al correo de Google, GMail, nos muestra la típica alerta de Certificado No Válido (o no validado), dependiendo del navegador usado.

Si seleccionamos la opción de ver el certificado (en lugar de confirmar la excepción de seguridad directamente como hacen la mayoría de los usuarios), podremos observar que el parámetro CN para el cual el certificado es emitido coincide con la URL seleccionada, pero que el parámetro CN, el cual identifica la compañía que emite el certificado, no es Google, sino mitmproxy, nuestro HoneyProxy.

Sin embargo, como todos sabemos, esta comprobación es realizada por un número mínimo de usuarios. Sin embargo, con la presente Excepción de Seguridad, estamos dando total acceso a HoneyProxy sobre todas nuestras comunicaciones que, erróneamente, creeremos cifradas.

Estas son solo algunas de las opciones presentes en HoneyProxy, pero hay muchas más. Si estáis interesados en profundizar en otras de las posibilidades que nos ofrece, podéis consultar su Wiki y contarnos otras prestaciones que hayáis descubierto.

Nota: HoneyProxy está muy ligado al proyecto mitmproxy, por lo que es interesante que se consulte información sobre dicho proyecto si se pretende hacer un uso profundo de HoneyProxy.

El anecdotario que puede extraerse de cada auditoria de seguridad que realizamos es siempre muy variado. Esto no es más que una pequeña solución a un problema encontrado en una de ellas.

Pongámonos en situación. El cliente utiliza una infraestructura formada por Thin Clients. Las medidas de seguridad implantadas en la red, principalmente a través de directivas de Active Directory, son altamente restrictivas.

Entre otras muchas limitaciones, nos encontramos con un escenario en el cual no se permite el acceso a varias zonas del sistema, se filtran la mayoría de conexiones a Internet a través de listas blancas en el proxy, no se puede montar unidades de almacenamiento externo y no se permite la ejecución de la mayoría de los ficheros ejecutables conocidos. Señalar además que todas las directivas aplicadas a través de AD dificultan mucho el análisis de seguridad, y por tanto una posible intrusión. Administradores de sistemas Windows: ¡ánimo! ¡Aplicad Directivas de Seguridad! ¡Funcionan! ;)

[Read more…]

(Para este viernes tenemos una entrada con un enfoque ligeramente diferente a la temática habitual, aunque sin duda es un entorno en el que la seguridad y el correcto funcionamiento de los equipos juega un papel esencial)

Tras el primer post de calentamiento y una vez conocidas las herramientas de las que disponemos (todo el dispositivo explicado anteriormente), estamos dispuestos para afrontar los incidentes de seguridad que se vayan presentando a lo largo de la jornada.

Hoy tenemos por delante varias sesiones con automóviles en la pista, donde cada una de una de ellas presente una criticidad diferente:

• Los incidentes durante las sesiones libres, donde se realizan las pruebas necesarias para que todo lo relacionado con el equipo (dirección, piloto, mecánicos y técnicos, automóvil, etc.) funcione a la perfección. Se puede comparar este tipo de preparación con la formación y las tareas cotidianas de un equipo de seguridad TI, donde el trabajo de cada uno de los miembros es fundamental para obtener los resultados esperados.

  [Read more…]

Tras la celebración del Gran Premio de Europa de F1 en Valencia el pasado fin de semana y dado que un servidor tuvo el placer de acudir a él por quinta vez como comisario de pista, se me ocurrió escribir un post sobre los aspectos relacionados con la seguridad en este deporte; más allá de los aspectos técnicos implicados en la seguridad del propio vehículo, quería centrarme en los que más conozco, los relativos a la seguridad en la pista.

En muchas ocasiones la gente me pregunta: “Vale, pero, ¿a qué te dedicas cuando vas al circuito?” Una vez, un compañero del circuito hizo una descripción que me gustó bastante. Era algo así como: “Nuestro trabajo consiste en que la pista esté en todo momento en las mejores condiciones para que los pilotos puedan hacer su trabajo con la mayor eficacia y seguridad posible“. Esta descripción me recordó bastante al trabajo que realizamos diariamente los que nos dedicamos a la Seguridad TI, ¿no?

Empecemos por conocer el dispositivo en pista, los miembros que forman el dispositivo de tandas o carreras, ya sea de motociclismo o de automovilismo. Está compuesto por una gran cantidad de personas, con múltiples responsabilidades y sin las cuáles el evento no podría llevarse a cabo. Sin embargo, nos centraremos en los dispositivos de seguridad en pista, pudiendo hacer referencia a otros integrantes en ciertas ocasiones.

Previamente al inicio de la jornada, todos los miembros del equipo tienen que tener clara su función y el protocolo de actuación a seguir durante cualquier incidente. Cuando se trata de un acontecimiento de una cierta entidad, y no cabe duda que una carrera de Fórmula 1 o de MotoGP lo son, un dispositivo está formado por un equipo de personas con unas funciones comunes y otras propias, las cuales deben estar distribuidas previamente. Concretamente, en un puesto específico, ubicado normalmente en una curva del trazado, el equipo está formado por:

1. Un jefe de puesto, cuyas responsabilidades dentro del grupo son, entre otras, asignar las funciones de cada miembro del equipo según los criterios que considere (experiencia, fuerza, habilidad…), asegurarse que el material necesario está perfectamente revisado y listo para usarse y mantener la comunicación mediante walkie-talkie con dirección/control de carrera, informando de cualquier incidencia dentro o fuera de la pista. También es el encargado de sincronizar a los miembros del equipo durante una intervención, así como responsabilizarse de las actuaciones y comportamiento del resto del grupo de comisarios. Personalmente, y aunque esto seguramente no se encuentra en ningún manual, creo que una de las tareas más importantes es la de mantener el buen ambiente de trabajo y compañerismo entre los miembros del equipo.
2. Comisarios de intervención, los cuales tienen que estar preparados en todo momento para actuar ante cualquier imprevisto en la pista (normalmente un accidente) y realizar las tareas necesarias para que tanto la pista como su entorno quede tal y como estaba antes del incidente (sin el vehículo accidentado, sin piezas rotas, etc.). Estos comisarios, como cualquier persona que salga de detrás de la bionda, deben tener especial cuidado con el resto de los vehículos que circulan por pista, evitando darle la espalda a la misma y estando siempre atentos a cualquier nuevo incidente mientras llevan a cabo el rescate. Además, durante carreras de motociclismo, son los encargados, junto con el jefe de puesto, de extraer las motos de la puzolana en el menor tiempo posible. En caso de que fuera necesaria ayuda al piloto, serían los encargados de resguardarlo con una protección de gomaespuma (antes eran balas de paja) hasta la llegada del personal médico especializado; en el caso de competiciones automovilísticas, tratarán de hacer todo lo posible por devolver el vehículo a pista y ayudar a los miembros del equipo de Rescates en su extracción en caso que no sea posible su regreso a la actividad de pista.
3. Comisarios de bandera, normalmente dos; son lo que se deben preocupar de la señalización a los pilotos mediante las diferentes banderas, los paneles luminosos en F1, el panel de números en carreras de motos o el panel de SC (Safety Car) en carreras de coches. Deben estar muy atentos al transcurso de la tanda o la carrera ya que son los encargados de comunicar al resto de pilotos cualquier incidencia.



4. Comisario bombero, claramente encargado de la extinción de cualquier conato de fuego que pueda producirse en el vehículo tras el incidente. No suele ser habitual que se produzcan incendios, pero cuando éstos ocurren es indispensable tener una persona encargada de los extintores ya que el vehículo puede arder en pocos segundos y resultar un peligro, tanto para el piloto como para los propios comisarios (por no hablar de la pérdida económica que supondría)

Aparte de las ubicadas en cada puesto, otras personas que forman el dispositivo de seguridad son las siguientes:

1. Servicio médico. Equipo compuesto normalmente por un médico y/o enfermero y un conductor de ambulancia. No se encuentran en todos los puestos del circuito por lo que deben estar atentos a cualquier incidente de carrera para acudir a aquellos puestos que deban cubrir. Habitualmente se asigna algún comisario de intervención para ayudar al servicio médico a trasportar la camilla si fuese necesario u otras tareas similares.
2. Comisarios de Rescates. Están dedicados a dar apoyo a los comisarios durante las intervenciones. Son un grupo especializado que, como el servicio médico, no están en todos los puestos del circuito, teniendo cada grupo de rescate diferentes zonas del trazado a las que dar apoyo. El equipo de rescates maneja varias scooters, pick ups (alguna con plataforma para cargar motos), tractores, grúas con plataforma (para cargar turismos y fórmulas) y otros vehículos industriales usados para el rescate o transporte (grúas tipo manitou, grúas-pluma…).
3. Dotación de bomberos. Existe un grupo de bomberos profesionales al tanto de las incidencias de carrera y dispuesto a intervenir en caso de que fuese necesaria una actuación más especializada.
4. Equipo de excarcelación. Grupo especializado en la extracción de pilotos del vehículo tras un accidente grave donde el piloto no puede salir por sus propios medios. Deben estar perfectamente sincronizados con el equipo médico. Sus intervenciones son escasas pero a la vez muy críticas cuando se realizan.

Una vez recopiladas y organizadas las “herramientas” que componen nuestro equipo de trabajo, estamos preparados para afrontar aquellas incidencias que surjan. Pero ésto solo ha sido la vuelta de calentamiento, los accidentes empiezan el próximo post. ¡Estén atentos al semáforo!

(La foto del Ferrari es de JiteshJagadish en Flickr, mientras que la de los comisarios es de Xabiandu en Twitter)

Los ataques de SQL-i siguen con nosotros. Por ejemplo, hace unos días un hacker hizo uso de esta técnica para obtener los contratos entre la compañía CEIEC y el Ministerio de Defensa chino.

Debido a su criticidad y efectividad, el peligro que suponen los ataques de Inyección de Código SQL ha ido creciendo frente a otro tipo de amenazas hasta situarse como la principal amenaza para las aplicaciones Web (en lucha encarnizada con los ataques Cross-Site Scriptings XSS).

El rápido crecimiento de la oferta de servicios a través de Internet ha generado un amplio abanico de aplicaciones que, en su mayoría, utilizan bases de datos para almacenar y proporcionar la información.
El riesgo inherente en este tipo de aplicaciones es que durante la entrada de datos por parte del usuario,se manipule la consulta legítima a la base de datos y se genere otro código manipulado, permitiendo acceder a información de la base de datos o eludir la autenticación. Pero como la mayoría de ustedes ya saben que son los SQL-i, vamos a pasar a lo que interesa: nuevas técnicas para prevenirlos.

Basándome en un paper que leí el otro día, voy a exponer algunas de las técnicas que están siendo objeto de estudio por parte de diversos investigadores y desarrolladores para defenderse de los temidos ataques SQL-i:

[Read more…]

En anteriores entradas sobre honeynets ya tratamos los diferentes tipos de honeypots y sobre las arquitecturas posibles en una red trampa. En este artículo vamos a identificar otros componentes esenciales para completar una honeynet: las herramientas de control, captura, monitorización y análisis de datos.

Como se indicó en el primer artículo, uno de los objetivos buscados a la hora de implantar una honeynet es el de analizar los vectores de ataque de la que ésta es víctima. Para alcanzar este propósito, hemos de tener en cuenta el resto de las tareas a gestionar de una honeynet y las herramientas o aplicaciones que ayudan a acometerlas.

• Control de Datos: Siempre cabe la posibilidad de que nuestra red trampa sea vulnerada por un atacante o incluso que sea utilizada para realizar desde ella otros ataques a mayor escala. Para mitigar en lo posible este riesgo, es necesario llevar a cabo un correcto control sobre los datos de entrada y salida de la honeynet. Veamos algunos mecanismos:
  • Firewall: Una de las herramientas fundamentales para realizar un correcto control de datos es un cortafuegos (p.e. IPtables). En él se deberá definir claramente el tipo y la cantidad de conexiones que se permite en nuestra red, tanto de salida como de entrada, evitando así la posibilidad de, por ejemplo, recibir o realizar ataques de fuerza bruta. También deberá estar correctamente especificado el tráfico que permitimos de una parte a otra dentro de la propia red, evitando la posibilidad de que el atacante pueda acceder a la parte de administración de la misma o incluso, si existe, a zonas de la red en producción. Todas estas restricciones deberán estar enfocadas a que el atacante disponga de un cierto grado de libertad para interactuar con nuestros honeypots, de lo contrario la honeynet no podrá cumplir con su objetivo. Finalmente, es muy recomendable realizar un control de datos por capas (p.e. cantidad de conexiones entrantes o salientes, restricción de protocolos, restricciones de ancho de banda…) en el que no exista un único punto de fallo y se pueda reaccionar a tiempo ante ataques novedosos.
  • Honeymole: Se utiliza para las granjas de honeypots. Implementa varios sensores que redirigen el tráfico a una colección centralizada de honeypots. Desarrollada y mantenida por el Chapter de Portugal de Honeynet Project.
  • Honeysnap: Herramienta usada para la extracción y análisis de datos de archivos pcap, incluidas las comunicaciones IRC. Desarrollado y mantenido por Arthur Clune del Chapter del Reino Unido.
• Captura de Datos: La captura y almacenamiento de la actividad, tanto de entrada como de salida, es una tarea fundamental en una honeynet. Un análisis de los datos, ya sea con el objetivo de la formación o aprendizaje, como si es el de analizar un posible ataque fuera de los controles habituales de la red, necesita de una buena recolección de información. Es recomendable efectuar una captura de datos a varios niveles. Podemos diferenciar entre 3 niveles diferentes y complementarios:
  • El registro del Firewall: “Logear” todo el tráfico controlado por el cortafuegos. Es el punto crítico y donde es posible obtener mayor información sobre las actividades llevadas a cabo por el atacante.
  • El tráfico de red: Captura de cada paquete, junto con su contenido (payload), que entra y sale de la red. Para esta tarea, la herramienta más indicada es un IDS (Sistema de Detección de Intrusiones), concretamente se aconseja el uso de Snort, un IDS de software libre usado masivamente por los administradores de sistemas y grupos de seguridad, y que ofrece una configuración y clasificación envidiable. Puede usarse la aplicación BASE (Basic Analysis and Security Engine) para acceder y analizar la información capturada de una forma ágil y sencilla.
  • Actividad del sistema: La captura de la actividad ocurrida en el honeypot es otra parte fundamental para la comprensión del ataque. Esta puede resultar más complicada de lo que en un principio pueda parecer ya que actualmente se utilizan conexiones cifradas. Aún así, si el honeypot lleva a cabo correctamente su cometido, la comunicación será descifrada y podrá ser analizada. Como ya comentamos en el post de la serie que trataba los diferentes honeypots, uno de los de alta interacción, Sebek, está orientado a registrar las pulsaciones de teclado del atacante directamente desde el kernel, lo que nos permite seguir de una forma muy efectiva su actividad en el honeypot.
• Monitorización de Sistemas: Para comprobar el correcto funcionamiento de nuestros sistemas en la honeynet, es muy aconsejable mantenerlos en constante monitorización. Una caída de un servidor (físico o virtual) provocada por un atacante, un aumento excesivo en el tráfico de red en una zona específica de la red, una subida de carga de CPU, memoria o una reducción del espacio de disco, son posibles síntomas de estar recibiendo un ataque efectivo sobre nuestros sistemas, por lo que estos deben estar controlados y deben ser detectados lo antes posible.
  • Nagios: Herramienta de monitorización de software libre muy popular en los entornos de administración de sistemas. Su modularidad y sencillez, a la vez que las múltiples posibilidades de monitorización que ofrece, la hacen una pieza prácticamente esencial en cualquier red. En el caso de una red trampa, más si cabe.
• Análisis de Datos: Finalmente, llegamos al objetivo por el cual se implantan y despliegan los honeypots en una red: el análisis y la interpretación de los datos y la actividad recolectados. Para ello podemos consultar todo tipo de ficheros de log creados por cada uno de los honeypots y las herramientas que se han especificado anteriormente, o tratar de centralizar los datos para un estudio mucho más cómodo y completo, pudiendo relacionar actividad y datos provenientes de diversas fuentes.
  • Prelude: Herramienta que recoge y centraliza información concreta y clasificada de los honeypots que se hayan integrado. Esta herramienta dispone de una interfaz web, Prewika, que facilita el acceso a la información recogida para posteriormente analizarla de forma rápida y sencilla. De esta forma es posible tener un centro de control del comportamiento de la honeynet donde poder analizar de una forma centralizada la información recolectada por nuestros botes de miel.
  • Capture BAT: Herramienta de análisis de comportamiento de las aplicaciones para sistemas de la familia Win32. CaptureBAT es capaz de controlar el estado del sistema durante la ejecución de aplicaciones y el procesado de documentos y que proporciona un análisis completo de cómo funciona el software, aún cuando no está disponible el código fuente. CaptureBAT monitoriza los cambios de estado del núcleo a bajo nivel y se puede utilizar con facilidad en diversas versiones y configuraciones de sistemas Win32. CaptureBAT está desarrollado y mantenido por Christian Seifert del Chapter de Nueva Zelanda de Honeynet Project.

Con esto, y a lo largo de cuatro entradas, hemos intentado analizar más o menos en profundidad los aspectos más importantes de las honeynets, serie que esperamos que les haya sido de utilidad. No obstante, si en algún punto quieren que incidamos algo más, o que expliquemos con más detalle alguna cuestión, ya saben que no tienen más que indicarlo en los comentarios.

(Entrada escrita en colaboración con Raúl Rodriguez, co-autor de la serie)