Big brands get big publicity after a breach and Capital One is no exception. However, mainstream media is known to sensational the story rather than taking an objective look at what happened. The following is our opinion based solely on publicly available information and is not the opinion of Capital One or any related parties.
Firstly, the term vulnerability as it relates to this story is being used incorrectly in most cases. We believe there was a misconfiguration on the way the server handled the transmission security for the Metadata service. This allowed Thompson to scan and sniff the plain text passwords being sent from the Metadata service up to the cloud server (probably a service account, passwords are seldom changed on these as they are usually coded into the application). Mind, you - she was internal and a programmer. Once she had the credentials, it was easy to craft a packet directly to the listening service requesting the data.
We believe, Amazon has no part in this. However, there were several errors committed by the Capital One team, the main one being deploying default settings and not hardening the data stream and end points. As is common with big companies, they most likely deployed in haste and did not take the time to perform due-diligence on the entire service architecture.
Furthermore, we feel the following errors may have also been culprits:
1. Vital servers (meta data servers) were not configured to protect the transmission (not using certs)
2. Firewalls internal to Capital One were also not configured to secure the transmission (all packets are just routed and not filtered by IP or Network)
3. Amazon security services were not enabled - though available. (Deployed default settings)
4. Ms. Thompson most likely had Admin rights on her work computer that allowed her to install tools to find the weak configurations.
5. Capital One was most likely not doing vulnerability scans of this service to identify the weak security.
6. Capital One did not do appropriate penetration testing to identify the weak architecture on this service.
7. Poor oversight altogether on metadata service infrastructure
To us, this appears to be human error as the proper configurations to secure the metadata services are there, but not many are enabling them. A security researcher found 800 more Amazon service customers also using the 'default' settings.
For purposes of ambiguity, I don't think news outlets are being direct on what exactly happened. This maybe both to slightly protect Capital One from being thrown under the bus for not conducting proper security and to prevent others from identifying the weakness easily.
Hope this helps you develop some additional understanding of the situation which unfortunately, is all too common. To us, the cloud is a 'fad' and nothing more - hardened security, real hardened security uses owned assets - and not cloud (shared) infrastructure. Also, you have to read the manual and ensure all the proper security features are enabled.
There is a massive misconception in the industry that moving to the cloud means security on everything. They seem to forget that AWS/Azure/Others are just providers. They give you the service and the operating horsepower to accomplish your task, but they will not and do not configure or maintain security for you. That has and will always be in the hands of the customer. This is due to the variations of configurations necessary for each business - individually. They want to provide something for everyone - and not lock customers into a security box - rather, they deploy default and allow you the customer to secure according to your own needs and internal standards.