小红书被指后台持续高频获取用户位置信息 小红书太垃圾了……账号被盗，让输入身份证号找回，结果输入后，告诉申诉失败……那让输入身份证是为了让小红书窃取更多个人信息吗?在一个互联网时代，小红书账号被盗，客服一开始只会让自己通过首页“账号找回”自行操作。

结果操作下来，告诉申诉失败。然后客服就说只能过段时间自己去试，多试几次，没有其他办法。真的是太垃圾了，尝试次数多了，还不能在申诉了。

客服听不懂诉求，小红书存在重大安全隐患，账号被盗都无计可施，这真是一个互联网平台吗?!从28号晚上20点发现账号被盗，一直到23点，客服就只有来来回回两句话，让自己操作找回。

那申诉失败就无计可施了。问客服就一直让等48小时给处理结果，如今30号了，已经两天了，还没有结果。真不知道小红书上怎么会有这么多用户，不担心自己被埋吗？

可能的深入利用思路

1.网络层：抓包测试暴露的接口

笔者相信这也是大多数Web渗透人员第一时间想到的思路 —— 抓包找接口分析。可惜“小红书”团队响应太迅速了，这个漏洞目前已经被修复了，所以这边笔者找到了历史版本的小红书App（附录），弱口令虽然已经失效，但是调试的接口仍然开放着，可供测试。

在分析App网络通信的过程中，一款顺手的抓包工具非常关键。笔者个人比较推荐Proxyman，它不仅支持多平台，还能清晰地把各个App的数据流量分开展示，便于逐条分析、记录。

接下来我们就用它来简单演示一下如何查看小红书App的请求数据包,经过笔者测试小红书8.86.0之前都是存在这个问题的，于是笔者对其使用Proxyman抓包进行监听。

发现输入口令点击“YES”后，上述的请求没有增多，说明小红书的开发者口令可能是通过本地进行验证或者其他协议传输，致使我们的Proxyman无法识别其协议，也就无法抓取其数据包了。如果大概率是本地口令，那我们是否能根据弹窗追踪到其功能点呢？

2.代码层：开发者模式的本地利用

笔者开始以为类似小红书这种后门式的“开发者模式”是极小概率事件，点击“设置”7下，输入“xhsdev”口令，才能进入的“后门”，多么小的概率才能被一个白帽子完全猜对啊，所以才会有人说此次事件是有内部“内鬼”导致的安全事件。

后来和笔者车联网部门的同事谈起此事，他们说其实有许多的App都是存在这种开发者模式的，只是不清楚登录密码，比如bilibili旗下的必剪App连续点版本号7-8下，比如雷石KTV等App，找到 “版本号” 等系统配置信息轻点7-8下一般都能唤醒“开发者模式”的后门。

必剪App开发者模式和 雷石 KTV App开发者模式截图

为什么这么多App都会存在这些隐藏式的开发者模式？为了搞清楚这些“后门”的成因，笔者找了一个专供于IoT Security、Mobile Security、Cloud security、Web Security等人员学习研究的开源App项目，该App的所有行为、配置、接口都默认开启调试权限，虽然这个项目已经是10年前的，但现在仍然在支撑和维护中，项目地址（见附录）。该项目没有网络云端，只有本地端，正好通过学习这个App的测试方法去研究上述众多存在“后门”的App。配置好 Android studio，直接导入项目源码，编译成apk就可以上手测试了。