Prototype Pollution in JavaScript

Thanks a lot. So we'll talk about prototype production in JavaScript, but before we do that, let's talk about something very important, me. So the bio is a bit outdated and that's on me. I don't work at Datadog anymore, like since two weeks ago. And I'm working at a company named QueryTails that is not even a company I need to tell the lawyer to incorporate. And it's not even an association because it's basically myself. So if you want to feel sad for me, you have to know that I feel so lonely that I do my stand up meetings with Chad GPT in the morning. And speaking of the logo of the companies that's another AI that designed it. So that's basically me being unemployed on Twitter, French unemployment money, trying to build a company.

But let's talk about prototype pollution. So first of all, before we pollute prototypes, let's learn what prototypes are. Even if that's a JavaScript conference, it doesn't hurt to go back. Also, you can notice there is no design in my slides whatsoever because designing these slides consisted of removing the Datadog logo and color scheme late yesterday in the plane.

Then we will talk about the impact of prototype pollution and avoiding prototype pollution in JavaScript. And this talk has been designed for twenty five minutes and I only had twenty of them. JavaScript is prototype based and somewhat typed. OK, what do I mean? Let's start with the type part because it's probably the most trolly. Well, you've got the type of operator and you can check the types of variables. So types of true is a boolean, type of null is an object that's called the billion dollar mystic, but that's not the topic of this talk. Type of 10 is number type of 10 n is bigint and so on and so on. We even have the undefined type for stuff that are undefined. JavaScript is so great. And pretty much everything else is an object. So objects are objects. String objects are objects. Regex are objects, null is an object and objects are objects. Obviously again and objects have methods like if you create the object Foo1 and call hasOnProperty on it, it we returned true. And if you create the object Foo1 and check hasOnProperty, hasOnProperty, it will return false because the method hasOnProperty does not belong to the Foo object.

So where does it belong? Let's use the best tool in history of programming, the debugger. And we can check our object and see that the method hasOnProperty exists on something that's called a prototype and the prototype can be accessed from the object directly. So what are prototypes? In JavaScript, objects have prototypes. When a method or property is not found on an object, it's looked up on the prototype. But prototypes are objects. So if a method or property is not found on a prototype, we check it on its prototype. But the prototypes are objects. So if a method or property is not found on the prototype, we can check in the prototype. And that's what we call the prototype chain. It means that we will recursively check the whole prototype chain until we get to null, to find a method or a property. And if it's nowhere in the prototype chain, it's undefined and undefined is not a function.

So prototype chain, basically, it's a tree. So on the left hand side, I defined a prototype in my proto. I use that to create objects. I defined a class with a constructor, old style class. I give it a prototype directly, and I even define a class with the class keyword. And basically when I create objects on the right hand side with these, they will share prototypes or not.

Okay. Let's go a bit deeper. Item three has a prototype, my proto, because on line eight on the right hand side code, we set objects dot set prototype of on this object. So we have a method to arbitrarily put a prototype on an object, but item one and item two, the prototype of the class one, because we created them with new and called the constructor of the class at the bottom of the left hand side. But since this class extends old style class, well the prototype of old style class define a line eight to 13 on the left hand side is still on the chain. So if I want to check the method, the method bar on item one or item two, it won't be available on cl.prototype but it will be available on old style class.prototype. Okay. Is that clear? I hope. Please don't throw stuff at me. Okay, thanks.

So how do we access the prototype of an object? Yeah. But the people telling me it was clear, knows everything about prototype. So how do we access the prototype of an object? We have multiple ways. So let's have a class named my class because I'm very original in the way I name my classes and create two items, my item and my item two. If we check, if show prop, which is a method of the class is available on this object, they are not, because has on property on line 13 tell us it's not available on the object directly. But if we do object get prototype of my item, this will return the prototype of the class. And this has the own property show prop, that's what we are on line 14. We can also access a prototype with underscore, underscore, proto underscore, underscore. So if we do my item, underscore, underscore, proto, underscore underscore that has on property show prop, it will return true. And if we console.log my item.constructor.prototype has on property show prop, it will return true too. And what is worth noticing that there is a single instance of this prototype in the heap, meaning my item dot underscore underscore proto underscore underscore, is exactly the same thing as my item two underscore, underscore, proto, underscore, underscore. Pretty sure nobody said prototypes that much in their life in a short amount of time.

So what's a prototype pollution? Well, a prototype pollution happens when an arbitrary payload handled by the JavaScript code base can overwrite properties or method somewhere on the prototype chain of one or multiple objects. This usually happens when we use a merge function and we will see in details why.

So what do I mean? Let's take an example. Let's take the Hook library in version 4.1.2, 4.2.0 and we have something called malicious payload on line two and that's a string that contains underscore underscore proto underscore underscore oops it works, and then we create an object name A and this object has nothing to do with malicious payload. In this world code base, it's never called in the same function as malicious payload. It doesn't know about malicious payload. So we console.log A.oops and it's undefined because oops is not present on the A object. Nor it is present on its prototype chain because it inherits from the default prototype chain of any object in JavaScript. Then we call hug.merge on a brand new object, nothing to see with A and JSON don't pass malicious payload. And after that, when we call A.oops, it will return it works. Because the prototype of all objects, the prototype of objects, the main prototype of the heap of this JavaScript codebase, now has the oops property. How comes? Well, it's because of a recursion.

So this is the merge function that we've seen on line five on the previous slide. And this function is actually performing recursive merge, meaning that if you want to merge two objects, and they have properties that might be in common on their sub objects, it will recursively check for them. But because of __proto__ being an accessible property on most objects, well, the function will say, Oh, I've got something in proto to write on this object and this object has proto. So we'll take the value of the prototype of the object and start writing stuff on that. So what I mean is that through the merge function, because of this recursive call on line 18, we go up the prototype chain and we write, oops. And that worked in lodash too, because I want to terrify everyone. I mean, in older versions of lodash, you've got another payload constructor, prototype, isAdmin. You remember I showed you we can access the prototype of function of an object by going through constructor.prototype. Well, we do exactly the same thing. We have an object B, B.isAdmin is undefined. We use lodash.merge on an object that has nothing to do with B and payload as a second argument. And then B.isAdmin is true. And oh, sorry. And lodash is insanely popular, this slide is not for JavaScript code, it's for security code. You all know that lodash is insanely popular and cool.

So what does the impact of prototype pollution? Because it sounds like a good way to mess with someone's code base, but can it be evil? So since 2018, there have been more than around 200 CVEs, CVEs mean public vulnerabilities disclosed for everyone to know and not every vulnerabilities get a CVE. So that's probably the top of the iceberg. There have been a few remote code execution in Kibana and the PaaS server, and no, I'm not working at Datadog anymore, so I can say what I think about Kibana without looking so well.

So I expect some slides about that and KTH University published a very interesting paper on this topic last summer. So the Kibana case CVE-2019-7609, basically it's a very, very fun one. I love it. So Kibana use child processes from Node.js for certain stuff. Like if you want to do some computation in Kibana, it will spawn a child process. And when you spawn a child process from Node.js, it will share the environment from the parent process to the children process through a JavaScript object. You see where this is going? There's an environment variable in Node.js that's named Node.option that you can use to pass common line arguments to the Node binary. So instead of doing Node dash dash something, you can do Node.option, put your dash dash something in it, and then when you start Node it will catch this up. And there is also the dash e or dash dash evil command line option in Node that enables you to run code passed as a string in the command line. So the example here is Node dash e console.log hello that actually starts a Node process and runs console.log hello. Let's prototype pollute this. Well, why do I have, oh yeah. I'm missing something. Okay. I'm missing a slide. Sorry about that. So basically there was a prototype pollution in Kibana and you were able to write Node option in the prototype chain. You know, you would prototype pollute and every JavaScript object in this heap. When you check if Node option is defined, it will respond with, oh yeah, there is a dash e execute by evil record execution, with the string. And that's basically what happened to Kibana. So if you had access to a Kibana server to a Kibana UI, you could run arbitrary code on the server and then spawn another try process with your share arguments on everything you want. So we fixed that. Dash e is not allowed in Node option anymore, but there is a bypass and it's public, but I won't talk to that. And Kibana has fixed the prototype pollution. The original paper is very interesting, very accessible and there is also a talk, certainly on that topic, very, very interesting to watch.

Parse server. So parse, who is familiar with Parse here? It was very, very popular a while ago. It's basically a backend project for mobile applications that expose an API in front of a MongoDB server, being acquired by Facebook, shut down by Facebook, and now there is only an open source version that only Google shut down product people love. And basically that's an API in front of MongoDB. You can store objects.

You can request object from MongoDB through a wave API. It's vulnerable to prototype pollution before it was fixed of course. And it uses a library that's named bsonjs. So, bson is a format to store objects in MongoDB. It stands for binary JSON or something like that. But, bson allows you to store functions that will be stored in MongoDB and you can unserialize. But by default, they are not unserialized. Because unserializing a function that would come from a database would basically mean, let's do eval on that string that comes from the database I have no idea about, and you don't want that to be a default. But if the option eval function on the object used an option for the bson library is true, well, you will be evaluating those arbitrary functions. And because Parse allows you to write pretty much anything you want in your database from the network, because it's Parse, you could actually run arbitrary code when the object is retrieved, which is, oh my god, that's because they check the diversion hack.

How to prevent prototype pollution because I'm a responsible person, I don't want you to feel scared and say, you know, let's use a language without prototypes like Python. How to prevent? Well, let's filter out, you know, merge functions. You see, for instance online nine here, line nine, nine, three, or online four here, that we filter out, underscore, underscore, proto, underscore, underscore. And that's what we've been fixing a lot of libraries. Lodash has been adding more prototype pollution than any other library I know, and they've been all fixed one by one. If you find a new one, feel free to responsibly disclose it to their maintainer, whatever libraries it is.

Sometimes, you will know that your code path is critical and you want to make sure that you're using as-owned property. Well, well, as-owned property can be tampered with with third-party attacks, but that's something else. So make sure that if you expect a property to exist on an object, you make sure that it exists on the object and not on its prototype chain. Also, this one I like. It's what I call building defensive object. I don't know if that's the academic term, but you can use Object.create and that will create a new object with its arguments as prototype. Well, null is an object. So you can do Object.createNull. These objects won't have all the methods you expect them to have as-owned property, as-owned symbols, get-owned-property descriptors, but this object will be safe from prototype pollutions because it doesn't have any prototype.

Sanitization, make sure that stuff that gets in your process from the outside are safe. Do data validation. I love the joy library because I'm a happy, happy thin fat boy, but there are a lot of amazing libraries to do data sanitization. Use them. They are very cool. And anyway, you should use them if you're building a web server with Node.js. As mentioned that will also probably remove your surface of attack to no secret injection. So go for it.

Conclusions. Oh my god, I'm on time. What's now? Monitor incoming objects Node.js has an option to disable proto, underscore, underscore, proto, underscore, underscore. It might break some code. So be warned that it might break some code because the Internet but you can use it. And for sanitization and prototype less object. Oh, you remember why I told you should use Python? That was a joke in January.

Someone published a paper. There is no proof of actual use in the wild for malicious attacks, but there have been a paper about class pollution saying that oh basically Python is vulnerable to that too. So there's nowhere safe.

Some links. The slides will be on Twitter. Please shout on Twitter if you want the slides. So let's stay in touch. You can find my Twitter with this short URL.

I hope you enjoyed this presentation and you have questions that I can answer. Thanks so much for being an amazing group. We will come to this question in due course. There was a lot of suggestions there on how you can mitigate the risks brought about by prototype pollution. If our audience were to go home and go to their code bases that they're currently working on and with the concerns that they may now have, what would be the first thing that you encourage people to do? Maybe it's a more simple low lift action or starting off a more significant piece of work.

That's a very good question. I think the first thing to do after being at a conference talk about security in Node altogether, when you come back is check where your objects come from, and that's true for mitigating prototype pollution, but also all sort of injections. So when I mean that, I mean, at some point, if you have a web application, it might accept objects from the outside. Can be the query strings, can be the body. At some point, there is a library in your code base that will pass a text HTTP request and return a JavaScript object. That's probably the main source of malicious inputs. Because your application, it can be vulnerable to third-party attacks from your NPM modules, all for the inputs coming from the network. And me, I prefer to think about the things coming from the network, talk about, talk to ZB If you are interested in the other threat model, the part of the threat model. So check the object that comes into your app and check what you are doing with them. Are you sanitizing them? Do you know their shape? Is there an error in your code when they don't like, when they don't look what you expect? That means method that, properties that you are expecting of the object, but also, are you sure that the object doesn't have properties you don't expect? So objects that get into your app, you must know what they look like. And that will, that will be the first way to know that nobody is injecting some kind of underscore, underscore, proto or constructor elements on your objects. Cool.

Thank you so much. So some questions from the audience, is there an easy way, I think you touched on this, but I'll ask the question explicitly regardless. Is there an easy way to check if my service is vulnerable to this attack, someone who uses a lot of third-party NPM modules? Sneak Audit, NPM Audit, you will already know the vulnerable methods, if they are known. Check if you're using merge methods in your own code, but yeah, basically making sure you don't have known vulnerability in your codebase is the first step. Ideally, frameworks should be able to handle these kinds of things for us.

Are they? Is there something like Express or Fastify or equivalents that prevents prototype pollution? As far as I know now, but I'm not up to date on Fastify documentation, Express documentation, I'm up to date because it hasn't changed in five or six years, but I don't think so. That's a very good point, I guess Matteo will say PRs are welcome, so feel free to PR Fastify.

The next question is something you mentioned in your talk, but it has had a couple of thumbs up. So I want to ask it regardless. What is the "-e argument in the node options bypass? Okay, so "-e is short for "-eval and basically it gives you an opportunity to pass a string as argument instead of a file and run this string as if it was a JavaScript file. So instead of doing node index.js, you do node "-e and you put a string with your whole JavaScript code and that that will execute it. Great. Thank you.

Does object.assign also create polluted prototypes? That's a good question. I want to say no, but I'm not sure of it. So that's your homework for tonight. I don't think so, but was checking. Didn't think you were coming to no congress for that homework. Are there other ways of doing RCE with prototype pollution without node options like in the Cabana example? Well, there was the bison example with a function being in serialized. So I guess so in a way, that really depends on the application you are attacking, does this application as string evaluation at some point whether it's through environment variables, through eval, through with VM the transcode, in that case, yes, but it's very business logic dependent. Thank you. Got a few more, you want to get through. Should we, based on your talk, should we therefore be using maps more and instead of objects to avoid these problems? I mean, yes. Yes. I mean, just make sure that you're, if you're very very cautious about that, you need to ensure that there is no intrinsic pollution, meaning that someone overrides the map based methods, they can't do that as far as I know with prototype pollution, but they can do that with a malicious third party. The Node.js code, code base is actually very defensive against that, so you can check. But yeah, maps is probably one of the smartest thing you can do in your web application as far as I'm concerned, I love maps. If you've been to James' talk about asynchronous storage, the first version I proposed of asynchronous storage would force you to use a map as the store, so as a map lover, I would say yes, but I'm biased. Just a tad. What if I merge an object with a native spread operator instead of the old version, an old version of lodash? I think you're safe from prototype pollution, but it's like object data assigned, I never tried it, so I can't be assertive on that. I think with a lot of these questions it is probably the case of like as you're trying to solve for this risk that you are trying all the solutions and seeing what the outcome is, right? Also, I kind of hope if these ways were vulnerable to prototype pollution, we would vastly know it as a community, so that's why I tend to think we are safe, but as a security person, I don't want to handle things. And you don't want to assume either. Are there or could there be some kind of ES lint rules that detect these problems? Good question. There could be a need. It's hard because it needs a bit of taint tracking.

There could be at least a semgrep rule that will check that you're merging based on incoming objects. So semgrep for those who are not familiar is a static analysis code. It's open source. It's written in Okeanos, built on the west coast, it's really really cool and it's designed to find vulnerabilities. But it's a bit smart. It's more powerful than most linting tools because it has some kind of symbolic execution engine and can basically run part of your code in a VM. I mean executes part of your code and decide if it's vulnerable. So I'm not sure about linter but I'm pretty sure about semgrep. Cool. Awesome.