Einleitung
In diesem Dokument wird beschrieben, wie Sie Cipher Block Chaining (CBC)-Modus-Ciphers auf der Cisco E-Mail Security Appliance (ESA) deaktivieren. Eine Sicherheitsüberprüfung/-überprüfung kann melden, dass eine ESA über eine Schwachstelle im Secure Sockets Layer (SSL) v3/Transport Layer Security (TLS) v1 Protocol Weak CBC Mode verfügt.
Achtung: Wenn Sie älteren Code von AsyncOS für Email Security verwenden, wird empfohlen, ein Upgrade auf Version 11.0.3 oder neuer durchzuführen. Die neuesten Versionen und Informationen finden Sie in den Versionshinweisen von Cisco Email Security. Wenn Sie weitere Unterstützung bei Upgrades oder der Deaktivierung von Chiffren benötigen, öffnen Sie ein Support-Ticket.
Voraussetzungen
Anforderungen
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf AsyncOS für E-Mail Security (beliebige Version), einer Cisco ESA und einer virtuellen ESA.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.
Hintergrundinformationen
- Gemäß PCI DSS (Payment Card Industry Data Security Standard) müssen CBC-Chiffren deaktiviert sein.
- Eine Sicherheitsüberprüfung hat eine potenzielle Schwachstelle bei SSL v3/TLS v1-Protokollen identifiziert, die Ciphers im CBC-Modus verwenden.
Tipp: SSL Version 3.0 (RFC-6101) ist ein veraltetes und unsicheres Protokoll. Es gibt eine Schwachstelle in SSLv3 CVE-2014-3566, bekannt als Padding Oracle On Downgraded Legacy Encryption (POODLE) attack, Cisco bug ID CSCur27131. Es wird empfohlen, SSL v3 zu deaktivieren, während Sie die Chiffren ändern, nur TLS verwenden und Option 3 (TLS v1) auszuwählen. Lesen Sie die angegebene Cisco Bug-ID CSCur27131 für vollständige Details.
SSL v3- und TLS v1-Protokolle werden verwendet, um anderen Protokollen wie HTTP und LDAP (Lightweight Directory Access Protocol) Integrität, Authentizität und Datenschutz zu bieten. Diese Services werden mit Verschlüsselung für den Datenschutz, x509-Zertifikaten für die Authentizität und unidirektionalen Verschlüsselungsfunktionen für die Integrität bereitgestellt. Für die Verschlüsselung von Daten können SSL und TLS Blockchiffren verwenden. Dabei handelt es sich um Verschlüsselungsalgorithmen, die nur einen festen Block mit Originaldaten zu einem verschlüsselten Block derselben Größe verschlüsseln können. Beachten Sie, dass diese Chiffren immer den gleichen resultierenden Block für den gleichen ursprünglichen Datenblock erhalten. Um eine Differenz in der Ausgabe zu erzielen, wird die Ausgabe der Verschlüsselung mit einem weiteren Block gleicher Größe, den so genannten Initialisierungsvektoren (IV), XORed durchgeführt. Der CBC verwendet eine IV für den ursprünglichen Block und das Ergebnis des vorherigen Blocks für jeden nachfolgenden Block, um die Differenz in der Ausgabe der Blockchiffrierverschlüsselung zu erhalten.
Bei der Implementierung von SSL v3 und TLS v1 war die Wahl des CBC-Modus schlecht, da sich der gesamte Datenverkehr eine CBC-Sitzung mit einem einzigen Satz von Initial-IVs teilt. Die übrigen IVs sind, wie bereits erwähnt, Ergebnisse der Verschlüsselung der vorhergehenden Blöcke. Die nachfolgenden IVs stehen den Abhörern zur Verfügung. Dies ermöglicht einem Angreifer, beliebigen Datenverkehr in den Nur-Text-Stream einzuschleusen (der vom Client verschlüsselt werden soll), um zu überprüfen, ob er den Nur-Text erraten kann, der dem eingefügten Block vorausgeht. Wenn die Vermutung der Angreifer richtig ist, ist die Ausgabe der Verschlüsselung für zwei Blöcke gleich.
Bei Daten mit niedriger Entropie kann der Klartextblock mit einer relativ geringen Anzahl von Versuchen erraten werden. Bei Daten mit 1000 Möglichkeiten kann die Anzahl der Versuche beispielsweise 500 sein.
Anforderungen
Damit ein Exploit funktioniert, müssen mehrere Anforderungen erfüllt werden:
- Die SSL/TLS-Verbindung muss eine der Blockverschlüsselungschiffren verwenden, die den CBC-Modus verwenden, z. B. DES oder AES. Kanäle, die Datenstromchiffren wie RC4 verwenden, unterliegen nicht dem Fehler. Ein großer Teil der SSL/TLS-Verbindungen verwendet RC4.
- Die Schwachstelle kann nur von jemandem ausgenutzt werden, der Daten über die SSL/TLS-Verbindung abfängt und aktiv neue Daten über diese Verbindung sendet. Durch die Ausnutzung des Fehlers wird die SSL/TLS-Verbindung beendet. Der Angreifer muss die Überwachung fortsetzen und neue Verbindungen nutzen, bis genügend Daten gesammelt werden, um die Nachricht zu entschlüsseln.
- Da die Verbindung jedes Mal beendet wird, muss der SSL/TLS-Client den SSL/TLS-Kanal so lange wiederherstellen können, bis die Nachricht entschlüsselt werden kann.
- Die Anwendung muss dieselben Daten auf jeder erstellten SSL/TLS-Verbindung erneut senden, und der Listener muss diese im Datenstrom finden können. Protokolle wie IMAP/SSL, die über einen festen Satz an anzumeldenden Nachrichten verfügen, erfüllen diese Anforderung. Allgemeine Web-Browsing nicht.
Bedrohung
Die CBC-Schwachstelle ist in TLS v1 enthalten. Diese Schwachstelle besteht seit Anfang 2004 und wurde in späteren Versionen von TLS v1.1 und TLS v1.2 behoben.
Vor AsyncOS 9.6 für E-Mail Security verwendet die ESA TLS v1.0- und CBC-Modusverschlüsselungen. Mit der Veröffentlichung von AsyncOS 9.6 führt die ESA TLS v1.2 ein. Dennoch können CBC-Modus-Verschlüsselungen deaktiviert werden, und es können nur RC4-Verschlüsselungen verwendet werden, die nicht dem Fehler unterliegen.
Wenn SSLv2 aktiviert ist, kann dies außerdem zu Fehlalarmen für diese Schwachstelle führen. Es ist sehr wichtig, dass SSL v2 deaktiviert wird.
Lösung
Achtung: Wenn Sie älteren Code von AsyncOS für Email Security verwenden, wird empfohlen, ein Upgrade auf Version 11.0.3 oder neuer durchzuführen. Die neuesten Versionen und Informationen finden Sie in den Versionshinweisen von Cisco Email Security. Wenn Sie weitere Unterstützung bei Upgrades oder der Deaktivierung von Chiffren benötigen, öffnen Sie ein Support-Ticket.
Deaktivieren Sie die CBC-Modusverschlüsselung, damit nur RC4-Verschlüsselungen aktiviert bleiben. Stellen Sie ein, dass das Gerät nur TLS v1 oder TLS v1/TLS v1.2 verwendet:
- Melden Sie sich bei der CLI an.
- Geben Sie den Befehl sslconfig ein.
- Geben Sie den Befehl GUI ein.
- Wählen Sie Option Nr. 3 für "TLS v1" oder wie in AsyncOS 9.6 "TLS v1/TLS v1.2" aufgeführt aus.
- Geben Sie diesen Schlüssel ein:
MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH:-EDH-RSA-DES-CBC3-SHA:-EDH-DSS-DES-CBC3-SHA:-DES-CBC3-SHA
- Geben Sie den Befehl INBOUND ein.
- Wählen Sie Option Nr. 3 für "TLS v1" oder wie in AsyncOS 9.6 "TLS v1/TLS v1.2" aufgeführt aus.
- Geben Sie diesen Schlüssel ein:
MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH:-EDH-RSA-DES-CBC3-SHA:-EDH-DSS-DES-CBC3-SHA:-DES-CBC3-SHA
- Geben Sie den Befehl OUTBOUND ein.
- Wählen Sie Option Nr. 3 für "TLS v1" oder wie in AsyncOS 9.6 "TLS v1/TLS v1.2" aufgeführt aus.
- Geben Sie diesen Schlüssel ein:
MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH:-EDH-RSA-DES-CBC3-SHA:-EDH-DSS-DES-CBC3-SHA:-DES-CBC3-SHA
- Drücken Sie die Eingabetaste, bis Sie zur Eingabeaufforderung für den Hostnamen zurückkehren.
- Geben Sie den Befehl commit ein.
- Bestätigen Sie die Änderungen.
Die ESA ist jetzt so konfiguriert, dass sie nur TLS v1 oder TLS v1/TLS v1.2 mit RC4-Chiffren unterstützt, während CBC-Filter nicht zulässig sind.
Hier ist die Liste der Chiffren, die verwendet werden, wenn Sie RC4:-SSLv2. Beachten Sie, dass die Liste keine CBC-Modusverschlüsselungen enthält.
ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1
ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1
ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1
EXP-ADH-RC4-MD5 SSLv3 Kx=DH(512) Au=None Enc=RC4(40) Mac=MD5 export
EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
Diese Exploits stellen aufgrund ihrer Komplexität und der Anforderungen an die Exploits nur ein sehr geringes Problem dar. Die Ausführung dieser Schritte ist jedoch ein wichtiger Schutz vor möglichen Exploits und vor der Durchführung strenger Sicherheitsscans.
Zugehörige Informationen