Cibercrimen Bancario: detenga los ataques financieros online. Lic. Cristian F. Borghello* - CISSP - MVP - CCSK

Transcripción

1 Cibercrimen Bancario: detenga los ataques financieros online. Lic. Cristian F. Borghello* - CISSP - MVP - CCSK

2 ÍNDICE Abstract Introducción Ataques MitB Técnicas y tipos de malware Prueba de concepto Medidas de protección adicionales Evaluación de herramientas no tradicionales Prueba de Wontok SafeCentral Banking en un ambiente real Conclusiones Referencias Pág. 03 Pág. 03 Pág. 04 Pág. 05 Pág. 06 Pág. 07 Pág. 08 Pág. 10 Pág. 12 Pág. 13 2

3 ACERCA DEL AUTOR: Lic. Cristian F. Borghello - CISSP - MVP - CCSK *Licenciado en Sistemas de la Información, 2001 Universidad Tecnológica Nacional de Argentina (UTN), Certificación internacional CISSP (Certified Information Systems Security Professionals) desde 2008 y CCSK (Certificate of Cloud Security Knowledge) desde Reconocido como Microsoft MVP (Most Valuable Professional), Consumer Security desde Creador y Director del sitio sobre seguridad fundador sitio orientado a la seguridad de los menores, padres y docentes en Internet, creador del sitio para luchar y combatir el phishing en América Latina. Actualmente se desenvuelve como consultor independiente desarrollando programas de concientización, educación y consultoría a medida para reconocidas empresas y organizaciones. También es profesor en materias afines en distintas universidades de Argentina. Abstract Las entidades financieras han adoptado medidas para proteger sus canales electrónicos, pero poco se informa al usuario que opera mediante homebanking sobre las acciones a realizar ante las limitaciones de las protecciones tradicionales (firewall y antivirus) frente a las nuevas técnicas utilizadas por lo cibercriminales. En este whitepaper se examinarán medios de protección no tradicionales que el usuario, que opera mediante homebanking y utiliza tarjetas de débito y crédito, debería adoptar para complementar los tradicionales. INTRODUCCIÓN Los desarrolladores de malware financiero y bancario siempre encuentran nuevas formas de eludir las tecnologías actuales de detección y, en los últimos años, se han convertido en una verdadera pesadilla para sistemas de escritorio, mientras encuentran la manera de evadir también la protección de los sistemas operativos móviles, sistemas de pago y cajeros automáticos. Existen numerosas técnicas y caminos para evadir las protecciones tradicionales de antivirus y firewall: algunas de ellas incluyen un amplio conocimiento del sistema operativo atacado, otras directamente aprovechan la ingenuidad del usuario y otras aprovechan una combinación de ambas para lograr una instalación adecuada y posterior explotación de vulnerabilidades. El resultado es el mismo: la información sensible del usuario llega a manos del delincuente quien la aprovecha para realizar fraudes, robos, suplantación de identidad y otras actividades delictivas. En aplicaciones y sitios web que manejan datos financieros, económicos y bancarios, y en un análisis más detallado de los inconvenientes, se observa que, en estos ataques existen puntos en común que no corresponden a errores de la entidad sino al otro extremo: el navegador, la aplicación, el usuario. Desafortunadamente, el desafío de asegurar el punto final que no se puede controlar, ha sido por mucho tiempo una batalla perdida. 3

4 ATAQUES MITB los ataques Man-in-the-Browser (MitB) [1] apuntan a infectar el sistema operativo y/o controlar de manera adecuada la herramienta que el usuario utiliza la conectarse a Internet el navegador o una aplicación móvil para lograr extraer información de utilidad que luego es enviada al atacante. El objetivo es modificar on-the-fly el contenido de las páginas web y de la transacción de manera invisible al usuario, independientemente de los mecanismos de cifrado utilizados (HTTPS/TLS/SSL/PKI), de las soluciones de autenticación y de cualquier otra medida de seguridad incorporada. Es importante destacar que los ataques MitB son distintos de los ataques de Phishing, en los cuales el usuario confía en un sitio web fraudulento que es copia del verdadero y que roba la información al momento de la autenticación. En MitB, el usuario ingresa al servicio real (incluso protegido con HTTPS), se registra/autentica de forma normal con sus datos y no hay ninguna diferencia apreciable. Generalmente se cree que un ataque MitB puede contrarrestarse mediante soluciones triviales como el teclado virtual o, más elaborado, como la verificación de transacciones fuera de banda por ejemplo el envío de un SMS al celular [2]. Pero, como el ataque funciona a nivel de transacción, estas medidas de protección han sido ampliamente vulnerada por malware del tipo Man-in-the-Mobile (MitMo) como SpyEye (Spitmo) [3], Zeus (Zitmo) [4] y Tatanga [5] en donde se infecta el dispositivo móvil del usuario para controlar cualquier tipo de interacción con el mismo. El malware puede ser detectado y eliminado por los antivirus pero, debido a las ganancias exorbitantes de los delincuentes, la innovación y evolución del malware, el juego del gato y el ratón es cada vez más, sólo el juego del ratón. En este sentido, el informe Web Browsers: Your Weak Link in Achieving PCI Compliance [6] concluye que, además de los antivirus, para protegerse de ataques relacionados a MitB, son necesarias medidas adicionales. En los ataques MitB, se ataca el navegador (o aplicación) del usuario y se inyecta nuevo contenido HTML en las páginas web enviadas (incluso por HTTPS) por el servidor web. Se busca capturar la información sensible directamente desde la memoria asignada al navegador para capturar credenciales y datos de las transacciones. Algunos ataques MitB inyectan campos adicionales a la página de inicio y otros superponen contenido HTML o una imagen sobre la página real, de forma que el usuario permanece en el sitio verdadero pero ingresa sus datos en campos que originalmente no estaban allí. Por ejemplo, en la siguiente imagen se observa el acceso a un banco real en donde puede verse la barra verde, el HTTPS, el certificado digital Class 3 Extended Validation [7] y el archiconocido candado. Figura 1 - Funcionamiento de Banker Screen Overlay. El malware también podría funcionar en Firefox y Chrome (SHA=17a0cba774b91afa5767ee1d5c7c0c9ccdd37c59) 4

5 Pero, en este caso un troyano bancario del tipo Screen Overlay controla el sistema y se observa: (1) Una imagen, tomada del sitio real, superpuesta por el troyano tapa gran parte de la página real. La imagen sólo deja disponible los campos que el usuario debe ingresar (tipo de documento, DNI y clave). (2) Un error del troyano al superponer la imagen tapa la parte inferior del logo del banco. Este error ocurre en esta versión del troyano, pero no necesariamente en todos. Finalmente, cuando el usuario presiona sobre el botón Ingresar, que es parte de la imagen superpuesta, los datos son enviados al delincuente. 5

6 TÉCNICAS Y TIPOS DE MALWARE Los troyanos del tipo Screen Overlay tienen su origen en Brasil y se encuentran muy desarrollados en América Latina [8]. La manera tradicional de realizar esta acción consiste en manipular las API (Application Program Interface) del sistema operativo y de las aplicaciones. La técnica denominada Hooking cubre una amplia gama de operaciones, generalmente involucra malware del tipo Rootkit (a nivel de usuario y kernel) y permite alterar el funcionamiento del sistema mediante la interceptación de llamadas a funciones, eventos y mensajes donde se encuentran los datos sensibles del usuario. Con estas inyecciones, se puede: exfiltrar información sensible (robo de datos del usuario); obtener cookies de sesión y autenticación; inyectar campos o formularios; reemplazar o modificar parte de la página web (por ejemplo cuando el usuario visualiza el saldo de su cuenta); realizar una operación fraudulenta en nombre del usuario autenticado; suplantar la identidad del usuario; captura de pantalla, keylogging y videologging (que permiten saltear los teclados virtuales) comprometer los DNS y redireccionar a otros sitios; SSL hijacking... Malware de este tipo incluyen, pero no se limitan a, variantes y clones de SpyEye Dyre, Gozi y clones de ZeuS como Citadel, Kins, SkyNet, Ramnit, Licat, Murofet, Zberp: Figura 2- Zeus Timeline ( ) 6

7 Además, el malware actual busca comprometer puntos de venta, software tipo PoS (Point of Sale) [9] y los utilizados en los cajeros automáticos [10]; nuevamente cualquier punto final donde el usuario queda expuesto como responsable de la detección. Ejemplos de este tipo de malware incluyen Alina, BlackPOS, BackOFF, Chewbaca, Dexter, Kaptoza POS, Ploutus y Tyupkin. El compromiso de este tipo de dispositivos es crítico ya que una organización que no los proteja estaría incumpliendo normativas nacionales e internacionales como DSS PCI [11]. PRUEBA DE CONCEPTO A modo de Prueba de Concepto (PoC) se infecta un Microsoft Windows 7 (actualizado y al día) con una versión del popular bot Zeus actualmente In-the-Wild y se verifica que efectivamente el navegador del usuario es inyectado y controlado por el malware. Figura 3 - Navegador infectado (SHA=e0ae875de0a7d53f92ff2ce5ea6bb7bd0c5370a8) En la imagen se puede observar que se ha agregado/inyectado el campo Clave Transferencia a través del componente WebInject del bot. Este campo no aparecería en una situación normal en un sistema limpio y permite al delincuente obtener datos adicionales del home-banking del usuario. Nota: en la prueba se utilizó un home-banking creado a tal fin y, en una situación real, el método de infección se podría perfeccionar cuanto se deseara, por ejemplo, solicitando todos los números de una tarjeta de coordenadas. 7

8 MEDIDAS DE PROTECCIÓN ADICIONALES Luego de conocer las técnicas de ataque y el malware que las aprovechan, las pruebas actuales consideran que las herramientas clásicas de seguridad fallan cuando se cumplen alguna de las siguientes condiciones (no necesariamente todas): la aplicación de seguridad es incapaz de detectar el malware cuando arriba al sistema (por ejemplo el usuario descarga un archivo o lo copia); el archivo es ejecutado sin ser detectado; es incapaz de impedir la captura y el envío los datos; no brinda ningún tipo de alerta informativa sobre actividades sospechosas; intercepta la instalación/acción del malware pero las advertencias pueden confundirse con solicitudes legítimas; la aplicación dañina es detectada como sospechosa pero se brinda la posibilidad de ejecutarla en modo restringido. Siguiendo un modelo de riesgos y defensa en profundidad (o por niveles) [12] se deben analizar otros tipos de soluciones y, ya en el año 2006, previendo las implicancias anteriores, se publica el informe Concepts against Man-in-the-Browser Attacks [13] en donde se analiza cada alternativa para combatir los ataques MitB. Una aplicación de seguridad tendrá éxito cuando: detecta el malware mientras está siendo descargado o copiado al sistema; detecta y bloquea el malware cuando se ejecuta; evita que el malware se ejecute al momento de arrancar el sistema y/o el navegador; bloquea el acceso a información sensible del usuario; manipula los datos del usuarios en compartimentos estancos, separados del resto del sistema y de las aplicaciones (sandbox); permite realizar una transacción segura, incluso cuando el sistema ya se encuentre infectado previamente; detecta, evita y detiene el envío de datos al delincuente; identifica el malware y lo bloquea automáticamente (sin necesidad de la interacción del usuario); se muestran mensajes claros al usuario que le permiten identificar solicitudes legítimas de solicitudes fraudulentas Como solución sugerida aparece un modelo que se puede considerar paranoico, pero no deja de ser efectivo: utilizar una máquina virtual cada vez que el usuario deba realizar una operación sensible, por ejemplo ingresar a su home-banking. Suponiendo que la máquina virtual no sea infectada o que la misma puede ser recuperada en cualquier situación, este acercamiento elimina el riesgo de los ataques contra el sistema o navegador local, pero representa un problema de usabilidad importante, porque un usuario final no debería tener la necesidad de obtener conocimientos avanzados para realizar una simple transacción bancaria o comercial. Pero, se puede lograr un punto intermedio? Este punto debería estar entre la seguridad mayor a la de un antivirus tradicional y la simplicidad deseada para el usuario: el acceso seguro no debería ser más costoso que un clic. En este contexto, se dice que una solución de seguridad tradicional trabaja en base a identificación de archivos a través de firmas o heurística, requiere actualizaciones frecuentes, puede generar falsos positivos y, podría no ser capaz de identificar ataques tipo 0-Days [14] o nuevas amenazas emergentes avanzadas con capacidad de persistencia, como APT (Advanced Persistent Threat) [15]. 8

9 EVALUACIÓN DE HERRAMIENTAS NO TRADICIONALES MRG Effitas (UK) [16] es una organización independiente conformada en 2009 y que se focaliza en la avaluación y eficacia de soluciones de seguridad que detectan malware bancario con características de MitB. Sus pruebas incluyen malware financiero y bancario real, actualmente In-the-Wild y que involucra algunas de las muestras mencionadas anteriormente. Desde 2012, Effitas ha publicado una serie de análisis donde se evalúan soluciones que consideran la creación de un ambiente aislado (tal y como se describió) cada vez que el usuario necesita realizar una operación segura. Como resultado el cliente puede completar sus transacciones sin riesgo de que el malware pueda obtener información sensible. Este enfoque proactivo es un escenario efectivo, incluso cuando el malware ya se encuentra en el sistema, porque provee un entorno seguro que las soluciones de seguridad convencionales no pueden brindar y, con el beneficio adicional, de la facilidad de uso. Fuera de las soluciones de seguridad tradicionales, en 2004, uno de los primeros proyectos que consideró el acercamiento de aislar parte de las aplicaciones ejecutadas por el usuario fue SandBoxie [17], la cual permite ejecutar dentro de un entorno controlado la aplicación que el usuario desee. Al día de hoy, uno de los principales inconvenientes de esta aplicación es que si el sistema es controlado por el malware antes de la ejecución de SandBoxie, este no protegerá de forma efectiva los datos ingresados por el usuario, por ejemplo en el caso de un keylogger o rootkit. Effitas así lo hizo notar en su informe de octubre de 2012 [18]. Por su parte, Trusteer Rapport [19] verifica que el usuario realmente se haya conectado a un sitio web genuino previamente agregado a una lista blanca en vez de a uno creado por delincuentes. Esta funcionalidad es sumamente útil para prevenir casos de Phishing, pero no garantiza la detección de malware avanzado, capaz de manipular transacciones al momento del intercambio de información entre el cliente y el servidor, capacidad que de todos modos puede ser provista por una solución antivirus tradicional. Una aplicación que ha demostrado una alta tasa de éxito en los análisis de Effitas, es Wontok SafeCentral Banking [20], una solución que a través de la creación de un entorno aislado y un escritorio seguro, vuelve momentáneamente inoperable el malware, rookits diseñados para tomar el control del sistema operativo, inyectores que toman el control del navegador, Keyloggers y Screen/VideoLogger responsables de grabar las teclas pulsadas y pantallas visualizadas por el usuario, DNS Changer capaces de manipular las conexiones a Internet. De esta manera busca evitar el Phishing, la ejecución del malware y los ataques MitB. 9

10 PRUEBA DE SAFECENTRAL BANKING EN UN AMBIENTE REAL En este caso, el objetivo no es la detección/eliminación del malware, lo cual puede realizarse con un antivirus tradicional. El objetivo es poder realizar transacciones seguras en un entorno donde el malware no tenga efecto. Figura 4 - Escritorio de Wontok SafeCentral Banking Al ejecutarse, Wontok SafeCentral Banking crea un nuevo escritorio en donde el usuario puede ingresar a su navegador de forma totalmente aislada del resto del sistema. El proceso sólo requiere un clic adicional y proporciona un entorno seguro (sandbox) para realizar transacciones bancarias, comerciales y financieras. Para verificar su funcionamiento y comportamiento en un ambiente hostil, se tomó el mismo sistema previamente infectado con Zeus, se instaló Wontok SafeCentral Banking y se realizaron las siguientes pruebas. Figura 5 - Archivos de Zeus en el sistema operativo 10

11 Se abre la consola Wontok SafeCentral y se ingresa al home-banking. En este caso se aprecia que el usuario ingresa sin que se realice la inyección HTML, previamente verificada en la PoC inicial. Figura 6 - Protección del home-banking de Wontok SafeCentral Banking 2. Se modifica el archivo de DNS local del sistema ( Windows\System32\drivers\etc\hosts ), simulando el comportamiento de un DNS Changer tradicional. Se debe tener en cuenta que este ataque de Pharming local puede ser llevado a cabo en cualquier sistema operativo. Luego del cambio, al ingresar al sitio se observa lo siguiente: Figura 7- Modificación del DNS local Figura 8 - Pharming local 11

12 Como puede observarse, el cambio de DNS efectivamente impacta en forma negativa y el usuario es redireccionado al sitio dañino. 3. Se abre la consola Wontok SafeCentral Banking, se ingresa a la misma URL anterior y se puede comprobar que la redirección vía el DNS local no se produce. 4. Se realiza una prueba similar con el troyano Screen Overlay mostrado previamente. El sistema efectivamente es infectado, pero el usuario puede seguir realizando sus transacciones en forma normal, sin verse afectado por la operación del malware. CONCLUSIONES Luego de las pruebas realizadas con distintos tipo de malware in-the-wild, se puede comprobar que la creación de un entorno aislado es una barrera adicional importante que está en sincronía con la defensa en profundidad recomendada por las buenas prácticas internacionales y complementa de forma efectiva las soluciones de seguridad tradicionales como antivirus y firewall. Este entorno brinda al usuario la posibilidad de realizar transacciones seguras y colabora con la organización en el fortalecimiento de entornos corporativos sin brechas de seguridad ni fuga de información. 12

13 REFERENCIAS [1] https://www.owasp.org/index.php/man-in-the-browser_attack [2] [3] [4] [5] [6] https://www.quarri.com/files/quarri_pci_brief.pdf [7] [8] [9] [10] [11] https://es.pcisecuritystandards.org/ [12] [13] [14] [15] [16] https://www.mrg-effitas.com/current-tests/ [17] [18] https://www.trusteer.com/sites/default/files/mrg_0.pdf [19] [20] 13