渗透测试流程详解 及 移动APP安全测试要点

来源https://woj.app/5232.html

渗透测试是指渗透人员在不同的位置（比如从内网、从外网等位置）利用各种手段对某个特定网络进行测试，以期发现和挖掘系统中存在的漏洞，然后输出渗透测试报告，并提交给网络所有者。网络所有者根据渗透人员提供的渗透测试报告，可以清晰知晓系统中存在的安全隐患和问题。 本文根据作者的渗透测试经验，讲讲基本的渗透测试流程，分享给大家。

文章目录

• 明确目标

• 信息收集

• 针对域名

• 渗透测试实例

• 漏洞发现

• 漏洞利用

• 后渗透测试

• 报告文档编写

• 风险规避

明确目标

当拿到一个合法的渗透测试项目时，我们首先应该明确客户要求我们进行渗透测试的范围以及整体项目的时间。比如说，给我们的域名有哪些，ip段有哪些，哪些社工手段我们不能使用等等

信息收集

针对域名

真实ip查询

当然，如果连真实ip都没有找到的话。相当于连门都没有找到，这里最头疼的就是企业常常为了增强网页访问速度为服务加cdn，如何查看是否做了cdn？这里我们可以利用nslookup url这个命令，如果说做了cdn那么会返回多个ip信息（如图1），当然也可以使用不同地点的vps去ping一下域名，做了cdn的话返回ip是不一样的。

这里简单说一下有哪些方式可以绕过cdn查询真实ip： 1、直接查看子域名的ip，一般企业都只会对主域名做cdn，而常常忽略了子域名 2、查询历史dns记录，如果存在做了cdn之前的记录也是可以查到真实ip的 笔者这里推荐一个网站dns查询 3、还可以使用对方的邮件服务，或者是rss订阅服务，当目标给你发送了一条消息也可以从消息中找到真实ip 4、利用国外的vps去ping一下域名或者使用nslookup更改dns为国外的dns都可能查到其真实ip 5、让服务器去访问你的vps，比如说这个网址有设置头像的方式，并且可以直接填写头像的url，那么我们可以把图片放在自己vps上提交给服务器，那么也可以从日志中得到真实ip 6、利用phpinfo，当然这个情况还是比较少的，因为一般都会把phpinfo给删除

whois查询

当拿到一个域名的时候，我们首先应该进行whois查询，可以使kali 下面的 whois命令或者使用在线工具，比如说whois查询，通过查询域名的注册人信息，我们可以对其进行社工钓鱼。或者我们可以有针对性的利用其信息生成字典，对后台或者其他登录功能进行爆破。

google hacking

利用google hacking可以快速的对目标进行信息收集。 谷歌入侵的原理是利用谷歌去搜索包括特定文本字符串的网页。 例如：当我们在接到一个对学校进行渗透的项目时，我们需要拿到一些关于这个学校的邮箱，电话号码，地址等信息，我们可以这样查找xls文件类型的文件：

下载下来之后发现有我们需要的东西

指纹识别

通过指纹识别，我们可以明确这个网站是用何种cms开发，然后我们可以利用公开的对应版本的poc进行测试，当然我们也可以将对应版本的源码下载下来进行代码审计。 针对一个web服务，我们应该首先明确这个是由什么语言开发的前后端，使用的什么webserver，因为不同的webserver也有不同的解析漏洞或者其他的漏洞。这里笔者推荐一款浏览器插件(wappalyzer)可以很方便的查看这些信息。我们也可以观察数据包特征或者网页加载的特殊文件来识别cms。 这里笔者推荐使用在线指纹识别指纹识别 可以看到，不仅能扫出一般的指纹信息，并且子域名信息，ip信息也一览无余

历史漏洞收集

了解目标历史漏洞对我们帮助也是非常的大，至少我们可以知道网站设计人员喜欢在什么地方犯错误，喜欢犯什么类型的错误。这样我们可以有针对性的进行渗透测试，或者说我们可以查看是否已经修补过得漏洞是否能够绕过。这里我推荐去乌云镜像网上对历史漏洞进行收集。

渗透测试实例

这里笔者就举一个真实的例子来强调信息收集的重要性 笔者之前一直在对某DCP网站进行渗透测试，但是这个系统差不多把该补的漏洞都补了，很多功能甚至都删了。无从下手之时一个很隐蔽的页面告诉我这是由哪个公司写的DCP，然后马上到乌云镜像网站上收集了一波历史信息。

然后一个个案例排查，最终庆幸的是有一个sql注入漏洞没有被补上。 用sqlmap跑一下： 这里有一个需要注意到地方是，注入点在后台，也就是必须登录之后才能访问，所以我们在注入的时候必须提供cookie,否则会302跳转！ 妥妥的DBA权限呀~ 查看了一下数据库，发现涉及师生信息10W+条数据！ 我们这里可以直接使用sql-shell来有针对性的筛选高权限账号，否则因为是时间盲注就太慢了！ 找到一个高权限的账号，顺利进入后台发现可以上传文件，并且只是前台做了文件后缀的限制，因此我们只需要抓包改一下文件名就可以绕过了

最后成功getshell。

通过这个例子大家可以看到，前期的信息收集是多么重要。从一次sql注入到getshell，千里之堤毁于蚁穴。 这里再讲一下sql注入的原理： 定义：SQL注入即是指web应用程序对用户输入数据的合法性没有判断，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。 sql注入有以下危害： 1、绕过认证，获得非法权限 2、猜解后台数据库全部的信息 3、注入可以借助数据库的存储过程进行提权等操作

因此这里我给网站运维人员提出几点建议：

1. 1. 时刻关注自己的系统的0day漏洞并且做好修补

   2. 适当降低数据库的权限

   3. 要有一定的安全意识，对用户信息进行加密

   4. 不要把所有过滤只交给前台！后台同样需要做一次校验

利用app进行信息收集

一些大一点的企业会有自己的 app，我们可以利用工具对其进行逆向，找出其所使用的url链接，然后进行专门的渗透测试

子域名收集

收集子域名的重要性也不言而喻了，当对主站无从下手的时候我们可以通过子域名下手，因为一个企业可能对子域名的安全不是很重视，甚至有些子域名只是内测阶段还没有上线，所以对子域名进行渗透测试是非常重要的。这里我推荐李劼劼的子域名挖掘脚本

敏感目录收集

这里指的敏感目录包括但不限于网站的备份文件，未授权访问的上传页面，文本编辑器或者phpmyadmin等等目录。就拿备份文件来讲，一般人拿到以后只会查看是否有数据库账号密码进行连接，如果没有就无从下手。其实我们可以通过代码审计发现它的漏洞进行渗透测试。再比如phpmyadmin，我们可以使用爆破工具对其账号密码进行爆破。或者是之前有黑阔留下的后门文件，我们也可以爆破其密码进行利用。笔者找到了一个类似案例：案例1

了解网站大体功能

我们需要对整个站点的整体功能有所了解，从注册用户到更改信息更改密码等等，所有的功能都需要尽可能体验一遍，在体验的同时就应该思考这个功能可能产生什么样的漏洞。并且需要多注册几个账号，这对后面的csrf漏洞发现或者逻辑漏洞发现等等都很有帮助

常用F12

在浏览网站的时候，我们需要时刻打开开发者工具，时刻关注页面加载情况，这对我们发现ssrf漏洞非常有帮助，这里笔者推荐使用火狐的firebug工具. 针对这个问题，笔者找到了一个例子。具体案例参考

企业员工信息收集

拿到员工的信息，我们可以尝试使用弱密码进行登录一些内部平台，并且一些员工的邮箱的前缀很可能就是他的密码。当然，如果说当一个服务不允许多次使用错误密码登录，我们可以先确定弱口令，然后爆破收集到的账号信息去爆破哪些用户使用这个弱口令从而绕过这个防护机制。 针对这个问题笔者找到了相似的案例：京东员工信息泄露

针对ip

众所周知，拿到一个ip的时候，我们一般都需要使用nmap或者其他同类扫描工具对其开放端口以及端口对应的服务进行扫描。通过端口开放情况，我们可以针对性的对其进行渗透测试，这里关于nmap的使用说明笔者不再具体阐述。需要注意的是nmap默认扫描端口是常用端口，所以我们需要在使用的时候指定扫描端口范围。

漏洞发现

漏洞发现这个话题实在是太过于庞大，笔者尽可能提到一些常见的漏洞，如果有遗漏还请海涵 🙂

漏洞扫描

关于漏洞扫描的工具太多了，笔者这里仅仅推荐awvs 但是不要依赖工具，很多漏洞工具都是扫不出的，一定要结合手工测试漏洞

sql注入

sql注入可以说是非常常见了，相信你在挖掘这类漏洞的时候已经轻车熟路了，掌握常用的sql注入手法已经熟练使用sqlmap或者同类工具都非常重要。但是我们需要学会剑走偏锋，多去探索冷门的sql注入方法，这样才不会被过滤了某些字符的时候而束手无策。其次作为白帽子要有自己的原则和底线，即使数据再诱人，也千万不要去拿任何数据!

xss漏洞

前端漏洞也是一个很大的板块，在做渗透测试的时候我们需要抓住一些细微的点，对每一个输出点都尽可能的测试，并且想方设法的去绕过

xxe漏洞

xxe漏洞不知道大家有没有过多的去关注，这类漏洞如果存在的话危害是非常大的，从读取信息到探测内网等等，很值得我们去关注

逻辑漏洞

逻辑漏洞包括任意重置用户密码，修改订单等等，这类漏洞是扫描器所不能扫描出来的，所以需要我们认真分析整个站点的功能，分析其逻辑，多用burpsuite抓包观察数据包是否可篡改，验证码是否可爆破等等

csrf

检测csrf漏洞一般是看每一个操作是否有验证码验证，是否有token或者referer,可以注册多个账户然后利用A用户生成的poc去检测B用户

ssrf

在介绍信息收集的时候说过需要常常打开F12，以便于我们发现这种漏洞

未授权访问

这里所指的未授权包括各种空密码之类的，这种漏洞危害是不言而喻的

弱口令，越权访问

可以通过爆破的方式发现弱口令，而越权访问又包括水平越权和垂直访问，这种漏洞我们可以观察url是否带有用户的明文信息或者直接访问一些敏感页面

各种框架漏洞

比如说structs这个框架的漏洞层出不穷，当明确了目标所使用何种框架之后，我们可以使用poc进行验证

信息泄露

信息泄露即通过各种搜索手段或者查看robots.txt之类的铭感目录得到铭感信息

文件包含

当我们在遇到文件上传并且有白名单校验的时候，利用文件包含可以轻松getshell

命令注入

命令注入的思路与sql注入思路是差不多的，都是对用户的输入过滤不严谨，关于这种漏洞笔者找到了几条相似案例：搜狐某战点存在隐式命令注入 、案例2

最后需要注意的是在进行漏洞发现的时候应该对每一个事件利用burpsuite进行抓包仔细观察数据包的传送情况，不放过任何一个可利用的点。

漏洞利用

尽可能的由浅入深，旁敲侧推，尽可能的将漏洞的价值发挥到最大化，比如说挖到一枚self-xss ，这个漏洞一般会被忽略，如果说结合csrf漏洞的话那么就是一个中危漏洞了 再比如说拿到一个企业的邮箱账户，我们可以对其vpn爆破然后进行内网探测等等都是可行的。

后渗透测试

这里所说的后渗透测试包括内网渗透，权限维持，权限提升，读取用户hash，浏览器密码等等。但是这里需要注意，是要在客户允许的范围内进行测试，白帽子需要有白帽子的底线！

报告文档编写

一个好的渗透测试报告至关重要。 只有编写完渗透测试报告这次渗透测试才算完全结束。 首先你需要明确漏洞名称以及漏洞原理。 其次要注明参与人员，测试时间，内网外网 在报告中具体阐述漏洞是如何产生的，如何利用的。最后应该给出详细的解决方案。特别是在与开发人员交流的时候，不应该趾高气昂的说你去把这个漏洞给修补一下，我觉得我们更应该和开发人员站在一起，换一种说法来沟通：这个漏洞危害比较大，我们应该如何去修补。我相信，这样会使得漏洞的响应更加的迅速。 最后画了一个大致流程图：

风险规避

1. 1. 不要进行诸如ddos攻击，不破坏数据

   2. 测试之前对重要数据进行备份

   3. 任何测试执行前必须和客户进行沟通，以免引来不必要的麻烦

   4. 可以对原始系统生成镜像环境，然后对镜像环境进行测试

   5. 明确渗透测试范围

文章来源：http://blog.nsfocus.net/penetration-testing-process-talk-about/

移动APP安全测试要点 上次《 运营商渗透测试与挑战》中提到，随着运营商新技术新业务的发展，运营商集团层面对安全的要求有所变化，渗透测试工作将会面临内容安全、计费安全、客户信息安全、业务逻辑及APP等方面的挑战。随着运营商自主开发的移动APP越来越多，这些APP可能并不会通过应用市场审核及发布，其中的安全性将面临越来越多的挑战，这一点在《 XcodeGhost危害国内苹果应用市场》一文中就曾提到过。

这个问题也引起了运营商的足够重视，已经自主开发了自动化检测工具及定期的APP安全测试评估工作。在此，绿盟科技博客特别邀请到移动APP安全测试专家，让他们结合一次Android APP安全测试实例，为大家讲解评估特点，并将评估检查点、评估细节和整改建议一一列出，给大家提供移动终端APP安全测试的思路。

作者：侯绍岗 杨乔国

文章目录

• 评估思路

  • 移动APP面临的威胁
  • 新技术新业务移动APP评估思路
  • 运营商自动化APP测评思路
• 安全检测要点

  • Allowbackup漏洞
  • WebView漏洞
  • 关键数据明文传输
  • 任意账号注册
  • 登录界面可被钓鱼劫持
• 有争议的整改建议

  • 关键数据明文传输
  • 登录界面钓鱼劫持
• 总结

评估思路

移动APP面临的威胁

风起云涌的高科技时代，随着智能手机和iPad等移动终端设备的普及，人们逐渐习惯了使用应用客户端上网的方式，而智能终端的普及不仅推动了移动互联网的发展，也带来了移动应用的爆炸式增长。在海量的应用中，APP可能会面临如下威胁：

新技术新业务移动APP评估思路

在这次的移动APP安全测试实例中，工作小组主要通过如下7个方向，进行移动终端APP安全评估：

运营商自动化APP测评思路

运营商自主开发的自动化APP安全检测工具，通过”地、集、省”三级机构协作的方式，来完成移动终端APP安全检测与评估。APP测试思路如下：

安全检测要点

Allowbackup漏洞

AndroidManifest.xml文件中allowBackup属性值被设置为true。当allowBackup标志为true时，用户可通过adb backup来进行对应用数据的备份，在无root的情况下可以导出应用中存储的所有数据，造成用户数据的严重泄露。

整改建议

将参数android:allowBackup属性设置为false，不能对应用数据备份。

WebView漏洞

应用中存在WebView漏洞，没有对注册JAVA类的方法调用进行限制，导致攻击者可以利用反射机制调用未注册的其他任何JAVA类，最终导致javascript代码对设备进行任意攻击。

整改建议

通过在Java的远程方法上面声明一个@JavascriptInterface 来代替addjavascriptInterface；

在使用js2java的bridge时候，需要对每个传入的参数进行验证，屏蔽攻击代码；

Note ：控制相关权限或者尽可能不要使用js2java 的bridge 。

关键数据明文传输

应用程序在登录过程中，使用http协议明文传输用户名和密码，并未对用户名和密码进行加密处理。通过监控网络数据就可以截获到用户名和用户密码数据，导致用户信息泄露，给用户带来安全风险。

整改建议

在传输敏感信息时应对敏感信息进行加密处理。

任意账号注册

使用手机号133*****887注册某个APP，获取验证码46908；

在确认提交时，拦截请求，修改注册的手机号码，即可注册任意账号，这里修改为1338*****678（任意手机号）；

分别使用133*****887和133*****678（任意手机号）登录，均可以通过验证登录，看到最终结果。

整改建议

注册过程最后的确认提交时，服务器应验证提交的账号是否是下发验证码的手机号。

登录界面可被钓鱼劫持

应用存在钓鱼劫持风险。应用程序没有做防钓鱼劫持措施，通过劫持应用程序的登录界面，可以获取用户的账号和密码，可能导致用户账号信息的泄露。

整改建议：

应用程序自身通过获取栈顶activity，判断系统当前运行的程序，一旦发现应用切换（可能被劫持），给予用户提示以防范钓鱼程序的欺诈。

获取栈顶activity（如下图），当涉及敏感activity（登录、交易等）切换时，判断当前是否仍留在原程序，若不是则通过Toast给予用户提示。

使用HTML5架构或android+HTML5混合开发，实现登陆、支付等关键页面，降低被劫持的风险。

有争议的整改建议

在实施整改过程中，运营商、APP厂商及安全厂商之间就如下几点存在争议：

关键数据明文传输

根据客户测评结果以及移动终端APP厂商理解，目前的数据安全问题可为：

• 客户端安全（数据录入）。

• 客户端到服务器安全（数据传输）。

• 服务器端安全（数据存储）。

而关键数据明文传输属于客户端数据录入安全，针对此部分，目前不仅是移动终端APP，包括Web安全方面，对此部分要求也是不一而分，具体可以体现为：

• 具有现金流的交易平台： 此类业务安全级别要求最高，在数据传输方面也是目前做得最好的。主要代表是：淘宝、京东、各大银行网银等。

• 具有较大社会影响力的平台： 此类业务安全级别低于上述业务，但由于账户数据丢失以后，对其自身以及社会影响较大，所以在传输上也不会采取明文传输。如：百度、腾讯等。

• 数据丢失本身不会造成较大的影响的平台： 此类业务账户数据本身价值不大，丢失以后也不会造成影响，或者本身不会受到太大关注，一般都不会对传输数据进行加密。这样的例子比比皆是。

当然也有厂商提出，明文传输在某些专业的漏洞检测和通报的网站上，是不属于安全漏洞的，为了验证此异议，在某平台上提交了一份关于明文传输的漏洞，得到的结果请看下图：

登录界面钓鱼劫持

APP应用存在钓鱼劫持风险。应用程序没有做防钓鱼劫持措施，通过劫持应用程序的登录界面，可以获取用户的账号和密码，可能导致用户账号信息的泄露。

这一条检测结果，最大的争议在于按照整改建议整改以后，对一般用户来说，没有任何作用。首先，我们了解一下钓鱼劫持如何产生。

Android钓鱼原理

需要理解，Android启动一个Activity时，是这样设计的，给Activity加入一个标志位FLAG_ACTIVITY_NEW_TASK，就能使它置于栈顶并立马呈现给用户。但是这样的设计却有一个缺陷。如果这个Activity是用于盗号的伪装Activity呢？这种现象在XcodeGhost事件中，已经被证实是可以实现的。

在Android系统当中，程序可以枚举当前运行的进程而不需要声明其他权限，这样的话，就可以编写一个程序，启动一个后台的服务，这个服务不断地扫描当前运行的进程，当发现目标进程启动时，就启动一个伪装的Activity。如果这个Activity是登录界面，那么就可以从中获取用户的账号密码，具体的过程如下图：

检测原理描述清楚以后，就需要给出让软件厂商能够明白的整改建议以及漏洞情景重现。

Android钓鱼情景演示

以小米手机为例：

1.当打开3个APP时，最后一个打开的APP”语音助手”，切换至手机桌面，长按HOME键查看进程，”语音助手”会显示在进程的第一个。

2.点击”微信”以后，切换至”微信”，再查看进程，可以看到，进程中由于”微信”已切换至当前窗口，故进程中不存在。

3.可以从第1步看到，当切换至手机桌面时，无论是语音助手、手机令牌、还是微信，都是默认后台运行，而且切换出来以后无任何提示。这样，当恶意activity收到微信登录界面或者其他敏感界面的时候，就会抢先推送至客户，从而让客户轻易的输入了帐号，并获取了客户的信息，但此时微信不会做任何提示。

4.再来观看一下某行手机APP，当切换至手机桌面时，会对客户做出提示。如下图：

假设一下页面是恶意推送的activity，那么在恶意推送的APP页面，应该会显示出此类提示，告知客户，此页面并非正常APP的页面。

用户打开正常页面 vs 用户打开了恶意页面

总结

从工信部《新技术新业务信息安全评估管理办法（试行）》（工信部保〔2012〕117号)及运营商的相关文件规定，以及绿盟科技实施的移动APP安全测试项目来看，移动APP安全测试在运营商的重要地位。

本文通过对一次移动APP安全测试及评估的实际案例，希望能够对安全从业者在移动终端APP评估方面，也欢迎大家在QQ群里参与这方面的讨论。