While the rest of us were loafing at the beach, the Penguinistas from Down Under were owning up to a pretty extensive cyberintrusion.
The team has published a decent document setting out what happened, and it went something like this:
- Crooks broke into the organisation’s Conference Management server.
- Crooks got root on the server.
- Crooks installed a remote access Trojan (RAT) for later.
- Crooks rebooted the server and activated the RAT.
- Crooks “logged in” again and installed zombie malware, also known as a bot.
- While the crooks had access, a conference database backup took place to the server.
Ironically, the backup that was intended to deliver one leg of the “security trinity” (availability) ended up hurting one of the other legs (confidentiality).
That’s because the database dump as good as dropped a bucket-load of Personally Identifiable Information (PII) in the crooks’ laps:
The database dumps which occurred during the breach include information provided during conference registration - First and Last Names, physical and email addresses, and any phone contact details provided, as well as a hashed version of the user password.
Fortunately, payment card data is passed to a third party site for processing, and never stored by Linux Australia, so there were no credit cards numbers or other data of that sort in the information exposed to the crooks.
Missing from Linux Australia’s otherwise commendably frank breach write-up is:
- Information about how the hashed passwords were stored. (This is useful to know, albeit not vital, because it gives a hint as to how successful an offline dictionary attack is likely to be.)
- Information about the security hole or holes that let the crooks in. (The document rather conveniently calls it “a currently unknown vulnerability,” though clearly it was known to the attackers.)
- Information about the RAT and zombie malware that was subsequently installed. (This is handy to know, but again not vital, because RATs and zombies are designed to allow attacks to develop as the crooks see fit, instead of following a predictable pattern.)
Usefully, the Linux Australia crew did publish a list entitled, “What steps were taken to prevent the threat of a similar breach in the future?”
We suggest you take a look at this list.
Even though some of the steps sound rather obvious, most security precautions seem that way in hindsight.
The thing is, even though the steps proposed by Linux Australia aren’t hard to do, they are very easy not to do.
Don’t use the “life’s too short” excuse: these guys are Linux gurus, and they got caught out.
In particular, take notice of this precaution:
The new host will have a far more rigorous operating system updating schedule applied to it.
Even if the exploit used by the crooks in this case really was a zero-day (an attack known only to the crooks, and for which no patch was available), that’s no excuse for being tardy with patches.
Firstly, most attacks don’t use zero-days to get in.
Secondly, even when crooks use a zero-day to get in, they often rely on additional, already-known, security holes to complete their attack.
Patch early, patch often!