一次从 APP 逆向到 Getshell 的过程

Delina

原文链接：一次从 APP 逆向到 Getshell 的过程
​
0x00 前言
话说夏天的某个早晨，笔者突然从梦中惊醒，耳边就直接传来一段低语：

炎炎夏日宅在家无聊？不如 （跟我一起做复读机，复制这段话再发出去，每天收入0元，我和身边的朋友都在做，反正闲着也是闲着。吃饱了也是撑着，不如挨顿骂）  跟我一起挖个 CNVD 原创漏洞。反正闲着也是闲着，吃饱了也是撑着，不如找机会点缀下简历、丰富下经验 ~

听完之后忽觉一阵激灵，好久才回过神来：莫非这就是传说中的天降神谕？真所谓垂死病中惊坐起，老天叫我去挖洞啊！既然如此那还想什么，开冲开冲！！
0x01 开搞
众所周知，获取 cnvd 原创漏洞证明无非两种途径。一个是提交重要关基的事件型漏洞，另一个就是提交通用型漏洞。这里选择第二种方式。因为直觉告诉我大型关基的漏洞应该早就在各种攻防演练中被挖得差不多了，而自己人菜技拙，何德何能和众大佬争功？
于是构造一波 fofa 关键字——同理，常见的、比较有影响力的开源项目大多也被大佬们审计得差不多了，所以这里直接从 fofa 找案例，然后从案例反查厂商，运气好的话也能捡到个小通用。一番挑肥拣瘦后找到了个疑似的软柿子（厚码见谅/doge）：
​
界面比较朴实无华。之所以判断是个软柿子是因为简单测试下来发现目标存在目录遍历的低级问题：
​
对本人来说，一些低级问题的出现也可以看成衡量开发人员安全意识高低的一个指标。也就是说，这个站出现其他更严重安全漏洞的可能性比较大。于是既然锁定了目标，那么依照惯例，先简单判断了下网站的情况：

•         看了下登录页面的样式和 html 源码，代码风格放荡不羁，符合小厂商比较随性的作风，而且 upload 目录存在目录遍历，至少可以说明运维人员比较粗心大意，可能存在漏打补丁之类的情况（而且通常一些比较有安全意识的 cms 开发人员，都会热心地在 upload 、attachments 等目录下手动加上一个空白的 index.html 来避免因运维配置错误而产生的目录遍历。所以如果从这个角度来看，说连开发人员安全意识也不足也不为过）
  
•         Cookie 中 存在键名为 JSSESSION 的 Cookie、404页面显示web容器为tomcat8.5，可判断后端语言是Java。因此也可以尝试 Tomcat、Weblogic、 Jboss、shiro、fastjson 等容器、中间件和组件的漏洞。
  
•         简单看了下 js 等静态资源，没有发现可直接利用的注释或隐藏的接口等信息。但页面展示了该系统配套使用的一个 APP，后期或许可以从 APP 入手尝试挖掘一些 web 界面没有展示出来的接口
  
  

有了简单的判断和猜想之后，要做的就是逐个验证了。
既然目标站点后端语言为 Java，那么先上一波 shiro  的探测。毕竟就算 Tomcat 和 Weblogic 之类的可以直接打到，感觉也只能算是中间件的漏洞，而不是这个 web 系统本身的通用。
shiro 的探测这里用到的是 burpsuite 的一款被动探测插件 shiroscan ， github 地址是 https://github.com/Daybr4ak/ShiroScan
插件安装好后，浏览测试页面，不足须臾，插件的 ShiroScan 的视图果然就给出了探测结果：shiro key scan unknown error：
​
瞧一眼插件的原始请求和服务器的响应，基本可以确认 shiro 应该是存在的了，出现这样的结果可能是插件内置的 shiro key 不够多。于是又不甘心地轮换了几个 shiro 的利用工具去测试，可惜结果都不如人意：
​
0x02 峰回路转
眼看 shiro 一把梭这条路是走不通了，又顺手测了测登录框的注入、Cookie的伪造等一些明面上能测的东西。最后还剩 fastjson 这个猜想还没有办法进一步验证了——因为就目前为止，系统暴露出来的功能除了一个登录，就再没有其他的了。更重要的是，即使只是这个登录页，其所提交的数据也不是 json 格式的，所以个人猜测这里存在 fastjson 漏洞的可能性比较低。于是挖掘的重点转向登录页挂着的配套 APP 上，希望至少可以从中挖出一些 web 界面没有展示出来的接口吧——当然，如果是未授权或者是存在 fastjson 漏洞的接口那就更好了。
说干就干。眼看饮茶时间又快到了，挖洞哪有喝茶重要。因此先不考虑 APP 加壳的问题，直接下载 APK，改后缀为 .zip 打开：
​
存在两个 dex 文件，这里也先不去探究哪个才是最要紧的了，总之两个都解压出来，分别改名为 xxx1.dex 和 xxx2.dex：
​
接着 dex2jar 伺候，得到 jar 包：
​
最后，jd-gui 打开，顺利得到源码，似乎可以捡漏逆袭：
​
得到源码后，全局搜索诸如 ：”username“、”password“、”host“、”hostname“ 、”domain“ 、”secretkey“、”publickey“、”upload“之类的字眼。因为经验告诉我，运气好的话可能可以直接得到一些可利用的硬编码信息或可未授权访问的敏感接口，比如：
​
显然，从图中代码不难看出，系统确实存在一个名为  appuploadfileservice/uploadfile  的接口，而且该接口在处理客户端提交数据前可能还没有任何身份校验机制。为了证明这个猜想，根据反编译得到的代码，在 burpsuite 中按下面推测大胆构造了请求：

first 和 offset 使用代码截图里的默认值就可以了；param 参数的作用未知；至于 file 参数，一个从请求的 querystring 获得，一个似乎从 POST 的数据 body 里获得——那么暂且认为 body 里的就是文件内容，则可以构造得到数据包为：

​
提交后返回 200 状态码，但是没有返回路径。难道是理解错误了？气氛一下子变得有点尴尬起来了。。。
不过好在，这种尴尬没持续多久，我又突然想起之前那个鸡肋的目录遍历。难道。。。？
于是怀着死马当活马医的信息再看一眼 upload 目录发现：
​
Bingo ！
原来请求中的 param 的意义是指定保存的目录。那么，自然而然地最后的 shell 访问地址是：http://xxxxx/upload/test/test.jsp ：
​
0x03 功败垂成
至此，一个未授权的任意文件上传漏洞算是挖掘完成了。然而，正当我准备放弃喝茶，打算打包提交 cnvd 混个原创证书时却尴尬地发现：
​
啊这、影响也太小了吧。。连 10 个互联网案例都凑不齐。。
还是提交事件吧、要脸。。。。
0x04 总结

•         要会搞 web ，但不能局限于只会搞 web ，因为 web 的突破口也有可能在其他地方。
  
•         渗透什么的还是要胆大心细，并且再鸡肋的漏洞也不能轻视，毕竟连一张厕纸、一条内裤都会又它自己的作用的。
  
•         下次挖通用前先查下产品使用率。。。
  
  

​