IETF verabschiedet Standard für die Absicherung des verschlüsselten Mail-Transports
15.10.2015 - Die Spezifikation DANE for SMTP hat nur zwei Jahre für ihre Standardisierung benötigt. Das Bundesamt für Sicherheit und Informationstechnik fordert nun bereits von zertifizierten Mail-Providern die Umsetzung des DANE-Verfahrens.
Die Internet Engineering Task Force (IETF) hat die Spezifikation DANE for SMTP in den Status eines Standards erhoben. Mit dem RFC 7672 schafft die Organisation eine Grundlage, die mittels TLS verschlüsselte Datenübertragung zwischen Mail-Servern effektiv gegen Zertifikatsmanipulationen abzusichern. Hersteller, die sich noch zurückgehalten hatten, diese Sicherheitstechnik zu implementieren, können ihren Kunden nun mit DANE mehr Sicherheit bieten und administrative Kosten bei der Umsetzung von Sicherheitsrichtlinien senken.
Mehr Sicherheit bei weniger Aufwand
Die auch DANE/TLSA genannte Sicherheitsmethode erspart das aufwendige und fehleranfällige manuelle Certificate Fingerprint Pinning. Darunter fassen Mail-Provider Richtlinien zusammen, die auf Senderseite vor Man-in-the-Middle Attacken und vor Session-Downgrades schützen sollen. Weltweit gibt es jedoch eine fast schon unüberschaubar große Zahl an Mail-Providern und es ist ökonomisch schlicht nicht möglich, Richtlinien für alle manuell anzulegen und zu pflegen, sodass derartige Absicherungen selten sind. Ändern sich die Kommunikationsparameter unbemerkt, zum Beispiel durch den Austausch eines abgelaufenen Zertifikats, verbietet die Richtlinie auf Seiten des SMTP-Senders die Verbindungsaufnahme, der Mail-Versand scheitert – und der Administrator muss sich auf die Fehlersuche und Reparatur begeben.
Mit DANE for SMTP gehören solche Probleme der Vergangenheit an. Die Empfängerseite gibt über einen DNSSEC-gesicherten Kanal bekannt, dass sie TLS anbietet und mit welchen Fingerprint das Zertifikat des Zielservers identifiziert werden kann. Damit entfällt das instabile manuelle Certificate Fingerprint Pinning auf Senderseite. Verbindliche Senderichtlinien werden stabiler und sind letztlich wesentlich günstiger zu administrieren. Damit wird der TLS-abgesicherte Mail-Transport selbst für kleine Unternehmen oder Privatnutzer mit DNSSEC- und DANE-Know-how vorstellbar.
Nur zwei Jahre bis zum Standard
Das RFC 7672 durchlief in gerade mal zwei Jahren die Gremien der IETF. Damit ist es vergleichsweise schnell standardisiert worden. Wesentlichen Anteil daran hatten einige deutsche ISPs und Mail-Anbieter, die DANE bereits früh vollständig auf ihren Plattformen implementierten – also auf Sender- und Empfängerseite. Der Kabelnetzbetreiber Unitymedia hat bereits im März 2014 begonnen, DANE zu implementieren. Als erster Mail-Provider hatte Posteo.de die Technik im Mai 2014 eingeführt.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) fordert im aktuellen Entwurf der technischen Richtlinie "Sicherer E-Mail-Transport" (BSI TR-03108) von E-Mail-Diensteanbietern, die einen sicheren Transport von E-Mails bewerben, die Umsetzung der DANE-Technik. Spätestens mit der Rezertifizierung sollen Anbieter DANE anbieten und nutzen.
Wie sich DNSSEC und DANE implementieren lassen, hat heise Netze in diversen Artikeln für verschiedene Plattformen beschrieben. Mehr dazu finden Sie auf unseren Themenseiten:
• DNSSEC: Eine Erweiterung des Domain Name System, die DNS-Daten kryptografisch gegen Fälschungen absichert und die Quelle der DNS-Daten authentisiert
• DANE: Eine Protokollfamilie, die die DNSSEC-Infrastruktur zur Authentisierung verwendet.
Quelle: Heise.de
Let's Encrypt: Meilenstein zu kostenlosen SSL-Zertifikaten für alle
5.6.2015 - Die alternative SSL-Zertifizierungstelle Let's Encrypt hat nun SSL-Schlüssel für ihre Root- und Zwischen-Zertifikate erzeugt. Das unter anderem von Mozilla und der EFF gestartete Projekt soll ab Sommer 2015 kostenlose SSL-Serverzertifikate verteilen.
Die von Mozilla, der EFF und anderen Organisationen Ende vergangenen Jahres ins Leben gerufene SSL-Zertifizierungsstelle Let's Encrypt hat die für die Ausstellung von Serverzertifikaten nötigen Schlüsselpaare für Root-und Zwischenzertifikate erzeugt. Das verkündete Josh Aas, Executive Director bei der Internet Security Research Group (ISRG), im Blog des Projekts.
Let's Encrypt will SSL/TLS-Zertifikate kostenlos für alle Server-Betreiber bereitstellen, die den Abruf ihrer Webseiten verschlüsseln wollen. Dafür sollen zwei Linux-Befehle reichen – man fordert damit ein signiertes Server-Zertifikat an und schaltet es umgehend live.
Die Server-Zertifikate werde Let’s Encrypt über zwei Zwischen-CAs unterschreiben, erklärt Aas. Die Root-Certificate-Authority soll offline bleiben. Damit alle gängigen Browser und Betriebssysteme diese Zwischen-Zertifikate akzeptieren, werden sie zusätzlich von der Zertifizierungsstelle IdenTrust unterschrieben (cross-sign). Die von Banken ins Leben gerufene IdenTrust unterstützt Let's Encrypt als Sponsor.
Im Normalfall werden die Server-Zertifikate von der Zwischen-CA "Let’s Encrypt Intermediate X1" unterschrieben, erklärt Aas das Verfahren. Die zweite Zwischen-CA namens "Let’s Encrypt Intermediate X2" werde nur dann eingesetzt, wenn Let's Encrypt nicht mehr mittels "Let’s Encrypt Intermediate X1" unterschreiben könne – etwa bei Fehlersituationen.
Die privaten Root-CA-Schlüssel der ISRG sowie der beiden Zwischen-CAs lagern in Hardware Security Modules (HSMs), die ein hohes Maß an Diebstahlschutz für die Schlüssel versprechen, erklärt Josh Aas weiter. Alle ISRG-Schlüssel seien derzeit RSA-Schlüssel. Im Laufe des Jahres wolle man aber CA-Schlüssel per ECDSA-Algorithmus erzeugen. Weitere Schritte auf dem Weg zur einer funktionierenden Zertifizierungsstelle will Lets Encrypt in wenigen Wochen bekannt geben.
Quelle: Heise.de
Venom - Sicherheitslücke soll weltweit Rechenzentren gefährden
15.5.2015 - Eine Sicherheitslücke im Diskettentreiber von QEMU gefährdet derzeit weltweit Rechenzentren.
Die unter dem Namen "VENOM" bekannte Lücke erlaubt es Angreifern, aus virtuellen Maschinen auszubrechen. Die Lücke steckt in einer alten Komponente, dem Diskettentreiber von QEMU.
Der Fehler ist in der National Vulnerability Database (NVD) unter der Nummer CVE-2015-3456 geführt und betrifft folgende Lösungen:
- Alle auf XEN Hypervisor basierten Lösungen (Oracle VM, Citrix XEN,...)
- Alle auf KVM basierenden Lösungen (RedHat, Oracle Enterprise Linux, ...)
VMware und Microsoft Hyper-V sollen nicht betroffen sein, da Sie nicht auf dem Treiber von QEMU aufsetzen.
Wie können Sie sich schützen?
Man muss in allen VMs die Floppy Definitionen löschen (leider sind die meist default mäßig vorgesehen) und die VM neu starten. Dass bietet zwar keinen 100%igen Schutz, dürfe aber die Ausnutzung der Lücke dramatisch verkomplizieren.
Patches der Hersteller
RedHat hat schon mit einem Patch für QEMU für KVM reagiert (siehe Quellen weiter unten).
Für XEN gibt es ebenfalls schon einen Patch, der allerdings erst von den Anbietern wie Oracle, Citrix,... implementiert werden muss.
Quellen
- Cert: CVE-2015-3456.
- RedHat: QEMU-KVM Security Update
- XEN.org: CVE Advisory.
- QEMU Projekt: git.qemu.org.
- Oracle Community: Oracle VM - nur HVM dürften betroffen sein.
Weltumspannendes BotNetz Simda wurde stillgelegt
14. April 2015 - Verschiedene Strafverfolgungsbehörden und private Sicherheitsfirmen haben das Botnetz Simda stillgelegt.
Zuletzt sollen 770.000 Computer zum Botnetz gehört haben. Infizierte Rechner wurden an Kriminelle verkauft. Dabei habe das Botnetz aus 190 Ländern operiert; mit 22 Prozent führte die USA die Liste der Länder mit infizierten Computern an. Das berichtet der Anbieter von Sicherheitssoftware Kaspersky Lab.
Für die Abschaltung des Botnetzes Ende vergangener Woche zeichnen mehrere Parteien verantwortlich. Darunter befinden sich etwa Firmen wie Microsoft, Kaspersky Lab und Trend Micro, aber auch das FBI war mit von der Partie. Die Operation fand zeitgleich über mehrere Ländern verteilt statt und Behörden beschlagnahmten dabei 14 Command-und-Control-Server des Botnetzes.
Die meisten Computer wurden auf der Basis von Sicherheitslücken in Java, Flash und Silverlight infiziert, die Benutzer mit Phishing-Mails geködert und so der Schadcode installiert.
Dieser Schadcode modifizierte die Hosts-Datei von Windows und leitete Besucher von Webseiten heimlich auf Server des Botnetzwerkes um. Von dort konnte dann weiterer Schadcode auf die Rechner geschleust werden. In vielen Fällen sollen die Veränderungen in der Hosts-Datei auch nach dem Entfernen der Backdoor bestehen bleiben. Wer die Hosts-Datei prüfen will, findet diese in der Regel unter %SYSTEMROOT%\system32\drivers\etc\hosts.
Kaspersky Lab bietet einen Test an, mit der die Infektion überprüft werden kann.
Quelle: Heise
RC4 Verschlüsselung ist schwächer als gedacht
7. April 2015 Wie Imperva aktuell ausführt, ist die RC4 Verschlüsselung noch schwächer als gedacht.
Daß RC4 nicht wirklich sicher ist, wissen wir schon seit 2002 - da wurde eine Vulnerability für RC4 bekannt. Trotzdem werden aktuell noch 30% aller verschlüsselten Verbindungen mit RC4 durchgeführt.
In der Abhandlung "Hii - Attacking SSL when using RC4" erklären die Securityspezialisten von Imperva genau, warum und wann RC4 besonders anfällig ist. Wenn man RC4 mit einem 8 Byte (64Bit) Key nutzt, dann gibt es nur 2 hoch 16 möglich Werte um den Key zu erraten. Das sind lächerliche 65536 Versuche - mit aktuellen CPUs geht das praktisch in ECHTZEIT.
Mit längeren Keys wird es zwar tendentiell besser, aber die etwas über 8 Millionen Werte, wenn der Key aus einem vielfachen von 4 Bytes besteht, kann man mit Hilfe von Lookuptabellen (Rainbow Tables) innerhalb von wenigen Sekunden knacken.
Wenn man viele dieser RC4 Verbindungsaufbauten "mitschneiden" kann und man annimmt, dass für den RC4 Key eines der TOP 10.000 Passwörter genutzt wird, kann man durchschnittlich mit 18 Versuchen (maximal mit 201 Versuchen) den Key mittels eines Brute Force Angriffs ermitteln! Laut den Spezialiisten von Imperva sind damit rund 30% aller RC4 Verschlüsselungen gehackt!
Zusammenfassung:
Wenn Sie RC4 noch einsetzen (müssen) ändern Sie die Key Passwörter auf einen zufälligen, möglichst langen String und setzen Sie alles daran RC4 in Zukunft nicht mehr zu nutzen.
Flash Update mit 18 Lücken
5.2.2015 Nach mehreren schon ausgenutzten Zero-Day Lücken im Flash gibt es jetzt einmal wieder einen Patch
Es hat jetzt zwei Wochen gedauert, bis Adobe die Zero-Day Lücke, die seit dem 21. Jan bekannt war, geschlossen hat. Die Lücke wurde von Kriminellen offensichtlich auch schon vor dem offiziellen Bekanntwerden genutzt. Das Schlimme an den häufigen Lücken in Flash bzw. den Browsern ist, dass man sich damit Rechner im Firmennetzwerk komprimitiert. Wenn das passiert, können Hacker aus dem Firmennetz auf die sensiblen Daten zugreifen.
Weitere Informationen finden Sie auch bei Heise.