Prueba de penetración

Prueba de penetración
Información sobre la plantilla
Pruebapenetracion.jpeg
Concepto:Son la estrategia más efectiva para evaluar tanto la competencia como las necesidades de una red computacional o una aplicación web. Una prueba de penetración simula un ataque desde afuera y proporciona un riguroso examen de vulnerabilidades actuales y potenciales, incluyendo fallas de software y hardware, configuraciones defectuosas del sistema, medidas de protección insuficientes, y más.

Prueba de penetración. Es la mejor opción para evidenciar debilidades y vulnerabilidades de una manera segura. También llamado a veces "hacking ético" es una evaluación activa de las medidas de seguridad de la información. En los entornos de red complejos actuales, la exposición potencial al riesgo es cada vez mayor y securizar los sistemas se convierten en un auténtico reto. A través del Test de Penetración es posible detectar el nivel de Seguridad Interna y Externa de los Sistemas de Información de la empresa, determinando el grado de acceso que tendría un atacante con intenciones maliciosas. Además, el servicio chequea las vulnerabilidades que pueden ser vistas y explotadas por individuos no autorizados, "crackers", agentes de información, ladrones, antiguos empleados, competidores, etc.

Servicios de Test de Penetración

  • Evaluar vulnerabilidades por medio de la identificación de debilidades de configuración que puedan ser explotadas.
  • Analizar y categorizar las debilidades explotables basadas en el impacto potencial y posibilidad de ocurrencia.
  • Proveer recomendaciones prioritizadas para mitigar y eliminar las debilidades.

Riesgos de las pruebas de penetración

DISPONIBILIDAD. De acuerdo con Chapela, durante la aplicación de las pruebas es necesario minimizar el peligro de interrupciones no programadas en servicios o procesos. Para esto, es necesario calendarizar las irrupciones de alto riesgo, desarrollar un plan de respaldo y conformar un equipo de respuesta capaz de actuar con rapidez. Además, debe determinarse con toda claridad qué probar y qué no. Tal es el caso de hardware y aplicaciones obsoletas, aplicaciones críticas, equipo sin respaldo –o carente de un plan de contingencia– y sistemas fáciles de colapsar cuando se examinan.

CONFIDENCIALIDAD. Para evitar que se pierda o fugue contenido valioso durante el desarrollo de las pruebas, debe establecerse claramente qué pueden copiar o leer quienes las ejecuten. Asimismo, conviene hacer un cambio completo de códigos de acceso al final de los ejercicios de penetración y establecer algunas prohibiciones, como: no copiar ni leer correo electrónico o información de bases de datos o archivos. Sobre este punto, Rafael García, gerente regional de productos de Symantec para América Latina, detalla: "Los Pen Tests deben involucrar todas aquellas áreas que están más relacionadas con el core del negocio, por lo que la metodología a emplear y sus límites dependen siempre del giro de la empresa, el grado de profundidad de las pruebas y el análisis requerido. En este marco, debe privilegiarse la firma de acuerdos de secrecía en los contratos y dar prioridad a la honestidad de los consultores".

INTEGRIDAD Y RESPONSABILIDAD. Durante el desarrollo de las pruebas, las empresas deben reducir al mínimo la probabilidad de alteraciones en aplicaciones o datos. Por lo tanto, entre las prohibiciones a fijar a quienes las ejecutarán están: no instalar jamás puertas traseras (back doors), ni ocultar soluciones de acceso remoto (bots, troyanos, rootkits y demás); no borrar, alterar o inhabilitar registros y, desde luego, no apagar o modificar el comportamiento de las herramientas de detección establecidas. Un punto muy importante en todo esto es registrar quién hace qué, para evitar abuso de terceras partes en los Pen Tests, así como dejar claro que no deben eliminarse u ocultarse los rastros de las pruebas. Este proceso implica también autenticar a los consultores, con el propósito de identificarlos claramente en los sistemas evaluados.

RIESGO POLÍTICO. ¿Qué pasa si una falla no prevista en ciertos servicios críticos ocurre como resultado de las propias pruebas? Deben minimizarse las probabilidades de que se generen choques internos entre las diferentes áreas involucradas o confrontaciones con proveedores, y evitar factores que reduzcan el valor percibido o el profesionalismo de las pen test. “Dada la lucha de poder entre áreas que existe, en algunas empresas, — asegura García—si el departamento de sistemas es el encargado de contratar las pruebas debe sentirse respaldado previamente por la alta dirección, para que los resultados, sobre todo si no son del todo positivos, no se utilicen como arma de pugnas”.

INCUMPLIMIENTO. Diversas pruebas de penetración buscan dar cauce a requerimientos legales y regulaciones para evitar multas o sanciones a la hora de efectuarlas. Asimismo, los resultados de la revisión van de acuerdo con los lineamientos y estándares corporativos aplicables en cada caso (ISO 27001 / BS 7799, CoBIT, ITIL y demás). Danny Allan, analista de investigación de la empresa Watchfire, hace énfasis en la carga creciente que toma el cumplimiento de todo tipo de regulaciones. No sólo para cuestiones técnicas, sino también en temas que tienen que ver con rubros como: competencia, protección de datos, privacidad, terrorismo, operaciones de outsourcing, reputación y propiedad intelectual, entre otros.

RIESGOS DE CONTRATO. Este tipo de incidentes surge al emplear consultores inapropiados. Para evitarlos, deberá evaluarse correctamente al proveedor del servicio y definir un plan de riesgos bien estructurado. Desde luego, no se debe contratar a asesores que sólo usan herramientas o únicamente conocen un aspecto de la tecnología. Además se debe ser cuidadoso al utilizar los servicios de aquellos que fueron black-hat hackers y ahora se han convertido en “especialistas” en Pen Test. Incluso, el Consejo Internacional de Consultores de Comercio Electrónico (The International Council of E-Commerce Consultants: EC-Council) propone una certificación en hackerismo ético, que cubre pruebas de penetración y directrices sobre cómo actuar en la materia. La recomendación de no emplear black-hat hackers tiende a convertirse así en una de las mejores prácticas a seguir. Si se consideran todos estos riesgos y se actúa en consecuencia para mitigarlos, las pruebas de penetración se vuelven un ejercicio útil, que puede aportar diversos puntos positivos a las empresas.

Beneficios de las pruebas de penetración

GENERAR INFORMES OPORTUNOS. Un buen informe de los riesgos y vulnerabilidades de una empresa, derivado de las pruebas de penetración, funge como herramienta efectiva de negociación para reafirmar o vender las estrategias de seguridad a la alta dirección, además de sostener y legitimar todo el proyecto de protección, por lo que el mencionado documento debe estar completo, bien hecho y sin errores. Entre los puntos que debe contener este informe están: un resumen para la alta administración; un análisis de los riesgos principales; recomendaciones agrupadas por tipo de dispositivo, sistema operativo, bases de datos o servidores de dominio, y las acciones concretas a seguir.

De acuerdo con Sm4rt, el informe (que deberá realizar el área de seguridad) requiere incorporar, además, acciones de mitigación priorizadas y clasificadas por esfuerzo, enfatizando detalles técnicos y recomendaciones; así como evidencia de las principales vulnerabilidades encontradas. Pero también deberá incluir una clasificación de riesgos, y una evaluación que considere tres conceptos: valor de los activos, nivel de debilidades y probabilidad de ataques.

Un autor bien conocido como Pete Herzog (Open Source Security Testing Methodology Manual: OSSTMM), sugiere, al respecto, una metodología dividida en secciones, módulos y tareas, en la que propone desarrollar un “mapa de seguridad” con seis apartados: información, procesos, tecnologías de Internet, comunicaciones, protección inalámbrica y física como base para la evaluación de riesgos.

DAR ÉNFASIS A LA ESTRATEGIA. Los Pen Test permiten priorizar riesgos y proponer acciones, con acento en las áreas alrededor de las amenazas principales. Las buenas pruebas ayudan a entender por qué los problemas pueden ser críticos, mientras dan sentido y dirección a los cambios sugeridos. El plan de acción que derive de las pruebas debe considerar el impacto desde el punto de vista de la probabilidad de ataques, vulnerabilidad y valor de los activos, así como el esfuerzo a realizar en materia de planeación, implementación y administración.

En todo caso, las pruebas de penetración más eficaces permiten correlacionar el impacto de los riesgos y su probabilidad, encontrando el punto óptimo para cada empresa.

CONTAR CON UN CATALIZADOR EFECTIVO. Los Pen Tests sirven también para: motivar el cambio hacia el incremento de controles, enfocar los esfuerzos técnicos, generar conciencia y sentido de urgencia. Pero, si de verdad se quiere lograr esto es necesario organizar una demostración final de los ejercicios de irrupción, pues de acuerdo con Chapela: “esto dice más que mil documentos”.

Y para cerrar el círculo conviene también organizar una reunión técnica con el fin de valorar a detalle los hallazgos, definir la forma de presentarlos a la alta dirección y trazar la estrategia a seguir. Entre las prohibiciones a fijar entre quienes ejecutarán las pruebas están: no instalar jamás puertas traseras (back doors), ni ocultar aplicaciones de acceso remoto (bots, troyanos, rootkits y demás); no borrar, alterar o inhabilitar registros y, desde luego, no apagar o modificar el comportamiento de las herramientas de detección establecidas.

Entre los puntos que debe contener el informe posterior a las pruebas de penetración están: un resumen para la alta administración; un análisis de los riesgos principales; recomendaciones agrupadas por tipo de dispositivo, sistema operativo, bases de datos o servidores de dominio y las acciones concretas a seguir.

Tipos de pruebas de penetración

Las pruebas giran en torno a la variación, es decir, detectar los aspectos del software y su entorno que pueden haber variado y ver cómo responde el software. El objetivo consiste en garantizar que el software funcione de una manera confiable y segura en escenarios de producción tanto razonables como, incluso, no razonables. Por lo que la planeación más importante que debe llevar a cabo un evaluador es conocer los aspectos que pueden variar y de qué formas dicha variación necesita configurarse para las pruebas.

Desde el punto de vista de la seguridad, el entorno, la entrada de usuario, así como los datos y lógica internos son los lugares principales donde dicha variación puede revelar problemas de seguridad. El entorno consiste en los archivos, aplicaciones, recursos del sistema y otros recursos locales o de red que la aplicación use. Cualquiera de éstos podría ser el punto de entrada de un ataque. La entrada de usuario la constituyen los datos que se originan con entidades externas (normalmente no confiables) que el software analiza y usa. Los datos y lógica internos son las variables y rutas lógicas almacenadas internamente que tienen cualquier número de enumeraciones potenciales.

Ataques del entorno

El software no se ejecuta aislado. Depende de cualquier número de archivos binarios y módulos de código equivalente, como scripts y complementos. Puede usar también información de configuración del Registro o del sistema de archivos, así como de bases de datos y de servicios que podrían residir en cualquier parte. Cada una de estas interacciones del entorno puede constituir la fuente de una infracción de seguridad y, por lo tanto, deben someterse a prueba.

Hay también una serie de preguntas importantes que debe plantearse acerca del grado de confianza que la aplicación posee en estas interacciones, incluidas las siguientes: ¿Qué grado de confianza posee la aplicación en su entorno local y en los recursos remotos? ¿Coloca la aplicación información confidencial en un recurso (por ejemplo, el Registro) que pueda leerse por otras aplicaciones? ¿Confía en cada uno de los archivos o bibliotecas que carga sin comprobar el contenido? ¿Puede un atacante aprovechar esta confianza para obligar a la aplicación a hacer lo que éste desee?

Además de estas cuestiones acerca de la confianza, los evaluadores de penetración deben observar los DLL que puedan estar defectuosos o que un atacante haya podido reemplazar (o modificar), archivos binarios o archivos con los cuales la aplicación interactúe y que no estén completamente protegidos a través de listas de control de acceso (ACL) o que se encuentren desprotegidos de cualquier otra manera. Los evaluadores deben estar también pendientes de otras aplicaciones que tengan acceso a recursos de memoria compartida o que almacenen datos confidenciales en el Registro o en archivos temporales. Por último, los evaluadores deben considerar factores que generen sobrecarga en el sistema como, por ejemplo, una red lenta, memoria baja, etc., así como determinar el impacto de estos factores en las características de seguridad.

Los ataques del entorno se llevan a cabo, a menudo, organizando de forma malintencionada un entorno inseguro y ejecutando, a continuación, la aplicación en ese entorno para ver cómo responde. Se trata de una forma indirecta de pruebas; los ataques se emprenden contra el entorno en el cual funciona la aplicación. Observemos ahora las pruebas directas.

Ataques de entrada

En las pruebas de penetración, el subconjunto de entradas que procede de fuentes que no son de confianza es el más importante. Éstas incluyen rutas de comunicación como, por ejemplo, protocolos de red y sockets, funcionalidades remotas expuestas como DCOM, llamadas a procedimiento remoto (RPC, Remote Procedure Calls) y servicios web, archivos de datos (binarios o de texto), archivos temporales creados durante la ejecución y archivos de control como scripts y archivos XML, todos los cuales están sujetos a manipulaciones. Por último, deben comprobarse también los controles de interfaz de usuario que permiten la entrada directa del usuario como, por ejemplo, las pantallas de inicio de sesión, los clientes web, etc.

En especial, deseará determinar si la entrada está controlada adecuadamente: ¿Se permiten las entradas consideradas seguras y se evitan las no seguras (por ejemplo, cadenas largas, paquetes formados incorrectamente, etc.)? La comprobación de entradas adecuadas y el análisis de archivos son críticos.

Necesitará realizar pruebas para ver si se pueden llevar a cabo entradas peligrosas en los controles de la interfaz de usuario y para averiguar qué podría ocurrir en caso de que esto se produjera. Esto incluye caracteres especiales, entradas codificadas, fragmentos de scripts, cadenas de formato, secuencias de escape, etc. Necesitará determinar si es posible que penetren cadenas largas que se encuentran incrustadas en los campos de paquetes o en los archivos y que puedan provocar el desbordamiento de la memoria. Los paquetes dañados en las secuencias de protocolo constituyen también una preocupación. Debe vigilar la presencia de bloqueos y comprobar la pila por si existieran vulnerabilidades potenciales en la memoria. Por último, debe estar completamente seguro de que tanto la validación como los mensajes de error ocurren en el lugar correcto (en el lado cliente y no en el lado servidor), esto constituirá una defensa apropiada frente a las entradas no seguras.

Los ataques de entrada constituyen auténticos ataques de artillería contra una aplicación. Algunos de ellos podrán esquivarse adecuadamente, mientras que otros provocarán daños en el software. Dependerá del equipo de penetración determinar qué ataques se considerarán ataques de entrada, así como la aplicación de las soluciones apropiadas.

Ataques de datos y de lógica

Algunos errores se encuentran incrustados en los mecanismos internos de almacenamiento de datos de la aplicación y en la lógica de algoritmos. En dichos casos, parece haber errores de diseño y de codificación en los que el desarrollador ha asumido la presencia de un usuario benevolente o bien no se dio cuenta de la presencia de ciertas rutas de código en las que el usuario debe tener cuidado.

La denegación de servicio es el ejemplo principal de esta categoría, pero no la más peligrosa. Los ataques de denegación de servicio pueden realizarse correctamente si los desarrolladores han cometido errores en la planeación para un amplio número de usuarios (o conexiones, archivos, así como cualquier entrada que provoque que ciertos recursos se sobrecarguen hasta el límite). No obstante, existen defectos lógicos mucho más insidiosos que necesitan someterse a prueba. Por ejemplo, la divulgación de información puede ocurrir cuando las entradas que controlan los mensajes de error y otros resultados generados revelen información vulnerable a un atacante. Un ejemplo práctico de los datos que deben eliminarse siempre sería cualquier cuenta de prueba codificada o API de prueba (las cuales se incluyen, con frecuencia, en compilaciones internas para ayudar en la automatización de las pruebas).

Esto podría facilitar el acceso a un atacante. Dos pruebas más que debería ejecutar son la introducción de credenciales falsas para determinar si los mecanismos internos de autorización son seguros, así como la elección de entradas que varíen las rutas de código. La mayoría de las rutas de código son seguras, pero es posible obtener acceso a la misma funcionalidad de maneras diferentes, lo cual podría omitir de forma inadvertida algunas comprobaciones cruciales.

Herramientas para realizar pruebas de penetración

  • Inguma: es una herramientas para realizar de prueba de penetración escrita enteramente en python. El framework incluye los módulos para descubrir los hosts, información sobre ellos, sacar nombres de usuario y las contraseñas por fuerza bruta y por supuesto exploits para muchos productos.
  • DSniff: Un juego de poderosas herramientas de auditoría y pruebas de penetración de redes. Este popular y bien diseñado set hecho por Dug Song incluye varias herramientas. dsniff, filesnarf, mailsnarf, msgsnarf, urlsnarf, y webspy monitorean pasivamente una red en busca de datos interesantes (passwords, e-mail, archivos, etc.). arpspoof, dnsspoof, y macof facilitan la intercepción de tráfico en la red normalmente no disponible para un atacante -- por ej. debido al uso de switches {"layer-2 switches"}. sshmitm y webmitm implementan ataques del tipo monkey-in-the-middle activos hacia sesiones redirigidas de SSH y HTTPS abusando de relaciones {"bindings"} débiles en sistemas con una infraestructura de llaves públicas {PKI} improvisados.

Fuente