译者：牧野之鹰
预估稿费：200RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
前言
LSASS：本地安全权威子系统，是Windows平台上一个用户模式进程，它负责本地系统安全策略（比如允许哪些用户登录到本地机器上、密码策略、授予用户和用户组的特权、以及系统安全审计设置）、用户认证，以及发送安全审计消息到事件日志中。著名的Mimikatz密码抓取工具就是从LSASS进程的内存中获取明文密码的。
正文
Windows NT从第一天开始就支持资源访问审计。任何审计事件最终都会记录到安全事件日志中（Security event log）。要启用审计功能，管理员需要在本地或者组安全策略中配置哪些类型的资源的访问需要被审计，包括是否审计成功和失败。每个要审计的资源都需要添加到系统访问控制列表（SACL）中，该系统访问控制列表决定了哪些类型的访问将被审计。ACL还可以指定将审计限制在特定组中。
最近一条推特激起了我的兴趣，这条推特指出在Windows 10 中的一个改动――为LSASS进程配置了一个SACL。这条推特中还有一张截图，截自一个描述Windows 10 RTM改动的网页。从中我们可知该SACL的引入是为了检测一些工具的使用，比如Mimikatz，它需要打开LSASS进程。但是对于这个目的，它能不能很好的工作呢？
让我们来分析这个LSASS的SACL，先从审计的角度来看看这样做的意义，然后再谈谈为什么这不是检测Mimikatz或者试图访问LSASS内存的类似程序的一个很好的机制。
我们首先设置一个测试系统，以便我们可以验证SACL是否存在，然后启用审计来检查打开LSASS时是否收到审计事件。 我更新了我的一个Windows 10 1703虚拟机，然后安装了NtObjectManager PowerShell模块。
在这里需要注意的几件事情，您必须在打开该进程时请求ACCESS_SYSTEM_SECURITY访问权限，否则您无法访问SACL。 您还必须在访问进程的安全描述符时明确请求SACL。 我们可以将SACL看作是一个SDDL（Security Descriptor Definition Language）字符串，它与来自tweet / Microsoft网页的SDDL字符串相匹配。 但SDDL的表示方法并不能让我们很好的理解SACL ACE（Access Control Entry），所以我会在文中将其扩展。 扩展后的形式表明ACE就是我们所希望的用于审计的ACE，主体用户是Everyone组，对成功和失败事件都启用了审计，并且掩码设置为0x10。
好的，我们来配置这个事件的审计。 我在系统的本地安全策略中启用了对象审计（例如运行gpedit.msc），如下所示：
您不需要重新启动以更改审计配置，因此只需重新打开LSASS进程，就像我们之前在PowerShell中所做的那样，我们应该可以看到在安全事件日志中生成的审计事件，如下所示：
译者：WisFree 预估稿费：200RMB 投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿 写在前面的话 现在已经是2017年了，想必大家一定知道什么是CSRF（跨站请求伪造）了，因为之前关于这个话题的讨论已经有很多了。这种漏洞已经存在了很多年，社区中也有非常详细的文档以及对应的解决方案，目前很多热门的网站开发框架基本上或多或少都实现了相应的缓解方案。 那我们在本系列文章中要讨论什么呢？请大家先思考以下几个因素： 1） 遗留应用缺少CSRF保护； 2） 某些框架的内置CSRF防护机制存在缺陷； 3） 应用程序没有使用已证明安全的框架保护机制； 4） 新的应用程序没有使用提供了CSRF保护功能的现代框架； 因此，对于目前的Web应用程序来说，CSRF仍然是一个相对普遍存在的安全漏洞。 在这篇文章中，我们首先会跟大家深入分析CSRF的工作机制，以及现代应用程序可以采用的安全措施。接下来，我们会给大家提供一份安全解决方案，同学们可以将其用于自己所开发的应用程序之中（不需要对源代码进行任何修改）。最后，我们会给大家测试一种针对cookie的新型扩展，如果它能够成为一种通用标准的话，它将能够消除绝大多数场景下的跨站脚本漏洞。除此之外，我们在GitHub库中提供了本系列文章中所要使用到的代码以及测试样例，有需要的同学可以自行下载。 了解攻击机制 简而言之，CSRF这种漏洞将允许攻击者强迫目标用户代表攻击者发送HTTP请求。这种攻击主要发生在客户端（例如Web浏览器），而在这种场景下目标用户所发送的应用程序信息是完全可信的，因此攻击者就可以成功实现攻击了。对于这种类型的攻击，我们需要关注以下三个因素：使用不安全的HTTP verb ，Web浏览器对cookie的处理、以及跨站脚本漏洞（XSS）。 HTTP标准将verb主要分成了安全的以及不安全的两大类。安全的verb（GET、HEAD以及OPTIONS）主要用于只读操作，使用了这些verb的请求用于返回与被请求资源有关的信息，并且不会对服务器端产生影响。不安全的verb（POST、PUT、PATCH和DELETE）主要用于对资源进行修改、创建和删除操作。但不幸的是，一个HTTP verb本身所要进行的操作是可以被忽略或者被篡改的。 导致HTTP verb使用不当的主要原因在于浏览器对HTTP标准的支持存在缺陷，这是一种历史遗留问题。在XML HTTP Request(XHR)流行起来之前，我们几乎得依靠特定框架和代码库来使用HTTP verb（除了GET和POST之外）。这种限制导致HTTP verb之间的区别界限变得十分模糊，虽然仅凭这一点并不能创建出CSRF的攻击场景，但这也让针对CSRF的保护变得更加难以实现了。对CSRF漏洞"帮助"最大的一个因素，就是浏览器处理cookie的方式了。 在设计之初，HTTP本身是一种无状态协议，即一个请求对应一个响应，请求之间不携带/交换任何的状态信息。为了支持复杂的Web应用程序，cookie就成为了一个维持相关HTTP请求之间状态的解决方案。浏览器的全局Cookie可以跨实例、窗口和标签进行共享，用户需要依赖于Web浏览器来自动化地给每一个请求发送cookie。由于cookie是可以在浏览器中进行访问或修改的，并且缺乏反篡改保护，因此请求状态的保存任务就转移到了服务器管理会话的身上。在这种模型下，服务器端需要生成一个唯一标识符并将其存储到cookie中。每一个浏览器在发送cookie时都需要发送这个唯一标识符，而服务器端就可以根据这种标识符来判断会话的有效性了。当会话终止之后，服务器端会丢弃这个标识 
【技术分享】让我们一起来消灭CSRF跨站请求伪造（上） 阅读原文»
没有评论:
发表评论