Sicherheitslücke im NGB

[p3Eq]

Hallo,

vor ein paar Tagen gab es ja einen Zwischenfall bezüglich einer Sicherheitslücke in der Forensoftware vom NGB. Mich würden dazu ein paar technische Hintergründe und der Ablauf des Angriffs interessieren. Hat dazu jemand ggf. genauere Infos?

Im IRC hab ich bisher hauptsächlich davon gehört, dass möglicherweise ein Script hochgeladen wurde, dass einen bestimmten User mit Adminrechten ausgestattet hat, allerdings würde mich in dem Zusammenhang auch interessieren, durch welche Lücken das Hochladen eines Scripts ermöglicht wurde...

 

[Mr_J]

Ich würde davon ausgehen, dass hier keine genauen Details veröffentlicht werden, da der Fehler ja nicht NGB-spezifisch war sondern es sich um eine allgemeine Lücke in der Software handelt. Von daher würde eine Veröffentlichung die Angriffsmöglichkeit für andere Foren wohl bieten.

MfG
Mr. J

 

[Larius]

Also das mit dem Script hochladen kann ich inzwischen wieder dementieren - der Zugang zum Server selbst blieb sauber, da ist niemand reingekommen.

Bzgl. Veröffentlichung: Naja, es ist ein Exploit der sich einfach umgehen lässt. Kurz zusammengefasst: Es git einen Install Ordner wo alles für Install + Update drinnen liegt. Das hat eine Lücke wodurch es möglich ist, Module hochzuladne. Module sind nichts anderes als PHP/Javascript Code, was sich dadurch ausnützen lässt das man dann einfach eine PHP Variable verwendet um einen gewissen Codeabschnitt zu triggern. Tada, schon kann man sich da mit etwas Wissen was zusammenhämmern, was dazu füht das ein User adminrechte kriegt.

Hässlich, effektiv, aber leicht zu fixen - einfach Install Ordner kübeln. Fugo kann euch da mehr dann erklären

 

[Baer]

You do not have permission to view link please Anmelden or Registrieren

Gruß
Baer

 

[Kugelfisch]

Das Problem war in der Tat, dass aus dem install-Ordner nur das Installationsskript (install.php), nicht jedoch das Upgrade-Skript gelöscht wurde. Das ist natürlich ein peinlicher Fehler, da man ohnehin das gesamte Installationsverzeichnis löschen sollte, bevor man ein Board öffentlich zugänglich macht. Ausserdem war die Schwachstelle öffentlich bekannt, trivial ausnutzbar, und ich kannte sie bereits, bevor sie bekannt wurde. Ich habe die vBulletin-Instanz nicht installiert (deshalb habe ich auch nicht die User-ID 1), allerdings bereits vor Wochen `überprüft`, ob das install-Verzeichnis noch vorhanden ist - unglücklicherweise mit einem `ls isntall` statt `ls install`, was natürlich keine Treffer lieferte.

Über die Schwachstelle im upgrade-Skript lässt sich ein Admin-Account mit beliebigen Zugangsdaten anlegen. Meine Analyse hat gezeigt, dass der Server nicht kompromittiert wurde und die einzige im Admin-CP vorgenommene Aktion das Löschen von drei Kategorien war, sowohl gemäss vB-Admin als auch gemäss Webserver-Access-Log. Dateien wurden keine verändert, die Datenbank per Binlog auf den Zustand nach der letzten Änderung vor dem kompromittierenden `INSERT INTO user ...`-Query zurückgesetzt.



Konket ruft upgrade.php nach dem Laden einiger Bibliotheken

$verify =& vB_Upgrade::fetch_library($vbulletin, $phrases, '', !defined('VBINSTALL'));

auf. Die vB_Upgrade-Klasse lädt und initialisiert dann eine vB_Upgrade_Ajax-Instanz, da sie über einen Webserver aufgerufen wurde (das Skript liesse sich auch auf der Kommandozeile ausführen). Deren init()-Methode benutzt vom Benutzer übermittelte Daten, um festzustellen, an welcher Stelle im Upgrade-Prozess man sich befindet und welcher Schritt als nächster zu erledigen sei:

$this->process_step($this->registry->GPC['version'], $this->registry->GPC['step'], $this->registry->GPC['startat'], $this->registry->GPC['checktable'], $this->registry->GPC_exists['response'] ? $this->registry->GPC['response'] : null, $this->registry->GPC['firstrun'], $this->registry->GPC['only'], $this->registry->GPC['htmlsubmit'], $this->registry->GPC['htmldata'], $this->registry->GPC['options']);

wobei $this->registry->GPC teilweise bereinigte GET/POST/COOKIE-Daten enthält. Interessant ist der erste Parameter, welcher festlegt, von welcher Version aus das Upgrade stattfinden soll. Im install/includes-Verzeichnis existieren php-Dateien mit jeweils einer Klassendefinition für jede Version (z.B. class_upgrade_4112.php, welche die Klasse vB_Upgrade_4112 implementiert). Allerdings existiert auch eine Datei namens class_upgrade_install.php, welche die für die initiale Installation vorgesehene Klasse vB_Upgrade_install implementiert. Da an keiner Stelle geprüft wird, ob der Wert von $this->registry->GPC['version'] der tatsächlichen Version entspricht, kann ein Angreifer den Wert `install` übergeben, um die Klasse für die Installation zu laden.
Jede dieser Klassen definiert einen oder mehrere Installations-/Upgradeschritte. Bei welchem Schritt sich der Benutzer gerade befindet, wird in $this->registry->GPC['step'] übergeben. Auch dieser Wert wird nur in eine Zahl konvertiert, aber keiner weiteren Prüfung unterzogen.

In vB_Upgrade_install ist Schritt #7 von entscheidender Bedeutung:

	/**
	* Step #7 - Default User Setup...
	*
	*/
	function step_7($data = null)
	{
/* ... */
				$salt = fetch_user_salt(SALT_LENGTH);
				/*insert query*/
				$this->db->query_write("
					INSERT INTO " . TABLE_PREFIX . "user
						(username, salt, password, email, usertitle, joindate, lastvisit, lastactivity, usergroupid, passworddate, options, showvbcode)
					VALUES (
						'" . $this->db->escape_string(htmlspecialchars_uni($data['htmldata']['username'])) . "',
						'" . $this->db->escape_string($salt) . "',
						'" . $this->db->escape_string(md5(md5($data['htmldata']['password']) . $salt)) . "',
						'" . $this->db->escape_string($data['htmldata']['email']) . "',
						'" . $this->db->escape_string($this->phrase['install']['usergroup_admin_usertitle']) . "',
						" . TIMENOW . ",
						" . TIMENOW . ",
						" . TIMENOW . ",
						6,
						FROM_UNIXTIME(" . TIMENOW . "),
						$admin_useroption,
						2
					)
				");
	}

In diesem Schritt wird bei der Installation ein Benutzer mit administrativen Rechten angelegt. Das Problem ist, dieser Schritt lässt sich aufgrund der Schwachstelle auch über das upgrade.php-Skript auslösen, indem man per POST version=install und step=7 übergibt. Die initialen Zugangsdaten stammen ebenso aus per POST übergebenen Benutzerdaten, lassen sich vom Angreifer also frei wählen.

Es existieren inzwischen auch fertige Exploits, um die Schwachstelle auszunutzen, z.B.

You do not have permission to view link please Anmelden or Registrieren

.

 

[Baer]

Du sollst dich nicht grämen!
Das zeigt doch schön dass du keine Maschine bist sondern auch nur ein Mensch. Das beruhigt mich zum Beispiel ungemein.

Mund abwischen und weiter gehts...

Gruß
Baer

 

[gelöschter Benutzer]

das Problem haben oder hatten somit wohl auch andere boards?

 

[Kugelfisch]

Wenn sie vBulletin einsetzen und das install-Verzeichnis (oder zumindest das Upgrade-Skript) nicht löschen, ja.

 

[keksautomat]

Es gehört doch zum kleinem 1x1, dass man das Install Verzeichnis löscht oder umbenennt / Rechte entzieht, oder nicht? :/ Naja, nun weiß mans für die Zukunft.
Ps: Ich wusste gar nicht, dass vB so häßlich aufgebaut ist mit Querys.

 

[Kugelfisch]

Selbstverständlich. Wie erwähnt, die Schwachstelle war mir bekannt und ich habe auch überprüft ob das install-Verzeichnis noch vorhanden war, nur leider aufgrund eines Tippfehlers an entscheidender Stelle angenommen, es wäre gelöscht.

 

[p3Eq]

Hey Kugelfisch,

danke für die ausführliche Erklärung!

Die Sicherheitslücke ist in der Tat sehr trivial, aber Fehler passieren jedem mal. Und da die Datenbank ja nahezu komplett wiederhergestellt werden konnte, ist das Ganze ja noch vergleichsweise glimpflich abgelaufen

 

[gelöschter Benutzer]

Beruhigend zu wissen das der Fisch auch nur ein Mensch ist.

 

[Ruby]

Und ich hab immer gedacht, Kullerchen wäre ein Fisch und kein Mensch.

Na ja, zu Sushi würden wir ihn eh erst dann verarbeiten, wenn unsere Daten zur NSA wandern.

Also sei ganz gechillt, Fehler können passieren, aber es ist ja nichts passiert.

 

[p3Eq]

Na ja, zu Sushi würden wir ihn eh erst dann verarbeiten, wenn unsere Daten zur NSA wandern.

Dafür müssten wir ihn erstmal finden und das könnte schon eine Herausforderung sein, die wir nicht bewältigen können

 

[NoName1954]

wenn unsere Daten zur NSA wandern.

Wenn du wüsstest, was die NSA längst weiß...

 

[Cyperfriend]

Woher zum Geier weist du, dass du nach "isntall" gesucht hast? Loggst du deine eigenen Aktivitäten penibler als die NSA und das über Wochen oder war das nur ein Beispiel?

Wenn du dich aber so sehr ärgerst Kugelfisch, dann stell dich zwei Minuten in eine Ecke und wir vergessen die Sache

 

[keksautomat]

.bash_history