Security Art Work

Hace un par de semanas llegó a mis oídos la existencia de una herramienta open source que nos puede ser útil a la hora de realizar las primeras fases de un pentesting: reconocimiento y mapping de servicios. Realizar estas primeros pasos de forma concienzuda puede hacer que las siguientes fases de nuestro pentesting puedan ser más dirigidas y eficaces a la hora de encontrar las posibles vulnerabilidades de nuestro objetivo.

Spiderfoot, es una herramienta open source creada por Steve Micallef (@binarypool) que fue publicada por primera vez en el año 2005 y llegó a formar parte del temario de la certificación de hacking ético (CEH) durante 2009.

La primera versión estaba escrita en C#. A partir de ahí hubo un paréntesis de 7 años en su desarrollo hasta que en el 2012 el autor decidió retomar el proyecto y hacerla más portable, funcional y extensible, reescribiéndola enteramente en Python, dotándola de un interfaz web y almacenando los datos de los resultados en una base de datos SQlite3.

A día de hoy la versión publicada es la 2.1.5 y sigue en continua evolución y está disponible para Windows y para Linux.

Spiderfoot cuenta con varios módulos dedicados a recoger información y tratarla extrayendo datos relevantes de distintos ámbitos (dns, contenido web, whois, Virustotal, Shodan, etc.) que nos serán de utilidad a la hora de realizar tareas de OSINT (Open Source Intelligence).

Los módulos reciben ciertos elementos (URL, códigos http, direcciones de correo electrónico) en forma de eventos, y entonces actúan sobre ellos para que a su vez generen nuevos eventos que serán consumidos por otros módulos de la aplicación.

Entre los módulos disponibles, está sfp_dns que realiza búsquedas a partir de las ips/URLs introducidas, sobre servidores DNS obteniendo direcciones ip, registros MX/NS, etc. También cuenta con el módulo sfp_spider que inspeccionará todas las páginas de un sitio web extrayendo su contenido para usarlo en posteriores búsquedas.

Instalación

Si la instalamos sobre un sistema operativo Linux, la aplicación está escrita en Python 2.6-2.7, por lo que necesitaremos esta versión para ejecutar la aplicación, así como instalar las siguientes dependencias, que pueden ser instaladas usando el gestor de paquetes de Python PIP.

$sudo pip install lxml
$sudo pip install netaddr
$sudo pip install M2Crypto
$sudo pip install cherrypy
$sudo pip install mako

Una vez instaladas las dependencias descargaremos el código de la aplicación:

git clone https://github.com/smicallef/spiderfoot.git

Tras esto ejecutaremos la aplicación usando el interprete de Python. Si no especificamos el puerto en que estará escuchando el servidor como parámetro en el momento de la ejecución, por defecto lo hará en el puerto 5001/tcp:

cd spiderfoot/
$sudo python ./sf.py 127.0.0.1:6666

En caso de instalarlo sobre un sistema Windows, todas las dependencias vienen incluidas en el ejecutable de instalación. Una vez ejecutado el servidor podremos acceder al interfaz apuntando nuestro navegador a la ip y puerto seleccionado.

En la primera página podremos configurar los escaneos; spiderfoot proporciona un alto nivel de granularidad a la hora de seleccionar los campos sobre los que se recogerá información. Podremos seleccionarlos por elemento (Imagen 1) o por módulo (Imagen 2).

En el apartado de settings podremos configurar entre otro nuestra clave API de virus Total, Shodan, parámetros de las consultas DNS, puertos a escanear, y una multitud de opciones que iremos viendo más adelante.

Y con esta breve introducción finaliza la primera parte. En siguientes artículos entraremos en profundidad en otros aspectos y utilidades de esta herramienta.

Si estás interesado, aquí puedes encontrar un listado exhaustivo de cursos de Python: CourseDuck Python courses

Ya se ha hablado varias veces en este blog de las bondades que nos ofrece Python, se han recomendado lecturas y algunas librerías útiles en el mundo de la seguridad, pero como me considero una persona organizada y me gusta tener todo centralizado, inicio mis andadurías por este blog con una serie de artículos dedicados al uso de Python en el pentest.

De python hay que destacar principalmente su facilidad de aprendizaje y uso incluso para alguien sin nociones o con unas muy bajas de programación. El código es multiplataforma y solo requiere del intérprete instalado en el sistema. En sistemas Linux suele venir preinstalado y contiene un ecosistema muy amplio y variado de paquetes que nos facilitarán cualquier tarea, bien nativas en Python o bindings que permiten el uso de la librería en C.

La gestión de paquetes se puede realizar fácilmente por medio del gestor de paquetes nativo del sistema o por medio de gestores de paquetes específicos para Python, como pueden ser pip o easy_install. También como ultimo recurso podremos descargarnos la librería del repositorio oficial e instalarla manualmente, por medio de install.py o instalar el .egg con uno de los gestores de paquetes específicos de Python. Para ver la cantidad de paquetes “oficiales” de la que disponemos podemos echarle un vistazo a PyPI.

[Read more…]

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…