[Discuss] [Wien] Ubiquiti Malware / Virus! Bitte prüft eure Geräte (dzt. nur Antennen betroffen)

[Erich N. Pekarek]

Hallo!

Am 2016-05-16 um 13:18 schrieb David Hopfmueller:
> On 05/16/2016 10:48 AM, Stefan Schultheis (home) wrote:
>
> Hi,
>
>> [...]
>
> Wow, ein Drittel des Netzes ist offline?! Ich wusste nicht, dass das 
> derartige Ausmaße angenommen hat.
Laut Ubnt-Forum hat es auch einige (kommerzielle) WLAN-Provider 
(weltweit) kalt erwischt.
> [...]
> Mich wundert, dass es zu dem Thema nicht mehr Traffic auf dieser Liste 
> gibt. Da müssen doch einige zig Leute betroffen sein. Ist das 
> großteils unbemerkt geblieben, kommuniziert ihr offline, leidet in 
> Stille, …?
Mich wundert es weniger: Funkfeuer ist für manche ein Add-On. Wieder 
andere Nodebesitzer haben einen Maintainer, der sich darum kümmert.

Das ist ja auch Teil meiner wiederkehrenden, langjährigen Kritik: dass 
die Weitergabe von Wissen bezüglich des Betriebs von Netzen stagniert, 
wenn man auf Maintainer anstelle von "Angels" (Mentoren) setzt.

> Wir sollten jedenfalls für die Zukunft eine Lösung finden. 
Strategien?
Etwa: Mentorship ausbauen, Tools für die Anomalieerkennung im Netz, 
Hard- und Software-Diversität; Auflösung des Widerspruchs zwischen einem 
informativen Community-OS (Fokus: verteilte 
Status/OLSR-Status-Interfaces) und der Vermeidung von allzu vielen 
(potentiell angreifbaren) Diensten pro Gerät.

> Der Vorfall ist ein weiteres Argument gegen Black-Box-Devices wie die 
> Ubnt-Bridges.
AirOS ist nicht in der Gesamtheit eine Black-Box, nur Teile, wie 
proprietäre WLAN-Treiber, für die man als Programmierer ein NDA 
unterzeichnen müsste.
Soviel darf ich von einem solchen, mir bekannten NDA-Unterzeichner 
weitergeben: die OpenSource-Treiber beherrschen nur einen kleinen 
Bruchteil der Funktionalität dessen, was von den Chips unterstützt wird.

Was aktuell betroffen ist, ist lighttpd, respektive das modifizierte "PHP2".
Siehe 
https://community.ubnt.com/t5/airMAX-General-Discussion/Virus-attack-URGENT-UBNT/td-p/1562940/page/5

Und gerade wegen der besseren WLAN-Treiber und aktuellen Regulatorien 
führt momentan kaum ein Weg an Hersteller-Software vorbei.
Was man jedoch tun kann: Lobbying betreiben und an den 
Open-Source-Teilen, die auch dort zum Einsatz kommen mitwirken. (Audits 
etc).

> Und ein deutlicher Reminder, uns als Community um eine 
> Update-Strategie und ein Sicherheitskonzept zu kümmern.

Die Update-Strategie nützt wenig, wenn es sich um einen Zero-Day-Exploit 
handelt - und somit begriffsgemäß Herstellerpatches fehlen.
Und das in diesem Fall anzuwendende Sicherheitskonzept stünde, wie oben 
erwähnt, im Widerspruch zu den bisherigen Anforderungen der "Community".
Was aber die "Community" ist, was ihr kollektiver Wille ist und, wie man 
im Sinne dessen arbeiten kann, das sind die wiederkehrenden Grundfragen...
(Rollen: Node Maintainer vs. Node Owner vs Node User vs ...).

Aber auch das hat sein Gutes:
In diesem Funknetz gibt einen zentralen Uplink - auch das steht im 
Widerspruch zu Paradigmen eines echten Community-Netzes,  aber gerade 
das erweist sich als Vorteil, wenn aufgrund erkennbarer Muster Ports 
geblockt werden sollen. (Es sei denn, unser Netz hat aus 
wissenschaftlichen Gründen den Zweck, ein Honeypot sein, was ich einmal 
nicht annehme.;-)

Und wieder einmal zeigt sich, dass rein technische Lösungen für eine 
soziale oder gemischt technisch-soziale Problematik nicht funktionieren 
können. Und wieder einmal darf ich sagen: Funknetze, wie wir sie kennen, 
sind EOL. Leider zeigen die Ereignisse, dass diese meine von Einigen 
hier herabgewürdigte Aussage zutreffend ist - Nur vom Leugnen der 
Probleme und mit Blocken von Nachrichten wird es auch nicht besser.

Besinnnen wir uns auf diese Fragen, bevor wir uns auf konkrete 
strategisch-technische Maßnahmen festlegen, die über ein Stopfen von 
Löchern hinausgehen:
Community, wer bist Du?
Community, was willst Du?
Community, wohin gehst Du?


Für den Moment können wir die "Black Boxes" nur aus der Schusslinie 
nehmen, indem wir die Anzahl der laufenden, angreifbaren Dienste reduzieren.
U.z. nicht gerade durch Security by Obscurity (Ports verlegen oder "nur" 
Blocken), sondern durch Abschalten des Webservers (http/https), dem 
Deaktivieren von SSH-Passwörtern (anstelle dessen SSH-Keys nützen).
Auf Verdacht würde ich auch auf SNMP verzichten.
Alternativ kann man den Bridge-Modus nützen und ggfls. die Boxen 
dedizierten VLANs zuordnen - wobei rein quelloffene und aktuelle 
Software Schnittstellen nach Außen bieten sollte.

Aaron kann einstweilen via Cert.at das Pentesting von AirOS vorantreiben.
>
> CU,
> David
>
LG
Erich
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/discuss/attachments/20160516/44038eaa/attachment.htm>