Recently in Seguridad Category

Hay que ser muy torpe para intentar un ataque de fuerza bruta sobre SHA-256. Cuando Leo Prieto intenta minimizar los alcances de la intrusión a los sitios de Betazeta de este viernes, en realidad hunde más sus pies en el barro, y le da más argumentos a los que justifican este ataque.

Antes de seguir, quiero decir que condeno estos defacement y ataques sitios web, como lo que le ocurrió aBetaZeta este fin de semana. /* Fayerwayer en todo caso ha sido bastante sarcástico cuando esto le pasa a otros, pero dejemos esa polémica hasta acá. */

Es un dato que hay delincuentes allá afuera, entonces debemos tomar las medidas para protegernos, y cuidar la seguridad de nuestras casas. Betazeta ha crecido a un punto en que tiene muchos sitios importantes expuestos, pero también maneja la información de muchos usuarios, entonces eso implica que debe ser más profesional en la administración de su seguridad.

No basta con usar un super algoritmo de hash, porque solo los estúpidos intentarán un ataque de fuerza bruta a tus claves,  lo primero que hará un hacker es un ataque de diccionario.

Cuando un desarrollador dice que sus claves son seguras porque las almacena usando un hash avanzado, en realidad está resolviendo el problema usando fuerza bruta, y sólo los idiotas usan la fuerza bruta para resolver los problemas de seguridad.

Más importante que el algoritmo de cifrado, es tener un esquema de seguridad o política de seguridad en la administración de claves:

1. Exigir el cambio de las claves con frecuencia. 
2. No permitir el uso de palabras comunes, o que estén en un diccionario.
3. Exigir un mínimo de caracteres para la clave (10 o más).
4. Exigir la combinación de letras, números y símbolos en las claves.
5. Nunca almacenar las claves en texto plano, o con algoritmos débiles de criptografía.
6. No almacenar sólo el hash de la clave, usar un mecanismo que genere algo de entropía en la clave almacenada (salt, o algo similar).

El manejo de la identidad en la red es un tema que he abordado en este espacio, pero que me parece necesario y urgente retomar, dada ciertas coyunturas que se están dando. Es por esto que voy a iniciar una serie de artículos sobre el problema del manejo de la identidad, y parto con este artículo reciclado de julio de 2007.

"Internet fue construida sin una manera de saber quien se conecta y a que se conecta."

Dado que la capacidad de identificar a las personas no está construida en la internet todo aquel que ofrece un servicio en internet tiene que resolver el problema del manejo de la identidad e alguna manera. A medida que la web crece la necesidad de identificar se hace más necesaria, y siempre nos topamos con distintos tipos de verificación de identidad, cada uno creado y adaptado a distintas necesidades. Millones de personas han aprendido a aceptar que cualquier cosa que un sitio web les pida es la "forma normal" de conducir los negocios en línea. Han sido entrenados para ingresar sus nombres, claves secretas e información de identificación personal en cuanto formulario de entrada que se les presenta en pantalla.

Como resultado el estado actual de la identidad digital en internet es un conjunto de soluciones adhoc que lleva a que las personas tengan diversas experiencias de usuario en cada sitios web. Todo esto hace que el sistema como una totalidad se vuelva frágil y no permite la realización de la promesa del comercio electrónico (vease las leyes de identidad)

Un meta-sistema de identidad

Dado que la adopción universal de un único sistema de identidad digital o tecnología es improbable, para tener una solución de uso amplio en la internet requerimos una aproximación distinta. Una que permita conectar los sistemas existente y futuros de identidad en lo que denominaremos un meta sistema de identidad. Este meta sistema, o sistema de sistemas permite fortalecer a los sistemas de identidad que lo constituyen. Permite la interoperabilidad entre estos, y habilita la creación de una interfaz de usuario consistente para todos. (ver: La Visión de Microsoft para un Meta Sistema de Identidad).

La adopción de estos meta sistemas pueden hacer de internet un lugar más seguro e impulsar el comercio electrónico, combatir el phishing y resolver otros problemas asociados al manejo de la identidad.

En el mundo off line, la gente lleva consigo distintas formas de identificación en sus billeteras, como por ejemplo, su cédula de identida, licencia de conducir, tarjetas de crédito, tarjetas de fidelización o asociación a un club, tarjetas de viajero frecuente. La gente controla cual tarjeta usar y cuanta información revelera en cada situación.

Del mismo modo el metasistema de identidad permite facilitar a los usuarios asegurarse y controlar el aceso a sus recursos en la internet. Permite que los usuarios seleccionen entre distintos portafolios sus identidades digitales y las usan en los servicios de internet de su preferencia donde son aceptados.

El metasistema permite que las identidades provistas por una tecnología o sistema de identidad sea usada en ambientes con tecnologías diferentes, siempre que exista un intermediario que entienda ambas tecnologías y en el cual se confíe para que haga las traducciones necesarias.

Las identidades dependen del contexto

Las identidades de una persona en el mundo offline varían de las signicativas, como un certficado de nacimiento, pasaporte, o la licencia de conducir, a las más triviales, como las tarjetas de negocios o las de un club de lectores. Las persoans usan sus distintas formas de identificación en contextos diferentes donde son aceptadas. Las identidades pueden estar fuera de contexto, pero no generan el resultado esperado. Por ejemplo, tratar de usar la tarjeta del club de lectores para cruzar una frontera claramente está fuera de contexto. Por otro lado, usar una tarjeta bancaria en un cajero autmático, o un Pasaporte .Net en una cuenta hotmail es algo que claramente está en su contexto adecuado.

Muchas veces sin embargo la distición no es tan clara. Por ejemplo, en Chile el RUT, un número entregado por el gobierno, es usado como identificador para ser consultado en los sitios web bancarios.
Esto trae una serie de problemas, sobre todo porque abre las puertas para cometer varios delitos.
En este sentido el uso del RUT en nuestros sitios web bancarios es mala.

Por otro lado, aunque el Passport de Microsoft puede ser usado en cualquier sitio, e incluso es simple de usar si uno usa la plataforma .Net, su uso en otros sitios normalmente está deshabilitado, porque se considera que está fuera de contexto.

De hecho, los investigadores de Microsoft, estudiando la experiencia de Passport y otros sistemas similares que irrumpieron en los primero años de la web, en conjunto con otros expertos de la industria establecieron una serie de principios que deben guiar a todos los sistemas de manejo de la identidad. Estos principios fueron compilados en las llamadas Leyes de la Identidad, expuestas por Kim Cameron.

Las leyes de la identidad

Las leyes de la identidad son los fundamentos para los meta sistemas de identidad.
Las 7 leyes de la identidad son:

1. Control y consentimiento del usuario. Los sistemas de identidad sólo deben revelar la información identificando a un usuario con el consentimiento del usuario.
2. Acceso Mínimo para un Uso Limitado. Un sistema de identidad debe revelar la mínima información posible.
3. Justificación de las Partes. Los sistemas de identidad deben ser diseñados de modo que la información revelada esté limitada a las partes que tenga un lugar necesario y justificado en una relación de identidad.
4. Identidad Dirigida. Un sistema de de identidad universal debe soportar ambos, identificadores omnidireccionales para uso de las entidades públicas e identificadores unidireccionales para uso de las entidades privadas, facilitando el descubrimiento junto con prevenir las correlaciones innecesarias entre los identificadores.
5. Pluralidad de Operadores y Tecnologías. Una identidad universal debe utilizar y habilitar la interoperación de distintas tecnologías de identidad provistas por multiples proveedores de identidad.
6. Integración Humana. Los sistemas de identidad deben definir al usuario humano como una componente del sistema distribuido, integradod a trave´s de un mecanismo de comunicación humano máquina que no sea ambiguo y que ofrezca mecanismos de protección en contra de ataques en contra de la identidad.
7. Experiencia Consistente entre Contextos. El metasistema que unifica la identidad garantiza a sus usuarios una experiencia simple, consistente mientras permite la separación de los contextos entre distintos operadores y tecnologías.

¿Que significa todo esto?

Cuando la identidad se lleva al mundo digital esta parece estar más en peligro que en el mundo real. La gente desconfía de los servicios que piden información de identidad. Muchos negocios no se realizan porque existe el temor de perder el acceso a las cuentas bancarias, o tarjetas de crédito.
El aumento del phishing y otros mecanismos de fraude hacen que muchas personas desconfíen de los sistemas de identificación en la red.

En realidad muchos de los problemas se resuelven considerando que la identidad en linea no es distinta de la identidad en el mundo fuera de linea. Es cosa de darnos cuenta de que los mismos mecanismos que operan en el mundo offline son los que deben ser posibilitados en la internet.

Al igual que en el mundo real, uno sólo entrega su licencia de conducir a la autoridad y en una forma controlada y consentida. En el mundo digital uno debe entregar su identidad digital con las credenciales adecuadas en el contexto apropiado, pero de una manera controlada y consentida.

Por eso es que cuando entregamos nuestros datos a una institución no queremos que estos datos sean entregados sin nuestro consentimiento, y tampoco queremos que sean usados en formas no autorizadas.

Estos principios han sido expuestos claramente por investigadores de punta, y existen muchos trabajos en este sentido para asegurar que las leyes de la identidad sean entendidas no sólo por los usuarios, sino por los implementadores de sistemas que manejan información sensible. 

Para los que desarrollamos sistemas que deben manejar datos personales, el trabajo de Kim Cameron y su equipo en Microsoft son una excelente guía para no perdernos en como proteger la identidad de nuestros usuarios y clientes.

¿Quiere saber que significa trazabilidad en informática?

Una explicación con ejemplos prácticos:

Receta con Descuento: Convenios con médicos o centros médicos suscritos por alguna de las grandes cadenas. Por esta vía, el médico receta un producto y manda al paciente a adquirirlo en los locales de una cadena específica, dado que allí obtendrá descuento por la compra.

El médico, o el centro de salud, cuyo código de barra está impreso en la receta, recibe una comisión cuando esa recomendación se materializa.

[...] los laboratorios entregan un listado con medicinas a los médicos recordándoles los congresos internacionales disponibles y que por recetar ciertos remedios pueden adquirir puntos para viajar.

Tras esto, los doctores le entregan a los pacientes tarjetas de descuento que son aplicables en determinadas farmacias, las que a través del código de barra comunican a los laboratorios la aplicación de la rebaja.

"El médico ha perdido la libertad de prescribir otros medicamentos y los otros laboratorios también tienen barreras a la entrada porque los médicos se están encargando de impedir que existan medicinas de competencias", afirmó.

Hace tiempo que quería escribir sobre este problema pero al leer esta nota hoy en Manzana Mecánica, me decidí. Es cierto que una explicación sociológica (o etológica) del comportamiento de los usuarios es muy interesante, pero hay otros aspectos técnicos e incluso éticos que hecho de menos en casi todos los análisis de estos casos.

Primero, este es un problema grave, porque estamos entrenando a los usuarios a que está bien que entreguen sus emails, claves, y listas de contactos en cualquier sitio. Esto es aprovecharse del comportamiento de manada, tal comolo aclara muy bien Mig.

Segundo, porque es inaceptable que Twitter, habiéndose dado cuenta hace tiempo del problema, aún no lo haya solucionado, y lo que es peor, ellos mismos diseñaron la solución de este problema, y ¡la tienen durmiendo desde hace más de un año!

La disponibilidad de APIs es una de las características de muchos de los servicios de la Web 2.0 (como Twitter, o Facebook), y son los que les dan el dinamismo que las caracteriza (aparte de los beneficios de promoción viral, al crear un ecosistema de servicios relacionados).

Hay muchos servicios que usan estas APIs.

Un ejemplo local, el servicio Bittr, que permite enviar actualizaciones a Twitter usando mensajes de texto (SMS o MMS),  necesita que le entregues tus datos de login en Twitter. En este caso los desarrolladores, juran y rejuran que las claves están seguras (encriptadas y todo eso), y les creo, pero igual me gustaría saber como lo implementan, porque es un problema bastante complicado, pero muchachos, tomen nota, y repítanlo como mantra: nunca hay que pedirle a un usuario su clave acceso a un sitio (o servicio) de terceros.

Cada vez estamos viendo sitios que implementan esta mala práctica, y por lo tanto, siempre habrán historias de terror asociadas.

Porque este es un grave problema, conocido hace tiempo, es una mala práctica, o como algunos proponen, un antipatrón de diseño: The Password AntiPattern.

La propuesta es la siguiente:

aunque te cueste un jugoso contrato, debes negarte a implementar cualquier tipo de interfaz que involucre preguntare al usuario su clave de acceso a un sitio (o servicio) de terceros.

La extensión de este problema es cuando se le solicita al usuario que además entregue su lista de contactos.

Me van a decir, "todo bien Eduardo, entendemos tu preocupación, pero igual necesitamos acceder a los datos del usuario".

La verdad es que la gente de Twitter se dió cuenta de este problema, y empezó a trabajar en una solución, y la encontraron, en conjunto con un montón de gente inteligente de Google, y otros servicios, y hace un año resolvieron este problema, se llama OAuth, pero por alguna misteriosa razón, aún no lo implementan en Twitter, y recién van a empezar a probarlo en beta en los próximos meses!

Este ya no es un problema técnico, porque ya es posible extender este tipo de servicios sin tener que pedirle jamás al usuario su información personal de login a servicios de terceros.

Yo no sé por qué Twitter no implementa OAuth, siendo que este proyecto nació de su propia preocupación por resolver el problema. 

Me quedo con una reflexión que leí por ahí, "en esta nueva realidad de la web social, más que preguntarse de qué manera puedo estirar (o abusar de) esta herramienta o servicio, lo correcto es preguntarse en que medida lo que voy a hacer tiene un efecto positivo en mi mundo."

En 2005 escribí una prueba de concepto aprovechando la vulnerabilidad de MD5 (Busindre ha explicado mucho mejor que yo, en español, mi prueba de concepto), en realidad la prueba de concepto tomaba las ideas expuestas por Dan Kaminsky en su ahora bastante famoso paper MD5 To Be Considered Harmful Someday.

Hace unos días un grupo de investigadores europeos publicaron otra prueba de concepto igual de interesante, en un paper irónicamente llamado: MD5 considered harmful today.

Al parecer, no he leido detalladamente el artículo, la prueba aprovecha la misma vulnerabilidad que mi ejemplo. El hecho es que teniendo una manera de generar una colisión, no es complejo modificar el contenido de cualquier archivo firmado con MD5, esto se podría extender para modificar un certificado digital, convirtiendolo en un certificado raiz.

No sabemos cuantas Autoridades Certificadoras (CA) aún usan MD5 para firmar sus certificados, no creo que sea una práctica común, pero basta tener un sólo certificado firmado con este algoritmo para dejar vulnerable a todos los certificados generados por esa autoridad certificadora.

La manera más efectiva de combatir esta vulnerabilidad es dejar de usar el algoritmo MD5 al momento de certificar un certificado. Esto es algo que seguramente empezará a ser implementado en los browsers, y todas las bibliotecas que implementen SSL.

Ben Laurie, uno de los fundadores de la Apache Software Foundation, y miembro del teamo core de Open SSL ha pensado lo mismo, y al menos ha estado analizando la factibilidad de eliminar MD5 del código fuente de Open SSL, o al menos cambiar el nombre a las funciones que implementan este algoritmo, y propone calendarizar al menos la total eliminación de MD5, al parecer eliminar ahora el algoritmo provocaría una serie de problemas a varios certificados existentes.

Espero que este sea un golpe de gracia para el uso de MD5 como mecanismo de validación de firma electrónica. Me gustaría que fuera así, lamentablemente este algoritmo sigue siendo usado para certificar archivos SO, o todo tipo de documentos digitales, por ejemplo, en Chile hay varias instituciones públicas que usan este algoritmo como firma obligatoria en varias normativas y procedimientos oficiales, que transfieren información bastante sensible, esos usos no tienen efectividad alguna, tal como mostré en 2005, espero que lean este artículo alguna vez y se cambie por algo mejor.

Estuve revisando algunos sitios web importantes que usan certificados digitales en Chile, con el fin de verificar que no usaran MD5, y afortunadamente no encontré nada. Pero atención, urge impedir que MD5 sea usado como algoritmo de firma en todo certificado, así que mientras eso no suceda, en realidad no sé si podemos confiar mucho en la infraestructura PKI.

Pero tampoco quedé muy tranquilo, porque casi todos los certificados digitales que pude ver usan SHA1 como algoritmo de firma, y sabemos SHA1 va a ser quebrado más temprano que tarde (teniendo un mecanismo de generación de colisiones es posible un esquema de suplantación similar al usado con MD5).

En términos de seguridad informática hemos empezado un año entretenido ;)

Actualización: MetaSploit ha agregado al arbol principal de su código la detección de certificados emitidos y firmados con MD5, lo malo es que el problema no está en los certificados ya firmados (estos se pueden revocar), la vulnerabilidad es que podemos crear nuevos certificados firmados con MD5. Insisto, lo que hay que hacer es invalidar la verificaciónMD5 cuando se use SSL.

¡Todo mal! Resulta que ahora hasta los administradores de Fayerwayer se andan perdiendo con respecto a lo que pasó, por lo que se desprende de sus declaraciones en radios y televisión.

Con el fin de evitar que se dispersen las ideas, y se cometan errores voy a enumerar algunos puntos que me parece deberían tener claros, no vayan a terminar pelando cables y en vez de analfabetos tecnológicos se transformen en analfabestias digitales. ;)

1. Se habla de un hackeo a sitios públicos, ¡eso no es lo que pasó! Lo que ocurrió es que un comentarista publicó unas direcciones desde donde se podían bajar los datos de varios millones de chilenos.
2. Muchos abogados y "expertos" dicen que lo peor que puede pasar es que a la gente le llegue más spam, avisos no solicitados, o los molesten con llamadas telefónicas en horarios inoportunos. La verdad es que en la información del DEMRE vienen datos socio conómicos.
3. Hace unos años atrás un grupo de ladrones usaban una lista similar para clasificar a sus victimas.
4. La información filtrada es suficiente para armar una identidad digital falsa, incluso para falsificar contratos, obtener certificados, etc.
5. Hace un tiempo en seguridad informática publicaron una prueba de concepto de lo que se puede hacer con este tipo de información perdida, les sugiero verla (el ejemplo obtiene los datos de la hija de la presidenta Bachelet)
6. La base de datos del SERVEL se puede comprar, pero esa base está tan distribuida que no vale la pena comprarla, es fácil de obtener en irc, o en algún sitio warez. Hay muchas bases de datos circulando por años! he visto bases de datos que contienen los números de cuenta corriente, y hasta las claves de acceso a los sitios de los bancos. Hace un tiempo se filtró una base de datos de clientes de transbank, afortunadamente parece que sólo tuvo acceso una persona a esa información.
7. Se dice que que esto no es grave porque la información es pública. Señores, su dirección, teléfono, incluso el RUTes un dato privado! La ley no es clara con respecto a esto, pero ¿por qué tiene que saber cualquier persona mi número de teléfono o donde vivo? ¡Que ustedes tengan acceso a la información de las personas accediendo a servicios como DICOM u otros no significa que eso esté bien!
8. NO, Microsoft no tiene nada que ver con este caso.

El chernoby digital

En noviembre de 2007 un disco con data de 25 millones de ciudadanos británicos se filtró, es algo similar a lo que pasó acá, la información aparte de tener datos personales incluía datos de beneficios sociales de 7 millones de familias (la información del DEMRE es de naturaleza similar).

Kim Cameron, uno de los principales expertos en temas de identidad digital a nivel mundial lo clasificó de un Chernobyl Digital.

Según Kim vivimos en una era en que se debe diseñar la seguridad desde los niveles más bajos hacia arriba. Al menos la información como esta debería estar encriptada. ¡Es como colocar toda la dinamita en el centro de la ciudad, asumiendo que un bien pensado procedimiento impedirá que estos explosivos sean encendidos! ¡El problema es sistémico!

Todas las reflexiones de Cameron con respecto al caso británico aplican a nuestra realidad nacional.
Lo terrible es que en Chile se puede acceder casi el mismo tipo de información que en el caso británico y en forma legal.

Es para estar angustiado, pero lo dicen que los inocentes y los ignorantes son los únicos que pueden dormir tranquilos siempre.

No sé si el comentario _I thought Linux was secure, tomado aisladamente, es inocente, o provocador.
Pero deben haber usuarios que se sorprenderán al darse cuenta que linux sí puede ser atacado seriamente, y la seguridad se puede comprometer.

Lo que pasó es que un grupo de crackers británico usaron el exploit vmsplice ganar el acceso a la cuenta root en varios servidores de Claranet, en Gran Bretaña.

En realidad es bien sencillo, seguramente muchas personas tienen acceso a un servidor compartido (shared hosting), y desde sus cuentas ejecutan el código y ganan los privilegios de root.

Este es un esquema, de los muchos posibles, para usar este exploit.

Lo mismo se debe estar repitiendo en muchas partes, y vamos a tener varias noticias parecidas en las próximas semanas.

El problema es que aunque el parche es trivial, y fácil de instalar los procedimientos, y los recursos no siempre están para poder responder a tiempo, y ese lapso es el que es usado por los vándalos.

Por supuesto, veremos tontas guerras entre los linuxeros y los usuarios windows sobre que sistema es más seguro.

De todas maneras, Linux tiene un tiempo de respuesta y corrección de este tipo de fallas cási instantáneo, si esto pasara en Windows o en MAc OS, primero tendríamos un mes en que se negaría el problema, otro mes de silencio, y varios meses más para obtener una respuesta.

Pero a pesar de ese tremendo tiempo de respuesta de la comunidad linux para resolver un problema serio, se tropieza con la capacidad de respuesta, que tiene una inercia, y esta inercia la que es usada por los que quieren hacer daño.

De todas maneras, aunque se haya aplicado el parche, ¿se puede estar seguro de que el computador no fue atacado antes, y ya hay un malware o alguna cuenta extraña creada? Así que no basta con aplicar el parche, hay que auditar el sistema, son horas extras de los operadores y administradores de sistema, plata, plata, plata....

La seguridad no consiste sólo en instalar parches y tener los firewalls al máximo...