Recuperando datos de un Disco Duro Seagate 7200.11 SD81

Vuelvo con este artículo que si bien no tiene mucho de “hacking” propiamente dicho, si que tiene su parte “forense”, que también tiene su encanto. Debido a la suma importancia personal de los datos que contenía el HDD, el poder recuperarlos fue todo un éxito porque además, no se perdió ni un solo documento y es por ello que os lo traslado aquí.

La historia.

Hace pocas semanas un familiar cercano me comunicó que su HDD donde tenía todas las fotos, vídeos y demás “timeline” de su familia tanto actual como los no presentes ya, no lo reconocía su equipo. Tras indicarle lo típico “¿has apagado y encendido el disco duro?, ¿has conectado el disco duro a otro ordenador?, ¿has pintado de verde el disco y tirado al río?, etc…” pude diagnosticarle, atrevidamente por teléfono, que había “cascao”.

Cuando coincidimos en una reunión típica familiar (dichos familiares viven bastante lejos de dónde yo) me dieron el regalito del Disco Duro Seagate 7200.11 con firmware SD81 de 500Gb, con 499Gb ocupados de información valiosa.

Mi idea era la que suelo seguir en caso de que me traigan discos duros que suenan a castañuelas y limitado a los cuatro aparatitos que tengo: o intentar dejar el disco duro en una posición donde la mecánica del mismo permita temporalmente acceso (muchas veces he recuperado así algunos datos) o congelando el disco duro (y también he tenido éxito algunas veces).

Pero una simple navegación por San Google (Duck Duck Go más bien) buscando el modelo por si acaso había algún hilo sobre este disco y bingo!, este modelo con algunos firmware distintos al que calza nuestro disco duro a reparar, contiene un fallo de serie que consiste en que el log se corrompe debido a una serie de eventos que registra el propio HDD.

Para que nos entendamos, estos modelos tienen un log de 320 registros el cual, desde que encendemos el disco, comienza a registrar eventos y tal (nada nuevo). El problema viene cuando el puntero que registra la posición del siguiente evento, está desplazado una posición (diseño y tal). Sí, ¿y que pasa? Pues que si coincide que estamos en la posición 319, y se finaliza la escritura en la posición/registro 319, y el puntero se queda en la 320, como apaguemos el disco en ese momento y queramos encenderlo, nos habrá “cascao”.

Se deben dar también unas condiciones concretas de escritura al inicio del registro 320, no solamente la mera situación del puntero es la que produce esta corrupción sino que se tiene que dar unas condiciones de escritura del log.

Con esto, al iniciar el disco duro, detecta una corrupción de memoria y bloqueará el acceso impidiendo así acceder a nuestros datos. Además, todo esto se quedará registrado en la SMART (tecnología para detección de fallos del Disco Duro, anticipar errores del disco, etc…) y por consiguiente, en los siguientes inicios que hagamos nos “bloqueará” el acceso.

Manos a la obra.

Bien, puesto en antecedentes y explicando un poco por encima que es lo que le ha pasado al disco, comentar que esto tenía aparentemente, solución.

Concretamente nuestro disco tiene el firmware SD81, que está dentro del “blackseagate” que comentamos. La información que encontré normalmente refería a SD15, el cual cambia alguno de los pasos o datos a introducir por hyperterminal.

¿Qué se necesita?

1. Tiempo
2. USB to Serial (UART)
3. Cable alimentación SATA
4. Hyperterminal

Una vez tengamos estos 4 requisitos, lo demás es bastante sencillo, al menos es la conclusión que sacas cuando lo haces y te funciona (xD).

El dispositivo UART es típico para los que tocan arduino y modifican firmwares de routers, etc.. además su bajo coste (3€ aproximadamente) lo hacen bastante accesible para todos los públicos.

Si aconsejaría que os decantárais por un dispositivo UART que al menos traiga los cables de conexionado largos de 30cm, por ejemplo, para tener maniobrabilidad.

También, tuve problemas con la conexión que traen los cables, porque llevan conectores de plástico duro y para conectarlos a la conexión del HDD tuve que quitarle dichos conectores y tirar de tubo termoretráctil para usarlo de aislante.

Muestra de 3 cables con conector quitado y en su lugar, termo-retráctil

Es necesario alimentar el disco duro para proceder con el trabajo. Para ello debes ingeniartelas para poder conectarle de alguna forma un cable SATA (desde una torre de un ordenador cercana, desde una fuente de alimentación de un ordenador, etc…)yo tengo un kit de conexión de discos IDE y SATA por lo que esto no fue problema de negociar o conectar.

Por último necesitamos HYPERTERMINAL. Los que tengáis XP ya podéis actualizaros a otro sistema más moderno o tirar de Linux asi que cuando hagáis eso (:P), si os decantáis por Windows tendréis que descargaros Hyperterminal (https://onedrive.live.com/?cid=b98f3d302358df4a&id=B98F3D302358DF4A!222) para poder hacer lo que voy a mostrar. También podéis usar Putty.

Proceso.

1. Conectar UART al equipo y comprobar que están los drivers OK.

Esto se hace en el administrador de dispositivos. Si os pasa como a mí, que lo instalé en un Windows 10, el UART que tengo no me iniciaba. Tuve que recurrir a unos drivers de 2008 para que me funcionara. Este fue el paso que más dolor de cabeza me dio aunque parezca mentira x D.

Muestra de como NO debe aparecer el UART en nuestro sistema.

2. Conectar cableado al disco duro.

Importante esto:

– El conector de transmisión de datos, TX, debe ir conectado a de Recepción de datos, RX, del Disco.

– El conector de recepción de datos del UART, RX, debe ir conectado al de Transmisión de datos del HDD, TX.

– La masa del UART conectada a la masa del HDD.

Muestra pines de conexión en HDD

Muestra de pines de conexión en USB.

3. Conectar UART al USB del equipo. Con todos los cables ya enchufados.
4. Conectar cable de alimentación al HDD.
5. Crear conexión Hyperterminal con las siguientes características:
   1. Velocidad de transmisión: 38400bps
   2. Bit de datos: 8 bits
   3. Bit de paridad: No
   4. Bits de parada: 1 bit
   5. Control de flujo por hardware: No.
6. Introducción de comandos

Este paso es fundamental. Ojito que este proceso es solo para el SD81, a mí es el que me ha funcionado y desconozco si funcionará o si dañaría el disco duro en otros firmwares por lo que cuidado con usarlo en otro firmware.

Comentar que F3 2> o F3 1> es la consola y nos dice en que “nivel” estamos, por lo que los comandos que introducimos son los que están después del >

• F3 2>U

Mostrará algo así:

Spin Up Complete

Elapsed Time 5.921 secs

• F3 2>/1

• F3 1>N1

• F3 1>
• F3 T>m0,2,2,,,,,22

Es muy importante teclearlo como está, con la m en minúscula, respetando las comas, sin espacios, etc…

Veremos algo así como:

Max Wr Retries = 00, Max Rd Retries = 00, Max ECC T-Level = 14, Max Certify Rewrite Retries = 00C8

User Partition Format Successful – Elapsed Time 0 mins 00 secs

• F3 T>

Ahora podremos desconectar la alimentación del HDD, y desconectar nuestro UART. Posteriormente, tras esperar algunos segundos, podremos conectar nuestro HDD a algún equipo con adaptador o a una torre, para comprobar si hemos “obrado el milagro” y poder poner los datos a salvo en otro disco duro.

Existe una especie de parche/actualización de Seagate para solucionar este bug en varias versiones afectadas SDxx pero lo más seguro inicialmente es proceder a trasladar la información a otro HDD.

PD: Aclarar que en otros hilos en Internet, utilizan la desconexión de la placa del disco y paran el motor (tras aislarlo con una tarjeta o similar) con comandos (Z) y luego conectan y tal. Esto es para comprobar si nuestro disco duro tiene ese tipo de error (aparecería algo similar a esto: LED:000000CC FAddr:0025A1E1), al menos, a mí el proceso me ha funcionado “saltándome” estos pasos de “aislar” el motor del disco duro de la placa y luego conectar.

Extra:

• La instrucción “/2″ nos sitúa en el nivel 2, lo que nos da privilegios para realizar los pasos correspondientes.
• Si tecleamos “/1″, iremos al nivel 1.
• Para borrar la SMART, previamente introduciendo “/1“, utilizamos comando N1.
• U: Arranca motor de giro del Disco. (Caso de tener que aislar temporalmente la PCB del motor del disco)
• Z: Para motor de giro del Disco.(Caso de tener que aislar temporalmente la PCB del motor del disco)

Las principales vulnerabilidades web

Cuando se va a atacar un sistema, lo último que se quiere es que salten todas las alarmas. Es por eso que usar fuentes online son una buena herramienta. Se puede utilizar hacking de buscadorespara localizar URLs con paso de parámetros, para comprobar si éstos están correctamente validados, para buscar correos electrónicos u otra información que pueda extraerse de un determinado sitio: ficheros de backup o de configuración que hayan quedado indexados, etc.

Un buscador muy utilizado es Shodan. Este buscador almacena toda la información pública que puede obtener de aquellos dispositivos que están expuestos a Internet. Entre otras cosas, podemos encontrar dispositivos con sus claves por defecto (routers, cámaras ip, etc), direcciones IP con los puertos que tienen abiertos, servicio y versión del mismo que corre en cada uno, certificados SSL, con sus respectivas suites de cifrado, etc. Una vez indexada una determinada IP en Shodan, evita tener que hacer una comprobación directa sobre el sistema, de manera que permite a un atacante conocer si un sitio web está correctamente actualizado, sin necesidad de lanzar un escaneo de puertos, que pueda delatarle a él.

METADATOS

Otra fuente de información importante son las fugas de información que se producen por culpa de los metadatos, que van incluidos en los documentos que se publican en Internet.

Con estos datos, es posible conocer nombres de usuario, equipos, sistemas operativos, versiones de software, etc. que se utiliza en la organización.

Si no se tiene cuidado, con estos datos es posible incluso realizar un mapa interno de la organización, desde los equipos cliente, con los usuarios de cada uno, hasta los servidores de los que se dispone, pasando por impresoras, etc.

Es por esto que es muy importante, antes de subir un documento o publicarlo, realizar una limpieza de metadatos del mismo.

Herramientas como FOCA, son de gran utilidad para comprobar qué información sensible estamos publicando, sin que seamos conscientes.

Principales vulnerabilidades web

Una vez que hemos visto lo importante que es la información acerca de nosotros que tenemos publicada, y que debemos intentar controlar, veamos qué vulnerabilidades más importantes puede presentar un sitio web.

En primer lugar nos situamos en el escenario, tenemos una plataforma montada sobre un sistema operativo, con su motor de base de datos, lenguajes, normalmente interpretados, certificados, etc. Ésta es la parte del servidor web en sí. Las vulnerabilidades que tendrá desde ese punto de vistas serán:

–Configuración débil, por defecto o mal configurado. Esto suele producirse por intentar desplegar el servicio lo más rápido posible o por una confianza excesiva en el software utilizado, incluso por desconocimiento. Cuando se expone a Internet un sistema con su configuración por defecto, si se encuentra una vulnerabilidad en el mismo, el exploit por defecto funcionará. Es necesario revisar el servicio a desplegar y buscar una configuración suficientemente fuerte.

– Comunicación insegura entre cliente y servidor. Es muy importante que la comunicación entre cliente y servidor esté cifrada, sobre todo, cuando se trata de envíos de formularios, por ejemplo, para autentificarse en sitio web. En muchas ocasiones, se configura el sitio web para usar cifrado, con una configuración débil, permitiendo protocolos inseguros, como SSLv2 y SSLv3, o suites de cifrado vulnerables, como MD5. Esto dará una falsa sensación de seguridad, el cliente verá que hay un certificado, que el sitio web, aparentemente está cifrado, y, sin embargo, por culpa de los protocolos permitidos, podría ser relativamente fácil descifrar esta comunicación. Es por ello que es necesario revisar el estado de la calidad en la configuración de nuestros certificados.

– Software desactualizado. Una vez desplegado el sistema, independientemente de que se hiciese el trabajo correctamente, pasado el tiempo, el software se desactualiza. Se localizan vulnerabidades, se corrigen en versiones posteriores, etc. Es necesario llevar un control de las versiones utilizadas, así como mantener el software actualizado, en el menor tiempo posible, desde que se libera una nueva versión. En caso contrario, al cabo de un tiempo, nuestro sistema será vulnerable y existirán exploits públicos que permitirán atacarlo.

Vulnerabilidades de la aplicación

Estas vulnerabilidades son propias de la aplicación que se quiere desplegar, del código de la misma. Independientemente de que la plataforma sobre la que despleguemos la aplicación esté correctamente fortificada, si la aplicación posee vulnerabilidades, corremos el riesgo de que puedan encontrarse y ser  atacadas.

Las vulnerabilidades más comunes en una aplicación web son:

Cross-Site Scripting (XSS), ésta es una vulnerabilidad o, mejor dicho, un conjunto de vulnerabilidades, que permiten, utilizando los parámetros de entrada de la aplicación, modificar y añadir código a la misma.

Son vulnerabilidades que se encuentran en el servidor, pero que están destinadas a atacar al cliente.

Generalmente, se necesita que el cliente sigua un enlace de la aplicación, en el que se ha modificado algún parámetro, para permitir añadir código, que se ejecutará en el navegador del cliente.

Normalmente, el código inyectado será html o JavaScript y la intención será un robo de cookies del cliente, predicción del id de sesión, etc.

Esta vulnerabilidad se aprovecha de la confianza en el cliente en el sitio web: Verá que es el dominio de la aplicación y que, al seguir el enlace, llega realmente al sitio web que quería, no hay suplantación del mismo.

Básicamanente, podemos agrupar los XSS en dos grupos:

– XSS reflejados: El código modificado se elimina al cargar la página de nuevo. Está basado en la URL y, por tanto, al recargar la página, se elimina el mismo.

-XSS persistentes: El código modificado queda almacenado en la web.

La forma de corregir esta vulnerabilidad es filtrar y validar todas las entradas de la aplicación. No se debe utilizar nunca una variable que se recibe desde el cliente, confiando en que ésta tendrá un valor correcto. Los lenguajes de programación incluyen diferentes funciones que permiten filtrar el contenido de las variables, dependiendo de dónde las vayamos a utilizar.

Cross Site Request/Reference Forgery (CSRF)

Esta vulnerabilidad es una evolución de los XSS. En este caso, se va a explotar la confianza en el servidor sobre el cliente. Es decir, nos haremos pasar por un cliente legítimo, utilizando datos parciales del mismo.

Esta vulnerabilidad está presente en formularios. Cuando estos se envían al servidor, es necesario asegurarse que la petición es legítima y debemos asegurarnos que el cliente ha realizado la petición, realizando los pasos previos necesarios.

La forma más común para eliminar esta vulnerabiliad o, al menos, mitigarla, es la inclusión de tockens dinámicos. En los actuales FrameWorks, suelen incluirse mecanismos para añadir esta protección a los formularios, de una forma muy sencilla. En algunos, por ejemplo, Laravel (utilizado para desarrollo de aplicaciones en PHP), basta añadir una etiqueta a la plantilla del formulario, para que se añada al mismo el tocken anti-csrf.

A continuación os muestro los nombres de los diferentes XSS más comunes, que dependen del lugar donde se consiga inyectar el código deseado.

• DOM Cross Site Scripting (DOM XSS)
• Cross Site Flashing (XSF)
• Cross Frame Scripting (XFS)
• Cross Zone Scripting (XZS)
• Cross Agent Scripting (XAS)
• Cross Referer Scripting (XRS)
• …

SQL INJECION

Si los ataques XSS son peligrosos, ya que pueden provocar un robo de sesión, los SQLi son aún más porque permiten acceder y manipular la BBDD. La idea es modificar las consultas que hace la aplicación a la base de datos, aprovechando las entradas de usuario a la aplicación.

Veamos una estructura de una consulta SQL típica.

SELECT [Columnas] FROM [Tabla] WHERE [Condiciones]

Primero se seleccionan las columnas que queremos mostrar, después se indica la BBDD y la tabla de la que queremos obtener las columnas y, por último, las condiciones para filtrar esos datos.

Cuando se van a realizar consultas, se realizan con un usuario de BBDD. Este usuario tendrá diferentes permisos.

Otra cosa a tener en cuenta es que, los motores de BBDD, tienen sus propias tablas para almacenar metadados, por ejemplo, las bases de datos que hay, qué tablas tiene cada BBDD, las columnas y tipo de cada una, información de usuarios, etc.

Hay que tener presente que, cuando se puede hacer un SQL injection, se hará con los permisos que disponga el usuario con el que se ejecuta.

Existen diferentes ataques de SQL injection, dependiendo de cómo se consiga inyectar y modificar la consulta, para obtener los datos que se desean.

• Bypass de un login mediante SQL Injection
• SQL Injection (Mediante UNION)
• Serialized SQL Injection
• Boolean-Base SQL Injection
• Time-Base SQL Injection
• Heavy-Queries SQL Injection
• Stack-Queries
• …

Ahora vamos a explicar cómo se realizaría un SQLi.

Empezaremos explicando un SQLi de tipo Union.

Lo primero es tener claro cómo sería la estructura de la consulta que se desea modificar. Cuando se va a utilizar Union para realizar la inyección, lo primero que debe hacerse es negar la consulta original, para que esa no sea la que devuelva la información.

Por lo tanto, se debe añadir una condición que siempre sea falsa.

SELECT ID, Nombre FROM Clientes WHERE ID=1 AND 1=0

Una vez que sabemos cómo negar la consulta legítima, vamos a testear cuantas columnas devuelve la consulta original. Esto es importante, porque los SQLi deben devolver exactamente el mismo número de columnas. Para ello, vamos probando mostrando un valor constante, luego dos, etc. hasta que veamos que tenemos un resultado.

http://dominio/index.php?id=1 AND 1=0 UNION SELECT 1
http://dominio/index.php?id=1 AND 1=0 UNION SELECT 1,2
...

Hecho esto, ya sabemos cuantas columnas debe devolver nuestra consulta, a partir de aquí, habrá que intentar obtener información de los nombres de tablas que hay en la BBDD, luego de los nombres de columnas por cada tabla y, una vez tengamos esa información, podremos ir extrayendo aquello que necesitemos.

user(): usuario que ejecuta las consultas en la aplicación

database():la base de datos usada actualmente

http://dominio/index.php?id=1+and+1=0+union+select+1,2,user(),database()

Otro escenario común es utilizar un consulta para validar la autentificación de un usuario. Se consulta en la BBDD si el nombre de usuario y password existen y, si devuelve un registro, entonces se le permite el acceso. Si alguna de estas variables es vulnerable a un SQLi, se puede forzar la consulta para que siempre devuelva algo, de manera que podremos saltar el login de la aplicación.

Por supuesto, existen herramientas que automatizan esto. Por ejemplo, SQLMap, nos permite automatizar los SQLis y, una vez detectado un parámetro vulnerable, nos permite extraer información de una manera muy cómoda. Incluso nos permitirá abrir una shell en el servidor, si esto es posible con el usuario actual, subir ficheros, realizar elevación de privilegios, etc.

Para prevenir los SQLi, se deben parametrizar las consultas y es necesario filtrar y comprobar el valor de las entradas. También es muy importante restringir al máximo los permisos del usuario con el que la aplicación se conecta a la BBDD y, por supuesto, para cada BBDD, utilizar un usuario diferente. Esto es muy importante y, aunque es una mala práctica usar una misma instancia del motor de BBDD para diferentes aplicaciones, es un escenario muy común. Por este motivo, si un usuario de la BBDD tiene permisos sobre varias BBDD de diferentes aplicaciones y una de éstas presenta esta vulnerabilidad, el atacante podría obtener los datos del resto de aplicaciones.

Además de esto, es muy importante ocultar los errores provocados por consultas en BBDD. Esto es porque la forma de detectar un SQLi es intentar forzar un error (la típica ‘) y, una vez se comprueba que existe, si se muestra al usuario, éste puede extraer información, como el motor de BBDD usado, etc., con lo que se le facilitará la realización del ataque.