Log4j-Vulnerability

[Rüdiger Kupper]

Da das gerade durch sämtliche Medien geht und unsere Nutzer verunsichert:
Wir müssen ein Statement zu log4j abgeben.

@bau

da bist Du gefragt.

[bau]

Laut Auskunft von G&P ist das Problem bei WU versionsabhängig sehr unwahrscheinlich.

[bau]

@kup: Du schreibst immer viel schönere Texte. Zwischenstand: Java ist zwar ein sehr beliebtes System, welches wir aber selbst nicht einsetzen. Lediglich Produkte von anderen Anbietern sind betroffen, wir setzen WebUntis und den Unifi-Controller ein - letzterer wurde gepatched, WebUntis wird gerade geklärt. Weitere Java-Software kommt bei uns nicht zum Einsatz.
Auskunft unseres Providers BelWUE: Java wird auch dort kaum eingesetzt. Produkte von externen Anbietern sind gepatched.

[Rüdiger Kupper]

Okay, dann warten wir am besten noch ab, was G&P herausfindet.

[Rüdiger Kupper]

Nextcloud (PHP) und Collabora sind nicht betroffen, Trac ist in Python geschrieben, also auch nicht betroffen.
Welche Dienste außer Webuntis haben wir sonst noch laufen, die von außen erreichbar sind?

[Rüdiger Kupper]

Gibt es diesbezüglich Neues? Ab Montag werden die Kollegen WebUntis wieder verstärkt nutzen.

[bau]

Die Verbraucherzentrale hat sich für nicht zuständig erklärt - ich habe eine Anfrage an unseren Schulträger gestellt. Somit muss WebUntis aktuell über den Apache geschützt werden, so dass die APP aktuell nicht läuft.

Wir könnten für die Kollegen eine Route zum WebUntis-Server bauen, die wir per MAC-Adressen-Regel auf das Endgerät des Kollegen einschränken. Ist aber aufwändig.

[Rüdiger Kupper]

Da müssten wir ja für jeden Kollegen seine individuelle MAC eintragen und sicher verwenden manche Kollegen noch mehrere Geräte parallel. Scheint mir zu aufwändig.
Kann man das log4j-Modul auf dem WebUntis-Server irgendwie manuell aktualisieren?

[bau]

Habe gerade nochmals bei Untis-BW nachgefragt wegen der drei Lösungsvorschläge, die ich bereits 2020 gemacht hatte:

• Nachbau der von G&P benutzten Serverumgebung bei uns in der Schule / Adminzugänge für die Administration von G&P
• Hosting bei G&P auf deren Server / Datenbankzugriff über gesicherten VPN-Tunnel von uns zu G&P zur Anbindung unserer Dienste
• Hosting bei G&P auf deren Server / Datenbank auf unseren Server über VPN-Tunnel-Zugriff von G&P auf den DB-Server

Zudem habe ich darauf hingewiesen:
Sie schreiben: "(...) der nicht von der Untis GmbH zu vertretende Fehler (...)" - unseren Recherchen zufolge handelt es sich eher um ein schon immer dokumentiertes Feature von Log4j, welches nun ähnlich den SQL-Injections für Schadsoftware ausgenutzt wird (Sie würden sicher keineswegs Daten einer Usereingabe einfach unbesehen in ein SQL-Statement übernehmen, um sich dann mit der Frage konfrontiert zu sehen, warum das Kind nicht ";DROP DATABASE; heißen darf - eher würden Sie die Usereingabe vorher mit z.B. mysql_real_escape_string() bearbeiten wollen). Ich würde behaupten wollen, dass seitens Gruber&PettersLog4j zu unreflektiert eingesetzt wurde.

[Rüdiger Kupper]

Ich frage mich grade, ob wir die Passwortabfrage irgendwie umgehen können, wenn die Kollegen über die Kepler-Cloud WebUntis ansurfen. Dort haben sie sich ja bereits authentifiziert.
Ein spezieller URL, den ich als Link eintrage, müsste gehen. Die NC-Nutzer bekommen den URL nie zu Gesicht, sie sehen in ihrem Browser nur '​https://cloud.kg-fds.de/apps/external/5'.
Wenn Du mir also einen Link zu WebUntis gibst, der die Passwortabfrage umgeht, dann könnten wir zumindest die doppelte Authentifizierung aus der Kepler-Cloud loswerden.

[bau]

intern wäre das 10.16.112.8 über https auf Port 8080, auf dem paedml sieht die Weiterleitung so aus:

ProxyPass        /WebUntis http://10.16.112.8:8080/WebUntis

[bau]

Aus den internen Netzen habe ich die Passwortabfrage entfernt:

• päd. Netz (10.32.0.0/12)
• Lehrernetz (10.16.112.0/23)
• Gastnetzwerk (10.0.0.0/16)
• MobileDevices (10.2.0.0/16)
• OpenVPN-Tunnel (172.16.34.0/24)

Leider funktioniert das in Gastnezwerk und MobileDevices so nicht, da dort Anfragen nach draußen mit NAT bearbeitet werden, auf dem Server kommt folglich die IP des Routers an. Nachdem ich die Routeradressen eingetragen habe, geht das jetzt.

[Rüdiger Kupper]

Replying to bau:

intern wäre das 10.16.112.8 über https auf Port 8080, auf dem paedml sieht die Weiterleitung so aus:

ProxyPass        /WebUntis http://10.16.112.8:8080/WebUntis

Interessant, dieser Link lässt sich dann nicht in einem Frame öffnen, nur in einem eigenen Fenster. Hängt das damit zusammen, dass die NC-Seite über eine https-Verbindung läuft und daher Frames, die http nutzen, nicht funktionieren?

[bau]

OK, sollte ich folglich im Tomcat noch SSL einrichten?

[Rüdiger Kupper]

Das wäre den Versuch wert, wenn es nicht viel Aufwand macht.

[Rüdiger Kupper]

Info:
​https://stackoverflow.com/questions/18327314/how-to-allow-http-content-within-an-iframe-on-a-https-site

Die Lösung, Google als Redirect zu nutzen, ist wirklich … abenteuerlich!

YEAH - ich habe vollstes Vertrauen in Google - vor allem bezüglich des Datenschutzes, da haben die ja hervorragende Grundsätze :-)

[Rüdiger Kupper]

Replying to bau:

OK, sollte ich folglich im Tomcat noch SSL einrichten?

Besser wäre es natürlich, das Log4j-Problem zu lösen!