, 26 mayo 2015 | Imprime

Gran parte de las ciudades del mundo son cada vez más “inteligentes”, lo cual se convierte en nuevos blancos para ciberatacantes. Las ciudades han ido incorporando nuevas tecnologías durante varios años, pero últimamente la tasa de tecnologización ha aumentado significativamente y muchas ciudades de todo el mundo son cada vez más inteligentes. Las nuevas tecnologías, junto con una conectividad más rápida y fácil, permiten a las ciudades optimizar recursos, ahorrar dinero y al mismo tiempo ofrecer mejores servicios a sus ciudadanos.

Una “ciudad inteligente” (Smart city en inglés) se puede definir como una ciudad que usa tecnología para automatizar y mejorar servicios de la comunidad, incrementando el nivel de vida de sus ciudadanos. En la ciudad inteligente del futuro todo estará conectado y automatizado. Esto todavía no es una realidad, pero mientras tanto, muchas ciudades ya están elaborando grandes presupuestos para poder ser más inteligentes en un futuro cercano.







, 25 mayo 2015 | Imprime

Continuando con las medidas de seguridad en capa 2 que hemos visto en entradas anteriores, en este post nos centraremos en STP (Spanning Tree Protocol), protocolo usado en la red para evitar bucles a nivel 2 en nuestra topología.

Es habitual ver tráfico similar a este cuando capturas tu propia interfaz (no entro a valorar si dispones de permisos de administrador o si el equipo es un servidor o un equipo de usuario):

13:44:16.651348 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0
13:44:18.660589 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0
13:44:20.661034 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0
13:44:22.666010 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0
13:44:24.670848 STP 802.1d, Config, Flags [none], bridge-id 8001.00:24:f7:31:65:00.8016, length 43
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8001.00:24:f7:31:65:00, root-pathcost 0







, 22 mayo 2015 | Imprime

El problema

El pasado 13 de Abril de 2015 el US-CERT publicaba una alerta informando de que “Las peticiones AXFR podrían filtrar información referente a los servidores de dominio“. La comunidad cuando menos se rascó la cabeza pensando en qué estaba pensando el US-CERT. De hecho, este comportamiento fue reportado ya en 1997 por el NIST.

Las peticiones AXFR a servidores de nombres permiten replicar bases de datos DNS entre distintos servidores DNS. Las entidades por lo general tienen al menos dos servidores DNS (un primario y un secundario) que les permiten seguir disponiendo de servicio de nombres en caso de que el primario caiga. Por esta razón es importante que todos los servidores de nombres de una organización estén sincronizados. Esta sincronización se consigue mediante las peticiones XFR. Existen dos tipos de peticiones XFR, la incremental (IXFR) y la completa (AXFR), que envía al secundario toda la información de DNS local (lo que se conoce como la zona) que tiene el servidor primario. A este proceso se le conoce como “Transferencia de Zona“.







, 21 mayo 2015 | Imprime

Cuando se habla de un delito informático, se tiende a pensar en una persona al otro extremo de la red con altos conocimientos técnicos que está intentando lucrarse ilícitamente. Pero lo cierto es que detrás de estos delitos no suele haber una única persona, sino organizaciones complejas con diferentes roles y actores que gestionan, administran y ejecutan sus acciones.

El fraude a través de la red ha tenido una gran evolución, lo que ha ocasionado una sofisticación mayor en la manera de cometer los ciberdelitos utilizando infraestructuras cada vez más complejas. Este aumento en el grado de complejidad implica que los propios delincuentes no pueden abarcar todo el funcionamiento y métodos de ataque sobre una infraestructura u organización.

Al igual que hay en el mundo mercantil desarrollo de software, operaciones de compra/venta, colaboraciones, rivalidades, etc., lo mismo ocurre en el mundo mercantil “negro” de forma paralela. Sin embargo, en esta ocasión hablamos de desarrollo de exploits, compra/venta de exploits y vulnerabilidades, colaboraciones entre organizaciones criminales, etc. De la misma forma, existe una segregación de tareas definida en la que podemos identificar varios roles claramente, en función de la tarea que realizan en la cadena criminal.







, 20 mayo 2015 | Imprime

Hace unas semanas un amigo me comentaba que, tras un incidente en el servidor en la nube que tenía contratado (servidor que utilizaba entre otras cosas como almacén para toda la documentación relacionada con su tesis doctoral), había perdido la totalidad de la información y se veía obligado a realizar el trabajo de nuevo. Mi primera frase fue “¿No tenías copia de seguridad…?”, creo que tratando de dejar a un lado la sensación de incredulidad que me había producido la noticia. No me había sorprendido que un servidor en la nube fallase, era que una vez más se cumplía el dicho, “En casa de herrero cuchillo de palo”.

Dicen que hay dos tipos de motoristas, los que se han caído y los que se van a caer. Esta frase, que he oído múltiples ocasiones, normalmente tras enterarme de algún accidente de algún conocido aficionado del motor sobre dos ruedas, es una frase que puede ser trasladada sin más a los sistemas de almacenamiento. Están aquellos sistemas que han fallado y los que van a fallar.







, 19 mayo 2015 | Imprime

Últimamente se están identificando numerosas campañas de correos maliciosos con ficheros adjuntos; en especial, con variantes de Cryptolocker o CTB-Locker y demás tipo de ransomware.

En la mayoría de casos se trataba de un archivo ejecutable, con extensión .EXE, directamente incluido en un archivo comprimido ZIP sin contraseña. Entre tanto ejecutable, hace unos días llegó un correo diferente que no contenía un ejecutable sino un archivo VBS. En realidad, se trataba de un archivo con doble extensión (algo muy habitual para engañar al usuario y hacerse pasar por un archivo XLS, en este caso).







, 18 mayo 2015 | Imprime

En octubre de 2013, hace poco más de un año y medio, se publicaba la nueva versión de la ISO/IEC 27001:2013.

Mucha era la expectación que se había creado en torno a esta nueva versión y los análisis empezaban a inundar las páginas web del sector y los grupos de LinkedIn. A los pocos días de la publicación en inglés de la norma, publicamos un exhaustivo análisis sobre los cambios que a priori se esbozaban del estándar.

La traducción al castellano, UNE-ISO/IEC 27001:2014, llegó más de un año más tarde, dejando poco margen a las organizaciones que habían estado esperando a la norma en castellano para su adaptación. Recordemos que el plazo que daban desde ISO (International Organization for Standardization) era de dos años desde su publicación en octubre de 2013. Esta situación habrá supuesto un reto para muchas organizaciones.







, 15 mayo 2015 | Imprime

Al hilo de lo que comentamos en el anterior artículo The blackout, ¿puede que todo lo que sucedió en Turquía el 31 de Marzo no se debería estrictamente a causas técnicas y fallos humanos?

Atacar un sistema eléctrico nacional para provocar un cero de tensión no es trivial, a pesar de que en el imaginario colectivo del siglo XXI tales sistemas son la infraestructura crítica por excelencia y aparentemente constituyen el primer objetivo de cualquier terrorista. Podemos pensar en dos aproximaciones. La primera, que está en la línea del artículo del Observer, consiste en desconectar una a una las infraestructuras que abastecen a todos los clientes: o abrimos interruptores en todas las líneas de transporte, o disparamos todos los grupos de las centrales de generación, o las desconectamos de la red abriendo los interruptores en las líneas de evacuación, o abrimos todos los interruptores de cabecera de las líneas de distribución.

Esto supone un grado de infiltración del sistema eléctrico de un país absolutamente total, requiriendo, además, tener capacidad de control y mando para coordinar todas las actuaciones simultáneamente (en realidad no hace falta llegar al 100% de infiltración, ya que eventualmente se inducirá un desequilibrio tal en el sistema que el efecto dominó facilitará el trabajo).







, 14 mayo 2015 | Imprime

El pasado 31 de marzo una de las peores pesadillas de nuestra civilización tecnológica se hizo realidad en Turquía (no, no hablamos de Sálvame): gran parte del país quedó sin suministro eléctrico durante horas, lo que provocó la inevitable cascada de caídas en otros servicios esenciales: transportes, comunicaciones, abastecimiento de agua potable, etc. Casi inmediatamente, especialmente en ciertos ambientes, se abrió paso la idea de que el incidente se debió a un ciberataque. Esta idea se vio reforzada, inevitablemente, por el secuestro y asesinato de un fiscal por un grupo terrorista. Han pasado ya casi dos meses y, como suele ocurrir, apenas se ha vuelto a hablar de este asunto (lo que para ciertas mentes propensas a la conspiranoia es, sin duda, la mejor confirmación posible de esta hipótesis).

A los pocos días la primera explicación oficial atribuía el suceso a una gestión deficiente de ciertas operaciones de mantenimiento en la red que dejaron el sistema eléctrico turco expuesto a un riesgo grave, riesgo que a la postre acabó materializándose. Según esta explicación se habría tratado de un fallo exclusivamente técnico que acabó costando el puesto a Kemal Yildir, máximo responsable de la compañía estatal TEIAS. TEIAS es la empresa que gestiona el transporte de energía eléctrica en Turquía. He estado buscando algún informe oficial al respecto con el fin de cotejar los datos técnicos que sustentan esta hipótesis, sin resultado. Pero sí he encontrado dos artículos relativamente recientes que sostienen dos visiones absolutamente contrapuestas resumidas en titulares:







, 13 mayo 2015 | Imprime

(Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.)

En la entrega anterior (ver parte I, parte II, parte III, parte IV y parte V) teníamos el caso a punto de caramelo: habíamos relacionado (inicialmente al menos) a R.G. y a S.P.F. con dos terminales que habían estado implicados en el asesinato.