restkhz

我没有逆向 fnos 固件，仅根据网上别人的逆向截图和别人的 poc 等公开信息简单说一下。

你理解对，路径穿越。本来是设计的不同尺寸图标读取，加载不同 size 的图标，但是 size 直接就作为文件名拼接在路径后，完全没有任何检查。
而后 web 程序权限是 root,正好什么都能读取了，用户数据裸奔...

然而仅仅只是路径穿越，任意文件读取吗？

它还有自己设计的很特别的鉴权，有几种模式，其中一种：
登陆鉴权是生成一个 16 位的玩意儿，结尾必须是'o'，姑且叫 secret.然后拿着 secret 这玩意儿, 再从 pem 里截取一段，作为 AES 的 key 给这 16 位玩意儿加密。这叫 token 。最后带着 secret, token 一起发给客户端。客户端用 secret 给请求做 hmac 签名。
服务器根本不存什么 token, secret 这些。只要用户发来的 token 解密后最后一位是'o'就去拿着这个东西去算请求的 hmac. 和用户请求中 hmac 对得上就 ok.之前自己生成的 secret 压根就没在用。
反正安全性全部依赖于那个 pem 中截取的密钥。

所以非常不巧，路径穿越能直接读取那个 pem 得到密钥, 就可以自己生成 secret 和 token,伪造 hmac 登录。


最后，后台拉取 docker 镜像的地方存在用分号就可以 RCE 的问题...

于是，实际上这里有三个漏洞，从路径穿越到 getshell ，拿下 root.

然后这一切又因为 FN connect 再次放大问题...我不知道 FNconnect 原理，但是我感觉因为流量走向问题很可能不特殊配置的 waf 也没用。

总之，输入处理有问题，权限设计有问题，用户鉴权有问题，反正就是哪里都有问题，问题甚至是低级问题...一堆问题堆在一起就变成超级大问题。最后处理也有问题...

@est 看你博客很久了：）

其实 TLS 也不用非对称的 key 加密，只是验证身份。通信都用对称加密比如 chacha20, aes 这类对称加密。因为能用 DH 做密钥交换，DH 密钥交换确定的密钥经过处理后才作为通信时对称加密的 key.

TLS1.2 有用过 RSA 做过密钥交换(加密传递生成密钥的参数)但是不够安全，几乎不用。

RSA 其实问题很多，上面这种情况没 PFS,而且 RSA 加密消息长度很有限，计算还慢，还有 Bleichenbacher 问题。

我上一个回复说到的 PGP 中其实 RSA 负责的是身份验证，和密钥传递。密钥？什么密钥？对称加密的密钥。邮件到底还是 AES 这类对称加密的。

TLS1.2 密钥交换时同时服务器发证书，证书不对，直接放弃握手,密钥还没协商完。
TLS1.3 更像 SSH ，先加密再发证书。只不过为了效率尽可能减少了来回通信，而且因为证书被加密就不怕证书 SNI 泄漏问题。

但是 TLS 和 SSH 依旧是两码事。

在上述所有场景中，公钥密码学仅仅是为了身份验证，为了防止 MITM, 而且几乎不参与加密。

回楼上一些 v2er, 这里防御的路径穿越是指某个脚本输入参数中的路径穿越，和 web 服务器的路径穿越不一样。
/lib/file.php?path=../../../etc/passwd
/rAnd0mP4th/file.php?path=../../../etc/passwd

是上面这个区别。如果你都找不到./rAnd0mP4th 那么后面脚本的任何漏洞都很难被利用。


这个技巧在 asp 时代就常有人用，当时就算 accessDB 被 SQL 注入，脱裤，管理密码 md5 被破，然而找不到后台登不上去，还是传不了马....
当年我忘了是阿 D 还是明小子都有路径爆破功能。


还有改服务器 banner ，改版本,包括但不限于 web,ssh...
屏蔽指纹，有时候就算有漏洞 bot 也无法选中。比如 bot 写的是找 wordpress 几个版本，然后一旦找到对应版本就用对应 exploit.然后你直接把版本改成 999.999.它无法选定...

有些很有意思的小技巧可能是《 web 之困》里提到的？我十多年前读的了，记不清了。但是值得看看。

楼上的一些 v2er ，我只是提醒一下，
不管是 TLS 还是 SSH 都不是非对加密
这也不是对称加密和非对称加密的区别，而是利用公钥密码学的另一种身份验证方法。

这里无论你是 RSA 还是 ed25519 ，还是 OP 的 16 位密码，都只是在做身份验证而已。
通信加密早就完成了。而且用的是对称加密。和上面说的 RSA, 16 位密码都没有关系。

“非对称加密”这个词本身就有误导性。实际上 RSA 很少用于加密通讯内容，PGP 都没有用 RSA 加密邮件内容。而 ed25519 甚至本身就不具备任何加密解密能力。

验证身份本身就有很多方法，无论你是密码，公钥，还是 TOTP ，都在不同场景有不同的优势。

我觉得 OP 问的问题是好问题。他的确有好的理由质疑，而且发表质疑需要勇气。

@Admstor OK, 你想谈安全。
你要从抵抗暴力破解来说，你这种情况完全足够了。非常安全。

但是！

从设计思路上来说，“口令”这种东西就是要给对方进行验证的。你有 secret,我也有，我要给你看 secret 来证明我有。两端都一定会要存有 secret ，并且在验证的时候这个 secret 一定会被传输。
公钥认证的思路是我们 secret 从不离开自己的设备。只要做一次 challenge-response 证明你有 secret 就可以. 我们只是用 secret 签名，secret 不会被传输，甚至服务器上都不需要存有 secret 存在.

你觉得哪种设计更安全？以后能暴露的攻击面更少？

你的对手会的不只是暴力破解。secret 出现的地方越多，出问题的可能性越大。我理解你讲的比如如果我密码足够强就算黑客读到/etc/shadow 也破不出来，和黑客拿到公钥没用同理。然而一旦出现 secret 明文本身呢？楼上也有说到 PAM 模块直接拦截读取明文的，这就是问题。但是我们或许应该在一开始就直接掐死这种可能。只要 secret 压根不出现在服务器上，不被传输，就没这些事情了。



我们抛开上面的理论层面的东西，
在现实世界中，合理的密码的确足够强。我自己也有不少设备和 VM 都是用密码的。小规模使用其实不会有任何问题，这也是为什么他至今都存在。
问题就是它经常被不合理使用，而且随着规模的扩大它只会越来越不方便。所以到一定规模的时候，我认为，使用公钥的最大原因就是：方便管理

安全这种东西你永远不能指望用户。用户是可以用 123456 作为密码的，是可以为了看毛片随手运行 exe 并且卸载杀毒软件的。更不要说定期更换密码，16 位大小写数字符号组合。所以不如直接逼着用户用更复杂的一套算了。


所以回到问题本身，我觉得公钥的确是更安全的，从理论和应用上都是。我希望我说清楚了。


顺便我在某个实验室做运维，管理 100+的 OS ，你猜猜我们用什么做 SSH 验证？密码？公钥？





答案：都不是，我们用 kerberos
kerberos 就更安全吗？没有。单纯就是管理方便。

安全不安全，你得带着威胁模型再讨论。在你提出的问题中，如果仅考虑暴力等等的，你这的确安全。
但是考虑防御纵深，那就不如公钥那么安全。就这样。管理也没那么方便。

主要是密码管理问题

比如，服务器有 root 账户,你们几个人一起维护用同一个密码，一旦有人离职这密码就要换掉。但是你现在只需要删掉他公钥就行。就不要说还有那些能 sudo 账户可能还有弱密码的问题...反正直接禁用密码用公钥就没这些事了。

另外你描述的 16 位密码大概是等效 log2(94)*16 ，105bit 。还是不够长。你要是有 20 位就能做到 128bit 了 XD

问题是公钥认证模式中几乎不可能做暴力破解。登陆时你要先发你的公钥，你要不先偷到公钥，要不先猜那个巨长的公钥。公钥先猜对了，服务器这时候要你签名之前步骤里的信息，你这才有机会开始猜私钥...

用密码服务器多了也要用密码管理器...不如用一个公钥私钥对直接解决大部分密码管理问题了。

另外私钥也可以上密码的。

没 IP 暴露公网也会因为用了 fnconnect 而被攻击。这种重大问题应该直接快速下架切断的。
这态度也没谁了。自己质量问题甚至处理不合规，反咬怪用户没更新，还一口一个“国家规定”，“小姑娘裸奔”，“请联系渠道经理”，“为什么我可以遵守规定没受到影响？”，真 tm 恶心。

他最好不要是官方的。否则企业加重责任。

@qingshengwen 估计是 Nv 独显，GTX16xx 或者 2060.