Me parece que se me había pasado comentaros pero…

Aunque el hacking empezó como una simple diversión para un grupo de jóvenes entusiastas, mucho ha cambiado desde entonces. Hoy en día, todos los países tienen, en mayor o menor medida, un grupo de respuesta o ataque de este tipo. Los ejemplos más claros serian la NSA y el CERT/CC (en el cual tuve la suerte de poder trabajar temporalmente) de Estados Unidos. Estamos viviendo lo que será recordado como el principio de las guerras digitales, donde los soldados usan teclados en lugar de fusiles automáticos.

Estas afirmaciones no son simples suposiciones o ciencia ficción, ya se han confirmado varios ataques de este tipo, que tenían como objetivo las infraestructuras críticas o datos de inteligencia de diferentes países. El primer caso descubierto fue Stuxnet, en 2010. La finalidad de este malware era hacer explotar los centrifugadores de Uranio de una planta de enriquecimiento nuclear de Iran, modificando los PLCs (Programmable Logic Controllers) de los mismos. Un año después, se descubrió el malware conocido como Duqu. Su objetivo en este caso no era hacer explotar nada, sino que se dedicaba a obtener información que posteriormente podría ser usada para realizar ataques similares a Stuxnet en diferentes sistemas de control industrial.

Tan solo un año más adelante, se descubrieron dos prueba más de estas batallas digitales, los malware Flamer y Gauss. Estos malware dejaban a un lado el apartado industrial y se centraban en obtener otro tipo de información privilegiada. Gauss se focalizaba en el robo de contraseñas y datos bancarios, pero Flamer iba un paso más, monitoreaba todo lo que el infectado escribía, e incluso específicamente guardaba las llamadas realizadas por Skype. Más recientemente, Ukrania ha sufrido dos ataques (Diciembre 2015 y 2016) que tiraron la red eléctrica de determinadas ciudades, utilizando el malware BlackEnergy. El último caso de este tipo apareció en 2017, que el malware Industroyer salió a la luz. A diferencia de los casos previos, este malware es altamente customizable, y permite atacar un gran número de sistemas de control industrial utilizando diferentes protocolos de comunicación.

A pesar de todos estos ataques altamente sofisticados, muchas infraestructuras criticas no están correctamente protegidas, y personas sin un alto conocimiento pueden a llegar a causar grandes problemas. Durante muchos años, este tipo de sistemas basaban gran parte de su seguridad en la conocida como security by obscurity. Principalmente, ocultaban su diseño e implementación para impedir o dificultar los ataques hacia ellos. Aunque basar tu seguridad en este concepto es completamenta incorrecto en cualquier momento, podía llegar a funcionar cuando estos sistemas estaban aislados, pero en la época de la hiperconectividad, esto no tiene ningún sentido. Actualmente existen varios buscadores de dispositivos conectados a la red, que permiten localizar sistemas vulnerables (o sin contraseña) en cuestión de segundos, sin la necesidad de realizar costosos escaneos globales.

Parece que las batallas digitales no son casos aislados, y que cada vez son más comunes. Si quieres estar preparado, te recomendamos empezar ha preocuparte por estas cosas, porque se dispararán varios unos y ceros durante las próximas décadas.

El que avisa no es traidor.

The post Cómo el hacking podría cambiar la historia appeared first on S3lab.

Me parece que se me había pasado comentaros pero…

Existe una nueva moda en el mundo del malware, el denominado cryptojacking. En muchas guerras usaban a los prisioneros enemigos para el minado de minerales, este sería un símil de este caso pero trasladado al siglo XXI. Consiste en utilizar los equipos de las víctimas del malware para el minado de criptomonedas. En los últimos tiempos, el ransomware se había convertido en uno de los tipos de malware mas comunes, pero parece que el cryptojacking está quitándole el puesto a pasos agigantados.

Aunque esta técnica resulte completamente nueva para muchos, lleva con nosotros casi desde el principio de las criptomonedas. En cuanto el Bitcoin comenzó a ganar atención publica (allá por 2011), también vino de la mano este tipo de malware. Al principio no resultó muy mediático ni común, pero en 2015 estalló la noticia de que el famoso cliente de descargas uTorrent estaba instalando un software para minar Litecoins. Desde entonces, este tipo de malware no ha parado de crecer, siendo este último año el repunte mas grande.

De todas formas, los usuarios no son los únicos afectados por este tipo de ataques, muchos servidores (especialmente CMSs) han sufrido también el cryptojacking. Uno de los casos mas recientes ha sido el de varios servidores de WordPress. Una vez infectados, se utilizaban tanto para el minado de Monero (una criptomoneda adecuada para este tipo de hardware) como para atacar otros servidores WordPress y lograr mas víctimas. Se estima que únicamente con este malware, el atacante ha ganado mas de 100K dólares en pocos meses.

De todas formas, aparte de los servidores o los diferentes programas de escritorio/móvil, existe una tercera forma de lograr minar criptomonedas en otros equipos, el navegador. Por un lado, es posible lograr dicho objetivo haciendo que el usuario instale una extension maliciosa. Este sería el caso ideal para el atacante, ya que el navegador estará minando criptomonedas siempre y cuando el propio navegador esté en marcha. A pesar de ello, el control sobre estas extensiones ha aumentado recientemente, llegando al punto de que el propio Google ha empezado a borrar este tipo de extensiones directamente. Por otro lado, es posible realizar el minado a través de cualquier web normal mediante JavaScript. Aunque este código tan solo se ejecuta mientras la propia página está abierta, en casos de reproducción de video o lectura de artículos, esto puede ser mucho tiempo. Aun cuando existe la posibilidad de preguntar al usuario antes de comenzar (una forma de monetizar una web sin necesidad de anuncios), parece que la gran mayoría de las veces se realiza sin ningún tipo de consentimiento previo.

El primer cuarto del 2018 ha sido el segundo peor cuarto que el Bitcoin ha tenido jamás, con una caída de mas del 50%. No sabemos si este tipo de situaciones harán que el cryptojacking se reduzca, lo que sabemos seguro es que no será una desaparición rápida (si  llega a bajar a corto plazo).

El que avisa no es traidor.

The post No mina criptomonedas todo lo que reluce, pero casi appeared first on S3lab.

Me parece que se me había pasado comentaros pero…

No todos los malware ejecutan su payload malicioso instantaneamente en cuanto se descargan y ejecutan por primera vez. Muchas veces, estos se mantienen en la sombra y se disparan únicamente cuando una determinada situación ocurre (algo así como una mecha inteligente). Ese tipo de malware se denomina «bomba lógica«.

Unos ejemplos simples de este tipo de malware son las bombas que explotan únicamente en fechas determinadas, o en el caso de dispositivos móviles, las que liberan su payload únicamente cuando la víctima se encuentra cerca de determinado lugar. De todas formas, existen otros tipos de bombas lógicas muy típicas que resultan muy interesantes y que se aprovechan de un fallo en el programa que interactúa con los propios archivos maliciosos:

• Billion laughs: También conocida como bomba XML, como bien indica su nombre, se utilizaba para sobrecargar parsers XML, generalmente de servidores HTTP. Este ataque explota el hecho de que XML permite definir entidades. Supongamos una entidad (la llamaremos entidad uno) que tiene única y exclusivamente el string «lol«. Posteriormente, crearemos la entidad dos que se definirá como 10 entidades uno, que a su vez están definidas como 10 entidades tres. Siguiendo esta regla hasta llegar a la entidad nueve, finalmente el parser XML tratará una única ocurrencia de la entidad nueve como un billón de instancias de esa risa inicial. Esto ocupará varios gigas de memoria y finalmente la aplicación web no será accesible.

• Git-Bomb: En este caso, aunque el funcionamiento sea muy similar al del ataque «billion laughs«, en este caso el damnificado será nuestro querido controlador de versiones git. Con tan solo un repositorio perfectamente formado por 12 objetos, se puede lograr esta interesante hazaña. El secreto se encuentra en la de-duplicación de «blobs» de git, que se utiliza principalmente para poder hacer los repositorios más pequeños y permitir usar el mismo blob cuando un archivo se mantiene sin cambios entre commits. Git también permite la de-duplicación de objetos árbol (los cuales definen la estructura del repositorio). Por tanto, siguiendo la técnica de la bomba XML, podemos hacer que git intente crear un billón de archivos con 10 referencias al blob y solamente 10 objetos árbol en total.

• Zip of Death: Este es uno de los ataques más antiguos de este tipo, pero dirigido al decompresor de archivos. El ejemplo más típico en este caso es el famoso «42.zip«. Se trata de un archivo comprimido de tan solo 42 kilobytes. Internamente este archivo tiene 5 capas de archivos zip anidados en grupos de 16, siendo la capa inferior un archivo que contiene 4.3 gigabytes. Finalmente el sistema intentará descomprimir 4.5 petabytes, lo cual causará más de un error en el equipo. Si algún autoestopista galáctico os pregunta el sentido de la vida, desconfiar de él, no es oro todo lo que reluce.

Las bombas lógicas no son solo algo teórico que los investigadores han imaginado, existen varios casos reales que han supuesto más de un quebradero de cabeza a más de uno. Un administrador de sistemas de Medco Health Solutions y un contratista de  Fannie Mae acabaron bastante tiempo entre rejas por introducir bombas lógicas en sus servidores.

Ejecutar o instalar unicamente cosas de las cuales confieis totalmente su origen y su funcionamiento en vuestro equipo. Si podéis echar un ojo al código en el momento haya alguna duda, estaréis mucho más seguros todavía.

El que avisa no es traidor.

The post Un simple click puede generar una explosión lógica appeared first on S3lab.

Cuando alguien se entera de que su equipo está infectado, automáticamente aparece una pregunta en su mente, ¿cómo ha ocurrido ésto? Primero se piensa en los archivos recientemente descargados/instalados, después en las páginas visitadas, y si no aparece ninguna respuesta contundente en los dos casos previos, se acaba desistiendo y maldiciendo la situación. Aunque no me atrevería a decir que la tercera opción posible que os voy a explicar sea la más común, sin duda es una. Los USBs son un periférico que puede llegar a tener un gran poder sobre muchos factores de los equipos, ya sea tanto para cosas buenas como por supuesto, para cosas más oscuras.

Gracias a los estragos que causaron los autorun.inf en el pasado (como se puede inferir por su nombre, ejecución automática al ser insertado), muchas personas han aprendido que coger un USB del suelo y ponerlo en el equipo no resulta algo seguro. De todas formas, existe otra manera de lograr objetivos maliciosos haciendo uso de ese querido periférico que muchos ni se plantean. Estos ataques principalmente se aprovechan de situaciones en las que los puertos USB se encuentran al descubierto y que cualquier persona puede acceder a ellos sin levantar mucha sospecha (estando el equipo encendido o incluso apagado). Aunque parezca algo poco común, si pensáis un poco, rápidamente os vendrán muchas situaciones que encajan: oficinas bancarias, centros policiales, consultas medicas… Un atacante malicioso o un hacker podría tomar ventaja e introducir un USB en dicho terminal y crear muchos quebraderos de cabeza al dueño o responsable del mismo.

Empezando por uno de los más conocidos, nos encontramos con el BadUSB. Estos USBs trabajan sobre una premisa muy básica a la vez que ingeniosa. Se basa en hacer que el equipo interprete que al introducir el USB realmente se ha conectado, por ejemplo, un teclado o ratón regular. Posteriormente, se ejecutan unos payloads de pulsaciones pre-programadas (usando un lenguaje de scripting sencillo) a una velocidad mayor que 1000 pulsaciones por minuto. Cada una de estas pulsaciones se considerarán completamente benignas para el equipo, ya que vienen de un teclado «supuestamente» normal. La cantidad de ataques que se pueden realizar son casi infinitos: creación de puertas traseras, envío de archivos confidenciales a servidores FTP, copia de datos personales y cookies… (podéis encontrar ejemplos de payloads en Github). Uno de los USBs más famoso de este tipo es el Rubber Ducky, pero existen varios con funcionalidades similares, como pueden ser Malduino  o USBdriveby.

El robo de información privada o la propia infección del equipo puede resultar aterrador para muchos, pero las posibilidades que dan los USBs maliciosos van mucho más allá. Más concretamente, un atacante podría llegar a «freír», literalmente, nuestro hardware. Así como lo leéis, simplemente insertando un USB, podríamos llegar a quedarnos sin nuestros datos locales (bueno, si no realizamos un trabajo de ingeniería forense). El funcionamiento, al igual que en el caso de BadUSB, resulta sencillo pero muy ingenioso. Cuando el USB es insertado, comienza a cargar los condensadores internos. Tras finalizar la carga, los descarga a través del propio puerto. Este ciclo de carga y descarga se repite varias veces por segundo. El proceso se ejecuta en bucle hasta que el USB es extraído. Las consecuencias son casi instantáneas, el equipo caerá en cuanto el USB sea introducido. El USB no es de un solo uso, se puede usar tantas veces como se quiera en cuantos equipos se desee, ya que realmente no está realizando un trabajo extremadamente perjudicial para los condensadores.

Es muy importante comentar que estos ataques no solo afectan a equipos de sobremesa o portátiles, sino que practicamente todos los aparatos que tienen puertos (e.g., smartphones y tablets) pueden sufrir en una medida u otra alguno de estos ataques, sino ambos.

El que avisa no es traidor.

The post Todo empezó con el USB de aquél hacker appeared first on S3lab.

Aunque muchos habréis oido hablar del phishing, incluso haber sido víctimas de alguno en el peor de los casos, igual no estáis tan familiarizados con el siguiente paso evolutivo: el spear phishing. Empezando desde los cimientos, el phishing se basa en embaucar usuarios para que compartan información sensible, como contraseñas, nombres de usuario o incluso detalles de la tarjeta de crédito. En algunas situaciones también se suele relacionar con la distribución de malware.

Generalmente el atacante malicioso se «disfraza» como una entidad confiable para darle al usuario la sensación de que la compartición de dichos datos es completamente legítima. La forma de comunicación con el usuario va desde email, redes sociales, llamadas telefónicas (vishing) e incluso mensajes de texto (smishing). Estos ataques se suelen enviar de forma simultánea al mayor número de personas posible, para lograr el máximo número de posibilidades de éxito. Aquí comienzan las diferencias del phishing con el spear phishing. Como bien se puede intuir del propio nombre de la técnica (traduciéndolo al castellano), cambiamos «la pesca» por «la pesca con arpón».

El spear phishing NO se basa en realizar ataques masivos con la esperanza de que usuarios desprecavidos caigan en la trampa y muerdan el anzuelo, sino que se basa en realizar ataques dirigidos específicos para cada persona. El mail incluirá información personal del usuario y parecerá un mensaje de una entidad con la cual el usuario tiene relación. De esta forma, las posibilidades de que el usuario no detecte la estafa son mucho mayores. En muchas ocasiones, este tipo de emails son difíciles de detectar a primera vista, ya que se asemejan en gran medida a un email completamente legítimo.

La pregunta del millón es… ¿Pero cómo consiguen esa información privada? Existen muchas posibles respuestas, pero sin duda una de las más comúnmente utilizadas para realizar este tipo de ataques, son las redes sociales. Muchas veces las personas no son conscientes de la cantidad de información privada que están «filtrando» sin querer: donde realizan la compra, establecimientos que frecuentan, lugar de trabajo… y así una larguísima lista de posibles entidades que un atacante malicioso puede intentar impersonar para lograr cierta información sensible de un posible objetivo. Este tipo de análisis se pueden hacer de una forma manual o de una forma completamente automatizada mediante un bot. Generalmente, la cantidad de información necesaria para cada ataque depende completamente de la importancia de la víctima concreta. Por tanto, existen campañas de spear phishing muy trabajadas, y otras algo menos concretas.

Como ejemplo, voy a explicaros una campaña de spear phishing bastante interesante que ha ocurrido en el último año en unas fechas muy concretas. El atacante empezaba monitorizando los diferentes torrents del último capítulo de “Game of Thrones (HBO)”. Posteriormente, guardaba la IP de las diferentes personas que se estaban descargando el capítulo, hora de descarga e información concreta de dicho archivo. Posteriormente, haciéndose pasar por una empresa legítima que se dedica a realizar demandas por copyright, informaba a sus correspondientes ISPs (proveedores de servicio) que dicha IP estaba realizando una descarga ilegal. Incluia toda la información de la que disponía e indicaba que tomarían acciones legales por dicha infracción. En ese punto, el ISP hacía un forward del email al cliente concreto con dicha IP en ese momento. El cliente, asustado porque efectivamente él había realizado esa descarga ilegal y el email venía directamente de su ISP, confiaba en la veracidad de todos los datos que aparecían en el email y acababa pagando una «multa» ficticia al atacante.

Llegados a este punto, me parece que la mayor bondad del spear phishing frente al phishing tradicional es clara: una mayor posibilidad de que finalmente el usuario acabe picando el anzuelo. Aunque parezca mentira, muchas veces los ataques genéricos de phishing logran un gran número de víctimas, por lo que muchas personas se pueden estar preguntando, ¿entonces para qué molestarse en la personalización? Generalmente, las campañas masivas de phishing son fácilmente detectables, por lo que no suelen durar mucho. En cambio, realizando este tipo de técnicas mas específicas, logran pasar por debajo del radar. Si al atacante le importa mas la calidad de esos datos (de empleados de una empresa concreta por ejemplo), en lugar de la cantidad, esta técnica resulta muchísimo mas efectiva.

Para acabar, un consejo tan útil como obvio: Nunca confíes a un email que te pida información privada o te descargues un archivo adjunto inesperado, por muy completo y real que parezca. Porque recuerda, la pesca con arpón está de moda.

El que avisa no es traidor.

The post Spear Phishing, adaptando anzuelos a objetivos appeared first on S3lab.

Me parece que se me había pasado comentaros pero…

Es extremadamente común que un malware avanzado no se dedique únicamente a esconder su código con diferentes packers, sino que también intente detectar si está siendo analizado de forma dinámica mediante una sandbox. En caso de darse cuenta de que lo están vigilando, modificará su comportamiento para esconder su funcionalidad maliciosa y mostrar funciones completamente inocuas. De esa forma, el sistema de análisis clasificará la muestra como benigna y podrá infectar el sistema objetivo sin problema alguno.

Muchas veces, conseguir detectar al vigía no es sencillo, por lo que los autores de malware suelen comprobar si efectivamente el malware está siendo detectado o no por determinadas sandbox. Para ello, hacen uso de las diferentes herramientas publicas. Van enviando las versiones de su malware hasta lograr una que pase completamente desapercibida. De todas formas, esto puede llegar a ser contraproducente, ya que como se ha mostrado en un trabajo reciente, el envío consecutivo de estas muestras permite la detección temprana de esos malware primigenios. Ahora, nos centraremos en explicar las ideas generales de cada una de las principales técnicas que se usan actualmente en el malware para detectar sandbox:

• Interacción de usuario: Como cabe esperar, los análisis dinámicos en sandbox no se realizan de forma manual, sino de una forma completamente automatizada. Basándonos en eso, es posible detectar el análisis simplemente fijándonos en la interacciones que hace o debería hacer un usuario (movimientos de ratón, pulsaciones de teclado…). Esto se puede hacer tanto incitando al usuario ha realizar dichas acciones mediante un instalador falso o comprobándolas sin ningún tipo de incentivo.

• Penalización de tiempo: Monitorizar un sistema y su comportamiento no es sencillo y hace uso de un gran número de herramientas de forma interna para lograrlo. Esta vigilancia tiene un castigo: el tiempo. La cantidad de pasos que tiene que dar cada ejecución es mayor, por lo que si analizamos el tiempo necesario para realizar cada acción podemos darnos cuenta que algo «extra» está ocurriendo, permitiéndonos detectar la presencia de una sandbox.

• Sistemas artificiales: Esta técnica no se basa en la detección de propiedades que puedan identificar una sandbox, sino en detectar que la máquina no se trata de un sistema de producción normal. Algunos de los ejemplos más sencillos serían la ausencia de ciertos drivers, tamaños de disco, memoria extremadamente pequeña o la falta de aplicaciones indispensables para cualquier usuario. Ya comentamos algo similar al hablar de honeypots de baja interacción, siendo éste uno de sus mayores problemas.

• Tecnologías específicas: Al contrario que en el punto anterior, en este caso nos centraremos en detectar situaciones anómalas que muestran un comportamiento fuera de lo común. La gran mayoría de sandbox usan hooks para capturar las comunicaciones entre diferentes componentes del sistema. Con una simple verificación del hash de ciertos ficheros del sistema se puede detectar que han modificado el código de los mismos. Para casos de emulación, realizar llamadas a instrucciones de CPU no incluidas puede ser muy útil.

De todas formas, estas técnicas no funcionan en todos los casos, ya que de la misma manera que el malware intenta detectar que lo vigilan, el que vigila intenta esconder lo que está haciendo. Si algo queda claro después de todo esto, es que las sandbox genéricas han quedado obsoletas y que confiar en un análisis así no es algo que haya que hacer si no queremos llevarnos ningún susto.

El que avisa no es traidor.

The post Ese malware sabe que lo están vigilando appeared first on S3lab.