Sicherheitslücke? Update durch fremdeinwirkung?

[FaKre]

Hallo zusammen,

ich habe da folgendes Problem, das mit neben Bauchschmerzen auch noch Kopfzerbrechen bereitet.

Gestern Mittag stand mein Garagentor sperrangelweit offen.
Ich dachte erst, dass es einen Stromausfall gegeben hat und es deswegen offen stand. Aber als ich dann mal auf meinem Raspberry auf dem auch FHEM läuft, nachgesehen habe, gab es keinen.

Dann wollte ich ins Logfile von FHEM gucken, ob ich da was sehe, was das Tor geöffnet haben kann, denn zum einen habe ich über einen potentialfreien Kontakt die Möglichkeit den Garagentorantrieb anzusteuern und über einen Fenster-Tür-Kontakt den Status des Garagentors.

Problem Nr. 1:
Ich kam nicht mehr in FHEM rein.
Ich habe den WEB Zugang mit einem doch recht sicheren Passwort versehen, da ich von außen auch zugreifen wollte.

Über ssh habe ich dann in die config reingesehen und stellte zu meiner Überraschung fest, dass das beim attr basicAuth ZmhlbTpmaGVt eingetragen war.
Das wäre fhem:fhem in base64 und definitiv nicht meine eingetragene Benutzer:Passwort Kombination.

Das habe ich dann wieder rückgängig gemacht und konnte mich auch wieder einloggen.

So weit so gut...
Dann habe ich ins Logfile geschaut um zu gucken, was da los war.

Da traf ich auf Problem Nr. 2

Scheinbar hat irgendwas oder irgendwer ein Update von FHEM gestartet.
Nach dem Update, dann mein Garagentor geöffnet (über das notifiy act_on_potentialFrei) und FHEM danach beendet.

Ich habe ebenfalls versucht ein Update per http request auszulösen ohne die Zugangsdaten einzugeben, dass hat aber leider (bzw. eigentlich eher Gott sei Dank) nicht funktioniert.

Mich erschlagen die zahlreichen Module leider, kann es dein, dass da jetzt eins drin ist, dass da nicht reingehört und sich jemand damit ein Hintertürchen eingebaut hat?

Laut "update list" ist aber auch nur das fhem repository [...]/controls_fhem.txt drin.

Sollte ich FHEM sicherheitshalber nochmal frisch installieren?

Gibt es vielleicht eine Möglichkeit die Zugriffe auf FHEM mit IP Adresse oder ähnlichem zu sehen oder das speichern zu aktivieren?



Hier der Betreffende Auszug aus dem Log:
Edit: ist wohl zu lang und die CODE Tags wurden abgeschnitten... ich versuche es eben zu kürzen

[rudolfkoenig]

Mir ist z.Zt nur ein potentielles FHEMWEB-Sicherheitsloch bekannt (CSRF), was ueber das Setzen des csrfToken FHEMWEB Attribtues vermeiden laesst. Das Attribut ist noch nicht per default aktiv, diese Voreinstellung ist aber fuer Version 5.8 programmiert. Wenn das bei Dir die Ursache sein sollte, dann werde ich die Aktivierung vorziehen, auch wenn sie mit manchen Schnittstellen noch nicht kompatibel ist. Ausserdem waere es gut zu wissen, wo du diesen "Virus" eingefangen hast. Es kann aber auch was anderes sein, was mir noch unbekannt ist.

Fuer die Protokollierung der Anmeldeversuche meine ich im Forum schon Beitraege gesehen zu haben, dafuer ist (noch) etwas Bastelarbeit notwendig.

Module werden erst dann geladen, wenn sie angesprochen werden. D.h. die Menge der Dateien ist nicht das Problem, sondern der Inhalt der aktiven Module. Ich bitte dich dein FHEM/controls*.txt hier anzuhaengen, genauso wie ein "find /opt/FHEM -print | xargs md5sum".

[herrmannj]

Mir scheint es sehr unwahrscheinlich das ein virus ein update auslöst.
Ich würde meinen das sich wohl eher "jemand" Zugriff verschafft hat.
Auch in diesem Fall erscheint es mir unwahrscheinlich das der jemand ein update auslöst ... recht untypisch.
Ebenfalls mysteriös: das Passwort hätte der "jemand" dann ausgerechnet auf "fhem:fhem" geändert ? Gibt ja nub wirklich bessere Hintertüren, vorsichtig formuliert.

@FaKre:
Du schreibst das Du den fhem über das INET erreichbar gemacht hast. ? Ist das richtig ?
Welche Ports hast Du dazu am router geöffnet ?

Ich erlaube mir aber zu mutmaßen das die Suche in die falsche Richtung geht. Das vorgehen macht für einen "jemand" einfach keinen Sinn...

Wie hast Du denn fhem initial installiert ?

vg
joerg

[FaKre]

Hallo nochmal,

sorry, musste erst noch ein bisschen arbeiten

Anbei die Dateien.
Da ich kein Verzeichnis mit /opt/FHEM habe und du wahrscheinlich entweder /opt/fhem oder /opt/fhem/FHEM meintest habe ich beides mal ausgeführt und angehängt.


@herrmannj
Das ist es ja auch, was mich wundert, wenn jemand bei mir drin wäre, könnte er so viel mehr Schabernack treiben als das was passiert ist.
das mit fhem:fhem hat mich vermuten lassen, dass es irgendwie durch das Update auf "default" gesetzt wurde.

Das Portforwarding geht von 9001 auf 8083 am Raspberry


Interessant ist auch, dass nach Ende des Updates und dem Schalten des Garagentors 10minuten vergangen sind
(vgl. Logfile )
2016.06.26 10:29:33 // Update ende -
2016.06.26 10:39:05 // Garage öffnen

Das spräche irgendwie dafür, dass sich jemand umgeguckt hat.
Was wiederum dagegenspricht ist, dass die Sprinkler nicht eingeschaltet wurden ^^


Mir kam bisher der Skript-Kiddie Gedanke...
- Ich Scanne Ports auf öffentlichen Adressen bis ein FHEM antwortet,
- Ich setze die Anmeldung zurück auf fhem:fhem
- Ich guck mich ein bisschen um
- Ich schalte was
- Ich mach FHEM shutdown
- Ich freue mich, dass ich jemand geärgert habe.

Mehr Sinn finde ich dahinter leider bisher einfach nicht...

[LuckyDay]

wenn jemand nur u in die cmd Zeile eingibt, startet man auch ein update, wollte es nur erwähnen

[Wernieman]

rein von der Sicherheit würde ich Dir auch nicht empfehlen, fhem direkt ins I-Net verfügbar zumachen.

Alternativ:
- apache (oder sonstiger Webserver) proxy. Der Kann dann auch die Authentifizierung machen!
- VPN
- ssh-Tunnel
- ......

P.S. ssh:
Hast Du einen sicheren ssh-Zugang? Auf Standard oder einen anderen Port?

[FaKre]

@Werniemann

ssh hab ich über den Standard Port aktiv aber kein Forwarding nach Außen.
Da komme ich nur von intern dran.

Apache als Proxy würde doch die gleiche Authentifizierung nutzen, ob jetzt FHEM die Basic Auth anfordert oder Apache ist doch am Ende gleich, oder woran dachtest du?

[Wernieman]

Ich (persönlich) weiß nicht, wo genau die Authentifizierung in fhem ansetzt. Da der apache diesbezüglich als "Security-mäßig-Sicher" abgeklopft wurde, habe ich genau den als Frontsystem eingesetzt (nicht nur wegen fhem). Dabei haben ich Ihn auch als Proxy (für fhem) eingesetzt.

[rudolfkoenig]

sorry, musste erst noch ein bisschen arbeiten ;-)

So'n Zufall, ich auch :)

Controlfiles sind ok, im Log-Auszug faellt mir auch nix schlimmes ein. Ja, ich wollte md5sum von /opt/fhem. Nach einem Vergleich: du hast 3 zusaetzliche Module, die nicht im Standard sind (55_GDS, 98_TheOpenTransporter, 55_weco), und die Dateien in www/frontend/www/frontend/app (ExtJS Frontend ?) sind auch unterschiedlich, die werden aber auch nicht per update geladen. Und natuerlich die Logfiles/.gplot/restoreDir/etc.
Alles in allem sollte sich bei dir eine "normale" FHEM-Distribution befinden.

Bezueglich CSRF ist eine Apache-BasicAuth-Authentifizierung genauso angreifbar, wie FHEMWEB mit seinem basicAuth, und VPN hilft gar nicht. In allen Faellen muss der Angreifer nur den FHEM-Hostnamen raten, das ist seit dem "Wegfall" von FHEM @ Fritz-Box aber schwieriger geworden. Und er muss natuerlich eine von uns besuchte Webseite (z.Bsp. forum.fhem.de) praeparieren.