Exploit FHEM 6.0

Begonnen von Raemsna, 02 September 2020, 19:20:58

Vorheriges Thema - Nächstes Thema

Raemsna

Hallo zusammen,

ich habe hier im Forum mit der Suche nichts zu diesem Thema gefunden.

Ich habe durch Zufall bei Github eine mögliche Verwundbarkeit von FHEM gesehen, die ich hier teilen wollte (um ggf. notwendige Maßnahmen zu ergreifen).

https://github.com/EmreOvunc/FHEM-6.0-Local-File-Inclusion-LFI-Vulnerability

Es geht darum, dass bei Änderung des Logfile Aufrufs über FHEM-WEB auch andere Systemdateien anzeigbar sind (ohne dass dies ggf. gewünscht ist) - meine Interpretation des Gesehenen.

Sorry, falls das Thema schon bekannt war / ist.

Grüße
Raemsna

amenomade

Habe ich bisher noch nie gelesen.

Aber das stimmt. Das geht nur für Dateien, die "read" Berechtigung für alle (bzw. für die Gruppe des fhem Users oder für den fhem User selbst) haben, aber das ist trotzdem ein exploit.

Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

herrmannj

Das als "exploit" zu bezeichnen ist Effekthascherei.

Wer Zugriff auf fhem hat, der kann beliebige system Befehle über die Kommandozeile absetzen:
{`ls`}
{`cat /etc/passwd`}
Das ist so 'by-design' und das gehört so.

a) so'n Zinnober wie im verlinkten POC ist völlig unnötig
b) der "POC" funktioniert nur wenn man angemeldet ist.

Translation: ein  user mit Zugriff auf die OS console (aka shell) kann sich Dateien anzeigen lassen. Nix neues.

FHEM bietet die Werkzeuge um den Zugang abzusichern - die wurden hier einfach nicht genutzt.

vg
JJoerg

amenomade

Eben. Das ist ein "exploit" für diejenige, die die Berechtigungen schon haben.
ZitatDas geht nur für Dateien, die "read" Berechtigung für alle (bzw. für die Gruppe des fhem Users oder für den fhem User selbst) haben

{`rm -Rf ~`} ist auch ein "exploit"

Vielleicht hätte ich die Einführungszeichen nutzen müssen...? Aber per se ist der Zugriff auf Systembefehle eine Sicherheitslücke. Somit hat man Zugriff auf Daten, die nicht zu Nutzdaten der Anwendung gehören.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Christoph Morrison

#4
Randbedingung: FHEMWeb mit allowed (Passwort egal), allowedCommands = , (d.h. man darf (explizit) in der Kommandozeile nichts ausführen)

In der Kommandozeile:
{ `cat /opt/fhem/FHEM/FhemUtils/uniqueID` }

Ergebnis:
Forbidden command { `cat /opt/fhem/FHEM/FhemUtils/uniqueID` }.

Direkter Zugriff via FileLog_logWrapper-Exploit, z.B. über
http://localhost:8084/fhem/FileLog_logWrapper?dev=Logfile&type=text&file=/opt/fhem/FHEM/FhemUtils/uniqueID

Ergebnis:

# This file is auto generated.
# Please do not modify, move or delete it.

uniqueID:7f0607aa210dec22428a78cc2a000899


:o
Immer noch by design?

Ich hab das in meinem Fork gepatcht, und Zugriff außerhalb des Installationsverzeichnisses (in der Regel /opt/fhem) gesperrt:
http://localhost:8084/fhem/FileLog_logWrapper?dev=Logfile&type=text&file=/etc/passwd

Ergebnis:
Possible break-in attempt by calling '/etc/passwd'

Mir ist bewusst, dass das keine endgültige Lösung ist, denn man soll auch z.B. die /opt/fhem/fhem.cfg oder eben die /opt/fhem/FHEM/FhemUtils/uniqueID  nicht so lesen können sollen. Das ist auch nur ein erster Entwurf.

nb: Ich finde "by design" ist eine schwache Antwort. Wenn das das Design ist, ist das Design schlecht, denn Sicherheit sollte immer mehrschichtig organisiert sein, d.h. nur weil ich z.B. eine TLS-Verbindung mache, sollte ich Passwörter trotzdem nicht unverschlüsselt speichern (ja Viegener, ich meine dich, hat mich doch mein Blink-Klartextpasswort in der uniqueID angelacht). Und wie man sieht bietet allowedCommands auch z.B. keinen Schutz davor, dass jemand mit Lesezugriff auf FHEM (nicht auf den Host), Dateien auf dem Host liest. Super übrigens wenn man ein Klartextpasswort für basicAuth angelegt hat (was man natürlich nicht tun sollte) und das über FileLog_logWrapper sowieso einfach gelesen werden kann - dann kann man die Zugriffsbeschränkung auch direkt weglassen.

amenomade

ZitatRandbedingung: FHEMWeb mit allowed (Passwort egal), allowedCommands = , (d.h. man darf (explizit) in der Kommandozeile nichts ausführen)
Damit darf man auch kein set, es sei in der Kommandozeile oder durch Klick auf eine webCmd in der UI.

Man kann natürlich get,set setzen. Das könnte aber andere Nachteile haben. Und man kann nicht alle FHEMWEB Instanzen mit nur get,set einrichten, sonst ist keine Konfiguration per UI mehr möglich

ZitatIch hab das in meinem Fork gepatcht, und Zugriff außerhalb des Installationsverzeichnisses (in der Regel /opt/fhem) gesperrt:
http://localhost:8084/fhem/FileLog_logWrapper?dev=Logfile&type=text&file=/etc/passwd


Ergebnis:
Possible break-in attempt by calling '/etc/passwd'
Das ist interessant.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Christoph Morrison

Zitat von: amenomade am 03 September 2020, 18:56:06
Damit darf man auch kein set, es sei in der Kommandozeile oder durch Klick auf eine webCmd in der UI.

Klar, das ist die maximale "Sicherheitsstufe" die man dem User aufkonfigurieren kann (ohne ihm den Zugriff komplett zu verbieten), deshalb hab ich diese für meinen Test gewählt. Und selbst dann kann man also beliebige Systemdateien auslesen, die der User erreichen kann, inkl. der von FHEM gespeicherten Passwörter in allowed / uniqueID.

Wäre jetzt nicht so schlimm, wenn dort die Passwörter wenigstens ordentlich verschlüsselt abgespeichert werden würden, aber weder der Wiki-Artikel zu allowed weist ausdrücklich auf den richtigen Weg hin; der Beispielcode dort ist auch plain text. MQTT2_CLIENT speichert dummerweise, genau wie 48_BlinkCamera, das Passwort in der uniqueID-Datei auch direkt im Klartext.

Zitat von: amenomade am 03 September 2020, 18:56:06
Man kann natürlich get,set setzen. Das könnte aber andere Nachteile haben. Und man kann nicht alle FHEMWEB Instanzen mit nur get,set einrichten, sonst ist keine Konfiguration per UI mehr möglich

Das ist halt by-design so ;-)

Christoph Morrison

FileLog_logWrapper + /dev/zero tötet übrigens FHEM ;-)

amenomade

Zitat von: Christoph Morrison am 03 September 2020, 20:09:35
https://forum.fhem.de/index.php?topic=102107.0
Naja... verschlüsselt bringt nicht viel. Ein Blick im Quellcode (auch erreichbar, und das ist bei opensource so) und schon ist es entziffert ;)
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Christoph Morrison

Zitat von: amenomade am 03 September 2020, 20:29:51
Naja... verschlüsselt bringt nicht viel. Ein Blick im Quellcode (auch erreichbar, und das ist bei opensource so) und schon ist es entziffert ;)

Nicht wenn man das Secret irgendwo wegspeichert, wo z.B. nur root Zugriff hat und das Secret nur einmal bei Start gelesen und ansonsten im Speicher gehalten wird. Dann würde man nur die verschlüsselten Daten lesen können (außer der Angreifer hat root-Zugriff, aber dann ist man eh verloren).

Ich hab mir mal den Mechanismus von Fritzbox angeschaut - klar, am Ende ist das alles mehr Obfuscation als wirkliche Verschlüsselung.