更新 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% 或接近，如果有其他进程存在，你可能被挖矿了。
• 11. PCAP
  • a. Shell find / -name "*.cap"
  • b. 帮助找到可能被捕获的任意捕获文件。
  • c. 这是更高级攻击者可能正在嗅探的迹象。
• 12. Shell 日志
  • a. shell cat /var/log/bash.log | grep nobody
    • i. 查找来自 nobody 用户的访问。
  • b. shell gzcat /var/log/bash.*.gz | grep nobody
    • i. 在压缩日志中查找来自 nobody 用户的访问。
• 13. Apache 日志检查
  • a. shell "cat /var/log/httperror.log | grep -B2 -A5 Traceback"
  • b. shell "gzcat /var/log/httperror.log.*.gz | grep -B2 -A5 Traceback"
  • c. shell grep -iE 'POST.*.pl HTTP/1.1" 200 ' /var/log/httpaccess.log -A 1
  • d. shell grep -iE 'POST.*.pl HTTP/1.1" 200 143' /var/log/httpaccess.log -A 1
  • e. shell grep -iE 'GET.*.xml HTTP/1.1" 200' /var/log/httpaccess.log -B 1
  • f. shell grep -i '.pl HTTP/1.1" 200 143' /var/log/httpaccess.log | grep POST
    • i. 所有这些都是在查找与 .pl 和 .xml 文件进出系统相关的特定项。
  • g. shell cat /var/log/httperror.log
    • i. 这是查看文件的原始内容，总体上是查找其他突出的项。
• 14. 持久性脚本
  • a. shell ps -aux | grep python
  • b. shell ps -aux | grep perl
  • c. shell ps -auxd | grep nobody
    • i. 这些都是已知的持久性方法，使用脚本运行反向 shell 和其他任务。在这些进程列表中，你应该只看到 grep 命令。
    • ii. 这涵盖了另一种持久性方法的发现。此漏洞利用使用了由 Nobody 用户运行的恶意进程。https://soolidsnake.github.io/2020/01/17/citrix_malware.html
• 15. 密码/账户检查
  • a. shell ls -l /etc/passwd
    • i. 查看文件日期，是否有最近添加的内容。
  • b. shell cat /etc/passwd
    • i. 是否有任何可疑项，本地账户？
• 16. 检查 TCP 连接
  • a. Shell netstat -natu
  • b. 在 VLAN 中查找非本地 IP 地址。内部 IP 也应该检查，以防其他设备被攻陷。
• 17. 检查你的身份验证配置文件
  • a. 它们之前设置为 TLS 或 SSL，而现在变成了明文？
    • i. 我看到有些在某些审计和在线过程中被更改。
    • ii. 这也是高级攻击者的迹象。
  • b. 这关系到你的配置文件 ns.conf 是否被更改。
  • c. 如果之前是明文，无论你是否发现漏洞利用迹象，都需要尽快将其设置为 TLS 和 SSL。
• 18. 检查你的证书
  • a. 这些是你可能需要重新生成密钥的 SSL 证书，尤其是如果你的设备被利用过。
  • b. 我建议如果你有任何被利用的迹象，重新生成 SSL 证书的密钥。一些较大规模的部署可能会面临更困难的道路，因为证书绑定的其他位置很多，SSL 证书更改可能导致中断/故障。
  • c. 我见过一些客户没有重新生成密钥，因为他们有良好的日志，能够证明除了运行漏洞利用外没有做其他事情，也没有进入系统配置。大多数客户可能只有几天的日志。
• 19. 检查配置文件以发现潜在的第一层目标
  • a. 查看你的 ns.conf，这将创建你的第一层目标列表，该列表最有可能在设备被利用时首先被访问。

如果被利用

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

你的业务受哪些合规机构管辖？金融/银行、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 文件以及任何其他检测到的内容，然后重新启动并再次检查持久性。如果你有良好的日志，那么你将知道是否执行了任何操作；如果没有，那么我会查看你的威胁态势，如果你在第一层目标或其他地方有日志记录，你就可以知道是否需要考虑恢复出厂设置和/或新建并迁移。

日志层级

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

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

其他好的后续步骤