RCE Lücke in smartem Stromzähler

Das ein Gericht das BSI gerade daran gehindert hat, einfach die Anforderungen an die Zulassung von smarten Stromzählern zu senken, war eine mehr als positive Entscheidung. Wie sich zeigt ist die Sicherheit von smarten Stromzählern essentiell.

RCE Lücke in smartem Stromzähler

ThreadPost berichtet in einem Artikel vom 12.3. von einer ungepatchten Sicherheitslücke in einem „Schneider Electronic PowerLogic ION/PM Smart Meter“:

„Critical security vulnerabilities in Schneider Electric smart meters could allow an attacker a path to remote code execution (RCE), or to reboot the meter causing a denial-of-service (DoS) condition on the device.“

Dies Modell wird zwar nicht in Deutschland eingesetzt AFAIK, zeigt aber wie wichtig die Sicherheitsfrage bei diesen Geräten ist. Die fraglichen Geräte hängen wohl am Internet und sind so Angriffen ausgeliefert. Wieso man da bitte nicht mal eine Firewall vorsetzt, die Verbindungen nur vom zuständigen Datacenter zulässt, wird wohl niemand von der Firma beantworten wollen.

Dieses spezielle Smartmeter kann komplett übernommen werden, oder alternativ geDOSt werden, also an der Arbeit gehindert werden. Wenn ich so eine Lücke hätte, wüßte ich was das Smartmeter messen lassen würde: Das ich im Urlaub bin und nur der Kühlschrank läuft 😉  „Ist halt gehackt worden“, falls jemand die Frage stellt, wieso die Leitungen rot leuchten 😉

Das Schlimme an der Sache ist, daß solche Geräte mal wieder in Rechenzentren und Medizinischen Einrichtungen stehen. Damit sind diese Geräte, denen man den Hack nicht ansieht, dann Einfallstore für weitere Attacken. Wie man dem Bericht weiter entnehmen kann, ist wohl der ganze interne Softwarestapel schlampig zusammen gebaut worden:

“We found that the advance_buffer function always returns true, regardless of other inner functions failing and returning false. „

Das meint, daß egal ob eine Unterroutine die Rote Leuchte rausstellt und den Aufrufer darauf hinweist, daß es nicht geklappt hat, macht die aufrufende Routine einfach weiter. Das nennt man im Fachjargon „Fire & Forget Code“. Dieser geht immer davon aus, daß das was er tut funktioniert. Eine Fehlerbehandlung ist nicht vorgesehen. Und genau das fällt diesem Smartmeterhersteller jetzt auf die Füße. Aus Programmierersicht habe ich da jetzt kein Mitleid, weil das ist einfach nur schlampig zusammen gebastelt worden.

 

Alle mal Firefox updaten!

Remote-Code-Execution in Firefox < 85.0.1 … Alle mal auf Update drücken!

Alle mal Firefox updaten!

Das Cert schreibt dazu:

Zusammenfassung:
Ein entfernter, anonymer Angreifer kann eine Schwachstelle in Mozilla Firefox und Mozilla Firefox 
ESR ausnutzen, um beliebigen Programmcode auszuführen.

Übersetzung: Jede Webseite kann Euch beim Besuch hacken!

Wer es sofort braucht:

sudo dnf update https://kojipkgs.fedoraproject.org//packages/firefox/85.0.1/1.fc32/x86_64/firefox-85.0.1-1.fc32.x86_64.rpm

bzw. sudo dnf update https://kojipkgs.fedoraproject.org//packages/firefox/85.0.1/1.fc33/x86_64/firefox-85.0.1-1.fc33.x86_64.rpm

Alle anderen müßten dann mal auf Ihre Distro warten.

BleedingTooth: Remote Code Execution in BlueZ Kernelstack

Kritische Sicherheitslücke im Bluetooth-Stack von Linux und Android entdeckt. Bluetooth eingeschaltet zu haben, reicht aus um angreifbar zu sein.

BleedingTooth: Remote Code Execution in BlueZ Kernelstack

Kritische Sicherheitslücke im Bluetooth-Stack von Linux vor Kernel 5.9 entdeckt. Der Fix wurde am 29.9. bereits heimlich in einen Kernel Branch eingepflegt und wartet seitdem auf den Merge in den Hauptkernel. Erst für Kernel 5.9 war das der Fall, so daß derzeit alle Geräte die mit Linux angreifbar sind, bis auch dort Backportpatche verfügbar sind.

Gefunden hatten diese Lücken Intel ( „Intel – wie konnte das passieren, die finden doch sonst nichts“ )  und Google. Bei Google kann ich das verstehen, die verdienen damit Geld, aber Intel? 😉

Also RCE, Remote Code Execution, und das auch noch ohne Anmeldung. Meint: Jedes Gerät mit aktiviertem Bluetooth in der Nähe ist angreifbar, nur weil es da ist. BleedingTooth ist dabei nicht nur eine Lücke, sondern ein ganzes Sammelsurium an Schwachstellen, die kombiniert, den RCE mit Privilegien Eskalation erlauben.

Bis auf weiteres: BlueTooth abschalten!

Quellen:

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html

https://github.com/google/security-research/security/advisories/GHSA-h637-c88j-47wq  ( Die erlaubt die Code Ausführung )

 

RCE: 68.8< Firefox Mobile <80.x Schwachstelle

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.

Schwachstellen im Apache Webserver < 2.4.44

Wer Apache als Webserver einsetzt, sollte jetzt aufpassen, denn wir haben jeweils eine  RCE und eine DOS Schwachstelle.

Schwachstellen im Apache Webserver < 2.4.44

In Apache wurden drei Schwachstellen identifiziert und im August behoben. Leider hat man u.a. bei Fedora vergessen, das publik zu machen, deswegen hier die Erinnerung für Euch:

Im HTTP2 Modul sind zwei Schwachstellen enthalten, die zum Crash führen und damit als DOS (Denial of Service) gelten:

important: Push Diary Crash on Specifically Crafted HTTP/2 Header (CVE-2020-9490)
moderate: Push Diary Crash on Specifically Crafted HTTP/2 Header (CVE-2020-11993)

Beide Schwachstellen kann man auch per Konfigurationsänderung abwehren, falls man keine gepatchten Webserver bekommen kann, oder noch nicht hat:

Je nachdem was Ihr für eine Distro habt, wird HTTP2 an verschiedenen Stellen aktiviert. Bei Fedora bietet sich an, eine eigene kleine Config in conf.modules.d/ anzulegen. In die Datei kommen zwei Einträge:

99-mitigate-http2.conf:

H2Push off
LogLevel warn mod_http2.c:error

Dann mit „systemctl httpd restart“ den Server neustarten. Die erste Anweisung behebt die 2020-9490 und die zweite sagt dem HTTP2 Modul, es soll nur kritische Sachen loggen, anstatt auch Warnungen. Das ist wichtig, da Angreifer über einen provozierten Fehler den Logging-Pool der Prozesse stören können und das führt dann zum Crash, was aber nur geht, wenn der Fehler auch geloggt wird.

moderate: mod_proxy_uwsgi buffer overflow (CVE-2020-11984)

Wer mit dem WebSocket Proxy uwsgi arbeitet, der muß updaten, eine Mitigation der möglichen Remote-Code-Schwachstelle ist nicht möglich. Bis zum Update kann man das Modul auch abschalten:

Für Fedora wäre das hier in conf.modules.d/00-proxy.conf:

# LoadModule proxy_uwsgi_module modules/mod_proxy_uwsgi.so

Einfach ein # vor die Ladeanweisung und den Webserver mit „systemctl httpd restart“ neustarten. Natürlich funktionieren die Proxy Tunnel, die auf „uwsgi:://server:port/uri“ lauten, dann nicht mehr. Habt Ihr noch einen vhost konfiguriert, der das benutzen möchte, wird der Start des Webservers nicht funktionieren.

Updates vorhanden

Updates auf die 2.4.46 liegen für Fedora bereit. Für alle, die Ihre Server per Autoupdate versorgen, hat sich das Problem damit bereits erledigt.

RCE: Firefox 79.0 Update einspielen

Mojn, Moin,

bitte spielt mal Eure FireFox Updates auf 79.0 ein, da <79 leider eine RCE Schwachstelle hat ( Remote Code Execution ). Also das Schlimmste vom Schlimmen.

RCE: Firefox 79.0 Update einspielen

Das BSI-Bürger-Cert schreibt dazu:

Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Mozilla Firefox und Mozilla
Thunderbird ausnutzen, um Schadcode auszuführen, einen Absturz zu verursachen, vertrauliche
Informationen auszuspähen oder Sicherheitsvorkehrungen zu umgehen. Zur Ausnutzung genügt es, eine bösartige E-Mail, Webseite oder einen Link dorthin zu öffnen.

so spielt Ihr das Update für Fedora ein:

sudo dnf -y update –enablerepo=updates-testing firefox

Einfach noch das Rootpasswort bestätigen, fertig.

Cato der Ältere meinte dazu übrigens: Ave RPM!

Wer wissen will, was das jetzt sollte, die BS LUG trifft sich einmal die Woche zu einem VideoChat, da löse ich das auf 😉

Nvidia: 2 Sicherheitslücken im Linux-Treiber

Zwei Sicherheitslücken sind im NVIDIA GFX-Kartentreiber für Linux enthalten, wenn Ihr noch nicht die brandaktuellste Version haben solltet, was schwierig sein dürfte.

Nvidia: 2 Sicherheitslücken im Linux-Treiber

Laut der Bugbeschreibung bei Nvidia, handelt sich dabei bei einer Lücke um einen Bug in der IPC Communication API, was man braucht um Daten zwischen einzelnen Prozessen hin und her zu schicken. Dieser Fehler kann dazu genutzt werden um mit erweiterten Rechten eingeschleusten Code auszuführen.

CVE-IDs
Addressed
Software ProductOperating SystemDriver BranchAffected VersionsUpdated Versions
CVE‑2020‑5963
CVE‑2020‑5967
GeForceLinuxR450All versions prior to 450.51450.51
Quadro, NVSLinuxR450All versions prior to 450.51450.51
R440All versions prior to 440.100440.100
R390All versions prior to 390.138390.138
TeslaLinuxR450All R450 versionsAvailable the week of June 29, 2020
R440All versions prior to 440.95.01440.95.01
R418All versions prior to 418.152.00418.152.00

Die zweite Schwachstelle ist dann schon schwieriger auszunutzen, da eine RACE Condition ist, es kämpfen also zwei Prozesse um eine Ressource. Der Gewinn des RACE würde einen DOS erlauben. Was ein Angreifer auf einem DesktopPC davon haben würde die Grafikkarte zu crashen, naja. Ist trotzdem gut, daß es gefixt wurde.

Für Fedora lautet die Treiberversion für meine GFX-Karte 440.82 und muß daher aktualisiert werden. Da diese aus dem Repo von RPMFusion stammt, dürfte der Verbreitungsgrad und damit der Updatezwang unter Fedora/Centos/RHEL Benutzern entsprechend hoch sein. Wie das zu Problemen führen kann und was man das machen muß, lest Ihr hier: Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll.

Bei RPMFusion habe ich heute schon angeklopft, daß Updates benötigt werden.

Quelle: https://nvidia.custhelp.com/app/answers/detail/a_id/5031

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

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.

Thunderbird < 68.4.1mit RCE Schwachstelle

Und gleich nach Firefox zieht Mozilla mit der (vermutlich) gleichen Schwachstelle in Thunderbird nach: Remote-Code-Execution in Version < 68.4.1

Remote-Code-Execution in Thunderbird

Wie wir gerade vom CERT erfahren haben, ist in Thunderbird eine Sicherheitslücke enthalten, die zum Ausführen von Code aus der Ferne taugt. Mozilla schreibt dazu:

CVE-2019-17024: Memory safety bugs fixed in Thunderbird 68.4.1

Reporter Mozilla developers
Impact high
Description

Mozilla developers Jason Kratzer, Christian Holler, and Bob Clary reported memory safety bugs present in Thunderbird 68.3. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code.

References   Memory safety bugs fixed in Thunderbird 68.4.1

Eine weitere kritische Sicherheitslücke wurden auch gefunden, auch wenn diese nicht per Email ausgenutzt werden kann:

Announced January 10, 2020
Impact critical
Products Thunderbird
Fixed in Thunderbird 68.4.1

In general, these flaws cannot be exploited through email in the Thunderbird product because scripting is disabled when reading mail, but are potentially risks in browser or browser-like contexts.

#CVE-2019-17026: IonMonkey type confusion with StoreElementHole and FallibleStoreElement

Reporter Qihoo 360 ATA
Impact    critical
Description  Incorrect alias information in IonMonkey JIT compiler for setting array elements could lead to a type confusion. We are aware of targeted attacks in the wild abusing this flaw.
References  Bug 1607443

 

Offensichtlich nutzen Angreifer das bereits aus, weil der gleiche Bug auch in Firefox drin war. Wie das genau dann passiert, kann ich mir allerdings auch nur schwer vorstellen.

Derzeit werden die nötigen Pakete bei Fedora noch gebaut! Es gibt also noch keine Updates, die man einspielen könnte für Euch. Andere Distributionen waren da ggf. schneller.

Update

Hier Eure Downloadlinks:

https://kojipkgs.fedoraproject.org//packages/thunderbird/68.4.1/1.fc30/x86_64/thunderbird-68.4.1-1.fc30.x86_64.rpm

https://kojipkgs.fedoraproject.org//packages/thunderbird/68.4.1/1.fc31/x86_64/thunderbird-68.4.1-1.fc31.x86_64.rpm

Exim: neue mögliche RCE Schwachstelle gefunden

Toller Sonntag. Überall Regen und dann weckt mich noch die Meldung, das im Exim eine neue, nicht abwehrbare Schwachstelle gefunden wurde 🙁 ( wichtiges 13 Uhr Update unten )

Elysium ist gefallen

Es gibt einen neuen Bug, der auch bereits gefixt wurde, aber leider nicht mit einem Workaround abzuwehren geht. Das bedeutet für Euch, daß Ihr Updaten müßt.

Der Fehler liegt in einem Programmierfehler der Stringverarbeitung, die dummerweise bereits beim HELO/EHLO greift. Ein Angreifer kann einen Heap-overflow auslösen, in dem er einen überlangen ELHO String sendet.

An der Stelle des Codes wurden die Rootrechte zwar schon gedroppt, aber das hilft nur wenig, falls der Angreifer tatsächlich einen RCE hinbekommt, was nicht ausdrücklich ausgeschlossen ist, aber auch nicht 100% bestätigt wurde. Daher muß man davon ausgehen, daß es jemand früher oder später schafft: Worst-Case halt.

Betroffen sind alle Versionen < 4.92.3.

Also entweder Ihr patchted Euren alten Exim selbst, oder Ihr updated auf die neue Version. Eure Entscheidung.

Aktuelle CVE Nummer zu dem Exim RCE : CVE-2019-16928 .
(Passage geändert, vorher keine bekannt gewesen.)

13 Uhr Update

Fedora kompilierte Versionen sind nicht angreifbar. Der Exploit funktioniert einfach nicht.

Getestet auf: Fedora 29 64Bit gegen 4.92.2

Andere Distros könnten angreifbar sein. Es hängt auch ein bisschen damit zusammen, wie das angegriffene System konfiguriert ist. „Eylsium ist gefallen“ ziehe ich damit teilweise zurück .. das Fedosium steht noch :DDD

Der Exploitstring ist übrigens 11k lang, nur falls Ihr das bei euch mal selbst ausprobieren wollt, nehmt gleich 12k.

Außerdem wurde mitgeteilt, daß es im Rahmen der 4.92.x eingeführt wurde und mit 4.93 auch schon wieder draußen war. Die Exploitmeldung war leider etwas hastig formuliert worden. Allerdings sehe ich da keinen Schaden drin, weil „besser safe than sorry“ wie der Denglischer sagt 😉