
The Red Cross Blood Service: Australia's largest ever leak of personal data - bootload
https://www.troyhunt.com/the-red-cross-blood-service-australias-largest-ever-leak-of-personal-data/
======
siddboots
I worked in data and business analysis for the Australian Red Cross Blood
Service for several years, and I know the tables mentioned in the article
well. I have spend many hours of my life worrying over the potential risk of a
data leak, especially for medical questionnaire and medical test data. Not
mentioned in the article are blood test results for HEPB, HEPC, syphilis, and
so on, but I presume they were also in the leak. (EDIT: on learning more about
the nature of the leak, this data probably was not in it)

An outsider might suspect that this occurred because ARCBS is the sort of
organisation that simply doesn't have the speciality/budget/staff required to
manage data security properly, but this isn't the case by any means. My
retrospective impression is that they had capable teams covering data
warehousing, data security policies, network security, etc. All of my
experience in the field tells me that they were better protected than the vast
majority of organisations of their size.

This event has solidified some of my more apocalyptic thoughts w.r.t. info-
sec. Namely, that a guarantee of secure data is essentially out of reach for
almost any organisation of any size. Partly this is due to increased
connectivity of networks, but equally it is due to better tooling and
analytics staff making thorough organisation of customer data the norm.

The cause of this problem is the hoarding of knowledge, as Zhuang Zhou
realised two and a half thousand years ago:

> In taking precautions against thieves who cut open satchels, search bags,
> and break open boxes, people are sure to cord and fasten them well, and to
> employ strong bonds and clasps; and in this they are ordinarily said to show
> their wisdom. When a great thief comes, however, he shoulders the box, lifts
> up the satchel, carries off the bag, and runs away with them, afraid only
> that the cords, bonds, and clasps may not be secure; and in this case what
> was called the wisdom (of the owners) proves to be nothing but a collecting
> of the things for the great thief.

~~~
x1798DE
This is exactly why large stores of data should be considered a liability and
NOT an asset. Keep as little of it as possible and for the least amount of
time possible.

I'm actually a bit confused about why they would need to store the medical
test data and medical questionnaire information at all - can't you boil those
down to "suitable" and "not suitable"?

~~~
imglorp
One would imagine a case where some blood product recipients got sick after a
transfusion, and the data would be helpful to narrow down the cause relative
to donor histories.

I bet you could encrypt all the histories with a public key however, and only
decrypt in such cases: private key held in a safe in the director's office,
etc.

------
red_admiral
One point I take away is that there's something even better than "responsible
disclosure": talk to your local CERT instead of the company affected, unless
you trust the company will handle it professionally.

~~~
josephb
It seems plausible that big organisations might take the contact from an
individual as "I haz ur data, omg Haxor!", then call the police.

Whereas the approach from a local CERT agency is likely to be taken more
seriously, acted on more speedily, and possibly result in less blowback on the
individual who came across the information and reported it.

------
gargravarr
"That 1.74GB was simply a mysqldump file that had everything in it... The
database backup was published to a publicly facing website."

This cements my opinion that we need sysadmin licenses.

As a sysadmin myself, when I read that in the article, I physically cringed.
No wonder you can't trust anyone with your private data these days!!

~~~
jacquesm
It's bad, but I've seen worse. _Much_ worse.

~~~
daddykotex
I'd be curious to hear some anecdotal stories like this, would you share :)

~~~
pavel_lishin
I'm not jacquesm, but one I always like to share is a client who would store
credit card data - numbers, addresses, expiration dates, and cvvs ( _yes_ ) -
in plain text in a database, in plain violation of PCI compliance and common
sense.

We kept telling them that this was a bad idea, that it wasn't compliant, that
it was dangerous, that they could lose their ability to process credit cards
at all _at best_ , and lose their entire database of customer credit card
numbers _at worst_.

But there was no money in the budget for this kind of refactoring.

Until the data was exfiltrated via a trojan.

Suddenly, there was money in the budget.

~~~
gargravarr
>Suddenly, there was money in the budget.

Was this before or after the lawsuit? Assuming there was one (which there
really needs to be...)

------
robbiep
I got a text message from the RCBS notifying me of the breach as I was reading
the article describing it (already knowing that I was likely someone affected
as a person who has regularly donated and participated in university challenge
drives) followed by an email. Felt their disclosure and follow up has been
appropriate although obviously disappointing they so sloppily allowed data to
be left around on servers.

Was interested to read that there is a security body Australian Cyber
Emergency Response Team (AusCERT) to deal with this stuff

\- this is the link the text message sent me to:
[http://info.donateblood.com.au/](http://info.donateblood.com.au/)

------
ponco
It's worth reading the entire article and comments - very interesting. I
particularly like the bit at the end discussing the ethics of the recovery - I
can't decide if it is ethical or not...many sides to the issue.

------
mkj
The official statement
[http://info.donateblood.com.au](http://info.donateblood.com.au) downplays
what was disclosed. "Included in the file was information such as names,
addresses and dates of birth."

That's kind of different to the confidential questionnaire answers.

Seems a bit incompetent why any of it is near a webserver - they don't have an
"online profile login" or anything like that.

~~~
siddboots
You can book appointments to donate blood on the public web site. The
questionnaire is part of that process.

~~~
mkj
Ah right. That makes a bit more sense, I thought Troy meant the paper answers
ended up on the webserver.

I guess I was thinking the online presence was more like a "contact us" email
form that emails it somewhere internal, not stored on the server.

------
daddykotex
+1 to Troy, this blog is amazing. The blog posts are always on point
technically and ethically.

------
arthursilva
Why hack a blood service system at first place? Oh my. Not that people should
hack anything, but this is extra nasty.

~~~
red_admiral
They didn't. They scanned the IPv4 address space for servers with directory
listing enabled and ".sql" files visible, and happened to find one at
Australia's red cross.

~~~
oarsinsync
And if you're less technically inclined, you can bypass the whole manual
scanning of address space, and just look at what Google's already indexed
publicly for you:

[https://www.google.co.uk/?q=%22index+of%22+.sql](https://www.google.co.uk/?q=%22index+of%22+.sql)

~~~
jacquesm
7000 entries :(

