Hallo,
hat eigentlich mal jemand fhem nach Schwachstellen im Code (OWASP Top Ten) durch Penetrationstest oder Code Review getestet, zumindest für die Internet-Schnittstellen (z.B. Openweather)?
Mir ist nichts bekannt, wuerde mich aber interessieren.
Und ich waere sehr erstaunt, wenn man keine finden wuerde.
dito.
Speziell für fronthem (dann next release) würde ich das sehr gern aktiv unterstützen wenn das jemand machen möchte.
vg
joerg
ich bin kein Pentester, aber bei einem Schnellcheck mit dem OWASP ZAP-Tool aus der Kali Linux Distribution kamen schon ein paar Alerts, wenn auch nur Medium und Low:
1) X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks.
Solution: Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site (if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN, otherwise if you never expect the page to be framed, you should use DENY. ALLOW-FROM allows specific websites to frame the web page in supported web browsers).
2) A private IP such as 10.x.x.x, 172.x.x.x, 192.168.x.x has been found in the HTTP response body. This information might be helpful for further attacks targeting internal systems.
Solution: Remove the private IP address from the HTTP response body. For comments, use JSP/ASP comment instead of HTML/JavaScript comment which can be seen by client browsers.
3) Web Browser XSS Protection is not enabled, or is disabled by the configuration of the 'X-XSS-Protection' HTTP response header on the web server
Solution: Ensure that the web browser's XSS filter is enabled, by setting the X-XSS-Protection HTTP response header to '1'.
4) The Anti-MIME-Sniffing header X-Content-Type-Options was not set to 'nosniff'. This allows older versions of Internet Explorer and Chrome to perform MIME-sniffing on the response body, potentially causing the response body to be interpreted and displayed as a content type other than the declared content type. Current (early 2014) and legacy versions of Firefox will use the declared content type (if one is set), rather than performing MIME-sniffing.
Solution: Ensure that the application/web server sets the Content-Type header appropriately, and that it sets the X-Content-Type-Options header to 'nosniff' for all web pages.
If possible, ensure that the end user uses a standards-compliant and modern web browser that does not perform MIME-sniffing at all, or that can be directed by the web application/web server to not perform MIME-sniffing.
Was mir noch aufgefallen ist: Für Firmata (FRM device) ist ein Telnet-Port geöffnet, der nicht Passwort-geschützt ist. Kann man da nicht etwas machen?
Ich würde mich auch besser fühlen, wenn ein Pentest-Experte mal genauer schauen würde. Wenn man fhem für Hausautomatisierung nutzt, sind doch schon einige sensible Daten / Services dabei...
Koennt ihr die Findings zeitnah in den Planung aufnehmen und fixen?
Nein, da ich die Probleme entweder nicht nachstellen kann (2), sie nicht verstanden habe (1,3) oder fuer Unsinn halte (4).
Wurde fuer die Tests das CORS Attribut gesetzt?
Hi,
ich fand eine Mail dazu, möchte das Auszugsweise auch hier nochmal beantworten.
mMn führt automatische / halbautomatische Pentests hier zu nichts weil:
fhem ist so konstruiert das der Benutzer, ganz gewollt, weitreichende Systemrechte hat. Beispiele: eigener code in 99_myUtils, evals, fhem cmd line, eigene module und so weiter. Das soll auch alles so sein.
Wenn ich Zugriff auf das webif habe, darf ich tun und lassen was ich will! In diesem Zusammenhang erübrigen sich alle Diskussion über cross side scripting und so weiter, das führt in die falsche Richtung.
Hier könnte man schauen welche Lücken bleiben wenn ich basic auth (oder andere Mechanismen) setze und an denen arbeiten.
vg
joerg
ja, das ist richtig. In diesem fall muss man die höheren risiken akzeptieren und den zugang zu fhem bestmöglich absichern.
Ein weiterer Angriffspunkt der bleibt sind schnittstellen / offene ports wie z.b. 3030 durch FRM / firmdata, openweather etc
...die andere frage ist, was muss man alles aus dem webif heraus können. muss man auch auf systemdateien zugreifen können oder reicht das fhem verzeichnis mit unterverzeichnissen bzw die ausführungsmöglichkeit von systemkommandos im kontext des fhem verzeichnisses?
Interessantes Thema. Ich arbeite auch oft mit Kali, allerdings ist es mir noch nicht in den Sinn gekommen meine Haussteuerung damit zu testen.
Das mag aber auch dadran liegen das mein Sicherheitsbewusstsein hoch ist. Und das von FHEM "auch". Undzwar in der Hinsicht, das FHEM komplett Cloudfree ist.
Ich denke das jedem Benutzer klar sein sollte, das man FHEM oder andere Frontends die mit FHEM zusammenarbeiten nicht einfach so durch seinen Router in das Internet schleift.
Auch nicht basicauth. "Einfach" niemals.
Das gleiche kann man auch auf andere Webapps adaptieren. Ein (z.B.) Wordpress auf meinem Apache zuhause würde ich auch nicht frei durch den Router schleifen. Und da kannst du quasi die gleichen Tools drauf los lassen, die finden auch was. Fhem ist eine reine intranet Applikation und sollte von außen auch nur via VPN genutzt werden.
Das auch eine gewisse Absicherung im Intranet dasein muss, logisch. Aber wenn man z.B. ein Gastwlan betreibt gibt es VLAN oder halt eben den basic auth ;)
Und sollte einem mal der Router geknackt werden, hat man ganz andere Probleme und da sind die ClickJacking Geschichten sowieso egal. ;)
Grüße
Grav
Stimmt im Prinzip.
Allerdings gibt es auch Szenarien wie: ein Spassvogel bringt auf einer der fhemwiki.de Seiten folgenden Code unter:
<img src="http://fritz.box:8083/fhem?cmd={set .* on}">
Wenn du diese fhemwiki Seite jetzt zuhause anschaust, und vorher im gleichen Browser dich an FHEM@Fritz.Box (mit Benutzername/Passwort) angemeldet hast, dann wird der FHEM-Befehl ausgefuehrt, basicAuth hin oder her. Es sei denn, du hast "attr WEB CORS" gesetzt (noch kein default).
Will damit sagen: es gibt prinzipiell auch sinnvolle Angriffsvektoren gegen FHEM, und an solche bin ich interessiert. An solche wie "Mit dem WEBIF kann ich /etc/passwd auslesen, nachdem ich mich ordentlich angemeldet habe", bin ich weniger interessiert.
Das stimmt natürlich, gewisse Szenarien wird es immer geben. Aber kann man nicht schon viele Szenarien durch Grundsätze in der Handhabung mit FHEM verhindern?
Dein Beispiel Szenerio nutzt sehr viele default Werte und bedeutet implizit:
- Fhem läuft auf einer Fritzbox
- Die Fritzbox hat den Default Hostname und womöglich noch das default Netz.
- Fhem läuft auf einem default Port.
Für mich persönlich gilt in jeder FHEM Umgebung der minimum Regelsatz:
- Nutze FHEM nicht auf einer Fritzbox, sondern auf einem eigenständigen Gerät. (Nicht nur aus Security Gründen)
- Nutze keine Standardnetzmaske
- Nutze keinen default Hostname.
- etc pp
Grüße
ZitatAber kann man nicht schon viele Szenarien durch Grundsätze in der Handhabung mit FHEM verhindern?
wie wäre es denn, solche grundsätze in einer art checkliste "Grundsätzliche Empfehlungen in der Handhabung mit FHEM" mit einfachen beispielen zu dokumentieren.