Category Archives: Security

Fedora 33: der Wechsel zu systemd-resolved schaltet DNSSEC aus

Posted on by

Wow, was für eine Hammermeldung. Damit hatte vermutlich niemand gerechnet, daß der Wechsel zu systemd-resolved als DNS Resolver des Systems einfach mal die einzige Sicherheitsmaßnahme im DNS aushebelt, die überhaupt spürbar Sicherheit gebracht hat 🙂

Fedora 33: der Wechsel zu systemd-resolved schaltet DNSSEC aus

„Seit heute morgen 6:44 Uhr wird zurück geschossen“ :  Paul Wouters, bekannt aus dem Bereich Transparenz und Sicherheit der IETF, updatete seinen Server auf Fedora 33, was er quasi sofort bereut hat. Mit dem Wechsel kam die Umstellung auf systemd-resolved, über den wir vor Monaten in der Fedora Mailingliste gesprochen hatten und ich eigentlich der Meinung war, daß die Umstellung der /etc/resolv.conf hin zu systemd-resolved in der Form gar nicht kommt.

Man merkt, daß Paul bei seinem Posting an die Fedora-Devel-Mailingliste auf Krawall gebürstet war, und das vollkommen zu Recht. Seine ganzen Serverdienste benutzen DNSSEC um die Verbindungen zu Mailserver, VPN usw. abzusichern, so daß niemand für seine Dienste eine MITM-Attacke fahren kann und dann kann der eingesetzte DNS-Resolver plötzlich kein DNSSEC mehr:

„It is my opinion as a long time DNS RFC author and package maintainer that systemd-resolved is not a suitable DNS resolver. Downgrading DNSSEC allowing local DNS to bypass DNSSEC is bad enough, but I read on:

https://fedoraproject.org/wiki/Changes/systemd-resolved

that DNSSEC is now completely disabled. Again, this is completely unacceptable. DNSSEC is part of the core of DNS protocols.“ (Paul Wouters)

Ich hätte nicht gedacht, daß jemand wirklich so verrückt wäre, Millionen von PCs mit einem DNS-Resolver aus der Steinzeit zuversehen, wo das Update doch eine Verbesserung und kein Rückschritt sein sollte. Seinen weiteren Ausführungen kann man sich nur anschliessen:

„This change is harmful to network security, impacts existing installations depending on DNSSEC security, and leaks private queries for VPN/internal
domains to the open internet, and prefers faster non-dnssec answers over dnssec validated answers. It fails various types of queries,
misimplements part of the DNS protocol. Not only according to me, but to 20years+ developers of the bind software as well.

The first mandatory step is to not disable DNSSEC. If I put on my security hat, I would actually have to look into filing a CVE for Fedora 33.“ (Paul Wouters)

Und der Mann weiß was er da schreibt, er hat 20 Jahre an Bind mitgeschraubt. Zum Glück für uns ist nichts in Stein gemeiselt, daher jetzt die Befehle, um nach dem Upgrade für Ordnung zu sorgen:

sudo rm -f /etc/resolv.conf
sudo ln -sf /run/NetworkManager/resolv.conf /etc/resolv.conf
sudo systemctl disable –now systemd-resolved.service
sudo systemctl mask systemd-resolved.service
sudo systemctl reboot

Damit haben wieder die DNS Einstellungen das sagen, die der User beim Anlegen der Netzwerkverbindung getroffen hat. Ich finde ja schon lange, daß der Systemd sich deutlich zu weit aus dem Fenster hängt. Das ist ein Bootsystem und kein eigenes Betriebssystem Leonard! Aber stellt sich doch glatt raus, daß der resolved vom systed das könnte, wenn man es nur einschalten würde, was es per default nicht ist :facepalm:

 

OpenSSH: neuere ssh Versionen verweigern Verbindung

Posted on by

In der Fedora Welt kommt seit Wechsel auf Fedora 33 zu einem Problem mit OpenSSH-Servern, wenn die noch alte Hostskeys verwenden oder man selbst zum Authentifizieren einen Key benutzen möchte, der noch SHA1 als Hashalgorithmus benutzt.

OpenSSH: neuere ssh Versionen verweigern Verbindung

Das sollte eigentlich nicht passieren, daß man mit einem Clienten nicht mehr in seinen Server kommt, aber zur Zeit häufen sich die Meldungen, daß man mit dem OpenSSH Shellclienten von Fedora 33 nicht mehr auf Server einloggen kann, wenn entweder der Server einen alten SHA1 Keys verwendet, oder der Client einen Authkey benutzt der noch SHA1 ist.

Die temporäre Abhilfe ist, dem Clienten mitzuteilen, daß er gefälligst den alten SHA1 weiter benutzen soll. Dazu ruft man ssh mit dem Argument „-oPubkeyAcceptedKeyTypes=+ssh-rsa“ auf:

ssh -oPubkeyAcceptedKeyTypes=+ssh-rsa root@servername

Auf lange Sicht muß man natürlich einen neuen Schlüssel auf den Servern und für seinen Zugang ausrollen. Dazu muß man wissen, ob man davon überhaupt betroffen ist und da sagt einem der SSH-Keygenerator:

ssh-keygen -l -f .ssh/Krypto.id_rsa
4096 SHA256:ehMkPi1CRDPCoOYMxdTI8BB2+TkCa13CyMQXX5EXesg id@braunschweig.de (RSA)

Zuerst die Schlüssellänge 4096 Bits, dann der gesuchte Hashalgorithmus „SHA256“ und am Ende der Type „RSA“.  Wenn Ihr betroffen seid, weil Eurer Key unter 2048 und/oder SHA1 ist, dann braucht Ihr einen neuen Key:

ssh-keygen -b 4096 -t rsa-sha2-512 -N „PASSWORD“ -f „FILENAME“ -C „Kommentar“

wobei -N -f und -C alle optional sind, aber falls Ihr größere Mengen an Schlüsseln erzeugen müßte, ist das ganz hilfreich 🙂

Am Ende stellt sich nun aber heraus, daß es gar kein Fedora33 „Feature“ war, daß zu dem Problem geführt hat, sondern ein OpenSSH Bug. Hier der Patch, falls Ihr das adaptieren müßt:

— sshconnect2.c.orig 2020-09-26 07:26:37.618010545 -0700
+++ sshconnect2.c 2020-09-26 07:25:35.665009029 -0700
@@ -1281,10 +1284,9 @@
*/
if (ssh == NULL || ssh->kex->server_sig_algs == NULL ||
(key->type != KEY_RSA && key->type != KEY_RSA_CERT) ||
– (key->type == KEY_RSA_CERT && (datafellows & SSH_BUG_SIGTYPE))) {
– /* Filter base key signature alg against our configuration */
– return match_list(sshkey_ssh_name(key),
– options.pubkey_key_types, NULL);
+ ((key->type == KEY_RSA || key->type == KEY_RSA_CERT)
+ && (datafellows & SSH_BUG_SIGTYPE))) {
+ return xstrdup(sshkey_ssh_name(key));
}

/*

Der Patch ist nicht von mir, sondern von Gordon Messmer und wurde erst vor einigen Stunden bei OpenSSH eingereicht. Mal sehen was daraus wird 😉

RCE: 68.8< Firefox Mobile <80.x Schwachstelle

Posted on by

Es ist vielleicht nicht das schlechteste, daß Mozilla seine Leute rausgekantet hat, denn je weniger da arbeiten, desto weniger können so richtig tief in die Scheiße greifen 🙁

RCE: 68.8< Firefox Mobile <80.x Schwachstelle

Wie gestern Abend von den Hacker News  berichtet wurde, gibt es im FireFox Mobile eine so gravierende Sicherheitslücke, daß sich einem die Fußnägel aufrollen. Wenn man mit einem FF M < Version 80 gemeinsam in einem WLAN oder anderen Netz ist, kann man dem Firefox eine Nachricht senden, und er führt das direkt aus: Eine Remote Code Execution Schwachstelle.Die Schwachstelle wurde im FireFox Mobile 80 für Android gefixt.

Hinweis: In einem FF Mobile 68.8 konnte das Verhalten, trotz absichtlicher Aktivierung des Features nicht reproduziert werden.

FireFox sendet SSDP Pakete ins Netz um Geräte zu finden, die man als Screencast verwenden kann. Das wäre a) der Job vom OS und b) nicht so schlimm, wenn man das Ergebnis, das einem unaufgefordert jeder im Netz senden kann, mal auf SINNVOLLE Werte prüfen würde, statt es BLIND auszuführen.

Über so einen Intent kann man auch Addons oder andere Apps Installieren’und natürlich auch Webseiten mit Exploits besuchen, das macht es so gefährlich.

Kleines Demo gefällig?

Dies Video stammt von Gitlab-Account des Red Teams:

Wer sich mit Android Programmierung nicht auskennt, ein „Intent“ ist eine Anfrage von App A an (meistens) alle anderen Apps, ob die mit dem Inhalt was anfangen können. So brauche ich bspw. als Browser keinen Videoplayer integrieren, weil das eine andere App vermutlich viel besser kann als ich.

Aber selbstverständlich nehme ich als Anwendung dazu keine Infos, die selbst von einer dubiosen anderen Stelle im Netz bekommen habe, sondern leite da nur Sachen hin, die „ich selbst“ erstellt oder runtergeladen habe vom Ziel.

So ein Verhalten ist grob fahrlässig und eines Anfängers ohne Security Schulung würdig, aber doch nicht den Entwicklern eines Marken-Browsers.

Fußnote

NetFlix Mobile scheint auch per SSDP nach Sachen zu suchen, aber ob die Entwickler den gleichen dicken Bug eingebaut haben, ist nicht bekannt. Wer selbst nachsehen will, soltle in seinem WLAN mal das hier starten: „sudo tcpdump -A -n not tcp and not icmp and port ssdp“

SSDP ist das Simple Service Discovery Protocol und gehört als UDP basiertem Dienst zum UPnP, den Universal Plug & Play. Diese ganzen Autodetect Sachen sind als Funktion ganz nett, aber führen immer mal wieder zu Schwachstellen. Per UPnP kann man z.b. als Programm der Firewall sagen, daß man gern ein Loch haben würde für seinen Dienst, ohne das der Firewall-Admin was davon mitbekommt. Wird oft von Instant-Messengern benutzt um durch die DSL-Router zu kommen.