Comunidad

El caso Twitter, monitorización y encriptamiento

octubre 17, 2018

El caso Twitter, monitorización y encriptamiento

El post está disponible también en : Inglés

Evento sobrevenido: el caso Twitter, monitorización y encriptamiento

Un evento sobrevenido como el que le sucedió a Twitter el 3 mayo 2018 le puede suceder a cualquier empresa. ¿Por un proceso de monitorización? ¡Estudiemos el asunto!

Evento sobrevenido: una introducción al tema

Seguro que utilizais la popular red social Twitter®, por ejemplo para recibir los mensajes de alerta de Pandora FMS para vuestro sistema, a fin de conocer de manera oportuna los asuntos que requieren la intervención humana, que por ahora es siempre necesaria. Como todo evento sobrevenido, fue grande nuestra sorpresa el jueves 3 de mayo de 2018 cuando Twitter® solicitó de una manera urgente (mensaje directo en pantalla) que debíamos cambiar nuestra contraseña de acceso. Sí, el mensaje era válido, ya que estábamos navegando con protocolo seguro (TLS). Sin embargo, procedimos con precaución antes de realizar acción alguna.

Por este vuestro blog, muy útil y servicial, recordamos cómo tratar las crisis de las Tecnologías de la Información y en el consejo número dos de ese artículo claramente está escrito, desde hace tiempo, lo que Twitter® nos comunicó casi en el acto: había un problema y se estaba trabajando en su solución. Bien, sonreímos complacidos. Ellos y ellas cumplieron con uno de nuestros cinco consejos (modestia aparte, estimados lectores y lectoras. ¿Podemos obtener vuestra indulgencia en nuestro brote de vanidad?). Este artículo describe -y trataremos de analizar- el sobresalto para los 330 millones de usuarios que componemos el ecosistema social. ¡Vamos!

Antecedentes

No es primera vez que un glitch software nos afecta, ni será tampoco la última. Gracias a la monitorización, un incidente causado por falla en el suministro eléctrico puede llevarnos a descubrir desaciertos en la conducción y administración de los sistemas. Es cierto: el evento sobrevenido es intempestivo, pero, ¿se pudo prevenir o al menos minimizar? En este caso, Twitter® de nuevo cumple con nuestra tercera recomendación: ser transparentes. Esta es la captura de pantalla del mensaje que recibimos:

evento sobrevenido

Como podemos ver (si es necesario haced clic derecho con vuestro ratón para abrir la imagen en una pestaña o ventana aparte), explican de manera directa y sincera: “descubrimos un error que guardaba las contraseña no ocultas en un registro interno”. A continuación ofrecen un enlace donde uno puede ampliar la información, pero, ¿adivinen qué? ¡Claro, Twitter® cumple otra de nuestras recomendaciones! Para ser exactos, la cuarta premisa: una buena comunicación. De manera directa, indica la naturaleza del problema sin entrar en detalles demasiados técnicos, solamente el mínimo necesario. Tal vez se preguntarán, ¿dónde está el detalle técnico en el comunicado?

Encriptar, cifrar, trocear, ofuscar… ¿son sinónimos?

Una “contraseña no oculta” es una contraseña almacenada de manera natural, tal como estamos leyendo estas líneas. No necesitamos nada adicional para leerlas: a eso lo llamamos “texto plano”. Por supuesto que esto de ninguna forma ni manera conviene a nada ni nadie, y Twitter® no es la excepción. Pero esta empresa, y no dejamos de deshacernos en halagos, se luce de nuevo al ofrecer una disculpa de buena manera. En su blog de Twitter®, el mismo Director de Tecnología (Chief Technology Officer o CTO por sus siglas en inglés) literalmente da la cara y nos explica en mayor detalle el problema, de una manera clara y directa (podéis leer su entrada en el blog, traducida al castellano, en este enlace).

Parag Agrawal, CTO de Twitter®, ingeniero de software graduado en la Universidad de Stanford y con trabajo experimentado en grandes empresas como Yahoo!®, Microsoft® y los Laboratorios AT&T® (y con apenas ocho meses en el cargo), obtuvo su bautizo de fuego en este evento sobrevenido (y el blog de Twitter® también). Con la ayuda del blog de Twitter® –de allí la importancia para todas las empresas de mantener siempre un blog oficial– la empresa pudo ofrecer una buena disculpa cumpliendo con nuestra recomendación número uno (aunque la numeración que empleamos no indica necesariamente el orden en ser aplicadas).

Además, también obtuvimos un atisbo hacia dos componentes clave: la manera -y norma- sobre cómo la industria tecnológica guarda nuestras contraseñas de acceso y los componentes de programación involucrados. Por ello, citamos textualmente la traducción:

«Enmascaramos las contraseñas a través de un proceso llamado hashing utilizando una función conocida como bcrypt, que reemplaza la contraseña actual por un conjunto aleatorio de números y letras que se almacenan en el sistema de Twitter®. Esto permite que nuestros sistemas validen las credenciales de tu cuenta sin revelar tu contraseña. Este es un estándar de la industria.»
«Debido a un error, las contraseñas se escribieron en un registro interno antes de completar el proceso de hashing. Este error lo encontramos nosotros mismos, eliminamos las contraseñas y estamos implementando planes para evitar que este error vuelva a suceder.»

Las letras cursivas y negrillas son nuestras, no forman parte del comunicado y las queremos explicar (paciencia, ya llegaremos al papel de la monitorización en este incidente).

Para el Diccionario de la Real Academia Española sí son sinónimos

Pero para nosotros, programadores y administradores de sistemas, no. Y esto no disminuye ni invalida a dicho diccionario. Lo que sucede es que la información dirigida hacia el público en general es, y será siempre, diferente a la dirigida al público especializado. En nuestro idioma castellano los verbos ‘encriptar’ (derivado del idioma inglés) y ‘cifrar’ significan lo mismo: transcribir con una clave a fin de dificultar su lectura por terceros. Pero en informática utilizamos un proceso que, prácticamente, no permite descifrar dicha información. ¿Cómo es esto posible? ¿A quién puede serle útil este proceso?

Por ello es que resaltamos la palabra anglosajona hash, en específico el verbo to hash, que significa trocear, dividir o picar en trozos, como cuando uno rompe en muchísimos pedazos una carta de papel. ¿Quién podría leer eso? Pero con el advenimiento de los ordenadores, el dividir un mensaje -o una contraseña que es el caso que nos ocupa- y guardarlo en diferentes sitios tampoco garantiza nada de seguridad; podrían interceptar nuestros trozos de mensaje en el servidor encargado de identificar a nuestros usuarios que inician sesión. El problema sigue siendo el mismo que le ocurrió a Twitter®: la contraseña sigue siendo almacenada en texto plano.
Claro queda que Twitter® guarda nuestras contraseñas hasheadas, de tal manera que en realidad compara ambos resultados con la misma función para asumir que el usuario es quien dice ser. Mejor dicho: cuando abrimos una cuenta de usuario en la mayoría de los sitios web y establecemos una contraseña, ésta es hasheada y almacenada en una base de datos. Nótese que empleamos un algoritmo para ese trabajo y lo volveremos a utilizar a futuro cuando iniciemos sesión de nuevo: volvemos a introducir nuestra contraseña, le aplicamos las fórmulas matemáticas y el resultado (una cadena de caracteres) debe ser igual e idéntico al depositado (el proceso que utilicemos debe garantizar que no haya colisiones: dos contraseñas distintas producen el mismo resultado –hash-).

Esto explica el por qué, cuando perdemos nuestra contraseña (evento sobrevenido) ante los bancos, no nos dicen cuál era, porque sencillamente ellos mismos no pueden descifrarla. Es más fácil borrarla y que nosotros coloquemos una nueva. Probablemente nos darán una clave provisional, desechable, que usaremos una sola vez para realizar esta tarea, pero es estrictamente temporal y se almacena y maneja de manera totalmente diferente al proceso de identificación normal. De hecho, al usar esa contraseña desechable no entraremos a nuestra cuenta bancaria, sino que un mensaje nos indicará que la nueva contraseña definitiva fue fijada y que iniciemos sesión por los canales regulares.

Utilizando bcrypt

Podremos instalar bcrypt en cualquiera de nuestros sistema GNU/Linux, por medio de la orden “apt-get install bcrypt”:

evento sobrevenido

Luego podremos utilizar el comando man bcrypt para conocer su funcionamiento (en Debian, desde la versión 8 “Jessie”, ha sido deshabilitada la capacidad de encriptar ficheros). Veremos algo parecido a esto y enseguida notaremos que su trabajo es encriptar archivos (ficheros) mediante el algoritmo blowfish:

evento sobrevenido

¡Pero lo más sorprendente es que también DESCIFRA dichos ficheros! Aquí vemos dos puntos débiles: el utilizar archivos para pasar la información y el hecho de que se pueda descifrar la información. Bcrypt establece que los archivos de origen, en caso de ser cifrados exitosamente, serán comprimidos y luego reescritos con caracteres aleatorios antes de ser borrados. (¿Recuerdan las series de televisión de la década de los 60?: “Este mensaje se autodestruirá en cinco segundos”. ¡Evento sobrevenido!).

Particularmente nos inquieta que bcrypt permita descifrar las contraseñas y así se lo hicimos saber por mensaje en Twitter al Sr. Parag.

La monitorización en el proceso de “fuga” de contraseñas

Aclaramos que en la ciencia -y arte- de monitorizar los sistemas, el trabajo intrínseco consiste en “sacar” datos para convertirlos en información y de manera alguna está contemplado ningún otro uso para los datos. También insistimos que Twitter® tampoco almacena, de manera explícita y directa, en formato de texto plano. En este aspecto, repetimos que Pandora FMS selecciona los datos a monitorizar en vez de filtrar los datos. Existe software de monitorización que recolecta todos los datos guardados en los registros (logs) de cada ordenador en producción y podemos inferir que fue en este punto que notaron que esos ficheros desechados estaban en texto plano.

Si bien es cierto, desde el punto de vista del programador, cuando se está en modo de desarrollo, el registrar absolutamente todo cuando se pasa al ambiente de producción se debe emplear la compilación condicional a fin de evitar que información privada de los usuarios se convierta en información pública. Estas normas están bien establecidas en el mundo de los desarrolladores de aplicaciones y software web. La manera más fácil es indicar en la opción “Acerca de”, en cada software, si está en modo de desarrollo o en modo de producción. Y de nuevo llueve sobre mojado: esto se logra con variables e instrucciones específicas de compilación condicional.

Vemos difícil de creer que bcrypt haya sido el “culpable” o causante del evento sobrevenido, sino la forma y manera de entregarle los ficheros a encriptar (a menos que utilicemos los parámetros “-c -r” que evita comprimir y borrar). Imaginamos que cada ordenador almacena la contraseña del usuario en texto plano de manera local -una cola de ficheros- que luego es enviado protegido por TLS a un servidor encargado de encriptar. El proceso de encriptar o hashear cualquier dato o información tiene un trabajo adicional que pesa sobre el desempeño del sistema, incluso se trabaja en un “cifrado ligero” para “el Internet de las Cosas“. En el artículo publicado por este vuestro blog sobre Solaris indicamos que dicho sistema operativo ofrece apoyo para ordenadores con chips auxiliares SPARC M7, dedicados de manera exclusiva al trabajo matemático necesario para cifrar absolutamente todo, incluso la transmisión de datos e información sobre la monitorización.

Hablar en profundidad sobre el cifrado y hasheado abarca para un artículo completo, ya que es un trabajo, como dijimos, que sobrecarga al sistema. Por ejemplo, en marzo de 2017 publicamos sobre el protocolo SNMP y que su uso no se había popularizado. Entre las características que hacen diferente a esta versión está la comunicación cifrada entre ordenadores (en la versión de Pandora FMS NG 722 damos soporte a la versión 3 en modo polling sin dejar de mantener la increíble velocidad). Evidentemente que cifrar y descifrar son pasos adicionales y que necesitan el manejo de credenciales, el guardado de contraseñas y aquí vamos de nuevo…

Conclusión

Os hemos presentado de manera somera un acercamiento al oficio matemático de cifrar y hashear datos e información. La información aquí presentada de ninguna forma ni manera es, ni pretende representar, la posición de Pandora FMS y sus desarrolladores: todo lo aquí planteado es responsabilidad única y exclusiva de su autor. Háganos saber sus comentarios aquí abajo o, mejor aún, contáctenos este enlace para mayor información acerca de Pandora FMS, donde gustosamente será atendido. ¡Hasta una próxima oportunidad!


    Written by:



    Leave a comment

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

    Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.