8 malas prácticas en el proceso de gestión de un 0day

En septiembre del año 2009 estábamos a punto de presentar en la Ekoparty de aquel año las técnicas de Connection String Parameter Pollution en la que íbamos a hacer demos con varios 0days que afectaban a las herramientas MyLittleBackup, MyLittleAdmin, Microsoft Web Data Administrator y ASP.NET Enterprise Manager. Cuatro herramientas utilizadas para la gestión de bases de datos MS SQL Server que tenían el mismo bug y permitían acceder remotamente de forma sencilla a los paneles de control de todos los clientes que los tuvieran expuestos en Internet con solo poner una cadena de caracteres y que os expliqué en detalle en el artículo Connection String Attacks.

Figura 1: Presentación de Connection String Paramenter Pollution en DEFCON 18

Desde entonces han pasado varios años pero aún hay muchos sitios vulnerables a estas técnicas. Repasando lo que ha sucedido desde entonces hay una serie de lecciones aprendidas de malas cosas realizadas que ayer quise explicar a mis alumnos en la Universidad y que me he decidido a publicaros por aquí.

1.- El reporte sin solicitud de un CVE

La primera de las malas lecciones aprendidas es que no todas las empresas de desarrollo de software se toman de igual forma la gestión de los bugs de seguridad. En aquel entonces a nosotros nos importaba más la técnica de explotación que estuvimos desarrollando en detalle en el paper, que en el 0day concreto, y dejamos que los fabricantes de software optaran por gestionarlo como ellos quisieran y al final cada gestión fue un desastre... para ellos y para sus clientes.

Figura 2: El advisory en el foro que se publicó

Desde la empresa que gestiona MyLittleAdmin y MyLittleBackup no se pidió un CVE para su bug y lo único que hicieron fue publicar un mensaje en un foro en el que decían que el parche era solo para corregir una "minor security vulnerability", como se puede ver en la Figura 2. Por supuesto, ni gracias, ni mención, ni nada por el estilo, ya que no les sentó nada bien que descubriéramos este fallo.

2.- Minimizar la importancia del bug

Cuando vi el advisory me puse en contacto con ellos y les expliqué que si mirábamos la criticidad del bug usando CVSS/CVSS2 sabiendo que iba a haber un exploit público, remoto, sin necesidad de una interacción por el usuario y permitiendo acceder al 100% de los datos, probablemente nos saliera un número muy alto. Un poco forzado por la evidencia, cambió el mensaje en el foro de su sitio que hacía las veces de Security Advisory y lo dejó como "Security Vulnerability", pero simplemente modificando el texto del mensaje.

Figura 3: El advisory modificado a "security vulnerability"

En aquel entonces le dije que el tratamiento que estaba haciendo no creía que fuera bueno para sus clientes, pues después de que yo contara esto en la Ekoparty, BlackHat y DefCON, todos aquellos usuarios de su software que no lo hubieran actualizado quedarían muy vulnerables. A día de hoy, aún quedan muchos sitios publicados en Internet con versiones de MyLittleAdmin y MyLittleBackup vulnerables a esta técnica que permiten a cualquiera acceder desde Internet a sus bases de datos.

3.- No realizar una detección de clientes vulnerables

Uno de los temas que ya he contado alguna vez es que si cualquiera haciendo un poco de hacking con buscadores es capaz de encontrar los sitios vulnerables, ¿cuál es el motivo por el que no lo hacen los propios fabricantes? Esto ya lo he comentado con varios de ellos, y alguno ha comenzado a hacer algún escaneo pro-activo en Internet para localizar versiones vulnerables de sus programas para avisar vía canales oficiales a sus clientes del problema. Por supuesto, en este caso ninguno de los fabricantes parece haber realizado el proceso de aviso a sus clientes y ayuda un poco más a que sigan quedando las instalaciones vulnerables en Internet.

4.- Preocuparse más de la imagen que del fallo de seguridad

Una de las cosas que más me llamó la atención es que nada más publicar el fallo de seguridad e ir yo a contar la presentación, desde MyLittleTools se hizo una campaña de marketing dando referencias de qué clientes usaban su software.

Figura 4: Lista de clientes publicada desde MyLittleToolsb

En aquel entonces pensé: "Genial, te digo que hay un 0day que se va a publicar en Internet y tú pones las víctimas expuestas". Fail.

5.- Olvidar la fase de retiro del software

Una de las cosas que se estudian en las clases de Ingeniería del Software es que hay que pensar en la fase de retirada del software, es decir, cuándo y cómo una aplicación debe ser retirada definitivamente. En el caso de Microsoft Web Data Administrator el software se liberó vía proyecto Open Source en CodePlex, pero se siguió distribuyendo la versión antigua desde los servidores de Internet, lo que hacía que aunque el programa estaba abandonado siguiera habiendo nuevas instalaciones del software vulnerable cada día.

Figura 5: en el año 2009 se retiró Microsoft Web Data Administrator

La versión de CodePlex estaba parchada, pero la que distribuía directamente Microsoft no lo estaba, así que cuando contacté con el Microsoft Security Response Center estuvieron de acuerdo en retirar el software de la descarga.

6.- Fallos en el control de reintroducción de bugs

En este caso, a pesar de Microsoft retiró el software vulnerable de Internet, en un proceso de migración de servidores volvió a ponerse disponible en Internet al cabo del tiempo, lo que yo detecté de casualidad y tuve que volver a reportar.

Figura 6: En el año 2011 estaba otra vez disponible el software vulnerable

Al final, durante otro largo tiempo se estuvieron creando nuevas instalaciones de software vulnerable servidas otra vez desde la propia Microsoft.

7.- Uso de software abandonado

El último de los programas vulnerables que se vieron afectados con estos 0days era ASP.NET Entrerprise Manager, un programa que cuando ya descubrimos el bug estaba abandonado totalmente por sus creadores, así que no había ninguna posibilidad de poder obtener un parche. De hecho, en la presentación del fallo contábamos un ejemplo de cómo debería solucionar manualmente, algo que por supuesto dudamos que alguien hiciera.

8.- No anticiparse al bug

En la presentación de Connection String Parameter Pollution, además de hacer las demos con las cuatro versiones afectadas por los 0days, dejamos claro que aunque en Oracle y MySQL era más difícil debido a que no era común la autenticación integrada en la base de datos, el resto de exploits para escanear la DMZ, escanear los puertos o cambiar la base de datos a la que se conecta la aplicación les afectaría. Hace no demasiado yo probé esto mismo con un panel web de gestión de bases de datos MySQL que se veía afectado.

Figura 7: Un panel de gestión de bases de datos MySQL afectado por un Connection String Attack

Hay que estar atento a todo lo que se publica que afecta a versiones de software similar para saber si tu aplicación puede verse o no afectada. Anticipación es una buena práctica de gestión de seguridad.

Conclusiones

Todos estos puntos han hecho que el matar un 0day tan fácil de explotar no se haya realizado y a día de hoy aún haya paneles de las cuatro versiones de software totalmente vulnerables expuestas en Internet, y para alguien ducho en el hacking con buscadores sea más que sencillo localizarlos. Gestionar correctamente la seguridad es fundamental, y si no se hace... todo será un desastre.

Saludos Malignos!