Security Art Work

Unos días atrás, nos encontramos con un nuevo reto en el que a partir de un archivo comprimido que se había capturado, debíamos descubrir que técnicas o consejos se decía que se estaban utilizando últimamente para instalar malware en los sistemas.

Al abrir el fichero attachment.rar vemos que contiene tres imágenes de ruinas romanas: “0.jpeg”, “1.png” y “3.jpg”.

Fijándonos un poco, lo único que destaca de las fotografías son los pequeños números romanos que aparecen en la esquina inferior derecha de dos de las fotos (“II” y “IV”) y que parece ser que falte la imagen “2”, ya que pasa de la “1” a la “3”.

[Read more…]

Hace un tiempo leí este artículo del Washington Post en el que se hablaba sobre el funcionamiento de las Google Glass y las dudas que habían surgido en cuanto a su impacto en la privacidad de sus usuarios y de las personas que les rodean.

Este artículo me hizo plantearme si nuestra sociedad está preparada para utilizar en su día a día un dispositivo de estas características y si es consciente de las consecuencias que puede tener usarlo. No estoy hablando únicamente de las reacciones que las personas puedan tener frente a un usuario de Google Glass sino si nuestras leyes están preparadas para afrontar los posibles escenarios que puedan darse y actuar correctamente.

Durante estos últimos meses, Google ha vendido una cantidad limitada de su prototipo a desarrolladores e ingenieros con el fin de testearlas y empezar a perfilar la que será su versión comercial, y acto seguido, empezaron a producirse situaciones complicadas e incómodas para sus usuarios, como por ejemplo: una persona fue agredida por usarlas en un espacio público, otra fue expulsada de un cine por entrar con ellas puestas.

Y es que uno de los principales problemas de este dispositivo, es que las personas que están alrededor de un usuario de Google Glass no pueden estar seguras al 100% de lo que esta persona está haciendo con ellas. ¿Cómo podemos saber si están grabando nuestra conversación? ¿O publicando una foto o un vídeo que nos acaban de hacer sin nuestro consentimiento? ¿O grabando el pin que acabo de teclear en el cajero de mi banco para sacar dinero? Está claro que todas estas acciones ya pueden llevarse a cabo hoy en día con otros dispositivos, como los smartphones, pero de una forma mucho más obvia y detectable para las personas que son observadas.

El funcionamiento predeterminado de Google Glass hace que cuando el dispositivo se active para realizar una acción, se ilumine la pantalla, y además, el usuario debe decir el comando de voz correspondiente o realizar las acciones necesarias con el touchpad, pero ¿y si el dispositivo ha sido reprogramado para que actúe de otra forma menos detectable? Google ha publicado una serie de APIs que permiten desarrollar apps para Google Glass o Glassware, pero que a su vez y teniendo los conocimientos necesarios, también pueden permitir modificar el comportamiento predeterminado de estas, o lo que es lo mismo, hackearlas. Ya se ha publicado información sobre usos alternativos a los programados oficialmente por Google, como por ejemplo, reprogramar el dispositivo para que permita el reconocimiento facial o la posibilidad de hacer fotos mediante el guiño de un ojo, en lugar de usar el comando de voz o el touchpad. De igual manera, si un dispositivo es hackeado, el atacante puede ejecutar acciones sobre el dispositivo y obtener información en tiempo real sobre el usuario legítimo. Todas estas modificaciones realizadas en unas Google Glass, pasarían desapercibidas para las personas que rodean al usuario de Google Glass y algunas de ellas, incluso para el propio usuario.

Ahora mismo este tipo de hacking se está haciendo con el consentimiento (o por lo menos conocimiento) de Google, ya que están en la fase de testeo, y parte de esta fase consiste en solucionar las vulnerabilidades que se encuentren en el prototipo y mejorar el software, pero no es difícil imaginar las posibilidades que tiene este dispositivo cuando sea comercializado y usado a nivel mundial.
En un futuro, las aplicaciones que este tipo de dispositivos pueden tener en servicios como seguridad vial y ciudadana, ambulancias, extinción de incendios, mejora en la calidad de vida de personas con deficiencias auditivas o visuales, entre otras muchas, pueden llegar a tener un gran impacto en la sociedad en general. Considero que sería necesaria e indispensable una campaña de concienciación y educación ciudadana entorno a lo que ya se conoce como el “Wearable Tech Market” y que la legislación debe actualizarse y evolucionar en consecuencia. Pero hoy por hoy, ¿estamos preparados?

Ampliando el post de mi compañero José Vila (@jovimon) sobre introducción a túneles SSH, os quiero mostrar otros truquillos para aquellos que usamos SSH a diario, y poder así agilizar tareas. Ya sabéis, para ser productivo hay que ser un maestro kung-fu de las herramientas que más usas ;)

Multiplexar conexiones y hacerlas persistentes aunque hayamos cerrado sesión

Muy útil si en nuestro día a día estamos entrando y saliendo en varios servidores. Aunque tengamos varias shells abiertas contra un servidor, el cliente SSH solo habrá creado una conexión y todas las consolas compartirán el mismo socket. De esta forma, sólo será necesario autenticarse la primera vez. Se creará un socket donde las siguientes conexiones a ese servidor irán multiplexadas a través de él. Por tanto, los próximos accesos serán mucho más rápidos y sin tener que introducir las credenciales de nuevo.

[Read more…]

Bajo este título tan gore, quería comentar un interesante artículo de MIT Technology Review: Heartbleed será irreparable en muchos dispositivos. Tom Simonite expone cómo una reciente vulnerabilidad descubierta en OpenSSL, Heartbleed, que tiene hasta logo, afecta también a muchos dispositivos en el mundo industrial o incluso doméstico. Cosas del Internet of Things (y el inglés me evita la redundancia). Les recomiendo leerlo, está traducido al español y contiene la opinión de varios expertos.

En la mía, el hecho de que haya una vulnerabilidad conocida y pública, que afecta a múltiples dispositivos que tienen interfaz web y controlan instalaciones industriales o se encuentran en los salones de nuestras casas, que los expertos (incluidos nosotros) opinen que no se va a realizar una actualización masiva de parches y que no haya un clamor popular, significa que todavía queda mucho camino por recorrer en el área de la concienciación de seguridad.

Yo no me imagino que se descubriera un posible defecto en, digamos, las fuentes de alimentación de los frigoríficos, que supusiera una cierta probabilidad de que se provocara un incendio y la ciudadanía no se pusiera a demandar responsables y soluciones.

Si no, pensemos en el caso de las vacas locas, una alerta alimentaria que supuso un riesgo relativo. En cuanto surgió el primer caso en España, en 2000, se promulgaron decretos, un Programa Integral Coordinado de Vigilancia y no hablemos de la repercusión mediática. Cierto es que hubieron casos mortales (un centenar en toda Europa, cinco en España), pero ya llevamos tiempo alertando de los peligros que la baja ciberseguridad de los sistemas de control industrial y el impacto no sólo económico que esto puede tener.

Seguiremos concienciando.

Un amigo mío tiene un amigo que es investigador experto en una de las principales instituciones de investigación francesas y le contaba, hace un par de días, que su grupo está preparando una propuesta para un proyecto de investigación junto con otros socios europeos, propuesta que debía presentarse esta semana.

Como tantos otros investigadores en Europa, este consorcio potencial utiliza una herramienta para compartir la información de su propuesta. En este caso, sharelatex.com, que, según dicen en su página, es usada por investigadores de numerosas y prestigiosas universidades de todo el mundo.

¿Cuál es la historia? Pues que sharelatex tuvo, según ellos informan, un problema de suministro eléctrico durante el fin de semana y sus servidores dejaron de estar disponibles. Posteriormente se restableció el funcionamiento de los equipos pero, aún así, la herramienta seguía sin funcionar, mensaje de disculpa incluido.

[Read more…]

Después de algún tiempo sin proponer ningún reto en el blog, volvemos a la carga con un nuevo caso donde tocará poner en práctica algunas técnicas que pueden ser utilizadas para obtener información oculta que pueda existir dentro de ficheros aparentemente “normales”.

En este caso, se ha capturado un e-mail (con el archivo attachment.rar adjunto) de una banda acusada de estar explotando vulnerabilidades en diferentes sistemas para instalar malware y así poder monitorizar todo lo que los usuarios hacen en sus máquinas.

Aunque a simple vista el archivo capturado (attachment.rar) únicamente parece contener tres fotografías, se cree que en él se dan algunas instrucciones o pistas sobre qué tipo de acciones están realizando para instalar el malware.

Como es habitual, se han facilitado dos archivos rar que requieren contraseña para ser visualizados. El primero de ellos (validator1.rar) se abrirá con la solución de la parte 1 del reto, y el segundo (validator2.rar) con la solución de la segunda parte. Remarcar que el reto no consiste en intentar crackear estos dos archivos comprimidos, sino que únicamente se facilitan para que se pueda comprobar si se ha llegado a la solución correcta o no. En esta ocasión, para poder resolver la segunda parte del reto, es necesario haber resuelto previamente la parte uno.

Como siempre, la solución será publicada en el blog en unos días. De todas maneras, si vemos que existen dudas sobre la resolución del reto, se publicará alguna pista durante el transcurso del mismo.

Espero que disfrutéis del reto ;)

Habitualmente, cuando se planifica el diseño de una red y su segmentación posterior mediante por ejemplo, un firewall, es frecuente partir del concepto histórico donde las redes internas son confiables y las externas no. Esto era lo normal hace algunos años donde la mayor parte de los ataques podían iniciarse fuera de la organización. Con este modelo de funcionamiento, es normal que se dé el caso de que un usuario, solamente por estar conectado a una interfaz de red concreta (por ejemplo inside) tenga heredados unos privilegios de acceso. Un claro ejemplo de esto podría ser la definición de security-level de los firewalls Cisco.

Los tiempos están cambiando, y podríamos hablar de dos razones (aunque seguro existen otras) que ayudarían a acelerar un cambio en los modelos de seguridad, por un lado, un factor tecnológico, ya que cada vez hay más dispositivos móviles conectados a la red corporativa y más aún, con el auge del BYOD, y por otro, la situación socio-económica general de cada sector/organización/estado, y en particular, el ambiente laboral de cada usuario dentro de su organización, que podrían provocar fugas de información, por esto, podríamos hablar de que la red interna deja de ser confiable.

Por esta razón, existe el llamado modelo zero-trust, modelo de seguridad alternativo introducido en el 2010 por John Kindervag, principal analista de Forrester. En él, se establece el concepto “Verify and Never trust”, donde se considera todo el tráfico por igual, independientemente de su ubicación y del dispositivo o usuario que lo genere y por lo tanto, a priori, sujeto a los mismos controles de seguridad.

El modelo Zero-trust se basa en varios principios:

• Garantizar el acceso seguro a todos los recursos independientemente de donde estén localizados.
• Seguir una estrategia de mínimo privilegio y seguir una política estricta de control de acceso.
• Inspeccionar y registrar todo el tráfico para validar la actividad en la red.

Forrester también presenta los conceptos de DAN (data adquisition network), una red que facilite la extracción de información de distintos sistemas (snmp, netflow, syslog, etc.) y los centralice en un único punto desde donde poder analizar la información en tiempo real de forma ágil, siempre teniendo en mente un diseño de red de dentro hacia fuera, y MCAP (micro-core and perimeter).

En este vídeo podemos ver a John Kindervag explicando la arquitectura de red en el modelo zero-trust.

Con este nuevo modelo, nuestra organización tendría que replantearse su estrategia de seguridad corporativa, definiendo por ejemplo, perfiles de conexión, para identificar quién, cómo, dónde y a qué información se accede, independientemente de que un usuario se conecte por cable, wifi, vpn, etc.

Actualmente, ya existen fabricantes como Paloalto, que implementan en sus dispositivos de seguridad este modelo. También Cisco tiene algo similar para el control de acceso llamado Ciscto TustSec. ¿Conocen algún otro fabricante? ¿Implementan medidas de seguridad en las conexiones internas de su organización o simplemente por estar en la red interna, ya se disponen de unos accesos independientemente de que usuario/departamento sea?

La verdad es que el post del día uno de abril quedó algo descafeinado… La versión inicial era más gore, sin referencias a si hoy no fuera el día que es, con noticias de periódicos de verdad (La Nueva España y La Voz de Asturias eran los elegidos) e incluso con alguna foto de una vaca con el estómago reventado, que eso siempre ayuda a comprender el problema. Pero por una cuestión o por otra se descafeinó y se veía a la legua que era un hoax (quizás también influyó en esto la serie de posts anteriores ;) Eso sí, se movió bastante por redes sociales, y parece que resultó interesante o al menos le pareció curioso a más de uno; hasta los de @48bits hicieron alguna referencia a las vacas en Twitter ;)

Si no lo hubiéramos descafeinado tanto, habría sido más creíble; el objetivo era hacer un bulo para el día uno de abril tocando, en primer lugar, la fibra sensible (una vaca con el estómago reventado como que llama la atención) y después metiendo diferentes técnicas de persuasión de las que habíamos visto. Algunas de ellas:

• Acercamiento al mundo real, citando fabricantes “de verdad”, tanto de PLC como integradores, poniendo unas coordenadas reales, en una zona conocida y que además coincide con la que hemos especificado al principio, zona norte de España. Y capturas “tocadas” de sistemas SCADA.
• Autoridad: nuestro amigo imaginario lleva muchos años en esto de la tecnología y además dirige el ámbito de ciberseguridad en explotaciones agropecuarias, vamos, que a priori no es un recién llegado y sabe de lo que habla…
• Experiencia, objetivo de los primeros párrafos: sabemos de animales. Sabemos matar animales, sabemos que una vaca muere si hace lo que decimos y con esto hacemos creer que en zonas de España es habitual la explotación aislada -realmente, creo que no es así, aunque sí que es normal tener las vacas en la montaña sin vigilancia humana directa, sueltas-. Por cierto, lo de las vacas que revientan, según tengo entendido es si comen determinada hierba que luego fermenta en el estómago… creo, tampoco es que me haya preocupado mucho…
• Respaldo de terceros, con la publicación de las noticias en dos medios independientes de SAW (aunque, como hemos dicho, inventados).
• Sugestión, acabando con el mensaje “si yo fuese un ganadero, me preocuparía” (vale, metemos lo de “y no fuera hoy el día que es”, para dar una pista, pero podríamos haberlo eliminado).

Evidentemente no se trata de hacer un hoax aplicando todas las técnicas de persuasión a la vez, como ya dijimos, sino de seleccionar varias e incluirlas en el bulo para darle realismo y conseguir que la gente lo reenvíe, hable de él o similares. No sé si lo hemos conseguido, aunque a primera vista sí que parece una historia coherente, ¿no? Ojo, coherente para un profano en la materia, no para un experto en seguridad, en sistemas de control, en explotaciones agropecuarias o en temas similares…

Si hubiéramos sido más crudos, seguro que se lo habría creído más gente. No obstante, a pesar de ser obviamente un hoax, sí que hubo alguno que picó; me han llegado comentarios del tipo “oye, y eso lo habéis denunciado” o un whatsapp de un amigo diciéndome literalmente lo de “Toni, tío, dime que lo de las vacas no es verdad”. En fin, que hay gente pa to :) Eso sí, ¿podría ser real? Por supuesto, no lo vamos a probar, aunque matar cien vacas creo que no es lo peor que nos puede pasar con los sistemas de control conectados a Internet…

P.D. Perdón por no responder a los comentarios del post de las vacas, pero mejor no dar señales de vida en el momento para decir si es un hoax o no…

Hoy os voy a presentar el resultado del trabajo que hicimos en el post del otro día. Una vez cargados todos los datos, accedemos con nuestro navegador al puerto 9292 del equipo donde hemos desplegado Logstash (en nuestro caso nuestro propio equipo), y empezamos a jugar con todas las visualizaciones que proporciona . El resultado inicial es el siguiente:

Aquí podemos ver como hemos introducido varios parámetros de búsqueda, que coinciden con las categorías que proporciona Emerging Threats, el conjunto de reglas que usamos en la sonda que hemos utilizado para las pruebas.

A continuación aparece por defecto un histograma que nos permite ver, de un vistazo, qué tipos de ataques han sido los que más hemos sufrido. Como se puede apreciar, hay varios picos de alertas “ET SCAN” que corresponden con escaneos hacia nuestra infraestructura, así como varios picos de alertas del tipo “ET P2P”, que nos hacen pensar que alguno de nuestros usuarios ha utilizado herramientas P2P.

A partir de este punto es donde empezamos la personalización, generando nosotros mismos las visualizaciones que queramos.

La primera visualización interesante es la de terms, que para un campo concreto que le indiquemos, obtiene los valores más (o menos) comunes. Se puede configurar para que nos muestre los resultados en un gráfico de barras, de tarta, o en una lista simple (como veremos más adelante).

Además, nos permite mostrar el número de registros con otros valores fuera de los que muestra (‘Other values’), e incluso a los que les falta el campo que estamos visualizando (‘Missing’).

Utilizando esta visualización para las IP y los puertos origen y destino obtenemos una vista como la siguiente:

Seguidamente, vemos otra de las visualizaciones que hemos generado:

Aquí aparece, a la izquierda, una visualización de tipo terms sobre las firmas más comunes que han generado alertas. Este caso es ligeramente diferente, ya que para que funcione bien la visualización debemos seleccionar el campo sig_name.raw. Esto se debe a que elasticsearch por defecto procesa todos los campos que le llegan, separándolos en palabras, de forma que la visualización de tipo terms actuaría para cada palabra que forma la firma, dejando por ejemplo en primer lugar el término “ET” con un valor igual al número de alertas que se han generado. Para evitar esta separación y poder obtener el valor deseado, logstash añade por defecto a cada campo otro homónimo con el sufijo “.raw”, que marca para que no sea procesado por elasticsearch, dejando el resultado como se aprecia en la imagen anterior.

Otra visualización interesante es la de tendencias (trends), que compara, para cada una de las búsquedas que hemos realizado, su evolución temporal, en base a un intervalo prefijado. Si por ejemplo, fijamos el intervalo en 1 día, comparará el número de ocurrencias de cada búsqueda en las últimas 24h, y el valor para las 24h anteriores, mostrando la diferencia en porcentaje.

Para finalizar, tenemos un gráfico de tarta que muestra la distribución de los protocolos IP utilizados por las alertas generadas.

En la parte inferior de la página vemos otra visualización por defecto, se trata de un listado detallado con un número determinado de alertas, de entre todas las que cumplen los requisitos indicados en las búsquedas. Como ya indiqué en el anterior post, se pueden seleccionar campos para que se ordene la información por ellos, y abrir cada alerta para ver todos sus campos.

Para finalizar el post, os voy a mostrar otra visualización muy interesante, que se puede obtener modificando el fichero de configuración que generamos para cargar los datos, añadiendo las siguientes líneas en el apartado filter:

  geoip {
	database => "/usr/share/GeoIP/GeoLiteCity.dat"
	source => ip_src
	target => geoip_src
  }
  geoip {
	database => "/usr/share/GeoIP/GeoLiteCity.dat"
	source => ip_dst
	target => geoip_dst
  }

Con ello obtendremos dos nuevos campos, con los que podremos generar mapas localizando hasta la ciudad a la que pertenecen las IP origen y destino de las alertas, siempre que sea posible.

Para obtener estos mapas el panel se creará con la visualización bettermap, y el único campo que necesitaremos introducir es el Coordinate, donde debemos indicar, por ejemplo, el campo geoip_src.location si queremos generar un mapa con los orígenes de los ataques.

El resultado es el siguiente:

Por supuesto, el mapa es navegable y al pulsar en cualquiera de los puntos el mapa se acerca, mostrando un desglose específico de las alertas por área geográfica.

En las últimas semanas se ha cambiado el proveedor de mapas para esta visualización, por lo que es posible que no se cargue ningún mapa al generar esta visualización. Para solucionar este problema, tan sólo es necesario realizar el cambio que se muestra en este commit de GitHub en el fichero vendor/kibana/app/panels/bettermap/module.js dentro de la carpeta donde se encuentra logstash.

Espero que os haya gustado esta entrada, y os animéis a jugar con este gran conjunto de herramientas.