| 关联规则 | 关联知识 | 关联工具 | 关联文档 | 关联抓包 |
| 参考1(官网) | |
| 参考2 | |
| 参考3 |
SandboxEscaper！
[出自:jiwo.org]
这次我按照SandboxEscaper博客操作了一遍，记录复现笔记。
原文：
https://sandboxescaper.blogspot.com/2019/12/chasing-polar-bears-part-one.html
Process Monitor
https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
vmware 15.0
https://download3.vmware.com/software/wkst/file/VMware-workstation-full-15.0.0-10134415.exe
密钥：YC74H-FGF92-081VZ-R5QNG-P6RY4
如果你的vmware版本比15.0高，您需要卸载当前的版本，并准备一份适用于15.0的系统镜像用来给vmware15.0用，这个镜像需要是多核，因为这个漏洞需要竞争条件来利用，关于恢复您可以卸载vm然后安装原来的版本，这并不会影响到您原来的镜像。
安装vmware后继续安装vmtools.exe,15.0的vmware安装的vmware tools初始版本是10.0版本，在本次复现的漏洞影响版本范围中。
另外不要忘记新建普通用户并登录以及您的管理员密码。
安装vmware tools后C:\Windows\Installer的目录下文件如下图所示（这个文件夹保存着所有基于Windows Installer安装的应用软件的注册信息,要显示它需要打开显示隐藏的文件夹并显示收系统保护的文件夹)
最大的那个就是SandboxEscaper博客里所说的vmware tools的msi文件（.msi是微软格式的安装包）
接下来我将对它进行为分析，不过在这之前需要过滤一些操作
应该只需要关注msiexec.exe（用于安装MSI的进程）的操作，CreateFile操作
执行5vmware tools mis文件命令 。
接着会弹出一些对话框，在要求重启时选择否。
此时再来查看Process Monitor会多出38000多个CreateFile操作
让我们再此过滤。某些事件的属性会是模拟用户操作，过滤掉它。
这里可以不用填写全部名，关键字desktop即可(电脑名)
ok,还剩28000多，让我们再过滤一次，这次我们需要排除用户没有权限写入的目录，C:\Windows和C:\Program Files，然后只包含system权限的操作
这时候再次再来观察：还剩下10000多行为
这个时候可以导出设置保存下来，下次再导入不用在一遍一遍设置了，
根据SandboxEscaper博客描述我们接下来需要找到C:\ProgramData文件夹（这个文件夹是隐藏的,它包含了应用缓存数据，对所有用户共享），不过作为普通用户我们有权限进行写入，这里可以发现点击属性没有写入权限，点击高级查看却有写入权限
也许属性里的写入是指能不能修改文件夹下原本有的文件内容，而高级里的写入指的是能不能在该文件夹下新建文件，如果是这样倒是说得通。
SandboxEscaper说我们需要过滤C:\ProgramData\VMware\VMware CAF\pme\scripts\stop-listener.bat，因为vm tools的安装包在构造stop-listener.bat存在漏洞
我只过滤掉了C:\ProgramData\VMware\VMware CAF\pme\scripts，最后只剩下300多条
找到stop-listener.bat！
之后在操纵记录中可以找到两次Createfile失败，请注意，这是一个漏洞点。
继续观察，很明显，该目录下的其他文件也有这样的问题。
继续根据SandboxEscaper博客描述操作
接下来过滤掉C:\ProgramData\VMware\VMware CAF\pme\scripts\stop-listener.bat
以及取消CreateFile的过滤
再次查看，这次能够更清楚的看到漏洞点
在上图中我们可以看到在两次Createfile之前进行了SetRenameInformationFile操作，函数rename( )和MoveFileA( )被调用时都会触发SetRenameInformationFile操作。
虽然我不明白这个.msi为何要在SetRenameInformationFile后调用Createfile为何失败，这波操作很奇怪，谁知道设计这个.mis的人怎么想的呢，但是漏洞点其实就是Createfile失败，如果我们能在Createfile失败之前创建相同的文件C:\ProgramData\VMware\VMware CAF\pme\scripts\stop-listener.bat
那么它会被设置属性成当前用户完全控制，也就是说我们创建的权限会被覆盖。
让我们看看SandboxEscaper是如何利用漏洞的
int main() { HANDLE thisthread = GetCurrentThread(); SetThreadPriority(thisthread, THREAD_PRIORITY_TIME_CRITICAL); HANDLE testhandle = NULL; do { CloseHandle(testhandle); testhandle = CreateFile(L"C:\\ProgramData\\VMware\\VMware CAF\\pme\\scripts\\stop-listener.bat", GENERIC_WRITE, FILE_SHARE_READ, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED, NULL); // no attr. template) } while (testhandle == INVALID_HANDLE_VALUE); CloseHandle(testhandle); return 0; }
触发过程，创建线程接着提升该线程权限，接着无线创建C:\ProgramData\VMware\VMware CAF\pme\scripts\stop-listener.bat，然后等待Createfile来覆盖C:\ProgramData\VMware\VMware CAF\pme\scripts\stop-listener.bat权限
最后获得stop-listener.bat权限，前面说到C:\ProgramData\VMware\VMware CAF\pme下的其他文件也有此类漏洞，所以它们也可以被利用。
关于利用SandboxEscaper谈到此文件没有办法被system进程执行，好吧，我也想不到，最后vmware修复了此漏洞，并且很有趣的是给了它一个本地提权的标识
一点感触：
因为我更相信SandboxEscaper是从几万个行为去找到的漏洞，所以我觉得这类漏洞完全可以只通过良好的过滤机制和审计行为来发现。
为了解Process Monitor的特性，我决定好好记录下Process Monitor的一些使用方法以及操作描述,我尝试了访问菜单上的每个选项，下面是会有用的快捷键
开始记录: ctrl+e
清屏: ctrl+ x
跳转到当前事件操作的路径 ctrl+ j
自动滚条 ctrl+ a
重置过滤器: ctrl+ r
捕捉线程事件 ait+o+p
打开进程树 ctrl+ t
转到事件：进程树进程列表中选定进程接着按下转到事件过滤器对应进程会被同时定位
包括进程：只包括进程树进程列表中选中的进程。
包括子树：只包括进程树进程列表中选中的进程，同时也包括进程创建的进程
至于 Process Monitor操作描述部分和详细部分这部分非常重要，但是有万能的Google大法。
继续跟踪SandboxEscaper的博客，发现一些策略。这是关于过滤器部分，它代表了您需要寻找什么。怎么寻找。
任意文件创建|任意文件写入
过滤器内容：包含createfile，过滤完整性中和低,排除模拟用户操作。
任意文件读取
过滤器内容：包含readfile，过滤完整性中和低,排除模拟用户操作，如果一个高权限进程从用户可写的文件读取内容并写入另一个文件，那么它将非常有用。
任意文件删除
这里我当个搬运工。过滤内容：详细信息包含delete，过滤完整性中和低,排除模拟用户操作
上面的所有过滤操作都是必须的，如果只是包含上面过滤消息还是会很多，所以得加上特定进程，以及考虑是否包含c:\windows,和c:\program files等用户无法写入文件的目录
后面SandboxEscaper谈到了这有关一种利用方式https://www.cyberark.com/resources/threat-research-blog/follow-the-link-exploiting-symbolic-links-with-ease 这个家伙主要讲的目录链接+符号链接利用
在跟着操作到这时我接触到了目录链接(在网上有看到好多别名，也叫软链接和NTFS 交汇点)
在命令行中使用MKLINK /J 创建它
创建一个123目录链接，如下图
它和符号链接类似，但只能用于本地上，只能链接到目录。
可以对没有访问权限的目录创建一个目录链接，但是该目录链接也会同样无法访问。
同样的也可以对没有写入权限的目录创建目录链接，但是无法对目录链接无法写入。
如果有对目标目录写的权限，那么对该目标目录创建的在目录链接下的做的任何文件操作都会影响到目标目录。
所以，无论怎么样目录链接都可以被创建除非目录链接所在的路径没有写入权限，另外，目录链接删除不会影响到原来的目录，但时对目录链接下的文件操作会影响到目标目录，这很有趣，不是吗？
Process Monitor看目录链接的特性，我通过打开123下的文件操作，但是结果却只显示了链接的目标目录的信息 但在结果中有REPARSE显示
下面是它和符号链接以及硬链接的区别
关于更多它的信息您可以查看https://stackoverrun.com/cn/q/2356048
如果在CreateFile时没有加上FILE_FLAG_OPEN_REPARSE_POINT 标值时，文件不会判断处理的文件是不是链接
当加上FILE_FLAG_OPEN_REPARSE_POINT 标志对绝对路径的判断也会产生问题，比如解析c\windows\123时只会判断123是不是链接而不是windows是不是链接。
#define FILE_FLAG_OPEN_REPARSE_POINT 0x00200000
在这里抛出一个问题，对于SandboxEscaper利用目录链接来利用这部分我未研究明白，即使把文件目录解析成文件目录链接又如何呢，向我前面所说的，如果对目标文件没有写入权限，那么对目录链接下的文件同样也没有写入权限，难道对目标目录的文件操作还能重新修改目录链接权限？
来自SandboxEscaper的结论：
这种类型的bug非常容易找到和利用。困难的是知道去哪里看。但是知道该去哪里寻找主要取决于坚持不懈和不断尝试，直到你找到一些东西。
