09 octubre 2014

Auditoría de seguridad de redes UMTS (3G) y GSM (2G) en tu móvil

Hace unos años aparecía una herramienta OpenSource revolucionaría que nos permitiría conocer muchos secretos de las redes GSM; OsmocomBB. Tras este proyecto, SRLabs en un intento de modernizar la solución y facilitar el uso, hizo posible analizar trazas de las redes UMTS y GSM en un dispositivo móvil en un nuevo proyecto: la aplicación para Android GSMmap . Para poder evaluar las capturas de esta aplicación y con ello ver qué está pasando en estas redes, es necesario instalar otra aplicación: xgoldmon, de Tobias Engel, que debe ser ejecutada en un PC bajo Linux.


¿Tobias Engel? Efectivamente, os debe sonar este nombre ya que fue él quien realizó en la 25C3 la impactante presentación de cómo localizar teléfonos móviles en las redes SS7:


Es probable que a muchos no os suene a nada el acronimo "SS7", pero desde luego que es el corazón de las interconexiones de redes internacionales (Roaming), formado por un conjunto de protocolos de uso muy común: SCCP, ISUP, INAP, MAP ... desarrollado por AT&T a partir de 1975. 

Pues bien, Tobias Engel y Ravishankar Borgaonk han creado una nueva aplicación para Android totalmente independiente, sin necesidad de otro software en el PC: Darshak (ver código fuente) que examinaremos a continuación con todo detalle en este artículo y como no, pondremos a prueba. La aplicación examina la información del interfaz de Anroid Radio Interface Layer (RIL) para detectar eventos anormales y presentarlos al usuario; llamadas sin cifrar, sin autenticar, etc. Dentro de estos eventos se encuentran los famosos SMS invisibles (silent SMS), utilizados para localizar a un usuario dentro de la red móvil o para instalar una aplicación Java en nuestra SIM, como demostró Karsten Nohl en su conocida charla de la BlackHat 2013: Rooting SIM cards.
  • Requisitos
Para poder utilizar la aplicación darshak necesitamos:
  1. Teléfono Samsung Galaxy S3 (GT I9300) aunque en alguna presentación los autores han hecho mención al Samsung Galaxy S2. 
  2. Version 4.1.2 de Android. Recomiendo descargarla de Sammobile
  3. Rootear el teléfono. Los autores aconsejan utilizar framaroot, aunque en mi caso ninguna versión encontró un exploit adecuado y acabé recurriendo a Odin y el mod CF-Root creado por el desarrollador Chainfire (version CF-Root 6.4).
  4. Configurar el modo DEBUG del teléfono a "HIGH". Para ello, en la aplicación marcador del teléfono, escribimos el código *#9900#, veremos la opción "Debug Level Enabled" y marcaremos el valor a "HIGH". Tras esto el teléfono se reiniciará.

Si no tenemos problemas de último momento, en un par de horas hemos subido la versión de Android y rooteado el teléfono, descargado la aplicación del Android Market y ya estamos listos para analizar las redes 3G y 2G.
  • Uso de la aplicación
Nos encontraremos ante una pantalla vacia, con una estructura de tabla donde podemos leer:



· Fecha (Date): Timestamp del momento en el que se detecta el evento/alarma.
· Tipo de Red (Network type): indica el tipo de red que estamos utilizando en el momento del evento, si es 2G o 3G.
· Evento (Event): indica si se trata de llamada saliente o entrante, mensaje saliente o entrante.
· Autenticación (Authentication): mostrará una bola verde si todo ha ido bien o roja en caso de no haberse autenticado el evento. Es decir, si hemos realizado una llamada y la red no nos ha solicitado autenticarnos, entonces veremos la bola roja.
· Cifrado (Encryption): De igual modo que antes, si el evento ha sido cifrado veremos la bola verde, pero si el evento ha tenido lugar en plano, bola roja.
· Eliminar (Remove): Eliminar el evento de la aplicación.

Presionando sobre cualquier campo excepto en Eliminar, se abrirá otra ventana con más información sobre el evento, donde encontraremos información muy útil que veremos a continuación. En contra de lo que podamos pensar, hay que darle al boton de "Refresh logs" cada cierto tiempo porque la aplicación no se auto-refresca todo lo bien que debería (¡punto de mejora!).
  • Vamos a poner la aplicación a prueba
Para muchos usuarios con llegar a este punto ya puede ser suficiente, tenemos la aplicación instalada y esperamos que un día al refrescar aparezca un evento en la pantalla principal de darshak. Si no podemos esperar y queremos comprobar cómo funciona, vamos a generar llamadas y mensajes en 3G y en 2G, sometiendo la aplicación a situaciones provocadas para comprobar que efectivamente son detectadas y reportadas. Veremos también métodos para obtener las evidencias de estos eventos/alarmas, fundamental en toda auditoría de seguridad.

Para generar llamadas y mensajes cortos vamos a utilizar la aplicación GSMmap, de la que hemos hablado en la introducción. En los ajustes del télefono vamos a forzar a sólo utilizar redes GSM (2G) o sólo utilizar redes UMTS/WCDMA (3G) para a continuación ejecutar GSMmap. Tan sólo tenemos que entrar en modo contribuir información (Contribute), aceptar el disclaimer y presionar sobre "Run Test":


Una vez haya finalizado todo el ciclo (por defecto 5 iteraciones de 4 pruebas), salimos de la aplicación para abrir darshak:


Vaya ... ya sabíamos que las redes GSM no autentican todas las operaciones, tal y como pudimos leer en otro artículo de Security by Default, pero ... ¿ Sólo 2 de 9 han sido autenticadas? ¡No parece mucho ! Vamos a abrir uno de estos eventos pulsando sobre la fecha. A continuación podemos ver dos llamadas de ejemplo, en una sí se ha solicitado la autenticación por parte de la red y en la otra no:


Parece increíble, tenemos una cantidad de información valiosísima en esta pantalla:
  1. Los algoritmos de cifrado que soporta nuestro teléfono.
  2. El TMSI que está utilizando la SIM (TMSI: Identidad Temporal de la SIM) .
  3. El evento, en este caso una llamada realizada por nuestro móvil (OUTGOING CALL), y que ha sido cifrada (Network operator is requesting to start ciphering).
  4. El algoritmo con el que finalmente se va a cifrar la llamada (¡¡A5/3 !! ¡¡Por fin !!).
  5. En el caso del evento alarmado, vemos que la red no ha pedido ningún tipo de autenticación, ni siquiera una identificación del terminal (IMEI).
  6. En el otro caso, vemos bajo GSM_INIT_AUTH_REQ el número aleatorio (RAND) que la red ha enviado a la SIM para autenticarnos.

En este punto, a parte de mi asombro al poder contar con esta información en el móvil allí donde vaya, me pregunto si al abrir las trazas de la aplicación GSMmap me encontraré con la misma información, para así acabar de convencerme de que esta aplicación es realmente una maravilla.

En la ruta donde se instala la aplicación GSMmap en el móvil encontraremos las trazas de las pruebas (/Android/data/de.srlbas.gsmmap/files), copiamos el fichero a nuestro PC y lo abrimos con xgoldmon:

/opt/xgoldmon# ./xgoldmon -t s3 -l -i 127.0.0.1 xgs.GT-I9300.20141007-195238.GSM.zzzz.sms_mt.4.log

Antes de ejecutar xgoldmon, abrimos wireshark escuchando en el puerto 4729 para ver las trazas:



Podemos ver en la primera imagen que efectivamente en el proceso de autenticación se ha utilizado ese número RAND. Si continuamos, en la seguna imagen podemos ver los mensajes Ciphering Mode Command y Complete, en los que también comprobamos que estamos utilizando el algoritmo A5/3, como remarco en rojo en la imagen.

Si repetimos el proceso para una llamada UMTS, podemos ver los mensajes SecurityModeCommand y SecurityModeComplete, a partir de los cuales el resto de señalización estará cifrada. En rojo he marcada el algoritmo UEA1, mientras que en amarillo la secuencia de autenticación y cifrado.


Para no alargar el artículo, resumo mi experiencia comentando que he podido comprobar que la aplicación refleja perfectamente estos eventos en las redes 2G, aunque en 3G tienen que corregirse algunos bugs sobre alarmas falsas de cifrado:


Cuando investigamos las trazas, vemos que la llamada sí se ha cifrado con los algoritmos UEA1 y UIA1, pero debido a este fallo,el evento es presentado con alarma. Según he podido confirmar con los autores de la aplicación, en unas semanas se publicará la siguiente versión de la aplicación que corrige este fallo.
  • Para terminar.
Cuando estaba alucinando con esta aplicación, pensé en el único punto negativo que se me ocurría; cuando vea una alarma en el móvil, no tendré más trazas/evidencias de lo que ha pasado que el evento de la aplicación. Pero me estaba equivocando, sí las tenemos en una base de datos sqlite3.

Si queremos investigar cualquier evento notificado por la aplicación, debemos buscarlo dentro de la base de datos sqlite3 que se encuentra en /data/data/darshak/databases/


Investigando dentro podemos llegar a ver la ráfaga UMTS o GSM que ha causado el evento en la aplicación, dejo a vuestra disposición una pequeña captura que muestra cómo ver los eventos mostrados y para uno de ellos (ID 31), ver la información ampliada.


sqlite3 /Darshak/DarshakDB
SQLite version 3.8.2 2013-12-06 14:53:30
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .tables
CELLULAR_EVENT    PACKET            PROFILE_PARAMS  
LOG               PACKET_ATTR       android_metadata
sqlite> select * from LOG;
23|1412579648961|2|4|XXXXX|1
...
59|1412747333774|1|1|XXXXX|0
sqlite> 
sqlite> select * from LOG where UID='23';
23|1412579648961|2|4|XXXXXX(operadora)|1
sqlite> 
sqlite> select * from PACKET where UID='7';
7|23|1412579648961|5|05 12 00 E1 47 DE 16 32 0F 72 89 46 01 6A 31 3F 2A 18 22 20 10 34 68 45 1E 78 AE 00 00 13 ED 2E D8 F4 38 C9 44 |0
sqlite> 
sqlite> select * from PACKET_ATTR where PACKET_UID='7';
19|7|1412579648961|1|E1 47 DE 16 32 0F 72 89 46 01 6A 31 3F 2A 18 22 |RANDOM Number : E1 47 DE 16 32 0F 72 89 46 01 6A 31 3F 2A 18 22 
20|7|1412579648961|19|34 68 45 1E 78 AE 00 00 13 ED 2E D8 F4 38 C9 44 |AUTN Number : 34 68 45 1E 78 AE 00 00 13 ED 2E D8 F4 38 C9 44 
sqlite>   

Si ahora os fijáis en los datos de la llamada en 3G que hemos visto en la imagen anterior, podéis ver que los número RANDOM y AUTN son los mismos, pero ahora tenemos acceso a la ráfaga entera, la cual nos va a permitir conocer más detalles:
05 12 00 E1 47 DE 16 32 0F 72 89 46 01 6A 31 3F 2A 18 22 20 10 34 68 45 1E 78 AE 00 00 13 ED 2E D8 F4 38 C9 44

  • Conclusiones.
Hace unos meses los compañeros de Layakk nos presentaron en la RootedCon su ataque a 3G. Quienes pudimos ver la charla nos quedamos con muchas dudas sobre cómo se ha implementado la seguridad en esta red, dudas que hoy gracias a darshak podemos despejar sin mucho esfuerzo, simplemente utilizando nuestros móviles para luego analizar la información que nos aportan.

¿Se cifran todas las llamadas en 3G? ¿Se autentican todos los eventos?¿Cada cuanto tiempo se refresca nuestro TMSI/P-TMSI/GUTI?

A veces es preferible no conocer las respuestas a estas preguntas para seguir con esa agradable sensación de falsa seguridad que nos proporciona el desconocimiento, pero si quieres conocer qué pasa en las redes móviles, te recomiendo probar darshak.

Contribución gracias a Pedro Cabrera
Leer más...

08 octubre 2014

Mi experiencia en Navaja Negra 2014 #nn4ed




Mucho ha dado que hablar Navaja Negra, uno de los Congresos de seguridad españoles, en los que la transparencia ha predominado, tanto en temas organizativos como de la decisión de la mayoría de las charlas, mediante el voto democrático por los asistentes al mismo.  Como ponente y asistente al mismo, puedo dar fe que el buen ambiente, la camaradería y esa sensación de volver a ver toda junta a un montón de loco por la seguridad, ha imperado. Sin embargo, no todo ha sido tan positivo. Quizá tardemos en saber qué sucedió con la demo de Pedro Candel AKA s4ur0n, debido a la cola que ha traído a nivel mundial con su charla "Pesadilla en RSA”.

Hablando única y exclusivamente en mi nombre, le envío un abrazo enorme a Pedro, que como cualquier humano, puede equivocarse. En cualquier caso, lo que hace noble a una persona, no es que no cometa errores nunca, sino su capacidad para reconocerlos públicamente, e incluso pedir disculpas por ello.

Por compromisos laborales en Madrid, me perdí la primera de las jornadas, la del jueves, donde debió haber un interesante debate entre cuerpos y fuerzas de seguridad del estado, con conocidos abogados y representantes de la Comunidad. Igualmente, me llegó muy buen feedback de la charla del amigo Pedro Sánchez y de lo amena e instructiva del abogado sevillano Luis Jurado #JE. 

El viernes por la mañana debuté en Navaja Negra 2014 con un taller patrocinado por Cyberoam, de Buenas Prácticas de Configuración de Sistemas de Seguridad Perimetral. Fueron dos horas y pico (y si no es porque miré el reloj, por mí, aún estaría allí hablando), de una charla bastante interactiva con el público, que permitió hacer una “clase colaborativa”, que desde mi punto de vista fue muy enriquecedora para todos, incluido por supuesto, para mí.



El viernes por la tarde, pude asistir a la charla de Chema Alonso. Ésta iba sobre ciertas peculiaridades en funcionamiento interno de Google a la hora de cachear e indexar las páginas que va viendo, permitiendo hacer BlackSEO, ataques de fuerza bruta, así como ciertas dosis de Google dorking.

Tras el descanso, vino la mencionada charla de Pedro Candel, a la que asistí muy parcialmente.

Para cerrar el día, estrené la charla “CSI Madrid S13E37: спасению” en la que condensaba lo más rápidamente un caso de peritaje forense al que tuve que hacer frente durante las Navidades de 2013-2014. Un caso que inicialmente parecía sencillo, al rascar en profundidad, simplemente se "fue de madre”. Varias configuraciones incorrectas, debido a que el servicio informático que mantenía la máquina demostró unos conocimientos nulos en materia de seguridad (usuarios con contraseña configurada como vacía desde hacía años y nunca cambiada, uno de ellos “admin” en el grupo administradores, el servicio Terminal Server abierto a Internet sin restricción alguna, etc,…) hicieron que varios ciberdelincuentes se lo pasaran pipa con un Windows 2003, utilizándolo cada uno para ganar dinero, de diferentes formas.



Al finalizar la charla, el turno de preguntas lo inauguró Dani Kachakil, que planteó una muy razonable duda, que hacía tambalearse todo el planteamiento del caso. Básicamente, Kachakil decía que un Windows 2003, por defecto, no permite que un usuario con contraseña vacía, se conecte a través de Terminal Server, y que para que esto se pueda hacer, hay que modificar una clave del registro de Windows, que invalida esa medida de seguridad. En el momento en el que lo planteó, me vinieron a la cabeza la de horas de trabajo invertido y pensé, pues tiene razón pero..... sin embargo, yo sé los logs que analicé, las conexiones del usuario “admin” registradas en el Log, desde direcciones IP de Rusia y China, entre otros, así como la actividad en el directorio del usuario admin…

Varios asistentes a la charla, que además indicaron que se dedicaban al mundo forense, corroboraron lo que decía Kachakil, y planteaban la misma duda. Además, Dani indicaba que había que hacer un cambio en una key del registro para permitir el acceso remoto, lo cual no cuadraba con los conocimientos tan pobres que demostró el servicio de mantenimiento informático (tomarse la molestia de buscar en Google cuál es la clave del registro y cambiar el valor correspondiente para poder entrar con contraseña vacía de forma remota, quizá fuese muy descabellado, pudiendo poner una contraseña sencilla). 

Tras el fin de la jornada del viernes, y ya de copas, abordé a Kachakil en un bar y estuvimos hablando del tema de nuevo. A su opinión se sumó Necronoid que rotundamente decía que eso no era posible y que tenía que existir algo más. Al rato, apareció Jesús Pérez Rubio que se mostró más neutral, no teniendo claro cuál era la solución o la raíz del problema. Con todo esto, la verdad es que aún tuve más dudas al respecto, aunque también estaba seguro de lo que había visto, por lo que… cuando llegué al hotel, me puse a trastear con un Windows 2003 que tengo en una máquina virtual, y esto fue lo que pasó: Creé un usuario llamado admin, con contraseña vacía (para poder hacerlo, tuve que eliminar los requisitos de contraseña, que tenía setteado a 12 caracteres en esa máquina); al crearlo con contraseña vacía, el sistema te indica que no se podrá acceder al sistema remotamente con ese usuario; lo incluí en el grupo administradores.  Trasteando por la Configuración de seguridad, en Directivas Locales -> Opciones de Seguridad, dí con una directiva que dice “Cuentas: Limitar el uso de cuentas locales con contraseña en blanco sólo para iniciar la consola”. La modifiqué a deshabilitada y probé desde una Kali,… rdesktop contra la IP, usuario admin, contraseña en blanco y para adentro…. Al final, no era tan difícil, aunque sinceramente, no entiendo para qué un administrador Windows iba a hacer esto, con los riesgos de seguridad que implica, pero todo apunta a ello.




Yendo más allá, la modificación de la directiva mencionada, por debajo, lo que hace es cambiar el valor de la clave HKLM\System\CurrentControlSet\Control\LSA\LimitBlankPasswordUse a valor 0. 
Sólo me quedaba comprobar, a partir de los ficheros que contienen la rama System del registro de Windows en HKLM, en la máquina analizada en el peritaje, si este valor era el indicado. Tras hacer un regdump.pl -vr del fichero system y filtrando por la cadena "limitblankpassworduse", se ve esto:

limitblankpassworduse (REG_DWORD) = 0x00000000 (0)

Es decir, que efectivamente, esto estaba así en la máquina y todos teníamos razón. Los que indicaban que por defecto no se podía acceder por Terminal Server con usuario con contraseña vacía a partir de Windows 2003, y yo en tanto en cuanto este setting había sido deshabilitado en su momento por "vayaustedasaberquién" siendo posible este cambio.

El sábado por la mañana pude ver parte de la charla de Abraham Pasamar sobre evasión de sistemas antivirus, de la que tiene una excelente saga en Security By Default, y lamentablemente no pude ver la de Alejandro Nolla ni la de Óscar Tébar.

Me habría gustado atender al resto de las charlas, pero entre motivos laborales el viernes, personales el sábado y conversaciones en la puerta con asistentes al evento, se me pasó el tiempo volando.

Leer más...

07 octubre 2014

Se avecina un nuevo spin-off de la serie CSI (longeva dónde las haya, con gran cantidad de temporadas y con variantes tanto para Las Vegas como de Miami y Nueva York) relacionado con el mundo de la tecnología y todo lo que cuelgue de la palabra cyber*: Por el momento, parece que podría llamarse CSI: Cyber


A modo de piloto podremos ver el capítulo 'Kitty', episodio 21 de la temporada 14 de la franquicia CSI: Las Vegas que se emitió el 30 de Abril de este año. En dicho capítulo, el equipo regular de la serie tendrá que solicitar ayuda a la división de cibercrimen de Quantico (Virginia) para resolver un caso del asesinato de la mujer de un magnate de los casinos.



Entre los actores confirmados destacan las caras conocidas de Patricia Arquette, que interpretará a la agente especial Avery Ryan y que ya apareció en el piloto, y James Van Der Beek, que hará el papel del agente Elijah Mundo. Uno de los papeles de "cyberhacker" será interpretado por Shad Moss (también conocido como Bow Wow), un famoso rapero el cual fue confirmado para la serie este verano.

Tal y como se conoce en el mundo del forense, la serie siempre ha estado en el punto de mira por no reflejar especialmente la realidad tanto en la manera de actuar como de resolver los casos, pero no por ello deja de ser entretenida. Seguramente para el caso de la franquicia CSI: Cyber nos echaremos las manos a la cabeza en más de una escena, con direcciones IP que rompen todos los estándares, geoposicionamiento imposible y herramientas de hacking al más puro estilo salvapantallas. 

Lo que sí está claro es que la temática cyber o los hilos argumentales de los casos que se intenten resolver, con todo lo que nos acontece últimamente, podremos tomarlos como perfectamente creíbles.

Leer más...

05 octubre 2014

Enlaces de la SECmana - 244


Leer más...

04 octubre 2014

8.8 Computer Security Conference





Como ya avancé en el post en el que hablaba sobre la cantidad de Congresos de Seguridad que se avecinan para Octubre, 8.8 en Santiago de Chile, en el que además participaré, es uno de ellos. La organización del evento me ha hecho llegar la nota de prensa sobre el mismo, y la reproduzco, tal cual me la han enviado, bajo estas líneas.


EL MAYOR EVENTO DE HACKING EN CHILE

Hackers internacionales enseñarán cómo hackear autos y semáforos en cuarta versión de 8.8 Security Conference

  • Cargada de sorpresas y novedades llega 8.8 Computer Security Conference 2014 ¨Superheroes, el evento de seguridad técnica (hacking) más emblemático del país.
  • Desde 2011 el evento reúne a profesionales y expertos de todo el mundo en torno a las últimas vulnerabilidades  y avances de la seguridad informática internacional.
  • En su cuarta versión el evento cuenta con expertos desde México, Argentina, España, Colombia, Perú, Suiza, Francia y Chile.
  • Este año el Gobierno chileno se encuentra preparando un proyecto de protección de datos personales, temática que se abordará en la charla “THE GOVERNMENT AS YOUR HACKING PARTNER”.
Con catorce expertos en hacking, invitados desde ocho países, se llevará a cabo este año la cuarta versión de la emblemática 8.8 COMPUTER SECURITY CONFERENCE, el principal evento de seguridad técnica de Chile, que se realiza este año el 23 y 24 de octubre en el Cine Arte Normandie.

Organizado por un grupo de profesionales de seguridad de la información, el evento reúne a profesionales y expertos de todo el mundo en torno a las últimas vulnerabilidades y avances de la seguridad informática internacional.

Este año llegan desde México, Argentina, España, Colombia, Perú, Suiza y Francia a Chile para compartir con otros jefes de seguridad informática y actualizarse en grupo sobre las nuevas tendencias de protección virtual.



HACKING Y GOBIERNO
Una de las charlas más reveladoras de este año es la que ha desarrollado Jose Garduño (mexicano residente en Chile) presentando los resultados de su tesis de maestría titulada "Las deficiencias en protección de la privacidad de Chile: una visión general de las políticas públicas, la cultura, el diseño del sistema, implementaciones y herramientas informáticas para su explotación. En su charla “The government as your hacking partner”, Garduño nos explica que la principal problemática se presenta porque las sociedades democráticas se enfrentan actualmente a un dilema muy difícil, por un lado, existe una demanda para tener acceso a los datos manejados por el gobierno como un mecanismo de control, auditoría y transparencia, y por otra parte, no hay marcos legales internacionales y locales actualizados para el establecimiento de límites sobre la información que debe ser expuesta, especialmente en relación con los datos personales privados. Garduño nos invita a la charla haciéndonos la siguiente pregunta, ¿Te gustaria saber cuanta informacion personal tuya se encuentra publicada en internet y se puede obtener solo con tu nombre o rut?, no te pierdas mi charla.

HACKEANDO, SEMAFOROS Y AUTOS COMO EN LAS PELICULAS
Entre los otros invitados de este año se encuentra César Cerrudo (CTO, IOACTIVE LABS) quien llega desde Argentina con la charla Hacking US (and UK, Australia, France, etc.) traffic control systems, una interesante exposición sobre cómo vulnerar la seguridad de los sistemas de control de tráfico de las principales ciudades del mundo, narrando cómo logro hackear los semáforos de Washington DC, San Francisco y Nueva York, método que podría aplicarse a capitales de Australia, Reino Unido, Francia y China, entre otras. Según Cerrudo, después de la exposición todos los asistentes tendrán el conocimiento para hacer lo mismo. 

El colombiano JaimeAndrés Restrepo, llega con la charla “Hackeando carros en Latinoamérica” donde expondrán  los diferentes problemas de seguridad encontrados en los últimos años por investigadores de seguridad en reconocidas marcas de automóviles de países anglosajones, teniendo claro que los vehículos de gama alta no son los únicos que se ven afectados por estos problemas. En esta charla mostrarán cómo marcas de autos económicos y altamente extendidas por países latinoamericanos, también cuentan con problemas de seguridad que podrían poner en riesgo a su conductor, acompañantes y peatones.

SOBRE 8.8

El nombre 8.8 hace referencia a la magnitud (la más alta antes de Japón) del gran terremoto que hubo en Chile en Febrero de 2010. El nombre fue elegido por su relación con Chile y también para destacar y sensibilizar sobre la importancia de prepararse de antemano para eventos/incidentes importantes, inclusive en el ámbito de seguridad de información.

Un grupo de profesionales relacionados a la seguridad de la información en distintos ámbitos en Chile aburridos con las típicas "conferencias de seguridad" orientados a la gerencia, gestión o organizadas para fines comerciales decidieron organizar una conferencia de hacking o 100% técnica, enfocada principalmente en compartir conocimientos y experiencias.

Nos gustaría que esto fuera un evento donde las personas interesadas en seguridad de la información: CIOs, CTOs, CISOs, ISOs, sysadmins, arquitectos de sistemas, desarrolladores de sistemas, administradores de red, especialistas en seguridad, consultores, analistas de riesgo, administradores de sistemas, estudiantes, hackers, geeks y muchos otros pueden compartir conocimientos y experiencias en un ambiente distendido y confortable. El objetivo principal es compartir experiencias, conocer las últimas técnicas que se usan, los últimos tipos de ataques registrados, la forma en que ellos se concretan y cómo se repelen.
Leer más...

03 octubre 2014

Línea temporal con incidentes de seguridad en puntos de venta

En OpenDNS Labs han realizado un genial trabajo de recopilación de todos los casos de incidentes de seguridad relacionadas con puntos de venta en comercios (también conocidos como PoS o Point of Sale) o negocios relacionados con la restauración.



A modo de línea temporal (timeline), podemos consultar información referente a más de 59 incidentes registrados. Si bien se tiene constancia de que, según un informe de Verizon se han registrado más de 198 incidentes, en esta recopilación se indican aquellos de los que se dispone de una fuente pública de información relacionada con ellos.

Línea temporal con incidentes relacionados con ataques en Puntos de Venta (POS)

El primero de todos los que podremos encontrar corresponde con un incidente de Julio de 2008 ocurrido en Fuddruckers, cadena estadounidense de restaurantes de comida rápida, especializada en hamburguesas. En este caso, se descubrió un keylogger en el terminal del punto de venta que permitió a los atacantes obtener más de 1300 datos de tarjetas de crédito de clientes. Ojo, estamos hablando del 2008...aunque parezca que la moda de ataques a PoS sea de los últimos meses, este tipo de vectores de ataque lleva presente años.

Si queréis información más detallada de cada incidente, os recomendamos en primer lugar registrarse en DatalossDB (proyecto del que os hablamos en el post DatalossDB: Mantente al día sobre fugas de información). Posteriormente, cuando consulteis la línea de tiempo, la mayoría de los enlaces llevarán a las fichas correspondientes con estas fugas de información.

Información detallada sobre el incidente de Fuddruckers

Podéis encontrar la línea temporal en el siguiente enlace:


Referencias:
Leer más...

02 octubre 2014

Las agencias de prensa tienen mala fama, ¿Por qué será?

Después de tanto tiempo con el blog (ya van unos cuantos añitos ...) son ya varias las anécdotas relacionadas con agencias de prensa que acumulamos los editores del blog.

Hoy voy a contar varias anécdotas y ya de paso, por si alguien se siente aludido o le resulta útil, a dar algunas pistas sobre como (desde mi humilde opinión) deberían hacer los acercamientos.


De entrada, nos reiteramos en lo que siempre hemos dicho: este blog NO es comercial. No hemos facturado ni un solo euro y NO vendemos posts, ni 'reviews' patrocinadas. No, no lo hacemos. 

Hay blogs que lo hacen y me parece genial, perfecto y les apoyamos desde aquí. Escribir en un blog supone invertir un tiempo y monetizarlo, es una opción genial.

La anécdota más repetida es enviar notificaciones sobre productos / ideas / proyectos que tienen que ver 0 con la seguridad. Nos han llegado propuestas para escribir sobre webs de música(?), productos financieros(?), ropa deportiva(?) y un largo etc de cosas totalmente ajenas.

Hombre, si estás buscando que la gente colabore, al menos DEDICA UN POCO DE TIEMPO a discernir si la temática aplica o no !

Otra de las más repetidas es el 'quiero poner enlaces' o 'quiero poner publicidad'. A estas peticiones siempre respondemos lo mismo: No somos un blog comercial, no aceptamos ni publicidad ni enlaces ni nada.

Si ves un blog que lleva más de 5 años online y no hay ni rastro de publicidad ¿no crees que será por algo?

Una de las anécdotas que más nos divierte es cuando alguien, supongo, en un rápido vistazo ve un nombre y se dirige a nosotros por ese nombre. Son míticos los 'Hola Alejandro', 'Hola Lorenzo' a la cuenta de contacto. Esto la verdad es que da igual, pero es verdad que genera mucha mejor imagen si al escribir pones 'equipo de...' o todos los nombres. Eso ya es +1 punto ganado.

Para la parte final me reservo una anécdota que entra dentro de la malicia y sobre todo la poca clase que me sucedió con ArenaMedia

Recibo el siguiente correo:







Le contesto preguntando qué es lo que quiere (por ahorrar tiempo) y me invita a acudir a su oficina a desayunar. Le vuelvo a preguntar qué es exactamente lo que busca y después de varios correos me dice:


Lo que me parece estupendo quitando el hecho de que yo no cursé una carrera de ciencias :(

Se lo explico y sigo tratando de indagar sobre qué es lo que quiere para llegar a:


¡ Acabáramos ! Así que se trata de escribir en el Huffington ! Mi respuesta:


Y ella, no obstante me lanzó otra propuesta, esta ya con el lamín de 'te pagaremos por ello' :


A lo que yo, le dije:


Que es básicamente lo que solemos hacer en estos casos, no, no queremos dinero y sí, nos encanta ayudar de buena FE a la gente siempre y cuando se cumpla la máxima de: que aporte contenido relacionado con la seguridad que es de lo que va el blog. Si esta buena mujer tiene acceso a alguien de algún proyecto relacionado con la seguridad, encantado de hablar de él.

Tras un correo en el que se muestra entusiasmada me pasa un contacto (que no voy a reproducir porque nada tiene que ver en esto) para que yo le llamase y moviese el tema :


En paralelo, esta buena mujer contactó con la gente del Huffington y les ofreció dinero para que yo escribiese ahí sobre 'su tema'. La gente del Huffington me llamó y me preguntó al respecto, otra vez les dije que no, no me interesaba cobrar por escribir.

En estas, con el contacto que me había pasado esta buena mujer, le respondí:


¿Y que creéis que pasó? que nunca mas supe, es decir, ni me respondió al correo !!! ni se molestó en aclarar los motivos de porqué ya no se iba a realizar. 

Incluso pasados unos meses le volví a escribir y tampoco supe nada más de ella !

Increíble pero cierto, después de un montón de tiempo invertido, de que molestase a mis compañeros del Huffington, de poner todo el cariño del mundo, nada, 0, nunca más.

Obviamente, aquí surgen dos problemas, de entrada, que acciones como estas hacen que el siguiente que llegue le trates peor o al menos con más recelo y por supuesto que indignifica y mucho el nombre de su cliente, a quien representa y que por supuesto nada tiene que ver y es una víctima colateral. Me consta que el proyecto Talentum es una idea SENSACIONAL que merece todo el apoyo del mundo y del que han surgido un montón de iniciativas GENIALES, por eso me apena mucho que esta buena mujer haya obrado así jugando con ese nombre

Y por esto, amigos, las agencias de prensa tienen la mala fama que tienen
Leer más...