Si alguna vez has visto algún episodio o película de Star Trek, te habrás fijado en algo muy característico, icónico, de la franquicia desde sus inicios: El uso de un teletransportador para la mayoría de los viajes entre la
Enterprise y los muchos de sus inhóspitos destinos. Ahora, en nuestro tiempo, ese recurso no sería ni trending topic, pero en los años sesenta, chico, en los años sesenta ver a un vulcaniano con sus orejas puntiagudas emerger de la nada en medio de un festival de luces estroboscópicas era una auténtica revolución. Allí no había ni mota de polvo y de pronto, zas, aparecía un tipo con todos sus átomos en su sitio, tricorder incluido, un paseito cuántico sin importancia; con vistas al universo.
Curiosamente, ese "truco" de escena les sirvió para recortar presupuesto, puesto que de ese modo se ahorraban las secuencias de despegue-aterrizaje de una hipotética lanzadera o método similar. Evidentemente, hacía falta hipotecar nuestra imaginación para no romper la
suspensión de la incredulidad, o ensanchar nuestra cintura científica para pasar por alto el quebrantamiento de varias leyes de la física. Pero oiga, ¿no resulta atrevido pensar en un sistema que descomponga la materia, la haga viajar a la velocidad de la luz y la vuelva a recomponer sin riesgo alguno en el otro extremo?
Pues bien, eso es lo que hace la serialización de objetos. Descomponer un objeto en un extremo, transmitir esos datos y recomponerlos en el destino. La magia de la computación distribuida. Solo que de momento tenemos un problemilla: no es tan segura como el teletransportador del Enterprise y en vez de recomponer un objeto seguro y fiable se nos puede colar una bomba de resina de Trilithium con pinta de inocente objeto que transporta de forma diligente las preferencias del usuario.
Eso es lo que ha pasado últimamente con una
vulnerabilidad en el framework
Struts de la fundación
Apache. Se trata de un conocido proyecto muy usado en aplicaciones web para J2EE. O de otra forma, un framework que usa la mayoría de grandes empresas en sus desarrollos bajo la plataforma y lenguaje Java. Aunque Struts tiene ya sus años (fue pionero en este ámbito), y no tiene el tirón que tuvo en su día, todavía se sigue usando en muchas instalaciones, algunas de ellas gestionando recursos bastante valiosos para estas empresas.
Tal es el caso que nos ocupa, el de
Equifax, una empresa de valoración de crédito que ha sido atacada supuestamente usando la mencionada vulnerabilidad. Hasta 143 millones de registros podrían haber sido extraídos de sus archivos y bases de datos por un grupo atacante. En un ambiente en el que la gestión de este incidente ha sido muy discutida, la fundación Apache ha emitido un
comunicado explicando algo que se puede resumir en una sola frase: "
si usas software y ha salido un parche de seguridad, PARCHEA, YA!". Evidente, pero que por desgracia hay que repetir continuamente.
La vulnerabilidad ha sido
descubierta por Man Yue Mo, de la empresa
lgtm. El fallo estaba en la clase
ContentTypeHandler, un interfaz muy básica pero potente que permite serializar y deserializar objetos desde el objeto raíz de la API de Java, el objeto Object. Esto permite a cualquier clase que herede una implementación de dicha interfaz poseer la funcionalidad para usar serialización (en palabras trekkies, de usar el teletransportador). Para que nos entendamos, un cliente contacta con un servidor y le dice "te voy a enviar un objeto serializado en formato XML", el servidor lo recibe, interpreta el XML del cliente a través de una instancia del objeto
XStreamHandler...y como este hereda de
ContentTypeHandler...no se detiene a comprobar si el XML donde yace el objeto inerte contiene o no un método peligroso.
Como curiosidad, se ha dicho que el bug tiene o puede tener 8 años de antigüedad, pero esto es relativo y no debería ocasionar sorpresa. Ahora mismo hay cientos de bugs peligrosos que están ahí, esperando a ser descubiertos, el problema no es no verlos, sino quien los ve y que hace con él. En una imagen:
Si nos fijamos en la línea de tiempo del investigador, las fechas coinciden:
Vemos los
cambios realizados a nivel de API, coincidiendo con el estilo, filosofía y formas Java: añadiendo una capa (más) de abstracción:
Y como ahora, con la nueva llamada a la API se comprueban
ciertos permisos que deben figurar para serializar objetos con una mejora en la seguridad (vamos a omitir decir, de manera completamente segura):
Huelga decir que a las pocas horas de hacerse pública la vulnerabilidad comenzaron a salir exploits y pruebas de concepto, incluyendo, como no, un
módulo para metasploit. Si se quiere tener una visión técnica más directa sobre cómo se arquitecta un exploit para esta vulnerabilidad podemos leer el código de
este repositorio de GitHub, donde se ha publicado un exploit
stand-alone para explotar el fallo por Mazin Ahmed. Ojo, no recomendamos que ejecutes este o cualquier exploit.
Por ejemplo, vemos cómo en dicho exploit se nos pide el comando que queremos ejecutar en el sistema remoto. Este irá codificado en XML, con la etiqueta que describe su tipo, "string":
A su vez, más adelante, el comando va incrustado en una plantilla que sirve para describir completamente el objeto a serializar (siempre será el mismo, solo cambia el comando):
Hay algo más, ya por curiosidad, no lo comenta pero como post-explotación, tras asegurarse de que es explotable utiliza
partes de
ysoserial, un framework que ha crecido recopilando vulnerabilidades de este tipo, serialización, en el ámbito de la plataforma Java, por ejemplo:
Es una codificación base64, luego:
Interesantísima forma de explotación, aunque viene a rubricar de nuevo uno de los principios universales de la seguridad informática: jamás dar por bueno lo que llega del usuario. Ni aunque sea un vulcaniano de orejas puntiagudas y buenas intenciones.
David García
dgarcia@hispasec.com
Más información
Remote code execution vulnerability in Apache Struts (CVE-2017-9805)
