文章导读：

本文记录了入门数月小白的第一个实战RCE漏洞，为各位同样学习时间不长的师傅分享从小白视角看如何从简单的任意文件下载漏洞高效率到getshell，欢迎各位师傅发表评论指导

文章正文：

写在前面

1、本次漏洞挖掘单位比较敏感，请各位师傅原谅我图片的厚码。

2、本文会将我在漏洞挖掘过程中的踩得坑一同记录，可能比较啰嗦，请各位师傅多多包涵。

初探网站

本次的目标网站是一个比较经典的空白页面，访问url https://targeturl:8888/ 时自动跳转到 https://targeturl:8888/#/userlogin

根据url信息可以判断该页面应该是一个用户登录页面，但是可以看到该页面没有任何功能点，哪怕切换了设备仿真也没有看到功能点。

虽然没有功能点，但看到背景和小熊猫可以知道加载了静态资源，直接看一下接口。

可以看到不少iot、alarm字眼，可以推测该页面可能是一个设备管理平台，废话少说，先跑一下接口。

可以看到，用bp跑出来结果基本都是302，显然是做了鉴权。说实话，我看到一个接口没有跑出来时已经想放弃了，但看到接口/api/user/login那个405的状态码，还是忍不住试了一下，想着说不定会有个弱口令什么的。

峰回路转

切换POST请求，contenttype改为：application/json，先发个空数据看看情况

接口看起来可以用，随便输了个username置空发送，结果神奇的事情发生了

响应包居然直接返回了用户admin的身份凭证token和userSessionId！token值为123456789，显然是测试用或只是一个摆设。直接来到网站空白页面，F12打开开发者模式，全局搜索关键词token和userSessionId，果然发现了userSessionId的使用方式。

很明显的看到，该部分代码明确解释了userSessionId的使用方式是将其值放入请求头部参数DATA-ID中（即DATA-ID：userSessionId），携带该请求头再次请求接口，便可成功调用接口

HAE发力了，花花绿绿的颜色就知道接口成功调用了。这样我们直接拿下第一个也是最重要的漏洞：

管理员凭证获取接口未授权漏洞

顺势攀升

既然已经有了身份凭证，可以随意调动接口，那么我们接下来就是看哪个接口能够利用了。

经过一番搜寻，发现大部分接口虽然泄露些账号密码或设备信息，但是之前也提到，该网站是个空白页面，没有功能点，泄露的这些账号密码根本不知道能在哪里能用，而配置信息泄露，感觉也没太大作用（当然可能是我不会利用o(╥﹏╥)o），因此很自然的，我把目光放在了两个接口/api/deleteFile和/api/getFile上

接口/api/deleteFile从命名可以得知作用是删除文件，该接口可能存在任意文件删除漏洞，容易对业务产生影响，比较敏感，暂时先放在一遍。

接口/api/getFile从命名和参数名filePath就可以看出来了，存在任意文件下载漏洞的可能性极大，尝试输入值 etc/passwd

（该接口使用bp调用非常不稳定，所以后续我会使用curl工具进行调用，比较稳定）

如图，直接就出来了，甚至省了路径穿越的功夫，尝试了其他几个固定文件路径，也是都直接出来了，非常标准的任意文件下载漏洞。

拿下第二个漏洞：

任意文件下载漏洞

陷入瓶颈

要想从任意文件下载漏洞到getshell，我第一反应是获取ssh登录账密，直接访问 etc/shadow，毫不意外密码是加密的，几乎不可能破解，然后尝试去fuzz用户ssh私钥文件路径，当然也是无功而返。

第二反应就是任意文件下载接口是否有可能存在命令执行，尝试了一波payload没有成功便放弃了。

由于经验尚浅，只能去网上找找大佬们写的文章看看有没有灵感，参考了几位大佬的文章，无一例外都提到了找源码然后进行代码审计，尽管我觉得凭现在的水平进行代码审计还早，但getshell的诱惑还是让我硬着头皮决定尝试这条路。

接着模仿大佬们尝试去找历史执行命令记录history文件，包括root用户和其他用户的history，然而开发安全意识也是相当好，每执行一条命令就清一次记录，完全没有办法获得信息。

然后是尝试找/proc/self/cmdline获得信息

透露了apache - tomcat服务和版本号，尽管有透露部分jar包路径，不过都是tomcat自带的，没法直接用，不过这下知道了基础路径和logging.properties文件路径。

既然知道了服务器使用的是tomcat服务，那么就可以直接去找经典的context.xml、web.xml、server.xml、tomcat-users.xml以及上面透露的logging.properties。然而现实不如人意，在我满心欢喜的打开这些文件，准备收获一番，结果只看到了一片片绿色，大部分代码都被注释，而且没有什么新内容，没有密钥信息，没有源码文件路径，只有一些无关痛痒的内容，比如web.xml的mime-mapping和server.xml中泄露的日志文件路径构造格式（这里忘记截图了）

在我费劲心思构造好日志文件路径成功访问到日志文件，打开一看

只有一片127.0.0.1请求心跳包和前端出现过的接口的记录，我悬着的心终于死了。

灵光一闪

就这样我花了一天时间，下载了不同文件尝试获取源码路径信息，依旧无功而返。

既然如此就只能fuzz路径了，我尝试了使用关键词构造不同路径使用getfile接口进行探测，然而该接口在输入路径没有文件的情况下只会返回状态码200和长度0，因此无法通过一点点fuzz目录，只能一次性尝试完整路径进行探测，这无疑是大海捞针。果然，尝试了数欠条路径，没有一个有结果，只有服务器日志上留下了我耻辱的痕迹o(╥﹏╥)o

就这样，我一遍翻看着之前下载的文件视图找到一些有用的信息，一边想着要不要放弃时，打开了上面提到的日志文件。看着日志文件记录的日期，我突然灵感一闪，这个日期不就是这几天的吗？联想到之前看到接口的关键词iot，我立刻就想到是某个设备正在运行。

这里补充个知识点（我也是现学的），Linux系统中， /proc/pid/ 路径下的文件和目录是内核动态生成的虚拟文件系统（procfs）的一部分，用于提供对应进程（pid 为进程 ID）的实时状态信息和配置细节。这些文件并非实际存储在磁盘上，而是内核在运行时动态生成的，便于用户或程序查询进程的各类信息。当进程启动时，内核会自动在 /proc 下创建以该进程 PID 命名的目录，并生成其中的各类虚拟文件，当进程终止后，内核会立即删除/proc下对应的pid目录及其所有内容，这些文件和目录会随之消失。

说到这里可能很多师傅就明白了，设备运行就代表存在进程，存在进程就代表/proc/pid/ 目录下存在进程文件，例如进程内存映射 /proc/pid/maps，该文件会记录进程调用的源码映射关系，也就是说，得到了这个文件，就得到了源码的路径！！

思路有了，首先我们需要做的就是获取pid值。前期信息收集中，发现了目标ip的21端口开放，且启用了ftp服务，那么有很大概率服务端文件中存在/var/log/vsftpd.log日志文件，该文件记录了FTP 服务的用户行为，而里面便有我们所需的pid值信息，使用getfile接口探测并下载vsftpd.log。

成功获取到历史pid值！！接下来就是构造/proc/pid/maps相关路径进行fuzz。果不其然，让我成功找到 proc/842/maps、proc/15670/maps、proc/21424/maps 文件，打开其中一个文件

大量的源码文件路径！！！使用ai排除掉tomcat自带源码以及第三方依赖源码，成功获取到目标服务的源码。

柳暗花明

拿到代码自然就是要进行代码审计了，这里使用的jar包反编译工具用是jd - gui，该工具非常好用且画面整洁，非常推荐给为新手师傅使用。

由于基础薄弱且对代码敏感度不够高，我这里决定采用和审视前端JS代码相同的方法，没错，就是找接口！

很多师傅黑盒测试时经常会去尝试FUZZ相似命名的敏感接口，其原理就是后端代码虽然写了接口，但没有展示在前端JS代码中，也就是被隐藏了起来，因此代码审计时先从找敏感接口开始，很容易挖到宝。

运气很好，全局搜索关键词 upload，真让我找到了一个隐藏的文件上传接口。

相信哪怕没什么代码基础的师傅也能看的出来，该文件上传接口不仅没校验文件类型和文件内容，甚至允许用户指定文件上传的位置！！

直接准备一个简单的jsp代码脚本文件，用于执行系统whoami命令

使用curl命令调用接口该文件上传接口，将文件上传到/webapps/ROOT/ 目录下，使用命令如下：

curl -i -k -H "DATA-ID:userSessionId" "https://target_ip:8888/api/uploadFile" -X POST -F "file=@./test.jsp" -F "dir=/opt/vbx/bin/apache-tomcat-9.0.26/webapps/ROOT/" -F "fileName=test.jsp"

根据响应可以判断文件上传成功了，接下来访问上传的test.jsp文件，看看代码是否成功执行系统命令，使用命令如下：

curl -i -k -H "DATA-ID:userSessionId" "https://target_ip:8888/test.jsp"

结果如图，返回了系统命令whoami执行结果为root，说明成功实现RCE！！！

这里顺便提一嘴，和该目标配置相同的网站独立ip还有5个，也就说拿下了该网站权限，也可以使用同样的漏洞拿下其他5个网站。

美滋滋拿下cnvd 10.0评分和证书

总结
整个流程下来，可以说几乎没有什么技术含量，纯靠细心观察和运气，尽管如此，我也从这个人生第一个RCE漏洞实战挖掘过程中学到了很多：

1、耐心：耐心可以说相当重要了，没有坚持测试看起来平平无奇的登录接口，就不会有后续了。

2、文件下载漏洞进一步利用：该部分感觉是我该次漏洞挖掘中收获最多和记忆最深刻的部分，在敏感文件例如history信息缺乏的情况下，找到了一条可以避免了大量FUZZ来碰运气找源码文件路径的路。

3、代码审计简单思路：本次代码审计也算是对其祛魅了，简单的思路还是和JS代码审计差不多，找接口、找硬编码信息，这些也是各位师傅都能做到的简单操作。

最后，感谢各位师傅耐心看完改文章，希望能对各位师傅提供一点小小的灵感！