Sec-Track » Sec-Track

Finalmente… ¿Quiénes son los responsables de la (In)seguridad?

4v4t4r — Wed, 18 Jan 2012 07:17:29 +0000

Llevaba más de 6 meses con este post en “el tintero”. Esto debido a lo complejidad y a todas las variables involucradas en el mismo. En un inicio pretendía tan solo medir la eficacia que podían tener algunos delincuentes informáticos en su actuar. Luego fuí involucrando productos, sistemas de explotación de vulnerabilidades, tiempos, etc… Finalmente terminé con tantos datos y tantas ideas que se me ocurrió tan solo hacer una reflexión y un pequeño estudio estadístico si pudiese llamarlo así… Luego este se convirtió en una desconferencia que presenté en el BarCampSE en Medellín.

Lo genial de la experiencia es que seguí la dinámica de desconferencia. En la cual el contenido de la presentación se fue modificando con la participación de los asistentes.

El escenario y planteamiento es sencillo… Bueno, antes el disclaimer OBLIGATORIO sobre la información presentada.

Comencemos…

Como primer apartado presenté una muy breve definición de Seguridad o (In)seguridad como la traté – Esto, a la ausencia de la misma.

Allí los asistentes presentaron sus definiciones de la triada que la componen.

Confidencialidad: La confidencialidad es la propiedad de prevenir la divulgación de información a personas o sistemas no autorizados.

Integridad: Para la Seguridad de la Información, la integridad es la propiedad que busca mantener los datos libres de modificaciones no autorizadas.

Disponibilidad: La disponibilidad es la característica, cualidad o condición de la información de encontrarse a disposición de quienes deben acceder a ella, ya sean personas, procesos o aplicaciones.

Más información desde la wikipedia >>

A partir de allí realicé la siguiente reflexión:

Finalmente, ¿Quiénes son los responsables de la (In)seguridad?

Aquí hice un inventario de los actores(roles) involucrados en la problemática. El grupo quedó así:

Usuarios
Webmasters
Desarrolladores
SysAdmins (Administradores de Sistemas)
CISOs (Oficiales de Seguridad)
CEOs
Vendors(Vendedores de productos-servicios)
Delincuentes Informáticos
Gobierno/Ley/Judicialización

Una vez definidos los roles veamos al escenario:

Imaginemos (determinemos-seleccionemos) un reconocido sitio web (www.reconocidositioweb.com). La temática del sitio puede ser cualquiera de las que conlleven miles de visitas al día. Estas temáticas pueden ser noticias, educativas, redes sociales, entretenimiento, gobierno, servicios, etc…

Para ilustrar mejor el escenario propuse un pequeño resumen de estadísticas del reconocido Top Sites de Alexa(Colombia).

Esto con el fin de ilustrar de mejor manera los objetivos potenciales de este determinado escenario.

En los recuadros seleccioné algunos sitios web más “locales” por así decirlo… Pues de alguna manera serían más susceptibles a ataques debido a que el publico objetivo es más regional.

Ahora realizo el siguiente cuestionamiento.

¿Qué pasa cuando el sitio web es vulnerado? Y digamos que con ataques comunes (Web dafacement, DoS, DDOS, full disclosure)

Veamos algunos ejemplos de este tipo de ataques a reconocidos sitios web:

Web defacement a elecciones.com.co

Web defacement a ejercito.mil.co

Web defacement a emisora.udea.edu.co

Full disclosure confidencialcolombia.com

Ataques DDoS

Esta serie de ataques podrían considerarse en muchos casos como “Hacktivismo“. Aun así continúan siendo delitos actualmente judicializables. Aclaro que el objetivo de mi publicación va más allá de entrar en debate sobre las actividades y motivaciones de estos colectivos y/o individuos.

Respondiendo a la pregunta (que obviamente cada uno viene haciendo desde que comenzó a leer el post) personalmente diría que este tipo de actividades en algunos casos (sobre todo en los de web defacements) no van más allá de la simple protesta política. Algunos otros relacionados con los DDoS y full disclosure si los considero más irresponsables por parte de sus causantes.

En definitiva, la mayoría de estos ataques repercuten nacional e internacionalmente por su alto impacto social.

Ahora bien, ¿Qué pasa cuando el sitio web es vulnerado? (Ataques avanzados y persistentes NO APT) Es decir, cuando el atacante prefiere profesionalizar sus ataques delictivos e ir más allá de la protesta…

En este tipo de ataques hago referencia a los relacionados con la propagación de malware por medio de sistemas automáticos de explotación de vulnerabilidades en navegadores (Exploits packs & Crimepack) y los productos relacionados (Adobe Reader, Flash, Java, etc.)

Para entrar en contexto tomé otro resumen de gráficas de uso de navegadores, sistemas operativos y versiones:

Browsers

Versiones de browsers

Sistemas Operativos – Desktops

Sistemas Operativos – Móviles

Gráficas completas de uso en malware-project.org

Ahora, para el desarrollo de esta prueba de concepto tomé un reconocido sitio web e inyecté un iframe que cargaba otro sitio web preparado para la prueba con un sistema automático de explotación de vulnerabilidades con el objetivo de tomar una muestra estadística. Pero en este caso cargando un archivo “inofensivo” que permitía identificar la locación de la víctima, dirección IP, Si tiene o no cámara web, Sistema Operativa, CPU, RAM, Antivirus y Firewall. Nada más lejos de la información que se obtiene con cualquier troyano. Imaginemos entonces si en lugar de este archivo el atacante decide incluir un troyano estilo poison ivy, Darkcomet u otro.

Pero veamos primero el sistema de explotación y los datos recolectados.

Panel de estadísticas del exploit pack.

Estadísticas de exploits

Estadísticas Sistema Operativo & Browsers

Estadísticas por país

Ahora detallo la muestra y resultados

Toma de registros y variables a determinar

En esta tabla se registran las siguientes variables:

Minutos: Para el presente estudio, es la variable libre o independiente, es decir, no depende de ninguna de las otras, pues sus resultados no están ligados a los registros de las demás.

Se toma aleatoriamente los registros al minuto 17, 22, 25, 27 y 30. Se clarifica que no se tomó ninguna secuencia o patrón para seleccionar estos tiempos; Simplemente se toman aleatorimente para garantizar la independencia de los datos; es decir que los registros no estén sujetos a una serie o secuencia determinada.

Equipos: Esta variable hace referencia al número de equipos que visitan la página comprometida (atacada) en determinado tiempo, lo que indica que la misma es totalmente dependiente de la variable minutos.

Equipos vulnerables: Esta variable se califica como la principal en la presente investigación ya que la deseamos predecir estadísticamente.

La variable Equipos vulnerables desempeña la función de variable dependiente ya que sus registros están totalmente determinadas por el tiempo , es decir, por la variable minutos.

Análisis de la correlación

En estadística, la correlación nos indica el grado de asociación lineal que existe entre dos variables, es decir, en que dirección y con que porcentaje se relacionan las mismas.

Este índice de correlación varía entre –1 y 1 donde valores cercanos a uno positivo nos hablan de una relación directamente proporcional (a medida que aumenta una variable también aumenta la otra), y valores cercanos a uno negativo nos hablan de una relación inversamente proporcional (a medida que aumenta una variable la otra disminuye) .

En la tabla anterior se calcula la correlación de la variable Minutos vs. Equipos vulnerables la cual es de 0.913777 o sea del 91% la cual es bastante alta y positiva. Esto nos dice que a medida que aumenta los minutos, aumentaran los equipos vulnerables lo cual era de esperarse . Ahora como un porcentaje del 91% está muy cercano al 100% están dos variables tienen una relación lineal muy fuerte indicándonos buenos indicios para proceder a realizar una regresión lineal simple.

Análisis de regresión lineal simple

De la ilustración anterior observamos gráficamente el comportamiento de las variables Minutos vs. Equipos vulnerables. Vemos que al ajustar una línea que explique la tendencia de los datos esta es de pendiente positiva manteniendo la tendencia a aumentar el número de equipos vulnerables a medida que aumentan los minutos corroborando lo dicho anteriormente en el análisis de correlación. Además la línea recta parece ajustar muy bien a los datos lo que nos indica que es adecuado realizar la regresión lineal simple.

Estimación de los parámetros de la recta de regresión

De la anterior ilustración observamos gráficamente el comportamiento de las variables Minutos vs. Equipos vulnerables. Vemos que al ajustar una línea que explicamos la tendencia de los datos esta es de pendiente positiva manteniendo la tendencia a aumentar el número de equipos vulnerables a medida que aumentan los minutos corroborando lo dicho anteriormente en el análisis de correlación. Además la línea recta parece ajustar muy bien a los datos lo que nos indica que es adecuado realizar la regresión lineal simple.

Intercepto de la recta: Se refiere al ajuste de la recta cuando los minutos son cero, es decir si los minutos son cero, ¿cuantos serán los equipos vulnerables? En este caso no tiene sentido interpretar este parámetro, pues a cero minutos transcurridos, cero equipos vulnerables; entonces se decide dejar este parámetro para ajustar de manera mas confiable la recta ; pues este intercepto nos explica todo lo que la pendiente no puede explicar.

Pendiente de la recta: Este parámetro nos indica el grado de inclinación de la recta. Esta pendiente nos da la siguiente información:

Por el aumento de una unidad en la Variable X, en promedio cuanto aumenta Y. Concretamente ¿si aumenta un minuto, en promedio cuantos equipos van a explotar a la vulnerabilidad? Esta pregunta se resolverá al momento de estimar este parámetro.

Componente de error: Con respecto a la componente de error, en estadística toda modelación que se haga tiene un componente de error, la cual tiene en cuenta todo lo que el modelo no puede explicar, es decir, hechos o variables que no se pueden controlar como por ejemplo: el hecho de un corte de energía, caída de Internet, bajó en el servidor, etc.

Estimación de los parámetros de regresión

NOTA: Lo procedimientos para estimar los parámetros de una recta de regresión simple son procesos de cálculo matricial tediosos y complicados los cuales no es necesario mostrar; Por eso precedemos con el software especializado para estadística SAS a realizar dichos cálculos y en este documento sólo se muestra los resultados.

Anotación:

´ Y = Nos indica que ya estamos trabajando con datos muestreados, es decir vamos a inferir de una pequeña muestra que tomanos hacia algo general por tanto ya no colocomos la componente de error aleatorio.

Interpretación de la pendiente:

De la tabla anterior, tenemos que la pendiente estimada se da por B = 3.52632 la cual se interpreta así :

Por el aumento de 1 minuto, en promedio 3.5 aproximadamente 4 Equipos explotarán a la vulnerabilidad.

En la ilustración anterior (recta de regresión ajustada a los datos) se grafica la nube de puntos con la recta de regresión ajustada. La cual tiene intercepto A = 6.26316 Y pendiente B = 3.52632; a través de esta línea, podemos proyectar lo que sigue sucediendo a medida que aumentan los minutos, simplemente siguiendo el comportamiento creciente de la línea. Así:

En la ecuación de la recta Y = 6.26316+3.52632(X) queremos saber el valor de Y cuando X toma un valor determinado; Remplazamos el número de minutos que deseamos y realizando los cálculos respectivos, tendremos el valor de nuestra variable respuesta (Equipos vulnerables).

Predicciones del modelo de regresión

El mayor potencial de los modelos de regresión es la capacidad de predecir datos futuros; y para el presente estudio, queremos precisamente proyectar cuantos equipos se van infectando a medida que aumenta los minutos, de esta manera calcularemos el valor futuro de cuantos equipos explotan a la vulnerabilidad si pasa un día , una semana o un mes.

Predicciones dentro del mismo rango:

En la tabla anterior, realizamos una evaluación de la predicción, es decir, comparamos el valor real de equipos vulnerados con respecto a los que predice nuestro modelo con su respectivo intervalo de confianza; Por ejemplo al minuto 17, 65 equipos explotaron a la vulnerabilidad y nuestro modelo predice que se explotaron 66; con un intervalo de confianza entre (60.651 y 71.770) lo cual me dice que el mínimo de equipos vulnerados en 17 minutos pueden ser aproximadamente 60 y el máximo 71, vemos como el valor real queda incluido en el intervalo , por consiguiente nuestro modelo predice de una manera muy apropiada el número de equipos vulnerados al transcurrir determinado tiempo. Tengamos en cuenta que este intervalo se realiza con un 95% de confianza , es decir, tenemos una probabilidad de equivocarnos del 5%.

Diagrama de dispersión

En la ilustración anterior se observa gráficamente algunas de las proyecciones en horas; vemos como después de predecir 20 horas sigue intacta la tendencia de los datos.

Resultados en horas de las predicciones del modelo de regresión

En la tabla anterior se observan los resultados de las proyecciones que arroja el modelo. Por ejemplo en 22 horas, aproximadamente se infectaran 4,661 equipos. En la ilustración siguiente se observa el crecimiento en minutos por medio de las barras.

Resultados en días de las predicciones del modelo de regresión

En la tabla anterior se observan los resultados de las proyecciones que arroja el modelo en días; por ejemplo en 8 días, aproximadamente se infectarán 74,482 equipos. En la siguiente ilustración se observa el crecimiento en horas por medio de las barras.

Por lo tanto…

Volvamos a los actores involucrados que hacen posible que este tipo de ataques se lleven a cabo…

No actualizamos, no usamos antivirus-FW, tenemos malos hábitos de navegación, no nos educan… Y siempre dicen que tenemos la culpa…

La reflexión será… ¿Realmente somos nosotros los responsables de nuestra (In)Seguridad?

Los webmasters tampoco actualizamos, no probamos o testeamos lo que usamos, utilizamos cualquier CMS o componente por su funcionalidad y no por su seguridad… En definitiva casi siempre nos dedicamos exclusivamente al contenido…

Los desarrolladores no actualizamos, no practicamos el DSLc (Ciclo de vida de desarrollo de software)… En la mayoría de casos… Si nos funciona, dejamos así…

Los administradores de sistemas tampoco actualizamos, no monitoreamos, en la mayoría de los casos no nos importa la seguridad… Finalmente nos escudamos diciendo que solo hacemos lo que dice el de seguridad…

Los oficiales de seguridad no actualizamos igual (“a los h4x0rs no nos pasa nada”), muchos nos quedamos en la escuela y no nos metemos en el ambiente real… No nos importa que funcione sino que sea “seguro”… Finalmente solo podemos hacer lo que diga el CEO ($$$)

Los CEOs menos que actualizamos, además de eso no nos importa… La mayoría ni tenemos un PC… Finalmente decimos… “¿Quién nos va a atacar?”

Ejemplo los de Adobe reader, flash, java, quick time, IE, FF, etc, etc, etc Siempre dirán: La culpa es de los usuarios, la culpa es de los devs y sobre todo de los CISOs.

Simple y claramente…

En este post prefiero no opinar al respecto (prometo hacerlo en el futuro)

O por lo menos esa es la conclusión a la que llegamos en dicha conferencia… Obviamente cada uno sacará la suya y espero la comparta por medio de los comentarios…

Aclaraciones & Reflexiones

Posiblemente existan otros roles-actores a involucrar. Siéntanse libres de agregarlos por medio de los comentarios. Ojalá con conclusiones.

El estudio estadístico no es un resultado 100% aplicable, aunque si muy aproximado… Pues obviamente los horarios de visitas varían, no siempre se tienen nuevos usuarios, etc…

¿Que pasaría donde se utilizara un exploit pack con exploits para bugs del tipo zero day (0 day)?

Que no incluya comentarios sobre legislación y gobierno no quiere decir que desapruebe lo actual… Al contrario, considero que en nuestro país existen normas y leyes a la altura del estado actual de la tecnología… No lo hago debido a que considero oportuno realizar todo un post sobre este tema…

Existen muchas otras razones por las cuales cada uno de los actores son responsables… Solo ilustro algunas… Espero sean complementadas (como se realizó en la conferencia) por medio de los comentarios…

Cuando recuerde algunas otras reflexiones y aclaraciones, las incluiré…

Wiki del proyecto colaborativo de entrenamiento en Seguridad Informática: Sec-Track

4v4t4r — Wed, 22 Dec 2010 02:05:56 +0000

Buenas noticias para el proyecto… Pues ahora contamos con un espacio colaborativo Wiki para una retroalimentación más óptima y de mejor calidad para cada uno de los desafíos, retos, wargames y entornos disponibles en el proyecto.

Sean bienvenidos al espacio y sean bienvenidas todas las ideas y aportes para el crecimiento del proyecto.

Por ahora me encuentro migrando parte del contenido de este blog a la wiki (entornos, solucionarios), cualquier error que encuentren por favor me lo notifican a mi correo o si pueden corregirlo, pues para eso es la wiki …

La idea es terminar con los entornos pendientes (PwnOS, DVWA, entre otros) y así continuar con las nuevas propuestas que traigo para el proyecto…

Por ahora tengo publicados todos los entornos De-Ice (disponibles al público, luego publicaré los privados ), los solucionarios (Spoilers), Metodologías, un Challenge de IHTB, DVWA, Review de libros, Reviews y material de certificaciones y trainings, Tools y videos prácticos de las mismas…

Vuelvo y repito, toda la colaboración y sugerencias son bienvenidas!!!

Wiki Sec-Track

Un año de vida del proyecto colaborativo de entrenamiento en seguridad Sec-Track

4v4t4r — Tue, 12 Oct 2010 21:06:39 +0000

Pues como dice el título de este post, Sec-Track.org cumple un año de existencia en internet.

Muchas gracias a todas las personas, organizaciones y proyectos que han apoyado de alguna manera esta iniciativa. Entre estos destaco a la Comunidad DragonJAR en cabeza de Jaime Andres Restrepo, El HackLab ( Fernando Quintero, Camilo Zapata, Cristian Tobón), a todos los que han participado en la resolución de entornos y compartiendo retos (Roger, NonRoot, Seifreed, Dino, HackPlayers, SamuraiBlanco, c1b3rh4ck, Epsilon, Hecky, Brain Urban, Juan Escobar, Servant y muchos otros que no recuerdo en este instante…

Muchas gracias a todos los lectores y colaboradores de este proyecto…

Muy pronto estaré publicando algunos retos propios y nuevos entornos de entrenamiento, acompañados de unos geniales premios compartidos por nuestros sponsors y por maravillosas personas que apoyan este proyecto.

Un abrazo…

Recopilación de publicaciones y entornos de Sec-Track

4v4t4r — Mon, 01 Mar 2010 21:09:28 +0000

Recopilación de las publicaciones en Sec-Track:

Sobre Sec-Track

¿Qué es Sec-Track?

Entornos de Entrenamiento

Metodologías / Frameworks / Docs

Tools

Videos / Audios

¿Qué es Sec-Track?

4v4t4r — Wed, 21 Oct 2009 05:24:08 +0000

Video tutorial introductorio y descriptivo del Proyecto Colaborativo Sec-Track y algunos de sus objetivos.

Introducción al Proyecto Sec-Track from Sec-Track on Vimeo.