Die kuriose Let’s Encrypt Zertifikatsvernichtung

Ihr habt sicher von der Let’s Encrypt Aktion  gehört, bei der am Mittwoch 4 Millionen Zertifikate für ungültig erklärt werden sollten und nun tatsächlich nur noch 1.3 Millionen entwertet wurden.  Was Ihr nicht gehört habt ist der Umstand, daß die Zahlen komplett überzogen sind und die Begründung auch nicht für alle stimmt.

1.3 Millionen Zertifikate für ungültig erklärt.

Am 3.3. kam folgende Email bei uns an:

ACTION REQUIRED: Renew these Let’s Encrypt certificates by March 4

We recently discovered a bug in the Let’s Encrypt certificate authority code, described here:

https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591

Unfortunately, this means we need to revoke the certificates that were affected by this bug, which includes one or more of your certificates. To avoid
disruption, you’ll need to renew and replace your affected certificate(s) by Wednesday, March 4, 2020. We sincerely apologize for the issue.

… Erklärung was man tun  muß …

Your affected certificate(s), listed by serial number and domain names:

03ecb7303d580891307fd3a47b380d312f4f: einedomain.de www.einedomain.de
030957775b69a991e4dd80c6d598aad621d1: eineanderedomain.de www.eineanderedomain.de
03454b86a0b34e3fced270c8cf31eff99e9c: einedomain.de www.einedomain.de
0380ffb6959d746e0dac1cc397d696e20997: eineanderedomain.de www.eineanderedomain.de
0444954637f2defb07cb113a612ec46b19a9: einedomain.de www.einedomain.de
03bb883d4c37e1a71afdff2d379ffcf3e023: eineanderedomain.de www.eineanderedomain.de
03143a5f2efaba0dc3083ac61b160cd0d9f6: einedomain.de www.einedomain.de
044967b81422a9cb42a24d4c3349a3809106: eineanderedomain.de www.eineanderedomain.de
03ea3701bebb2679bcb5dd9f49308a90ad6e: einedomain.de www.einedomain.de
034d72dd79494e8d34843c3e0dcd99dc0229: eineanderedomain.de www.eineanderedomain.de
032fd14c38423850ea037b09b4868c1d92ff: einedomain.de www.einedomain.de
03dd1bf96a9a77edcde65dd49dcb65c77619: eineanderedomain.de www.eineanderedomain.de
03e2c85073fcf4e4a807e4fe7674a4e8342e: eineanderedomain.de www.eineanderedomain.de
03c802547e5f9b20704cf3385f5d64e4cab4: einedomain.de www.einedomain.de
03a75558e1bef0c4a68d8d437758d0c36743: eineanderedomain.de www.eineanderedomain.de
049ce54f1a025d3581408b7e1f39c82bf761: einedomain.de www.einedomain.de
0389bef9a312c1cf568d9af54f7e20003a37: eineanderedomain.de www.eineanderedomain.de
04a7b495e56693c4847a259f68c1cb3dca0d: einedomain.de www.einedomain.de
03671ac363d115d81991fb78b4efa00b72b8: eineanderedomain.de www.eineanderedomain.de
04dda4b6e006f8fb5c17b8e98ec60cc5c487: einedomain.de www.einedomain.de
04f7293f6e2f18d11f0e7f4ac1b03f32ac66: eineanderedomain.de www.eineanderedomain.de
033f28ecf7cdfdf9094fef13e295a2fb6702: eineanderedomain.de www.eineanderedomain.de
035af3d7a2209dcd5a6eee2ebfb0b774ab9f: pma.{einedrittedomain.de} {einedrittedomain.de} webmail.{einedrittedomain.de} www.{einedrittedomain.de}

Wie man sehen kann, sind das Zerts für eine winzige Anzahl an Domainnamen, die ALLE SAMT schon vor Jahren ausgestellt wurden und schon lange ersetzt und ungültig sind. Ich habe keine Ahnung was Let’s Encrypt da genau gemacht hat, aber es ist defakto Blödsinn gewesen. Offensichtlich hat da niemand die Ablaufdaten geprüft, sonst wäre das nicht passiert. Ganz unbekannt ist das Problem bei Let’s Encrypt nicht:

Q: I received the email telling me I should renew my certificate, however, the online testing tool isn’t indicating my cert needs replacing.
A: Even if you received an email, it’s possible that the affected certificates have been replaced by newer certs not affected by the bug. (Either due to being issued in the last few days since it was fixed, or simply by not meeting the specific timing criteria necessary for the bug to trigger.) In that case, it’s not necessary to renew them again. You can use the checking tool at https://checkhost.unboundtest.com/ to verify if the certificate you’re currently using needs renewal, or verify that the serial number of the cert you’re currently using is present in the list of affected certs at https://letsencrypt.org/caaproblem/.

Da uns Certs teilweilse vom Start des Testbetriebs von LE angegeben wurden, kann man annehmen, daß die Uhren in Amiland anders ticken 🙂 Certs werden 20 Tage vor Ablauf automatisch erneuert, so daß man bei der Menge oben leicht ausrechnen kann, wie alt die sein müßten 😉

CAA & DNS

Kommen wir zu nächsten Ungereihmheit bei der Sache, der CAA Validierung. Wie man in dem Artikel „https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591“ nachlesen, daß die ganze Aktion ausgelöst wurde, bei bei CAA Einträgen falsch geprüft wurde. Dafür müßten aber folgende Bedingungen erfüllt sein:

CAA verwenden

Wenn Sie sich nicht für CAA interessieren, müssen Sie im Allgemeinen nichts tun (siehe jedoch unten die CAA-Fehler). Wenn Sie mithilfe von CAA einschränken möchten, welche Zertifizierungsstellen Zertifikate für Ihre Domain ausstellen dürfen, müssen Sie einen DNS-Anbieter verwenden, der die Einstellung von CAA-Einträgen unterstützt. Suchen Sie in der SSLAate CAA-Seite nach einer Liste solcher Anbieter. Wenn Ihr Provider aufgeführt ist, können Sie mit dem SSLMate CAA Record Generator eine Gruppe von CAA-Datensätzen generieren, in denen die CAs aufgelistet sind, die Sie zulassen möchten.

Wir haben aber gar keine CAA Einträge bei unserer Validierung benutzt 😉 Natürlich kann man da immernoch eine DNS Abfrage pro Zertvalidierung machen, aber rauskommt dann halt nichts. Ich vermute mal, daß genau der Fall „nichts“ aka. „Kein Ergebnis“ das eigentliche Problem war.

So oder so wundert es mich nicht, daß die Zahl von 4 Millionen auf 1.3 geschrumpt ist. Ich vermute, die geht eher in die zehntausende, als in die Millionen, wenn man die Fehlerquota bei uns als Maßstab ansetzt. Die Liste oben ist nur ein Auszug der Email, da waren noch viel mehr falsche Ergebnisse drin, als Ihr jetzt erahnen könnt 😉

(An.d.r.Ä. ein „nicht“ im ersten Absatz eingefügt.)

Let’s Encrypt gibt milliardstes Zertifikat aus \o/

Am 27.2. wurde die eine Milliarde SSL Zertifikate von Let’sEncrypt überschritten. Bei 46 Millionen Webseiten für die Zertifikate ausgestellt wurden, war das ja auch nur eine Frage der Zeit, wenn man 4 Zerts pro Jahr pro Domain durchbringen muß 🙂

Herzlichen Glückwunsch – Let’s Encrypt 😀

„We issued our billionth certificate on February 27, 2020. We’re going to use this big round number as an opportunity to reflect on what has changed for us, and for the Internet, leading up to this event. In particular, we want to talk about what has happened since the last time we talked about a big round number of certificates – one hundred million. One thing that’s different now is that the Web is much more encrypted than it was. In June of 2017 approximately 58% of page loads used HTTPS globally, 64% in the United States. Today 81% of page loads use HTTPS globally, and we’re at 91% in the United States! This is an incredible achievement. That’s a lot more privacy and security for everybody. Another thing that’s different is that our organization has grown a bit, but not by much! In June of 2017 we were serving approximately 46M websites, and we did so with 11 full time staff and an annual budget of $2.61M. Today we serve nearly 192M websites with 13 full time staff and an annual budget of approximately $3.35M. This means we’re serving more than 4x the websites with only two additional staff and a 28% increase in budget. The additional staff and budget did more than just improve our ability to scale though – we’ve made improvements across the board to provide even more secure and reliable service.“

Das selbstgesteckte Ziel haben Sie jedenfalls erreicht, das ist mal sicher. Ob das Netz wirklich sicherer geworden ist, ist eine andere Frage 😀

Security: Angriff auf WPA2 möglich, wenn Broadcom&Cypress Chips im Spiel sind

Eine Meldung der Hacker News erfreut die Gemütslage von allen Admins weltweit: WPA2 + Broadcomships sind eine schlechte Kombination 🙁

Angriff auf WPA2 möglich, wenn Broadcom & Cypress Chips im Spiel sind

Die mit CVE-2019-15126 registrierte Schwachstelle mit dem Namen „Kr00k“ erlaubt es in Kombination mit dafür anfälligen Chips von Broadcom &  Crypress, die WLAN Verschlüsselung teilweise zu verhindern.

Das funktioiert so, daß ein Angreifer ohne überhaupt im Funktnetz zu sein, ständig Disassoziationen auszulöst, indem er Deauthentifizierungspakete an alle sendet. Das führt dazu, daß sich die Chips aus dem WLAN lösen und den WLAN Schlüssel intern auf NULL setzen. So weit wärs noch ok, aber nun senden anfällig Broadcom und Crypress Chips die Restpufferinhalt im Chipspeicher ohne die Verschlüsselung ans Ziel. Streng genommen verschlüsseln die die Daten mit 000000000000000000, was dann keine Verschlüsselung mehr ist. Ist also ein Bug in der Chipfirmware, weil die müßte den Puffer auch leeren, statt den Inhalt denn zu senden.

„Unsere Tests bestätigten, dass einige Client-Geräte von Amazon (Echo, Kindle), Apple (iPhone, iPad, MacBook), Google (Nexus), Samsung (Galaxy), Raspberry (Pi 3), Xiaomi (RedMi) sowie einige Zugangspunkte von Asus und Huawei für Kr00k anfällig sind“, so die ESET-Forscher.“ schreiben die Hacker News.

Diese Lücke hackt also nicht Eurer WLAN Passwort, weswegen ein Wechsel des Passworts nichts bringt. Da Broadcom Chips in allen möglichen Geräten zu finden sind und damit in allem was IoT, Accesspoints, alte Handies etc. ist ungepatcht laufen, wird das ein schöner Mitschmatsch werden.

Wie könnt Ihr euch schützen?

Das schlimmste was mit dem Angriff passiert ist, daß einige eurer Pakete im WLAN so übertragen werden, als wenn es ein OFFENES-WLAN wäre. Damit sind alle die Datenübertragungen betroffen, die Klartextverbindungen beinhalten, z.b. HTTP:// Traffic, FTP, SMTP, POP, IMAP, DNS und jede Menge IoT Geraffel. Wer seine Dienste alle mit TLS Verbindungen wie HTTPS, FTPS, SFTP, SCP, SSH, STARTTLS für SMTP, POP und IMAP schützt, muß sich keine Sorgen machen. Aber wer zu Hause intern von einem PC per Samba auf einen anderen PC zugreift, dessen Daten könnten damit abgelauscht werden.

Ein gezielter Angriff auf bestimmte Daten ist mit dem Angriff nicht möglich, der Angreifer weiß also nie was er da so bekommt, aber je mehr er mitschneidet, desto schlechter für Euch.

Wie bekomme ich raus, daß ich betroffen bin?

Für Eurer Linux braucht Ihr erstmal eine Version von „lshw„, also für Fedorabenutzer eingeben: „sudo dnf install -y lshw

Ihr werdet Rootrechte brauchen, also „sudo su“ eingeben. Mit „ip l“ bekommt Ihr Eure Interfacenamen heraus, „ifconfig“ würde es auch tun:

# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether f0:76:1c:be:39:c8 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
link/ether 34:e6:ad:5d:18:ee brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:e7:5f:07 brd ff:ff:ff:ff:ff:ff

Wir brauchen das wlp3s0 WIFI Interface. Jetzt gebt Ihr „lshw | less“ ein und bekommt eine lange Liste mit Info zu Eurer Hardware. Den Befehl solltet Ihr Euch also merken, den braucht man häufiger mal. In der Ausgabe sucht Ihr nach Eurem Interfacenamen und stoßt so auf solch einen Block:

*-network
description: Wireless interface
product: Wireless 3160
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:03:00.0
logical name: wlp3s0
version: 83
serial: 34:e6:ad:5d:18:ee
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=iwlwifi driverversion=5.2.18-100.fc29.x86_64 firmware=17.3216344376.0 ip=192.168.0.103 latency=0 link=yes multicast=yes wireless=IEEE 802.11
resources: irq:54 memory:c4000000-c4001fff

Entweder verrät es euch jetzt schon die Herstellerbezeichnung, hier Intel Corporation, oder der Drivername (hier iwlwifi) gibt den Chiphersteller preis. Wenn da BC drin vorkommt, war es ein Broadcom. Den Code für Crypress Chips kenne ich jetzt leider nicht auswendig, aber das findet Ihr vermutlich im Netz auf Linux-Wifi-Infoseiten.

Wie gehts weiter?

Apple soll wohl bereits Patches für seine Benutzer veröffentlicht haben. Wann die anderen patchbaren Systeme hinterher ziehen, bleibt offen. Für alles was IoT, oder mehr als 2 Jahre alte Accesspoints, Handies etc. kommt wohl jede Hilfe zu spät, da hilft nur entsorgen. Vorher würde ich aber einen Blick auf die Webseite meines Herstellers werfen, vielleicht gabs ja doch ein Gnadenupdate.

Quelle: https://thehackernews.com/2020/02/kr00k-wifi-encryption-flaw.html