APP常见漏洞挖掘实例及分析

01

背景

近年来，随着移动设备逐渐融入日常生活，各大公司都开始研发基于自身服务的APP系统。但是由于部分应用开发人员安全意识的缺失，以及整体架构的缺陷，导致APP系统漏洞频繁发生，给互联网企业带来极大的损失。以下为我们给国内某大型互联网企业做APP安全测试时的案例，希望企业APP开发人员能从中得到一些启示。

02

流程及分析

1. 登录验证缺陷

【 问题描述 】

该APP提供给用户两种可用的登录方式：手机号+静态密码、手机号+动态密码。两种登录方式同时存在问题。

◆ 动态密码：在动态密码登陆中，密码为4位数字，短信内标注有效时长为5min，实际有效时长却约为30min，对获取动态密码次数做了限制，但未对密码暴力破解做任何防护，可以在短短几分钟内暴破成功。

◆ 静态密码登录：在静态密码登陆中，该APP将用户手机号和密码以明文形式发送到服务端（在现在的APP中，这并不罕见），这必然会造成安全问题，但这并不是这次的重点。发送用户登录信息后，登录失败服务端返回数据包如下：

登录成功则会返回更多信息：

此处的id为用户的唯一标识，频繁使用于数据交互过程中。password形似hash，但位数不对。

在该返回包内并未看到登录成功常返回的set-cookie字段。测试后发现该APP服务端并未使用session储存用户状态，而是直接根据用户提交的参数返回执行结果。

【问题分析】

动态密码登录时，需保证密码生成的随机性以及密码的复杂度在有效时间内不可解。该APP的动态密码仅为4位数字，明显低于常见的6位，且有效时长过长。对暴破的防护也做错了地方，放在获取动态密钥上，限制了获取次数，却没有限制密钥输入次数，易受暴破攻击。

静态密码登录时，服务端的作用仅是在验证用户名和密码后，返回用户信息，本身并不记录登录成功这个状态，也未对用户做出标识。也就是说只要APP能向服务端发送正确的参数，无论我们是否在服务端完成了身份认证都可以正常与服务端交互。所以在此处，我们只要有合法的用户id和password就可以通过构造返回包，正常使用APP，并不需要通过服务端验证。

2. 越权访问

【 问题描述 】

几乎所有需要登录的APP都留有获取用户信息的接口，通过发送特定的标识获取该用户的详细信息，大部分APP使用session来进行该操作，而该APP，我们已于（一）中得知，并未使用session储存用户状态，抓包后发现，其使用user_id获取用户信息。

通过对比发现，此处的user_id，即为登录返回包中的id。

参数正确时，服务器返回数据包如下：

此处的password即为登录返回包中的password，mobile为用户手机号。

同时我们已知，服务端在登录操作中并未使用session记录用户状态，所以此处大概率存在越权漏洞，我们使用其他用户的user_id，发送给服务端，

成功获取用户信息。同时，该APP中存在获取附近用户的功能，只需将用户坐标发送给服务端，

便可得到周围用户的大致信息，其中就包括用户的user_id。

【 问题分析 】

大多数软件会选用session在服务端保存用户信息，客户端通过携带session发送请求，服务端识别session查找用户状态，这样的方式不仅是为了优化用户体验，也是出于安全考虑。该APP省去这个过程，服务端单纯地对用户的请求返回结果，同时并未对作为请求参数的user_id进行保密处理，使其随手可得，造成了越权漏洞。通过此漏洞，完全可以遍历用户user_id，并获取password，结合登录过程的漏洞使用其他用户的账号。

3. 加密算法缺陷

【 问题描述 】

在登录时我们发现服务端会返回一个password，并会运用在之后的数据交互过程中，这个password形似hash值，但位数不对，可能是经过了相应处理。在该APP的密钥修改功能中，我们发现一个漏洞。该APP修改密钥，需要用户输入原密钥和新密钥，请求包如下：

其中的key与其他三个参数有关，服务器在处理此操作的时候也会校验该key值，成功返回如下：

服务器会返回重新计算后的psw（即之前的password）。

但我们发现，如果key与其他参数对应不上，服务器会返回错误，但依然会计算该psw并返回，同时对密钥长度的限制仅在APP中进行，服务器并不会检测密钥长度，于是我们使用弱密钥"0"，发送给服务端计算：

这下就很明显了，

cfcd208495d565ef66e7dff9f98764da为0的md5值，该psw确由明文密码的md5加工而来，通过几组弱密码测试后，得到结论，该APP服务端使用弱加密算法处理明文密钥并返回。完全可以通过psw值计算得到明文密钥。

通过几组测试后可发现，明文密钥(ck)生成psw的过程如下：

❶将密钥md5获得32字符长的H(ck)；

❷将ck每一位ascii减1得M(ck)；

❸将M(ck)中顺序逐位插入H(ck)两位字符中获得P(ck)；

❹psw即为P(ck) + 9 + strlen(ck)。

【 问题分析 】

服务端并未对新密钥的合法性做任何校验，同时在key值校验失败后依旧返回了计算后的psw，这使得攻击者可以使用一些特殊的输入，根据返回的psw猜解加密算法。同时该APP在psw的计算上使用了弱加密算法，所以在得到psw后可直接得到明文密钥。引发该问题的关键还是在于服务器将明文密钥稍加处理后返回给客户端，且该psw被频繁使用在通讯过程的加密中，如果将psw改为随机生成的密码串，依然可以起到相同的功能，也可防止明文密码暴露。

4. 社交模块敏感信息泄露

【 问题描述 】

在本APP中会使用用户user_id向服务端查询用户的个人信息，服务端返回包含手机号和psw等敏感数据。而服务端并不会记录用户的登录状态，所以user_id为核心敏感数据，不能泄露user_id给其他用户。

我们研究发现，通过该APP存在社交模块，在社交模块中，通过“评论区”、“周边的人”等功能均可以获得用户user_id，造成核心敏感数据泄露。特别是利用“周边的人”功能，攻击者可通过篡改GPS数据遍历user_id，危害极大。

【 问题分析 】

APP中的社交模块是用户交互业务场景，极易发生敏感信息泄露，在开发中我们要对传递的变量严格进行处理。

03

总结

通过本次APP漏洞检测，我们发现该APP的登录验证、加密算法、鉴权机制、敏感信息保护等均存在高危漏洞，对这些漏洞稍加利用，可直接获取所有用户资料和造成业务混乱，危及整个业务构架。引发问题的原因在于开发人员的安全意识缺失，及各模块开发人员间缺少沟通，使得各模块发生问题，并最终引发更大的威胁。

04

建议

APP是企业信息服务体系的前端，一旦发生安全问题，造成的损害是难以估量的，我们建议在APP上线前一定要做严格的代码审计和漏洞测试才能上线，避免因安全问题造成重大业务损失。

极矛之端铸盾之御

渗透测试 / 威胁响应 / APT防御 /

物联网安全 / 区块链安全