Testeo con Privilegios

De acuerdo con el manual para test de seguridad de ISECOM (OSSTMM), realizar un testeo con privilegios, es un "Test donde las credenciales necesarias son suministradas al usuario y los permisos concedidos para testear con dichas credenciales."

Este tipo de test se da dentro de un ámbito de seguridad en el que el entorno del cliente es una caja blanca, amparado por acuerdos de confidencialidad.

De dicho OSSTMM, por el cual nos guiamos para las pruebas de penetración, me permito destacar dos puntos dentro de sus "Lineamientos de Acción".

" . . .
6.3. Si es necesario para pruebas con privilegios, el cliente debe proveer dos mecanismos de acceso independientes, ya bien sean nombres de usuarios y contraseñas, certificados, números de identificación, etc. Estos deben tener los privilegios típicos de los usuarios a ser analizados. (no debe ser cuentas especiales o aseguradas)
6.4. Cuando se ejecuten análisis privilegiados, el analista inicialmente debe probar sin privilegios en un ambiente desconocido o de caja negra y luego probar de nuevo con privilegios en el mismo ambiente.
. . . "

Estos dos ítems enmarcan el caso ante el cual se encuentra todo proyecto de análisis de vulnerabilidades que haya venido realizado análisis de "caja negra" tanto en las pruebas de penetración a los Activos Críticos y el Análisis estándar en las diferentes fases y ciclos del proyecto. En algún momento se debe llegar al análisis de "caja blanca" o con privilegios, alcanzando un anillo de seguridad más profundo.

Técnicamente, este tipo de test es importante en casos como:
1. La mayoría de pruebas de inyección OSWAP desde la OWASP-DV-005 hasta OWASP-DV-014.
2. Evaluación de la configuración del sistema vulnerable, es decir, poder determinar valores específicos del Registro en el kernel del sistema.
3. Explotación de buffer overflows en procedimientos almacenados.
4. Anticipar ataques de usuarios válidos como visitantes eventuales, empleados o administradores con fines maliciosos.
5. Procedimientos almacenados al alcance de usuarios de bases de datos.
6. Pruebas de escalado de privilegios.

Es importante aclarar que el análisis usando privilegios, se hace con algoritmos seguros (no intrusivos), hasta tanto el objetivo se haya blindado y etiquetado oficialmente como "Asegurado".

Herramientas

• Verificar que se ha desactivado telnet usando nmap
  Cuando telnet está activo en su puerto por defecto (23/tcp) se puede descubrir con este comando:
  
  nmap -T4 -n -p23 192.168.0.100
  
  La respuesta en mi LAN es:
  Starting Nmap 4.52 ( http://insecure.org ) at 2009-07-02 20:26 COT
  Interesting ports on 192.168.0.100:
  PORT STATE SERVICE
  23/tcp open telnet
  Nmap done: 1 IP address (1 host up) scanned in 0.065 seconds
  
  Como podemos notar en la línea correspondiente, 23/tcp está abierto. De estar cerrado diría:
  PORT STATE SERVICE
  23/tcp closed telnet
  Lo cual es lo que se espera al desactivar este servicio.
  
  
• Wireshark (analizador de protocolo)
  Permitió comparar una sesión telnet con una ssh con los siguientes resultados:
  Telnet
  Todo lo que se digitó (incluso claves de ecceso) se leen en texto claro.
  SSH
  Todo lo digitado es ilegible ya que está cifrado.
  
  
• telnet
  Como cliente, nos permite ver versiones de servicios como ssh o http. En el siguiente ejemplo
  nmap nos encuentra puertos abiertos en 192.168.0.1 y después telnet la versión del servicio:
  
  # nmap -T4 -n 192.168.0.1
  
  Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2009-07-04 13:26 COT
  Interesting ports on 192.168.0.1:
  (The 1657 ports scanned but not shown below are in state: closed)
  PORT STATE SERVICE
  22/tcp open ssh
  80/tcp open http
  1720/tcp filtered H.323/Q.931
  
  Nmap run completed -- 1 IP address (1 host up) scanned in 10.900 seconds
  # telnet 192.168.0.1 22
  Trying 192.168.0.1...
  Connected to 192.168.0.1 (192.168.0.1).
  Escape character is '^]'.
  SSH-2.0-1.00
  
  # telnet 192.168.0.1 80
  Trying 192.168.0.1...
  Connected to 192.168.0.1.
  Escape character is '^]'.
  ^[
  
  HTTP/1.0 400 Bad Request
  Server: Embedded HTTP Server 2.42
  Connection: close
  

Pasos remediación

• Usar su FAV (Falcon Análisis de Vulnerabilidades http://analisisdevulnerabilidades.com/ ) para encontrar Vulnerabilidades, gráficas de estado y reportes.

• Revisar lista de códigos CVE (Common Vulnerabilities and Exposures) y su calificación CVSS (Common Vulnerability Scoring System). Estos códigos nos sirven para tener un punto de referencia claro a partir del cual comparar, son un termómetro de la gravedad de las vulnerabilidades y en su sitio web encontramos amplia información sobre el caso buscando el código (http://cve.mitre.org/find/index.html).
  
• Buscar soluciones y aplicarlas. Los reportes que recibimos sugieren soluciones. Por ejemplo, si es un parche de Windows, se puede aplicar con WSUS. Si es una clave débil, hay que fortalecerla. Si es una actualización en Linux, usar yum o apt-get, etc (dependiendo de la distribución).
  
• Obtener reportes comparativos. Una vez remediemos, podemos solicitar a FAV un comparativo, que nos dice que tan efectivo fue nuestro trabajo de remediación (http://analisisdevulnerabilidades.com/index2.html).