Posibles consecuencias de Meltdown y Spectre

Tras el revuelo que se montó con las dos vulnerabilidades que se detectaron estas navidades (bueno, unos meses antes) que ya analicé en las dos entradas anteriores, quisiera hacer una reflexión acerca de lo que en realidad son los sistemas modernos de vulnerables o no.

Lo primero que hay que decir es que sí, que todos los sistemas de los últimos 10 años son vulnerables y lo van a ser hasta que se solucione el problema y se cambien las CPUs por otras nuevas. Esto incluye a Intel, AMD, ARM, Power y todas las CPUs con ejecución especulativa (o como leñe se traduzca al español y que no suene tan mal) Si quieres uno seguro, los SPARC con encriptación de la memoria por HW.

Ahora la cuestión ¿cómo de complicado es explotar estos fallos? Pues ahí tengo una buena noticia: es muy complicado, lo que no quiere decir que te quedes tranquilo del todo, pero por lo menos, no vamos a morir todos esta semana (y la que viene, seguramente tampoco) pero tampoco que extrañaría que en un tiempo, alguien sea capaz de sacarle jugo.

Hay gente que saca provecho de todo .. hasta de los cuadro de Kandinsky

Meltdown, aparte de afecta únicamente a Intel (los AMD lovers están de enhorabuena) se puede parchear con el parche KPTI o KAISER que lo que es separar los datos de kernel y de usuario en dos espacios de direccionamiento diferente con lo que un intento de acceder a la parte protegida es infructuoso. Lo malo es que obliga a cambios de direccionamiento y el impacto en el rendimiento es negativo, no tanto como se decía inicialmente y mucho mayor en CPUs y sistemas operativos antiguos como Windows Server. No hay mal que por bien no venga ... se puede forzar la renovación tecnológica (cada vez que veo, en 2018 peticiones de nuevas máquinas con Windows 2008 se me revuelven las tripas) Respecto a SPECTRE, no hay paliación, pero le pasa lo mismo, si no le ofreces los datos en el mismo espacio de direcciones no puede acceder a ellos.

Por otro lado, ninguno de estos agujeros puede escribir en ninguna parte, sólo pueden leer, así que no debemos temer que nos inyecten código malicioso, pero si podrían pillar claves privadas, usuarios y otros datos delicados y confidenciales que deberían estar protegidos. Aquí tenemos que tener en cuenta dos cosas:

• Aleatorización del espacio de direcciones. En el pasado los sistemas operativos tenían un mapa de memoria más o menos fijo y yendo directamente a posiciones de memoria se podían obtener resultados en concreto (la memoria de vídeo, el stack, variables del sistema, etc) De hecho, muchas veces se programaba directamente pensando en estas direcciones con el fin de mejorar las prestaciones. Eso ya no es así, pero una parte la memoria está "virtualizada" (los programas tienen mapas de memoria propia que se copia en memoria real) y se ha incorporado un elemento "aleatorio" a la hora de distribuir la memoria del kernel, de manera que no está siempre en las mismas posiciones, lo que dificulta el acceso a determinados áreas del sistema. No es lo mismo crear un virus que saque datos de unas posiciones determinadas que no uno que tenga que buscar primero.



Mapa de memoria de MS-DOS

• La velocidad de acceso a los datos de estas vulnerabilidades es relativamente escasa. Según he leido, 500 KB/s en el caso de Meltdown y 10 KB/s en el caso de SPECTRE. Eso significa que si tenemos que extraer y analizar 1 MB de datos tardaremos 100 segundos en el segundo caso en el mejor de los casos y haciendo un impacto en el sistema que nos estaría gritando "¡eh! ¡que estoy aquí putenandote el ordenador!" y la cosa no es así ¿verdad? queremos ser discretos. Si para un 1 Mb necesitamos 100 segundos, para 1 GB que son 1024 veces más como que la cosa no parece eficaz (el PC desde el que escribo tiene 16 GB, son 455 horas de análisis si no me he equivocado)

Como ya hemos dicho que no se permite escribir, hay que utilizar otras maneras de entrar en los sistemas, bien vía troyanos, vulnerabilidades de otros componentes ... o desplegando una VM con código malicioso que afecta a las nubes públicas (por eso se han dado tanta prisa en desplegar los parches) 

Pero por no estar en una cloud pública o tener KPTI instalado no vas a estar seguro. Quizás no te puedan acceder a claves privadas en el kernel pero por ejemplo, si te pueden meter un keylogger y capturarte passwords como muestra el vídeo.

Para resumir: El riesgo existe aunque la manera de protegerse también y es relativamente sencilla:

• Mantén el sistema operativo actualiza. Evita los sistemas operativos antiguos que no tienen parche de seguridad.
• No te instales software de orígenes dudosos.
• Ojo al spam, phising, troyanos, etc
• Mantén el antivirus actualizado.
• No sería mala idea encriptar el HD (perjudica a las prestaciones)
• Tomate el ordenador en serio, sobre todo si lo tienes conectado a Internet (cosa que haces ya que si no, no estarías leyendo esto)
• Ojo con los android que las apps las carga el diablo (IOS creo que es un poco más seguro, pero hay que tener cuidado también)

SPECTRE. Recuperación del dato. Entre lo sutil y lo diabólico.

En mi entrada anterior hablé de cómo MELTDOWN y SPECTRE burlaban los mecanismos de protección de las CPU para llegar áreas protegidas pero la cuestión era ¿cómo podía recuperar el dato? -- como si a alguien le importara -- (le voy a dar a la voz en off) 

Si analizamos el comportamiento predictivo de la  CPU resulta que por un lado, puede ejecutar comandos de forma desordenada ... vale, pero si por un casual atacamos una posición de memoria protegida no la podemos dejar en ningún sitio  -- claro zoquete, por eso está protegida -- ni en un registro ni en una posición de memoria pero resulta que sí podemos averiguar su valor por medio ... sutil, como diría el maestro ... con indirectas.

Pues antes de contar cuál es ese medio, voy a explicar un poco en detalle cómo funciona una caché -- si ya sabía yo que éste si no soltaba el rollo no se quedaba a gusto --- Las CPUs son rápidas, muy rápidas pero las memorias, aunque lo parezcan, no lo son tanto y por ello metemos en medio unas memorias mas rápidas llamadas cachés que aunque no son tan rápidas como los registros son mucho más rápidas que la memoria. Con el fin de optimizar el acceso a esa memoria, cada vez que hay que ir a buscar un dato a la memoria no se copia ese dato solo a la memoria, sino que se copia una cosa llamada línea que dependiendo de la arquitectura, es un número de de bytes determinados. En el caso de las CPUs de Intel que uso ahora son 64 bytes como se puede apreciar. Es decir, yo pido un byte y si hay un fallo de caché, va a la memoria y trae 64. Como la probabilidad de que pida bytes adyacentes es muy alta, seguramente la próxima vez que pida otro dato distinto éste se encuentre en la caché.

¿Qué diferencia tenemos de que un dato esté o no en caché? Pues que tarde 400-500 ciclos de CPU en tenerlo o que tarde 200, un ahorro considerable.

Pues la idea de estas vulnerabilidades es aprovecharse de esto. Como ya he dicho previamente, la  CPU accede a datos protegidos pero no los puede dejar en ninguna parte entonces ¿cómo poder saber el valor de este dato? Pues de manera indirecta con dos cosas:

- Profundo conocimiento del funcionamiento de la CPU y cómo se maneja el manejo de páginas de memoria.

- Un array "gordo" que no quepa en una línea y que ocupe 256 páginas de memoria ¿por qué 256 páginas y no 128 bloques o cualquier otra cosas ....? Ahora lo verás. El ejemplo está sacados del whitepaper del meltdown attack.

Lo que voy a describir leerá un sólo byte de la memoria. si quieres leer por ejemplo, una clave de 2048 bits (256 bytes) pues primero tienes que averiguar dónde está y repetir el proceso de 256 veces. No es rápido pero acaba funcionando y si eres sútil, no te pillaran. Si entras a saco vas a joder todo el rendimiento del servidor y te van a pillar a la primera.

El código es el siguiente (como dije, está en el white paper de meltdown)

Previamente a hacer nada vaciaremos toda la cache mediante la instrucción CLFLUSH y cargamos en el registro RCX la dirección que queremos atacar (la protegida) y en RBX la dirección de memoria donde esté nuestro array de prueba. Como ya hemos dicho antes, tenemos que conocer el tamaño de página que se intercambia, en este ejemplo, 4096 bytes (la típica página de 4K de toda la vida)

¿Lo tenemos todo listo? -- pero ¿te crees que alguien ha llegado aquí? -- pues vamos a hacer magia. Cargamos en el byte más bajo del acumulador (recordemos que nuestros registros son de 64 bits) el byte que apunta RCX (línea 4) y multiplicamos ese valor que hemos cargado por 4096 (línea 5) -- ¿lo cualo que dices que has hecho? -- multiplicar por 4096 o lo que es lo mismo, desplazo hacia la izquierda 12 posiciones (el número hexadecimal 0x0C es el decimal 12) lo que equivale a multiplicar por 2 un total de 12 veces y como 2 elevado a 12 es 4096, ya tenemos ese valor. Y con ese valor que hemos obtenido, sumado al puntero del array que queremos acceder cargamos el dato (línea 7) Un avezado espectador diría, pero si, estás machacando el puntero original -- Oye, que estás machacando el puntero original -- (eso no vale, lo he dicho yo primero) Pues en efecto, pero el valor que tenga RBX ya no me importa porque ya he hecho la magia ¿ha quedado claro?

-- Pues no, no ha quedado nada claro -- pues te lo explico, voz en off. En este caso, estoy forzando una excepción (violación de acceso a la memoria protegida) pero me aprovecho de que esto se ejecuta de manera desordenada ... es decir, que antes de que salte la excepción, la CPU ha accedido al dato, ha ejecut a la línea 7 ... y ha deshecho todo lo que hizo porque no es válido ... no hay forma de acceder al valor RBX, ni al de RCX, ni a la posición de memoria ... o quizás sí -- ¿me estás vacilando -- Pues sí, te estoy vacilando un poco porque en realidad si ha quedado un rastro. Antes hemos dicho que tenemos un array del tamaño de 256 páginas (en este caso 4K cada una, un array en memoria de un Mbyte) y que previamente, hemos vaciado la caché. Utilizando como índice el valor protegido hemos accedido a una posición de memoria de nuestro array cuyo valor es irrelevante, la cuestión es que ha cargado en memoria una página de memoria y sólo una ¿cómo sé cual? Pues de una manera muy sencilla, voy consultando página por página (desde 0 hasta 256 leo un byte en la posición multiplicada por el tamaño de la página) y miro cuanto tiempo tarda la CPU en dármela. Dado que todas están en la memoria principal, tendrá que ir a por ellas y tardará un tiempo muy similar para todas la páginas menos para una ... aquella página cuya posición coincida con el valor leído previamente en la memoria protegida -- no me queda claro-- Pues seguro que si ves este gráfico te queda más claro.

Todos los accesos pasan de los 400 ciclos de CPU menos uno que se queda por los 200, ese el que hemos pillado antes y ¡voilá! hemos hecho magia, averiguando un valor sin poder acceder a él. si quiero más datos, pues nada, repito el proceso las veces que haga falta, que con paciencia y saliva el elefante ...

El mecanismo que uses para llegar a forzar este proceso puede ser como MELTDOWN (fuerza una excepción pero antes ya ha accedido) o jugando con la predicción (SPECTRE) o algún invento nuevo, pero lo interesante del caso es que no le veo una solución sencilla al menos sin perjudicar el rendimiento del ordenador. No sirve el separar en cachés los datos e instrucciones del anillo 0 y del 3 porque estás accediendo a los datos del anillo 3 y vas a dejar el rastro en la caché. El forzar flushes de la caché cuando se produzcan violaciones puede perjudicar a otros procesos (no olvidemos que la LLC está compartida por todos los cores y procesos) Seguramente habrá que reforzar de alguna manera el acceso a la parte protegida por HW, primando el bit de protección que al parecer ahora  no es lo suficientemente estricto.

-- ¿De qué anillos hablamos? -- De estos, que te lo hay que contar todo.

Pues ... eso es esto, amigos.

-- Anonadado me hallo ¿latita Whiskas pa celebrarlo? ---

Meltdown, Spectre y la caché de la muerte.

Estos días se ha hecho pública una vulnerabilidad que se aprovecha de la arquitectura de caché de todos los ordenadores. Posiblemente lo que hayas oído es que todos los ordenadores son vulnerables y que no hay protección posible que eso canta mucho en las noticias y es sensacionalista a tope. Lo malo es que por una vez tienen bastante razón.

Vamos a ver lo que pasa y para ello toca un poco de - ¿rollo patatero? - pues en efecto (macaguenlavozenoff).

Vamos a ir por partes, que la cosa tiene tela (avisados estáis ... ¡huid insensatos!) Por un lado, hay que tener en cuenta una cosa llamada "anillos de ejecución" que se definen en los sistemas operativos, el nivel 0 es el del sistema operativo y es el más privilegiado. Luego van los drives y por último, las aplicaciones, con menos privilegios.

¿Por qué se hace esto? Pues para evitar que se monte el pifostio padre y que una aplicación pueda modificar cosas del sistema operativo o de otras aplicaciones como ocurría en sistemas operativos más antiguos o simplones como el MS-DOS donde todo era accesible por todo y un programa mal hecho (no hay programa infalible) te podía colgar el ordenador o hacer algo peor, meterte un virus. Éstos inicialmente eran para tocar las narices pero ahora, con todos los ordenadores conectados te pueden robar tus datos o utilizar tu ordenador para cosas raras desde minar criptomonedas o cosas peores.

La cuestión es que los UNIX/Linux, el IOS de Apple que está basado en UNIX, Android (basado en Linux) y por fin Windows no permiten el acceso de las aplicaciones a estos niveles, haciéndolos más seguros (Claro que si sigues usando 1234 como password importa tres narices) Últimamente los virus intentan entrar por dos vías:

- Engañando al usuario para que les "eleve" la prioridad y hacer de las suyas,.

- Aprovechando bugs del sistema operativo o de las aplicaciones.

Al final todo esto, con un poco de cabeza, un antivirus y no andando haciendo el indio, más o menos se palía.

Ahora viene la segunda parte (de este rollo, que siempre se te olvida) que va un poco de arquitectura. Resulta que los vendedores de CPUs hablan mucho de cores, GHz pero suelen omitir un pequeño detalle: el acceso a la memoria. Echemos un ojo a esta captura:

La velocidad de la CPU es molona, casi 4 GHZ ... parece un pepinaco de cuidado y lo es. Lo que llama la atención es cuando aparece un campo llamado multiplicador .... ¿qué es eso? A lo mejor debemos retarnos a la era de los 486, cuando había uno con los número 33/66 (yo tuve un 33/100) y eso significaba que mientras que el procesador funcionaba internamente a 66 MHz (si, tres órdenes de magnitud por debajo) el acceso a la memoria funcionaba a la mitad (33 Mhz) Pues con el tiempo, la distancia en velocidad entre las CPUs y la memoria se ha ido incrementando. En este caso te encuentras que la memoria funciona a unos pobres 103 MHz y el multiplicador es nada menos que hasta un x44. No obstante, la memoria también ha evolucionado. Por ejemplo, utiliza ambos flancos en la señal de reloj, lo que convierte la frecuencia en el doble, transfiere varios bits en cada flanco, tiene bastantes bits de ancho de banda, .... En concreto en este caso, la velocidad teórica es de 3605 Mhz (DDR4) pero esa velocidad es sólo cuando transmite ... el problema es cuando hay que ir a buscar el dato que nos encontramos con una cosa llamada latencia que significa que el procesador está parado a la espera de un dato ... y eso pasa mucho más de lo que te piensas.

¿Cómo podemos paliar esto? -- pero ¿acaso te piensas que nos importa? -- Pues de varias maneras (incluso todas a la vez):

- Aumentando el número de cores, lo que permite hacer cosas en paralelo.La potencia del procesador equivale al número de GHz por el número de cores.

- Aumentando el número de threads por core, lo que hace que si un thread está en espera, el otro pueda que haga algo. En este caso, mi CPU no tiene Hyperthreading, pero en otras el aumento aparente es aproximadamente un 30-40% del rendimiento de la CPU. En procesadores con más threads como los SPARC, es mayor.

- Metiendo entre la memoria principal y los registros de la CPU diversas capas de memorias, cada vez más lentas pero cada vez mayores. En este caso, cada core dispone de dos cachés muy rápidas y pequeñas, de 32 KBytes cada una, una para datos y otra para código (una especie de arquitectura tipo Harvard que contrasta con el resto de la máquina, que en Von Newman) luego una segunda caché (por core) de 256 KB que mezcla datos y código y por último, una caché de L3 compartida por todos los cores de 6 MBytes que es la mayor y más lenta, pero aún así, más rápida que la memoria principal. Al último nivel de caché (en este caso la L3) se la conoce como Last Level Caché (LLC) y es el tamaño de caché que se publicita.

¿Hasta aquí todo claro? (pues seguro que lo complica) Con el fin de optimizar el rendimiento de la CPU las cachés no sólo van cargando datos a medida que se piden exclusivamente, se carga un bloque adyacente de manera que si el dato que se pide a continuación está en ese bloque (suele pasar) ya lo tienes en la caché. Es decir, la CPU va como a tirones: procesa lo que hay en la caché hasta que se queda sin datos y los vuelve a buscar a la memoria, cuando los tiene, los procesa de nuevo.

Pues resulta que las instrucciones no se ejecutan sin más, sino que primero se decodifican, se cargan los datos y luego se operan. Al final, una sola instrucción implica varios ciclos de CPU pero resulta que en realidad, las CPUs son capaces de de ejecutar una o más instrucciones por ciclo ¿cómo? Pues por medio de pipelines que ejecutan estas fases en paralelo: una decodifica instrucciones, otra carga parámetros, otras operan, ..... Pues para rizar el rizo y con la ayuda del compilador, no solo hacen eso sino que son capaces de predecir el comportamiento del programa en hilos ... es decir, pueden ejecutar el IF y el ELSE a la vez y en función del resultado, aprovechar la rama de ejecución ya calculada y descartar la mala ¡la leche! ¿no?  De hecho es capaz de ejecutar las instrucciones de manera desordenada (o lo que es lo mismo, de una manera distinta a la que fueron escritas) para optimizar los recursos y luego ordenar los resultados. Por supuesto, para ello cada procesador precisa un compilador especialmente diseñado para él

Pues toda esta parafernalia que ha costado más de una década desarrollar al nivel actual es la causante de los problemas que han aparecido recientemente. Al parecer incluso el CEO de Intel ha vendido todas las acciones que ha podido de su compañía, quedándose tan solo con las mínimas exigidas para el puesto cosa que le puede costar las cárcel por uso de información privilegiada. En España le meterían de CEO en una empresa del IBEX 35.

Lo que ha aparecido son básicamente dos vulnerabilidades:

Meltdown. 

Intenta hacer un acceso a un área de memoria restringida. El nivel de protección del Sistema Operativo y del HW se lo impide, pero consigue aprovechar una debilidad de las CPUs Intel y acceder a cualquier posición de memoria protegida. Este problema se mitiga con un parche que si no ha salido saldrá ya conocido como KPTI (Kernel Table Page Isolation) o KAISER que mueve las tablas de memoria del Kernel. Lo malo es que al parecer puede ralentizar bastante los ordenadores, en especial los que se hacen uso intensivo de los cambios de contexto (cambios de nivel en los anillos) que son las nubes, equipos virtualizados, etc. Pero mejor que permitir que desde una VM se acceda a otra ¿no? Yo no descartaría que en futuro aparezcan variantes de Meltdown que busquen otros datos aparte de las tablas de memoria. De momento, sólo afecta a CPUs Intel.

SPECTRE.

Esta es una vulnerabilidad peor porque afecta as todos los procesadores y arquitecturas (Apple, Android, Windows, Linux, ...) y es debida a que las cachés son compartidas por todos los procesos que corren en un ordenador y en los ordenadores modernos, procesos, lo que se dicen procesos, corren un montón (en la imagen de abajo puedes ver una captura de lo que hay en mi PC ahora mismo y no tengo precisamente muchas cosas abiertas pero procesos, dice que hay 205 corriendo) El tema es que Spectre juega con el sistema de predicción, forzando la ejecución de código privilegiado en entornos no privilegiados. Es la más complicada porque no tiene prevención (al menos ahora) y con un simple javascript pueden acceder a datos que se encuentren en el mismo servidor (aunque pensándolo bien, en entornos multiprocesador sólo se podrían acceder a VMs que corrieran en el mismo procesador e incluso, en los mismo cores, eso va a depender si está en L3 o en L2/L1) La cuestión es que la cosa tiene mala solución. Lo bueno de Spectre es que es muy complicado el sacarle partido de manera maliciosa ahora mismo ... pero todo llegará.

Y para terminar ¿qué afectación vamos a tener? Pues lo grandes servidores de nubes, públicas o privadas van a tener un problema serio de vulnerabilidad y de hecho, ya se están intentando proteger, aunque sea a costa de perder un porcentaje importante de sus prestaciones (se habla de hasta un 30%) El cambio de arquitectura y CPUs a corto plazo es irrealizable, a medio ... pues ya veremos. Se irán paliando poco a poco estos problemas, se incorporarán mecanismos de seguridad en la caché y poco a poco se irán sustituyendo los ordenadores vulnerables (hoy, 5 de enero de 2018 son todos) pero dudo que antes de una década haya desaparecido esta amenaza completamente. el tema no es tanto producir chips como el desarrollar, probar y reemplazar una arquitectura que ha estado evolucionando por más de una década.

Teóricamente los ordenadores domésticos son menos "interesantes" a la hora de infectarlos porque ya está el malware habitual, pero yo no me confiaría demasiado.

A saber de quién será la voz en off.
Felices fiestas que me voy de celebración.

El grid maligno (IoT, seguridad, blokchain y otras hierbas)

Se nos va a ir en breve el 2017 y mirando un poco hacia atrás yo veo dos noticias interesantes (para mí que me dedico a ello, para otros les interesará el fumbol o el esperpento de banderas de Cataluña; yo ya lo encuentro cansino)

Gracias a este esperpento, el latrocinio gubernamental pasa a segundo
plano (éste también trincaba, dicho sea de paso)

Por un lado hemos sido conscientes (bueno, algunos ya lo intuíamos y otros, lo tenían bastante claro) de que con el aumento exponencial de uso de ordenadores en todas partes el número de vulnerabilidades aumentaría y el que se realizaran ataques masivos. El famoso ataque de Wannacry y en España, el impacto en una gran empresa como es Telefónica nos hizo conscientes de que estábamos con el culo al aire. Mis parabienes a esos señores tan espabilados que han recortado el presupuesto a los informáticos. A ver si conocen los conceptos lucro cesante e imagen de empresa. La cuestión es que Wannacry secuestró miles de ordenadores a los que pedía un rescate en bitcoins. Lo cierto es que según se dice, hicieron mucho ruido, pero sacar pasta ... poquita. Posiblemente haya sacado más con la revaloración del bitcoin desde entonces que con el secuestro.

Ahora estamos con el asunto del Internet of the Things (IoT) que no es ni más ni menos que disparar el número de dispositivos conectados a internet hasta varios miles de millones (unos 20.000  millones se estima ... por lo menos) con lo que vamos a estar rodeados de miles de aparatitos que en unos casos serán unos gadgets curiosos, en otros serán artefactos muy útiles y en otros serán gilipolleces, pero todo conectado ¿exagero? hace 15 año tenía en mi casa dos artefactos con conexión a Internet: el ordenador y el router de ADSL. Éste último con una compleja password por defecto: 1234. Ahora mismo, el número de equipos conectados por IP pasa de quince entre ordenadores, móviles, tablets y otros gadgets.

Por otro lado, aunque ya llevan 10 años rulando por ahí, la tecnología blockchain y asociadas junto con las criptomonedas  debido al impulso hacia arriba que ha dado la cotización. Ya hablan de bitcoin lo ejpertos más insospechados.

Ejpertos explicando la tecnología blockchain.

Si unimos las dos cosas ¿qué podríamos sacar? ¡en efecto! Utilizar vulnerabilidades para aprovecharse de otros para minar criptomonedas.

Al parecer se la han colado a la mismísima Movistar o a portales de Torrents.Ojo, esto no quiere decir que Movistar haya sido quien ha colado el minador, sino que les han hackeado (ya veremos si desde fuera o desde dentro) En otros portales, pues la cosa varía. Si te metes en portales "peculiares" a lo mejor son ellos los que lo hacen directamente. De hecho los navegadores empiezan a incorporar extensiones anti minado, similares a los bloqueadores de publicidad que ya incorporan,

El asunto es que hay que ser chapuzas. Te cuelas en miles de ordenadores y ¿no se te ocurre otra cosa que montar el pollo para que te pillen? Desde luego, si te vienes al congreso de malignos no te dejamos ni servir el café. La idea de hacer un delito es permanecer anónimo, sin que te conozca nadie y disfrutar de las ganancias y cuanto más se tarde en descubrir mejor, igual hasta con el tiempo fundas hasta una familia real y apareces en el Hola.  (*)

Listado de delincuentes anónimos a los que no se ha podido pillar por no saber quienes son.

Lo suyo es infiltrarse en ordenadores e ir recopilando información a lo bestia: passwords, usuarios, cuentas bancarias, instalar keyloggers, recopilar datos para analizar por big-data .... si minas bitcoins o similares no incordies, limita el gasto de CPU al 25% o menos para no molestar, el mejor parásito  es el que no mata al anfitrión. Pasa desapercibido, llévate información y no molestes porque lo que consigues es despertar a la bestia y te van a cazar.

Alguien podría pensar ¿y qué haces dando ideas al cibercrimen? Pues a ver si te piensas que he sido yo el primero en pensar en esto. Seguro que ya hay mucha gente trabajando en ello si no está ya medio desplegado (empezando por la NSA)

Bueno, os dejo, que tengo que quedar con unos amiguetes para planear .... la entrada del año. Feliz 2018.

(*) Seguro que más de uno pensó que iba a poner a los Borbones, pero no ...

Virus, troyanos, IoT y otras cosas del .... hacker.

Ya ha pasado algún tiempo desde que ha sucedido el divertido episodio de WannaCry que puso en jaque a compañía como Telefónica. Chistes aparte sobre Chema Alonso quien por cierto sin ser el encargado de los PCs fue quien dio la cara cosa de mucho mérito porque conozco alguna otra empresa gorda que le ha pasado lo mismo y ha callado miserablemente, la cosa tiene más miga de lo que parece.

CISO = Chief Information Security Officer

¿Piensas que el ataque ya ha pasado y que todo está bajo control? Pásate por estos enlaces y me lo vuelves a decir:

http://www.digitalattackmap.com/

https://threatmap.checkpoint.com/ThreatPortal/livemap.html

https://cybermap.kaspersky.com/

https://threatmap.fortiguard.com/

El asunto es que no, no estás para nada seguro y ya no hablo de que te encripten el ordenador, eso con un backup (o mejor dos y en sitios separados y no conectados al ordenador) se soluciona en el peor de los casos. La cuestión es que éste ha sido uno de los ejemplos y se van a repetir y mucho. No hace demasiado tiempo el funcionamiento de Internet estuvo afectado por un ataque de DDoS (Es algo así como Ataque Distribuido de Denegación de Servicio) que afectó a los DNS de Dyn y ¿quienes lo realizaron? Montones de dispositivos IoT como cámaras IP, monitores de bebés, DVDs conectados ... un ejército zombie de dispositivos IoT.

¿Te piensas que las cámaras no son vulnerables? Mira este otro enlace, a lo mejor encuentras tu casa.

No, el concepto de sandbox no es éste.

La cuestión es que cada veza tenemos más equipos, bien sean ordenadores, tablets, teléfonos, smartTV, cámaras IP, decodificadores, .... y el número de vulnerabilidades aumenta día a día. Para más INRI al parecer la NSA se dedica a localizar bugs pero no los publica, con lo que no es posible parchearlos (vale, otras veces pasan olímpicamente de arreglar las cosas) Por otro lado, lo de montar parches de manera global en una empresa tampoco es una tarea fácil ya que nos es la primera vez que un parche hace que una cosa deje de funcionar y antes de dejar a decenas, cientos o miles de trabajadores parados es mejor ir haciendo pruebas (pro ejemplo en una sandbox) y despliegues poco a poco.

La cuestión es que entre una cosa y otra, este troyano (no virus, el virus funciona de otra forma) se extendió de manera sigilosa entre cientos de miles de ordenadores en el mundo y en un momento determinado se activó. Incluso de pueden consultar los pagos y movimientos en bitcoin (de esta yo diría que no se van a jubilar) A día de hoy (la cosa puede cambiar) un bitcoin vale 2227,88 $

https://blockchain.info/address/13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94

https://blockchain.info/address/12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw

https://blockchain.info/address/115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn

El tema es que se ha visto que las redes son vulnerables, todos los dispositivos lo son, aquí los responsables prefieren gastarse los cuartos en cosas como el coaching y otros timos antes que en infraestructura y seguridad (debe ser que les dejan  menos comisión, suena menos guay y hay que estudiar más para saber que haces en lugar de escuchar a un charlatán) Siempre vas a tener dispositivos obsoletos y vulnerables, con lo que aparte de intentar evitarlo, hay que reforzar la seguridad en la periferia vía IDS, IPS, Antivirus, Firewall, microsegmentación, DMZs, Si no sabes lo que es eso, veta a dar un curso básico de seguridad, es el ABC. Luego ya vas a protegerte contra ataques sociales (si, como el marketing, pero orientado al mal .... vale, el marketing no está pensado para hacer el bien, pero esto está mal visto.) Es como si alguien aprovechando información tuya y tu relación te quiere vender acciones preferentes de una caja de ahorros quiere obtener información de ti  para usarla en su provecho.

Yo veo un riesgo más allá del tema del ramsonware como ha sido este ataque. Hemos visto que es posible infiltrarse subrepticiamente dentro de centenares de miles de ordenadores y no hace falta secuestrarlo, se les puede hacer operar como zombies (ya es viejo) o directamente, se puede empezar a recolectar datos de manera masiva, conseguir números de tarjetas de crédito, contraseñas, accesos a sitios restringidos, hacer espionaje industrial, alterar el mercado de valores, lanzar ataques sociales (mira el video de una granja de "clicks" en China, si eso existe es porque alguien paga) Igual tenemos Matrix yt 1984 más cerca de lo que pensamos.

Lo reconozco, no puedo evitarlo, cada vez que pienso en cosas para hacer en IoT no se me ocurre nada bueno.

Lo que nos va a traer el IoT

No hace demasiado he publicado una entrada en la que hablaba de los cambios que iba a tener la sociedad en menos tiempo del que pensábamos a causa del paradigma Software Defined y concluía con que aparte de muchos cambios tendríamos un sector que tendría gran pujanza: la seguridad. Pues en el momento de escribir esto un ataque DDoS (Distributed Deny of Service) se produjo hace pocos días, dejando fuera de combate durante unas horas varios de los servicios más famosos de Internet. El ataque se produjo contra los servidores de DNS (los que se encargan de "encontrar" los destinos entre las direcciones IP) Dado la cada vez mayor conexión de la población a estos servicios (Facebook, Twitter, etc) el impacto fue conocido entre la población en general. Por supuesto que los ataques de denegación de servicios son ya conocidos desde hace mucho tiempo, pero claro, en este momento muchos se acaban de dar cuenta que de la cosa va con ellos (otros no, pero se acabarán dando cuenta)

A mí, mientras no me quiten el Marca(en papel) eso no me afecta.
Fuente: la vergüenza nacional.

La cuestión es que como dije anteriormente, vamos a un mundo muy conectado y que va a evolucionar muy rápido y cuando las cosas se hacen rápido, hay cosas que se quedan en el tintero como seguramente pasará con diversos aspectos de la seguridad. Alguno dirá entonces que se hagan las cosas más despacio, pero es que no va a poder ser. El que se retrase se morirá (en el mundo de los negocios) y lo que viene ahora va a meter miedo. Según Pat Gelsinger (CEO de VMware) ha comentado su previsión del IoT en los próximos años (el que no me crea, que lo vea aquí) mientras que PC, móviles, tablets, relojes y similares se estancarán en unos 8.500 millones (que no está mal) los dispositivos de IoT (Internet de las Cosas) se irán a los 18.000 millones de paratos conectaos.

Estimación de dispositivos IoT en cinco años.
Fuente: VMworld 2016

Aunque meta la pata en un 50% estamos hablando de 16.000 millones de sistemas programables, conectados a las redes y potencialmente vulnerables.Ya tenemos los equipos "potentes" como PC o móviles con problemas de malware o de exploits que son aprovechados para crear redes de ordenadores zombies (por eso es muy recomendable actualizarlo todo) Y si pasa eso con los equipos mas "gordos" ¿qué no va a pasar con el resto?

En el SW las cosas salen relativamente seguras, pero con el tiempo acaban apareciendo vulnera bilidades como aparecieron el la shell Bash de Linux o el propio OpenSSL y son cosas que durante muchos años se consideraron seguras. Si hay un agujero en alguna parte, acabará apareciendo. Es imposible taparlos todos en el diseño y la forma de solucionarlos es distribuir los parches de manera rápida, como hizo Tesla con el agujero de seguridad que le abrieron en su coche. Pero cuando nos vamos a IoT la cosa va a ser más complicada. Tendremos millones de sistemas conectados que no se actualizarán. Habrá equipos simplones (cámaras, sensores de temperatura, etc) conectados a redes con una vida mayor que los de las empresas que los han construido ¿que no? Se están diseñando equipos con muy bajo consumo que pueden durar 10 años o más con la misma batería así que piensa lo que puede evolucionar la cosa del hackeo. Por suerte no todos van a estar conectados a redes habituales sino que, al menos por el momento, se están construyendo redes de bajo consumo y bajo tráfico que podrían limitar el daño producido por una red pero igual que ciertos dispositivos que tuvieron vida temporal y que ahora prácticamente no existen (como las PDAs o las cámaras digitales compactas) a lo mejor la vida de estas redes es relativamente corta y todo va redes 5G, 6G o lo que sea. Si tenemos en cuenta que ahora un móvil tiene más potencia y memoria que un PC de no hace tanto tiempo, igual el potencial de estos nuevos equipos IoT va a ser superior a lo que pensamos.

Tampoco hemos de olvidar que tanto equipo con tanto GPS, red y electrónica ultrasensible puede ser afectada de otra manera: tormentas magnéticas o campos electromagnéticos provenientes del espacio. Seguro que alguno que lea esto pensará que estoy siendo un poco paranoico, pero recomiendo mirar este enlace de la Casa Blanca. El presidente Obama ha firmado una orden ejecutiva para coordinar la respuesta de la nación ante eventos relacionados con el "clima" del espacio ¿suena raro? Pues no es tanto. Ya sabemos que el Sol (eso que brilla arriba por el día) tiene ciclos solares de unos 11 años y que puede tener eyecciones de masa coronal, tormentas solares y otras guarradas muy espectaculares. Estas cositas a altas temperaturas están muy lejos pero tienen una particularidad: no están regidas por la física atmosférica normal sino por el electromagnetismo ya que son nubes de plasma (gas ionizado) ¿y que nos pasa si eso llega a la Tierra? Pues a nosotros, a los bichos y plantas nada, pero a los satélites, equipos de comunicaciones, sistemas de posicionamiento, les puede hacer mucha pupa y desde provocar errores a dejarlos fuera de combate y seguramente lleves en el bolsillo un teléfono con GPS dónde tienes todos tus contactos y hablas con la gente sin importar su ubicación. Pero no eres tú solo, muchas empresas se basan en Internet ahora para todo, mucha gente no usa mapas sino el GPS del coche, etc. No es que venga un apocalipsis zombie, pero el cristo que se puede montar es interesante. Tenemos una sociedad muy tecnológica, especialmente en los últimos años y cualquier cosa que afecte a nuestras redes lo vamos a notar. Por ejemplo, en mi casa hay ahora mismo siete dispositivos que se usan a diario con GPS, más algún otro ya "descatalogado" y/o retirado y seguro que en muchos hogares pasa lo mismo.

"lluvia" coronal en una tormenta solar.
Fuente: apod.nasa.gov

La famosa bomba del ArcoIris es un invento con ya mucho años, pero ahora la sociedad es mucho más vulnerable y ya casi no hace falta una bomba de hidrógeno para provocarlo. El propio Sol nos puede jugar una mala pasada.

Asustada me ha dejado ¿puedo salir o no?

El Backup ... y la madre que lo parió.

Por lo general a la hora de diseñar (o improvisar) un sistema informático se suelen dedicar bastantes horas a pensar (¡ejem!) aspectos tales como para qué sirve, cómo se va a implementar, las interfaces con el usuario, la seguridad .... se dice que incluso se llega a pensar en los requisitos del usuario, pero claro, ese último aspecto suele estar por demostrar.

Ummmm ¿Ya está aquí el brasas este de nuevo?
Seguro que hay gato encerrado.

Al final a alguien se le ocurre decir "Oye ¿y qué pasa si se cae el servidor/se corrompe el sistema/si hay un virus/vamos, que se joda esto?" a lo que muy ufano el responsable/jefe de proyecto/analista/arquitecto/entero/cuñao dice todo ufano "Tranquilo, que hacemos un backup y todo controlado"

Lo más jodido de todo es que lo normal, es que le hagan caso y la gente se quede tan tranquila. La mayor parte de los usuarios piensan que backup es un ser mágico venido de Oriente que es capaz de solucionar todos sus problemas con aquella copia en discos de 5"1/4 que se hizo al principio de la explotación del sistema. Es como ese ser proceso mágico que pasaba la ropa sucia del suelo al cajón de armario toda limpia y planchada que nos pasaba a la mayoría cuando éramos adolescentes y que desapareció también mágicamente cuando nos íbamos de casa de los padres.

Pues resulta que no. El backup es un proceso complejo, costos y sobre todo NECESARIO ¿cual es la importancia de las copias de seguridad? Pues no es ni más ni menos que la importancia que le des a tu negocio/información/fotos de la comunión. Dependiendo de tu negocio un backup puede ser incluso un requisito legal aunque la ley no lo diga así. Por ejemplo, a una operadora de telecomunicaciones se le puede pedir un listado de los accesos de determinada persona hasta cierto tiempo (un par de años me parece) Claro que toda esa información se puede guardar en los sistemas transaccionales, pero el coste y ocupación es brutal (una operadora de telecomunicaciones genera millones de registros de llamadas CADA DÍA)

No solo pongo fotos de gatos. También chistes malos.

A la hora de diseñar el proceso de backup es conveniente pensar en algunas cosas:

- Qué información estoy dispuesto a perder. A lo mejor Facebook si pierde las últimas fotos que le han subido los usuarios no es muy grave, pero si un banco pierde los movimientos de los últimos cinco minutos puede que salga en el telediario. Obviamente, lo que se copia es lo que no se quiere perder que seguro que alguno ya está pensando lo contrario.

- Cuánto tiempo puede estar el negocio sin funcionar. En el ejemplo de antes, si se cae Facebook no pasa nada salvo algún ataque de histeria y/o suicidio a lo bonzo. Si se cae el banco unas horas posiblemente lo que menos pase es que el jefe de informática actualice su CV en LinkedIn y pase a "En búsqueda activa de empleo" La recuperación del servicio puede no ser sólo cosa del backup ... pero eso ya lo contaré cuando tenga ganas de escribir; llevo desde junio sin publicar nada ¿te piensas que el próximo va a ser inminente?

- Hasta cuando quieres guardar la información. Por lo general y salvo imperativo legal, la mayor parte de copias con retenciones altas solo sirven para ocupar espacio y recursos.

- Cada cuánto tiempo he de hacer el backup. Un periodo de tiempo demasiado largo puede hacer que el backup no sea muy operativo. Un periodo de tiempo muy corto puede machacar al sistema e incluso, hacer perder copias útiles con datos degenerados (degenerados por estropeados, no por eso que estás pensando)

- En cuántos sitios debo tener las copias. Esto ya va en función de la paranioa de cada uno. Yo personalmente considero que los datos delicados deben estar al menos almacenados tres veces: la original y dos copias separadas ¿esto te parece excesivo? Pues no te cuento el sudor frío que te entra cuando se degrada el original y sólo tienes una copia ¿funcionará? ¿no funcionará? Se puede hacer una copia a disco y otra a cinta. Personalmente, creo que las copias a cinta cada vez irán más en desuso. Los discos cada vez son mayores (10 Tb ahora mismo) y con técnicas como deduplicación y compresión la capacidad aumenta mucho y las cintas son más lentas, evolucionan más despacio y tienen la mala costumbre de fastidiar las unidades de lectura y escritura con el tiempo (no demasiado tiempo por cierto)

Una vez tenidos más o menos claros lo puntos anteriores viene la parte de rascarse el bolsillo ya que:

- El backup no se hace solo, hace falta un SW adecuado (hay soluciones OpenSource como Bacula) Ten en cuenta que una de las cosas más peliagudas del sistema de backup es saber lo que tienes dentro de los TB de información que has copiado y la gestión de ese catálogo es bastante pesada. Por otro lado, este SW suele permitir una cosa interesante: la recuperación granular, es decir, si has perdido un fichero a lo mejor prefieres recuperar ese fichero en lugar de pasarte varias horas recuperando todo el filesystem de una cinta. 

- El backup hay que dejarlo en algún sitio. Cintas, VTL, cabinas de discos. Salvo que sea de manera temporal, el dejar el backup en el mismo disco/servidor/cabina donde están los originales no una buena idea. Es equivalente a dedicarte a la escalada y atar la cuerda de seguridad que te sujeta por un arnés a tu propio tobillo. Mientras no te caigas no pasa nada pero como te caigas ...

- Hay que saber qué copiar. Si quieres copiar los datos de una BD seguramente el copiar el directorio /etc no sea una buena idea. También hay que saber cómo se pueden copiar las cosas.El copiar los ficheros de una BD en funcionamiento NO es una buena idea. Es posible que recuperar algo que no sirva para nada, al menos si no has puesto la BD en modo backup claro. 

- Hay que programar ventanas para hacerlo. Si tienes datos que se actualizan cada pocos segundos a lo mejor hacer una copia al mes no es lo más adecuado. También pasa lo contrario, no por hacer una copia cada cinco minutos (existe el caso, no me lo he inventado) vas a estar más protegido.

Por último, es recomendable si no es necesario recurrir al backup hacer pruebas periódicas de recuperación, al menos para asegurarse de que las cosas funcionan, el equipo humano sabe recuperarlo, etc.

Conducimos bastante mal ....

Cuando empecé a hacer este blog no tenía muy claro sobre qué quería escribir en concreto, con lo que más o menos escribía sobre lo que me parecía. De hecho, lo sigo haciendo. En su día, tras un viaje, me dio por escribir sobre el tráfico y creo que hoy lo voy a volver a hacer.

Cuando salía de trabajar, en torno a las seis y pico las siete el cielo estaba oscuro como si estuvieramos en invierno. Teníamos encima una tormenta bastante fea. No es normal este tiempo en estas fechas, pero llevamos una semana muy desagradable climatológicamente hablando. Viento, frío, lluvia ... vamos, un encanto de primavera. No es que sea fanático del sol, pero es que este año el invierno se está poniendo un poco cansino.


Pues tras salir del trabajo me encamino al coche esperando a ver si aguantaba 30 segundos más antes de descargar ... y mira, por una vez, las gotas empezaron a caer cuando estaba dentro del coche (lo normal es que acabe empapado antes de entrar) Es una lluvia fuerte, de esta que no deja ver mucho y encima, como no había llovido mucho antes, levanta agua y barro, lo justo para tener que frenar e irte. El recorrido del trabajo a mi casa son unos 15 kms por carretera de doble sentido y otros 4-5 por ciudad. Si alguien vive en Madrid o Barcelona, pues no sabe lo que es. Tardo unos 20 minutos en hacer ese recorrido ... cuando hay tráfico. Si no lo hay, tardo menos (no mucho menos, pero ayuda a ir pensando en tus cosas si no te preocupas de otros coches)

Como he dicho era un dia feo, con mala visibilidad por la lluvia, con poca luz por las nubes ... y me he cruzado con muchos coches con las luces apagadas. De hecho, había coches que solo se veían cuando estabas sobre ellos. Creo que fue ayer cuando salió una encuesta en que los españoles no conocían las señales de tráfico. Debe ser cierto, porque al salir del parque un coche nos adelantó a todo trapo a mí, al coche que iba delante y a un camión, comiéndose al pasar a éste la señal de prohibido adelantar y media curva sin visibilidad. Todo ello con un chaparrón. Por si fuera poco, tenía detrás mío, a pocos metros una furgoneta (por supuesto sin luces) que no me iba a delantar (no había otro sitio para adelantar en algunos kms) y que estuvo todo el rato poniéndome nervioso (he sufrido un par de alcances por detrás y no me hace la menor gracia) Si hibieramos tenido que frenar por cualquier razón me hubiera llevado por delante (el suelo tenía más de un cm de agua)

¿tan complicado es guardar la distancia? ¿acaso la gente no se da cuenta de que es peligroso? y respecto a las luces ¿tan complicado es encenderlas cuando se ve mal (y no digo las de posición, digo las de cruce? Cuando te cruzas con 20 coches con las luces dadas y tú no las llevas ¿no has pensado que a lo mejor quien lo hace mal eres tú?

Saludos y cuidado en la carretera. Ahora que tengo a alguien que me lee, no quiero que le pase nada.