SIGRED – 进入域管理员权限：利用 WINDOWS DNS 服务器中存在 17 年之久的漏洞
DNS 常被描述为“互联网电话簿”，是一种将人性化的计算机主机名转换为 IP 地址的网络协议。由于 DNS 是互联网的核心组件，因此目前有许多 DNS 服务器解决方案和实现，但只有少数几种得到广泛使用。
“Windows DNS 服务器”是 Microsoft 的实现，是 Windows 域环境的重要组成部分和要求。
SIGRed (CVE-2020-1350) 是 Windows DNS 服务器中的一个可感染蠕虫的严重漏洞（CVSS 基本评分为 10.0），影响 Windows Server 2003 至 2019 版本，并可能由恶意 DNS 响应触发。由于该服务以提升的权限（SYSTEM）运行，如果成功利用，攻击者将获得域管理员权限，从而有效地破坏整个公司基础设施。
DNS 常被描述为“互联网电话簿”，是一种将人性化的计算机主机名转换为 IP 地址的网络协议。由于 DNS 是互联网的核心组件，因此目前有许多 DNS 服务器解决方案和实现，但只有少数几种得到广泛使用。
“Windows DNS 服务器”是 Microsoft 的实现，是 Windows 域环境的重要组成部分和要求。
SIGRed (CVE-2020-1350) 是 Windows DNS 服务器中的一个可感染蠕虫的严重漏洞（CVSS 基本评分为 10.0），影响 Windows Server 2003 至 2019 版本，并可能由恶意 DNS 响应触发。由于该服务以提升的权限（SYSTEM）运行，如果成功利用，攻击者将获得域管理员权限，从而有效地破坏整个公司基础设施。
“土耳其鼠”在大规模持续网络钓鱼活动中进化了 ADWIND
Check Point 研究人员正在跟踪一场不断发展的恶意垃圾邮件活动，该活动针对 80 多家土耳其公司。该恶意软件使用不同的规避方法来绕过安全解决方案。
初始攻击媒介始于包含 Office 文件附件的网络钓鱼电子邮件。该文件采用已有 20 年历史的BIFF 格式，无法通过常见的 Office 解析工具进行解析。在下一阶段，会下载恶意 Jar 文件。此文件经过大量混淆，并采用多种规避技术来避免被安全产品检测到。然后，jar 文件会植入 Adwind RAT（一种多平台恶意软件），该恶意软件被配置为窃取敏感信息并将其发送到攻击者的命令和控制 (C&C) 服务器，同时获得对受害者机器的远程访问权限。
所有这些文件在 Virus Total 中的检测率都非常低，很可能是因为混淆程度太高。
攻击者向受害者发送恶意电子邮件。
受害者触发恶意内容。
从 GitHub 存储库下载了恶意 RAT。
该恶意软件与其 C＆C 服务器建立连接。
Check Point 研究人员正在跟踪一场不断发展的恶意垃圾邮件活动，该活动针对 80 多家土耳其公司。该恶意软件使用不同的规避方法来绕过安全解决方案。
初始攻击媒介始于包含 Office 文件附件的网络钓鱼电子邮件。该文件采用已有 20 年历史的BIFF 格式，无法通过常见的 Office 解析工具进行解析。在下一阶段，会下载恶意 Jar 文件。此文件经过大量混淆，并采用多种规避技术来避免被安全产品检测到。然后，jar 文件会植入 Adwind RAT（一种多平台恶意软件），该恶意软件被配置为窃取敏感信息并将其发送到攻击者的命令和控制 (C&C) 服务器，同时获得对受害者机器的远程访问权限。
所有这些文件在 Virus Total 中的检测率都非常低，很可能是因为混淆程度太高。
攻击者向受害者发送恶意电子邮件。
受害者触发恶意内容。
从 GitHub 存储库下载了恶意 RAT。
该恶意软件与其 C＆C 服务器建立连接。
F5 BIG-IP hsqldb(CVE-2020-5902)漏洞踩坑分析
F5 BIG-IP最近发生了一次比较严重的RCE漏洞，其中主要公开出来的入口就是tmsh与hsqldb方式，tmsh的利用与分析分析比较多了，如果复现过tmsh的利用，就应该知道这个地方利用有些鸡肋，后面不对tmsh进行分析，主要看下hsqldb的利用。hsqldb的利用poc已经公开，但是java hsqldb的https导致一直无法复现，尝试了各种方式也没办法了，只好换其他思路，下面记录下复现与踩坑的过程。
利用源码搭建一个hsqldb http servlet
如果调试过hsqldb，就应该知道hsqldb.jar的代码是无法下断点调试的，这是因为hsqldb中类的linenumber table信息没有了，linenumber table只是用于调式用的，对于代码的正常运行没有任何影响。看下正常编译的类与hqldb类的lineumber table区别：
使用javap -verbose hsqlServlet.class命令看下hsqldb中hsqlServlet.class类的详细信息
可以看到自己编译的类中，每个method中都有一个 LineNumberTable，这个信息就是用于调试的信息，但是hsqldb中没有这个信息，所以是无法调试下断点的，hsqldb应该在编译时添加了某些参数或者使用了其他手段来去除这些信息
F5 BIG-IP最近发生了一次比较严重的RCE漏洞，其中主要公开出来的入口就是tmsh与hsqldb方式，tmsh的利用与分析分析比较多了，如果复现过tmsh的利用，就应该知道这个地方利用有些鸡肋，后面不对tmsh进行分析，主要看下hsqldb的利用。hsqldb的利用poc已经公开，但是java hsqldb的https导致一直无法复现，尝试了各种方式也没办法了，只好换其他思路，下面记录下复现与踩坑的过程。
利用源码搭建一个hsqldb http servlet
如果调试过hsqldb，就应该知道hsqldb.jar的代码是无法下断点调试的，这是因为hsqldb中类的linenumber table信息没有了，linenumber table只是用于调式用的，对于代码的正常运行没有任何影响。看下正常编译的类与hqldb类的lineumber table区别：
使用javap -verbose hsqlServlet.class命令看下hsqldb中hsqlServlet.class类的详细信息
可以看到自己编译的类中，每个method中都有一个 LineNumberTable，这个信息就是用于调试的信息，但是hsqldb中没有这个信息，所以是无法调试下断点的，hsqldb应该在编译时添加了某些参数或者使用了其他手段来去除这些信息
环境：
hsqldb source代码是1.8的，现在新版已经2.5.x了，为了和f5中的hsqldb吻合，还是用1.8的代码吧
JDK7u21，F5 BIG-IP 14版本使用的JDK7，所以这里尽量和它吻合避免各种问题
hsqldb source代码是1.8的，现在新版已经2.5.x了，为了和f5中的hsqldb吻合，还是用1.8的代码吧
JDK7u21，F5 BIG-IP 14版本使用的JDK7，所以这里尽量和它吻合避免各种问题
CVE-2020-5902: F5 BIG-IP 远程代码执行漏洞分析
0x00 漏洞简述
2020年07月08日， 360CERT监测发现 F5 官方更新了 F5 BIG-IP 远程代码执行 的风险通告，该漏洞编号为 CVE-2020-5902，漏洞等级：严重。
未授权的远程攻击者通过向漏洞页面发送特制的请求包，可以造成任意 Java 代码执行。进而控制 F5 BIG-IP 的全部功能，包括但不限于: 执行任意系统命令、开启/禁用服务、创建/删除服务器端文件等，使用官方的httpd配置缓解修复方案仍可造成反序列化代码执行漏洞。该漏洞影响控制面板受影响，不影响数据面板。
对此，360CERT建议广大用户及时将 BIG-IP 按照修复建议升级到指定版本。与此同时，请做好资产自查以及预防工作，以免遭受黑客攻击。
0x01 漏洞详情
首先，这里F5选择了Apache和tomcat服务器使用ajp_proxy模块进行通信，apache处理完请求之后，通过ajp协议转发给Tomcat，默认是8009端口，来看一下关于漏洞的配置文件，
proxy_ajp.conf
ProxyPassMatch ^/tmui/(.*\.jsp.*)$ ajp://localhost:8009/tmui/$1 retry=5
...
ProxyPassMatch ^/hsqldb(.*)$ ajp://localhost:8009/tmui/hsqldb$1 retry=5
apache的httpd.conf
#
# HSQLDB
#
<Location /hsqldb>
<RequireAll>
AuthType Basic
AuthName "BIG\-IP"
AuthPAM_Enabled on
AuthPAM_IdleTimeout 1200
require valid-user
Require all granted
</RequireAll>
</Location>
<Location /tmui>
# Enable content compression by type, disable for browsers with known issues
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain application/x-javascript text/css
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>
<RequireAll>
AuthType Basic
AuthName "Restricted area"
AuthPAM_Enabled on
AuthPAM_ExpiredPasswordsSupport on
AuthPam_ValidateIP On
AuthPAM_IdleTimeout 1200
AuthPAM_DashboardTimeout Off
require valid-user
Require all granted
</RequireAll>
</Location>
0x00 漏洞简述
2020年07月08日， 360CERT监测发现 F5 官方更新了 F5 BIG-IP 远程代码执行 的风险通告，该漏洞编号为 CVE-2020-5902，漏洞等级：严重。
未授权的远程攻击者通过向漏洞页面发送特制的请求包，可以造成任意 Java 代码执行。进而控制 F5 BIG-IP 的全部功能，包括但不限于: 执行任意系统命令、开启/禁用服务、创建/删除服务器端文件等，使用官方的httpd配置缓解修复方案仍可造成反序列化代码执行漏洞。该漏洞影响控制面板受影响，不影响数据面板。
对此，360CERT建议广大用户及时将 BIG-IP 按照修复建议升级到指定版本。与此同时，请做好资产自查以及预防工作，以免遭受黑客攻击。
0x01 漏洞详情
首先，这里F5选择了Apache和tomcat服务器使用ajp_proxy模块进行通信，apache处理完请求之后，通过ajp协议转发给Tomcat，默认是8009端口，来看一下关于漏洞的配置文件，
proxy_ajp.conf
ProxyPassMatch ^/tmui/(.*\.jsp.*)$ ajp://localhost:8009/tmui/$1 retry=5
...
ProxyPassMatch ^/hsqldb(.*)$ ajp://localhost:8009/tmui/hsqldb$1 retry=5
apache的httpd.conf
#
# HSQLDB
#
<Location /hsqldb>
<RequireAll>
AuthType Basic
AuthName "BIG\-IP"
AuthPAM_Enabled on
AuthPAM_IdleTimeout 1200
require valid-user
Require all granted
</RequireAll>
</Location>
<Location /tmui>
# Enable content compression by type, disable for browsers with known issues
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain application/x-javascript text/css
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>
<RequireAll>
AuthType Basic
AuthName "Restricted area"
AuthPAM_Enabled on
AuthPAM_ExpiredPasswordsSupport on
AuthPam_ValidateIP On
AuthPAM_IdleTimeout 1200
AuthPAM_DashboardTimeout Off
require valid-user
Require all granted
</RequireAll>
</Location>
F5 PAM 认证模块
F5实现了自己的pam进行认证，模块路径为/usr/lib/httpd/modules/，其中，涉及到login.jsp授权的是mod_f5_auth_cookie.so文件。
反汇编之后，大概是这样的。我们能够请求/tmui/login.jsp而不需要进行身份验证。
总结
在apache的处理中，;是被当作普通字符的，不会解析。
/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
此时，由于请求的是/tmui/login.jsp，根据pam认证模块里，/tmui/login.jsp不需要认证，接着，该请求会被转发到 tomcat上，最终tomcat请求：
/tmui/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
在web.xml 是有该配置的
<servlet-mapping>
<servlet-name>org.apache.jsp.tmui.locallb.workspace.fileRead_jsp</servlet-name>
<url-pattern>/tmui/locallb/workspace/fileRead.jsp</url-pattern>
</servlet-mapping>
请求/hsqldb;，apache本身会对/hsqldb进行认证，根据httpd.conf的配置，是匹配不到/hsqldb;的
<Location /hsqldb>
<RequireAll>
AuthType Basic
AuthName "BIG\-IP"
AuthPAM_Enabled on
AuthPAM_IdleTimeout 1200
require valid-user
Require all granted
</RequireAll>
</Location>
但正是因为tomcat对于;处理上的差异，导致了身份的绕过，%0a也是一个道理
F5实现了自己的pam进行认证，模块路径为/usr/lib/httpd/modules/，其中，涉及到login.jsp授权的是mod_f5_auth_cookie.so文件。
反汇编之后，大概是这样的。我们能够请求/tmui/login.jsp而不需要进行身份验证。
总结
在apache的处理中，;是被当作普通字符的，不会解析。
/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
此时，由于请求的是/tmui/login.jsp，根据pam认证模块里，/tmui/login.jsp不需要认证，接着，该请求会被转发到 tomcat上，最终tomcat请求：
/tmui/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
在web.xml 是有该配置的
<servlet-mapping>
<servlet-name>org.apache.jsp.tmui.locallb.workspace.fileRead_jsp</servlet-name>
<url-pattern>/tmui/locallb/workspace/fileRead.jsp</url-pattern>
</servlet-mapping>
请求/hsqldb;，apache本身会对/hsqldb进行认证，根据httpd.conf的配置，是匹配不到/hsqldb;的
<Location /hsqldb>
<RequireAll>
AuthType Basic
AuthName "BIG\-IP"
AuthPAM_Enabled on
AuthPAM_IdleTimeout 1200
require valid-user
Require all granted
</RequireAll>
</Location>
但正是因为tomcat对于;处理上的差异，导致了身份的绕过，%0a也是一个道理
请求拆分有多危险？Golang 中的一个漏洞，或者我们如何在 Portainer 中发现 RCE 并入侵 Uber
Docker 容器是通过 Docker API 进行管理的，但允许访问 Docker API 并不安全，因此通过 Websocket 接口使用了 TCP 代理方案。由于请求包含唯一的容器标识符 — id ，因此无需身份验证即可完成代理。它充当特定容器的 API 密钥。
这个查询发送给 Docker api，POST /exec/uuid/start。然后建立一个 Websocket 连接，通过TCP
代理到容器，用户可以在网站上运行命令
Docker 容器是通过 Docker API 进行管理的，但允许访问 Docker API 并不安全，因此通过 Websocket 接口使用了 TCP 代理方案。由于请求包含唯一的容器标识符 — id ，因此无需身份验证即可完成代理。它充当特定容器的 API 密钥。
这个查询发送给 Docker api，POST /exec/uuid/start。然后建立一个 Websocket 连接，通过TCP
代理到容器，用户可以在网站上运行命令
特定 API 提供商的工作流程
还可以创建 Dork 来定位特定的 API 提供商及其端点。这对于为用户的 API 密钥创建自动检查的公司尤其有用。了解 API 密钥的上下文和语法后，搜索空间可以大大减少。
了解特定的 API 提供商后，我们可以获取与 API 提供商的正则表达式匹配且位于 API 调用上下文中的所有键，然后我们可以使用内部数据库或 API 端点检查它们的有效性。
例如，假设一家公司（HalCorp）为用户提供了一个 API，用于读取和写入其帐户。通过创建我们自己的 HalCorp 帐户，我们发现 API 密钥的形式为[a-f]{4}-[a-f]{4}-[a-f]{4}
还可以创建 Dork 来定位特定的 API 提供商及其端点。这对于为用户的 API 密钥创建自动检查的公司尤其有用。了解 API 密钥的上下文和语法后，搜索空间可以大大减少。
了解特定的 API 提供商后，我们可以获取与 API 提供商的正则表达式匹配且位于 API 调用上下文中的所有键，然后我们可以使用内部数据库或 API 端点检查它们的有效性。
例如，假设一家公司（HalCorp）为用户提供了一个 API，用于读取和写入其帐户。通过创建我们自己的 HalCorp 帐户，我们发现 API 密钥的形式为[a-f]{4}-[a-f]{4}-[a-f]{4}
但是这个类并不能用于调试，因为fastjson中用ASM生成的代码没有linenumber、trace等用于调试的信息，所以不能调试。不过通过在Expression那个窗口重写部分代码，生成可用于调式的bytecode应该也是可行的（我没有测试，如果有时间和兴趣，可以看下ASM怎么生成可用于调试的字节码）