Top Trending CVEs of November 2022
- Nov 28, 2022
- Shawn Evans
Happy Thanksgiving! November was a surprisingly slow month. It’ll be perfect for some light reading over a thanksgiving break. In this edition we cover the once hyped and quickly downgraded OpenSSL vulnerability that made headlines in the late days of October. We also analyze a Windows Kerberos vulnerability introduced by the use of legacy RC4-MD4 encryption. Lastly, we round out the month with a Juniper SSLVPN unauthenticated remote command execution vulnerability.
Let’s get informed about what to be on the lookout for in this month’s trending CVEs.
This related set of vulnerabilities is present due to the implementation of legacy encryption algorithms used within the Kerberos protocol, specifically RC4. The attack is similar to an AES-REP Roast attack, with a brute force twist. The end goal being to gain unauthorized access to ciphertext encrypted with an RC4-HMAC key. As part of the Kerberos protocol, which has been around for a quite a while, it’s possible to define the desired encryption algorithm used to request a service ticket.
This attack requires the following for successful exploitation;
RC4-MD4 uses a 40 bit key for encryption. While it would be possible to brute force, it’s not practical for attacks on the wire. When a user submits an AS-REQ to the KDC, it typically lacks a pre-authentication timestamp, which results in an error response from the server (KDC_ERR_PREAUTH_REQUIRED). Within the error response, the server includes a list of supported pre-authentication encryption types, as well as the salt required to generate the encryption key for the user. When using RC4-MD4, the key used to encrypt the timestamp is the same as the key used to encrypt the session key. Therefore, targeting the timestamp is a much more viable attack path to recovering the ciphertext in the response. The rub with this attack is that the process must be performed on the wire, so there is a man-in-the-middle condition that needs to be satisfied. This is easy enough with the likes of Responder or mitm6. Assuming everything works out the end result is the ability to authenticate as a different user within the domain.
There is in fact a more functional exploit to this vulnerability (CVE-2022-33679), however this requires a KDC account to have pre-authentication disabled, which is uncommon and a vulnerability in and of itself. This one has an exploit in the wild available on github.
CVSS Score: 8.1
Systems Impacted: Windows Server 2012 R2 (Server Core installation), Windows Server 2012 R2, Windows Server 2012 (Server Core installation), Windows Server 2012, Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation), Windows Server 2008 R2 for x64-based Systems Service Pack 1, Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation), Windows Server 2008 for x64-based Systems Service Pack 2, Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation), Windows Server 2008 for 32-bit Systems Service Pack 2, Windows Server 2016 (Server Core installation), Windows Server 2016, Windows Server 2022 Datacenter: Azure Edition (Hotpatch), Windows Server 2022 (Server Core installation), Windows Server 2022, Windows Server 2019 (Server Core installation), Windows Server 2019
This was initially announced as a critical vulnerability, but later downgraded to high, but we’re going to cover it anyways. The vulnerability stems from a lack of validation checks on emails included as part of x.509 certificates. The vulnerability requires that a client or server validates the email address included in the x.509 certificate, which is not entirely common. Having satisfied this condition, an x.509 certificate with a crafted email address that contains non-ascii values can be used to trigger a memory corruption attack that results in denial of service (Dos) or remote command execution.
The vulnerability stems from the way in which punycode domains are expanded. Punycode is used to encode internationalized domain names from unicode to an ascii representation. The vulnerable function ossl_punycode_decode accepts a string buffer with a punycode domain and converts it to unicode. An attacker can exploit the vulnerable function by generating an x.509 certificate that contains a punycode domain. When a crafted punycode domain is encoded to unicode it results in an integer overwrite, because the unicode string exceeds the size of the output buffer by 4 bytes. The result of this uncaught condition is a crash. It’s worth noting that remote command execution has not been demonstrated in the wild.
The conditions required to cause a DoS condition are not common. Exploitation is also heavily dependent on the way in which the package was compiled. This is why the vulnerability was reduced in severity from critical to high.
CVSS Score: 7.5
Systems/Applications Impacted: OpenSSL v3.0.0 to v3.0.6
Researchers have identified a flaw in the way in which Juniper SSLVPNs process Phar files. Phar files are PHP archives that enable developers to pack PHP applications into a single file. When a phar file is processed by a PHP file operation the underlying metadata is deserialized. An attacker can exploit this behavior by crafting a malicious phar file that exploits an object instantiation vulnerability inside the Juniper code.
The key to this vulnerability is that the PHP does not have to be executed, but processed by any one of a number of file operations, such as get_dir_listing as used in the Juniper code . The deserialization can result in an arbitrary file write, which leads to remote command execution.
The vulnerability can be triggered by submitting a crafted request to the “/jsdm/ajax/logging_browse.php” script, with a crafted “filepath” POST parameter that points to a malicious phar file. It’s worth noting that phar files can have any extension. Unauthenticated adversaries can upload an image file (jpg) to the Juniper server via the image upload portal. This has a pretty low attack complexity with exploit code available in the wild. Patch up!
CVSS Score: 8.1
Systems Impacted: JunOS 19.1R3-S9, JunOS 19.2R3-S6, JunOS 19.3R3-S7, JunOS 19.4R3-S9, JunOS 20.1R3-S5, JunOS 20.2R3-S5, JunOS 20.3R3-S5, JunOS 20.4R3-S4, JunOS 21.1R3-S2, JunOS 21.2R3-S1, JunOS 21.3R2-S2, JunOS 21.3R3, JunOS 21.4R1-S2, JunOS 21.4R3, JunOS 22.1R1-S1, JunOS 22.1R2x, JunOS 22.2R1
To stay up to date on the latest trending and critical celebrity vulnerabilities, subscribe to NopSec’s newsletter. If you don’t like having to keep up with vulnerabilities like these yourself, let our Unified VRM platform do it for you. It takes into account new critical vulnerabilities as they emerge, ensuring your risks are prioritized accordingly in your unique environment. If you’d like to see what NopSec’s Unified VRM can do in action watch this on-demand product tour.