En muchas ocasiones, como cuando se hacen túneles SSH, es más cómodo mantener una conexión abierta que no se cierre por timeout. Una manera de hacerlo es mediante las políticas del servidor SSH, pero otra manera más sencilla es hacerlo por cada conexión desde el cliente.

Comúnmente en los clientes SSH en Unix están las opciones TCPKeepAlive y ServerAliveInterval. La primera indica que se quiere mandar un paquete SSL por TCP hacia el servidor para mantener la actividad y la otra indica el intervalo en segundos en el cual se van a mandar los paquetes. Un ejemplo de uso sería el siguiente:

ssh -o TCPKeepAlive=yes -o ServerAliveInterval=5 usuario@servidor

Así ya podrán mantener sus sesiones de SSH abiertas todo el tiempo que quieran y no olviden cerrarlas cuando las dejen de usar.

Hace poco tuve un accidente con mi MacBook Pro y el disco fue lo único que se dañó, porque también es el componente más sensible a una caída (ya ni la pantalla) y no se volvió inservible, pero se dañó lo suficiente para que no todos los archivos fueran recuperables, por lo que perdí casi toda mi música y algunas otras cosas. Lo único bueno es que generalmente mis proyectos de software están en un SVN por lo que no perdí información trascendental y valiosa. Pero para cualquier desarrollador es muy engorroso y lento instalar de nuevo todo el software que utilizas de diario, por lo que me arrepiento tanto de no haber tenido un Time Machine.

Antes de hacer mi copia me estuve informando y estuve pensando seriamente cómo debía hacer este proceso, por lo que aquí les dejo unas recomendaciones:

1. Compra un buen disco duro externo, con capacidad de al menos el doble de capacidad de tu disco duro actual
2. La versión inicial de Time Machine es muy importante, porque de ahí se derivará todo un árbol a futuro de los cambios que se vayan haciendo a tus archivos
3. Baja una herramienta como GrandPerspective o DaisyDisk para observar cómo está distribuido el espacio en tu disco actual.
4. Organiza tus archivos, haz un directorio llamado “NoBK” en donde vayan archivos grandes o cosas que ocupen mucho espacio y que si el día de mañana no estuvieran no tendría importancia.
5. Algunos discos duros externos vienen con algún formato o traen herramientas para formartearlos. Lo mejor será abrir la Utilidad de Discos, borrar todo el disco y formatearlo en Mac OS Plus
6. Antes de hacer la primer copia de seguridad, configura tu Time Machine y excluye tu carpeta “NoBK” y la de “Descargas”. Algunos recomiendan otras de sistema pero es un error si quieres poder recuperar tu instalación actual en caso de un percance
7. Haz tu copia de seguridad inicial y procura diario hacer una al menos por las noches

Time Machine no sólo sirve para hacer copias de seguridad en caso de daño a tu disco o robo, también si quieres jubilar tu actual Mac a una más nueva puedes usar la copia de Time Machine para restaurar tu instalación en otro equipo.

Otra reflexión interesante cuando ocurrió el percance, es que mis datos más importantes nunca estuvieron en peligro, porque actualmente todo está en la nube, el correo, documentos, calendarios y código fuente en svn.

Si en lugar de usar Time Machine quieres algo más ubiquo y en la nube puedes probrar CrashPlan, es un servicio que te permite hacer respaldos en la nube, pero debes tener una muy buena conexión para que sea útil.

Es bien sabido que Telmex es la principal empresa proveedora de enlaces a internet en este país y en el mundo de la seguridad (sobre todo para los amantes de aircrack) es además bien sabido que son la principal empresa que instala sus modems preconfigurados con la insegura y obsoleta tecnología WEP para proteger el acceso a las redes inalámbricas de cada punto de acceso. Para decirlo pronto y claro, cualquier persona con un pequeño entrenamiento puede colarse a la red inalámbrica de tu casa si es que tienes Infinitum.

Con esta información, da mucha risa que ofrezcan estos servicios de “seguridad” cuando sería trivial colarse a la red local de una empresa que tenga contratado un Infinitum, por más firewall, VPN e IPS que tengan configurado. Una vez dentro de la red local “de ahí pal real” con todas las máquinas Windows que tengan, recursos compartidos en red, conversaciones en MSN, passwords que viajen en texto plano (sin https), etc.

Al final es triste recordar la incultura en seguridad que se tiene en el mundo empresarial, las pésimas políticas que se adoptan y los engaños de marketing que les cuelan. Lo peor es que no se limita a México, sino en todo el mundo es lo mismo.

Si quieren verdadera seguridad para sus servicios, ahí les dejo nuestro enlace.

P.D. Dado que no quiero darle referencias de este blog a esa abominación de empresa llamada Telmex usé la etiqueta rel=”nofollow” para el enlace.

En la siguiente animación se pueden seguir las proyección de los pasos a seguir para lograr el rescate:

Rescate de los mineros chilenos atrapados bajo tierra

La noticia saltó a los medios especializados el 16 de julio. Los primeros detalles indicaban que la vulnerabilidad permitía a un atacante ejecutar automáticamente código al insertar un medio extraíble en el sistema. La crónica y más detalles se puede encontrar aquí:

Interesante (y peligroso) troyano que aprovecha un interesante (y peligroso) 0 day en Microsoft Windows

Ahora el código es público y ni lentos ni perezosos ya lo incluyeron en la archiconocida suite MetaSploit. Aunque ya es posible mitigarlo mediante una Directiva de Seguridad Local, Microsoft no ha publicado aún ningún parche.

Gracias a Un informático en el lado del mal por la recopilación de fuentes.

Protocolos de conocimiento cero (ZKP)

Sabemos que sin un esquema de cifrado de llave pública es trivial para un atacante interceptar la información que se envía entre el cliente y el servidor, pero el sistema debe tener alguna manera de autenticar a los usuarios del sistema. Necesitamos enviar algo que si un atacante intercepta no pueda utilizar para autenticarse. Esto se conoce como un protocolo de conocimiento cero (Zero-knowledge proof), y en palabras coloquiales significa: “probar que poseemos cierta información sin revelar esa información”.

Como comúnmente la única información que queremos “probar que poseemos pero no queremos revelar” es la contraseña, voy a explicar el esquema que usa MySQL para implementar su autenticación de usuarios. Los detalles no están explicados de manera formal en la documentación de MySQL pero alguien se tomó el tiempo de leer el código fuente y explicar cómo funciona (MySQL 4.1.x authentication internals).

¿Cómo se almacenan las contraseñas?

Lo primero que hay que tener en cuenta es que, siguiendo los principios básicos de almacenamiento seguro de contraseñas, éstas se almacenan en el sistema sólo como un hash criptográfico. Que tiene la propiedad de ser prácticamente irreversible y prácticamente único. Por lo que esta es la primera parte del ZKP, ya que sólo quien conozca la contraseña podrá generar el hash criptográfico que le pertenece.

Desde MySQL 4.1 las contraseñas de usuario están almacenadas en la tabla “mysql.user” en la columna “Password” de la siguiente manera: . Donde es el hash criptográfico SHA-1.

La transmisión

Si cada vez que el cliente se quiera autenticar sólo transmitiera , cumpliría con el principio de no revelar la contraseña, pero un atacante podría capturar y enviar después para autenticarse exitosamente aún sin conocer la contraseña. Por lo que necesitamos agregar más cosas al protocolo para que la información que transmite el cliente sólo sea útil para un intento de autenticación.

Este sería el esquema cliente-servidor para la transmisión:

1. Se inicia el intento de autenticación
2. El servidor genera una cadena aleatoria y se la transmite al cliente.
3. El cliente calcula , y (aqui significa concatenación).
4. Finalmente el cliente transmite . (aquí significa bitwise XOR)

Autenticación

El servidor sólo conoce , que está almacenado en la tabla de usuarios, y . Para autenticar hace lo siguiente:

1. Calcula .
2. Calcula .
3. Calcula .
4. Sólo si la autenticación es exitosa.

Observaciones

Nunca se transmite ni , por lo que la fortaleza está en que este ZKP verifica que el cliente conoce y pero sin revelar esa información, y que sería casi imposible que un atacante poseyera sin conocer .

También hay que observar que es una cadena única por cada intento de autenticación, o sea que esa cadena siempre está cambiando.

Implementación

Próximamente trabajaremos en una implementación de este esquema para aplicaciones web usando JavaScript y PHP, que publicaremos bajo licencia LGPL.

Este malware viene incorporado en un screensaver contenido en un paquete .deb que requiere privilegios de administrador para instalarse. Específicamente es un troyano diseñado para formar parte de una Botnet y hacer ataques DDoS.

Las instrucciones para eliminarlo revelan dónde se instala y cómo se autoejecuta:

sudo rm -f /usr/bin/Auto.bash /usr/bin/run.bash /etc/profile.d/gnome.sh index.php run.bash && sudo dpkg -r app5552

Hace tiempo reflexioné sobre este futuro poco alentador en un artículo sobre un troyano en mac. Lo que me lleva a hacer una reflexión que me gustaría que todos los linuxeros nos hiciéramos: ¿cuántas veces has revisado lo que hace e instala un paquete .deb antes de ponerle tu contraseña de administrador?

Eso de creernos invulnerables por usar Linux o Mac OS pronto va a dar frutos, y son frutos podridos. Si se le sigue diciendo a la gente, sistemáticamente, que es invulnerable al malware es casi seguro que caiga en un engaño por exceso de confianza. También pasó con el troyano que venía en la versión de bittorrent de iWork y quién sabe cuántos aún sigan infectados.

Para hacer este tipo de cuestiones existe un sitio que nos permite hacer una comparación general de precio en diferentes cosas: restaurantes, productos básicos, transporte, renta de departamentos, gasolina, internet y telefonía. El sitio es:

http://www.numbeo.com/cost-of-living/compare_countries.jsp

Hoy encuentro una serie de posts referentes a un exploit en concreto en donde explican con cierto grado de detalle los pasos concretos a seguir y los conceptos que hay detrás de un exploit por stack overflow para la aplicación Easy RM to MP3 Conversion Utility.

Exploit writing tutorial part 1 : Stack Based Overflows

Exploit writing tutorial part 2 : Stack Based Overflows – jumping to shellcode

Exploit writing tutorial part 5 : How debugger modules & plugins can speed up basic exploit development

Exploit writing tutorial part 3 : SEH Based Exploits

Exploit writing tutorial part 6 : Bypassing Stack Cookies, SafeSeh, HW DEP and ASLR

Exploit writing tutorial part 3b : SEH Based Exploits – just another example

Exploit writing tutorial part 4 : From Exploit to Metasploit – The basics

Exploit writing tutorial part 7 : Unicode – from 0×00410041 to calc

Y sigue actualizándose.

El NIST, la agencia encargada de definir los estándares tecnológicos para las agencias federales de EEUU, establece que la información con vigencia menor a 2010 debe usar al menos 1024 bits, con vigencia menor a 2030 deberá usar al menos 2048 bits y con vigencia mayor a 2030 deberá usar 3072.

Bruce Scheiner por otro lado en 2002 ratificó una tabla publicada anteriormente por él mismo en donde establece los bits recomendados según seas un individuo, una corporación o el gobierno. Ahí estipula que para 2005 los individuos ya deberían usar llaves de 1280 bits, y el gobierno ya debería estar usando 2048 bits.

Algunos más “inteligentes” que los anteriores, dicen que todos exageran, y recomiendan 1025 bits, razonando superfluamente que eso duplica la complejidad de la factorización. Ese razonamieto surge de pensar que el mejor algoritmo de factorización es por “fuerza bruta” sobre los posibles factores, probando todos los números entre y para factorizar un módulo de 1024 bits, pues sus factores primos son de 512 bits.

La realidad es otra, y desde hace tiempo, desde Fermat de hecho, existen métodos sublineales de factorización de enteros respecto al tamaño del entero y los mismos algoritmos son subexponenciales respecto al número de bits del entero. Por lo que aumentar un bit la llave no es tan drástico como aumentarlo en otros algoritmos como AES, como no es tan drástico multiplicar por dos el tamaño del entero, pues eso no duplicaría el tiempo necesariamente. ¿Pero qué tanto aumenta el tiempo un bit más?

Criba General de Campos Numéricos (GNFS)

GNFS es el mejor algoritmo de factorización de enteros, conocido a la fecha, para enteros de 130 digitos al menos (que son aproximadamente 432 bits). En 2005 el algoritmo se utilizó para romper el récord de factorización RSA para un entero de 640 bits, hazaña que fue llevada acabo por un equipo de investigación alemán. Lo interesante de este algoritmo es su complejidad, y en base a ella voy a realizar algunos cálculos para esclarecer qué tan fuerte es aumentar un bit más a un módulo RSA.

La complejidad del algoritmo está dada por

donde es una constante dada por la heurística utilizada en el algoritmo y es el número a factorizar (no los bits del número). Carl Pomerance, creador del segundo mejor método de factorización, indica que en este caso . Por otro lado tenemos que es una función asintótica que tiende a cero, por lo que para los cálculos se va a considerar como cero, pues Pomerance así lo toma.

Teniendo eso, lo que se puede hacer ahora es calcular el tiempo del algoritmo para factorizar un número de 1024 bits y comprarlo respecto al tiempo para factorizar uno de 1025 bits. Por lo que vamos a denotar al tiempo de 1024 bits y al tiempo de 1025 bits.

Sabemos que un número de 1024 bits se aproxima a y uno de 1025 bits a , por lo que se van a tomar esas aproximaciones para simplificar la exponenciación. Tenemos entonces que

donde es la constante de la notación asintótica.

Por lo tanto tenemos que

Que es muy poco. Pues si el gobierno de algún país contara con los recursos para romper un módulo de 1024 bits en 24 semanas (6 meses), entonces romper uno de 1025 bits les llevaría casi 25 semanas. Esto en el mejor caso, puesto que la complejidad del algoritmo está dada en notación O, así que el algoritmo podría comportarse aún mejor de lo estimado y ser más rápido.

Si hacemos lo mismo y comparamos un módulo de 1024 respecto a uno de 1280, tenemos que . Que es bastante decente, y suponiendo que se pudiera factorizar el módulo de 1024 en una semana, entonces tardarían 8 años y medio en factorizar el de 1280; lo que le da bastante más confiabilidad a ese módulo que a uno de 1025. Aunque un cálculo más correcto sería considerando una ecuación diferencial porque la capacidad de cálculo no va a permanecer 8 años igual, va a ir aumentando.

Pragmáticamente hablando

Seguramente alguno va a desconfiar de este análisis, y necesitará una prueba más terrenal, sin tanta matemática. En ese caso lo invito a bajar un paquete que tenga implementado el algoritmo y factorice un número de unos 450 bits, que se puede hacer en un tiempo bastante decente (unos minutos) y vaya aumentando de bit en bit, para comparar los tiempos. Implementaciones hay varias y se pueden encontrar en la página de la wikipedia sobre GNFS.