You could have read about a new interesting attack vector. It got the cool name of the Denail-of-Money attack. The first published case (which was actually an accident) was happened with an Associate Professor at Leonard N. Stern School of Business of New York University called Panos Ipeirotis.
His story in nutshell is that he made himself a more then $1700 Amazon AWS bill in a couple of hours. The root cause of the problem was that he shared 250 GB images in an S3 bucket. He used the thumbnails of these images in a Google spreadsheet. As it turned out Google in this case doesn’t cache content because it is considered private. Instead of caching Google simply downloaded all the 250GB every hour which costed a huge amount of money(although at the end Amazon refunded it).
During my first pentest reports it happened a few times that I suddenly realised that I hadn’t saved some data which would have been good to include in the report. Usually this costs you only time to reproduce the problem and gather that data again, but sometimes it’s not possible. Either you are not allowed to access the target system anymore or in case of a test environment it might not be even running anymore. In this case you need to accept that your report will be worse as it could have been. To avoid these situations I tried to summarize for myself what is needed to a report and how all relevant data should be stored for a finding. Bear in mind that usually every penetration tester has their own way to keep their data so this here is just my way(or the highway..).
It happens time to time that I need to do penetration test on a production system because the costumer doesn’t have any test environment. That is always a bad start. The explanation is usually that the target system is not a separate application or appliance but it is tightly integrated in the company’s infrastructure. Nevertheless it is very unfortunate from the penetration tester’s point of view. This brings the following limitations in the pentest:
- no insertion in the database that cannot be removed
- no agressive tests
- careful with business logic
For example in a production system it is difficult to decide whether clicking on a submit button will immediately order something for €1000, send out 10000 e-mails or first pop up a confirmation window which might be vulnerable to Cross Site Scripting.