Por Alejandro Hevia, director CLCERT, profesor del Depto. de Ciencias de la Computación, FCFM, Universidad de Chile.

Es probable que cualquier que haya usado un computador haya escuchado hablar de “actualizaciones de seguridad” o “parches”. Para muchos, un concepto extraño: ¡cómo puede un computador recién comprado ya necesitar “parches”! En la columna de hoy, quiero discutir el intrincado proceso que da pie a dichos parches, concretamente el controvertido mundo detrás del proceso de “mejorar la seguridad del software”.
Para funcionar correctamente, un programa no sólo tiene que hacer lo que dice (calcular correctamente las fórmulas de una planilla o permitir escribir un documento) sino que no puede fallar o “caerse”. Si no opera correctamente, decimos que tiene un error. Una vulnerabilidad es un tipo especial de error que permite a alguien externo (un hacker malicioso) cambiar la ejecución normal del programa permitiéndole ver mi información. Por ejemplo, supongamos que para llevar nuestras finanzas compramos un software contable, el cual entre otras cosas se conecta a Internet para saber el valor del dólar y la UF. Un error es que calcule mal el interés de mi cuenta de ahorro; una vulnerabilidad sería un error en la parte del programa que se conecta a Internet, tal que le permite a un hacker malicioso “confundir” a mi programa inyectándole información inesperada o maliciosa y posiblemente tomar control completo del software. De hecho, podría ocurrir sin darme cuenta. Y luego de eso, el programa parece calcular mis finanzas, cuando por detrás realmente hace lo que el hacker malicioso le pide, incluyendo recolectar contraseñas (de correo, de acceso, bancarias, etc.), números de cuentas y tarjetas, y cualquier otra información personal o comercial que sea usada en mi computador, inclusive mientras uso otros programas distintos. Claramente este tipo de errores son extremadamente serios, pues son literalmente la puerta de entrada para programas maliciosos (o “malware”) que se instalan en el computador, robando información y dejándome a merced de un tercero quien pudiera usarlo para guardar información ilícita (por ej. pornografía infantil) o como trampolín para atacar a otros computadores.
Hacer software sin vulnerabilidades históricamente ha sido muy difícil. Tanto grandes empresas como Microsoft u Oracle, que han invertido cientos de millones de dólares en el tema, como proyectos comunitarios masivos (GNU o “Linux”) con equipos de desarrolladores especializados en seguridad, aún sufren día a día con nuevas vulnerabilidades.
Pero, ¿cómo hace una empresa para solucionar las vulnerabilidades en su software? Primero debe encontrarlas. Por supuesto, hacen lo mejor posible para localizarlas y solucionarlas antes de vendernos el software, o eso dicen (es al menos sospechoso que el modelo actual de negocios se basa en vendernos “mejor” software del que nos vendieron antes pero sin garantizar ausencia de errores!). Sin embargo, el track record de la industria no es de lo mejor en este sentido. La experiencia dice que prácticamente todo software (de complejidad no trivial) tendrá vulnerabilidades al momento de ser vendido o “released”. Lo interesante se produce luego: aunque las empresas siguen trabajando en mejorar su software, las vulnerabilidades son ahora usualmente encontradas por uno de dos grupos: los mismos usuarios, en la forma de profesionales de seguridad, investigadores, o programadores, o por hackers maliciosos y criminales informáticos.

La diferencia obvia es que el primer grupo tiende a ser honesto y comunicar sus resultados a los fabricantes de software; el segundo, no tanto, y solo busca “explotar” las vulnerabilidades para su beneficio económico.
A primera vista, las consecuencias son obvias: si la vulnerabilidad es encontrada por un criminal, es explotada para crímenes y ataques, ergo pierden tanto el usuario del software como el fabricante (al menos, su reputación); si es encontrada por investigadores honestos, es comunicada a la empresa, quien la arregla y gana el usuario y la empresa. ¿O no? No tanto. Esto se debe a que la relación entre fabricantes de software y profesionales de seguridad ha sido históricamente compleja, sembrada de desconfianzas mutuas.
Por una parte, los fabricantes de software frecuentemente han reaccionado ignorando repetidamente los reportes de vulnerabilidades entregados por profesionales de seguridad, o bien, amenazando con demandas, incluso demandando a dichos profesionales si éstas eran reveladas, una versión moderna de “dispararle al mensajero” si este trae la mala noticia que su software es defectuoso. Mal que mal, asumir y arreglar las vulnerabilidades tiene costos significativos directos (resolver el error, encontrar el parche) e indirectos (reputación del fabricante). Sin embargo, no solucionar la vulnerabilidad es posiblemente aún peor pues si ésta ha sido encontrada por expertos honestos, es probable que hackers maliciosos la encuentren y exploten sin comunicarle a nadie, exponiendo a ataques a los usuarios honestos. Por otra parte, ante la indiferencia de los fabricantes muchos profesionales de seguridad guiados más bien por su frustración (o ego) han reaccionado hacia el otro extremo: revelando públicamente detalles de las vulnerabilidades e incluso “exploits” (programas ejecutables que usan la vulnerabilidad) argumentando que tal medida es necesaria para “forzar una respuesta” del fabricante. Es fácil imaginar lo difícil que es dialogar en estas condiciones: “He aquí detalles de la vulnerabilidad” dice el profesional de la seguridad. “No te creo, la vulnerabilidad que describes no existe” dice el fabricante. “¿Cómo que no? He aquí un ejemplo en la forma de exploit”. “¿Un exploit? ¡Esto dará pie a un ataque! tu conducta es ilegal te voy a demandar”. Lamentablemente, el resultado neto es que nadie gana, sólo pierden los usuarios del software.
Afortunadamente, la experiencia ha demostrado que es posible comunicar vulnerabilidades a los fabricantes de software en forma razonable. De hecho, esto ha convergido en, al menos, dos posibles procesos distintos. El primero, denominado full-disclosure, es una variante del proceso más liberal: “revelar los detalles públicamente – aunque no el exploit - y luego conversar con el fabricante”. Esto, en general, es visto como demasiado radical, pues pone al fabricante responsable en una posición muy difícil, mala publicidad y la tarea de resolver la vulnerabilidad contra el tiempo mientras sus usuarios arriesgan ser atacados. Una variante más conciliatoria es el “responsible disclosure” donde la vulnerabilidad es reportada directamente al fabricante del software pero se incluye como testigo a un tercero neutral confiable (un centro de seguridad establecido, de buena reputación) quien intercede para que ambas partes cumplan sus compromisos. En particular, el tercero neutral verifica que el profesional de seguridad no sólo entregue detalles de la vulnerabilidad exclusivamente al fabricante, sino que espere al menos un par de meses antes de hacerlos públicos; además, verifica que durante ese tiempo el fabricante efectivamente trabaje en resolver la vulnerabilidad en conjunto con quien reporta. Para muchos, responsible-disclosure es un buen compromiso para mejorar el software… o al menos para parchar el software ya existente.
El delicado balance logrado entre fabricantes de software y profesionales de seguridad nos muestra que obtener seguridad del software requiere procedimientos no necesariamente intuitivos. Quizás el más importante de ellos es evitar la tentación de dispararle al mensajero; acallar a quien responsablemente comunica una vulnerabilidad no sólo es a la larga inútil sino fundamentalmente contrario al proceso de “critica constructiva” que conduce hacia un software seguro.