Security Art Work

A estas alturas, muchos de ustedes sabrán (y pudieron comprobar en tiempo real) que el pasado martes a eso del mediodía Twitter era colapsado por un bug en su propia página web que permitía, explotando una vulnerabilidad XSS en la gestión del evento “onmouseover”, la ejecución de código javascript a través de tweets diseñados para ese objetivo. El código inyectado en el tweet sería del tipo:

El ataque provocaba desde un pop-up “inofensivo” con un comando javascript tipo “onmouseover=”javascript:alert(‘Hola!’);” que generaba una ventana emergente con el mensaje “Hola” a todos los followers en cuyo “timeline” estuviera el tweet manipulado, hasta la aparición de cuadros en negro donde debería estar el texto del tweet, pasando por letras gigantes ocupando toda la pantalla, o la redirección del perfil del usuario a cualquier otra web. Por ejemplo, un tweet del tipo:

[Read more…]

Estos días, tras la vuelta de vacaciones, volví a poner en marcha mi viejo receptor de onda corta, junto al que tantas noches pasé cuando era joven :) ¿El motivo? Simple curiosidad: quería ver si la actividad de estas bandas de radio seguía siendo tan interesante como hace quince o veinte años, cuando podías escuchar desde VOA (Voice of America) o REE (Radio Exterior de España) hasta Radio Teherán -esta última con un buen número de interferencias, posiblemente provocadas-, pasando por emisoras de pequeños grupos religiosos estadounidenses y sudamericanos o la todopoderosa Radio Vaticana -con unas antenas cuyo tamaño deja pequeña a cualquier torre de alta tensión que podamos imaginar-. Tras la recepción, el escucha enviaba un informe de recepción y a las semanas recibía una tarjeta QSL junto a folletos informativos de la emisora, con horarios, frecuencias, etc. en cualquier idioma y, en algunos casos, incluso propaganda “política” de un régimen más o menos cerrado.

Efectivamente, pude comprobar que la actividad en onda corta sigue siendo ajetreada, con las grandes emisoras oficiales de todos los países emitiendo junto a pequeñas estaciones, posiblemente piratas, que transmiten desde algún punto indeterminado del mundo; pero sin duda lo que más me llamó la atención es que, como antaño, todavía siguen emitiendo las number stations. Las estaciones de números son emisoras que se limitan a transmitir códigos formados por letras o números, tanto en voz (habitualmente digitalizada) como en Morse, de una forma continua y monótona durante la emisión, que suele durar menos de una hora y que por supuesto en ningún momento identifica la emisora; la emisión comienza con unos minutos de llamada, tras los cuales (en ocasiones existe algún tipo de encabezamiento tras la llamada inicial) se comienza a transmitir una retahíla de números o letras en grupos cortos y con una pausa entre sí, para acabar después con algún código que indique el final de transmisión. Una vez alcanzado dicho final, la frecuencia utilizada queda vacía. Raro, ¿verdad?

Efectivamente, las emisiones de las estaciones de números son cuanto menos extrañas; no está muy claro su origen, y se suele especular con radiobalizas, transmisiones meteorológicas y mil cosas más. Pero la hipótesis más arraigada entre todos los escuchas es la de que estas emisiones son mensajes cifrados de las agencias de inteligencia a sus espías desplazados en otros países, y esta hipótesis cobra fuerza tanto por casos de espionaje que han llegado a los tribunales (en los que se ha demostrado el uso de la onda corta para envío de información cifrada) como por el hermetismo que las agencias tienen al respecto (si estas emisiones fueran pruebas de la BBC, dudo que hubiera tanto mutismo envolviéndolas).

En estos días de Twitter, Blackberries, Facebook, 3G y mil cosas más, parece que las agencias de inteligencia siguen enviando mensajes cifrados por el canal más público que existe: el aire. Pensémoslo bien: con un pequeño receptor de onda corta, un espía ubicado en medio del desierto puede recibir el mensaje, descifrarlo y actuar en consecuencia, sin necesidad de ningún equipamiento de alta tecnología (que en muchos países llamaría la atención y podría poner en peligro la vida del agente), de conexión a Internet o de un móvil tribanda: sólo con un lápiz y un papel. Sencillo, ¿verdad… o no? Quizás los servicios secretos las utilicen como medio alternativo cuando no existe otra posibilidad, como entrenamiento de agentes en situaciones simuladas o, simplemente, como elemento que introduce ruido en el enemigo (mientras dedica recursos a tratar de descifrar mensajes radiados sin sentido, no los dedica a intervenir otros canales).

Si las estaciones de números se usan de verdad para transmitir mensajes cifrados a los espías, más allá de discusiones criptográficas encontramos dos problemas claros en esta técnica. El primero de ellos es obviamente la unidireccionalidad de la información: puedo transmitir instrucciones a las personas desplazadas en una zona, pero si esas personas quieren comunicarse conmigo tendrán que utilizar otro medio, salvo que estén en algún sitio donde un equipo emisor de onda corta no levante sospechas :) El segundo gran problema relativo a las number stations es la correlación: quizás no pueda descifrar el mensaje concreto, pero si una emisora transmite mucho más de lo que es normal en ella, más rápido o con algo que diferencie una emisión de las demás, puedo llegar a determinar que algo pasa o va a pasar. De esto último se cuida muy mucho quien sea que emita, y de ahí que el tono monótono y pausado de las estaciones de números sea lo primero que nos hace abandonar la escucha que hemos iniciado por simple curiosidad (aunque dicen las malas lenguas que algunas estaciones rusas transmitían como locas cuando, en agosto de 1991, se produjo un intento de golpe de estado en la antigua URSS).

En definitiva, el objetivo de las number stations sigue siendo algo misterioso en nuestros días, relacionado aparentemente con los servicios de inteligencia y que tras muchos años de actividad siguen operativas: ahí están y cualquiera las puede oir. Si alguno se aburre, puede comprar un receptor -los hay de cualquier precio, y para recibir estas transmisiones no necesitamos ninguna maravilla de equipo- y pasar el rato buscando estaciones de números; es más, puede entretenerse tratando de descifrar el mensaje: todos los que hemos sido radioaficionados o radioescuchas lo hemos intentado alguna vez y dudo que ninguno de nosotros haya tenido éxito… pero para todo hay una primera vez :)

La respuesta habitual de muchos responsables de informática (de informática sí, pero no demasiado responsables) frente a la seguridad es que no tienen que preocuparse en exceso ya que según ellos, su organización no es objetivo de ataque de nadie y por lo tanto se sienten tranquilos respecto a la seguridad de sus servidores.

Obviamente, si eres un banco está claro que eres un objetivo de ataque, ya que albergas dinero, y si alguien consigue realizar una intrusión, obtiene un beneficio económico directo. Si eres un comercio online, a través de éste se puede llegar a disponer de datos de tarjetas bancarias, lo cual también se traslada en dinero. Este tipo de organizaciones ya tienen en su cabeza que son objetivo directo de ataque, y normalmente están al tanto de la seguridad de sus servidores expuestos a Internet.

Pero, si no soy ninguna de estas cosas, porque me dedico a la fabricación artesana de tornillos, ¿soy objetivo de ataque? Pues sí. Usted puede tener enemigos, empleados o ex-empleados disgustados, la competencia (poco ética), proveedores, o clientes que por alguna razón estén disgustados y tengan un particular sentido de la justicia. Pero en fin, usted puede pensar que no estamos en ninguno de estos casos; no tiene empleados o desempleados descontentos, sus clientes y proveedores (y todos sus empleados) le tienen en alta estima, su competencia juega limpio, y además, se lleva usted bien con todo el mundo.

Entonces, ¿por qué me van a atacar a mi, si no le importamos a nadie y nadie nos tiene manía? ¿Quién puede querer perjudicar a mi organización, que no ha roto un plato?

Pues mucha gente; es lo que tiene Internet. Pero, de nuevo: ¿por qué? Pues dejando aparte que su organización muy probablemente maneja dinero, es muy sencillo. Sus servidores disponen de potencia de calculo, almacenamiento, conexión a Internet, y reciben visitas de clientes o usuarios, recursos todos ellos sumamente interesantes para los atacantes; en su mayor parte, quizá no se enfrente a ataques en los que su organización sea el objetivo final, pero sí será víctima de ataques cuyo objetivo es un pez más grande. Pongamos algunos ejemplos de intrusiones, o explotación de vulnerabilidades habituales en Internet:

• Servidor de correo: Si su servidor de correo está (incorrectamente) configurado para permitir el reenvío de correos de terceros sin autorización, será cuestión de minutos que algún spammer le utilice para desde tu servidor se envíen correos no deseados a medio mundo. Quizá no lo considere un ataque, cuando se vea incluido en listas negras de servidores de correo y los servidores de sus clientes y proveedores le devuelvan los correos, verá que la cosa no tiene demasiada gracia. Sin mencionar la posibilidad de que su servidor de correo sea saturado o le provoquen un DoS.
• Uso del ancho de banda: Aunque puede no considerarlo un ataque en el sentido más estricto del término (usted no es el atacado), pueden utilizar sus servidores para provocar una denegación de servicio a un tercero, lo que evidentemente influirá en su conectividad y por ejemplo, la disponibilidad de los servicios que ofrece a través de esa línea de Internet.
• Uso de sus visitas licitas y reputación para redirigir a sus clientes a páginas maliciosas, con virus y troyanos; existen virus y gusanos cuyo ataque se basa en ese propósito. Asimismo, un problema de Cross Site Scripting, de poca relevancia técnica para sus sistemas, puede tener como objetivo incrustar una página web remota con virus y troyanos en su frontal web, con lo que todos los visitantes de éste no suficientemente protegidos serán infectados con el malware. Imagine las consecuencias reputacionales.
• Uso de un servidor para albergar una pagina de phising, de modo que un servidor de su organización albergue una copia de la página del banco XYZ.
• Uso de la CPU de los ordenadores y servidores locales para romper contraseñas por fuerza bruta.
• Uso de los servidores para colocar Bots de IRC, con el objetivo de poder llevar a cabo comunicaciones de manera anónima y secreta. Es habitual encontrarse este tipo de artefactos, y en mi vida profesional el mayor numero de intrusiones ha sido con este cometido.
• Uso de los servidores para albergar contenidos ilegales, con los posibles problemas que pueden implicar: desde programas pirata, películas, o música, hasta mucho cosas peores.
• Uso de tu servidor como anonimizador de otros ataques, con lo que los atacantes evitan que se localice su IP origen. Esto le puede meter en un lío legal de cuidado. Además de ello es habitual que una vez atacado el site remoto que era el objetivo final, para evitar dejar rastros formateen completamente el servidor intermedio.
• Robo de publicidad: Si su organización dispone de banners publicitarios, un ataque reciente se dedica a cambiar la cuenta de publicidad “oficial” por la del atacante para conseguir llevarse los ingresos.
• Conseguir enlaces o referencias a otro site (esto es otra especie de spam: webspam) para posicionarse bien en los buscadores (SEO). Este tipo de enlaces hay incluso quien los vende.
• Uso combinado de un sniffer para obtener cuentas de usuarios de su organización: cuentas ftp, cuentas de shell y cuentas de correo electrónico, capturadas y utilizadas por numerosos robots y malware, sin ser en absoluto ataques dirigidos contra su organización, pero de los que es víctima.

Esta lista de posibles ataques es sólo una pequeña muestra de lo que he visto en alguna ocasión, pero no le quepa duda de que los atacantes tienen otras muchas “ideas” para utilizar sus servidores, sin que se trate un ataque dirigido en especifico a su organización. Así pues, tenga usted cuidado ya que cualquier servidor de Internet es objetivo de ataque; hay muchas razones para que le ataquen, y muy probablemente en estos momentos le estén atacando. Sea prudente y no infravalore a los criminales.

Mañana es lunes cinco de diciembre de 2060 y cumplo 85 años, por lo que tras la reforma laboral de 2028 al fin puedo jubilarme… por tanto, aunque seguiré participando de vez en cuando en el blog, quería preparar un post recopilatorio de todo lo que hemos ido viendo y sufriendo durante todos estos años que hemos pasado juntos. Ha llovido mucho desde 2007, cuando empezamos con SecurityArtWork y, como siempre decimos, la seguridad cambia no de año en año, sino de segundo en segundo, tanto para bien como para mal… por lo que con 53 años a nuestras espaldas, nos podemos permitir el lujo de recapitular un poquito.

¿Quién no recuerda, por ejemplo, cuando existían ejércitos que peleaban entre sí en el campo de batalla, por tierra, mar y aire? Algo inimaginable hoy en día, pero que hasta bien entrado el siglo era lo habitual; en lugar de utilizar a fondo la ciberguerra, los países desplazaban enormes cantidades de personas y armamento para conseguir algo que tenían a un clic de distancia, con todo lo que eso implicaba (costes, riesgos, etc.). Actualmente nos parece primitivo, pero os aseguro que hasta hace unos años no era tan raro; es más, cuando hablablas de protección frente a ataques “diferentes” de paises enemigos te miraban mal, hasta aquel gran atentado que hubo sobre 2020, en el que casi se hunde a una gran potencia mediante el bloqueo de su sistema eléctrico, la interrupción de sus comunicaciones y la apertura de las presas más importantes (¿cómo era aquello, SCADA se llamaba?).

Pero sin duda, lo que más entradas y comentarios en este blog ha generado durante este tiempo fue la imposición de los tags RFID subcutáneos, allá por 2045. ¿Os acordais de toda aquella polémica? Menos mal que los gobiernos tenían todo bien atado, ya que con la proliferación de las redes sociales que se produjo a principios de siglo era fácil identificar y neutralizar a los elementos perturbadores, y al final la cosa no fue a más… cuatro críticas en favor de la privacidad y asunto olvidado, y la verdad es que, con el paso del tiempo, a día de hoy es algo que se agradece… ¿o no nos gusta a todos llegar al super y encontrar directamente ofertas personalizadas para nosotros (o mejor, no llegar al super, sino que el super directamente nos envíe a casa lo que sabe que nos hace falta)? ¿y qué quereis que os diga de la localización geográfica mediante estos tags? No sé cómo podíamos vivir antes sin saber dónde estaban nuestros amigos o familiares en cada momento… Además, otra ventaja de RFID es que ha dejado de llegarnos spam; ahora le llamamos publicidad dirigida y no llega por correo electrónico (que los más jóvenes no sabrán ni lo que es), sino directamente a nuestros tags personales gracias a las enormes antenas que todos tenemos en nuestras calles y que nos envían la información que alguien sabe que necesitamos

También nos reímos un rato con esas casas inteligentes que nos vendían como rosquillas a finales de los años 20, y que al principio no resultaron tan inteligentes como sus diseñadores creían. Y es que tener una persiana, unas luces o un electródoméstico conectados a Internet 3.0 parecía interesante, pero introducía más problemas que ventajas… y si no, que se lo digan a todos los que llegaron a casa tras unas vacaciones de verano, con 55 grados en las calles -maldito cambio climático-, y descubrieron que alguien les había encendido la calefacción desde China y necesitaban oxígeno para respirar en el salón, o que su nevera había encargado cinco toneladas de arroz por una feature no documentada de Windows 2025… ¡qué gran negocio para las empresas de seguridad… y para los supermercados! :)

¿Y os acordais cuando derogaron la LOPD? Total, en la práctica muy pocos la cumplían, gracias a aquello que nos vendieron -ya ha llovido- como “la nube”. Esa nube que al final se convirtió en nubarrón, porque a cambio de un reproductor MP4 no tuvimos problema en dejar todos nuestros datos en ella, accesibles a empresas de cualquier punto del mundo, y así nos fue… ¿Datos de carácter personal? ¿Yesoqués? Con lo que se llamó la globalización y temas similares, muchas leyes nacionales dejaron de tener sentido y se empezó a trabajar en una legislación internacional equivalente para todos y, sobre todo, efectiva. De esto hace ya bastantes años, y en ello siguen (y seguirán).

Pero por supuesto, no todo han sido cambios durante estos largos años: hay cosas que se mantienen casi como el primer día; y si no, fijaos en la Sociedad Global de Autores Digitales, la SGAD -antes tenía otro nombre que no recuerdo-, que aunque ha variado un poco desde principios de siglo -en aquél entonces no cobraban el canon de nacimiento, quizás porque los niños tarareaban canciones sin derechos de autor- en esencia sigue manteniéndose casi como entonces… antes perseguían el P2P y ahora persiguen el intercambio de archivos a través de los dispositivos humanos de almacenamiento (HSD), esos que podemos conectar a nuestro cuerpo simplemente acariciando su interfaz táctil y que nos permiten no sólo ampliar nuestra memoria, sino compartir conocimiento -y otras cosas- con los demás.

En resumidas cuentas, finalizar una etapa siempre produce nostalgia; ayer tuve que explicarle a mi nieto lo que era un libro, y sólo acerté a decirle que es parecido al resultado de imprimir en papel un archivo de unos cuantos K. ¡Y no veais lo que me costó explicarle lo que era el papel, ahora que ya no tenemos árboles! Al final, las dichosas gafas de realidad virtual personalizadas que se pusieron tan de moda hace unos años nos han hecho perder hasta las impresoras…

Tal como vimos en la anterior entrada, una forma sencilla de evadir el motor de reglas es emplear distintas codificaciones para intentar que el ataque no coincida con el patrón buscado por el IDS. Junto a lo visto con anterioridad, existen otros métodos sobre el protocolo TCP/IP para intentar evadir el motor de reglas. Veremos cuatro de los principales métodos de evasión a nivel de TDP/IP:

Explotar el tiempo de vida (TTL)

El TTL es un campo de las cabecera TCP/IP que se encarga de evitar que un paquete permanezca en la red para siempre. El TTL es un campo de 8 bits que indica el número máximo de enrutadores por los cuales puede pasar. Al llegar a un enrutador el TTL disminuye en 1, si el número resultante después de restarle 1 es igual a 0 el paquete es descartado, informando al emisor con un paquete ICMP de tipo Time Exceeded Message. A muchos de ustedes les sonará el campo porque es empleado por herramientas de tipo traceroute (véase esta entrada sobre las curiosidades del traceroute) para conocer los enrutadores por los que pasamos antes de llegar a nuestro destino.

[Read more…]

En este post vamos, por fin, a poder obtener las claves de un tag Mifare Classic para posteriormente leer el contenido, escribir… Para ello, partimos de la base que ya tenemos las librerías instaladas tal y como dijimos en el anterior post, y que detectamos el lector (si tenéis problemas con esto, decidlo en los comentarios).

Vamos ahora a instalar las herramientas que necesitaremos. La primera de ellas se llama mfcuk e implementa el ataque llamado “darkside” descrito en http://eprint.iacr.org/2009/137.pdf. Este ataque aprovecha la poca entropía que se utiliza en el cifrado Crypto-1 para obtener mediante fuerza bruta la clave de un sector.

svn checkout http://mfcuk.googlecode.com/svn/trunk/ mfcuk-read-only

(para la versión 1.3.4 de libnfc, 
svn checkout http://mfcuk.googlecode.com/svn/trunk/ mfcuk -r r37)

cd mfcuk-read-only
autoreconf -vis
./configure
make
sudo make install

Una vez instalado, lo ejecutamos con la orden:

mfcuk_keyrecovery_darkside -C -v 2 -R 3:A -M 8

-C     Para realizar la conexión
-v 2   Modo very verbose
-R 3:A Recuperar la clave A del sector 3
-M 8   Tipo de tag Mifare Classic 1K

Obtenemos el siguiente resultado:

Donde vemos que ha encontrado la clave A del sector 3. Este ataque, según los creadores dura unos 5 minutos, pero en mis pruebas no ha bajado de 20. Como veis, obtener las 30 claves (en el caso que sean todas diferentes) nos podría llevar demasiado tiempo. Ahora vamos a utilizar el programa mfoc para obtener todas las demás claves. Mfoc utiliza el llamado “Nested-Authentication attack” que se basa en el conocimiento de una clave para atacar a los sectores restantes. Su instalación es la siguiente:

wget http://micmd.googlecode.com/files/mfoc-new.tar
cd mfoc
autoreconf -vis
./configure
make 
sudo make install

Para usar la clave que hemos obtenido anteriormente hay que volver a compilar el archivo mfoc.c que está en ./mfoc/src/mfoc.c y buscar el vector de claves por defecto:

Solo hay que añadir la clave siguiendo el mismo patrón. Luego hacemos un:

gcc mfoc.c -o mfoc

y ya lo tenemos a punto.

La ejecución del programa, yo la he hecho de la siguiente forma:

mfoc -P 100 -O salida.mdf

-P 100     Reintentos
-O         Archivo de salida

Veremos algo como esto:

Esta parte todavía no es el ataque; aquí mfoc está comprobando si las claves que tiene por defecto funcionan con algún sector. Primero hace una pasada probando las claves A. Como se deduce, la clave a884…. es la clave A del sector 0. Después de esto, empezará el ataque donde irá obteniendo las claves una a una. En el caso de que las obtenga todas en las 100 repeticiones, hará el volcado del tag en el archivo salida.mdf. Sí no, yo recomiendo apuntar las claves e ir introduciéndolas en el archivo mfoc.c.

Por último, una vez tengamos todas las claves podemos crearnos con un editor hexadecimal un archivo llamado keys.mdf. Este archivo lo podemos crear a partir del salida.mdf poniendo todo a ceros excepto los sectores tráiler de cada bloque. Con este archivo keys.mdf ya podemos operar con el tag con las funciones de la librería libnfc:

nfc-mfclassic w a contenido_nuevo.mdf keys.mdf

w                       Escritura
a                       Clave A
contenido_nuevo.mdf     Archivo de entrada
keys.mdf                Archivo con las claves

Con esta última orden hemos escrito un tag Mifare Classic con un contenido modificado, con lo que termina esta entrada y de momento (por mi parte) las entradas sobre seguridad en Mifare Classic. Si algún lector intenta llevar a cabo lo aquí explicado y tiene problemas, estaré encantado de ayudarle en los comentarios.

Después de unas largas vacaciones, vamos a continuar con el apartado de evasión de IDS que comenzamos hace un par de meses. Tal como vimos, existen distintos vectores de ataques para intentar evadir o denegar el servicio en los entornos de detección de intrusos a nivel de red. El principal objetivo del atacante es evadir el motor de reglas del IDS, de tal forma que el ataque es modificado para que el patrón de búsqueda del motor de reglas no reconozca el ataque como tal, pero sí que sea ejecutado por el servidor víctima.

Para que resulte más sencillo de explicar, vamos a introducirnos en el papel de un atacante en un ejemplo típico de evasión de IDS. Imaginemos que auditando un entorno web hemos detectado que hay un recurso vulnerable (index.php) que permite obtener ficheros de la máquina, y en este caso querremos obtener el fichero “passwd” del directorio “etc”. La consulta web que realizaríamos seria de este estilo:

Al realizar la consulta, vemos que el paquete es rechazado por un IDS (IPS) puesto que éste busca la cadena “/etc/passwd” y si la detecta rechaza el paquete. Nuestra intención como atacantes es pues explotar los distintos posibles vectores de ataques que evadan el IDS y nos permitan obtener el fichero “/etc/passwd”.

El primer tipo de vector de ataque será modificar la cadena “/etc/passwd” para que no sea interpretada por el IDS pero si por el servidor. Este tipo de vector de ataque se dividen principalmente en tres grupos:

1) Interpretación incorrecta del protocolo

Este vector de ataque es muy común en metadatos y servidor Web. Consiste en inyectar en el paquete cabeceras repetidas donde solo una de ellas, normalmente la última, contiene realmente la cabecera que quiere ser explotada por el atacante. Siguiendo el ejemplo anterior, un posible vector de ataque para intentar explotar la vulnerabilidad del servidor web sería enviando una solicitud con el siguiente contenido:

2) Modificación del direccionamiento

Existen métodos para introducir otros caracteres en la cadena que se quiere explotar, sin que esto altere el dato solicitado al servidor, de tal forma que el servidor al ejecutarlo nos permita acceder al recurso solicitado y a su vez, engañar al IDS al no coincidir con el patrón buscado:

Codificación de los caracteres

Otro vector de ataque muy conocido consiste en emplear codificaciones que son interpretadas por distintos servicios pero no así por el IDS. Esto es debido a que algunos servicios soportan codificaciones no estipuladas en el estándar RFC. Por tanto, un IDS debe tener soportes para tantas codificaciones como soporten los distintos servicios, ya que de lo contrario, nosotros como atacantes podríamos evadir el IDS empleando una codificarción no soportada por el IDS pero sí por el servidor, tal como se describe en el paper de Daniel J. Roelker: HTTP IDS Evasion Revisited.

Por ello, dependiendo del servidor existen distintas codificaciones para representar caracteres y de esta forma, poder representar el vector de ataque que queremos realizar. En la siguiente tabla se representa un ejemplo sencillo de como se podría representaría el carácter A (no todos los servicios soportan las mismas codificaciones):

En el caso del ejemplo, si quisiéramos representar el “/etc/passwd” en cualquiera de las codificaciones anteriores sería de la siguiente forma:

Otra forma típica de evadir IDS es aprovechar las primeras características del UTF-8 (Unicode) que permitía representar un mismo carácter de distintas formas, ya que un mismo carácter podía representado con distinto número de bytes. Este fallo fue solventado en el actual estándar UTF8, pero algunos servicios siguen soportando el antiguo estándar. Al respecto, una de las principales ventajas que supone la codificación UTF8 frente a las vistas con anterioridad es la capacidad de emplear el “Bare Byte Unicode Encoding” que permite representar la codificación UTF8 sin necesidad de usar el carácter “%”, lo que le permite saltarse muchos filtros de seguridad.

Debido a lo descrito con anterioridad, los IDS están obligados a emplear normalizadores o preprocesadores, que permitan una representación normalizada del paquete enviado por el usuario, evitando tener que crear firmas para cualquiera de las posibles formas que pudiera adoptar un patrón de ataque. En el caso de Snort y de servidores Web, éste dispone del preprocesador http_inspect, encargado de normalizar las URL solicitadas por los usuarios para intentar eliminar cualquier posibilidad de evasión del IDS. Pero para ello, hay que configurar adecuadamente el preprocesador, indicando las direcciones IP de aquellos servidores que funcionan siguiendo el “estándar” (nótense las comillas, me río yo del estándar) del IIS o de Apache, tal como se describe a continuación:

Espero que les haya parecido interesante. En la siguiente entrada trataremos otro vector de ataque consistente en aprovecharse de las cabeceras TCP/IP para evadir IDS. Cualquier comentario es bienvenido.

(N.d.E.) En otro orden de cosas, Román Soft nos hace llegar la siguiente nota de prensa, relacionada con un concurso de seguridad que seguro que les parecerá interesante:

Como pudimos observar en la primera parte de esta introducción publicada hace un par de días, la tecnología RFID plantea nuevas oportunidades de mejorar la eficiencia de los sistemas de uso diario además de añadir comodidad. Pero dichas mejoras conllevan nuevos riesgos para la seguridad por ataques o caídas del servicio, riesgos para la privacidad como acceso ilegitimo a información sensible, y otros riesgos derivados de la exposición a las radiaciones. Dichos riesgos se comentarán un poco mas en profundidad a continuación. Todos los participantes de esta tecnología tienen la responsabilidad de prevenir estos riesgos, desde los responsables de desplegar la tecnología hasta los organismos o los propios usuarios.

Los riesgos para la seguridad son los derivados de acciones que pueden deteriorar, interrumpir o sacar provecho de forma maliciosa del servicio. Podemos citar diversos ataques:

• La forma mas sencilla de ataque a un sistema RFID es evitar la comunicación entre lector y etiqueta, lo que se consigue introduciendo la etiqueta en una “jaula de Faraday” (en este blog se explicó el efecto Faraday en este post) creando un campo electromagnético que interfiera con el que ha creado el lector. Este ataque puede ser considerando, en otro entorno completamente diferente, como un sistema de protección. Por ejemplo, existen fundas especiales para el pasaporte electrónico que crean una “jaula de Faraday” evitando lecturas no autorizadas de su información.
• Otro tipo de ataque sería la suplantación, que consiste en enviar información falsa que parece ser válida. De esta manera se podrían obtener productos caros con etiquetas suplantadas de productos mas económicos.
• Un tercer ataque detectado es la inserción de comandos ejecutables en la memoria de datos de la etiqueta, que podrían inhabilitar lectores y otros elementos permitiendo algún tipo de fraude o una DoS.
• Por otro lado, si saturamos el sistema enviándole de forma masiva mas datos de los que es capaz de procesar, o somos capaces de anular la comunicación de radiofrecuencia emitiendo ruido potente estaríamos frente a un ataque de denegación de servicio.

Aparte de éstos, también se pueden dar ataques como inyectar código SQL hacia el soporte físico que lee la tarjeta, ataques por inyección de malware o ataques Man in the Middle capaz de vulnerar la confianza mutua en los procesos de comunicación y reemplazar una de las entidades. También se pueden inutilizar las etiquetas sometiéndolas a un fuerte campo electromagnético si disponemos por ejemplo de una antena altamente direccional. Todos estos ataques pueden ser parcial o totalmente mitigados aumentando la capacidad de memoria y procesamiento de las etiquetas, permitiendo de esta manera implementar mecanismos avanzados de seguridad y cifrado.

Para evitar estos riesgos, se recomienda usar etiquetas de sólo lectura o no escribir los datos directamente en ellas, incluir únicamente un código en la etiqueta y el resto de información en una BBDD con mas seguridad, e incluir métodos de autenticación previos al borrado o desactivación de las etiquetas, y para realizar la comunicación entre lector y etiqueta.

Hablemos ahora de los riesgos para la privacidad de los usuarios. En éstos, se usan ataques con técnicas similares a las anteriormente mencionadas pero en los que se accede a la información personal. Este tipo de ataques van desde accesos no permitidos a las etiquetas con datos personales, hasta el rastreo de las acciones o gustos de las personas: accesos a recintos, hábitos, transportes…etc.

Las medidas para evitar los riesgos para la privacidad son una tarea primordial para las organizaciones, y requieren de una adecuada planificación del sistema de información. Al respecto, la Comisión Europea ha aprobado una Recomendación sobre Privacidad en Comunicaciones RFID denominada “On the implementation of privacy and data protection principles in applications supported by radio-frequency identification SEC (2009) 3200 final“, en la que se establecen recomendaciones y buenas practicas para implementar comunicaciones RFID.

Decir también que la Ley orgánica 15/1999 de 13 de diciembre de Protección de Datos de Carácter Personal (LOPD) es directamente aplicable a la tecnología RFID y con ello cada uno de los principios, derechos y obligaciones que regula. Por tanto los desarrolladores de este tipo de productos tiene que tener en cuenta entre otras cosas que:

• Debe realizarse un juicio previo sobre si realmente es necesario usar tecnología RFID, definir las funcionalidades claramente y adoptarse revisiones en relación con la cancelación posterior de los datos personales recopilados cuando no sean necesarios.
• Los usuarios deberán ser informados de la existencia del tratamiento que se le da a sus datos personales.
• Debe garantizarse la seguridad de todos los recursos relacionados con los tratamientos de datos personales vinculados a la tecnología RFID (hardware, software, organizativos…). La implantación de este tipo de tecnologías en territorio español debe respetar las normas del Real decreto 1720/2007.

Por último y no menos importante, deberá tenerse en cuenta el futuro desarrollo de la Directiva 2009/136/CE7 que indica la necesidad de velar por la protección de los derechos fundamentales, y en particular del derecho fundamental a la protección de datos, cuando las etiquetas RFID estén conectadas a redes públicas de comunicaciones electrónicas o usen servicios de comunicaciones electrónicas como infraestructura básica. En este caso, deberán aplicarse las disposiciones pertinentes de la Directiva 2002/58/CE (Directiva sobre la privacidad y las comunicaciones electrónicas), incluidas las relativas a seguridad, datos de tráfico y de localización, y a la confidencialidad.

Cómo recomendaciones finales para los usuarios, para evitar este acceso indeseado a la información existen diversos sistemas:

• Utilización de etiquetas watchdog. Estas etiquetas informan de intentos de lectura y escritura que se hagan en su área de actuación.
• Aislamiento. Evitando la lectura de las etiquetas salvo en los momentos que se desee. Para ello, sólo hay que introducir la etiqueta en una funda de material metálico o plástico, que haga la función de “jaula de Faraday” comentada anteriormente.
• Firewall RFID. Estos dispositivos crean una zona segura alrededor del usuario mediante la emisión de ondas que anulan la efectividad de RFID. Se denominan también inhibidores de radio- frecuencia. Esta solución es aplicable a entornos de máxima seguridad, no compatible con situaciones en las que ciertas lecturas deben ser permitidas y otras no.
• La inutilización de las etiquetas una vez se haya realizado la transacción, destruyéndola físicamente, o mediante el comando KILL.

Con esto, finaliza la breve y básica introducción a RFID; si quieren indagar más en el tema, pueden seguir con la Guía sobre seguridad y privacidad de la tecnología RFID que ha publicado INTECO, y con los múltiples recursos que ofrece la red sobre esta tecnología tan interesante como potencialmente peligrosa.

Según el DRAE, la disuasión es la “acción y efecto de disuadir”, y disuadir significa “inducir, mover a alguien con razones a mudar de dictamen o a desistir de un propósito”; básicamente, la disuasión consiste en convencer a alguien, de una u otra forma, para que cambie su manera de actuar. Cuando hablamos de seguridad, las medidas de disuasión son las que tratan de “convencer” a alguien hostil para que cese su actitud -al menos ante nosotros-; en muchos casos, son el efecto colateral de salvaguardas reales, pero en ocasiones se utilizan de forma pura, sin ningún otro mecanismo de seguridad real más allá de la intención de “convencer” a un delincuente de que nos deje tranquilos…

Desde siempre, la disuasión ha sido uno de los pilares básicos de la seguridad, junto aspectos como la prevención, la canalización o la detección; las medidas puramente disuasorias eran habitualmente tan baratas (cámaras de seguridad falsas, carteles de conexión a CRAs inexistentes, desfiles militares con misiles de cartón…o un simple cartel de “Cuidado con el perro”) que justificar (o amortizar) su coste era trivial, así que con una rentabilidad justificada, no había impedimentos para echar mano de estas salvaguardas. Por supuesto, la efectividad de una medida estrictamente disuasoria es cuestionable: volviendo a los ejemplos anteriores, si un potencial atacante descubre que las cámaras son falsas, que no estamos conectados a ninguna CRA, que nuestros misiles se rompen si llueve o que no tenemos perro, tendrá el camino libre hacia su objetivo; así, llegado este punto, la disuasión pura habrá dejado de funcionar y deberán entrar en juego otro tipo de salvaguardas más eficaces… Adicionalmente, otro aspecto de las medidas de disuasión puras es el efecto negativo que pueden llegar a tener; si nuestra casa está plagada de controles de acceso, carteles, etc. puede llegar a convertirse, con o sin razón, en un buen reclamo para un potencial atacante, y en ese caso deberemos disponer de más medidas de seguridad para frenar el ataque. Por tanto, el uso excesivo de medidas disuasorias puede ser, en ocasiones, contraproducente.

[Read more…]