绕过AppLocker系列之CreateRestrictedToken的利用

本文讲的是 绕过AppLocker系列之CreateRestrictedToken的利用， 大多数时候，绕过AppLocker都会利用可信的Microsoft二进制文件或者配置错误的策略进行代码执行，这些方法都比较简单。但是，我们还有一种通过利用架构设计的漏洞来绕过SPR或AppLocker。特别是在Windows 7和Windows 2008 Server环境中，可以滥用API函数（CreateRestrictedToken）来实现绕过。微软后来发布了一个补丁来解决这个问题。

从命令提示符可以轻易的识别出是否缺少这个补丁：

wmic.exe qfe list | findstr.exe   2532445

AppLocker修补程序丢失

因为没有输出任何内容，所以这表示KB2532445补丁并没有安装。直接尝试执行不受信任的二进制文件就会因为AppLocker的限制而运行失败。

有一个由Michael Bailey开发的PowerShell 脚本，它通过使用SANDBOX_INERT标志来利用API函数CreateRestrictedToken，以便可以允许执行二进制文件。由于该标志禁用了所有规则集合的检查，因此可以绕过AppLocker和软件限制策略。这个漏洞最初是由Didier Stevens发现的，并且在他的博客中进行了完整的记录。

AppLocker Bypass – CreateRestrictedToken

为什么会发生这样的情况呢？让我们来看看 MSDN 是如何定义CreateRestrictedToken这个 API函数的。关于CreateRestrictedToken 函数的SANDBOX_INERT标志，MSDN 有如下描述：

如果使用此值，系统将不会检查AppLocker规则或应用软件限制策略。对于AppLocker，此标志将禁用所有这四个规则集的检查：可执行文件，Windows Installer，脚本和DLL。

在安装过程中创建必须运行提取的DLL的安装程序时，请在SaferComputeTokenFromLevel函数中使用SAFER_TOKEN_MAKE_INERT标志。

我写了一个小的应用程序来进行测试：

HANDLE hToken;
HANDLE hNewToken;
PROCESS_INFORMATION sPI;
STARTUPINFO sSI;
 
if (OpenProcessToken(GetCurrentProcess(), TOKEN_ALL_ACCESS, &hToken))
{
    if (CreateRestrictedToken(hToken, SANDBOX_INERT, 0, NULL, 0, NULL, 0, NULL, &hNewToken))
    {
        memset(&sSI, 0, sizeof(sSI));
        sSI.cb = sizeof(sSI);
        if (CreateProcessAsUser(hNewToken, L"c:testDialog42.exe", NULL, NULL, NULL, TRUE, 0, NULL, NULL, &sSI, &sPI))
        {
            puts("process created");
        }
}

这个程序会启动另外一个程序——Dialog42.exe，我已经使用白名单配置了SRP，但是Dialog42.exe并不在白名单列表中：

但是，当我在我的应用程序中使用SANDBOX_INERT标志启动Dialog42.exe时，就可以正常运行。

原文发布时间为：2017年7月31日

本文作者：丝绸之路 

本文来自云栖社区合作伙伴嘶吼，了解相关信息可以关注嘶吼网站。

原文链接