Destapada operación de blanqueo a través de juegos para móvil gracias a un MongoDB sin control de acceso

La organización utilizaba tarjetas de crédito robadas para comprar mejoras e ítems en los juegos para móvil de forma automatizada, que después revendían a cambio de dinero real en portales de compra-venta de recursos alternativos.

A Al Capone le pilló el fisco. El arresto del contable Guillermo Pallomari fue el primer gran golpe al cartel de Cali. "Luis, se fuerte", e incontables ejemplos más. Desde que el crimen organizado existe, el libro de cuentas de una organización es una prueba fundamental para demostrar las fechorías llevadas a cabo. Una información que se guarda bajo llave en una localización conocida por pocos. A nadie se le ocurriría, por ejemplo, guardarla en una base de datos expuesta a Internet sin control de acceso, ¿no?

El pasado mes de junio, mientras investigaban cuanto tarda una base de datos MongoDB en ser comprometida, el equipo de Kromtech Security detectó una de estas bastante curiosa. Sin control de acceso ni restricción por IP, se almacenaban en ella más de 150 mil tarjetas de crédito con toda la información requerida para usarlas, entre otros datos personales. Habían dado con una base de datos de "carders".

Análisis del funcionamiento del fraude. Obtenida de Kromtech.

Junto a las tarjetas de crédito, se encontraba información de varias cuentas de Facebook, con un punto común: todas hacían referencia a una página vietnamita de una supuesta herramienta para conseguir ventajas adicionales en juegos para móvil. Tirando de este hilo, fueron descubriendo que detrás de la base de datos había toda una operación de lavado de dinero.

El sistema estaba altamente automatizado. Los juegos que se utilizaban para lavar dinero eran principalmente Clash of Clans, Clan Royale y Marvel Contest of Champions, conocidos por tener un extenso mercado negro de mejoras. Los actores maliciosos registraban cuentas Apple fraudulentas a gran escala utilizando cuentas de correo también falsas. 

Una vez con las cuentas Apple creadas, cargaban tarjetas robadas hasta encontrar una valida con la que compraban recursos para los juegos mencionados, llegando incluso a balancear la carga entre varios dispositivos iPhone con jailbreak. Las mejoras después eran publicadas en sitios de compra-venta alternativos para su venta.

Portal de compra-venta de recursos g2g.com

Para aplicarlas, se hace abuso de la funcionalidad de estos juegos para enlazar una misma ID de Supercell con diferentes IDs de Apple y Android. Los usuarios cedían sus cuentas Apple a los estafadores por un periodo de tiempo y estos las enlazaban con las cuentas Supercell donde almacenaban los recursos del juego, devolviéndoselas con recursos recién comprados usando su colección de tarjetas robadas.

Supercell prohíbe explicitamente la compra de recursos a terceras partes, siendo castigada con la cancelación de los recursos o incluso de la cuenta. Sin embargo, es sencillo para los jugadores y estafadores comprarlos y transferirlos sin levantar sospechas, incluso de forma automática, lo que permiten que el mercado alrededor de esta actividad prolifere.

Igualmente, el equipo señala que muchas de las tarjetas usadas no tenían información valida pero habían sido aceptadas por Apple, lo que apunta a una política bastante permisiva a la hora de aceptar tarjetas de crédito. 

Francisco López

flopez@hispasec.com

@zisk0

Más información:

Digital Laundry: how credit card thieves use free-to-play apps to launder their ill-gotten gains:

https://kromtech.com/blog/security-center/digital-laundry

MongoDB, el nuevo filón del Ransomware

Es posible que el Ransomware afecte a cientos de miles de usuarios de "a pie" o incluso cifre carpetas compartidas de redes corporativas donde la pérdida de ciertos archivos podría suponer una sobredosis de ibuprofeno a los sysadmins. Pero eso, económicamente, podemos suponer que no reporta un gran beneficio al filibusterismo digital. 

El lucro está realmente donde se encuentran los dineros, los cuartos, la pasta, el peculio, en definitiva, la riqueza. ¿Porqué cifrar las fotos del último verano o los informes TPS cuando puedes paralizar el departamento de ventas de una multinacional? ¿y donde de encuentra el corazón de todo ese andamiaje digital que sustenta el aparato de negocio? Las Bases de Datos amigo, las bases de datos. Ahí es donde tenemos el tesoro de la corona, años enteros de amasamiento binario, transacciones, datos, cifras, etc, etc, etc.

Así que, con la cantinela de costumbre, se traza el rumbo, se izan las velas y se dan guiñas a la crujía hasta enfocar un buen puerto abierto y tranquilo, ahí tenemos un 27017. Abrimos los cartapacios y consultamos las cartas: MongoDB. Ahora toca cargar las piezas con un buen amasijo de contraseñas por defecto y "bum", tras unas pocas andanas la plaza se rinde y capitula. Victoria fácil y desmeritoria. A los pies, gigas y gigas de petróleo eléctrico, el botín es nuestro.

No hace falta ni cifrar. Ahora se extrae la base de datos cuidadosamente, trozo a trozo. Luego se borra por completo y se deja una nota de rescate: 1000 maravedíes a cambio de esta fabulosa fortuna. Suyo, el cybercrooker de turno. No pasa mucho tiempo cuando empiezan a sonar los timbres de los teléfonos del departamento técnico. No pasa mucho tiempo más cuando después de un reseteo la cosa sigue sin funcionar. Algo falla, los datos ya no están ahí.

Bases de datos secuestradas asomando en Shodan

Estos ataques se vienen produciendo desde enero de este año, cuando se reportó el secuestro progresivo de miles de bases de datos. No solo MongoDB, por supuesto, pero era significativo su porcentaje, que alcanzaba hasta un 56% del total de secuestros a manos de varios grupos organizados. Nada de zero-days, ni sofisticadas APT, palos y piedras: basta con probar un juego de contraseñas y clack, acceso permitido. Incluso algunas instalaciones ni tan siquiera poseían contraseña.

Poco a poco, los grupos organizados dieron cuenta de este nuevo filón y se fueron sumando a la fiesta, soltando automatismos que iban escudriñando la red en busca de objetivos. Una auténtica cadena de producción, donde todo es un proceso, desde la infección o ataque al propio pago. Podríamos hablar ya de un perfecto RaaS (Ransomware as a Service), la industrialización del pecado por omisión o desidia de algunas organizaciones, que movidos por la fiebre del low-cost reducen la planificación y despliegue al mínimo imprescindible.

Un trabajo que merece la pena atender, es el de los investigadores Víctor Gevers, Niall Merrigan y Dylan Kats. Se han dedicado a recopilar información sobre los ataques, transacciones, grupos involucrados, campañas, etc. Toda la información está disponible públicamente en una hoja de cálculo. En ella puede observarse una curiosa anotación "These are actors that have been found deleting databases without exfiltrating the data first. This means that they are unable to produce data even if ransom is paid". Es decir, que incluso pagando no hay datos de vuelta; algo que se observa con toda variante de Ransomware.

En este sentido, otro de los puntos reseñables en los datos acumulados es que los delincuentes "hacen caja". Si observamos las transacciones en bitcoins vemos flujos de pequeñas cantidades que han sido abonadas en un intento, muchas veces en vano, de recuperar los datos sustraídos. Esto podría haber hecho que los ataques repunten y que últimamente se observe una nueva oleada de secuestros.

Con el Internet de las cosas que parecen no importarnos lo más mínimo se han creado lucrativas botnets para extorsionar mediante denegaciones de servicio selectivas. Se han levantado granjas clandestinas de criptominado y ahora tenemos servicios publicados a la ligera, con datos valiosos protegidos por contraseñas (donde las hay) triviales. 

Justo aquí, en este bloque, tradicionalmente hemos puesto una serie de medidas para paliar semejantes agujeros. ¿Pero vale la pena el esfuerzo? ¿De verdad le interesa la seguridad a alguien que deja expuesto los datos del negocio a una distancia de 8 caracteres? Yo asumo que no. El mal rato dura lo que tardan los datos en reconstruirse o los seguros en responder o incluso puede que ese golpe termine por cargarse el negocio y apaga y vámonos, quien sabe. 

MongoDB ha publicado una guía de prácticas seguras y una checklist preciosa, algo es algo. Un solo administrador competente echa una mañana en bastionizar con esos documentos una instalación de MongoDB, pero claro eso ya sale caro, ya no es low-cost, ni un veterano ni una mañana en "perder" el tiempo arreglando algo que "funciona"...

David García

@dgn1729

dgarcia@hispasec.com

Más información

Massive Wave of MongoDB Ransom Attacks Makes 26,000 New Victims

https://www.bleepingcomputer.com/news/security/massive-wave-of-mongodb-ransom-attacks-makes-26-000-new-victims/

How to Avoid a Malicious Attack That Ransoms Your Data

https://www.mongodb.com/blog/post/how-to-avoid-a-malicious-attack-that-ransoms-your-data

Intrusión en la red de la compañía MongoHQ

MongoHQ, la firma que da soporte profesional y alojamiento a usuarios de la base de datos MongoDB, ha informado en un comunicado que han detectado una intrusión en sus servidores. Según la compañía los atacantes podrían haber accedido a la base de datos de cuentas de usuarios.

MongoDB es una base de datos NoSQL, programada en C++ y licenciada bajo GNU AGPL. MongoDB fue publicada por primera vez en 2009, su uso se encuentra bastante extendido en la industria.

El pasado día 28 de octubre, los técnicos del equipo de operaciones de MongoHQ detectaron un acceso no autorizado a una aplicación interna orientada al soporte. Los atacantes habían usado unas credenciales provenientes de una cuenta comprometida. La aplicación interna permite acceder a información de cuentas, lista de bases de datos, direcciones de correo electrónico y las credenciales de los clientes en forma de hash utilizando el algoritmo bcrypt.

El problema es que dicha aplicación de soporte permite a cualquier técnico autenticado acceder al portal principal de los clientes con los mismos privilegios que estos para realizar tareas de soporte. En ese portal el cliente puede consultar sus datos almacenados y administrar sus instancias privadas de MongoDB.

Los responsables dan por hecho que los atacantes han tenido acceso a los datos de conexión de los clientes y a través de la auditoría que están llevando a cabo han detectado accesos a los datos almacenados utilizando las credenciales que guardaban. Es decir, que ciertas bases de datos de sus clientes han sido volcadas (se desconoce si parcial o totalmente) por los intrusos.

La respuesta de MongoHQ fue detener los servicios implicados y proceder a efectuar un análisis forense y auditoría. Se han desactivado las cuentas de los técnicos y rehabilitado tras cambiar sus credenciales. También se han puesto en contacto con los clientes afectados directamente, al menos sobre los que tienen evidencia de que sus datos han sido accedidos.

Sobre las medidas que van a imponer a partir de ahora, anuncian la imposición de un sistema de doble autenticación, acceso exclusivo a través de VPN y la dotación de permisos graduales basados en el mínimo privilegio necesario. Además planean cifrar el contenido importante que administren las aplicaciones.

Resulta evidente que este anuncio de medidas es equivalente a decir que carecían de ellas. No es fácilmente digerible que una arquitectura que almacena datos, supongamos muy valiosos, de terceros no tuviera ya una rigidez y fiabilidad desde el punto de vista de la seguridad. Sorprende sobre todo el último punto, que no tuvieran establecido un sistema de credenciales basados en el mínimo privilegio, algo básico.

Otro de los puntos reseñables en el comunicado es la invalidación de credenciales de Amazon Web Services que sus clientes tenían almacenadas en MongoHQ. Dichas cuentas eran usadas para realizar copias de respaldo en la infraestructura S3 de Amazon.

Por supuesto, como primera medida a tomar, aconsejan cambiar las credenciales de acceso a los servicios.

MongoHQ irá comunicando, a medida que aparezcan nuevos hallazgos, información sobre el incidente.

Más información:

MongoHQ Security Breach

http://security.mongohq.com/notice

bcrypt

http://en.wikipedia.org/wiki/Bcrypt

David García

dgarcia@hispasec.com

Twitter: @dgn1729

Vulnerabilidad en MongoDB permite la ejecución de código arbitrario en el servidor

El investigador de seguridad con sobrenombre de agixid, parte de la empresa franco-suiza SCRT, ha publicado una vulnerabilidad en el sistema de bases de datos MongoDB. Esta permite la ejecución de código remoto, manipulando el puntero utilizado por el método nativeHelper para ejecutar comandos del sistema. Ya ha sido publicado un exploit para el fallo.

MongoDB es un sistema de bases de datos no relacional de código abierto desarrollado por la compañía 10gen. Es una base de datos documental, esto es, que almacena sus datos de forma estructurada. En concreto, utiliza un formato extendido de JSON, llamado BSON, propio de este sistema. Actualmente es el sistema NoSQL más popular, contando con versiones para varios sistemas operativos, y siendo utilizado en los back-ends de empresas como SAP, SourceForge o Foursquare.

La investigación de agixid pretendía ahondar en los entresijos del método 'run' del sistema para tratar de ejecutar código en el servidor. Este método ejecuta en una shell el comando que se le pase como parámetro (por ejemplo, ls en sistemas Linux). Sin embargo, este comando es sólo valido en el cliente y no permite ejecutar código a través de consultas al servidor.

Agidix descubrió que el método run simplemente realiza una llamada a nativeHelper, una función del motor JavaScript SpiderMonkey de Mozilla, pasando como parámetros un vector asociativo (run_) y el comando a ejecutar. Este vector run_ no está definido en el lado del servidor, pero sí se puede utilizar directamente un vector de la forma {"x":0x01234}, por ejemplo, para suplirlo. El valor asociado a x apunta a la dirección de memoria de una función JavaScript, y que será ejecutada sin ninguna comprobación a través de un método de tipo NativeFunction. Al poder controlar el puntero a la función que se ejecuta, se puede ejecutar código arbitrario en el servidor.

La vulnerabilidad, con identificador CVE-2013-1892, ha sido probada en la versión 2.2.3 de MongoDB para sistemas de 32 bits. La rama 2.4 no se ve afectada, ya que se ha cambiado el motor JavaScript a V8, motor de Google, que no es vulnerable. Sin embargo, la última versión de la rama 2.2 (2.2.4) fue publicada el día 26 de marzo sin ninguna alusión a la vulnerabilidad. Por otro lado, ya se ha publicado un módulo en Metasploit para su explotación.

Más información:

mongodb – SSJI to RCE

http://blog.scrt.ch/2013/03/24/mongodb-0-day-ssji-to-rce/

  

Francisco López

flopez@hispasec.com