当你看到这篇文章标题时，是不是很吃惊，PayPal服务器的RCE漏洞？Dafaq？WTF？真的吗？这当然是真的，很幸运，我通过枚举和域名查找方法发现了该漏洞。
从头说起
最近，我通过4个月夜以继日的学习努力，突破重重考验，终于获得了OSCP渗透测试认证。这么长时间的花费，以至于我根本没时间参与一些漏洞众测项目。所以，接下来打算挖挖漏洞赚点零花钱。
正常人的周末是这样的：聚会、喝酒、玩乐、视频聊天等等，或者，走，去看《蜘蛛侠:英雄归来》！在家追剧《权力的游戏》…..
我的周末则是这样的：忙！
上传漏洞发现
某个周末，我和往常一样在博客和Youtube上研究技术，碰到了关于PayPal漏洞的一些writeup，于是，打算在PayPal的漏洞赏金项目中查点资料。在Burp拦截器关闭状态下，我访问了PayPal漏洞赏金项目主页，发现了一些东西，如下：
打开主页后，在Burp中可以得到以上响应信息，仔细观察，其响应头的内容安全策略（CSP）保护中包了多个PayPal域名，其中 “https://*.paypalcorp.com“ 让我很感兴趣。在漏洞挖掘中，一般来说，尽可能多的去发现一些有效子域名非常有用，因这这些子域名的安全最容易被忽视。
大家可以使用Subbrute、Knockpy、enumall等多种域名枚举工具，在这里我使用了 VirusTotal的子域名枚举功能，对PalPal域名进行了枚举，具体如下：
https://www.virustotal.com/en/domain/paypalcorp.com/information/
之后，复制枚举出来的子域名，利用命令”dig -f paypal noall answer” 进行域名指向分析：
其中一个域名 brandpermission.paypalcorp.com 的实际指向网站为 https://www.paypal-brandcentral.com/，该网站是PayPal的一个支持工单系统，通过该系统，卖主、供应商和合作方可以申请PayPal品牌授权并上传商品的Logo图片。
上传！每个挖洞人看到上传后的反应都是非常激动的：
好吧，上传试试！我上传了一副名为”finished.jpg” 的图片，后被系统以 “finished__thumb.jpg”为名存储在以下目录中：
“/content/helpdesk/368/867/finished__thumb.jpg”
可以看到， finished__thumb.jpg是上传后被在目录867下重新转储的图片文件，于是，我想看看在该目录下是否还存有我们原来上传的”finished.jpg”图片，太幸运了，”finished.jpg”竟然还在867目录下，LUCKY！（请看后续分解）
经过对该系统实际工作流程和文件目录命令约定等情况进行了解后，知道上述链接中的”386”是我们上传时分配的工单号，”867”则是与此工单号相关的商品文件存储目录。
接着，我又以相同的方式创建了另一个上传工单，只不过这次我把其中的图片文件换成了一个”success.php“文件，该php文件中包含了以下命令执行脚本：
执行后，竟然出现了重定向302响应（这也说明会发生访问成功的200 ok啦），当然也就意味着该系统肯定没对上传文件类型和内容作出验证。哦，有点意思！
深入挖掘实现RCE
当php文件上传出现302响应时，我第一反应是复制图片上传后产生的路径来进行对比执行，但是，在这里我们只能看到工单目录，无法得知存储目录。在这里得到的工单号目录为/366/，由于不知道存储目录，所以具体的php文件也无人知晓。
但是，从前述的JPG上传过程中，我们知道系统在把上传文件转储后还会仍然在同一个目录下保存原文件。所以，我们后续上传的success.php原文件仍然存在于系统的存储目录下。（LUCKY之处）
仔细观察工单目录和存储目录后，由于我们php文件的上传工单号为366，所以在此，我们可以尝试对存储目录进行暴力猜解，就先定个500-1000的目录号吧：
https://www.paypal-brandcentral.com/content/_helpdesk/366//success.php
BurpSuite拉出来跑一遍，哇，不出所料，返回了一个200响应的865目录id:
此时我的心情是这样的：
有了工单目录、存储目录和可执行的php文件，还有什么是不可能的呢？！来个RCE试试：
https://www.paypal-brandcentral.com/content/_helpdesk/366/865/success.php?cmd=uname-a;whoami
再来个cat /etc/passwd，哇….：
后经发现，该系统竟然还包括PayPal的一个员工登录界面，漏洞危害可想而知！
漏洞报送
2017年7月8日 18:03 - 漏洞提交 2017年7月11日 18:03 - 漏洞修复
我还以上述方式在其它网站中发现了同样的漏洞，敬请关注我下周的博客更新。
