Über den Entwickler

Warum ich eine App gebaut habe, die die Netzwerkgrenze Ihres Mac automatisch schützt

Ein Bericht darüber, wie der unabhängige Entwickler Tetsuharu Fujiki (Lafine Systems Design) die Risiken öffentlicher Wi-Fi-Netzwerke und offener Entwicklungsserver selbst untersucht hat.

Der Auslöser war eine beiläufige Frage zum WLAN im Schnellrestaurant

Der Auslöser war eine beiläufige Frage zum WLAN im Schnellrestaurant

Als ich eines Tages über ein öffentliches WLAN arbeitete, fragte ich mich plötzlich: „Wie sieht mein Mac wohl für die Person am Nachbartisch über dieses WLAN aus?“ – und begann nachzuforschen.

„Auch in öffentlichen WLANs ist es sicher, solange die Client-Isolation (AP-Isolation) greift, weil man dann nicht mit anderen Geräten kommunizieren kann.“ Das glaubte ich lange, aber bei näherer Untersuchung war diese Annahme brüchiger als gedacht. Die Client-Isolation ist nicht in jedem WLAN aktiviert. Und selbst wo sie aktiv ist, lässt sie sich mit einer vom SANS Institute gemeldeten Methode namens „AirSnitch“ umgehen. Auch dass mein Mac per Bonjour (mDNS) im Klartext allerlei über sich verrät, wurde mir erst klar, als ich selbst dns-sd und lsof ausführte.

Das Fazit war einfach. Es gibt zwei Gegenmaßnahmen: die Angriffsfläche verkleinern und davon ausgehen, dass niemand bei jedem Netzwerkwechsel von Hand umschaltet. Fast niemand prüft seine Einstellungen jedes Mal, wenn er in ein Café kommt (ich auch nicht). Deshalb habe ich eine macOS-App gebaut, die vertrauenswürdige Netzwerke automatisch von den übrigen unterscheidet und in unbekannten Netzwerken die Angriffsfläche automatisch verkleinert. So begann RoamSwitch.

Wie sich zeigte, hatten auch Entwicklungsserver dasselbe Problem

Wie sich zeigte, hatten auch Entwicklungsserver dasselbe Problem

Bei der Untersuchung öffentlicher WLANs fragte ich mich auch, wie es bei Entwicklungsservern aussieht, und grub nach. Ich hatte vage angenommen, „ein Entwicklungsserver hört nur auf localhost und ist daher von außen sicher“, aber tatsächlich unterscheidet es sich je nach Framework, und manche Standardwerte sind unerwartet.

next dev bindet an 0.0.0.0, wenn man keinen hostname angibt. Auch python -m http.server lauscht standardmäßig auf allen Schnittstellen. Vite verwendet standardmäßig localhost, aber jeder dürfte schon einmal --host angehängt haben, um auf einem echten Smartphone zu testen. Genau darauf zielt CVE-2023-34092 (Path Traversal, CVSS 7.5). Bei Dockers -p kann ein Port sogar an den Firewall-Einstellungen des Hosts vorbei auf 0.0.0.0 veröffentlicht werden.

Das führte zum selben Schluss. Realistischer, als darauf zu setzen, dass sich jemand jedes Mal ans Schließen erinnert, ist es, den Zugriff von außen automatisch zu sperren, sobald man sich mit einem nicht vertrauenswürdigen Netzwerk verbindet. Tatsächlich ist das eine der am häufigsten gemeldeten Nutzungsweisen von RoamSwitch. Es prüft offene Ports passiv und meldet das Risiko, und in nicht registrierten Netzwerken sperrt es den Zugriff aus dem externen LAN mit dem Paketfilter des Kernels.

Profil

Lafine Systems Design / Unabhängiger Entwickler

Lafine Systems Design / Unabhängiger Entwickler

Die Firewall-Steuerung (pf/socketfilterfw), die ARP-Spoofing-Erkennung und der privilegierte Helfer (XPC) von RoamSwitch beruhen auf praktischer Erfahrung. Ich war als SE bei einem ausländischen IT-Unternehmen und in einem großen Elektronikkonzern tätig und habe mich später selbstständig gemacht, um ASP-Dienste für Behörden, Universitäten und Forschungseinrichtungen anzubieten. Heute entwickle ich „RoamSwitch“ als Einzelperson und schreibe auf Zenn über meine Recherchen.

Nachprüfbar veröffentlicht

📝 Technische Artikel auf Zenn lesen Support & Anfragen

Gesetzlich vorgeschriebene Angaben wie Name des Betreibers, Anschrift und Zahlungsarten finden Sie in der Offenlegung nach dem Gesetz über bestimmte Handelsgeschäfte.