This Week in Security: MOAB, Microsoft, and Printers [Hackaday]

View Article on Hackaday

This week, news has broken of the Mother of All Breaches, MOAB. It’s 12 terabytes and 26 billion records, averaging about 500 bytes each. Now note that a record here is likely not a discrete email address, but simply a piece of data — a row on the database.

Now before we all lose our minds over this, there’s an important detail to take note of: These aren’t new leaks. This is a compilation of leaks, and as far as researchers have checked, there aren’t any new leaks disclosed here. This was someone’s database of accumulated leak data, accidentally re-leaked via an unsecured database. [Troy Hunt] goes so far as to speculate that it could be from a breach search service, which sounds pretty plausible.

There was yet another release of credentials late last week that hasn’t attracted as much attention, but seems to represent a much bigger issue. The Naz.api data set isn’t a breach where a company was hacked, and their entire user database was stolen. Instead, this one is combination of a credential stuffing list and stealer logs.

Credential stuffing is basically a smarter brute force attack, where the credentials from one breach are tried on multiple other sites. Such a list is just the results where guesses were successful. The really interesting bit is that this dataset seems to include stealer logs. Put simply, that’s the results of malware that scrapes victim machines for credentials.

Naz.api has over 70 million unique email addresses, and it looks like about a third of them are new, at least according to the Haveibeenpwned dataset. Now that’s significant, though not really worthy of the MOAB title, either.

Microsoft’s Mysterious Shellacking

Microsoft got their email breached, and the story is weird. Microsft states that it was Midnight Blizzard, a Russian APT, and that initial access was via a “password spray attack” — essentially a dictionary attack. Microsoft states that this approach attackers to “compromise a legacy non-production test tenant account”. And from this foothold, attackers “used the account’s permissions to access a very small percentage of Microsoft corporate email accounts, including members of our senior leadership team”. It feels like there’s a whole lot of details in the missing step two of this story, before Midnight Blizzard arrived at PROFIT!!.

A late update has come in on this story. It looks like there was an old OAuth application that had some sort of global admin access to the entire Microsoft corporate environment. This is very new information, but it’s beginning to look like Microsoft accidentally left the keys in the lock on this one.

HP Saves Printers by Bricking Them

Printer companies have done some sketchy things over the years. For example, I remember one unit I was tasked with configuring, that was programmed not to print anything until a Windows machine finished an online registration process — it was bricked out of the box, unless unlocked through this process. So it’s not terribly surprising to read that HP is pulling a similar stunt, bricking printers when third-party ink replacements are installed. If you’re wondering how they haven’t been sued into oblivion for this tactic, the answer is that the lawsuits are still ongoing. But what really caught our attention is the explanation HP came up with to defend this practice: We brick printers to protect them from viruses on that unauthorized ink.

OK, so let’s take a look at this claim. HP puts a memory chip in each of their cartridges, which contains the model and serial number of the cartridge. The printer pulls this data from the chip and sends it off to HP for verification. So, embedded firmware, pulling very structured data from a black-box source, that gets lightly manipulated and forwarded on. That sounds exactly like a situation where buffer overflows and vulnerable code would abound. So the basic premise checks out. HP printers probably have vulnerable code that reads from ink cartridges.

The rest of HP’s argument is that third-party cartridges are using re-programmable chips, which could contain a malicious payload. Because HP has a secure manufacturing process, it’s much less likely to deliver something malicious. And honestly, that thought checks out, too. Who knows where third-party cartridges come from, and who’s had access to them?

So… Thanks HP? Not so fast. There’s a couple intervening points. The first is that this sort of attack would necessarily be targeted and difficult to pull off. It’s a possible threat, but one that’s squarely in the realm of state-sponsored actors. And most importantly, why exactly do HP ink cartridges have data chips and a serial data connection in them? It’s specifically so HP can implement cartridge DRM. So yes, this is a self-causing security problem.

And if that’s not enough printer security news for one week, Lexmark has announced a pair of vulnerabilities in PostScript interpreters. The really interesting one is a vulnerability in the Service Engineer menu, that allows for arbitrary code execution.

Crawling Domains for Secrets

It’s amazing what a clever idea can turn into with just a few days of work, and about $100 worth of compute. A researcher at Escape built a webcrawler with a single purpose: looking for exposed API keys. The crawler was fed with the Majestic Million list of the top one million domains (Hackaday clocks in at number 2,757), and set off to work.

The results are a bit surprising. After scanning just under a million domains — governmental and other sensitive targets were pruned from the list — the tool found 18,000 exposed secrets. That’s nearly two percent of the world’s top million domains. Yikes!

Atlassian detailed and scanned

Last week we talked about a nasty Confluence vulnerability, and this week it already seems to be under active exploitation. ProjectDiscovery has us covered with a fairly deep dive into the issue, and it’s not a hard one to understand. Confluence uses Velocity template files, and Struts to actually serve those pages. But it’s possible to access the template files directly as an unauthenticated user. That’s not great, but what turns this into a serious vulnerability is that some of those templates will take HTTP parameters, and fire off processes with them. The text-inline.vm template in particular is vulnerable to this, and injected parameters can lead to code execution.

Bits and Bytes

Also from ProjectDiscovery, we have cvemap, an interesting little tool for quickly searching, sorting, and reviewing released vulnerabilities. Of particular interest is the integration with GitHub, the tracking of whether PoCs are in the wild, and more.

We prefer to talk about security problems when there are patches or workarounds available to mitigate the problem. That’s why we really don’t like problems like this one, that gets released after radio silence from the vendor. Researchers at HeroLab found a deserialization vulnerability in the Gambio online shop software that can lead to code execution. It was discovered back in December, and after six weeks of silence, we have disclosure. HeroLab has included a workaround that should protect Gambio installs, but warns that it may lead to functionality breakage.

And finally, there’s a bit of a storm brewing around CVEs, particularly when it comes to WordPress Plugins. It seems that a handful of security vendors are making the assumption that every vulnerability has always existed, and report CVEs as affecting every version prior to the fix, even when only a single version is vulnerable. The problem seems to be worse when these security vendors are anointed as CVE Numbering Authorities, CNAs. There is some hope, in that the CNA rules are being revised, and some of these issues are being considered. Here’s hoping.