Downgrade como Backdoor

Se conoce como “downgrade” (en español degradar, bajar de nivel) a la acción de sustituir un software por una versión anterior de sí mismo. Sería la acción contraria a un “upgrade” (actualización).

Este término es habitual del mundo de las video-consolas y es una técnica típica en el proceso de pirateo de las mismas ya que solo ciertas versiones de los firmwares son vulnerables a los ataques que permiten ejecutar código no original.

En el mundo de la seguridad informática “seria” este tipo de acciones ha sido considerado como poco importante y es raro encontrar menciones a las mismas, sin embargo pueden convertirse en una técnica muy efectiva para ocultar una backdoor (puerta trasera) o para burlar defensas basadas en listas blancas.

Los mecanismos de protección de ejecución basados en listas blancas se basan en controlar la ejecución de ciertos programas y prohibir la ejecución de cualquier binario a menos que este identificado en una lista de programas autorizados.

Un ataque basado en downgrade consistiría en utilizar versiones antiguas de programas autorizados por las listas blancas, pero que contienen vulnerabilidades conocidas que pueden ser explotadas.

De esta forma podemos ejecutar código indirectamente a través del exploit, pero el binario que se lanza inicialmente es legítimo.

Pero el uso más interesante de esta técnica es la creación de backdoors mediante el downgrade de binarios clave del sistema operativo.

Por ejemplo recordemos la famosa vulnerabilidad en el proceso de login (/bin/login) de los sistemas Solaris que permitía acceder al sistema como cualquier usuario sin conocer la contraseña.

Una forma sencilla de troyanizar el binario de login de un Solaris podría ser sustituir /bin/login por una versión antigua afectada por esta vulnerabilidad. De esta forma el intruso tendría un método fácil de acceder al sistema y el binario no resultaría excesivamente sospechoso:

• Una consulta al sistema de parches de Solaris (mediante el comando patchadd –p o mediante el comando showrev -p) no revelaría que el binario es vulnerable ya que inicialmente el parche que soluciona esta vulnerabilidad ya ha sido instalado.

• Un chequeo mediante la herramienta elfsign revelaría que el binario está firmado correctamente por el Solaris Cryptographic Framework.

• Una consulta a la Solaris Fingerprint Database también revelaría que el binario es original de Sun Microsystems y podría ser pasado por alto en un análisis forense.

Existiría el riesgo de que otro hacker utilizase también la vulnerabilidad para acceder al sistema, pero ¿Quién comprueba hoy en día vulnerabilidades tan antiguas?