Últimamente, las revisiones de código han ido ganando mucha popularidad. Las organizaciones que hasta hace poco se conformaban con una red segura y con alguna que otra prueba de penetración ahora revisan el código de sus aplicaciones antes de lanzarlas.

Una revisión del código, más allá de lo que encuentran las pruebas de penetración de aplicaciones, puede descubrir puertas traseras y troyanos en el código. Estas puertas traseras podrían haberse introducido en el código de forma intencionada o inadvertida.

Las inseguridades en la mayoría de las aplicaciones pueden surgir debido a varias razones. Una razón importante es la enorme presión sobre los desarrolladores para cumplir con los requisitos funcionales y entregarlos a tiempo. Algunos de los errores más comunes que pueden cometer los desarrolladores son:

No se puede vincular una página a otras páginas web
Pon un código de prueba y olvídate de eliminarlo
Extraviar páginas web en el directorio de inicio que en realidad están destinadas a otros módulos de la aplicación
Algunos desarrolladores malintencionados pueden plantar intencionalmente una puerta trasera para acceder a ellos en el futuro

‍

¿Cómo entran las puertas traseras en la aplicación?

Considere una aplicación basada en la web creada en ASP.NET. La aplicación cuenta con estrictos controles de autenticación y autorización. Se ha implementado un esquema seguro de administración de sesiones.

Pero desafortunadamente, uno de los desarrolladores dejó involuntariamente algunas páginas de prueba en el directorio de la aplicación. La página de prueba se escribió para ejecutar algunas consultas a la base de datos desde la interfaz de usuario, básicamente para facilitar su uso. Un atacante detecta la página de prueba mientras navega por la aplicación y rápidamente reemplaza el nombre de la página web en la URL por el nombre de la página de prueba, accede a la página y recupera la información de las tarjetas de crédito de los clientes. Por lo tanto, un pequeño error en la fase de desarrollo puede provocar el robo de información confidencial.

La existencia de una puerta trasera puede permitir a los atacantes inyectar, ver, modificar o eliminar bases de datos o páginas web sin autorización. En algunos casos, también puede penetrar en el sistema y ejecutar comandos del sistema.

Las principales características de las puertas traseras son:

Páginas web huérfanas
Código de depuración sobrante
Parámetros invisibles
Páginas web innecesarias
Uso de sentencias DDL
Uso de eliminaciones/actualizaciones

‍

Técnicas para detectar puertas traseras mediante la revisión del código

Veamos cómo buscamos puertas traseras utilizando cada una de las características mencionadas anteriormente.

Páginas web huérfanas

Busque todas las páginas web que no estén enlazadas ni accedidas desde ninguna otra página web; probablemente se utilicen para realizar pruebas y no para eliminarlas. Esto se puede detectar analizando las directivas de los encabezados de página para comprobar si hay una llamada a la página.

La tarea se puede facilitar escribiendo un script en perl que busque enlaces en toda la aplicación que no estén vinculados a ninguna otra página web. Otra forma podría ser escribir un script en perl para una búsqueda de cadenas que busque el nombre de una página web en particular, por ejemplo test.aspx, en todo el directorio de la aplicación. El script muestra todas las líneas que contienen test.aspx del código de la aplicación. Este método requiere el análisis manual del código fuente.

Código de depuración sobrante

Busque todas las páginas web en las que al objeto de sesión se le asigne un valor a partir de la entrada del usuario. Las variables de los objetos de sesión se utilizan para almacenar información sobre un único usuario y están disponibles en todas las páginas web de la aplicación. Por lo tanto, si a un objeto de sesión se le asigna un valor en una página, el mismo objeto de sesión se puede usar para tomar una decisión o para realizar una consulta SQL en otra página. Supongamos que el objeto de sesión se usó para probar la función de acceso basada en roles en una aplicación. Más tarde, el desarrollador decide utilizar la codificación clásica de estilo ASP y se olvida de eliminar el código. Un atacante se da cuenta de esto y cambia el valor del objeto de sesión para obtener un mayor acceso privilegiado a la aplicación. Esto provoca la omisión de la autorización o la escalada de privilegios. Si a los objetos de sesión se les asigna un valor a partir de la entrada del usuario y se utilizan como lógica para la autorización, se trata de una vulnerabilidad.

Parámetros invisibles

Identifique todas las páginas web para los parámetros GET o POST analizados por una página web. Busque los parámetros que no tengan ningún código relacionado con el servidor.

La tarea se puede simplificar escribiendo un script en perl que extraiga los parámetros de entrada de las páginas web, los almacene en una matriz y los compare para encontrar los parámetros que solo aparecen en el código del lado del servidor.

Páginas web innecesarias

Busque páginas web que no estén vinculadas al directorio de trabajo actual de la aplicación. Es posible que existan páginas que simplemente estén ubicadas en la carpeta de la aplicación, pero que se estén accediendo a ellas desde otros módulos de la aplicación.

Uso de sentencias DDL

Busca instrucciones DDL en todas las páginas web para operaciones como borrar, soltar, alterar o crear. Estas operaciones no deben gestionarse desde un código subyacente, sino que deben gestionarse desde un procedimiento almacenado.

Uso de DELETE/UPDATE

En todas las páginas web, busque las instrucciones DELETE y UPDATE sin una cláusula WHERE o condiciones WHERE que siempre den como resultado True.

Mejores prácticas

Estas son algunas de las mejores prácticas que un desarrollador debe tener en cuenta al desarrollar una aplicación.

Identifique y elimine todas las páginas web que no estén vinculadas a ninguna otra página web de la aplicación
Identificar y eliminar los parámetros GET/POST que no utiliza la aplicación
Separe las páginas web en consecuencia. Es mejor tener los módulos de aplicaciones críticas alojados en servidores separados
No asigne valores de la entrada del usuario a las variables globales
Utilice siempre procedimientos almacenados para las operaciones de DDL

Share this post