This Week In Security: Bitdefender, Ripple20, Starbucks, And Pwned Passwords

[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.

Image by Wladimir Palant, CC BY-SA 4.0

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.


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.)

JSOF reached out in response to my criticisms, and made some fair points in their defense. I’ve included their response below.

“JSOf only uses the emails to send a one time single email offering to join our mailing list of all-research and content. Subscribing to the mailing is explicit and a subscriber would have to insert their email again and press subscribe. We have been receiving good feedback to this process.

We believe the description of vulnerabilities as zero-day vulnerabilities correctly depicts the situation at the time of publishing and the current ongoing situation where patches are not available for many devices, many devices remain unpatched, and more vendors and devices are expected to release advisories and patches”

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 following API endpoint 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.)


13 thoughts on “This Week In Security: Bitdefender, Ripple20, Starbucks, And Pwned Passwords

  1. Dear HaD:
    I do get the issue with ad blockers and making revenue. After all hosting a site is not free, especially if its popular. HOWEVER I DON’T trust ANY ad service to vet their ads, simply because I haven’t seen any of them do it. The only way to get me to turn off my ad blocker is to:

    1. Guarantee me that all ads are checked for malicious elements and/or at least guaranteed to come from reputable vendors, no middle men ie. g00gle.
    2. Show me only ads that relate to HaD activities.

    I’m seeing SamacSys ads so you are defeating “AdBlock+” to some degree, but that is the kind of ad I WANT to see.

    Re. StarBucks: This sort of thing frustrates me and I’m still looking for solutions for various webserver software. The pathname component of an URL should be vetted in the server and made sure it meets the following criteria:

    1. “:” and “\” are not allowed.
    2. “.” and “..” path components are not allowed.
    3. Always starts with “/”
    4. multiple consecutive slashes are not allowed.

    When any of those conditions are met a 400 (bad req) should be returned. There is NO valid reason for a webserver to have to handle relative URLs. A relative URL in the HTML should get reduced by the browser to the correct absolute pathname. In the common use cases this is already done. Honestly due to the lack of context the server is not capable of performing that function. It makes sense that this is done in the server, which would prevent EVERY site app framework from needing to dupe the effort. They get handed vetted URLs. Most frameworks don’t scrub URLs anyways. Instant win for everyone!

    #4 is probably the most difficult to enforce. Not hard for the server developer but due to the shear volume of incorrectly written templates and client side scripting (JS). I frequently see URIs like “/my_app//something/something”. So maybe #4 is an option. Personally I’d dev with it on and catch those things before they go into production.

    Re Editor’s note on passwords: cool recipe! Thanks for sharing. I wrote a simple bit of code years back to make passwords with a larger character set than used by Base64. But that was before /dev/urandom. It should also be noted that using /dev/random, will take longer, but will create a password with higher quality entropy. Use that for your most sacred digital asset access. :-)

    1. They’re defeating AdBlock+ by the most one-strange-trick method ever. They’re serving their own ads! (

      Since they don’t come from the usual sewer of web ad providers, they won’t be in any standard block lists. And I like site-served ads because they tend to be on topic, as well as not being flashy, in-your-face, or running sketchy scripts that try to track you, or simply peg your laptop’s CPU because they’re written by idiots.

      My problem isn’t with ads, it’s with annoying behavior that doesn’t just come from ads. For instance, I usually block video player scripts from web sites that do forced auto-play. I didn’t want to see their stupid video, and I don’t want to waste bandwidth on it even if it starts with the sound off.

      1. Yeah, I’m honestly fine with the concept of advertising, and site-served ads are usually fine. But I will NEVER disable adblock on an entire site, especially if the ads are hosted by Google, especially if the site tries to lock the content behind a whitelist-to-view frame (sup inspect element). The one ad provider I’ve whitelisted globally is Project Wonderful, and that’s because their guidelines make moot the reasons that adblockers should be considered a _security_ plugin… PW only allows static images or simple gif ads. No Flash. No sound. No JavaScript. Nothing that could possibly allow an ad to hijack the browser, download things without user interaction, etc.

  2. I wish you (Hackaday) would help make the distinction between ads and tracking. I support the idea of ad supported content, but I don’t support advertisers tracking my browsing the Internet.

    To deal with tracking, I use Privacy Badger from the EFF. Privacy Badger does not use lists of good and bad links. Instead, it watches for behavior such as pages from different sites looking at the same cookies and blocks only sites that it learns are tracking.

    1. I agree – it’s tracking that bugs the crap out of me too (way more than the adds) -which is why all my cooks and local storage etc get cleared quite often even within a browser sessions, and of course all are deleted every time I get out of the browser..

  3. For passwords, also consider `diceware`. It can be made prettier at the expense of security with:

    diceware –no-caps -n 5 -d” ”

    This generates passwords like:

    cowl usher ember ferrari sari

      1. LOL! “nordic rune”! I’ve had several of my passwords rejected at various sites because I used “special chars” that didn’t fall in there “special char” list… and I use a standard American keyboard, nothing fancy, just ASCII. Kind of like saying, “no! not THAT nordic rune!”

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.