ntlm

4 Articles

This Week In Security: Filename Not Sanitized, MonikerLink, And Snap Attack!

February 16, 2024 by 6 Comments

Reading through a vulnerability report about ClamAV, I came across a phrase that filled me with dread: “The file name is not sanitized”. It’s a feature, VirusEvent, that can be enabled in the ClamnAV config. And that configuration includes a string formatting function, where the string includes %v and %s, which gets replaced with a detected virus name and the file name from the email. And now you see the problem, I hope: The filename is attacker supplied input.

Where this really gets out of hand is what ClamAV does with this string. execle("/bin/sh", "sh", "-c", buffer_cmd, NULL, env). So let’s talk defensive program design for a minute. When it comes to running a secondary command, there are two general options, system() and the exec*() family of system calls. system() is very simple to use. It pauses execution of the main process and asks the operating system to run a string, just as if the user had typed that command into the shell. While this is very convenient to use, there is a security problem if any of that command string is user-supplied. All it takes is a semicolon or ampersand to break assumptions and inject a command.

To the rescue comes exec(). It’s a bit more complicated to use, requiring the programmer to manually call fork() and wait(). But it’s not running the command via the shell. exec() executes a program directly, totally eliminating the potential for command injection! Except… oops.

Yeah, exec() and related calls don’t offer any security protections when you use them to execute /bin/sh. I suspect the code was written this way to allow running a script without specifying /bin/sh in the config. The official fix was to disable the filename format character, and instead supply it as an environment variable. That certainly works, and that fix is available in 1.0.5, 1.2.2, and 1.3.0.

The real danger here is that we have another case where some hardware appliance manufacturer has used ClamAV for email filtering, and uses this configuration by default. That’s how we get orders from CISA to unplug your hardware, because it’s already compromised. Continue reading “This Week In Security: Filename Not Sanitized, MonikerLink, And Snap Attack!” →

This Week In Security:Breaking CACs To Fix NTLM, The Biggest Leak Ever, And Fixing Firefox By Breaking It

July 8, 2022 by 16 Comments

To start with, Microsoft’s June Security Patch has a fix for CVE-2022-26925, a Man-In-The-Middle attack against NTLM. According to NIST, this attack is actively being exploited in the wild, so it landed on the KEV (Known Exploited Vulnerabilities) Catalog. That list tracks the most important vulnerabilities to address, and triggers a mandated patch install no later than July 22nd. The quirk here is that the Microsoft Patch that fixes CVE-2022-26925 also includes a fix for a couple certificate vulnerabilities including CVE-2022-2693, Certifried. That vulnerability was one where a machine certificate could be renamed to the same as a domain controller, leading to organization-wide compromise.

The fix that rolled out in June now requires that a “strong certificate mapping” be in place to tie a user to a certificate. Having the same common name is no longer sufficient, and a secure value like the Security IDentifier (SID) must be mapped from certificate to user in Active Directory. The patch puts AD in a compatibility mode, which accepts the insecure mapping, so long as the user account predates the security certificate. This has an unintended consequence of breaking how the US Government uses CACs (Common Access Cards) to authenticate their users. Government agencies typically start their onboarding by issuing a CAC, and then establishing an AD account for that user. That makes the certificate older, which means the newest patch rejects it. Thankfully there’s a registry key that can be set, allowing the older mapping to still work, though likely with a bit of a security weakness opened up as a result. Continue reading “This Week In Security:Breaking CACs To Fix NTLM, The Biggest Leak Ever, And Fixing Firefox By Breaking It” →

Microsoft Live Account Credentials Leaking From Windows 8 And Above

August 2, 2016 by 62 Comments

Discovered in 1997 by Aaron Spangler and never fixed, the WinNT/Win95 Automatic Authentication Vulnerability (IE Bug #4) is certainly an excellent vintage. In Windows 8 and 10, the same bug has now been found to potentially leak the user’s Microsoft Live account login and (hashed) password information, which is also used to access OneDrive, Outlook, Office, Mobile, Bing, Xbox Live, MSN and Skype (if used with a Microsoft account).

Continue reading “Microsoft Live Account Credentials Leaking From Windows 8 And Above” →

25 GPUs Brute Force 348 Billion Hashes Per Second To Crack Your Passwords

December 6, 2012 by 66 Comments

It’s our understanding that the video game industry has long been a driving force in new and better graphics processing hardware. But they’re not the only benefactors to these advances. As we’ve heard before, a graphics processing unit is uniquely qualified to process encryption hashes quickly (we’ve seen this with bitcoin mining). This project strings together 25 GPU cards in 5 servers to form a super fast brute force attack. It’s so fast that the actual specs are beyond our comprehension. How can one understand 348 billion hashes per second?

The testing was used on a collection of password hashes using LM and NTLM protocols. The NTLM is a bit stronger and fared better than the LM, but that’s not actually saying much. An eight character NTLM password will fall in 5.5 hours, while a 14 character LM hash makes it only about six minutes before the solution is discovered. Of course this type of hardware is only good if you have a copy of the password hashes themselves. Login protocols will lock out after a certain number of attempts and have measures in place to slow down automated systems like this one.

[via Boing Boing]