Archive | Boulot

Playing with bcrypt and Joomla

Juste pour poser là quelques détails sur le stockage sécurisé des mots de passe dans Joomla (cms php très courant).

Bref un truc avec lequel on joue un peu en TP, mais qui est aussi parfois bien utile quand on a perdu le mot de passe de l’unique compte d’administration du site (n’est-ce pas la Mairie de N….?, vieille mission Alliacom en 2010).

Si je jette un œil sur le contenu de ma table des utilisateurs Joomla, j’aperçois ce genre de chaînes de caractères dans les champs password :

$2y$10$OL0ibA8TKT.287zm4HPkYuKI/5CH0X1bMe9PyxPRjOxjeCSC/FOwm

On notera par ailleurs qu 2 utilisateurs avec le même mot de passe présenteront un hash différent, bref on est loin du pauvre MD5 sans sel utilisé il y a quelques années par Joomla.

On reconnaît un hash bcrypt par la présence en début de chaîne de  $2y dans ‘$2y$10$’, le $10 est le coût algorithmique, autrement dit 210 = 1 024 itérations.

Les 22 caractères suivants constituent le sel aléatoire. Les caractères qui complètent la chaîne composent le mot de passe hasché. Comme un petit schéma vaut mieux qu’un long discours :

brcypt

brcypt selon wikipedia

Pour plus de détails (tout public) sur bcrypt  : https://www.bcrypt.fr/questions

Et pour aller plus loin dans la compréhension : https://auth0.com/blog/hashing-in-action-understanding-bcrypt/

Et enfin pour faire quelques tests en ligne : https://bcrypt-generator.com/

La fonction crypt en php, fonctionne donc comme cela :

crypt($motdepasse, '$2y$10$'.randombytes(22));
playing with bcrypt and Joomla

playing with bcrypt and Joomla

http://micmap.org/php-by-example/man…ion.crypt.html

Exemple : password (très mauvaise idée de mot de passe)

$2y$10$.prE1BkZ87aPNnsKMTOSxe9pv8TQIhfBb2HZpSnBPfh.LeHgnaLD2

 

Cette fonction est par exemple utilisée dans Joomla la classe/méthdoe JUserHelper::hashPassword pour Joomla. Après étude, il est ainsi relativement simple de créer un fichier joomla-password-hash.php et de le placer à la racine de son site.

<?php
define(‘_JEXEC’, 1);
define(‘JPATH_BASE’, dirname(__FILE__));
require_once(JPATH_BASE . ‘/includes/defines.php’);
require_once(JPATH_BASE . ‘/includes/framework.php’);
echo « <strong>Password: </strong> » . JUserHelper::hashPassword(‘password’);

?>
https://api.joomla.org/cms-3/classes/JUserHelper.html

En résumé, le nombre d’itérations implique un calcul plus long et plus fastidieux pour les scripts de hacks et même si la base de données était piratée, cela me semble un peu plus difficile de retrouver le mot de passe… comme ce fut le cas l’année dernière pour dailymotion (ce service de video utilisent bcrypt également) : https://www.information-security.fr/…didentifiants/

L’implémentation d bcrypt a donné un peu plus de sécurité à Joomla, cela n’empêche pas d’imposer un minimum de caractères, mélange min/maj, caractères spéciaux aux mots de passe pour fonctionner un peu plus efficacement. Il faut éviter par exemple que les utilisateurs utilisent uniquement leur date d’anniversaire pour le mot de passe … (chercher « paradoxe des anniversaires » dans un moteur de recherche si vous aimez les probabilités )…

De plus, il y a aujourd’hui un marché de solutions complémentaires à connaître : MFA, double authentification (google authenticator et dérivé), sans mot de passe comme launchkey.com, par sms avec accountkit de facebook…

Posted in Boulot, Clic1 Commentaire

OpenShift Issue

OpenShift Playground

OpenShift Playground

Sad, no beeing able to assess OpenShift Playground 🙁

Posted in Boulot, Clic, Trop sérieux1 Commentaire

Solarwinds (solorigate, sunburst)

SolarWinds - Photographer: TRIPPLAAR KRISTOFFER/SIPA/AP

SolarWinds – Photographer: TRIPPLAAR KRISTOFFER/SIPA/AP

 Le sujet :

Voir page Wikipedia FR ou mieux Wikipedia EN

Raccourci :

Un vulgarisation du sujet grâce à une vidéo de 5mn de Romain du Marais

Les faits : « In an operation that cybersecurity experts have described as exceedingly sophisticated and hard to detect, the hackers installed malicious code in updates to SolarWinds’s widely used Orion software, which was sent to as many as 18,000 customers.

The malicious code provided the hackers access to the customers’ computer networks and, as clients around the world continue to comb their systems for signs of the Russian hackers, the list of victims is expected to grow. »

 

Chronologie :

Octobre 2019 : premiers essais à blanc de la méthode de distribution du malware

Mars 2020 : distribution de la backdoor

8 décembre 2020 : FireEye, par le biais d’un article de blog de son CEO Kevin Mandia communique sur le hack dont elle vient d’être victime avec pour conséquence le vol d’une partie des outils utilisés par ses Red Teams.

Reuters et les agences de presse généralistes relaient l’information : U.S. cybersecurity firm FireEye discloses breach, theft of internal hacking tools

13 décembre 2020 : communication coordonnée de FireEye, solarwinds, Microsoft et du gouvernement américain.

 

Premiers détails:

NextImpact – 23 décembre 2020
Piratage de SolarWinds : un ancien salarié avait alerté, en vain
D’après le très bon article original de Bloomberg du
SolarWinds Adviser Warned of Lax Security Years Before Hack by

 

Communication de crise : SolarWinds spokesperson said in a statement, “Our top priority is our work with our customers, our industry partners and government agencies to determine whether a foreign government orchestrated this attack, best understand its full scope, and to help address any customer needs that develop. We are doing this work as quickly and transparently as possible. There will be plenty of time to look back and we plan to do that in a similarly transparent way.”

In addition, the company said it is collaborating with law enforcement and “will continue gathering all relevant information to ensure an incident like this does not happen again.

 

Les acteurs :

Kevin Thompson, solarwinds’s chief executive officer, former securty adviser at solarwid

Ian Thornton-Trump, chief information security officer at threat intelligence firm Cyjax Ltd

Tim Brown former chief technology officer at Dell Security, current vice president of security architecture

Vinoth Kumar Cybersecurity expert who discovered FTP server credential on gitHub

Former internal langue de pute, ex solarwind : A former SolarWinds employee, who worked as a software engineer at one of the company’s U.S. offices, said SolarWinds appeared to prioritize the development of new software products over internal cybersecurity defenses.

Jake Williams, aka monsieur-je-sais-tout, a former hacker for the U.S. National Security Agency who is now president of cybersecurity firm Rendition Infosec, said technology companies such as SolarWinds that build and produce computer code often “don’t do security well.”

 

Les victimes :
At Least 200 Victims Identified in Suspected Russian Hacking, dont :

 

Les affreux :

Alors, Dark Halo ou bien  APT29 (aka Cozy Bear), un groupe de hackers lié au SVR (Служба внешней разведки Российской Федерации, retranscrit en Sloujba vnechneï razvedki Rossiskoï Federatsi2 – Service des renseignements extérieurs de la fédération de Russie – Russian Foreign Intelligence Service) ?

Joe Słowik ⛄ @jfslowik · 17 déc.

Joe Słowik ⛄ @jfslowik – 17 déc.

 

Un peu de technique :

Très bon article intégrant pas mal de détails techniques compréhnsibles par ma mère sur l’attaque dans l’article The SolarWinds cyberattack: The hack, the victims, and what we know

Pour aller, plus loin : le technical write-up de Microsoft

SolarWinds supply chain attack Source: Microsoft

SolarWinds supply chain attack
Source: Microsoft

 

Conclusion de Costin Raiu (Kaspersky GREAT) :

Even if SolarWinds had robust cybersecurity practices, however, it might not have deterred the alleged Russian hackers, who U.S. authorities described as highly skilled, patient and well resourced, demonstrating “complex tradecraft” in their attacks.

“The reality is that sophisticated threat actors, no matter how good the defenses, will eventually succeed,” said Costin Raiu, director of global research and analysis at the cybersecurity firm Kaspersky. “If the cost justifies the effort, the breach will happen.”

 

 

Mises à jour :

02/01/2020 : The New-York Times : As Understanding of Russian Hacking Grows, So Does Alarm

04/01/2020 : Detecting Supernova Malware using Splunk

05/01/2020 : SolarWinds Hit with Securities Class Action Over Statements in Run-Up to Cyberattack on Fed. Government

05/01/2020 : FBI, CISA, NSA Officially Blame Russia for SolarWinds Cyber Attack

Russia loves solarwinds

solarwinds

Posted in Boulot1 Commentaire

Notes Splunk 2020

Splunk

Splunk

 

 

 

 

 

 

 

 

 

Quelques conseils ici pour réaliser nos tests..Installation et configuration de Splunk

C’est fou ce que ce petit outil me dit de vous.

J’ai caché 2 ou 3 trucs rigolos sur ce site, saurez-vous les découvrir ?

 

Posted in Boulot0 commentaire

Protégé : HTTP authentication

Cette publication est protégée par un mot de passe. Pour la voir, veuillez saisir votre mot de passe ci-dessous :

Posted in BoulotCommentaires fermés sur Protégé : HTTP authentication

Protégé : RSA public key : Behind the scene

Cette publication est protégée par un mot de passe. Pour la voir, veuillez saisir votre mot de passe ci-dessous :

Posted in Boulot, CryptoCommentaires fermés sur Protégé : RSA public key : Behind the scene

TLS setup for Apache Tomcat

Very first thing : Read That F*** Manual !

$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA

and specify a password value of « whatYouWantButNotChangeIt ».

keystore

keystore

 

 

 

 

 

 

 

 

 

 

 

 

 

Edit your server.xml file, beware that commented examples provided could be very far from what youy need :

<!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
<Connector
           protocol="org.apache.coyote.http11.Http11NioProtocol"
           port="8443" maxThreads="200"
           scheme="https" secure="true" SSLEnabled="true"
           keystoreFile="${user.home}/.keystore" keystorePass="changeit"
           clientAuth="false" sslProtocol="TLS"/>


<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
keystoreFile="/root/.keystore"
keystorePass="***********"
clientAuth="false" sslProtocol="TLS">

Posted in BoulotCommentaires fermés sur TLS setup for Apache Tomcat

RSA avec openSSL

Intégralement et honteusement pompé sur https://www.fil.univ-lille1.fr/~wegrzyno/portail/PAC/Doc/TP-Certificats/tp-certif002.html

1. Génération d’une paire de clés

On peut générer une paire de clés RSA avec la commande genrsa de openSSL.

$ openssl genrsa -out <fichier> <taille>

fichier est un nom de fichier de sauvegarde de la clé, et taille et la taille souhaitée (exprimée en bits) du modulus de la clé.

Par exemple, pour générer une paire de clés de 1024 bits, stockée dans le fichier maCle.pem, on tape la commande

$ openssl genrsa -out maCle.pem 1024

Le fichier obtenu est un fichier au format PEM (Privacy Enhanced Mail, format en base 64), dont voici un exemple :

$ cat maCle.pem

-----BEGIN RSA PRIVATE KEY----- MIICXAIBAAKBgQCveVjLltevTC5kSAiTYjHMVuAR80DHMLWCp3BOVZ49eXwraXxO 7AfKWpA5g0wFZgZNERIfFYaCnvaQDQA+9BRIfsSSr3oSw0My5SD6eg15v0VmJmvP d8LgBypJHbr6f5MXWqntvzp0Qvg6ddeNpUIrqkkh4uDfHFDWqyrkQUCvKwIDAQAB AoGANchUrfnq28DWy0fE0R+cscvC292Z8jN8vrIBWxEk8iSlKU0om6v+a0g8wlP6 3gC6V66uxjY7xxdf7SD+/UykVl4PGFymhLtywSdGlgec3tLgBtV3ytJFilAVDBij LzQwUegCO4zt1JWYc6vvaVdNyQSaGIIeYGsNDWEYlOtDSlkCQQDVRn9JS15G8p+H
4Z0PbU9ZQg2L1u9/SD/kELVe3Kx1fdHulxH0v8V2AgPdXA29Nhi+TxUtC+V8CMc2 KXmAvFsHAkEA0qBDmjHMDPwcGaqbQ2lymYQIGlZ5TLQFA98Dey2uE+CB6pmS/e/Z ilu1IaasuE3vBzXfB/JU7DUkV++JQ7TtvQJBAL2s5dUch2sXqlOhjhpDP/eE7CE6 9WLAsbm2Nmd4YJRZYtQLXPfLeeSapC9BCCMHsnfGQ3H9i4mFEQ6VUi7w1Q8CQAQa pVaS09QI8Y86eM4GdvowzWud9b0d4N8jcFDtIfA3NrDYjzmte8KraMsgEUuCET9F
uHPSL/9uRagE/dq44s0CQCMQU4PMqkMtwzCFsV8ZqLmkDPn1binIAwRLYFcsQRDt gTi6rycz3Pk1hCVzBfyMd8zwqpwKmR5FoOXuJEv+mVg=
-----END RSA PRIVATE KEY-----

2. Visualisation des clés RSA

La commande rsa permet de visualiser le contenu d’un fichier au format PEM contenant une paire de clés RSA.

$ openssl rsa -in <fichier> -text -noout

L’option -text demande l’affichage décodé de la paire de clés. L’option -noout supprime la sortie normalement produite par la commande rsa.

Par exemple

$ openssl rsa -in maCle.pem -text -noout

Private-Key: (1024 bit)
modulus:
00:af:79:58:cb:96:d7:af:4c:2e:64:48:08:93:62: 31:cc:56:e0:11:f3:40:c7:30:b5:82:a7:70:4e:55: 9e:3d:79:7c:2b:69:7c:4e:ec:07:ca:5a:90:39:83: 4c:05:66:06:4d:11:12:1f:15:86:82:9e:f6:90:0d: 00:3e:f4:14:48:7e:c4:92:af:7a:12:c3:43:32:e5: 20:fa:7a:0d:79:bf:45:66:26:6b:cf:77:c2:e0:07: 2a:49:1d:ba:fa:7f:93:17:5a:a9:ed:bf:3a:74:42: f8:3a:75:d7:8d:a5:42:2b:aa:49:21:e2:e0:df:1c:
50:d6:ab:2a:e4:41:40:af:2b
publicExponent: 65537 (0x10001)
privateExponent:
35:c8:54:ad:f9:ea:db:c0:d6:cb:47:c4:d1:1f:9c: b1:cb:c2:db:dd:99:f2:33:7c:be:b2:01:5b:11:24: f2:24:a5:29:4d:28:9b:ab:fe:6b:48:3c:c2:53:fa: de:00:ba:57:ae:ae:c6:36:3b:c7:17:5f:ed:20:fe: fd:4c:a4:56:5e:0f:18:5c:a6:84:bb:72:c1:27:46: 96:07:9c:de:d2:e0:06:d5:77:ca:d2:45:8a:50:15: 0c:18:a3:2f:34:30:51:e8:02:3b:8c:ed:d4:95:98: 73:ab:ef:69:57:4d:c9:04:9a:18:82:1e:60:6b:0d:
0d:61:18:94:eb:43:4a:59
prime1:
00:d5:46:7f:49:4b:5e:46:f2:9f:87:e1:9d:0f:6d: 4f:59:42:0d:8b:d6:ef:7f:48:3f:e4:10:b5:5e:dc: ac:75:7d:d1:ee:97:11:f4:bf:c5:76:02:03:dd:5c: 0d:bd:36:18:be:4f:15:2d:0b:e5:7c:08:c7:36:29:
79:80:bc:5b:07
prime2:
00:d2:a0:43:9a:31:cc:0c:fc:1c:19:aa:9b:43:69: 72:99:84:08:1a:56:79:4c:b4:05:03:df:03:7b:2d: ae:13:e0:81:ea:99:92:fd:ef:d9:8a:5b:b5:21:a6: ac:b8:4d:ef:07:35:df:07:f2:54:ec:35:24:57:ef:
89:43:b4:ed:bd
exponent1:
00:bd:ac:e5:d5:1c:87:6b:17:aa:53:a1:8e:1a:43: 3f:f7:84:ec:21:3a:f5:62:c0:b1:b9:b6:36:67:78: 60:94:59:62:d4:0b:5c:f7:cb:79:e4:9a:a4:2f:41: 08:23:07:b2:77:c6:43:71:fd:8b:89:85:11:0e:95:
52:2e:f0:d5:0f
exponent2:
04:1a:a5:56:92:d3:d4:08:f1:8f:3a:78:ce:06:76: fa:30:cd:6b:9d:f5:bd:1d:e0:df:23:70:50:ed:21: f0:37:36:b0:d8:8f:39:ad:7b:c2:ab:68:cb:20:11: 4b:82:11:3f:45:b8:73:d2:2f:ff:6e:45:a8:04:fd:
da:b8:e2:cd
coefficient:
23:10:53:83:cc:aa:43:2d:c3:30:85:b1:5f:19:a8: b9:a4:0c:f9:f5:6e:29:c8:03:04:4b:60:57:2c:41: 10:ed:81:38:ba:af:27:33:dc:f9:35:84:25:73:05: fc:8c:77:cc:f0:aa:9c:0a:99:1e:45:a0:e5:ee:24:
4b:fe:99:58

Les différents éléments de la clé sont affichés en hexadécimal (hormis l’exposant public). On peut distinguer le modulus, l’exposant public (qui par défaut est toujours 655371), l’exposant privé, les nombres premiers facteurs du modulus, plus trois autres nombres qui servent à optimiser l’algorithme de déchiffrement.

3. Chiffrement d’un fichier de clés RSA

Il n’est pas prudent de laisser une paire de clés en clair (surtout la partie privée). Avec la commande rsa, il est possible de chiffrer une paire de clés2. Pour cela trois options sont possibles qui précisent l’algorithme de chiffrement symétrique à utiliser : -des, -des3 et -idea.

$ openssl rsa -in maCle.pem -des3 -out maCle.pem writing RSA key Enter PEM pass phrase: Verifying - Enter PEM pass phrase:

Une phrase de passe est demandée deux fois pour générer une clé symétrique protégeant l’accès à la clé.

4. Export de la partie publique

La partie publique d’une paire de clés RSA est publique, et à ce titre peut être communiquée à n’importe qui. Le fichier maCle.pem contient la partie privée de la clé, et ne peut donc pas être communiqué tel quel (même s’il est chiffré). Avec l’option -pubout on peut exporter la partie publique d’une clé.

$ openssl rsa -in maCle.pem -pubout -out maClePublique.pem

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCveVjLltevTC5kSAiTYjHMVuAR
80DHMLWCp3BOVZ49eXwraXxO7AfKWpA5g0wFZgZNERIfFYaCnvaQDQA+9BRIfsSS
r3oSw0My5SD6eg15v0VmJmvPd8LgBypJHbr6f5MXWqntvzp0Qvg6ddeNpUIrqkkh
4uDfHFDWqyrkQUCvKwIDAQAB
-----END PUBLIC KEY-----

Mais pourquoi ma clé commence toujours par MIGf… ?


# openssl rsa -inform PEM -pubin -in maClePublique.pem -text -noout
Public-Key: (1024 bit)
Modulus:
00:af:79:58:cb:96:d7:af:4c:2e:64:48:08:93:62:
31:cc:56:e0:11:f3:40:c7:30:b5:82:a7:70:4e:55:
9e:3d:79:7c:2b:69:7c:4e:ec:07:ca:5a:90:39:83:
4c:05:66:06:4d:11:12:1f:15:86:82:9e:f6:90:0d:
00:3e:f4:14:48:7e:c4:92:af:7a:12:c3:43:32:e5:
20:fa:7a:0d:79:bf:45:66:26:6b:cf:77:c2:e0:07:
2a:49:1d:ba:fa:7f:93:17:5a:a9:ed:bf:3a:74:42:
f8:3a:75:d7:8d:a5:42:2b:aa:49:21:e2:e0:df:1c:
50:d6:ab:2a:e4:41:40:af:2b
Exponent: 65537 (0x10001)

5. Chiffrement / déchiffrement de données avec RSA

On peut chiffrer des données avec une clé RSA. Pour cela on utilise la commande rsautl

$ openssl rsautl -encrypt -in <fichier_entree> -inkey <cle> \ -out <fichier_sortie

  • fichier_entree est le fichier des données à chiffrer. Attention, le fichier des données à chiffrer ne doit pas avoir une taille excessive (ne doit pas dépasser 116 octets pour une clé de 1024 bits).
  • cle est le fichier contenant la clé RSA. Si ce fichier ne contient que la parte publique de la clé, il faut rajouter l’option -pubin.
  • fichier_sortie est le fichier de données chiffré.

Pour déchiffrer on remplace l’option -encrypt par -decrypt. Le fichier contenant la clé doit évidemment contenir la partie privée.

6. Signature de fichiers

La commande dgst permet de le faire.

$ openssl dgst <hachage> -out <empreinte> <fichier_entree>

hachage est une fonction de hachage. Avec openssl, plusieurs fonctions de hachage sont proposées dont

  • MD5 (option -md5), qui calcule des empreintes de 128 bits,
  • SHA1 (option -sha1), qui calcule des empreintes de 160 bits,
  • RIPEMD160 (option -ripemd160), qui calcule des empreintes de 160 bits.

Dans la vraie vie signer un document revient à chiffrer son empreinte (et non pas à signer son empreinte comme on peut le lire dans le doc original, puisque la signature est une double opération cryptographique hash&encrypt). Pour cela, on utilise l’option -sign de la commande rsautl

$ openssl rsautl -sign -in <empreinte> \ -inkey <cle> \ -out <signature>

et pour vérifier la signature

$ openssl rsautl -verify -in <signature> -pubin \ -inkey <cle> -out <empreinte

Il reste ensuite à vérifier que l’empreinte ainsi produite est la même que celle que l’on peut calculer. L’option -pubin indique que la clé utilisée pour la vérification est la partie publique de la clé utilisée pour la signature.

Pour ceux qui ne veulent pas jouer avec  Java : Command Line Utilities openSSL

Si vous voulez faire des tests en ligne (! confidentialité sur clefs privées), il existe de nombreux outils :
https://8gwifi.org/ – PEM Parseur
https://www.devglan.com/online-tools/rsa-encryption-decryption
https://www.sslshopper.com/ssl-certificate-tools.html


Posted in BoulotCommentaires fermés sur RSA avec openSSL

Data-in-Transit Encryption with MariaDB

Sécuriser les données au repos c’est important, mais sécuriser les flux l’est tout autant.

Donc, après une petite synthèse sur Data-at-Rest Encryption avec Transparent Data Encryption, voyons comment mettre un peu de confidentialité dans le transport.

Un peu de cuisine pour commencer … En ces temps de confinement, cet article servira de support à un TP que nous jouerons avec les LP DLIS de l’IUT de Vannes semaine prochaine.

On va ouvrir un accès sur une base MariaDB exposée sur Internet … ouais, on des fous 🙂

Bon, on va quand même avant toute chose activer les logs sur le fameux SGBD histoire de voir qui attaque sans passer par un proxy. Attention malgré tout car dans les fameux fichiers de logs on retrouve aussi en particulier, les requêtes de création de comptes avec si on n’y prends pas garde le mot de passe en clair (et accessoirement toutes les commandes pourries)  :

logs mariaDB

logs mariaDB

root@vpsxxxxxx:/etc/mysql/mariadb.conf.d# ls /var/log/mysql/mysql.log -lart
-rw-rw—- 1 mysql adm 182 Mar 27 11:56 /var/log/mysql/mysql.log

 

 

Pour faire les choses un petit peu sérieusement, on n’ouvrira qu’une base sur internet avec un seul compte dédié créé pour l’occasion, histoire d’avoir un peu de cloisonnement.

Forcément et heureusement, dans un premier temps ça ne passe pas. Il faut modifier la configuration par défaut qui n’autorise que les connexions depuis le poste local.

can't connect to mariaDB

can’t connect to mariaDB

 

 

 

 

 

 

Et puis, après quelques efforts, la connexion peut enfin être établie…

mysql from everywher for everyone

mysql from everywher for everyone

 

 

 

Faudrait pas croire que votre mot de passe circule en clair (contrairement au trafic suivant l’authentification) .

Il se dit que le mot de passe suivrait  le mécanisme de chiffrement détaillé ici  :

https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase_authentication_methods_native_password_authentication.html

Malheureusement, à cet instant (20200329151524) je n’arrive pas à retrouver dans mon pcap les 20 octets de nonce (on nous ment ?)

Scramble data

Scramble data

 

 

 

 

 

 

 

Bref, quoi, qu’il en soit et au delà de la vérification de l’implémentation de ce mécanisme, revenons au chiffrement du flux …

Etape 1 – Créer le certificat racine de l’autorité de certification (CA)

 

Créons un dossier tls dans le répertoire /etc/mysql/  (parce que ssl c’est tellement vingtième siècle):

$ cd /etc/mysql
$ sudo mkdir tls
$ cd tls

Note: La valeur du Common Name (CN) utilisée pour les certificats serveur MariaDB et le client doivent être différents du Common Name utilisé pour le certificat racine de l’autorité de certification. Pour éviter tour problème, j’ai utilisé les valeurs suivantes :
Common Name de la CA : MariaDB admin
Common Name du serveur : MariaDB server
Common Name du client : MariaDB client

Dans la vraie vie, la CA serait hébergée sur une autre machine.

Génération de la paire de clefs RSA

$ sudo openssl genrsa 2048 > BZHITSCA-key.pem

Génération du certificat de la clef publique ( tip : pour être très précis, on parle donc de certificat DE clef publique)

$ sudo openssl req -new -x509 -nodes -days 365000 -key BZHITSCA-key.pem -out BZHITSCA-cert.pem

On lui donne une validité de 1 000 ans, ce qui nous donnera le temps de jouer.

 

Par abus de langage on associe souvent la commande précédente à une simple génération de clef privée. Mais en fait le fichier .pem produit permet aussi d’exporter la clef publique.

$ sudo openssl rsa -in BZHITSCA-key.pem -pubout -out BZHITSCA-pubkey.pem

Etape 2 – Créer le certificat du serveur MariaDB

Génération de la clef et de la Certificate Signing Request

$ sudo openssl req -newkey rsa:2048 -days 365 -nodes -keyout SERVER-key.pem -out SERVER-req.pem

Le deuxième objet créé est la requête de demande de signature de certificat. Donc, généralement on put dire qu’un certificat c’est un fichier contenant des « informations » relatives à une entité et la clef publique de cette même entité ayant subi une signature numérique par l’autorité de certification (qui certifie donc que la clef publique représente bien l’entité en question). Capito ?

Export de la clef RSA

$ sudo openssl rsa -in SERVER-key.pem -out SERVER-key.pem

Signature du certificat du serveur

$ sudo openssl x509 -req -in SERVER-req.pem -days 365000 -CA BZHITSCA-cert.pem -CAkey BZHITSCA-key.pem -set_serial 01 -out SERVER-cert.pem

Etape 3 – Copier les certificats sur le client

Configuration du client

mkdir /etc/mysql/client-ssl && cd /etc/mysql/client-ssl

# Copy the following files: CLIENT-cert.pem, CLIENT-key.pem and BZHITSCA-cert.pem
scp root@REMOTE_SERVER_IP:~/cert/{client-cert.pem,client-key.pem,ca-cert.pem} ./

chmod -R 700 /etc/mysql/client-ssl

Editer my.cnf pour configuere les chemins vers les certificats:

nano /etc/mysql/my.cnf

et ajouter:

[client]
ssl-ca =   /etc/mysql/client-ssl/ca-cert.pem
ssl-cert = /etc/mysql/client-ssl/client-cert.pem
ssl-key =  /etc/mysql/client-ssl/client-key.pem

Etape 4 – Configurer le seveur MariaDB

Editer  le fichier /etc/mysql/mariadb.conf.d/50-server.cnf ou bien /etc/mysql/mariadb.cnf comme suit:

$ sudo vi /etc/mysql/mariadb.conf.d/50-server.cnf

Ajouter dans le bloc [mysqld]:

### MySQL Server ###
## Securing the Database with ssl option and certificates ##
## There is no control over the protocol level used. ##
##  mariadb will use TLSv1.0 or better.  ##
ssl
ssl-ca=/etc/mysql/ssl/ca-cert.pem
ssl-cert=/etc/mysql/ssl/server-cert.pem
ssl-key=/etc/mysql/ssl/server-key.pem

Savegarder le fichier etredémarrer mariadb :
$ sudo /etc/init.d/mysql restart

Etape 5 – Créer un nouvel utilisateur et se connecter

 

CREATE USER 'secure_user'@'%' IDENTIFIED BY 'my_password';
GRANT ALL PRIVILEGES ON votre_base.* TO securee_user@'%' REQUIRE SSL;
FLUSH PRIVILEGES;

 

Vous pouvez alors en principe vous connecter avec TLS:

mysql -h REMOTE_SERVER_IP -u remote_user -p"my_password"
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 5
Server version: 10.1.26-MariaDB-0+deb9u1 Debian 9.1

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> Bye

 

Pour mémoire (pas mal de liens qui m’ont permis de comprendre) :

https://stackoverflow.com/questions/38167587/how-to-use-wireshark-to-capture-mysql-query-sql-clearly

How to get the network packets between MySQL client and server?


tcpdump -nnei any port 3306 -w tmp.pcap
https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase_authentication_methods_native_password_authentication.html

http://databaseblog.myname.nl/2017/03/network-attacks-on-mysql-part-1.html

https://www.cyberciti.biz/faq/how-to-setup-mariadb-ssl-and-secure-connections-from-clients/

https://www.gab.lc/articles/mysql_with_ssl/

capture wireshark

capture wireshark

Posted in BoulotCommentaires fermés sur Data-in-Transit Encryption with MariaDB

Improve you chinese …

Pour occuper cette période un peu particulière de confinement COVID-19 et alimenter quelques menus TPs, je me lance dans la grande aventure de la tentative de compréhension d’InnoDB.

Si j’avais eu un peu de courage, je me serais remis à Ruby et j’aurais étudié les excellents travaux de Jeremy Cole https://blog.jcole.us/innodb/ mais vu que des chinois sympathiques semblent avoir porté son travail en java , let’s go !!

Jusqu’à la semaine dernière, utilisateur-amateur de MariaDB, je ne m’étais même jamais posé de questions sur les types de backend de mon SGBD. Je faisais juste le malin en allant lire vos tables à partir des fichiers MYD avec un pauvre éditeur hexadécimal.

J’ai donc téléchargé le dernier build du client innodb-java-reader et …

Bon, pour l’instant, on ne va pas se cacher, ça ne se passe pas très bien 🙂

 alibaba / innodb-java-reader

alibaba /
innodb-java-reader

[2020-03-28] Puis après quelques échanges par mail avec Xu, nous avons fini par découvrir un bug lié à ma config (bon c’est sûr quand tu bosse sous windows pasr ce que ta Debian est bridée sur Java 7 …) .

Read your data ...

Read your data …

Je rappelle que l’objectif reste de pouvoir aller lire les fichiers InnoDB sans passer par le moteur MariaDB afin de démontrer la pertinence du chiffrement.

Posted in BoulotCommentaires fermés sur Improve you chinese …