[Wladimir Palant] seems to be on a one man crusade against security problems in security software. The name may not be immediately recognizable, but among his other infamies is originating Adblock Plus, which we have a love-hate relationship with. (Look, surf the net with an adblocker, but disable it for sites you trust and want to support, like HaD).
This week, he announced a rather serious flaw in the Bitdefender. The disclosure starts off with high praise for the Bitdefender: “security-wise Bitdefender Antivirus is one of the best antivirus products I’ve seen so far….” Even with that said, the vulnerability he found is a serious one. A malicious website can trigger the execution of arbitrary applications. The problem was fixed in an update released on the 22nd.
The vulnerability is interesting. First, Bitdefender uses an API that was added to web browsers specifically to enable security software to work without performing man-in-the-middle decryption of HTTPS connections. When a problem is detected, Bitdefender replaces the potentially malicious page with it’s own error message.
Because of the way this is implemented, the browser sees this error message as being the legitimate contents of the requested site. Were this a static page, it wouldn’t be a problem. However, Bitdefender provides an option to load the requested page anyway, and does this by embedding tokens in that error page. When a user pushes the button to load the page, Bitdefender sees the matching tokens in the outgoing request, and allows the page.
This can be exploited through an AJAX call. A malicious webpage makes an XMLHttpRequest call back to the same domain, and manipulates the response so an error message is injected by Bitdefender. Since it’s the same domain, the contents of that response are accessible to the malicious page, meaning the security tokens are leaked. Those tokens can then be used to trigger the launch of Bitdefender’s Safepay browser. That’s not terrible in itself, but the real problem is the fact that the Safepay browser is launched using an attacker provided url. request.send("data:text/html,nada --utility-cmd-prefix=\"cmd.exe /k whoami & echo\""); The spaces don’t get properly escaped, so command line arguments can be injected, leading to arbitrary execution.
Ripple20
JSOF just released part of their research on the Trek TCP/IP stack, but they’re exploiting this to harvest email addresses, a tactic that I find repugnant, and frankly any security company should as well. Thankfully the PDF is available once you know where to look.
Trek produces an IP stack that can be used as an element of a Real Time OS, or even on embedded devices that lack a full OS. That software stack has been deployed on IoT devices around the world. This is what the JSOF researchers are talking about when they say “the supply-chain factor”. They discovered 19 separate vulnerabilities in this software stack, four of which were critical remote code execution (RCE) problems.
(I feel I must take JSOF to task once more, as they refer to these as zero-day vulnerabilities. While it may have been strictly true that they were zero-days when they were first discovered, the fact that JSOF went through a coordinated disclosure process means that these are no longer zero-day vulnerabilities. This seems like an attempt to hype their research, rather than being based on fact.)
So far, the details have only been released for two vulnerabilities: CVE-2020-11896 and 11898. The first is a RCE and the second an information leak. Both vulnerabilities stem from improper handling of fragmented IP-in-IP tunneled packets. Apparently the target device doesn’t need to have an IP tunnel configured, but it does need to have IP tunneling support. It’s unclear how common or uncommon this configuration is, but as long as fragmentation and tunneling support is present, all that is needed for compromise is a single open UDP port.
When receiving packets, when the length of packet fragments exceeds the length indicated in the packet headers, a function is called to trim the excess received data. It’s possible to manipulate this function such that more data will be processed than is expected. The excess data is copied beyond the end of an allocated buffer, leading to predictable results. There are some clever additional steps needed to actually achieve RCE, so go read the paper for more details.
Interestingly, Cisco just released an advisory detailing their initial work on triaging the Ripple20 bugs. So far it appears that patches are not yet available for vulnerable Cisco products, which highlights what a challenge this particular set of bugs might be.
Secure Boot Bypass
[Jason A. Donenfeld] of Wireguard fame has discovered a fun flaw in the Linux kernel’s lockdown mode. Kernel lockdown is an extension of the EFI Secure Boot scheme that, among other things, ensures that unsigned kernel modules don’t get loaded, even by root. As you can imagine, it was an uphill battle getting that feature in the Linux kernel at all.
The vulnerability is an EFI variable that can be written to, even with a kernel lockdown policy, that inserts an ACPI table. This essentially means injecting code into the pre-boot process, instructing the booting machine to set the kernel lockdown policy to disabled. The humorous part of all of this work is that Donefeld’s test case is loading the Wireguard module. It seems like a lot of work just to get his VPN to load.
Searching a Starbucks API
[Sam Curry] must constantly have his browser’s DevTools window open, because he just happened to notice API calls that were being processed while he was purchasing a Starbucks gift card. Being the curious, security minded individual he is, Sam decided to take some time to explore the API that was being used. He quickly determined that the API was using an Internet facing front-end to proxy API calls into the Starbucks internal network. After much trial and error, the API endpoint/bff/proxy/stream/v1/users/me/streamItems/web\..\.\..\.\..\.\..\.\..\.\..\.\search\v1\Accounts\ was discovered. It was never intended to be publicly accessible, but some clever path traversal work made it possible. This endpoint allowed Sam to search through every user in the Starbucks system, all 100 million records.
This did represent quite the problem, so the finding were quickly reported, and fixed within 24 hours. There isn’t any evidence that the vulnerable endpoint was independently discovered or exploited. Sam did net a nice $4,000 bounty for the find.
Pwned Passwords, Version 6
[Troy Hunt] keeps popping up, and this week it’s because he published the sixth iteration of the Pwned Passwords service. He wrote a blog post about the update, and the update added over 17 million new passwords. For those of us not familiar with the service, it’s a web page where you can enter your password, and see if it’s been compromised in a data breach. Yes, you read that right, the intention is for you to go enter your password on someone else’s web service. Yes, this is nuts. The r/netsec Reddit thread has both had a lot of fun with this, and has suggestions for how to use the service without trusting any of Troy’s code.
All kidding aside, the service uses k-anonymity to protect your password. It works like this. Your browser takes the password you enter, generates a SHA1 hash, and then sends the first five characters of that hash to the service. The list of hashes beginning with those five characters is returned, and the code running in your browser checks to see if the full SHA1 is in the returned list. It’s clever, should be safe, and there’s still no way I’m putting an important password into that web site. Instead, I prefer the simple python script put together by [Ben Wiederhake]. It’s short and simple enough for all of us to read through the source before running it.
(Editor’s note: I use Pwned Passwords occasionally. It’s good for verifying that your non-critical password(s) aren’t easily crackable. Hackaday1234 passes, for instance, so feel free to use that for forum logins. But your actually important passwords should be unique, long, and randomly generated, and thus don’t even require checking. head -c 8 /dev/urandom | base64 and done. Security can be very simple if you let it.)
No comments:
Post a Comment