A Deep Dive into Serverless Attacks, SLS-4: XML External Entity (XXE) Attacks

Let me first apologize for the long absence. However, I haven’t been idle. I’ve been working hard to take the OWASP Serverless Top 10 project to its next stages: an open-call to collect as much data as possible, then the final publishing of a serverless-designated top 10 report that will serve as the go-to for every serverless security practitioner and developer. Stay tuned.

Now, after you approved my absentee notice, we can continue with this series and dive into the next security risk in the OWASP top 10 project – XML External Entity (XXE) attacks.

Personally, I think this risk will not be one of the attacks that get to the final guide. First, cloud functions often run in a closed environment, such as VPC or VNet. So, unless the external facing function interacts directly with the targeted XML, there is a good chance that this resource will not be able to communicate outside at all. Meaning, the attacker will not be able to steal data in the straightforward, common attack.

But, that’s not all. Another reason for this attack to get off the headlines is the fact that most of the providers have their XML parser as part of their out-of-the-box SDK and it is usually secured by default. So, unless the developer messes with it and opens some backdoors, the default configuration will prevent the parser from parsing external entities.

To be clear – if you’re a developer – use the given XML parsing libraries, but do not add insecure configuration to it, like enabling external DTDs, etc. And, here is your designated meme:

Oh, but we’re just starting with the shaming. Let’s inspect typical vectors and impacts of XXE attacks. The most common XXE use case is to read local files on the server. If you remember my previous post in the series, sensitive files on the environments can be either the source code of the function itself, or any file that is processed under the /tmp folder.

So an attack, targeting /etc/passwd is not interesting here. But, it’s a risk nonetheless. Instead of sending this payload:


A serverless XXE attacker would send the following payload. Assuming that the developer chose to ignore everything we said so far, this attack could still work:


Another outcome associated with traditional XXE attacks is Denial of Service (DoS), in which the attacker sends a payload that will force the XML parser to consume all the server’s resources until it crashes. One example is the Billion Laughs Attack. However, in this case, the ephemeral nature of serverless provides each incoming request with a designated environment and not only that, most functions do not live more than 30 seconds. So, yes. If the attacker is consistent it might cost a few (very few!) bucks, but it will most definitely not prevent any other user from being served.

The only way it could cause a real DoS, is if the developer really really wants to help the attackers and not only gives a long, unnecessary timeout to the function (up to 15 min), but also sets a low concurrency limit for the function. But, hey – I‘ve seen things before… evil things. &lol.

Other traditional XXE attacks might try to perform a type of SSRF attack, forcing the XML parser to make network requests within the local network, leading to the possibility of further escalation for the attacker. What about serverless? A standard execution of a function has no “internal network.” It leaves on a closed environment, controlled by the provider. If you found an escape – XXE is the least of the problems.

However, there could be serverless architectures where some other cloud resources share the same private subnet as a function that handles the XML parsing. But even if this scenario exists, you will usually not find resources that are accessible directly, without protection.

life inside an amazon vpc

Don’t believe anything I said. Let’s try. A simple function that reads an XML file from an s3 bucket and parses it:

XML file from an s3 bucket
Uploading the following “good” XML:


Now, let’s look at the logs for our print. Normal:

With “evil” XML:


Undefined entity:

Out-of-Bound… still nothing:


However, if the developer REALLY wants to, he can open it to some trouble… a slightly modified function. This time the developer enabled DTD:

developer enabled DTD
Let’s have a billion laughs:

After setting the function to 10 minute timeout with 192 mb memory:


According to AWS Lambda pricing, each 100ms on 192 mb function costs $0.000000313. Based on that, to cost the organization $1, the attacker would need to execute more than 10,000 of such “DoS” attacks, on a typical 30 second timeout function. Totally worth it. &lol

Enough with the negativity, let’s see an example of an attack that does work. At least partially. In this example the developer is using the lxml library, and manually making it insecure, by modifying the resolve_entities, load_dtd and no_network flags to the opposite of their default value:

lxml library

In this case, by sending a simple XXE payload I could cause the XML parser to fetch the function’s source code.

XML parser

XXE payload
Bottom line, the attack exists, if you deal with XML you should be aware of the risks and try not to enable configurations that were disabled in the first place. Other than that:

  • Use the service provider’s SDK whenever possible
  • Scan supply chain for relevant libraries known vulnerabilities
  • If possible, identify and test for XXE attacks via API calls
  • Make sure to disable Entity Resolution

And if you can’t? Use Protego’s Function Self Protection and we’ll do that for you.

Protego’s Function Self Protection

The post A Deep Dive into Serverless Attacks, SLS-4: XML External Entity (XXE) Attacks appeared first on Protego.



*** This is a Security Bloggers Network syndicated blog from Blog – Protego authored by Tal Melamed. Read the original post at: https://www.protego.io/a-deep-dive-into-serverless-attacks-sls-4-xml-external-entity-xxe-attacks/

Tal Melamed

Tal has 15 years’ experience in the information security field, specializing in security research and vulnerability assessment. Prior to being the Head of Security Research at Protego, Tal was a tech leader at AppSec Labs, leading and executing a variety of security projects for serverless, IoT, mobile, web, and client applications, as well as working for leading security organizations, such as Synack, CheckPoint, and RSA. Tal is also a keen speaker; training DevOps and hackers around the world, as well as lecturing at major security conferences; and a neat developer, experimenting daily with offensive and defensive security.

tal-melamed has 8 posts and counting.See all posts by tal-melamed