Monthly Archives: März 2020

Neue Platte automatisch entschlüsseln lassen

Posted on by

Ich hab eine neue Platte im PC und die soll sich natürlich beim Hochfahren automatisch ins System integrieren, wenn ich das Passwort kenne. Leider klappt das mit den Automatiken nicht so ganz, daher müssen wir da kurz Hand anlegen.

Automatisch LUKS-Platten beim Boot einbinden

Zunächst brauchen wir mal eine mit LUKS verschlüsselte Platte. Um eine Platte mit LUKS zu verschlüsseln eignet sich das Laufwerketool. Die zu formatierende Partition auswählen und auf „Partition formatieren“ klicken:

man sieht die erste Formatierungsseite im LaufwerketoolIhr geht den neuen Namen für die Platte an, damit meldet die sich dann später im System, und wählt „Passwortgeschützter Datenträger (LUKS)“  aus. Ggf. habt Ihr die Wahl zwischen LUKS und LUKS2, aber F30 hat die noch nicht. Wenn ja, nehmt ruhig LUKS2.

Man sieht, wie das Passwort eingegeben wird.Ein ordentlich langes Passwort ist Pflicht. Danach dürft Ihr das noch einmal bestätigen und ein paar Sekunden später die Platte mit Hilfe des Lazy-Inits bereits bereit. „Lazy-Init“ meint, daß die Platte dort formatiert wird, wo Daten geschrieben werden sollen und nicht jetzt gleich die ganze Platte von Vorn bis Hinten formatiert wird. Das hätte nämlich bei 8TB 23 Stunden gedauert, da hatte ich wirklich keine Lust zu 😉

Die UUID ermitteln

Zwei Möglichkeiten eröffnen sich Euch: Ihr fragt das Laufwerkstool nach der UUID der neuen Platte ( Luks-Teil ) oder Ihr bemüht „blkid“ in der Konsole. Da wir diese eh gleich brauchen, bietet sich das an:

Erstmal ROOT werden:

$ su

dann suchen wir uns die UUID raus:

# blkid|grep sdd
/dev/sdd: UUID=“c16596bf-b40d-4c57-a46d-93b98d4bac47“ TYPE=“crypto_LUKS“

„sdd“ ist hier meine Platte. Eine UUID ist eine einmalige ID ( daher das zweite U ) die aufgrund eines einheitlichen Verfahrens ( das erste U ) erzeugt wird. Mehr müßt ihr darüber eigentlich nicht wissen.

Nun nehmen wir die UUID und tragen das passend in /etc/crypttab und /etc/fstab ein:

$ echo „/dev/mapper/luks-c16596bf-b40d-4c57-a46d-93b98d4bac47 /media/Huge ext4 defaults,x-systemd.device-timeout=0 1 2″ >>/etc/fstab

Da es sich um ein LUKS Laufwerk handelt und Devmapper das für uns managen wird, tragen wir den Devmapperpräfix und die UUID als Laufwerkspfad ein. „/media/Huge“ ist der Mountpoint, den Ihr bei Euch ggf. vorher noch anlegen müßt. Natürlich könnt Ihr auch einen anderen Pfad dafür nehmen, müßt Ihr wissen. Für alle Einsteiger: Der Mountpoint ist nichts weiter als ein leeres Verzeichnis. Das kann liegen wo Ihr wollt, aber /mnt/directory oder /media/directory  bieten sich an. Wichtig ist, daß da nichts anderes gemountet ist und der Pfad nicht in einem anderen Mountpoint ist.

Beispiel:

/media/Small
/media/Bigger
/media/Huge

„ext4“ ist das Filesystem. Ihr werdet gemerkt haben, daß nach dem Formatieren der LUKS Partition ein weitere Partition unter der LUKS-Partition aufgetaucht ist. Da liegen Eure Daten dann wirklich drin. Das sieht so aus:

am sieht die Anzeige einer Luks-Partition gefolgt von der dadrin befindlichen normalen PartitionDiese Partition muß von Euch jetzt auch erst noch formatiert werden, dann natürlich passend zu dem Eintrag in der /etc/fstab, den wir gerade besprochen haben. Nehmt einfach Ext4, könnt Ihr praktisch nichts falsch machen. Wie Ihr sehen könnt, bekommt diese Partition eine eigene neue UUID. Aber das muß Euch jetzt nicht weiter belasten.

Damit die Platte jetzt auch beim Booten entschlüsselt wird und damit das Mounten/Einhängen des Laufwerks überhaupt erst möglich wird, tragt Ihr die UUID noch in die /etc/crypttab ein:

echo „luks-c16596bf-b40d-4c57-a46d-93b98d4bac47 UUID=c16596bf-b40d-4c57-a46d-93b98d4bac47 none“ >> /etc/crypttab

Das wars schon. Beim nächsten Booten ist die Platte dann sofort verfügbar.

„Keine Panik!“

Ok, eine freundliche Schriftart habe ich jetzt auf die Schnelle nicht zur Hand und großer geht es auch nicht, aber falls Ihr mal etwas vergessen oder Euch vertippt habt und Euer System nicht bootet.. KEINE PANIK!

Das löst sich ganz einfach:

1. den PC von einer USB-LIVE Disk booten.
2. Das Laufwerketool starten.
3. Eure Systempartition ggf. erst entschlüsseln und dann direkt im Tool mounten/einhängen.
4. TERMINAL öffnen
5. „su“ eingeben
6. „blkid“ eingeben
7. UUID in /etc/fstab und /etc/crypttab  vergleichen
8. Tippfehler beheben und Rechner neu booten.

99% aller Fehler in dem Bereich sind Vertipper oder man hat es schlicht und ergreifend nicht abgespeichert 🙂

CVE-2020-8597: Pre-Auth RCE in PPP

Posted on by

Ist Euch mal aufgefallen, daß über eine der dicksten Sicherheitslücken in 2020 so gut wie kein Wort verloren wird?

CVE-2020-8597: Pre-Auth RCE in PPP

Im Point-To-Point-Dienst wurde eine Lücke entdeckt, die es erlaubt Code auszuführen, noch bevor man sich autorisieren muß. Die Brisanz an der Sache ist, daß nicht nur die Server betroffen sind, sondern auch die Clienten. Eingesetzt wird das u.a. bei VPN Systemen.

Was mich an der Sache ein bisschen ärgert ist, daß seit 2 Wochen das Update vom ppp bei Fedora im Bodhi hängt, weil mal wieder keiner zum Testen Zeit & Lust hatte, was mir sehr bekannt vorkommt. Davon mal abgesehen, wurde der aktuelle Chef vom Fedoraprojekt direkt nach entdecken der Lücke über die Brisanz, den Entdecker und die verifizierende Quelle informiert, keine 8 Stunden nach den ersten Gerüchten. Ich weiß das, weil ich das gemacht habe, mit dem Hinweis es an die Security von RH, PPP etc. zu  eskalieren.

Damit mußte eigentlich allen Beteiligten klar sein, daß es sich um ein Critupdate handelt. Kritisch ist das nämlich, weil viele VPN Techniken, außer SSH, auf den ppp setzen und damit eine echt große Angriffsfläche gegeben ist. Die Lücke ist so krass, daß die sogar osübergreifend existiert. Das erlebt man ja auch nicht jeden Tag.

Der, sagen wir mal schweigsame, Umgang mit der Lücke, auch in den Medien führt übrigens dazu, daß Kunden diverser Produkte die den ppp kommerziell einsetzen nicht mal wissen, daß es diese Lücke gibt, was dazu führt, daß es keinen Druck bei den Herstellern gibt. Ich befürchte sogar fast, daß die nicht mal wissen, das es die Lücke gibt, weil das erst heute, 2 Wochen nach bekanntwerden,  über FullDisclosure gelaufen ist und somit auch erst jetzt die Runde macht.

Pro-Linux.de ist übrigens eine der wenigen Seiten in Deutschland, die überhaupt über diesen Bug berichtet haben, aber auch mehr, weil es ein automatisches Advisory von Debian gab und weniger, weil daß jemandem aufgefallen ist. Für eine Pre-Auth RCE mit Eskalation zu Root ist das alles eine sehr seltsame Sache. The Hacker News hat vor 2 Tagen darüber berichtet, aber das wars dann schon. Golem oder Heise vermisst man mal wieder, dabei wäre das ein gefundenes Fressen für die Medien, weil es Millionen betroffener Clients und Server gibt.

Wenn Android hustet, …

…, wo niemand genau weiß, ob jemand wirklich davon betroffen ist, da raschelt es gleich im Blätterwald, aber wenn die Sicherheit von Millionen Hosts in Gefahr ist, dann bleibt alles ruhig?

Dem einen oder anderen stellt sich jetzt vermutlich die Frage, wieso habe ich das nicht gleich im Blog gepostet als ich davon erfuhr? Ich wollte meiner Distro einen kleinen Vorsprung geben, damit der Patch ausgerollt wird, bevor die Masse der Blackhats das mitbekommt. Nachdem Fefe das in seinem Blog rausgehauen hatte, konnte man zu dem annehmen, daß es im Blätterwald sehr schnell die Runde machen würde, was ja dann überraschenderweise nicht passiert ist.

Ihr merkt, bei dieser Lücke ist einiges anders als sonst. Ich frage mir nur gerade, was eigentlich die Lektion ist, die wir daraus lernen sollten: „trotz wager Infos die Posaune rausholen und sofort berichten“ oder „doch abwarten bis es mehr Infos gibt und so riskieren, daß keiner was meldet“? Ich muß gestehen, da bin ich auch überfragt. So etwas wie beim ppp darf sich jedenfalls nicht wiederholen.

Die kuriose Let’s Encrypt Zertifikatsvernichtung

Posted on by

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