更新 2020-01-22

现在有一个来自 FireEye 的工具可以帮助扫描以下项目。关键在于你需要有足够多的日志可以回溯到 2020-01-09，才有机会看到漏洞被利用之后的操作。如果它找到了 .XML 负载文件，那么你需要根据以下信息来决定采取什么行动。 https://www.fireeye.com/blog/products-and-services/2020/01/fireeye-and-citrix-tool-scans-for-iocs-related-to-vulnerability.html

工具下载

https://github.com/citrix/ioc-scanner-CVE-2019-19781 https://github.com/fireeye/ioc-scanner-CVE-2019-19781/

检测利用

目前没有简单的方法能证明某人做了什么。有了 4 个公开的漏洞利用，每个都会留下不同的工件/特征，这对检测有帮助，但并不能 100% 确定。关键要记住，这些公开的漏洞利用在 10 号之前是私有的，但这并不意味着没有其他人在野外为了自身利益而不分享其他漏洞利用。大多数情况下，漏洞利用是可以编辑的，攻击者可以更改将要丢弃的文件名、用户账户名、进程名、查询路径以及许多其他选项，这意味着有人可能已经利用过系统的可能性呈指数级增长。还有高级攻击者和基础攻击者，前者会清理痕迹，并想出非常巧妙的方法消失在系统中以逃避检测。

如果你运行 Nessus，可以使用下面的 .YAR 文件进行特权扫描，寻找常见的检测方法。 https://github.com/Neo23x0/signature-base/blob/master/yara/exploit_shitrix.yar

漏洞利用审计

关于此审计过程的优秀链接。 https://nerdscaler.com/2020/01/13/citrix-adc-cve-2019-19781-exploited-what-now/amp/ http://deyda.net/index.php/en/2020/01/15/checklist-for-citrix-adc-cve-2019-19781/

免责声明：如前所述，这不会检测到所有的漏洞利用，但如果攻击者没有修改公开的漏洞利用和/或没有清理痕迹，它可能有助于检测到一些异常。大多数攻击者会使用默认的漏洞利用，以下是一些可能遗留的有文档记录的工件。这个命令列表来自许多来源，并且随着其他变种、变通方法和新的进展出现，它将非常动态。随着更多感染事件的发生以及更大样本集的进一步取证完成，我们可以预计这会不断变化。

首先查看你不曾做过的事情。如果你通常不会在 ADC 上做太多操作，这些应该很安静，同时它们可能包含几周、几个月甚至几年前你上次操作时的条目。下面有更精确的查询。同时也要理解，即使在这篇博客中，这也是一个猫鼠游戏。当我们披露我们看到的以及如何发现攻击者时，他们也在利用这些信息对付我们，改变他们的策略以逃避检测。

漏洞利用快速检查清单 v1

• 1. 检查你的许可证，我听说有些人重启了设备，结果发现许可证已过期。
• 2. 获取支持文件，即备份系统 -> 诊断 -> 获取支持文件，并保存该文件。
• 3. 以下所有命令都在 NSCLI 中，如果你通过 SSH 进入设备并使用 Shell，则可以省略 Shell 前缀。
• 4. 检查设备上的日期，以帮助关联日志发现
  • a. shell date
• 5. 检查配置更改日期
  • a. Shell ls -l /netscaler/ | grep netscaler
  • b. Shell ls -l /nsconfig | grep netscaler
    • i. 你的 netscaler.conf 的日期是什么？
    • ii. 看起来正确吗？检查文件链接到其他位置。
• 6. 检查本地账户密码文件
  • a. Shell ls -lh /etc/passwd
    • i. 检查文件修改时间。如果在漏洞利用之后且不是你修改的，那么你需要尽快更改该密码。
    • ii. 我建议如果检测到任何漏洞利用，更改 nsroot 或任何本地账户的密码。在许多情况下
  • b. Shell cat /etc/passwd
    • i. 查看里面有哪些账户。
    • ii. 默认的有：Root, nsroot, daemon, operator, bin, nobody, sshd, nsmonitor。
• 7. 检查你的日志
  • a. shell ls -lh /var/logfile
    • i. 文件是否在？它们是否非常小？
    • ii. https://support.citrix.com/article/CTX121898
• 8. 异常文件检查
  • a. 如果这些文件的名字长度超过或少于 8-9 个字符，且是随机文件名，那么这是更高级攻击者修改了标准漏洞利用的迹象。如果你看到这种情况，你需要相应调整你的补救措施。Pwnpzi1337.xml 是 Project India 漏洞利用的文件名。
  • b. shell ls /netscaler/portal/templates/*.xml
    • i. 这里不应该有 XML 文件。
    • ii. 如果被感染，检查这里的文件日期。
    • iii.shell ls -lh /netscaler/portal/templates/
  • c. shell ls /var/tmp/netscaler/portal/templates
    • i. 此目录不应存在。
    • ii. 如果被感染，检查这里的文件日期。
    • iii.shell ls -lh /var/tmp/netscaler/portal/templates
  • d. shell ls /var/vpn/bookmark/*.xml
    • i. 最常见的情况是不存在，但也不应该有 XML 文件。
    • ii. 如果被感染，检查这里的文件日期。
    • iii.shell ls -lh /var/vpn/bookmark/
  • e. shell ls /tmp/.init
    • i. 此目录不应存在。
• 9. Cron 作业（持久性方法）
  • a. shell cat /etc/crontab
  • b. shell crontab -l -u nobody
• 10. 加密检查
  • a. shell top -n 10
    • i. NSPPE-xx（数据包引擎）应为 100% 或接近，如果有其他进程存在，你可能被挖矿了。

如果被利用

根据你的威胁态势，你需要采取的措施总是会有所不同。以下是我一直在告诉客户的关于发现漏洞利用执行证据的一些想法。

你的业务受哪些合规机构管辖？金融/银行、SOX、PCI、HIPAA、州/地方及政府法律。

如果你受这些框架之一约束，那么你需要遵循这些合规机构的相应流程。根据你所属的认证和专业团体的规定，还有关于事件响应和披露的道德考量。

以下是两个知名事件响应流程指南的链接： https://security.berkeley.edu/incident-response-planning-guideline https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

目前我们知道的是，大约在 1 月 10 日发布了第一个公开漏洞利用，有报告称 9 日就出现了感染，因为那时漏洞刚出现。在大多数情况下，如果你在 2020 年之前修补了系统，风险要低得多，而不是在本月晚些时候。

CVE-2019-19781 估计风险威胁上升期

12月17日-12月31日 最低被利用风险 1月1日-8日 较低被利用风险 1月9日-13日 较高被利用风险 1月14日-至今 最高被利用风险

这应该纳入你的下一步流程。

我发现了被利用的痕迹，现在怎么办？ 这仍然取决于情况，大多数 Citrix ADC 部署没有配置良好的 SNMP 和 SYSLOG 日志记录，可能没有好的方式来搜索、过滤或告警是否存在工件。如果你有绝对完善的日志记录，并且你确信他们没有做任何事，那么你也许可以继续正常生活。如果你确实发现了某些内容，并且能够自信地移除他们的远程访问，那么你也可以继续。

但大多数人会发现自己发现了一些痕迹，但可能无法连接点，无法确定做了什么以及他们可能去了哪里，在检测到之后重置设备可能更容易。

我的下一条建议将在接下来的两周内变化。

样本事件响应路径

我无法给出适合所有人情况的完美答案，这些是我目前（1月19日）的想法，随着我对下一步步骤以及与此漏洞相关的防御或攻击方面的更多了解，这些想法可能会改变。没有正确答案，IT 安全就像大多数领域一样，由“视情况而定”主导。我强烈建议，如果你发现除了那三个目录中的这些文件之外还有其他任何内容，我认为设备已被攻陷，应采取更谨慎的路径。在某些情况下，我建议采取更谨慎的路径，尤其是在没有日志来确认他们做了什么或没做什么的情况下。你需要与你的团队合作，根据你的情况决定最佳行动方案，因为这是一项团队运动。总会有更好的方法来处理这类问题，但基于你在设备和周边（第一层目标）拥有的证据，你或许可以通过降低风险并从那里开始来接受。

• 缓解：无论发生什么，你都应该从这里开始。使用新的固件或响应策略。
• 在审计期间检测到漏洞利用。
  • 启动你的事件响应流程。
• 具有良好设备日志记录
  • 存在高级攻击或持久性迹象
    • 新建并迁移
  • 无高级攻击或持久性迹象
    • 修复并继续运行
• 没有设备日志记录
  • 存在高级攻击或持久性迹象
    • 新建并迁移
    • 恢复出厂设置
  • 无高级攻击或持久性迹象
    • 新建并迁移
    • 恢复出厂设置
• 具有良好第一层目标日志记录
  • 存在高级攻击或持久性迹象
    • 新建并迁移
    • 恢复出厂设置
  • 无高级攻击或持久性迹象
    • 修复并继续运行
• 没有第一层目标日志记录
  • 存在高级攻击或持久性迹象
    • 新建并迁移
    • 恢复出厂设置
  • 无高级攻击或持久性迹象
    • 新建并迁移
    • 恢复出厂设置

响应定义和想法

• 新建并迁移 – 启动你的事件响应流程，然后你可以开始此过程 https://docs.citrix.com/en-us/citrix-hardware-platforms/mpx/migrating-configuration-of-existing-appliance-to-another-appliance.html。对于 VPX 和 SDX 客户来说，这相对容易，因为它们的虚拟特性以及配置平台的灵活性。MPX 迁移则是另一回事，因为恢复出厂设置的方式和基础镜像的维护方式，如果存在高级攻击者，通过固件升级和/或恢复出厂设置来持续存在的风险非常低。可能性可能较低，但仍然存在（就像网络世界中的任何事物一样）。
• 恢复出厂设置 – 启动你的事件响应流程，删除 .xml 文件以及任何其他检测到的内容，然后重新启动并再次检查持久性。然后开始恢复出厂设置的过程。可以从 Citrix 获取脚本来完成此过程。这将把系统擦除到最低级别，然后再重新加载操作系统，但每个人都会根据其威胁态势信任此方法，并且可能还需要更多操作。
  • 最极端的方法是 RMA 设备以重新加载驱动器，根据你的生命周期、平台和冗余计划，这可能是一个好主意或坏主意。我只建议在你看到使用了高级技术并且通过他们的技术确认了横向移动的情况下，可能考虑走这条路。我知道 Citrix 正在研究有什么选项，并且
• 修复 – 启动事件响应流程，删除 .xml 文件以及任何其他检测到的内容，然后重新启动并再次检查持久性。如果你有良好的日志，那么你将知道是否执行了任何操作；如果没有，那么我会查看你的威胁态势，如果你在第一层目标或其他地方有日志记录，你就可以知道是否需要考虑恢复出厂设置和/或新建并迁移。

日志层级

• 良好的本地日志记录
  • 你处于最佳位置，可以看到本地发生了什么，知道是否存在横向移动的企图，或者漏洞利用是否像大多数情况一样只是被运行。
• 良好的第一层目标日志记录
  • 你处于最佳位置，可以看到横向移动是否发生或是否被尝试。这些应该是可能被首先针对的目标，如果你看到成功的横向移动，那么你应该最担心，并在修复路径上更加谨慎。如果没有，那么你可以降低威胁风险，只需采取修复路径。
• 没有本地日志记录
  • 你处于最差位置，无法看到本地发生了什么，知道是否存在横向移动的企图，或者漏洞利用是否像大多数情况一样只是被运行。你必须在修复路径上更加谨慎。
• 没有第一层目标日志记录
  • 你处于最差位置，无法看到横向移动是否发生或是否被尝试。这些应该是可能被首先针对的目标，如果你看到成功的横向移动，那么你应该最担心，并在修复路径上更加谨慎。

我希望人们能够清除感染，并有足够好的日志记录，自信地认为他们不再被侵入，并且能够恢复正常活动，而无需执行这些步骤。

其他好的后续步骤

如果存在任何被利用的痕迹，你需要做出两个主要决定。

• 1. 更改 NSROOT 密码
  • a. 我建议无论你发现什么或有什么日志，都执行此操作。这是一个让 nsroot 进入密码轮换周期的机会。ADC 管理应绑定到 LDAP，并且 NSROOT 应仅用于紧急情况。
• 2. 更改 LDAP 服务账户（或其他身份验证服务）
  • a. 更改此密码，同时我建议如果可能的话，更改为另一个账户，这样你也会有不同的 SID。如果经过测试后再部署，这可能是一个无人注意的被动更改。
• 3. 更改 SSL 密钥
  • a. 良好的日志记录
    • i. 如果你 100% 确定它是好的，那么你可能没问题。
    • ii. 我内心仍想说要重新生成所有密钥，但我知道在大型环境中这有多么困难。
  • b. 没有日志记录
    • i. 我认为你必须重新生成上面所有的密钥。虽然有 PEM 和 PFX 保护，但我见过很多地方对这些使用了非常简单的密码，可能被离线暴力破解。由于我们不知道，我们需要保护公司。

密码想法

如果存在任何成功利用的迹象，我建议更改设备上所有本地账户的密码。继续更改它，因为在许多部署中，它可能自 4-7 年前最初部署以来从未更改过。如果你看到命令行访问和/或篡改的迹象，那么你几乎可以确定攻击者能够破解密码。在 Pre 11.0 固件上，它使用 AES256，在后期版本中，它使用 AES512，这也可能容易受到破解。确保它安全地绑定到 LDAP，并且你已经为 NSROOT 登录设置了告警。

LDAP 想法

如果你看到了一定程度的利用，我还应该确保更改 Citrix ADC 配置中定义的所有服务账户。最常见的是 LDAP/Kerberos 绑定账户。有人在 Citrix ADC 上运行漏洞利用并不意味着他们是域管理员，但根据你的控制和日志记录，可能不需要太长时间。这是一个非常简单的更改，如果经过测试，对用户来说可以是无缝的。

证书想法

根据你在审计中发现的内容，这将有助于解决这个问题。如果你有良好的日志记录，并且可以看到对此文件的访问请求，那么你必须重新生成密钥。如果你没有良好的日志记录，那么你也应该重新生成密钥。如果你有通配符证书，那么这也是另一个大问题，它绑定的站点越多，你的风险和暴露就越大。可能发生的最坏情况是，你认为它没问题，而有人用你的证书搭建钓鱼网站，所有培训都无法阻止点击。如果有人可以访问你的证书，这可能导致更大的问题，我建议谨慎行事并重新生成密钥。根据当前证书的到期日期，这可能是一个合适的时间。我见过有些人在这个过程中切换到另一个证书注册商以便改变一下，但他们的日志显示该文件被访问和下载，同时检测到了其他高级技术。

致谢 ###最后但同样重要的是，还要感谢自该问题首次出现以来一直致力于此的一些人士。还有更多幕后人士不在这个列表中，我未曾谋面。

• Citrix团队 – 努力传播信息并开发这些新固件。由于代码家族的差异，他们需要同时处理5个补丁，这使得工作更加困难。
• Daniel Weppeler @_DanielWe – 记录响应器策略以检测探测/攻击
• Florian Roth @cyb3rops – 用于检测利用的Nessus YAR文件
• CTP Anton van Pelt @AntonvanPelt & CTA Mads Petersen @mbp_netscaler & Jan Tytgat @jantytgat – 与CTP\CTA和Citrix团队在多条战线上持续合作。
• KevTheHermit @KevTheHermit – 在CVE之外披露AWS实例密码漏洞
• Bad Packets Report @bad_packets – 整个Bad Packets团队 https://badpackets.net
• Kevin Beaumont @GossiTheDog – 大力宣传所见问题，并分享其蜜罐的细节和观察。
• Mpgn @mpgn_x64 – 提供漏洞利用细节及其变种
• Nick Carr @ItsReallyNick – 提供漏洞利用细节和事件响应建议。
• Digi Cat u/digicat – Reddit用户，出色的实时新闻博客。
• Ben Sadeghipour @NahamSec – DFIR YouTube视频及其他贡献
• SANs团队 – 文章、DFIR及深度解析视频
• Craig Dods @0xCraig – 密码影响及研究
• Manuel Kolloff @manuelkolloff – 利用后渗透演练。
• FireEye和Mandiant团队 感谢Rick Cole为我们创建了最早的检测覆盖，以及Mandiant事件响应团队为本博客提供的输入——尤其是Austin Baker、Brandan Schondorfer和John Prieto——还有所有正在响应或保护客户环境免受此漏洞影响的安全顾问。同样感谢我们漏洞情报团队的Nicholas Luedtke，他协助完善了本博客的披露和工具时间线。