Forum:Serversicherheit: Wie mit inaktiven Kamelaccounts verfahren?

Forum > Serversicherheit: Wie mit inaktiven Kamelaccounts verfahren?

Hinweis: Dieser Fred wurde seit 1163 Tagen nicht bearbeitet. Dieser Fred ist offiziell versandet - die Diskussion damit Geschichte. Bitte nichts mehr hinzufügen.
Bei Bedarf dann halt einen neuen Fred starten oder diesen notfalls reanimieren.

Ich bin gerade mal die Listen der Feenstabschwinger, Kameltreiber usw. durchgegangen. Da blutet einem schon das Herz, wenn man die ganzen Namen so liest, die alle hier nicht mehr mitwirken. Aber ich sehe da auch ein Sicherheitsproblem, gerade auch weil wir noch so eine veraltete Softwarebasis haben, was wenn so ein Account mal gehackt wird? Oder die inzwischen herrenlosen Bots, sofern sie noch existieren? Sollte man da nicht mal aufräumen? Man kann ja in einer von unpriviligerten Kamelen nicht bearbeitbaren Liste festhalten, wer von den leider nicht mehr anwensenden Kamelen welche Rechte hat(te) und ihnen diese erstmal enthziehen. Anhand der Liste kann man denen ja diese Rechte wieder geben, sollten sie eines Tages zurück kehren. Was denkt ihr darüber? Kamillo (Diskussion) 23:08, 31. Aug. 2021 (NNZ)

Naja, ne Liste braucht man da eigentlich nicht zu führen, denn über Vergabe und Entzug von Rechten führt MediaWiki automatisch Buch. Wenn ein User also zurück kommt, muss man nur in sein Rechtelogbuch schauen und dann kann man ihm/ihr die Rechte wieder geben. Alternativ kann man ja zusätzliche Benutzergruppen anlegen, die einen ähnlichen Namen haben und die inaktiven Kamele diesen Gruppen zuordnen.

Accounts hacken ist durch die veraltete Softwarebasis nicht unbedingt einfacher, denn das Login System sollte robust genug sein, dass man sich nur mit Passwort anmelden kann (eventuelle Sessions sind sicherlich schon ausgelaufen). Und selbst mit nem Lesezugriff auf die Datenbank wird ein Angreifer nicht weit kommen, denn Passwörter sind da (soweit ich das weis) nur als Hash gespeichert. Wenn dann brächte der Angreifer Schreibzugriff auf die DB um z.B. ne Mail Adresse zu ändern, aber das zu bekommen ist (wenn überhaupt) nur mit viel Aufwand möglich (und wenn es geht, wäre der Angreifer eventuell auch in der Lage die Gruppenzugehörigkeit zu verändern).

Grundsätzlich hast du auf jeden Fall recht, dass es inaktive Accounts mit erweiterten Rechten durchaus ne gewisse Gefahr darstellen. Mööep KamelPatrick (Diskussion) 00:38, 1. Sep. 2021 (NNZ)

Das mit den inaktiven Konten ging mir auch schon durch den Kopf. Wobei die Sicherheitslücke noch nicht mal unbedingt in MediaWiki liegen muss. Wenn irgendwo in der Wahnsinnig Weiten Wüste ein Account gehackt wird, der die selbe Mailadresse verwendet wie bei uns, dann wird ein Bot (die meisten "Hacker" sind ja Bots) diese Kombination bei allen möglichen anderen Diensten ausprobieren. Daher sind verwaiste Accounts durchaus ein Problem. Ich weiß nicht genau, welche Möglichkeiten MediaWiki bietet mit solchen Accounts umzugehen. Ich würde vorschlagen, sie inaktiv machen (im Sinne von kann sich nicht mehr anmelden aber bekommt eine spezielle Hinweisseite) und auf der Hinweisseite steht dann, an wen er sich wenden kann um den Account zu reaktivieren. Insofern stimme ich Sloyment Kamillo zu, diese Accounts sind aufgrund ihrer erweiterten Rechte ein Sicherheitsrisiko.

Zum Thema "Hackbarkeit" von unserem MediaWiki: Ich habe ad hoc nicht rausfinden können, ob die Version 1.23alpha Passwörter noch mit MD5 gehashed in der Usertabelle ablegt. Vor 7..9 Jahren war das durchaus noch Gang und Gäbe. Wäre also ein Hacker dazu in der Lage, beispielsweise durch SQL Injection MediaWiki dazu zu kriegen, die Usertabelle auszukotzen und die MD5-Hashes anzuzeigen, dann ließe sich durch simple Rainbow Tables nahezu jeder Account offline hacken. Das heißt, wir würden es noch nicht mal mitbekommen, dass bei einem Account auffällig viele falsche Logins a la Brute Force passieren würden. Der Angreifer würde das richtige Passwort (oder eines das den selben MD5 Hash hat) offline berechnen und gleich beim ersten Versuch hier richtig eingeben. Das ließe sich nur dadurch erschweren, dass man wirklich komplexe Passwörter wie z.B. "MÏ*u´»å7ÆÐ+SÁ¥ª4¦x~V×ÉÑTAçüPñȳé«:(j2EVM" (generiert mit KeePass) verwendet. Aber bitte, wer macht das schon?

Die veraltete Software als solche (insbesondere Apache, PHP, MySQL) bietet für Hacker eine interessante Basis für allerlei üble Machenschaften. Ich glaube nicht, dass ein Angriff so aussehen würde dass uns jemand die Website sperrt und dann Bitcoins fordert. Dafür ist die Kamelo nicht wichtig und wertvoll genug. Vielmehr würde ich vermuten, dass unser Server in ein Botnetz eingegliedert würde und dann beispielsweise Spam verschickt (dann würden wir ratzfatz auf Blacklisten landen und das wäre schwer rückgängig zu machen). Oder unser Server würde sich an Angriffen auf andere (evtl. sicherheitskritische) Ziele beteiligen. Grad für DDoS-Angriffe sind so gut angebundene Drohnen sehr begehrt. Dann wäre evtl. Sloyment als Betreiber juristisch haftbar. Dazu mehr in diesem PDF. Denn so einen veralteten Server zu betreiben könnte zumindest als Fahrlässigkeit ausgelegt werden. Das möchte ich auf jeden Fall vermeiden, denn uns allen ist doch am Fortbestand der Kamelo gelegen, oder etwa nicht?

--Wüstenspitz (Diskussion) 08:36, 1. Sep. 2021 (NNZ)

Grundsätzlich ist der Source Code ja öffentlich verfügbar, von daher ist es durchaus möglich rauszufinden, wie Mediawiki in welcher Version Passwörter gehasht hat. Da ich aber dran erinnern konnte, dass ich in der XAMPP installation auf meinem Rechner vor ein paar Jahren mal etwas mit MediaWiki rumgespielt hatte, hab ich da mal nen Blick reingeworfen und festgestellt, dass ich ne Installation mit Version 1.22 und eine 1.24 habe. Da die Datenbank bei beiden aber irgendwie kaputt war, hab ich mal ein Blick in den Source Code von MediaWiki geworfen und festgestellt, dass in 1.22 die Passwörter noch per MD5 gehasht wurden (allerdings optional mit nem Salt, was das ganze ja etwas sichererer macht), während die entsprechende Methode in 1.24 als seit dieser Version Deprecated markiert war, womit also zu befürchten war, dass Version 1.23 auch noch MD5 hashes nutzt. Und um ganz sicher zu gehen hab ich im offiziellen MediaWiki Repository mir den Branch für Version 1.23 angeschaut und der hat dann die Befürchtung bestätigt (was allerdings nicht unbedingt etwas über die Installation hier sagt, denn die ist ja wohl zum Teil modifiziert). Einziger Lichtblick ist, dass hier eventuell die Variante mit dem Salt genutzt wird (lässt sich aber lediglich in der Datenbank und über die Konfigurationsdatei nachprüfen), wo Rainbow Tables vermutlich kaum noch nutzbar sind. Allerdings hat dieser Lichtblick auch Einschränkungen, denn die Frage ist, seit wann eventuell mit Salt gearbeitet wurde, denn nur seit diesem Zeitpunkt geänderte Passwörter sind so gehasht, alle anderen bleiben mit dem alten Verfahren gehasht.

Naja, problematisch mit der Mailadresse wird das eigentlich nur, wenn der Mail Account selbst gehackt wird, denn ohne Zugriff auf den Mail Account bringt die Info nix, zumal der Login hier strikt über den Usernamen erfolgt und nicht über die Email. Deaktivieren kann man Accounts in MediaWiki glaube ich nicht, man kann sie lediglich sperren oder einer Usergroup zuweisen, die nur sehr reduzierte Rechte hat (in neueren MediaWiki Versionen ggf sogar, dass nur bestimmte Seiten bearbeitet werden können).

Bezüglich der Server Software, besteht durchaus das Risiko, dass Lücken ausgenutzt werden und der Server für Unfug missbraucht wird. Allerdings ist da zu bedenken, dass es sich dabei nicht um die offiziellen Releases der Entwickler für die entsprechende Version der Software handelt sondern um darauf aufbauende Packages des Linux Systems und da wurden auch Jahre nach dem Release der Version noch Fehler gefixt, womit zumindest die bekanntesten Bugs der entsprechenden Version hier nicht vorhanden sein sollten (außer sie wurden erst nach dem letzten Update der Packages auf dem Server Anfang 2017 gefixt, weshalb hier mal ein kleines Update nötig wäre). Zudem hat Strato als Hoster des VServers, auf dem die Kamelo läuft, sicherlich auch ein gewisses Interesse Spam-Wellen aus den eigenen Rechenzentren zu vermeiden (denn als Hosting-Anbieter haben die ja auch ne gewisse Verantwortung), weshalb ich davon ausgehen würde, dass die da auch schauen, dass da keiner Unsinn treibt. Das große Problem dürfte also eher sein, dass ein massives Update nötig sein wird um die aktuelle MediaWiki-Version zu installieren. Mööep KamelPatrick (Diskussion) 17:59, 1. Sep. 2021 (NNZ)

Das ist bei Open Source Fluch und Segen zugleich: Mit dem Quellcode liegen auch die Sicherheitslücken auf dem Tisch. Sie werden gesucht, gefunden, gefixt und Updates bereitgestellt. Nur müssen die Updates dann auch eingespielt werden. Wenn das hier nicht geschah, sind alle Lücken unserer Version allgemein bekannt.

Nach einem Softwareupdate müssten wir so vorgehen, dass wir von allen Kamelen beim nächsten Login das eingegebene Passwort gegen die gespeicherten Hashes prüfen und dann ein neues Passwort verlangen, was dann mit (wahrscheinlich) BCrypt gesalzen und gehashed neu abgespeichert wird. Am besten noch sicherstellen, dass das neue Passwort nicht identisch mit dem alten Passwort ist.

Aber erstmal müssen wir zu einem aktuellen Softwarestand kommen. Das wird noch schwer genug. Bzgl. MediaWiki habe ich zwischenzeitlich herausgefunden, dass es evtl. doch noch einen Upgradepfad von 1.23 auf 1.35 LTS gibt. Wir sollten künftig nur LTS-Releases einsetzen, denn wir haben kaum den Elan, jedes Jahr ein Upgrade durchzuführen (Upgrade ist ja nicht das selbe wie Update, was meist noch automatisiert möglich ist). Wer kam überhaupt auf die Idee, eine Alpha-Version zu verwenden?

Trotzdem würde ich nicht versuchen, das laufende MediaWiki zu upgraden. Es kann, vorallem mangels Erfahrung, einfach zu viel schief gehen. Besser wäre es, einen unabhängigen Webspace mit aktueller Software auf einer Subdomain aufzusetzen. Dann die jetzige MediaWiki-Installation klonen und in der Testumgebung upgraden.

Ich bin aber schon mal froh, dass wir doch ein paar Kamele mit Fachwissen haben. :-)

--Wüstenspitz (Diskussion) 19:06, 1. Sep. 2021 (NNZ)

Das Missbrauchpotential für so einen verwahrlosten Server ist riesig, reicht von der Spamschleuder, DDOS-Angriffen über Hosting von Malware für Spamkampagnen (ein häufiges "Einsatzgebiet" von gehackten Wordpress-Instanzen) bis hin zum Beispiel zur Ausnutzung von "PrintNighhtmare" über manipulierte CUPS-Dienste. Das ist ein hochsensibles Thema und wir müssen da unbedingt aktiv werden, ich hoffe Kamel:Sloyment ermöglicht den Zugang zu der Maschine bald. Aber das beantwortet meine Ausgangsfrage nicht, Wörterbuchangriffe auf die Mediawiki-Accounts der Kamele um die Passwörter rauszubekommen sind damit nicht abfangbar. Der eine Faktor zur Anmeldung ist öffentlich, der Kamelname, nur das Passwort muss ausgeknobelt werden. Wenn das jemand versucht, ich glaube nicht, dass jemand aus der Runde das bemerkt, es gibt da wahrscheinlich keine Warnungen. Ich weiß nicht, wie MediaWiki auf solche Versuche reagiert, sperrt es Anmeldeversuche für gewisse Zeit wenn X Passwörter kurz hintereinander auf einen Account einprasseln? Was ist wenn der Angreifer umgekehrt vorgeht, immer das selbe Passwort nacheinander auf alle Kamelnamen (die sind wie geschrieben, öffentlich). Von anderen Angriffsvektoren schreibe ich da noch garnix. Kamillo (Diskussion) 23:46, 1. Sep. 2021 (NNZ)

Ich werde am WE mal in Ruhe mit Sloyment telefonieren, hoffentlich erreiche ich ihn. Vorher fehlt mir einfach die Zeit. Das Verhalten bei mehreren falschen Logins lässt sich ja einfach testen: Einfach mal einen Opferaccount anlegen und ausprobieren. Ich würde erwarten, dass ab 3 oder 5 Versuchen ein zunehmendes Delay greift, sodass Brute Force Angriffe erschwert sind --Wüstenspitz (Diskussion) 07:23, 2. Sep. 2021 (NNZ)

@Kamillo: Wie wäre es denn, wenn wir mal an alle Kamele mit z.B. mehr als 1000 Edits eine E-Mail schicken? So in der Art "Die Kamelopedia vermisst dich..." --Wüstenspitz (Diskussion) 19:09, 1. Sep. 2021 (NNZ)

Würd ja gerne mal wieder was von meinem Lieblingskamelbruder Kamel:Igor lesen, wieviele Gläschen er inzwischen hat? Oder schnarcht er selbst in einem? *schnief*. Wenn das datenschutzrechtlich in Ordnug wäre, könnte man mal drüber nachdenen, aber vielleicht weckt man damit auch die falschen Geister, wo man eigentlich froh ist, dass man sie los ist? Kamillo (Diskussion) 23:46, 1. Sep. 2021 (NNZ)

Über die Details ließe sich ja verhandeln und eine Auswahl treffen. Datenschutz sehe ich nicht ganz so kritisch, denn wir haben ja außer der Mailadresse keine personenbezogenen Daten und die Adresse haben wir nicht eingekauft sondern wurde uns vom Empfänger selbst gegeben. Damit würde ich die Einwilligung schon mal annehmen. Nur dürfte so eine Auswahl nicht anhand der Adressen öffentlich diskutiert werden sondern anhand des Kamelnamens (Pseudonym). --Wüstenspitz (Diskussion) 07:23, 2. Sep. 2021 (NNZ)

Ein erster Anfang wäre gemacht, wenn generell von allen Null-Edit-Kamele ein Jahr nach der Anmeldung, dessen Kontos automatisch vollständig gelöscht werden, eine Neuanmeldung wäre dann für gelöschte Konten nötig. Des weiteren bei allen inaktiven (ein Jahr nach dem letzten Edit) Kameltreibern oder gar Feenstabschwingern deren Rechte entziehen (zu reinen Herumtreibern machen, ohne Kameltreiber-Status). Bei einer ewentuellen Rückkehr kann man den Herumtreibern Kameltreiber-Rechte wieder zurückgeben Dufo (Diskussion) 09:20, 2. Sep. 2021 (NNZ)

Das sieht schonmal nach einem runden Plan aus. Weg mit den Nullen! Kamillo (Diskussion) 21:28, 2. Sep. 2021 (NNZ)

Wer ein bissle was von Elektrik versteht, weiß dass Nullung sowieso seit vielen Jahren schon verboten ist. Sind sowieso ein Großteil Bots. Vielleicht lässt sich ja eine Möglichkeit schaffen, Accounts automatisch zu löschen, die z.B. vier Wochen nach der Anmeldung noch nichts verzapft haben. --Wüstenspitz (Diskussion) 07:18, 3. Sep. 2021 (NNZ)

Ich vermute sogar, dass solche Scheinaccounts ein Teil bereits laufender Angriffe sind. Schließlich lassen sich manche Lücken nur nach einer Anmeldung ausnutzen. --Wüstenspitz (Diskussion) 07:21, 3. Sep. 2021 (NNZ)

Ich, als selbst ziemlich inaktives Kamel, äußere mal meinen Vorschlag:

1.) Kamelkonten, deren Inhaber zwei Jahre lang keinerlei Aktivität gezeigt haben, werden gesperrt (nicht jedoch deren Kontaktierungsmöglichkeit per E-Mail!). Jungkamele werden auf Dauer gesperrt, wenn sie innerhalb von drei Monaten seit Anmeldung keine Mitarbeit leisten.

2.) Kameltreibern, die ein Jahr lang keinerlei Aktivität gezeigt haben, wird der Treiberstock geklaut.

3.) Für die wegen Inaktivität gesperrten Kamele besteht weiterhin die Möglichkeit des internen E-Mailverkehrs, über den die erneute Freischaltung jederzeit beantragt werden kann.

Betroffene Kamele könnten dann in ihrer Kamelbox durch eine entsprechende, womöglich sogar mit einem Bildchen (siehe rechts) verschönerte Vorlage benachrichtigt werden. So brauchen sie sich nicht zu wundern, dass sie gesperrt sind.

(Nicht unterschriebener Beitrag von Sorgenkamel)

Und, Kamels, wie ist hier der Stand der Dinge? Kamillo (Diskussion) 18:34, 16. Sep. 2021 (NNZ)

Ich bin zur Zeit mehr mit außerwüstlichen Dingen beschäftigt als mir lieb ist. Das wird mindestens noch zwei Wochen so bleiben. Danach, so Sloyment will, greifen wir das greise Servertier vorsichtig an und schieben seinen Rollator Stück für Stück voran. --Wüstenspitz (Diskussion) 00:57, 21. Sep. 2021 (NNZ)

Geht mir ähnlich. Von daher hab ich nix dagegen, wenn wir damit erst in 3 Wochen oder so anfangen. Mööep KamelPatrick (Diskussion) 09:20, 21. Sep. 2021 (NNZ)