Understanding Linux Malware 閱讀筆記
===
---

###### tags: `paper`

本篇為 [Understanding Linux Malware](https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8418602) 閱讀筆記
TBD

---

**目錄:**
[TOC]

# I. Introduction
在以前，許多 Hackers 都是針對 Windows 攻擊，原因是其高達 83% 市佔率，數量非常多。
間接地，針對 Windows Malwares 的偵測、防禦、分析的研究相較於 Linux 的也就比較多。

但由於最近 IOT 開始熱門，Embedded Devices 數量增加，大部分又是用 Unix-Like 的 OS。
一來針對 Unix-Like 的資安研究就比較沒有系統化；二來做 IOT 的廠商為了求快，資安防護很多都沒做足，導致急需各種 Linux Malwares 的研究。

# II. Challenges
分析 Linux Programs 會遇到一些 Challenges，以下講述這些挑戰。

## A. Target Diversity
第一種挑戰是 Malwares run 的環境非常多種

- Architectures:
有 MIPS、ARM、x86，又分 32bits、64bits
- Loaders & Libraries:
每個 ELF 檔可以指定 Loader、要 link 的 shared libraries
- OS:
雖然本篇論文 OS focus on Linux，但這個問題點是辨識此 ELF 檔是編譯給哪個 ELF-compatible OS e.g. FreeBSD、Android，由於其他 OS (例如 FreeBSD) 跟 generic Linux 還是有些不一樣，像是 syscalls numbers and arguments，會導致 crash。
雖然 ELF 檔有個欄位 `OS/ABI` 用來表達 for which OS，但實際上這個欄位 Linux kernels 並不會去做處理，導致說 `OS/ABI` 寫說此 ELF 檔是 for which OS 是一回事，實際上這個 ELF 檔是 for which OS 又是另外一回事。
Magic Number 第 8 Byte 代表 `OS/ABI` 欄位，詳細見 `elf.h`
Ubuntu 中此欄位預設是 00，readelf 輸出為 `UNIX - System V`
詳細見 readelf source code
此程式簡單輸出 hello。
以下硬改 binary，將此欄位改成代表 `UNIX - FreeBSD` 的數字 09
依舊可以執行，表示這欄位的資訊沒什麼參考價值。

## B. Static Linking
當一個程式是 Statically Linked:
1. more potable:
需要的 Libraries 都已在程式中，目標環境中沒有安裝 Libraries 也沒關係
2. more harder to reverse engineer:
靜態連結後，call function 就直接跳到目的地，看不到、不知道 call 了什麼 function。
直接舉例說明，以下用了 `math.h` 中定義的函數 `sin()`，需 link 到其他 Libraries
用 dynamically linking
使用 ldd 指令可以觀察到需要哪些 Libraries
使用 gdb 反組譯可觀察到 call 了 `sin()`

用 statically linking
使用 ldd 可以知道此 Program 不是 dynamically linking 的
使用 gdb 反組譯只能看到直接 call 了某個 address 上的 function

Libraries 就像是高階一點的與 kernel 溝通的 API
如果以 Statically Linked，就有限定與哪種 kernel 溝通，這就是此挑戰所在

## C. Analysis Environment
在分析 Windows Malwares 時，通常不需要最高權限
但有些 Linux Malwares 需要
但給了最高權限，分析起來又會更複雜

## D. Lack of Previous Studies
如標題

# III. Analysis Infrastructure
分析流程分為三部分:
- File & Metadata Analysis
- Staic Analysis
- Dynamic Analysis

## A. Data Collection
透過 VirusTotal intelligence 的 API fetch samples

## B. File & Metadata Analysis
萃取 data 出來，將不是分析目標的 file
> shared libraries, core dumps, corrupted files, or
executables designed for other operating systems

或是會阻礙分析的 file 給過濾掉

並且也會從 VirusTotal reports 萃取出 AV labels，並透過 AVClass Tool 試圖辨別出 malware family。

## C. Staic Analysis
分成兩種:
- Binary Code Analysis
用 IDA Pro scripts 萃取出許多指標
像是幾個 functions、functions size 多大、複雜度多少，或是幾個
syscall 之類的數據

- Packing Detection
用到目前為止蒐集到的資訊來判斷用了什麼加殼器 (Packer)
如果在這一個階段能脫殼就脫殼並且重新跑一次 Static Analysis
脫不了殼的會在 Database 中做記號，後續再嘗試進行動態分析

## D. Dynamic Analysis
分成兩種:
- five-minute execution inside an instrumented emulator:
又分成兩種:
- a KVM-based virtualized sandbox with hardware support for x86 and x86-64 architectures
- a set of QEMU-based emulated sandboxes for ARM 32-bit little-endian, MIPS 32-bit big-endian, and PowerPC 32-bit

有用到 SystemTap 去做探測器(kprobes、uprobes)
作者們 patch 了 SystemTap，使其能 support 32bits ARM 和 MIPS 架構
蒐集了所有 syscalls 、其參數、回傳值以及 call syscalls 的位址
glibc 也增加了探測器去蒐集字串相關和記憶體操作相關的資訊

沙盒測試後，產生一個報告，裡面包含所有 system calls 及 userspace functions，接著會繼續分析出有用的資訊

一開始分析，若知道少了什麼東西(Libraries、Loaders)，或是偵測到有權限不足的問題，會重新以 root 權限再分析一次，接著比較以使用者權限跑分析跟以 root 跑分析有什麼差別

他們有給 samples network access，監看有沒有怪異流量，紀錄 PCAP

- custom packing analysis and unpacking attempt:
作者們以 Unicorn 為基礎開發了自動脫 UPX 的 tool

# IV. Dataset
介紹了 Dataset 中，有哪幾種 malwares

# V. Under The Hood
介紹用在 Malwares 中常見的技巧

## A. ELF Header Manipulation