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查询。类似这样的问题还很常见，当然了，这也为自己挖洞提供了思路，在挖洞越来越困难的当下，挖洞思路的变化显得十分重要了。