渗透测试某大型互联网公司的思路与收获

发表于:2019-9-19 11:52  作者:EvilMoon   来源:知乎

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试技术 渗透测试

  某大型互联网公司推出了漏洞奖金计划,以现金来奖励发现重要漏洞的白帽子,作为一名白(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),我们将立即处理

【福利】填问卷 送2019精选测试大礼包+接口测试实战课程!

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2019, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道