Cómo secuestrar la identidad digital de una persona (I)

16 de julio de 2014 Por

Hoy les vamos a mostrar el impacto que tiene perder su terminal móvil Android y no disponer de un código de seguridad o patrón de bloqueo robustos. Como se pueden imaginar por el título del post, la consecuencia va a ser el secuestro o suplantación de la identidad digital de la persona afectada. Comencemos…

Supongamos que soy una persona terriblemente malévola y que me he encontrado un teléfono Samsung Galaxy S4 en una butaca a la salida del cine. Este smartphone no dispone de bloqueo, por lo que a priori, lo primero que se me ocurre es que puedo llamar a mi novia en USA sin pagar ni un céntimo. Pues bien, esto es de lo mejor que le podría pasar a la pobre persona que ha perdido una parte de su cuerpo. Digo esto porque hoy en día nuestra vida completa la llevamos en el bolsillo convirtiéndose en una parte más de nuestro organismo, creando una necesidad que roza lo absurdo (conozco gente que duerme abrazada a su teléfono).

Lo siguiente que se me ocurre que se podría hacer es robar la cuenta de Gmail/Google de la siguiente manera:

    1. Obtengo la dirección de correo electrónico asociada en el terminal móvil, simplemente abriendo la aplicación de Gmail.

    2. Lanzamos los formularios de recuperación de contraseña a través de un navegador web en un ordenador. Haciendo click en ¿Necesitas ayuda? y posteriormente en “he olvidado mi contraseña”, le introducimos el correo electrónico que hemos obtenido en el paso 1.

    3. El asistente nos pregunta si recordamos alguna contraseña anterior, por lo que le diremos que “No lo sé”.

    4. A continuación Google nos deja elegir entre enviarnos a otra cuenta de correo electrónico el proceso de recuperación o… continuar a través del teléfono móvil asociado a la cuenta. Pincharemos en esta última.

    5. En este punto en nuestro ordenador aparece un aviso indicando que debemos autorizar a través del móvil, el cambio de contraseña. Siendo esta solicitud válida durante 10 minutos.

    6. Al instante en el terminal sustraído aparecen una serie de mensajes como los siguientes:

    7. Tras simplemente darle a “Permitir” podemos establecer la contraseña que nosotros queramos en el ordenador,obteniendo el control total de la cuenta de Google.

¿Pero que podemos hacer con una cuenta de Google? Por el momento acceder a todos los servicios asociados: Google+, GoogleDocs, Gmail, etc. Pero quizá uno de los más interesantes para un atacante pueda ser el Google Wallet, el cual te permite comprar productos, como: teléfonos móviles, tabletas, música o aplicaciones entre otros.

¿Interesante?

Seguiremos desde este punto en la próxima entrada.

Fundamentos sobre Certificados Digitales – Guía de uso seguro de Certificados Digitales

14 de julio de 2014 Por

Recientemente, el Centro de Seguridad TIC de la Comunidad Valenciana (CSIRT-cv), ha publicado una “Guía de uso seguro de Certificados Digitales”, esta guía vino precedida por una campaña de concienciación emitida en redes sociales. Formada por una serie de consejos de seguridad diarios, relacionados con el uso de certificados digitales. A este respecto, y dado que esta serie de entradas en Security Art Work dedicada a Fundamentos de Certificados Digitales está perfectamente alineada con los temas tratados en la guía, he considerado introducir la guía dentro de la misma serie.

Es importante destacar que, quizás un poco como contrapunto a los temas tratados en cada una de las entradas precedentes de la serie, la guía tiene una audiencia con menos orientación técnica que la que abarcan el resto de entradas, más cargadas de contenido técnico más enfocado a profesionales de TI y entendidos en la materia. Sin embargo, esto no debe desmotivar a este colectivo más avanzado, ya que posiblemente se tengan ciertos conocimientos sobre el uso de certificados digitales, aunque posiblemente no en todos los ámbitos tratados en la guía. Dicho lo propio, pasamos a la presentación de la misma.

El objetivo principal de la guía es informar y concienciar respecto del uso seguro de certificados digitales en la vida cotidiana, y su audiencia objetivo son el conjunto de los ciudadanos y empleados públicos. Dentro de ella, se facilitan conocimientos básicos de uso de certificados en las principales aplicaciones de uso habitual que tengan requerimientos específicos respecto a privacidad de la información, así como que requieran asegurar la autenticidad del remitente o tercero con el que contactamos. Todo ello tratando de ser lo más sencillo posible en las explicaciones, orientadas a su público objetivo. Destacar además que está estructurada como una guía de referencia, facilitando el acceso a los contenidos que se requieran en cada situación de forma sencilla y clara.

A modo de resumen de contenido, la guía da soluciones y recomendaciones específicas respecto a los siguientes puntos principales:

  • El DNI Electrónico: Hace unos años se produjo una modernización profunda del Documento Nacional de Identidad Español, desde entonces se ha convertido en el certificado digital obligatorio del que disponemos todos los Españoles, y que la gran mayoría desconoce.
  • Certificados de Persona Física o Empleado Público: Se trata de certificados digitales identificativos de propósito general y son emitidos por Autoridades de Certificación de confianza. Permiten identificar a su propietario telemáticamente, así como cifrar comunicaciones digitales.
  • Uso de Certificados Digitales en correo electrónico: Se incluye un dedicado al correo electrónico, el medio de comunicación de uso más difundido en Internet. Del mismo modo que cualquier medio de comunicación digital que transmite datos por redes públicas requiere que se tengan en cuenta los requisitos de seguridad pertinentes; y como suele ser habitual, centrados en la confidencialidad de la información compartida, así como la autenticidad de la misma.
  • Navegación Segura: Del mismo modo que se puede emitir un certificado digital para una persona se puede emitir un certificado para un sitio web. En este caso, el certificado garantiza identificar inequívocamente al sitio web al que nos conectamos y a su vez implementa cifrado en todas las comunicaciones entre cliente y servidor. Por tanto, se debe verificar sin lugar a la calidad y fiabilidad del certificado cuando conectamos a un sitio web que por ejemplo, maneje información sensible.
  • Firma de código: Esta capacidad permite firmar código fuente de las aplicaciones que vamos a instalar en nuestros equipos. Cuando un código no está firmado o no está firmado por una entidad de confianza corremos el riesgo de que se haya modificado fraudulentamente, y muy posiblemente pueda ejecutar acciones maliciosas en nuestros ordenadores. Cada vez que instalemos un programa deberíamos asegurar su origen, integridad y su legitimidad.
  • Firma de documentos digitales: Cuando se firma un documento digital, dicha firma tiene la misma validez que una firma manuscrita; además asegura que el documento firmado no ha sido alterado o modificado. Del mismo modo, es fundamental poder identificar la legitimidad de la firma implementada en cualquier documento.

Por último, se incluye información adicional sobre la solicitud y gestión de certificados con la Agencia de Tecnología y Certificación Electrónica de la Comunidad Valenciana (ACCV), que es una Autoridad de Certificación de reconocida confianza y opera dentro de la Comunidad Valenciana, facilitando certificados digitales reconocidos gratuitos para los ciudadanos.

Como conclusión y en mi humilde opinión, me gustaría hacer un pequeño análisis de la situación actual respecto al uso de esta tecnología. En muchas ocasiones me gusta emplear la frase “Los certificados digitales, esos grandes desconocidos…”, y esa es por desgracia la realidad, y es que la mayoría de los usuarios de medios tecnológicos e internet los usan en su vida diaria, aunque no sean conscientes. Los certificados digitales están cada día más extendidos en los servicios TI; empleándose comúnmente para asegurar la confidencialidad, autenticidad y trazabilidad de la información en la red.

Los certificados son un mecanismo muy potente y muy seguro; pero como suele pasar en la gran mayoría de los casos, por seguro que sea, si se hace un uso negligente de los mismos pueden conllevar muchos más riesgos que beneficios. No seamos alarmistas, el objetivo de la guía no es ni mucho menos asustar a la audiencia, sino ayudar a poder emplear estos mecanismos de forma segura y para ello la mejor base es conocer los riesgos a los que nos enfrentamos, pero siempre desde una óptica de confianza. De ese modo los certificados nos podrán ayudar a aprovechar todas las ventajas y servicios que nos ofrece la sociedad de la información en la actualidad con total seguridad.

La “Guía de uso seguro de Certificados Digitales” se encuentra disponible en este enlace, dentro del portal Web de CSIRT-cv, y también desde la sección de descargas de dicho portal.

Personalmente, como siempre agradecido por vuestra atención y recordaros que estamos a vuestra disposición desde Security Art Work.

Un saludo a todos. Os deseo un feliz y seguro verano.

PFsense: firewall perimetral (II)

10 de julio de 2014 Por

En esta segunda parte se explican las configuraciones previas a la utilización del firewall.

Recordemos el artículo anterior, donde las configuraciones de las interfaces quedaban de este modo:

Pues ahora hay que cambiar la interfaz de red del Anfitrión (máquina real no virtualizada), para que se pueda acceder vía web a pfsense. En este caso podemos acceder desde una dirección IP perteneciente a la red interna (192.168.1.0/24), quedando así la configuración de la interfaz del anfitrión:

Para acceder solo debemos poner en el navegador http://192.168.1.2 e introducir las credenciales por defecto. Usuario “admin” y Password “pfsense”.

Nos aparecerá una ventana como esta:

La primera vez que se entra, se accede a un “Wizard”, es decir a una configuración paso a paso:

La primera parte es donde se configuran las direcciones de los Servidores DNS, el nombre de la máquina y el nombre del dominio, en este caso se configura con las DNS de Google.

El dominio llamado en este caso “mired”, facilita mucho las cosas a la hora de acceder a un equipo, ya que podemos comunicarnos por ejemplo con un equipo llamado “oficina”, poniendo únicamente oficina.mired, o en este caso para acceder a pfsense en lugar de poner http://192.1681.2 se puede poner http://pfsense.mired.

En esta misma página de configuración existen otras opciones que en este caso no nos hacen falta como es la configuración PPOE. En el caso de que queramos conectar un router en modo “bridge”, es decir que tenga NAT deshabilitado y todo el tráfico vaya directo hacia el firewall pfsense, pero este no es el caso.

Por último la sincronización de la hora y fecha del equipo se hace a través de un servidor ntp, podemos elegir la zona horaria, en este caso la de Madrid:

Seguidamente, una vez que procedemos a dar “next” se pasa a la configuración de las interfaces previamente seleccionadas antes en la configuración.

La primera interfaz (WAN), la interfaz que se conecta a internet (vinculada a la interfaz wlan0 del anfitrión), está configurada por DHCP, siempre se podrá configurar de forma estática, simplemente deberá coincidir con el rango de esta red (192.168.0.0/24).

En la configuración general es importante incluir la dirección MAC de la interfaz WAN, es decir en este caso la MAC de wlan0. Si pfsense estuviera conectado a un router, deberíamos poner la MAC de la boca de red a la que está conectada el router, para evitar posibles ataques de tipo “spoofing”.

En la parte de abajo aparece una opción llamada “Block logonnetworks”, si esta opción está activada, se bloquearán redes a través de la interfaz WAN que sean de tipo privado, es decir, no dejará que una dirección IP de fuera del tipo 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, y 169.254.0.0/16, entre a través de WAN.

Configuración de la red interna:

El último paso es cambiar la clave de acceso web, algo muy recomendable.

Al terminar la configuración, pfsense muestra una “Dashboard”, donde se muestra un resumen de la configuración, de la carga de CPU y memoria utilizada y el estado de las interfaces de red.

En el siguiente artículo se profundizará más en la configuración avanzada de pfsense.

Cuando los clientes son sus propios enemigos

7 de julio de 2014 Por

Algunas veces por desconocimiento. Otras por simplicidad. Algunas otras por hacer las cosas rápidamente, pero la mayoría por desconfianza, nos ponemos trabas a nosotros mismos en lo que respecta a la seguridad informática. Y es que lo que para un experto en seguridad puede ser complicado de diseñar y configurar, se hace un mundo para el cliente final.

Para mí hay dos conceptos a tratar en cada situación a estudiar, de hecho, casi es extrapolable a cualquier entorno informático: comunicaciones, sistemas, desarrollo… Una es la relación con el cliente, y otro la situación en la que se encuentra el mismo.

En lo referente a la situación en la que se encuentra, casi nunca trabajamos en el entorno ideal. No disponemos muchas veces de tiempo, de capacidad de reacción, de ventana de disponibilidad para trastear, o incluso de una maqueta de pruebas previa a la intervención. De hecho, casi nunca se tiene toda la información necesaria para poder trabajar, e incluso tenemos que buscar por nuestra cuenta casi todo lo que necesitemos para poder empezar. En este campo poco podemos hacer, es un trabajo de concienciación a todos los niveles, que aunque parece que se va cambiando poco a poco, no depende enteramente de nosotros, pues requiere de un esfuerzo adicional que poca gente está dispuesta a hacer.

Pero lo que respecta al trato con el cliente, podemos hacer más de lo que creemos. Somos capaces de pasar horas auditando, valorando cada situación, estudiando las diferentes posibilidades y buscando una solución final adecuada, pero no de pensar ni 5 minutos en cómo se lo vamos a presentar al cliente. Es casi tan importante saber hacer entender lo que tratamos de conseguir, como el mero hecho de desarrollarlo.

Debemos saber entender lo que realmente se necesita en cada momento, valorando la seguridad para el propio cliente, como el uso que vaya tener en el día a día. Hemos de situarnos en su posición, y desarrollar una solución que entienda, y sea factible a su modo de ver. Que no le complique su trabajo día a día, pero que cumpla con la seguridad necesaria. Quizá de nada le sirva a una empresa de patatas, tener la seguridad de un búnker militar. Esto es primordial para desarrollar una solución, pero también para poder hacerle entender con sus propias palabras, el porqué de la misma, y el por qué ha de emplear recursos, tiempo o dinero en aplicarla.

Nuestra faena no acaba con la implementación de la seguridad. Tenemos que ser capaces de hacer entender a nuestro cliente, que lo que estamos haciendo es ante todo para proteger sus datos. Para garantizar que nadie se apropia de su información sensible. Que aunque añadamos un poco de complejidad a su día a día, siempre el mínimo posible, va a poder tener la confianza de que limitaremos las posibles fugas de datos. Explicándoselo con sus propias palabras, y con su propia mentalidad. Y esto, es harto difícil.

De nada me sirve utilizar cuatro protocolos de seguridad indescifrables, o utilizar casos que nada tienen que ver con el suyo. Tampoco explicarle que me he hecho pasar por un hacker que trabaja desde Uganda para poder acceder a su clave de wifi. Tenemos que hablar su idioma, y valorar sus propias inquietudes.

No nos engañemos, aún tenemos que hacer mucha concienciación. Debemos exponer bien nuestros argumentos, hacer demostraciones, enseñar porque necesitan dicha seguridad. Mostrarles que los amigos de lo ajeno, no llevan antifaz y una bolsa con el símbolo del dólar impreso, muchas veces están detrás de un ordenador. Hacerles entender que no sólo es necesario poner una alarma en las puertas de las empresas, sino asegurar que ponemos sus datos a salvo. En definitiva, ganarnos su confianza. Y hacer eso, es lo más difícil a lo que nos enfrentaremos.

Permisos en Android y malware, el nuevo “He leído las condiciones del contrato”

3 de julio de 2014 Por

El malware no es nuevo a día de hoy, y uno de los sectores en los que más está creciendo es en el campo de los dispositivos móviles debido al auge continuo de smartphones y tablets. Un ejemplo de ello es la cifra proporcionada en el reciente Google IO 14 de 1000 millones de dispositivos Android activos actualmente.

Hace unos días aparecía un informe de McAfee donde se destacaba la cantidad de clones del juego Flappy Bird que cuentan con algún tipo de malware en su código. Curioso. Con este dato decidí hacer una revisión rápida a esa colección de clones para centrarme en los permisos solicitados por cada uno de ellos.

Pero claro, ¿cómo saber si son un exceso de permisos o no? Para ello, empecemos con nuestra propia lógica: es un juego sencillo que lo único que hace es guardar una puntuación máxima y de vez en cuando sale algún anuncio, por lo que deberíamos esperar al menos los permisos de conexión a internet y de almacenamiento. Casualmente decidí probar el juego en su momento y aún dispongo de acceso al mismo en mi historial de Google Play, así que pude acceder a ver los permisos que realmente necesitaba la aplicación:


Los permisos originales del juego.

Al final resulta que solo necesita tres permisos, los cuales son aceptables para lo que se espera de la aplicación. Sin embargo, a la hora de ver otras similares, nos encontramos con el siguiente abanico de opciones extra que debemos autorizar o no en función del clon elegido:


Recopilación de los múltiples permisos que pueden solicitar los clones. No es la lista de permisos de una aplicación.

Hasta cierto punto algunos de estos permisos son razonables. Por ejemplo, buscar cuentas en nuestro dispositivo para publicar nuestra última puntuación en la red social correspondiente: no nos garantiza que junto a nuestra marca personal además añada publicidad de otros productos ajenos al juego (un enlace a una web que oferta productos de China). Sin embargo, ¿por qué deberíamos permitir averiguar nuestra localización? ¿Es necesario para el caso anterior de compartir nuestro récord? ¿O realmente tiene otro propósito?

Instalando una de las aplicaciones en un dispositivo limpio (sin tarjeta SIM, formateado de fábrica y sin ningún dato de cuenta introducido) nos encontramos con la siguiente imagen. Referida al compartir lo que suponemos que era la tabla de récords, dado el inconveniente que nos encontramos con el idioma de la misma (coreano, concretamente). Las dos primeras redes sociales no hay problemas en reconocerlas, ¿pero las dos siguientes? ¿Y la opción de compartir por correo? ¿En verdad alguien la usa para enviar ese tipo de información?

No hay duda de que Google trabaja en mantener limpio su mercado de aplicaciones, pero se ve que hace falta mucho más control para evitar ya de base la posibilidad de subir aplicaciones comprometidas, y más aún si logran tener cierto éxito. Otro caso similar relativamente reciente fue el de las aplicaciones del tipo linterna que suscribían a servicios SMS de pago y conseguían ocultarlo hasta que llegaba la factura del mes, con permisos para leer SMS entre otros. ¿Nadie se extraña de eso en una aplicación que lo único que tiene que hacer es encender un LED?

Y es que al final la culpa no es solo de quien proporciona acceso a la descarga de la aplicación, sino también del propio usuario que por no gastar quince segundos mirando los permisos de la aplicación puede acabar pagando hasta 30 euros extra a fin de mes, junto a algún que otro susto.

Como consejo final, decir que si revisáis un contrato o una factura antes de firmarlo, ¿por qué no hacer lo mismo con el móvil y las aplicaciones que instaléis?

Impresiones con Autopsy3

2 de julio de 2014 Por

Recientemente he utilizado la versión 3 de Autopsy, la popular interfaz web de The Sleuth Kit, con idea de ver las novedades respecto a la versión anterior (v2). El hecho de estar acostumbrado a la versión 2, que la v3 sólo estuviera para Windows y además fuese basada en Java, habían hecho que hasta ahora no me hubiese decidido a probarla

Finalmente me he decidido y estas son algunas impresiones que he tenido.

La primera impresión que se tiene de la interfaz de usuario es que es bastante más amigable, moderna y usable que su antecesora web, con un acceso mucho más ágil a las diferentes partes de la aplicación. Una característica que he visto muy útil es el módulo de Ingest y la posibilidad de seleccionar los plugins que van a utilizarse; de esta forma, para ganar algo de tiempo, podemos realizar una ingesta de datos con un único plugin para tener algo sobre lo que trabajar y, mientras realizamos un análisis preliminar, podemos dejar cargando y procesando el resto de plugins.

Uno de los plugins que nos puede ahorrar algo de tiempo a la hora de descartar archivos conocidos sin manipular es la base de datos de hashes, que compara el hash de los archivos con dicha base de datos. La base de datos que es de obligada descarga es la NSRL del NIST, National Software Reference Library, con un tamaño actual de 6 GB de software conocido (tanto bueno como “malo”). No obstante, hay que recordar que no contiene entradas de malware sino más bien herramientas consideradas para hacking, desde nmap a herramientas de esteganografía. Otra pega es que, al parecer, sólo contempla versiones de software por defecto sin tener en cuenta las actualizaciones, por lo que puede crear falsos positivos o alertarnos ante archivos sospechosos aunque que se trate de actualizaciones lícitas.

Para utilizar esta base de datos tendremos que descargar la base de datos unificada, o bien las otras opciones más reducidas que también nos ofrece; y la importamos de la siguiente manera:

Tras lo que tendremos que indexar el contenido:

Una vez hecho esto, ya podemos realizar una nueva ingesta con el plugin del hash database activado, seleccionando la base de datos del tipo NSRL. Si queremos utilizar una base de datos de malware, tendremos que recurrir a algunas de pago o utilizar servicios online de consulta de hashes que nos dirá, uno a uno, si se reconoce como malware. Entre esos servicios online tenemos la Hash Database de SANS, OWASP File Hash Repository, Malware Hash Registry de Team Cymru, o VirusTotal, entre muchos otros.

El proceso de ingesta tardará dependiendo del tamaño de la imagen y la potencia del equipo, pero nos mostrará una columna con el resultado del hash y si se encuentra en las bases de datos (known/unknown en la NSRL o bad-known si tuviéramos otras de malware. A partir de ahí, podemos descartar aquellas detectadas como known y, aquellas que sean unknown y tengamos dudas, podemos utilizar dichos servicios online copiando el hash del archivo seleccionado.

Para sacarle un defecto que le he encontrado, aparte del hecho que he tenido que configurar el idioma del sistema al inglés debido a problemas de Java con el Timeline y las fechas, es que, no sé si debido a la diferencia entre el número de eventos entre meses u a otro, han desaparecido los eventos de enero y febrero, sin posibilidad de seleccionarlos en el Timeline, con lo que he tenido que sacarlos a través de búsquedas en esas fechas.

Para poder mostrar los archivos modificados en enero y febrero he tenido que recurrir a búsquedas filtradas por esas fechas. En su defensa diré que está funcionalidad aún se encuentra en estado Beta, por lo que son normales estos errores.

La verdad es que he visto una versión más moderna, completa y ágil de utilizar y, a pesar de algunos pequeños detalles, me ha convencido bastante.

La odisea de (intentar) hacer las cosas bien…

1 de julio de 2014 Por

Hace unos días, Antonio Sanz comentaba en su post “He descubierto una vulnerabilidad: ¿Y ahora qué?” las distintas opciones que existen cuando se encuentra una vulnerabilidad de seguridad.

En este post, pretendo contar mi experiencia acerca de un responsible-disclosure que llevo coordinando desde octubre de 2013. Para situar al lector en contexto, decir que en dicho mes encontré un par de fallos de seguridad en un dispositivo HMI (Human-Machine-Interface) perteneciente a un sistema de control industrial. Explotando las dos vulnerabilidades de manera simultánea, la situación se puede volver algo “peliaguda” para el operador del sistema, lo que no es ningún tipo de consuelo si tenemos en cuenta la finalidad de los sistemas que son vulnerables.

Nada más encontrar la vulnerabilidad, realicé una pequeña búsqueda de buzones de contacto de la empresa, para ponerme a hablar directamente con ellos y agilizar el trámite. A día de hoy, todavía espero respuesta.

La segunda opción fue contactar con el ICS-CERT, la organización encargada de lidiar con este tipo de problemas en cuanto a sistemas industriales se refiere. Amablemente, al día siguiente nos comunicaron que se iban a poner en contacto con el fabricante para poder solucionar el problema.

Sin embargo, no es oro todo lo que reluce, y tras varios intentos infructuosos de contactar con el fabricante, ICS-CERT decidió gestionar el incidente con otro CERT, ya que sería más fácil para este último ponerse en contacto con la empresa en cuestión. Tras verificar qué versiones del dispositivo son vulnerables, miramos el reloj y nos damos cuenta de que ya estamos en Navidades, con lo que entre vacaciones y fiestas, retomamos las conversaciones un 8 de enero de 2014, cuando nos dicen que van a preguntar al otro CERT para ver el estado de la vulnerabilidad.

La siguiente noticia que tenemos es un 13 de febrero, cuando nos confirman que el fabricante ha verificado la existencia de la vulnerabilidad y nos comunican que van a investigar si ésta afecta a más equipos, mientras trabajan para solucionarla; contactamos con otro CERT, gubernamental, para ver si a ellos les hacen más caso, pero parece que no… Nosotros, por nuestra parte seguimos insistiendo para conocer el estado del incidente, hasta que un 29 de abril nos confirman que el estado sigue siendo el mismo que en febrero.

Más tarde, en mayo nos informan de que el fabricante ha hecho públicas las vulnerabilidades, y que ICS-CERT va a crear un advisory (toma ya, nosotros callados y estos van y…). Ya en junio, el mismo ICS-CERT nos comunica que las vulnerabilidades sólo afectan a los productos vendidos internacionalmente (si yo fuera desconfiado, sospecharía…), y que el fabricante no notificará a sus clientes nacionales, pero sí a los extranjeros; la fecha estimada para ello es mitad de junio o principios de julio (por suerte para ellos, en el correo no dicen si será este julio, o el de dentro de diez años, cuando el producto ya esté obsoleto, y por tanto, nadie lo tenga).

En resumen, llevamos desde octubre de 2013 y hemos llegado a julio de 2014 y la vulnerabilidad es conocida desde hace nueve meses por parte del fabricante. Sin embargo, el cliente final, quien es realmente vulnerable, no lo sabe. Por estos motivos, hemos decidido hacer pública la vulnerabilidad en los próximos días. Seguid conectados. Para animar la espera, podéis comentar vuestras experiencias al reportar vulnerabilidades en los comentarios de esta entrada.

PD Nada que reprochar ni al ICS-CERT ni a ningún otro de los CERT que han intentado, junto a nosotros, hacer las cosas bien… creemos que el principal, y único, problema, lo ha aportado el fabricante…

Tercer informe sobre Protección de II.CC. de S2 Grupo. La información está ahí fuera

26 de junio de 2014 Por

Continuando con la línea de trabajo iniciada con los dos anteriores informes sobre protección de infraestructuras críticas S2 Grupo acaba de publicar la tercera entrega. En esta ocasión nos hemos fijado en un problema creciente del que no se habla demasiado: la disponibilidad de información detallada sobre nuestras II.CC. libremente accesible a través de internet, especialmente en lo referente a sus instalaciones, procesos, sistemas de control, procedimientos de operación y, por último, organización y gestión de la seguridad.

En SAW ya hemos hablado de este asunto en alguna ocasión (véase, por ejemplo, esta entrada en el blog). Sin embargo, la gravedad de la cuestión merece una aproximación más sistemática que nos permita hacernos una idea clara de la magnitud del problema. Así, al iniciar la investigación que ha dado lugar al informe nos planteamos responder a las siguientes preguntas:

  • Descubrir qué tipo de información está disponible en internet acerca de nuestras II.CC.
  • Determinar el origen de la información.
  • Estimar el grado de riesgo que puede suponer el uso de la información hallada por parte de un atacante.
  • Establecer si existe alguna diferencia entre los distintos subsectores en que se divide el conjunto de II.CC.
  • Analizar los resultados obtenidos para dibujar un cuadro general que nos permita avanzar conclusiones al respecto.

El foco de la investigación se puso en aquellos sectores considerados críticos según la Ley 8/2011 en los que se hace un uso extendido de sistemas de control industrial. De esta forma nos hemos quedado con:

  • Sector sanitario.
  • Energía.
  • Trasporte.
  • Industria química.
  • Industria nuclear.
  • Abastecimiento de agua.
  • Alimentación.
  • Administración.
  • Sector aeroespacial.

El trabajo ha consistido en la búsqueda en internet de información relativa a sistemas de control, procesos, seguridad física y lógica, equipamiento y maquinaria, etc. de una organización destacada de cada uno de los sectores. Las búsquedas se han realizado entre los meses de noviembre de 2013 y febrero de 2014.
Una vez obtenida la información, esta se ha caracterizado y clasificado para determinar:

  • El tipo de información.
  • El contexto en el que está contenida.
  • El origen.
  • La consideración subjetiva del impacto que podría suponer el uso de esta información. Se han establecido tres niveles: bajo, medio y alto.

Es importante subrayar que la idea detrás de esta investigación no es realizar una campaña exhaustiva de localización de información, algo que, por otra parte, es casi imposible, sino obtener una visión cualitativa de la magnitud del problema, sus causas y posibles soluciones.

Los resultados de la investigación

Se ha localizado información de prácticamente todos los sectores analizados con alguna excepción notable, como el caso del aeroespacial. Los principales canales por los que se difunde son:

  • Proyectos de fin de carrera y tesis doctorales
  • Pliegos de contratación de las Administraciones públicas
  • Casos de éxito de proveedores
  • Publicaciones técnicas especializadas en cada sector
  • Artículos técnicos

Nuestra investigación pone de manifiesto que la información es elaborada y publicada por todos los actores participantes en la vida de una II.CC. El papel de terceros tales como empresas constructoras o contratistas de mantenimiento es poco sorprendente. Sí lo es, en cambio, el hecho de las propias AA.PP. o empresas operadoras de II.CC. ofrezcan tanta información y con tanto detalle acerca de sus propias instalaciones. Una mención específica merecen ciertas universidades que se constituyen en auténticos repositorios online de información técnica muy específica.

En ocasiones los propios empleados ofrecen información fuera de la actividad diaria de la compañía; es el caso de los artículos técnicos publicados con el conocimiento (o no) de sus organizaciones. Hemos localizado, por ejemplo presentaciones elaboradas por personal de una I.C. para su empleo durante un curso de formación. El material describe exhaustivamente componentes y sistemas de la I.C. ofreciendo, incluso, detalles de la operación, gestión, etc., todo ello con abundante material gráfico.

Adicionalmente hemos querido cuantificar los resultados obtenidos. Para ello hemos realizado un análisis en que:

  • A cada sector se le ha asignado un valor de probabilidad entre 1 y 3, que cuantifica la facilidad de localizar información.
  • Además, se ha valorado, nuevamente de 1 a 3, el impacto posible de la información localizada.

El producto de ambas variables constituye el riesgo calculado para cada sector. Este valor se ha ponderado considerando el tamaño relativo de cada sector medido como el número de empleados. La razón para esto es que en lo relativo a la disponibilidad de información, el factor definitivo detrás del problema son las personas: esto es, la solución pasa por modificar la forma en que las personas gestionan la información dentro de cada organización. De esta forma, es más fácil que se filtren documentos sensibles cuanto mayor sea el número de personas que intervengan en su custodia, clasificación o difusión.

Los resultados se muestran en la siguiente gráfica:

Del análisis del gráfico extraemos las siguientes conclusiones:

  • Los sectores con un menor número de empleados, como el aeroespacial o la industria nuclear, no suponen un grave problema a pesar de las ideas a priori acerca del impacto de un ataque sobre estas infraestructuras. Un tamaño pequeño del sector significa que una situación de riesgo (en cuanto a la gestión de la información) es abordable de forma manejable, dado el reducido número de personas implicado (lo que facilita la labor de cambiar procedimientos, establecer políticas, avanzar en la concienciación, etc.)
  • Los sectores de agua, industria química y alimentación se encuentran en la zona alta tanto en cuanto a riesgo como a magnitud del problema, entre otras cosas a causa del elevado número de personas que trabajan en estas organizaciones.
  • Algo similar ocurre con el transporte, que si bien no posee un valor de riesgo alto sí se encuentra en una situación difícil debido a su tamaño.
  • Se evidencia el grave problema que supone la gestión actual de la información en la Administración Pública y organizaciones afines. En el origen están los requerimientos de publicidad exigidos en los procedimientos de contratación.

Conclusiones

El estudio realizado, si bien limitado por necesidad, pone de manifiesto un problema al que generalmente se concede poca o nula consideración cuando se habla de la ciberseguridad de sistemas de control industrial y su relación con la protección de infraestructuras críticas: la absoluta inconsciencia con la que se maneja y hace pública información sensible de gran interés para posibles atacantes. Ello es especialmente grave en un contexto en el que el diseño de una APT tiene como un elemento esencial el conocimiento profundo de la organización objetivo, tanto para diseñar el malware como los mecanismos de infección (por ejemplo, la planificación de un ataque de ingeniería social).

El tipo de información y los mecanismos de publicación son diversos, pero hay uno que destaca sobre todos los demás: las licitaciones de concursos públicos.

El segundo mecanismo que se encuentra detrás de la proliferación de información sensible es la necesidad, a medias científica y a medias comercial, de mostrar las propias habilidades, de forma que se publicitan las propias referencias con todo tipo de detalles. Cuando se mira desde el punto de vista de la ciberseguridad, no deja de resultar chocante la cantidad de información detallada que se ofrece al público general, en ocasiones ante el desconocimiento del promotor o titular y en otros casos con la aquiescencia cuando no la propia participación del mismo.

Independientemente de que la seguridad por oscuridad no es una opción válida, no debe olvidarse que, del mismo modo que el primer paso en un ataque es la recopilación de información, el primer paso de una estrategia de defensa debe ser el control de la misma.

Líneas de acción propuestas

¿Qué puede hacerse para afrontar este problema? Las líneas de trabajo básicas propuestas en el informe son las siguientes:

  • Analizar la legislación en lo relativo a contratación pública para compatibilizar las exigencias de publicidad y libre concurrencia con la necesidad de salvaguardar cierta información.
  • Realizar sesiones de concienciación en las organizaciones mostrando el riesgo que supone el uso de cierta información por parte de agentes malintencionados.
  • Establecer políticas de clasificación de la información en todos los ámbitos.

Para terminar

La investigación realizada pone de manifiesto el grave problema existente con la proliferación de información descontrolada en internet en relación con nuestras II.CC. El principal problema, de hecho, es la absoluta falta de conciencia acerca de las posibles consecuencias con la que se maneja esa información. Como siempre, las personas son parte fundamental en la cadena de la seguridad y, en este ámbito, queda mucho trabajo por hacer.

El informe completo está disponible para su consulta en este enlace.

Referencias
[1]Ley 8/2011. Boletín Oficial del Estado, núm. 102, sec. I, pág. 43370. Abril de 2011.
[2] Resolución de 15 de noviembre de 2011 de la Secretaría de Estado de Seguridad. Boletín Oficial del Estado, núm. 282, sec. III, pág. 124147. Noviembre de 2011.
[3] Ley 30/2007 de 30 de octubre de Contratos del Sector Público
[4] 1er Informe sobre la protección de infraestructuras críticas en España. 2011. S2 Grupo.
[5] 2º informe sobre la protección de infraestructuras críticas en España. 2012. S2 Grupo.

He descubierto una vulnerabilidad: ¿Y ahora qué?

23 de junio de 2014 Por

Imaginemos que Pepe es una persona con conocimientos de seguridad informática que, por simple curiosidad, se dedica a investigar en busca de posibles fallos de seguridad.

Una noche, a las 3.00AM, descubre un fallo de seguridad grave en un SO para móviles que permite al atacante hacerse con el control total del teléfono. Pepe sabe perfectamente que tiene en sus manos una vulnerabilidad gravísima, para la que hasta donde él sabe no hay solución posible, lo que se denomina un 0-day [1].

Nervioso, Pepe piensa en lo que podría hacer, y multitud de posibilidades saltan a su mente.

Podría simplemente publicarlo en su blog de seguridad bajo lo que se denomina full disclosure (revelación completa) [2], y directamente dar acceso a todo el mundo a la información para que se pudiera fabricar una solución. Esto le aseguraría ser el primero en publicarla, y ganar reconocimiento como investigador (en un mundillo en el que la reputación cuenta, y mucho).

Pero al dar la información al mismo tiempo tanto a fabricantes como a los posibles intrusos, Pepe provocaría una carrera en la que seguramente los usuarios serían los damnificados (el proceso de parchear una vulnerabilidad conlleva un proceso de control de cambios, que es por fuerza mucho más lento que el desarrollo de un exploit que solo necesita aprovecharse de la misma).

Otra opción sería ponerse en contacto con el fabricante del SO e informarle del fallo de seguridad bajo lo que se llama responsibledisclosure (revelación responsable) [3], dándole tiempo para que pueda preparar el parche que la resuelva antes de su publicación. De esta forma Pepe seguiría llevándose el mérito, pero no pondría en peligro a los usuarios al disponer de la solución al mismo tiempo de su publicación.

Puede suceder que el fabricante ignore a Pepe (ya sea por falta de canales de comunicación eficaces, o por política de la empresa). En este caso Pepe podría acudir a un CERT como el del INTECO [4], que se encargaría de contactar con la empresa (y así le daría una cierta cobertura a Pepe en el caso de tener luego problemas)… o pasar a la opción anterior y revelar directamente la información en Internet.

En el caso en el que Pepe estuviera más interesado en una ganancia económica más que de prestigio (que la fama no paga la conexión a Internet), tendría también varias opciones.

Lo primero que podría hacer Pepe es comprobar si el fabricante ofrece algún tipo de programa de bug bounty (caza de fallos) [5], en los que el fabricante ofrece recompensas por encontrar fallos de seguridad que pueden ir desde camisetas exclusivas hasta dinero contante y sonante. Esta opción es interesante porque en casi todos los programas hay un “Hall of fame”, que permitiría a Pepe a su vez ganar reconocimiento por haber encontrado el fallo.

El problema de esta opción es que casi siempre los fabricantes pagan poco. Muy poco. Si Pepe lo que quiere realmente es el dinero (y su ética personal es lo suficientemente laxa), tiene otras alternativas mucho más ventajosas.

Pepe podría llevar su fallo de seguridad a sitios como ZDI (Zero Day Initiative) [6], que ofrecen recompensas por fallos de seguridad bajo el modelo de responsibledisclosure. Estas empresas luego ofrecen servicios de alerta temprana (Pepe sabe que pocas empresas dan algo gratis), pero al final la vulnerabilidad se soluciona, y Pepe tiene más dinero en el bolsillo (y sobre todo, estas iniciativas son una buena opción en caso de que el fabricante no tenga un bug bounty en activo).

Pero donde está el dinero de verdad es en la venta privada: Pepe podría vender su 0-day a empresas especializadas en la compra de vulnerabilidades, pero que en lugar de publicar la información la guardan y crean exploits que pueden vender de forma privada. Algunas de estas empresas como Vupen [7] tienen una política estricta de ventas (en principio solo a países “buenos”), aunque no se sabe dónde pueden acabar ni para qué pueden ser usados. Por tener tienen hasta listas de precios [8].

El tema es que el precio es bueno. Muy bueno. Se rumorea que se ha llegado a pagar hasta 250K$ por un 0-day muy similar al suyo, que puede ser fácilmente diez veces más de lo que el fabricante o iniciativas como ZDI podrían pagar. Eso sí, Pepe no puede decirle nunca a nadie lo que ha hecho, por la cuenta que le trae (es lo que tiene trabajar con empresas que trabajan con gobiernos que tienen agencias de tres letras).

Podría ser que Pepe no estuviera interesado en ser “fichado” por estas empresas (nunca se sabe las vueltas que da la vida). En ese caso podría acudir a algún bróker de vulnerabilidades [9], que por una módica comisión se encargaría de hacer de intermediario con las empresas pertinentes y le ayudaría a mantener su preciado anonimato.

Pero estos bróker no crecen debajo de las piedras (y no son especialmente accesibles). Y Pepe quiere el dinero. La última opción que le queda es venderlo en el mercado negro [10], en el que hay multitud de lugares en los que venderlo. Y en algunos de ellos le pueden pagar en preciosas e irrastreables BitCoins. Y si Pepe tiene muy pocos escrúpulos, no creo que tenga muchos problemas en venderlo en varios lugares a la vez…

Estas son las opciones que Pepe baraja en su mente a las 3.00AM mientras toma su décimo café del día…

Si pasamos de la ficción a la realidad, el problema existente está bastante claro: Los incentivos económicos son mucho más atractivos que el mero reconocimiento, e incluso los programas que mezclan ambos aspectos se quedan cortos en la parte económica.

Esta oferta viene dada por la existencia de una demanda por parte de algunos gobiernos (principalmente de aquellas partes destinadas a la obtención de inteligencia), que en mi opinión han valorado erróneamente la naturaleza de doble filo de una vulnerabilidad. Si bien el estar en posesión de una vulnerabilidad nos permite poder usarla para atacar otros sistemas, nuestros propios sistemas también siguen siendo vulnerables a dichos ataques.

Y si se realiza una evaluación de la cantidad de sistemas y del valor de la información contenida en los mismos en mi opinión se tiene más que perder guardando que publicando…

Ante esta elección subscribo totalmente la opinión de Bruce Scheneier [11]: Todo el proceso de la investigación sobre vulnerabilidades debería estar enfocado a la mejora de la seguridad de los sistemas, el objetivo inicial para el que fue creado.

Para ello es obligatorio reencauzar el (bastante torcido hoy) proceso, ofreciendo una serie de incentivos tanto monetarios como de reconocimiento que conviertan el hecho de hacer pública una vulnerabilidad sea siempre más atractivo que venderla.

¿Qué nos haría falta?. Una idea sería crear algo similar a BugCrowd, un servicio de creación de bug bounties que gestiona búsquedas de vulnerabilidades, y dotándolo de procedimientos de responsibledisclosure.

Esta organización debería de ser internacional, completamente imparcial y financiada tanto por gobiernos como por las compañías de tecnología. Su principal objetivo: mejorar la seguridad de todos los elementos que componen Internet para todo el mundo, independientemente de qué país o sistema sea empleado. A vista de pájaro, un posible candidato para liderar esta iniciativa podría ser el IAB (Internet Architecture Board) [13], que tiene una distribución de miembros suficientemente variada como para compensar los diversos intereses existentes.

El otro lado de la ecuación reside en los propios investigadores: si nadie vendiera las vulnerabilidades que encontrara, y si el resto de la comunidad repudiara a aquellos que sí que lo hacen, lograríamos de una forma sensible reducir la oferta y/o redirigirla a la iniciativa anterior.

Cierto, el mercado negro aún seguiría actuando (y lo sigue haciendo en la situación actual), y aún tendríamos investigadores que no tendrían problemas éticos o morales en seguir vendiendo sus vulnerabilidades, pero se lograría en cierta medida retomar el control de todo el proceso.

Lo que sí que es cierto es que la situación actual tiene unas perspectivas poco halagüeñas, y es necesario hacer algo al respecto. El cómo (y en este caso muy importante, el cuánto) es algo que tenemos que decidir entre todos.

[1] Zero Day
[2] Full disclosure
[3] Responsibledisclosure
[4] INTECO-CERT
[5] BugCrowd – List of bug bounty programs
[6] Zero day Initiative
[7] Vupen
[8] Lista de precios de vulnerabilidades
[9] The Grugq
[10] Selling exploits for bitcoins in underground market
[11] Scheneier :The Vulnerabilities Market and the Future of Security
[12] BugCrowd
[13] Internet Architecture Board

Vigilancia digital en la coronación de Felipe VI

20 de junio de 2014 Por

Hemos estado viendo durante estos últimos días un amplio despliegue de seguridad entorno a la coronación de Felipe VI como nuevo rey de España. Francotiradores, equipos de artificieros/Tedax, Guardia civil y no me extrañaría, GEAS por las alcantarillas de Madrid. Todos ellos ejerciendo su trabajo para garantizar la seguridad de la corona. ¿Pero qué ocurre con el panorama digital? , ¿Qué ocurre en el campo de batalla de los bits?, ¿Por qué es necesario ampliar el espectro de protección al entorno virtual?

En un contexto más directo con el proceso in situ de la proclamación, imaginemos por el momento que algún grupo contrario a la monarquía, pudiera acceder a la red informática del congreso de los diputados y manipular el audio de la sala reproduciendo constantemente el “Himno de Riego”, o por ejemplo controlar a voluntad el alumbrado de la sala mientras el nuevo rey recibe su corona, convirtiendo la sala en una auténtica discoteca de alto standing. O puede ser más simple todavía, realizar una denegación de servicio sobre las infraestructuras de comunicaciones y dejar sin señal de transmisión a los medios que cubran el evento.

Los riesgos directos son múltiples pero no hay que descuidar los indirectos, es decir aquellos que pueden afectar a la imagen de la corona, como por ejemplo la modificación de su famosa página web o incluso los que no son directamente relacionados con la familia real, como pueden ser los servicios digitales de instituciones públicas o fuerzas y cuerpos de seguridad del estado.

Es por eso que durante estos días no solo hay que tener en cuenta la seguridad física del evento sino la digital ya que en muchas ocasiones esta puede sobrepasar el terreno virtual, y sino péguenle un vistazo a este interesante artículo de la revista Wired.