FritzBox penetranter Hacker

Begonnen von dieda, 13 Mai 2019, 18:09:47

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: Christoph Morrison am 14 Mai 2019, 10:17:17
Hätte uns doch nur jemand vor all den kleinen ranzigen Wifi-Devices gewarnt, wegen denen man jetzt Wifi nicht mehr einfach abschalten kann ...
ymmd ;D ;D ;D
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

KölnSolar

ZitatHätte uns doch nur jemand vor all den kleinen ranzigen Wifi-Devices gewarnt
Tu ich doch permanent.  ;D (Möglichst) Kein WiFi-Devices im Smart-home und erst recht (möglichst) keine Cloud.
Dann kann man zumindest temporär abschalten.  8)

Ich bin ja jetzt der gefühlt 97te, der gerne wüsste, wie der TE zu seiner Annahme kommt. Und das
ZitatMangels eigene Möglichkeiten, er kann kein Telefonanschluss legen lassen, Gründe führen hier zur Identifizierung des Hackers, mobiles Internet ist in Deutschland teuer, zu surfen, skypen und Virdeos zu schauen.
hab ich auch nicht wirklich verstanden. War das die Antwort auf Jörgs Frage ?

Zitat von: amenomade am 13 Mai 2019, 18:15:41
Hab das noch nie gesehen, aber FHEM kann in der Fritzbox schauen, welche MAC Adressen im WLAN sind, und kann auch WLAN deaktivieren. Also.... sollte machbar sein.
Im Syslog der Fritte sieht man ja außerdem sowohl die "fehlgeschlagene" Zugangsprüfung, als auch Zugriffsversuch von "gesperrten MAC-Adressen".
Es gibt zwar auch Fehlmeldungen, aber immerhin ein erster Fingerzeig, wenn man diese Meldungen in FHEM bekäme.
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

herrmannj

Ich bin da nicht mehr auf dem laufenden .. aber als ich noch jung war, da war eine etablierte Methode zur Bestimmung des konkreten Risikos für Informationssysteme "Threat und Vulnerability".

Vulnerability, also eine konkrete und bekannte Sicherheitslücke und Threat als praktikable Möglichkeit diese so auszunutzen dass man, zum Beispiel, die Vertraulichkeit einer Information verletzen kann. Oder möglicherweise die Authentifizierung. Das (oder so) hat der TE vermutlich mit "hacken" gemeint ?

Kann mich jemand auf dem Stand bringen welche konkreten Sicherheitslücken denn eine aktuelle, gepatchte und vernünftig konfigurierte Fritzbox heute so mitbringt? Genau wie PAH bin ich ganz erschrocken heute lernen zu müssen das man "jedes WLAN hacken kann" ...

JoWiemann

Hm, im Moment ist mir keine wirkliche Sicherheitslücke bei der Fritte bekannt. Der letzte allgemeine Hinweis zu WLAN und WPA2 wurde Ende 2018 berichtet. https://www.google.de/amp/s/amp.computerbild.de/artikel/cb-News-DSL-WLAN-Sicherheit-WPA2-Angriff-22217293.html

Im Unternehmen stellen wir seid längerem fest, dass die Attacken mehrgleisig laufen. Also eine Kombination aus social engineering, Versuch der Nutzung von Sicherheitslücken und das Ausnutzen des Faktors Mensch.


Gesendet von iPhone mit Tapatalk

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

FHEM-User22

Moin,
Zitat von: KölnSolar am 14 Mai 2019, 11:09:55
ZitatMangels eigene Möglichkeiten, er kann kein Telefonanschluss legen lassen

Ich bin ja jetzt der gefühlt 97te, der gerne wüsste, wie der TE zu seiner Annahme kommt. Und dashab ich auch nicht wirklich verstanden. War das die Antwort auf Jörgs Frage ?
ich denke mal, der Antrag auf Erteilung eines Antragformulars wird dankend abgelehnt, nach mehreren Notizen in der Sch....auskunft. Gibts auch bei Strom. Da hacken sich die Leute physisch mit H05VV-F 3x1,5 mm² in die Hauslicht-Abzweigdosen ein.

Grüße
FHEM auf Raspberry Pi und Proxmox und... und.... und....

Christoph Morrison

Zitat von: herrmannj am 14 Mai 2019, 17:05:26
Kann mich jemand auf dem Stand bringen welche konkreten Sicherheitslücken denn eine aktuelle, gepatchte und vernünftig konfigurierte Fritzbox heute so mitbringt? Genau wie PAH bin ich ganz erschrocken heute lernen zu müssen das man "jedes WLAN hacken kann" ...

Man kann sicher nicht jedes WLAN hacken, aber die einige sind vermutlich recht dürftig konfiguriert sein - wenn man nicht schon direkt den Schlüssel auf einer Steckdose geparkt hat, die unbeaufsichtigt im Garten rumliegt.

Und am Ende kann man auch so ziemlich jedes WLAN hacken in dem man den Besitzer oder seine Liebsten bedroht.

Aber darum geht's hier eigentlich nicht. Ich bin immer noch auf die etwas konkreteren Antworten des OP gespannt.

herrmannj

Zitat von: Christoph Morrison am 14 Mai 2019, 17:37:07
Man kann sicher nicht jedes WLAN hacken, aber die einige sind vermutlich recht dürftig konfiguriert sein - wenn man nicht schon direkt den Schlüssel auf einer Steckdose geparkt hat, die unbeaufsichtigt im Garten rumliegt.
Wenn die Config sch.. ist dann muss man die anpacken. WPA2 CCMP an, WPS aus. Key im Garten? Solange fhem nicht mit KI (als head replacement) ausgeliefert wird hilft da nix mehr ... :D
Zitat
Und am Ende kann man auch so ziemlich jedes WLAN hacken in dem man den Besitzer oder seine Liebsten bedroht.
Physische Sicherheit ist ein essentieller Bestandteil von Informationssicherheit. Aber im Ernst; da fragt man dann nicht im fhem forum sondern in der nächstgelegen Dienststelle. ;)

dieda

Ich habe einige Benarichtigungen in meiner Fritzbox unter "System" aktiviert und eine Benachrichtigung bekommen, dass ein neues Gerät sich eingeloggt hat. Mir das ganze angeschaut. Gerät Mac, etc. alles nicht autorisiert...

System ist jetzt gehärtet.D. h. neuer SSID Name, neuer Schlüssel

Standard-Einstellungen:

  • Standard-Profil = gesperrt (also nix machen dürfen)
  • Mac-Filter aktiviert
  • Häkchen bei "keine neuen..."

ZitatDie folgenden Netzwerkgeräte haben sich erstmalig mit Ihrer FRITZ!Box verbunden.
Komponenten:
Sensoren und Aktoren: FS20, Max!, Zigbee, Zwave
IODev:  Cul1101, MaxLan, ZWAVE, Deconz
Router: KD-Fritte (6360)
Sonstiges: Raspberries,  1x LMS,1 FHEM, 1 x zum Testen,  Logitech-Clients,  Onkyo, SamsungTV, Squeezebox, TabletUIs

yersinia

Schön OT....
Im Grunde kann man davon ausgehen, dass in der ITK nichts (dauerhaft) sicher ist.
Selbst WPA2 ist zumindest via Brute Force mit Passwortlisten knackbar - Tools wie airmon-ng und aircrack-ng unterstützen gerne. Auch die KRACK Attacke ist schon >1,5 Jahre alt. Selbst WPA3 ist (noch) nicht so sicher. Mit Rechenpower, Zeit und Geduld kommt man überall durch.

Zitat von: herrmannj am 14 Mai 2019, 17:51:00
Wenn die Config sch.. ist dann muss man die anpacken. WPA2 CCMP an, WPS aus. Key im Garten? Solange fhem nicht mit KI (als head replacement) ausgeliefert wird hilft da nix mehr ... :D
So sieht es aus. Starke, wechselnde und vorallem geheime Schlüssel verwenden. Keine Standardpasswörter nutzen. (Betriebs-)Systeme aktuell halten. Netze trennen (VLANs, physisch). Kram wie WPS, UPNP oder TR069 abschalten. Auch über VPN Tunnel oder dynDNS sollte man gut nachdenken - benötigt man das wirklich? Ist man erfahren genug, das auch abzusichern?

Gegen Script-Kiddies kann man MAC-Filter einbauen und die SSID umbenennen - hält aber keine 'Erfahrenen' ab.

Auch beim Surfen im Internet nicht den Kopf ausschalten (Angriffe von Innen), keine Inhalte öffnen von Absendern die man nicht kennt, keine Downloads von obskuren Seiten laden, Signaturen und Prüfsummen nutzen!

Und ganz wichtig: Backup, Backup, Backup, Backup! Regelmässig, verschlüsselt, mehrfach redundant, vom Netz getrennt, physisch an verschiedenen Orten.
(Nicht vergessen: Hin und wieder ein Backup einspielen um zu testen, ob es funktioniert...)
Wirklich wichtige Dokumente/Unterlagen/Informationen nicht auschließlich digital lagern.

Bedeutet das Aufwand, Pflege, Wartung und teilweise massive Einschränkungen im Komfort? Yes Sir. Bekommt man dies allerdings einen Otto-Normal-Benutzer vemittelt? Wohl kaum...
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

nils_

ich les mal mit.... jetzt hab ich wirklich angst um mein WLAN  8)



gibts noch Popcorn irgendwann hier?
viele Wege in FHEM es gibt!

Wernieman

.. wobei man auch immer die Bedrohzenarien beachten muß. Beim I-Net-Zugang sind es Milliarden Potentielle Angreifer, beim WLAN die Umgebenden (100m im Umkreis?). Wenn jemand MICH angreifen will, wird er es wahrscheinlich eher aus dem Netz machen, als mein WLAN zu hacken. Das ist, selbst bei bekannten Problemen, aktuell nicht zu aufwendig. Gibt einfachere Methoden. Alternativ physikalisch Eingreifen (Hauseingbruch) als das WLAN ....

Wenn man nicht die Standardpasswörter benutzt, ist es aktuell selbst mit den bekannten Tools sehr aufwendig .. und wer leistet sich schon einen Rechencluster, nur um MEIN LAN-Passwort zu knacken?

Als Firma dagegen .. sieht es schon anders aus (Wenn ich groß und/oder bekannt genug bin).


- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Prof. Dr. Peter Henning

ZitatIm Grunde kann man davon ausgehen, dass in der ITK nichts (dauerhaft) sicher ist.
Darüber habe ich schon 1997 einen Roman geschrieben - den wir dann, nachdem er jahrelang nur herumgelegen hat, 2015 als eBook herausgebracht haben: https://www.amazon.de/Das-Sieb-Brahma-Peter-Henning-ebook/dp/B00DVEYDEG.

LG

pah



herrmannj

Na dann bleiben wir mal im Theorie Teil :D

Sicherheit als absolute oder binäre Größe existiert in der Informationssicherheit per se nicht.

Es geht immer darum ein konkretes Risiko auf ein annehmbares Maß zu reduzieren. Das setzt natürlich voraus das man a) das Risiko messen kann (qualitativ, quantitativ) und eine Definition für "annehmbar" zu besitzen.

Das Risiko bestimmt man idR mit Hilfe einer Matrix, auf der einen Achse der Impact und auf der anderen die Eintrittswahrscheinlichkeit. Beide Werte werden multipliziert (geringe Eintrittswahrscheinlichkeit/hoher Impact == große Eintrittswahrscheinlichkeit/moderater Impact).

Dann führe ich Maßnahmen durch um das Risiko auf "meinen" Schwellenwert zu senken. (Eintrittswahrscheinlich reduzieren, Impact abfedern, Risiko transferieren, vermeiden .... ). Die Eintrittswahrscheinlich kann man schätzen oder es berechnet dann der Profi, dazu spielen dann (unter anderem) Threat and Vulnerability eine Rolle.

Dabei müssen die Maßnahmen natürlich günstiger sein als der Schaden den ich vermeiden möchte. ;)

Brainstorming zu WLAN:

Wenn ein unautorisierter Benutzer das WLAN für eigene Zwecke benutzt:
* verbraucht er Ressourcen die dem Besitzer (evtl) fehlen. Bandbreite, Volumen, Strom. Der konkrete Schaden (€) für den Besitzer dürfte in Zeiten von Flatrate und co überschaubar sein. Die Eintrittswahrscheinlichkeit ist gering wenn man Hygiene hält: aktuelle gewartete und gepatchte Fritzbox, vernünftige config, Passwort schwer zu erraten und sicher verwahrt.
* es gibt ein Reputationsrisiko: der "Gast" könnte juristisch relevante Handlungen (Urheberrecht, Erpressung) über die IP Adresse des Besitzers durchführen. Der anzunehmende Impact ist hoch (nicht existentiell) allerdings git es ja mittlerweile einige Urteile die hier zugunsten des "Besitzers" ausfallen - und die Eintrittswahrscheinlichkeit bleibt gering (siehe oben)
* die Vertraulichkeit könnte verletzt werden. Wenn ein unautorisierter Benutzer über den WLAN Schlüssel verfügt kann jener (unter bestimmten, begrenzten Umständen) die legitime Kommunikation mitlesen. Hier besteht also die Gefahr das zum Beispiel Anmelde Daten (APP des "Besitzers" -> Banking) offengelegt werden. Impact: potentiell hoch. Aber: diese Kommunikation ist ohnehin auf öffentlich Netzwerke (per Definition nicht vertrauenswürdig) ausgelegt, also separat geschützt durch Verschlüsselung. Die Bewertung muss man am konkreten Umstand treffen; in der Regel sollte man davon ausgehen das diese Maßnahmen (auch oben) gemeinsam das Risiko auf ein annehmbares Maß reduzieren.

Was in der Regel unter den Tisch fällt ist jedoch das Thema Verfügbarkeit (des WLAN). Es gibt in der Tat eine ganze Reihe von bekannten, praktisch durchführbaren Angriffen auf WLAN die zur "Unbenutzbarkeit" führen. Was daraus folgt muss man bewerten (welcher Schaden entsteht) und ist prinzipbedingt - es sind halt Funkwellen.

Ist sicher nicht vollständig, aber so kann man das Thema in eine Struktur bringen.

Christoph Morrison

Zitat von: herrmannj am 15 Mai 2019, 11:25:23
Was in der Regel unter den Tisch fällt ist jedoch das Thema Verfügbarkeit (des WLAN). Es gibt in der Tat eine ganze Reihe von bekannten, praktisch durchführbaren Angriffen auf WLAN die zur "Unbenutzbarkeit" führen. Was daraus folgt muss man bewerten (welcher Schaden entsteht) und ist prinzipbedingt - es sind halt Funkwellen.

Häufig vernachlässigter Punkt, imho. Inzwischen laufen bei einigen Leuten ganze Teile ihrer Sicherheitsinfrastruktur über Wifi - Stichwort Kameras - und alle gehen davon aus, dass Wifi auch stets zur Verfügung steht. Dabei hat man das mit einem 10$-Device von Aliexpress problemlos ohne weitergehende Skills "geregelt" und dann sind die Kameras zwar nicht blind, melden aber keine Alarme mehr, speichern nichts mehr in die Cloud und eine eventuell vorhandene Karte rauszupflücken ist nachträglich auch kein Thema mehr.

Beta-User

#29
@herrmannj:
Schöne Zusammenfassung!

Zitat von: Christoph Morrison am 15 Mai 2019, 11:37:18
Häufig vernachlässigter Punkt, imho. Inzwischen laufen bei einigen Leuten ganze Teile ihrer Sicherheitsinfrastruktur über Wifi - Stichwort Kameras - und alle gehen davon aus, dass Wifi auch stets zur Verfügung steht. [...]
Ist sicher ein Punkt, aber auch wenn ich sonst gerne speziell vor unbedarftem Einsatz von WLAN warne: Das ist _allen_ Funklösungen gemein; ein potentieller Angreifer wird tendenziell versuchen, alle (gängigen) Bandbreiten zu stören (wenn ihn sowas schon interessiert, dann richtig, oder?)... => da hilft (mit Einschränkungen) nur Kabel.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files