CVE-2020-26214
published 2020-11-06CVE-2020-26214: In Alerta before version 8.1.0, users may be able to bypass LDAP authentication if they provide an empty password when Alerta server is configure to use LDAP…
PriorityP184critical9.8CVSS 3.1
AVNACLPRNUINSUCHIHAH
EXPLOIT
EPSS
65.93%
99.2th percentile
In Alerta before version 8.1.0, users may be able to bypass LDAP authentication if they provide an empty password when Alerta server is configure to use LDAP as the authorization provider. Only deployments where LDAP servers are configured to allow unauthenticated authentication mechanism for anonymous authorization are affected. A fix has been implemented in version 8.1.0 that returns HTTP 401 Unauthorized response for any authentication attempts where the password field is empty. As a workaround LDAP administrators can disallow unauthenticated bind requests by clients.
Affected
3 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| alerta | alerta | < 8.1.0 | 8.1.0 |
| alerta_project | alerta | < 7.5.7 | 7.5.7 |
| alerta_project | alerta | >= 8.0.0 < 8.1.0 | 8.1.0 |
Detection & IOCsextracted from sources · hover to see the quote
yara↗
regex: '"name": "Alerta ([0-9.]+)"'
- →Send a GET request to /api/config and check the response body for the strings '"alarm_model"', '"actions"', and '"severity"' together with a 200 status code to fingerprint a vulnerable Alerta instance. ↗
- →Extract the Alerta version from the /api/config response body using the regex '"name": "Alerta ([0-9.]+)"' and flag any version less than 8.1.0 as vulnerable. ↗
- →Authentication bypass is triggered by submitting an empty password against the LDAP-backed Alerta login; the server must return HTTP 401 for empty-password attempts to be protected. ↗
- ·Vulnerability only affects deployments where the LDAP server is configured to allow unauthenticated (anonymous) bind requests; LDAP servers that disallow unauthenticated bind are not affected. ↗
- ·The bypass requires Alerta to be configured with LDAP as the authorization provider; non-LDAP authentication backends are not impacted. ↗
CVSS provenance
nvdv3.19.8CRITICALCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
nvdv2.07.5HIGHAV:N/AC:L/Au:N/C:P/I:P/A:P
CVEs like this are exactly what “Exploited This Week” covers.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
OSV
CVE-2020-26214: In Alerta before version 8
osv·2020-11-06
CVE-2020-26214 CVE-2020-26214: In Alerta before version 8
In Alerta before version 8.1.0, users may be able to bypass LDAP authentication if they provide an empty password when Alerta server is configure to use LDAP as the authorization provider. Only deployments where LDAP servers are configured to allow unauthenticated authentication mechanism for anonymous authorization are affected. A fix has been implemented in version 8.1.0 that returns HTTP 401 Unauthorized response for any authentication attempts where the password field is empty. As a workaround LDAP administrators can disallow unauthenticated bind requests by clients.
GHSA
LDAP authentication bypass with empty password
ghsa·2020-11-06
CVE-2020-26214 [CRITICAL] CWE-287 LDAP authentication bypass with empty password
LDAP authentication bypass with empty password
### Impact
Users may be able to bypass LDAP authentication if they provide an empty password when Alerta server is configure to use LDAP as the authorization provider.
Only deployments where LDAP servers are configured to allow unauthenticated binds (eg. default on Active Directory) are affected.
### Patches
A fix has been implemented that returns HTTP 401 Unauthorized response for any authentication attempts where the password field is empty. See https://github.com/alerta/alerta/pull/1345
### Workarounds
LDAP administrators can disallow unauthenticated bind requests by clients.
### References
https://tools.ietf.org/html/rfc4513#section-5.1.2
https://pypi.org/project/alerta-server/8.1.0/
### For more information
If you have any questions
OSV
LDAP authentication bypass with empty password
osv·2020-11-06
CVE-2020-26214 [CRITICAL] LDAP authentication bypass with empty password
LDAP authentication bypass with empty password
### Impact
Users may be able to bypass LDAP authentication if they provide an empty password when Alerta server is configure to use LDAP as the authorization provider.
Only deployments where LDAP servers are configured to allow unauthenticated binds (eg. default on Active Directory) are affected.
### Patches
A fix has been implemented that returns HTTP 401 Unauthorized response for any authentication attempts where the password field is empty. See https://github.com/alerta/alerta/pull/1345
### Workarounds
LDAP administrators can disallow unauthenticated bind requests by clients.
### References
https://tools.ietf.org/html/rfc4513#section-5.1.2
https://pypi.org/project/alerta-server/8.1.0/
### For more information
If you have any questions
No detection rules found.
Nuclei
Alerta < 8.1.0 - Authentication Bypass
nuclei·CVSS 9.8
CVE-2020-26214 [CRITICAL] Alerta < 8.1.0 - Authentication Bypass
Alerta < 8.1.0 - Authentication Bypass
Alerta prior to version 8.1.0 is prone to authentication bypass when using LDAP as an authorization provider and the LDAP server accepts Unauthenticated Bind requests.
Template:
id: CVE-2020-26214
info:
name: Alerta < 8.1.0 - Authentication Bypass
author: CasperGN,daffainfo
severity: critical
description: Alerta prior to version 8.1.0 is prone to authentication bypass when using LDAP as an authorization provider and the LDAP server accepts Unauthenticated Bind requests.
impact: |
Successful exploitation of this vulnerability allows an attacker to bypass authentication and gain unauthorized access to Alerta.
remediation: |
Upgrade Alerta to version 8.1.0 or later to mitigate this vulnerability.
reference:
- https://github.com/advisories/GHSA-5hmm-x
No writeups or analysis indexed.
https://github.com/alerta/alerta/commit/2bfa31779a4c9df2fa68fa4d0c5c909698c5ef65https://github.com/alerta/alerta/issues/1277https://github.com/alerta/alerta/pull/1345https://github.com/alerta/alerta/security/advisories/GHSA-5hmm-x8q8-w5jhhttps://pypi.org/project/alerta-server/8.1.0/https://tools.ietf.org/html/rfc4513#section-5.1.2https://github.com/alerta/alerta/commit/2bfa31779a4c9df2fa68fa4d0c5c909698c5ef65https://github.com/alerta/alerta/issues/1277https://github.com/alerta/alerta/pull/1345https://github.com/alerta/alerta/security/advisories/GHSA-5hmm-x8q8-w5jhhttps://pypi.org/project/alerta-server/8.1.0/https://tools.ietf.org/html/rfc4513#section-5.1.2
2020-11-06
Published