Módem saboteado

Hace unas semanas, descubrí que el módem de uno de mis clientes había sido alterado para intentar vaciarle sus cuentas de BBVA-Bancomer. Lo bueno es que él no tiene cuentas en ese banco.

Algo huele mal

Lo descubrí por accidente, mientras investigaba un problema con su módem de Telmex. Al revisar sus computadoras, me llamó la atención que todas tenían establecido un dominio para las búsquedas DNS:

Así se ve en OSX. En Windows aparece como "sufijo DNS específico para la conexión".

Hmmmm, el nombre de un banco… esto huele mal. Las computadoras obtenían este parámetro de parte del módem y no parecía venir de Telmex. Así que me puse a investigar.

Dentro del módem

La interfaz web de estos módems es un pequeño laberinto (¿por qué la configuración de DNS está en la sección Diagnósticos?), pero finalmente encontré lo que buscaba:

Esto no es suficiente para sabotear el portal del banco. Pero, en la pestaña Tabla de nombres, se completaba la fechoría:

Granjeros de cuentas de banco

Es obvio que un hacker se metió¹ al módem y añadió estos ajustes. El propósito de estas alteraciones es posibilitar un ciberataque conocido como pharming, que consiste en hacer que el navegador abra un sitio apócrifo cuando se visita el URL correcto de un sitio. Hay varias formas de montar un ataque de pharming, así que voy a limitarme a describir cómo funcionaba éste en particular.

Normalmente, cuando tecleamos "www.bancomer.com" en la barra de direcciones del navegador (o bien, damos click a un hipervínculo a "http://www.bancomer.com"), la computadora necesita consultar la dirección numérica del servidor llamado "www.bancomer.com". En la mayoría de las redes domésticas, las computadoras están configuradas para preguntarle al módem, que a su vez consulta un servidor DNS operado por Telmex (que probablemente consulte otro servidor DNS, y así, hasta obtener la respuesta). Cuando la computadora recibe del módem la dirección numérica de "www.bancomer.com", se la pasa al navegador, que "abre" esta dirección numérica.

Cuando el módem ha sido hackeado como en las imágenes de arriba, el módem cree que sabe "de memoria" la dirección del servidor de nombre de pila "www" y apellido "bancomer.com" y que no necesita consultarla con el servidor DNS. En esa dirección, los hackers operan un sitio falso con un gran parecido visual al de Bancomer²:

Sitio apócrifo (para phishing). Nótese que la barra de direcciones dice "www.bancomer.com".

Actualmente el formulario de acceso ha dejado de funcionar, pero presumo que simulaba un ingreso exitoso y luego intentaba engañar a la víctima para que, sin saberlo, autorizara una transacción real, probablemente una transferencia a otro banco o la compra de tiempo aire de celular.³

Notas

1. Tengo mi hipótesis de cómo se metieron los vándalos. En 2013-2014, Telmex distribuía este modelo de módem con una puerta trasera accesible desde toda la Internet. Los hackers la descubrieron y comenzaron a controlar los módems de otras personas. En algún punto de 2014, Telmex se dioc uenta y reconfiguró todos los módems remotamente, cerrando la puerta, pero algunas de las alteraciones que hicieron los hackers no fueron revertidas. Para más información de la puerta trasera, leer este post en el blog de Hackim. 
2. Sólo los clientes de DSL (Infinitum) de Telmex pueden ver el sitio apócrifo. Los demás ven un sitio genérico "en construcción".
3. Para ver un ejemplo de cómo un sitio de phishing intenta conseguir que su víctima autorice una transacción con el dispositivo de Acceso Seguro Digital Bancomer, ver este video en Youtube.

Más información

• Pharming en Wikipedia.
• Información sobre Pharming en el sitio de Bancomer. Está bastante incompleta pues únicamente toca una variante que consiste en sabotear una computadora en particular, lo cual es más fácil de prevenir y de detectar.
• Información más completa sobre Pharming en el sitio de Trusteer.

Telmex y Windows 8.1

Hoy hago un paréntesis en la ciberseguridad para mentar madres.
[Si llegaste aquí buscando una solución rápida y no tienes tiempo de leer la anécdota, salta a la solución provisional.]

Tu computadora con Windows 8 se actualiza por sus pistolas a Windows 8.1. Tu conexión a Internet comienza a fallar mucho. De pronto, ya no puedes abrir ningún sitio en ningún navegador y te sale este error:

Esta página no se puede mostrar (Internet Explorer)

Esta página web no está disponible (Chrome)

Se agotó el tiempo de espera (Firefox)

«Debe ser el cochino Infinitum¹, en un ratito se arregla». Reinicias. Recién prendida la computadora, funciona bien, pero a los pocos minutos vuelve a fallar. «Tal vez ya está chafeando mi módem»². Excepto que en la otra compu, en la táblet, en el smartphone y &emdash;hasta en la smart TV&emdash; el Internet anda perfecto. «Entonces ha de ser por la actualización de Windows, un driver incompatible o algo». Actualizas todos los drivers, restableces el Winsock, desactivas el soporte para IPv6 y haces otros conjuros peligrosos. Y sigue igual.
Llamas al soporte técnico de Telmex, donde te aconsejan lo de rutina: que reinicies tu módem, que revises que todos los foquitos (sic) estén verdes y que, de seguir teniendo problemas, eches otra llamada.
Todo parecería indicar que el culpable es Microsoft. Pero si conectas la PC afectada a otra red que no tenga el mentado módem Technicolor, ¡el Internet sirve!

Dejemos aquí la terrorífica anécdota y pasemos a lo que averigüé y qué se puede hacer.
Sucede que varios modelos de módem marca Technicolor tienen un bug que se manifiesta únicamente con el nuevo Windows. Esto se sabe desde 2013 y Technicolor respondió casi de inmediato con una configuración que evita el bug. Telmex nada más tiene que personalizarla, probarla y distribuirla a sus clientes pero, al parecer, no han sido suficientes los quejosos, o le resulta muy fácil disuadirlos («A ver, reinicie su módem; ¿ya quedó? ¡ya ve, ya está!»). O, simplemente, le importa un bledo.
Como no se ve intención de Telmex de arreglar o cambiar los modems defectuosos, no nos queda más remedio que aplicar el equivalente informático de la cinta de ducto:

Solución provisional

Cambia en tu computadora la configuración de servidores DNS, por ejemplo, por los de Google (al final del artículo puedes encontrar un nexo a una guía paso a paso):

Insisto en que es una solución provisional y no estoy seguro si elimina todos los problemas que pueda tener Windows 8.1 con este módem. Al menos, ya deja navegar y ver videos.
P.D. Si empleaste esta solución y de repente dejó de funcionar, revisa que no se haya regresado a "Obtener la dirección del servidor DNS automáticamente". Me parece que en algunas computadoras pasa esto al cambiar de red inalámbrica.

Notas

1. Una observación lingüística: Infinitum debería llevar tilde. Telmex también.
2. Estrictamente es un gateway (en español, puerta de enlace o pasarela).

Más información

• Guía paso a paso para cambiar los servidores DNS por los de Google (en PDF)
• Instrucciones para cambiar los DNS por los de Google (en inglés)

¿Cómo anda la seguridad de la banca en línea?

Si lees, ves o escuchas las noticias, seguramente escuchaste hace unos meses el nombre Heartbleed —y que tenías que cambiar todas tus contraseñas de Internet— y, más recientemente, POODLE. Sin entrar en detalles, ambos son problemas graves de seguridad que afectaron y afectan a muchos sitios web "seguros" (aquellos cuya dirección comienza con https:// y que son indicados por el navegador con un candadito).

HTTPS te garantiza que no te conectes con sitios impostores, que nadie pueda husmear en tus comunicaciones y que nadie dé instrucciones espurias en tu nombre. Pero la validez de estas garantías depende de la calidad de la implementación. Creo que todos coincidiremos en que la banca en línea está entre los sitios donde más crítico es esto.

HTTPS es como un túnel que se extiende de nuestro navegador al servidor del banco. Si un hacker logra perforarlo, podría ver lo mismo que nosotros vemos en la sesión de banca en línea, alterar nuestras órdenes –por ejemplo, la cuenta destino y el monto de un traspaso– e incluso dar órdenes espurias en nuestro nombre.
El "material" del túnel resulta de una negociación entre el navegador y el servidor. En la ilustración, el túnel es de ladrillo (representando un algoritmo considerado fuerte hoy en día). Si el servidor tiene entre sus opciones madera o paja, el túnel podría acabar siendo de uno de esos materiales en ciertas condiciones.

Así pues, me di a la tarea de estudiar la seguridad HTTPS de la banca en línea mexicana.

Metodología

Utilicé el servicio SSL Server Test de Qualys SSL Labs para evaluar la calidad de la implementación de HTTPS de ocho sitios de banca en línea de bancos nacionales y cinco de bancos extranjeros emparentados con cinco de los primeros, a fin de comparar la seguridad que implementan en casa y aquí.

Corrí la prueba para los 13 sitios en noviembre de 2014 y en febrero de 2015. A continuación reporto sólo las calificaciones más recientes, pero comento sobre los cambios más relevantes.

Resultados

Primero los bancos extranjeros, para tenerlos como referencia:

Banco	País	Calificación	Notas
BBVA	España	B
Citibank	EUA	C	Vulnerable a POODLE
HSBC	Reino Unido	B
Santander	España	F	Vulnerable a POODLE
Scotiabank	Canadá	B

Ahora los nacionales. Banamex califica ligeramente mejor que su dueño Citibank:

Banamex

Bancomer califica peor que BBVA España: [Importante: Ver actualizaciones]

BBVA Bancomer

Banorte e Ixe parecen tener configuraciones de seguridad idénticas. Sus calificaciones cayeron de A- a F en diciembre, cuando se descubrió que siempre sí son vulnerables a POODLE:

Banorte

Ixe

HSBC también cayó de A- a F en diciembre, por la misma razón:

HSBC

Inbursa, reprobado. Tiene una configuración de HTTPS arcaica; me pregunto cuándo fue la última vez que pasó una auditoría de seguridad. Al menos, es inmune a Heartbleed y POODLE. [Importante: Ver actualizaciones]

Inbursa

Santander, muy bien, mucho mejor que su matriz en España:

Santander

Scotiabank, no tan bien como su matriz en Canadá: [Importante: Ver actualizaciones]

Scotiabank

Análisis de resultados

Las calificaciones de algunos bancos (Banorte/Ixe, HSBC México y Santander España) se desplomaron en diciembre, tras el descubrimiento de que un ataque POODLE sí puede funcionar contra ellos y que las medidas de mitigación originales no les son aplicables. Quiero remarcar que no es que los sitios fueran más seguros antes diciembre; los problemas existen en sus servidores desde hace meses o años, y es posible que algún hacker de sombrero negro lo supiera e intentara sacar provecho.

El caso de Inbursa es diferente, ya que obtuvo F (reprobado) principalmente porque soporta una versión dinosáurica de HTTPS llamada SSL2. Actualmente lo que se está debatiendo es si jubilar SSL3, ¡la versión que le siguió!

En cuanto a la comparación con los bancos extranjeros, yo esperaba ver configuraciones iguales entre homólogos. Y no: HSBC, Bancomer y Scotiabank quedaron abajo de sus dueños extranjeros, mientras que Banamex y Santander calificaron mejor que sus matrices.

Finalmente, ninguno de los sitios analizados es vulnerable a Heartbleed, y tengo mis razones para pensar que ninguno lo ha sido en el pasado.

Conclusiones

Antes que nada, quiero dejar claro que una F no hace a un sitio inseguro, como tampoco una A lo hace seguro. El SSL Server Test de hecho está dirigido a los administradores de sitios para ayudarlos a encontrar los talones de Aquiles de sus propios sitios. Una calificación reprobatoria o la presencia de una vulnerabilidad no implica automáticamente que si abrimos ese sitio estamos expuestos. Hay ataques como Heartbleed que los hackers dirigen contra el servidor y no hay nada que podamos hacer, pero hay otros como POODLE que requieren ciertas condiciones en la computadora del cliente (por ejemplo, una versión particular de tal navegador o la presencia de tal plugin). Dicho esto, una calificación baja sí es un foco rojo en tanto que indica cierto descuido en materia de seguridad por parte del banco.

Es interesante que la vulnerabilidad POODLE resultó tener mucho más alcance del que se pensaba antes de diciembre, y los bancos afectados no han reaccionado.

Por último, no olvidemos que la seguridad de la banca en línea también depende de otros factores como la seguridad del propio banco (integridad del personal, seguridad física…), la seguridad del software desarrollado/distribuido/usado por el banco y ciertas prácticas y procedimientos (medidas para dificultar el phishing, manejo de los tokens…), por sólo mencionar algunos.

¿Qué opinas ahora, sigues confiando en la seguridad de tu banco?

Actualizaciones

(2015-03-25)

El 3 de marzo se anunció un nuevo ataque bautizado FREAK; se considera tan grave que cualquier sitio vulnerable obtiene automáticamente una F en el test. En consecuencia, algunas calificaciones cambiaron:

• Bancomer es vulnerable: su calificación desciende a F
• Inbursa es vulnerable (pero su calificación ya era F)
• Scotiabank México subió a B; sospecho que era vulnerable y lo corrigieron rápidamente, quedando más seguro que antes (su barrita de key exchange subió a 90)

Nuevamente hago hincapié en que los servidores identificados como vulnerables a FREAK no eran más seguros antes del 3 de marzo. En general, cuando una calificación desciende, no es debido a cambios en el servidor, sino en los criterios. Así es esto de la seguridad.

Más información

• Explicación de las calificaciones [en inglés]
• Heartbleed explicado en tira cómica [en inglés]
• Preguntas y respuestas sobre Heartbleed [en inglés]
• Discusión técnica del ataque POODLE original [en inglés]
• Discusión del más reciente ataque POODLE contra TLS [en inglés]

Inesperado regreso

Abrí este blog en 2010 y lo abandoné ese mismo año, durante la redacción de la segunda entrada, en la que pretendía explicar XSS sin nada de código. Invertí muchas horas en el borrador y nunca quedé satisfecho. Me frustré y, además, me surgieron dudas sobre la relevancia del blog, así que decidí dejar de escribir.

Cuatro años después, he decidido resucitarlo.

2014 ha sido un año muy emocionante en lo que a ciberseguridad se refiere, entre otras cosas, por el anuncio de una vulnerabilidad tras otra (Goto-Fail, Heartbleed, Shellshock), que a muchos nos dejaron boquiabiertos. Por otro lado, percibí una ausencia de discusión sobre la seguridad de los sistemas que se usan en México. Así, este blog se reabre, esta vez con una perspectiva más local.

Bienvenidos de vuelta.

El incidente en Twitter

El martes pasado, se descubrió una vulnerabilidad del tipo XSS en Twitter. No una nueva, sino una que había sido identificada y parchada hace unas semanas, y que resurgio con una actualización del sitio. El bug era grave en cuanto a que hizo posible un gusano XSS, pero de acuerdo con el reporte de Twitter, las identidades de los usuarios en ningún momento se pusieron en riesgo, y el fallo se arregló en 4 horas. Sin embargo, tengo unas cuantas reflexiones:

• Me parece que al equipo de desarrollo de Twitter le falta orden. Como ya he dicho, fue un rebrote de un bug que ya se había parchado. Estoy consciente de que estas cosas pasan, pero en Twitter constantemente vemos que los mismos problemas reaparecen una y otra vez. Además, este no fue cualquier bug, sino una vulnerabilidad más o menos grave.
• Por otro lado, la respuesta fue muy rápida y, a los que seguimos alguna de las cuentas de soporte, nos mantuvieron al tanto de los avances. Punto a favor del equipo de seguridad de Twitter.
• Volviendo a ver el vaso medio vacío, me parece que no hubo una alerta general oficial para los demás usuarios, y la lista de trending topics se llenó de frases aludiendo a que Twitter había sido hackeado. Mucha alarma y poca información de qué hacer como usuario.

Para cerrar, puedo decir que el incidente me sorprendió porque Twitter es una plataforma relativamente simple (comparada con Facebook, por ejemplo) y los desarrolladores deben haber sabido que si había un punto débil al cual debían darle meticuloso cuidado, era el parsing de enlaces externos, menciones y hashtags. Curiosamente, hace unas horas se descubrió -y reparó- otra vulnerabilidad parecida.

En fin, regreso la próxima semana para hablar un poco sobre XSS. Hasta pronto y practiquen safe hex.

Más información

• Security Nut: New Twitter Xss (en inglés)