Phineas Fisher (aka Hack Back!) se ha convertido en uno los casos más mediáticos de los últimos tiempos referente a la seguridad informática. Una persona que se atreve a hackear a empresas reconocidas del sector y organismos policiales, y además publicarlo en un tutorial o en el último caso con un videotutorial de cómo lo hizo. Se trata sin duda de un caso atípico. Vamos a ver si se podría haber evitado el ataque.

Nota: Por lógica y sentido común en este escrito no se van a dar ningún tipo de información sensible o personal que pudiera afectar a terceras personas. Se trata simplemente de analizar técnica y rigurosamente lo ocurrido. Analizo siempre los datos publicados por los medios de comunicación de manera pública. No hay datos privados de Mossos de Esquadra y este análisis es más bien para ayudar (analizar) igual que lo haría un periodista especializado. No es mi intención perjudicar a nadie.

Phineas Fisher (aka Hack Back!) se ha convertido en uno los casos más mediáticos de los últimos tiempos referente a la seguridad informática. Después de su primer hackeo público a la empresa de vigilancia Gamma Group, vino uno de los casos más sonados, con el hackeo de la popular empresa italiana Hacking Team, y el reciente robo de dinero de un banco para donarlo a un grupo Anti-ISIS y por último el hackeo al Campus del Sindicato de los Mossos, la Polícia autonómica de Catalunya.

Una de las cosas que más sorprendió fue la guía DIY (Do It Yourself)  que publicó Phineas Fisher sobre el cómo se hizo el hackeo a Hacking Team escrita originalmente en Español (luego traducida al inglésl por el mismo). ¿Será Phineas Fisher español o hispano hablante? La verdad es que hasta ese momento toda la información publicada por el mismo en Twitter, Reddit había siempre estado escrita en inglés. Sorprendió bastante que el texto original fuese en Español. Lo que da pistas sobre su posible lenguaje materno.

No es la primera vez que un hacker reivindica sus actos por Twitter, pero no es tan habitual que cree un usuario de Reddit, conceda entrevistas o escriba manuales y video-tutoriales reales de sus acciones. No es habitual atribuirse actos de hacking delictivos tan mediáticos como es el caso, y menos hacerlo por motivos sociales y/o políticos. Puede que el hackeo del Campus del SME no haya sido de una extraordinaria dificultad, pero si lo fue el de la empresa Hacking Team, bastante más complicado, laborioso y extenso. El propio autor comenta unas 100 horas de trabajo. Además de crear un 0day en un sistema embebido logrando un exploit remoto de root.

 ¿Porqué el atacante conocía la web del Sindicado de los Mossos d'Esquadra SME?

Cualquier persona que sea de Barcelona y tenga amigos o conocidos en los Mossos no tiene porque saber que existe un un sindicato de los Mossos. Y menos que tuvieran una plataforma de aprendizaje on-line (Campus). Es evidente que no es una web oficial de los Mossos de Esquadra, pero si una plataforma dónde participarán Mossos de Esquadra y no sé la relación oficial que mantienen con los Mossos.

Por lo que leo, actualmente, la policía catalana cuenta con cinco sindicatos: la Trisindical (una coalición de SME, SPC-ME y CAT-ME), además de SAP-UGT y USPAC.  Toni Castejón, es el Secretario General del sindicato de Mossos (SME).


Enlaces al vídeo tutorial:

• https://vimeo.com/167411059

Datos sensibles - información privada

Vamos a analizar los errores del Campus del SME (Sindicato Mossos de Esquadra)

Al tratarse una plataforma dónde  vamos a tener datos personales, privados y sensibles como son:

• Nombre y Apellidos
• DNI
• TIP (Tarjeta de Identificación Policial)
• Ayuntamiento
• Ciudad
• Dirección
• Código Postal
• E-mail
• Profesión
• Provincia
• Teléfono Fijo
• Teléfono Móvil
• País
• E-Mail
• Datos bancarios (IBAN, Nº de Cuenta) 
• Etc

Toda seguridad va a ser poca con los datos que manejas  y aunque no haya nada inhackeable, si tenemos que tomar algunas medidas de seguridad básicas, además se trata de miembros y fuerzas de policia.

Aunque el vídeo del ataque dura 39 minutos resulta evidente que el atacante ya conocía de antemano la estructura del Campus y sus puntos vulnerables.

El vector de ataque más normal hubiera sido WordPress o alguno de sus plugins. Es un software CMS muy popular y de sobras conocido y potencialmente vulnerable. Pero en este caso el vector de ataque fue un Campus Virtual no estándar, es decir ,escrito y desarrollado desde cero. Contrasta que no se usara el software por excelencia de Campus Virtual como es Moodle, que es la plataforma de aprendizaje por internet más usada en Catalunya. Prácticamente todas las universidades han ido migrando, incluso los que disponían de sus propios Campus, a la plataforma open source Moodle, adaptándola cada una a sus necesidades.

• Hosting: OVH.net VPS
• Servidor web + php: Apache + PHP 5.4.45
• Sistema Operativo: Debian
• Gestor Base de Datos: MySQL 5.5.49

La versiones aún no siendo las más actuales, no son per se vulnerables a un ataque si están correctamente configuradas.

Resumen errores del Campus del Sindicato de los Mossos de Esquadra

• SQL Injection (Variable ID del Campus sin ningún tipo de filtro o validación)
• Usuario MySQL DBA (Administrador con acceso a todas las bases de datos y tablas). Se deberían haber creado al menos dos usuarios del MySQL, uno con sólo permisos para el Campus (alumnos, afiliados) y el otro para el WordPress.
• MySQL con load data habilitado
• Usar cifrado débil (SHA y MD5) y sin SALT
• Contraseñas débiles (4 caracteres numéricos) Google requiere por ejemplo un mínimo 8 caracteres para cualquier contraseña.
• Permiso de subir documentos vía php sin validar el contenido de los documentos que se suben. No validan ni la extensión. Potencialmente muy peligroso.
• Usuario Apache (PHP) con permisos de shell (no hay entorno enjaulado, con chroot) y permite ejecutar comandos como mysqldump
• Usar la misma contraseña para el Campus y para el Twitter. Re-utilizar contraseñas es una mala práctica de seguridad.

Análisis técnico del vídeo del hackeo

SQL Injection

En este caso tenemos un Campus programado desde cero, hecho a a medida

Es evidente que antes de realizar el vídeo el atacante ya sabía de antemano que el Campus era vulnerable por inyección (SQL Injection). Una técnica o vulnerabilidad muy conocida y documentada. No vamos a entrar ahora en más detalles sobre dicha vulnerabilidad, pero si como podría habrse evitado.

Tal y como se puede ver en el vídeo el atacante utiliza la variable ID de los cursos para inyectar el código, concretamente en el fichero:

https://ww.sme-mossos.cat/campus/inc/inscribirse_prev.php

query("select * from cursos where id=".$_POST['id']);

Aquí vemos el código php del fichero inscribirse_prev.php, como la variable ID se obtiene directamente del formulario (GET/POST) sin ningún tipo de limpieza o validación. Es decir se recoge directamente la variable.

Basta con poner una simple comilla ' en el ID de la consulta para que falle.

Cualquier persona que haya estudiado programación web o haya hecho un curso de hacking ético, sabe que esta es una vulnerabilidad muy grave y básica. Existen desde hace muchos años explicaciones de todo tipo para al menos intentar evitar este tipo de ataques, y aunque según que filtros se pueden saltar y evadir, no filtrar directamente es una irresponsabilidad.

 Lo primero que enseñan o deberían enseñar es que si una variable es un ID debería validarse para que sólo sea numérica. Hay varias funciones en PHP para validar datos.

¿Cómo es posible que en el año 2016 ocurran este tipo de errores? En un fichero php modificado en el año 2015, demuestra que no es un Campus viejo.

Simplemente utiliza la herramienta SQLMap para automatizar y facilitar el ataque, pero se podría haber hecho manualmente con idéntico resultado o con otra herramienta similar como SQLNinja

SQLMap permite realizar de manera automática 6 técnicas de ataques:

• boolean-based blind
• time-based blind
• error-based
• UNION query
• stacked queries
• out-of-band

En este caso se elige UNION query, tal como se ve en el vídeo:

--technique=U

UNION query-based: se basa en añadir una consulta que empiece con UNION ALL SELECT, revelando información sensible solo si la aplicación web vuelca toda la información devuelta por la BD en la página web atacada.

El conseller de interior de Catalunya, el Señor Jordi Jané, dijo que el ataque había sido muy sofisticado, pero cuando vemos en el vídeo vemos que no lo ha sido tanto. No es mi intención desacreditar sus declaraciones, pero estarán de acuerdo conmigo cualquier profesional de la seguridad informática que el ataque era viable.

Usuario MySQL es DBA

De nuevo usando la herramienta SQLMap comprueba si el usuario que consulta la base de datos es DBA

--is-dba

Devuelve:

current user is DBA: True

El administrador de bases de datos (también conocido como DBA, en inglés database administrator) es un usuario que tiene permisos sobre todas las Bases de Datos con sus respectivas tablas.

Es una medida muy frecuente de seguridad crear un usuario de MySQL sin permisos (sin ningún permiso) y luego asignar a ese usuario permisos específicos a una base de datos con sus respectivas tablas usando GRANT

mysql> CREATE USER 'custom'@'localhost' IDENTIFIED BY 'obscure';
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
    ->     ON bankaccount.*
    ->     TO 'custom'@'localhost';

http://dev.mysql.com/doc/refman/5.7/en/adding-users.html

Sólo tiene que usar el parámetro sql-shell con SQLMap

--sql-shell

De esta manera el atacante obtuvo acceso inmediato a todas las bases de datos, de la web (WordPress) y del Campus.

MySQL con LOAD DATA infile/outfile habilitado

¿Cómo pudo el atacante obtener y leer los ficheros del DocumentRoot del Campus y de la web Wordpress a través del MySQL?

Con LOAD DATA INFILE y/o SELECT ... INTO OUTFILE

Por defecto MySQL incluye el parámetro LOAD DATA (LOAD DATA LOCAL) habilitado que permite leer ficheros:

• http://dev.mysql.com/doc/refman/5.7/en/load-data.html
• http://dev.mysql.com/doc/refman/5.7/en/load-data-local.html

Para evitarlo debemos añadir en el fichero de configuración my.cnf la entrada:

local-infile=0

De esta manera obtendremos el error al intentar leer ficheros a través de MySQL:

ERROR 1148: The used command is not allowed with this MySQL version

El atacante primero intenta subir la webshell Weevely al directorio uploads (una carpeta con probables permisos de escritura 777) pero el usuario de MySQL no tiene permisos para ello

Pero con la opción de SQLMap file-read para analizar el código fuente:

 --file-read

Leyendo ficheros con SQLMap:

• --file-read=
• --file-write=
• --file-dest=

LOAD_FILE()
INTO OUTFILE/DUMPFILE 

Una vez obtenido el código fuente lo analiza buscando el patrón MD5 y efectivamente se utiliza el cifrado débil MD5 y SHA1 sin ningún tipo de salt

    $sql = "SELECT id, nombre, dni, password, tipo_usuario, activado FROM alumnos where dni like '".strtoupper($dni)."' and password  like '".md5(sha1($pass))."'";

Es decir, las contraseñas de los usuarios están cifradas usando:

md5(sha1($pass))

¿Que es un Hash sin Salt? - ¿Qué es el salt de una contraseña ?

Un hash es un código que se obtiene tras aplicar un algoritmo especial a una cadena de texto.

Es decir que si tenemos, por ejemplo, una contraseña "password" y le aplicamos un hash MD5 obtendremos el valor de 5f4dcc3b5aa765d61d8327deb882cf99

• http://www.elhacker.net/convertidor.html

El problema se ve agravado por el no uso de un salt del hash MD5, y que aunque oculta el texto claro de la contraseña es fácilmente crackeable.. MD5 fue diseñado para ser extremadamente rápido y requiere un coste de cpu (cálculo) mínimo.

Los hashes con salt, son como los hashes de toda la vida pero con un plus de seguridad. En este caso el truco está en la salt que se le agrega. Salt es un número de dígitos o carécteres aleatorios que se le agrega al hash ya sea al principio o al final. Con lo que los hashes ya no son los normales y por ende no figurarán en una tabla haciendo más difícil  crackearlos. Ya que se deberá probar no solo con cada hash, sino también con cada salt y sus combinaciones.

Las funciones de hash más conocidas y utilizadas eran MD5 y SHA-1, pero dado que MD5 y SHA-1 han sido comprometidas, actualmente se recomienda el uso de nuevas funciones como son SHA-2 y Bcrypt.

Gracias al "salt", garantiza que cada hash almacenado es único, incluso si dos usuarios eligen la misma contraseña de acceso, cada uno de hash en una tabla comprometida debe ser crackeada por separado. Usar el mismo salt en cada hash es fácilmente crackeable de nuevo usando tablas inversas.

Es importante resaltar que si se usa un "salt" único para todos los usuarios  tampoco sirve de nada. Cada salt debe ser único y diferente para cada usuario. Así que en la tabla de usuarios, se debe almacenar a parte del la contraseña, el salt.

API para cifrar contraseñas en PHP 5.5

Internamente la API utiliza la función crypt() y está disponible desde la versión 5.5.0 de PHP. Si utilizas una versión anterior de PHP, siempre que sea igual o superior a 5.3.7, existe una librería con las mismas funcionalidades que la nueva API: github.com/ircmaxell/password_compat.

La función más importante de la nueva API es password_hash(), que codifica la contraseña que le pases con el algoritmo indicado

El primer argumento de la función es la contraseña original sin cifrar y el segundo argumento debe ser una de las dos siguientes constantes

• PASSWORD_DEFAULT, codifica la contraseña utilizando el algoritmo bcrypt y el resultado es una cadena de 60 caracteres de longitud, cuyos primeros caracteres son $2y$10$. El algoritmo utilizado y la longitud de la contraseña codificada cambiarán en las próximas versiones de PHP, cuando se añadan algoritmos todavía más seguros. Si guardas las contraseñas en una base de datos, la recomendación es que reserves 255 caracteres para ello y no los 60 que se pueden utilizar actualmente.
• PASSWORD_BCRYPT, a pesar de su nombre, codifica la contraseña utilizando el algoritmo CRYPT_BLOWFISH. Al igual que en el caso anterior, la contraseña codificada ocupa 60 caracteres en total, siendo los primeros caracteres $2y$.

 El tiempo empleado en cifrar una contraseña se denomina "coste" y se puede configurar mediante el tercer argumento opcional de la función password_hash(). El coste por defecto es 10 (por eso el prefijo de las contraseñas anteriores es $2y$10$) y su valor debe estar comprendido entre 04 y 31.

• http://php.net/manual/es/function.password-hash.php

 Por lo tanto usando un diccionario de palabras y un simple script PHP llamado sha_md5.php:

 while($f = fgets (STDIN){
$passwenc = md5(sha1(rtrim($f)));
echo "$passwenc : $f";
}
?>

Busca en el código fuente por el patrón FILE y descubre que hay una opción para poder subir ficheros (sin validar) pero se necesita ser del tipo usuario 3 (Administrador)

Pero gracias a que pudo obtener una shell con la vulnerabilidad SQL, puede buscar en la DB Campus por usuarios (alumnos) que sean del tipo 3.

Como no hay ningún salt, con el script anterior en php puede obtener la contraseña de un usuario del tipo 3. Su contraseña es de 4 caracteres numéricos.

Ahora ya puede acceder al Campus con normalidad con un usuario con permisos y subir la webshell. Una vez subida la webshell obtiene una nueva shell con netcat.

Como comenta en el video es mejor no perder el tiempo crackeando las contraseñas de los usuarios  (en  este caso encontrando coincidencias de un diccionario con los hash obtenidos), es mejor instalar un "backdoor" en el código fuente para capturar directamente y en texto plano, los credenciales de los usuarios que acceden al Campus o al WordPress.

Cuando el usuario se valide tanto en Wordpress como en el Campus las contraseñas se guardarán automáticamente en un fichero de texto. Usando la sencilla función de php file_puts_contents

file_puts_contents("fichero.txt", "$_POST['variable_ usuario']", "$_POST['variable_ usuario']", FILE_APPEND);

Herramientas utilizadas durante el ataque

Todas las herramientas utilizadas en el vídeo son herramientas muy conocidas, accesibles a cualquier persona y muy bien documentadas. Son herramientas muy utilizadas en cualquier curso de hacking ético y se demuestra que el ataque era relativamente sencillo, pues no se requirió de ninguna herramienta propia o hecha a medida. Sólo hay creado a medida el script sha_md5.php para juntarlo con el diccionario y encontrar coincidencias con los hashes de las contraseñas y el script file_reader.pl para descargar los ficheros vía SQLi.


Por orden de aparición:

• Kali Linux (distribución GNU/Linux muy conocida para realizar tests de pentesting)
• OWASP Zap (Zed Attack Proxy)
  
• SQLMap
• Script propio sqli file_reader.pl (script para descargar ficheros de forma automatizada)
• Weevely (php web shell) 

Comandos utilizados en la shell

• vim (editor de texto)
• grep (para buscar patrones y palabras clave)
• zcat (descomprimir en directo)
• nc (netcat para crear la shell personalizada)
• export (crear variables de la shell)
• php -l (comprobar sintaxis ficheros php)
• touch (para cambiar la fecha de los ficheros php modificados con el backdoor)

¿Quién es Phineas Fisher y de dónde es?

Detalles curiosos del vídeo

• Chema Alonso (el terminal indica que el usuario de Kali Linux es chemaalonso y el nombre de la máquina  es elladodelmal). El final del vídeo termina con Saludos Malignos!, la forma habitual de despedirse en las entradas del blog del verdadero Chema Alonso.
• Gossos (palabra en catalán que significa "perros" es un insulto vox populi a los Mossos). El atacante utiliza la contraseña "g0ss0sDeCuadra" en la webshell Weevely
• Listado de canciones del vídeo (playlist)
  

Cabe destacar que el documental de "Citutat Morta" está relacionado con la Guardia Urbana de Barcelona y no directamente con los Mossos de Esquadra.

Cuando usa SQLMap no usa "ningún" tipo de proxy visible, así que es muy de suponer que usa Kali Linux en una máquina virtual pasando primero por Whonix. En el vídeo solo configura el navegador Firefox y OWASP ZAP para usar el proxy en localhost puerto 8080, por lo que es de entender que usa Tor para el resto del tráfico.

Una de las pocas posibles "pistas" que ofrece el vídeo:

En el vídeo se puede ver cuando ejecuta el comando "date" en el terminal la fecha del sistema operativo de Kali Linux:

• CLT son las siglas en inglés de "Chile Standard Time"

Zona horaria CLT en vez CEST (Central European Summer Time). Una pista que lógicamente podría ser intencionadamente falsa.

Es evidente que podría ser latino, ya que su manual publicado, fue una guía en castellano con algunas palabras propias de Sudamérica. En su segunda manual DIY habla en femenino.

Otra de la cosas que llama la atención es la elevada velocidad descarga de 1,60MB/s obtenida al descargar con wget la copia del sitio hackeado del SME: Si está usando una cadena de VPN's o similar, es una velocidad muy alta.