QANTAS Cyber Incident

[DejaBrew]

Interviewed by the AFR, she said…

That sounds more accurate and quite reasonable.

 

[TheRealTMA]

That sounds more accurate and quite reasonable.

In the scheme of things, he’s been in that position for quite a long time until now.

 

[RB001]

Other account in the household (Lifetime Bronze), didn't get either of the initial two emails, but today received:
...

​

What specific data of yours was accessed?

Our cyber security teams have undertaken an investigation and we can confirm that the following types of your data held on the compromised system was accessed:

Name

Qantas Frequent Flyer number

Tier

...

I don't believe they've ever called QF, their only activity is earning primarily through EDR, and spending on CR flights and Qantas Hotels.

 

[nancypants]

Nothing for me yet. Was one of the first for the first emails, maybe I will be one of the last for this set

My surname begins with an N if they’re doing them alphabetically

 

[serfty]

Nothing for me yet. Was one of the first for the first emails, maybe I will be one of the last for this set

My surname begins with an N if they’re doing them alphabetically

A ... here ... nothing further ...

 

[Flyfrequently]

Y - always almost last

 

[AuSammy]

Quite a large crop of spam emails today.

They mustn’t have access to the QF data yet as all of them started with “dear user” or “dear winner” and the same old carp about a message waiting in myG0v or a free medical kit waiting for me.

So dumb they don’t even realise my email is my name.

Still waiting for my QF email number 3.

 

[Pushka]

Still waiting for the very first email here.

Curious that 'only' 6 million data files were accessed. Why those 6 million? What made them vulnerable? Surely there is only one data base?

 

[henrus]

Curious that 'only' 6 million data files were accessed. Why those 6 million? What made them vulnerable? Surely there is only one data base?

For managing and logging enquiries they used a database from 3rd party provider called salesforce. It's unclear (and we'll probably never know for sure) which call centres use what however what we do know is that the Manila one uses salesforce (to log/manage tickets).

For those emailing, using the contact form, calling about a booking (and talking to Manila) or anything Qantas Frequent flyer department related this is all done via the Manila 3rd party team who in turn use this salesforce database.

You can google salesforce, they aren't a small company and according to their website F1, Spotify, Telstra, AFL, TfNSW, Flight Centre are just a few of the companies that use salesforce. It's very likely the vulnerability wasn't one with the database (or anything salesforce platform related) but more someone with elevated permissions stuffing up (either on purpose knowing they can sell the data or by mistake like social engineering/sharing passwords etc).

 

[Seat0B]

The Age is reporting that some CL members are included in the breach…

Ooh not happy Jan won’t even come close to describing their state of mind.

 

[RSD]

I've heard nothing yet but did receive the first email. So far no extra emails etc, and about the normal amount of silly calls from India trying to sell me solar coldwater replacements funded by the Victorian government - even though I live in Tassie. I usually start asking those callers did they fail their Australian truck driver licence and get sent back to India?

 

[RooFlyer]

Curious that 'only' 6 million data files were accessed. Why those 6 million? What made them vulnerable? Surely there is only one data base?

I've been assuming that that was the extent of the area of data that the call centre operative allowed access to.

For managing and logging enquiries they used a database from 3rd party provider called salesforce. It's unclear (and we'll probably never know for sure) which call centres use what however what we do know is that the Manila one uses salesforce (to log/manage tickets).

But thinking further (yes, dangerous I know), the subject of "offshore" databases, why would Manila need its own local database? Would not each agent 'log in' to the system in play and that data needn't be on a server a few km away?

Oh. Is it cheaper to store the data in the Philippines even if it means duplicating customer records ? Would Cape Town have its own local database, with some of my records on it if I've been shunted to them? Auckland? Hobart?

 

[Seat0B]

Received Emails 1&2 but not yet Email 3 with details of which of my info has been stolen.

 

[ellen10]

Received Emails 1&2 but not yet Email 3 with details of which of my info has been stolen.

Same for me too. No 3rd email yet

 

[AuSammy]

Curious that 'only' 6 million data files were accessed.

With zero knowledge of their architecture or the alleged front end salesforce, why shouldn't I join others and posit my own wild guess that the incursion was detected before the hackers had time to capture the masses of data held there.

It would possibly take time to understand the data tree and construct & run reports to crawl through millions of records.

Quite possibly the data captured was totally unrelated to who has used Manilla call centre and merely related to the time they had available to capture.

 

[sudoer]

my own wild guess that the incursion was detected

or their session timed out, which cut the attacker off before they could exfiltrate the entire QFF database.

Based on the data points posted so far, and the fact I got emails 1 & 2 on my work address which has no QFF account attached and is only used as the contact address on PNRs created by my corporate TA, I suspect the Manila call centre (or at least who has/hasn't called them) will be irrelevant

 

[henrus]

But thinking further (yes, dangerous I know), the subject of "offshore" databases, why would Manila need its own local database? Would not each agent 'log in' to the system in play and that data needn't be on a server a few km away?

For this very reason it's occurred in the first place. This has been reported (by AFF and others) as not someone "hacking" into the database but rather a leak through someone using valid credentials to access it. QF uses these 3rd party call centres (again contracted to but not part of QF group) and only provides them access to limited systems (or a whole seperate system altogether) required to do their jobs.

QF's salesforce deployment isn't limited to the Manila call centre but what appears to unique is the database they use which is separated from the rest of the QF platforms. In this case such setup has clearly saved a bit of QFs bacon as it's not the whole frequent flyer database but I guess in the long term it's valid to ask why they needed to keep such records for so long in that database (instead of removing them and pushing to a locked down version).

As for the server distance and physical database location, with undersea cables I can get a ~300ms (0.3 of a second) response time to a server in London (from Brisbane) so the physical location doesn't really matter and it's possible the database was located in Australia but just access abroad. About 2 years ago the QF group switched a lot of their services to Amazon's AWS which has data centres across the globe but in this case I'm not sure that even matters as it's could even be salesforce who controls and hosts this platform.

 

[AuSammy]

For this very reason it's occurred in the first place. This has been reported (by AFF and others) as not someone "hacking" into the database but rather a leak through someone using valid credentials to access it. QF uses these 3rd party call centres (again contracted to but not part of QF group) and only provides them access to limited systems (or a whole seperate system altogether) required to do their jobs.

QF's salesforce deployment isn't limited to the Manila call centre but what appears to unique is the database they use which is separated from the rest of the QF platforms. In this case such setup has clearly saved a bit of QFs bacon as it's not the whole frequent flyer database but I guess in the long term it's valid to ask why they needed to keep such records for so long in that database (instead of removing them and pushing to a locked down version).

As for the server distance and physical database location, with undersea cables I can get a ~300ms (0.3 of a second) response time to a server in London (from Brisbane) so the physical location doesn't really matter and it's possible the database was located in Australia but just access abroad. About 2 years ago the QF group switched a lot of their services to Amazon's AWS which has data centres across the globe but in this case I'm not sure that even matters as it's could even be salesforce who controls and hosts this platform.

Based on info in public domain (ie an operative was tricked into handing over some credentials) the location of the data base and whether it was outsourced or not seems largely irrelevant in the scheme of things. In addition QF seems to have had an early tipoff something might happen and had already sent out warnings to staff days before.

The attacker could have been extraordinarily convincing or merely known the right buzzwords knowing the application involved.

The operative might have been on leave and just returned or not been on the email trail of warnings or preoccupied and stuffed up. Humans make mistakes.

A myriad of scenarios, the finer details of which we will never know and it would be smart of QF not to reveal.

The least revealed about any organisations security arrangements in the public domain the better - makes the job harder for attackers.