El concello de Cerdedo, 200.000 € y muchas dudas

26 de octubre de 2012 Por

No es raro, en los tiempos que corren, recibir continuos mensajes sobre las precauciones a tomar cuando accedemos a una web o recibimos un correo que pueden ser potencialmente falsos, hasta el punto de que el concepto de phishing es cotidiano para cualquiera que sea un usuario habitual de Internet. Bueno, es o debería ser. Tampoco resulta raro oír de vez en cuando que éste o aquél han sido estafados haciendo uso de esta técnica.

Lo que quizá no resulte tan familiar es que el robo ascienda a 200.000 euros, que se trate de una entidad pública como es el caso del concello de Cercedo y que salga en prensa. Aunque teorías conspirativas no han faltado al parecer en las redes sociales, vamos a centrarnos en lo que sabemos, que no es mucho y con el prisma distorsionador de la prensa generalista podemos afirmar que es todavía menos.

Resumiendo mucho, la cuestión es que el personal municipal intentó entrar el pasado lunes al portal de banca online y al no poder acceder, lo postergó al día siguiente, cuando descubrió que no quedaba ni un euro de los 200.000 € que debería haber en la cuenta. La investigación apunta a que el fraude fue realizado vía phishing, aunque no está claro. Déjenme exponer varias reflexiones en voz alta.

Lo primero con lo que nos encontramos es con el bloqueo de la cuenta bancaria. El artículo apunta a que a pesar (y gracias a que) el personal del concello no podía acceder a su cuenta, los ladrones tenían más tiempo para realizar las transferencias. Aunque como pueden imaginarse no conozco todos los servicios de banca electrónica de este país, voy a asumir por lógica que cuando una cuenta se bloquea, se bloquean (o deberían hacerlo) todas las operaciones sobre ella, o al menos las que se pueden realizar desde el interfaz de usuario. En este caso, existen varias posibilidades.

La primera opción es el artículo es incorrecto o inexacto y que a pesar de lo que indica (“los estafadores dispusieron de unas veinte horas en las que realizaron transferencias de cantidades aleatorias a diferentes cuentas“) las transferencias sí se llevaron a cabo durante el lunes y el martes, pero en realidad se habían programado con anterioridad a ese lunes. Seguramente poca gente revisa las transferencias periódicas de su cuenta bancaria, y este podría ser el caso. Programo el sábado una transferencia bancaria y bloqueo la cuenta el día que se va a realizar, con lo que además se evita un potencial bloqueo de las funcionalidades del interfaz de usuario, pero seguramente no de aspectos como las transferencias periódicas ya que se presume que se programaron mientras la cuenta no estaba bloqueada. Sí, ya sé que son muchas conjeturas, pero es todo lo que tenemos.

La segunda opción es que el artículo es correcto y que a pesar de encontrarse la cuenta bloqueada, o bien continuaba siendo operativa para un usuario que permaneciese registrado en la página, o los ladrones habían conseguido “saltarse” ese bloqueo. En el primer caso se trataría de un problema de seguridad funcional y en el segundo un problema de seguridad lógica. Incluso en el primer caso (la cuenta bloqueada es operativa si estabas registrado antes del bloqueo), parece razonable considerar el control 11.5.6 de la norma 27001: “Deben usarse limitaciones en el tiempo de conexión en aplicaciones de alto riesgo para añadir seguridad adicional“, que en mi variada experiencia como usuario en portales de banca a distancia no he encontrado todavía implementado (si bien sí es habitual el 11.5.5: “Las sesiones interactivas deben terminar tras un periodo establecido de inactividad“). Lo cierto es que aun considerando el control 11.5.6, realizar una transferencia y conseguir bloquear la cuenta mediante intentos de acceso fallidos no puede llevar un tiempo demasiado grande. No obstante, el artículo habla de veinte horas y múltiples transferencias.

Lo que nos lleva al siguiente punto: la elección del momento.

Según plantea el artículo, “En la cuenta acababa de ingresar la Xunta cantidades importantes correspondientes a subvenciones que la Administración local esperaba desde hacía meses“. Vale, quizá sea casualidad que el fraude se realizase justo en ese momento, pero es cuanto menos sospechoso y puede despertar sospechas fundadas sobre la potencial existencia de un insider (el alcalde ha defendido a los empleados del concello: “Poño as mans no lume por todos os empleados“), bien en el entorno del concello o en cualquier entidad pública o privada que fuese conocedora de que dicha transferencia se iba a realizar. No conocemos el número de personas que estaban al tanto de la transferencia en cuestión, y podríamos estar hablando de decenas de personas o quizá incluso más de un centenar; dada la crisis actual, no es descartable que el concello estuviese esperando el dinero para abonar algunos retrasos a proveedores, a los que habría podido tranquilizar informando de que estaban esperando una transferencia. Al final, el resultado es que esta información podría haber sido casi de ámbito público.

Hemos de tener en cuenta que a pesar del momento concreto en el que se realiza el acto delictivo, siendo conocedor de que dicha transferencia se iba a realizar, el delincuente podría haber obtenido las credenciales semanas o meses antes y mantenerse a la espera; no sé si se habrán percatado, pero por la razón que sea las claves utilizadas habitualmente en banca a distancia, ya sea la de acceso o la que permite realizar operaciones (a través de claves o tarjetas de coordenadas), no es algo que suela cambiarse con frecuencia, sino más bien al contrario. Si este fuese el caso, no hablaríamos de una casualidad sino de un delito perfectamente planificado.

El siguiente aspecto a tener en cuenta es el método de acceso a las credenciales. Según el artículo, los primeros indicios apuntan hacia el phishing. No obstante, si atendemos a la “idoneidad” del momento, estaríamos ante un caso de phishing dirigido y no el típico correo masivo mal redactado, pobremente diseñado y cuya similitud con el original es fruto de la casualidad. Esto complica enormemente las posibilidades de que un usuario pudiera detectar que se trataba de una página fraudulenta ya que el nivel de “esmero” que los delincuentes podrían haber puesto en el diseño del ataque y el portal falso lo haría casi indetectable y más si había algún tipo de control sobre la infraestructura tecnológica del concello que permitiese modificar registros del DNS o similares.

Sin embargo, las claves de acceso suelen ser diferentes a las claves de operación, por lo que o bien los atacantes llevaban el tiempo suficiente escuchando para obtener dichas claves, o el usuario introdujo por ignorancia todas las claves que se le solicitaron. Tengamos también en cuenta que suplantar una web permite cierta “libertad” a la hora de solicitar información adicional, como por ejemplo podría ser el caso de una verificación “rutinaria” de comprobación de claves de operación.

Aunque vamos a ir acabando, hay diversos puntos adicionales a señalar.

Por un lado, está el hecho de que los delincuentes cambiasen la clave y el concello no se percatase, ya sea porque no existe esa alarma en Novagalicia o porque el destinatario no recibió dicha alarma: En el caso del Concello de Cerdedo, se presume que se pudo haber operado en un falso portal de Caixanova, facilitando a través de él las claves a los piratas. Estas fueron luego sustituidas por otras para ganar tiempo para vaciar la cuenta. Confieso que ignoro si este tipo de alarmas existen, pero es evidente que el cambio de clave de acceso debería remitir un SMS al teléfono especificado para ello, y ese teléfono estar especialmente protegido. De igual forma, la ejecución de una transferencia suele (ignoro si es el caso de Novagalicia) generar una alarma. Desgraciadamente, disponiendo de las claves de operación, es sencillo cambiar el teléfono, por lo que alguien que dispone de dichas claves puede evitar sin ninguna dificultad que el legítimo dueño de la cuenta reciba el SMS (pero no si este cambio también genera una alarma). Esto evidencia que con la existencia de determinadas alarmas, hay algunos fraudes que se evitarían y al mismo tiempo, que hay algunos datos y uno de ellos es el de alarma y notificación que no deberían poder ser configurados desde el portal de banca electrónica. A pesar del usuario.

Por otro lado, llama la atención que mientras el Concello no recuperó el control, los estafadores dispusieron de unas veinte horas en las que realizaron transferencias de cantidades aleatorias a diferentes cuentas. Quizá la transferencia de 200.000 € en dos días a diversas cuentas debería haber despertado cierta alarma en los sistemas de correlación bancaria y más tratándose de un organismo oficial. Cierto es que puede tratarse de una operativa legítima, pero podemos plantearnos si sería razonable que desde el banco alertasen sobre este tipo de situaciones.

Por último, me preocupa la frase “el personal municipal intentó acceder a la cuenta el lunes y no fue capaz. Creyendo que se trataba de algún problema informático, dejaron la operación para el martes“. Con ese planteamiento, no se me ocurren muchos problemas informáticos que desemboquen en un problema de acceso a un portal remoto de banca a distancia, por lo que cabe pensar que la formación en materia de seguridad informática del personal que manejaba estas cuentas no era todo lo buena que cabría esperar. También es razonable plantearse si el personal habría actuado igual si el acceso bloqueado hubiese sido el de acceso a sus cuentas bancarias personales. Lo cierto es que probablemente no; si nos ponemos nerviosos hasta cuando no podemos acceder a nuestro perfil de Facebook (hasta que nos damos cuenta de que las mayúsculas están activadas), ¿por qué nadie llamó al servicio de atención telefónica del banco? Si se pensó que era un problema informático, ¿por qué no se avisó al personal informático? Y si se avisó, ¿qué se hizo luego?

Evidentemente, no tenemos más que un artículo periodístico con múltiples lagunas y desconocemos hasta qué punto los hechos son tal y como se cuentan. Sin embargo, aun en ese caso y evitando caer en acusaciones infundadas, hay varias lecciones que podemos aprender. Pasen un buen fin de semana y no pierdan de vista sus ahorros, estén donde estén. Nos vemos de nuevo el lunes.

Malware humano – Protegiendo un servidor de los usuarios

10 de abril de 2012 Por

En el proceso de bastionado de un servidor, lo usual es protegerlo contra ataques procedentes de fuera de la máquina. Añadimos mil y una medidas, como las que comenté en un post anterior. Sin embargo, es muy habitual obviar la seguridad interna, porque se confía en exceso en los trabajadores y no se valora adecuadamente el impacto que puede producir un ataque accidental o intencionado. Ex-empleados cabreados que conservan credenciales de acceso, ingeniería social a personal interno, o manazas, son algunos ejemplos de estas muestras de “malware” tan particular, porque sinceramente, ¿quién no ha tenido ganas de hacer alguna vez un rm -rf /? ;)

Vamos a describir unas cuantas indicaciones para asegurar el servidor de estos posibles ataques internos.

1. Política de contraseñas

Este es un clásico imprescindible en cualquier tipo de autenticación a un servicio. Por ejemplo, una política que imponga una longitud mínima de contraseña, el uso de mayúsculas y números, y que no sea una palabra de diccionario. Por desgracia, no se usa tanto como se debería y permite que herramientas de bruteforcing como thc-hydra o John the Ripper sigan siendo muy útiles hoy día.

[Read more…]

Presentamos Mail Malware Trap

28 de noviembre de 2011 Por

A raíz de la entrada del correo electrónico donde se enlazaba a un troyano bancario, comencé a desarrollar un programita que tenía en mente desde hacía tiempo. Se trata de un recolector de Malware de correos electrónicos, encargado de acceder a distintas cuentas de correo, obtener el correo electrónico, almacenarlos en base de datos, y en caso de poseer adjuntos, ser analizados con la API de Virus total.

Veámoslo con más detenimiento. Primero será necesario disponer de una serie de sondas, correspondientes a cuentas de correo electrónico perteneciente en distintos servidores públicos como son Gmail, Yahoo o Hotmail, así como una serie de correos privados como por ejemplo el corporativo. Dichas cuentas de correo solo se usarán para recoger el correo que llegue a la bandeja de entrada y Spam. Para ello en ocasiones será necesario hacer filtros para trasladar el correo de la carpeta Spam a bandeja de entrada. Por ejemplo para Gmail sería necesario crearse un filtro de tipo texto con la siguiente entrada “is:spam” e indicar que debe enviarse como correo no leído a la bandeja de entrada. Con esto dispondremos de varias cuentas de correo distribuidas sobre distintos servidores de correo cuyo único objetivo es almacenar los correos de entrada.

Así, el recolector de malware lo que hará será conectarse a las cuentas para descargarse el correo nuevo y una vez obtenido insertará en una base de datos MySQL el correo descargado, indicando de qué servidor de correo lo ha descargado, a qué hora ha llegado, quién lo ha enviado, con qué asunto y con qué texto. Tanto el asunto como el texto se almacenarán en base64 en la base de datos.

El agente también comprobará si el correo electrónico tiene adjuntos. En caso de tener se descargará el adjunto conservando su nombre y lo almacenará en un árbol de sistema de ficheros compuesto por año, mes y identificador de correo de la base de datos. A su vez se insertará en la base de datos de que correo procede el adjunto, donde está almacenado, su comprobación MD5, si ha sido subido anteriormente a Virus Total y en caso afirmativo, se nos mostrará el resultado de los antivirus.

Veamos como funciona. En primer lugar será necesario disponer de una base de datos MySQL en el servidor donde instalemos el agente. Una vez dispongamos del MySQL será necesario crearnos el usuario y la base de datos mediante las siguientes órdenes:

$ mysql -u root -p
> CREATE database mailmalwaretrap;
> CREATE USER 'mailmalwaretrap'@'localhost' IDENTIFIED BY 'MiContrasenya';
> GRANT SELECT, INSERT, DELETE ON mailmalwaretrap.* TO 'mailmalwaretrap'@'localhost';

A continuación volcaremos el esquema de la base de datos, que podéis obtener de mailMalwareTrap.sql (los ficheros están al final del post):

$ mysql -u root -p < mailMalwareTrap.sql

Posteriormente configuraremos el agente, escribiendo en el fichero “mailMalwareTrap.conf” una línea por cada cuenta de correo que dispongamos, teniendo en cuenta que se deberá seguir el siguiente esquema “servidorCorreo|cuentaCorreo|contraseña”. Si por ejemplo nuestro servidor de correo es “pop.gmail.com”, la cuenta “lol@gmail.com” y contraseña “lolazo” el fichero será el siguiente:

# cat mailMalwareTrap.conf
pop.gmail.com|lol@gmail.com|lolazo

Para finalizar obtendremos el agente “mailMalwareTrap.py” donde será necesario tener instalado las dependencias de MySQL para Python.

Para el ejemplo que mostraremos usaremos una única cuenta de Gmail donde enviaremos desde otro servidor de correo adjuntando un fichero pdf que corresponde con el meterpreter. Una vez enviado ejecutaremos el script para que procese los correos nuevos. Se aconseja que se ponga el script en el crontab para que se ejecute cada hora:

$ mailMalwareTrap.py
Hay correos nuevos en "pop.gmail.com".
$

Si accedemos a la base de datos tabla “mail”, veremos que se ha insertado el nuevo correo con identificador “1”, correspondiente a la sonda “1”, que ha llegado a las 10:52 del 11 de Noviembre, cuyo asunto y texto están en base64 para evitar “sorpresas”:

Si analizamos la tabla malware veremos lo siguiente:

Malware con identificador 1, procedente del correo con ID 1, que se encuentra almacenado en “/tmp/result/2011_11/1/meterpreter.pdf”, que ya había subido con anterioridad a Virus Total, listado de los resultados de los distintos antivirus (la mayoría lo detectan), texto añadido por nosotros (en este caso está a NULL) y para finalizar la comprobación md5 del malware.

Si comprobamos a mano la comprobación md5 veremos que es la misma que hay almacenada en la base de datos:

$ md5sum /tmp/result/2011_11/1/meterpreter.pdf
062e7ecdc4a15f2f49cb5b2b09e5a4ea /tmp/result/2011_11/1/meterpreter.pdf
$

Como ven es una forma sencilla de tener un recolector de malware de las carpetas Spam de distintos servidores que permite analizar los riesgos que pueden acontecer en su infraestructura.

Como mejoras pendientes tengo dos puntos claramente identificados: el primero será buscar en el texto del correo posibles URLs y analizar con Virus Total si se tratan de URL con malas intenciones. Así mismo el segundo punto lo constituye una interfaz gráfica que permita gestionar los correos de forma más sencilla. Pero todo esto ya otro día ;)

Espero que les haya gustado la entrada, todo sea dicho, imagino que alguien habrá tenido la idea antes, pero sinceramente, yo creo que para aprender es necesario hacerlo uno mismo. Los ficheros pueden descargarlos directamente desde este enlace: mailMalwareTrap.rar.