Pentest Files: Error Messages And Cloud Access Keys

Welcome to our Pentest Files blog series.

Each blog post will present an interesting or dangerous finding one of our testers has identified in an actual recent pen-test, so you can see the kinds of cool things our pen-testers get up to, and also to help you take steps to prevent similar vulnerabilities in your own assets.

These findings are taken from real reports, anonymised, and published with kind permission from our clients.

Issue discovered: The application was found to disclose sensitive service ‘key’ information in a verbose error.

Introduction

These ‘information disclosure in error messages’ issues are as old as pentesting itself, are usually pretty boring, and typically rated as low severity.

However, Cloud hosting has now become the norm, and our testers pay a lot more attention to error messages than in the past, because in a lot of cases these error messages disclose AWS tokens!

Read on the for full (anonymised) details of the issue as our tester found it.

What is this?

The application was found to disclose sensitive service ‘key’ information in a verbose error.

What is the business risk?

This would give an unauthenticated attacker access to key services such as AWS.

How can I fix it?

Disable and do not leak sensitive key information in verbose error messages.

Technical Details

Whilst browsing to the following URL (unauthenticated); https://acme-company.com/img/grad/logo-black-new.svg' A verbose error was encountered.

Although this verbose error obscured some sensitive information the following was still leaked;

• AWS access and secret key (giving CLI access to affected AWS account).
• GPG_KEYS
• STRIPE_WEBHOOK_SECRET
• FETCHIFY_KEY For example accessing the AWS account using the AWS access and secret key ; aws sts get-caller-identity

{
   "UserId": "AIADFJSFDIJSFISMDKMSDM",
   "Account": "39123456789",
   "Arn": "arn:aws:iam::39123456789:user/client-staging"
}

Recommendation

Remove this secret material from application responses. This can typically be conducted by setting the Laravel APP_DEBUG value to off. We also recommend to consider these credentials compromised, rotate them immediately and conduct an incident response investigation to determine whether there is evidence of this credential material being accessed previously.

Want to check for yourself if your application is free from this kind of vulnerability? Why not get a quote or contact us to set up a pentest.