Drupal V7.3.1 框架處理不當致使SQL注入

  這個漏洞本是2014年時候被人發現的，本着學習的目的，我來作個詳細的分析。漏洞雖然很早了，新版的Drupal甚至已經改變了框架的組織方式。可是絲絕不影響對於漏洞的分析。這是一個經典的使用PDO，可是處理不當，致使SQL語句拼接從而致使注入的問題。從這個問題，以及以往我見過的不少的漏洞來看，我不得不說，代碼底層作的再安全，過濾的再徹底，若是程序員的一個不當心，也將會致使重大安全問題的出現。多少的編碼繞過，邏輯漏洞正是不當心帶來的問題。

  0x00 注入的定位

  首先我根據網絡上已經出現過的EXP，而後進行追蹤。無奈，這個框架實在太大，我在跟進的過程當中，遇到了諸多的問題，甚至路由模式都沒有搞的很明白。而後根據已有的漏洞細節，我迅速定位到了漏洞的發生點。

  在文件 \modules\user\user.module 中 有 user_login_authenticate_validate() 函數，代碼以下：

  

function user_login_authenticate_validate($form, &$form_state) {
  $password = trim($form_state['values']['pass']);
  if (!empty($form_state['values']['name']) && !empty($password)) {
    // Do not allow any login from the current user's IP if the limit has been
    // reached. Default is 50 failed attempts allowed in one hour. This is
    // independent of the per-user limit to catch attempts from one IP to log
    // in to many different user accounts.  We have a reasonably high limit
    // since there may be only one apparent IP for all users at an institution.
    if (!flood_is_allowed('failed_login_attempt_ip', variable_get('user_failed_login_ip_limit', 50), variable_get('user_failed_login_ip_window', 3600))) {
      $form_state['flood_control_triggered'] = 'ip';
      return;
    }
    $account = db_query("SELECT * FROM {users} WHERE name = :name AND status = 1", array(':name' => $form_state['values']['name']))->fetchObject();

  //省略無關代碼...

 

很明顯，這裏的SQL查詢就是漏洞觸發現場了，咱們跟進db_query這個函數，代碼以下：

  

function db_query($query, array $args = array(), array $options = array()) {
  if (empty($options['target'])) {
    $options['target'] = 'default';
  }

  return Database::getConnection($options['target'])->query($query, $args, $options);
}

繼續跟進query函數：

  public function query($query, array $args = array(), $options = array()) {

    // Use default values if not already set.
    $options += $this->defaultOptions();

    try {
      // We allow either a pre-bound statement object or a literal string.
      // In either case, we want to end up with an executed statement object,
      // which we pass to PDOStatement::execute.
      if ($query instanceof DatabaseStatementInterface) {
        $stmt = $query;
        $stmt->execute(NULL, $options);
      }
      else {
        $this->expandArguments($query, $args);
        $stmt = $this->prepareQuery($query);
        $stmt->execute($args, $options);
      }
    //省略無關代碼...

咱們知道，若是在PHP鏈接MySQL數據庫中，若是咱們使用PDO進行預編譯的話，咱們的語句是沒法改變原有的查詢結構的，也就是說，注入的語句，沒法進行查詢，只能是當作字符串。從而從數據庫查詢層對注入作了完全防護。那麼這裏是怎麼產生問題的呢？

0x01 錯誤的處理致使的安全問題

  可是這裏有個問題，就是當參數是數組的時候，就會用到expandArguments這個方法，而後這個方法因爲處理不當會致使安全問題。

  函數代碼以下：

  

  protected function expandArguments(&$query, &$args) {
    $modified = FALSE;

    // If the placeholder value to insert is an array, assume that we need
    // 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) {
        // 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
        // a duplicate key.  We do not account for that as the calling code
        // is already broken if that happens.
        $new_keys[$key . '_' . $i] = $value;
      }

      // Update the query with the new placeholders.
      // preg_replace is necessary to ensure the replacement does not affect
      // placeholders that start with the same exact text. For example, if the
      // query contains the placeholders :foo and :foobar, and :foo has an
      // array of values, using str_replace would affect both placeholders,
      // but using the following preg_replace would only affect :foo because
      // it is followed by a non-word character.
      $query = preg_replace('#' . $key . '\b#', implode(', ', array_keys($new_keys)), $query);

      // Update the args array with the new placeholders.
      unset($args[$key]);
      $args += $new_keys;

      $modified = TRUE;
    }

    return $modified;
  }

咱們再來回顧一下以前的查詢語句，

db_query("SELECT * FROM {users} WHERE name = :name AND status = 1", array(':name' => $form_state['values']['name']))

這個數組咱們是可控的，首先在array_filter以後，使用foreach進行遍歷，而後二輪遍歷中建立了一個新的數組。接着把$query變量中的鍵，進行了替換，替換掉之後的內容是以前新數組鍵用 ', '進行合併成的一個新的字符串。這樣咱們經過鍵來進行SQL注入就行的通了。注入語句將會經過拼接進入。

0x03 測試

能夠看得很清楚，name數組中的兩個鍵都被拼接進了SQL查詢。

 

0x04 反思

 這裏是挺有意思，也很常見的一個問題。我在開頭的引言中也說了。原本是作好了處理的，可是卻使用了拼接，致使可控的外部數據進入了SQL查詢。相似這樣的問題還很常見，固然了，這也爲本身挖洞提供了思路，在挖洞愈來愈困難的當下，挖洞思路的變化顯得十分重要了。