Heartbleed: el aftermath
No
trataré de explicar a fondo qué es Heartbleed
y cómo funciona su explotación pues creo que ya se ha hablado lo suficiente
sobre ello, pero para quien aún no sepa lo que es, la mejor explicación que he
encontrado al respecto es la imagen de xkcd[1].
Mi
objetivo aquí no es explicar Heartbleed
sino analizar desde una perspectiva de seguridad las razones por las que existe
un bug tan grave y sus posibles consecuencias.
Primero,
hay que considerar que las implementaciones de OpenSSL 1.0.1 a 1.0.1f son vulnerables a Heartbleed[2]. Para establecer mi punto,
mencionaré tres premisas:
- OpenSSL es un software libre desarrollado bajo la premisa de que una comunidad abierta de programadores están dispuestos a generar piezas de código sin una retribución económica para ellos.
- Estas piezas de código después podrán ser usadas libremente por el público, siempre y cuando se respete la licencia de uso, que generalmente es GPL[3].
- Para asegurar la seguridad y confiabilidad de estas piezas de software funcional se confía en la “revisión entre pares”, es decir, al ser un sistema con el código fuente abierto cualquiera puede revisarlo y reportar alguna anomalía.
Se
supone que el código de OpenSSL fue
revisado por miles de personas en el mundo, pero surge entonces un problema
llamado complejidad: dado que OpenSSL
es un sistema de misión crítica con un grado de complejidad muy alto que
proporciona características de seguridad “avanzadas” a los sistemas, el número
de gente que puede entender este código es muy reducido, así que aunque el
código esté abierto no cualquiera lo entiende. También hay que considerar que
de las pocas personas que entienden el código, solo una pequeña porción tiene suficiente
tiempo libre y está dispuesta a revisarlo sin existir una remuneración de por
medio.
Entonces,
¿en quién recae la responsabilidad de revisar el código?
Si se
observa la lista de servidores populares que fueron afectados se pueden ver nombres bastante grandes, que al parecer utilizaron
el código sin dedicar muchos recursos a revisar lo que estaban implementando.
El
código abierto o software libre no funciona así, no se trata de “software
gratis” sino de una forma distinta de invertir en software y considero que el
efectuar una revisión adecuada es responsabilidad de todos los que implementan
un elemento como este. Y el mismo criterio es aplicable para todo el software
libre que anda suelto por el mundo: “Si ves las barbas de tu vecino cortar, pon
las tuyas a remojar”.
¿Heartbleed pudo haberse evitado? la
respuesta es simple: sí.
Pero,
¿por qué no se evitó? La respuesta no es nada simple, lo que nos lleva al
asunto de la seguridad.
Si las
compañías hacen seguridad a cada uno de sus elementos pero no al sistema
completo, eso genera huecos que eventualmente serán descubiertos y explotados
como en el caso Heartbleed. Puede
parecer “clavado” de parte mía mencionarlo, pero en los estándares para
sistemas de gestión de seguridad de la información existe un concepto que se
llama validación de datos de entrada, de procesamiento interno y de salida, que
debería ser tomado más en serio por parte de las empresas pues básicamente es el
antídoto para asuntos como la inyección SQL y XSS y hasta para el Heartbleed mismo. ¿Por qué? Pues porque
si se validan los datos que muestra cualquier salida y se comparan con
expresiones regulares que busquen la posibilidad de exponer números de cuenta,
tarjetas de crédito, usuarios o contraseñas, se podrían evitar muchas de estas
situaciones; lo mismo aplica para el procesamiento interno, ya que se podría
validar que un programa no pueda leer partes de la memoria que no escribió, que
es lo que hace Heartbleed para leer
partes de la memoria a través del Heartbeat.
Y para el caso: ¿qué tiene que estar haciendo Heartbeat, que sirve para
saber si un servidor está vivo, leyendo la memoria en donde se almacenan
certificados, usuarios, contraseñas y demás información sensible?
Pasemos
ahora al tema de las consecuencias. Ya sabemos que Heartbleed ha costado mucho dinero por la emisión de nuevos
certificados, la revisión de código, los daños a la reputación de empresas, las
demandas presentadas, más lo que se agregue, pero también están las
consecuencias para los usuarios.
Una
de estas consecuencias es la actualización de passwords. Me llegó una notificación de mi manejador de passwords diciendo que debía cambiar 97 de
ellos en distintos sitios, lo cual suena a una pesadilla y lo es. Hay quien
considera que la posibilidad real de que se hayan filtrado grandes volúmenes de
passwords es muy baja pero yo no
necesito que se hayan filtrado grandes volúmenes, basta con alguno mío, así que
opté por cambiarlos todos, con todo lo que este cambio implica. De por sí los
cambio con cierta regularidad, pero ahora fueron todos al mismo tiempo y aún sigo
medio enredado, pero ahí vamos.
Otra
consecuencia de impacto fuerte ha sido la reemisión de certificados, que en
este caso fue un impacto positivo para los emisores porque están haciendo el
negocio de su vida vendiendo nuevas versiones de certificados que estaban
vigentes pero que podrían haber sido comprometidos con Heartbleed. Aunque su negocio es vender certificados, y es honesto,
¿y lo que le cuesta al usuario, apá?
La
consecuencia final, y que a mi parecer debe tener el mayor impacto, es una mayor
conciencia sobre el peso que tiene una afectación en la reputación de todos los
servicios y compañías que se vieron comprometidos.
Los usuarios deben exigir que las empresas tomen muy en serio el negocio que hacen a las expensas de quienes les compran –que no es un negocio pequeño, por cierto– y que estas empresas revisen el código que implementan, que no confíen ciegamente en las “herramientas” de seguridad que alguien más hizo solo porque son comúnmente utilizadas o porque les salieron carísimas y entonces deben ser muy buenas; deben exigirles que pongan mucha más atención.
Los usuarios deben exigir que las empresas tomen muy en serio el negocio que hacen a las expensas de quienes les compran –que no es un negocio pequeño, por cierto– y que estas empresas revisen el código que implementan, que no confíen ciegamente en las “herramientas” de seguridad que alguien más hizo solo porque son comúnmente utilizadas o porque les salieron carísimas y entonces deben ser muy buenas; deben exigirles que pongan mucha más atención.
Igual
que en una democracia, la labor del votante no es solo votar sino dar
seguimiento al desempeño del gobernante. En el caso de los sistemas la labor
del usuario no es solamente hacer uso de ellos sino exigir a quien le presta el
servicio que cumpla con lo que le ofrece, además de establecer límites cuando sea
evidente que alguno está trasgrediendo las barreras de lo aceptable y está
haciendo o ha dejado de hacer algo que puede dañar su integridad.
Comentarios
Publicar un comentario