« Recuperar los passwo... | Main | El definitivo script... »
20090625 jueves junio 25, 2009

Cuando la seguridad flaquea en sutilezas

Estaba yo peleándome con el chungo CAS para montar un tutifruti de SSO (aka chingechingón) con la idea de usarse en Joomla+Mantis+Alfresco+Cocoon, cuando me percaté, tras un accidente (como Pasteur con sus mohos en la 'petri'), de que algo no iba como la lógica dicta que debería de ir.

¿Qué pasa si en tu ordenador se retrasa la fecha del sistema 1 año, y te vas a una página, por ejemplo gmail.com y te logineas?

Pues que observarás un curioso mensaje como este:

Error de certificado todavía no válido

¿Y que tiene de especial?, pues que evidentemente el certificado todavía no es válido, algo que no se si está permitido o si es o no lógico.

¿Por qué oscuro motivo se querría tener un certificado que a día de hoy no es válido y hacerlo público? ¿Porque tienes un sistema como el de los seguros médicos -con periodo de carencia-? ¿Acaso es un mensaje de "todavía no hemos inaugurado, vuelva de aquí a unos meses"? ¿Para ahorrarte unos leuros?

¿Y donde veo el inconveniente? pues que -aunque no lo he probado todavía-, si en mi navegador tengo certificados caducados, o código firmado con dichos certificados, y mediante un troyano logro retrasar la fecha del sistema, vuelvo a validarlos y por ende, a permitir comunicación https válida a efectos del navegante.

Tal vez la validación del certificado se debería de realizar, al realizar operaciones on-line, contra algún servidor ntp que de una fecha "certificada", pero eso no quita el otro tipo de inconvenientes.

Entiendo que los Validity Period y Validity days de los certificados de los keystores de java también quedan sin su función cuando se modifica  la fecha del sistema, con lo que un código java que retrase la fecha permitiría utilizar un certificado metido en el keystore ya caducado, por ejemplo en un servidor.

Por lo que he leído la revocación de un certificado es de carácter inmediato y no está supeditada a una fecha de activación, porque si no fuera así la cosa sería más grave.

Y la última reflexión tonta de la mañana, entiendo que el problema se da en cualquier navegador, pero no lo he probado en el MS-IExplorer que sólo con abrirlo me da grima.

 

El error en el certificado también pasa con el plugin de Delicious para Firefox, que se loginea por https, no se si desde el código XUL de un plugin se puede cambiar la fecha que toma el navegador, lagarto, lagarto..

Posted by Feliciano Borrego in Ti at 20090625 Comentarios[8]

Comentarios:

¿Y el problema exactamente es? Es decir, funciona correctamente y tiene toda su lógica, no veo el problema.

El certificado de Google es valido a día de hoy, el problema está en tu ordenador y no en sus sistemas. Sí, sería un problema si pudieras acceder a un certificado antiguo en sus sistemas y te funcionara retrasando un año la fecha de tu sistema, pero no es el caso. Y aunque un programa pudiera retrasar la fecha de tu ordenador... ¿de que le iba a servir? ¿Para conseguir no conectarse?

Ah, y las listas de revocación de certificados tienen fecha, no se invalidan todas las operaciones hasta la fecha, si no menuda gracia.

Enviado por GreenEyed en junio 25, 2009 a las 11:30 AM CEST #

Creo recordar (y no tengo buena memoria :-D ), que la validación es en ambos extremos, en tu caso es TU FIREFOX en que no se fía de Gmail porque aún no valen sus credenciales, pero si intentas hacer uso de un certificado tuyo para autenticarte contra un servidor, será el SERVIDOR quien valide tu certificado con su hora (y aquí lo normal es que el admin lo tenga sincronizado por NTP).

De todas formas, me parece interesante tu comentario acerca de que si algún MALO obtiene la clave privada de un certificado legítimo (pongamos bancario), aunque le costara 2 años y 400 PS3 trabajando día y noche :-D , siempre podría infectar a un usuario, cambiarle le fecha del sistema y colarle un certificado caducado (y adulterado), así ese phising sería más difícil de evitar.

Sed Buenos :-D !

Enviado por DaniP en junio 25, 2009 a las 12:34 PM CEST #

GreenEyed, por supuesto que el problema está en el PC, y no en Google. El escenario mas aproximado sería el que DaniP expone en su segundo párrafo.

Y además queda pendiente el tema de los jars/aplets firmados con un certificado caducado/¿revocado? que con un simple cambio de fecha, volverían a ser válidos. Así como los certificados de los keystore-s utilizados en la seguridad de la JVM.

No pretendo desmontar todo el montaje de securidad establecido, únicamente planteaba los problemas derivados de manipular la fecha del sistema, que se podrían disminuir si al descargar de un servidor un objeto como un certificado, un aplet o un flash, la fecha de referencia para dicho objeto la diera también el propio servidor, y no el PC.

Enviado por feli en junio 26, 2009 a las 12:40 AM CEST #

Si alguien es capaz de descifrar un certificado, suplantar el DNS en tu ordenador para que apuntes al suyo y retrasarte la fecha del sistema... ¿tu crees que el problema es que los certificados caducan? ¿Realmente crees que añadir una fecha de referencia seria un obstaculo para alguien capaz de hacer todo lo anterior? Igual que te cambia tu fecha del sistema te cambia la fecha de referencia y listo.
En vez de hacer todo eso le sería más fácil cambiarte los certificados raiz de tu navegador y poner los suyos y ya no tiene que cambiar fechas y te puede colar cualquier applet, no solo uno caducado.

Enviado por GreenEyed en junio 26, 2009 a las 08:31 AM CEST #

Si tu ordenador da por buenos unos applets/jars cuyo certificado está caducado, el problema es TUYO, no del sistema de seguridad, que te da las herramientas suficientes para comprobarlo. Como se supone que te los descargas por la red, se supone que puedes comprobar la hora real y entonces es responsabilidad tuya hacer la comprobación.

Decir que enviando una fecha de referencia disminuirían los problemas no tiene sentido. Ya existe esa "fecha de referencia" y es la fecha del sistema, coordinada con NTP. Si no puedes obtener esa fecha, no hay que buscar mas. Si tu sistema está comprometido, no te puedes fiar de nada así que hacer elucubraciones a partir de ahí es, en mi opninión, perder el tiempo.

Enviado por GreenEyed en junio 26, 2009 a las 08:31 AM CEST #

Bueno, quizás mis limitados conocimientos de estos temas me han llevado a intuir que esto constituye una "Time-of-check, Time-of-use (TOCTOU) race condition".

Lamentablemente ahora no dispongo de tiempo para buscar un buen ejemplo y poder afirmar rotundamente que así sea.

Así que daré, de momento, por buenas tus explicaciones de que con un simple retraso en la fecha del sistema no es posible crear un 'exploit', usando un certificado ya caducado, para ganar acceso a un recurso.

Buen fin de semana GreenEyed, y también para cualquier otro lector.

Enviado por feli en junio 26, 2009 a las 08:14 PM CEST #

Buen fin de semana a ti también, y mis disculpas si ha sonado algo brusco (releyendolo, podría ser). Sólo queria decir que la seguridad es una cuestión de niveles y si tu sistema esta tán comprometido como para que te puedan hacer según que... entonces ahí es mejor parar de elucubrar.

Es como preocuparse sobre si usar el extintor manchará las paredes de la casa. Si la casa esta ardiendo lo de menos serán las paredes, así que a partir de ahí...

En este caso, si alguien puede descifrar el certificado y manipular las fechas de tu sistema e impedir que las compruebes fuera... entonces ya dale las llaves de tu casa, hombre :).
De todas formas, las "acciones criptográficas serias" van acompañadas de un sello de timestamp y si son mas serias, de una lista de revocacion con fecha del timestamp. Es decir, no es que el problema no se pueda dar, la cuestion es a quien se lo pueden hacer y que sacarian a cambio.

Enviado por GreenEyed en junio 27, 2009 a las 10:33 AM CEST #

Si alguien es capaz de descifrar un certificado, suplantar el DNS en tu ordenador para que apuntes al suyo y retrasarte la fecha del sistema... ¿tu crees que el problema es que los certificados caducan? ¿Realmente crees que añadir una fecha de referencia seria un obstaculo para alguien capaz de hacer todo lo anterior? Igual que te cambia tu fecha del sistema te cambia la fecha de referencia y listo.
En vez de hacer todo eso le sería más fácil cambiarte los certificados raiz de tu navegador y poner los suyos y ya no tiene que cambiar fechas y te puede colar cualquier applet, no solo uno caducado.

Si tu ordenador da por buenos unos applets/jars cuyo certificado está caducado, el problema es TUYO, no del sistema de seguridad, que te da las herramientas suficientes para comprobarlo. Como se supone que te los descargas por la red, se supone que puedes comprobar la hora real y entonces es responsabilidad tuya hacer la comprobación.

Decir que enviando una fecha de referencia disminuirían los problemas no tiene sentido. Ya existe esa "fecha de referencia" y es la fecha del sistema, coordinada con NTP. Si no puedes obtener esa fecha, no hay que buscar mas. Si tu sistema está comprometido, no te puedes fiar de nada así que hacer elucubraciones a partir de ahí es, en mi opninión, perder el tiempo.

Enviado por GreenEyed en julio 03, 2009 a las 06:54 PM CEST #

Enviar un comentario:
Los comentarios han sido deshabilitados.