Vulnerabilidad en Drupal deja a millones de sitios web en peligro
Responsables del gestor de contenidos, Drupal, han advertido a sus usuarios que sus sitios web están en peligro si no actualizaron en su momento a la última versión publicada el 15 de octubre.
Ataques automáticos que comprometen webs realizadas con Drupal 7 que no fueron actualizadas a la versión 7.32 comenzaron a las pocas horas de publicarse el parche. Si no se actualizó la web antes del 15 de octubre a las 23h UTC, es decir a las 7 horas de la publicación del parche, se debe proceder como si todas las webs estuvieran comprometidas, explican desde el CMS.
Drupal es un paquete de software de código abierto que proporciona un sistema de gestión de contenido (CMS) para sitios web. Es el tercero del mercado por popularidad detrás de WordPress y Joomla y se creen que esta vulnerabilidad crítica de inyección de código SQL ha dejado comprometidos 12 millones de sitios web.
Curiosamente la última actualización Drupal 7.32 corregía este tipo de vulnerabilidades. El problema reside en que de nada sirve actualizar ya estos sitios comprometidos, algo que ha ocurrido mediante “ataques automatizados” a las 7 horas de publicarse el parche, explican.
No es sencillo parchear tan rápidamente las máquinas, dicen desde la firma Sophos. Muchos usuarios no recibieron el aviso a tiempo simplemente porque estuvieran durmiendo por la diferencia horaria. La solución sería que Drupal implemente un sistema de actualización automática para la instalación de los parches de seguridad, algo que ya tienen otros gstores como WordPress.
En el ámbito de seguridad de la información los controles nos permiten mitigar riesgos, razón por la cual se han desarrollado marcos de trabajo (frameworks) que ofrecen diferentes tipos de medidas de seguridad.
En esta ocasión vamos a revisar los Controles de Seguridad Críticos (CSC) para la ciberdefensa, una propuesta inicialmente coordinada por SANS Institute que luego fue transferida al Consejo de Ciberseguridad para su administración y mantenimiento.
¿Qué son los controles de seguridad críticos y qué los diferencia?
Se trata de un conjunto de controles que definen acciones específicas para la ciberdefensa, desarrollado y mantenido por diferentes partes interesadas, como empresas, agencias gubernamentales, instituciones académicas y expertos en el tema.
Se denominan críticos porque son el resultado del conocimiento combinado que se tiene actualmente sobre los ataques y las medidas de seguridad utilizadas para mitigarlos. Estos controles han sido priorizados con base en la reducción de riesgos y la protección que ofrecen contra las amenazas más comunes. Además se trata de un consenso sobre el conjunto de las medidas que resultan efectivas para detectar, prevenir, responder o mitigar los ciberataques.
Aunque no busca reemplazar a los marcos de trabajo y estándares, estos controles surgen como una opción para ofrecer nuevas alternativas de seguridad, ya que los requisitos de las normas y otros marcos desarrollados en ocasiones se enfocan en el cumplimiento y elementos de gestión, destinando recursos a actividades que no están directamente relacionadas con la protección contra las amenazas.
Características de los controles de seguridad críticos
Los controles tienen como característica principal su enfoque hacia la priorización de las funciones de seguridad, que han mostrado efectividad para la mitigación de riesgos, lo que indica qué debería realizarse primero, dentro de una lista relativamente pequeña de acciones.
Además se trata de un subconjunto del catálogo definido por National Institute of Standards and Technology (NIST) SP 800-53, por lo que los elementos recomendados han sido probados con anterioridad. La versión 5.1 de este documento incluye 20 controles de seguridad críticos.
Para llevar un control se presenta una descripción de su importancia en cuanto a la forma de identificar o bloquear la presencia de ataque, así como la forma en la que un atacante podría aprovechar la ausencia de este control. Para identificarlos se emplean las letras CSC (Critical Security Control) y el número correspondiente a la prioridad del mismo.
Además, incluye una lista de las acciones específicas que las organizaciones deben llevar a cabo para implementar, automatizar y medir la efectividad del control. El CSC también considera procedimientos y herramientas que permiten su implementación y automatización, así como métricas y pruebas que permiten evaluar el estado de la implementación y su efectividad. Por último, se cuenta con un diagrama entidad-relación de los componentes utilizados durante la implementación.
Categorías de CSC
Dentro de la lista de controles de seguridad críticos podemos encontrar cuatro categorías que permiten tener una mejor descripción de los mismos, con base en las características que se muestran a continuación:
Triunfos rápidos: Son los tipos de controles que proporcionan una reducción significativa de los riesgos sin la necesidad de llevar a cabo importantes cambios en aspectos financieros, de procedimientos, en arquitecturas o técnicos. También pueden proporcionar dicha reducción de manera sustancial o inmediata sobre los ataques más comunes en las organizaciones. Medidas de visibilidad y de atribución: Estos controles buscan mejorar los procesos, arquitectura y capacidades técnicas de las organizaciones para monitorear sus redes y sistemas informáticos, para detectar intentos de ataques, localizar los puntos de acceso, identificar equipos comprometidos, actividades de infiltración de atacantes u obtener información sobre los orígenes de un ataque. Configuración de seguridad de la información mejorada e higiene: Tienen como objetivo reducir el número y la magnitud de las vulnerabilidades de seguridad, así como mejorar el funcionamiento de los sistemas informáticos en la red, a través de un enfoque hacia las prácticas de seguridad deficientes que podrían dar ventaja a un atacante. Subcontroles avanzados: Utilizan nuevas tecnologías o procedimientos que proporcionan mayor seguridad, pero representan mayor dificultad para su implementación, mayor costo o requieren más recursos, como personal altamente calificado.
Una opción más de seguridad a considerar
Entonces, los controles de seguridad críticos pueden ser utilizados como una opción más de medidas para la protección, con las características propias de esta lista como la priorización de las acciones a realizar y su completa orientación hacia la detección, prevención, respuesta o mitigación de amenazas a la seguridad.
En este sentido, pueden contribuir en la complementación de otros estándares o mejores prácticas de seguridad, ya que ofrecen medidas actualizadas sobre las amenazas más comunes y otras características, como elementos para la medición de la efectividad, procedimiento y herramientas.
Con el lanzamiento de Android 5.0 Lollipop a la vuelta de la esquina son muchos los usuarios que esperan ansiosos las nuevas funcionalidades del sistema operativo de Google. Muchos usuarios se sentirán especialmente atraídos por la nueva interfaz Material Design pero nosotros vamos a centrarnos en 5 aspectos de la seguridad que han sido mejorados en esta nueva versión de Android.
Cifrado por defecto
Esta es quizás la característica que pasará más desapercibida para los usuarios pero que otorgará mayor privacidad a los datos que almacenemos en nuestro dispositivo. Si bien es cierto que Android venía ofreciendo a sus usuarios la posibilidad de cifrar el contenido de sus dispositivos, esta opción requería ser activada por el usuario.
En Lollipop, el cifrado vendrá activado por defecto, manteniendo seguras nuestras fotos, vídeos o documentos privados de miradas indiscretas, necesitándose una clave para poder acceder a los mismos de forma segura. No hace falta decir que esta clave de cifrado deberá ser lo suficientemente robusta como para que no pueda ser fácilmente adivinada o rota por mecanismo de fuerza bruta.
Viendo que Apple también ha adoptado medidas similares, esta característica parece una reacción de ambas empresas ante los casos de espionaje gubernamental destapados tras las revelaciones que aún al día de hoy siguen produciéndose por los documentos filtrados por Edward Snowden.
De todas formas, de nada sirve cifrar esta información en nuestro dispositivo si después la subimos a sistemas de almacenamiento en la nube. Es importante que, si queremos tener una copia de seguridad de esta información, esta también se encuentre cifrada.
Bloqueo de la pantalla
Una de las medidas de seguridad básicas que prácticamente todos los usuarios realizan es bloquear su pantalla con un código PIN o un patrón de desbloqueo. A estos sencillos métodos se han añadido recientemente la posibilidad de utilizar valores biométricos como el reconocimiento facial o de nuestras huellas dactilares.
Google quiere ir un paso más allá y hacer este proceso de bloqueo / desbloqueo de forma más sencilla y propone utilizar Smart Lock, una funcionalidad de Android Lollipop que permite desbloquear nuestro dispositivo mediante la vinculación vía Bluetooth o NFC a otro dispositivo, como por ejemplo un smartwatch (reloj inteligente). Además, el sistema de reconocimiento facial se ha mejorado, haciendo que su utilización sea más rápida y efectiva.
Además de estas nuevas características, podremos configurar qué tipo de notificaciones se pueden mostrar en la pantalla de bloqueo, pudiendo acceder a información interesante de forma rápida y manteniendo nuestro dispositivo bloqueado.
Compartir WiFi de forma segura
Buena parte de la seguridad de una red WiFi depende de la robustez de su contraseña. Estas contraseñas suelen darse alegremente demasiadas veces, especialmente en sitios públicos como bares o bibliotecas, algo que compromete seriamente la seguridad de la red y que puede provocar que tengamos visitantes inesperados.
Para evitar tener que ir cambiando continuamente de contraseña, Google propone un nuevo sistema a base de utilizar etiquetas inteligentes con tecnología NFC. De esta forma, podremos almacenar la contraseña de nuestra red WiFi en una de estas tarjetas y dársela a los usuarios que quieran hacer uso de la misma, sin comprometer en ningún momento la clave usada para proteger la red.
Restauración de fábrica con contraseña
La popularización de los smartphones también ha provocado que los delincuentes se fijen en ellos como un botín apetecible y cada día se roban miles de ellos para desconsuelo de los usuarios. Existen herramientas como Android Device Manager o nuestra solución de seguridad ESET Mobile Security que permiten bloquear remotamente el dispositivo borrado, borrar su contenido o incluso localizarlo en Google Maps.
No obstante, si se realiza una restauración del dispositivo al estado en el que sale de fábrica, estas aplicaciones también desaparecen y perdemos la oportunidad de intentar recuperar nuestro Smartphone.
Para evitar esta situación, en Android Lollipop se requiere una contraseña para restaurar el teléfono a los valores de fábrica. De esta forma, si un ladrón intenta “limpiar” el teléfono para venderlo de segunda mano no podrá hacerlo sin esta contraseña, dándole más tiempo al legítimo propietario para tratar de recuperar su dispositivo.
SELinux, más seguro todavía
Desde la aparición de Android, el sistema operativo siempre ha confiado en una sandbox para ejecutar las aplicaciones en un entorno aislado de forma controlada. No obstante, si analizamos la situación actual del malware en dispositivos móviles observaremos como los delincuentes han conseguido saltarse esta protección y propagan sus amenazas sin muchos problemas.
Google quiere poner fin a esta situación y en Lollipop activa por defecto el modo “enforced” para las aplicaciones en todos los dispositivos. De esta forma se evita que los delincuentes se aprovechen sin demasiadas complicaciones de las vulnerabilidades que vayan apareciendo en el sistema. Sin duda un movimiento inteligente por parte de Google que no solo nos beneficia a los usuarios de a pie si no que apunta también a los entornos corporativos.
Conclusión
Todas estas características ayudarán sin duda a hacer de Android un sistema más seguro pero no hemos olvidar que los usuarios somos la mayoría de las veces la principal línea de defensa y hemos de estar informados acerca de las amenazas que puedan afectar a nuestros dispositivos. Si además contamos con una solución de seguridad como ESET Mobile Security (que cuenta con una versión gratuita) que nos ayude a establecer capas de defensa adicionales, podremos disfrutar de todas las bondades del nuevo Android Lollipop de una forma segura.
El pasado viernes, en la última jornada de la Ekoparty, los investigadores representantes de Core Security Technologies, Martin Balao y Martin Fernandez, nos deleitaron con su demostración de explotación de aplicaciones Android para lograr la ejecución de comandos en dispositivos remotos. Esto se lograba mediante la posibilidad de inyectar procesos para hacer uso de aplicaciones con vulnerabilidades conocidas, y así conseguir acceso a los permisos vigentes en el equipo víctima. A lo largo de su presentación explicaron cómo explotar, escalar y post-explotar este tipo de debilidades presentes en uno de los sistemas operativos móviles más utilizados mundialmente, de manera absolutamente imperceptible para el usuario del terminal.
¿En qué consiste la explotación?
La idea principal de su desarrollo radica en la inyección de procesos para obtener los permisos otorgados a una aplicación vulnerable, y así lograr ganar acceso a la Dalvik VM. Esto se logra mediante la explotación de la clase WebView, la cual presenta componentes HTML y javascript –usualmente utilizados para mostrar publicidades al usuario. Éstos vuelven posible la exposición de instancias de clases de Java con la utilización del método addJavascriptInterface() que exporta un objeto JSInterface, deviniendo en la invocación de métodos estáticos como getClass() o forName(), y la eventual obtención del contexto de ejecución conjuntamente a la explotación de cualquier clase cargada en la VM, pudiendo ejecutarse con esta vulnerabilidad diferentes comandos en el sistema operativo remoto.
Entre las dificultades que este enfoque presenta encontramos la fuerte presencia de sandboxing en Android, con aplicaciones corriendo en espacio de usuario, sin privilegios de administrador –y consecuentemente, sin acceso al sistema de archivos o la posibilidad de instalar otras aplicaciones, y el hecho de que binder –el driver del kernel en el sistema operativo Android– utiliza tanto identificadores de usuario como de procesos en su operatoria.
Dado que la presencia de sandboxes restringe la comunicación entre aplicaciones, el objetivo de la explotación se torna entonces en utilizar permisos de aplicaciones vulneradas para interactuar con otros procesos, no desde un proceso separado, sino con la escritura e invocación de archivos en el filesystem desde el mismo proceso mediante inyección. Esto implica la capacidad de alocar un espacio de memoria, escribir un shellcode en el mismo, crear un hilo que lo ejecute, y lograr realizar esto sin corromper la memoria virtual del proceso y el estado de los diferentes hilos.
Y ahora, ¿cómo resulta esto posible?
Ya que, al acoplar un depurador a un proceso, generamos otro proceso padre del mismo bajo nuestro control, somos capaces entonces de interceptar los mensajes enviados al hilo original, otorgándonos el poder de escribir espacio de memoria –incluso de sólo lectura–, leer el contexto de ejecución del hilo, secuestrarlo, detenerlo, o ejecutarlo en un lugar de memoria diferente. Con base en este principio, podemos acoplar un depurador a un hilo de la Dalvik VM, alocar memoria, escribir un shellcode, crear un hilo de ejecución, y utilizar las variables mapeadas entre direcciones físicas y virtuales, dejando finalmente el proceso en su estado original.
Algunos linkers dinámicos presentan la función dlopen, la cual carga una dirección en la memoria del proceso. Para ubicar esta función y acoplarse a ella, es posible buscar la entrada correspondiente en la Global Offset Table (GOT), la cual nos redireccionará a la posición final absoluta de los símbolos de la llamada a la función, pero sólo una vez que el linker dinámico la resuelva.
Entonces, debemos mirar cada entrada en la Procedure Linkage Table (PLT), las cuales constan de un pequeño código ejecutable. En vez de llamar a la función directamente, el código llama una entrada en la PTL, la cual luego se encarga de invocar la función genuina. Esta estructura es conocida como “trampolín”. La identificación de este arreglo se basará en el estudio de patrones aritméticos de los registros, donde cada secuencia de instrucciones corresponde a una función diferente. Una vez determinado el trampolín correspondiente a dlopen, es posible colocar en éste el hilo secuestrado a ejecutar.
La clase ActivityThread del framework contiene un método estático que inicializa la creación del hilo principal de la aplicación vulnerable. Ésta presenta un atributo sMainThreadHandler que devuelve una instancia de Handler, la cual permite mediante el método post() encolar objetos Runnable a ser ejecutados. Un atacante puede generar una llamada nativa para invocar este método, y así obtener una referencia a un objeto Context. Este último actúa como interface para acceder a la información general sobre el contexto de ejecución de la aplicación, como ser recursos y clases específicos de la misma, o llamadas desde binder al Activity Manager Service para realizar operaciones como lanzar actividades, publicar y recibir intentos, y concretar acciones de alto nivel –como la lectura o envío de SMSs.
Resumiendo lo aprendido…
Luego de la inyección, un atacante podría interactuar con binder utilizando Java a modo de post-explotación. De esta forma, se consigue acceso a los objetos en Java, sus métodos, y los métodos estáticos de las clases a las que pertenecen. Una manera de lograr esto es instanciar un objeto de APK ClassLoader, y utilizarlo para cargar código malicioso.
El resultado final de la explotación es la posibilidad de reemplazar los javascripts, incluir payloads binarios, escribir éstos en el sistema de archivos, y concluir con un Java Agent ejecutando en el equipo víctima con el mismo identificador de proceso que la aplicación vulnerable, lo que permite la posterior escalación de privilegios y la inyección remota de comandos –como la generación de llamadas o el envío de SMSs, el listado del sistema de archivos o de los procesos actualmente siendo ejecutados en el sistema operativo.
Como bien resaltaron los oradores, el comprender este tipo de vulnerabilidades nos recuerda la importancia de evitar aplicaciones depurables en entornos de producción, siendo las entidades corporativas potenciales blancos para estos ataques. Además, los archivos .apk construidos en modo standalone –es decir, paquetes de aplicación que no requieren de otros paquetes o archivos para funcionar– se constituyen como un sistema inherentemente débil, que de ser combinado con un proceso de explotación como el explicado a lo largo de esta charla, pueden generar poderosos vectores de ataque.
No es nueva, puede que tenga un mes desde que se descubrió pero va avanzando:
Un hacker de sombrero blanco (WhiteHack) de Suecia dice que ha encontrado un agujero de seguridad grave en Yosemite de Apple OS X que podría permitir a un atacante tomar el control de su ordenador.
Emil Kvarnhammar, un hacker de la firma de seguridad sueca TrueSec, llama a la vulnerabilidad "rootpipe" y ha explicado cómo lo encontró y cómo se puede proteger en contra de ella.
Es una llamada vulnerabilidad de escalada de privilegio, lo que significa que, incluso sin una contraseña a un atacante podría conseguir el más alto nivel de acceso en una máquina, conocida como acceso a la raíz. A partir de ahí, el atacante tiene el control total del sistema.
Afecta a la versión más reciente de OS X, versión 10.10, conocida como Yosemite. Apple no ha solucionado el fallo, sin embargo, él dice, por lo TrueSec no proporcionará detalles aún de cómo funciona
El malware o los códigos maliciosos han estado aquí de alguna manera por más de 40 años, pero el uso de malware para tomar el control de un grupo de computadoras organizadas en algo llamado “botnet“, es un fenómeno del siglo 21. Las botnets han sido responsables de algunos de los incidentes de seguridad más costosos de los últimos 10 años, por lo que hay mucho esfuerzo puesto en derrotar a este tipo de amenazas y, cuando es posible, cerrarlas de una vez.
Recientemente, tuve la chance de entrevistar a alguien que pasa mucho tiempo batallando botnets: Pierre-Marc Bureau, Security Intelligence Program Manager de ESET. Le pedí que explicara qué son, qué amenaza suponen, y cómo defenderse de este tipo de malware. ¿Qué es una botnet, cómo funciona y cómo se propaga?
La palabra botnet se compone de dos palabras: “bot” y “net“. “Bot” viene de “robot“, un nombre que a veces le damos a una computadora que ha sido infectada con software malicioso. “Net” viene de “network” (red), un grupo de sistemas que están conectados entre sí. Las personas que escriben y operan malware, no pueden ingresar manualmente a cada equipo que han infectado. En su lugar, utilizan botnets para manejar de manera automática un gran número de sistemas infectados. En resumen, una botnet es una red de computadoras infectadas, y dicha red es utilizada para propagar el malware. ¿Cómo puedes darte cuenta que tu equipo es parte de una botnet? ¿Tiene impacto sobre el rendimiento de un sistema?
Cuando una computadora forma parte de una botnet, puede recibir instrucciones para, entre otras cosas, enviar spam o saturar un sitio web. Estos comportamientos pueden ser visibles para aquellos usuarios que tienen un limitado ancho de banda de Internet.
Un usuario puede descubrir si su equipo está infectado a través de diferentes herramientas. La más típica es utilizar un buen producto anti-malware. Para usuarios con mayores conocimientos técnicos, una herramienta de diagnóstico como ESET SysInspector, o simplemente observando los procesos que corren en el sistema y los programas instalados, pueden llegar a revelar la presencia de una infección. De todos modos, no siempre es tan fácil determinar la presencia de una botnet. ¿Quién está detrás de las botnets y para qué son utilizadas?
Las botnets son utilizadas por actores maliciosos para varios propósitos, que van desde robo de información a enviar spam. Como con cualquier cosa, cuantos más recursos tengas, más rápido será conseguir los resultados. Varios tipos de personas operan las botnets. Bandas criminales las utilizan para robar credenciales de acceso de home banking con el objetivo de cometer fraudes, mientras que existen “bromistas” que las usan para espiar por webcams para luego extorsionar a sus víctimas. ¿Cuál es el rol de un servidor de Comando y Control en una botnet? ¿Poder derribarlo ocasiona también la eclosión de toda la botnet?
Lo que llamamos un servidor de Comando y Control (algunas veces es llamado C&C o C2) es un servidor central que es usado para conectar a todos los equipos infectados. Con la mayoría de las botnets, si se cierra el panel de Comando y Control, significa derribar toda la red de equipo infectados.
De todas maneras, existen excepciones: la primera es que hay botnets que usan redes P2P (red entre iguales) para comunicarse, lo que significa que no hay un servidor de Comando y Control para dar de baja. La segunda excepción se da en el caso que estamos viendo cada vez más: botnets que usan diversos servidores de Comando y Control. Estos están localizados en diferentes países y jurisdicciones, haciendo muy dificultoso darlos de baja al mismo tiempo. ¿Cuáles son los riesgos más grandes para los usuarios hogareños y las empresas?
Los riesgos asociados a las botnets son exactamente los mismos que el software malicioso en general. Son variados: puede haber información sensible robada de un dispositivo electrónico, tales como propiedad intelectual, planos o contraseñas de acceso a recursos estratégicos. Las computadoras infectadas además pueden ser utilizadas para sobrecargar servidores y para enviar spam.
Es muy importante entender que una vez que un equipo está infectado, no pertenece más realmente a su dueño, es operada y usada por alguien que puede estar del otro lado del mundo, potencialmente conduciendo todo tipo de actividades ilegales. ¿Quién está más en peligro: las empresas o los usuarios hogareños?
La línea entre los dispositivos personales y corporativos es bastante borrosa. Todos llevamos nuestros dispositivos personales al trabajo y viceversa. Yo diría que las botnets son una amenaza para ambos tipos de usuarios. En general, las redes corporativas tienen una seguridad más estricta y realizan monitoreos; identificar y detener ataques de botnet debería ser más sencillo en este tipo de redes. Por el otro lado, existe información más sensible para ser robada en la red de una empresa. ¿Existe algún grupo o tipo de usuario que sea más vulnerable que el resto?
Realmente no. Hay varios tipos de malware, cada uno puede ser utilizado para apuntarle a un grupo diferente de usuarios. Históricamente, ¿cuáles son las botnets más conocidas, las más grandes y la peor?
Conficker es probablemente la botnet que ha recibido mayor atención y seguro es una de las más grandes de la historia, con millones de equipos infectados muy rápidamente. Esto originó que la comunidad de investigación organizara una fuerza especial para combatirla. Como resultado, la botnet nunca fue utilizada por sus operadores. Otras significativas incluyen a Storm que era utilizada principalmente para enviar spam; y TDSS (también llamada Alureon) que tenía un componente de rootkit que era bastante difícil de limpiar del sistema. ¿ESET ha descubierto alguna botnet grande este año?
Sí, nuestra investigación de Operación Windigo resultó ser uno de los proyectos de investigación de botnets de la historia de ESET. Nuestro equipo descubrió una red de servidores infectados que eran usados para redirigir usuarios a contenidos web maliciosos, robar credenciales y enviar spam. Descubrimos que en los últimos años, más de 25.000 servidores habían sido infectados. En el momento que escribimos nuestro reporte, más de 10.000 servidores seguían infectados (Nota del Editor: Pueden descargar el premiado paper de investigación sobre Windigo aquí). ¿Qué sistema operativo suele utilizar un bot? ¿Han visto botnets para Mac, Linux o Android?
Hemos visto software malicioso creado para todos los grandes sistemas operativos. Agrupar dispositivos infectados en redes, o botnets, es posible en todas las plataformas. Un ejemplo de esto es el malware Flashback, que infectó a cientos y miles de dispositivos Mac. ¿Cuál es el enfoque más efectivo a la hora de combatir botnets?
Desde una perspectiva tecnológica, hay varias maneras de combatir las botnets, empezando por utilizar un anti-malware. De esa manera, se pueden advertir infecciones en el tráfico de red, en la memoria de equipos infectados o en su disco duro. Por el otro lado, creo que el enfoque más efectivo para combatir las botnets es la educación, despertando conciencia sobre esta amenaza.
Necesitamos que todo el mundo se dé cuenta que si su equipo está infectado, puede ser utilizado para lastimar a otros. Por lo tanto, cada vez que se encuentra un equipo infectado, es necesario desconectarlo y limpiarlo lo más rápido posible. Finalmente, la colaboración entre usuarios, grupos de investigación, proveedores de Internet y agencias de seguridad, ayuda enormemente a combatir las botnets y a llevar a la justicia a aquellos que las operan.
Un ejército de muertos vivientes haciendo estragos en Internet. Esta es una pesadilla que se ha repetido una y otra vez desde que la población online del mundo ha explotado, pero una y otra vez, protectores de la web se han unido para detener estas hordas maliciosas –aunque no ha sido fácil. Hay algunas plagas de botnets conformadas por zombis que han sido particularmente problemáticas; daremos un vistazo a lo peor de lo peor.
Si eres un lector asiduo de este blog, te debes haber encontrado con el término “bot” muchas veces. Las botnets son uno de los tipos más populares de malware, ya que ofrecen una forma de controlar un gran número de máquinas al mismo tiempo, para que hagan lo que dicte el atacante. Si no estás familiarizado con el término, debería ser de ayuda entender a estas horrorosas bestias refiriéndonos a ellas con uno de sus alias menos comunes.
Un “zombi” es una máquina que ha sido infectada con un cierto tipo de malware controlado remotamente. La imagen mental que deberías estar figurándote con este nombre es una entidad que ha sido despojada de sus motivaciones usuales y se comporta de formas inusuales e indeseables. En este caso podría ser, por ejemplo, una computadora propagando spam, haciendo clic en anuncios silenciosamente, o robando información sensible y financiera.
Una red de zombis es casi como un escenario de infección post-apocalíptico en el cine. Algunas de esas cosas son virtualmente inmortales o imposibles de matar –siempre parece haber una última criatura al acecho en las sombras, lista para empezar una nueva ola de problemas.
Aquí tienes una lista de cinco redes zombi que me pusieron los pelos de punta -a mí, y a muchos otros investigadores ayudando a tratar de detenerlas.
1. Storm
Este es el malware más viejo de nuestra lista, y ha sido uno de los primeros en tener éxito usando tácticas que luego serían utilizadas por otras botnets de esta lista. Fue masivo, logrando alcanzar diez millones de computadoras con Windows en su cenit. También fue una de las primeras botnets increíblemente grandes usadas para el rédito económico de sus autores.
El gran tamaño de esta red les permitió fraccionarla para venderla a diferentes partes, con diversos fines maliciosos. Y porque esto resultó un esfuerzo muy lucrativo, los creadores del malware lo diseñaron para que pelee contra los investigadores anti-malware: era capaz de tornar sus fuerzas zombis contra quien intentara unirse a su canal de comando y control, desde donde los autores daban órdenes a los bots, dejando a los investigadores offline y fuera de batalla. 2. Conficker
El malware es difícil de predecir. A veces una amenaza que en la superficie no parece ser particularmente avanzada, puede terminar protagonizando un ataque abrumador. En su apogeo, Conficker infectó millones de máquinas Windows: algunos dicen que el número llegó a 15 millones.
En las películas, cuando una amenaza complica el modo de vida cotidiano, un grupo de especialistas se forma para derrotar al enemigo. Esto no fue diferente: la cantidad de infecciones fue tan grande que se creó el equipo Conficker Working Group para pelear contra él. Y si bien tuvieron un éxito disminuyendo el número de máquinas infectadas, según el sitio del grupo, hay todavía un millón de computadoras aún afectadas en el mundo –seis años después de que fuera descubierto.
3. Zeus
¿Qué tal si la invasion zombie no afectara solo humanos, sino también mascotas y animales de granja? Zeus fue igual de abarcativa: no solo fue una gran botnet en sistemas Windows, tenía también un componente que robaba códigos de banca en línea de una variedad de dispositivos infectados (Symbian, Windows Mobile, Android y Blackberry). En 2012, fuerzas estadounidenses y sus socios de la industria de la tecnología dieron de baja la botnet.
Pero los autores originales tomaron piezas de su creación original y la revivieron –tal como un hechicero vuelve a la vida a un zombi resucitado- y nació lo que conocimos como Gameover Zeus, la cual el FBI dio de baja hace unos meses.
Sin embargo, ese tampoco fue el final de esta bestia informática: sus creadores están rearmando nuevamente su red zombi. ¿Se acuerdan de Cryptolocker, que no nos daba respiro el año pasado? Esta amenaza fue propagada por variantes de Zeus.
4. Flashback
Para aquellos que piensan que “Mac no se infecta con virus”, Flashback fue en cierta forma un shock. Lo cierto es que las Macs pueden infectarse con malware –y lo hacen. De hecho, máquinas infectadas se han convertido en parte de esta botnet masiva. Mientras la red Conficker se hizo de un mayor número de máquinas afectadas, Flashback tuvo un gran porcentaje del número total de máquinas Apple, con cerca de 600 mil infectadas en su “mejor” momento.
Hoy la botnet está abandonada, pero contemplando que aún hay computadoras infectadas, ¿quién sabe qué deparará su futuro?
5. Windigo
En la superficie, este bot parece ser como muchos otros: roba credenciales de máquinas infectadas, o usa su poder de procesamiento para enviar spam. Y con solo algunas decenas de miles de máquinas infectadas en su pico, sería difícil equiparar esta amenaza con el resto de las botnets de esta lista.
Sin embargo, los autores de este malware parecen haber creado su propio ejército zombi lentamente, de modo que han logrado permanecer fuera del radar por un tiempo.
Y esas decenas de miles de máquinas son Linux, en su mayoría servidores, y muchos alojan sitios que visitan millones de personas. Windigo no se limita a afectar sistemas Linux: infecta computadoras Windows con malware que se propaga a través de un exploit kit. También “sirve” a los usuarios de Mac con avisos de sitios de citas, y redirige a los de iPhone a sitios pornográficos.
El nombre viene de la leyenda algonquina que habla de un Wendigo asociado al canibalismo –la representación “corporizada” de la gula, la varicia y el exceso. Esta bestia nunca estaba satisfecha matando y consumiendo a una persona; siempre estaba buscando nuevas víctimas.
Muchas de estas amenazas fueron destruidas en algún momento, pero el peligro, en verdad, sigue existiendo en forma de máquinas aun infectadas o proclives a estarlo, que se esconden en las sombras esperando una oportunidad para volver. Estas amenazas afectaron a casi todos los grandes sistemas operativos, lo que nos muestra que no hay dispositivo realmente inmune. Todos necesitan implementar buenas prácticas de seguridad en toda ocasión, con cualquier dispositivo, independientemente del tipo de software que utilice.
Si hacen eso, tienen mejores chances de protegerse no solo a ustedes mismos, sino también a otros, de estas creaciones resurrectas.
Tal como les anticipamos, hoy, en la segunda jornada de presentaciones de la décima edición de ekoparty, fue el turno del argentino César Cerrudo, conocido por haber encontrado la forma de hackear sistemas de control de tráfico de ciudades de Estados Unidos -también utilizados en Francia, Australia, Reino Unido y otros países. Les contaremos los detalles de su investigación, dónde residen las vulnerabilidades y para qué ataques podrían ser utilizadas.
Por empezar, es necesario conocer la infraestructura que se utiliza. En el mundo hay más de 200 mil magnetómetros enterrados en el asfalto, los cuales, cuando un auto pasa por encima, detectan la anomalía y el movimiento. Su batería dura 10 años, por lo que requieren poco mantenimiento; cuentan con una mini computadora y un chip procesador para la transmisión inalámbrica en 2.4 gigahercios. Estos sensores se conectan a la red interna del sistema de control de tráfico por GSM o ethernet.
Una interfaz que va en las cabinas junto a los semáforos traduce los datos para mandarlos al sistema, y hay repetidores que extienden el rango de la señal. ¿Cómo trabajan?
Los sensores, entonces, están en la calle con los repetidores y el access point (AP). Pensemos un posible uso: en una esquina, detectarán si hay autos esperando y qué tan larga es la fila; recolectarán información para mandarla al AP, que la reenvía a un semáforo o a distintos sistemas para control de tráfico. De esta forma, según la configuración que se use, se buscará hacer más inteligentes a los semáforos, por ejemplo, si se necesita que haya una onda verde para descongestionar el flujo de tráfico. En otras palabras, si hay un auto trabado, el sistema será capaz de tomar una decisión como dar luz verde para que pueda avanzar.
También pueden calcular la velocidad de circulación, ya que saben en tiempo real, en base a distintos cálculos, cuánto le llevó a un determinado auto recorrer determinada distancia.
En cuanto a software, corren con uno para Windows hecho en Flash/ActionScript para configurar access points, repetidores y sensores, y mandarles comandos. ¿Cuáles son las vulnerabilidades encontradas?
Por empezar, el sistema no tiene cifrado, lo que significa que todos los datos viajan en texto plano. Esto permite que cualquier atacante pueda interceptar las comunicaciones, y ver lo que se está transmitiendo.
Al respecto, el fabricante ha dicho: “Las transmisiones de radio no llevan comandos, sino datos, por lo que no hay riesgo”. La respuesta a la ausencia de cifrado fue que como a los clientes no les había gustado, decidieron desestimarlo, y que como el sistema estaba diseñado para funcionar sin cifrado, no había riesgo en términos de seguridad. Además, argumentaron, como el protocolo es propietario, está “libre de hackers” porque solo ellos lo conocen. ¡Error!
Pero, tal como expuso César Cerrudo, hay algunas falencias:
El sistema no tiene autenticación en las comunicaciones: el AP confía ciegamente en que los datos vienen de los sensores, por lo que si alguien manda información falsa, la va a tomar como verdadera. De igual forma, los sensores siempre creen que los comandos vienen del AP. El firmaware del sensor no tiene cifrado ni firma digital, por lo cual cualquiera puede actualizarlo, modificarlo e insertarle un virus o un backdoor, por ejemplo.
¿Qué problemas podría causar?
Si estos ataques se hicieran a gran escala, los efectos serían masivos ya que en el mundo hay más de 200 mil sensores que funcionan con estas características, que equivalen a cien millones de dólares en equipos. Básicamente, una consecuencia sería netamente económica en este sentido, por las pérdidas que pudiera ocasionar, y por otro lado, habría consecuencias a nivel físico si hablamos del funcionamiento cotidiano de los sistemas de tráfico.
Pensemos en los embotellamientos en zonas neurálgicas, desvíos, accesos y rampas que se podrían ocasionar -y también, en los accidentes. Además, exceso de tiempo con luz verde o, por el contrario, todo luz roja ocasionando demoras y bloqueando ambulancias, bomberos o policía; o que se muestre un límite de velocidad erróneo, entre otras posibilidades.
César nombró el caso de Los Angeles, donde hubo dos días de atascamiento porque se alteró el tráfico de una intersección neurálgica. Él usaba su computadora en la calle apuntando a los sensores usando el software del fabricante, y comprobó que cualquier AP sirve para acceder a cualquier sensor del mundo.
El siguiente video de IOActive muestra detalles de la utilización de estos sistemas en grandes ciudades:
¿Qué ataques se podrían hacer?
Naturalmente, un ataque de Denegación de Servicio (DoS) sería viable; es posible acceder a los sensores y mandar datos falsos, deshabilitar sensores o repetidores y demás. Por otro lado, las nuevas implementaciones de estos sistemas son fáciles de localizar, porque el fabricante hace publicaciones y anuncios de prensa sobre nuevos clientes, nuevas instalaciones y demás. De igual forma, los dispositivos son fácilmente localizables en todo el mundo mediante Google Street View, que permite obtener sus coordenadas.
También es posible lanzar el ataque usando GPS (cuando detecte unas coordenadas específicas), y desde la altura con drones, utilizando una antena. Para que los ataques sean efectivos, se debe estar a un máximo de 300 metros y utilizar una antena para amplificar el alcance.
La demostración en vivo de César constató que desde un AP con el software del fabricante, podía indicar la (falsa) existencia de sensores que en verdad no existen y eran inventados en el momento. Mandando datos falsos de detección desde una distancia de 20 metros, se veía cómo el software detectaba todo en tiempo real.
César también mencionó la posibilidad de hacer un gusano que se propague a través de la actualización de firmware, de forma que si se le inserta malware, se replicará: si se infecta un sensor, luego se infectan todos. Como agravante, se puede engañar al sistema de forma que nadie pueda saber si ese firmware fue alterado.
Por último, ataques más avanzados y difíciles, prácticamente imposibles hoy en día, serían a través de la localización de personas en tiempo real, comprometiendo sus smartphones. Si recolectando información en redes sociales sobre dónde está o qué está haciendo una persona, el atacante sabe qué controles de tráfico tiene cerca y por lo tanto puede comprometerlos y así, hacer “ataques dirigidos” pero a nivel físico.
¿Qué les parece todo esto? ¿Creían posible hackear sistemas de control de tráfico? No se pierdan los contenidos que seguiremos publicando como parte nuestra cobertura especial de ekoparty desde We Live Security en Español.
Continuamos cubriendo la ekoparty y esta vez fue el turno de Luis Colunga, investigador y representante de la firma Websec, con su presentación sobre explotación práctica de señales de radio, utilizando la tecnología SDR –del inglés, Software Defined Radio, con la que ha estado experimentando los últimos tres años.
Software Defined Radio consiste en el reemplazo de componentes físicos usualmente utilizados en comunicaciones inalámbricas por su equivalente en software. Esto ofrece la posibilidad de mantener desarrollos sin la necesidad de hardware específico, facilitando el rediseño, la reparación de bugs y la nueva puesta en producción de sistemas, reduciendo conjuntamente los costos de despliegue.
Esta tecnología, usualmente utilizada bajo un enfoque académico para la realización de investigaciones basadas sobre medios inalámbricos, puede encontrar nuevos usos al permitir la recepción de señales de radio, emitidas por automóviles, aviones, barcos e incluso satélites, de manera sencilla y económicamente rentable.
En este contexto, la creciente importancia de SDR como herramienta de seguridad se refleja en sus ventajas al momento de fortalecer los protocolos de telecomunicaciones inalámbricas y métodos de autenticación que en ellas se presentan, entendiendo los posibles ataques que pueden ser llevados a cabo e incluyéndolos en el repertorio de pruebas en procesos de pentesting.
Las plataformas disponibles al momento de realizar SDR varían en múltiples factores, como ser rangos de frecuencia, ancho de banda, interfaces disponibles, capacidad de recepción/transmisión, o precisión del oscilador, utilizando equipos de recepción y transmisión de señales, o mediante análisis de ondas con procesadores exclusivos que permiten el ahorro en costo de procesamiento.
Algunos equipos utilizados en la presentación incluyen RTL-SDR, un equipo que cuesta unos 20 dólares, inicialmente pensado para la recepción de señales de televisión digital cuya utilización devino en la posibilidad de trabajar con transmisiones Wi-Fi mediante el desarrollo de un driver especializado. Otro desarrollo es HackRF, que permite transmisiones dúplex, la sintonización de toda la banda FM con un ancho de banda de 20 Mhz y un costo aproximado de unos 300 dólares.
De esta manera, mediante la utilización de equipos de muy bajo costo, es posible la recepción de tráfico GSM, y su consiguiente análisis y codificación, con el objeto de explotar protocolos inalámbricos para obtener el tiempo de llegada de aviones, su velocidad, su identificador, y la consecuente ubicación geográfica en base al procesamiento de la señal. Aún más, es factible la irrupción en el tráfico aéreo para crear aviones fantasmas, lo que representa una seria amenaza para la gestión del tráfico aéreo, mediante como presentó Colunga durante el evento.
Asimismo, es posible perpetrar ataques mediante captura, procesamiento y retransmisión de señales inalámbricas producidas por automóviles, irrumpir señales de televisión digital, tomar control de dispositivos industriales, o aprovecharnos de la falta de cifrado y autenticación en las comunicaciones satelitales, receptando y almacenando múltiples señales al mismo tiempo.
La utilización de SDR fue vedada en el pasado debido a su alto costo y desarrollo inmaduro. Sin embargo, con el paso del tiempo y el paulatino aumento del conocimiento de los protocolos y tecnologías disponibles, se ha reducido su coste promedio desde unos 5000 dólares en 2010, a unos 20 dólares en la actualidad; y de esta forma es mucho más sencillo llevar su aplicación a prácticas de seguridad rutinarias.
Como bien recordó el orador en su charla, vale recordar que muchas de estas prácticas son ilegales y peligrosas ya que implican irrumpir en comunicaciones que, a pesar de no estar debidamente protegidas, está vetado por ley (en muchos países) el acceso y, fumdamentalmente, un error cometido en el análisis podría llegar a causar incluso un accidente.
Mostrar Temas
