Seite 1 von 1
[3.2] Einbruchsversuch?
Verfasst: 02.09.2017 16:21
von tsk
Hallo,
Ich habe zufällig einen vermutlichen Einbruchsversuch entdeckt:
Auf dem FreeBSD Server sehe ich in /var/log/messages folgende Einträge:
Code: Alles auswählen
Aug 17 02:54:35 turbo postgres[56583]: [3-1] ERROR: column "$H\2y$9TE61ADb5$10\mGuVQ7ixG0zjLxLuslrIOO$QfJA4iz7ouOvtdnduI5Cr" does not exist at character 45
Aug 17 02:54:35 turbo postgres[56583]: [3-2] STATEMENT: UPDATE phpbb_users
Aug 17 02:54:35 turbo postgres[56583]: [3-3] SET user_password = "$H\2y$9TE61ADb5$10\mGuVQ7ixG0zjLxLuslrIOO$QfJA4iz7ouOvtdnduI5Cr.YLV6oUNUO"
Aug 17 02:54:35 turbo postgres[56583]: [3-4] WHERE user_id = 56
Diese Einträge enstehen dann, wenn Forenbenutzer eingeloggt sind, allerdings nicht immer, falls jemand eingeloggt ist. Das tritt selbst dann auf, wenn ich eingeloggt bin. Kann jemand etwas dazu sagen?
Re: [3.2] Einbruchsversuch?
Verfasst: 03.09.2017 15:10
von canonknipser
Das sieht für mich danach aus, als ob dein Datenbanksystem postgres nicht mit dem generierten Passwort-Hash (also die verschlüsselte Form des Benutzer-Kennwortes, dass in der Datenbank abgelegt wird) zurechtkommt und den übergebenen Wert als Spaltennamen (
columns does not exist) betrachtet.
Das Ganze passiert bei einer Passwortänderung, hier beim Benutzer mit der ID 56.
Für die weitere Analyse wäre es wichtig zu wissen
- welche postgres-Version setzt du ein
- welche phpBB-Version setzt du ein (3.2.0 oder 3.2.1)
- welche Erweiterungen hast du installiert?
Re: [3.2] Einbruchsversuch?
Verfasst: 03.09.2017 19:32
von tsk
Danke für deine Anteilname...
a.: Postgres 9.3.1
b.: phpbb3 3.2.1
c.: keine Erweiterungen, nur Sprachen Deutsch Du/Sie
(Es war ein Version von viglink installiert, aber nicht aktiviert. Ich habe die Installation entfernt- keine Besserung... Ich muss gestehen, ich weiss aber auch nicht wie die Installation zustande kam... ev. war es ein Teil der Installation wie nach
https://blog.phpbb.com/2016/12/09/phpbb ... extension/)
Ich glaube nicht, dass das durch eine normale Operation zustande kommt. Die Meldung tritt irgendwie sporadisch auf...
Der Benutzer mit der Nummer 56 ist Administrator...
Ich kann mich jedoch völlig problemlos als Administrator anmelden.
Gibt es eine Möglichkeit phpbb und/oder das php pgsql zu monitoren, also alles was da durch geht in ein File zu protokollieren?
Re: [3.2] Einbruchsversuch?
Verfasst: 03.09.2017 21:13
von tsk
Ich komme der Sache etwas näher:
Die Fehlermeldung tritt immer dann auf, wenn /forum/cron.php?cron_type=cron.task.core.update_hashes 'aufgerufen' wird, also diese:
https://area51.phpbb.com/docs/code/3.2. ... ashes.html Funktion.
Frage: Die Doku sagt etwas über "... gradually update all "old" style hashes ...". Warum 'gradually' und warum für den Administrator (zuerst)?
Also wohl doch kein Einbruchsversuch... aber was soll das, kann man das nicht explizit machen und warum funktioniert's nicht?
Re: [3.2] Einbruchsversuch?
Verfasst: 03.09.2017 21:57
von canonknipser
OK, du hast also keine frische Installation, sondern einen Update einer äteren Version von phpBB 3 (von 3.0.x oder 3.1.x auf 3.2.1)
Bei Sprung auf Version 3.2 wurde der Algorithmus, der zum Erzeugen des Password-Hashes (also der "Prüfzeichenkette"), die für den Abgleich des Kennwortes verwendet wird, geändert von MD5 oder "blowfish" zu "bcrypt". Mit 3.2.1 wurde der cron-Prozess eingebaut, der alte Kennwort-Hashes umstellt auf "bcrypt":
https://tracker.phpbb.com/browse/PHPBB3-15219
Dieser liest die User-DB in Blöcken von 20 (damit es nicht zu viele auf einmal sind = gradually) durch (ohne "ORDER BY"):
https://github.com/marc1706/phpbb/blob/ ... p#L99-L103, d.h. es ist mehr oder weniger Zufall, dass der Admin-Account als erster dran ist , liegt aber ggf. auch daran, dass er der älteste Account mit einem alten Passwort ist,
und macht anschließend einen Update
https://github.com/marc1706/phpbb/blob/ ... #L114-L116
Ggf. ist da was in der postgres-Implementierung nicht ganz sauber. Änder mal das Admin-Kennwort über die phpbb-Oberfläche, ggf. hat der Algorithmus auch "nur" ein Problem mit dem speziellen Kennwort.
Zu Vigilink: Die Extension wird von 3.2 mitgeliefert, aber bei Upgrades nicht aktiviert.
Re: [3.2] Einbruchsversuch?
Verfasst: 04.09.2017 10:31
von tsk
Wir kommen der Lösung näher:
Ja, das ist eine ältere Installation, die mehrfach upgedated wurde.
Wenn ich das Administrator Passwort ändere, bekomme ich jetzt eine ähnliche Fehlermeldung mit der user_id 55, einem anderen Benutzer...
Heisst das, alle Benutzer müssten einmal ihre Passwörter ändern oder gibt es auch eine Möglichkeit diese Updaten korrigierend administrativ zu erzwingen?
Wenn es ein Problem mit Postgres ist, wo kann das sein, doch wohl am ehesten in der php-Schnittstelle php56-pgsql, oder?
Re: [3.2] Einbruchsversuch?
Verfasst: 04.09.2017 16:17
von canonknipser
Ich vermute mal, das postgres (da kenne ich mich nicht in Detail mit aus, aber habe ich mir so aus der Dokumentation angelesen) nicht mit dem Double-Quote
" zurechtkommt.
Ändere doch bitte mal die Zeilen mit dem Update-Statement in der
update_hashes.php Zeile 114 bis 116 wie folgt ab:
Code: Alles auswählen
$sql = 'UPDATE ' . USERS_TABLE .
' SET user_password = ' .
" '" .
$this->db->sql_escape($new_hash) .
" ' " .
'WHERE user_id = ' . (int) $row['user_id'];
Dadurch wird das Double-Quote durch ein Single-Quote ersetzt. Falls das zum Erfolg führt, würde ich einen Bug-Report eröffnen
Edit: Ich hab vorsichtshalber schon mal den Bug aufgemacht:
https://tracker.phpbb.com/browse/PHPBB3-15347
Re: [3.2] Einbruchsversuch?
Verfasst: 05.09.2017 09:46
von tsk
Ja, das scheint das Problem gelöst zu haben. Vielen Dank.
Es gibt da mehrere update_hashes.php. Ich habe das in .../cron/task/core/ benutzt, was offenbar das richtige war.
Zumindest das update_hashes.php in .../console/command/fixup/ scheint das gleiche sql Statement abzusetzten. Müsste man das dort auch anpassen?
Den Bug-Report übernimmst du?
Vielen Dank nochmal!
Re: [3.2] Einbruchsversuch?
Verfasst: 05.09.2017 14:50
von canonknipser
tsk hat geschrieben:Zumindest das update_hashes.php in .../console/command/fixup/ scheint das gleiche sql Statement abzusetzten. Müsste man das dort auch anpassen?
Ja, das muss da auch angepasst werden. Dies ist aber eine Routine, die nur bei Verwendung der expliziten "Update-Hashes"-Funktion über das Command-Line-Interface (CLI) aufgerufen wird. Ich nehme sie mit in das Ticket auf: