TL;DR
PHP開發者以及一些安全研究人員經常會在本地搭建一個基於Xdebug的PHP的除錯服務，在大部分配置情況下，Xdebug採用HTTP請求頭中的X-Forwarded-For欄位作為DBGp協議的回連地址。受害者瀏覽攻擊頁面一段時間，攻擊者可利用DNS Rebind技術向本地伺服器傳送帶有惡意X-Forwarded-For的請求，即有可能在受害者電腦上執行任意程式碼。
Xdebug是用於除錯PHP的擴充套件，可以根據本地原始碼遠端除錯伺服器上的PHP程式碼。很多開發者和安全研究人員通常會在本地搭建一套PHP的除錯環境，用於日常的開發和除錯。如果伺服器開啟了Xdebug的回連，並且攻擊者能直接訪問到伺服器的話，可以直接造成RCE。
但是大部分情況下，這些伺服器處於內網環境中，有些甚至監聽在127.0.0.1上，攻擊者很難直接訪問到，導致無法利用。如果把開發人員當做代理，利用CSRF來攻擊位於內網的Xdebug呢？
我們首先看一下Xdebug有關遠端除錯的文件。
如果xdebug.remote_connect_back啟用，xdebug.remote_host沒有設定，Xdebug會主動連線發起HTTP請求的客戶端。Xdebug會依次檢測$_SERVER['HTTP_X_FORWARDED_FOR']、$_SERVER['REMOTE_ADDR']來決定回連的IP地址。
即當Xdebug有類似如下的配置的時候，即有機會讓Xdebug回連到請求頭中X-Forwarded-For指向的ip地址。
xdebug.remote_connect_back = 1
xdebug.remote_enable = 1
xdebug.remote_log = /tmp/test.log
複製程式碼一般來講，在PHP開發人員的本地環境中會有index.php和config.php等檔案。在受害者訪問攻擊者的惡意頁面時，攻擊者可以讓受害者在瀏覽器裡嘗試向本地url如http://127.0.0.1/index.php?XDEBUG_SESSION_START或者http://127.0.0.1/config.php?XDEBUG_SESSION_START發起HTTP請求，並帶有指向攻擊者伺服器的X-Forwarded-For請求頭。這樣攻擊者就能在自己的伺服器上收到來自受害者的DBGp協議的連線，在受害者的電腦上執行任意PHP程式碼。
我們都知道，在瀏覽器裡傳送帶有非simple header的CORS請求的時候，需要先傳送一個preflight request探測伺服器是否允許傳送這種請求頭。此檢測過程是由一個OPTIONS請求完成的。如果OPTIONS請求的響應頭裡有Access-Control-Allow-Headers: X-Forwarded-For這一項的話，才能傳送帶有X-Forwarded-For的GET或者POST請求。在受害者的本地環境中，幾乎不會有這種響應頭的。
不過，攻擊者可以採用DNS Rebind的方式來繞過這個限制。攻擊者首先自己搭建一個DNS解析伺服器，讓自己控制的域名在發生第一次DNS解析的時候指向攻擊者的伺服器，以後都解析到127.0.0.1。這樣當受害者訪問攻擊者的頁面（http://attacker-domain-with-dns-rebind/exp.html）的時候，會從攻擊者的伺服器上拉取攻擊程式碼，使瀏覽器迴圈向http://attacker-domain-with-dns-rebind/index.php?XDEBUG_SESSION_START傳送帶有惡意X-Forwarded-For頭的請求。因為攻擊者存放攻擊程式碼的頁面和觸發Xdebug回連請求的url在同一個域內，即可不用傳送前面所說的preflight request。
由於DNS的解析結果也存在一定的快取時間，在瀏覽器裡大概需要1分鐘的時間才會失效進行第二次解析。在發生第二次解析的時候，其指向的IP地址會變為127.0.0.1，即向受害者本地的伺服器傳送能觸發Xdebug反彈的請求，這時候攻擊者的伺服器就能收到來自受害者Xdebug的連線了。攻擊者可以通過DBGp協議中的eval命令在客戶端執行任意php程式碼。
我們認為漏洞的成因是Xdebug從X-Forwarded-For頭中取IP作為回連地址，而X-Forwarded-For頭是不可信的。
玄武實驗室於2018年3月26日將此問題報告給PHP官方，PHP官方人員於2018年3月30日作出回應，不認為這是一個安全問題，並將報告轉為bug使之處於公開狀態。玄武實驗室建議PHP開發人員和安全研究人員在Xdebug的配置檔案中根據當前情況增加xdebug.remote_host配置項，來防止自己遭受此攻擊。
Author:salt@xuanwulab