Removiendo un IP válido de DenyHosts

El script DenyHosts, es muy popular entre los system administrator de Unix/Linux porque nos permite bloquear automáticamente ataques de fuerza bruta, es decir aquellos que usando un login conocido intentan un diccionario de passwords hasta que dan con una combinación usuario/password válida. El problema radica en que el script sigue una serie de reglas fijas y uno de nuestros desprevenidos usuarios puede disparar una de las alertas y su IP queda automáticamente bloqueada para futuros accesos. Este bloqueo se suele implementar a tavés de la inclusión de /etc/hosts.deny, sin embargo el solamente borrar el IP de /etc/hosts.deny no resuelve el problema ya que DenyHosts guarda sus propios logs y la IP es insertada nuevamente si no la encuentra, porque el script asume que el hacker esta intentando ganar acceso delistando su IP. Entonces, cómo debemos remover una IP válida de DenyHosts, aquí los pasos para Debian/Ubuntu, pero pueden usar el mismo criterio para cualquier otra distribución Linux.

  1. Detenga el daemon de DenyHosts, puede hacerlo de la siguiente manera: /etc/init.d/denyhosts stop
  2. Remueva el IP válida de /etc/hosts.deny
  3. Vaya al directorio donde DenyHosts guarda su data /var/lib/denyhosts, si no tiene ese directorio en su distribución puede saber donde DenyHosts guarda su data ejecutando esta comando: grep ^WORK_DIR /etc/denyhosts.conf
  4. Busque todas las apariciones de su IP en los archivos de ese directorio, lo anterior lo puede hacer con el comando (donde www.xx.yy.zz es la IP que desea deslistar): grep ww.xx.yy.zz ./*
  5. Abra con el editor de textos favorito cada uno de los archivos donde aparece y remueva la línea donde aparece listada su IP.
  6. reinicie DenyHosts: /etc/init.d/denyhosts start

Listo con los sencillos pasos anteriores habrá resuelto su problema de remover un IP válido de DenyHosts.

Google y su promesa de un OS sin virus

No hay duda que una de las declaraciones de Google sobre su futuro Sistema Operativo (OS) que más polémica ha levantado ha sido su promesa de que Google Chrome OS resolverá el problema de virus para los usuarios. Dicha afirmación ha sido llamada "idiota" por algunos expertos de seguridad informática como es el caso de Bruce Schneier, Jefe de Tecnologías de BT (British Telecom), cuyas declaraciones difundidas a través de sendos artículos en ReadWriteWeb y PCWorld han levantado tanta polémica en la blogósfera sobre el hecho de que si es posible o no construir un OS a prueba de virus, que el mismo Schneier ha respondido a través de un post en su blog personal titulado "Making an Operative System Virus Free".

El punto principal esgrimido por Schneier para defender la respuesta que diera al periodísta por teléfono, y habiendo aceptado el hecho de no haber leído el comunicado oficial de Google respecto a Chrome OS, es el trabajo de Tesis de Ph. D de Fred Cohen, que en 1986 demostró matemáticamente que es imposible crear un programa de detección de virus perfecto. Pero más importante que las explicaciones dadas por Schneier en su blog, son los comentarios dejados alli.

De los comentarios dejados alli la forma de conseguir un sistema operativo libre de virus pueden catalogarce en 4 grandes ramas:

  • Construir un OS que siga las especificaciones de la NSA SELinux, que se basan en parte en las recomendaciones del famoso "Libro Naranja", que a su vez es la respuesta a la directiva 5200.28-STD del Ministerio de Defensa Americano.
  • Almacenar el OS en un medio de sólo lectura (ROM) cuya única misión es carga el navegador (en este caso el Google Chrome), y todas las aplicaciones residen en la web, lo mismo que los datos.
  • Un sistema de firmas digitales que identifique inequivocamente al autor del software y al propietario de la computadora, ningún software puede ejecutarce si no esta firmado por el dueño de la computadora.
  • Finalmente, la última propuesta dice que no se puede diseñar un OS a prueba de virus porque el lado más débil de la cadena es el usuario, quien suele ser descuidado porque no es responsable del daño que puede causar una computadora infectada y que pasa a formar parte de una botnet. Proponen entonces una solución basada en educar a los usuarios y hacerlos legalmente responsables por el daño causado a otros si su computadora infectada es usada como plataforma para atacar a otros.

Cada una de las propuestas tiene su justicación, pero en lo personal creo que una alternativa en la cuál el SO no es más que el mínimo software necesario para correr el navegador que se vuelve en sí mismo en la plataforma es la manera más segura de evitar infecciones, pues en caso de que el equipo se infectara por alguna razón, la forma más simple de limpiarla sería reiniciar la computadora. Pero en este escenario la responsabilidad de la seguridad se traslada del usuario al proveedor del servicio, lo cuál resulta un problema mucho más fácil de resolver desde el punto de vista de las tecnologías involucradas.

Twitter amenaza pública.

Jeff GoldblumOtra vez el problema de las historias falsas que se propagan rápidamente a través de Twitter ha hecho su aparición, según ha reportado el blog Technologizer, al parecer alguien, el día de ayer (25 de junio de 2009) decidió hacer circular la noticia de que el actor Jeff Goldblum, quien es recordado por películas como "La Mosca",  "Jurasic Park" o "Independence Day" había muerto en Nueva Zelanda. Dado el particular momento que se vivía por el fallecimiento ese mismo día de Michael Jackson y Farrah Fawcett, algunos twitteros dieron la noticia por verdaera y comenzaron a retwittearla, aunque otros se mostraron más cautelosos.

Lo cierto era que la noticia había sido fabricada usando una herramienta para crear noticias falsas sobre famosos que se llama "fake A wish.com". Aunque Twitter es un buen lugar para saber lo que sucede, una de las razones por las cuales esto pasa es porque nadie verifica la veracidad de la información, es por eso recomendable que antes de dar por cierto una noticia recibida a través de Twitter, revisar sitios como CNN o NYTimes, si los medios tradicionales no recogen la novedad propagada por Twitter lo más seguro es que sea falsa.

Esta no es la primera vez que este tipo de noticias falsas son esparcidas rápidamente a través de Twitter, en este blog hace poco más de un mes en un post titulado "Redes sociales o rebaño de ovejas", comentaba lo mismo cuando la supuesta muerta de Patrick Swayze, fue la "novedad" en Twitter. Sin embargo hoy se me ocurre darle una dimensión extra, el potencial peligro para la seguridad pública. Permitanme describirles el escenario.

Suponga que un grupo terrorista crea miles de cuentas en Twitter, y usando herramientas de spam consiguen unos cuantos cientos de seguidores por cada cuenta, esto no un escenario imposible, es más dichas redes de twitteros fantasmas existen. Supongamos que logran hackear exitosamente la página web de un medio masivo, digamos NYTimes, CNN, FoxNews, MSNBC, etc.; ahora en un momento de máximo tráfico, cuando las personas estan saliendo a su trabajo o volviendo del mismo, lanzan una campaña masiva enviando retweets de una noticia falsa inyectada en uno o más websites y esta coge rebote. Dado que es tan alta la penetración de smartphones en cuanto la noticia del "ataque bacteriológico" en una estación de metro se comience a esparcir, el pánico hara el resto, fotos de gente corriendo fuera de las estaciones llegaran a twitter y se multiplicaran con retweets, los medios cubriran la noticia del pánico y poco a poco el caos se propagará.

El escenario anteriormente descrito sería posible, debido a que las personas tienden a actuar de manera irreflexiva cuando se sienten amenazadas, aquí la palabra clave es "sentirse", el ataque no tiene por que ser real, ni tampoco tiene que ser lanzado desde el país al cual va dirigido. La única condición para que este tipo de ataques funcione es que debe ser una noticia creíble y debe ser propagada masivamente cuando el acceso a otras fuentes para contrastar dicha información sea difícil.

El escenario anterior no es nuevo, ya en el Perú durante los recientes eventos de Bagua se ha vivido. Recordemos que las noticias del "genocidio" contra los nativos con "cientos de muertos" reportado desde las radios locales generaron un efecto multiplicador en el caos de un evento que debió haber sido focalizado, el desalojo de manifestantes de una carretera.

Claro, que este tipo de ataques sirven sólo como distractores. Tarde o temprano la verdad emerge y la calma llega, pero durante el pánico, todas las medidas de seguridad quedan desbordadas y es el momento ideal para montar un ataque real.

En lo personal, este escenario me parece posible. Es más estas noticias falsas son sencillamente una advertencia de que esta forma de ataque es posible y se deben tomar medidas para evitarlo. Creo que Twitter haría bien al incluir algún sistema de ponderación, de tal forma que noticias publicadas por twittteros con baja "reputación" no alcancen una rápida propagación.

¿Acto de honor o cobardía?

K T LigeshEl día de ayer la noticia de que el proveedor de hosting británico VAServ había sido hackeado y como resultado de dicho ataque el contenido de 100,000 websites había desaparecido, fue comentada en casi toda la blogosfera desde muy distintas perspectivas. Sin embargo lo que estaba claro era que el problema era debido a una vulnerabilidad en el software usado para la administración de los servidores virtuales llamado HyperVM, producido por la compañía india LxLabs.

Como resultado de esta catastrofe y debido a la pérdida de un importante contrato, el CEO de LXLabs, K T Ligesh, se suicidó en su casa de Bangalore según reportó el diario indio Times of India, noticia que luego fuera recogida por The Register. Al parecer Ligesh de 32 años tenía problemas aún lidiando con la fatídica muerte de su madre y hermana que se suicidaron ahorcandose hace 5 años según reporta Times of India, debido a ello tal vez se puede explicar el tatuaje que llevaba en su brazo en el que se leía "GOD IS A F***inf IDIOT", su vida bohemia y tal vez la radical medida que tomo de acabar con su vida. A la derecha pueden ver la foto de Ligesh tomada de su Facebook.

La vulnerabilidad que permitió a los hackers destruir la mitad de los servidores que alojaba VAServer, fue reportada el 21 de mayo pasado por milw0rm en privado a LxLabs, sin que este diera muestras de querer resolver el problema, como resultado de ello, la vulnerabilidad fue hecha pública el pasado jueves 4 de junio y el ataque contra la infraestrcutura de VAServ el domingo 7 de junio en la noche. Esta no era tampoco la primera vez que el producto presentaba problemas de seguridad, sin embargo como aclaró Jonathan Zahedieh en uno de los comentarios de la noticia a pesar de haber seguido el procedimiento regular de informar primero al desarrollador del software, este no dio muestras de querer resolver el problema y la publicación del exploit no fue un acto de venganza.

El suicidio de Ligesh puede verse de dos formas, yo lo veo como un acto final de honor y sincero arrepentimiento, después de todo lo único que quedará de nosotros, luego de nuestra muerte, será el recuerdo que dejamos y ciertamente ser recordado como alguien que aceptó sus culpas, restituye en algo la imagen de administrador negligente e indiferente a asuntos críticos para su empresa. La otra forma de verlo es como un acto de cobardía para huir de las responsabilidades legales resultado de la terrible pérdida financiera infringida a VAServ, esta es la postura sostenida por mi compañero de trabajo Zilvinas Stumbras. Este es un tema muy controversial y cada quién puede verlo desde una perspectiva diferente.

Mi reflexión final es que si los CEOs fracasados de los grandes bancos norteamericanos de inversión, Bernie Madoff, George W. Bush o Dick Cheney se hubieran suicidado luego de sus fracasos tan sonoros, que tuvieron tanta repercusión en la sociedad, al menos yo podría tener otra mirada sobre sus vidas. El haber sido los causantes de tremendos desastres y seguir viviendo como si nada hubiera pasado, sin admitir la menor responsabilidad es simplemente una acción que los pinta de cuerpo entero como personas sin honor, que no merecen la confianza de sus semejantes. Un suicidio no devolvería el dinero a todos los afectados por la estafa de Madoff, sin embargo sería una señal de que el actuó de buena voluntad y no deseaba causar todo el daño que finalmente causó. Por otra parte el que siga vivo tampoco es garantía ni de que colabore con la justicia, ni que se recupere algo del dinero que dilapidó. Así que si me preguntan, en estos casos donde un ser humano por sus errores afecta la vida y el futuro de muchos otros, debe de elegir el camino más honorable posible.

Vulnerabilidad 0 day en Windows 2000/XP/2003

Me ha llegado una notificación de la lista de correos de Hispasec, sobre una vulnerabilidad 0 day, es decir no hay parche disponible y el error esta siendo usado por cyberdelincuentes para atacar equipos Windows, aquí la descripción del problema:

"Microsoft ha reconocido en un aviso oficial una vulnerabilidad en DirectX sobre [Windows] 2000, XP y 2003 que podría permitir a un atacante ejecutar código arbitrario. El fallo parece que se está aprovechando en estos momentos por atacantes, por lo que se convierte en un 0 day. Es explotable a través de archivos de QuickTime.

DirectX 7.x, 8.x y 9.x sobre Windows 2000, XP y 2003 sufre de una vulnerabilidad en la forma en la que DirectShow (en quartz.dll) maneja el formato QuickTime. Si la víctima abre un archivo QuickTime especialmente manipulado a través de cualquier vía (también a través el navegador), el atacante podría ejecutar código arbitrario con los permisos del usuario que ejecuta la aplicación."

Aunque soy usuario de Linux en el desktop y en mis servers desde hace muchos años, soy conciente de que la gran mayoría de usuarios tienen a Windows en sus escritorios y para ellos va la advertencia, de paso que protegiendo sus equipos alivian un poco mi trabajo de filtrado de spam. Bueno la recomendación hecha por Microsoft para evitar que la máquina pase a formar parte de una de las muchas netbots que existen en Internet es:

  • Deshabilitar la interpretación de contenido QuickTime en quartz.dll borrando la rama HKEY_CLASSES_ROOTCLSID{D51BD5A0-7548-11CF-A520-0080C77EF58A} del registro.
  • Modificar la ACL de quartz.dll eliminando los permisos NTFS.
  • Desregistrando la librería (Regsvr32.exe –u %WINDIR%system32quartz.dll).

Más información sobre la vulnerabilidad en Technet http://www.microsoft.com/technet/security/advisory/971778.mspx