某大型互联网公司推出了漏洞奖金计划，以现金来奖励发现重要漏洞的白帽子，作为一名白（xue）帽（sheng）子（gou），就通过下文的方法成功拿到了某大型互联网公司的现金奖励。在这里也要安利一下我厂的TSRC（腾讯安全应急响应中心），非常良心，奖励十分丰厚。
农历大年初一和大年初二，同小伙伴在日本参加了 SECCON CTF 的决赛。赛后，我发现即使是名次稍微靠后的日本参赛队伍也能获得丰厚的奖励，并且颁文部科学大臣奖以及经济产业大臣奖，日本人对安全的重视程度可见一斑。再想想大概这就是 羁绊 （划掉）传承与鼓励吧。所以笔者不由地也想做一些微小的工作，分享点什么，于是成文。
安全逻辑
安全在其特性上是强烈依赖业务的，因为如果没有业务，安全的价值就不复存在。一个安全研究员会研究软件的漏洞，研究业务逻辑的漏洞，甚至研究人的漏洞。以软件为例，安全研究员会找一切的输入点，尝试给系统一些奇奇怪怪的输入来判断某些功能是否存在安全问题。
但是，本文所要分享的不是一堆的晦涩难懂的内存布局，利用技巧，而是一名安全研究员想给大家科普的一些应有的安全小 tips 。
在目标明确的前提下，相对来说小企业的安全更好维护，而大企业的安全性更难保证。拿软件来举例，一个 HelloWorld 程序和一个大型的软件， 因为 HelloWorld 程序不存在输入点，所以自然相对大型软件就安全得多。但是否为了安全就不发展了呢？肯定不是的。谚语有云：停在港口的船是最安全的，但那不是造船的目的。
企业一定是着眼于发展，在发展中大企业的安全性就更难保证，其原因在于以下两点：
业务线长，因而导致攻击面广。
公司员工众多，而员工安全意识参差不齐。
立足于这两点，笔者当年针对某大型互联网公司做了一些测试。首先，对各种边缘业务进行一些常规的漏洞扫描，以及针对一些软件的安全问题进行分析，虽然发现一些 Client Side 的安全问题，但这些并不是本文的重点。和 Orange（一位黑掉 Facebook 的台湾黑客，访问他的博客需要自带梯子） 有同感：「身为一位渗透测试人员，比起 Client Side 的漏洞我更喜欢 Server Side 的攻击，能够直接的控制服务器、获得权限操作 SHELL 才爽。」
攻击入口
由于笔者懒，所以选择了从员工的角度针对某大型互联网公司进行一次测试，而炙手可热的同性交友开源社区 GitHub 就进入笔者的关注列表中。
确定了测试方法后，对于 GitHub 上的信息收集的两个重要目的就很明确了：
定位某大型互联网公司的员工。
查找对渗透有用的信息。
根据这两点，笔者在前期进行简单的信息收集：某大型互联网公司内网大部分的业务都会部署在 http://axxxxxx-inc.com 这个域名下。此时，一个隐含的逻辑就呼之欲出：只要 GitHub 代码中包含「axxxxxx-inc」关键词的有很大可能性是某大型互联网公司的员工上传的代码。
利用这个关键词笔者发现不少某大型互联网公司内网的东西。在解决定位的问题之后，自然而然要解决的就是如何查找有用信息的问题。最直接的就是用户账号密码、以及入口点。
经过一番搜索，不难找到员工登录的入口点 http://login.axxxxxx-inc.com ，但笔者缺少帐号密码来登录系统。
有理由相信，哪怕是在自己的计算机上，大多数开发人员是不会把账号密码直接写在代码中的，而在什么情况下是会需要在代码里附上账号密码的呢？我扶了一下眼镜，嗯。大概是自动化定期发邮件的时候会把账号密码写上去，以及数据库连接等情况。所以很明显我们的关键词就是 smtp 、 jdbc 等。
功夫不负有心人，笔者就在 GitHub 上找到了一个可以登录 l****.http://axxxxxx-inc.com 的入口账号。
当然，现在来看大家都熟知 GitHub 上不能、不能、不能（重要的事情不能只说一遍）上传一些诸如公司邮箱的账号密码等信息了。但是在 2014 年大家这个意识还不够强，于是利用 GitHub 上找到的入口帐号登录后，以下一堆内网业务系统的入口映入眼帘。
内网探索
在这个页面上有数千个业务入口，且有些系统实施了一些权限校验。所以笔者就写了个脚本带上 cookie ，判断有哪些业务系统是当前账户可以访问，而哪些系统是当前账户没有权限的。经过一番的失败的探索，笔者发现几个很有意思的业务系统，且这些系统存在着漏洞，就拿两个来举例。
一、某 H5 后台
该后台存储着许多的某业务客户端的 H5 代码，该系统能够便捷的让使用者导入相关的 H5 代码并在修改后同步到某个地方。
直觉告诉我，这里似乎有问题。所以我很自然就抓了个包，观察其交互，发现该系统发给后端 CGI 接口的数据是一个 URL，如
| url=http://example.com |
所以猜测该系统是直接拿用户的输入去拉取的 HTML 数据。是不是觉得没有什么问题？然而并不是。
如果我们传输的 URL 非 HTTP 协议的 URL 而是 FILE 协议的 URL ，也就有可能拉取到服务器的文件。嗯，运气不错。当我传输 file://localhost/etc/passwd 的时候，刷的一下蹦出了一堆可爱的用户信息。
内行人就会问了，虽然可以读文件，但是也只能读取到已知文件名的文件，因为我们没有办法列出目录。但是！人生最精彩的就是这个「但是」，这套业务系统的底层操作系统为 RedHat 。RedHat 有个特点就是它的文件夹也是一个文件，也就是在其他系统中我们需要猜测文件名才能够读取到文件内容，但是在 RedHat 下你是能够看到一切的，只需要把目录当作文件读取即可。如此这般，这个漏洞便能读取该服务器上的所有文件了，危害等级++。
二、某项目管理系统
访问到这个系统初期，第一眼看到的是众多业务及服务器，猜测大概是一些管理系统。仔细访问下来，发现这套系统非常的强大，能够针相关业务的服务器部署 Jar 包，这也意味着只需要构造一个恶意的 jar 包就可以控制这些服务器。但是，秉着只测试不作恶的原则，我不能这么做。然而这套强大的系统也给了一个测试服务器，提供 Python 代码调试测试的功能。
不多说，运行一段 python 代码先，然后结果就是我得到了这个测试服务器的控制权。XD
反思这个系统，其能运行代码是漏洞吗？我觉得不是，能够执行 Python 代码理应是这个系统的一个功能。那么问题出在哪里？笔者认为是其权限控制不严格，一个测试账户都能有权限访问并此操作这套系统，且执行任意代码，从而导致危险程度就大大加深。
他山之石
本文旨在分享一些黑客常用的攻击方法，借此警醒还有文中相同问题的网友。Make the Internet secure again（误
当下，在 GitHub 等代码托管平台，还有许多的私人信息被无意的放在上面。如：某些系统的 API Key 、邮箱帐号密码等。希望看了此文的网友们自查一下自己的 GitHub ，看看是否有一些不方便公开的东西不小心公开了。
在笔者看来，企业只有像腾讯这样，以更开放的态度面对安全问题，企业的安全才会有质的提升。无数互联网公司投入了大量的人力与金钱在安全上，也是为了更好的保护用户的安全。要知道防御要防的是整个面，而攻击者只需要攻击一个点，这本身就是一场不对称的战斗。
在这场旷日持久的斗争中，全世界的安全工作者默默的做了无数的努力，为用户抵挡了无数的攻击。但是防御往往会晚于攻击，所以安全工作者也在模拟攻击者的思路提出方案，在事前防御，不断提高攻击者的攻击门槛，让网络更安全。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
