El
método de propagación de los phishings, en su gran mayoría y casi por
definición, sigue siendo el mismo desde hace bastantes años, a través de email.
Hace unos días recibimos uno del Banco Santander Chile en el correo del
laboratorio. El email, en su conjunto, estaba bien construido, con un lenguaje
correcto y sencillo, que nos indicaba que nuestra "Clave 3.0" estaba bloqueada porque aún no se había verificado
y nos invitaba a entrar para verificar los datos a través de un enlace.
El phishing que nos mostraba al
pulsar en el enlace del correo se encontraba en un sitio vulnerado, cuyo tiempo
de carga era un poco largo, por lo tanto esto nos hizo sospechar que el
contenido no estaba alojado realmente en el mismo servidor, o que algo raro
sucedía, como explicaremos más adelante.
A través de una escalada de
directorios, nos encontramos que el servidor, por defecto, listaba el contenido
de sus carpetas, y además, nos encontramos un archivo zip llamado "www.santander.cl.zip".
Los atacantes suelen subir el kit de phishing comprimido a la página vulnerada
y posteriormente extraerlo para tener el phishing listo. En este caso, olvidaron
borrar el archivo zip después de extraerlo.
Teniendo ya el zip en nuestro
poder nos permite analizarlo al detalle. Este tipo de oportunidades no se deben
dejar pasar, pues suponen una valiosa fuente de información para nuestro
trabajo de antifraude en el laboratorio.
Al descargarlo y descomprimirlo,
observamos que como suponíamos, eran todos los archivos del phishing, así que
procedimos a reproducirlo en local para estudiar su funcionamiento, que por su
interés mostramos a continuación.
En primer lugar vamos a mostrar
el funcionamiento desde el punto de vista del usuario/cliente afectado y
posteriormente cómo el phishing almacena y utiliza los datos que le
proporcionamos.
Al acceder a la página, se carga
una copia falsa de la portada principal del banco. En ella, como buenos
usuarios confiados, procedemos a introducir el RUT (número de identificación
nacional para los habitantes de Chile) y la clave:
En este punto el phishing hace tres comprobaciones. En primer lugar el RUT y la clave deben tener un formato
válido. Además, comprueba contra la página real del banco (por supuesto, en
segundo plano), que las credenciales son correctas. En caso de que el RUT y
clave tengan el "formato" adecuado pero no
seamos clientes del banco (o nos hayamos equivocado en alguno de ellos), nos
mostrará la siguiente pantalla de error, pidiéndonos que accedamos 15 minutos
después, achacando un error en sus sistemas (y además con faltas ortográficas).
En caso contrario, es decir,
somos clientes y nuestro RUT y clave son correctos, pasa a una pantalla en la que
solicita la tarjeta de coordenadas completa, que además plantea de manera
desorganizada, para parecer más real. Hay dos pequeños detalles en esta
pantalla, y es que el phishing ha conseguido ya obtener el nombre y apellido
del cliente y el número identificativo de la tarjeta de coordenadas (señalados
en verde).
Una vez se rellenan todos los
datos, reenvía al usuario a la página real del banco para levantar menos
sospechas. En caso de que no se rellenaran todas las casillas o alguna de ellas
no tuviera el formato correcto (2 dígitos numéricos), avisaría con un error y
se quedaría a la espera para que se corrija.
Este es el proceso "visible" para el usuario, pero vamos a
estudiar el código que hay detrás de esto.
Como se realiza el trabajo "sucio"
En primer lugar, el atacante hace
uso en todo momento de la librería "cURL"
de PHP. Esta facilita la realización de conexión HTTP sobre otro servidor,
siendo capaz de mantener las sesiones y cookies, para facilitar bastante el
trabajo.
En la primera pantalla, carga el
contenido de la página original del banco "http://www.santander.cl/" haciendo uso de cURL. Esto hace que el tiempo de carga aumente, que fue una de
las cuestiones que nos llamó la atención.
En el primer bloque de código
hace la petición a la página real del banco y descarga el contenido en la
variable "$html".
En el segundo bloque reemplaza las rutas relativas por rutas absolutas, para
que se carguen correctamente las imágenes y demás recursos de la web (JS, CSS)
y que además los enlaces sean correctos. En el último bloque modifica la
dirección de envío del formulario de identificación, escribiendo una dirección
que mantiene bajo su control "?STP=login".
Posteriormente, para comprobar si
el RUT y la clave introducidas por el usuario son correctas, vuelve a hacer una
petición con cURL sobre la dirección real "https://www.santander.cl/transa/cruce.asp".
En caso afirmativo continúa haciendo sendas peticiones sobre
"https://www.santander.cl/transa/segmentos/Menu/views/sections/vsTS.asp?sectionCode=TC1" y "https://www.santander.cl/transa/mensajeria2/pivote_superclave.asp" para obtener el nombre y apellido del cliente y número identificativo de la
tarjeta de coordenadas respectivamente.
Toda esta información la mantiene
guardada en la sesión de PHP para posteriormente usarla en el proceso de
solicitud de la tarjeta de coordenadas, como pudimos ver en la tercera imagen.
Todo con objeto de darle más credibilidad al phishing.
Pasamos al momento de generar la
página en la que nos solicita la tarjeta de coordenadas.
Con la función GenerateCard()
genera un array asociativo con todas las coordenadas y posteriormente, con el
código remarcado, extrae coordenadas pseudo-aletorias del array y genera la
tabla HTML para la petición de coordenadas.
Como hemos mostrado en la imagen
anterior, las solicita de manera desordenada y además tiene 2 métodos de
control para asegurarse, en cierto modo, que el usuario no se equivoca al
introducirlas. El primero de los métodos es que el usuario debe introducir
todas las coordenadas, no puede dejar ninguna en blanco. El segundo es que cada
una de las coordenadas deben ser numéricas y tener al menos 2 dígitos. LONGCOORDS
es una constante que está fijada a 2 en la cabecera del archivo (no se aprecia
en la imagen).
Para terminar, guarda todo esto
en un fichero de logs ("Logsdb.txt"),
definido en la constante DB_FILE) en el servidor y además, lo manda por correo
usando el servidor SMTP configurado en el servidor vulnerado.
La manera de guardar este archivo
de logs también es bastante curiosa, pues si lo guardara en texto plano,
cualquiera que conociera la ruta del archivo podría abrir el archivo "Logsdb.txt" y ya tendría el "trabajo hecho". Para ello, antes de
guardar la información en el registro, la cifra.
Para comenzar la función de
cifrado utiliza la variable $string que son los datos robados y la clave $key,
que está definida en el código.
- La línea 5 lo único que hace es extraer cada uno de los caracteres.
- La linea 6 extrae un carácter de la clave siguiendo este patrón: si el bucle sólo contuviera esta línea de código y la clave fuera "1234", nos generaría como resultado la cadena "412341234...", con la misma longitud que el texto de entrada.
- La línea 7 es la que en realidad hace el cifrado. Realiza una SUMA del valor en decimal de ambos caracteres (el del texto plano y el correspondiente de la clave) y después lo vuelve a transformar en carácter.
- La línea 8 concatena todos estos caracteres en la variable "$result".
- Para finalizar la función, devuelve el contenido de la variable "result", pero antes lo codifica en base64, ya que los caracteres generados pueden no quedar en el rango ASCII y generar problemas al almacenarlos en disco.
El cifrado es bastante débil, con
un pequeño análisis estadístico se podría extraer el texto en claro. Basa la
fortaleza del cifrado en lo que se conoce como "seguridad por oscuridad", es decir, se supone que nadie conoce
el método excepto él.
Por comodidad, el atacante ha
creado la página "index.php?STP=logers"
en la que introduciendo un usuario y contraseña, que tiene previamente definidos
en el código, se muestra todo el contenido de los logs en texto plano. Para
ello utiliza el siguiente código, junto con una captura de los logs (obviamente
no son datos reales):
En ella comprueba si el usuario
ha introducido el usuario y la contraseña definidas en el código, si es así,
muestra el contenido de todos los logs que tiene en el archivo, no sin antes
descifrarlos con el método "Desofuscar()". Si no se introduce el usuario y la
contraseña o son incorrectos, devuelve un formulario para hacer login.
Y para finalizar, vamos a
explicar cómo funciona el método "Desofuscar()", aunque en realidad hace
lo mismo que "Ofuscar()",
pero a la inversa.
- En la línea 4 decodifica el texto que tenía almacenado en base64.
- En la línea 6 extrae carácter a carácter de la cadena cifrada.
- En la línea 7 extrae el carácter correspondiente de la clave, exactamente igual que el método de cifrado.
- La línea 8 es la que se encarga realmente de descifrar. Cuando se cifraba se realizaba una suma de los valores en decimal de los caracteres, pues ahora se tiene que realizar la resta del valor almacenado menos la clave. Con ello obtenemos el carácter original.
- En la línea 10 concatena los resultados que tenía y cuando termina la cadena completa, la devuelve.
En resumen, el flujo de trabajo del phishing se resume en la siguiente imagen.
Conclusiones
Después de este pequeño estudio
podemos sacar algunas conclusiones:
El objetivo final es claro,
recoger la máxima información del cliente para posteriormente poder realizar
transacciones ilegítimas. Las novedades que han llamado la atención a
nuestro departamento antifraude son, en primer lugar, la validación contra la
página web del banco, si bien es cierto que no es el primer caso, este banco lo
hace un poco más fácil para el atacante, ya que no usa sistemas como el "CSRF token" (por ejemplo), lo cuál
no elimina el riesgo, pero complicaría un poco el proceso.
Por otro lado, la forma de
engañar al usuario utilizando su nombre real y el número exacto de su tarjeta
de coordenadas. La mayoría de phishings que tratamos en nuestro departamento
antifraude a diario no se molestan en extraer tanta información para
simplemente mostrarla al usuario. En algunas ocasiones simplemente, en lugar
del nombre, usan algo genérico como "Cargando...".
Y para terminar, la forma de
guardar la información de los usuarios (cifrada) es de lo más interesante. No
es un cifrado robusto, como ya hemos dicho anteriormente, pero también es
cierto que pocos "phishers"
se molestan en hacer esto, simplemente lo guardan en texto plano en algún
archivo con nombre extraño.
El código también tiene
referencias al sistema de autenticación por SMS, pero no hace uso de él. No
sabemos si es por un mal desarrollo o simplemente porque el atacante todavía no
han tenido usuarios reales para probarlo. Bien es cierto, que si finalmente se
implanta este método (a través de SMS), la recogida de datos del phishing sería
más compleja, lo que esperamos que alerte al usuario, porque se haría la transferencia
fraudulenta en el mismo momento en que el usuario está introduciendo los datos
en el phishing.
Antonio Sánchez
Buena entrada.. esperando por mas : )!
ResponderEliminarEste comentario ha sido eliminado por el autor.
ResponderEliminarMuy buen tema la verdad pero necesito las ideas principales
ResponderEliminarExcelente explicación.
ResponderEliminarThis article provides a detailed analysis of a recent phishing attempt, highlighting common tactics and technical aspects of cybercriminals' operations. It highlights the importance of constant vigilance, the attention to detail in collecting user information, weak data encryption, and the potential SMS authentication system. The article serves as a valuable resource for understanding cyber threats. mejor abogado de planificación patrimonial
ResponderEliminar