Novedades en la categoría Seguridad

Durante el gobierno de Ronald Reagan, como parte de la investigación del famoso escándalo Irán Contras/Irán-Contra, se exhibieron un par de emails entre John Poindexter y Oliver North como pruebas de su conspiración. Estos emails fueron obtenidos de los respaldos de los servidores de email, porque los autores los habían eliminado de sus computadores cuando se vieron sorprendidos.

Ahora se ha destapado un escandalillo que involucra la filtración de email, en este caso los de la ex gobernadora de Alaska, Sarah Palin, compañera de fórmula de John McCain en las elecciones presidenciales norteamericanas (esta es una nota para los despistados, que nunca faltan).

Pero resulta que los norteamericanos tienen normas sobre el uso de email por parte de funcionarios públicos, existen leyes federales que obligan a tener un registro histórico de los correos electrónicos. Esa es la razón por lo que el comportamiento de Palin es cuestionable (aunque no es la primera vez que los funcionarios de gobierno republicanos evaden estas normas).

Ahora, yo me pregunto ¿qué pasará por estos lados?

¿Habrá siquiera una política que norme el uso de correos electrónicos por parte de los funcionarios de nuestro gobierno?

Al menos siempre me he topado en la empresa privada que existen políticas, más o menos claras, que definen que el correo corporativo no puede ser usado para otras cosas que no sean los negocios de la empresa, y por lo tanto estos son auditables.

Al menos, yo creo que los correos entregados las instituciones públicas a sus funcionarios deben ser auditables, y esto significa que debe haber un registro histórico de estas comunicaciones para su posterior análisis en proceso forenses o investigativos. Pero incluso, estos registros deberían ser asequibles al público después de un tiempo (por su valor historiográfico).

La transparencia pasa por medidas como esta, ¿no creen ustedes?

En 1981 se publica uno de los documentos más importantes de la internet, el famoso RFC 793, que define el protocolo TCP, que es el principal protocolo de internet, y que es la base de la mayoría de los protocolos usados en la red.

En este documento Jon Postel escribe, lo que ha llegado a conocerse como el Principio de Robustez, o la Ley de Postel:

Las implementaciones TCP deben seguir un principio genera del robustez: ser conservador en lo que haces, ser liberal en lo que aceptas de otros.

TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.

Dependiendo de tu sistema valórico, encontrarás el consejo de Postel como algo bueno, e incluso recomendable para otros aspectos de la vida, no sólo en los protocolos de transmisión de datos.

Este principio ha sido criticado por cierto, porque aparentemenente promueve una tolerancia pasiva, o por ser demasiado liberal, y eventualmente permite aplicaciones inseguras.

La verdad es que no era la intención de Postel ser demasiado permisivo con los protocolos, y decir que las validaciones no eran necesarias. Pero, efectivamente, el principio de robustez ha sido mal interpretado, y eso nos ha generado muchos problemas, principalmente con la seguridad de las aplicaciones.

Pero no hay que olvidar que el principio de robustez tiene una mirada puesta en las necesidades de los usuarios finales.

En la actualidad esto tiende a olvidarse, y muchos desarrolladores, sobre todo los más rígidos (y sobre todo los más jóvenes), exigen que se cumplan los estándares, sin ninguna excepción, aunque eso atente contra las necesidades de los usuarios.

Consideren el caso de HTML. ¡Un verdadero caos! hay cientos de implementaciones de HTML, con miles de bugs, parches y soluciones ad-hoc incrustadas en la web y en los navegadores de internet.

En algún momento se optó por establecer estándares basados en XML como la solución definitiva del problema, y con esto se quiebró la Ley de Postel.

XML es un protocolo estricto. En teoría un documento XML inválido no debe ser aceptado.  Pero habrán documentos inválidos, eso es casi inevitable.

Un ejemplo clásico es lo que pasa con la sigla "AT&T", de acuerdo a la especificación XML se debe escribir: "AT&T", pero eventualmente alguien escribirá "AT&T". Las aplicaciones que privilegien los deseos de los usuarios y acepten documentos XML escritos en forma no tan estricta (piensen en los varios tipos de browsers disponibles), terminarán imponiéndose (porque son aplicaciones más robustas).

XML nos pide que rompamos el principio de Postel, XML exige que seamos intolerantes con lo que recibimos. Esto puede atentar contra las necesidades del usuario.

Ese es un problema que aparece también en protocolos como SOAP, y en general casi todas las recomendaciones de interoperatividad basados en estándares rígidos, como XML. "La ley de Postel no acepta excepciones", cuando vamos contra este principio el que lo paga eventualmente es el usuario.

¿Qué opinan ustedes? ¿conocen otras situaciones donde al tratar de romper este principio perjudicamos la experiencia del usuario?

Leo en Kriptópolis que la empresa norteamericana Premier Elections Solutions (*), reconoce que tiene un error crítico de programación en su sistema de votación electrónica, que haría que miles de votos emitidos se pierdan en el proceso de conteo, y que este error está ¡desde hace 10 años por lo menos!

El error provoca la desaparición de votos antes de que sean contados y ocurre en el proceso de transferencia desde las tarjetas de memoria a la central de recuentos. Al parecer, en cuestión de milisegundos, votos aún no contabilizados resultan definitivamente descartados cuando llegan otros nuevos a la central.

El gravísimo error fue detectado tras las primarias de Ohio el pasado marzo pero, tras tratar de echar la culpa a bugs del software antivirus utilizado y a imprecisos errores humanos, la empresa se ha visto obligada a reconocer que el fallo lleva 10 años presente en su software y afecta tanto a las pantallas táctiles como a los escáneres, siendo sus consecuencias más graves cuanto mayor es el número de votos involucrados en la eleccción...

Parece que Michael Moore tiene tema para otro documental...

• una subsidiaria de Diebold, un conocido fabricante de cajeros automáticos.

Hace unos días escribí sobre la absoluta falta de preocupación de los proveedores de internet por protegernos, la cosa sigue igual, en mi caso aún mi proveedor de internet no corrige ni protege sus servidores DNS. Tal como dije en esa nota, esto es muy grave. Porque, debido a esto no podemos saber, ni estar seguros cual es la página web que estamos visitando. Esta vulnerabilidad ataca a todo tipo de computador o sistema operativo, porque es un error de diseño en uno de los servicios más importantes de internet.

Recientemente se ha difundido un video que muestra una prueba de concepto, llamada evilgrade, que aprovecha esta falla.

Aunque el video es bastante técnico, el concepto es muy simple, y preocupante.

Este ataque permite engañar a los programas que realizan una actualización autómática (upgrade). Por ejemplo, puede ser usada para engañar al sistema Windows Update, o a la actualización del Runtime de JAva, e incluso para engañar a los antivirus, que se actualizan en forma automática y periodicamente.

También, se ha publicado una herramienta de software que permite "envenenar" a los servidores DNS vulnerables al ataque Kaminsky. De hecho, uno de los hackers autores de MetaSploit, pudo detectar un ataque a su ISP en Texas, USA, que reemplazaba la dirección de Google con un servidor propio.

Esto es grave y peligroso, pero no vemos que los ISP estén haciendo mucho por resolver esta situación.
Tampoco es noticia, supongo que cuando se roben algunos millones, o se infecten miles de computadores, recién va a aparecer en los sitios de tecnología.

Bruce Schneier, escribe sobre la necesidad de diseñar el software pensando en la seguridad desde el principio.

El ejemplo planteado por Schneier es interesante, se trata de djbns, un servidor DNS que no sufre de la grave vulnerabilidad que está atacando a otros servidores DNS, porque fue diseñado desde el principio pensando en que podría ser objeto de toda una clase de ataques, de los cuales el "Ataque Kaminsky" sería un caso particular.
Daniel J. Bernstein, el autor de djbns, estudió la seguridad del DNS, y con eso pudo diseñar su software en forma segura.

Pero, como hemos discutido muchas veces, el software evoluciona, y es por eso que surgen bugs y problemas de seguridad, tal como el caso de la vulnerabilidad DNS detectada por Kaminsky.

Schneier tiene razón, parchar a gran escala no funciona bien, es caro, ineficiente, y toma mucho tiempo, a pesar de todos los empeños. Si usaramos un "diseño inteligente"¹, consideraríamos los aspectos de seguridad desde el principio.

Nos encantaría que todos los desarrolladores de software, siguieran los consejos de Schneier. Pero el software debe adaptarse a su entorno, para poder sobrevivir. Estas adaptaciones incluyen las modificaciones por "las necesidades del negocio", la presión por terminar en plazos ajustados, con presupuestos insuficientes, o se le exige al software ser flexible, al grado de se llega a exigir la capacidad de nuevas características casi todos los días. También ocurre, que entender como funciona el software es algo que toma tiempo, incluso para los mismos que lo hemos diseñado.

Esa es la paradoja, nos gustaría creer que existe un diseño inteligente, porque sería más facil entender la vida, pero no es así, por más que queramos, la vida sigue las reglas invisibles de la evolución. Del mismo modo, en el diseño del software, aunque tenemos más libertad, y somos como pequeños dioses que podemos dictar la arquitectura completa de nuestro software, este sigue las reglas invisibles de la evolución del software, similares a las que dictan la evolución de la vida.

Por supuesto que no todo es "azar y necesidad", y el ejemplo del trabajo de Bernstein es algo que debemos estudiar, e incorporar en nuestros diseños.

No, el diseño inteligente tampoco existe en software, pero al menos podemos aspirar a un diseño más seguro.

[1] Esta nota estuvo a punto de titularse "diseño inteligente", pero me rehuso a darle la más mínima ayuda a los que promueven la ignorancia .

Probablemente un usuario novicio no sabrá cómo responder esta pregunta, pero si eres un usuario más avanzado me dirás que has revisado la barra de direcciones de tu navegador, que te has preocupado de no seguir un link que recibiste por email, o tuviste la precaución de escribir la dirección que te entregó tu banco, caracter a caracter, con mucho cuidado.

¡Es más! Te entregaron un aparatito, que te dijieron que está sincronizado con un super califragilistico mecanismo al que sólo accede un servidor de tu banco, y que asegura que, si alguien llegase a adivinar tu clave, el numerito mágico que este dispositivo te entrega impide que otro pueda ingresar al web del banco haciendose pasar por tí.

Estás tranquilo y seguro de que todo funciona, porque además tu proveedor de internet te ha prometido que se preocupa de tu seguridad, protegiendote para que no entren virus, bloqueando puertos que no vas a necesitar, y evita que te lleguen emails no solicitados, que podrían tratar de engañarte.

Pero tengo que decirte que todo eso es una falsa sensación de seguridad.

Porque intentar clonar un sitio web como el de tu banco es algo que un ladrón informático intentará hacer.

Me dirás que no pueden clonar la dirección web del banco, porque hay instituciones que se aseguran que funcione todo el sistema de nombres de dominio, para que nadie se adueñe de la dirección de otros.

Efectivamente, hay una enorme infraestructura montada sobre un servicio llamado DNS que permite que puedas llegar al servidor asociado a la dirección que ingresaste en tu navegador, y esas instituciones efectivamente se preocupan de que las direcciones sean entregadas a quienes corresponden.

Es un complejo servicio, que funciona muy bien, a una velocidad asombrosa y que permite que toda la web sea lo que es.

Pero esa maquinaria, tan compleja y maravillosa tenía (tiene) un fallo en su diseño original, un error tan grande que ha sido manejado en secreto, y de forma coordinada por importantes firmas y proveedores de internet en todas partes del mundo, para que sea reparado antes de que algún delincuente haga uso de esta vulnerabilidad.

Porque esta vulnerabilidad permitiría engañar a tu computador, a tu navegador, y cualquier otros programa que use direcciones basadas en nombres, enmascarando un servidor fraudulento, redirigiendo el tráfico a donde no corresponde.

Las consecuencias serían muy graves, por eso que se ha hecho esta coordinación a nivel mundial.

Pero lamentablemente, al menos en Chile, y al parecer en España también, nuestros proveedores de internet aún no han reparado el problema, a pesar de que tienen la solución desde hace semanas.

Algo que es tan urgente, aún no ha sido ejecutado, con la prontitud que esperaríamos, no sabemos las causas, pero creo que danlo mismo la razón de la demora, es obligación de los ISP brindar un servicio seguro que nos proteja de potenciales problemas como los descritos, o al menos si es cierto lo que ellos mismos dicen, de que toman medidas, que atentan a la neutralidad de la red, para protegernos, entonces con mayor razón deberían demostrarlo parchando sus servidores DNS vulnerables.

¿Quieres saber si tu proveedor de internet se ha preocupado de reparar sus servidores DNS? visita esta dirección, y presiona el botón que dice Check My DNS, esperemos que se pongan las pilas pronto nuestros proveedores de acceso, porque tenemos razones para sospechar que pronto se empezará a hacerse mal uso de esta vulnerabilidad.

Sucede que en estos días me pidieron ayuda para revisar un sistema (escrito mayormente en C) en que participé hace 6 años atrás. En el proceso descubrimos varios errores que sólo se hicieron evidentes ahora que se intentó una actualización del sistema operativo. Errores que nunca aparecieron en 6 años de operación continua.

Considero que no se llega a entender bien un sistema hasta después de observarlo detenidamente durante mucho tiempo. Puedes volver a revisar un código que escribiste hace meses, o años atrás, y siempre encontrarás un detalle. Puede ser un error grave, que sólo aparece como warning, y que en un ambiente no produce problemas, pero que "estalla" al correrlo en otro.

Al revisar tu viejo código sucede que te das cuenta de malas decisiones de diseño, o notas que puedes hacerlo mejor (normalmente porque has ganado experiencia y sabes como escribir mejor código). Otras veces descubres serios fallos de seguridad, que son sutiles, pero que no puedes ignorar. errores que no notaste en un primer momento, o que no pudiste revisar (siempre falta tiempo).

Algo parecido es lo que ha pasado recientemente con el problema en el diseño del DNS, y que tiene de cabeza a los administradores actualizando y parchando los servidores DNS.

La lección es que nunca podemos asegurar que, dado que un sistema lleva mucho tiempo funcionando correctamente, está libre de errores.