Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security VulnWatch
[Top] [All Lists]

MySQL Anonymous Login Handshake - Information Leakage.

Subject: MySQL Anonymous Login Handshake - Information Leakage.
Date: Tue, 02 May 2006 15:40:02 +0200
~.oOOo. Anonymous Login Handshake .oOOo.~
=========================================

MySQL Server (<= 4.1.18, 5.0.20 )  has an information 
leakage in the way mysql parses login packets on anonymous 
users (blank password).

Author: Stefano Di Paola
Vulnerable: Mysql <=   4.1.18, 5.0.20
Type of Vulnerability: Local/Remote - input validation - Information
Leakage
Tested On :  Debian 3.1 - IA32.
Vendor Status: Notified on April, 25th 2006, Confirmed on April, 26th
2006, New versions released on 2nd May 2006.
Fixed: Update to 4.0.27, 4.1.19, 5.0.21, 5.1.10 versions.

A Proof of Concept is Attached for this issue.
Tested on: Debian 3.1 - IA32.


A little Note:
To take advantage of these flaws an attacker should have direct access
to MySQL server communication layer (port 3306 or unix socket).
But if used in conjuction with some web application flaws 
(i.e. php code injection) an attacker could use socket programming
(i.e. php sockets) to gain access to that layer.

-- Description

By crafting a specifically malformed login packet, initial db name is
filled with uninitialized memory content.


Let's suppose MySql Server has anonymous access.

Infact, if we want to use 'wisecdb' database as user 'wisec' and
password 's'  a normal client would send a packet like this:
---------------------------------------------------------------
43  00  00  01  0d  a6  03  00  00  00  00  01  08  00  00  00
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
00  00  00  00  77  69  73  65  63  00  14  aa  69  23  07  2a
ff  99  61  a3  c4  5f  04  66  3b  32  ef  a1  f2  b6  59  77
69  73  65  63  64  62  00
C   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .
.   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .
.   .   .   .   w   i   s   e   c   .   .   .   i   #   .   *
.   .   a   .   .   _   .   f   ;   2   .   .   .   .   Y   w
i   s   e   c   d   b   .
---------------------------------------------------------------

but if we look at the code (MySQL <= 5.0.20)
on sql_parse.cc line ~  993
        function  check_connection(THD *thd):
--      
  char *user= end;
  char *passwd= strend(user)+1;
  char *db= passwd;
  char db_buff[NAME_LEN+1];                     // buffer to store db in
utf8
  char user_buff[USERNAME_LENGTH+1];            // buffer to store user
in utf8
  uint dummy_errors;

  uint passwd_len= thd->client_capabilities & CLIENT_SECURE_CONNECTION ?
    *passwd++ : strlen(passwd);
  db= thd->client_capabilities & CLIENT_CONNECT_WITH_DB ?
    db + passwd_len + 1 : 0;
[1]
  /* Since 4.1 all database names are stored in utf8 */
  if (db)
  {
    db_buff[copy_and_convert(db_buff, sizeof(db_buff)-1,
                             system_charset_info,
                             db, strlen(db),
                             thd->charset(), &dummy_errors)]= 0;
    db= db_buff;
  }
        
--

It can be noticed a check for packet construction is missing here[1].

Just replace the null byte at the end of username 
'wisec\0' with any other byte like this 'wisec0'.
What happens?

user is assigned to some part of the packet content, and db is assigned
with some (internal) memory beyond packet_length.

so if we send a specifical packet we'll get an error message like this: 

Access denied for user ''@localhost to database 'lqt'

By changing packet lenght (db length) and with a little bit of luck a
malicious user could get sensitive informations such as parts of queries
and or response executed by some previously logged user.

-

The fix:

bugs are fixed in 4.0.27, 4.1.19, 5.0.21, 5.1.10.
You can download them on http://dev.mysql.com/downloads/


=================================================

==Anonymous packet information leakage poc : 

my_anon_db_leak.c

  Compile with:
  gcc my_anon_db_leak.c -o my_anon_db_leak
  
  usage:
  my_anon_db_leak  [-s path/to/socket] [-h hostname_or_ip]
[-p port_num] [-n db_len]


Example 
$ my_anon_db_leak -s /tmp/mysql.sock -n 20


Regards,

Stefano

-- 

......---oOOo--------oOOo---......
Stefano Di Paola
Software Engineer
Email: stefano.dipaola_at_wisec.it
Email: stefano.dipaola1_at_tin.it
Web: www.wisec.it
..................................

Attachment: my_anon_db_leak.c
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>
  • MySQL Anonymous Login Handshake - Information Leakage., Stefano Di Paola <=