
Accenture left a huge trove of highly sensitive data on exposed servers - nunb
http://www.zdnet.com/article/accenture-left-a-huge-trove-of-client-passwords-on-exposed-servers/
======
abraae
> 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.

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

~~~
scurvy
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.

~~~
mrSugar
No. If it is public, everyone is authorized.

~~~
scurvy
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.

------
thisisit
>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.

------
jlgaddis
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.

~~~
smt88
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.

~~~
tomstockmail
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.

------
smt88
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.

~~~
nl
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._

~~~
smt88
> _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.

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

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

------
KGIII
> ...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.

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

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

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

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

How does he do it?

~~~
skywhopper
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.

~~~
numbsafari
... 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?

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

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

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

[https://en.m.wikipedia.org/wiki/Accenture](https://en.m.wikipedia.org/wiki/Accenture)

------
commenter1
Paint me surprised, not.

