By all accounts, and sadly there are many of them, a hacker – in the break-and-enter-your-network-illegally sense, not in a solve-super-hard-coding-problems-in-a-funky-way sense – has broken into ride-sharing company Uber.
According to a report from the BBC, the hacker is said to be just 18 years old, and seems to have pulled off the attack for the same sort of reason that famously drove British mountain climber George Mallory to keep trying (and ultimately dying in the attempt) to summit Mount Everest in the 1920s…
…“because it’s there.”
Uber, understandably, hasn’t said much more so far [2022-09-16T15:45Z] than to announce on Twitter:
We are currently responding to a cybersecurity incident. We are in touch with law enforcement and will post additional updates here as they become available.
— Uber Comms (@Uber_Comms) September 16, 2022
How much do we know so far?
If the scale of the intrusion is as broad as the alleged hacker has suggested, based on the screenshots we’ve seen plastered on Twitter, we’re not surprised that Uber hasn’t offered any specific information yet, especially given that law enforcement is involved in the investigation.
When it comes to cyberincident forensics, the devil really is in the details.
Nevertheless, publicly available data, allegedly released by the hacker himself and distributed widely, seems to suggest that this hack had two underlying causes, which we’ll describe with a medieval analogy.
- Tricked an insider into letting them into the courtyard, or bailey. That’s the area inside the outermost castle wall, but separate from the best-defended part.
- Found unattended details explaining how to access the keep, or motte. As the name suggests, the keep is the central defensive stronghold of a traditional medieval European castle.
The initial breakin
The jargon term for blagging your way into the 21st century equivalent of the castle courtyard is social engineering.
As we all know, there are many ways that attackers with time, patience and the gift of the gab can persuade even a well-informed and well-meaning user to help them bypass the security processes that are supposed to keep them out.
Automated or semi-automated social engineering tricks include email and IM-based phishing scams.
These scams lure users into entering their login details, often including their 2FA codes, on counterfeit web sites that look like the real deal but actually deliver the needed access codes to the attackers.
For a user who is already logged in, and is thus temporarily authenticated for their current session, attackers may attempt to get at so-called cookies or access tokens on the user’s computer.
By implanting malware that hijacks existing sessions, for example, attackers may be able to masquerade as a legitimate user for long enough to take over completely, without needing any of the usual credentials that the user themselves required to login from scratch:
And if all else fails – or perhaps even instead of trying the mechanical methods described above – the attackers can simply call up a user and charm them, or wheedle, or beg, or bribe, or cajole, or threaten them instead, depending on how the conversation unfolds.
Skilled social engineers are often able to convince well-meaning users not only to open the door in the first place, but also to hold it open to make it even easier for the attackers to get in, and perhaps even to carry the attacker’s bags and show them where to go next.
That’s how the infamous Twitter hack of 2020 was carried out, where 45 blue-flag Twitter accounts, including those of Bill Gates, Elon Musk and Apple, were taken over and used to promote a cryptocurrency scam.
That hacking wasn’t so much technical as cultural, carried out via support staff who tried so hard to do the right thing that they ended up doing exactly the opposite:
The jargon term for the equivalent of getting into the castle’s keep from the courtyard is elevation of privilege.
Typically, attackers will deliberately look for and use known security vulnerabilities internally, even though they couldn’t find a way to exploit them from the outside because the defenders had taken the trouble to protect against them at the network perimeter.
For example, in a survey we published recently of intrusions that the Sophos Rapid Response team investigated in 2021, we found that in only 15% of initial intrusions – where the attackers get over the external wall and into the bailey – were the criminals able to break in using RDP.
(RDP is short for remote desktop protocol, and it’s a widely used Windows component that’s designed to let user X work remotely on computer Y, where Y is often a server that doesn’t have a screen and keyboard of its own, and may indeed be three floors underground in a server room, or across the world in a cloud data centre.)
But in 80% of attacks, the criminals used RDP once they were inside to wander almost at will throughout the network:
Just as worryingly, when ransomware wasn’t involved (because a ransomware attack makes it instantly obvious you’ve been breached!), the median average time that the criminals were roaming the network unnoticed was 34 days – more than a calendar month:
The Uber incident
We’re not yet certain how the initial social engineering (shortened to SE in hacking jargon) was carried out, but threat researcher Bill Demirkapi has tweeted a screenshot that seems to reveal (with precise details redacted) how the elevation of privilege was achieved.
Apparently, even though the hacker started off as a regular user, and therefore had access only to some parts of the network…
…a bit of wandering-and-snooping on unprotected shares on the network revealed an open network directory that included a bunch of PowerShell scripts…
…that included hard-coded security credentials for admin access to a product known in the jargon as a PAM, short for Privileged Access Manager.
As the name suggests, a PAM is a system used to manage credentials for, and control access to, all (or at least a lot of) the other products and services used by an organisation.
Wryly put, the attacker, who probably started out with a humble and perhaps very limited user account, stumbled on an ueber-ueber-password that unlocked many of the ueber-passwords of Uber’s global IT operations.
We’re not sure just how broadly the hacker was able to roam once they’d prised open the PAM database, but Twitter postings from numerous sources suggest that the attacker was able to penetrate much of Uber’s IT infrastructure.
The hacker allegedly dumped data to show that they’d accessed at least the following business systems: Slack workspaces; Uber’s threat protection software (what is often still casually referred to as an anti-virus); an AWS console; company travel and expense information (including employee names); a vSphere virtual server console; a listing of Google Workspaces; and even Uber’s own bug bounty service.
(Apparently, and ironically, the bug bounty service was where the hacker bragged loudly in capital letters, as shown in the headline, that UBER HAS BEEN HACKED.)
What to do?
It’s easy to point fingers at Uber in this case and imply that this breach should be considered much worse than most, simply because of the loud and very public nature of it all.
But the unfortunate truth is that many, if not most, contemporary cyberattacks turn out to have involved the attackers getting exactly this degree of access…
…or at least potentially having this level of access, even if they didn’t ultimately poke around everywhere that they could have.
After all, many ransomware attacks these days represent not the beginning but the end of an intrusion that probably lasted days or weeks, and may have lasted for months, during which time the attackers probably managed to promote themselves to have equal status with the most senior sysadmin in the company they’d breached.
That’s why ransomware attacks are often so devastating – because, by the time the attack comes, there are few laptops, servers or services the criminals haven’t wrangled access to, so they’re almost literally able to scramble everything.
In other words, what seems to have happened to Uber in this case is not a new or unique data breach story.
So here are some thought-provoking tips that you can use as a starting point to improve overall security on your own network:
- Password managers and 2FA are not a panacea. Using well-chosen passwords stops crooks guessing their way in, and 2FA security based on one-time codes or hardware access tokens (usually small USB or NFC dongles that a user needs to carry with them) make things harder, often much harder, for attackers. But against today’s so-called human-led attacks, where “active adversaries” involve themselves personally and directly in the intrusion, you need to help your users change their general online behaviour, so they are less likely to be talked into sidestepping procedures, regardless of how comprehensive and complex those procedures might be.
- Security belongs everywhere in the network, not just at the edge. These days, very many users need access to at least some part of your network – employees, contractors, temporary staff, security guards, suppliers, partners, cleaners, customers and more. If a security setting is worth tightening up at what feels like your network perimeter, then it almost certainly needs tightening up “inside” as well. This applies especially to patching. As we like to say on Naked Security, “Patch early, patch often, patch everywhere.”
- Measure and test your cybersecurity on a regular basis. Never assume that the precautions you thought you put in place really are working. Don’t assume; always verify. Also, remember that because new cyberattack tools, techniques and procedures show up all the time, your precautions need reviewing regularly. In simple words, “Cybersecurity is a journey, not a destination.”
- Consider getting expert help. Signing up for a Managed Detection and Response (MDR) service is not an admission of failure, or a sign that you don’t understand cybersecurity yourself. MDR is not an abrogation of your reponsibility – it’s simply a way to have dedicated experts on hand when you really need them. MDR also means that in the event of an attack, your own staff don’t have to drop everything they are currently doing (including regular tasks that are vital to the continuity of your business), and thus potentially leave other security holes open.
- Adopt a zero-trust approach. Zero-trust doesn’t literally mean that you never trust anyone to do anything. It’s a metaphor for “make no assumptions” and “never authorise anyone to do more than they strictly need”. Zero-trust network access (ZTNA) products don’t work like traditional network security tools such as VPNs. A VPN generally provides a secure way for someone outside to get general admission to network, after which they often enjoy much more freedom than they really need, allowing them to roam, snoop and poke around looking for the keys to the rest of the castle. Zero-trust access takes a much more granular approach, so that if all you really need to do is browse the latest internal price list, that’s the access you’ll get. You won’t also get the right to wander into support forums, trawl through sales records, or poke your nose into the source code database.
- Set up a cybersecurity hotline for staff if you don’t have one already. Make it easy for anyone to report cybersecurity issues. Whether it’s a suspicious phone call, an unlikely email attachment, or even just a file that probably shouldn’t be out there on the network, have a single point of contact (e.g.
email@example.com) that makes it quick and easy for your colleagues to call it in.
- Never give up on people. Technology alone cannot solve all your cybersecurity problems. If you treat your staff with respect, and if you adopt the cybersecurity attitude that “there is no such thing as a silly question, only a stupid answer”, then you can turn everyone in the organisation into eyes and ears for your security team.
Why not join us from 26-29 September 2022 for this year’s Sophos Security SOS Week:
Four short but fascinating talks with world experts.
Learn about protection, detection and reponse,
and how to set up a successful SecOps team of your own: