Hacker News new | comments | show | ask | jobs | submit login
Accenture left a huge trove of highly sensitive data on exposed servers (zdnet.com)
194 points by nunb 9 months ago | hide | past | web | favorite | 33 comments

> No actual breach seems to of occurred: We asked if anyone else had accessed the servers, the spokesperson said its logs showed access "by only a single non-authorized IP address which we traced back to a data security consultant who contacted us about about two weeks ago," referring to Vickery.

Suspicious wording, if indeed "The four servers were quietly secured the next day.". Normally the PR response would have emphasised that e.g. "we took action immeiately and resolved the problem within 24 hours".

And as for "non-authorized IP address" - really? Is IP address whitelisting used to secure this stuff? And if so, then how on earth did an unauthorized IP address get through?

And then "the company downplayed the exposure, saying the data was less than half a percent of its cloud service" - but according to TFA that 0.5% included the master keys!?!

At the least, their public responses are feeble and imprecise.

Which leads to the suspicion that something darker happened.

AFAIK, if the S3 bucket is public, anyone can access it. All IP addresses are authorized.

Access and authorization are separate concepts. You can't trespass on someone's property just because there is no gate.

This is why companies put authorized use only login banners on servers and network gear.

No. If it is public, everyone is authorized.

Sorry, not the case at all. If you start poking around on a server that the DoD forgets to lock down, you're going to jail. You're not authorized to use it just because you can access it.

>As we continue our forensic review we may learn more but, the email and password information in the database is more than two and a half years old and for Accenture users of a decommissioned system," the spokesperson said.

I don't know if they understand that password re-use is a thing. So it doesn't matter if the passwords are too old or not.

Still the response is nothing but a long line of excuses: the data was not client related, no PII data was leaked, passwords are old etc.

Boy, it sure does sound like Accenture wants to keep this one quiet.

I think I'll take a break from HN to send an e-mail to some friends whose employers are Accenture customers and see if they've heard from 'em about this.

I asked a friend whether it was a story that was blowing up in Accenture. They haven't heard a word about it. It seems like Accenture is trying to bury it and do nothing about it.

I used to work in Deloitte's Federal cybersecurity practice. Nobody I sent articles to had heard of the recent email server breaches before I told them, and they are still waiting for leadership to make a practice wide statement. Then it came out that some of the emails were from clients and teams I worked with. Still nada.

It's making its rounds. Accenture is incredibly unorganized though, for example I have no idea which teams use this AWS service. I didn't even know Accenture had AWS services as they tend to push Azure more. My own project uses it's own datacenter which is the case for most clients - Accenture wants to leave them least responsible in these kinds of events.

This is potentially much worse than Equifax. I'm not sure why it's not being covered more heavily.

There are many major companies in Accenture's client portfolio that this would expose, including health-care companies.

It's not covered more heavily for 2 reasons:

1) The story only just broke.

2) No actual breach seems to of occurred: We asked if anyone else had accessed the servers, the spokesperson said its logs showed access "by only a single non-authorized IP address which we traced back to a data security consultant who contacted us about about two weeks ago," referring to Vickery.

> No actual breach seems to of occurred

I might be wrong about this, but my understanding is that a decent black-hat hacker wouldn't have left many (if any) breadcrumbs because he had "the keys to the kingdom". It would be easy to erase change logs on the way out.

The logs in question would be AWS's S3 access logs. Having Accenture's credentials wouldn't let you delete those.

Unless the bucket contained these as well? (ok, that was arguing for the sake of argument... :)

Seems like they got lucky then. Their statement also claims that no sensitive client data was accessible. Bad sign for clients: I'd be banging on the door asking what their mitigation will be for the future.

> I'm not sure why it's not being covered more heavily

I might be cynical but Accenture is a big advertiser and main stream news sites generally don't want to piss off their source of income.

Mainstream news sites are supposed to have a firewall between advertisers and editorial. This has eroded in some places, but NYT, WaPo, and other respected sites would still have them.

Also, there are so many sites now that Accenture couldn't be advertising on all of them, at least not significantly.

> ...passwords -- some of which were stored in plaintext.

Maybe don't do that?

Also, the greater-than sign in their logo is amusing. I amused myself by looking at the picture while mentally inserting nouns. eg dog poop > Accenture

I am easily amused.

It's an "accen"t pointing to the fu"ture".

source: unfortunately I used to work there when they came up with the name.

The discoverer's article is quite informative: https://www.upguard.com/breaches/cloud-leak-accenture

Chris Vickery (who discovered this problem) has quite a record of discovering unsecured S3 buckets.

How does he do it?

S3 buckets have a single unified namespace, so presumably he's got bots running 24/7 scanning every legal bucket name. Filter it down using english words, likely ops jargon, and company names. I'm guessing Accenture has lots of buckets named "accenture-prod-uploads" or other promising combinations.

... and this is why I generally prefix all bucket names with a UUID. Mildly user hostile, but bucket names go in config files, so who cares?

Yup, they must have (except for one region in AWS), a DNS compliant and completely unique name. So it’s just a case of dns bruteforce, working through wordlists and common phrases/words to try and spot them. I ran something very similar for a couple of months, and found >200,000 valid S3 buckets, a large portion of which had permissions issues (public list etc).

And if he's doing it, others are too. There's a very high likelihood that all this data has been compromised.

I wrote a web-scraping script to iterate through buckets and download items, to see which of my employer's S3 buckets were unsecured. Chris probably did the same thing, but is spidering the whole namespace instead of just targeting a known list.

S3 has a hostile interface which is missing many necessary features. AWS try to supplement this through 3rd party products (Cloudberry) and other paid services (Macie), instead of making a client that helps you know what's in your buckets and who can see them.

If I recall correctly, you can't specify on a bucket that you want a group to access it. You have to specify on the group that it has access to the bucket. There's tons of stupid shit like that.

Just an hour ago I was on a call, helping someone else find a file she had just uploaded, but wasn't visible in the S3 Web Console. Because it doesn't bring back ALL files in the folder, just the current 300. And they aren't sorted, so the file she had just uploaded was 2 pages back from a lot of other files which were uploaded today. It's nonsensical.

Generally companies apply the excuse of a "sophisticated attack". This time it seems they aren't able call it that way.

The mix of cloud creds plus TLS certs makes me think this was something like Terraform remote state stored on S3.

Something feels fitting that Accenture is a spin-off of Arthur Andersen


Paint me surprised, not.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact