En Noviembre de 2009 una noticia dio la vuelta al mundo. Era la informaicón relativa al fallo publicado por Marsh Ray y Steve Dispensa, de PhoneFactor, sobre la forma en que se gestionaba la renegociación en el protocolo TLS. La vulnerabilidad se conoce como TLS Renegotiation y ha sido presentada en muchas conferencias alrededor del mundo. Yo tuve la suerte de estar con este par de pájaros en la Troopers 2010, realizada en Marzo del 2010 en Alemania, donde grabaron la sesión y puede verse toda la información y la historia del fallo en ella:
Con Marsh comenzó todo el debate sobre ¿quién es responsable?, en el que hablamos sobre la cantidad de tiempo que debe darse a un fabricante para arrelgar el fallo... Y es que la suya se las traía.
El funcionamiento de un ataque MITM, usando esta vulnerabilidad, es bastante sencillo. Supongamos una aplicación web con un canal Http-s seguro, autenticado y correcto con la vulnerabilidad del TLS-Renegotiation. Un atacante que realice un ataque MITM no podrá ver ningún dato de la conexión (si no quiere levantar niguna alerta de seguridad) pero podría forzar una renegociación TLS modificada y, a partir de ese momento, inyectar comnados a la aplicación get. Si esta tiene comandos como https://server.com/app?cmd=create_user&pwd=mierda se podría controlar la aplicación. Este ejemplo de ataque lo que realizó Ben Feinstein en la últim Blackhat con un Firewall CISCO en la conferencia "The emperor has no clothes".
La vulnerabilidad fue catalogada con el CVE-2009-355 y todos los fabricantes afectados debían solucionarlo. El caso es que este fallo, que no sólo afectó a las plataformas Microsot, dio lugar a la creación de un grupo en el IETF para el diseño y proposición de un nuevo estandar que solventara esta debilidad de una forma coordinada.
Así, en Febrero de 2010 se publicó el RFC 5746, títulado "Transport Layer Security (TLS) Renegotiation Indication Extension" que propone una extensión al modelo de regonociación para hacerlo de forma segura.
Esta semana Microsoft publicó una actualización de seguridad de SChannel para Microsoft Windows [MS10-49] que arregla esta vulnerabilidad, además de solución una vulnerabilidad crítica catalogada con el CVE-2010-2566 que afecta al Schanel de la que no se había hecho full-disclosure del exploit.
La historia está en que no basta sólo con actualizar el software (de servidor y cliente) para arreglar el fallo, sino que hay que hacer que los certificados lo soporten. Esto no suele ser trivial y así, a día de hoy, basta con usar cualquier herramienta de evaluación de certificados, como la de Qualys, y comprobar que esto aún va despacio.
Yo he probado con el certificado de Microsoft.com y, como se puede ver, aun soporta el mecanismo inseguro de renegociación TLS. Más trabajo para los informáticos si queréis mantener la plataforma lo más segura posible.
Por último, no quería cerrar este artículo sin hacer notar dos cosas:
1) Marsh y Steve, que a parte de ser dos tipos superdivertidos, y vecinos de Superman, oyeron muchas críticas a su trabajo porque se pensaba que no podía ser utilizado para atacar sistemas, pero al final... ahí están las cosas. Microsoft ha reconocido su trabajo en los créditos del advisory.
2) Gracias al trabajo de investigación y divulgación de muchos investigadores independientes como ellos se consigue ir mejorando las tecnologías, así que nada, poneos todos a romper cosas porque si se pueden romper es que son defectuosas.
Saludos Malignos!
Con Marsh comenzó todo el debate sobre ¿quién es responsable?, en el que hablamos sobre la cantidad de tiempo que debe darse a un fabricante para arrelgar el fallo... Y es que la suya se las traía.
El funcionamiento de un ataque MITM, usando esta vulnerabilidad, es bastante sencillo. Supongamos una aplicación web con un canal Http-s seguro, autenticado y correcto con la vulnerabilidad del TLS-Renegotiation. Un atacante que realice un ataque MITM no podrá ver ningún dato de la conexión (si no quiere levantar niguna alerta de seguridad) pero podría forzar una renegociación TLS modificada y, a partir de ese momento, inyectar comnados a la aplicación get. Si esta tiene comandos como https://server.com/app?cmd=create_user&pwd=mierda se podría controlar la aplicación. Este ejemplo de ataque lo que realizó Ben Feinstein en la últim Blackhat con un Firewall CISCO en la conferencia "The emperor has no clothes".
La vulnerabilidad fue catalogada con el CVE-2009-355 y todos los fabricantes afectados debían solucionarlo. El caso es que este fallo, que no sólo afectó a las plataformas Microsot, dio lugar a la creación de un grupo en el IETF para el diseño y proposición de un nuevo estandar que solventara esta debilidad de una forma coordinada.
Así, en Febrero de 2010 se publicó el RFC 5746, títulado "Transport Layer Security (TLS) Renegotiation Indication Extension" que propone una extensión al modelo de regonociación para hacerlo de forma segura.
Esta semana Microsoft publicó una actualización de seguridad de SChannel para Microsoft Windows [MS10-49] que arregla esta vulnerabilidad, además de solución una vulnerabilidad crítica catalogada con el CVE-2010-2566 que afecta al Schanel de la que no se había hecho full-disclosure del exploit.
La historia está en que no basta sólo con actualizar el software (de servidor y cliente) para arreglar el fallo, sino que hay que hacer que los certificados lo soporten. Esto no suele ser trivial y así, a día de hoy, basta con usar cualquier herramienta de evaluación de certificados, como la de Qualys, y comprobar que esto aún va despacio.
Yo he probado con el certificado de Microsoft.com y, como se puede ver, aun soporta el mecanismo inseguro de renegociación TLS. Más trabajo para los informáticos si queréis mantener la plataforma lo más segura posible.
Por último, no quería cerrar este artículo sin hacer notar dos cosas:
1) Marsh y Steve, que a parte de ser dos tipos superdivertidos, y vecinos de Superman, oyeron muchas críticas a su trabajo porque se pensaba que no podía ser utilizado para atacar sistemas, pero al final... ahí están las cosas. Microsoft ha reconocido su trabajo en los créditos del advisory.
2) Gracias al trabajo de investigación y divulgación de muchos investigadores independientes como ellos se consigue ir mejorando las tecnologías, así que nada, poneos todos a romper cosas porque si se pueden romper es que son defectuosas.
Saludos Malignos!
a qué direcccion se te puede enviar un mail? te paso el mio aurora.ml@gmail.com
ResponderEliminarTengo que explicarle algo.
Que wapo el post:)
ResponderEliminar"oyeron muchas críticas a su trabajo porque se pensaba que no podía ser utilizado para atacar sistemas, pero al final... ahí están las cosas"
Ya sea en plan security p0rn star o en plan pequeño, en la empresa en la que uno trabaje, esto se da muy a menudo :( es muy frustrante.
Y sobre todo, me encanta esta frase del final:
"poneos todos a romper cosas porque si se pueden romper es que son defectuosas."
Eppur si muove
Un saludo.
Manolo.