La prueba de penetración es indispensable para evaluar la seguridad de un sistema informático, validar y verificar metódicamente la eficacia de los controles de seguridad informática.
Índice de temas
Qué es la prueba de penetración (o pentest)
Este tipo de análisis está diseñado para evaluar la seguridad de una “aplicación web” -software que interactúa con la red-, por lo que las pruebas abarcan todo el sistema informático de una organización.
Por ejemplo, el análisis de un portal web comienza probando las diferentes funcionalidades, y después se centra en el mecanismo de autenticación y la interacción con las bases de datos. A continuación se analiza la configuración del servidor correspondiente y todos los elementos que lo rodean en la red, y, por tanto, todos los datos y la información que posee una organización.
El “PenTest” es la verificación necesaria para probar que el sistema informático cumple los requisitos de seguridad de sus partes interesadas.
Fortaleciendo la Ciberresiliencia a través de Pentesting
Las pruebas de penetración, o pentesting, desempeñan un papel crucial en el fortalecimiento de la ciberresiliencia de una organización. Al simular ataques cibernéticos reales, el pentesting proporciona información valiosa sobre las vulnerabilidades de seguridad existentes en los sistemas y redes de una empresa. Al identificar estas vulnerabilidades y áreas de debilidad, las organizaciones pueden tomar medidas proactivas para fortalecer sus defensas cibernéticas y mejorar su capacidad para resistir y recuperarse de posibles ataques. En resumen, el pentesting no solo ayuda a detectar y mitigar riesgos de seguridad, sino que también contribuye significativamente a la capacidad de una organización para mantenerse resiliente frente a las amenazas cibernéticas en un entorno digital cada vez más desafiante.
Cómo funciona y cómo se realiza una prueba de penetración
El proceso implica un análisis activo y pasivo del sistema para identificar cualquier debilidad, fallo técnico y vulnerabilidad: estos problemas pueden surgir del diseño, la implementación o la gestión del sistema, y podrían explotarse para comprometer los objetivos de seguridad del sistema y, por tanto, de la empresa.
El objetivo es impedir que un atacante malintencionado -externo o interno- o una inestabilidad del sistema afecten a la confidencialidad, integridad y disponibilidad de los recursos.
Los problemas de seguridad detectados se presentarán al propietario del sistema en un informe, junto con una evaluación del impacto, una solución técnica o, si no es posible, una solución paliativa.
Para realizar una prueba en sistemas que no son de su propiedad, es necesario operar con un contrato que demuestre el consentimiento y la autorización para las actividades, que regule sus objetivos y plazos y, sobre todo, los únicos recursos implicados.
El contrato para las pruebas de penetración y la profesión de probador de penetración
El contrato debe contener cláusulas de confidencialidad, las direcciones IP desde las que se iniciarán las pruebas, las personas físicas responsables y operativas durante la actividad y la posible colaboración con operadores y administradores internos.
La persona que realice una prueba del sistema debe garantizar la no interrupción de las actividades y procesos, la no modificación y pérdida de datos e información de los clientes.
Todas las actividades no reguladas por un contrato deben considerarse ilegales.
Como ya se ha mencionado, los propósitos y objetivos deben quedar claros en el momento del contrato. El propietario del sistema decide qué información compartir con el analista.
Tipos de pentesting
El pentest puede ser realizado por personal interno de IT o testers externos. A segunda de la información de seguridad compartida con el equipo de testers, podemos distinguir tres tipos de pentest:
- Prueba de caja negra (Black box testing) – El tester en este caso no sabe nada sobre la empresa, aparte del nombre, simulando así la situación real de un cracker.
- Prueba de caja blanca (White box testing). Este tipo de prueba se realiza proporcionando a los testers una información precisa sobre el sistema informático y las medidas de seguridad.
- Prueba de caja gris (Grey box testing) – Esta es una solución híbrida, donde el tester tiene limitada información sobre el sistema.
El pentest de caja negra es el más realista, pero también es el más largo y caro; además los resultados dependen mucho de la habilidad del tester. Los hackers éticos son utilizados muy a menudo para este tipo de prueba.
Las pruebas de caja blanca y caja gris son muy específicas, efectivas, y más adecuadas para la mayoría de las empresas.
Se puede llevar a cabo una actividad de prueba compartiendo la dirección de Internet (del cliente propietario) como única información: el objetivo de este tipo de actividad – en jerga “caja negra” – es comprender qué resultados podría obtener un atacante externo a través de Internet. Esta modalidad no suele ser eficaz porque está directamente ligada a las habilidades del analista y al tiempo invertido.
Por lo general, se recomienda compartir más información y detalles -‘caja gris’ o ‘caja blanca’- sobre los servidores y dispositivos de seguridad individuales: en este caso, la persona que lleve a cabo la tarea podrá obtener una visión general del sistema, y la prueba será más eficaz y completa, ya que se centrará en los dispositivos individuales y no solo en el funcionamiento general. La información del sistema y de los dispositivos individuales es fácil de encontrar, pero su recopilación requiere tiempo, que podría emplearse en un análisis más profundo.
El propietario del sistema puede crear un usuario del sistema ad hoc para la actividad de análisis, o más bien un usuario por cada tipo de “rol de usuario” existente en el sistema, y proporcionar credenciales temporales a quien vaya a realizar el análisis. El objetivo es analizar los riesgos externos -como antes- y los riesgos internos: la actividad permitirá comprender qué usuarios pueden leer, modificar o borrar qué recursos, comprendiendo así el verdadero riesgo de un dispositivo manipulado o de un usuario malintencionado dentro del sistema.
Cómo se dividen y cuáles son los tipos de pruebas de penetración
Pruebas de penetración externas
El objetivo de las pentests externas es averiguar si un pirata informático puede entrar en el sistema informático (desde el exterior precisamente), y a qué profundidad puede penetrar en el sistema afectado. Con estas pruebas, se busca todo lo visible en la red (por ejemplo, con Google dork) para intentar encontrar puntos de acceso “descubiertos” (puertas traseras, fallos y errores en el sistema informático, etc.) que podrían permitir al pirata informático entrar (o mejor dicho, “penetrar”) en el sistema.
Por lo general, el probador de penetración lleva a cabo estos ataques sin conocer la infraestructura de la empresa, empezando en su lugar por la web, Internet y las búsquedas en los motores de búsqueda. Algunas cosas que se pueden analizar y probar en estas pruebas externas son: DNS (servidores de nombres de dominio), sitio web, aplicación web y otros.
Pruebas de penetración internas
Una prueba interna suele llevarla a cabo alguien dentro de la organización. Por ejemplo, si un atacante consigue de algún modo obtener las contraseñas y otros datos de acceso de un empleado, entonces podría acceder fácilmente a muchos sistemas internos que solo están disponibles para los empleados de la empresa. Una prueba de penetración interna sirve precisamente para analizar casos de este tipo y encontrar agujeros y fallos en el sistema interno reservado a los empleados.
Pruebas dirigidas
Las pruebas de penetración dirigidas se llevan a cabo conjuntamente por un probador de penetración y el departamento de TI, y sirven principalmente para que el departamento de TI de la empresa se dé cuenta de cuál puede ser la perspectiva de quienes atacan los sistemas, de modo que puedan hacerse más seguros con futuros desarrollos.
Pruebas a ciegas
Este es el ataque más interesante y realista, aunque es el más costoso para la empresa que quiere probarlo, y también costoso en términos de recursos y tiempo por parte del probador. De hecho, en este caso de “prueba a ciegas”, la única información de que dispone el pen tester es el nombre de la empresa. A partir de ahí, tendrá que encontrar la forma de penetrar en los sistemas informáticos de la empresa, utilizando técnicas de pirateo conocidas.
Prueba a ciegas doble
Muy similar a la prueba a ciegas vista anteriormente, la prueba a doble ciego tiene la única diferencia de que el departamento de TI desconoce por completo que se está iniciando este tipo de ataque/prueba. De este modo, se simula un ataque informático real, “a escondidas” de todos los principales actores informáticos de la empresa.
Pruebas de penetración de aplicaciones web (Web Application Penetration Testing)
Se trata de identificar debilidades o vulnerabilidades de seguridad en aplicaciones web y sus componentes, incluido el código fuente, la base de datos y cualquier red de back-end relevante. Un proceso de pentest de aplicaciones web normalmente se compone de las siguientes tres fases: Reconocimiento: recopilación de información sobre la aplicación. Por ejemplo, el sistema operativo (Operative System- OS) y los recursos utilizados por la aplicación. Descubrimiento: detección de las vulnerabilidades. Explotación: utilización de vulnerabilidades detectadas para obtener acceso no autorizado a la aplicación y datos
¿Hacia dónde pueden dirigirse las pruebas de penetración?
Pruebas de penetración de aplicaciones web
Con las pruebas de penetración de aplicaciones web, se puede averiguar si un pirata informático podría poner en peligro la aplicación web de una empresa, ya sea desde dentro o desde fuera. Un pentest de aplicaciones es una prueba de penetración de un sitio web, en busca de las vulnerabilidades más comunes definidas por OWASP (Open Web Application Security Project). A continuación, se estudian las aplicaciones web para encontrar puertas traseras y agujeros en el sistema que hagan vulnerable la aplicación, quizá creados durante el desarrollo o la integración de la aplicación.
Pruebas de penetración de redes inalámbricas
Las pruebas de penetración para vulnerar redes inalámbricas tratan de comprender la facilidad con la que se puede explotar una red utilizando la tecnología inalámbrica. Aquí también se simula el ataque de un atacante malintencionado dentro del perímetro inalámbrico de cobertura de la red.
Prueba de penetración del protocolo VoIP
Una prueba de penetración del protocolo VoIP consiste en recopilar toda la información posible de la red VOIP, entre la toma Ethernet y el teléfono. Por ejemplo, es posible penetrar en los teléfonos IP, en toda la infraestructura telefónica VOIP, en el fraude telefónico de papel de aluminio y comprender así el grado de vulnerabilidad de la red VOIP corporativa.
Prueba de penetración del acceso remoto
Las pruebas de penetración del acceso remoto permiten descubrir las vulnerabilidades debidas al trabajo a distancia, protegiendo así el trabajo remoto. Por lo tanto, es útil realizar pruebas de penetración en los sistemas VDI, Citrix y escritorios remotos utilizados por la empresa, que permiten a sus empleados trabajar en movimiento y a distancia (remotamente), garantizando así la seguridad de toda la estructura informática corporativa.
Cuáles son los tipos de pruebas de penetración (pen tests) en un sistema informático
Las pruebas que se pueden realizar en un sistema informático son de varios tipos, clasificados generalmente en 11 categorías.
Recopilación de información
La recopilación de información sobre el sistema objetivo es el primer paso del PenTest: se realiza un análisis de toda la información que se puede obtener a través de la página web de la organización, los motores de búsqueda, los documentos públicos, las páginas y bases de datos de socios, las redes sociales y cualquier otra cosa que se pueda encontrar en línea, buscando información a través de llamadas telefónicas a la empresa o contactando con antiguos empleados.
Esta es la metodología que se explica en los blogs, pero en la práctica, basta con unas pocas herramientas automáticas para encontrar toda la información necesaria: por ejemplo, un software con funciones de “Evaluación de vulnerabilidades” puede recopilar las versiones del software instalado en unos minutos, y ya es posible saber qué herramientas no están actualizadas y, por tanto, qué vulnerabilidades están presentes.
Nota: todas las herramientas automáticas ayudan a acelerar las operaciones, pero pueden ser muy imprecisas.
Pruebas de gestión de la configuración y el despliegue
Probar la configuración de las herramientas -especialmente las instaladas en servidores- permite comprender el funcionamiento de los dispositivos individuales y de las aplicaciones instaladas en ellos.
Por lo general, es fácil encontrarse con herramientas con “configuración por defecto”: esto significa que los desarrolladores han instalado un software o una red de dispositivos y no han modificado la configuración creada automáticamente durante la instalación y, por ejemplo, puede que aún sea posible autenticarse en una base de datos con las credenciales de instalación “usuario: admin” y “contraseña: admin”.
Es habitual encontrar “archivos de instalación” sin cifrar de herramientas de software, así como notas escritas de los administradores del sistema: esta información ofrece detalles valiosos sobre el funcionamiento de las herramientas y pone de manifiesto errores y vulnerabilidades explotables.
Si una herramienta está mal configurada, además de fallos de funcionamiento y puntos débiles específicos, es muy probable que no se hayan implementado funciones de seguridad; conociendo las carencias técnicas de los administradores del sistema, es probable que también se llegue a otros problemas.
Pruebas de autenticación
Probar los mecanismos de autenticación significa comprender cómo funciona el proceso y detectar cómo se pueden eludir los controles.
La autenticación es el acto de verificar el origen de la comunicación, no solo la identidad de una persona. La autenticación debe depender de varios factores además de la combinación “usuario y contraseña”.
Los mecanismos que garantizan la autenticación son fundamentales para preservar la información. Por ello, es esencial implementar el control de acceso con las herramientas y protocolos más robustos del mercado.
Uno de los principales problemas que se plantean, incluso en las empresas multinacionales, es la gestión inadecuada de los mecanismos de seguridad, y puede bastar con interceptar la autenticación de un usuario y reutilizar el mensaje -aunque esté cifrado para autenticarse.
Pruebas de gestión de identidades
La información de un sistema debe estar protegida, regulando lo que los usuarios pueden leer, modificar y/o borrar. La actividad de la organización debe estar protegida contra todo tipo de riesgos, internos y externos, voluntarios e involuntarios.
En las redes modernas, es imperativo definir los “roles” y los “privilegios” de los usuarios en el sistema para la gestión de los recursos.
La implementación de una herramienta implica básicamente al menos dos roles: ‘administrador’ y ‘usuario’. El primero representa al único usuario al que se le debe permitir el acceso a las funciones de instalación de herramientas y modificación de configuraciones.
Las políticas de la empresa deben regular los poderes sobre los datos de cada usuario, que deben estar asociados a un único individuo. Los administradores del sistema también deben tener poderes limitados: el acceso con privilegios máximos debe ser un hecho excepcional. Cada “regla” debe revisarse periódicamente.
Las pruebas de gestión de identidades también deben analizar el funcionamiento del sistema de gestión de credenciales: los procesos deben garantizar la solidez y la protección de las contraseñas. Por ejemplo, ninguna herramienta debe presentar la lista de usuarios asociada a sus contraseñas, aunque esta información esté encriptada.
Pruebas de autorización
La autorización es el proceso que tiene lugar después de la autenticación, estas dos fases deben estar vinculadas: no debe existir ninguna autorización en un recurso sin autenticación.
El objetivo del análisis de la autorización, a diferencia de los análisis anteriores, es comprender si es posible acceder a los recursos explotando intencionadamente las vulnerabilidades, es decir, realizando ataques reales.
En esta fase, el objetivo es comprender la eficacia del control de acceso y autorización.
El verificador comprobará si es posible acceder a recursos que deberían estar protegidos, por ejemplo, eludiendo el mecanismo de control y/o explotando vulnerabilidades.
Pruebas de gestión de sesiones
Uno de los componentes principales de cualquier aplicación basada en web es el mecanismo de sesión: controla y mantiene el estado del usuario, por ejemplo, para garantizar la identidad y permitir operaciones en varias páginas y a lo largo del tiempo. La “gestión de sesiones” se define como el conjunto de controles -desde el inicio hasta el cierre de sesión- que rigen la interacción entre el usuario y la aplicación web, y entre el usuario y el estado.
Existen diferentes formas en las que una aplicación web puede interactuar con un usuario, en función de los objetivos empresariales, las tecnologías utilizadas, los controles de seguridad y los requisitos de disponibilidad del servicio. Aunque existen directrices que se consideran eficaces para el desarrollo de aplicaciones, es importante que la seguridad de la aplicación se tenga en cuenta al principio de la fase de diseño, así como en el contexto de los requisitos y expectativas del proveedor.
Las actividades de análisis, en esta fase, se centran en comprender la viabilidad real de los ataques, la mayoría centrados en interceptar o redirigir los mensajes intercambiados entre el usuario y el sistema. Un atacante, por ejemplo, no debe tener la posibilidad de analizar y reutilizar -total o parcialmente- los mensajes intercambiados -en forma simple o encriptada- para burlar los mecanismos de control de sesión, a fin de poder operar como un usuario -en la jerga “explotado”- que ya se ha autenticado y obtenido autorizaciones.
En algunos sistemas, todavía es posible interceptar las comunicaciones de un usuario, reutilizar parte de la información de la sesión -en ‘cookies’- para comunicarse con el sistema como un usuario autorizado; al atacante le será posible conocer proyectos, información u otros secretos comerciales.
Pruebas de validación de entrada
La debilidad más común de las aplicaciones web ha sido siempre la falta de control y validación de la entrada -del usuario o del entorno interno y externo.
Nunca se debe confiar en los datos de entrada, ya que pueden ser modificados arbitrariamente por un usuario malintencionado. Las aplicaciones suelen tener un gran número de puntos de entrada, lo que dificulta a los diseñadores y desarrolladores la aplicación de controles. Si el departamento informático no tiene como objetivo la seguridad del sistema, sino solo la minimización del tiempo, se inclinará por omitir todo lo que no sea básicamente necesario para el funcionamiento. Si un usuario malintencionado puede enviar porciones de “código” a través de una aplicación web y hacer que el sistema las “ejecute”, el daño para la organización puede ser considerable.
La falta de validación de la entrada conduce a las vulnerabilidades más conocidas de las aplicaciones web, como el ‘cross-site scripting’, la ‘inyección SQL’ y el ‘desbordamiento del búfer’.
Para explotar este tipo de debilidades no se requieren profundos conocimientos técnicos y teóricos, sino que basta una breve búsqueda en Internet para comprender cómo llevar a cabo un ataque, lo que significa que incluso los atacantes inexpertos pueden constituir una amenaza real.
En los últimos dos años, ha aumentado la atención prestada a estas vulnerabilidades, y los analistas suelen centrarse en este análisis, a riesgo de subestimar la importancia de los demás pasos.
Pruebas del lado del cliente
Las pruebas del lado del cliente se confunden a menudo con las pruebas de validación de entradas. Las pruebas del lado del cliente comprueban si es posible la ejecución voluntaria de código por parte del navegador web, o de plug-ins, instalados en la máquina del usuario. En este caso, la ejecución del código tendrá lugar “del lado del cliente” (por ejemplo, en el ordenador del usuario víctima) y no será ejecutado por el sistema informático, es decir, “del lado del servidor”.
A modo de ejemplo, la inyección de HTML es un tipo de ataque que tiene lugar aprovechando una falta de validación de la entrada, pero el código malicioso es ejecutado por el usuario y no por el servidor -utilizando la página web únicamente como vector-: el atacante inserta código HTML en una página web y cuando esta es cargada por el usuario, el navegador realiza las operaciones. Esta vulnerabilidad específica puede tener muchas consecuencias, como el robo de las “cookies de sesión” de un usuario, que pueden utilizarse para autenticarse con el usuario de la víctima.
Gestión de errores
Un aspecto importante del desarrollo de un sistema seguro es evitar la pérdida de información. Los mensajes de error proporcionan a un usuario malintencionado información detallada sobre el funcionamiento interno del sistema.
El propósito de la “revisión del código” y la gestión de errores es garantizar que la aplicación no proporcione detalles del sistema en condiciones de error esperadas e inesperadas. No se debe presentar al usuario ninguna información sobre el funcionamiento cuando se produce un error.
Por ejemplo, un atacante puede intentar provocar errores deliberadamente y, leyendo los mensajes devueltos por la aplicación, puede entender qué herramientas de hardware y software están presentes en el sistema y, por tanto, comprender qué ataques -‘exploits’- son posibles.
La gestión de errores y excepciones debe implementarse en la fase de desarrollo: todas las rutas que puedan generar un error o una excepción deben comprobarse y gestionarse adecuadamente.
Criptografía débil
Al igual que en el mundo real, cualquier código puede ser descifrado en informática. La robustez de la criptografía se evalúa por el tiempo que se tarda en descifrar los mensajes, con la tecnología disponible: una herramienta automática (gracias a la potencia de cálculo disponible) puede descifrar un mensaje en segundos o en millones de años, según el protocolo utilizado.
Se están estudiando los algoritmos criptográficos y, una vez descubierta la metodología para descifrar un “mensaje”, es decir, el contenido cifrado, el descifrado no autorizado resulta mucho más rápido.
La configuración de las herramientas del sistema debe prever la utilización únicamente de los protocolos que se consideren seguros, comprobando periódicamente su no obsolescencia.
El sistema informático de una organización no debe comunicarse “en claro” -sin utilizar cifrado- ni por rutas inseguras.
Este tipo de análisis consiste principalmente en probar las comunicaciones y detectar los protocolos de comunicación utilizados.
Hay una serie de análisis criptográficos que se están probando, que se utilizan para la investigación científica, o por agencias gubernamentales, y que no se suelen utilizar para trabajos de consultoría, debido a que estas metodologías no se utilizan ampliamente.
Pruebas de lógica empresarial
Las pruebas lógicas sobre procesos informáticos previenen errores y defectos en los procesos, y funcionan del mismo modo que las pruebas de procesos empresariales (por ejemplo, en producción).
Las “funciones” se prueban introduciendo una entrada y examinando la salida, sin tener en cuenta casi nunca la estructura de la herramienta.
Conclusión: formación y consejos para los encargados de las pruebas de penetración
Este tipo de pruebas requiere que los profesionales de la seguridad actúen de forma diferente a las pruebas anteriores, utilizando técnicas de “garantía de calidad” y “control de calidad”.
Hasta la fecha, la automatización de las pruebas no es posible y sigue siendo una actividad manual que depende de las habilidades del probador y de su conocimiento de los procesos empresariales y sus reglas. Las pruebas para detectar fallos en la lógica empresarial de una aplicación web dinámica y multifuncional requieren metodologías que no pueden estandarizarse. Para probar, por ejemplo, un mecanismo de autenticación, es necesario entender los pasos secuenciales del protocolo y verificar el comportamiento del sistema; una posibilidad es cambiar el orden de los pasos y entender qué ocurre.
Por lo general, es difícil para un consultor realizar este tipo de análisis de forma exhaustiva sin que el propietario proporcione información completa sobre el sistema. La actividad se ocupa normalmente de comprobar el mal funcionamiento de componentes individuales.
La seguridad se evalúa en un plazo determinado: el descubrimiento de una vulnerabilidad o un cambio en la configuración de una sola herramienta, por ejemplo, puede aumentar el riesgo para todo el sistema.
Una organización debe invertir en prestar cada vez más atención a las cuestiones de seguridad, e incluyendo las Pruebas de Penetración en el proceso de auditoría continua, se puede conseguir que toda la estructura informática sea segura y estable.
Prohibida su reproducción total o parcial.