sunloginl rce漏洞分析

首先分析二进制文件，拖入ida

发现被加壳，die（detect it easy）查壳发现是upx，使用github官方的upx最新版脱壳即可

1	upx -d xxx.exe

注意最新的工具脱壳后无法直接执行，应该是upx在加壳的过程中将基址存在了某个寄存器或内存中，而脱壳过程中将这段代码删除了，导致无法找到对应的基址。

但是可以拖入ida进行分析

脱壳后拖入ida进行分析，脱壳后针对于SunloginClient_11.0.0.33162_X64文件关键函数偏移为0xE1D0DE，和start函数的offset为0x2DAFDE

verify-haras功能点为本次出现敏感信息泄露的关键功能，下面根据补丁对比看下实际功能

补丁对比

查看补丁前和补丁后泄露CID的接口，其中sub_1400F0690函数用于http response

补丁前

补丁后将相关的功能点删除了

信息泄露

这里我将详细的调试以及跟踪过程都放入了文章，方便感兴趣的小伙伴自己调试复现，说不定会发现惊喜。

由于脱壳后程序无法执行，所以笔者采用了带壳调试的方式，调试方式为首先运行待调试程序，然后找到开放端口的向日葵进程，之后attach入该进程即可调试。

具体做法就是通过esp定律定位到oep，之后通过相对偏移在关键位置下断点，而带壳调试有两个比较麻烦的点，一是定位关键代码相对来说困难一些，二是无法观察函数调用栈，因为都是在壳函数中完成的所有操作。

上面已经得出，我个人的SunloginClient_11.0.0.33162_X64文件

1	lea rdx, aVerifyHaras ; "verify-haras"

偏移为0xE1D0DE，和start函数的offset为0x2DAFDE，所以根据偏移在动态调试时下硬件断点（软件断点无法跟入到该代码处，暂时不清楚原因），之后保持向日葵在运行状态，之后浏览器访问

1	http://ip:port/cgi-bin/rpc?action=verify-haras

程序将会断在上述指令处。

之后单步执行，观察函数传入的参数，rcx与rdx均为verify-haras。

之后调用了函数，返回值为"dmPqDgSa8jOYgp1Iu1U7l1HbRTVJwZL3"，暂时不清楚该字符串代表什么含义，也不清楚不同次的执行该字符串是否会变化

之后调用函数将两个字符串拼接，查看返回值（也就是rax寄存器）证实了我们的猜想。这时我们可以解决刚刚的疑惑，也就是说第二个字符串就是CID（但是这里我们已经知道漏洞详情从而分析漏洞，如果没有知道漏洞详情，那么该漏洞的挖掘就是一门技术活了）。

之后相应包中就带上了CID相关的信息

这时候我们比较好奇，为什么要拼接这样的get请求来达到信息泄露的目的呢，通过ida查看该函数的交叉引用（下面对应的解释以及注释均为笔者根据调试自己的漏洞环境得出的结论，详细的调试过程就不贴出了）

可以看到验证了cgi-bin/rpc的接口，向上查看，发现还有

login.cgi

cgi-bin/login.cgi

express_login

desktop.list

cloudconfig

transfer

micro-live/enable

check

getfastcode

assist

projection

getaddress

在查找字符串的时候也发现了对应的注册，上面图片里面的逻辑其实就是449行对应的函数

这时我们向下找，在该函数中，我们可以看到在处理action时，通过第266行获得了action的参数值并放入action_parameter变量中。

接下来拿获取到的参数值与字符串verify-haras做对比，如果匹配，则进入if逻辑，很显然，我们构造的action的参数值就是verify-haras，进入if逻辑后，if里面的Src存放了http的响应包，这里第398行调用了函数来生成一串随机字符串，该随机字符串就是CID，最后将拼接后的Src返回给用户，即泄露了CID（注意这里的CID是每次请求都会变化的）。

可以看下403行对应释放内存的逻辑，14行将原来索引到CID对应内存的指针的最后一位置为0，所以通过偏移是可能索引到被释放的内存的，有引发内存错误的风险，

调试tips

在字符串ida字符串搜索时看到了很多带有cgi-bin/rpc对应的关键字，比如

比如

还比如

具体定位方式实际上就是给每个cgi-bin/rpc的位置处下断点，简单有效，实际上动态调试的目的也在于此，当某个变量的含义不确定或者判断某段代码是否会执行，或者调试exp时观察是否会执行对应逻辑都很有效果。

还有需要注意的一点

调试程序时如果出现派生进程以及多线程，一定要attach对应的漏洞进程，否则可能无法断在断点处。多线程调试时如果只关注某个功能点，可以将其他进程暂时挂起（比如这里的cgi-bin）.

ida_verify_haras: 140E1D0DE

ida_action： 140E1CC51

1： 140594909 88 87D5

2： 140595253 887e8b

3： 140E2173E 4660

debug_verify_haras： 00007FF76698D0DE

1： 7FF7 6610 4909

2： 7FF7 6610 5253

3： 7FF7 6699 173E yes

代码执行

上面已经统计了开放的接口，直接找check对应的处理函数

跟进246行，在处理cmd参数时，比对了两个参数值ping和nslookup

而这两个参数值存在rce漏洞

ida_cmd_parameter： 140E1B905

之后执行了167行的逻辑

调用了CreateProcess执行了传入的命令

调试可以明显观察到执行了CreateProcessA进程

执行ReadFile后，将执行后的结果放入Buffer指向的内存中了。

这时有一个问题，既然直接给ping或nslookup传递拼接的命令就可以执行任意代码，那为什么要在cookie中传入CID呢。cookie中的CID的作用是什么呢，我们在函数中没有看到对应的校验逻辑，下面的图就是执行代码的逻辑，可以看到只有v21是个类似于校验的值，但仔细分析发现，v21只可以判断参数名称是否为ping或nslookup。

笔者在复现的时候走了些许弯路，尝试了寻找CID、cookie对应的字符串，发现没有在任何一处断点断下。

这里有一个比较坑的一点在于：ida的shift+f12并不能发现所有注册的字符串，有些明显的字符串形式并没有被shift+f12统计到，所以我们在分析代码逻辑时不要过度依赖于shift+f12的功能（比如在查找cgi-bin/rpc字符串时，shift+f12就没有统计到关键代码位置）

最后通过错误信息定位到CID校验点

通过流量可以发现，当我们不传入CID时，response body返回了报错信息，这时我们通过这个报错信息到ida中查找

将上面两个函数对应报错位置处下断点，很容易发现实际上是第二个函数做了校验

下面是不断尝试所得到的数据=(

ida_verify_haras: 140E1D0DE

ida_cid_1： 1409F5BF1 -42 74ED

ida_cid_2： 140204F9A -C1 8144

ida_cid_3： 140112979 -D0 A765

ida_cid_4： 140E209B8 38DA

debug_verify_haras： 00007FF76698D0DE

debug_cid_1： 7FF7 6656 5BF1 -42 74ED

debug_cid_2： 7FF7 65D7 4F9A -C1 8144

debug_cid_3： 7FF7 65C8 2979 -D0 A765

debug_cid_4： 7FF7 6699 09B8 38DA

ida_verify_haras: 140E1D0DE

ida_cookie_1： 140204F3F -C1 819F

ida_cookie_2： 14057F7D8 -89 D906

ida_cookie_3： 1409F4A60 -42 867E

ida_cookie_4： 140111141 -D0 BF9D

ida_cookie_5： 14014D5AA -CC FB34

debug_verify_haras： 00007FF7142ED0DE

debug_cookie_1： 7FF7 136D 4F3F

debug_cookie_2： 7FF7 13A4 F7D8

debug_cookie_3： 7FF7 13EC 4A60

debug_cookie_4： 7FF7 135E 1141

debug_cookie_5： 7FF7 1361 D5AA

ida_verify_haras: 140E1D0DE

ida_verification_failture_1: 14020528F C1 7E4F

ida_verification_failture_2: 140E13659 9A85

debug_verify_haras： 00007FF7142ED0DE

debug_verification_failture_1: 7FF7 136D 528F

debug_verification_failture_2: 7FF7 142E 3659 yes