Nos despedimos de esta semana con un post de Pedro Quirós acerca de seguridad en SCADA, tan de moda estos días gracias a Stuxnet y a los medios de comunicación generalistas. Que pasen un buen fin de semana y vengan todos con las pilas recargadas para los últimos días previos al puente (sobre todo aquellos que no lo tengan ;)

A día de hoy hay pocos procesos productivos que no tengan una alta dependencia del ámbito TIC. Si bien en muchas organizaciones el número de usuarios de oficina es relativamente bajo y la complejidad es muy reducida, muchas veces disponen de entornos productivos con líneas de montaje que están controladas por equipos Scada. Estos equipos son auténticos ordenadores que controlan la operatividad y la eficiencia de las líneas de montaje o fabricación. Infraestructuras tan críticas con la nuclear, eléctrica, de alimentación, distribución de agua o de transporte usan entornos Scada a gran escala. Generalmente se consideran entornos seguros dado que suelen estar separados en áreas de la red diferenciadas, o incluso su propia subred. Muchos gestores las consideran “redes seguras” porque “no tienen acceso a internet”, además de considerarlos “entornos de bajo riesgo” dado que son entornos propietarios con un número muy limitado de expertos. Así que sus principales bazas eran el desconocimiento y el aislamiento.

Ya se lo decía Rod Tidwell a Tom Cruise en la película Jerry Maguire: ¡Enséñame la pasta! Y es que en el mundo en el que nos movemos, a la hora de tomar decisiones (decisiones que afectan a nuestras organizaciones), no podemos desestimar el factor económico.

El entorno exige una “Mejora continua” y este objetivo está presente en cada momento. Todos los días se nos bombardea con cuestiones sobre la eficiencia, optimización, racionalización de costes, etc. Tenemos a nuestra disposición una amplísima gama de elementos que contribuyen a este fin. Estamos familiarizados con los términos y somos conscientes de la importancia que tiene en nuestro día a día. Está bien, entremos en el juego, nos disponemos a mejorar […] ¿Por dónde empezamos?

Como vimos hace un tiempo, el tiempo de reacción ante un ataque se vuelve un proceso crítico para nuestra organización. Si en la entrada anterior (orden shun), vimos como realizar un filtrado, tanto de las conexiones actuales como de futuras conexiones en un firewall Cisco ASA, hoy veremos como realizar el mismo proceso en un Firewall-1 de Check Point.

Antes de ver las opciones que FW-1 nos ofrece para el filtrado de conexiones, debemos tener en cuenta qué sucede cuando aplicamos la política en nuestro Gateway. Habitualmente, es normal que los firewalls mantengan las conexiones establecidas y denieguen (si así lo indica la política), las nuevas conexiones. Sin embargo, en Firewall-1 esta forma de funcionamiento es configurable, por lo que dentro de las opciones ‘connection persistence’ del propio gateway podemos encontrar las siguientes:

Para hoy viernes, he de advertirles de antemano que les he preparado una entrada un tanto atípica, y que desvela cuestiones importantes sobre las tres primeras temporadas de la serie “24″ (y los primeros capítulos de la cuarta). Así que si tienen intención de verla o están en ello, no continúen leyendo. Luego no les digan que no les he advertido.

Para el resto, una pequeña introducción. “24″ es una serie norteamericana emitida por la FOX que narra las “peripecias” de la UAT (Unidad Anti Terrorista) de Los Ángeles, a lo largo de diferentes situaciones de crisis. El personaje principal se llama Jack Bauer, y es protagonizado por Kiefer Sutherland. Éste es un agente de campo de pasado militar (operaciones especiales), una gran cantidad de recursos, y poca simpatía por las normas y los protocolos. Alrededor de éste existen un número indeterminado y variable de personajes secundarios, con mayor o menor relevancia a lo largo de las diferentes temporadas. La principal característica de la serie es que cada una de las temporadas se corresponde con una situación de crisis comprendida en las 24 horas de un día, de modo que cada una de las horas del día corresponde a un capítulo. Aunque se indica al principio de los capítulos que los hechos transcurren en tiempo real, los capítulos duran 45 minutos aproximadamente, por lo que no es del todo cierto dado que 60 minutos en tiempo real no pueden comprimirse de ninguna forma en 45 minutos de emisión (o yo no acabo de entender la idea).

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:

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?

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.

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?).

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.

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.