@cwyalpha #300 快应用是手机系统内预置的，支持浏览器里面发送 http 请求唤醒应用 不只是 vivo，其他很多国产手机也有这个，比如 coloros, miui, flyme, emui

根据 @cwyalpha 的回复，现在能构造出控制内网 /公网机器跳转到指定快应用的链接了
可以设置 __PROMPT__的值决定是直接跳转还是弹窗确认是否跳转，如果 __PROMPT__=0，那么无需用户确认，自动跳转到指定的快应用。
此外该链接可以通过本机访问目标网站触发或者攻击者远程触发。

攻击者远程触发：
http://ip:55555/?i=com.meituan.waimai.quickapp&__PROMPT__=1&__NAME__=ttteeesssttt # 有弹窗，启动美团外卖

http://ip:55555/?i=com.meituan.waimai.quickapp&__PROMPT__=0&__NAME__=ttteeesssttt # 无弹窗，直接启动美团外卖


水坑攻击：在某个网页添加能发起请求的代码，如添加 <img>，
<img src="http://127.0.0.1:55555/?i=com.meituan.waimai.quickapp&__PROMPT__=0&__NAME__=tttesttt">

受害者访问此页面后可以直接跳转到美团外卖（此请求其实是设计者预设的合法请求，但是可能被水坑攻击利用）

说到底，其实这是 quickapp 的 feature，通过 http 请求唤醒应用，这里监听了所有端口导致了问题的严重放大，被映射到公网，导致了问题的更严重的放大，致使了这个 feature 可能被攻击者远程利用，通过内网 /公网的一次 GET 请求启动目标手机的应用。

暂未确认是 UPNP 导致的端口被映射到公网，还是其他途径映射到公网的，fofa 搜索指纹能找到 7 万台设备，zoomeye 搜索指纹能找到 20 万台设备。两个厂商扫描的周期不同以及可能存在历史数据，个人推测公网受害者大约在 10 万台这一量级。
对于没有映射到公网的设备，数量可能是映射到了公网的设备的千倍。根据 https://finance.sina.com.cn/tech/2021-05-01/doc-ikmxzfmk9958014.shtml 的内容，在大内网的地方，比如企业内网、校园网，漏洞触发可能更容易。


根据楼上各位大佬分析到的结果，这应该已经能算是一个有一定危险性的漏洞了，推测 CVSS 评分 5-6，可能的攻击场景是远程启动受害者应用或者反复请求恶意 URL 导致拒绝服务攻击。但是更严重的利用，比如注册一个恶意的快应用，然后通过此触发方式在受害者手机上启动该快应用，进一步实现权限提升，可能是可以实现的，但存在一定难度。

锅不能全扔给 vivo，快应用也得背一点，可能不只是 vivo 存在这个问题，其他品牌支持快应用的手机可能也有类似的问题 :)

至于如何解决 55555 仍在开放，目前为止该漏洞仍然可以被恶意利用这个问题，暂时只能在路由器里面关 upnp，adb 卸载某些包（哪些我也不知道）。关 UPNP 只能防御来自 NAT 之外的攻击，不能抵御内网里的攻击，所以，等 vivo 的 OTA 更新吧 （推测他们会处理这个问题叭）

至于楼主的存在较大的带宽占用这个问题，目前似乎没有更多的信息了，个人推测快应用可能和 HCDN 没有关系。

另：
蹲一蹲楼上各位大佬写的分析过程 :)

https://i.loli.net/2021/05/25/XqRKVAo3u65SaEN.png

可以添加 __NAME__参数，控制弹窗提示的名字

http://192.168.123.81:55555/?i=1&__PROMPT__=1&__NAME__=hacked_by_somebody&__SRC__=hack

__SRC__参数的作用暂不明确

@droidmax61 #188 不清楚，可以问问 @essicaj 是怎么得到这个参数的 我猜测是快应用的 id 😕😕

http://127.0.0.1:55555/?i=1&__PROMPT__=0 设置参数为 0，不需要弹窗确认就可以进入到快应用里面了

http://ip:55555/?i=1&__PROMPT__=1 复现成功

路由器下有 iqoo neo, iqoo neo3 两台 vivo 系的手机，但是在我路由器的 upnp 列表里面没有看到这两个手机的任何端口的记录。

https://i.loli.net/2021/05/24/SKpjU8tiH7WBzd5.png

看了手边的一台 iqoo neo，发现不止监听了 55555 端口，还监听了 0.0.0.0:16080, 所有接口的 41741 端口，不过看起来另外两个端口似乎并不是 http 协议，我用 nc 和他交互可以成功建立 tcp，但是没有响应，推测是我发送的消息不符合他的格式。
```
PD1936:/ $ ss -tlpn
State Recv-Q Send-Q Local Address:Port Peer Address:Port
Cannot open netlink socket: Permission denied
LISTEN 2 0 0.0.0.0:16080 0.0.0.0:*
LISTEN 0 0 *:55555 *:*
LISTEN 0 0 *:41741 *:*
LISTEN 0 0 [::ffff:127.0.0.1]:41525 *:*
PD1936:/ $
```

vivo 固件是可以下载的 在 https://www.vivo.com.cn/upgrade/index，但是网页的按钮似乎有点问题，F12 找到链接，还可以下载的

早晨看到 iqoo neo 是有这个问题的，最新版 iqoo neo 固件的地址是 http://sysupwrdl.vivo.com.cn/upgrade/official/officialFiles/PD1914_A_8.6.8-update-full_1616036354.zip ，看最后的时间戳可以推测这是 2021-03-18 的固件，个人推测这个版本的固件监听 55555 的概率较大。

菜鸡只能帮到这里了，有请逆向大佬上 :)

1. 目前能看到系统进程开了个端口，具体作用暂不清楚。开了个端口不代表一定被人发现了漏洞，不代表现在就能被攻击者访问手机内的数据。但是手机开放端口有较大的漏洞风险，因为这个端口是厂商自己的服务，可能没有经过有效的代码审计，一旦出现问题那么后果很严重。

2. 上一个这么干的是 ES 文件浏览器，漏洞编号 CVE-2019-6447 。ES 文件浏览器监听 59777 端口，内网的其他设备无需鉴权即可访问该手机的文件、启动 APP 。漏洞刚出现时在我手机上复现成功，我从我的第一个手机开始到出现这个漏洞时，我的每个手机都安装了 ES 文件浏览器，此漏洞出现后，我再也没用过 ES 文件浏览器了 :( 太令人恐惧了

3. 此次 vivo/iqoo 手机除了监听了端口，还用了 UPNP 协议主动暴露自己到公网，为什么一个手机需要完成服务器的使命，乐观点，这是边缘计算的落地么？如果存在类似于 ES 文件浏览器的问题，那么影响范围相比于 ES 文件浏览器的未授权访问漏洞，将会几何级数的放大。fofa 上能看到有 7 万多台错误的暴露在了公网的手机，而这些手机，本应该隐藏在 Nat 后面的，这些手机用户可能连什么是端口，什么是 IP 地址都不知道，但是他的手机却可能被素不相识的攻击者用批量控制的脚本接管 :(

4. 我上一个回答 #50L 的截图里面的某一个 iqoo 用户，刚刚问我有办法关掉这个端口么。我觉得吧，关不了，我们花钱买的手机，并不是我们的手机，智能电视上的勾正数据也一样，小米的应用启动注入广告也一样，我们花钱买的设备获得了设备的法律上的处分权，但是事实上行使对手机软硬件处分权的，是系统厂商、APP 提供商，我们只是一个用户 :(

5. 厂商不是做慈善的，有利益，厂商才能开发新的应用，完善应用功能，消费者才能在手机上使用各种应用，二者密不可分，共同在法律的框架下行使和享受各自的权力和义务。然而互联网发展太快，隔几个月就会有新的玩法，但法律的制定往往需要数年的时间，因此法律往往滞后于互联网的脚步，而厂商往往利字当头，就会出现各种离谱的利用消费者数据、消费者的设备干的事情。说到底， 我们只是大数据时代的某个数据库里面的某一行记录而已 :)

https://i.loli.net/2021/05/24/Bfs81mMoJO9Cq2r.png

iqoo 也一样

具体是做什么用的有待进一步分析，目前只知道开了这个端口。

@cdlnls 巧了巧了 我也这样用的

我一直用的 1.2.4.8 延迟 5ms 左右，体验挺好的 :)

+1 最近报销出租车票变得麻烦不少，所以我选择不加班了 :)