MOVEit FortiGate, someone is Rowhammering the door - July 2-8 2023 - F5 SIRT This Week in Security

Aaron back with you as your editor this week. As always there were a lot of news stories - most of which doesn't (in my opinion) warrant talking about at length; more ransomware[1] malware[2], volumetric DDoS attacks[3], the usual kind of news really, so I wanted to focus on three things that caught my eye for other reasons - either parallels to our own work in the F5 SIRT and F5s QSNs, problems that we've faced in F5 like the difficulties around updating large estates or simply things that really caught my eye from a technical perspective in an area that interests me personally (yes, you're going to read about some hardware level vulnerabilities!). I hope you enjoy the content, do let us know if you'd like to see more of a specific kind of news!

I like to MOVEit, MOVEit!

Progress Software are continuing their run of bad luck, disclosing another Critical and two more High severity vulnerabilities in the MOVEit Transfer software[1] - two of which are SQL injection vulnerabilities and one causing the application to crash. It seems likely that the SQL injection vulnerabilities could allow arbitrary code execution but they will certainly allow unfettered access to the database (and the Critical is an unauthenticated vulnerability[2] so can be exploited without any credentials), while the third vulnerability doesn't show any signs of code execution opportunity at the moment it could certainly result in a denial of service.

Two things came to mind reading all this:

First, I suspect the reason we're seeing a second critical on the heels of the first is that there is now simply more examination of the code happening; June's Critical CVEs (CVE-2023-34362[3] & CVE-2023-35708[4]) enabled a number of high profile attacks by the Cl0p ransomware gang[5] and that has the research community turning over all the rocks. I feel for the PSIRT team at Progress here, we have been in their shoes in the past and it can feel like you are enduring an unending onslaught; but it will abate and, in the long run, this is only a positive. Better that responsible researchers find these things than motivated malicious actors.

Secondly, I see that Progress has moved to a regular cadence for disclosing (and fixing) vulnerabilities. Similar to our own Quarterly Security Notifications (and as a reminder: our next QSN will be August 2nd) they have adopted what they call a "regular Service Pack program" of bi-monthly product updates and disclosures. For me this was just more proof that F5 has adopted the right principles for our own QSN programme.

Vulnerable FortiGate servers remain unpatched

We've talked at length about how hard patching systems at scale can be in previous issues as well as in This Month in Security[1], but I have to say, it feels like a large number of FortiGate administrators might be asleep at the wheel here.. In a report published on June 30th (which picked up news traction early July), Bishopfox[2] scanned the Internet and found 330,000 instances still vulnerable to CVE-2023-27997[3] sitting on the Internet (that is, after all, the job of a FortiGate); that equates to almost 70% of the entire exposed installbase (as determined by Bishopfox) which is quite something for a vulnerability originally disclosed in early June and for which exploits are available.

This is a problem that we, as an industry, really need to solve - how can we make the barrier to patching as low as possible? I am trying not to throw stones here considering BIG-IP is not always the easiest system to update, so I include F5 here as much as every other vendor; we all need to do better, be better. Clearly we can't stop fixing vulnerabilities, so we need to start moving toward software deployment mechanisms where updating can be made automated and we (as vendors) need to be investing heavily enough in Q&A that the upgrade 'gotchas' are few and far between - perhaps then administrators will be able to consume updates for things like BIG-IP or FortiGate as easily as Windows updates are rolled out to a userbase?

Rowhammer returns! Now for fingerprinting

I think I've talked about Rowhammer before - I've certainly talked about other hardware level vulnerabilities - but to recap:

Modern dynamic access memory (DRAM) stores each bit of data in an individual cell, with each cell comprising of one capacitor and one transistor. The capacitor, or rather its state of charge, is what determines whether or not the cell stores a binary 1 or 0. Those cells are then arranged into rows and columns, turning the cells into a giant matrix, and individual bits are read or written to by selecting both a row and a column via an address decoder.

Except it's a little more complicated than that; for the purposes of rowhammer, though, you really need to know two things:

One, when you 'read' a bit you actually transfer the charge from the capacitor to somewhere else, meaning reads are destructive, therefore every read must actually be a read followed by a write to re-write the value back to the cell.

Two, due to the design (and the way values - states of charge - are buffered), you can't write back an individual cell alone and you must write back an entire row.

That means that every read of an individual bit actually reads an entire row and re-writes an entire row back.

So where does Rowhammer come in? Well, DRAM is incredibly dense (we pack a lot of cells into a very small space) which means that write operations (which, remember, are triggered by a read operation) in one row will sometimes influence a change in the charge stored in cells in an adjacent row. This happens occasionally in normal operation, either due to external influences (cosmic rays - no, really!) or due to the constant refresh cycle DRAM must undergo to preserve the cell charges, and DRAM controllers use a range of techniques to detect and avoid it. Rowhammer aims to bypass these error correction techniques by 'hammering' a single row in memory - constantly reading from specific rows in order to influence the values in adjacent rows.

It all sounds very theoretical, doesn't it? But it's been proven to work and has become an enduring arms race between DRAM manufacturers implementing ever more complex error checking and researchers finding ever more inventive ways to bypass them - it pops up at conferences like BlackHat regularly where it has been proven to be exploitable for local privilege escalation (Seaborn, Duillien)[1] and VM sandbox escape (Razavi, Gras, Bosman, Preneel, Giuffrida, Bos)[2] among other things, and in papers presenting new mitigation techniques like CSI:Rowhammer (Juffinger, Lamster, Kogler, Eichsleder, Lipp, Gruss)[3] and now, finally, we can reach the subject of this section, Centauri (Venugopalan, Goswami, Din, Lowe-Power, King, Shafiq of UC Davis)[4]

Centauri is a Rowhammer based device fingerprinting mechanism - device fingerprinting is big business of course, used for everything from better ad targeting to anti-fraud solutions designed to detect whether the bank transfer request is coming from a recognised device - and the researchers believe their new Rowhammer based mechanism could be used for the latter; of course it could also be used for the former! Currently they have only proven their technique using native code (i.e. x86 or ARM code running on the operating system directly) but they believe it could be implemented within browsers as well, which is the more usual target for device fingerprinting.

Personally I think it is unlikely to gain significant traction in the device fingerprinting space - it's a costly (in terms of CPU) technique likely to be fragile (and defeated by newer DRAM designs) with the downside of the potential for physical damage to the end users device. That said, device fingerprinting is its own arms race between fingerprint techniques and privacy focussed browsers, and I expect that browsers are a more rapidly evolving target than the DRAM installed in computers, so perhaps I'm wrong about traction here..

You can read more about Centauri either in the original paper[4] or in the Register article[5] from last week.