bilibili子域名根目录挂黑页问题记录

昨天在群里看群友在反馈一个上传接口存在任意文件上传的问题,但是B站的管理员以content-type限制并不能造成实际影响为由认为这个问题可控,事实上确实有限制,群友们一致认为除了对客服钓鱼以外也难以利用这个缺陷。于是我也一起看了看这个接口,从而有了这个记录。

业务背景

先来看看漏洞所在的业务位置:B站某客服系统
具体截图:

可以看到有个上传附件的功能,问题就在这个地方出现的。这个系统主要是由第三方公司承建的,所以存在较多的问题而且B站也因为一些原因只能做整体加固不能对其进行代码修改。原来的设计就是可以上传任意后缀名的附件并提供给客服审核,所以再不济也会存在钓鱼的问题。

漏洞情况

没有太多好说的,就是个任意文件上传:

主要问题和一些实际情况:

  1. 所有参数均可控,控制后可以改变最终路径
  2. filename参数中会对一些特殊符号做过滤或者转义,而pid参数则相对过滤比较松
  3. type参数是一个字典,如果为空就不会出现在路径中,目前已知的值是msg,设成msg会出现在路径中
  4. Picture目录内可以任意写,写完后会返回路径并且可以直接访问
  5. 超过网站根目录的写直接返回400错误
  6. 对于网站根目录的写返回是成功的,但是访问的时候会显示404(指自定义文件名的时候)
  7. 上传会根据后缀名不同返回不同的content-type,基本限定在plain、img、和二进制类型,不认识的一律返回二进制contenttype
  8. web根目录可以访问,返回content-type是html

难点:

  1. content-type限制死了,在picture目录下的content-type均不能当作页面解析,也不能作为js被调用
  2. web根目录下常规文件名均返回404,容易使人认为并没有上传成功过
    思考:
  3. 假设上传没有权限,如超过网站根目录,返回的是400,但是这有个问题,网站根目录和picture目录之间的上传返回的是200OK,因此推断上传可能是成功的,假设上传成功,那么404应该是nginx层面做了限制
  4. 假设是nginx层面做了限制,并且web根目录访问后是一片白,看到返回的content-type是html,那么就肯定存在默认页面比如index.html。
  5. 如果前面推测没有问题,那么进而尝试覆盖index.html或者是其他可能的默认页面文件名。

结论:
尝试覆盖index.html毫无疑问是成功的,那么至少得出可以挂黑页了,并且可以用来打全站的cookies,或者是钓鱼等等。
附上一张弹窗:

引申:

  1. 考虑到系统框架用的是java系列,可能是stuts2或者是SpringMVC,我觉得是struts2,还可以在深挖一些东西通过覆盖一些系统框架文件来获取权限。因此我认为是存在getshell的可能的,或者使用框架漏洞来尝试
  2. 管理员说这个系统是网络隔离的,就算被攻陷风险也可控,但在我看来,如果真的被getshell,考虑到是个客服系统,可以通过构造一些更复杂的攻击payload去尝试攻击那些引用这个系统数据的内部系统,当然也可以用来钓鱼。
  3. 长期用以监控用户反馈,伪装客服对反馈用户进行诈骗也是可能的