Bogus security mechanisms: Encrypting localhost traffic

Nowadays it is common for locally installed applications to also offer installing browser extensions that will take care of browser integration. Securing the communication between extensions and the application is not entirely trivial, something that Logitech had to discover recently for example. I’ve also found a bunch of applications with security issues in this area. In this context, one has to appreciate RememBear password manager going to great lengths to secure this communication channel. Unfortunately, while their approach isn’t strictly wrong, it seems to be based on a wrong threat assessment and ends up investing far more effort into this than necessary.

Switching my blog to a static site generator

After staying on Textpattern for more than ten years, time was right for a new blog engine. It’s not that Textpattern is bad, it’s actually pretty good and rather sturdy security-wise. But perfect is the enemy of good, and a blog where it’s only static files on the server side is perfect security – no attack surface whatsoever. No PHP and no database on the server means far fewer security updates. And I can easily see locally what any modifications to the site would look like, then push to a repository that doubles as backup – done, the changes are deployed. Finally, I got simply fed up with writing Textile when everywhere else the format of choice is Markdown.

So now this blog is generated by Hugo, it’s all static files and the server can get some rest.

Screenshot of load average being 0.00

As an added bonus, the concept of page bundles means that adding images or PDFs to individual posts no longer results in an unmanageable mess. Migrating content and layout from Textpattern was fairly straightforward, with the custom RSS template to allow full blog posts in the RSS feed being already the “challenging” part.

But there are two inherently dynamic parts of a blog: search and comments. Very often, statically generated blogs will use something like Google’s custom search and Disqus to implement these. I didn’t want to rely on third parties however, for privacy reasons already. In addition, with comments I’d much rather keep them in the repository along with all the other content instead of breaking the beautiful concept with a remote dynamically generated frame. So here is how I solved this.

Dear Mozilla, please stop spamming!

Dear Mozilla, of course I learned about your new file sharing project from the news. But it seems that you wanted to be really certain, so today I got this email:

Email screenshot

Do you still remember how I opted out of all your emails last year? Luckily, I know that email preferences of all your users are managed via Mozilla Basket and I also know how to retrieve raw data. So here it is:

Should you be concerned about LastPass uploading your passwords to its server?

TL;DR: Yes, very much.

I’ve written a number of blog posts on LastPass security issues already. The latest one so far looked into the way the LastPass data is encrypted before it is transmitted to the server. The thing is: when your password manager uploads all data to its server backend, you normally want to be very certain that the data visible to the server is useless both to attackers who manage to compromise the server and company employees running that server. Early last year I reported a number of issues that allowed subverting LastPass encryption with comparably little effort. The most severe issues have been addressed, so all should be good now?

Sadly, no. It is absolutely possible for a password manager to use a server for some functionality while not trusting it. However, LastPass has been designed in a way that makes taking this route very difficult. In particular, the decision to fall back to server-provided pages for parts of the LastPass browser extension functionality is highly problematic. For example, whenever you access Account Settings you leave the trusted browser extension and access a web interface presented to you by the LastPass server, something that the extension tries to hide from you. Some other extension functionality is implemented similarly.

How much privacy do you have left on the web?

Every now and then, politicians will demand mandatory use of real names on the web. Supposedly, this will restrict hate speech and make the discourse more civilized overall. South Korea tried this approach already and realized that there was only a marginal effect if any. It has been argued again and again that this approach doesn’t help against hate speech but damages freedom of individuals [German], but why would anybody care about facts?

I have nothing to add to the debate as such, everything has been said already. But I, like probably many others, had the impression that the debate is going on because being anonymous on the web is so easy. You have to keep in mind that the last time I did something on the web without signing with my real name was more than a decade ago. So when now I tried to establish an identity on the web not tied to my real-life identity, I was in for a huge surprise: things changed massively! As things stand right now, being truly anonymous on the web is hardly possible at all.

BBN challenge resolution: Getting the flag from a browser extension

My so far last BugBountyNotes challenge is called Can you get the flag from this browser extension?. Unlike the previous one, this isn’t about exploiting logical errors but the more straightforward Remote Code Execution. The goal is running your code in the context of the extension’s background page in order to extract the flag variable stored there.

If you haven’t looked at this challenge yet, feel free to stop reading at this point and go try it out. Mind you, this one is hard and only two people managed to solve it so far. Note also that I won’t look at any answers submitted at this point any more. Of course, you can also participate in any of the ongoing challenges as well.

Still here? Ok, I’m going to explain this challenge then.

If your bug bounty program is private, why do you have it?

The big bug bounty platforms are structured like icebergs: the public bug bounty programs that you can see are only a tiny portion of everything that is going on there. As you earn your reputation on these platforms, they will be inviting you to private bug bounty programs. The catch: you generally aren’t allowed to discuss issues reported via private bug bounty programs. In fact, you are not even allowed to discuss the very existence of that bug bounty program.

I’ve been playing along for a while on Bugcrowd and Hackerone and submitted a number of vulnerability reports to private bug bounty programs. As a result, I became convinced that these private bug bounty programs are good for the bottom line of the bug bounty platforms, but otherwise their impact is harmful. I’ll try to explain here.

BBN challenge resolution: Exploiting the Screenshotter.PRO browser extension

The time has come to reveal the answer to my next BugBountyNotes challenge called Try out my Screenshotter.PRO browser extension. This challenge is a browser extension supposedly written by a naive developer for the purpose of taking webpage screenshots. While the extension is functional, the developer discovered that some websites are able to take a peek into their Gmail account. How does that work?

If you haven’t looked at this challenge yet, feel free to stop reading at this point and go try it out. Mind you, this one is hard and only two people managed to solve it so far. Note also that I won’t look at any answers submitted at this point any more. Of course, you can also participate in any of the ongoing challenges as well.

Still here? Ok, I’m going to explain this challenge then.

Maximizing password manager attack surface: Learning from Kaspersky

I looked at a number of password manager browser extensions already, and most of them have some obvious issues. Kaspersky Password Manager manages to stand out in the crowd however, the approach taken here is rather unique. You know how browser extensions are rather tough to exploit, with all that sandboxed JavaScript and restrictive default content security policy? Clearly, all that is meant for weaklings who don’t know how to write secure code, not the pros working at Kaspersky.

Kaspersky developers don’t like JavaScript, so they hand over control to their beloved C++ code as soon as possible. No stupid sandboxing, code is running with the privileges of the logged in user. No memory safety, dealing with buffer overflows is up to the developers. How they managed to do it? Browser extensions have that escape hatch called native messaging which allows connecting to an executable running on the user’s system. And that executable is what contains most of the logic in case of the Kaspersky Password Manager, with the browser extension being merely a dumb shell.

BBN challenge resolutions: “A properly secured parameter” and “Exploiting a static page”

BugBountyNotes is quickly becoming a great resource for security researches. Their challenges in particular are a fun way of learning ways to exploit vulnerable code. So a month ago I decided to contribute and created two challenges: A properly secured parameter (easy) and Exploiting a static page (medium). Unlike most other challenges, these don’t really have any hidden parts. Pretty much everything going on there is visible, yet exploiting the vulnerabilities still requires some thinking. So if you haven’t looked at these challenges, feel free to stop reading at this point and go try it out. You won’t be able to submit your answer any more, but as both are about exploiting XSS vulnerabilities you will know yourself when you are there. Of course, you can also participate in any of the ongoing challenges as well.

Still here? Ok, I’m going to explain these challenges then.