Chiffrer une base MariaDB pour Gophish

Salut à tous, aujourd’hui on va regarder comment on peut protéger des tables de base de données et chiffrer une base MariaDB. En effet, dans ce précédent article sur Gophish, je vous ai montré quelques outils open source pour faire des campagnes de phishing. Ce que je n’ai pas pris le temps de vous dire, c’est que lorsqu’on fait du Phishing en entreprise (ou en presta), on récupère de la donnée personnelle, au sens RGPD, mais genre en masse.

Déjà, en amont de la campagne, votre « client » va devoir vous donner la liste des utilisateurs cibles et leur adresses e-mail. Et puis pendant la campagne, les « victimes » vont s’authentifier sur un portail laisser un nom d’utilisateur, potentiellement un mot de passe, un horaire, etc. Bref, autant je ne fais pas partie des ayatollahs qui considèrent qu’une adresse IP toute seule est une donnée personnelle, autant dans ce type de cas, il n’y a pas trop de débat.

Du coup, on a des obligations vis à vis de ces données : protection, information en cas de pépins, destruction, enregistrement dans un registre du traitement, etc. je ne vais pas vous refaire le RGPD ici. Mais dans ce cadre, je me suis dit qu’il pourrait être intéressant de mettre en place un chiffrement « de surface » sur la base de données Gophish, histoire de faire bonne mesure. Et pouf voilà ce post…^^

Chiffrer une base MariaDB

J’ai repris un tuto que j’ai trouvé plutôt bien fait (ici), mais la doc officielle est là, qui fait le taf sans rentrer dans des détails compliqués de la crypto. La première étape consiste à générer une clé de chiffrement symétrique :

# mkdir /etc/mysql/.hiddenkey
# chown -R mariadb:mariadb /etc/mysql/.hiddenkey
# chmod -R 400 /etc/mysql/.hiddenkey
# cd /etc/mysql/.hiddenkey
# openssl rand -hex 16 > keys.txt

Une fois cette clé dans le fichier keys.txt, il faut éditer le fichier pour rajouter un id (numéro) devant et séparer les deux avec un point-virgule

# vim keys.txt et add "1;" (et utilisez sed si vous en fait plein, hein)
## 1; 4c8631814574f563359fb95fccfe57a4

Ensuite on refait la même opération de génération de clé, mais cette fois pour chiffrer notre fichier avec un seconde clé.

# openssl rand -hex 16
ff5b3026d19674570890bffd789e0a12
# openssl enc -aes-256-cbc -md sha1 -k ff5b3026d19674570890bffd789e0a12 -in keys.txt -out keys.enc
# ll
-rw-r--r-- 1 root root 64 Oct 10 17:03 keys.enc
-rw-r--r-- 1 root root 35 Oct 10 17:02 keys.txt
# rm keys.txt

Voilà ensuite on va configurer MariaDB pour activer le module de chiffrement :

# vim /etc/mysql/conf.d/encryption.cnf
[mysqld]
plugin-load-add=file_key_management
file-key-management
file_key_management_encryption_algorithm=aes_cbc
file_key_management_filename = /etc/mysql/.hiddenkey/keys.enc
file_key_management_filekey = ff5b3026d19674570890bffd789e0a12
innodb-encrypt-tables
innodb-encrypt-log

Un petit coup de restart du container ou du service MariaDB et c’est bon, on a activé le module. Par contre, là il faut savoir que rien n’est chiffré, le chiffrement s’effectuant table par table.

Du coup pour cet exemple, j’ai fait le tour des tables contenant des données personnelles dans Gophish et activer le chiffrement.

# mysql -p
show databases;
use gophish;
show tables;
ALTER TABLE results ENCRYPTED=YES ENCRYPTION_KEY_ID=1;
ALTER TABLE events ENCRYPTED=YES ENCRYPTION_KEY_ID=1;
ALTER TABLE targets ENCRYPTED=YES ENCRYPTION_KEY_ID=1;

Pour les paranos, les tables suivantes contiennent des comptes d’accès utilisés par la plateforme, du coup on peut les chiffrer aussi (tant qu’a y être) :

# contiennent des données internes à l'appli, mais sensibles.
ALTER TABLE users ENCRYPTED=YES ENCRYPTION_KEY_ID=1;
ALTER TABLE smtp ENCRYPTED=YES ENCRYPTION_KEY_ID=1;
ALTER TABLE imap ENCRYPTED=YES ENCRYPTION_KEY_ID=1;

Je vous donne pour finir les requêtes magiques pour lister les tables pour lequel le chiffrement est activé et désactivé le chiffrement

SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION WHERE ENCRYPTION_SCHEME=1;
# et 
ALTER TABLE maTable ENCRYPTED=NO; pour désactiver.

Vous pouvez contrôler que le chiffrement est bien appliqué en allant dans et en regardant un fichier de table avant et après que celui-ci soit chiffré :

# cd /var/lib/mysql/gophish/
# xxd users.ibd
00004190: fd0e 4ad5 ca80 af20 882e 67c5 ed09 d9d3 ..J…. ..g…..
000041a0: 557a 9cef 4efb 8a61 cd31 c766 9c2c 5df8 Uz..N..a.1.f.,].
000041b0: ac9f 2608 24e3 8ef5 4492 f0f3 8d96 86c7 ..&.$…D…….
000041c0: 80e8 0faa ec10 84a7 0207 6310 9cdd 9f37 ……….c….7
000041d0: 6436 3100 15b4 2683 2fca e1e4 425c 2316 d61…&./…B#.
000041e0: e97c bc53 38b3 41bb a1f1 bf40 bfe8 92f8 .|.S8.A….@….
000041f0: 40ad 3434 d650 4395 4f6e 2de8 cad2 3c5f @.44.PC.On-…<_

Mais tout cela ne répond pas à la question que tout le monde se pose ?

Est-ce vraiment utile de chiffrer une base MariaDB comme ça ?

Et bein, en fait, comment dire… non ? Clairement d’un point de vue sécu en tout cas, car dans l’exemple que je viens de vous dérouler, la clé de chiffrement est stockée juste à côté de nos fichiers de conf et de la base. Un attaquant qui aurait accès au fichier de la base aurait donc très probablement accès à la clé de déchiffrement de celle-ci. La procédure de MariaDB propose bien de remplacer la clé de déchiffrement par un fichier mais bon : c’est les poupées russes là, si on ouvre la première on peut dérouler tout le reste… D’ailleurs je soupçonne qu’une procédure de restauration aussi basique que celle-ci fonctionnerai (à tester, je vous le laisse en exercice).

Si au moins le module permettait de charger en mémoire la clé de déchiffrement du fichier keys.enc au démarrage (MariaDB n’en a besoin qu’à ce moment) du service mais sans persistence sur le disque. Alors il y a bien l’option de déporter le fichier de clé (vu ici) et qui rajoute permet quand même la protection contre le vol physique du serveur ou un dump un peu con du disque dur, mais si le fichier reste accessible l’attaquant ira le récupérer sur l’autre machine tout pareil… J’ai pas trouvé mieux (à l’heure actuelle), c’est un peu léger je trouve pour une base de l’ampleur de MariaDB sur le marché.

Après d’un point de vue conformité, c’est moins pire (ou pas) voire un peu mieux, en effet vos correspondant traitement des données seront content : la base qui contient des données personnelles est chiffrée, ce qui peut éviter quelques remarques en réunion projet, mais en contrepartie d’un faux sentiment de sécurité donné aux responsables, probablement en exposant un peu moins à des risques légaux en cas de pépins quand même (après tout vous aviez chiffré la base)… j’attends la jurisprudence avec impatience pour vous dire !

Conclusion

Bref, tout ça pour dire le chiffrement des tables de MariaDB ne sert pas à grand-chose selon moi à part faire plaisir à quelques décideurs qui n’y comprennent pas un bit (rien de choquant jusque là) et qui ne s’y intéressent surtout pas (déjà plus embêtant) : tant que leurs cases sont au vert dans le tableau Excel de suivi projet ! C’est tout pour aujourd’hui, j’espère que vous aurez retenu que si on vous demande de chiffrer une base MariaDB vous pouvez le faire facilement pour faire plaisir à votre chef, mais rappelez-vous de protéger le serveur (iptables, suricata, fail2ban, Splunk, etc.) quand même. Comme d’habitude, j’espère vous avoir appris 2-3 trucs et que ça vous aura intéréssé, je vous dis à la prochaine pour d’autres geekeries !