Secuenciar y analizar ADN era algo lento y costoso hace unos años, pero actualmente cada vez es más barato y rápido analizar millones cadenas de ADN. Las herramientas bioinformáticas son cada vez más asequibles y no podemos olvidar que, al fin y al cabo, se podrían catalogar como un dispositivo más dentro de los ICS. Almacenar información en cadenas de ADN no es algo nuevo y se presenta como un posible futuro de almacenamiento para datos digitales, actuando como discos duros orgánicos.
Almacenar datos en ADN tiene ventajas como durabilidad o incluso la no obsolescencia (el ADN no pasará de moda), pero quizás la mayor sea la capacidad de almacenamiento siendo posiblemente el sistema con más densidad de información existente (llegando incluso a 214 Petabytes en un gramo). Por lo tanto, es posible que, en un futuro, existan ordenadores que utilicen secuencias de ADN para almacenar y recuperar todo tipo de información.
 |
| Figura 2: Paper publicado sobre la secuenciación de malware en ADN |
Pero este hipotético futuro también podría acarrear nuevos tipos de ataques utilizando muestras falsas de sangre o saliva para poder acceder a la información de ordenadores ubicados en hospitales que secuencien ADN, universidades o incluso más allá, inyectar código malware a secuenciadores utilizados por la policía para identificar posibles sospechosos de actos delictivos y modificar los resultados. Pero bueno, esto es especular demasiado, ¿o no?. Vamos a concentrarnos en el paper y la PoC que han creado estos investigadores de la Universidad de Washington.
 |
| Figura 3: Muestra real de ADN sintetizado con el malware incrustado en su secuenciación |
Como lamentablemente ocurre en otros dispositivos del IoT o los ICS, los programas y el hardware de secuenciadores de ADN no implementan apenas medidas de seguridad. Los investigadores fueron capaces de sintetizar ADN, que después de secuenciarlo y una fase de post-proceso, era capaz de generar un fichero que podría facilitar un acceso de control remoto al mismo aprovechando vulnerabilidades en el código del programa.
Todos hemos visto las famosas letras A, C, G y T (formando cadenas como por ejemplo AAATGGTCTTATCC) que representan la estructura primaria de una molécula de ADN y dichas letras corresponden a subunidades de nucleótidos llamados Adenina, Citosina, Guannina y Timina. Estas secuencias se agrupan en cadenas generadas con dichas letras las cuales a su vez se almacenan en ficheros de ordenador en un formato estándar llamado FASTQ. Estos ficheros tienen una estructura simple tipo ASCII como se puede ver en este ejemplo:
 |
| Figura 4: Ejemplo de FASTQ Format file |
Estos ficheros provienen directamente del secuenciador sin ningún tipo de análisis previo (RAW). Antes de que comience el análisis de dicha secuencia almacenada en el fichero FASTQ, se realiza un pre proceso de limpieza para eliminar los datos no deseados basados en valores con poca puntuación (cuarta línea del ejemplo de arriba). Durante la secuenciación es cuando estos datos sin formatear se agrupan y alinean (este proceso es realmente complejo y se suele utilizar mucha potencia de cálculo) utilizando otras secuencias como referencia (por ejemplo, el genoma humano). Esta nueva alineación se guarda en otro formato llamado SAM o su versión comprimida llamada BAM y las posibles variaciones se almacenan en un fichero tipo VCF.
PoC: ADN para explotar malware
Entonces ¿puede el ADN utilizarse para comprometer un ordenador? Para poder contestar a esta pregunta tenemos antes que analizar los pasos que a realizar para tener éxito. El primer paso es poder sintetizar una secuencia de ADN sintético real con el código malicioso incrustando en él. Otro paso será poder secuenciar dicho ADN utilizando métodos de secuenciación estándares. Luego será necesario realizar un post-proceso utilizando un programa para analizar dicha secuencia de ADN. Finalmente, el exploit debería de provocar la ejecución de código arbitrario en el ordenador objetivo del ataque. Este es el aspecto final que tendría un fichero final FASTQ con el código de un exploit incrustado y secuenciado:
 |
| Figura 5: Exploit en formato FASTQ secuenciado |
Esto implica que será posible ejecutar un ataque tipo buffer overflow cuando el programa intente leer una cadena que sea mayor que el tamaño máximo de almacenamiento de dicho buffer. Por lo tanto, se preparó un Shellcode de 55 bytes de tamaño con otros 39 más para almacenar otros datos como valores de los registros (0xdeadbeef). Finalmente se obtuvo un exploit con 94 bytes de tamaño que se codificó en 376 nucleótidos. El proceso, con resultado negativo, se puede ver en la siguiente imagen:
 |
| Figura 6: Primer intento fallido de secuenciar el malware |
Para sintetizar el exploit se utilizó el programa IDT gBlocks el cual generó fragmentos de hasta 3.000 bases de longitud. Pero aquí es donde aparece el primer gran problema. Los comandos utilizados como NOP o los bytes 0xdeadbeef antes mencionados, generan cadenas repetidas (NOP genera cadenas “GCAA”). Estas repeticiones pueden no ser correctas, ya que no encajan en un tipo de ADN válido y el programa IDT gBlocks las rechaza. El segundo problema apareció debido a la longitud del exploit, que intentaron resolver con una versión de 32 bits que finalmente no tuvo éxito. Este primer ataque fracasó principalmente al no encontrar una secuencia que pudiera ser secuenciada razonablemente por el secuenciador utilizado, modelo NextSeq de la marca Illumina.
 |
| Figura 7: Secuenciador de ADN NextSeq |
El segundo intento se realizó utilizando un exploit basado en una característica de bash, la cual afecta los dispositivos virtuales /dev/tcp que crean conexiones TCP/IP. Por lo tanto, se redireccionaron stdin y stdout de /bin/sh a un socket TCP/IP, el cual conectaba a su vez con el servidor atacante. Este ataque se combinó con otro tipo return-to-libc dando como resultado un exploit de 43 bytes. Esta vez procuraron ocupar el menor espacio posible a la hora de escribir el código fuente del exploit. Por ejemplo, para la ejecución arbitraria de código remoto, utilizaron un servidor el cual su FQDN se codificó con un nombre de dominio lo más corto posible, para de esa forma mantener el exploit también con el menor tamaño posible.
Esta vez sí consiguieron un contenido sintetizado con un nivel aceptable para ser considerado válido por IDT gBlocks. Finalmente se obtuvieron 4 ficheros diferentes FASTQ con 811.118 elementos. Una vez ejecutado el programa fqzcomp, se activó el código del exploit el cual conectó a su vez con el servidor antes comentado habilitando la ejecución de código remoto con éxito.
 |
| Figura 8: Segundo intento, esta vez con éxito, de secuenciar el malware |
Estos ataques se realizaron ad-hoc, utilizando programas reales, pero preparando el terreno para que la infección y la ejecución tuviera éxito. En cambio, también analizaron otros programas (en concreto 13) utilizados a día de hoy para el análisis de código de ADN y encontraron numerosas vulnerabilidades, la mayoría basados en buffer overflow. Muchos de estos programas están escritos en C y C++, utilizando todo tipo de librerías que utilizan funciones inseguras como strcat, strcpy, sprintf, vsprintf, gets y scans (siendo strcat, strcpy y sprintf las más utilizadas). Terreno abounado para buscar y explotar bugs. Por ejemplo, los programas fastx-toolkit, samtools y SOAPdenovo2, fueron atacados con éxito utilizando técnicas de buffer overflow.
En definitiva, el caso de la secuenciación de ADN y sus herramientas es muy parecido, en lo que a falta de seguridad se refiere, al mundo de los ICS. Aunque este problema aún no resulta una amenaza real, este primer acercamiento ayudará a concienciar a estos desarrolladores a crear código más resistente a cualquier tipo de ataques. Aunque todo esto suena a ciencia ficción, es una amenaza totalmente real y cada vez más se acerca el momento de avisar a las empresas que crean ADN sintético de que es hora de comprobar que no tengan código malicioso incrustado en él.
