Last week’s cyberintrusion at Australian telco Optus, which has about 10 million customers, has drawn the ire of the country’s government over how the breached company should deal with stolen ID details.
Darkweb screenshots surfaced quickly after the attack, with an underground BreachForums user going by the plain-speaking name of optusdata offering two tranches of data, alleging that they had two databases as follows:
11,200,000 user records with name, date of birth, mobile nmber and ID 4,232,652 records included some sort of ID document number 3,664,598 of the IDs were from driving licences 10,000,000 address records with email, date of birth, ID and more 3,817,197 had ID document numbers 3,238,014 of the IDs were from driving licences
The seller wrote, “Optus if you are reading! Price for us to not sale [sic] data is 1,000,000$US! We give you 1 week to decide.”
Regular buyers, the seller said, could have the databases for $300,000 as a job lot, if Optus didn’t take up its $1m “exclusive access” offer within the week.
The seller said they expected payment in the form of Monero, a popular cryptocurrency that’s harder to trace than Bitcoin.
Monero transactions are mixed together as part of the payment protocol, making the Monero ecosystem into a sort-of cryptocoin tumbler or anonymiser in its own right.
What happened?
The data breach itself was apparently down to missing security on what’s known in the jargon as an API endpoint. (API is short for application programming interface, a predefined way for one part of an app, or collection of apps, to request some sort of service, or to retrieve data, from another.)
On the web, API endpoints normally take the form of special URLs that trigger specific behaviour, or return requested data, instead of simply serving up a web page.
For example, a URL like https://www.example.com/about might simply feed back a static web page in HTML form, such as:
<HTML>
<BODY>
<H2>About this site</H2>
<P>This site is just an example, as the URL implies.
</BODY>
</HTML>
Visiting the URL with a browser would therefore result in a web page that looks as you would expect:
But a URL such as https://api.example.com/userdata?id=23de6731e9a7 might return a database record specific to the specified user, as though you had done a function call in a C program along the lines of:
/* Typedefs and prototypes */ typedef struct USERDATA UDAT; UDAT* alloc_new_userdata(void); int get_userdata(UDAT* buff, const char* uid); /* Get a record */ UDAT* datarec = alloc_new_userdata(); int err = get_userdata(datarec,"23de6731e9a7");
Assuming the requested user ID existed in the database, calling the equivalent function via an HTTP request to the endpoint might produce a reply in JSON format, like this:
{
"userid" : "23de6731e9a7",
"nickname" : "duck",
"fullname" : "Paul Ducklin",
"IDnum" : "42-4242424242"
}
In an API of this sort, you’d probably expect several cybersecurity precautions to be in place, such as:
- Authentication. Each web request might need to include an HTTP header specifying a random (unguessable) session cookie issued to a user who had recently proved their identity, for example with a username, password and 2FA code. This sort of session cookie, typically valid for a limited time only, acts as a temporary access pass for lookup requests subsequently performed by the pre-authenticated user. API requests from unauthenticated or unknown users can therefore instantly be rejected.
- Access restrictions. For database lookups that might retrieve personally identifiable data (PII) such as ID numbers, home addresses or payment card details, the server accepting API endpoint requests might impose network-level protection to filter out requests coming directly from the internet. An attacker would therefore need to compromise an internal server first, and wouldn’t be able to probe for data directly over the internet.
- Hard-to-guess database identifiers. Although security through obscurity (also known as “they’ll never guess that”) is a poor underlying basis for cybersecurity, there’s no point in making things easier than you have to for the crooks. If your own userid is
00000145, and you know that a friend who signed up just after you got00000148, then it’s a good guess that valid userid values start at00000001and go up from there. Randomly-generated values make it harder for attackers who have already found a loophole in your access control to run a loop that tries over and over to retrieve likely userids. - Rate limiting. Any repetitive sequence of similar requests can be used a a potential IoC, or indicator of compromise. Cybercriminals who want to download 11,000,000 database items generally don’t use a single computer with a single IP number to do the entire job, so bulk download attacks aren’t always immediately obvious just from traditional network flows. But they will often generate patterns and rates of activity that simply don’t match what you’d expect to see in real life.
Apparently, few or none of these protections were in place during the Optus attack, notably including the first one…
…meaning that the attacker was able to access PII without ever needing to identify themselves at all, let alone to steal a legitimate user’s login code or authentication cookie to get in.
Somehow, it seems, an API endpoint with access to sensitive data was opened up to the internet at large, where it was discovered by a cybercriminal and abused to extract information that should have been behind some sort of cybersecurity portcullis.
Also, if the attacker’s claim to have retrieved a total of more than 20,000,000 database records from two databases is to be believed, we’re assuming [a] that Optus userid codes were easily computed or guessed, and [b] that no “database access has hit unusual levels” warnings went off.
Unfortunately, Optus hasn’t been terribly clear about how the attack unfolded, saying merely:
Q. How did this happen?
A. Optus was the victim of a cyberattack. […]
Q. Has the attack been stopped?
A. Yes. Upon discovering this, Optus immediately shut down the attack.
In other words, it looks as though “shutting down the attack” involved closing the loophole against further intrusion (e.g. by blocking access to the unauthenticated API endpoint) rather than intercepting the initial attack early on after only a limited number of records had been stolen.
We suspect that if Optus had detected the attack while it was still under way, the company would have stated in its FAQ just how far the crooks had got before their access was shut down.
What next?
What about customers whose passport or driving licence numbers were exposed?
Just how much of a risk does leaking an ID document number, rather than more complete details of the document itself (such as a high-resolution scan or certified copy), pose to the victim of a data breach like this?
How much identification value should we give to ID numbers alone, given how widely and frequently we share them these days?
According to the Australian government, the risk is significant enough that victims of the breach are being advised to replace affected documents.
And with possibly millions of affected users, the document renewal charges alone could run to hundreds of millions of dollars, and necessitate the cancellation and reissuing of a significant proportion of the country’s driving licences.
We estimate than about 16 million Aussies have licences, and are inclined to use them as ID inside Australia instead of carrying round their passports. So, if the optusdata BreachForum poster was telling the truth, and close to 4 million licence numbers were stolen, close to 25% of all Australian licences might need replacing. We don’t know how useful this might actually be in the case of Australian driving licences, which are issued by individual states and territories. In the UK, for instance, your driving licence number is quite obviously derived algorithmically from your name and date of birth, with a very modest amount of shuffling and just a few random characters inserted. A new licence therefore gets a new number that is very similar to the previous one.
Those without licences, or visitors who had bought SIM cards from Optus on the basis of a foreign passport, would need to replace their passports instead – an Australia passport replacement costs close to AU$193, a UK passport is £75 to £85, and a US renewal is $130 to $160.
(There’s also the question of waiting times: Australia currently advises that replacement passport will take at least 6 weeks [2022-09-28T13:50Z], and that’s without a sudden surge caused by breach-related processing; in the UK, due to existing backlogs, His Majesty’s Government is presently telling applicants to allow 10 weeks for passport renewal.)
Who carries the cost?
Of course, if replacing all potentially compromised IDs is deemed necessary, the burning question is, “Who will pay?”
According to the Australian Prime Minister, Anthony Albanese, there’s no doubt where the money to replace passports should come from:
This afternoon @albomp gave the parliament an important update on the Optus security breach.
Not only are we demanding Optus pay for replacement passports for those affected by the breach, but we’re also committed to strengthening our privacy laws through the Privacy Act review. pic.twitter.com/JyoRJxyM3p
— Clare O’Neil MP (@ClareONeilMP) September 28, 2022
There’s no word from the federal legislature on on replacing driving licences, that being a matter handled by State and Territory governments…
…and no word on whether “replace all documents” will become a routine reaction whenever a breach involving ID document is reported, something that could easily swamp the public service, given that licences and passports are usually expected to last 10 years each.
Watch this space – this looks set to get interesting!