Security Art Work

Desde la aparición de las redes sociales se ha ido concienciando poco a poco a los usuarios del peligro de compartir cierta información con los demás. Una de estas redes sociales, cada vez más popular y que en general y a diferencia de otras, proporciona la información publicada por un usuario a otros sin restricciones de acceso, es Twitter. Esta red ha cumplido 7 años desde su lanzamiento (muchos tweets que contar…) y parece que la mayoría de los usuarios todavía no están concienciados acerca de la privacidad, como suele ser habitual.

Como sabemos Twitter permite dos tipos de cuentas: las protegidas, cuyos tweets son accesibles sólo a las personas “autorizadas”, y las cuentas desprotegidas, cuyos tweets son accesibles a cualquier usuario. Dejando de lado que, tal y como sucede en otras redes sociales, un tweet “protegido” deja de serlo cuando un usuario sin la cuenta protegida lo “retuitea”, ¿qué ocurre con las cuentas de Twitter no protegidas? Éstas no sólo permiten a las personas seguir tu timeline sin necesidad de tu autorización (ie. hacerse “seguidores”), sino que además permite que cualquier usuario de Twitter, seguidor o no de tu timeline, pueda leer tus tweets. Es una ventana abierta pública a todo lo que escribimos. Esto tiene sus ventajas, pero también sus inconvenientes.

Para ver porqué esto puede ser en ciertos casos un problema, vamos a hacer uso de TweetDeck, uno de múltiples clientes que permiten añadir “columnas” según criterios de búsquedas e incluso el timeline de una persona, a la que no tenemos porqué “seguir” y que podemos por tanto “monitorizar” sin su conocimiento. Veamos un ejemplo:

¿Qué información comparte la gente por Twitter?

No es la primera vez, ni será la última, que los usuarios comparten información privada y en ocasiones confidencial a través de medios menos que óptimos. Esto da como resultado, como ya se ha visto a lo largo de otras entradas en este y otros blogs, que información que no debería ser a priori pública, esté al alcance de cualquier persona con un poco de curiosidad y/o maldad. Sólo hay que hacer una búsqueda con ciertas palabras clave e indagar en los tweets obtenidos.

¿7 años después?

No importa los años que lleve Twitter en marcha, los nuevos usuarios se registran y la mayoría de ellos, sin preocuparse en las opciones de seguridad/privacidad que nos ofrece esta red social (muy inferiores, desde luego, por su distinta naturaleza, al caso de Facebook), comienza a enviar Tweets públicamente. Unos comparten fotos (personales, de tarjetas de crédito/débito, comprometidas, etc.), mientras que otros usuarios más “atrevidos” comparten información sensible como su número de teléfono, su correo electrónico o incluso contraseñas. Eso, dejando de lado salidas de tono que a diario cometen personalidades, políticos, deportistas, etc. Aunque parecería que ante este tipo de cosas es suficiente con borrar el Tweet, sólo hay que pasarse, por ejemplo, por topsy y muchos de estos tweets públicos aunque hayan sido borrados todavía estarán cacheados, pudiéndose consultar perfectamente.

Conclusiones

A estas alturas huelga decir que falta concienciación entre muchos usuarios de las redes sociales, y Twitter no es una excepción. Es muy preocupante que los usuarios compartan información tan sensible entre sus contactos, sin ser conscientes de que cualquier persona puede leerlo. En general, el ego representado en el número de followers ha asumido como estándar una configuración abierta, donde un número relativamente bajo de usuarios tienen cuentas protegidas, a diferencia de otras redes sociales donde “parece” que empieza a existir una cierta comprensión de las implicaciones de una cuenta abierta. En este caso, cabe aplicar el sentido común y ser consciente de las implicaciones de nuestras publicaciones. En cualquier caso, siempre es útil rememorar que PLBKAC.

Lanzo una pregunta al aire, ya que muchos usuarios desconocen o no se preocupan por la privacidad: ¿debería establecerse por defecto la cuenta protegida?

(N.d.E. Dejemos aparte las implicaciones que esto tendría para la expansión de Twitter y su modelo de negocio)

Estamos cansados ya de hablar del término convergencia cuando nos referimos a la unificación, como un todo, de los diferentes ámbitos de la seguridad: física, lógica, etc. Por eso, en este post queremos hablar de divergencia, haciendo referencia a las cosas que separan los ámbitos particulares de seguridad, en especial los de seguridad lógica y seguridad física. Y una de las principales diferencias entre la seguridad física y la seguridad lógica, bajo mi punto de vista, es la regulación que tiene la primera, para lo bueno y para lo malo, y de la que adolece la segunda, de nuevo para lo bueno y para lo malo.

El sector de la seguridad privada está completamente regulado (perdón, muy regulado, no sé si completamente o casi…); los perfiles de seguridad y sus obligaciones y atribuciones se identifican claramente, así como los requisitos para acceder a dichos perfiles y poder ejercer las tareas propias de cada uno de ellos: Vigilante de Seguridad, Director de Seguridad, Jefe de Seguridad… Por contra, cuando hablamos de seguridad lógica, no existe ningún tipo de regulación: cualquiera puede hacer una auditoría, configurar un cortafuegos o gestionar un incidente, por poner unos ejemplos. Esto no es per se ni bueno ni malo ni todo lo contrario, pero introduce una condición curiosa y es el criterio particular y subjetivo que en cada caso aplicamos para decir si algo está bien o mal o para decidir si una persona o una empresa está capacitada para realizar un trabajo determinado.

Podemos discutir (y de hecho en este blog ya lo hemos hecho en más de una ocasión) de los perfiles existentes en la LSP, sus requisitos de acceso, sus atribuciones, su formación y mil cosas más; pero como hemos dicho, están perfectamente definidos, con todas las mejoras que podamos introducir sobre ellos. Podemos hablar largo y tendido de la formación, escasa en muchos casos, para obtener el TIP de Vigilante, Jefe o Director de Seguridad, sobre todo de las deficiencias que presenta, pero no podemos hablar de la formación, habilitación o lo que sea para gestionar un incidente de seguridad lógica (ojo, hablo de formación reglada, no de asociaciones, academias, certificaciones o demás). Y no podemos porque, obviamente, no existe: en ningún sitio están recogidos de forma oficial los contenidos mínimos para obtener la “habilitación” de auditor de seguridad lógica, incident handler o “director de seguridad de la información”.

Ojo, no sólo hablamos de regulación “legislativa”, sino también de normas; en seguridad física existen normas UNE o ISO para casi todo: armeros, cajas fuertes, CRA… y además muchas de ellas son de obligado cumplimiento incluso por Ley. Por contra, en seguridad de la información tenemos algunas normas puntuales, ninguna de ellas de obligado cumplimiento (en términos generales y hablando de normas UNE/ISO) y que en la mayor parte de casos no dan más que pinceladas de lo que debería ser, no de lo que debe ser: dicho de otra forma, una norma de aplicación en seguridad física marca casi siempre al detalle, por ejemplo el nivel de resistencia de una caja fuerte para que cumpla con el estándar hasta un grado determinado, mientras que la normativa de seguridad de la información es más del tipo “debemos proteger las redes”. Ya, ¿cómo? :)

Ahora la pregunta del millón: ¿sería positivo que el sector de la seguridad de la información o de la seguridad tecnológica estuviera tan regulado como el de la seguridad privada? Imagino que habrá opiniones para todos los gustos, y que esa regulación traería cosas buenas y malas. Creo -opinión particular para discutir- que una cosa negativa de la regulación excesiva es que deja poco margen a la imaginación o, incluso, a la mejora (esto se hace así porque lo dice una Ley y de ahí no te puedes salir) y eso, a la larga, convertiría esta seguridad en algo bastante estático, todo lo contrario a lo que debe ser la seguridad y más la que tiene una componente tecnológica muy fuerte. Por contra, con la regulación del sector se evitaría cierto intrusismo, al menos a priori: para abordar un proyecto se deberían cumplir unos requisitos determinados, y el que no los cumpla “no juega” (luego, a partir de ahí, ya veríamos cómo los cumple cada uno, qué requisitos son, si son mejores o peores, etc.). No cualquiera que pase por la calle podría hacer una auditoría, por poner un ejemplo, igual que no cualquiera puede montarse una CRA: hay que cumplir con una legislación estricta para empezar a hablar. Ah, y no entro al tema de las atribuciones profesionales de cada uno, que esa es otra guerra distinta (aunque también da juego, ya hablaremos ya ;).

En fin, que opiniones hay para todos los gustos… por cierto, ¿cuál es la vuestra? Seguiremos hablando de otros aspectos de la “divergencia” entre seguridad física y lógica o, en general, entre “seguridades”. Eso sí, sin olvidar que todos, se supone, vamos en el mismo barco…¿verdad?

Como suele decirse en algunas ocasiones, existen dos maneras de aprender las cosas. Por las buenas, y por las malas. Luego verán a qué me refiero.

Hace unas semanas discutía con mi pareja sobre el porcentaje de penetración influencia de los medios digitales frente a los medios tradicionales como fuente principal de información, en el caso de la prensa escrita específicamente. Es decir, hasta qué punto Internet había reemplazado al diario matutino para conocer las noticias diarias. Como pueden imaginarse, no llegamos a ninguna conclusión, aunque sí es cierto que atendiendo a las estadísticas de algunas organizaciones dedicadas al tema quizá el nivel de penetración es menor del que yo inicialmente pensaba; encerrado como estoy 24 horas al día en un mundo digital, lo raro hubiese sido pensar lo contrario. La cuestión es que todavía queda un buen porcentaje de la población cuya vía principal de información siguen los medios tradicionales: la prensa escrita, la televisión y la radio.

En el mundo pasado de los medios tradicionales, una campaña publicitaria o de marketing solía tener un impacto reputacional relativo. Por una parte, porque el mensaje era unidireccional: yo te digo esto y tú te lo crees o no te lo crees, pero tu participación en el mensaje es como receptor. En todo caso, te envío cupones o te hago encuestas, pero todo en un marco muy controlado, nada de salirse del guión. Por otra parte, porque existía un monopolio informativo: todos (o casi todos) los medios de producción de información pertenecían a empresas con determinada ideología e intereses, que podían tener intereses comunes con los anunciantes o recibir presiones de éstos; este tipo de cosas, dicen, aún pasan hoy en día, tanto en la prensa oficial tradicional como en la (oficial) digital. Es decir, usted no me publica esto y seguimos tan amigos, o si lo publica, que sea en la página diez en una columna perdida, o seremos un poco menos amigos.

En el mundo actual, en el que conviven mundos digitales y mundos tradicionales, el escenario ha cambiado muy significativamente. El lenguaje ha dejado de ser unidireccional para convertirse en bidireccional, a pesar de muchos. Ahora, campañas de marketing tradicionales que podían exhibirse normalmente en televisión sin mayores consecuencias hacia la imagen de marca porque al otro lado sólo había ojos y orejas, pueden desencadenar consecuencias muy perjudiciales para la reputación, debido a que el mundo digital es más conversacional y abierto a la participación y la crítica. En este escenario, algunas organizaciones han sabido reaccionar, analizando hasta donde es posible las consecuencias de una campaña e incluso aprovechando este doble sentido de la comunicación, mientras que a otras les ha pillado a contrapie. No es raro encontrarse de vez en cuando con esta o aquella multinacional metiendo la pata hasta el fondo, como suele decirse, lo que sobra decir el impacto que puede tener sobre la imagen de marca.

El segundo factor es más importante si cabe que el primero: el fin del monopolio de los medios de producción de información. Aunque evidentemente las corporaciones de medios de comunicación tradicionales mantienen un peso significativo en el mundo digital, entre otros por su ámbito generalista y por los clientes de la prensa escrita que les acompañan, ya no son ni mucho menos las únicas fuentes de información. Existen nuevos actores y nuevos medios. En este escenario digital ya no es posible controlar el mensaje ni el emisor, lo que hace que el mensaje ya no gire en torno a lo que la marca quiere que gire (algo que presiona a los medios tradicionales a un lugar incómodo: ese en el que deben mantenerse en una cierta vanguardia informativa sin arriesgar excesivamente la marca de sus anunciantes). Pasamos de hablar de machismo en un anuncio a acusaciones de explotación en un país asiático o la deforestación de los bosques de este o aquel país. Imaginen el impacto para la imagen de marca y la reputación de la organización.

Hacer frente a estas dos amenazas para mantener la reputación de la marca, que cada vez estará más asociada con la reputación “online”, va a requerir dos cambios principales. El primero, la bidireccionalidad del lenguaje, requiere un mayor análisis social por parte de los departamentos y agencias de marketing y publicidad: un conocimiento más profundo de la sociedad y de las diferentes sensibilidades, siempre, obviamente, que la idea no sea polemizar, que también es una opción válida. Hacer frente al segundo cambio va a requerir algo mucho más radical que se llama Responsabilidad Social Corporativa (RSC). Pero una de verdad, no una de anuncio de televisión: esa que tiene en cuenta los derechos de los trabajadores, las minorías étnicas, el medio ambiente, los problemas sociales y muestra un comportamiento ético y responsable con su entorno. Quizá todavía sea posible mantener una RSC “de pega” gracias a que estamos a medio camino entre el mundo digital y el mundo tradicional y como les decía el índice de penetración de los medios digitales sigue siendo escaso (entre la población adulta), pero a medida que avancemos y esos jóvenes que hoy ya se informan en Internet crezcan, cada vez será más difícil mantener la imagen de marca sólo a través de piezas y campañas diseñadas para ello. Como dice la Biblia, “Por sus obras los conoceréis” (Mt 7,15-20). Afortunadamente.

Esto es lo que va a pasar. Y muchas organizaciones lo van a aprender por las malas. Ya lo verán.

Hace ya algún tiempo tuvimos un incidente donde los atacantes estaban utilizando un servidor de la organización afectada como un proxy anónimo, aprovechando una configuración errónea del servidor. Durante el mismo incidente, nos vino a la cabeza la pregunta, ¿Qué usan para detectar que este servidor estaba mal configurado y tiene capacidad de proxy?. La pregunta no iba por la senda de averiguar una técnica muy compleja, sino ver qué podían estar utilizando y añadir dentro de nuestros análisis preventivos uno que compruebe que los servidores no tengan ningún servicio actuando como proxy anónimo, por error. Antes de ponernos a hacer un “pythonito” que haga justo eso, me puse a bucear un poco en la red.

Lo primero que encontré buscando sobre este asunto fue una entrada en un blog cuyo título era “FHTTP + shodan” (Ver I y II)

En esta entrada publican un script sencillo que va cogiendo como fuente Shodan y busca servidores que estén configurados como proxy anónimo. Está bien la idea, pero lo que necesitamos es algo que no dependa de Shodan y de los puertos que decide barrer.

Después de un rato buceando, hice una paradinha, y me dije, seguro que esto ya lo ha hecho alguien para nmap y es bastante probable que lo usen. Y realizando una búsqueda encontré http-open-proxy, ¡Bingo!

Veamos la descripción del plugin:

“The script attempts to connect to www.google.com through the proxy and checks for a valid HTTP response code. Valid HTTP response codes are 200, 301, and 302. If the target is an open proxy, this script causes the target to retrieve a web page from www.google.com”.

Para que el script se active tiene que encontrar alguno de los siguientes puertos:

portrule = shortport.port_or_service({8123,3128,8000,8080},{'polipo','squid-http','http-proxy'})

El script tiene dos parámetros muy útiles:

-- @args proxy.url Url that will be requested to the proxy
-- @args proxy.pattern Pattern that will be searched inside the request results

Un ejemplo de uso de los parámetros sería:

root@saw:~# nmap --script="http-open-proxy" --script-args="proxy.url=www.debian.org,proxy.pattern=
       The Universal Operating System" www.dominio.es -PN

Lo único que estamos diciéndole es que a través de la ip de www.dominio.es se intente conectar a www.debian.org y el patrón que debe buscar es “The Universal Operating System”.

El script por defecto viene con una serie de tests para comprobar si realmente se trata de un proxy o no, que podéis ver al editarlo. Su utilización es tan sencilla como:

root@saw:~# nmap --script="http-open-proxy" www.dominio-conocido.es -p8123,3128,8000,8080 -PN

Starting Nmap 5.21 ( http://nmap.org ) at 2013-03-01 19:47 MSK
Nmap scan report for www.dominio-conocido.es (z.z.z.z)
Host is up (0.024s latency).
PORT STATE SERVICE
3128/tcp closed squid-http
8000/tcp closed http-alt
8080/tcp closed http-proxy
8123/tcp closed polipo

Nmap done: 1 IP address (1 host up) scanned in 0.16 seconds

Ahora lo que vamos a hacer es proporcionarle al script una dirección que es un proxy recogido de un listado público:

http://www.xroxy.com/proxylist.php?port=8080&type=&ssl=&country=&latency=&reliability=#table

root@saw:~# nmap --script="http-open-proxy" x.x.x.x -p8123,8080,8000,3128 -PN -e venet0:0
Nmap scan report for x.x.x.x
Host is up (0.38s latency).
PORT STATE SERVICE
3128/tcp filtered squid-http
8000/tcp filtered http-alt
8080/tcp open http-proxy
| http-open-proxy: Potentially OPEN proxy.
|_Methods supported: GET
8123/tcp filtered polipo

Nmap done: 1 IP address (1 host up) scanned in 11.00 seconds

Ahora probamos con el típico puerto del squid, 3128:

root@saw:~# nmap --script="http-open-proxy" y.y.y.y -p8123,8080,8000,3128 -PN

Starting Nmap 5.21 ( http://nmap.org ) at 2013-03-01 19:54 MSK
Stats: 0:00:01 elapsed; 0 hosts completed (0 up), 0 undergoing Host Discovery
Parallel DNS resolution of 1 host. Timing: About 0.00% done
NSE: Script Scanning completed.
Nmap scan report for y.y.y.y
Host is up (0.11s latency).
PORT STATE SERVICE
3128/tcp open squid-http
| http-open-proxy: Potentially OPEN proxy.
|_Methods supported: GET HEAD
8000/tcp filtered http-alt
8080/tcp filtered http-proxy
8123/tcp filtered pólipo

Nmap done: 1 IP address (1 host up) scanned in 8.14 seconds

Este mecanismo u otro similar sería el que utilizarían los atacantes para descubrir proxy anónimos que no están públicos en el listado y realizar desde ahí sus fechorías. Nosotros ahora mismo podemos utilizar este mismo mecanismo para comprobar sobre nuestros clientes que ningún proxy tiene una configuración que permite su uso de manera anónima.

El tercer día de la /RootedCON se presentó igualmente interesante a pesar del cansancio acumulado. Prueba de ello fue la gran asistencia desde la primera charla que nos presentó la gente de Taddong, David Pérez y José Picó. Nos mostraron una manera de localizar un terminal móvil a través de la señal de comunicaciones por GSM. ¡Estaba chupado! Explicaron cómo triangular la señal utilizando para ello una estación base propia, conociendo únicamente el IMEI del teléfono a localizar y forzando a que se conecte a ésta. Tras una divertida explicación del proceso, modelos matemáticos utilizados y correcciones para que no lo situara en el Oceano Índico, consiguieron una precisión de un par de metros en un área de 2 kilómetros utilizando una antena omnidireccional para la localización aproximada y posteriormente cambiando a una dirigida para mayor precisión.

La siguiente charla vino de la mano de Joxean Koret, quien nos presentó la problemática de las aplicaciones actuales para detectar bugs y vulnerabilidades en el código y su propuesta: Fugue. Vimos que es necesaria una gran cantidad de dinero si quieres hacer uso de aplicaciones comerciales, aprendimos sus limitaciones y cómo las aplicaciones libres que existen en el mercado se quedan muy cortas cuando se trata de código con millones de líneas y un giga de tamaño. Esta herramienta, aún en desarrollo y parece que por mucho tiempo (entendemos el porqué), es capaz de analizar tanto el código como el programa compilado haciendo uso de una transformación AST, utilizar checkers de firmas tanto habituales como creadas por el usuario y centrarse únicamente en las partes del código que queramos y determinadas funciones o variables. Una idea sensacional en la que debe haber unas cuantas horas invertidas; si no recuerdo mal, cuatro años. Una presentación muy inteligible para un tema tan denso como éste.

Tras una pequeña pausa para reponer fuerzas con las famosas conchas, pasamos a la charla de Jaime Sánchez. En ella recordó el viaje realizado por un paquete de red desde la tarjeta hasta el espacio de usuario y presentó unos scripts para manipular la información de estos paquetes, con el objeto de confundir al usuario o a aplicaciones de fingerprinting, realizar detección de intrusiones a través de covert channels o para actuar como un IPS. Una charla muy interactiva con muchas demos en vivo.

A continuación llegó Raúl Siles, con una fuerte ovación incluso antes de comenzar con su presentación, en la que nos contó cómo funciona el mecanismo de conexión de diferentes dispositivos móviles a las redes Wi-Fi, cómo poder listar los PNL o Lista de Redes Conocidas y tras esto tratar de forzar al terminal a que se conecte a un punto de acceso controlado por nosotros. Vimos que en muchas ocasiones no se pueden eliminar las PNL y nuestro terminal se podría conectar sin nuestro conocimiento, para lo que presentó su iStupid, una herramienta para eliminarlas. Hizo una demostración en vivo de los PNL de los dispositivos de los presentes en la /RootedCON, a punto de establecer un Hall of Shame de PNLs comprometedoras. Tras muchas risas, terminó con las posibilidades de realizar MitM suplantando esas redes según el cifrado y el dispositivo utilizados. Muy completa.

Albert López sorprendió con una actualización del clásico HEAP overflow pero aplicándolo a las versiones actuales de glibc y kernel. Hizo una introducción muy detallada e ilustrativa del HEAP overflow y cómo jugar con las referencias a punteros de los BITS libres. He de reconocer que algunos nos perdimos con tanta referencia a forward y backward… Presentó algunas pruebas de concepto y correcciones sobre las diferentes formas de explotarlo, actualizando y corrigiendo un paper de 2005. Finalmente explicó un escenario muy particular de explotación (House of Mind) y cómo aprovecharlo. Anunció un paper de 100 páginas donde desarrolla en profundidad todo esto y la manera de evadir el parche que sacaron para corregir el fallo de House of Mind.

Para cerrar la jornada y el congreso, tuvimos la visita inesperada de Wardog, al que los asistentes pudieron realizar toda clase de preguntas y dudas y recibir sus punzantes respuestas. Muy divertido, como siempre. Tras esos minutos de entrevista llegó la hora de Chema Alonso y su presentación sobre IPv6, no sin antes agradecer la auditoría que hicieron de su panel de control de la botnet que presentó en la /RootedCON 2012 y algún que otro inquietante correo que le llegó a raíz de sus ponencias en diferentes eventos internacionales. Nosotros nos tuvimos que marchar dejando al pobre Chema con un problema con el router en IPv6, pero nos consta que pudo solucionarlo y seguir con la demo de su ponencia.

Finalmente queremos felicitar a la organización por el alto nivel de los ponentes, la coordinación de un evento con más de 600 personas. Estamos esperando ya impacientes la celebración de la /RootedCON 2014 a la que no faltaremos.

En nuestro segundo día de la RootedCon parece que el congreso va ganando cuerpo como el buen vino. La mañana la abrieron los chicos de OWISAM, Andrés Tarasco y Miguel Tarasco, presentando una interesante metodología de análisis de seguridad 802.11 y acompañada de una herramienta de auditoría la cual tenemos muchas ganas de probar. Desde Securityartwork desearles suerte con el proyecto, seguro que es un éxito.

Justo antes del café Jesús Olmos nos presentó ChromeHack un complemento del popular navegador de Google para la auditoría Web. La verdad es que me sentí muy identificado cuando comentó el origen del proyecto, el hecho de estar realizando un análisis y tener: una Hackbar, el Tamperda, Burp, Pipper,  2 escritorios, y siete consolas abiertas, hace que el test acabe siendo un infierno. Es por eso que, este maravilloso plugin permite realizar con un simple botón derecho del ratón contra un recurso HTML concreto: fuerza bruta a un login, inyección SQL  o XSS a formularios, fuzzing de URLs, todo ello basado en diccionarios de ataque. La verdad es que tenemos muchas ganas de probarlo y alimentarlo por ejemplo con los diccionarios del gran Pipper.

Concha Codan en el buche y zumito refrescante pasamos a ver la interesante ponencia de David Barroso (pese a que ya la habíamos visto en otros foros) sobre ataques de denegación de servicio distribuidos. Me sorprendieron muchas cosas pero en especial me pareció curioso el modelo de negocio de algunos ciberdelincuentes de “Pago por instalación”, es decir yo ya tengo mi botnet con mi legión de zombis y le vendo la instalación de su troyano de control a un segundo, pudiendo un único cliente infectado formar parte de varias botnets controladas por varios grupos criminales.

Justo antes de comer Sebastián Guerrero nos mostró como crear un rootkit para Android, ya que la Sandbox en estos terminales solo se despliega en el ring de usuario, no aplicando al Kernel o las librerías del sistema. Por lo tanto es posible en caliente cargar un módulo LKM, el cual se ejecuta en este espacio privilegiado. Su aportación permite obtener la SYSCALL TABLE (tabla donde se recogen la lista de direcciones de las llamadas a sistema) sin depender de la versión específica de un Kernel concreto de Android, esto es necesario para poder Hookear estas llamadas. Su módulo Penetraitor V0.1 puede, como Sebastián comenta, utilizarse para el bien, como por ejemplo debuggear aplicaciones o para el mal, creando una reverse shell cuando se le envíe un mensaje al teléfono o reciba una llamada de un teléfono concreto.

Tras un exquisito cocido madrileño, asistimos a la ponencia de Pepelux, donde nos mostró como realizar un test de intrusión sobre una FreePBX, distribución Linux con Asterisk integrado, destinada a realizar las funciones de centralita telefónica. Jose Luís nos enseñó cómo es posible comprometer este tipo de servidores a través de la creación de un plan de llamadas capaz de ejecutar código en el sistema. Ni decir tiene que todo acaba con final feliz, máquina rooteada.

Por último Roberto Baratta, CISO de Novagalicia, nos mostró como su compañía es capaz de luchar contra el ciberfraude bancario, a través de mecanismos como por ejemplo la correlación con SPLUNK o la cooperación con otras entidades. Me llamó la atención el comentario sobre la nueva directiva europea que obligará en 2014 a que los bancos estén obligados a publicar sus incidentes de seguridad. No obstante sí que hubo una cosa que me hizo levantar las orejas cual conejo deslumbrado en medio del asfalto, y es el hecho de que para analizar la seguridad del código de sus programadores, este se envíe a “La Nube”.

En general muy buenas sensaciones en este segundo día de la RootedCon, quedándonos incluso con ganas de más.

Un año más estamos en la /RootedCON. Este año se inicia con una interesante charla de David Fuertes titulada “Señales débiles, ¿nos protegemos sabiendo que nos van a atacar?“. David nos ha hablado sobre uno de los temas de moda como son las “APT” y el enfoque que le dan actualmente las organizaciones a la hora de protegerse, donde muchas de ellas no asumen que van a ser alguna vez comprometidas. David terminó exponiendo algunas ideas para detectar en las organizaciones esas señales débiles que puedan hacer saltar las alarmas, como puede ser centrarse en la cantidad de tráfico de red.

La siguiente charla corrió a cargo de Vicente Díaz: “Birds, bots and machines – fraude in twitter and how to detect it using machine learning techniques“, donde explicó una investigación que ha llevado a cabo para detectar campañas de bots de twitter que se dedican a enviar spam. Para poder diferenciar si es un bot enviando spam se aplicó machine learning, obteniendo en su estudio unos datos bastantes buenos de detección. También recalcó que una de las fases importantes de la investigación es la definición de los parámetros (públicos o calculados) que permiten después decidir si es un bot o no; un ejemplo de parámetro es el “tiempo medio entre tweet“. Como veis una charla muy interesante y con el mensaje de que no hay que tener miedo a la IA.

Jose Miguel Esparza y Mikel Gastesi “Sopelka vs Eurograbber: really 36 million eur?” nos hablaron de la botnet sopelka y alguna de sus peculiaridades, como por ejemplo que se trata de tres muestras de malware y un solo panel, un dato realmente curioso. Una vez ya habían detallado las funcionalidades pasaron a hablar de un informe que se hizo eco en todos los medios de amplia difusión sobre Eurograbber y las grandes cantidades de dinero robadas. Sobre el informe han hecho una crítica a la falta de rigor del mismo, tras realizar diferentes comprobaciones que han comentado en la misma charla. Su mensaje principal es que cuando leamos un informe debemos ser críticos y detectar rápidamente cuándo se trata de un informe enfocado únicamente al marketing.

Juan Antonio Calles y Pablo González: “Metasploit & Flu-AD: Avoiding AVs with Payloads/DLLs Injection” nos hablaron de Flu-AD, cómo ha nacido y cuál es su estado actual. La herramienta, como muchos de vosotros ya sabéis, es un troyano para que los cuerpos policiales puedan cazar a pedófilos, pederastas, etc. Flu-AD en su origen estaba hecha en .NET y debido a diversos requisitos (por ejemplo, tamaño inferior 50kb del binario) que se les ha marcado por parte de los cuerpos policiales han tenido que desarrollarla en C. Otro punto donde han centrado su trabajo es en hacer que todos sus componentes sean indetectables. También nos mostraron su integración con metasploit, para aprovechar todo su potencial.

Alejandro Ramos “Te pique lo que te pique analiza un SQLite“, nos contó la estructura de un SQLite y las consideraciones que hay que tener en cuenta cuando vas a recuperar información de una base de datos de este tipo. Básicamente comentó que cuando se borra información de SQLite, ésta no se elimina sino que se marca que el espacio está libre, por lo que la información como en los sistemas de ficheros hasta que no sea sobrescrita seguirá ahí. Una de las dificultades para la recuperación de información radica en las aplicaciones que de manera periódica reorganizan el espacio.

David Meléndez Cano, “Trash Robotic Router Platform“, enseñó dos prototipos en los que lleva trabajando unos cuantos años. Su filosofía para crearlos es reutilizar “cacharros” que todos tenemos por casa sin usar y crear este tipo de dispositivos. Uno de ellos estaba basado en un router linksys y el otro en una fonera. Estuvo contando cual ha sido todo el proceso y qué escollos se ha encontrado hasta tener los prototipos. Una charla muy buena y un trabajo increíble.

Y de momento, eso fue todo en el primer día de la rootedcon. Seguiremos informando.

El martes pasado estuvimos en unas jornadas organizadas por la Fundación Borredá en las que se presentó la capacidad conjunta del CNPIC e INTECO para el establecimiento de un CERT orientado a la Protección de Infraestructuras Críticas; en línea con las hipotéticas líneas de trabajo de esa futura Estrategia Española de Ciberseguridad, se potencia la capacidad de respuesta a incidentes y la Protección de Infraestructuras Críticas en una única iniciativa en la que INTECO y el CNPIC unen sus esfuerzos para mejorar las capacidades de detección, prevención y respuesta a incidentes en el ámbito de la PIC. Y de nuevo en este evento surgieron dos conceptos mágicos que, como el de convergencia del que hablamos en su momento, hasta la fecha están only available for Powerpoint: intercambio de información y colaboración.

Hace poco leía en el blog de @lostinsecurity una entrada bastante clara -y dura, pero real- en la que se referenciaban ambos términos, especialmente significativa después de ver a David Barroso en una mesa redonda en el CNIS de este año, con una frase en negrita con la que lamentablemente no puedo estar más de acuerdo: no existe la colaboración e intercambio de información que debería existir. Como con la convergencia, se nos llena la boca de colaboración y de information sharing… pero como suele pasar, el PPT es muy sufrido y la realidad, muy cruel… Colaboramos como amigos (conozco a fulanito y me hace el favor de darme la info que necesito porque mañana él me pide algo y yo le hago el favor, y luego nos tomamos unas cervezas) pero sin formalizar la relación entre organizaciones, y eso no puede ser; ojo, no es que esté mal, pero por sí mismo, no puede ser por los mil motivos que todos sabemos. Ya lo decía en su post @lostinsecurity: Dejemos el PowerPoint y el Word. Es hora de empezar a hacer algo útil.

Ya en 2007 Jeffry Brady, del National Joint Terrorism Task Force identificaba en Barriers to information sharing los problemas de los que hoy hablamos, cuatro tipos de obstáculos que es necesario afrontar para una compartición efectiva de información; a saber: tecnológicos (como la incompatibilidad entre sistemas de información diferentes), humanos (el más importante, la habitual resistencia al cambio), organizativos (el peor, esa cultura de muchas organizaciones de no compartir datos) y sistémicos (¿leyes?). Han pasado exactamente seis años y los problemas, a pesar de que las soluciones teóricas son muy conocidas, básicamente son los mismos; en opinión de muchos, entre los que personalmente me incluyo, “sólo” tenemos que poner dos cosas sobre la mesa para que estas palabras dejen de ser una utopía y pasen a ser una realidad (y si es efectiva, mejor que mejor): la primera, confianza y la segunda, bidireccionalidad. Tengo que confiar en los que van a recibir -anonimizados o no- información sobre mis incidentes, en muchas ocasiones sensibles; si no confío en ellos, lo que les envíe será poco o nada relevante salvo que un tercero con poder (¿por qué no?) me obligue: y aún así en este caso ya me buscaría la vida para cumplir la obligación dando la menor información posible… y si doy información útil, también quiero recibirla. No es algo nuevo que hayamos descubierto ahora; ya se decía hace años: do ut des. Si sólo soy yo el que aporta a una relación, mal acabará… ¿verdad?

Bien, tenemos claros los problemas y las soluciones… ¿qué pasa entonces? Ni confiamos ni nos gusta dar información. Como hace años, exactamente igual… ¿Qué hacemos? No voy a dar aquí la disertación de siempre sobre establecimiento de relaciones de confianza, modelos de intercambio de información y blablabla… ¿Para qué, si ya la sabemos y no le hacemos caso? Es el mismo discurso que en 2006 o 2007 pero con una diferencia: mientras lo mantenemos hemos perdido seis añitos que seguro que alguien, en algún lugar del mundo, ha aprovechado. Y si seguimos haciendo lo mismo, obtendremos los mismos resultados… a ver si la iniciativa del CNPIC e INTECO rompe esta línea.

Completamente de acuerdo con lo que decía @lostinsecurity: dejemos el PPT y las palabras bonitas y pongámonos manos a la obra. Señores de las Administraciones Públicas: lideren estas iniciativas; desde la empresa privada NO PODEMOS aunque queramos. Potencien el intercambio de información y la colaboración. Oblíguenme si hace falta, pero mejor convénzanme de que es lo mejor para todos (a mí particularmente no, ya estoy convencido ;). Compartamos información, colaboremos… y en especial en la protección de infraestructuras críticas, que tanta falta nos hace. Como decía, confiemos en que la iniciativa conjunta de INTECO y el CNPIC de la que hablábamos al principio tenga éxito y potencie la colaboración y el intercambio de información entre todos los actores involucrados en la PIC, llevándolas a la realidad y, más importante, convirtiéndolas en una salvaguarda de verdad. Nos hace falta como el comer. Ah, y ójala lo podamos hacer antes de que nos llevemos un susto, o algo peor.

Después de haber hablado en varias ocasiones sobre la esteganografia, volvemos al tema ampliando un poco más la técnica de LSB (Ocultando archivos en otros – LSB, Ocultando archivos en otros – LSB II).

Resumidamente, esta técnica consiste en ocultar información en el bit menos significativo de cada uno de los píxeles de una imagen, consiguiendo así que el cambio realizado sea invisible al ojo humano. El problema de esta técnica, es que la información oculta puede obtenerse fácilmente si esta no se ha codificado previamente o si no se sigue un patrón concreto a la hora de ocultarla. Para poder evitar que terceras personas puedan descubrir que una cierta imagen contiene información oculta, podemos utilizar la técnica que se explicará a continuación.

Este método de ocultación de información será útil (idealmente) para ocultar imágenes, de dos colores como máximo, dentro de otras imágenes, siendo necesario la posesión de un token (el cual será otra imagen) por ambas partes de la comunicación para obtener la imagen oculta. A pesar de decir que de forma “ideal” únicamente se pueden ocultar imágenes de dos colores, esto no implica que no se pueda introducir texto en una imagen bicolor, y esconder el resultado ;)

La técnica, básicamente consiste en dos imágenes, dónde una de ellas será una imagen que únicamente debería poseer el emisor y el receptor, y la otra será la imagen que queremos ocultar (la cual tiene que tener unas dimensiones menores o iguales que la imagen portadora).

Una vez se tienen ambas imágenes, se recorrerán todos los píxeles de la imagen a ocultar y si el color RGB del píxel es diferente de 0xFFFFFF (blanco puro), se restará “1” al color del píxel en esa misma posición de la imagen portadora (o se sumará “1” en el caso de que el valor del píxel sea “0”), modificando así únicamente aquellos píxeles cuya posición correspondan a píxeles “pintados” en la imagen a ocultar. De esta forma, para poder obtener la imagen oculta, se irán comparando uno a uno los píxeles de la imagen recibida con los de la imagen original (secreta entre ambas partes) y en aquellos que sean diferentes, será donde se han ocultado los píxeles “pintados” de la imagen a ocultar. Hay que remarcar, que con esta técnica, es posible que no se obtenga exactamente la misma imagen que al principio en el caso de que se usen más de dos colores, ya que en su obtención solo se “pintarán” dos colores (blanco o negro) perdiendo todos aquellos valores intermedios.

Por último, comentar que cuando se ha explicado esta técnica se ha dicho que es “ideal” para imágenes de dos colores, ya que en esos casos será donde menos diferencia visual exista entre la imagen original y la imagen modificada, pero que también se podría utilizar para tener en cuenta 3 o incluso más tonalidades, ya que el ojo humano no es capaz de diferenciar entre todos los valores existentes de color.

Para poder entenderlo todo mejor y verlo con nuestros propios ojos, se han creado dos scripts que se encargarán de ocultar una imagen en otra (Ocultar una imagen) y de obtener la imagen oculta de una imagen en base al token establecido (Obtener imagen oculta).

Suponiendo que tenemos la imagen1.png funcionando como token, y queremos ocultar la imagen2.png, deberemos realizar lo siguiente:

php ocultar.php png png imagen1.png imagen2.png imagen3.png

Obteniendo así una nueva imagen (imagen3.png) completamente “igual” a la anterior, pero con la imagen2.png oculta en su interior. Cuando la otra persona reciba la imagen3.png, podrá obtener su imagen oculta ejecutando el segundo script de la siguiente forma (donde OBLIGATORIAMENTE deberá indicar la imagen utilizada como token):

php obtener.php imagen1.png imagen3.png imagen4.png

Para aclarar un poco más el ejemplo dado, se mostraran las diferentes imágenes que se han utilizado a lo largo del proceso:

Imagen 1: Imagen en la cual se ocultará la segunda imagen. Podríamos decir que esta imagen funcionaría como password, ya que únicamente la deberían poseer las dos partes de la comunicación.

Imagen 2: Imagen que queremos enviar a la otra parte de forma secreta y que ocultaremos en la imagen 1.

Imagen aux: Superponiendo ambas imágenes, podríamos ver cuales serán los píxeles que se modificarán en la imagen original (imagen1.png) al ocultar la imagen 2.

Imagen 3: Esta será la imagen que deberemos enviar a la otra persona y que contendrá la imagen 2 oculta en ella, sin que nadie más pueda obtenerla sin poseer la imagen 1.

Como se puede observar, no se aprecia ninguna diferencia entre la imagen1.png y la imagen3.png, pero si las comparamos, vemos como son archivos diferentes.

Imagen 4: Está será la imagen que obtendrá el receptor cuando la extraiga de la imagen 3. Como se ve, a pesar de que “pierde” calidad, el mensaje oculto puede leerse perfectamente.

Con este ejemplo, hemos podido comprobar como modificando algunas de las técnicas básicas de esteganografía, se pueden obtener resultados bastante más seguros y potentes para ocultar información secreta sin dar indicios de que existe información oculta en nuestros archivos ;)