About this talk
In this session, Danny, a developer and security advocate from Dynatrace, discusses the importance of security awareness for developers in light of current vulnerabilities in web applications. He highlights a critical vulnerability called 'React to Shell,' which was discovered in React Server Components and allows remote exploitation without any user interaction. The speaker explains that this vulnerability stems from a lack of security checks in the deserialization process of the protocol used in React, enabling attackers to access sensitive data and manipulate server applications. Danny also addresses broader security risks, such as broken access control and supply chain attacks, providing real-world examples and recommendations to strengthen security measures. He emphasizes that security should be a shared responsibility among all developers, and he encourages further education on security practices.
Full transcript
Hello. Hello everyone. Can you hear me? Yeah? Good. So, my name is Danny. I'm a developer and security advocate for Dynatrace. And how many of you guys are security engineers specifically? Anyone? Okay, not many people. I guess most of you are developers, either front-end, back-end, cloud engineers maybe, so. This is a cyber security talk and you might wonder, so why should I care about security if we
already have a security engineering team, right? In big companies, we used to have this team. why care? Well, now in the age of AI, I think the gap have some security knowledge is closer than ever maybe this vibe code it code that you did works, but it's not secure, so for everyone to have these security concepts in mind, it's something that it's really useful for your day-to-day
development and also for growing in your career. you have you could have your super nice stroopwafel e-commerce and uh the attackers will use any hole in your application to exploit your server and get your data. And all the attackers don't look as nice as this one. Some are more like this other rat. to get started with this talk, I wanted to specifically talk about a single vulnerability
that happened recently in the web ecosystem, which was about React, and it's called React to Shell. This vulnerability was disclosed this December, it's been the greatest vulnerability, most critical vulnerability in React history so far, with a 10 out of 10 of the uh score system. Why is that? It's because you can access it remotely, so you don't need to be on the local LAN of the server
to be able to exploit it. It's very easy to exploit. You don't need uh any kind of difficult steps in order to reach it. You don't need privilege. You don't need to be authenticated. There is no user interaction needed, so no need for the user to do a mistake by clicking a button in the UI. No, it's accessible through the API, and anyone can can do it.
Maybe if you even had some servers running in the cloud, you've received and you've seen in the logs that someone tried to exploit this vulnerability by by creating some post request into your Just to check if it was feasible. Um it also allows access to sensitive data because you can access the shell of your server. And by accessing the shell, they have the attackers have the power
to do everything, basically manipulate any kind of data. and they can make the system unusable. the affected libraries were React Server Components from Next.js version 19.0, 19.1, 19.2, and also React Router were affected. let's understand how this vulnerability happened. So, react server component have a protocol that is called react flight that is used to serialize and deserialize tion of the data transmitted within the server and the
client. So, after react 19 there was this piece of code that was added into into the server to deserialize the data and in short what this could do was that you would get the payload of the any post that you send to the server and you were putting it inside the attribute of module exports in this case. So, by doing that you are not checking anything in
terms of security you are able to put whatever attribute you want in this module exports. So, you could do something like this example and access the proto attribute in the in JavaScript. So, by accessing the proto attribute and adding dot constructor dot constructor basically have uh call to the function constructor in JavaScript. So, whatever you put inside the payload, in this case a simple console log one
it will get executed. So, I'm converted into a function. So, this line is equivalent to the to what is in the comment. well, there was no safe check in the API for users to not use the proto attribute in order to achieve this. So, uh here I have a special footage of the current security check that happened in React server components at that time. how do we
exploit it? In order to exploit it, we need to understand the source code that is open source and see that this flight protocol is using this chunks in this JSON structure. And as you can see, you can somewhere proto in there. You can see the constructor.constructor that I told you about. And by creating crafting this JSON, you will be able to execute in the server whatever is
it on the prefix attribute. And in this case, it's a JavaScript code gains you access to the shell command by doing the execSync. You can do a listing of the file system files, for example. not sure if you understood correctly, so I think it's better to show you a demo. And what I did so far it's I built a Next.js application plain from the create create Next.js
app. So, this is what you get just by starting. And I switched the versions to the to the vulnerable ones in the package.json to be able to use this exploit. So, now you won't wouldn't be able to to do so. I here have Burp Suite. And with Burp Suite, I have here crafted my payload that I'm going to send to to the vulnerable server. So, I'm doing
a post. And I here is where I have the this proto thing attribute constructor constructor and here is the the code I want to run my server. So, in this case I'm doing a who am I shell command. Uh if I run it again you can see that who am I Danny Coil is the user that I have in in the server. So, I could also do
something like LS. So, I'm listing the files on the server. So, I see all the source files. I could browse through them. I can see which are the processes that are running. Here they have many processes running. Maybe I'm interested into the into the next JS. So, I'm going to filter the processes by the ones that include next. So, I can see here my next JS server
process is this one. So, I could do I could stop it. Kill minus nine. This process. no response from the server. Okay. So, as you can see the the page is not loading anymore. So, our server is gone. We can see in the logs that it was killed. So, you can do anything. You can actually remove all the all the files in So, with this we end
up this piece of the demo. has some good things at least out of the box. For example, cross-site scripting protection. And also frameworks like Angular, Vue have also that. So, in this case we are seeing React as specifically, but you can check that. For example, when you try to run some super malicious code like in this case, a script that says I love jQuery, you won't be
able to do that because it will be converted in plain text. And you need to uh specifically say dangerously set inner HTML in order to be able to render properly the the script or any HTML that is not plain I wouldn't do that for any third-party sources or user input unless it's properly sanitized. So, you can sanitize with libraries like DOMPurify. And then you are good to
go because this is the input that you get. And this is the output that you get. So, it gets rid of all the JavaScript code by sanitizing it. cross-site scripting is no fairy tale. For example, there was a case for eBay in 2014 that it allowed adding cross-scripting in the product description. So, there was a smart guy that thought, "Okay, why not try to sell cheap iPhones
for 38 euros and see if people click in our description of the iPhone, and then they will get right redirected to a fake login page exactly the same as eBay. So, but if you put your real credentials on there you those credentials will get stolen. be aware about cross-site scripting. But, now I want to focus on the most critical security risk nowadays. In the there are two
of them. I don't have time for more, but two of them that are in the top three of most critical security risk. And the most critical one is the broken access control which is when you fail to enforce proper restrictions on what users are allowed to do. it could happen in two ways. On vertical privilege escalation, this is when you are a regular user and you are
allowed to to get admin user permission scopes or even root access. And it can also be horizontal privilege escalation. So, this maybe I'm user A and I can access the resources from user B, but maybe this should be private. You should only access what you can. we had a real case scenario on 2000 Anand Prakash, if I pronounce it which he was the CEO of of AppSecur
access Facebook at the time. He tried to reset his password and they were sending a six-digit code to your phone. Uh so, basically this six-digit code had a anti-brute force mechanism in So, if you try to reset the password 10 times, it wouldn't allow it to. But, this guy, what he found is that if beta.facebook.com instead, you had the same data than in the real application, but
there was no brute force mechanism to stop. So, you could ask uh ask and ask and ask and ask for for the real password and reset multiple times, infinite times until you get the the real six-digit code hack any account in Facebook. So, he got rewarded for 15 15k for trying finding out this vulnerability. luckily, it was not exploited much. But, bear in mind of this vulnerability.
So, overall, there's a weak API security when you have no rate limits at all. You also are exposing excessive data in like only send to the front end on from your APIs the data that you actually need in order to display, no more, no no less. And also, improper error handling like having stack traces or content of source files in in your APIs results can potentially be
bad for the security of your system they can read through it. another thing is that I don't know you guys, but sometimes I need to create a token which are the permissions I do need know. So, I'm a bit lazy and I take all the check boxes. And that's it. Who has did that? Okay, many people, so Please don't try to have users to only access the
minimum necessary for their task. Otherwise, if someone gains access to this user, they potentially access whatever they not supposed to. So, please create tokens consciously. what else? The second vulnerability is the supply chain attacks. So, this is when attackers don't target yourself, they target third-party software that you use. And we all know that our software and any software out there a project that some random person maintains
and nobody knows who. in 2024 this there was this library that was called xz utils that they added back port backdoor code in the in this library in order to gain access to the to the Linux system. So, it was a data compression tool that basically every SSH command that you were running in in had a backdoor that they this guy could steal the data of every
Linux system at the time. So, how this disclosure was really interesting to me because the attacker was really playing the long game. There was a repository this one that had a low maintenance. So, there was this new user that 3 years before started making contributions in order to gain the trust of the real maintainers. suddenly someday it become the new maintainer also because maybe they there they
had multiple accounts and they were like insulting the real maintainer like, "Hey, you are a bad maintainer. Uh you should let someone else take care of it." And in the end they fall they switch the maintainer to this new user. And then once they change the maintainer, the he added backdoor code encrypted so no one would realize easy. But luckily after been released with less than a
day, someone realized that there was the SSH command was taking half a second more to load than before updating. So, they quickly find out which was the real reason about this and no major servers were affected by this. which security measures can you apply in order to avoid supply chain attacks? One would be updating your dependencies regularly. So, you avoid known vulnerabilities that attackers can exploit. every
second, every minute because it can happen something like this that package is not yet thoroughly tested. So, maybe it has a vulnerability. So, I do recommend using settings like the minimum release age. So, waiting 24 80 84 hours 48 hours or some days at least before installing a new package. And you can use tools like Dependabot and Renovate to we to update the packages. I I use
both. And with this setting you won't get the latest packages until 48 hours. So you are safe of vulnerabilities like Also, you can set set up private repositories. We use J- JFrog for for this. And this private repositories act as a proxy. So instead of reaching NPM directly, you reach uh your private repository JFrog. And this catches the the approved And you it allows to control which
versions you make available in this repository. And also detains detects man-in-the-middle attacks because you have this integrity checksum that end-to-end you check that it matches the the actual checksum that it was supposed So overall, choose your your dependencies wisely. even if you are using private repositories, avoid untrusted dependencies and avoid dependencies for trivial stuff like centering a div. And so these are the two vulnerabilities I wanted
to focus about. And I want to finish the talk uh security mechanism that many of you may already know, which is the cross-origin resource sharing. what is CORS? CORS is basically when you try to access from a certain origin another application. probably some of you had this error once in a while. Who had this error of your page has been blocked by CORS policy? No access control
origin header is present. Okay. And who tried to solve it by adding this line to the server? Okay, good. But bad idea. as I told you, um CORS is when you are able to access data from different origins. attackers could potentially use this bad setting in order to access your your data. So, try to host always the server and the client in the same in the same
origin. And also, if you need to access external server instead of accessing them directly from your front end, you can use the your proxy server, your own act as a proxy and access this external to wrap up, I want to show you a demo of how this vulnerability can be exploited in in your applications. For that, I built a crypto trading web. trading web is vulnerable because
it has CORS misconfigured. So, a potential attacker that is already preparing a phishing email to send it to me and collect my data into their server. So, how this actually works. So, the attacker will send a phishing email to me. And if I click to the phishing email and I open this phishing site that it's on the phishing email, uh the this phishing site, since my trading
crypto web is vulnerable, this phishing site will be able to access the APIs from my crypto trading web. So, it will it will it will get the data from this page, send it back to him. And once it has the data it will send the data to the data collector server where they have all the data of the users they hijack. So, demo time. Let me show
you. Here's my Crypto Trader website. So, I'm logging as the attacker. I can see I have some some crypto. I can see the account details and the attacker what would do is like maybe refresh the page. It will say, "Okay, user details from the API." We see the headers and okay, access control origin asterisk and it also has access control allow credentials true. this means that this
webpage is really knowing this the attacker will try to fish one of the users of this application in order to gain access to their tokens and potentially their their their crypto. So, we log out now. We log in as the as the regular user. And regular user would be buying crypto, selling crypto and this regular user goes to his inbox in Gmail and he sees, "Congratulations, you
won a free ticket for JSWorld Conference." Okay. Seems interesting to me. So, I click on it looks like a pretty nice email. So, you want a free ticket for I Amsterdam, May 7th. For valued in 499, claim your free ticket. Seems legit, no? Also, this the sender the real gswc [email protected]. So, seems legit. So, let's click it. And here is when we already up. So, we have
been hacked already without doing anything, without entering any credentials because our crypto app is so vulnerable. It has it doesn't have course enabled, so this website is able to get the data from the other one because I'm already logged in in this one. So, my my session is is stored in the cookies and this page is able to get it. So, it wins back this. I added
some logs stolen data and data successfully exfiltrated to attacker server. And if we see the attacker server here, we can see that we received the data. this actually only works if if you have if you are logged in and you have the session in the cookies. So, for example, if I clear the cookies and I log out and I try to do again, I will get still
a course error I don't have the data in the cookies anymore. So, uh you need to be logged This guy needs to be logged in in order to make the data vulnerable. So, now if I refresh, token. Well. Well, never mind. But you saw the point. going back to the presentation, as a conclusion, um security needs to be present at each development stage and everyone needs to
be aware. Even if you are not a security engineer, you are front end, back end, everyone needs to know about security. Can happen things like this one. So, don't wait for the vulnerabilities to happen to act. if you want to learn more about security, there are plenty of free enablement sources. There is a PortSwigger web security academy that has many lab exercise that you can play around.
There are course ones, there are cross-site request forgery, there are the broken access control, everything. There's also courses from this case Cisco ethical hacker course. There's the TryHackMe web that tomorrow there's one speaker from this company as well. They're They're sitting around there. OWASP Secure Training Dojo also has plenty of exercises for security to get to know more about it if you if you liked it. overall,
this is it. Thank you very much for listening. Hope you enjoyed it.
