## TeamT5 Lab Found a Critical Vulnerability in Microsoft Windows

Our senior security researcher Shih-Fong Peng (@_L4ys), has found a critical vulnerability in Microsoft Windows. This vulnerability is officially defined by MITRE as CVE-2019-1188 (LNK Remote Code Execution Vulnerability).

TeamT5 suggests our clients to update this patch immediately. This vulnerability could allow attackers obtain privilege of the local user. Users should be vigilant of any suspicious removable drive or remote share for holding malicious .LNK file. If the .LNK file is parsed by any application, it could allow remote code execution and make system under the control of attackers.

- More Details of CVE-2019-1188:

https://msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2019-1188

- More Detail of the Microsoft Patches in August 2019:

https://msrc.microsoft.com/en-us/security-guidance

*photo courtesy of: pixabay.com

TeamT5 Lab Found a Critical Vulnerability in Microsoft Windows

## **TeamT5's technology "ThreatSonar" wins the finals of MOST's "Formosa Grand Challenge 2: S-FUND", taking home TWD 5 million in prize money as start-up funds.**

_(Reference: www.most.gov.tw)_

TeamT5 has won the final competition of the "Formosa Grand Challenge 2: S-FUND", which was held by Ministry of Science and Technology (MOST) and jointly implemented by the Science & Technology Policy Research and Information Center (STPI) and the National Center for High-performance Computing (NCHC). TeamT5 was awarded TWD 5 million and received praises from the review board. The Ministry of Science and Technology looks forward to their more completed business models in addition to advancing their technologies further and having a place in the field of international information security protection.

The "Formosa Grand Challenge 2: S-FUND" competition was held from May 2015, offering challenges for companies to solve IT security issues. Participating teams are free to propose solutions to subjects such as "Assisting in the resolution of potential threats", "Improving IoT security", "AI security threats and defense technology development", and "Other applications of cybersecurity technology". More than 20 teams registered to participate in the competition. The TeamT5 security team has performed with their AI developed technology "ThreatSonar Endpoint Intelligent Threat Identification Platform" and finally won the competition after going through all the stages over the past year.

From:

The Ministry of Science and Technology

https://www.most.gov.tw/folksonomy/detail?subSite=main&article_uid=30d3f20d-2fd0-4b0e-b7ba-2ead02e0e651&menu_id=9aa56881-8df0-4eb6-a5a7-32a2f72826ff&l=CH&utm_source=rss

The Science & Technology Policy Research and Information Center (STPI)

https://www.stpi.narl.org.tw/public/show?id=4b1141646ad4bbb2016b3f14bac56694


TeamT5 Wins the "Formosa Grand Challenge 2: S-FUND" Final

## TeamT5 贏得科技部「科技大擂台2：AI資安攻防戰」決賽大獎 

由科技部主辦，國家實驗研究院科技政策研究與資訊中心與國家高速網路與計算中心共同執行的「科技大擂台2：AI資安攻防戰」決賽，6月9日於華山文化創意產業園區舉辦。

科技部此次舉辦AI資安競賽，目標是希望扶植優秀台灣團隊、激發資安科技的創新應用。比賽共有20多個團隊參與，經過一年的選拔，最後共有3個團隊進入決賽，由「杜浦數位安全」以「端點智能威脅鑑識平台」之技術，獲得評審團一致推薦頒發獎金500萬元。該公司研究威脅情資並完整掌握，提供有效的網路威脅解決方案。

科技部強調，晉級決賽的三組隊伍皆十分優秀，各自的研發成果也有初步的市場成績，期待他們未來除了在技術上能更精進之外，也能建立更完整的商業模式，在國際資訊安全防護領域占有一席之地。


相關資訊:

[科技部: 邁向更安全的數位世界 -科技大擂台2：AI資安攻防戰決賽成果揭曉](https://www.most.gov.tw/folksonomy/detail?subSite=main&article_uid=30d3f20d-2fd0-4b0e-b7ba-2ead02e0e651&menu_id=9aa56881-8df0-4eb6-a5a7-32a2f72826ff&l=CH&utm_source=rss)

[國家實驗研究院科技政策研究與資訊中心: 邁向更安全的數位世界 AI資安攻防戰決賽成果揭曉](https://www.stpi.narl.org.tw/public/show?id=4b1141646ad4bbb2016b3f14bac56694)

TeamT5 贏得科技部「科技大擂台2：AI資安攻防戰」決賽大獎 

科技部が主催し、STPI（国家実験研究院科技政策研究与情報中心）とNCHC（国家高速網路与計算中心）が共催する「Formosa Grand Challenge（科技大擂台）2：AI情報セキュリティ攻防戦」の決勝戦が、6月9日に華山文化創意産業園区で開催されました。

今回、科技部は台湾の優秀なチームの育成と情報セキュリティテクノロジーの革新的な応用の刺激を目指し、AI情報セキュリティコンテストを開催しました。コンテストには20チーム以上参加し、1年間の選抜を経て、最終的に3チームが決勝に進み、「TeamT5」が「エンドポイントスマート脅威識別プラットフォーム」技術により、審査員の満場一致で賞金500万新台湾ドルを獲得しました。同社は脅威インテリジェンスを研究して完全に把握し、サイバー脅威に関する効果的なソリューションを提供しています。

科技部は、決勝に進んだ3組はいずれも優秀で、それぞれの研究開発成果も市場の初期段階で成功をおさめており、将来的には技術の向上だけでなく、完全なビジネスモデルを確立し、国際的な情報セキュリティ保護の分野で一定の位置を占めるようになることを期待しているとコメントしました。


関連情報：

[科技部：より安全なデジタルの世界へ -Formosa Grand Challenge（科技大擂台）2：AI情報セキュリティ攻防戦決勝戦の結果発表](https://www.most.gov.tw/folksonomy/detail?subSite=main&article_uid=30d3f20d-2fd0-4b0e-b7ba-2ead02e0e651&menu_id=9aa56881-8df0-4eb6-a5a7-32a2f72826ff&l=CH&utm_source=rss)

[STPI（国家実験研究院科技政策研究与資訊中心）：より安全なデジタルの世界へ AI情報セキュリティ攻防戦決勝戦の結果発表](https://www.stpi.narl.org.tw/public/show?id=4b1141646ad4bbb2016b3f14bac56694)


TeamT5が科技部の「Formosa Grand Challenge（科技大擂台）2：AI情報セキュリティ攻防戦」でグランプリを受賞

News

## Brief
In 2021, we discovered an open directory on Huapi’s C2. We found the source code contained an exploit aiming at Mikrotik routers. More specifically, our analysis found that the exploit would allow the attackers to send specially crafted payloads to achieve Remote Code Execution (RCE) via WAN without any authentications. The targeted RouterOS products include mikrotik-tile-6.46.8, mikrotik-vm-64.8, and mikrotik-vm-6.48.

TeamT5 alerted Mikrotik to patch this vulnerability upon discovery. The patch for this vulnerability was released on 2021/11/17 and can be downloaded from the official Mikrotik website. All affected organizations should update their RouterOS immediately to avoid actors’ exploitation.

HUAPI (aka BlackTech, Palmerworm, or PLEAD) has been active since 2007 and has been targeting Taiwan for over a decade. Huapi’s malwares are highly sophisticated, and some of them use unique anti-analysis packers. Some of Huapi’s malware utilized a modified RC4 algorithm to encrypt the malicious C2 communication. Huapi focused on governmental entities, technology or telecommunication industries, and think tanks. Our observation suggested that over half of the victims were governmental agencies in Taiwan, the United States, Japan, and South Korea.

### Attack vector
As a powerful and easy-to-use router, Mikrotik routerboard supports SCEP (Simple Certificate Enrollment Protocol), a service that was designed for simple certificate delivery. During transport, the binary data is encoded in Base64 via HTTP GET. Unfortunately, when processing the data from the payload, a miscalculation may occur if the payload is not properly formatted, potentially resulting in a Heap-based Buffer Overflow.

The open directory we had discovered contained exploit code that targeted ```mikrotik-tile-6.46.8```, ```mikrotik-vm-64.8``` and ```mikrotik-vm-6.48```, along with their corresponding shellcode snippets. In the following sections, we will be analyzing the exploit code that was designed for ```mikrotik-vm-6.46.8```.

#### Root cause analysis
By sending the following payload, we can cause the service ```www``` to crash and potentially trigger a Heap-based Buffer Overflow.

 ```GET /scep/{scep_server_name}?operation=PKIOperation&message={} HTTP/1.1\r\n```

The crash can be traced back to the function ```base64Decode```, located under ```ScepRequest::parseRequest``` from ```/nova/lib/www/scep.p```. When unpacking the Base64 request, the following code is used to calculate the output buffer size,

```output_buffer_length = 3 * (input_buffer_length >> 2)```

…which may cause a miscalculation of the output buffer, resulting in an insufficient memory allocation from ```malloc```, leading to a heap overflow.

![Mikrotik 1.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_1_3b141d6955.png)


#### What happened?

For instance, we assume that the our input data is ```xxxxxxxxxxxxxxxxhCE```, and the length of input buffer is 19. Based on the decompiled code, ```out_len = 3 * (input_len >> 2)``` which is ```out_len = 3 * (input_len // 4)``` (double slashes represent integer division), thereby allocating 12 bytes as decoded data buffer. However, the decoded data buffer should be 14 bytes instead of 12. This oversight allows the attacker to overwrite data in heap.

#### Overview of the exploit flow
According to the chunk-recycling mechanism, by overwriting the chunk size of a chunk in bins to a larger value (```0x4121```), the next ```malloc``` call will return a heap chunk overlapped with allocated chunks. This will lead to a heap overflow when writing to the chunk.

The part which will be overwritten is a vtable pointer in a destructor (```sub_8052E90```) function, and by setting the register ```edx``` to ```0x8061a74```, the instruction ```call [edx+4]``` will execute the gadget at ```0x8058e89``` ( ```xchg eax, ebp; ret;``` ) and execute the shellcode after pivoting the stack to the attacker-owned buffer.

![Mikrotik 2.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119435/Mikrotik_2_ccf3d68d2e.png)


#### Heap spray
The attacker can begin heap spraying by requesting 64 concurrent connections, and close some of them in order to let the vtable pointer be overwriten by the heap overflow later.

![Mikrotik 3.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_3_fe1501df37.png)

The function ```aaaa``` assembles the ROP gadgets, and the variable ```sc``` contains the shellcode for execution.
![Mikrotik 4.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119435/Mikrotik_4_a90ea7d1c9.png)

#### Trigger heap overflow
The function ```bbbb``` sends the payloads to the victim server in the aforementioned format.

![Mikrotik 5.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_5_7049e384ab.png)
![Mikrotik 6.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119435/Mikrotik_6_17cf9a40dd.png)

The parameter message (```'x'*801*4+'hCE'```) in the function ```bbbb``` will overwrite the size of next chunk. Here in gdb , it shows that the parameter message has been decoded to ```c7 1c 71 84 21``` at ```0x80859f0```, and the last byte ```\x21``` has been written as the next chunk size at ```0x80859f4```.

![Mikrotik 7.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119435/Mikrotik_7_d1f398ad3a.png)

#### Attempting to retrieve the oversized chunk on heap
![Mikrotik 8.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_8_69ec279783.png)

In order to retrieve the overflowed chunk, we need to send out more request. At some point, the register ```edx``` will be set to ```0x8061a74``` when the attempt reaches ```i=3```.

![Mikrotik 9.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_9_0ea232d0c5.png)

#### Trigger destructor
The final step of the exploit, set off destructor  ```call [edx+4]``` by closing connections.
![Mikrotik 10.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_10_3d19ac41ab.png)

#### Fingers crossed
Thanks to the heap spraying at the initial phase of the exploit, the data in the address ```0x8061a74``` will be modified, thus the instruction ```call [edx+4]``` will end up calling ```0x8058e89``` instead (the address of gadget ```xchg eax, ebp; ret;```) and start executing our gadgets.

![Mikrotik 11.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_11_936def75c5.png)

Once the gadgets have been hit, ```0x8058e89: xchg eax, ebp; ret``` and ```0x8052eb9: leave``` will allow us to pivot from the stack to the controllable buffer and start to execute our ROP chain from ```0x804fbfc```.

The ROP chain will try to increase the address of ```open``` to the address of ```mprotect```, and the ```0x804fc04: pop esp; ret;``` will set ```esp``` to ```0x8061a74+8``` to wrap up the ROP chain. Lastly, calling ```mprotect``` and jump right into the shellcode (```0x8061674```).

![Mikrotik 12.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_12_85dcd691f7.png)

In the exploit, the shellcode can be interpreted as ```unlink('/nova/store/user.data') + sync() + reboot()```, after the target device has finished rebooting. The attacker should then be able to login into web service as admin without a password.

### Conclusion
To wrap up, let’s go over the exploit code once again:

**1. Low stability**

- Since ```add()``` does not work in our favor and that ASLR is enabled by default, the exploit chain may fail on the first try.
- Occasionally, even though the ```/nova/store/user.dat``` file will be deleted, the device does not end up rebooting. The shellcode may require extra improvements to make it more stable.
- Even in best case scenario, the success rate is only about 5~6%.
- Thankfully, in the event where the attack attempt fails, the watchdog process will restart the ```www``` service for us. This ensures stability and allows the attacker to not cause noticeable disruption during the attack.

**2. Strict prerequisites**

- The attacker must be aware of the path name ```scep_server_name``` before being able to begin such attack.

**3. Disclosure Timeline**

```2021/07/11```: Acquire exploit codes from the open directory

```2021/10/04```: Responsible disclosure to Mikrotik and reserved CVE-2021-41987

```2021/11/17```: Official patch released

```2022/03/01```: Full disclosure released

**4. Affected versions of RouterOS**
- ```6.46.8```
- ```6.47.9```
- ```6.47.10```

### About TeamT5 D39
D39 is committed to the field of vulnerability security and vulnerability discovery. The research scope includes systems and devices that are connected to the Internet, such as mobile devices, IoT devices, Linux, and Windows. Our team has held a number of critical or important vulnerabilities and has conducted presentations across various major security conferences, such as Blackhat, HITCON, etc.

Exploit research has always been one of the most advanced fields in network attack and defense. TeamT5 expects to invest resources to cultivate more talents to enter this field, and expects to have more and more world-leading vulnerability research talents in Taiwan. We welcome those who dare to face unknown challenges, are committed to vulnerability research and discovery, and have independent research capabilities to join us. 🤝

### Reference
- https://wiki.mikrotik.com/wiki/Manual:System/Certificates
- https://en.wikipedia.org/wiki/Base64

*Image courtesy of Pixabay

Vulnerability Exposure & Notification on Mikrotik (CVE-2021-41987) 

## 前言
APT 駭客組織 Huapi 自 2007 年開始活躍至今，攻擊台灣超過 10 年的時間。TeamT5 觀察到 Huapi 所開發的惡意程式，有時會使用加殼來阻擋研究人員分析，且通常會使用修改後的 RC4 演算法來加密傳輸。Huapi 長期攻擊政府、高科技、電信或研究智庫單位，根據 TeamT5 的統計結果，超過 5 成的受害單位為政府機關，受害國家包含台灣、美國、日本及南韓，其中針對台灣政府機關進行入侵攻擊為多。

仰賴於長期的追蹤及觀察，我們在一台中繼站發現公開目錄，目錄中存在一組針對 Mikrotik SCEP 服務的 0day 攻擊程式碼。在確定弱點存在後，我們也將弱點的相關成因回報給 Mikrotik 官方，讓官方可以在第一時間內進行修補開發，以避免該弱點繼續被惡意攻擊者進行利用。

Mikrotik 官方於 2021/11/17 釋出了修正版本，請有使用到受影響版本的用戶盡速升級，以免遭受危害。這裡我們將完整揭露攻擊程式的利用細節及漏洞原理，讓我們一窺 APT 駭客組織都是怎麼為達目的、不擇手段。

### 攻擊程式包分析
作為一個功能強大且簡單易用的路由器，Mikrotik routerboard 也支援簡單憑證註冊通訊協定(Simple Certification Enrolling Protocol, SCEP)，來讓其他終端裝置可以簡便的取得所需之憑證。在協定交互的過程中，所有二進位資訊都會使用 base64 編碼之後再進行傳送，但由於 Mikrotik SCEP 服務在進行 base64 解碼的時候計算錯誤，會導致 Heap-based buffer overflow 的發生。

攻擊程式碼(以下簡稱 exploit)總共包含了針對三個不同版本的 exploit code 分別是 ```mikrotik-tile-6.46.8```、```mikrotik-vm-64.8```與```mikrotik-vm-6.48```，及其相對應版本的 shellcode 用以攻擊成功之後執行額外的惡意指令。

以下是我們針對版本 ```mikrotik-vm-6.46.8``` 進行的exploit分析。

### 弱點根因
透過一個簡單的 HTTP 請求:

```GET /scep/{scep_server_name}?operation=PKIOperation&message={} HTTP/1.1\r\n```

將可以很容易的讓 ```www``` 這個負責 HTTP 服務的 binary 崩潰，並被 watchdog 重新啟動。

經過一番逆向工程後可以發現，位於 ```/nova/lib/www/scep.p``` 中的 ```ScepRequest::parseRequest```，在解開 base64 編碼的 ```message``` 參數時，由於計算解編碼後的資料長度出現錯誤，導致 malloc 分配出來的大小不足，進而造成 heap overflow：
![Mikrotik 1.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_1_3b141d6955.png)

### 讓 Base64 變成漏洞，是不是搞錯了什麼 ?
舉例來說，假設我們的輸入資料是 ```xxxxxxxxxxxxxxxxhCE``` 長度為 19，依照逆向後的程式邏輯來看，SCEP 計算出解編碼後的長度是12 ``` out_len = 3 * (in_len // 4)``` (這邊的 ```//``` 為整數除法)。但實際上解編碼後的資料長度為 14，這就直接導致了 heap 上的資料被覆蓋的問題。

### 漏洞利用
透過分析 exploit code 我們可以發現，攻擊者使用上述漏洞將 bins 中的某個 chunk size 改大 (0x4121)，之後再次 malloc 將會拿到這個過大的 chunk 屆時便可以覆寫 heap 上的內容。

覆蓋某個 destructor 中會用到的 vtable pointer，將 ```edx``` 改成 ```0x8061a74``` 使得 ```call [edx+4]``` 執行位於 ```0x8058e89``` 的 gadget (```xchg eax, ebp; ret;```)。

![Mikrotik 2.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119435/Mikrotik_2_ccf3d68d2e.png)

#### 堆噴灑
首先發起 64 個請求做 heap spray 將我們要的 gadget 與 shellcode 隨著連線請求灑到 heap 上，並將其中一些連線關閉來讓 heap chunk 可以被 overflow 覆蓋到 vtable pointer。

![Mikrotik 3.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_3_fe1501df37.png)

這裡用到的 function ```aaaa``` 會將後續所需要的 ROP gadgets 組合起來，function 中的變數 ```sc``` 表示後面會被執行到的 shellcode。

![Mikrotik 4.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119435/Mikrotik_4_a90ea7d1c9.png)

#### 觸發堆溢出
透過呼叫 function ```bbbb``` 會將我們的 payload 使用前面提過的型式送出用以觸發 heap overflow。

![Mikrotik 5.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_5_7049e384ab.png)
![Mikrotik 6.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119435/Mikrotik_6_17cf9a40dd.png)

在 function 中的參數 message ```'x'*801*4+'hCE'```，會在 base64 解編碼的同時由於前述的計算錯誤，將導致下一個 chunk 的 size 會剛好被覆蓋到。
![Mikrotik 7.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119435/Mikrotik_7_d1f398ad3a.png)


#### 嘗試重新取得被覆蓋到 size 的 chunk
後續透過繼續新增請求的方式，嘗試取得被改大的 chunk，overflow 的內容可以改到在 vtable 裡的 pointer。

![Mikrotik 8.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_8_69ec279783.png)


在 ```i=3``` 時，會讓 ```edx``` 的值改成 ```0x8061a74```。
![Mikrotik 9.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_9_0ea232d0c5.png)


#### 觸發 destructor

最後透過關閉連線的方式，觸發 destructor ```call [edx+4]```
![Mikrotik 10.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_10_3d19ac41ab.png)


#### 幸運爆擊
由於一開始的 heap spray，```0x8061a74``` 會變成某個一連線時填入的內容，因此 ```call [edx+4]``` 會變成呼叫 ```0x8058e89```。

![Mikrotik 11.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_11_936def75c5.png)


一旦成功進到 ROP gadget，這個 ROP chain，會將 ```open@got``` 改成 ```mprotect```，使用 gadgets，嘗試把 ```open``` 變成 ```mprotect```。

![Mikrotik 12.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_12_85dcd691f7.png)



```0x804fc04: pop esp; ret;``` 會把 ```esp``` 改成 0x8061a74+8，接回完整 ROP chain。 最後呼叫 ```mprotect``` 使執行流進到 shellcode (```0x8061674```) 上執行。

該份 exploit 中 shellcode 的內容為，```unlink('/nova/store/user.dat') + sync() + reboot()```。 等待重新啟動之後可以發現 Web 介面可以不使用密碼直接登入。

### 結論
透過上面的分析可以發現這個攻擊程式碼(exploit)有幾個侷限性：

**1. 穩定性較低**
- 由於 ```add()``` 沒有處理進位，又有 ASLR 的緣故，運氣不好的話將直接導致攻擊失敗。
- 在嘗試重現的過程中我們也發現到，有時候 shellcode 已經正常執行 (```/nova/store/user.dat``` 已經被刪除)，卻未如預期般重新啟動，這部分需要改進 shellcode 來增加成功機率。
- 在嘗試重現的同時，我們也試圖透過修改 exploit 及 shellcode 來增加其穩定性，但最後成功率仍只有約略為 5~6%。
- 唯一值得慶幸的是，倘若攻擊失敗也只是會造成 ```www``` crash 後被 watchdog 重新啟動，並不會對使用上造成太大困擾或是引起使用者注意。

**2. 攻擊前提嚴格**

如根因所述，```scep_server_name``` 須為已知，若沒有這個 path 基本上也無法進行攻擊。

**3. 回報時間軸**

- ```2021/07/11```: 在 C2 發現 exploit code
- ```2021/10/04```: 回報給 Mikrotik 官方, 保留編號 CVE-2021-41987
- ```2021/11/17```: Mikrotik 官方釋出更新修正該弱點
- ```2022/03/01```: 公開 CVE-2021-41987 相關細節

**4. RouterOS 受影響版本**

- ```6.46.8```
- ```6.47.9```
- ```6.47.10```

### 關於 TeamT5 D39 漏洞研究團隊
D39 致力於弱點安全與漏洞挖掘領域，研究範圍包含 Mobile、IOT、Linux、Windows 等有機會連網的系統與裝置都是我們的目標（笑），團隊擁有多項重大（Critical）或重要（Important）之安全漏洞，並於 Blackhat、HITCON、POC 等國際會議擔任講者。

攻擊程式碼(exploit)研究一直是網路攻防裡面最高深的技術之一，TeamT5 期許投入資源來培養更多人才進入這個領域，期待台灣能有越來越多世界頂尖的弱點研究人才。歡迎勇於面對未知挑戰，致力於漏洞研究、挖掘為目標，並具有獨立研究能力者一同加入我們 🤝

### 參考
- https://wiki.mikrotik.com/wiki/Manual:System/Certificates
- https://en.wikipedia.org/wiki/Base64

*首圖來源: Pixabay

Mikrotik 漏洞揭露與通報 (CVE-2021-41987)

## はじめに
APTのハッカー組織Huapiは、2007年から活動を開始し、10年以上台湾に攻撃を仕掛けています。TeamT5は、Huapiが開発したマルウェアについて、研究員の解析を防ぐためにパッキングされていることがあり、通常は変更されたRC4のアルゴリズムで暗号化して送信されることを確認しました。Huapiは長期にわたり政府、ハイテク、電気通信、研究、シンクタンク機関を攻撃しており、TeamT5の統計では、被害者の50%以上が政府機関となっています。台湾、アメリカ、日本、韓国などが被害を受けており、多くの侵入や攻撃が台湾の政府機関を狙ったものであることが確認されました。

長期的な追跡と観察により、当社はC&Cサーバでの公開ディレクトリにMikrotik SCEPサービスを対象とした0dayエクスプロイト一式が含まれていることを発見しました。脆弱性の存在を確認した後、当社は脆弱性が発生する原因をMikrotikに報告しました。これにより、直ちに修正パッチを開発し、この脆弱性を利用した継続的なマルウェアの攻撃を防ぐことができました。

Mikrotikは、2021年11月17に公式の修正バージョンを公開しています。影響を受けるバージョンを使用しているユーザーは、被害を避けるためにできるだけ早くアップデートしてください。当社はここで攻撃プログラムの詳細と脆弱性が生まれる原理の詳細を明らかにします。目的のためなら手段を選ばないAPTハッカー組織のやり方を見てみましょう。

### 悪意のあるパッケージの解析
Mikrotik routerboardは、強力な機能性と簡易性を備えたルーターとして、他の端末装置が必要な証明書を簡単に取得できるよう、SCEP（Simple Certification Enrolling Protocol）をサポートしています。プロトコルの相互作用において、すべてのバイナリデータはbase64エンコード後に送信されますが、Mikrotik SCEPサービスによるbase64デコードの計算エラーが、Heap-based buffer overflowを引き起こします。

エクスプロイト（exploit）には、3つのバージョンを対象としたexploit code```mikrotik-tile-6.46.8```、```mikrotik-vm-64.8```、```mikrotik-vm-6.48```および攻撃成功後にコマンドインジェクションを追加するため、バージョンに応じたshellcodeが含まれています。

以下は、当社がバージョン```mikrotik-vm-6.46.8```に対して行ったexploitの解析です。

### 脆弱性の根本的な原因

シンプルなHTTPリクエスト：

 ```GET /scep/{scep_server_name}?operation=PKIOperation&message={} HTTP/1.1\r\n``` 

```www``` というHTTPサービスを担うbinaryを簡単に破壊し、watchdogで再起動することができます。

リバースエンジニアリングにより、 ```/nova/lib/www/scep.p``` の ```ScepRequest::parseRequest``` がbase64エンコードの ```message``` パラメータをデコードする時、データの長さの計算にエラーが発生することでmallocの割り当てが不足し、heap overflowが発生することを発見しました。
 
![Mikrotik 1.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_1_3b141d6955.png)
 

### Base64が脆弱性になるのは、何かの間違いではないか
例えば、 ```xxxxxxxxxxxxxxxxhCE``` という長さ19のデータを入力した場合、リバースエンジニアリング後のプログラミングロジックの観点から、SCEPはデコード後の長さを12として計算します。 ``` out_len = 3 *（in_len // 4）``` （ここでの```//```は整数の除法です）。しかし、実際のデコード後のデータの長さは14で、これがheapのデータが上書きされる問題につながります。

### 脆弱性の利用
当社は、exploit codeの解析により、攻撃者は上記の脆弱性を利用してbinsの特定のchunk sizeをより大きなサイズの（0x4121）に変更し、続いてmallocが大きくなったchunkを取得する時にheapの内容を上書きすることを発見しました。

特定のdestructorで使用されるvtable pointerを上書きして ```edx``` を ```0x8061a74``` に変更し、 ```call [edx+4]``` が ```0x8058e89``` のgadgetを実行するようにします（ ```xchg eax, ebp; ret;``` ）。
 
![Mikrotik 2.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119435/Mikrotik_2_ccf3d68d2e.png)
 
#### ヒープスプレー
はじめに、64のheap sprayをリクエストし、接続リクエストと同時に必要なgadgetとshellcodeをheapにスプレーします。heap chunkのoverflowによってvtable pointerが上書きされるように一部の接続は閉じられます。
 
![Mikrotik 3.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_3_fe1501df37.png)
 
ここで使用されるfunction ```aaaa``` は、後で必要となるROP gadgetsを組み合わせます。functionの変数```sc```は、後で実行されるshellcodeを示しています。
 
![Mikrotik 4.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119435/Mikrotik_4_a90ea7d1c9.png)
 
#### ヒープオーバーフローのトリガー
function ```bbbb``` を呼び出すと、前述のパターンでheap overflowをトリガーする当社のpayloadが送信されます。
 
![Mikrotik 5.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_5_7049e384ab.png)
![Mikrotik 6.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119435/Mikrotik_6_17cf9a40dd.png)
 
functionのパラメータ message ```'x'*801*4+'hCE'``` は、base64デコードと同時に前述の計算エラーにより、次のchunkのsizeがちょうど上書きされます。
 
![Mikrotik 7.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119435/Mikrotik_7_d1f398ad3a.png)
 

#### sizeが上書きされたchunkの再取得を試みる
続いて、リクエストを追加し続け、サイズを大きくされたchunkの取得を試みることで、overflowの内容をvtableのpointerに変更することができます。
 
![Mikrotik 8.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_8_69ec279783.png)
 

```i=3``` の時、 ```edx``` の値が ```0x8061a74``` になります。
 
![Mikrotik 9.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_9_0ea232d0c5.png)
 

#### destructorのトリガー 


最後に接続を閉じることで、destructor ```call [edx+4]```をトリガーします。
![Mikrotik 10.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_10_3d19ac41ab.png)


#### 幸運を祈る
最初のheap sprayにより、 ```0x8061a74``` のデータアドレスが変更されるため、 ```call [edx+4]``` が ```0x8058e89``` を呼び出すようになります。
 
![Mikrotik 11.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_11_936def75c5.png)
 

ROP gadgetへのアクセスが一度成功すると、このROP chainが ```open@got``` を ```mprotect``` に変更し、gadgetsを使用して ```open``` を ```mprotect``` に変更しようとします。

![Mikrotik 12.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1646119434/Mikrotik_12_85dcd691f7.png)



```0x804fc04: pop esp; ret;``` は ```esp``` を0x8061a74+8に変更し、完全なROP chainに再接続します。 最後に ```mprotect``` を呼び出し、shellcode ( ```0x8061674``` )にジャンプして実行します。

このexploitのshellcodeの内容は、 ```unlink('/nova/store/user.dat') + sync() + reboot()``` です。 再起動後、Webインターフェースでパスワードを使わなくてもログインできることが確認できます。


### 結論
上記の解析により、このエクスプロイト（exploit）には、いくつかの制限があることを確認しました：

**1. 安定性が低い**
- ```add()``` は、けた上げ数を処理せず、ASLRがあることから、運が悪ければ攻撃の失敗に直接つながります。
- 再現を試みる過程で、当社もshellcodeが正常に実行されているにも関わらず（ ```/nova/store/user.dat``` が削除されている）、予想通りに再起動しないことがあることを発見しました。この部分については、shellcodeを改良して成功率を上げる必要があります。
- 再現を試みながら、当社もexploitとshellcodeの修正により安定性を高めようとしましたが、最終的な成功率は約5～6%にすぎませんでした。
- 唯一幸いだったのは、攻撃が失敗しても ```www``` がcrashしてwatchdogが再起動されるだけで、使用上に大きな問題はなく、ユーザーの目につくこともないという点です。


**2. 攻撃のための厳しい前提条件**

根本的な原因として述べたように、 ```scep_server_name``` を認識している必要があり、このpathがなければ、基本的に攻撃することはできません。

**3. 開示のタイムライン**

- ```2021/07/11``` : C2でexploit codeを発見
- ```2021/10/04``` : Mikrotikに報告、識別番号CVE-2021-41987を予約
- ```2021/11/17``` : Mikrotikがこの脆弱性を修正するアップデートを公開
- ```2022/03/01``` : CVE-2021-41987に関する詳細を開示

**4. 影響を受けるRouterOSのバージョン**

- ```6.46.8``` 
- ```6.47.9``` 
- ```6.47.10``` 

### TeamT5 D39脆弱性研究チームについて
D39は脆弱性のセキュリティと脆弱性の発掘に取り組んでおり、研究範囲には、Mobile、IOT、Linux、Windowsなど、インターネットに接続されるシステムやデバイスのすべてが含まれます。重大（Critical）または重要（Important）なセキュリティ脆弱性に関する豊富な経験を有し、Blackhat、HITCON、POCなど国際的なカンファレンスで講演を行っています。

エクスプロイト（exploit）の研究は常にインターネットの攻防における最先端技術の一つとなっており、TeamT5は、台湾において世界トップクラスの脆弱性研究者がますます多くなることを目指し、より多くの人材を育成するためにリソースを投入しています。当社は、勇気を持って未知の挑戦に立ち向かい、脆弱性の研究や発見という目標に向かって力を注ぐ独自の研究能力を備えた人々の参加をお待ちしています。 🤝

### 参考文献
- https://wiki.mikrotik.com/wiki/Manual:System/Certificates
- https://en.wikipedia.org/wiki/Base64

*画像のソース: Pixabay

TeamT5 Lab Found a Critical Vulnerability in Microsoft Windows