WebSocket走私实践（附赠LiveGBS监控系统未授权管理员密码重置）

WebSocket走私实践（附赠LiveGBS监控系统未授权管理员密码重置）

对此，我特别感谢TryHackMe和HackTheBox academy，永远相信和追随英国TryHackMe所教导的网络安全知识,并保持学习

WebSocket走私相关的知识在这里^[1]

前段时间学习过http1/2走私、websocket走私，所以令我对response status code 101和426有了从未有过的关注

并成功在实战中关注到101和426的http响应，最终找到一处WebSocket走私

此处 WebSocket升级时导致走私的原因是设置了错误的版本，如， 请求头：Sec-WebSocket-Version: 777 再将Content-Length设置为0，即可触发WebSocket走私。

进一步原因是前端没有验证后端WebSocket是否升级成功(code 101)，即使升级失败（code 426）前端也依然使用WebSocket处理，而后端仍然使用HTTP，在TryHackMe已经解释的非常清楚

当前端处理完交给后端时，后端会处理Content-Length和Transfer-Encoding标头，我们就可以通过传统HTTP走私伪造http请求头来触发它

这还是第一次在实战中发现这一切，尽管后面发生了些不愉快的事情，但THM与HTB所教导的知识利用在了现实环境中的感觉依然很棒。

LiveGBS 匿名访问 未授权管理员密码重置缺陷

开启了匿名访问就可以浏览监控

但LiveGBS系统的游客访问并不是因为有专门的功能开发，而是关闭了api鉴权功能，所以根据LiveGBS的api文档，我们可以很轻松的利用密码重置api来对管理员账户进行密码重置。

可以看到重置密码这条日志的操作人是空的

References

[1] 这里: https://tryhackme.com/r/room/wsrequestsmuggling

原文始发于微信公众号（APT250）：WebSocket走私实践（附赠LiveGBS监控系统未授权管理员密码重置）