viernes, octubre 24, 2014

Dos casos reales de robo de dinero con suplantación de identidad de ayer mismo

Durante el día de ayer me pidieron asesoramiento para un par de incidentes que me resultaron curiosos por el modus operandi de los estafadores. Casos en los que en lugar de buscar una forma burda y rápida de robar el dinero, eligieron una manera sigilosa y quirúrgica para hacerlo.

Figura 1: Dos casos reales de robo de dinero con suplantación de identidad

Os los cuento por aquí, para que veáis que esto no es películas y que te puede pasar a ti o a tu empresa también y cómo han aprovechado todos los detalles posibles para pertrechar sus ataques.

El caso de la transferencia bancaria de 19.000 € por e-mail

El primero de los casos es un ataque contra un individuo que cuenta con unos ahorros en su cuenta corriente. Esta persona lleva trabajando tiempo con la misma sucursal bancaria y por tanto ha llegado a un nivel de confianza tal como para mantener una correspondencia habitual por medio del correo electrónico pidiendo pequeños pagos, movimientos e información de su cuenta. La relación es fluida, y durarera en el tiempo, así que esas acciones se acaban llevando a cabo sin una confirmación robusta de todas y cada una de las órdenes que se realizan. De vez en cuando hablan por teléfono así que no hay problema en la confirmación. 

De repente, durante el día de ayer, la persona recibió un aviso desde el proveedor de su cuenta de correo electrónico (Google) informándole de que se había producido una conexión a su identidad desde una dirección no habitual, que si era él no pasaba nada, pero que si no era él que la bloqueara y cambiara la contraseña. Por supuesto, tras verificar que el correo electrónico era original y no un caso de suplantación de identidad mediante una técnica de spoofing de e-mail para hacerle un ataque de phishing se preocupó e hizo lo que le pidieron. Al mismo tiempo recibió una llamada telefónica del banco.

La persona de la sucursal que habitualmente le realiza las acciones le había llamado por teléfono para confirmar si los 19.000 € que iba a transferir al extranjero tenían algún motivo concreto, ya que le parecía muy extraño que una orden de semejante cantidad se hiciera por correo electrónico. No hay ni que decir que él no había hecho la petición de la transferencia, pero la persona que lo había pedido lo había escrito desde su correo, imitando la forma de escribir suya. Como el banco por seguridad tenía la cuenta bloqueada para transferencias internacionales, el atacante había tenido primero que mantener una correspondencia para pedir que cambiaran esa restricción, para después pedir la orden de transferencia de los ahorros de la víctima a un país extranjero.

Evidentemente, la alerta en el último momento de la empleada de la sucursal, y el que pudiera hacerse con él por teléfono a tiempo para confirmar todo, pararon en última instancia el que se llevaran el dinero de su cuenta. El atacante había robado su cuenta de correo electrónico, había estado leyéndose los correos uno a uno y conociendo el entorno de su vida personal a través de su vida digital, para preparar el mejor ataque posible, y cuando lo encontró, lo hizo de manera bien pensada y aprovechando todas y cada una de las debilidades que pudo.

Le robó una cuenta de su correo personal al que se conectaba porque no tenía un segundo factor de autenticación asociado. Eso implica que o bien tenía el equipo infectado con algún troyano para robar identidad o que había realizado alguna conexión a una red de forma insegura. Después se aprovecho de que la persona había, conscientemente, rebajado los niveles de seguridad al utilizar el correo electrónico para comunicarse con su banco y solicitar acciones sobre sus cuentas. 

El caso del cobro de los servicios que se paga a un tercero

El segundo de los incidentes del día de ayer no acaba tan bien. En este caso, una empresa A trabaja para otra empresa B. Dicha empresa B debe realizar los pagos para la empresa A en una fecha que denominaremos el día D. Pocos días antes del día D, uno de los responsables del proyecto de la empresa A se va de vacaciones unos días activando el famoso OoO (Out of Office) informando del hecho, pero como había dejado todas las gestiones realizadas, solo cabe esperar que el día D llegue el pago de la empresa B hacia las cuentas de la empresa A.

Llegado el día D, la empresa A constata que no ha recibido el pago de B, y tras regresar el responsable del proyecto de sus vacaciones contacta con la empresa B para reclamarlo. La empresa B, en ese momento responde que realizó el pago en tiempo y forma a la cuenta que le había dicho el responsable de la empresa, enviándoles además el justificante de transferencia.

Cuando revisan el justificante, se percatan de que la transferencia se ha hecho a una cuenta de otro país, que nada tiene que ver con ellos y les dicen que se han equivocado. Sin embargo, la empresa B les envía los correos electrónicos enviados por el responsable de A solicitando el pago del proyecto a esa cuenta, que por supuesto es de un atacante que se ha llevado el dinero.

No he tenido acceso a esos correos electrónicos, pero está claro que el atacante tiene controlada la empresa A o la empresa B. Si los correos electrónicos son un spoofing de las cabeceras de correo de la empresa A, entonces conocía el proyecto (ya fuera por una fuga de información de A o de B) y se la ha colado a la empresa B a la que ha engañado, por supuesto, en ese caso, el que la política SPF de la empresa A no fuera lo suficientemente robusta habría ayudado a esa suplantación, lo que le permitiría a la empresa B abrir un debate sobre si es responsable en algún término al no haber endurecido sus políticas anti-spoofing.

Si por el contrario, el correo ha salido de los servidores de correo electrónico de la empresa A, entonces parece claro que el engaño y robo se lo han hecho a la empresa A, pero por otro lado lo cierto es que nunca se realizó el pago de los servicios desde la empresa B a la empresa A, por lo que al fiarse de un medio como el correo electrónico para confirmar un cambio de cuenta de pago es también responsabilidad de la empresa B.

Lo que sí que está claro es que el atacante se ha llevado todo el dinero por conocer todos los detalles del proyecto, que el responsable estaba fuera de vacaciones y que el correo electrónico era el medio que estaban usando las dos empresas para comunicarse en detalles tan importantes. Quién se quedará sin el dinero está aún sin resolver.

Una reflexión final

Como podéis ver, los atacantes hacen ataques dirigidos mucho más elaborados, como los que muchos creen aún que solo son de película, sumando para ellos pequeñas debilidades de seguridad en los procesos de gestión de las identidades digitales personales y empresariales. Ten mucho cuidado y si quieres saber un poco más de estos casos, te recomiendo la lectura del libro de Fraude Online.

Saludos Malignos!

jueves, octubre 23, 2014

WordPress: SQL Injection Bug en Scarcity Builder Plugin

Hacer unas semanas, un joven investigador de seguridad venezolano llamado KelvinSecurity se puso en contacto conmigo para contarme que se había topado con un bug de SQL Injection en un plugin para WordPress llamado Scarcity Builder, que se utiliza para generar contadores de marketing en sitios web creados sobre WordPress con el objetivo de que generen presión en los visitantes para forzar una acción. Cosas de la gente de marketing, ya sabéis.

Figura 1: Bug de SQL Injection en Scarcity Builder para WordPress

El caso es que el bug era un 0day porque incluso la web del propio fabricante era vulnerable a este fallo, así que decidimos ponernos en contacto con los desarrolladores y se abrió un ticket de soporte. La empresa que está detrás de él, llamada Digital KickStart, solucionó el fallo y respondió con una nueva actualización del mismo, tal y como podéis ver en la siguiente imagen.

Figura 2: Confirmación de que han solucionado el bug en la versión 2.2.10

Sin embargo, el bug, que es un SQL Injection de libro y que se encuentra fácilmente usando Havij o cualquier otro escanner de vulnerabilidades web, está aún por desgracia en muchas páginas web con WordPress, ya que la empresa no ha hecho un Security Advisory o similar.

Figura 3: Explotación del bug en un WordPress vulnerable con Havij

El SQL Injection se encuentra en concreto en: 
wp-content/plugins/scarcitybuilder/shortcode/index.php?edit=
Por supuesto, con un SQL Injection como esté, se puede extraer toda la información de WordPress, incluidos, usuarios, contraseñas e información confidencial que se encuentre guardada en la base de datos o accesible desde ella en el servidor.

Figura 4: Extracción de información con el bug en el plugin Scarcity Builder

El plugin no es demasiado común - seguramente porque es un plugin de pago - y solo aparecen algo más de 800 sitios indexados en Google que lo tengan funcionando, pero el bug es tan fácil de localizar y explotar de forma automatizada que espero que hagan un aviso directo a los clientes haciéndoles entender el riesgo de no actualizar a esta versión.

Figura 5: Número de WordPress con este plugin instalado, localizados vía Google

Si tienes WordPress con este plugin, actualízalo ya. Si tienes clientes con WordPress, avísales de este riesgo de seguridad para que tomen medidas urgentes y, a ser posible, que tengan procedimientos y herramientas para actualizar automáticamente los plugins. No olvides que tienes herramientas como WPHardening para fortificar WordPress, y que tú además puedes puedes fortificar WordPress con configuraciones más seguras.

Saludos Malignos!

Entradas populares