Forum:Serversicherheit: Wie mit inaktiven Kamelaccounts verfahren?

Forum > Serversicherheit: Wie mit inaktiven Kamelaccounts verfahren?

Hinweis: Dieser Fred wurde seit 1166 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)

@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)