UNMANARC's WEBSITE.

Basado en una conversación en securityfocus, y a través de varias consultorías de seguridad informática que he realizado, se me ocurrió la idea de probar estadísticamente el nivel de riesgo de ataque a una organización.

Número de Cuentas	Probabilidad de que exista al menos una clave débil
10	0.401 - 40.1%
25	0.722 - 72.2%
50	0.923 - 92.3%
100	0.994 - 99.4%

Hoy en día la moda de las organizaciones es crear cuentas internas en LDAP con una nomenclatura de usuario "estandar", por ejemplo, si mi nombre es aarón y mi apellido mizrachi, el nombre de usuario sería algo asi como "amizrachi"...

Esta moda coorporativa, junto a malas políticas de passwords, raya en la peligrosidad de exponer la seguridad de toda la coorporación por tratar de lucir bien.

Es posible que a nivel gerencial, las decisiones de seguridad informática no se tomen muy en serio debido a que primero que la seguridad esta la imagen de la empresa.

Una vez expuesto esto, procederemos a probar de forma estadística este hecho:

Supongamos que un intruso logra conseguir en google u otro programa/sistema/método, la lista de N personas que trabaja en la empresa.

Adicionalmente, un estudio confirmó que la probabilidad de que la clave de una cuenta elegida al azar en un servidor sea débil es en promedio del 5%. La debilidad de la clave se conoce como la posibilidad de que esta se encuentre en un conjunto preconcebido de elementos.

P( una clave sea débil ) = 0.05 (5%)

Entonces, queremos conocer la probabilidad de que haya una o mas claves débiles en un servidor:

Definimos: A = Número de claves débiles en un servidor n = Número de cuentas en un servidor

Se define la probabilidad:

El número de claves débiles tiene la posibilidad de ser desde cero hasta el número total de cuentas existentes, asumiendo que toda cuenta tiene una clave:

1 = P ( A >= 0 && A <= n )

Esta probabilidad se puede separar en la probabilidad de que no exista ninguna clave débil y la probabilidad de que haya una o mas claves débiles.

1 = P( A = 0 ) + P ( A >= 1 && A <= n )

Despejando, La probabilidad de que haya una o mas claves débiles es 1 menos la probabilidad de que no haya claves débiles.

P ( A >= 1 && A <= n ) = 1 - P( A = 0 )

Para calcular la probabilidad de que tengamos claves débiles, debemos calcular la probabilidad de que ninguna sea débil.

Probabilidad de que ninguna clave sea débil:

P ( A = 0 ) = (1-P( una clave sea débil ))ⁿ

Lo anterior se expresa como que la secuencia de n claves sean todas fuertes... (1-P(una clave sea débil)) es la probabilidad de que una clave sea fuerte. Y P(una clave sea débil) como lo discutimos antes, es del 5% (0.05)

---

Queremos buscar P ( A >= 1 && A <= n ) que es la probabilidad de que haya al menos una clave débil en el servidor.

Sustituyendo en 1 - P( A = 0 ), P( A = 0 ) por (1-P( una clave sea débil ))ⁿ, tenemos la siguiente formula general para la probabilidad de que haya al menos una clave débil en el servidor:

1-(1-P( una clave sea débil ))ⁿ

Lo cual con los datos estadísticos quiere decir:

1-(1-0.05)ⁿ

=

1-(0.95)ⁿ

---

Hasta ahora todo son fórmulas matemáticas/estadísticas. Gerencialmente no muestra el impacto hasta que calculamos su valor:

n = Número de Cuentas	Probabilidad de que exista al menos una clave débil
10	0.401 - 40.1%
25	0.722 - 72.2%
50	0.923 - 92.3%
100	0.994 - 99.4%

Conclusión: Para servidores con mas de 100 cuentas predecibles es casi seguro conseguir una clave débil con un porcentaje de probabilidad mayor que 99.4%.

---

Que hacer?

Eliminar las claves débiles en algunos sistemas resulta sencillo, por ejemplo, existen sistemas de administración de claves que permiten filtrar claves débiles utilizando heurísticas y wordlists (Listas de palabras), Adicionalmente a estas listas de palabras se deben agregar números de cédula, DNI, Seguro Social, Pasaporte, fechas de nacimiento... Todo ello para evitar que los usuarios ingresen esto como clave.

Tambien se recomienda una política de bloqueo de cuenta cada vez que ocurran un número pequeño de intentos, por ejemplo 3 intentos.

Y finalmente... Si queremos mas seguridad aún, debemos eliminar las convenciones de nombre de cuentas... No es necesario este último paso a menos que usted requiera de extrema seguridad.

Que impacto puede tener continuar con mi política débil?

Esto va a depender de muchos factores, en principio, de los privilegios y accesos que tenga la persona vulnerada, y como a través de estos, el intruso puede atacarlo.

El intruso puede obtener la lista de nombres con diversas ténicas, desde buscando en google por su empresa, utilizando programas tipo "maltego", o incluso haciendo trashing, que significa que el intruso irá hasta su organización, y escarbará tanto en la basura como visualmente en las zonas aledañas a su area de trabajo.

Mas alla de estas técnicas, enumeremos los impactos

• Email: La víctima puede manejar una cuenta de correo coorporativa. Esta víctima puede considerar que no es necesario asegurar su cuenta de correo porque no realiza operaciones importantes a través de ella. Sin embargo para un atacante, una cuenta de correo puede resultar muy útil. Este podría utilizarla como un mécanismo de comunicación efectivo entre el y otra persona. Con cambiar la firma, el atacante puede atribuirse cualquier cargo dentro de la empresa, con el nombre de la víctima. Si bien es cierto, que SMTP deja forzar el email y hacer algo similar, con esta técnica, el atacante además podrá recibir respuesta de sus correos y mantener una conversación
• Acceso VPN / Intranet / Wireless: Posiblemente y sin que la victima lo sepa, esta tiene acceso VPN a la organización, acceso wireless, o incluso a algún login que le permita ingresar desde la internet hasta las aplicaciones de la empresa. El atacante podría utilizar esto para escalar dentro de la organización y obtener acceso interno completo
• Acceso a Shell y/o Escritorio Remoto: Cada día mas los sistemas se centralizan y le permite a los usuarios trabajar en distintas estaciones, es por ello que probablemente la cuenta víctima tendrá acceso a shell, escritorio remoto o incluso un directorio interno. En estos casos, muchas veces los privilegios permitirán al atacante escalar dentro de la organización tal como si se encontraran en un computador interno.
• Otros accesos: Cada organización tiene una estructura de red distinta, así como permisos distintos para sus usuarios. Otros sistemas que se autentican centralmente podrían tambien sufrir las consecuencias
• Listas de SPAM y fraude coorporativo: El peligro de exponer los emails y otros artefactos dentro de la organización nos eleva a un segundo nivel de riesgo. El primero es el spam. Es mas sencillo realizar spam deliberado a la organización si además se posee una nomenclatura de nombres, pero de todas formas, el peligro mas importante es el espionaje coorporativo, especialmente el caso cuando una empresa consigue fácilmente los correos de ciertas personas en puestos claves y decide ofrecerles via email ofertas por la venta de información. Estos correos pueden aparecer tanto por nomenclatura de nombres, como por revisión de los correos internos comprometidos con claves débiles.

Sabiendo esto, no queda mas que recomendar seguir una buena política de seguridad, y adicionalmente realizar las auditorías correspondientess periodicamente.