Del Penetration Test a La Realidad_Ardita

7/23/2019 Del Penetration Test a La Realidad_Ardita

http://slidepdf.com/reader/full/del-penetration-test-a-la-realidadardita 1/19

Página 1

Del Penetration Test a la realidad

Autor: MSc. Julio C. Ardita ( [email protected])

Resumen: Analizar la evolución de las metodologías y técnicas de Penetration

Test (Evaluación de la Seguridad) desde sus comienzos hasta llegar al día de

hoy, determinar que problemática enfrenta y que trata de resolver, describir cual

es la utilización real del mismo y que futuro tiene esta técnica.

Introducción

Los Penetration Tests (PT) se encuentran de moda en todo el mundo y debido a

su rápido avance no existen metodologías ni estándares oficiales adoptados sobre

los mismos. Las técnicas y metodologías de PT van avanzando con la

investigación a nivel mundial de diferentes equipos y personas y con Internet como

medio de comunicación.

Hoy, existen cientos de empresas y personas que realizan PT diariamente con

metodologías parecidas y a veces con resultados totalmente diferentes, debido a

que no existe una profesionalización en el área.

¿Qué es el Penetration Test?

Es un conjunto de metodologías y técnicas de intrusión aplicadas sobre un

sistema en un tiempo determinado con el objetivo de conocer el nivel de seguridad

informática real del mismo, detectado y explotando vulnerabilidades.



Página 2

Formalmente el Penetration Test es una parte del proceso de seguridad

informática de una organización.

¿Qué no es el Penetration Test?

No es una auditoría de seguridad completa y tampoco es un análisis de

vulnerabilidades de seguridad informática. Según el FFIEC (Federal Financial

Institutions Examination Council) los PT, auditorías de seguridad y análisis de

vulnerabilidades pueden utilizar las mismas herramientas en sus metodologías,

pero la naturaleza de los mismos es diferente.

Historia del Penetration Test

El PT tuvo un nacimiento muy confuso, no se sabe exactamente donde nació, y se

ubicó como una nueva rama dentro de la seguridad informática. Originalmente, los

primeros PT testeaban redes x.25, conexiones dial-up, accesos remotos,

servidores y servicios internos (raramente correctamente configurados), etc.

Con el nuevo posicionamiento de la seguridad informática y auge de Internet, el

PT fue evolucionando desde sus comienzos hasta llegar a ser algo muy completo

y complejo, que incluye permanentemente nuevas técnicas.

¿Cuál es la realidad del PT?

Hoy el PT enfrenta una realidad muy compleja, debido a la desinformación que

existe. Son muy pocas las organizaciones que tienen en claro para que contratan



Página 3

un PT, que alcance le dan, si están preparadas para recibir los resultados

(normalmente malas noticias) y si realmente valoran el trabajo realizado.

Las recomendaciones que surgen en los PT en muchos casos no son

implementadas.

Existe un desconocimiento general sobre la “calidad” de un PT y sobre como

“medir” un PT (no si fue exitoso o no, sino si realmente se realizaron las tareas

que corresponden y no quedaron falsos negativos). Esto genera una amplia oferta

que abarca desde estudiantes que corren una herramienta hasta equipos de

expertos con un elevado know-how y experiencia.

¿Dónde se ubica el PT?

El PT forma parte del proceso de la seguridad informática. Su misión comienza

una vez que las políticas de la organización han sido implementadas sobre los

sistemas de información. Utilizando técnicas intrusivas se demuestran las

vulnerabilidades que ponen en riesgo la confidencialidad, integridad y

disponibilidad de la información. Y nos da un punto de partida sobre el cual

comenzar a ajustar las políticas de la organización.

¿Qué incluye el PT?

En muchos lugares, el PT es sinónimo de PT de Internet, es decir, focalizado en

Internet. La gran mayoría de los documentos, papers y estándares se abocan a

describir como hacer un PT en Internet con lo clásico (arin, whois, ping, traceroute,

nmap, nessus, securityfocus BID e informe).



Página 4

Los PT generalmente se pueden dividir en dos grandes líneas: externos e

internos.

§ Los PT externos apuntar a analizar el nivel de seguridad real de una

organización desde el exterior y deberían incluir módems, centrales telefónicas,

accesos remotos, Internet, conexión con sucursales, otras conexiones

externas, redes wireless, etc.

§ Los PT internos se focalizan en analizar el nivel de seguridad real de una

organización a nivel interno, incluyendo análisis de la infraestructura de la red,

estaciones de trabajo, servidores, aplicaciones, etc.

Los PT cada vez son más abarcativos e incluyen nuevos protocolos, equipos,

tecnologías (aplicaciones web, software ERP, SAN, etc) y también incluyen

nuevas técnicas (Cross-site-scripting, Sql-injection, Buffer-overflow, Format-

strings y técnicas anti-IDS entre otras).

Vulnerabilidades de seguridad y PT

Las vulnerabilidades de seguridad informática tienen una relación directa con los

PT: mientras se sigan descubriendo nuevas vulnerabilidades, siempre será

necesario realizar nuevos PT.

Existen hoy en día más de 13.000 vulnerabilidades de seguridad informática y

están apareciendo aproximadamente 4.000 más por año, ésto implica que las

organizaciones deben seguir una fuerte política de actualización y mantenimiento

de sus sistemas informáticos. Si una organización no está al día, el PT tendrá un

resultado positivo.



Página 5

El mismo problema se repite con aspectos de configuración de los sistemas y

equipos informáticos, si la organización no realiza la instalación y configuración de

forma adecuada, nuevamente el PT tendrá un resultado positivo.

Conociendo esta problemática, ¿vale la pena realizar un PT al año?, ¿conviene

realizar dos, tres, cuatro, seis PT al año?. Mientras se realicen PT con más

frecuencia, más cerca se estará de cerrar la brecha entre la nueva vulnerabilidad y

la posibilidad que un intruso pueda explotarla.

Los PT brindan un gran aporte a la seguridad informática debido a que muchas

vulnerabilidades son descubiertas durante la realización de los mismos.

Normalmente las empresas de software realizan auditorías de seguridad sobre sus

productos antes de lanzarlos al mercado. Sin perjuicio de eso, la mayoría de las

vulnerabilidades surgen cuando se realizan PT independientes a organizaciones

que comienzan a utilizar estos nuevos productos.

Justificación del PT

¿Por qué una organización decide realizar un PT?. La realidad demuestra que las

razones pueden ser varias:

§ Conocer la situación real de un sistema y mejorarlo.

§ Demostrar los riesgos existentes.

§

Justificar la obtención de más recursos económicos.

§ Verificar que los mecanismos de seguridad se encuentren funcionando

correctamente.

§ Por regulaciones y/o obligación.



Página 6

§ Como un seguro para poder cubrirse ante auditorías.

§ Para poder dormir a la noche.

¿Qué es lo que la organización espera del PT?

Formalmente la organización espera conocer los riesgos a los cuales se ven

sometidos los sistemas informáticos.

La experiencia demuestra que la mayoría de las veces, las empresas que piden

PT están en un cierto grado de maduración en relación a la seguridad informática.

Salvo algunos casos, las organizaciones esperan que los resultados del PT sean

positivos para ellos (es decir que esté todo bien y no se encuentre nada). Pero la

mayoría de las veces las organizaciones no están preparadas para recibir malos

resultados.

¿Cómo es visto el PT dentro de la organización?

Las organizaciones están compuestas por personas, con lo cual cada área de la

organización va a tener su visión del PT ligada también a que área fue la que lo

solicitó. Se han definido cuatro categorías: CEO, Seguridad Informática, Gerente

de Sistemas, Técnicos y Auditoría Interna de Sistemas.

Normalmente se genera una “competencia” que aunque en la teoría no se

demuestre, en la práctica es un tema de orgullo en relación a los sistemas

informáticos. Pasa por un aspecto psicológico de que otra persona critique “algo”

que “es mío”.

Muy pocas veces se ve al PT como una ayuda.



Página 7

La gran mayoría de las veces, el PT genera “mucho” nuevo trabajo para poder

corregir los problemas que se detectan.

¿Qué pasa luego del PT?

Luego de presentados los informes técnicos sobre el resultado del PT se genera

una nueva problemática: la correcta aplicación de las recomendaciones emanadas

de los informes. La frase “del dicho al hecho hay un gran trecho” describe de la

mejor manera esta problemática.

Las recomendaciones muchas veces son redactadas sin tener en cuenta el

entorno operativo, ésto provoca que incluso muchas recomendaciones sean

técnicamente inviables.

En las organizaciones suelen darse dos casos: el área de seguridad informática es

la que implementa los cambios o es la que supervisa al área de soporte técnico

que es quien realiza on-hands los cambios.

En cualquiera de los dos casos, se definen las acciones a seguir (cambio de

parámetros, aplicación de patches, upgrades de versiones, modificaciones al

código, etc.) y luego se comienza con el Plan de Implementación de las mismas.

Luego de varios meses, ¿se han aplicado las recomendaciones propuestas?.

Poniendo varias excusas como ser: no hay recursos humanos suficientes, no se

pueden probar los cambios en entorno de prueba (porque no existe), no se puede

realizar un upgrade de versiones (el proveedor confirmó que la aplicación deja de

funcionar), no hay recursos económicos, etc; el resultado final es que no se

aplican. Sólo se aplican los cambios que implican un alto riesgo.



Página 8

Para esta problemática se ha propuesto una solución que radica en la clasificación

de todos los problemas encontrados con dos variables: nivel de riesgo y

posibilidad de resolución.

El nivel de riesgo puede ser alto, medio o bajo.

La posibilidad de resolución puede ser inmediata, a corto plazo, a mediano plazo o

a largo plazo.

Jugando con estas dos variables para cada problema detectado en el PT, se

puede hacer una clasificación y un orden de solución.

¿Cómo medir la calidad de un PT?

Es muy difícil, ya que no existen estándares ni organismos controlantes.

La calidad puede diferir muchísimo entre un PT de una empresa A y otro de la

empresa B.

Los factores principales que inciden son:

§ Conocimiento del equipo que realiza el PT.

§ Experiencia en la realización del PT.

§ Forma de redacción de los informes.

§ Presentación e interacción con la organización.

Sin duda, el más importante es el nivel de conocimiento, ya que un PT contratado

a una empresa A puede dar como resultado que la organización está muy bien

(por desconocimiento o por un alcance mal definido) mientras que un PT

contratado a una empresa B puede dar resultados negativos para la organización.



Página 9

El problema surge cuando la organización debe contratar un PT, ¿cómo saber de

las empresas que ofrecen este servicio cuáles son realmente buenas?. Las claves

para una correcta elección son confianza, antecedentes, presencia, etc.

PT Continuos

Las organizaciones deben hacer PT continuos: cada un año, seis meses, tres

meses, etc. ¿Conviene entonces utilizar siempre la misma empresa para realizar

los PT?.

Si utilizamos la misma empresa contamos con la ventaja de la confianza y que se

conoce su nivel de conocimiento. La principal desventaja es que se pierde

objetividad, ya que la empresa que realiza el PT conoce la infraestructura utilizada

y las posibles vulnerabilidades que pudieran existir a priori.

Si utilizamos diferentes empresas cada vez que se realiza un nuevo PT contamos

con la ventaja de que cada vez las empresas tendrán que comenzar de nuevo y

podremos comparar niveles de calidad, etc. Las desventajas son tener que

establecer nuevas relaciones comerciales y tener un nivel de desconfianza inicial.

Costo del PT

Los PT cuestan dinero, es un hecho y hay que aceptarlo. Ahora, existen muchas

diferencias de costos basadas en varios factores.

El primer factor es el lugar, el costo de un PT realizado en Europa es parecido al

de Estados Unidos, pero muy diferente al costo en Latinoamérica. Cabe aclarar



Página 10

que el costo en este caso no implica nivel de calidad. Este factor se basa en el

valor de hora de los miembros del equipo que realizan el PT.

El segundo factor son los recursos técnicos involucrados. La empresa que realiza

el PT puede utilizar notebooks de última generación, licencias de software de

seguridad informática que tienen un elevado costo, desarrollo de aplicaciones

propias, etc.

El tercer factor está basado en el conocimiento y experiencia del equipo humano

que realiza el PT: si el equipo está compuesto por expertos con años de

experiencia y know-how en el campo o si está formado por estudiantes con un

nivel básico.

El cuarto factor es la correcta definición del alcance. Este es uno de los factores

clave para la determinación del costo, ya que en base al alcance se definirá el

tiempo que durará el PT.

La suma de todos estos factores definirá el costo final del PT; igualmente el

mercado mediante la ley de oferta/demanda también determina estos factores.

¿Cuál es el resultado ideal de un PT?

¿Que no se detecten vulnerabilidades o problemas de seguridad sobre los

sistemas evaluados?. ¿Que se pueda acceder como administrador a sistemas

críticos de la organización?. Todo depende del punto de vista con el que se mire.

El éxito desde la perspectiva del equipo que lleva adelante el PT puede no

equivaler al éxito desde la perspectiva de la organización.



Página 11

Si hablamos desde la empresa que realiza el PT, formalmente sería exitoso si el

equipo logra “ingresar” a los sistemas de la organización. La pregunta ahora es,

¿qué es ingresar?. Es poder visualizar información confidencial, ejecutar

comandos sobre un determinado sistema, dejar archivos, etc.

Si hablamos desde la organización, generalmente un resultado ideal (también

depende de que área lo contrató) es que el equipo que realiza el PT no tenga

éxito.

Generalmente alguien no termina feliz. Estos casos se deben detectar y se debe

trabajar en el proceso de sensibilización.

Metodología del PT

Formalmente no existen metodologías; pero en la práctica, existen tantas

metodologías como empresas de seguridad informática.

Las metodologías abarcan desde la clásica tres fases: identificación, scanning y

explotación, hasta las de múltiples fases.

Según la experiencia, la metodología a aplicar sería la siguiente:

1. Reconocimiento

§ Obtención de información.

§ Análisis y planificación.

2. Scanning

§ Enumeración de vulnerabilidades.

§ Detección de vulnerabilidades.

3. Penetración



Página 12

§ Explotación de vulnerabilidades.

§ Escalada de privilegios.

4. Obtención de información

5. Informes

§ Análisis de los resultados.

§ Desarrollo de informes.

§ Presentación.

6. Limpieza

A nivel metodología no formal, existe el OSSTMM (Open Source Testing

Methodology Manual) que describe metodologías, técnicas y herramientas a

utilizar en las diversas fases de un PT.

Utilización de vulnerabilidades

Las fases más críticas de un PT son la detección, verificación y explotación de

posibles vulnerabilidades.

Cuando se detecta una potencial vulnerabilidad, se debe verificar la misma para

evitar falsos positivos. Este proceso muchas veces no resulta trivial. Para cada

vulnerabilidad se debe especificar como se la detectó (banner, fingerprint o

suposición).

Una vez que se tiene detectada y verificada una vulnerabilidad, se la debe

aprovechar, explotándola utilizando exploits. Un exploit puede tomar la forma de



Página 13

un programa, una serie de pasos a seguir, combinaciones de diversos eventos,

etc.

Sabiendo que existen más de 13.000 vulnerabilidades, ¿de dónde se obtienen los

exploits?. De bases de datos de exploits (Securityfocus BID, PacketStorm, etc),

mailing lists (pen-test de Securityfocus), sites underground (Zer0 days xploits),

chats, etc. Obtener el exploit que necesitamos y que funcione correctamente

puede tomar varias horas.

¿Qué pasa si no existe un exploit disponible para la vulnerabilidad que

detectamos?. Es posible desarrollar un exploit o un poc (proof of concept),

probarlo en un laboratorio y luego lanzarlo. ¿Las empresas que hacen PT pueden

hacer ésto?, ¿tienen el know-how?, ¿tienen el tiempo?, ¿vale la pena hacerlo?.

En la realidad, investigar una vulnerabilidad, estudiarla, preparar un laboratorio,

desarrollar un exploit y probarlo puede tomar varios días. Son contadas con las

manos de los dedos las empresas que hoy en día realizan ésto.

¿Qué pasa con los falsos negativos (vulnerabilidades que existen y no se

detectaron) en un PT?. Esto afecta en gran medida a la calidad de un PT y al buen

nombre de la empresa que lo realiza. Y es uno de los problemas más críticos de

hoy en día.

PT, ¿artesanal o automático?

Las herramientas de detección de vulnerabilidades cada vez son más poderosas,

han recorrido una larga historia desde el iss 1.2 hasta decenas de software

automatizado.



Página 14

Hasta ahora la automatización fue llevada a cabo en la fase de detección de

vulnerabilidades. Son pocos los paquetes que realizan una verificación de

vulnerabilidades. Y muchos menos los que realizan la tarea de la explotación de

las mismas.

¿Se puede lograr una total automatización del PT o es una tarea artesanal?.

El producto Core Impact es uno de los primeros que se aproxima a la

automatización del PT, sin embargo, no cubre todos los aspectos y sigue haciendo

falta un equipo humano altamente capacitado detrás.

La realidad demuestra que por un largo tiempo seguirá siendo una práctica

artesanal, y cada vez más soportándose en herramientas que automatizarán

ciertos procesos.

Equipo que realiza el PT

Una gran parte del éxito es la composición del equipo que realiza un PT.

Debido a la diversidad de tecnologías existentes es necesario contar con un

equipo multidisciplinario para llevarlo a cabo.

Los equipos deben estar formados como máximo por cuatro personas, ya que se

necesita coordinación, comunicación y camaradería entre los miembros.

Las claves de un buen equipo son las siguientes:

§

Experiencia de campo. Si se vivió una situación, ya se la conoce.

§ Elevado nivel de conocimiento en redes, protocolos, sistemas operativos,

aplicaciones, programación, etc.

§ Perspectiva. Cada miembro puede aportar su visión del problema.



Página 15

§ Elevado interés y pasión por la investigación. El mejor equipo “disfruta”

realizar un PT. Es un reto.

§ Sentido ético y profesional.

Duración del PT

Normalmente la duración de un PT se encuentra atada al alcance del mismo. El

tiempo que consumirá se calcula en base a experiencias anteriores, pero no hay

reglas claras.

Dos ejemplos: ¿Cuánto se tarda en realizar un scanning UDP de todos los puertos

de una clase C?. Depende del vínculo con Internet de la empresa que realiza el

PT y del vínculo de la organización. También depende de los saltos que existan.

¿Cuánto se tarda en testar una aplicación de HB?. Depende de la cantidad de

opciones que posea, de cómo esté programado, de cuántos servidores estén

involucrados, etc.

En la realidad los PT suelen durar poco tiempo, de una a seis semanas,

dependiendo la infraestructura de la organización. Esto nos deja varias preguntas:

¿se habrán realizado todas las pruebas posibles?, ¿se habrá llegado a ver todo?,

¿el equipo que realizó el PT trabajó?. Si no se detectó nada crítico, ¿con más

tiempo, podrían hacer más cosas?.

Si por razones de tiempo, no se llegan a realizar ciertas pruebas, debe quedar

debidamente documentado.



Página 16

Aspectos legales

Si durante un PT se descubre una vulnerabilidad crítica en un sistema de

HomeBanking o si se bloquea un sistema crítico en producción, ¿qué sucede?.

Hoy existe un área gris en los aspectos legales a tener en cuenta para realizar un

PT.

Formalmente hace falta que la organización firme dos cartas a la empresa que

realiza el PT: un convenio de confidencialidad y una carta de autorización.

El convenio de confidencialidad es básicamente un NDA, donde se describen las

obligaciones de la empresa que va a realizar el PT en relación a toda la

información que conocerá, accederá y tendrá en su poder durante la realización

del PT.

La carta de autorización (permiso para realizar el PT) debe estar firmada por el

responsable de la Organización (CIO, Oficial de Seguridad Informática, Abogado,

etc.) antes de tocar un solo sistema. Como mínimo, la carta de autorización

debería incluir:

§ ¿Quién va a realizar el PT?

§ ¿Cuándo el PT va a ser realizado?

§ ¿Por qué el PT va a ser realizado?

§ Qué tipo de actividad es la autorizada y cuál no.

§

¿Cuál es el alcance?

§ Contactos en el cliente ante emergencias.



Página 17

¿Qué pasa cuando estos contratos pasan por abogados?. Se demora el proyecto.

El área legal se toma sus tiempos para analizar los documentos y seguramente

introducirá modificaciones a favor de la organización.

Problemáticas del PT

Las principales problemáticas reales a las cuales se enfrenta el área de PT son las

siguientes:

§ Existe un gran desconocimiento por parte de los clientes (organizaciones)

sobre qué se quiere de un PT.

§ Es muy difícil calcular los tiempos que puede insumir un PT.

§ Se requiere formar un equipo que posea experiencia y conocimientos

profundos. Y muchas veces es muy complejo formar un equipo para realizar

PT.

§ Existe una sobreabundancia de herramientas de seguridad que ayudan en

algunas fases, pero también existe una falta de herramientas en otras fases

críticas.

§ La fase de explotación de vulnerabilidades no se encuentra madura. Que

exista una vulnerabilidad teórica no significa que pueda explotarse

fácilmente.

§

No existen estándares de nivel de riesgos sobre los problemas que se

detectan en un PT. Varios elementos de bajo riesgo pueden implicar en su

conjunto, un alto riesgo.



Página 18

Conclusiones

Hoy las organizaciones están utilizando los PT con varios objetivos y el propio

mercado los está convirtiendo en una obligación.

Existen estándares no formales, que seguramente en los próximos años

desembocarán en estándares internacionales formalmente aceptados.

Existe una superpoblación de empresas de seguridad que realizan PT con

variados grados de calidad. El mercado es quien se encarga de manejar la

balanza.

El PT ha tenido un gran avance en los últimos años, pero todavía existen ciertas

áreas y zonas grises donde poco se ha investigado y queda mucho por hacer.



Pá i 19

Fuentes

§ Performing a Network Vulnerability Assessment – Mark Lachniet.

§ Vulnerability Assessments: Finding holes without digging your own - David

Clarkson.

§ Arming Linux With Penetration Testing Tools - Vince Kornacki.

§ Tests of Penetration in a Data Network– Oscar Ruiz.

§ The Art of Penetration Testing – George G. McBride.

§ The Penetration Test – Iván Arce.

§OSSTMM (Open Source Testing Methodology Manual) -

(www.osstmm.org).

Del Penetration Test a La Realidad_Ardita

Documents

Transcript of Del Penetration Test a La Realidad_Ardita