This loophole broke out yesterday, today only time to see the code.
In Drupal, the execution of SQL statements is done using the PDO model, which generally avoids most injections because the use of placeholders limits the syntax of SQL statements.
But this does not mean absolute security, such as the loophole.
In Drupal's user module, find the User.module:
$account = Db_query ("select * FROM {users} WHERE name =: Name and status = 1", Array (': name ' = = $form _state[' values '] [' Name ']))->fetchobject ();
Here: Name is the placeholder, and its content is derived from the $form_state behind it. Follow this db_query function to see how the form data is processed.
After the toss, found the expandarguments function, the function is to use the parameters of the previous db_query to obtain the final query, it is because the function of the $key value of improper processing caused the vulnerability.
Poc:
Name[0%20;update users set Name%3d ' owned ', pass%3d ' $S $dkikdklivrk0ivhm99x7b/m8qc17e1tp/kmod1ie8v/pgwjtazld ' where UID%3d 1;%23%20%20]=admin&name[0]=111111&pass=shit2&test2=test&form_build_id=&form_id=user_ Login_block&op=log+in
The name array in the POC is the array that is passed into the function, which is then processed using the Expandarguments function.
In the process of processing, a new array is obtained in this way:
$new _keys[$key. '_' . $i] = $value;
This $new_keys is used when the query statement is finally fetched.
$query = preg_replace (' # '. $key. ' \b# ', implode (', ', Array_keys ($new _keys)), $query);
Then the problem comes. If you can control this $key, then we can construct a statement to execute (note: The PDO model can execute multiple statements).
Analyze the POC and debug the function:
As you can see, the expandarguments function is to separate the passed in name layer, and finally bring the key into the final SQL statement generation process. The final query is the SQL statement to be executed, and the problem is that PDO executes multiple, so the UPDATE statement executes successfully.
Due to a sentence: Drupal uses: name for the SQL statement stitching, the Expandargument function will: Name into: NAME0, using: Name_$key0 way to complete, this $key is controllable, so caused by the vulnerability.
The results of the implementation are as follows:
Overwrite my previous admin user. The password in the POC was generated using a build script built into Drupal, the password-hash.sh in scripts.
This vulnerability is also very powerful, because you control the other side of the database, so flexible conditions, will inevitably lead to more patterns of attack means.
The flaw gives me the feeling that "there is no absolute security".
"Reprint Please specify the source"
Drupal 7.31 SQL injection Analytics and POC