Serverless Security And The Weakest Link (Or How Not to Get Nuked by App-DoS)

Here’s a short blog post on design-for-failure, serverless scalability, App layer DoS and what happens when you rely on open source 3rd party libraries.

Premise

I was approached by someone who runs a sarcastic newsletter, who asked me to try and hack his serverless-based newsletter registration app (and no, it wasn’t Jeremy Daly–it was someone far more sarcastic). I believe the promise was that if we’ll do some serious damage, he’ll give us credit and even deploy PureSec. Needless to say, I never say no to an opportunity to inflict some damage and most importantly – to get access to more serverless security data and knowledge.

In order to speed things up – that person granted us access to the source code, which was hosted on Github, with the promise that – “there’s nothing really special about the app, it’s running with least-privileged permissions” and “I doubt you will find anything interesting, but give it your best shot!”.  

Sponsorships Available

Sponsorships Available

Sponsorships Available

App-DoS via Email Addresses

Looking at the source code, the first thing that caught our attention was the fact that the app was using the “SendGrid” service for handling email operations.

Digging a bit more into the SendGrid library, we noticed it was leveraging Python’s ’email’ package, and specifically using the method email.utils.parseaddr().

Alrighty then – parsing emails are ya? Parsers are always the most interesting component to target,

The parseaddr() method is used to parse a given email address and return an Email object. Sifting through the code, we found out that this function supports all sorts of email formats mentioned in RFC 822 – e.g. <foo bar> [email protected]  – looking at the code, we figured it will run inefficiently when presented with long email addresses that contain certain characters with special meaning.

With this information at hand, we created a 100KB long email address in the format:

<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x<a>@<>x…

Sending a single API call with this email address to the “subscribe” API endpoint demonstrated that the serverless function stalled for a few seconds, whereas with a standard email address it would simply reply within milliseconds. Bingo.