29 enero 2015

Cybercamp 2014: charla y slides de Lorenzo Martínez

Uno de los eventos de seguridad del año pasado fue, sin duda, Cybercamp, organizado por el Instituto Nacional de Ciberseguridad (INCIBE)

Se celebró en el Pabellón multiusos de la Casa de Campo y contó con ponentes internacionales sobradamente reconocidos como Richard Stallman, Johanna Rutkowska o Stefano di Paola, entre otros.

Por mi parte, abrí la última jornada con un taller de tres horitas en las que conté diferentes aspectos a tener en cuenta a la hora de hacer un peritaje informático forense, y conté, de forma anónima, varios casos que se me habían presentado en mi vida profesional como perito. 

No me dí ni cuenta y las tres horas se me pasaron volando. Si no es porque los chicos de Trancas y Barrancas pasaron por allí, me pego las tres horas hablando sin descanso (gracias por la foto Chus!)




Según me manifestaron unos cuantos madrugadores que asistieron al mismo, sería genial poder contar con las slides de la charla, por lo que las he colgado en una cuenta Slideshare que hemos abierto para Securízame. 



Por otra parte, luego dí una charla, planificada inicialmente para media hora, pero que tuve que 'zipear' en 20 minutos por motivos de retrasos acumulados…  Son los riesgos de dar la última charla del día. Con el título "Emprender (en TIC) en tiempos revueltos", y a ritmo del hombre Micromachines, conté fundamentalmente las razones que me llevaron a emprender con Securízame y dar ciertas guías a los asistentes, sobre cómo he hecho las cosas hasta ahora. No digo que sea “LA" forma de hacerlo, pero es la que he seguido y comparto mi experiencia.

El video de la misma está en el canal youtube de Securízame, y la podéis ver directamente bajo estas líneas. 



Las slides de dicha charla, pese a que no sé qué queréis ver de ellas, por petición popular, también las he colgado en Slideshare.

Leer más...

27 enero 2015

Próximos eventos: MorterueloCON en Cuenca y HackRON en Tenerife












"Creced y multiplicaos" (Gen. 1:28)

2014 fue sin duda el año con mayor número de eventos de seguridad, nacionales y locales, al que he asistido desde que me dedico profesionalmente a seguridad. Finales de 2014, y en concreto entre Septiembre, Octubre y Noviembre, tuve que hacer malabarismos con la agenda recorriendo España, Portugal (y parte de Latinoamérica) en diferentes eventos privados y Congresos de Seguridad

Nicolás Castellano, uno de los organizadores del Congreso más antiguo de España, NoConName, incluso escribió un post para Security By Default que tuvo bastante cola en el sector en relación a la cantidad de oferta de eventos de seguridad, sus consecuencias, beneficios y contras.

Si bien el año pasado se congregaron un montón de ellos a finales de año, 2015, ha comenzado con una programación muy adelantada. La semana pasada se celebró la primera edición del primer evento de esta índole en Santander (Cantabria), llamado Sh3llCON, que según podido saber, ha tenido una gran acogida.

En la primera quincena de Febrero, como preludio del todopoderoso RootedCON, el evento con mayor aforo en España, podemos ir calentando ya con dos convocatorias locales que celebran su segunda edición: MorterueloCON en Cuenca y HackRON en Santa Cruz de Tenerife.

En el caso de MorterueloCON, se celebrará el jueves 5 y viernes 6 de Febrero en Cuenca. El coste de la entrada es de 0 euros y constará de charlas por la mañana y talleres por la tarde. La agenda completa podéis verla en la web www.morteruelo.net, y habrá charlas de gente como David Reguera, Óscar Tebar, Josep Albors, Eduardo Sánchez y un servidor, entre otros. La oferta formativa de talleres es aún más suculenta, los amigos Daniel Medianero, David Hernández o Miguel Arroyo, se encargarán de ello. 




Hackron, se celebra una semana después, el 13 y 14 de Febrero, en Santa Cruz de Tenerife, coincidiendo, al igual que el año pasado con el inicio de las fiestas de Carnaval, en una de las ciudades españolas donde mayor tradición de esta fiesta hay. En este caso, el evento tiene un coste mínimo de entrada, algo natural debido a la penalización que conlleva mover a tantos ponentes desde la península a las islas. 

El plantel de ponentes es simplemente genial, contando con charlas de Luis Delgado, Josep Albors, Alejandro Ramos, Pedro Sánchez, Igor Lukic, Pablo González, Pedro Candel, Juan Garrido, Deepak Daswani, las abogadas Noemí Brito y Ofelia Tejerina. 

Podéis ver la agenda completa del evento en la web http://www.hackron.com/. Este año, me habría encantado quedarme al fin de fiesta allí, ya que el año pasado me lo pasé de escándalo, pero por motivos de más y más viajes a la otra punta del Mundo, me tocará dar mi charla en la primera de las jornadas y volverme en el mismo día.


Sobre la justificación de la existencia de los eventos locales, quiero aportar mi humilde opinión, desde tres puntos de vista diferentes.

Desde la perspectiva del asistente, ambos eventos suelen ser de público local, conquenses y alrededores en el caso de Morteruelo y canarios en el caso de Hackron. En general, público de universidades y empresas locales que no tienen por qué haber asistido a eventos de talla mayor como RootedCON, NCN o Navaja Negra, por lo que aunque varias de las charlas se repitan en eventos mayores, está perfectamente justificada su razón de ser. Además, en uno de ellos se ofrecen talleres de diferentes temáticas: Hacking ético, Hardening de servidores GLAMP, Seguridad web o Análisis Forense, que al ser gratuitos, el año pasado tenían el aforo hasta los topes.

Desde la perspectiva del ponente, con la experiencia de haber participado en la primera edición de ambos eventos el año pasado, sólo tengo buenas palabras para ambos congresos. El trato es inigualable, el público es muy agradecido y cercano, y tener la excusa para ver a viejos compañeros, con localizaciones lejanas a la capital, hacen que los madrugones y las afonías merezcan la pena sin dudarlo.

Desde el punto de vista de los organizadores, conociendo a Rafael Otal, como uno de los responsables de MorterueloCON, así como a Igor Lukic y Cecilio Sanz en el caso de Hackron, creo que los que les conocemos, tenemos meridianamente claro que el objetivo no es monetizar el evento, puesto que Morteruelo es gratuito y Hackron cobra un precio simbólico (y en costes de logística de sala y de traslado de ponentes se va mucho dinero), sino el traer conocimiento a cada una de sus comunidades autónomas, llevar a cabo un evento social, dedicado a seguridad, generar comunidad y conciencia de seguridad, y fomentar el desarrollo de la profesión y la motivación en los asistentes. En términos organizativos, tengo clarísimo que la cantidad de horas invertidas, noches sin dormir, preocupaciones y estrés general, no es rentable económicamente organizar ninguno de estos eventos en España, si no es claro está por el orgullo y satisfacción de haber llevado a cabo una nueva edición de algo que les hace grandes internamente y que, los que vamos gratuitamente, tanto para contar cosas interesantes a los asistentes, como para aprender de lo que los demás compañeros tienen que decir, volvamos a casa con gran satisfacción.

Así que, arranca 2015 y empezamos con Cuenca y Santa Cruz de Tenerife... Nos vemos!


Leer más...

26 enero 2015

Hacking en redes SS7

Introducción

Hace 6 años, Tobias Engel publicaba en la 25C3 un método para localizar a cualquier víctima de la red móvil (GSM) utilizando para ello mensajes de protocolos de la red SS7. Durante el seguimiento de esta edición del Chaos Communication Congress (31C3), hemos podido disfrutar de varias conferencias acerca de las vulnerabilidades de la red SS7; Karsten Nohl, Tobias Engel y Laurent Ghigonis con Alexandre De Oliveira (del equipo de Philippe Langlois) nos han presentado distintos puntos de vista sobre la seguridad de esta red mostrando sus vulnerabilidades; algunas teóricas y otras explotadas.


Por otro lado, si bien GSM, UMTS y LTE son nombres de redes de telecomunicaciones bien conocidos por todo el mundo, creo que SS7 no goza de la misma fama y posiblemente esto ha impedido a algunos de los interesados en la seguridad seguir con todo detalle estas presentaciones.

¿Qué es exactamente SS7?


No es la intención de este artículo describir técnicamente la compleja red SS7 ni cada uno de los protocolos que la componen, sino el comentar los conocimientos necesarios para entender los anteriores ataques.


Cuando hablamos de SS7, estamos recordando y paseando por la historia de las telecomunicaciones; Su historia es muy larga, nos estamos remontando a los años 1970, cuando AT&T desarrollaba su precursor, sistema de señalización 6 y 5 años más tarde desarrollaba el sistema de señalización 7, que permitiría enlaces de señalización de 64.000 bps. La organización ITU-T (International Telecommunication Union - Telecommunication Standardization) lo adoptó como estándar en 1980, por lo que se encargaría de definir los estándares internacionales (Q.7XX para SS7) para garantizar la interconexión de estas redes a escala mundial.

Podemos pensar en SS7 como un conjunto de protocolos que, por nombrar alguna de sus funciones más importantes, permiten establecer dinámicamente los circuitos para realizar una llamada ya que establecen la señalización necesaria para que las redes involucradas puedan consultar entre ellas información sobre los abonados, como saber dónde se encuentra cada parte de la llamada, dar servicios de valor añadido a los usuarios, entre otras muchas funciones.

A día de hoy, estos protocolos se utilizan en todas las redes de telecomunicación conocidas: red telefónica pública conmutada (PSTN), la red digital de servicios integrados (RDSI), redes inteligentes (IN), y las redes móviles (PLMN).

Protocolos de SS7 y Sigtran

Antes de echar un vistazo rápido al conjunto de protocolos SS7, es importante tener en cuenta "Sigtran" (derivado de signaling transport);

En un principio la señalización se transportaba utilizando un conjunto de protocolos llamados MTP (Message Transfer Part) divididos en 3 capas:

Nivel 1 - Signalling Data Link (representa la capa física, normalmente -en Europa- utiliza un timeslot en un interfaz E1, capa 1 también del modelo OSI)
Nivel 2 - Signalling Link (proporciona un medio fiable de transferencia de señalización entre dos puntos de señalización -PointCodes- conectados directamente, corresponde con la capa 2 del modelo OSI )
Nivel 3 - Signalling Network (capa OSI 3 - el propósito principal es enrutar mensajes entre nodos de la red SS7 de una manera fiable)

Pero con la llegada de las Redes "Next Generation Networks" o NGN, se convirtió en un requisito indispensable la convergencia de todas la redes, así que SS7 actualizó los protocolos de transporte que acabamos de ver y pasó a adoptar el protocolo IP. Esta actualización, llamada Sigtran, sólo afectó a las capas de la pila de protocolos más bajas, las capas superiores (capa 4) han permanecido inalteradas:

ISUP (ISDN User Part): es responsable de establecer dinámicamente los circuitos utilizados para las llamadas. Como podéis ver por su nombre, en un principio estuvo estrechamente ligado a la red RDSI (ISDN: Integrated Services Digital Network)

MAP (Mobile Application Part): capa de aplicación que permite a los nodos de las redes móviles GSM y UMTS comunicarse para proporcionar servicios a los usuarios de estas redes.

¿Qué necesitamos saber de la red SS7? 


Con el fin de preparar lo que podría ser una auditoría de seguridad o un ataque a nuestra red SS7, vamos a necesitar tener muy claro qué necesitaremos de cada protocolo o capa para poder llevar a cabo nuestras malignas intenciones:

  • MSISDN: Mobile Station Integrated Services Digital Network, compuesto por el código de país (España es 34) y el número de teléfono del abonado (National Destination Code mas el Subscriber Number).
  • IMSI: International Mobile Subscriber Identity, el identificador único de cada tarjeta SIM en la red móvil (formado por el Mobile Country Code, el Mobile Network Code y el Mobile Subscription Identification Number).
  • IMEI: International Mobile Equipment Identity, el identificador de cada terminal móvil (se puede consultar en todos los móviles marcando *#06# en el marcador -dialer-).
  • GoblalTitlle: Es la dirección SCCP de cada nodo en la red SS7, utilizando el mismo formato que los número de teléfono de los abonados pero en este caso representan nodos de la red, no personas.
  • SubSystemNumber: indica a cada nodo de la red con qué otro tipo de nodo va a establecer enlace/comunicación. Cada tipo de nodo tiene su propio número;  6  HLR (MAP), 7  VLR (MAP), 8  MSC (MAP) ....
  • PointCode: es el identificador de la capa 3 de MTP que se asigna a cada nodo de la red.
Todos ellos se encuentran recogidos en el siguiente enlace de la 3GPP "TS 23.003: Numbering, addressing and identification", con una mejor descripción y el formato de cada uno.

Hacking en SS7: ¿Cómo? ¿Dónde?


En el pasado, la idea de una operadora de telecomunicaciones era análoga a la idea de un gobierno o un país. De esta manera, nadie vio ninguna objeción a la hora de interconectar todas las redes SS7 con el nivel de seguridad que proporciona SS7, era algo más que necesario puesto que permitiría realizar llamadas a cualquier parte del mundo.


¡Muy chulo! pero ... ¿Quién pensó en la seguridad?. La red SS7 se ha diseñado con el supuesto de confianza; todos los jugadores/operadores son legítimos y vienen en son de paz. Las cosas han evolucionado mucho, no sólo hemos pasado de los interfaces E1 a enlaces IP, sino que se ha liberalizado el mercado de las telecomunicaciones; han aparecido los operadores virtuales (OMV), así como licencias de test o desarrollo temporales y un gran mercado sobre el transporte de tráfico internacional. Esta situación es la que heredamos hoy, y en la que no todo el mundo tiene buenas intenciones, pero cuando nos demos cuenta, ya estarán conectados a nuestra red SS7.

Esta facilidad para conectarse a la red SS7 es relativa, ya que existe una regulación en todos los países que marca de alguna manera quién, cómo y qué pasos debe dar para establecerse como una operadora y poder dar servicios a los usuarios. El problema más gordo viene cuando alguno de estos países, potencialmente pueda estar interesado en obtener información de sus residentes en el extranjero o incluso espiar a personas de otros países (para no ser muy apocalíptico no voy a citar muchos ejemplos de actualidad reciente, pero esto pasa en el mundo real, ¿verdad Ángela M.?).

Ataques sobre la red SS7


Los distintos ataques que voy a comentar los he agrupado en 4 categorías:

  • Información filtrada o mal securizada (fugas de información)
  • Fuzzing de protocolos (D.o.S, Resource Exhaustion, etc.)
  • Reconocimiento y enumeración de la red (mapa y escaneo de nodos, puertos, etc.)
  • Inyección de paquetes (SendRoutingInfo, ProvideSubscriberLocation, etc)
Para revisar cada uno de ellos en detalle y poder mostrar ejemplos reales, he utilizado dos máquinas virtuales corriendo Ubuntu y una pila de protocolos SS7, simulando dos nodos de una red real. La configuración de las máquinas que he utilizado es; la máquina con IP 192.168.56.101 tiene el  PointCode 2 y la otra máquina con IP 192.168.56.102 el PointCode 1. Al arrancar la aplicación SS7 en ambas máquinas, podemos ver en una captura de wireshark cómo se establece la asociación M3UA:


Las cuatro primeras líneas corresponden al SCTP handshake (4-way handshake) que protege al protocolo SCTP de posibles ataques de Denegación de Servicio (una mejora respecto al protocolo TCP en el que todos conocemos los ataques D.o.S tipo SYN flood y similares) al establecer el servidor/nodo una Cookie en el mensaje "INIT ACK" y este no hará el más mínimo caso al cliente hasta que reciba esta Cookie de vuelta en el mensaje "Cookie Echo", entonces se cierra la asociación con el mensaje "Cookie Ack", habiendo protegido los recursos del servidor durante la transacción.

En un escenario real, los objetivos serán los nodos de la red móvil (HLR, MSC, STP, etc.), sobre los que un posible atacante podría enviar mensajes válidos con el fin de obtener información sensible, como nuestra localización, nuestra identidad en la red (IMSI) o modificar nuestros datos almacenados en la base de datos. 
  • Información filtrada o mal securizada.
Todos alguna vez hemos oído o recibido alguna sesión de trabajo sobre la importancia de custodiar la información sensible de nuestra compañía, esto se vuelve crítico cuando hablamos del documento IR 21. Este documento recoge las "especificaciones técnicas" de cada operadora y es entregado a cada operadora con la que establece un acuerdo de interconexión. Recoge información sensible sobre la arquitectura de red, tipo de red, versiones de protocolos, direcciones IP de los nodos, global title de los nodos, etc.

Simplemente probad a buscar en vuestro buscador favorito "IR21 filetype:pdf" o búsquedas similares, encontrareis más de un documento !!.


Como podéis observar en la imagen (fragmento de un IR21), no sólo podemos ver el fabricante de los nodos y qué nodos son (MSCs híbridas 2G y 3G de Ericsson) y su Global Title, también su localización.
  • Fuzzing de protocolos
Si tuviese que elegir entre casarme con la "Ingeniería Inversa" o con el "Fuzzing de Protocolos" ... simplemente no podría elegir. El Fuzzing está demostrando últimamente la gran cantidad de vulnerabilidades y defectos de programación que se pueden encontrar de manera automática y el potencial de las herramientas (PROTOS, codenomicon, scapy, etc.) que emplean este método para estudiar la seguridad o robustez del software. En el caso de SS7, podemos empezar a jugar con dos herramientas; scapy y zzuf. No es la intención de este artículo explicar qué es Fuzzing o los distintos tipos de Fuzzers que existen (interesados ver este tutorial de InfoSec), pero claramente al lanzar estas herramientas contra nuestras pilas de SS7, podemos ver cómo la aplicación se vuelve pesada así como los mensajes erróneos enviados al servidor. Podremos centrarnos en el protocolo que nos interese investigar (SCTP, M3UA, SCCP, etc.) y una vez aislado el mensaje, reenviarlo a nuestra otra máquina para comprobar nuestro éxito:


Utilizando estas dos herramientas, es recomendable adaptar o desarrollar una monitorización específica para la aplicación que se encarga de arrancar la pila de protocolos SS7, ya que es muy posible que en cualquier momento le ocurra algo a la aplicación inesperado y tendremos que estudiar qué mensaje o qué situación ha sido la causante.
  • Reconocimiento de la red
Desde el más clásico nmap hasta módulos Python que implementan SCTP pasando por sctpscan, nos permitirán lanzar escaneos de Ip's utilizando SCTP como transporte, para descubrir todo lo necesarios sobre la topología de la red.

Ejemplo de Nmap:

root@~# nmap -sY 192.168.56.101

Starting Nmap 5.21 ( http://nmap.org ) at 2015-01-24 15:53 CET
Nmap scan report for 192.168.56.101
Host is up (0.00030s latency).
Not shown: 41 closed ports
PORT      STATE SERVICE
2905/sctp open  m3ua
MAC Address: 00:00:00:00:00:00 ()

Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds
root@~#

Ejemplo de sctpscan:

root@~# ./sctpscan.py 192.168.56.101
Scanning 192.168.56.101
Cant bind mirror port 2905, use 10000 instead
Cant bind default port 10000, use kernel attributed source port
SCTP Port Open: 192.168.56.101 2905
Results: 1 opened, 112 closed, 0 filtered
root@~#

En la captura de Wireshark vemos el 4-way handshake del puerto abierto (2905), entre todos los demás intentos:


  • Inyección de paquetes
Para cuando el posible atacante hubiese identificado los nodos de la red, el siguiente paso será poder crear su propia asociación con el nodo (en caso de no existir) para poder enviar los mensajes MAP, ya que es en este nivel donde se manejan datos de usuarios, tal y como vimos en el esquema (IMSI, IMEI y MSISDN).

Podemos crear nuestro propio socket SCTP mediante un script (Python) o utilizar los clientes disponibles en la pila de protocolos SS7, lo más importante será confirmar que el nodo que está al otro lado utiliza la misma versión del protocolo que nosotros y construir nuestros paquetes binarios de tal modo que obtengamos la información que nos interesa de nuestra victima. Una vez creada la asociación SCTP, tendremos que ir subiendo de capa, reconociendo los nodos, hasta llegar a localizar el nodo objetivo que buscamos.

Utilizando la pila de protocolos SS7 de Dialogic, podemos ver la lista de mensajes ya formados, listos para utilizar con la MAP Test Utility y Responder:

Syntax: -d<mode> [-m<mod> -u<map> -o<options>-b<base_did> -x<active> -n<num_dlg_ids> -c<sc> -p<phase> -s<message>-i<imsi> -e<msisdn> -f<ggsn_num>] -g<orig> -a<dest>
  -a  : destination address
  -b  : base MAP dialogue id
  -c  : service centre address  (only valid for mode=0)
  -d  : mode of operation: 0 - Forward short message
                           1 - Send IMSI
                           2 - Send routing info for GPRS
                           3 - Send IMSI & Send routing info for GPRS
                           4 - Forward MT short message
                           5 - Send routing info for SM
                           6 - Send ProcessUnstructuredSS-Request
  -e  : MSISDN (only valid for mode=1 or 3)
  -f  : GGSN number (only valid for mode=2 or 3)
  -g  : originating address
  -i  : international mobile subscriber ID (mandatory for modes 0 and 2)
  -m  : mtu's module ID (default=0x2d)
  -n  : number of outgoing MAP dialogue ids
  -o  : Output display options (default=0x000f)
  -p  : MAP phase (i.e. phase 1 or phase 2 - default=2; only valid for mode=0)
  -s  : short message (only valid for mode=0)
  -U  : USSD String (e.g. *123*456789#)
  -u  : MAP module ID (default=0x15)
  -x  : number of active dialogues to maintain (default=0, max=1024)

Es decir, sin necesidad de forjar nuestro propio paquete binario desde cero, podemos probar y jugar con varios mensajes clave SS7 que habéis leído estas navidades: Send Routing Info, SendIMSI y Forward MT Short Message, simulando el ataque descrito anteriormente en nuestro ordenador.

A continuación podemos ver el resultado de enviar un "SendRoutingInfo" para el MSISDN 34666111222, y la respuesta con el IMSI del supuesto abonado:



Siguiendo estos pasos se pueden llevar a cabo los ataques que parece han conmocionado a todo el mundo (Washington Post), y desde luego, no es para menos.

Conclusión


Es imposible resumir la historia de las telecomunicaciones así como detallar todos los aspectos técnicos de los protocolos que forman las redes SS7, pero espero que este rápido repaso de SS7 y la enumeración de los principales vectores de ataque a esta red haya abierto el apetito para ahora sí, abrir los enlaces a las slides de las conferencias y entender un poco mejor cómo nos pueden haber estado robando nuestra privacidad desde hace algún tiempo.


Contribución por Pedro Cabrera
Leer más...

25 enero 2015

Enlaces de la SECmana - 260


Leer más...

23 enero 2015

Desanonimizando nodos Tor gracias a SSH

Durante estos últimos tiempos cada vez más operaciones 'Anti Tor' son realizadas por el FBI y otros organismos similares.

Siempre, cuando cae un nodo TOR importante, la paranoia cunde entre los defensores del anonimato y preguntas tales como  ¿Pero TOR no sirve precisamente para que eso NO ocurra? ¿Cómo han podido hacerlo? salen a la palestra.

Vía Marc Rivero, llego a un enlace a Reddit donde exponen una teoría que, por simple y efectiva, es realmente brillante.

El asunto es el siguiente: 
  • Alguien tiene un nodo Tor que tiene una 'pata' en TOR, cuya dirección es intraceable, y otra pata en el 'mundo real' con una IP normal y corriente. 
  • En ambos mundos ejecuta un servidor SSH
  • Un servidor SSH (que emplea algoritmos de clave pública/privada) siempre mantiene las mismas claves, tanto en 'Mundo Tor' como en 'Mundo real'
  • por lo que, si obtienes el 'fingerprint' de su clave en 'Mundo Tor', puedes ir a Shodan y preguntar si conoce ese servidor SSH en el mundo real.
Simplemente brillante, una forma realmente efectiva para correlar Nodo Tor VS Nodo real.

No hay que olvidar que Tor no solo sirve para conectarse a un servicio web, es una práctica bastante común hacer que el puerto del servidor SSH también esté disponible desde Tor para poder acceder de forma anónima.

Y Shodan permite hacer búsquedas del estilo 




Leer más...

21 enero 2015

Curso Análisis Forense Digital en Profundidad

Desde que llevo dedicándome a la seguridad he visto bastantes modas y perfiles profesionales con un recorrido bastante efímero, por contra, hay dos tipos de perfiles que son sinónimo de oportundiades laborales: Pentesting y Forense.

Y tal vez el perfil con mas empuje de los dos sea el de analista forense. Vivimos días donde los incidentes de seguridad suceden a diario y no solo en grandes empresas u organismos. Existe verdadera desesperación entre los 'headhunters' para encontrar perfiles con los que poblar los equipos IR (Incident Response)

El año pasado tuve el inmenso placer de participar como profesor en el curso que ofertó Securizame sobre Análisis forense en profundidad, y este año, debido al éxito de la anterior edición, se va a repetir y ampliar.

El curso abarca prácticamente todas las disciplinas relacionadas con análisis forense. Desde los aspectos más clásicos (equipos Windows, redes, Android, IOS, sistemas Linux) hasta novedosas materias como análisis forense de documentos o VOIP

El índice del curso es el siguiente:

Informática Forense y Evidencia Digital 

Delitos Informáticos y Criminalidad en Internet

Análisis forense en Mac OS X

Análisis forense en Windows

Análisis de sistema de ficheros NTFS / Logs / indicadores de compromiso

Análisis Forense en Linux

Malware y Amenazas (Troyanos, documentos con bugs, Ransomware)

Análisis Forense de Documentos

Análisis Forense de virtualización y RAID

Análisis Forense en Redes, antiforense, correos electrónicos y VoIP

Análisis Forense de aplicaciones Microsoft

Análisis Forense de tarjetas SIM, Blackberry y Windows Phone

Análisis Forense en IOS

Análisis Forense en Android

Cada módulo de 8 horas de duración.

El elenco de profesores tampoco se queda atrás: Pedro Sánchez, Juan Garrido, Jaime Adrés Restrepo y otros muchos.

Si estás interesado, no dudes en pre-inscribirte ya mismo desde aquí porque el curso empieza el 23 de Febrero y termina el 21 de Mayo
Leer más...

20 enero 2015

AntiRansom 2.5 is out !!

Aun con la enorme satisfacción de haber conseguido que Unhide fuese elegida 'Mejor herramienta de seguridad 2014' (Muchas gracias a todos los que votaron!!) todavía reciente, he decidido lanzar un update de otra herramienta: AntiRansom.

Ya en la versión 2.0 adelanté medidas proactivas para detener una infección en curso y en esta versión 2.5 las he afinado para que funcionen mejor.

Básicamente he mejorado el ratio de detección para 'cazar' al proceso que está haciendo lo que no debe y generar un volcado de su memoria.

He grabado un vídeo con una muestra real de ransomware para que se vea bien como funciona.

Si tenéis dudas sobre como instalar / desinstalar, visitad el post de la versión 2.0





Podéis obtener la versión 2.5 de AntiRansom en primicia desde aquí
Leer más...

18 enero 2015

Enlaces de la SECmana - 259

Leer más...

15 enero 2015

No, no te van a identificar remotamente con el DNIe 3.0

Nada me gusta menos que estropear una buena historia, y menos si esa historia tiene componentes de conspiraciones, con buenos y malos, donde los malos oprimen a los buenos y se repite mucho el número '1984'

Vaya por delante mis sentidas disculpas a toda la gente que ha estado estos días desinformando sobre el DNI-E 3.0 y su tecnología RFID. 

La parte que más me ha gustado de la historia es la de 'y te van a poder identificar remotamente', y si va acompañada de enlaces a carteras especiales 'anula-RFIDs', es aun mucho más entretenida.

No obstante, la realidad se impone y lamentablemente ese escenario, no es real. Y no es real porque simple y llanamente no se va a poder acceder a los datos del nuevo DNI de forma remota ... sin una clave de acceso ÚNICA por CADA DNI

¿Y donde está esa clave de acceso? Buena pregunta, esa clave está impresa en el DNI ¿Simple eh?. En realidad no es nada nuevo, como ya contamos hace algunos años, es una tecnología parecida al nuevo Pasaporte que también tiene tecnología RFID. Mucho se difamó el concepto, muchas cábalas se hicieron. Han pasado años y nada, sin noticias de que alguien haya conseguido vulnerar el sistema.

En el caso del nuevo DNI, las tecnologías que salvaguardan el acceso a los datos son 'MRZ' (Machine Readable Zone) y 'CAN' (Card Access Number). El caso del MRZ es lo mismo que en el Pasaporte. Un código que se 'lee' mediante OCR del pasaporte. Y en el caso del nuevo DNI, se añade CAN que es un número que aparece en la parte inferior derecha del anverso.

Si nos fijamos en la foto que ilustra este artículo, parece que a la pobre Mireia no se lo han explicado bien, ya que el número que sale en la foto (276224) es el código necesario para acceder a sus datos, su foto y su firma mediante RFID.

A partir de ese número (o el código MRZ) el lector y el DNI derivan y negocian una clave de sesión para el intercambio cifrado de datos. En principio tampoco se van a poder hacer ataques de tipo 'replay' en el caso de que alguien esté a la escucha de la conversación entre lector y DNI.

Entonces ¿Cómo queda la historia? Bueno, la historia termina con un dispositivo RFID en tu bolsillo al que nadie que no tenga el DNI en su mano (para leer los códigos de acceso) va a poder acceder. Y si lo tiene en la mano, los datos que va a poder sacar son los mismos que puede leer mediante RFID. 

En mi opinión, el paso a RFID, lejos de ser un movimiento ladino del gobierno para identificar manifestantes, va en el sentido de que se pueda usar desde dispositivos móviles y por consiguiente se le pueda sacar más utilidad. Actualmente, el hecho de necesitar lectores de tarjeta, ha sido un mazazo a la usabilidad ya que casi nadie los tiene o los quiere usar, pero ¿quién no va a tener un móvil con RFID de aquí a 3 años? Los habrá, seguro, igual de seguro que el número de personas que los tengan será notablemente superior al que hoy día tiene lector de tarjetas smartcard

PD: Algo muy parecido se ha hecho ya en Alemania
Leer más...

13 enero 2015

Bluebox-ng Howto (II)


Buenas otra vez, vamos a seguir en donde nos quedamos anteriormente, así que pego el vídeo de nuevo y vamos a comentar cada paso. La idea del orden de los ataques a lanzar es evitar, en la medida de lo posible, que nos bloqueen. O por lo menos que lo hagan lo más tarde posible (ej: fuerza bruta al final).

El primer paso es un escaneo SIP, se hace una petición para saber si el objetivo tiene servicios corriendo de este tipo. De la respuesta se intenta obtener el "User-Agent" (o “Server”) para conocer el servicio y la versión que está corriendo. Realmente, para cada combinación IP/puerto, se lanza una petición utilizando cada uno de los métodos SIP más comunes ("OPTIONS", "REGISTER", "INVITE", "MESSAGE", "BYE", "NOTIFY", "PUBLISH", "SUBSCRIBE") sobre todos los protocolos de transportes que puede operar el protocolo SIP (UDP, TCP, TLS-distintas versiones, WS-Websockets y WSS-seguro). De esta forma sabremos, por un lado, los servidores que están online y, por el otro, de qué alternativas disponemos para jugar. Todas las respuestas recibidas se guardan en el campo "responses" del informe para poder estudiarlas con calma.

Uso módulo auto

A partir de aquí, para cada objetivo encontrado, se siguen las acciones descritas en los siguientes puntos:
  • Obtención de información: Geolocalización, DNS inverso, ping, TCP ping, traceroute, búsqueda de posibles vulnerabilidades conocidas para ese servicio y si SHODAN tiene esa dirección IP indexada. Los resultados esta vez se irán almacenando en el campo del informe correspondiente del módulo que lanzan (“ping”, “traceroute”, “vulns”, etc.).
  • Se hace otro escaneo, que se almacena en el mismo campo (“responses”). Pero esta vez con tipos de peticiones un poco extrañas que, en principio, no deberían requerir respuesta del servidor (o por lo menos una positiva). Ojo, en principio no son vulnerabilidades, pero nos ayuda a conocer un poco más a lo que nos enfrentamos. Asimismo obtenemos una visión bastante clara de la buena o mala configuración del servidor y de la calidad su implementación del protocolo SIP.
  • Llamadas sin autenticar a ver si pasan o no, “sipUnauthCall” en el informe.
  • Ataques de fuerza bruta lentos, pues eso, atacamos primero extensiones y luego contraseñas, pero siempre con una espera bastante larga entre peticiones. El objetivo de ver si nos bloquean ante ataques de este tipo, no obtener las contraseñas de momento. No son los más cómodos, pero pueden ser bastante efectivos con contraseñas débiles y tiempo (campo “sipSlowBrute”).
  • Paquetes maliciosos: Aquí usamos dos módulos:
    • “sipSqli”: En el protocolo SIP también existe este vector, aunque aquí no tenemos el sqlmap … :(. De momento no realizamos la inyección, simplemente enviamos el “payload” a ver si nos bloquea, nos responde o nos descarta la petición.
    • “sipTorture”: Un RFC bastante conocido para este protocolo es el 4475 (“Session Initiation Protocol (SIP) Torture Test Messages”). Como su nombre indica en él se describen distintos tipos de peticiones que podrían estresar al servidor y hacerlo romper. No hemos implementado todos los casos todavía, pero sí un número representativo para conocer, un poco más sobre la calidad de la implementación/configuración.
  • Test de denegación de servicio (“sipDoS”): Simplemente enviamos paquetes consecutivos para ver, como en los dos casos anteriores, si nos responde, nos descarta o cuanto tarda el servidor en bloquearnos.
  • Escaneo de puertos comunes en estos entornos (“nmap” en el informe). Para esto usamos el Nmap, es la única herramienta externa que nos permitimos por el momento. El motivo es que no conocemos ningún escáner decente escrito en Node.
  • Fuerza bruta de extensiones: Como comentamos alguna vez en el blog con este protocolo es posible tratar de adivinar las extensiones. Para ello tenemos dos módulos que son los que se utilizan aquí: “sipBruteExt404” y “sipBruteExt100”. No son las dos únicas vulnerabilidades conocidas de este tipo, pero sí las más extendidas.
  • Fuerza bruta de contraseñas (“sipBrutePass”): Si encontró alguna extensión válida en el paso anterior utilizará esas, en otro caso probará también con una lista. Todo esto lo podéis especificar en el perfil elegido al lanzarlo.
  • Generación del informe
En el post anterior comentamos que la herramienta se podría usar como cualquier otra librería de Node. Esto nos permite desarrollar nuestros propios scripts o herramientas personalizadas. Un ejemplo sencillo podría ser el siguiente, que serviría como base para un sistema de pentesting continuo diseñado para un entorno VoIP. El código está incluido en la carpeta "examples" del proyecto. Por simplicidad vamos a suponer que solo tenemos una dirección IP expuesta en Internet y solo vamos a comprobar SIP sobre UDP (puerto 5060) como protocolo de transporte. Podríamos hacer lo mismo para un rango completo o para un array de direcciones IP, sobre cualquiera de los protocolos de transporte soportados. Si queremos modificar alguno de los parámetros podemos añadirlo o modificarlo en el objeto “moduleOptions”.
  • Búsqueda en Shodan (requiere clave): Comprueba si la dirección IP está indexada en Shodan. Evidentemente solo tiene sentido si se trata de una dirección pública.
  • Escaneo SIP: Para ver si el servidor tiene algún servicio SIP activo.
  • Fuerza bruta de extensiones: Igual que antes intenta enumerar extensiones y/o usuarios si el servidor es vulnerable a dos fallos conocidos: CVE-2009-3727 y CVE-2011-2536.
  • Llamadas sin autenticar.

Uso del script

Finalmente nos gustaría comentar nuestro TODO a partir de ahora:
  • Incluirlo en las distintas distribuciones GNU/Linux, empezando por las de seguridad.
  • Hasta el momento simplemente programamos los vectores que más usábamos, pero nos quedan algunos interesantes y unas cuantas ideas que queremos probar.
  • Como sabemos que hay más gente escribiendo herramientas de seguridad en Node.js nos gustaría unir esfuerzos de alguna manera. A los interesados os queda aquí el enlace: https://gist.github.com/jesusprubio/8f092af4ca252e252eab
Esto es todo por hoy, esperamos noticias vuestras ... ;)

Artículo cortesía de Jesús Pérez y Sergio García

Leer más...

11 enero 2015

Enlaces de la SECmana - 258



Leer más...

09 enero 2015

Yomvi fomenta el uso de software obsoleto y vulnerable

Desde hace algún tiempo, la 'batalla' contra las retransmisiones deportivas por Internet ajenas al titular de los derechos, se está recrudeciendo. 

Se han llegado a lanzar campañas de corte pseudo-mafioso contra portales de tipo RojaDirecta cuya motivación era 'entorpecer' el buen funcionamiento de esas páginas y, en teoría, evitar que pusieran de forma gratuita contenido cuyo titular quiere legítimamente comercializar.

Cabe pensar que, ante esa feroz campaña anti webs que ponen el contenido gratuito, el titular de los derechos se ha esmerado en poner en el mercado una alternativa eficaz que aporte ventajas sobre la opción gratuita

Actualmente, la opción más consolidada es Yomvi, la plataforma de Canal Plus España que permite, por ejemplo, comprar un partido de futbol por menos de 9 euros.

Hasta aquí todo está bien, 9 euros por un partido a cambio de verlo sin cortes y con buena calidad me parece razonable. El problema viene cuando se intenta usar el servicio de Yomvi. De entrada, han basado su plataforma en Silverlight de Microsoft. Esto ya supone un pequeño problema para usuarios de Linux que han de emplear alternativas exógenas como pipelight para poder usarlo.

Por si no fuera poco, el servicio NO funciona con la última versión de Silverlight, es decir, una persona que haya seguido el ciclo de versiones de esa plataforma se encuentra con que al intentar cargar un partido el navegador devuelve:


Por supuesto, Yomvi NO indica que el problema viene por usar una versión actual, incluso su equipo de soporte técnico directamente se lava las manos. Si has pagado por ese contenido y tienes la 'suerte' de usar una versión actualizada del plugin, te has quedado sin contenido, ni lo vas a ver ni te van a re-embolsar tu dinero.

Si te da por googlear puedes encontrar foros no oficiales donde indican el problema: Con la última versión no funciona.

Y la solución propuesta es emplear la versión 5.0, que de entrada no es fácil de conseguir y encima data del 2011


Si miramos el listado de vulnerabilidades reportadas para esa versión, podemos encontrar con que, para usar Yomvi, aceptamos navegar con una versión que tiene hasta 5 formas reportadas de EJECUTAR CÓDIGO en nuestro PC y por consiguiente ser susceptibles a ser infectados por un Ransomware, un troyano bancario o convertir nuestro equipo en una botnet.

Y este es el panorama del fútbol por Internet 'legal' en España. Plataformas que obligan a usar versiones vulnerables, que penalizan a quien usa una versión actualizada (directamente le roban, no puede visualizar) y cuyo soporte técnico nada quiere saber en caso de problemas.
Leer más...

08 enero 2015

Libros recomendados sobre seguridad en la actualidad

Hoy os traemos una recopilación de libros que desde mi punto vista son muy interesantes y de un modo u otro, están relacionados con la seguridad informática y las últimas tendencias ciber que tantos titulares nos dan últimamente. Salvo los libros de la serie "Jeff Aiken Series" de Mark Russinovich que son novelas con gran contenido técnico y muy cercanos a la realidad (aunque ficción al fin y al cabo), y la biografía de Kevin Mitnick contada por él mismo con Ghost in the Wires, el resto son trabajos de investigación de diferentes temáticas que os contaremos brevemente, y escritos por grandes periodistas.

Mark Russinovich - Jeff Aiken Series

     Zero Day (2011)           Trojan Horse (2012)       Rogue Code (2014)

      

Mark Russinovich, más conocido por ser el creador de la suite de SysInternals, deja a un lado la programación y los internals de Windows para traernos una trilogía genial en la que tendremos APTs (de verdad), espionaje, investigaciones concienzudas, análisis de incidentes en todos los niveles, y un largo etcétera, centrando el protagonismo en un investigador de seguridad llamado Jeff Aiken el cual se encargará de salvar al mundo ya en 3 ocasiones.

Brian Krebs - Spam Nation (2014)



Brian Krebs, periodista y azote de las mafias underground (su blog se está doseando más últimamente que las redes de PlayStation y Xbox estas navidades...), desenmascara en este libro las operaciones de spam y hacking dirigidas contra los americanos. Con investigaciones y entrevistas en exclusivas, nos daremos cuenta de lo tremendamente vulnerables que somos frente a estas mafias organizadas con las que convivimos (muchas veces sin ni siquiera enterarnos...) día a día.

Kevin Mitnick - Ghost in the Wires (2012)


Después de muchos años, y con varios libros en los que siempre se ha intentado contar su vida desde sus inicios por parte de otros, el propio Kevin Mitnick ha plasmado en este libro todas sus aventuras en las que sabremos cómo empezó y por qué, anécdotas de sus hacks e ingenierías sociales y muchas historias más. Si bien en libros suyos anteriores de la serie "The Art Of XXX" también nos cuenta algunas de las etapas de su vida, aquí tendremos la oportunidad de tener mayor detalle de todas sus aventuras.

Kim Zetter - Countdown to Zero Day (2014)


Si estás al tanto de las últimas modas en seguridad informática, tendrán que sonarte los términos Duqu, Stuxnet y demás. Estas nuevas campañas avanzadas suponen una amenaza mayor a la que estábamos acostumbrados anteriormente, en el que el objetivo ya no son simplemente bases de datos, sistemas operativos de usuarios o empresas aleatorias. Kim Zetter, periodista y editora de Wired, comienza desvelando desde el inicio hasta el final todo lo que ocurrió con Stuxnet (su planificación, ejecución, descubrimiento, contención, investigación...) tras disponer de testimonios de los propios investigadores que desvelaron esta amenaza. Pero no sólo Stuxnet es el protagonista de este libro, ya que además Zetter se adentra en los mercados y redes que están detrás de estas amenazas cuyo objetivo es el ataque a infraestructuras críticas.

Glenn Greenwald - No Place to Hide (2014)



¡No podía faltar un libro relacionado con la NSA y Snowden! Este libro fue mencionado y recomendado durante la mesa debate en la última Rooted Valencia. Lo bueno de este libro es que está escrito por Glenn Greenwald, periodista de The Guardian, el cual pudo entrevistar en primera persona a Snowden en Hong Kong, desconocido por todo el mundo hasta ese momento, y que decía tener evidencias claras del espionaje que estaba realizando el gobierno y la NSA sobre los ciudadanos americanos.

Os recordamos que en nuestro blog encontraréis más libros relacionados con la seguridad informática (tanto en formato novela como técnicos para aprendizaje) bajo la etiqueta Libros.

Si queréis recomendar algún libro de este tipo, ¡no dudéis en utilizar los comentarios!
Leer más...

05 enero 2015

Cine de Hackers: The Imitation Game (2014)


Llevaba ya tiempo detrás del estreno de la película de la que os voy a hablar hoy, y acabo de llegar de verla en el cine, así que tengo fresquito el contenido y las sensaciones que la misma me ha generado.

Si menciono a Alan Turing como uno de los padres de la informática, supongo que muchos de vosotros sabréis de qué hablo, y que conocéis la historia del excéntrico matemático inglés, que fue contratado por el gobierno de su país, en plena Segunda Guerra Mundial, con el único fin de ayudar a descifrar las comunicaciones alemanas. 

En aquella época, Alan Turing se encontraba trabajando en la Universidad, y al recibir la llamada de su país, se puso manos a la obra en un proyecto altamente secreto (de hecho, se mantuvo como secreto de estado incluso 50 años después) para generar una máquina capaz de descifrar los mensajes generados por Enigma, las famosas máquinas alemanas, cuya configuración (o clave) cambiaba diariamente. El número máximo de combinaciones a probar era de 139 trillones, y dar con la clave correcta hacía válido el descifrado hasta las 12 de la noche de ese mismo día. 

Obviamente, a principio de los años 40, cuando no había ordenadores (de hecho Turing se considera el precursor del primer ordenador) no existía en la Tierra ninguna forma de hacer un ejercicio de criptoanálisis similar para poder llegar a descifrar el código. 

En la película, el genial actor Benedict Cumberbatch (que posiblemente recordéis como protagonista de la serie Sherlock) da vida a Alan Turing, cuya forma de ser, totalmente fuera de lo que podríamos considerar normal, hace un papel genial que le viene como anillo al dedo.


-. ATENCIÓN, SPOILERS! .-

Llama la atención de la película, cómo logran acotar el número de comunicaciones necesarias, gracias a la repetición de la idéntica despedida de los mensajes, con un saludo a Hitler, lo que disminuía y mucho el trabajo a realizar por Cristopher, el nombre de la máquina según la bautizó Alan. Uno de los puntos de inflexión de la película, que le da una de las claves a Turing para llegar a este punto se dio en un bar. Me recordó mucho a la escena de "Una Mente Maravillosa", en el que John Nash, habla de su teoría de juegos y concluye que Adam Smith estaba equivocado

Más importante aún que descifrar el código correcto diariamente, es el mantener el secreto de que son capaces de hacerlo, que haría que los alemanes cambiasen el diseño de la máquina y mandase a /dev/null el trabajo realizado hasta ese momento. Por ello idean una estrategia para detener algunas operaciones, y dejar pasar otras. Según decían en la película, era como jugar a ser Dios, puesto que tenían en su mano el poder o no salvar un montón de vidas a voluntad. 

Gracias a semejante proeza, se calcula que la guerra terminó dos años antes y que se salvaron 14 millones de vidas humanas. Lamentablemente, la de Alan Turing no fue una de ellas, puesto que en esa época, en Inglaterra, ser homosexual estaba considerado como una actitud indecorosa y tipificado como delito, por lo que Alan fue condenado a un tratamiento que se supone que "lo curaría de su enfermedad". Al año de dicho tratamiento, el propio Alan decide poner fin a su vida, suicidándose. Una vez más, las leyes escritas por unas pocas personas, hacen que otras personas sean culpables de un delito.

La película está ambientada de una forma espectacular, interpretada por "Sherlock", y la actriz Keira Knightley (que da vida a Joan Clarke), que hacen que permanezcas al 100% todo el rato que dura la misma.

No esperéis nmaps, metasploits, ni APTs en esta ocasión, pero en mi opinión, es una película muy entretenida, que te hace ver en fotogramas la historia que hemos leído sobre uno de los padres de la computación digital.

FICHA:
Rigor técnico: 4/5
Historia: 5/5
Calificación general: 5/5

Leer más...