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.
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.
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
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.