The UpGuard Cyber Risk Team can now reveal that Accenture, one of the world’s largest corporate consulting and management firms, left at least four cloud storage buckets unsecured and publicly downloadable, exposing secret API data, authentication credentials, certificates, decryption keys, customer information, and more data that could have been used to attack both Accenture and its clients. The buckets' contents appear to be the software for the corporation’s enterprise cloud offering, Accenture Cloud Platform, a “multi-cloud management platform” used by Accenture’s customers, which “include 94 of the Fortune Global 100 and more than three-quarters of the Fortune Global 500” - raising the possibility that, if valid, exposed Accenture data could have been used for critical secondary attacks against these clients. With a CSTAR cyber risk score of 790 out of a possible 950, this cloud leak shows that even the most advanced and secure enterprises can expose crucial data and risk serious consequences.
On September 17th, 2017, UpGuard Director of Cyber Risk Research Chris Vickery discovered four Amazon Web Services S3 storage buckets configured for public access, downloadable to anyone who entered the buckets’ web addresses into their internet browser. A cursory analysis on September 18th of the four buckets - titled with the AWS subdomains “acp-deployment,” “acpcollector,” “acp-software,” and “acp-ssl” - revealed significant internal Accenture data, including cloud platform credentials and configurations, prompted Vickery to notify the corporation; the four AWS buckets were secured the next day.
All four S3 buckets contain highly sensitive data about Accenture Cloud Platform, its inner workings, and Accenture clients using the platform. All were maintained by an account named “awsacp0175,” a possible indication of the buckets’ origin.
The bucket “acp-deployment” appears to be largely devoted to storing internal access keys and credentials for use by the Identity API, which is apparently used to authenticate credentials. A folder in the bucket titled “Secure Store” contains not only configuration files for the Identity API, but also a plaintext document containing the master access key for Accenture’s account with Amazon Web Service’s Key Management Service, exposing an unknown number of credentials to malicious use.
Also contained in the bucket is a number of “client.jks” files - stored in some cases alongside what is believed to be the plaintext password necessary to decrypt the file. It is unknown precisely what the keys in “clients.jks” could be used to access. Private signing keys were also exposed within these files - placing a critical tool in the hands of anyone who encountered them.
The bucket “acpcollector” appears to contain data necessary for visibility into and maintenance of Accenture’s cloud stores. The bucket contains VPN keys used in production for Accenture’s private network, potentially exposing a master view of Accenture’s cloud ecosystem. Also contained in the bucket are logs listing events occurring in each cloud instance, enabling malicious actors to gain far-reaching insight into Accenture’s operations.
At a size of 137 GB, the bucket “acp-software” is much larger, giving some indication of its contents: large database dumps that include credentials, some of which appear to be for some Accenture clients. While many of the passwords contained here are hashed - passwords mathematically transformed into an alphanumeric string - a collection of nearly 40,000 plaintext passwords is present in one of the database backups. Access keys for Enstratus, a cloud infrastructure management platform, are also exposed here, potentially leaking the data of other tools coordinated by Enstratus. Information about Accenture’s ASGARD database, as well as internal Accenture email info, are also contained here.
Also in this bucket are data dumps from the Zenoss event tracker used by Accenture, revealing such incidents as the adding of new users, recording of IP addresses, and JSession IDs which, if not expired, could be plugged into cookies to gain entry past authentication portals. An examination reveals a number of Accenture clients recorded in this manner.
Finally, credentials for what appear to be Accenture’s Google and Azure accounts are also present in this folder - another critical revelation which could be used to gain further access to and control of Accenture assets.
The final bucket “acp-ssl,” contains more key stores in a folder called “acp.aws.accenture.com.” The keys appear to provide access to various Accenture environments, such as one titled “Cloud File Store Key,” among a number of private keys, as well as certificates that, in theory, could be used to decrypt traffic between Accenture and clients, potentially gathering any sensitive information as it is sent across the wire.
Taken together, the significance of these exposed buckets is hard to overstate. In the hands of competent threat actors, these buckets, accessible to anyone stumbling across their URLs, could have exposed both Accenture and its thousands of top-flight corporate customers to malicious attacks that could have done an untold amount of financial damage.
It is possible a malicious actor could have used the exposed keys to impersonate Accenture, dwelling silently within the company’s IT environment to gather more information. The specter of password reuse attacks also looms large, across multiple platforms, websites, and potentially hundreds of clients.
Enterprises must be able to secure their data against exposures of this type, which could have been prevented with a simple password requirement added to each bucket. Accenture’s relatively middle-of-the-road CSTAR score of 790 is a testament to the difficulty modern IT departments must face: how can we ensure all of our systems are configured as they need to be, even at scale? Until such enterprises can trust that their systems are only accessible as needed, hugely damaging exposures of this type will persist, exposing us all to the brunt of cyber risk.
Update: A prior version of this article at times referred to cloud storage buckets as "servers"—although that is technically accurate, we have changed those instances to "buckets" to improve clarity.