Security

De JarfilWiki

Contenido

Temas

Varios

MAC spoofing

Linux

  1. ifconfig eth0 down
  2. ifconfig eth0 hw ether XX:XX:XX:XX:XX:XX <- la nueva MAC
  3. ifconfig eth0 up

XP

  1. Inicio -> Ejecutar -> Teclear regedt32.
  2. Ir a HKEY_LOCAL_MACHINESYSTEM -> CurrentControlSetControlClass -> {4D36E972-E325-11CE-BFC1-08002BE10318}
  3. Buscar la clave DriverDesc del interfaz que se quiere modificar.
  4. Editar (o añadir) la clave de cadena (tipo REG_SZ) NetworkAddress para que contenga la nueva MAC.
  5. Deshabilitar y volver a habilitar el interfaz cambiado (o rearrancar el sistema).

Seguridad - Sobre Bug y Parches

De cara a la seguridad, lo más importante es el tiempo que transcurre desde que aparece un sistema vulnerable hasta que se corrige la vulnearabilidad. Se pueden distinguir las siguientes etapas:

  • Aparición de la vulnerabilidad
  • (opcionalmente) Publicación del programa vulnerable
  • (opcionalmente) Publicación del código fuente
  • (a partir de aquí) Descubrimiento de la vulnerabilidad
  • Instalación del programa vulnerable
  • Exposición del programa vulnerable (su uso ante agentes potencialmente peligrosos)
  • (opcionalmente) Notificación de la vulnerabilidad
  • (opcionalmente) Parche para la vulnerabilidad
  • Desactivación o Corrección de la vulnerabilidad

El periodo de mayor riesgo es el que va de la Exposición a la Corrección (o en su caso Desinstalación), pues es el tiempo en el que un agente potencialmente peligroso (ej: hacker ante un servicio Web) tiene la oportunidad de explotar dicha vulnerabilidad. También es importante el tiempo total desde la Aparición hasta la Corrección, siendo exponencialmente importante a partir de la Publicación (crece el número potencial de agentes peligrosos). De ello se deduce que un programa vulnerable que no se Publique ni se Exponga (ej: sólo se instale en un entorno estrictamente cerrado) es perfectamente inmune, aunque seguramente también perfectamente inútil.

Lo que nos va a ocupar en este caso va a ser el periodo de tiempo entre la Notificación o Parche y la Desactivación o Corrección, pero para ello vamos a tener que tomar en cuenta los demás periodos.

  • Tras la aparición de la vulnerabilidad, sólo los desarrolladores implicados la conocen. No hay peligro para la seguridad pues no se ha implementado.
  • Al Publicar el programa vulnerable, empieza el periodo de potenciales pruebas por parte de agentes maliciosos. Así mismo, empieza a crecer la base de Instalaciones disponibles para realizar un ataque.
  • Una publicación del código fuente implica una mayor probabilidad de que un agente, malicioso o no, descubra la vulnerabilidad. En este caso es IMPERATIVO ofrecer un medio de respuesta rápida ante notificaciones por parte de agentes benévolos.
  • Al ir creciendo el número de Instalaciones del programa e irse ofreciendo a los usuarios finales, aumenta su Exposición.
    • En caso de que el acceso pueda realizarse por agentes cuya seguridad no se haya verificado (ej: desde Internet), el peligro aumenta directamente con el número de usuarios que tengan contacto con el programa. Es IMPERATIVO establecer mecanismos de monitoreo del correcto funcionamiento.
    • Si se trata de un programa que los agentes potencialmente maliciosos pueden probar de forma aislada (off-line, ej: descargando el software) el peligro aumenta exponencialmente al carecer de un sistema de alerta temprana.
  • Tras la Notificación de la vulnerabilidad, el peligro es máximo. Todos los agentes quedan informados de la existencia de la vulnerabilidad. Los agentes maliciosos empezarán a idear maneras de explotarla. Es IMPERATIVO ofrecer un Parche o Corrección en el menor tiempo posible (a poder ser simultáneamente).
  • Al publicar el Parche el peligro empieza a poder reducirse al irse Corrigiendo los sistemas vulnerables. Sin embargo el peligro para los no Corregidos crece exponencialmente respecto al número de sistemas vulnerables mas el tiempo transcurrido, dado que en este momento los agentes maliciosos disponen de TODOS los datos de la vulnerabilidad (ej: versión corregida - versión vulnerable = vulnerabilidad). Es IMPERATIVO que los usuarios Corrijan sus sistemas en el instante de aparecer el Parche.

Caso especial: programas Open Source en Internet.

En este caso, la Publicación incluye el Código fuente, de forma que la probabilidad de descubrir la vulnerabilidad es muy alta desde el principio. Es IMPERATIVO ofrecer un medio de comunicación absolutamente ágil entre potenciales agentes benévolos, desarrolladores y usuarios (o administradores). Las notificaciones deben incluir siempre un Parche para realizar la Corrección, aunque este no sea óptimo ni definitivo. La distribución pública aumenta tanto el número de agentes malévolos como benévolos, siendo estos últimos siempre un número mayor.

Caso especial: programas Privativos (Cerrados) en Internet.

Aquí la probabilidad de que un agente malévolo descubra la vulnerabilidad es mucho menor al no disponer del código fuente. Los factores principales son la Exposición y popularidad del programa al aumentar tanto el número de ocasiones para descubrimientos fortuitos de la vulnerabilidad como el interés despertado en los agentes malévolos para buscarlas. En el momento del descubrimiento de la vulnerabilidad es importante que el Desarrollador ofrezca un medio de comunicación y respuesta eficiente (lo cual implica gastos en mantenimiento por parte del Desarrollador). Al ser imposible ofrecer soluciones temporales de código fuente, se debe decidir si la Notificación debe retrasarse hasta disponer de un Parche o facilitar una Correccion (ej: desinstalar el software, opción contraria a los intereses del Desarrollador).

Conclusión.

El mejor modelo de software es aquel que implique al usuario en la actualización del mismo, a poder ser por medio de actualizaciones automáticas del código fuente, pudiendo el usuario decidir si delegar o no en el Desarrollador esta decisión.

ToDo

Seguridad de los hashes (crc, md5, etc) en ficheros de texto

Un hash es el resultado de una función cuyos parámetros son una serie de datos de entrada (ej: un fichero). Un hash óptimo es aquel que, ofreciendo resultados de n bits, a partir de 2^n conjuntos de datos de n bits diferentes (todas las posibilidades), ofrece 2^n resultados distintos. Esto es: no tiene colisiones, o dos conjuntos de datos diferentes con el mismo hash. (en la práctica, esto rara vez se da)

Ahora bien, un hash suele utilizarse para comparar entre sí dos conjuntos de datos de longitud (muy) superior a n bits. En este caso, por cada m bits adicionales, habrá 2^m posibles colisiones entre dos ficheros distintos. Entonces, ¿qué utilidad tiene un hash?

Desde luego en comparaciones "absolutas" no tienen sentido. Un atacante decidido siempre podrá encontrar una colisión usando un conjunto de datos que le interese con sólo unas pocas (n bits) modificaciones. Otra cosa es que le sea "prácticamente factible". Esto es, si, dado el actual estado de la computación, es posible hallar el conjunto correcto de modificaciones necesarias en un tiempo razonable (ventana de exposición). Si el cálculo se estima que puede necesitar de millones de años, es posible confiar hasta cierto punto en la inviolabilidad relativa del hash, siempre a condición de que no se desarrollen nuevas técnicas para hallar una solución al problema.

Sin embargo, en el caso de una transmisión, con un hash capaz de detectar n bits modificados de n+m, y si la tasa de errores del enlace es siempre menor a n entre n+m (ej: error < 1/1000 -> hash de 64 bits cada 64000), es perfectamente fiable considerar este hash como una prueba de una transmisión correcta. Incluso aunque la tasa de error aumente notablemente, si el hash está diseñado de tal manera que la naturaleza del error probable no aumente la probabilidad de colisiones, seguirá pudiendo usarse el hash como "relativamente fiable". Es más, incluso comparando una transmisión cualquiera con el hash de la transmisión de "ruido puro", sólo habrá una probabilidad de 1/(2^n) de que ambos coincidan o, lo que es lo mismo, una colisión segura cada 2^n+1 transmisiones. En este caso bastaría detectar los primeros errores para poner en duda toda la transmisión y volver a intentarla para comparar los resultados bit a bit y no por hash.

Otro caso interesante sería la comparación de modificaciones entre ficheros. En el caso de ficheros binarios (ejecutables, comprimidos, etc) la fiabilidad de un hash se reduce notablemente debido a posibles cambios fortuitos en la codificación del mismo, que habría que analizar en términos de variabilidad. Sólo ante cambios de variabilidad limitada (ej: adición de un código determinado de un virus) habría algo más de seguridad, al ser poco probable que dos ficheros diferentes, una vez añadido el codigo, presenten el mismo hash (suponiendo que el virus no sea capaz de calcular eficazmente el nuevo hash y modificarse en concordancia). Sólo habría 1/(2^n) posibilidades de que el fichero resultante mostrase el mismo hash o, lo que es lo mismo, sólo 1 de cada 2^n ficheros no mostraría cambios en caso de que a todos se les añadiese el mismo código.

ToDo: replantear/recalcular

En el caso de ficheros de texto, suponiendo una modificación con "buena voluntad" (edición normal por un usuario), y pensando en una utilización de un máximo de unas 50.000 palabras diferentes que originen cada una un hash diferente (digamos que 2^16), con un hash de 2^64, al de 64/16=4 palabras habría una posibilidad de que exite alguna palabra siguiente que pudiese originar el mismo hash, o lo que es lo mismo, una combinación determinada de 4 palabras originaría podría originar una colisión. En la práctica, dado que el lenguaje impone restricciones en cuanto a la secuencia de las palabras, pero al mismo tiempo los hashes de las palabras no tienen que estar bien dispuestos, pero también en el texto predomina la representación de menos de 7 bits, se podría hablar de una fiabilidad del hash de 2 a 32 veces superior respecto a longitud si suponemos ficheros de texto bien formados que si lo hacemos con ficheros binarios.

Aún así esto no quita que dados 2^n+1 ficheros habría una colisión segura, pero dados m (con m mucho menor a 2^n) cambios "bien intencionados", esta colisión sería más probable que apareciese antes en ficheros binarios que en los de texto.

Seguridad

Contraseñas

Equivalencia en bits:

Contraseña bits Fórmula
2EijWBSD 47.76 l(26+26+10)/l(2)*8
qinmaredalkano 54.56 l(21*5+26/4)/l(2)*8
wooraghajtolu 56.40 l(21*5+26)/l(2)*8
La casa del gato verde está en llamas 58.20 l(200)/l(2)*4+l(1000)*4
El gato verde ardiendo anda corriendo rápido 71.72 l(500)/l(2)*8
60.97 l(200)/l(2)*4+l(2000)*4
63.31 l(300)/l(2)*4+l(2000)*4

Caracteres/módulos mínimos para conseguir 64 bit:

pseudo-regexp chars Fórmula Ejemplo
[a-zA-Z0-9] 10.72 ~ 11 64/(l(26+26+10)/l(2)) q N T o 9 V K 1 P h v
([:cons:][:vocal:]|[a-z]) 9.07 ~ 9 64/(l(21*5+26)/l(2)) k la w ro ta ga u so l
[a-z] 13.58 ~ 14 64/(l(26)/l(2)) c t w z j h m g c x k w f g

Software

  • KeePass
    • KeePass Pronounceable Password Generator
Obtenido de "http://wiki.jarfil.net/Security"
Herramientas personales