[PoC] Cifrado del historial de bash (.bash_history)

El otro día, en mis momentos de ocio, se me ocurrio buscar una forma de cifrar el historial de comandos que guarda bash. Hay servidores que sólo tenemos -o hemos ganado- acceso como usuarios, y no nos gusta que el administrador (root) vea lo que hacemos o los comandos que hemos ejecutado. Existen varias formas de ir contra eso, por ejemplo eliminar el bash_history o bien editarlo cada vez que hacemos algo que no queremos que sepan. Esta forma es un poco mas rebuscada y busca cifrar mediante GPG el historial, de manera tal que el root no podrá leer lo que dice el archivo.

La logica es bastante simple:

  1. Cuando ingresamos (login) a nuestra cuenta desciframos el bash history usando nuestra clave privada
  2. Cuando salimos (logout) ciframos el archivo con nuestra clave publica.

Para lograrlo vamos a necesitar tener una clave gpg y configurar el comportamiento del login y logout con unos scripts que les mostraré a continuación.

Vamos a usar el usuario “usuario” de prueba. Primero, creamos la clave GPG:

[usuario@belcebu ~]$ gpg --gen-key

En mi caso, generé una clave de 2048 bits con el UID Usuario de Prueba (Historial Cifrado) <test@zerial.org>

Editamos el archivo .bashrc y agregamos las siguientes lineas

gpg -d -r "Usuario de Prueba (Historial Cifrado) <test@zerial.org>" $HISTFILE >$HOME/._bash_history
mv $HOME/._bash_history $HISTFILE

Luego creamos el siguiente script, lo llamaremos .crypt_history.sh:

#!/bin/bash

sleep 2;
gpg -e -r "Usuario de Prueba (Historial Cifrado) <test@zerial.org>" $HOME/.bash_history
mv $HOME/.bash_history.gpg $HOME/.bash_history

Y agregamos la línea

nohup sh $HOME/.crypt_history.sh &

Al archivo .bash_logout

De esta forma, al ingresar como usuario se ejecutará automaticamente el comando que descifra el .bash_history y cuando salimos, será cifrado.

[root@belcebu ~]# cat /home/usuario/.bash_history
zå¬ÈùrèÿJx¨¸QÕ{¥ ±5#ºcHb¶÷çFÀ®ú4ÞÃØÝ­xbZúF çïkågµNÒ¸5îÅ£ ³KÝ0U¯º±YHú#ÙÞ©Ù&¶þ¢Lyug
þ
ÓL¹ðú®&°í¾vI?V\9Õx'{4hÐaÜdÛPÅ©²¦öcñm¾O’µÔ2ɪðá¸ó²ëÕÁ²NªOÈ`A²U´¬Uîkï
u:÷ÛASþdè¶]1ê¬GBXLT¥3þ0Ñ_8uóâEQ¯`.¾Kn3AÒy»çÌ¡øyà$ßÙkíKzܧ¸×’Øx¿S¥
ÂâÆâveó´Î/¸)aýü4µÅ:mCú}1Á$äãÑõæ>¥ÈM9IÈÛ³=PË^q{Ñ
3º ë]Å¿74ë*Ø
Öuå¦
[root@belcebu ~]#

Y si ingresamos como usuario …

gpg: encrypted with 2048-bit RSA key, ID C8F972E8, created 2011-02-03
“Usuario de Prueba (Historial Cifrado)
[usuario@belcebu ~]$ history
1 cat nohup.out
2 vim .bashrc
3 vim .crypt_history.sh
4 ls
5 history
6 ls -lia
7 history
[usuario@belcebu ~]$

Existe un pequeño detalle, es que el root puede ingresar como usuario y de esta forma poder el historial. Pero para esto, nosotros debemos proteger nuestro cifrado con un passphrase, asi cuando el root quiera ingresar como usuario, éste le pedira una clave para poder descifrar el archivo bash_history, si el root no maneja esa clave no podrá ver lo que hay.

Esto es solo una prueba de concepto (PoC), se puede hacer cualquier modificación a los scripts usados para adaptarlos a otras necesidades y obviamente mejorar el cifrado mismo del bash_history.
Nota: Existen varios peros en esta forma de cifrar, que obviamente pueden ser mejoradas, por ejemplo, podria existir algun conflicto cuando se inicia mas de una vez la sesion del usuario.

8 comentarios

  1. Trabajo para nada porque no te protege del root. En el segundo caso la clave privada está guardada bajo contraseña en el sistema, así que solo tiene que instalar un keylogger el root (por defecto tiene permisos para ello) para quedarse con tu contraseña.

    Se debería cifrar con una clave pública ajena al sistema, y tener un script para mandar el history una máquina remota donde se haga el descifrado.

    Pero personalmente también me parece todo absurdo 😛 porque si el root está tan interesado en conocer lo que tecleeas, tiene otras mil formas a parte de leer el history, como usar bashlogger o modificar bash, guardar por duplicado los history, hookear funciones, modificar otros binarios, etc. Si solo se considera el fichero history (irreal) si no trabajas en conjunto con una máquina remota siempre vas a estar jodido. Pero en ese escenario también lo estás porque el root podría hasta modificar el comportamiento de tus scripts y solo te quedaría jugar con la posibilidad de tener todo firmado digitalmente, comprobación de la integridad y demás cosas.

    Yo creo que es querer tener una sensación falsa de seguridad/privacidad 😛

    Saludos!

  2. Zerial

    febrero 3, 2011 a las 11:09 am

    Hola vierito5!

    Tienes razon en varias de las cosas que dices, pero no creo que sea una sensacion de false seguridad/privacidad.

    Si bien el archivo de clave esta en el mismo servidor y el root tiene acceso a ella, pues no tendra acceso al passphrase. Si bien puede instalar un keylogger o algo asi, pues el key logger se instala a niverl de cliente, no? Es decir, el keylogger deberia estar en mi PC para que guardara las teclas que presiono. Sobre el bashloger, pues entonces habra que usar otra pedida para protegerse del bashloger.

    Esta bien que tiene varias falencias, pero solo es una prueba de concepto de como cifrar, de alguna forma, el bash_history.

    Lo que dices de guardar fisicamente los archivos de claves en forma remota lo encuentor bueno, pero tambien tiene sus falencias. Por ejemplo, podria aplicar el script de cifrado del bash history en mi sistema, antes de hacer el ssh, que cifre el archivo y me lo traiga y luego cuando cierre la sesion, lo mande cifrado nuevamente, pero que pasa si te conectas de otra maquina, donde no tienes los archivos de clave? Te limitas a entrar solo desde un pc.

    Creo que tu critica es buena y tiene un cierto sentido, pero no aplica ya que dejo en claro que realmente no es una medida de proteccion y que tiene muchas falencias, que simplemente es una prueba de concepto

    saludos!!

  3. Zerial

    febrero 3, 2011 a las 11:13 am

    vierito5, ademas es tan absurdo como pensar en no usar contraseñas, ya que si alguien te quiere hackear perfectamente puede instalar un keylogger en tu pc, no? 🙂

  4. Ya, pero estás hablando del root de tu máquina, no de un atacante externo. El atacando externo ha de ganar privilegios antes de poder joderte.

    Tema de loggear lo que escribes, aunque te conectes remótamente estás vendido igualmente porque todo lo que ejecutas se hace en la máquina donde el root tiene los privilegios.

    Como PoC está chulo 🙂 (la crítica pretendía ser constructiva) pero yo sigo viendo que te protege.

  5. vierito5, me parece muy buenas tus criticas y lo que dices, pero estoy buscando la forma de hacer esto lo mas seguro posible.

    Se que es vulnerable y que si el root quiere, puede joderme, pero … como lo hago de mejor forma? Cual podria ser una mejor forma?

    Abri un hilo en full-disclosure: http://seclists.org/fulldisclosure/2011/Feb/62

    Saludos

  6. Lo cierto es que no sé porque veo que el root lo tiene fácil para cogerte. Da igual incluso que como usuario desactives el history, el root puede loguearlo por otro lado y en claro o como quiera.

  7. Zerial, ésto es simple ofuscación, no cifrado.

    Realmente no sé por donde empezar; ésto parece una broma.

    En términos generales: Si no confías en el root, el servidor ha de asumirse inseguro pues está controlado por el anterior. Si realizas el “cifrado” y “decifrado” en el servidor inseguro, ha de asumirse que cualquier información relevante al susodicho proceso está comprometida. Ésto incluye la “clave”.

    Más específicamente, root puede modificar BASH para registrar todo en una ubicación a la que no tengas acceso, ésto incluye el historial y la clave.

    Nota: asumo que el root tiene acceso a la computación realizada en su computadora pues no conozco algun método de realizar computaciones de forma segura en un medio inseguro.

    Referente al “keylogger”, supongo que el otro usuario se refiere no a un keylogger en tu computadora (De confianza) sino en la parte del servidor; root solo tiene que modificar el programa pertinente (sshd, telnet, etc…).

    Por cierto, GNU PG tiene la opción de cifrado simétrico directamente (-c). El cifrado asimétrico solo tiene sentido cuando se deseea separar la facultad de cifrar de la de decifrar, lo cuál es innecesario en éste caso.

    Un saludo, y no le hagas al criptógrafo porque no te sale ;-).

  8. En estos casos es mejor nunca guardar un history
    y sobre el root facil.. rootearse la maquina xD

Deja un comentario

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

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