Hace unos días se supo que se había detectado un grave fallo en las DNS, y que muchos servidores eran vulnerables.
Para saber si las DNS de tu equipo son del grupo de vulnerables, puedes chequearla desde aqui.
Claro que te tienes que fiar de que si te dicen que la tuya es vulnerable, la que te dan no lo es 😉
Como comenté ayer, y como observarán los asíduos, hemos cambiado la web. Pero el cambio ha sido mas profundo que todo eso.
En realidad hemos cambiado el blog, la web, el alojamiento, y alguna cosa mas. Y todavía faltan detalles.
Y ha sido menos traumático de lo que cabía esperar. Mas o menos ha sido así.
Contratamos un nuevo alojamiento con Bluehost , (con el que estábamos probando con otros dominios), mucho mas espacio en servidor, transferencia de 3 TB mensuales, y un montón de cosas mas. La semana pasada comenzamos a migrar el blog, y los posts que estaban almacenados. Cuando nos pareció que todo estaba bien, venía lo mas complicado, migrar cuentas de correo, cambiar los DNS, etc.
Pensamos que era conveniente hacerlo por la noche para perder el mínimo de correos, visitas y que, de paso, se actualizasen correctamente los DNS. Asi que el lunes por la noche (podíamos haberlo hecho en fin de semana, pero no lo creímos tan crítico) cambiamos los DNS, y esperamos a ver que pasaba.
A eso de las 12 y media (un par de horas después del cambio) dejó de verse la web antigua, y tampoco se veía la nueva, y así fue durante unas horas. Pero a las 7 de la mañana empezó a verse el dominio nuevo. Comenzamos a crear las nuevas cuentas de correo, e inmediatamente los correos llegaban bien.
Quedaban algunos detalles peliagudos, uno de ellos era direccionar los enlaces que antes apuntaban a camyna.com/wordpress a solo camyna.com y Helektron dío con la solución:
tenemos un antiguo blog y sus noticias tenían el formato:
http://www.hola.com/wordpress/2005/04/28/hola-mundo/
Resulta que nos hemos migrado y ahora tenemos todo el contenido bajo:
http://www.hola.com/
Con lo que las noticias tienen el siguiente formato:
http://www.hola.com/2005/04/28/hola-mundo/
Para solucionarlo, simplemente tenemos que crear un archivo llamado .htaccess, editarlo y escribir:
RedirectMatch 301 ^/wordpress(/.*)?$ http://www.hola.com$1
Con esto conseguiremos que TODAS las peticiones que se hagan bajo http://www.hola.com/wordpress/ se redireccionen a http://www.hola.com/.
OJO: Con esta norma se redireccionarán también todas las rutas de imágenes. Si por ejemplo tenemos:
http://www.hola.com/wordpress/img/hola.gif
Se redireccionará a:
http://www.hola.com/img/hola.gif
Luego subimos los posts que se habían escrito los últimos días, y por el camino se nos perdió algún comentario (sorry) .
Anunciamos el cambio de look, RSS y pusimos un aviso en la antigua dirección que ahora ya no está, puesto que no es necesario.
El caso es que a media mañana todo iba como la seda. En apenas 10 horas todo el proceso estaba completado, y al parecer no hemos perdido casi nada por el camino, chapeau!!
Ahora a seguir trabajando, y esperando que os guste el cambio. Cualquier duda, sugerencia, notificación de error, o lo que sea, nos lo podéis hacer llegar. Seguro que os podemos ayudar, Helektron es un «fenómeno» en esto, y a las pruebas me remito.
Hablábamos el otro día sobre este serio problema de seguridad de Microsoft Windows,
Hoy encontramos mas información al respecto en Hispasec.
Microsoft confirmaba a través de una notificación oficial el día 13, la existencia de una vulnerabilidad que estaba siendo aprovechada por atacantes «de forma muy limitada» según la propia compañía. El problema se debe a un desbordamiento de memoria intermedia en la implementación de la interfaz RPC del servidor DNS (Domain Name System) de Windows a la hora de procesar peticiones mal formadas. Esto puede ser aprovechado por atacantes para ejecutar código arbitrario con privilegios de SYSTEM (control total sobre el sistema) si se envía una petición especialmente manipulada al sistema vulnerable.
Esto afectaría a un sistema sólo si mantiene un DNS (típicamente en servidores de Microsoft) y un potencial atacante tuviese acceso a unos puertos específicos. El ataque no sería posible exclusivamente a través de puerto 53, abierto habitualmente al exterior para las consultas DNS, sino que debe apoyarse de la capacidad de administración remota de DNS (a través de RPC) para explotar la vulnerabilidad y ejecutar código. Microsoft proporcionó un método para eliminar esta funcionalidad y proteger el sistema a falta de parche oficial.
Aun así, varios factores se han añadido a la ecuación para convertir esta vulnerabilidad en un verdadero peligro. Típicamente un controlador de dominio en red interna es también el servidor autorizado DNS del dominio. En una red interna, no suelen protegerse estos controladores tras un cortafuegos, o las reglas de filtrado pueden estar más relajadas. En ese caso, aunque no expuesto al exterior, el servidor podría quedar fácilmente comprometido desde la misma red interna. Si el controlador de dominio queda comprometido, el atacante habría llegado al corazón de una red interna controlada por el directorio activo.
El día 15, metasploit descubrió un exploit público capaz de aprovechar esta vulnerabilidad. Queda desde entonces abierta para todos la posibilidad de estudiar y experimentar con el fallo. El problema concreto parece estar en la función extractQuotedChar. Los ataques dejan de ser «limitados».
Además, aparece al poco tiempo un nuevo exploit (programado por Andrés Tarasco y Mario Ballano) que es capaz de aprovechar la vulnerabilidad sin necesidad de tener acceso al rango mencionado en un principio (1024-5000), sino que permitiría ejecutar código a través del puerto 445. Este puerto es usado para el protocolo SMB (Server Message Block) sobre TCP/IP, y se utiliza para el intercambio de ficheros, entre otros fines. Una vez más, este puerto no suele estar expuesto al exterior, pero mantiene e incluso agrava el problema en redes internas, donde estará abierto con casi toda seguridad. Este código también afecta a Windows 2003 con SP2.
Para colmo, se ha detectado un gusano que intenta aprovechar la vulnerabilidad. El nombre elegido es Rinbot, y una vez que logra ejecutar código, se conecta al dominio x.rofflewaffles.us y convierte a su víctima en zombie (parte de una botnet). La detección específica por parte de los antivirus es escasa todavía. Según el SANS, que ha usado VirusTotal para el análisis:
AhnLab-V3 2007.4.14.0 04.16.2007 Win32/IRCBot.worm.199680.I
AntiVir 7.3.1.52 04.16.2007 HEUR/Crypted
AVG 7.5.0.447 04.16.2007 Win32/CryptExe
DrWeb 4.33 04.16.2007 BackDoor.IRC.Sdbot.1299
eSafe 7.0.15.0 04.16.2007 Suspicious Trojan/Worm
Fortinet 2.85.0.0 04.16.2007 suspicious
Kaspersky 4.0.2.24 04.16.2007 Backdoor.Win32.VanBot.bx
Prevx1 V2 04.16.2007 Malware.Trojan.Backdoor.Gen
Symantec 10 04.16.2007 W32.Rinbot.A
Webwasher-Gateway 6.0.1 04.16.2007 Heuristic.Crypted
Sospechamos que esta vulnerabilidad provocará un nuevo parche fuera del ciclo habitual de Microsoft. De lo contrario no habría solución oficial hasta al menos el ocho de mayo. Se recomienda deshabilitar la capacidad de manejo remoto sobre RPC para los servidores DNS o bloquear el tráfico entrante no solicitado entre los puertos 1024 y 5000 e incluso 445 si no es necesario.
Para deshabilitar la capacidad de manejo remoto sobre RPC, en el registro, en la rama:
«HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters»
se debe añadir un valor DWORD llamado «RpcProtocol» con el valor 4. Es importante destacar que es necesario reiniciar el servicio DNS para que el cambio surta efecto.
Más Información:
Monday update on Microsoft Security Advisory 935964
http://blogs.technet.com/msrc/archive/2007/04/16/monday-update-on-microsoft-security-advisory-935964.aspx
Situation update on Microsoft Security Advisory 935964
http://blogs.technet.com/msrc/archive/2007/04/15/situation-update-on-microsoft-security-advisory.aspx
Vulnerability in RPC on Windows DNS Server Could Allow Remote Code
Execution.
http://www.microsoft.com/technet/security/advisory/935964.mspx
New Rinbot scanning for port 1025 DNS/RPC
http://isc.sans.org/diary.php?storyid=2643&rss
DNS Vulnerability being Exploited in the Wild
http://www.symantec.com/enterprise/security_response/weblog/2007/04/dns_exploit_time_is_upon_us.html
Encuentro en Hispasec la siguiente noticia:
Este es un boletín con carácter de urgencia debido a la gravedad del fallo. Se ha encontrado una vulnerabilidad en el sistema DNS de Microsoft Windows que puede ser aprovechada por atacantes remotos para ejecutar código en el sistema.
El problema se debe a un desbordamiento de memoria intermedia en la implementación de la interfaz RPC del servidor DNS (Domain Name System) de Windows a la hora de procesar peticiones mal formadas enviadas a un puerto entre el 1024 y 5000. Esto puede ser aprovechado por usuarios no autenticados para ejecutar código arbitrario con privilegios de SYSTEM (control total sobre el sistema) si se envía una petición especialmente manipulada al sistema vulnerable.
Sólo se ven afectados los sistemas que ejecuten este servicio (DNS), que suele ser la gama «server» de Microsoft. Desde algunas fuentes afirman que ya se están produciendo ataques intentando aprovechar el fallo.
Se recomienda deshabilitar la capacidad de manejo remoto sobre RPC para los servidores DNS o bloquear el tráfico entrante no solicitado entre los puertos 1024 y 5000.
Para deshabilitar la capacidad de manejo remoto sobre RPC, en el registro, en la rama:
«HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters»
se debe añadir un valor DWORD llamado «RpcProtocol» con el valor 4.
Los problemas causados por los DNS de Telefónica (que a esta hora desconozco si se han solucionado), han dado sus resultados. Negativos por supuesto.
Hoy al mirar las visitas a la web, y también los ingresos por publicidad, los valores han menguado sensiblemente. No es que me afecte excesivamente. No es que gane mucho dinero con esto, pero si que me preocupa que al igual que mi página estuvo desaparecida para miles de usuarios, también lo estuvieron las de al menos una docena de mis clientes.
Algunas de esas páginas son de comercio electrónico, y otras dan servicios muy concretos de los que dependen esas empresas. Para esas empresas yo soy (CAMYNA como empresa), el responsable de su sitio web, y por lo tanto a quien primero llaman. Yo llamo a mi proveedor, me dicen que el problema es de las DNS de Telefónica, vale, las cambio, pero eso consigue que yo pueda navegar por esos sitios, pero ¿y el resto de los internautas?, ¿quien les dice que cambien?.
Además mi proveedor echa la culpa a Telefónica, y Telefónica (a la que no he llamado), me puedo imaginar que también escurrirá el bulto. La indefensión es total. ¿Cuanto dinero se podrá llegar a no ganar en días como el de ayer? .
Y ahora solo me queda esperar que esté todo arreglado, que los DNS hagan su trabajo, y la gente poco a poco vaya visitando lo que se dejó pendiente.
He elegido un mal día para navegar.
Google Reader también se queja.
En vista de los problemas de DNS que hay hoy, y para prevenir nuevos, pongo aqui un listado de DNS que he sacado de ADSLAYUDA.
Y aqui un manual de como hacerlo.
Hoy «no funcionaban» ninguno de nuestros dominios, bueno para ser exactos sólo funcionaba notefi.
Una vez que he hablado con el proveedor (que me ha costado un buen rato), me ha comentado que hay problemas con los DNS de Telefónica que no están actualizando correctamente.
Me han pasado 2 que si que funcionan: 62.36.225.150 y 62.37.228.20