NGINX 類漏洞 整理記錄

簡單介紹NGINX:

• Nginx是一款輕量級的Web 服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，在BSD-like 協議下發行。

• 其特點是占有內存少，並發能力強，nginx的並發能力在同類型的網頁服務器中表現較好。主要應用在百度，淘寶等高並發請求情形。

漏洞：

1.NGINX解析漏洞

(1)Nginx文件名邏輯漏洞（CVE-2013-4547）

影響版本：Nginx 0.8.41~1.4.3 / 1.5.0~1.5.7

漏洞原理：主要原因是nginx錯誤的解析了請求的URI，比如說下面這個模塊，nginx會匹配以|.PHP|結尾的請求，發送給FastCGI(一個ong-live型CGI，激活后不用每次都fork，減少內存消耗)。而存在文 件名漏洞時，1.jpg[0x20][0x00].php會匹配為php文件（0x20為空格，0x00是null，查詢ASCII表）但進入該模塊后，因為1.jpg后是空格，會被設置為script_filename的值被發送到fastcgi解析。就完成了一次錯誤的解析。

location ~ \.php$ {
    include        fastcgi_params;

    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
    fastcgi_param  DOCUMENT_ROOT /var/www/html;
}

小擴展： 很多網站限制了允許訪問后台的IP，那么在請求時可以這么請求/test[0x20]/../admin/index.php,前提是有test這個文件夾

漏洞復現：

• 訪問靶機url:8080，可以看到是一個上傳頁面，看看能不能直接上傳php；

           

•  那看看后綴名能不能繞過；

  

•   接下來就是要使該文件被解析為php文件，根據CVE-2013-4547文件名錯誤解析原理，.jpg[0x20][0x00].php就可以進入php的函數，而被cgi解析。重放訪問上傳文件的數據包， 可以看到沒被解析；

         

• 先在請求頭中添加一些字符，觀察16進制的數據

         

•  0x20代表的是空格，這里我輸了兩個空格，方便修改數值；將第二個0x20修改為0x00，即空，滿足漏洞實現條件，再重放發包。

         

   　　可以看到，1.jpg的內容成功被php解析。

(2)用戶配置不當導致

漏洞原理：

　　該漏洞與nginx，php的版本無關，這是由於 php 中的選項 cgi.fix_pathinfo 默認值為1，表示開啟；nginx看到.php結尾的文件就交給php處理，而不先判斷文件是否存在，這一點IIS與nginx是一樣的。

漏洞復現：

• 制作一個簡單的圖片馬，繞過上傳，可以看到上傳成功，也可以正常解析為圖片

         

        

         

• 利用nginx php 文件解析特點，可以成功解析文件中的php代碼。

 

(3)%00截斷解析

影響版本：0.5.*, 0.6.*, 0.7 <= 0.7.65, 0.8 <= 0.8.37

漏洞原理：php-fastcgi在執行php文件時，URL在處理 %00 空字節時 與FastCGI處理不一致，使得我們在其他文件中插入php代碼，訪問 URL+%00.php 即可執行其中的php代碼。

2.CVE-2017-7529  NGINX越界讀取緩存漏洞

漏洞詳情：

　　在ｎｇｉｎｘ作為反向代理服務器，且開啟了緩存時，攻擊者可以構造惡意的ｒａｎｇｅ域，來獲取相應服務器中的緩存文件頭部信息，導致敏感的服務器信息泄露。

　　在進行實踐之前，先了解一下這個關鍵的ｒａｎｇｅ，ｒａｎｇｅ是ＨＴＴＰ中允許客戶端分批斷點續傳請求資源的一個參數，舉例，在請求大資源時，可以通過ｒａｎｇｅ並發下載；若網絡中斷，可以斷電續傳。ｒａｎｇｅ設置在ｈｔｔｐ請求頭中。

對range域的詳情感興趣的可參見：https://www.freebuf.com/articles/terminal/140402.html，介紹的很詳細

影響版本：Nginx version 0.5.6 - 1.13.2

漏洞復現：

• 正常請求返回的數據如下：

            

•  設置了range域后返回的信息：可以看到服務器的一些信息，在這個模擬環境中還不能看出信息的價值，但在某些重要生產環境中，被代理服務器的信息泄露是很嚴重的漏洞。希望有幸碰見
• 這里使用的poc是：https://github.com/vulhub/vulhub/blob/master/nginx/CVE-2017-7529/poc.py

         

3.錯誤配置導致的漏洞

(1)CRLF注入漏洞

　　漏洞介紹：CRLF是“\r\n”的簡稱，即回車+換行的意思。在HTTP協議里，http頭部和http正文是用兩個CRLF分割的，惡意的注入http返回包頭部，即是CRLF注入漏洞。這也叫HTTP Response Splitting ，簡稱HRS。

　　漏洞復現：這里搭建了一個簡單的靶機環境，錯誤配置示例如下，傳入的 %oa%0d 會被uri解碼為 \r\n 。

location / {
    return 302 https://$host$uri;
}

• 在請求頭部注入%0a%0dSet-Cookie：hello，可以看到返回頭部中確有注入成功，可造成會話固定漏洞。

         

•  也可以注入%0a%0d%0a%0dxxxx，插入正文到返回正文中，但這里我沒有彈框，因為環境中重定向的https://host 沒有被定義。    

       

       這里有一個新浪的CRLF利用實例參見：https://www.leavesongs.com/PENETRATION/Sina-CRLF-Injection.html

(2)目錄穿越漏洞

　漏洞介紹：nginx在配置別名(alias)時，將“/files” 等同為“/home/”，可以看到這里多了一個“/”，這個就導致可從/home/目錄穿越到他的上層目錄，即 /files../ == /home/../  ，其錯誤配置示例如下：

　　　　　 　

  漏洞復現：

• http://url:8081/files是公共文件目錄，files 會被解析為/home/,files../ = /home/./ , 可以訪問到根目錄下的文件，造成任意文件下載。

                      

(3)add_headers被覆蓋

錯誤配置如圖所示： 

                              

漏洞原理：

1. add_header是headers模塊中定義的一個指令，用來添加http響應頭部。格式如：add_header Cache-Control no-store

2. nginx是分層級組織的，每層可以有自己的指令，子塊繼承父塊的配置；但對於相同指令，子塊的配置可以覆蓋掉父塊的配置。

3. Content Security Policy，簡稱CSP，內容安全策略，來限制網站是否可以包含某些來源內容，來預防一些注入漏洞，如XSS；

4. 在上圖錯誤示例中，server塊配置為：

add_header Content-Security-Policy "default-src 'self'";     ===>  使頁面只能加載同源資源，且禁止內聯代碼執行。

add_header X-Frame-Options DENY;    ===>  　　使頁面中不能被放在iframe框架中，避免被用作點擊劫持。

但是location = /test2 子塊中，add_header 被重新配置了，這個會覆蓋父塊的配置，所以在/test2 頁面下沒有做安全限制。

以上內容是提取出來與此漏洞有關的，要詳細了解的請參見：

add_header ：https://www.jb51.net/article/156230.htm

csp：http://www.mamicode.com/info-detail-2440203.html

x-frame-options：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/X-Frame-Options

漏洞復現：

•  可以看到兩個頁面中響應頭中的變化：

               

               

 總結：

　　本文涉及的漏洞分為三大類

• 解析錯誤漏洞：

  • CVE-2013-4547：.jpg0x20 0x00.php

  • cgi.fix_pathinfo=1 時，.jpg/.php
  • %00.php (版本過低)

• 緩存讀取漏洞：CVE-2017-7529 

• 版本配置錯誤漏洞：

  • CRLF注入---HRS HTTP響應頭注入；%0a%0d的利用

  • alias /files  = /home/  

  • add_header指令，子塊覆蓋父塊