Todas las amenazas

Virus

Hackers

Spam

Todo el sitio    Sólo virus
  
Enciclopedia de virus
Alertas
Análisis
Noticias
Glosario
Bitácora

 
Archivo

<< 2015  
ene feb mar
abr may jun
jul    
     
Sobre los autores de la bitácora del analista antivirus
About Diary's Authors

La bitácora del analista antivirus es un weblog mantenido por los analistas antivirus de Kaspersky Lab, encabezado por Eugene Kaspersky. Lea más sobre los autores de esta bitácora

 

  Home / Bitácora

Bitácora del analista antivirus

Se terminaron los juegos: Winnti ahora ataca a las compañías farmacéuticas


  Dmitry Tarakanov       29 junio 2015 | 14:38  MSK

Comentar  

Por mucho tiempo se había considerado al grupo Winnti como una fuente china de amenazas que apuntaban específicamente a desarrolladores de juegos. Hace poco tuvimos acceso a información de que podría tener más blancos y que ya no se limitaba a la industria del entretenimiento. Es más, nosotros hemos venido haciendo un seguimiento permanente de los ejemplares del programa malicioso Winnti, pero hasta el momento no hemos logrado capturar uno que contenga pistas sólidas de ataques contra otras industrias. Asimismo, nuestra visibilidad como fabricantes no cubre a todas las compañías del mundo (al menos hasta ahora ;)) y nuestra red Kaspersky Security Network (KSN) no ha detectado otros ataques, salvo los perpetrados contra compañías desarrolladoras de juegos. Bueno, a veces entre las organizaciones atacadas se encontraban las de telecomunicaciones, o mejor incluso, grandes conglomerados, que aparentemente tenían al menos uno de sus negocios relacionado de alguna forma con la producción o distribución de juegos online.

En abril, Novetta publicó su excelente informe sobre el programa malicioso Winnti, detectado en las operaciones del grupo Axion. El grupo Axiom se ha presentado como un avanzado autor chino de amenazas que lanzaba ataques de contraespionaje contra una amplia variedad de industrias. Para nosotros, el informe Novetta fue otra fuente de información de que Winnti ya se estaba expandiendo más allá de los juegos online. Una de las últimas muestras de Winnti que detectamos también parece confirmar esta sospecha.

La nueva muestra pertenece a una de las versiones de Winnti descrita en el informe de Novetta: Winnti 3.0. Esta es una de las DLLs que componen esta plataforma RAT (troyano de acceso remoto), la biblioteca Worker (que en esencia es la DLL RAT) con el nombre interno w64.dll y las funciones exportadas work_end y work_start. Puesto que, como es usual, este componente se guarda en el disco con las cadenas, y muchos otros datos en el encabezado PE se eliminan o se reajustan a cero, resulta imposible restaurar la fecha de compilación de esta DLL. Pero esta biblioteca incluye dos controladores compilados el 22 de agosto y el 4 de septiembre de 2014. La muestra contiene un bloque de configuración cifrado colocado como recubrimiento. Este bloque puede contener una etiqueta para la muestra; generalmente se trata de una ID de campaña o identificación/nombre de la víctima. Esta vez, los operadores colocaron esta etiqueta en la configuración y resultó ser el nombre de una compañía farmacéutica de renombre mundial con sede en Europa:

Figura 1. Bloque de configuración

Además de la etiqueta de la muestra, el bloque de configuración incluye los nombres de otros archivos involucrados en el funcionamiento de la plataforma RAT y el nombre del servicio (Adobe Service), después del cual se instala el programa malicioso. La presencia de los siguientes archivos podría ser una señal de que el sistema ha sido infectado:

C:\Windows\TEMP\tmpCCD.tmp
ServiceAdobe.dll
ksadobe.dat

Uno de los controladores mencionados (un conocido, malicioso rootkit de red Winnti) estaba firmado con un certificado robado de una división de un gigantesco conglomerado japonés. Aunque esta se encarga de la fabricación de microelectrónica, otras direcciones de negocios del conglomerado incluyen el desarrollo y producción de drogas y de equipos médicos.

Aunque la naturaleza de la participación de los operadores de Winnti (que antes se percibían como una amenaza sólo contra la industria de los juegos online) en las actividades de otros equipos de ciberespionaje sigue en tinieblas, la evidencia está ahí. A partir de ahora, cada vez que oigas mencionar a Winnti, no sólo pienses en los desarrolladores de juegos; empieza a incluir empresas farmacéuticas y de telecomunicaciones como blancos de sus ataques.

Estas son las muestras mencionadas:

8e61219b18d36748ce956099277cc29b – Backdoor.Win64.Winnti.gy
5979cf5018c03be2524b87b7dda64a1a – Backdoor.Win64.Winnti.gf
ac9b247691b1036a1cdb4aaf37bea97f – Rootkit.Win64.Winnti.ai


El misterio de Duqu 2.0: el regreso del sofisticado ciberespía


  Global Research & Analysis Team (GReAT), Kaspersky Lab       11 junio 2015 | 18:21  MSK

Comentar  

Una nueva vulnerabilidad “de día cero” le ayuda a inyectar en el kernel de la memoria y mantenerse escondido

Duqu 2.0: Frequently Asked Questions
Puedes encontrar aquí las reglas Yara
El informe técnico de Duqu 2.0 (PDF) se encuentra aquí
Comunicado de prensa
Los indicadores de infección se encuentran aquí

Hace algunos meses, durante una limpieza de seguridad, Kaspersky Lab detectó una intrusión cibernética que afectaba a muchos de nuestros sistemas internos.

Este hallazgo nos impulsó a lanzar una investigación de gran escala, con la que descubrimos una nueva plataforma de malware de uno de los grupos más hábiles, misteriosos y poderosos del mundo de las Amenazas Persistentes Avanzadas (APT): Duqu. El actor Duqu desapareció en 2012 y se creía que había dejado de operar... hasta ahora. Nuestro análisis técnico indica que la nueva ronda de ataques incluye una versión actualizada del infame malware Duqu de 2011, al que a veces se refieren como el hermanastro de Stuxnet. Hemos llamado a este malware y su plataforma asociada “Duqu 2.0".

Algunas de las nuevas infecciones de Duqu de 2014-2015 tienen conexiones con los acontecimientos de P5+1 y las negociaciones con Irán sobre tratados nucleares. Parece que el actor de amenazas responsable de Duqu ha lanzado ataques a los lugares en los que se realizaban estas importantes negociaciones. Además de los acontecimientos de P5+1, el grupo Duqu 2.0 ha lanzado un ataque similar relacionado con el 70 aniversario de la liberación de Auschwitz-Birkenau.

En el caso de Kaspersky Lab, el ataque aprovechó una vulnerabilidad de día cero en Windows Kernel y tal vez hasta dos vulnerabilidades más que ahora ya están parchadas, pero en su momento eran de día cero. El análisis del ataque reveló que la meta principal de los atacantes era espiar las tecnologías, investigaciones y procesos internos de Kaspersky Lab. No se detectaron interferencias con procesos o sistemas. Puedes encontrar más detalles en nuestro informe técnico.

Desde el punto de vista de un actor de amenazas, la decisión de atacar a una compañía de seguridad de fama mundial debe ser muy difícil. Por un lado, es casi seguro que el ataque se descubra - es casi imposible que el ataque pase desapercibido. Es por eso que el ataque a compañías de seguridad puede indicar un exceso de confianza en que no se los descubrirá o una falta de interés en que se los encuentre y exponga. Es posible que, al atacar a Kaspersky Lab, los cibercriminales de Duqu hayan hecho una alta apuesta con la esperanza de mantenerse ocultos; pero perdieron.

En Kaspersky Lab somos firmes creyentes de la transparencia, por eso estamos haciendo pública esta información. Kaspersky Lab está seguro de que sus clientes y partners están a salvo y de que los productos, tecnologías y servicios de la compañía no sufrieron el impacto de este ataque.

Duqu 2.0 - Indicadores de infección (IOCs)

MD5s

Cargadores de acción:

089a14f69a31ea5e9a5b375dc0c46e45
16ed790940a701c813e0943b5a27c6c1
26c48a03a5f3218b4a10f2d3d9420b97
a6dcae1c11c0d4dd146937368050f655
acbf2d1f8a419528814b2efa9284ea8b
c04724afdb6063b640499b52623f09b5
e8eaec1f021a564b82b824af1dbe6c4d
10e16e36fe459f6f2899a8cea1303f06
48fb0166c5e2248b665f480deac9f5e1
520cd9ee4395ee85ccbe073a00649602
7699d7e0c7d6b2822992ad485caacb3e
84c2e7ff26e6dd500ec007d6d5d2255e
856752482c29bd93a5c2b62ff50df2f0
85f5feeed15b75cacb63f9935331cf4e
8783ac3cc0168ebaef9c448fbe7e937f
966953034b7d7501906d8b4cd3f90f6b
a14a6fb62d7efc114b99138a80b6dc7d
a6b2ac3ee683be6fbbbab0fa12d88f73
cc68fcc0a4fab798763632f9515b3f92

Núcleos:

3f52ea949f2bd98f1e6ee4ea1320e80d
c7c647a14cb1b8bc141b089775130834

IPs de Comando y Control:

182.253.220.29
186.226.56.103

También puedes usar el archivo IOC disponible aquí para buscar a Duqu 2.0 en tu red.


Lecciones aprendidas de Flame, tres años después


  Mary-Beth Samekh        9 junio 2015 | 11:39  MSK

Comentar  

Hace tres años, un 28 de mayo de 2012, anunciábamos el descubrimiento de un programa malicioso conocido como Flame. Al mismo tiempo que publicábamos nuestras Preguntas y Respuestas sobre Flame, CrySyS Lab publicaba su detallado análisis de sKyWIper. Unos días antes, Maher CERT había publicado IOCs para Flamer. En resumen, Flame, sKyWlper y Flamer eran nombres distintos para una misma amenaza que tomó por sorpresa al mundo como la primera gran revelación después de Stuxnet y Duqu.

Desde el descubrimiento de Flame, hemos informado sobre muchos otros programas maliciosos avanzados, incluyendo Regin y Equation, pero Flame sigue siendo especial por ser una de las más complejas, sorprendentes e innovadoras campañas maliciosas que hayamos visto.

Volviendo al descubrimiento de Flame, estas son algunas de las lecciones que aprendimos.

  1. Un programa malicioso de alta gama y nivel gubernamental puede ser pesado. El conjunto completo de módulos instalados pesaba 20 MB, que era mucho. Antes de esto, los programas maliciosos más sofisticados pesaban entre unos kilobytes y algunos cientos de kilobytes, y la mayoría de los usuarios descartaba un archivo ejecutable de 6 MB por ser “poco interesante”. Ya no es así.
  2. Cómo evadir los air-gaps. Flame fue uno de los primeros programas maliciosos en implementar mecanismos para evadir los air-gaps de seguridad mediante el uso de unidades USB. Al conectar una unidad USB en un equipo infectado con Flame sin conexión a Internet, el programa malicioso guardaba la información robada en un archivo oculto en la unidad USB. Este archivo era invisible ante la mayoría de los exploradores de archivos y contenía hasta 16 MB de documentos robados, y otra información, del equipo de la víctima. Cuando esta unidad USB se introducía a otro equipo infectado con Flame y conectado a Internet, entonces la información robada se extraía de esta unidad y se enviaba a sus servidores C&C.
  3. Docenas de C&Cs. Llegamos a contar hasta 100 servidores diferentes de comando y control de Flame. Para un programa malicioso con objetivos definidos, esto resultaba inusual, además de ser una cantidad elevada. Los autores de Flame crearon diferentes versiones del programa malicioso que se conecta a muchos C&Cs a fin de limitar el impacto de la clausura de uno de ellos.
  4. Captura de audio Bluetooth. Uno de los módulos de Flame se encargaba de identificar dispositivos Bluetooth próximos al equipo infectado y los usaba para grabar el audio en el ambiente. Este es un ataque muy raro introducido por Flame.
  5. La era de la vigilancia masiva. Creemos que el principal objetivo de Flame era facilitar la vigilancia masiva. Este programa malicioso estaba diseñado para extraer todo en los equipos infectados, desde documentos hasta capturas de pantalla, actividad en el teclado y audio. Los servidores C&C de Flame no incluían provisiones para la operación manual del programa malicioso; todo ocurría de forma automática.
  6. MD5 está muerto. Una de las características más interesantes de Flame era la forma en que infectaba otros equipos en la red local. El ataque incluía la casi mágica reingeniería de un certificado que servía para firmar actualizaciones de Windows. Este certificado se basaba en una firma MD5 que los atacantes lograron falsificar, lo que indica que tenían la habilidad de descifrar hashes MD5 arbitrarios.
  7. Caída de la confianza en las actualizaciones de Windows. Uno de los módulos más interesantes de Flame realizaba lo que llegó a describirse como un exploit “en modo Dios” que alteró las actualizaciones de Windows al secuestrar las peticiones de actualización de Windows. Por años se recomendó a los usuarios que actualizaran frecuentemente Windows, y otros programas de terceras partes. Flame se aprovechó de la confianza de los usuarios en estas actualizaciones, y la alteró.
  8. La punta del iceberg. Después de descubrir Flame, nuestra detección genérica comenzó a activarse con otras muestras. Por la similitud de los códigos, detectamos otros dos programas maliciosos del mismo grupo: Gauss y MiniFlame. Esto nos llevó a darnos cuenta de que existen muchos otros programas maliciosos por descubrir, y que posiblemente nos lleve años hacerlo.
  9. Todo está conectado. Cuando descubrimos Flame, muchos usuarios preguntaron: "¿Está relacionado con Stuxnet?”. Respondimos: “No, no hay indicios”. Estábamos equivocados. Tras varias semanas descubrimos un módulo de Flame que también se usó en la versión 2009 de Stuxnet para replicarse. En esencia, el Stuxnet 2009 se compiló para replicarse usando un exploit de Flame. Esto muestra que, en realidad, ambos estaban conectados. Al mismo tiempo, Stuxnet estaba conectado con Duqu y, como descubrimos hace poco, con el grupo Equation, a través de sus exploits inicialmente usados por el gusano Fanny. A veces toma tiempo ver todas las conexiones, incluso si no parecen obvias al principio.
  10. “Flame es soso”. Cuando Kaspersky y CrySyS Lab publicaron nuestros análisis de Flame, algunos usuarios los descartaron por poco interesantes. “Un programa malicioso de 20 MB puede ser l33t? ¡Imposible!”. (Las críticas se acallaron cuando el ataque a Microsoft Windows Updates y el colapso de MD5 se detectaron y repararon). Mikko Hypponen de F-Secure tiene un estupendo blog sobre este tema: https://www.f-secure.com/weblog/archives/00002383.html.

Finalmente, queremos terminar con un discurso fantástico por el activista del derecho a la privacidad, Chris Soghoian, titulado “Lecciones del ataque contra Bin Laden y la Ciberguerra: Inmunizaciones y actualizaciones de seguridad”.

https://archive.org/details/ChrisSoghoian-LessonsFromTheBinLadenRaidAndCyberwarImmunizations

Se refiere a Flame en el punto 5:00, pero recomendamos mirar todo el video. Como Chris menciona en este video: "a pesar de la aparente ventaja a corto plazo que representa hackear las actualizaciones de seguridad, esto es algo que no vale la pena”. Estamos de acuerdo, y añadimos que actuar en contra de la seguridad global siempre será contraproducente para quien lo hace.

Estadísticas de los ataques DDoS mediante botnets en el primer trimestre de 2015


  Kaspersky Lab       29 mayo 2015 | 12:00  MSK

Comentar  

Metodología
Resultados del trimestre
Territorios de los ataques
Dinámica del número de ataques DDoS
Tipos y duración de los ataques DDoS
Servidores de administración y tipos de botnets
Conclusión
Glosario

Metodología

Los ataques DDoS (Distributed Denial-of-Service) son uno de los métodos más usados por los delincuentes informáticos. Su objetivo es llevar a un sistema informático (por ejemplo un sitio web) a tal estado, que los usuarios legítimos no puedan obtener acceso al mismo. Uno de los escenarios populares de DDoS es el ataque mediante botnets.

Kaspersky Lab cuenta con una experiencia reconocida de varios años en el campo de la lucha contra las amenazas informáticas, entre ellas los ataques DDoS de diferentes tipos y niveles de complejidad. En particular, los expertos de la compañía hacen un seguimiento de las actividades de las botnets mediante el sistema DDoS Intelligence (una parte de la solución Kaspersky DDoS Protection), que les permite mejorar constantemente las tecnologías de protección contra los ataques DDoS Intelligence. El sistema DDoS Intelligence está basado en el análisis de las instrucciones que los servidores de administración envían a la red de bots y no exige que el bot esté presente en el equipo del usuario ni que se ejecuten las instrucciones enviadas por el servidor.

Existen diferentes aproximaciones al análisis de las actividades de los ataques DDoS, uno de los cuales es el análisis de los ataques lanzados contra recursos en concreto (como regla, los clientes de las compañías que responden por su protección contra los ataques DDoS). El análisis de las actividades de las botnets aplicado en este informe permite no limitarse a clientes en particular, sino más bien ver el problema desde otra faceta.

En este informe presentaremos la estadística de DDoS Intelligence recolectada en el periodo que va desde el 1 de enero al 31 de marzo (primer trimestre) de 2015, que compararemos con los datos obtenidos el trimestre anterior (del 1 de octubre al 31 de diciembre de 2014).

Consideraremos como ataque DDoS aislado si la pausa entre sus periodos de actividad no supera las 24 horas. Por ejemplo, si un solo recurso sufrió ataques de la misma botnet y la pausa entre ellos fue de 24 hora, los consideraremos dos ataques. También se consideran ataques diferentes los lanzados contra un solo recurso, pero ejecutados por bots de diferentes botnets.

La ubicación geográfica de las víctimas de los ataques DDoS y los servidores desde donde se enviaban las instrucciones se determinan por sus direcciones IP. El número de blancos únicos de ataques DDoS en este informe se calculará por el número de direcciones IP únicas en la estadística trimestral.

Es importante mencionar que la estadística de DDoS Intelligence se limita a las botnets detectadas y analizadas por Kaspersky Lab. También hay que comprender que las botnets son sólo uno de los instrumentos con los que se realizan los ataques DDoS y los datos presentados en este informe no abarcan todos los ataques ocurridos en el periodo indicado.

Resultados del trimestre

  • En el primer trimestre de 2015 se detectaron 23 095 ataques DDoS mediante botnets, un 11% menos que en el trimestre anterior (25 929 ataques).
  • El número de víctimas únicas de ataques DDoS en el periodo fue de 12 281, un 8% menos que el trimestre anterior (13 312 blancos)
  • China, EE.UU. y Canadá encabezaron la estadística de países que sufrieron la mayor cantidad de ataques DDoS
  • El ataque DDoS más prolongado detectado en el primer trimestre de 2015 duró 140 horas (cerca de seis días) y el recurso más atacado soportó 21 ataques en tres meses
  • SYN-DDoS y HTTP-DDoS fueron los escenarios de ataques DDoS mediante botnets más propagados en el primer trimestre

Territorios de los ataques

En el periodo que nos ocupa se detectaron 23 095 ataques DDoS contra recursos ubicados en 76 países. En comparación con el trimestre anterior, la cantidad de ataques (25 929) se redujo en un 11% pero la cantidad de países donde se encontraban los blancos de los ataques (eran 66), aumentó.

La mayor cantidad de ataques DDoS, al igual que en el cuarto trimestre de 2014, se lanzó contra recursos ubicados en China, EE.UU. y Canadá. En el TOP 10 de los países más atacados hay pequeños cambios, pero sus integrantes siguen siendo los mismos.

Fig. 1. TOP 10 de países por cantidad de ataques en el cuarto trimestre de 2014 y el primero de 2015

En el grafico se puede observar que mientras el número de ataques lanzados contra recursos ubicados en China y EE.UU. tuvo una baja notable, la cantidad de ataques contra servidores canadienses subió. También creció la cantidad de ataques contra recursos ubicados en Rusia, Corea del Sur y Francia.

Según la cantidad de víctimas de ataques DDoS en cada uno de los países, el TOP 10 luce igual al anterior. En total, en el primer trimestre de 2015 las botnets atacaron 12 281 víctimas, un 8% menos que el trimestre anterior (13 312 blancos).

Fig. 2. TOP 10 de países por cantidad de víctimas de ataques DDoS en el cuarto trimestre de 2014 y el primero de 2015

En Rusia, Corea del Sur y Francia aumentó la cantidad de recursos atacados en comparación con el trimestre anterior, al igual que el número de ataques lanzados en estos países. Pero en Canadá, a pesar del aumento del número de ataques, la cantidad de víctimas ha disminuido, lo que es un indicio de que los ataques contra los mismos recursos han sido más activos en este país.

Las primeras posiciones ocupadas por China y EE.UU. en ambas estadísticas (tanto por el número de ataques como de víctimas) están relacionadas con el hecho de que el hosting en estos países es relativamente barato y muchas compañías escogen proveedores de hosting en estos países.

El máximo número de ataques lanzados contra un mismo recurso alcanzó los 21 en el primer trimestre:

Número de ataquesRecurso
21Sitio en ruso (grupo de inversiones)
16Sitio en Vietnam (servicios de organización de bodas)
15Proveedor de hosting en EE.UU.

Fig. 3. TOP 3 por número de ataques contra el mismo recurso, primer trimestre de 2015

A pesar de que en el periodo de análisis de este informe la mayor cantidad de ataques recayeron sobre China, EE.UU. y Canadá, los primeros dos puestos de la estadística del número de ataques los ocuparon un recurso ruso y otro vietnamita, y sólo en el tercer puesto tenemos a un proveedor de hosting de EE.UU.

Dinámica del número de ataques DDoS

En el primer trimestre la cantidad de ataques DDoS tuvo fuertes fluctuaciones en el tiempo*: la mayor actividad de las botnets se registró a finales de enero y la menor, a mediados de febrero.

Fig. 4. Dinámica del número de ataques DDoS, primer trimestre de 2015

* Debido a que los ataques DDoS pueden prolongarse de forma ininterrumpida por varios días, en la línea de tiempo un ataque puede contarse varias veces, una por cada día. Como resultado, el total de ataques por fechas resultó un poco mayor (30 064) que si contáramos cada ataque prolongado aparte (23 095).

Como vemos en el gráfico de abajo, en diciembre del año pasado se observó un notable aumento de la cantidad de ataques DDoS lanzados mediante botnets, seguido en enero y febrero por un descenso estable, pero en marzo empezó de nuevo a subir. El pico de diciembre se puede relacionar con las fiestas de fin de año y las vacaciones, cuando los delincuentes trataron de afectar el funcionamiento de los sitios y servicios que gozan de demanda entre los usuarios.

Fig. 5. Número de ataques por mes, cuarto trimestre de 2014, primer trimestre de 2015

Entre los días de la semana, el día en que se hicieron más ataques mediante botnets fue el jueves, y no el lunes como en el pasado trimestre. El domingo sigue siendo el día menos popular entre los delincuentes.

Fig. 6. Los días de la semana más populares para lanzar ataques DDoS, cuarto trimestre de 2014 y primero de 2015

Tipos y duración de los ataques DDoS

Entre las características más importantes de los ataques DDoS están dos: su duración y su escenario, porque son los que determinan el daño que infligen a la víctima. La aplastante mayoría de los ataques del periodo que nos ocupa tuvo una duración de menos de 24 horas. A pesar de que en el pasado trimestre encontramos ataques de hasta dos semanas de duración, en el primer trimestre no los hubo tan largos.

Duración, horasNúmero de blancos, cuarto trimestre de 2014Número de blancos, primer trimestre de 2015
Más de 15050
100-14983
50-99299121
20-49735433
10-191679703
5-921611426
Menos de 484259594

Fig. 7. Duración de los ataques DDoS en el cuarto trimestre de 2014 y el primer trimestre de 2015

El tipo de ataques DDoS se determina por el formato de solicitudes “basura” que se envían al recurso de la víctima. En el primer trimestre de 2015, al igual que en el cuarto de 2014, el método de ataques DDoS más popular fue SYN-DDoS. Los ataques tipo TCP-DDoS le cedieron el segundo puesto a los de HTTP.

Fig. 8. Tipos de ataques DDoS más populares , cuarto trimestre de 2014 y primero de 2015

Servidores de administración y tipos de botnets

Los centros de administración que los delincuentes usan para administrar las botnets pueden estar ubicados en diferentes países. Como regla, no guardan ninguna relación ni con la ubicación de los delincuentes ni con los territorios de propagación de los bots controlados por este servidor de administración. Según la cantidad de servidores de administración activos en el primer trimestre, lideran la lista EE.UU., China e Inglaterra.

Fig. 9. Distribución de los servidores de administración de las botnets por países, primer trimestre de 2015

El primer trimestre de 2015, al igual que el trimestre anterior, los más activos por la cantidad de ataques lanzados fueron los bots destinados a infectar servidores con sistema operativo Linux, que superaron a los bots creados para los equipos con sistema operativo Windows. Al mismo tiempo la cantidad de ataques mediante botnets para Windows quedó prácticamente sin cambios, mientras que la cantidad de ataques lanzados desde botnets Linux bajó.

Fig. 10. Número de ataques desde botnets para Windows y Linux, cuarto trimestre de 2014 y primer trimestre de 2015

A pesar de que las botnets para el sistema operativo Linux son considerablemente menos, la cantidad de ataques lanzados desde ellas y la potencia de los mismos, superan a los de los ataques de botnets para la plataforma Windows. Esto está condicionado porque al infectarse un servidor Linux, los delincuentes reciben amplias posibilidades de manipulación con los protocolos de red y la velocidad del canal de Internet de los servidores infectados por lo general supera la velocidad de las conexiones a Internet de los equipos de los usuarios, lo que da la posibilidad de lanzar ataques más potentes.

Además, el promedio de vida de las botnets basadas en el sistema operativo Linux es considerablemente mayor que el de las basadas en Windows. Esto está relacionado con que es difícil detectar y neutralizar estas botnets, ya que es raro que los servidores con Linux cuenten con medios de protección especiales, a diferencia de los dispositivos y servidores con el sistema operativo Windows.

También merece la pena destacar que el 93,2% de los blancos en el primer trimestre fueron atacados sólo por una familia de bots. En el 6,2% de los casos en el ataque participaron dos familias al mismo tiempo y sólo en el 0,6%, tres o más: los delincuentes o bien utilizaban al mismo tiempo varias diferentes familias de bots para los ataques, o los clientes del ataque habían hecho pedidos a varios ejecutantes al mismo tiempo.

Conclusión

La cantidad de ataques DDoS mediante botnets, al igual que la cantidad de víctimas de estos ataques, en el primer trimestre bajó en comparación con el periodo anterior. Al mismo tiempo, la cantidad de países abarcados por esta amenaza, por el contrario, aumentó. Ya es tradición que la mayor parte de los ataques se lance contra recursos de EE.UU. y China, ya que en estos países el hosting es barato y en ellos están ubicados muchos recursos. Pero en el TOP 10 también hay víctimas de Europa y los países del Pacífico. Esta estadística es un indicio de que los ataques DDoS mediante botnets tienen vigencia para los recursos más diversos, independientemente de su pertenencia geográfica. Además, esta amenaza sigue expandiendo sus fronteras.

Los delincuentes informáticos que usan botnets para organizar ataques DDoS siguen siendo bastante insistentes: el ataque DDoS más prolongado detectado en el primer trimestre de 2015 duró 140 horas (cerca de seis días) y el recurso más atacado soportó 21 ataques en tres meses. Sin embargo, como muestran las investigaciones, incluso un breve ataque puede afectar el funcionamiento de un recurso desprotegido. Uno de estos ataques le puede costar a la víctima 444.000 dólares, sin considerar los riesgos de reputación provocados por el descontento de los usuarios que no recibieron el servicio que esperaban.

Las compañías de seguridad en Internet hacen su aporte a la lucha contra los ataques DDoS y las botnets en particular, encontrando y agregando a las bases de firmas nuevos programas maliciosos, protegiendo los servidores contra hackeo y los ordenadores contra la infección, poniendo límites a las actividades de los servidores de administración, etc. A pesar de todo, los ataques DDoS siguen siendo uno de los instrumentos populares de los delincuentes informáticos y las compañías deben tomar medidas oportunas para defenderse. El servicio de filtración del tráfico “basura” permite al recurso online seguir estando disponible para los usuarios legítimos incluso durante un ataque largo y potente.

Enlaces útiles:

El ecosistema de las botnets

La economía de las botnets

IT Security Risks survey 2014: DDoS

Kaspersky DDoS Protection webpage

Kaspersky DDoS Protection whitepaper

Glosario

Bot – programa malicioso que ejecuta diversas acciones al recibir instrucciones de un delincuente.

Familia de bots – conjunto de bots que tienen un código fuente similar, es decir, son diferentes versiones de un mismo bot. Sus servidores de administración pueden ser diferentes.

Botnet – conjunto de dispositivos infectados por el mismo bot y que tienen el mismo servidor de administración. Los delincuentes informáticos difunden con anticipación en Internet programas maliciosos especiales que convierten a los servidores, ordenadores o dispositivos móviles en “zombies” a control remoto (i.e. bots).

Servidor C&C (de administración) – es un servidor mediante el cual los delincuentes envían instrucciones a sus bots y donde reciben sus respuestas. En el caso de los ataques DDoS, los bots, al recibir una orden de los delincuentes, envían solicitudes al recurso de la víctima de forma directa o mediante terceros servidores, es decir, realizan un “ataque distribuído”.

SYN-DDoS – es el conjunto de escenarios de ataques DDoS que explotan las peculiaridades de la realización del protocolo TCP (Transmission Control Protocol, protocolo de control de transmisión). El establecimiento de una conexión TCP transcurre en tres etapas, que recuerdan el proceso de dar un apretón de manos: El cliente envía un paquete con la bandera SYN. El servidor, al recibir el paquete SYN, responde con un paquete con encabezados SYN y ACK. Después, el cliente envía un paquete ACK, con lo que confirma la conexión. Durante el proceso de SYN-flood el atacante envía un paquete con la bandera SYN, pero no exige un paquete de respuesta con las banderas SYN+ACK para establecer la conexión, lo que obliga al servidor de la víctima a gastar recursos en el procesamiento de estas solicitudes y el envío de paquetes de respuesta.

TCP-DDoS – es el conjunto de escenarios de ataques que de la misma manera que SYN-flood, explotan las peculiaridades de la realización del protocolo TCP, pero al mismo tiempo establecen conexión con el servidor de la víctima. En los ataques de tipo TCP-flood, después de la realización del procedimiento del “apretón de manos”, la parte atacante envía datos “basura” de gran tamaño y de una forma muy lenta por la conexión establecida. Esto recarga el servidor y no le permite dar recursos a las conexiones legítimas.

ICMP-DDoS – conjunto de escenarios de ataques por el protocolo ICMP (Internet Control Message Protocol), que se usa para transmitir mensajes de error y otras situaciones de excepción que surjan durante la transmisión de datos. En caso de ataque, el delincuente envía una gran cantidad de solicitudes ICMP al servidor de la víctima, para provocar que gaste recursos en el procesamiento de solicitudes “basura”, en vez de procesar las legítimas.

UDP-DDoS – conjunto de escenarios de ataque que usan el protocolo UDP, que no exige el establecimiento de conexiones (User Datagram Protocol, protocolo de datagramas del usuario). El atacante envía al servidor de la víctima numerosos paquetes UDP, cada uno de los cuales requiere procesamiento por parte del servidor y su hardware de comunicación, lo que causa recargas en los recursos de procesamiento de la víctima.

HTTP-DDoS - todos los escenarios de ataques DDoS cuyo objeto son las aplicaciones web. Durante el proceso de realización de los ataques el delincuente puede realizar tanto solicitudes GET/POST simples a la página principal de la aplicación web, como solicitudes atípicas (buscar cierta información en la base de datos de la aplicación web, ejecutar determinados scripts en el servidor web, etc.). Además, en el cuerpo de la solicitud se pueden poner encabezados o ficheros cookie para evadir los filtros que determinan a un usuario legítimo por la presencia de cookies. También, el atacante puede abrir el navegador en el equipo infectado para simular la actividad de un visitante común del sitio web y no dejar que los sistemas de protección instalados detecten los bots en el flujo general de visitantes.


Grabit y RATs


  Ido Naor       28 mayo 2015 | 11:00  MSK

Comentar  

Hace poco, clientes de Kaspersky en Estados Unidos recurrieron a los expertos de Kaspersky, solicitándoles investigar un nuevo tipo de programa malicioso que lograron recuperar de los servidores de sus organizaciones. Este programa malicioso se llama Grabit y se distingue por su comportamiento versátil. Cada una de las muestras que analizamos tenía tamaño y actividades diferentes respecto a las otras, pero el nombre interno y otros identificadores eran perturbadoramente similares. La marca de tiempo parece ser válida y próxima a la cronología de infección documentada. Nuestra documentación apunta a una campaña que comenzó a fines de febrero de 2015 y concluyó a mediados de marzo. Cuando se supone que terminó la fase de desarrollo , el programa malicioso comenzó a propagarse desde India, Estados Unidos e Israel por el mundo entero.

Las decenas de muestras que logramos obtener estaban programadas en un equipo con plataforma Windows y procesador de 32bit, en .NET Framework de Microsoft (Visual Basic/C#). Los archivos se compilaron durante tres días, entre el 7 y el 9 de marzo de 2015. El siguiente gráfico ilustra cómo el grupo, o el individuo, crearon las muestras, el tamaño de cada una, la hora del día en que se compilaron, y los intervalos de tiempo entre cada compilación.

Cronología de compilación del programa malicioso

La muestra más pequeña (0,52Mb) y la más grande (1,57Mb) se crearon el mismo día, lo que podría indicar que el grupo realizaba experimentos para probar sus funciones, empacadores e implementaciones de “códigos muertos”.

El cuadro revela el modus operandis a medida que el actor se esfuerza siempre para alcanzar una variedad de muestras, código de diferentes tamaños y, supuestamente, una ofuscación más complicada.

Junto a esta variedad de tamaños, actividades y ofuscación, se implementó en cada muestra un sólido algoritmo de cifrado. La cadena ofuscada, clases y métodos exclusivos dificultaron su análisis. También se encuentra activada la ASLR, lo que puede ser un indicio de un RAT de código abierto o incluso un framework comercial que empaquetó el programa malicioso en una estructura bien escrita. Este tipo de trabajo se conoce como un factor de mitigación para que los actores mantengan su código oculto a los ojos de los analistas.

Durante nuestra investigación, el análisis dinámico mostró que la función “call home” del programa malicioso se comunica mediante canales obvios y no se esfuerza por ocultar su actividad. Además, los archivos no estaban programados para realizar ningún tipo de maniobras en el registro para ocultarse de Windows Explorer. En sentido figurado, parece que los actores están enviando a la guerra a un “caballero débil en armadura pesada”. Es decir, quienquiera que haya desarrollado el programa malicioso, no escribió todo el código desde cero. Un caballero bien entrenado nunca iría a la guerra con un escudo y una espada de madera.

Al mirar el tráfico “call home”, la función keylogger prepara archivos que actúan como contenedores para intercepciones del teclado, recopilando nombres de hosts, de aplicaciones, de usuario y contraseñas. Sin embargo, lo interesante se encuentra aquí.

Los nombres de archivo contienen una cadena muy informativa:

HawkEye_Keylogger_Execution_Confirmed_<VICTIM> 3.10.2015 6:08:31 PM

HawkEye es una herramienta comercial que viene desarrollándose desde hace varios años. Apareció en 2014 como un sitio llamado HawkEyeProducts, e hizo una contribución famosa a la comunidad hacker.

En el sitio, el producto muestra una gran versatilidad, ya que contiene muchos tipos de RATs, funciones y características, como el registrador HawkEye tradicional u otros tipos de herramientas de administración remota, como Cyborg Logger, CyberGate, DarkComet, NanoCore y otras. Parece admitir tres tipos de entregas: FTP, SMTP y Web-Panel.

Como se ve, este programa malicioso utiliza varios RATs para controlar a sus víctimas o hacer seguimiento de sus actividades. Una de las implementaciones exitosas de este actor contenía el reconocido DarkComet. Esta conveniente función “elige tu RAT” desempeña un papel muy importante en la infección del programa malicioso, la rutina y la sobrevivencia en el equipo de la víctima. Las muestras de DarkComet son más complicadas que el registrador HawkEye tradicional. Una instancia tenía un generador de llaves aleatorias que fija un vector de inicialización para los 4 primeros bytes del archivo ejecutable y agrega una llave aleatoria de 5 bytes que desempaqueta otro archivo PE, de menos de 20Kb de tamaño. El archivo PE contiene otro empaquetador con una técnica de ofuscación mucho más compleja. La última muestra que probamos tenía un comportamiento muy complicado. El código tenía la misma técnica de ofuscación, aunque el tráfico no se transfería en texto simple. Los datos robados se empaquetaban y enviaban cifrados mediante puertos HTTP aleatorios. Esto significa que el grupo está tratando de producir otros tipos de muestras maliciosas con RATs diferentes.

Se han recopilado aproximadamente 10.000 archivos robados. Las compañías con sede en Tailandia e India tenían el mayor porcentaje de equipos infectados. Al observar las credenciales robadas, queda claro que los empleados se enviaban el programa malicioso entre sí, pues los nombres de hosts robados y las aplicaciones internas son los mismos.

A continuación se muestra el cuadro completo, actualizado a mayo de 2015:

Clasificación por país del programa malicioso

Demostrando la efectividad de sus sencillos keyloggers, un C2 (el 15 de mayo) contenía miles de credenciales de cuentas víctimas de Cientos de sistemas infectados.

En resumen, los actores de Grabit no usaron evasiones ni maniobras sofisticadas en sus actividades dinámicas. Resulta interesante ver las diferencias principales entre el desarrollo básico del programa malicioso y las funciones reales que usa.

Algunas muestras del programa malicioso usaban el mismo servidor hosting e incluso las mismas credenciales. ¿Será que nuestro actor estaba apurado?
Nuestra apuesta es que estamos ante un grupo y no ante un solo individuo. Algunos miembros del grupo son más técnicos, y otros están más orientados hacia la seguridad y más conscientes de los riesgos a que pueden exponerse.

Volviendo al principio

Por lo que hemos visto hasta ahora, este programa malicioso se propaga como un archivo de Microsoft Office Word (.doc) adjunto de correo, que contiene un macro malicioso llamado AutoOpen. Este macro abre un socket en TCP y envía una petición HTTP a un servidor remoto, pirateado por el grupo para usarlo como un hub malicioso, antes de descargar el programa malicioso. En algunos casos, el macro malicioso estaba protegido por contraseña, pero nuestro actor puede haber olvidado que un documento .doc es en realidad un archivo comprimido y que cuando se abre con un editor apropiado, las cadenas del macro se muestran en texto simple.

El programa malicioso actúa de una forma evidente, modificando entradas de registro comunes, como las configuraciones de arranque, sin cubrir su rastro. En la mayoría de los casos, sus binarios no se eliminan, y su comunicación es en texto simple, donde la víctima puede espiar la comunicación y capturar las credenciales del servidor FTP/SMTP.

Los derivados del programa malicioso se encuentran principalmente en:

C:\Users\<user>\AppData\Roaming\Microsoft

Extensiones phishing: .doc

3f77403a64a2dde60c4962a6752de601d56a621a

4E7765F3BF73AEC6E350F412B623C23D37964DFC

Iconos: .pdf, .doc, .ttf, .xls, .ppt, .msg, .exe

Stealer: .txt, .jpeg, .eml

Nombres de ejecutables adicionales:

AudioEndpointBuilder.exe
BrokerInfrastructure.exe
WindowsUpdate.exe

Extensiones del programa malicioso: .zip o .exe

9b48a2e82d8a82c1717f135fa750ba774403e972b6edb2a522f9870bed57e72a

ea57da38870f0460f526b8504b5f4f1af3ee490ba8acfde4ad781a4e206a3d27

0b96811e4f4cfaa57fe47ebc369fdac7dfb4a900a2af8a07a7b3f513eb3e0dfa

1948f57cad96d37df95da2ee0057dd91dd4a9a67153efc278aa0736113f969e5

1d15003732430c004997f0df7cac7749ae10f992bea217a8da84e1c957143b1c

2049352f94a75978761a5367b01d486283aab1b7b94df7b08cf856f92352166b

26c6167dfcb7cda40621a952eac03b87a2f0dff1769ab9d09dafd09edc1a4c29

2e4507ff9e490f9137b73229cb0cd7b04b4dd88637890059eb1b90a757e99bcf

3928ea510a114ad0411a3528cd894f6b65f59e3d52532d3e0c35157b1de27651

710960677066beba4db33a62e59d069676ffce4a01e63dc968ad7446158f55d6

7371983a64ef9389bf3bfa8d2abacd3a909d13c3ee8b53cccf437026d5925df5

76ba61e510a340f8751e46449a7d857a2d242bd4724d0d040b060137ab5fb31a

78970883afe52e4ee846f4a7cf75b569f6e5a8e7a830d69358a8b33d186d6fec

7c8c3247ffeb269dbf840c7648e9bfaa8cf3d375a03066b57773c48de2b6d477

7f0c4d3644fdcd8ac5bc2e007bb5c3e9eab56a3d2d470bb796af88125cd74ac9

Direcciones IP:

31.220.16.147
204.152.219.78
128.90.15.98
31.170.163.242
185.77.128.65
193.0.200.136
208.91.199.223
31.170.164.81
185.28.21.35
185.28.21.32
112.209.76.184

¿Nos ponen los sistemas de vigilancia públicos en riesgo de ciberataques?


  Vasilios Hioureas       27 mayo 2015 | 11:00  MSK

Comentar  

Cuando las tecnologías de vigilancia inseguras se vuelcan en tu contra

La investigación se presentó por primera vez en DefCon 2014. Su publicación es un aporte de Kaspersky Lab a Securing Smart Cities – una iniciativa global sin fines de lucro para resolver los problemas de seguridad informática actuales y futuros de las ciudades inteligentes mediante la colaboración entre compañías, gobiernos, medios de comunicación, organizaciones sin fines de lucro e individuos de todo el mundo.

Thomas Kinsey, de Exigent Systems Inc., contribuyó a este informe.

Una noche, estaba con un colega cuando se nos ocurrió la brillante idea de treparnos a una fuente pública en medio de una ciudad. De pronto, una voz etérea descendió de los cielos: "POR FAVOR BÁJENSE DE LA FUENTE". Quedamos atónitos, hasta que nos percatamos de que varias cámaras de seguridad – con altavoces y todo - nos apuntaban desde varios postes de luz. Era la primera vez que nos sentíamos tan vigilados, así que decidimos investigar cómo funcionan estos sistemas.

No es ninguna novedad que los departamentos de la policía y los gobiernos hayan estado vigilando a los ciudadanos por años con cámaras de seguridad en varias ciudades del mundo. Hoy en día, la mayoría de nosotros lo acepta como un intercambio que estamos dispuestos a hacer: sacrificamos nuestra privacidad con la esperanza de que esta medida ayude a mantenernos a salvo de los criminales y terroristas. Pero también esperamos que nuestros datos privados, en este caso, los videos de nuestra vida pública, se manejen con responsabilidad y seguridad para que esta vigilancia no acabe causando más daño que bien.

En nuestra investigación, descubrimos varias ciudades que usan tecnologías inalámbricas en sus cámaras de seguridad e infraestructuras, en vez de hacer las conexiones tradicionales mediante cables. Este cambio ahorra costes y tiempo a las autoridades de la ciudad.

Por desgracia, el problema es que las tecnologías inalámbricas no son tan seguras como deberían. Como estamos conscientes de la seguridad, nos percatamos de inmediato de que manejar datos de esta manera podría dejar los sistemas vulnerables a ataques, por lo que comenzamos a averiguar si estos sistemas estaban implementados de tal modo que protegían nuestros datos o si podían manipularse con facilidad con fines maliciosos.

Aunque las tecnologías inalámbricas en sí mismas pueden ser vulnerables, existen muchas mejoras adicionales que se pueden implementar para aumentar su seguridad a un nivel adecuado. Lo ideal es que haya varios niveles de seguridad para que, si un hacker logra superar un obstáculo, a continuación tenga que enfrentarse a otro todavía más difícil. Pero este no fue el caso.

Investigación

Nuestra investigación comenzó en un ámbito físico: viajamos a varias partes de la ciudad averiguando en qué consistía el hardware y encontramos la primera señal de que la ciudad no había puesto suficiente esfuerzo en la administración de sus propios sistemas.

Figura 1: el sistema de seguridad

Como muestra la imagen, el sistema de seguridad estaba configurado de una forma muy descuidada. Las unidades que manejarán nuestros datos no se han escondido para nada; algunas hasta mostraban el nombre y modelo del hardware, datos necesarios para identificar los dispositivos e iniciar la investigación.

¿Por qué es tan importante esconder las etiquetas y rotulaciones del hardware? Un ejemplo servirá para ilustrar la gravedad del asunto. Cuando un servidor necesita asegurarse, un factor importantísimo para prevenir que se lo explote es que el binario del servidor no esté al alcance del público. La razón es que, si un investigador consigue acceder al binario, puede utilizar ingeniería inversa y estudiarlo para encontrar errores y vulnerabilidades. Es muy raro que se descubra una vulnerabilidad sin haber visto el código que implementa el servicio. Es por esto que el hecho de que la rotulación esté a la vista parece un error intrascendente, pero en realidad tiene un efecto masivo.

Volviendo a la red de cámaras: si un hacker lograse romper la seguridad inalámbrica de estos sistemas (que sólo implementan las protecciones WEP o WPA estándar), hasta este punto sólo podría ver protocolos desconocidos, encabezamientos y paquetes inalámbricos que no hacen referencia al sistema al que pertenecen. En nuestro análisis, al principio no teníamos idea de cuál era el programa que generaba estos paquetes, ya que es un sistema privado. Sin tener el código a nuestra disposición, habría sido casi imposible revertir el protocolo que usan, que en realidad es la única forma de examinar la red como es debido. En este punto, nuestro trabajo ya estaba hecho.

Habiendo obtenido el hardware, nos dimos cuenta de que, a pesar de que la forma en lo colocaron dejaba mucho que desear, éste no era el verdadero problema. La red de nodos en malla era en realidad una solución muy compleja y bien ejecutada, con módulos integrados que aseguran las comunicaciones más allá de la seguridad estándar de la tecnología inalámbrica. Sólo se necesitaba a alguien con suficientes conocimientos para que implemente esta tecnología y se asegure de que esté bien configurada. Pero, por desgracia, después de inspeccionar muchos de los paquetes, nos dimos cuenta de que estos módulos de cifrado no se habían configurado ni implementado para nada. Se estaban enviando datos legibles mediante la red, poniéndolos al alcance de cualquier observador que pueda poner sus manos en ellos. No teníamos que superar ningún cifrado, por lo que todo era cuestión de recrear nuestra propia versión de este programa para manipular los datos que transfería.

Una comparación rápida de cómo funciona una red en malla para transportar transmisiones de video te ayudará a comprender las cosas que descubrimos que nos sirvieron para manipular el sistema. En una red Wi-Fi tradicional, cada dispositivo está conectado a un router que funciona como punto central. Para enviar un sector de un dato a otra parte de la red, debes enviarlo a esa dirección y viajará mediante el router hacia el dispositivo conectado. Esto funciona bien en mucha proximidad pero, para poder comunicarse a larga distancia, la red de cámaras usó topología y protocolos que no vamos a nombrar en este artículo.

Figura 2: topología tradicional de una red inalámbrica doméstica. Los clientes pueden ser cualquier dispositivo conectado a Internet

Figura 3: un atacante le dice al usuario que es el router, y le dice al router que es el usuario. Así es como intercepta el tráfico de y para el servidor web

En general, estar en cualquier red inalámbrica, como por ejemplo una red inalámbrica doméstica, permite que cualquier persona conectada pueda lanzar ataques de mediador (man-in-the-middle) usando métodos como el envenenamiento de ARP. Esto, en esencia, hace que el usuario pueda alterar cualquier dato que se haya enviado desde y para el router. Por la naturaleza del programa en malla, este método estándar no sería muy valioso si se lo intenta en un modo vainilla. En esencia, cada nodo en la red mallada sólo puede tener una línea directa de visión a alguno de los muchos nodos de la red. Para enviar un paquete a un dispositivo que no está dentro de su rango, el paquete debe viajar desde el punto de origen, pasando por varios otros nodos para por fin llegar al nodo de destino. El sistema del vendedor de hardware implementa un algoritmo "pathfinding" para encontrar rutas que permitan transportar los datos de forma eficiente y mediante la ruta más confiable hacia destino. El algoritmo es muy similar a aquel que se usa en videojuegos para determinar la ruta que un personaje va a tomar para llegar a su destino, evitando obstáculos.

Figura 4: el algoritmo Pathfinding encuentra rutas para que los personajes viajen en base a variables tales como la dificultad del terreno

El algoritmo pathfinding que se usa en las cámaras depende de ciertas variables, pero las más importantes son la fuerza de la señal entre un nodo y el siguiente y la cantidad de nodos por los que viaja para llegar a su destino final.

Es justo esto lo que aprovechamos. Cuando mentimos a los otros nodos diciéndoles que teníamos una línea directa hacia la estación de policías simulada y que nos comportaríamos como un nodo enviando paquetes, las cámaras más próximas comenzaron a reenviarnos sus paquetes de forma directa por la implementación A*. Esto permite un clásico ataque de mediador, "man-in-the-middle", pero esta vez hacia una gran cantidad de transmisiones de video. Una buena analogía con el juego RTS de arriba podría ser la de construir un puente sobre un lago para que todos puedan seguir el camino en vez de tener que bordear la orilla.

Figura 5: el paquete se origina en un Nodo A, viaja mediante los nodos B y C para llegar a su destino (simulación de estación de policías). Mientras tanto, todos los otros nodos viajan por una ruta diferente y no pueden interceptarse cuando se espía una sola ubicación

¿Qué implica esto?

No estamos en el negocio del hacking, sólo queríamos crear una prueba de concepto para demostrar que este tipo de ataques es posible, para exponer que existe una vulnerabilidad y, por último, para alertar a las autoridades sobre una vulnerabilidad que debe arreglarse. Por eso mismo, nuestra investigación se realizó en nuestro pequeño laboratorio privado, replicando los sistemas que la policía pone en efecto y sin dañar su red en ninguna manera.

Si los hackers maliciosos explotaran los problemas que acabamos de mostrar, se podrían desatar muchas situaciones peligrosas al mejor estilo de Hollywood. La capacidad de lanzar ataques man-in-the-middle a los datos del video está a sólo un paso de reemplazar las imágenes reales del video por otras pregrabadas. En este caso, una de las posibilidades es que los cibercriminales hagan creer al departamento de policía que está ocurriendo un crimen en una parte de la ciudad para que se envíen oficiales a ese sector. Esto dejaría abiertas la oportunidad para que se cometa un crimen en otra región de la ciudad que no tenga oficiales disponibles. Esta es sólo una forma en la que alguien podría usar estos sistemas con malas intenciones y aprovechar la vulnerabilidad para cometer crímenes con mucha mayor eficacia. Pero, por desgracia, ésta no es una película de Hollywood. Es una funcionalidad que pudimos replicar en nuestro laboratorio.

Confiamos nuestros datos privados a las autoridades pertinentes, pero si estas autoridades no dedican suficiente tiempo y recursos para manejar estos datos de forma responsable, es preferible dejar de lado esta tecnología por completo. Por fortuna, la ciudad que investigamos se preocupó cuando le alertamos sobre el problema y ha tomado iniciativas para mejorar la seguridad.

La triste realidad es que en estos días todo está conectado, y mientras se implementan nuevas tecnologías para modernizar las más antiguas, también se introducen nuevas vulnerabilidades. Dejando de lado los sistemas de vigilancia que analizamos hoy, existen muchos más sistemas que son, y serán, vulnerables a diferentes ataques. Es una carrera constante entre los "chicos buenos", que prueban la seguridad, contra los "chicos malos", que pueden usar las vulnerabilidades con malas intenciones. Nuestra labor es continuar con esta lucha para hacer de éste un mundo más seguro.

Conclusiones

Se deben tomar en cuenta las siguientes consideraciones para hacer que una red de malla tenga un grado razonable de seguridad:

  • Aunque todavía puede ser atacado, un cifrado WPA con contraseña fuerte es un requisito mínimo para evitar que el sistema sea un blanco fácil.
  • Esconder los filtros SSID y MAC también mantendrá a raya a los hackers menos hábiles.
  • Esconder todas las etiquetas de los equipos ayuda a controlar a los atacantes que no tienen esta información.
  • Asegurar los datos de video con criptografía de llaves públicas hará casi imposible que se manipulen los datos de video.

Los estafadores también pueden tener derechos


  Andrey Kostin       21 mayo 2015 | 13:00  MSK

Comentar  

Hace poco nos topamos con un interesante – desde el punto de vista técnico – método de obtener información personal. A uno de nuestros clientes le llegó un mensaje electrónico en el que le decían que alguien había utilizado su Live ID para enviar spam, y que por este motivo se procedería a bloquear su cuenta. Para evitar el bloqueo, le proponían seguir un enlace y cumplir las nuevas exigencias de seguridad del servicio.

Todo esto suena como la descripción de un típico mensaje phishing. Más adelante la víctima tendría que seguir un enlace, llegar a una página falsificada idéntica a la página oficial del servicio Windows Live, ingresar allí sus datos, que después serían enviados a los estafadores, etc. Pero para nuestra sorpresa, el enlace del mensaje fraudulento de verdad llevaba al sitio de Windows Live y los delincuentes no estaban tratando de apoderarse del login o contraseña de la víctima. Ellos estaban actuando de una forma mucho más astuta.

El esquema fraudulento

¿Cuál es el peligro que representa seguir el enlace enviado, si de verdad lleva al sitio oficial de Microsoft?

Mensaje fraudulento

Lo que pasa es que la cuenta de Live ID también puede utilizarse para autorizarse en otros servicios: Xbox LIVE, Zune, Hotmail, Outlook, MSN, Messenger, OneDrive, etc. Como resultado del ataque, el delincuente no sólo obtiene acceso directo a estos servicios en nombre de la víctima, sino que también puede robar la información personal contenida en los perfiles de los usuarios de estos servicios y usarlos para fines fraudulentos.

Al seguir el enlace del mensaje, llegamos al servicio oficial live.com, donde nos piden que nos autoricemos ingresando nuestro login y contraseña.



Una vez pasada la autorización, el login y la contraseña no caen en manos de los delincuentes, como se podría suponer (y como suele suceder), sino que realmente nos autorizamos en live.com. Pero después de esto, el servicio nos hace una solicitud interesante:



Cierta aplicación pide permiso de ingreso automático, acceso a los datos del perfil y la lista de contactos, como también acceso a las direcciones de correo electrónico. Al pulsar “Sí”, le concedemos estos derechos y, en esencia, les enviamos a sus creadores nuestros datos personales, las direcciones de correo de nuestros contactos, los apodos y nombres de nuestros amigos, etc. En vista de que en este caso no sabemos nada ni sobre la aplicación, ni sobre sus autores, podemos suponer que los datos recolectados de esta manera serán utilizados para fines fraudulentos. Y una vez más queremos recalcar que el login y la contraseña siguen siendo confidenciales.

¿Cómo funciona todo esto?

Desde el punto de vista técnico, todo es muy sencillo. Existe un protocolo especial abierto de autorización llamado OAuth, que permite dar a terceros acceso limitado a los recursos privados del usuario sin darle su login y contraseña. Con frecuencia, los creadores de aplicaciones web usan este protocolo en las redes sociales, si sus aplicaciones requieren ciertos datos para funcionar, por ejemplo, la lista de contactos. Para los usuarios la comodidad consiste en que ellos ya están autorizados en el servicio y no tienen que ingresar su login y contraseña cada vez para otorgarle permisos a la aplicación.

Hace ya bastante tiempo que se sabe de las brechas de seguridad del protocolo OAuth: a principios de 2014 un estudiante de Singapur describió los posibles métodos de robo de información de los usuarios una vez pasada la autorización. Pero hasta ahora no habíamos detectado mensajes de phishing en los que los delincuentes hubiesen tratado de aplicar estos métodos en la práctica.

En el caso que nos ocupa, cuando el usuario pulsa el enlace del mensaje fraudulento: hxxps://login.live.com/oauth20_authorize.srf?client_id=00xxx4142735&scope=wl.signin%20wl.basic%20wl.emails%20wl.contacts_emails&response_type=code&redirect_uri=hxxp://webmail.code4life.me/hot/oauth-hotmail.php

llega a la página de autorización, donde se le pide su confirmación para otorgar los derechos codificados en los parámetros de la aplicación. Si el usuario da su consentimiento, se lo remite a una página especial (hxxp://webmail.code4life.me/hot/oauth-hotmail.php), en cuyo URL después del parámetro “code” se agrega “access token” (hxxp://webmail.code4life.me/hot/oauth-hotmail.php?code=36cef237-b8f6-9cae-c8e4-ad92677ba), que la aplicación intercepta directamente desde el campo de direcciones. Más adelante la aplicación usa este “access token” para acceder a los recursos protegidos. A grandes rasgos, las posibilidades de OAuth no se limitan a sólo la autentificación y la autorización. Habiendo recibido el token durante la autorización, se lo puede usar para integrar las posibilidades del servicio web o la red social en sus propios recursos: lectura, escritura de posts, acceso a las noticias y muros de los amigos, y mucho más.

Contenido del enlace

Si miramos con atención al enlace enviado, podemos notar los parámetros wl.signin, wl.basic, wl.emails y wl.contacts_emails. Es precisamente en ellos que están codificados los niveles de los permisos que la aplicación solicita al usuario:


  • wl.signin es un registro único, gracias al cual los usuarios que ya entraron a Windows Live se registran automáticamente en cualquier sitio web que admita este tipo de autorización;
  • wl.basic da acceso a la lectura de los datos principales del perfil del usuario, como su sobrenombre, nombre, apellido, sexo, edad, país donde se encuentra, y la lista de sus contactos;
  • wl.emails da acceso a la lectura de direcciones de correo electrónico personales, preferidos y de servicio del usuario;
  • wl.contacts_emails abre el acceso a las direcciones electrónicas de todos los contactos del usuario.

También existe una enorme cantidad de otros parámetros que dan permiso para, por ejemplo, obtener las fotografías del usuario y sus contactos, datos sobre sus cumpleaños, lista de encuentros y de sucesos importantes. De hecho, usando esta información el delincuente puede crear un retrato de la persona, entender a qué se dedica, cuándo no está en casa, quienes son sus amigos y con quién sale, y usar estos datos para fines criminales.

Durante búsquedas adicionales logramos encontrar otros mensajes phishing similares que contenían enlaces al servicio oficial de Microsoft. En todos los casos los delincuentes solicitaban a la víctima la misma información (datos del perfil, direcciones de correo electrónico, contactos) y sólo eran diferentes las direcciones de las páginas especiales donde se encontraba la aplicación fraudulenta.

hxxps://login.live.com/oauth20_authorize.srf?client_id=000000004C1xxx06&scope=wl.signin%20wl.basic%20wl.emails%20wl.contacts_emails&response_type=code&redirect_uri=http://soluciones-ntflix.com/web/oauth-hotmail.php

hxxps://login.live.com/oauth20_authorize.srf?client_id=000000004C1xxx3C&scope=wl.signin%20wl.basic%20wl.emails%20wl.contacts_emails&response_type=code&redirect_uri=http://registros-promos.com/web/oauth-hotmail.php

hxxps://login.live.com/oauth20_authorize.srf?client_id=00000000441xxx1B&scope=wl.signin%20wl.basic%20wl.emails%20wl.contacts_emails&response_type=code&redirect_uri=http://applications-registro.com/web/oauth-hotmail.php

hxxps://login.live.com/oauth20_authorize.srf?client_id=00000000441xxx17&scope=wl.signin%20wl.basic%20wl.emails%20wl.contacts_emails&response_type=code&redirect_uri=http://estimaciones-serv.com/web/oauth-hotmail.php

Merece la pena destacar que algunas aplicaciones para redes sociales también usan el protocolo OAuth.



Ejemplo de concesión de derechos a una aplicación en Facebook

Una aplicación creada por los delincuentes puede pedir a la víctima permiso para hacer publicaciones y poner fotografías en el muro, leer y enviar mensajes personales y agregar notas en los libros de invitados. Estas posibilidades pueden usarse para propagar spam y enlaces a sitios phishing o maliciosos.

Conclusión

En el caso que hemos analizado, lo más probable es que la información se recopile para propagar spam usando la libreta de direcciones de la víctima o para realizar ataques mediante el spam selectivo (spear phishing).

Para no convertirse en víctima de los astutos estafadores, no hay que seguir los enlaces recibidos por correo o mensajes personales en las redes sociales. Pero lo más importante es no dar derechos de acceso a los datos personales a aplicaciones desconocidas en las que no confías. Antes de dar tu consentimiento, tienes que leer atentamente la descripción de derechos de acceso a la cuenta que recibirá la aplicación y calcular el nivel de peligrosidad de la amenaza. Puedes buscar en Internet información y comentarios sobre la aplicación y los derechos que solicita. Además, en cualquier red social o servicio web se puede ingresar a la configuración de la cuenta o perfil y ver qué derechos tienen las aplicaciones instaladas, y si es necesario, reducir su cantidad.


Ejemplo de derechos en Google

Si te enteras que la aplicación ya propaga spam o enlaces maliciosos en tu nombre, puedes enviar una queja a la dirección de la red social o del servicio web para que la bloqueen. Y si necesitas autorizarte en algún servicio o red social, es mejor ingresar directamente al sitio web escribiendo su dirección en el navegador. Y, por supuesto, verificar que las bases de tu antivirus y tecnologías de defensa contra el phishing estén actualizadas.


¡Tu devolución de la renta trae un programa chantajista de regalo!


  Dmitry Bestúzhev       14 abril 2015 | 19:50  MSK

Comentar  

Las declaraciones de la renta de último minuto dirigen a un programa chantajista oportunista

Oh, ¡¿Por qué siempre tenemos que dejar todo para el último minuto?! El 15 de abril es la fecha límite para enviar los formularios del Servicio de Rentas Internas en Estados Unidos, y parece que muchos de los que vivimos en este país esperamos hasta el último momento para declarar nuestros impuestos y esperar con muchas, muchas ansias esa satisfactoria devolución de la renta. šPor desgracia, los escritores de virus conocen nuestra situación y están listos para sacarle provecho. Sabiendo que hay mucha gente esperando los correos electrónicos del Servicio de Rentas Internas sobre las devoluciones pendientes, los criminales han elaborado sus propios mensajes falsos:

El archivo adjunto es en realidad el programa malicioso Trojan-Downloader.MsWord.Agent, construido por el mismo grupo responsable de la campaña maliciosa LogMeIn que describimos aquí.

La infección es muy similar a la que mencionamos en la entrada anterior, pero los criminales han pasado de atacar las entradas de Pastebin a hackear un servidor web de China para alojar el fichero de instrucciones del script. Este fichero y la URL de descarga también están cifrados en Base64, y la carga explosiva resultante es un programa chantajista.

Las URL incluidas en los macros maliciosos dirigen al fichero de instrucciones del script cifrado con Base64 y a la URL que se muestra abajo, que aloja la amenaza

Ficheros de instrucciones con la URL que dirige al programa chantajista

Kaspersky Anti-Virus detecta el programa chantajista como Trojan-Ransom.Win32.Foreign.mfbg.

Como el ataque se centra en imitar al Servicio de Rentas Internas de los Estados Unidos, esta operación está dirigida a los ciudadanos y residentes permanentes de los Estados Unidos.

Haciendo frente a CoinVault: la hora de liberar los ficheros ha llegado


  Santiago Pontiroli       13 abril 2015 | 19:41  MSK

Comentar  

Santiago Pontiroli


Hace algunos meses escribimos una entrada del blog sobre CoinVault. Allí explicamos cómo despedazamos el programa malicioso para llegar a su código original en vez del ofuscado.


Por eso, cuando la Unidad Nacional de Altos Crímenes Tecnológicos (NHTCU) de la policía de Holanda y la Oficina de la Procuraduría Nacional de Holanda se pusieron en contacto con nosotros porque habían conseguido una base de datos del servidor de comando y control de CoinVault (con IVs, llaves y billeteras privadas de Bitcoin), tuvimos la oportunidad de darle un buen uso a los conocimientos que habíamos acumulado y acelerar la creación de una herramienta de descifrado.

También creamos un sitio web y comenzamos una campaña de comunicación para decirle a las víctimas que podían recuperar sus datos sin pagar el rescate.

Necesitábamos saber lo siguiente para construir la herramienta de descifrado:


  • ¿Qué algoritmo de cifrado se usó?

  • ¿Qué modo de cifrado por bloques empleó?

  • Y, lo más importante, ¿con qué programa malicioso estamos lidiando?


Por supuesto, no teníamos tiempo para hacer un estudio profundo de ingeniería inversa, así que lo primero que hicimos fue ejecutar el ejemplar del programa para ver lo que estaba haciendo. Tal como imaginamos, era otro ejemplar de CoinVault. Lo siguiente que hicimos fue abrir el ejecutable en un decompilador, donde vimos que se usó el mismo método de ofuscación que se describió en la entrada. Entonces confirmamos que se estaba usando CoinVault. Pero todavía no sabíamos qué algoritmo de cifrado y modo de cifrado por bloques estaba usando.


¡Por suerte tenemos una caja de arena! Lo bueno de la caja de arena es que, además de ejecutar el programa malicioso, puede rastrear casi cualquier cosa. Podemos volcar ficheros y cambios en el registro pero, en este caso, los vaciados de memoria fueron lo más interesante. Sabíamos por los anteriores ejemplares de CoinVault que el programa malicioso empleaba la clase RijndaelManaged, así sólo tuvimos que buscar esta cadena en el vaciado de memoria.



Y aquí la tienes. Podemos ver que sigue usando AES, pero no el bloque de 128 bits de tamaño, sino el de 256 bits. El modo de cifrado por bloques también se cambió de CBC a CFB. Esa es toda la información que necesitábamos para escribir nuestra herramienta de descifrado.


Para ver si puedes descifrar tus ficheros, visita https://noransom.kaspersky.com.

El juego del escondite de Simda: una actividad para adultos


  Vitaly Kamluk       13 abril 2015 | 19:13  MSK

Comentar  

El 9 de abril de 2015, Kaspersky Lab participó de una operación sincronizada que coordinó la INTERPOL Global Complex for Innovation para desactivar la red zombi Simda. Microsoft había iniciado la investigación y la expandió para ampliar su círculo de participantes, que incluyen TrendMicro, el Cyber Defense Institute, oficiales de la Unidad Nacional de Altos Crímenes Tecnológicos (NHTCU) de Holanda, el FBI, la sección de Nuevas Tecnologías de la policía Grand-Ducale de Luxemburgo y el Departamento de Crímenes Cibernéticos “K” del Ministerio del Interior de Rusia, apoyado por la Oficina Nacional Central de INTERPOL en Moscú.

Como resultado de este trabajo conjunto, se confiscaron 14 servidores C&C en Holanda, Estados Unidos, Luxemburgo, Polonia y Rusia. Los análisis preliminares de algunos registros aislados en un sinkhole del servidor revelaron una lista de 190 países afectados por la red zombi Simda.


El personaje Simba, cortesía de Walt Disney Productions, no tiene nada que ver con la red zombi Simda

Simda es una misteriosa red zombi que se usa con fines cibercriminales, como la propagación de programas potencialmente nocivos o indeseados. Es misteriosa porque rara vez aparece en nuestros radares de KSN a pesar de que compromete una gran cantidad de equipos cada día. Esto se debe en parte a que detecta la emulación, las herramientas de seguridad y los equipos virtuales. Tiene varios métodos para detectar los ambientes aislados en una caja de arena y engaña a los investigadores consumiendo todos los recursos del CPU o informando al dueño la dirección IP externa de la red de investigación. Otra razón es su polimorfismo en el lado del servidor y la limitada vida de sus bots.


Simda se distribuye mediante sitios web infectados que redirigen a paquetes de exploits. El bot utiliza direcciones IP integradas de forma rígida en el código para notificar a su dueño sobre varias etapas del proceso de ejecución. Descarga y ejecuta componentes adicionales de sus propios servidores de actualización y puede modificar el fichero hosts del sistema. Logra lo último con una técnica interesante, aunque a primera vista decepciona por su obviedad.


Por lo general, los escritores de malware modifican los ficheros host para alterar los resultados de los motores de búsqueda o añadir a la lista negra algunos sitios web de programas de seguridad, pero el bot Simda agrega registros inesperados para google-analytics.com y connect.facebook.net para dirigir a IPs maliciosas.


¿Por qué? No lo sabemos, pero creemos que tiene que ver con el propósito principal de Simda: la distribución de otros programas maliciosos. Este modelo criminal de negocios permite distribuir el programa malicioso con exclusividad. Esto significa que los distribuidores pueden garantizar que sólo el malware del cliente esté instalado en los equipos infectados. Esto ocurre cuando Simda interpreta una respuesta del servidor C&C: puede desactivarse a sí mismo para evitar que el bot se inicie la próxima vez que se reinicie el sistema, saliendo de inmediato. Se desactiva a la vez que modifica el fichero hosts del sistema. Como un último adiós, Simda reemplaza el fichero hosts original por uno nuevo de su propio cuerpo.


Una mente curiosa se preguntará: ¿para qué? Estos dominios ya no se usan para generar búsquedas de resultados, pero los ordenadores infectados por Simda en el pasado pueden de vez en cuando enviar solicitudes HTTP a servidores maliciosos, aun cuando se supone que se han instalado programas maliciosos exclusivos externos.


Debemos recordar que la primera infección de estos equipos la realizó un exploit que aprovechó una vulnerabilidad en un programa desactualizado. Es muy probable que un programa malicioso externo se elimine con el tiempo, pero un usuario descuidado podría no volver a actualizar el programa vulnerable.


Si todos esos hosts siguen volviendo a los servidores maliciosos para pedir recursos web como ficheros javascript, los criminales podrían usar los mismos exploits para re-infectar los equipos y volverlos a vender, tal vez hasta de forma “exclusiva” al cliente original. Esto confirma lo que ya sabemos: que no hay honor entre criminales.


En esta investigación, Microsoft y varias autoridades completaron el proceso de aislamiento en un sinhkole y Kaspersky Lab contribuyó voluntariamente al proceso de cierre. Esto incluye el análisis técnico del malware, la recolección de estadísticas de infección, asesoramiento sobre la estrategia de cierre de la red zombi y la consulta de nuestros compañeros de la INTERPOL.


Kaspersky Lab detectó el bot Simda como Backdoor.Win32.Simda y, según nuestros cálculos basados en las estadísticas de KSN y telemetría de nuestros socios, afectó a cientos de miles de víctimas en todo el mundo.

Simda se genera de forma automática según la demanda y esto lo confirma el desorden en los tiempos de compilación de los enlaces. Abajo vemos una tabla con la información de un pequeño subgrupo de alrededor de 70 ejemplares de Simda:


Horas de enlace de los ejemplares en la zona horaria UTC

Las horas de enlaces más altas pueden tener relación con los tiempos de mayor actividad de sus víctimas, que se encuentran entre las zonas UTC-9 y UTC-5, que incluyen a los Estados Unidos.


Gracias a la operación de sinkhole y el intercambio de datos entre los participantes, hemos armado una página donde puedes revisar si tu IP se ha conectado en algún momento a los servidores C&C de Simda. Si sospechas que tu equipo está comprometido, puedes usar una de nuestras soluciones gratuitas o de prueba para analizar tu disco duro o instalar Kaspersky Internet Security para una solución a largo plazo.


Los productos Kaspersky Lab detectan cientos de miles de modificaciones de Simda y muchos programas maliciosos externos que se distribuyen durante sus operaciones.

Referencias:

Page Top  |  Archivo >>

 

Copyright © 1996 - 2015
Kaspersky Lab
Todos los derechos reservados

Correo electrónico: webmaster@viruslist.com