This Week In Security: MOAB, Microsoft, And Printers

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.

15 thoughts on “This Week In Security: MOAB, Microsoft, And Printers

  1. Wait, what? HP printers phone home to verify the ink cartridge is legit?
    What happens if the printer is behind a firewall, or airgapped?
    My Epsons try to phone home, but seem unperturbed when they can’t.
    My Brothers present a webserver to the local net, but my firewall shows they never try to phone home.

    1. WELL this explains why my printer at work is bricked. Screw me for saving money I guess. Scanner still works though. I don’t plan on spending money on anything HP – nor do I currently.

  2. Hmm… The printers at a friend’s work are all HP. They are lasers though but are running Windows CE! Why on earth a printer should be running that monstrosity is anyone’s guess.
    It’s weird to watch a printer crash and then take nearly FIVE MINUTES to reboot! It goes through what feel like 50 separate checks of hardware and firmware before actually allowing you to resume printing. Even switching it off and on again results in the same thing.
    Not sure about laser cartridge DRM but I wouldn’t put it past HP to be into those kind of shenanigans too.

  3. I feel you were too kind to HP there….

    Also, claiming the attack vector is “squarely in the realm of state-sponsored actors” is kind of like saying: this project is so hard only, only low to mid level civil servants will be able to get it done. I’ll bet you a pint that either a hobbyist or academic gruop creates a PoC before any states sponsored groups (of course, there is the ‘how would we know’ issue).

    The usually state-sponsored approach to these things is just pay the printer company to add a back door.

    1. While proof of concept attack is something that is able to be pulled off by individual to make it at practical scale you actually have to pose pretty much as an ink manufacturer, as if I remember correctly the chip itself is a part of ribbon cable assembly that also includes printing nozzles (might be wrong on that one). And even if acting as a middle man that requires sizable investment at the start before you start seeing any profit.

      1. The 3rd party cartridges use a reprogrammable IC, so you would just need to program another 3rd parties cartridge to deliver malware. That said if this was a real issue that was actually exploited than it would have triggered a strong response in the news. It would be rather sensational for spooky chinese ink cartridges stealing your money. This applies to more than HP, almost all printer manufactures have cartridges with ICs in at least some of their printers.

  4. My two printers (Brother) are all on the ‘local’ home network which doesn’t have internet access. I have two ‘networks’ here just for that reason. Nothing touches the internet unless I want it to.

    Never had good luck with HP, went to Epson for awhile, but now using Brother Printers (Laser and InkJet Tank). On other hand, have co-workers that love there HP Printers :) .

    I don’t mind printers sensing ink level… But printers phoning home or only allowing proprietary cartridges seems wrong to me. I have no problem with a statement that warrenty is VOID If using non-HP ink. Fine. Up to the owner then. That makes sense. But bricking a printer just because is just wrong.

  5. HP is just talking nonsense. Think about it – if there was a security issue there, when would the exploit happen? I’d be confident in saying it’ll happen when the printer reads and parses the data, which of necessity happens before it validates (or otherwise) the cartridge as HP… So by the time the printer rejects the cartridge as third-party, the (theoretical) exploit would have already happened – and the check accomplished exactly nothing for security.

    1. I’m wondering just how bad is HP’s firmware if it can pass malware through to a computer. I thought the cartridge is supposed to have only the unique serial number (to verify with HP server) and a rewrite-able area for cartridge usage (to ensure empty cartridge doesn’t show up as full on a different printer) and no way for a code to go through, hack printer to to pass the code to the computer.

      If HP isn’t confident that it can’t prevent malicious code from getting passed around off shady ink cartridge, then maybe we shouldn’t buy HP printer anymore? What’s to prevent hacker from taking genuine ink cartridges, reprogramming them with virus, then selling it as new? If HP printer thinks it’s a genuine cartridge and passes malware to the host computer, that seems to suggest HP needs to fix their printer firmware to not accept or pass anything other than serial number and estimated ink cartridge’s remaining ink.

      I haven’t had any HP printer since I think the 920c which was about 2 decades ago. HP was being shady back then with tiny cartridge costing $30+ and lasting maybe 20 full color photo 6×4 before it reports empty already.

      1. I think the attack vector idea is to fine and exploit a buffer overflow or some other flaw in the code when sending the serial number and remaining ink levels data. But who knows, there maybe flaws else where, such as when the printer is booting there maybe opportunities to inject code/data over whatever bus the cartridge is on.

        Once you have code running on the printer you have control of a networked device on a trusted network somewhere. Bonus, people on that network generally trust that device and data coming from it, so maybe when documents are scanned you can include some malicious code/data to infect other machines. Or perhaps reduce detection risk and try to quietly send off a copy of printed/scanned data (assume the printer has network access, of which many do).

        > “maybe we shouldn’t buy HP printer anymore?”

        I think that is a reasonable idea, and not just because HP says they have poor security. It was the HP ink cartridge DRM nonsense that led me to go with an Epson EcoTank. Buying your ink by the liter, rather than the milliliter, is so much better.

    2. Also curious about that. What data exactly are they farming from a printer? Or better yet, what data is HP harvesting from *us* that they don’t want out?

      Of course, if you don’t want to deal with a gray market, there’s the obvious solution:
      Make your products better and cheaper (two words that often don’t go together) so people don’t look elsewhere.

  6. > […] HP has a secure manufacturing process […]

    HAHahahahahahhhaaaa! Tell another one.

    Also, the attack surface of HP’s cryptographic cartridge verification protocol is likely larger and more complex than the attack surface of the actual data protocol. By adding that complexity, they are actually *increasing* the chance that a fake cartridge could own your printer.

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.