Tras esta breve introducción, me gustaría repasar algunos de los números de serie que llevamos encima y por los cuales se nos puede identificar y de los que quizás no seamos totalmente conscientes.

Empecemos por cosas que llevamos encima:

• Todos tenemos un DNI (documento nacional de identidad), que evidentemente es nuestro número de serie “administrativo”.
• La tarjeta RFID del metro o del autobús, ya implantada en muchas ciudades, tiene un número único, y la empresa de transportes tiene un histórico de todos los viajes que se han hecho con esa tarjeta, que en algunos casos puedes incluso registrar y por tanto asociar a tu persona.
• La tarjeta de alquiler público de bicicletas (Valenbisi en el caso de Valencia) tiene también un número de serie a través del que sin duda alguna se podrán obtener datos de utilización, trayectos, etc. Estos datos también van asociados a la persona.
• Muchos productos que compramos ya disponen de etiquetas RFID únicas a través de las que identificar al producto de manera única, y en algunos casos como por ejemplo en la ropa, esas etiquetas pueden estar ocultas en el producto de manera que lo utilicemos sin ser conscientes de ello.
• Por supuesto, las tarjetas de crédito con chip (EMV) tienen su propio número de serie, y es evidente que cualquier compra que realicemos (establecimiento, día, hora, etc.) con esa tarjeta se asocia fácilmente a nosotros. Nótese que en algunos casos en los que el vendedor es también el distribuidor (tiendas de ropa como H&M, Zara, Mango, por ejemplo) el vendedor podría ser capaz de asociar el número de serie del producto (si lleva RFID) a la tarjeta y de este modo también a la persona, teniendo un historial completo de las ventas realizadas a esa persona e incluso pudiendo identificarla cada vez que entrase o pasase cerca de un establecimiento. Que eso sea legal o no es otra cuestión.

Pasemos ahora a dispositivos hardware.

• La dirección de la tarjeta de red (MAC) es única, y además se transmite siempre que se accede por la red. Que en determinados casos pueda ser falseada queda fuera del alcance de esta entrada y de la mayor parte de los mortales con acceso a un dispositivo con acceso a red.
• Los dispositivos Bluetooth también disponen de una dirección única por dispositivo y hoy en día casi todos los teléfonos móviles tienen bluetooth… y muchas personas lo llevan activado innecesariamente.
• Las tarjetas de fibra también tienen su propia dirección MAC: el WWN.
• Todos los teléfonos móviles tienen un numero de serie (IMEI) que no puede ser consultado en remoto por los usuarios, pero la operadora sí que lo conoce. Yo por ejemplo soy reacio a donar un móvil, ya que mi identidad esta asociada a ese móvil y desde los atentados del 11M por normativa no se puede vender un teléfono móvil si no se asocia a un DNI y en algún sitio esta escrito que ese móvil es mio.
• Las tarjetas de telefonía también tienen otro numero que puede consultarse remotamente por cualquiera, el IMSI (International Mobile Subscriber Identity number), relacionada con el HLR (Home Location Register).
• Además de todo lo visto, algunos dispositivos llevan grabado su numero de serie de manera electrónica como por ejemplo los iPhone (y muchos otros aparatos).
• Los discos duros y memorias USB tienen un numero de serie, que los identifica de manera única una vez formateadas.

Pero aquí no se acaba la cosa.

• Las primeras versiones de Microsoft Office incluían el numero de licencia del producto, con lo que se podía trazar quien lo había hecho (la licencia es numero único). Posteriormente con las quejas fue eliminado.
• Algunas impresoras y fotocopiadoras graban de manera oculta su numero de serie en unos puntitos amarillos casi invisibles.
• Google Chrome en sus orígenes generaba un numero identificado único para cada navegador, que finalmente por presiones decidió eliminarlo. Como hemos visto en anteriores entradas, el fingerprinting podría considerarse un número de serie, aunque a) no es un valor siempre único y lo más importante, no es algo controlado por un fabricante sino una combinación de variables no controladas.
• Las ultimas cámaras asocian al exif el numero de serie de la cámara, por lo que “pegado” a cada foto va el numero de serie de la cámara y el numero de serie del objetivo. Hay quien utiliza esta información para encontrar en Internet fotos que hayan hecho con su cámara robada, pero también puede ser utilizado para saber quien ha hecho una foto.
• Además, el coche y muchos otros elementos físicos disponen de un número de serie (chasis, matrícula, radio, etc.) sobre los que, aunque seamos más conscientes, no pensamos en que están asociados a nosotros.

Personalmente, cuando voy de casa al trabajo suelo llevar encima los siguientes números de serie:

• Mi DNI, SIP, RFID de tarjeta de Metro.
• Matrícula del coche, número de chasis del coche, dirección MAC del bluetooth del coche.
• Teléfono móvil, con IMEI, MAC de Wifi, MAC de Bluetooth, número de dispositivo de iPhone.
• Portátil con dirección MAC de tarjeta de red, MAC de Wifi, MAC de Bluetooth, y diversos números de serie dentro del software.

Vamos, que sin problemas puedo estar identificado por mas de 20 números únicos, muchos de ellos incluso que se publican por el aire.

Sobre la seguridad de todos estos números, comentar lo siguiente:

• Privacidad: Hay que protegerlos ya que permiten identificar de manera única, dispositivos, sistemas y en el peor de los casos a las personas. ¿Cuanto números de serie llevamos encima? ¿Todos ellos son necesarios por funcionalidad, o son por un excesivo control? ¿La información está protegida suficientemente?
• LOPD: Si de alguna manera permiten identificar de manera única a una persona están sujetos todos estos valores a la LOPD, y en algunos casos este procedimiento puede considerarse no desproporcionado.
• Control de acceso: No hay que utilizar estos números para autorizar permisos de manera exclusiva, ya que estos números pueden ser cambiados: se puede cambiar la MAC de una tarjeta de red, se puede cambiar el WWN de una tarjeta de fibra, se puede cambiar el IMEI de un teléfono, y alguien puede saberse tu numero de DNI (código de seguridad para hacer cualquier tipo de operación en los operadores telefónicos, p.e.). Aunque el número esté grabado por hardware si se transmite se puede cambiar y tampoco sirve de nada.

Así que tras este breve repaso a nuestro particular y personal conjunto de números de serie, sean ustedes precavidos con lo que hacen ya que como ven hay muchos números les pueden delatar.

(N.d.E. La fotografía, de Bill Barker, corresponde al número de serie del motor de un Chevrolet de 1931, previo a la aparición de los VIN (Vehicle Identification Number)).

Según comenta el artículo los actores principales de las ciberguerras son los estados, terroristas y grupos sociopolíticos, y junto a éstos existen actores secundarios que son parásitos o establecen una simbiosis con los actores principales de la ciberguerra. Se plantean varios objetivos para iniciar este tipo de conflictos, como son espionaje y reconocimiento, propaganda y guerra social, deshabilitar la infraestructura Web del gobierno objetivo y atacar infraestructura críticas entre otros. Todas estas amenazas son conocidas y hemos hablado de ellas en varios artículos de blog, de manera directa o indirecta, siendo conscientes del riesgo al que estamos expuestos, por lo menos los que estamos en este sector y vamos viendo día a día cómo van actuando los “malos”.

En una segunda parte del artículo se centra en la recolección de información y el análisis de la misma. Como todos sabemos la información existe y está ahí expuesta, y es el momento de recolectarla y sobretodo de extraerla, analizarla y de relacionar las diferentes fuentes de información. Se que dicho así, suena sencillo, pero es tal el volumen de información en la red, que este uno de los retos de este tiempo.

Sanjay Goel en el artículo diferencia entre “unstructured data”, que son datos de foros de hackers, blogs, sitios web, cuentas de twitter, etcétera, que te ayudan a prevenir un ataque y “network data”, donde se refiere a información de IDSs, darknets, honeypots, firewalls, routers, equipos infectados, etcétera. Añade además que estos dos tipos de fuente deben activarse una a la otra. Es decir, si se observa algo extraño en nuestros “network data”, debemos observar la información que llega de las “unstructured data” y viceversa, lo que resulta evidente.

Como conclusión, me permitirán que me quede con la necesidad de contar con el análisis humano combinado con herramientas semiautomáticas y técnicas avanzadas, imprescindibles para procesar este volumen de información de una diversidad tan elevada. Bajo mi punto de vista llegar a una automatización total es una tarea a día de hoy de lo más compleja, pero automatizar y correlar esta información en la medida de la posible se ha convertido en una necesidad imperiosa.

En definitiva, la información está ahí; “solo” nos queda recopilarla, correlarla, analizarla, predecir acontecimientos futuros, actuar ante acontecimientos actuales, y analizar acontecimientos pasados. Ahí es nada.

Conocíamos la teoría, y sabíamos que potencialmente podría ser muy versátil gracias a su diseño modular, que lo hace escalable y personalizable (comentábamos que estaba formado por Nuggets que podemos crear nosotros mismos) pero hasta que no lo hemos probado no hemos visto qué era capaz de hacer.

La instalación del entorno no es rápida, sin embargo, disponemos de una máquina virtual con todo ya montado, ideal para probar de una manera cómoda el funcionamiento. Tiene instalados los siguientes nuggets: Yara, OfficeCat, ClamAV, Archive Inflate, Scripting, File Inject, Snort, Virus Total (se activa si le proporcionamos una API key) y el PDF Dissector ( solo se activa bajo licencia) y está montada sobre FreeBSD.

Una vez levantada la VM puedes acceder a la interfaz de administración (o de gestión como yo le he llamado, véase la siguiente imagen) desde http://:8080 :

Desde este panel de administración podemos gestionar fácilmente todo el sistema, desde la creación de usuarios, conexiones de red, creación de nuevas interfaces, control de los servicios, estado de los nuggets, ver qué procesos se están ejecutando, comprobar el estado de nuestra CPU, tráfico a través de las interfaces, etc. Por ejemplo, en la siguiente imagen vemos como desde el panel de administración comprobamos que nuggets tenemos funcionando:

También podemos comprobar los servicios:

En el puerto 80 podemos acceder a la interfaz de usuario, en la cual podemos consultar los eventos generados o subir ficheros para que los analice directamente (”Submit Data Block“). A continuación se muestra una imagen de dicha interfaz en la que mostramos el campo Status, para comprobar el estado general del sistema:

Se ha probado por ejemplo a pasarle un fichero comprimido que contenía un ejecutable malicioso y en los eventos generados se puede ver el análisis que se le hace tanto al fichero comprimido como a cada fichero contenido en él alertándonos en que fichero se alojaba el malware.

Para las pruebas que se hicieron, se configuró una nueva interfaz de red en la VM (que se llamó monitorización —ver primera imagen de este post—) de modo que Snort (nuestro nugget collector) monitorizara todo el tráfico que llegara por esa interfaz. Una vez hecho ésto, para probar el funcionamiento se le pasaron varios pcap con malware que se cogieron de este repositorio. Comentar que se hizo con Tcpreplay:

/usr/local/bin/tcpreplay --intf1=em1 file.pcap

De esta forma se inyecta por la interfaz em1 (mi interfaz de monitorización) un fichero file.pcap.

Así, una vez enviado tráfico sobre la interfaz de monitorización puedo observar en la interfaz de usuario, en Events, todas las alertas que me genera ese tráfico, aquí una imagen (cortada porque era un gran listado de eventos):

En la imagen anterior vemos tres eventos a modo de ejemplo, en los dos primeros nos muestra que se han generado alertas (5ª columna). Desplegando, en este mismo panel, los metadatos asociados al evento que tenemos seleccionando nos da la siguiente información:

Pinchando directamente en las alertas generadas nos muestra lo siguiente:

Desplegando la sección de Malware Names, nos saca un listado (incompleto porque se ha acortado para que se viera mejor) de nombres de este tipo de malware:

En líneas generales este sería el funcionamiento básico de Razorback.

Por supuesto está aún en “pañales” y probablemente se le pueda sacar mucho más partido en un futuro del que se ha mostrado en este post, pero nos da una idea de lo que es capaz de hacer y cómo manejarnos a través de los paneles de gestión que incorpora. Tras las breve toma de contacto que se ha tenido con este Framework diríamos que algunas ventajas a tener en cuenta serían que es apropiado para detectar en tiempo real incidentes contra usuarios finales, puedes crear tus propios nuggets, parece interesante para detectar 0-day, detección de tendencias de ataques, interesante a la hora de hacer un análisis forense a un pcap, las interfaces son muy intuitivas… Por otro lado, sus principales inconvenientes serían que está en desarrollo, parece generar falsos positivos y es complicado de montar.

Hace unos días os propusimos un reto sobre esteganografía, en el cual debíais encontrar cual era el videojuego del cual se había realizado una nueva versión. Para esto se proporcionaba un archivo comprimido el cual se creía que tenía información privilegiada sobre este juego.

Al intentar abrir el archivo, se nos pedía una contraseña, la cual sabíamos (gracias a la pista proporcionada en un comentario del reto) que sólo era de caracteres numéricos y de no más de cuatro caracteres, así que necesitábamos obtener esa contraseña.

Para este paso, como sabemos que es una contraseña sencilla, podemos utilizar algún software de recuperación de contraseñas como por ejemplo rarcrack.

Después de un ratito (este ratito depende de la máquina utilizada y el programa elegido, todo hay que decirlo, aunque en este caso se acotaron mucho los caracteres posibles y la longitud para que se obtuviese más rápido) obtendríamos nuestro password, el cual era “4567”, y podríamos abrir el archivo.

Una vez extraemos el contenido del rar, nos encontramos con dos fichero más. Uno con el nombre “juego.txt” y otro con el nombre “final_challenge”.

En “juego.txt” nos encontramos el siguiente contenido:

Así que toca seguir buscando ya que si no efectivamente sería demasiado fácil sí. El otro archivo no tiene extensión y si hacemos un file observamos que es un archivo RAR, pero al intentar abrirlo no muestra ningún archivo. Así que decidimos abrirlo con un editor hexadecimal para ver si efectivamente se corresponde a un archivo .rar. Si nos fijamos en la cabecera, parece que efectivamente sí que se trata de un archivo rar, pero hay un “?” (0×3F) que llama la atención, ya que éste no aparece en la cabecera original de este tipo de ficheros.

Si buscamos en la documentación de los archivos RAR, vemos que en vez de 0×3F, debe ir 0×07, así que procedemos a realizar dicha modificación y ya podemos ver el contenido.

Una vez extraídos los archivos, vemos que hay otros dos nuevos (otra vez), “token” y “codigo_des”. Ninguno de ellos tiene extensión, pero rápidamente vemos que uno de los dos es una imagen PNG y el otro un data:

Si abrimos la imagen, obtenemos un fondo negro con rayas verticales blancas, algo que parece ser un código de barras:

Si intentamos decodificarlo, vemos que no obtenemos ningún resultado, así que procedemos a realizar un pequeño análisis manual de la imagen. A simple vista, en la imagen sólo observamos dos colores, pero si la abrimos con GIMP por ejemplo, observamos que en realidad existen tres colores distintos.

Esto quiere decir que hay un tercer color, el cual nosotros no vemos, pero que existe en la imagen. Como se sabe, cada color puede tener diferentes tonalidades, desde el valor 0 (negro) hasta el 255 (blanco), pero el ojo humano no es capaz de diferenciar todos ellos, así que esto debe ser lo que sucede en este caso. Para poder ver este color, podemos utilizar GIMP de nuevo y seleccionar el color blanco con un umbral de 0. Al hacer esto, observamos que existen tres barras más en la imagen que están de color negro, pero que no se han seleccionado con nuestra selección, lo cual quiere decir que es un negro diferente (¡!).

Si procedemos a pintar estas barras de blanco, obtenemos un nuevo código de barras, el cual sigue sin tener significado. Si nos fijamos bien, es un código de barras un tanto extraño, ya que normalmente las barras negras son las que indican la información, pero en este caso son barras blancas. Partiendo de esto, invertimos los colores de la imagen y vemos que ahora sí que se parece más a un código de barras de “toda la vida”, y está vez sí que tiene significado. Concretamente “p4ssw0rDd3s”.

Una vez hemos acabado con este archivo, analizamos el código hexadecimal del siguiente archivo para intentar descubrir de qué tipo es. Fijándonos en la cabecera podemos ver que se corresponde a un archivo cifrado con OpenSSL, pero para aquellos que nunca hubiesen trabajado con este tipo de archivos, se puso una pista en la imagen anterior, ya que si la abríamos con un editor hexadecimal, podíamos ver al final de todo “0p3nSSL rUl3S!”, lo cual nos mencionaba dicho programa.

Como todos sabemos para descifrar un archivo cifrado es necesaria una contraseña. En este caso, no disponemos de esa contraseña, pero hemos obtenido del código de barras anterior la palabra “p4ssw0rDd3s”, la cual encaja bastante con lo que estamos buscando en este momento. Así que vamos a ello.

Al ejecutar OpenSSL vemos que puede utilizar diferentes algoritmos de encriptación, pero si nos fijamos en el nombre de la imagen “codigo_des” y en el password obtenido “ p4ssw0rDd3s”, vemos que aparece la palabra “des”, la cual pertenece a un algoritmo utilizado por OpenSSL (Mira tú por donde…). Así que parece ser que todas nuestras piezas encajan y por fin podemos obtener el contenido del fichero “token”.

Escribimos la orden de OpenSSL para descifrar el archivo y probamos suerte:

Vemos que no obtenemos ningún error y que en nuestro directorio ha aparecido un nuevo archivo, el cual corresponde a una imagen. Así que la abrimos y obtenemos lo siguiente:

La cual nos indica que hemos llegado al final del reto, ya que la respuesta del famoso juego esperado es “SUPER MARIO BROS”. Así que hasta aquí la solución del reto propuesto.

Esperamos que haya sido de vuestro agrado y a aquellos que lo hayáis conseguido, felicidades, y a los que no, espero que al menos hayáis aprendido un poco más sobre algunas técnicas de esteganografía y de los usos que se pueden dar de ella a la hora de esconder información.

Como mención destacada, comentar que tan sólo unas horas tras la publicación del reto, recibíamos la primera respuesta correcta de Kachakil, quien está más que experimentado en este tipo de retos :)

En el sistema propuesto, el terminal dispone de un modo de funcionamiento privado donde este envía una petición PER (Privacy Enabling Registration) a la red del operador; dicha petición consiste en un mensaje de certificación que valida al usuario y un valor aleatorio denominado RET (Random Equipment Tag), que se incluirá en los registros VLR (Visitor Location Register) y HLR (Home Location Register) del operador, los cuales permiten enrutar y mantener las llamadas, pero sin asociarlos a un usuario determinado (los siguientes mensajes de registro incluyen peticiones PET en lugar del número de télefono).

En España, la Ley de conservación de datos relativos a las comunicaciones electrónicas y a las redes públicas de comunicaciones (Ley 25/2007 de 18 de octubre) indica que los operadores de telefonía móvil con servicios prepago deberán registrar la identidad de los clientes que acceden a la red. Aparte de esta ley, cada vez es más habitual que la privacidad y el anonimato en la red se muestren como una problemática real, y ya comienzan a aparecer servicios de Internet integrados con sistemas de identificación como el DNI electrónico, como por ejemplo ha hecho Tuenti recientemente.

Sin entrar en detalles técnicos que seguro que hay muchos que se me escapan y a la vista de un entorno legislativo y político cada vez más preocupado por trazar y registrar todo tipo de comunicaciones, ¿piensan que un sistema así podría ser factible? Y desde otro punto de vista, ¿es necesario o deseable?

La posibilidad de que ataques cibernéticos afecten al normal funcionamiento de infraestructuras claves para el sostenimiento de las sociedades modernas es una causa creciente de preocupación entre todos los agentes implicados. Prueba de ello son los recientes desarrollos normativos que están teniendo lugar y que en nuestro país se sustancian en la Ley de Protección de Infraestructuras Críticas y el Reglamento que la desarrolla.

Una de las características del temor que produce esta amenaza proviene del hecho de que no sigue una de las reglas establecidas de los enfrentamientos a que la sociedad está acostumbrada: identificar al enemigo. En efecto, hasta este momento los ataques contra una sociedad se producían en el contexto de una guerra o un ataque terrorista. El enemigo, por tanto, era conocido (incluso en el caso de ataques terroristas, ya que estas acciones buscan que la parte atacada sepa quién infringe el daño). Ahora, sin embargo, se toma conciencia de que elementos claves de una sociedad pueden ser atacados inadvertidamente y por un enemigo sin rostro, del cual, además, se desconocen sus motivaciones y por tanto no podemos prever su forma de actuar. Incluso se nos puede atacar de forma remota sin necesidad de encontrase físicamente entre nosotros.

Sin embargo, por muy novedoso que nos pueda resultar esto, en una fecha tan temprana como 1961, mucho antes de los ordenadores personales y las redes de comunicación, ya se previó que una eventualidad como ésta se podría producir. Hablamos de A por Andrómeda, una serie de televisión de la BBC que posteriormente se trasladó a novela, escrita por Fred Hoyle (físico especialista en cosmología) y John Elliot (productor de televisión).

¿Y cómo tenía lugar un ataque de este estilo en la infancia de las TIC? Avancemos el argumento aunque sin revelar el final, por si alguien siente interés en acudir a las fuentes por sí mismo.

En el radiotelescopio más avanzado del mundo, recién construido en Inglaterra, se recibe de pronto una señal cíclica procedente de un punto del cielo en la constelación de Andrómeda. Tras descartar un origen terrestre o incluso un satélite artificial (el Sputnik I se lanzó en 1957 y en 1961 el total de artefactos en órbita se podían contar con los dedos de una mano) los científicos responsables llegan a la conclusión de que se trata de una señal de origen genuinamente extraterrestre. Tras realizar un análisis del mensaje con los medios informáticos de la época (toneladas de equipo a base de válvulas y cables con interfaz por medio de tarjetas perforadas) se concluye que éste consta de tres partes: la primera son las instrucciones para construir un computador de potencia desconocida en la Tierra, la segunda parte es el programa que se ejecutará en ese computador y la tercera los datos sobre los que el programa debe trabajar.

Con toda la parafernalia de secretismo, instalaciones militares, etc. habituales se lleva a cabo la construcción y puesta en marcha del supercomputador (que naturalmente necesita un edificio completo para alojarlo y cuya sala de control se encuentra en el interior de la propia máquina). Y sin embargo, tan pronto se comienza a proporcionar datos a la máquina y recibir sus respuestas John Fleming, el investigador principal, siente que el supercomputador tiene un interés propio, representando la voluntad de los emisores de la señal desde un lugar tan remoto como desconocido…La máquina ejecuta un programa con un fin ignoto mientras los científicos proporcionan los recursos físicos que va demandando. En ese momento Fleming toma conciencia de que posiblemente se enfrentan a un dispositivo destinado a tomar el control de la Humanidad.

La serie/novela avanza interesantes cuestiones relativas a la inteligencia artificial, computadores, ataques cibernéticos y guerra biológica a pesar de que la materialización de la tecnología pueda resultarnos actualmente absolutamente arcaica. De hecho, posiblemente sea la primera descripción detallada de un ataque deliberado mediantes medios cibernéticos, a distancia y sin conciencia de peligro por la parte atacada. Y es que, realmente, no hay nada nuevo bajo el sol…

Una nota final para los interesados. Lamentablemente sólo se conserva uno de los episodios de la serie original y no existen ediciones actuales en castellano por lo que, si queréis conocer el resto de la historia, deberéis recurrir a una de las versiones en inglés que se hicieron posteriormente o leer el libro “A for Andromeda” (Amazon).

Parece un mal endémico del personal técnico el no tener una buena capacidad de redacción y síntesis; podemos hablar sobre multitud de conceptos técnicos, utilizando una infinitud de palabras en inglés pero parece que no seamos capaces de sintentizar y trasladar a un lenguaje más coloquial un incidente de seguridad que hayamos detectado.

Repasando un documento de ENISA sobre ejercicios para la gente de un CERT, revisé el que habla del contacto con terceros para la notificación de un incidente. En este ejercicio se practica la forma en que se avisa a los interesados de algo que ha ocurrido, cuáles han sido las posibles consecuencias y qué deseamos que hagan para solucionarlo.

Esto que parece tan simple, en ocasiones se convierte en un correo electrónico con un texto “copy-pasteado” hecho con retales de otros correos, con información sin aclarar muy bien de dónde sale o qué representa y con unas instrucciones un poco vagas. Por esto, quería recoger las ideas que propone ENISA para la redacción de una buena notificación.

Por mi experiencia, el correo debe ser breve y conciso en lo que se desea transmitir, y ajustarse al perfil del destinatario del correo, normalmente personal técnico pero sin grandes conocimientos de seguridad, para que este correo no genere rechazo.

Lo primero de todo es presentarse. En un par de líneas, debemos decir quiénes somos. Este paso tendrá que omitirse si ya nos conocen porque no queremos resultar repetitivos ni queremos que se vea nuestro correo como algo automático que redactamos sin pensar. No podemos dejar que la información empiece en el tercer o cuarto párrafo, que es lo que realmente queremos transmitir del incidente.

Lo segundo es una descripción clara de lo que ha ocurrido. Debemos dejar de lado los tecnicismos, las definiciones extensas o referencias a otros sitios. “Ha recibido un ataque al servidor web tal desde tal, cuyas consecuencias han sido/han podido ser…” sería una forma aceptable. Pensadlo un momento. A un responsable de departamento le dará igual si ha sido una inyección SQL en el parámetro id del recurso vulnerable.php, poniendo nosequé cosa o si se trata de un RFI apuntando a un servidor de Rusia o Botswana. Esto puede ir más adelante, pero no en este momento, donde queremos transmitirle lo que ha ocurrido y el impacto que haya podido tener. Debemos evitar extendernos demasiado. También facilitará la lectura y evitará que confundamos al receptor. Un párrafo únicamente a modo de resumen ejecutivo será más que suficiente.

Ahora las evidencias. Una vez ha comprendido lo que ha ocurrido, podemos explicarle el cómo. Ya podemos nombrar qué técnica o herramienta se ha utilizado o qué vulnerabilidad ha sido explotada; podemos hablar de siglas y aportar cuantas evidencias tengamos de nuestros registros de cortafuegos, IDS o cualquier sistema de monitorización que ayude a entender técnicamente lo ocurrido. Qué impacto y consecuencias ha podido tener, por qué ha ocurrido ahora (algún servidor desactualizado, por ejemplo); pero tampoco sin llegar a aburrir. Ofrecer la mayor información posible no significa aportar la mayor cantidad de datos. Copiar una captura del registro de alertas del IDS repetidas, aunque sea una docena, no aporta nada y puede causar un efecto disuasorio. Si tenemos más datos, se puede entregar como adjunto pero las evidencias técnicas deben ser las mínimas necesarias para comprender el alcance y su impacto. En un par de párrafos con referencias a los archivos adjuntos podemos dejarlo claro.

Por último, tenemos las acciones que queremos que tomen. Quizá sea necesario que nos aporten más información para conocer el alcance o efectividad del incidente; o quizá queramos que reinstalen un sistema por completo, pero debe quedar lo más claro posible aquello que queremos que hagan. Hay que evitar ambigüedades o acciones poco precisas, teniendo en cuenta que quizá no tengan muchos conocimientos de seguridad. También hay que dejarles a ellos un poco de margen de maniobra, ya que ellos conocerán mejor que nadie sus sistemas y qué acciones pueden ser las mejores, pero habrá que asegurarse de que hayan comprendido el problema y cómo solucionarlo.

Un vez hemos transmitido el mensaje que queríamos debemos despedirnos con información sobre nosotros mismos. Se debe incluir un pie de firma con los datos de contacto y firmar digitalmente el correo. Siempre se habla de la poca seguridad de los correos y debemos transmitir una imagen de profesionalidad, utilizando firmas que certifiquen la autenticidad y la integridad del mensaje. Si enviamos información confidencial, deberemos cifrar el mensaje con un mecanismo acordado previamente entre las partes.

Como conclusión, quiero remarcar que los correos deben ser concisos y aportar la mayor información sin parecer un correo automático o una captura de un log del sistema, ya que estos crean poco interés en el receptor y puede que se le dé menos importancia de la que tenga en realidad. Utilizar un lenguaje entendible por personas con poco conocimiento en seguridad y huir de texto pegado de registros de sistemas. Esto último puede ir en archivos adjuntos.

Se debe transmitir la importancia en este primer correo y, si fuera necesario, enviar tantos correos como nos solicite el destinatario para aclararle sus dudas, pero que no caigan en saco roto por parecer siempre iguales.

Se trata de programas para generar pequeños virus que una vez infectan un equipo permiten controlar remotamente el ordenador de la víctima permitiendo robar contraseñas, hacen las funciones de keylogger, pueden cargar o descargar ficheros, matar procesos, gastar bromas, grabar webcams, ver escritorios remotos, etc.

Su popularidad vino motivada en gran parte por su facilidad de uso ya que no son necesarios conocimientos avanzados de informática más allá de saber algo de inglés, saber que es una IP y poco más, lo cual provocó que muchos script kiddies se lanzaran a la caza de equipos para infectar. A pesar de su sencillez de uso los usuarios medios pueden llegar a conseguir un parque de equipos infectados decente y usable ya que disponen de opciones avanzadas como la gestión de equipos infectados desde IRC, ocultar el proceso en otros procesos o servicios del sistema, o camuflar el fichero ejecutable dentro de fotos o ficheros ofimáticos.

Por suerte los RAT no utilizan técnicas novedosas de infección por lo que sigue siendo necesario que el usuario ejecute un fichero para quedar infectado así que la mayoría de antivirus nos protegerán de este tipo de software, especialmente de los más conocidos, aunque como siempre, la mejor defensa contra los virus seguirá siendo el sentido común y sospechar de ficheros poco fiables.

Estos programas o virus se han visto obligados a evolucionar en el tiempo para adaptarse a las sucesivas versiones de Windows, principal plataforma que explotan, aunque tras hacer ligeras adaptaciones para funcionar en Windows 7 (con algunas limitaciones) parece que muchos desarrolladores han abandonado su mantenimiento. Desconocemos si este abandono se debe a la dificultad para ejecutarse en equipos con el control de cuentas de usuario, la llegada de Windows Defender para proteger a los incautos sin antivirus, o a que los desarrolladores han perdido el interés, pero el caso es que es complicado que veamos nuevas versiones de grandes glorias como SubSeven, Poison Ivy, o Bifrost, si bien han surgido algunos proyectos interesantes como Flu.

Para los curiosos que nunca hubiesen oído hablar de estos programas os invitamos a descargarlos y probarlos ya que son cuanto menos curiosos y se pueden utilizar incluso para escarmentar a algún usuario descuidado. Eso sí, probarlo en entornos lo más aislados y controlados posibles (máquinas virtuales, equipos de prueba, etc…) ya que a fin de cuentas estaréis infectando vuestros propios equipos con un software que no sabemos a ciencia cierta qué hace.

Solo queda pues esperar a ver si realmente es un “género muerto” o si el tema está en letargo a la espera de volver a florecer en nuevos sistemas operativos o incluso dispositivos.

Hace algo más de un año, en Security Art Work se habló sobre la esteganografía y algunos de los métodos utilizados en esta disciplina (entradas una, dos y tres).

Con el artículo de hoy toca rememorar este tema, ya que tal y como está últimamente todo el tema de la privacidad con leyes como PIPA y SOPA, uno se puede preguntar si nos veremos “obligados” a tener que comunicar cierta información mediante técnicas más elaboradas de cifrado. ¿Podría ser la esteganografía una de ellas?

Esta vez no vamos a publicar un escrito ampliando la información ya dada. En vez de esto, proponemos un reto para aquellos que queráis dedicarle algo de tiempo e intentar resolverlo. Con los anteriores artículos se puede tener un conocimiento de algunas de las técnicas que pueden ser usadas en la esteganografía, pero como el propio título dice, es solo una introducción, así que: ¿qué mejor manera de aprender y practicar todo esto que con un reto?

Para este reto, partimos del siguiente escenario: hemos obtenido un archivo de una compañía de videojuegos, de la cual se rumorea que se ha realizado una nueva versión de un juego ya conocido. Ciertas personas aseguran que este archivo (ver adjunto debajo) contiene información ultra secreta referente a ello. ¿Seríais capaces de decir de qué juego están hablando estos rumores?

La solución del reto la publicaremos dentro de una semana, así que aquellos que lo intentéis y no lo consigáis, o simplemente aquellos que tengáis curiosidad, estad atentos al blog ;)

Archivo: NewEnd.
MD5: 134c4aa557833d650822e679670d1957

¿De qué trata este evento?

El día de Protección de Datos en Europa es una jornada que tiene como objetivo de promover el conocimiento entre los ciudadanos acerca de cuáles son sus derechos y responsabilidades en materia de protección de datos. Esta jornada está respaldada por las autoridades de Protección de Datos de los estados miembros de la Unión Europea (por ejemplo, la AEPD), el Consejo de Europa y la Comisión Europea.

¿Por qué se celebra el día 28 de enero?

El Comité de Ministros del Consejo de Europa eligió esta fecha para conmemorar el aniversario de la firma del Convenio 108 del Consejo de Europa para la protección de personas con respecto al tratamiento automatizado de datos de carácter personal. Dicho convenio se firmó el 28 de enero de 1981 y establece las bases para la protección de datos en Europa.

¿Qué podemos esperar de estas jornadas?

Tal y como hemos comentado, el objetivo es informar a todos los ciudadanos sobre sus derechos y responsabilidades en materia de protección de datos. Desde mi punto de vista se trata de una cuestión importante que nos afecta a todos. En principio es previsible que a título individual poco o nada podemos hacer que tenga repercusión sobre el marco regulatorio actual. Pero esto no es del todo cierto. Vivimos en un contexto muy cambiante en el que las leyes parecen quedarse obsoletas de hoy para mañana. En mi opinión, la adaptación del marco legal debe contar con la participación de todos los interesados (y afectados) es decir, de todos nosotros.

Sin ir más lejos, el pasado 28 de diciembre la AEPD abrió una consulta pública para conocer la opinión y experiencia de prestadores de servicios, usuarios y expertos sobre Computación en Nube.

¿Cómo participar?

La seguridad de la información en general y la protección de datos en particular no son cuestiones puntuales para tener en cuenta un día y dejarse de lado el siguiente. Aún teniendo esto en cuenta, se pretende impulsar y difundir la importancia de estos temas promocionando el día de la Protección de Datos.

La AEPD ha puesto a disposición de los usuarios material gráfico (banners) para que todos aquellos organismos, entidades, asociaciones o particulares que así lo deseen puedan incluir en sus páginas web un elemento para apoyar la difusión del Día de la Protección de Datos.

Nos despedimos respaldando esta iniciativa desde Security Art Work y les deseamos que pasen un buen fin de semana.