信息收集

　　拿到手的目标是一个 ip 加端口的站点，

　　复制链接到浏览器打开，可以看到重定向至一个登录页，在观察登录入口时，发现验证码可复用，之后使用 burp 重发几次请求，得知同一账号，密码可无限错误，这里由于登录认证的缺陷，导致可进行账号密码爆破，运气好的话可以进入后台；但是，爆破动静太大了，会产生大量日志，容易被察觉，况且爆破后台需要一定的时间，目前处于收集资产阶段，简单测试几个弱口令失败后，转而去寻找其它的有用信息。

使用 fofa 简单探测了下端口，发现这个 ip 开放了很多端口，如 3306，27017，6379，22 等等

这里简单思考了一下，能利用的端口有 MySQL，redis，mongodb，ssh 还有一些 http 服务，这其中 mysql 版本为 8.0.17，在这个版本，漏洞多多少少都修复的差不多了，接下来尝试 mongodb 未授权漏洞，不出所料，漏洞修复了；再尝试弱口令连接，也不存在~~，之后经过其它的信息收集手法，暂时对目标业务信息有了一个比较简单的认知，随后还是回到 http 服务，尝试从 web 端入手。

　　漏洞探测

　　之前在测试这些站点的时候，发现这个项目的运维特喜欢使用站点名称加年份的组合口令；根据这个有用信息，结合以前收集到的历史账号密码和目标站点的有用信息来生成一个小组合口令字典，随后再结合 burp 进行爆破，果然不一会，账号密码出来了~~

记录下账号密码，重新登陆时，却发现后台出现了这个情况，如下：

这时候的第一反应是，站点是不是部署了 waf，ip 被 ban 了？随后使用手机网络打开也同样如此，后来找业务方了解了下情况，说是不能用 admin 登陆，不然会出现错误~~

之后客户直接给出了个测试账号，我这边也懒得爆破了，就凑合着用了~~

　　一波操作进到后台，随便点点点，发现了个上传的位置，准备好一个马儿，上传截包分析，经过几次实验后，发现 uploadFormat 上传参数可控，只需要增加后缀即可上传 .Jsp

原本以为到此就结束了，没想到事情并不简单，复制得到的链接进行访问，发现全都是 404，之后再次在后台寻找其它上传点，发现仍旧如此，不单单是上传的文件会 404，就连站点原本存在的其它文件，复制链接打卡也同样会 404；经过几次尝试后，初步判断这个站点的上传和文件查看功能出现了问题，既然上传用不了，那就转而去寻找其它可利用漏洞，简单搜寻了一波，却也只发现了一堆 xss~~

回想了下刚刚收集端口的时候，发现目标还开放了 redis 服务，前段时间搞内网的时候，就遇到了很多 redis 未授权，后台既然没有收获了，那就转向 redis 等服务入手吧。

　　这里简述一下 redis 未授权漏洞：

　　Redis 默认情况下，会绑定在 0.0.0.0:6379，如果没有进行采用相关的策略，比如添加防火墙规则避免其他非信任来源 ip 访问等，这样将会将 Redis 服务暴露到公网上，如果在没有设置密码认证（一般为空）的情况下，会导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。

　　攻击者在未授权访问 Redis 的情况下，利用 Redis 自身的提供的 config 命令，可以进行写文件操作，攻击者可以成功将自己的 ssh 公钥写入目标服务器的 /root/.ssh 文件夹的 authotrized_keys 文件中，进而可以使用对应私钥直接使用 ssh 服务登录目标服务器

　　使用 redis-cli 链接时提示 (NOAUTH Authentication required) 即需要输入密码链接，而非未授权。

之后利用 msf 进行枚举 redis 密码，通过短暂的枚举得到 redis 口令，下一步利用枚举到的口令进行登录验证，可知 redis 服务为弱口令，如下：

漏洞利用

　　关于 redis 漏洞的利用有很多种，比如主从复制 rce，定时任务写 shell 等，但我个人还是比较喜欢直接往服务器写入公钥去登录；既然想法有了，那就要行动起来；因为 msf 有现成的漏洞利用模块，所以就直接用它进行公钥的写入啦。

　　这里简单介绍下 msf 下几个 redis 模块的用处：

　　auxiliary/scanner/redis/file_upload #此模块功能为上传本地的文件到目标服务器。

　　auxiliary/scanner/redis/redis_login #此模块功能是对 redis 的密码进行枚举，亲测速度很快。

　　auxiliary/scanner/redis/redis_server #此模块功能是验证枚举或者其他手段得到的 redis 密码是否正确，该功能会执行一个 info 命令并返回执行结果。

　　接下我们需要利用的模块为 auxiliary/scanner/redis/file_upload，先在本地生成一个公钥，需要注意的是，生成的公钥要改名为：authorized_keys，并且要在文件内容的前面和后面都加上 nnn 换行符才行，否则会导致利用失败。

一切准备就绪后，设置好 options，run 可以看到公钥上传成功；成功上传后，使用公钥进行连接，由于服务器采用了 root 权限运行 redis 服务，所以这里连提权都不需要了~~

获取 root 权限后，发现目标处于内网环境，之后简单的收集了下内网信息，发现开放的服务还挺多的

　　正准备进行下一步的内网渗透时，却被业务方叫停，说是超出了测试范围，由于授权单上只标明了 web 渗透，并未涉及到内网，到此，本次渗透也就不得已结束了。

　　注：发布该文章时，所有漏洞均已修复，因为知道各位师傅的厉害，所有打码严重一点~~；文章如有错误，请第一时间指出，让萌新我学习一下，谢谢各位~

小结

　　此次渗透最核心的问题还是 redis 弱口令，如果口令稍微复杂一点，可能漏洞利用就失败；其实本次渗透毫无波澜，甚至还有点无聊，这让我一度认为这是不是为 HW 而部署的一个蜜罐系统，虽然后来跟业务方确认了这是真实业务系统来着；废话不多说，花了一个下午的时间去测试，结果也出来了，得回去分析日志了。

制作不易点个赞再走吧