昨天一个问题经历 5->4.8->4.5 然后还是没回我问题。。。一看耗了 7%的 5h 额度 真是难绷

好像还是会 529 ，得想办法快点蹬了，说不定额度会重置

ClickFix 攻击，我们这之前就有一个中招了，claude condex 都有这样的，是故意通过投放广告来做的，应该不是被黑了，除了 ai 工具还有其他的，很多机构出的都有文章分析和讨论了：
https://www.microsoft.com/en-us/security/blog/2026/05/06/clickfix-campaign-uses-fake-macos-utilities-lures-deliver-infostealers/
https://mp.weixin.qq.com/s?__biz=Mzg5MTc3ODY4Mw==&mid=2247508325&idx=1&sn=3c089f3e3bb02fbc6bbc8bc884ad4da7&chksm=cfcac271f8bd4b67f9c9200a1c89b84d3bb670c54f978f56c29ad6ebaa007f6a26766c2d5858#rd
https://www.linkedin.com/posts/kmapena_did-one-of-your-users-try-to-install-anthropic-activity-7448220206834810880-X7t5

@andlp 换个好点的 ai 吧。。
1. 核心触发原语：AF_ALG 与特定加密算法
脚本开头使用了 a = s.socket(38, 5, 0)。其中 38 对应的是 AF_ALG （ Linux Kernel Crypto API 的用户态接口）。
接着它绑定了特定的加密算法：a.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))。
algif_aead 是内核中处理 AEAD （认证加密）的核心模块。
authencesn 是一种用于 IPsec 的加密包装器，它需要处理扩展序列号（ ESN ）。在计算 HMAC 时，它需要对序列号的字节进行重新排列，这会导致它在目标缓冲区中执行一次 4 字节的临时写入（ Scratch Write ）。
2. 内存越权：splice 与页缓存投毒
脚本中使用了 os.splice （对应 C 语言的 splice() 系统调用）。splice 可以在两个文件描述符之间移动数据，而不需要将数据复制到用户空间（即零拷贝）。
在这个 payload 中，攻击者通过 splice 将目标文件（这里是高权限的可执行文件 /usr/bin/su ）映射到了加密套接字（ Socket ）的内存空间中作为“密文”输入。
漏洞的致命点在于：algif_aead 模块在执行加密操作时，默认是 “原地操作”（ in-place ） 的（即源缓冲区和目标缓冲区是同一个）。当输入数据是通过 splice 从普通文件映射过来时，目标散列表（ Scatterlist ）实际上直接指向了该文件在内核中的 页缓存（ Page Cache ）。
3. 利用过程：积少成多的 4 字节写入
当脚本调用 u.recv() 触发解密操作时，底层的 authencesn 算法会将攻击者通过 sendmsg 传入的 4 字节序列号（ seqno_lo ，即 payload 中的恶意指令片段），直接覆盖写入到由于原地操作而共享的“目标缓冲区”中。
因为目标缓冲区就是 /usr/bin/su 的页缓存，这就导致内核的只读页缓存被直接篡改了 4 个字节。
payload 中的 while i<len(e): c(f,i,e[i:i+4]); i+=4 是一个循环。它将一大段经过 zlib 压缩的 Shellcode （提权恶意代码）解压后，每次 4 个字节，利用上述机制一点点“缝合”进内核中 /usr/bin/su 的内存映像里。
4. 提权执行
当 4 字节循环写入完成后，内核中缓存的 /usr/bin/su 已经被注入了恶意的 Shellcode 。
此时脚本执行 g.system("su")。由于 Linux 内核会优先从页缓存中读取文件执行，加上 su 本身带有 setuid 属性（执行时拥有 root 权限），被投毒的 Shellcode 就会以 root 权限运行，从而完成提权
------
3. Linux 本该有的保护机制去哪了？（漏洞的真正命门）
是的，Linux 有一个极其核心的机制：内存权限控制（ Memory Management Permission ）。
在这个漏洞场景中，攻击者是用只读（ Read-Only ）权限打开的 /usr/bin/su 。
按照 Linux 正常的逻辑，当 authencesn 算法试图把那 4 字节的脏数据写到 /usr/bin/su 的页缓存时，内存管理系统（ MM subsystem ）应该立刻跳出来大喊：“停下！这个页面是只读的！”然后触发一个缺页异常（ Page Fault ），直接把操作干掉，甚至把当前的进程杀掉（ Segmentation Fault ）。
如果这个机制生效，那 4 字节根本写不进去！
那为什么没生效呢？这恰恰是这个漏洞（ CVE ）最核心的代码 Bug 所在：
内核的 algif_aead 模块在处理 splice 传过来的内存页（ Page ）时，它底层调用的是 kmap_atomic 之类的底层函数去直接映射物理内存。
这个底层的写入操作绕过了 VFS （虚拟文件系统）的写权限检查，也绕过了正常的 Copy-on-Write （写时复制）机制。它盲目地假设：“既然你把这个缓冲区指定为加密/解密的输出目标（ dst ），那它一定在前面已经被检查过是可写的了。”

安全运维更偏网络，安服、运营更偏应用安全，想跨过去还是需要一定的知识储备的
行业整体肯定是不如以往，但你起码也说下在什么地方，一线城市能力足够的话找个工作没问题的。不过安服不出差就有点难，头部几个大公司人员储备多的可能还好，例如北京公司就负责北京这块的业务，其他地方有各地的办事处啥的，但完全不出差也难

研究得越多越玄学，实际可能 IP 只占一部分，或者说很小一部分，我和我同事都是 8 块钱的机场，我用了俩月随便换节点，日本美国都用过还经常掉 IP 直连被客户端提示连不上，一点事都没，他号半天就没了

有受众自导自演罢了 认识的大佬没有一个像这样上蹿下跳的

怀念国补时候 2700 的 mac mini

按照零信任的设计思路，是需要应用去和零信任做对接的，但就目前各公司用的情况来看，还是当做普通的 VPN 在用，连网关分配一个 IP 然后通过虚拟网卡和隧道直接访问资源，权限还是靠所谓“零信任”给分配的，和 VPN 没感觉有任何区别

跟 MITM 有啥关系，没听说过中间人还能 RCE 的 这说法这不是忽悠傻子吗。。

这都算好的了，只图圈你使用费这点米
你搜 wps 搜狗输入法 chrome 这种更绷不住 都是银狐组织的钓鱼网站
bing 现在已经是一坨中的一坨了

从业人员告诉你 这都是自动化的探测、利用手段，你拿到了也是没什么鸟用的东西
要是对安全感兴趣可以先从渗透测试开始，搞这些自己都不知道是什么东西的东西，还想要利益
这很难评，祝你成功吧

给你提个建议，直接快进到关停，然后在这个帖子里把你爬的网站发出来，我们自己加收藏夹
当然 我只是建议

5080 还不如咬咬牙 4090 看着都觉得亏 老黄这刀法莫名其妙的

@BadFox 只讲屁股不讲脑子那还有什么好说的呢，你大可把最后一句话的网络安全素质直接删掉，我看那才是你想表达的。我之前在央企，关基每年都要做认定，是工信部牵头要交材料的，临时说是那是个 p 关基，刑法里的破坏计算机信息系统才是一般条件下可以扣的帽子，跟关基没有半毛钱关系

@BadFox 关基认定是有标准的，还真不是说是就是

@wellhome 现在所谓 AI 的原理就决定了他更适合做程序员的辅助，提升工作效率，你要是用 ai 做主导他给你挖了坑你都不知道 所以即使淘汰也是淘汰那种只会 crud 遇到问题就百度的，这种淘汰不淘汰的有什么区别吗
就像之前互联网兴起之后各种互联网+，AI 兴起也会带动传统行业 AI+，随着新技术你应该看到新的可能性，而不是在那自怨自艾没有买股票，你是没看到股票保卫 2600 的时候？