Seguridad Wi-Fi empresarial – Servidores radius (I)

6 de noviembre de 2013 Por

En la actualidad las conexiones inalámbricas se han vuelto algo indispensable a la hora de conectarnos a internet, el aluvión de nuevos dispositivos como móviles, tablets, ebooks etc… Hacen que en casi todo hogar doméstico exista un router con funciones de punto de acceso para poder conectarnos sin cables.

Los motivos que llevan a conectarse sin cables son varios, desde la simple comodidad de no tirar cables por casa, a las características de la infraestructura de una empresa o las propiedades geográficas de un lugar, que no permiten hacer otro tipo de conexión.

En 1999 se asienta la tecnología inalámbrica llamada Wi-Fi, funcionando bajo el estándar IEEE 802.11b, que nos daba una mísera velocidad de 11 Mbps, y donde los dispositivos aún eran únicamente compatibles con el famoso cifrado WEP, el cual usa el algoritmo de cifrado RC4 de 128 bits (104 en realidad) y que fácilmente puede ser roto.

[Read more…]

An evening with Vicente (II)

5 de noviembre de 2013 Por

Llevamos tres días jugando al ratón y al gato con nuestro amigo Vicente y empezamos a cansarnos del tema, pero no nos queda otra que seguir…

DIA 4 (y sucesivos)
A la misma hora de todos los días (aproximada, claro) estamos ya mirando la consola de eventos y los móviles, esperando a Vicente una noche más… Pero hoy Vicente ha desaparecido, tras tres días jugando con nosotros; durante unas jornadas estamos especialmente alerta a cualquier cosa que se salga de la normalidad en ACME, pero nada. Como si se lo hubiera tragado la tierra; los ataques de Acunetix no obtuvieron ningún resultado significativo, no hay más actividad anómala en el entorno -al menos similar a la generada por nuestro amigo- y parece haberse perdido todo el interés de Vicentín en ACME… ¿Que habrá pasado? ¿Habrá encontrado un ACME2? Ni idea por el momento, pero el caso es que ya no molesta, al menos a primera vista… Unos días después revisamos otra vez el entorno de ACME y no encontramos nada relevante, por lo que desactivamos el GIR y olvidamos el tema. ¿Fin de la historia? No :)

FIN DE LA HISTORIA
Aproximadamente un mes después de la fiesta nos llaman del CNP; la denuncia que en su día hicimos sigue su curso y el Oficial que está llevando el tema quería aclarar algunas dudas… Sinceramente, ni me acordaba del tema, pero es de agradecer el interés mostrado en este caso por el CNP y el excelente trabajo que hicieron. Resuelvo las dudas y a otra cosa…

Algo menos de tres meses después del incidente, el Oficial vuelve a llamarme: lo tienen. Han cogido al tipo. OPERATOR les ha dado la información, previa orden judicial, de quién estaba detrás de todas las direcciones identificadas y -oh, sorpresa- era la misma persona: Vicentín; han mandado a dos policías a su casa, lo han trincado y el chaval ha cantado hasta el último detalle… La verdad, un pobre diablo al que han pillado; como me dijo hace años un amigo de la Guardia Civil, pillamos a los más tontos, y de los más tontos a los que llevan un mes en esto… En fin, sin comentarios sobre el pardillo, ya se apañará; da incluso algo de pena, pero nos hizo perder muchas horas y sobre todo nos hizo pasar algún rato de preocupación. No detallaremos cómo fue el tema judicial para no generar morbo que no aporta nada, pero el caso es que al chaval lo pillaron con todo el equipo :)

LECCIONES APRENDIDAS
Como todo incidente, tenemos que aprender algo de la situación que vivimos en ACME; sin duda, para nosotros, lo más grave es la sensación de indefensión que sufrimos, tanto el cliente como nosotros mismos… Un atacante está analizando la seguridad de la infraestructura de un cliente -o la tuya propia- y lo más que puedes hacer oficialmente es bloquear la IP. Cojonudo, perdonen la expresión. Como si un tío está intentando forzar la puerta de tu casa y lo más que puedes hacer es cerrarla bien… Luego se nos llena la boca hablando de convergencia, de 112 digital y de cosas así. Mentira. Si alguien intenta entrar físicamente en mi casa llamo al 062 y tengo a una pareja de la Guardia Civil en la puerta; si intenta entrar virtualmente, no tengo a nadie a quien llamar (claro, puedo llamar también al 062 y esperar); menos mal que Vicentín se cansó en un momento determinado de atacar a ACME, porque en caso contrario podríamos haber estado meses bloqueando direcciones IP en el firewall. Surrealista, ¿verdad? Hasta que no tengamos una especie de “062” al que llamar en situaciones así, mal vamos, porque no podemos hacer otra cosa más que cortar tráficos… Aunque me han comentado que puedes comprar, pagando en efectivo sin dejar rastro, un VPS ruso desde el que jugar con Vicentín muy alegremente (y encima el ancho de banda del proveedor es bastante barato)… Ojo, que me lo han comentado, que nosotros eso no lo hacemos porque es ilegal, por supuesto. Seguiremos poniendo la otra mejilla para que nos den más abajo y con el pie…

Como elemento positivo, hay que reconocer que el CNP hizo un trabajo excelente, y eso es siempre de agradecer, en nuestro caso especialmente al Oficial y, por extensión, al Inspector Jefe del Grupo; nos atendieron de maravilla en todo momento, el intercambio de información fue fluido y ágil y los resultados obtenidos fueron perfectos, con el atacante delante de un juez. El aspecto judicial ante situaciones como la explicada, y las situaciones surrealistas en los juzgados, darían para más de un post, pero ese ya es otro tema que excede la gestión del incidente con Vicentín…

La gestión de incidentes no es, por suerte o desgracia, una ciencia exacta. No sabemos si otros habrían hecho lo mismo que nosotros, mejor o peor, en esta historia inventada ¿Qué opináis? ¿Se os ocurre alguna alternativa legal más allá de bloquear y denunciar? ¿Denunciaríais? ¿Atacaríais -ojo, sin saber realmente si la IP es del atacante o de su vecino-? Cualquier idea es bienvenida, que el objetivo es, siempre, ir mejorando…

Una visión global de la ciberseguridad de los sistemas de control (II)

4 de noviembre de 2013 Por
(N.d.E. Este artículo fue publicado en el número 106 de la revista SIC, correspondiente a Septiembre de 2013. Sus autores son Óscar Navarro Carrasco, Responsable de ciberseguridad industrial, y Antonio Villalón Huerta, Director de seguridad. Ambos trabajan en S2 Grupo y pueden ser contactados vía onavarro en s2grupo.es y avillalon en s2grupo.es)

La semana pasada finalizábamos el artículo haciendo al lector una pregunta ¿tiene en cuenta el enfoque actual de la ciberseguridad industrial este contexto?

Y la respuesta, en nuestra opinión, es que NO.

En primer lugar, y siempre en términos generales, los elegidos dentro de las empresas para gestionar la ciberseguridad industrial y todo lo referente a la LPIC son, como no debe ser de otra forma, los departamentos de seguridad, en el mejor de los casos, o los responsables de seguridad tecnológica; incluso si no existen estos roles, es directamente el departamento TI quien pasa a hacerse cargo de cualquier cosa que tenga el prefijo “ciber”. Esta elección puede parecer obvia en ciertas ocasiones, pero como ya indicamos al principio, saber conducir no es equivalente a conocer la ruta.

Estas personas tienen que librar una batalla con departamentos en ocasiones más antiguos, con directivos ‘pata negra’ que han trabajado en el núcleo del negocio –o eso creen- toda la vida (posiblemente en el sentido estricto), que perciben la seguridad como un simple gasto y cualquier cosa tecnológica como algo recién llegado que carece de una importancia real y que llega a invadir su territorio, su reino. Y lo que es peor, es muy posible que en las reuniones quede patente que, efectivamente algunos departamentos de seguridad –o de tecnologías- no conocen ni siquiera este lenguaje, al igual que esos “expertos” en negocio no entienden ni una palabra del riesgo tecnológico. El resultado de las confrontaciones las debe resolver un superior jerárquico que posiblemente proceda, igualmente, del ‘núcleo duro’ y que entiende lo que dice una parte, pero por desgracia posiblemente no lo que dice la otra. Y es muy difícil convencer a alguien cuando el único argumento que queda es el de la amenaza, especialmente si ésta no se percibe como tal. Otras amenazas, como las consecuencias de un fallo en el sistema de control a causa de una intervención incorrecta (medible en repercusión social y lucro cesante) son mucho más fácilmente asimilables, ya que suponen la preocupación diaria de estos directivos.

Es poco realista fijar objetivos a largo plazo considerando como tal el horizonte 2017-2018, como se propone en el Mapa de ruta de ciberseguridad industrial en España. Guste o no, en un sector donde algunos PLC todavía usan sistemas operativos y protocolos de más de 20 años de antigüedad, 5 años constituye un plazo, a lo sumo, medio, al menos de momento. Es a consecuencia de todo ello que se llega a una situación de bloqueo como la actual, lo que tiene como resultado que los plazos previstos en la LPIC y en el Reglamento que la desarrolla se estén incumpliendo.

Es posible, incluso, que los responsables de los sistemas de control industrial intenten adoptar medidas en este ámbito, siempre bajo su supervisión. El problema de esta aproximación es que ni la formación ni la cultura facultan al personal de este departamento para trabajar en esta cuestión, siempre hablando en términos generales. Incluso puede que estas medidas no tengan más objeto que justificar que se están ‘haciendo cosas’, una razón más para apartar de la cuestión al departamento de seguridad o al departamento TI y proseguir con esa lucha entre reinos que tanto suele preocupar a esos directivos “pata negra” y tan poco preocupa a la sociedad.

Certificaciones polémicas

Es fácil caer en la tentación de trasladar directamente las estrategias y experiencias que han dado buen resultado en el ámbito TI al ámbito industrial. Recuérdese el dicho: “cuando todo lo que tenga sea un martillo, todo lo que vea le parecerá un clavo”. Sólo un ejemplo, existe ya una certificación expedida por el IACRB denominada CSSA (Certified SCADA Security Architect). En primer lugar, en el campo profesional industrial un pie de firma repleto de acrónimos correspondientes a certificaciones resulta, cuando menos, extravagante —al igual que a muchos nos parece ridículo en el ámbito tecnológico—. La pregunta es: ¿Cuántos sistemas SCADA o procesos industriales han diseñado los poseedores de tal acreditación? ¿Es necesaria experiencia previa en sistemas SCADA para obtenerla? Más aún, los profesionales que se dedican, por ejemplo, a programar PLC ¿poseen la base necesaria para alcanzar la certificación? Antes de responder afirmativamente, rogamos al lector que se pregunte con cuántos programadores de PLC ha hablado. La realidad es que tal certificación está en posesión, al menos en España, de profesionales del ámbito TIC. Es fácil y obvio imaginar la escasa disposición de un responsable de un sistema de control a aceptar recomendaciones de un CSSA sin experiencia en diseño, operación o mantenimiento de sistemas SCADA.

fotoOtro error consiste en pretender que el sector industrial y de infraestructuras adopte cambios o acometa acciones radicales a la velocidad a que suele ocurrir o es posible en las TIC. En este caso hay que buscar un término medio entre pretender lo imposible y retrasar lo inevitable, dos caminos que conducen al desastre. En este sentido es, en nuestra opinión, poco realista fijar objetivos a largo plazo considerando como tal el horizonte 2017-2018, como se propone en la recientemente publicado Mapa de ruta de ciberseguridad industrial en España del Centro de Ciberseguridad Industrial. Guste o no, en un sector donde algunos PLC todavía utilizan sistemas operativos y protocolos de comunicaciones de más de 20 años de antigüedad (un éxito, sin duda, de sus creadores), 5 años constituye un plazo, a lo sumo, medio, al menos de momento. Es a consecuencia de todo ello que se llega a una situación de bloqueo como la actual, lo que tiene como resultado que los plazos previstos en la LPIC y en el Reglamento que la desarrolla se estén incumpliendo.

Lo dicho anteriormente no se basa en especulaciones sin fundamento. Es el resultado de nuestra experiencia al respecto, tanto de S2 Grupo como la nuestra en particular. Uno de los autores es Ingeniero Industrial y hasta su incorporación a S2 Grupo había desarrollado su carrera en el ámbito de la ingeniería y construcción; nunca había trabajado con ingenieros informáticos. Por el contrario, otro de los autores es Ingeniero Informático, especializado en seguridad, por lo que para él hablar de meses o años para corregir una vulnerabilidad, o utilizar sistemas operativos de hace lustros es, sencillamente, algo no asumible. Tanto uno como otro llegan a afirmar que la relación con los otros profesionales es comparable a la del contacto con alienígenas y sólo cuando han desarrollado un lenguaje común y tenido una noción del trabajo llevado a cabo por la otra parte ha sido posible iniciar una relación fructífera. A la vista de todo lo expuesto, cabe cuestionar si el enfoque actual de la ciberseguridad industrial es el adecuado o si los que trabajamos en seguridad desde hace tiempo estamos pensando que la situación —y la solución— es sólo cosa nuestra. Se dice que no por mucho madrugar amanece más temprano y lo urgente de la cuestión no justifica adoptar medidas precipitadas, más aún cuando éstas pueden resultar contraproducentes.

Se ha hablado mucho de la falta de formación en ciberseguridad de los profesionales del ámbito industrial, asi como de concienciación. Sin duda, son aspectos en los que se debe trabajar. Pero hay dos cuestiones en las que no se suele reparar y que son de la mayor importancia: la inercia/conservadurismo y el corporativismo.

En nuestra opinión, el trabajo de mejora de la ciberseguridad industrial no puede realizarse de espaldas a los profesionales que han diseñado, construido y mantienen en explotación las infraestructuras que se deben proteger, igual que esos profesionales no pueden vivir ni un minuto más sin concienciarse –siempre es el primer paso- de la importancia de la seguridad. Es evidente que ambas partes tienen mucho que aportar y su participación es imprescindible. Los expertos en seguridad tecnológica poseen la experiencia y las herramientas técnicas, mientras que los profesionales en procesos y sistemas de control industrial deben aportar su conocimiento de los sectores productivos, los procesos controlados y las limitaciones que el contexto impone a las soluciones específicas.

Por ejemplo, hay cuestiones que el sector tecnológico ha resuelto de forma excelente y que deben incorporarse, con las consideraciones específicas oportunas, al ámbito de los sistemas de control. En primer lugar, el empleo de técnicas de correlación compleja para la identificación y caracterización de incidentes de seguridad. Ello es tanto más importante por cuanto los ataques a estos sistemas están adoptando la forma de APT y son, por tanto, bastante más complejos que una simple orden de ‘shutdown’. En segundo lugar, el modo en que se gestionan los incidentes en el ámbito tecnológico; los sistemas industriales están diseñados para hacer que el fallo sea algo extremadamente raro (tanto más raro cuanto más peligroso resulte). Su gestión está poco regulada y depende altamente de las personas y su experiencia y conocimiento de la instalación controlada. En cambio, en las TIC se ha aprendido a convivir con el fallo, razón por la cual se han desarrollado herramientas, sistemas y procedimientos de gestión que permiten tratar eficazmente las consecuencias, por ejemplo, de un ciberataque. A modo de ejemplo y en esta línea en S2 Grupo disponemos de un iSOC (industrial Security Operation Center) destinado a tratar estas incidencias con un enfoque mixto.

En definitiva, creemos que la estrategia actual en ciberseguridad industrial ha descuidado, hasta el momento, algunos aspectos cruciales. Como consecuencia, el progreso ha sido más lento de lo esperado a pesar de las exigencias legislativas. Para corregir esta situación hay que incidir en cuestiones que hasta el momento no han recibido la atención necesaria:

1. Tener en cuenta que el sector industrial es muy heterogéneo, por lo que no existen soluciones generales. Es imprescindible conocer las particularidades de cada uno de ellos para realizar un enfoque adecuado. Este trabajo sólo pueden hacerlo profesionales de los sectores implicados.
2. Recordar que un sistema SCADA no es sólo el software de supervisión, el servidor SCADA o la red de comunicaciones (elementos familiares para un profesional TI). Se trata de un sistema complejo en el que también hay elementos físicos (como, por ejemplo, instrumentación y actuadores). En este sentido, posibles soluciones para problemas específicos irresolubles a nivel TI pueden pasar por volver a recuperar cosas como la lógica cableada y los enclavamientos físicos y eléctricos, viejos conocidos de los profesionales industriales.
3. Tener en cuenta el ritmo a que se asimilan los cambios en el sector industrial para no fijar horizontes no realistas.
4. Prestar la máxima atención al factor humano, evitando que se den situaciones de enfrentamiento tipo Nosotros vs. Ellos que acaben en posiciones ultradefensivas o de bloqueo.
5. Desarrollar aproximaciones sucesivas teniendo en cuenta las largas vidas útiles de equipos e instalaciones.
6. Las Administraciones y otras entidades licitadoras de infraestructuras deben incluir en los pliegos exigencias concretas relativas a la ciberseguridad industrial de las instalaciones proyectadas, de forma que estas condiciones pasen a formar parte del proceso proyecto-construcción.
7. Es imprescindible la formación de equipos interdisciplinares lo que debe alcanzar también a la interlocución con los responsables de la gestión de las infraestructuras críticas. De esta forma, éstos podrán comunicarse, además de con expertos en ciberseguridad, con personas de formación y experiencia afines, lo que ayudará a salvar los obstáculos culturales (especialmente a un nivel intermedio).
8. Se hace mucho énfasis en la formación, especialmente en la forma de másteres específicos. Pero no debe olvidarse que, en muchas ocasiones, los propios programadores disponen de gran autonomía en la toma de decisiones técnicas específicas en el diseño de los sistemas, por lo que no se debe descuidar ningún nivel educativo o profesional.
9. Siguiendo con la formación, creemos que debe evitarse extender el modelo basado en certificaciones específicas, tan habitual entre los profesionales TIC, a los especialistas en sistemas de control industrial.
10. Se deben desarrollar instalaciones dotadas de sistemas de control, industrial suficientemente realistas como para permitir adquirir experiencia en ciberseguridad (tanto en estrategias de ataque como de defensa o gestión de incidentes). Estas instalaciones son el ámbito idóneo para los equipos mixtos que deben trabajar en ellos desde el momento mismo del diseño. Además, constituyen un medio de demostración importantísimo para el personal no formado en ciberseguridad.
11. A modo de resumen final: evitar trasladar tal cual la experiencia y procedimientos de ciberseguridad en el ámbito TI al ámbito industrial. Una nueva cultura común debe surgir del trabajo conjunto de todos.

Pueden descargar el artículo original desde este enlace: Una visión global de la ciberseguridad de los sistemas de control. Revista SIC, número 106, Septiembre 2013.

Diseñando Sistemas III: El análisis del sistema

31 de octubre de 2013 Por

Continuando con el ciclo de diseño y desarrollo de los sistemas de tratamiento de la información (véase Diseñando Sistemas II: El diseño del sistema y Diseñando Sistemas I: La toma de requerimientos), una vez definido el diseño del sistema, entramos en la fase de análisis detallado del mismo. En esta etapa, si es necesario, se puede plantear un documento de análisis detallado de las funciones o directamente un análisis técnico de las mismas. Bajo mi experiencia, el primero solo reflejaría el flujo de información y las decisiones y ramificaciones posibles del mismo, así como los puntos de entrada de la información y los diferentes casos de conjuntos de datos que pueden darse para su proceso. Igualmente indicaría las transacciones válidas y el modo de controlarlas, y las prohibidas —si las hubiera— y el modo de actuar sobre ellas.

El análisis técnico debe reflejar con suficiente detalle los controles y acciones a ejecutar con cada modelo posible de datos, así como los conceptos que componen su proceso y como llevarlo a cabo. Es decir, debe definir con detalle las transacciones y sus condiciones de proceso, así como los resultados que se pretende obtener, reflejando su contenido, formatos y también cualquier control o acción requeridos con antelación o posteriormente.

Son conceptos básicos pero que frecuentemente se olvidan —aunque les parezca mentira hoy aún se olvidan—. Por ejemplo hacer la captura de datos en línea, incluyendo la validación de éstos en el momento de su captura y no en procesos posteriores, ya que la información errónea no debería entrar en el sistema ni formar parte de su base de datos. Esto evitará procesos inútiles y revisiones posteriores de los datos. Si quien la genera sabe que en el caso de no ser correcta, la información será rechazada, procurará depurarla por sí mismo.

Obviamente, para poder hacer lo anterior, es necesario tener cuidadosamente definidos los controles a realizar y estos son los que deben describirse en el análisis detallado, indicando contra qué otra información o combinación de informaciones se va a validar cada uno. Para ello ya propuse en el artículo sobre el diseño detallado, la definición de parámetros y datos de control que el administrador del sistema o el usuario experto responsable deberá introducir previamente en las tablas de control.

Una vez dada por buena la información introducida, lo lógico es que sea válida para alguna de las posibles transacciones que el sistema “sabe” ejecutar y por tanto no haya problemas de error de datos o cancelación de programas si estos han sido desarrollados de acuerdo a las especificaciones detalladas del análisis técnico y éste ha previsto las diferentes posibilidades. Para conseguir esto, dicho análisis debe reflejar cómo ejecutar cada paso del proceso o transacción, con información suficiente para que el programador pueda comprenderlo y aplicarlo en su código, e igualmente pueda plantear las pruebas y validar los resultados.

Creo que es de suma importancia llegar a este punto con la mejor definición de los procesos que sea posible y que esta quede bien documentada, evitando que sea transmitida en reuniones de viva voz (muy frecuente) confiando en el buen hacer de los programadores que tomarán sus notas interpretando por si mismos lo que el analista o jefe de proyecto les cuenta, y que a su vez, es una interpretación de lo que el cliente les ha pedido. Un buen análisis funcional (o diseño del sistema) es la base para un buen análisis técnico (o especificaciones de programa) y estos dos son la base para desarrollar un sistema fiable y rentable.

Bajo mi experiencia, transmitirle al programador el fundamento de los procesos es esencial, no solo para obtener un buen resultado técnico sino para que facilite igualmente su gestión posterior por parte de los usuarios, así como su explotación. La fase de programación y pruebas de un sistema ha sido considerado tradicionalmente la de mayor duración en el desarrollo de un proyecto, pero generalmente esto se debe a la falta de definición de las necesidades del cliente y de los detalles del proceso requerido, en definitiva a un análisis incompleto o poco documentado. La experiencia me ha enseñado que la inversión de tiempo en estas dos etapas anteriores al desarrollo es muy rentable si este último puede hacerse con claridad y rapidez, y las pruebas plantearse con criterios de conocimiento adquirido de lo que se pretende obtener.

Considerar que el programador no necesita conocer el fundamento o el porqué de muchas de las decisiones que el programa va a ejecutar es un tremendo error, ya que limita de manera importante su creatividad y la aplicación de su propio conocimiento y experiencia en el desarrollo, incluso impide que el programador que conoce bien las herramientas que al final van a procesar la información, pueda sugerir algunas mejoras en la propuesta técnica, aportando cierto valor añadido a la misma. Lo más probable es que esto conduzca a tener ciclos de error – revisión – prueba – y nuevo error, hasta perder mucho tiempo (y aumentar el coste) y lo que es peor, comenzar a estresar al equipo porque las fechas de entrega se acercan o sobrepasan y el coste se dispara, lo que genera casi siempre nuevos errores y acaba con la entrega de un producto de calidad inferior a la deseada y prometida al cliente, que va a requerir soporte continuo hasta quedar depurado. Frecuentemente suele disimularse o camuflarse el coste indeseado de esta última fase, dentro de las actividades de un nuevo proyecto, lo que además de injusto, vuelve a ser un error.

Así pues, el responsable del proyecto deberá controlar cada etapa del mismo y validar la documentación y el medio mediante el cual se transmite la información y el conocimiento adquirido sobre los procesos a ejecutar, para que cada componente del equipo pueda realizar correctamente su trabajo.

#badBIOS

30 de octubre de 2013 Por

Hace dos días, recibí un correo que contenía este enlace. Tras leerlo, estaba un poco asustado, parecía algo serio, especialmente viniendo del creador del concurso pwn2own Dragos Ruiu (@dragosr), ya que él no necesita algo así para hacerse famoso o tener un nombre.

Como no hay demasiada información o un informe “oficial”, aquí os dejo algunos hechos sobre lo que Dragos ha encontrado y su investigación:

  • Encuentra un malware que infecta el hardware.
  • Lo encuentra instalado en portátiles con sistemas Windows instalados, pero se ve que de alguna manera es independiente de la plataforma, puede infectar sistemas BSD y OSx tampoco es inmune.
  • Reescribe la BIOS del sistema y es persistente, incluso tras “flashear” la BIOS con un firmware legítimo, sigue infectando el sistema. Esto obliga al investigador a usar una nueva máquina para cada prueba.
  • Se comunica mediante SDR (Software Defined Radio) para unir air gaps (equipos sin conexión a ninguna red). Funciona incluso si las tarjetas de red inalámbricas y de Bluetooth son extraídas.


    (https://plus.google.com/103470457057356043365/posts/exuXRz5C3L3)

  • Carga un Hypervisor.
  • Cuando se infecta la BIOS, no permite el arranque desde dispositivos externos sin importar la configuración elegida, la mayoría de las veces arranca desde el disco interno.


    (https://twitter.com/dragosr/status/388632113496350721)

  • Reescribe la memoria flash de todos los dispositivos de memoria USB que se conectan a un sistema infectado, incluyendo lectores de CD que se conectan mediante USB. No afecta a los ficheros del dispositivo USB, va directamente al firmware.
  • Insertar un pendrive infectado en un sistema limpio es suficiente para infectarlo… ¡sin siquiera tener que montarlo!

    “I didn’t even mount the volume and it was infected.”

    (https://twitter.com/dragosr/status/393021493149302785)

  • A veces “brickea” las memorias USB al extraerlas de manera no segura, pero vuelven a la vida cuando se introducen en un sistema infectado.


    https://twitter.com/dragosr/status/393026712197279746)

  • En los sistemas Windows infectados aparecen algunos ficheros .ttf y .fon extra. Tres de ellos (meiryo, meiryob, and malgunnb) tienen un tamaño mayor del esperado.
  • Cuando se intentan extraer estos ficheros, desaparecen del CD en el que se han copiado.


    • (https://twitter.com/dragosr/status/393633641370112000)

  • Se apunta a Rusia como origen del malware, ya que son los únicos desarrolladores de software malicioso que modifica los controladores flash. Además, el malware bloquea los dominios rusos que modifican las memorias flash.


    (https://twitter.com/dragosr/status/393023050750234624)

  • Los primeros síntomas se encontraron en un Macbook hace tres años.


    (https://twitter.com/dragosr/status/394223528813146112)

  • Han subido una lista con los md5 de los ficheros a este enlace.

En estos momentos, no sé si se trata de un trolleo épico. Personalmente no creo que Dragos se juegue su reputación así, o si estamos delante de un nuevo tipo de amenaza ante la que tenemos que estar preparados. Lo peor es que, a día de hoy, nadie tiene ni idea del propósito del malware.

Trataré de manteneros al día y os recomiendo que sigáis en Twitter a @dragosr y el hashtag #badBIOS si queréis estar al día sobre el tema.

[NOTA] Si os interesa una muestra, tened un ojo en malware.lu. @xylit0l publicó esto en kernelmode.info:

Re: New Bios Malware
 by Xylitol » Sun Oct 13, 2013 9:23 pm
Talked to r00tbsd over irc, he have an image of the infected bios but got no time 
for the moment to add it on malware.lu.

Fuentes:

[1] https://plus.google.com/103470457057356043365/posts/9fyh5R9v2Ga
[2] https://plus.google.com/103470457057356043365/posts
[3] https://www.wilderssecurity.com/showthread.php?t=354463
[4] https://www.security.nl/posting/366329/Onderzoeker+ontdekt+mysterieuze+BIOS-malware
[5] https://kabelmast.wordpress.com/2013/10/23/badbios-and-lotsa-paranoia-plus-fireworks/
[6] https://twitter.com/dragosr
[7] https://twitter.com/rich_addr
[8] http://www.kernelmode.info/forum/viewtopic.php?f=16&t=2998&p=21195&hilit=BIOS+malware#p21195

Passwords en claro con Procdump y Mimikatz Alpha

29 de octubre de 2013 Por

En este post me gustaría hablaros de una técnica que leí este verano y que no había podido poner en práctica hasta hace poco en un test de intrusión.

La técnica consiste en obtener las contraseñas en claro de un servidor sin ejecutar código “malicioso” en el mismo. De esta forma nos evitamos tener que lidiar con evasiones de antivirus y demás dolores de cabeza.

Herramientas necesarias:

[Read more…]

Fundamentos sobre certificados digitales (V) – Dispositivos físicos para gestión y custodia de claves

28 de octubre de 2013 Por

Seguimos con la serie de entradas relacionada con los certificados y firma digitales. En este punto, nos vamos a centrar en una parte fundamental de la infraestructura necesaria para la generación y custodia de claves, concretamente la que suele sustentar las claves principales de la cadena de confianza de una Autoridad de Certificación (en adelante CA). Como se ha comentado a lo largo de esta serie de entradas, se trata de un entorno crítico respecto a la confidencialidad, en el que una revelación accidental de información podría ser catastrófica.

Las claves privadas de la jerarquía de certificados de una CA y más especialmente el certificado raíz son los activos más críticos de estas organizaciones. Dados estos requisitos tan altos de seguridad, este tipo de claves se suelen almacenar offline en emplazamientos seguros (Centros de Procesos de Datos, Cajas de Seguridad, etc.); y en dispositivos que ofrezcan un cifrado fuerte y sea capaz de mantener un control férreo de acceso a las claves. Para ello, lo habitual es emplear dispositivos hardware diseñados a tal efecto. Estos dispositivos se denominan HSM o “Hardware Security Module”; y aunque existen aproximaciones de infraestructura de PKI que no lo emplean, es la solución más recomendable para obtener el nivel de seguridad adecuado para el entorno que nos ocupa.

Un HSM es un dispositivo hardware que crea, gestiona y almacena claves digitales con seguridad integrada. De forma general, los HSM se implementan como un dispositivo hardware dedicado, bien como tarjeta de ampliación para un ordenador personal, hasta un sistema diseñado para tal fin; en cualquier caso, la característica principal de este hardware es que incorpora un criptoprocesador seguro. Como es de esperar, más a la vista de las necesidades de seguridad del entorno, estos dispositivos se diseñaron para mitigar los riesgos de seguridad identificados, así como para optimizar todas las operaciones criptográficas que se tengan que realizar en cualquier entorno.


Diversos modelos de HSM de NCipher

En resumen, estos dispositivos se han diseñado con las siguientes finalidades principales:

  • Generación segura de claves criptográficas dentro del propio dispositivo.
  • Gestión y almacenamiento de claves criptográficas en el propio dispositivo.
  • Manipulación de información criptográfica o sensible.
  • Liberar a los servidores de aplicaciones de la carga del cómputo criptográfico.

Comencemos con un componente fundamental dentro de cualquier HSM: el criptoprocesador. Un criptoprocesador es un tipo de procesador especializado en la gestión y creación de claves criptográficas.

¿Qué diferencia a este procesador de cualquier otro? Como más de uno sabrá, se pueden generar claves criptográficas con cualquier tipo de procesador, lo que incluye cualquier procesador de cómputo general que podríamos encontrar en un ordenador personal cualquiera. Por lo tanto, ¿que nos aporta el uso de criptoprocesadores? En primer lugar, un criptoprocesador es un dispositivo de funcionalidad específica, que incluye instrucciones internas para gestión de claves criptográficas (cosa que un procesador de cómputo general no posee). Este hecho hace que sea mucho más eficiente en la generación de claves que un procesador normal, una de las ventajas más conocidas de implementar funciones en hardware.

Ahora, ¿qué es un criptoprocesador seguro? Un criptoprocesador seguro garantiza que todo el procesado de claves se genera de forma interna, por lo que en ningún momento sale del dispositivo ningún tipo de información sin cifrar. El objetivo básico de este tipo de dispositivos es asegurar que no es necesario aplicar medidas de seguridad al resto del sistema, ya que el criptoprocesador implanta medidas de seguridad que garantizan que no se libera información sensible al resto del sistema y dotando al dispositivo de resistencia a intentos de manipulación. Algunas medidas concretas de seguridad que se suelen implementar en estos dispositivos son las siguientes:

  • Detección y respuesta ante manipulación.
  • Placas protectoras de conductividad para evitar la captura de señales internas del dispositivo.
  • Ejecución controlada que asegure que no se producen retrasos temporales que puedan liberar información secreta.
  • Borrado automático del dispositivo cuando se detecta cualquier tipo de manipulación.
  • Controles de ejecución de sistema operativo o aplicaciones basados en cadena de confianza, para así asegurar su autenticidad.

Gran parte de estos dispositivos se han diseñado para el uso de criptografía de clave simétrica y asimétrica. Estos en concreto, como es evidente, son los que son determinantes dentro del entorno de una PKI. ¿Qué requisitos son deseables en este dispositivo en una PKI? Veamos hoy uno de los puntos clave de estos dispositivos, el elevado nivel de seguridad lógica y física.

Esto es fácil de decir pero, ¿cómo lo medimos? Actualmente se han establecido estándares que miden los niveles de seguridad implementados en cualquier dispositivo criptográfico que combina el uso de hardware y software, como un HSM. Concretamente, el “National Institute of Standards and Technology” (NIST), desarrolló un estándar que permite establecer el nivel de seguridad ofrecido por este tipo de dispositivos. Dicho estándar se denomina “Federal Information Processing Standard” (FIPS), actualmente en su versión FIPS-2. Este es el estándar de facto en estos casos, y surge como una guía de requisitos deseables para el uso de dispositivos criptográficos para organismos gubernamentales o sujetos a normativas muy estrictas. El estándar establece cuatro niveles distintos, los cuales gradúan el nivel de seguridad del dispositivo evaluado. Se detallan a grandes rasgos los requisitos para cada uno de los niveles establecidos:

  • Nivel 1: Este es el nivel que podría tener cualquier ordenador personal con una tarjeta criptográfica genérica. En este nivel únicamente se requiere el uso de un algoritmo criptográfico y una función de seguridad reconocidos; no existen requisitos de seguridad física.
  • Nivel 2: De forma adicional a los requisitos establecidos por el nivel anterior, en este caso, se requerirán mecanismos de seguridad física que permitan identificar si se han realizado manipulaciones del módulo que hayan podido permitir un acceso no autorizado a las claves gestionadas en el módulo. Estos mecanismos deben ser desde sellos que se rompan cuando se accede al dispositivo que almacena las claves en claro o a los parámetros de seguridad críticos del dispositivo (parámetros que se almacenan en claro sobre los registros del criptoprocesador y que se emplean para generar las claves).
  • Nivel 3: Sumado a los requisitos incluidos en el nivel 2, se requiere que el dispositivo no sólo permita detectar accesos no autorizados, sino que responda a dichos accesos, uso no autorizado o modificación del módulo. Me explico, por ejemplo, un nivel de seguridad 3 sería un dispositivo que detectara su apertura y de forma automática y borrara por ejemplo los parámetros de seguridad críticos, inutilizándolo y asegurando la confidencialidad de las claves almacenadas.
  • Nivel 4: Del mismo modo que en los casos anteriores, en el nivel 4 se mantienen los requisitos de los niveles anteriores y se añaden nuevos requisitos. En este caso, aparte de requerir más capacidad de detectar intrusiones físicas, el módulo deberá detectar condiciones inadecuadas de humedad, temperatura o tensión que pudieran afectar a su funcionamiento. De este modo, se puede asegurar que se gestionarán estas contingencias y la confidencialidad de la información custodiada en el módulo.

Cualquier HSM para implementar una PKI deberá al menos tener un certificado FIPS-2, obteniendo un nivel 3. Más información respecto a este estándar puede obtenerse de http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

Espero que os haya parecido interesante. La semana que viene continuaremos con otros puntos clave de estos dispositivos tan interesantes.

APTs. Detectando movimientos laterales

25 de octubre de 2013 Por

Las APTs (Advanced Persistent Threats) conforman uno de los principales riesgos a los que se enfrentan hoy en día las empresas, organizaciones y estados. Su objetivo principal es sustraer de forma silenciosa, la mayor cantidad de información de sus víctimas, tratando de pasar totalmente desapercibidas (en algunas ocasiones persisten meses incluso años sin ser identificadas). Famosas fueron las campañas China APT-1, que hace sobre un año destapó “supuestamente” Mandiant o la Rusa con nombre en clave “Red October” detectada por Kaspersky.

A grandes rasgos estas amenazas presentan tres fases en cuanto a su despliegue y funcionamiento:

1º Fase de Análisis. Donde el atacante trata de obtener la mayor información posible de la organización víctima: direcciones de correo, usuarios, roles del personal, estructura jerárquica (aquí la web corporativa ayuda mucho…), etc. De esta fase hay una cosa curiosa y es que normalmente los objetivos más perseguidos no son los directores generales, altos cargos o personal de gran poder sino sus secretari@s. Esto es debido a que estos últimos son en última instancia los empleados que manejan la información más crítica, ya que son los encargados de leer el correo electrónico de su superior, contestar en su nombre o acceder en su lugar a recursos especialmente sensibles.

[Read more…]

Una visión global de la ciberseguridad de los sistemas de control (I)

24 de octubre de 2013 Por
(N.d.E. Este artículo fue publicado en el número 106 de la revista SIC, correspondiente a Septiembre de 2013. Sus autores son Óscar Navarro Carrasco, Responsable de ciberseguridad industrial, y Antonio Villalón Huerta, Director de seguridad. Ambos trabajan en S2 Grupo y pueden ser contactados vía onavarro en s2grupo.es y avillalon en s2grupo.es)
La ciberseguridad de los sistemas de control industrial y la protección de infraestructuras críticas se encuentra a caballo entre dos mundos: el de los expertos en seguridad y el de los profesionales de los sistemas industriales. Actualmente la aproximación a este problema se ha realizado exclusivamente desde una perspectiva, la tecnológica, posiblemente por incomparecencia de la otra parte. Sin embargo la aportación de ambas visiones del problema es fundamental para una adecuada protección de nuestras infraestructuras.

Es un hecho que la ciberseguridad de los sistemas de control industrial constituye una de los grandes asuntos del momento. Desde hace algunos años existe una preocupación generalizada acerca de las amenazas que se ciernen sobre estos elementos críticos para el funcionamiento de las sociedades modernas y su capacidad para enfrentarse a ellas. Sin embargo, el progreso es exasperadamente lento y, en términos prácticos, poco parece haberse avanzado. ¿Por qué? ¿Acaso la magnitud del riesgo no justificaría que se adoptasen medidas con la máxima urgencia?

Para descubrir la causa de esta aparente contradicción hay que comenzar por cuestionarse incluso lo que parece evidente. Y para empezar, nada mejor que repasar la primera afirmación de este texto:

¿Es un hecho que la ciberseguridad de los sistemas de control industrial constituye uno de los grandes asuntos del momento? ¿Constituye este asunto una preocupación generalizada?

[Read more…]

Bastionado de servidores ssh

23 de octubre de 2013 Por

Recientemente adquirí un servidor dedicado que utilizo para, entre otras cosas, compartir ficheros entre amigos. En principio, la compartición de ficheros se iba a hacer mediante HTTPS, por lo que el servidor SSH no tenía ninguna configuración fuera de lo normal. Bastó con algunos cambios de la configuración por defecto para tener algo un poco más robusto:

Port X
Protocol 2
ServerKeyBits 4096
LoginGraceTime 30s
PermitRootLogin no
MaxAuthTries 3
MaxSessions 2
PubkeyAuthentication yes
HostbasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
AllowUsers usuario

Sé que me he dejado varias cosas importantes, como toda la gama de los forwardings, y que cambiando el puerto en el que escucha el demonio SSH no se soluciona nada (seguridad por oscuridad)… excepto todos los intentos realizados por bots, que creedme, son bastantes.

[Read more…]