Ha pasado un poco de tiempo desde que empezamos con esta serie de entradas dedicadas a la auditoría de código, pero vamos de nuevo con el último post de la serie.

En la primera parte, hicimos una introducción a la tarea y vimos cómo se trata de algo que cada vez cobra más importancia. En la segunda parte planteamos los primeros pasos, así como la forma en la que organizar el equipo y poder repartir tareas. ¿Seguimos?

Separa “lo blanco” de “lo de color”

Cuando nos pongamos manos a la obra, debemos tener en cuenta que casi siempre podremos hacer auditoría estática (leyendo código) y dinámica (ejecuciones en entorno de prueba). Ser capaz de separar qué parte corresponde a cada caso será vital para acortar tiempos y obtener un resultado positivo.

Para poder hacerlo, nos basaremos en la documentación obtenida en la fase anterior y en una clara enumeración de tecnologías y sistemas. Teniendo toda la información sobre la mesa, podremos otorgar pesos de forma que:

Código candidato a auditoría estática:

• Partes desarrolladas hace mucho tiempo.
• Partes generadas de forma automática (sobre plataforma “insegura”).
• Algoritmos “a medida” y complejos.
• Partes sin documentar.
• Zonas de acceso anónimo.
• Valores y configuración por defecto.
• Desarrollo en ensamblador.
• …

Código candidato a auditoría dinámica:

• Partes desarrolladas hace poco tiempo.
• Partes generadas de forma automática (sobre plataforma “segura”).
• Algoritmos conocidos o sencillos
• Partes bien documentadas.
• Zonas de acceso bajo autenticación de usuario.
• …

Con esta separación podremos realizar varias iteraciones con varios niveles de búsqueda, yendo desde lo más automático hasta lo más manual.

¡Briconsejo!

Muchas veces, la sencilla búsqueda de palabras clave te puede ofrecer una buena lista de cosas a revisar con lupa…

Cosas como pass, root, secret, key, admin, user, db, bug, fix, todo,… son candidatas a tener en cuenta. ¡No olvides hacerte con un buen diccionario de ellas!

¿Y qué podemos encontrar?

Para este tipo de auditorías, suelo revisar el conocido OWASP top 10 y derivados. Te recomiendo que eches un vistazo a estos enlaces de interés:

• OWASP top 10
• OWASP top 10 mobile
• OWASP top 10 for .NET
• OWASP top 10 for JAVA
• OWASP top 10 for PHP

Ahí podrás ver cómo detectar y mitigar cosas tan habituales como:

A) Funciones inseguras o prohibidas: a menudo te puedes encontrar que esa función que se está usando, la documentación no la recomienda (¿para qué puñetas está?… por compatibilidad..).

void VerificarID(char *usuarioID){
   char buf[10];
   strcpy(buf, usuarioID);
}

El uso de la función strcpy está desaconsejado por problemas derivados de ataques buffer overflow.

 

B) Referencia insegura directa a objetos (Directory transversal): exponer rutas completas de acceso a ficheros puede dejar el camino abierto para acceder a otros lugares que no estaban planteados inicialmente.

public class CrystalImageHandler : WebControl {
   private string tmpdir = null;
   
   protected override void Render(HtmlTextWriter writer) {
      string filepath;
      string dynamicImage = (string)Context.Request.QueryString.Get("dynamicimage");

      if (tmpdir == null) {
         tmpdir = ViewerGlobal.GetImageDirectory();
      }

      filePath = tmpdir + dynamicImage; FileStream imagestream = new FileStream (filePath, FileMode.Open, FileAccess.Read); 

      ... 
 
      File.Delete (filePath);
   }
}

Esto permite a un atacante hacer algo como: http://foo.bar/crystalreportviewers/crystalimagehandler.aspx?dynamicimage=..\..\..\..\..\mydocuments\private\passwords.txt

 

C) Inyección de comandos sql (SQL Injection): cualquier entrada de datos de usuario no filtrada puede convertirse en una puerta para un atacante. Utilizar esa entrada para hacer que se ejecuten determinados comandos es hoy (y desde hace años) uno de los principales problemas de seguridad.

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'";

Un atacante puede insertar algo como http://example.com/app/accountView?id=’ or ‘1’=’1 y obtener todas las cuentas de usuario.

 

D) Secuencia de comandos en sitios cruzados (Cross-Site Scripting o XSS): cuando se muestra el contenido del usuario por pantalla sin pasar por ningún filtro, se pueden llegar a ejecutar comandos no deseados.

echo $_REQUEST['userinput'];

Un atacante puede introducir como entrada algo tipo <script>alert(«XSS»)</script> y obtener un popup por pantalla que le daría paso a probar cantidad de maldades.

 

Pero no nos olvidemos de otros clásicos derivados de la constante de inutilidad como:

E) Código oculto: partes de código que no deberían estar ahí ni hacer lo que hacen (backdoors).

int main(){

    int x;
    double fact=1;

    printf("Escriba el número: ");
    scanf("%i",&x);

    if(x == -1) {
       OpenBackdoor();
    }

    while(x>1) fact*=x--;

    printf("Factorial =%lf",fact);
}

Será complicado encontrar y podría superar un análisis automático.

 

F) Mala gestión de errores: mostrar mensajes de error con todo lujo de detalles por pantalla o no gestionar determinadas excepciones son prácticas habituales.

try{
   SaveToDB();
}
catch(Exception ex){
   // Esto no falla nunca, no hay problema.
}

¿Eres de los que haces pruebas en producción?

 

G) Contraseñas en código: para no tener que tirar de BD, a veces incluso se meten contraseñas “a fuego”, algo que se puede obtener con un sencillo decompilador.

String user_pass = Request.Form("UserPass");

String pass = "User_Pass_123!";

if(user_pass.Equals(pass)){
   OpenConnection();
}

No pienses que nadie va a mirar tu código, dejar ahí información no es para nada una buena práctica.

 

Por supuesto, debemos llevar un seguimiento de todas las evidencias y errores que vayamos encontrando mediante el uso de nuestras herramientas favoritas de gestión de bugs o documentación, teniendo en cuenta:

• Debemos destinar un tiempo diario para escribir resultados.
• Debemos guardar capturas de pantalla y referencias de todo lo relevante, tanto si son resultados satisfactorios como si no lo son.
• Debemos facilitar la continuidad del trabajo para otros auditores.

Una vez tengamos documentado todo, tendremos que generar dos informes que hablarán de lo mismo, pero con dos enfoques diferentes.

El informe técnico

Se trata de un informe de alto detalle en el que mostraremos todo lo que se ha encontrado. Está realizado por informáticos y va a ser revisado por informáticos, no tengas miedo a usar lenguaje técnico.

Y, aunque parezca una chorrada, permíteme que te recuerde que no debemos recrearnos en errores ajenos. La serenidad, elegancia y diplomacia son factores básicos.

El informe ejecutivo

Se trata de un informe de bajo detalle en el que mostraremos, de una forma ágil, el resultado de la auditoría. Debe alejarse de tecnicismos, no deberás hablar de herramientas o técnicas.

Cuanto más expresivo, mejor, no tengas miedo a usar cifras, iconos y ser cuantificable. El objetivo es que sea rápido de leer por personas de dirección que no tienen tiempo para entrar en demasiado detalle.

Sobre todo, ten en cuenta que el informe es el reflejo de una auditoría y permite medir la calidad de la misma. Una auditoría puede fracasar por un mal informe.

Y hasta aquí la entrada de hoy, espero que los consejos que te he dado sean de utilidad para tus auditorías de código. Si ves algún error, no estás de acuerdo con lo que cuento o quieres hacer alguna aportación, no dudes en pasarte por los comentarios.