Die Geschichte eines "kaputten" Testfalls oder seien Sie vorsichtig mit den OpenSSL-Versionen ...

Haftungsausschluss. Ich bin kein "echter Schweißer", aber aufgrund der Suche nach interessanten Arbeiten im Bereich der Informationssicherheit habe ich in letzter Zeit regelmäßig verschiedene CTFs und Maschinen auf HackTheBox gelöst. Als ich einen Link zu einem der Testobjekte im CTF-Stil erhielt, konnte ich daher nicht vorbeikommen ...







Die Bedeutung des Testobjekts ist recht einfach. Es wird ein Verkehrsdump angegeben, der einen Verschlüsselungsschlüssel, etwas Müll und ein verschlüsseltes Flag enthält. Wir müssen sie extrahieren und die Flagge entschlüsseln. Außerdem wird der OpenSSL-Befehl angezeigt, mit dem dieses Flag verschlüsselt wurde. Der Verkehr ist ziemlich interessant, aber nach 10 Zeilen Python-Code hatte ich einen Verschlüsselungsschlüssel, Müll und eine verschlüsselte Flagge vor mir. Es scheint, was könnte schief gehen?



Die Zuweisung besagt, dass das Flag mit ungefähr dem folgenden Befehl verschlüsselt wurde (ich habe einige unbedeutende Parameter weggelassen und den Verschlüsselungsalgorithmus geändert).



echo "FLAG_xxxx…xxxxxx" | openssl enc -e -base64 -aes-256-cbc -nosalt -k $password 
      
      





Ich habe die aus dem Verkehr erhaltenen Parameter in den Befehl eingefügt, ihn gestartet und ... Müll bekommen! Ich habe es erneut versucht. Wieder Müll. Ich habe versucht, den Verkehr auf verschiedene Weise wieder aufzubauen. Nein, anscheinend kann der Verkehr nur eindeutig erfasst werden. Aber die Verschlüsselungsausgabe ist wieder Müll !!! Gleichzeitig warnt OpenSSL ehrlich, dass es eine schlechte Idee ist, in einem Durchgang einen Schlüssel von einem Passwort zu erhalten ...



echo "ENCRYPTED_FLAG" | openssl enc -d -base64 -aes-256-cbc -nosalt -k $key 
*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.
      
      





Am nächsten Tag wurde versucht, diesen Wahnsinn zu knacken. Ich habe vernünftigerweise begründet, dass ich anscheinend den in den Bedingungen angegebenen "Müll" falsch isoliert und mehrere Optionen für die Aufteilung der resultierenden Zeichenfolge in "Passwort" und "verschlüsseltes Flag" für nachfolgende "Brute Force" geschrieben habe. Es hat nicht geholfen ... Ich begann jeden der Parameter tief zu verstehen.



Wie wir wissen, benötigt AES einen Verschlüsselungsschlüssel und IV (Initialisierungsvektor), um zu funktionieren. Mit der Option -k können wir eine Textphrase verwenden, von der OpenSSL selbst den erforderlichen Schlüssel und IV erhält. Sie können sie mit dem Parameter -p anzeigen.



echo "FLAG_123" | openssl enc -e -base64 -aes-256-cbc -nosalt -p -k "password"
*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.
key=5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8
iv =3B02902846FFD32E92FF168B3F5D16B0
C11kA+GcqkU4ocOvZAVr3g==
      
      





Dieses Wissen gab mir auch nichts. Dann beschloss ich trotzdem, zu der verrücktesten Idee zurückzukehren, die mir einfiel. Nämlich: Das Problem liegt nicht bei mir, aber in OpenSSL hat sich etwas geändert ... Der

Datenverkehr war auf 2016 datiert, also habe ich Ubuntu 14.04 genommen und ohne große Hoffnung auf Erfolg einfach die ersten Daten eingefügt. Und plötzlich bekam ich anstelle von Müll eine FLAGGE! Der Abend hörte auf, träge zu sein ... Außerdem erzeugte derselbe Befehl mit demselben Passwort und dem Parameter -p völlig unterschiedliche Verschlüsselungsschlüssel und IV!



NEUES SYSTEM (openssl 1.1.1h)



echo "FLAG_123" | openssl enc -e -base64 -aes-256-cbc -nosalt -p -k "password"
*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.
key=5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8
iv =3B02902846FFD32E92FF168B3F5D16B0
C11kA+GcqkU4ocOvZAVr3g==

      
      





ALTES SYSTEM (openssl 1.0.1f)



echo "FLAG_123" | openssl enc -e -base64 -aes-256-cbc -nosalt -p -k "password"
key=5F4DCC3B5AA765D61D8327DEB882CF992B95990A9151374ABD8FF8C5A7A0FE08
iv =B7B4372CDFBCB3D16A2631B59B509E94
R3N+5v3zOz9QcNt08cwqcA==
      
      





Es wurde klar, dass die Befürchtungen bestätigt wurden. Der Algorithmus zum Generieren von Schlüssel und IV aus einer Passphrase hat sich geändert, wodurch die Fähigkeit, CTF frontal in modernen Versionen von OpenSSL zu lösen, vollständig beeinträchtigt wurde. Bei der Suche nach den Nuancen der Implementierung stieß ich auf eine sehr interessante Arbeit " Passwortbasierte OpenSSL-Verschlüsselungsanalyse des Schlüsselableitungsprotokolls ", und alles passte zusammen. Kurz gesagt, Version 1.1.0 hat ein neues Protokoll zum Generieren von Schlüsseln aus einem Kennwort PBKDF2 hinzugefügt. Noch wichtiger ist jedoch, dass der alte PBKDF1-Algorithmus den Standard-Hashing-Algorithmus von MD5 auf SHA-256 geändert hat! Somit erzeugt dasselbe Passwort unterschiedliche Schlüssel und IV. Um zuvor verschlüsselte Daten zu entschlüsseln, müssen Sie in neueren Versionen den Parameter -md md5 verwenden .



"-Md messagedigest: Geben Sie den Nachrichtenauszug an, der für die Schlüsselableitung von md2, md5, sha oder sha1 verwendet wird. "



Nach dem Hinzufügen dieses Parameters wurde es möglich, das Flag auf der neuen OpenSSL zu erhalten. Ich weiß nicht, ob eine solche "Nuance" von den Entwicklern der Testaufgabe wirklich berücksichtigt wurde oder sie sie einfach nicht auf modernen Systemen getestet haben, aber die Tatsache bleibt, dass ich mich eingehend mit einigen Feinheiten von OpenSSL befassen musste.



PS Durch meine Bekanntschaften habe ich die Entwickler des Testtests bereits über das gefundene Problem informiert, sonst sind sie plötzlich sehr überrascht, dass diese Leute nicht zu ihnen gehen ...



All Articles