This is a transcript of the A08 - Software & Data Integrity Failures training session. Click here to return to the OWASP Top 10 Security Vulnerabilities page.
Janez Urevc: [00:00:00] Let's get going. Um, so the last topic for this session is software and data integrity failures. Um, this used to be called deserialization problems or something like that or broken deserialization. Something like that. Um, but it's, it, it became much broader now and includes deserialization for sure, but also other things.
Um, and in a way, this topic also touches back on vulnerable components except here to. Uh, it's not that we are running outdated components, but the problem becomes the source where we're getting these components from. Um, so if we're [00:01:00] not making sure that we are getting our software and dependencies for our projects from a trusted sources and that we are not verifying packages that are coming over using, you know, some techniques such as like digital signature checking or like hash digest checking and things like that.
Um, then we might, you know, somebody might trick us into running some malicious code that will cause us problems. Um, so. Definitely check your packages when you're downloading them. Um, ideally of course, in an automatic fashion also like when you're [00:02:00] adding new package repositories to your Composer or NPM or whatever else you're using verified repositories that you're having are trusted.
So don't just find a blog post that explains how to do something. And it gives you a link to a repository and say, Hey, download, easily download all these packages from, from this repository. Um, could it be that some of these trying to trick you into running something that's malicious? Um, and these actually happened quite a lot In the Bitcoin world.
Um, so in Bitcoin you have these applications called wallets that are basically storing your private keys and controlling your coins through that. [00:03:00] And there has been numerous reports when people created fake websites for some of the more known wallets. Usually the, the problem were desktop wallets because when you are on iOS or Android to usually get stuff from the app store, but even there, you have to be careful what you're doing while when you're installing things on, on your desktop computer, you usually go and download something from the internet.
And what attackers tried to do was they, they hacked, the one of those wallets, which were usually open source project, so they can get code for it and just injected some malicious code that either stole your keys and send them to the attacker or directly stole your money. And then they created a website.
And if you are not careful, you downloaded, like this malicious version [00:04:00] of the wallet. Um, and as soon as you imported your private keys into this app your money was gone. So really bad outcome. Um, and yeah, it's not just like, this is just one example, but one other example would be firmwares for uh, like home and office routers or other IOT devices. Um, I'm pretty sure that every one of us was at least tempted to download a firmware from not necessarily trusted source because it's supposedly included some other feature that we really, really needed at that point. Um, and if there is a malicious code in such firmware you as a key exposed your internal network to [00:05:00] somebody else and somebody else can control what you do after you've done that.
So be really careful what you're installing and where you're getting your software from in terms of developing our projects Peer review process is something that is really useful here and I'm repeating myself again. I know, but if we have multiple sets of eyes looking at changes then we have much higher probability that somebody will, you know, think about it maybe in a slightly different way and say, Hey, this sounds weird.
Maybe we should look more thoroughly into it and figure out if we should really include this in our project or not. [00:06:00] Um, so another, another area where strong culture and strictly defined development workflow and proper peer review process can really help us a lot.
Um, yeah, so this is one, one area in this category is software that we're downloading and using, but then we also have the data integrity part which most commonly is, you know, about checking the data that comes from untrusted sources or from our users or third party services. And especially problematic is data that is serialized in formats that [00:07:00] potentially allow attackers to execute third party code. That's really bad.
And one example in PHP is the unserialized/serialized functions. Um, and even if we check the API for the unserialized function, we have this really fat, bad warning that this should never be used for untrusted user input because unserialized will execute codes when it unserializes something.
And if we are trying to unserialize data that came from an untrusted source, we are exposing ourselves to, ourselves to remote code execution. Um, well, [00:08:00] obvious recommendation would be, try not to use these functions if you don't really need them, like, if it's just about the data you can use JSON encoding and decoding.
Um, or if you are serializing things to store them into cache, maybe you don't need to serialize the entire object. Maybe you just need to pick a few values from that object and store them in your caches in a key value fashion. Um, it's maybe slightly less developer friendly because you don't just throw serialized data into a function.
You know, everything is back as it was in some clear previous point in time. Um, but it's much more secure [00:09:00] and it also consumes less less space, less memory. Um, so there's also the benefit of that. And related to this serialization issue there was even a very interesting security advisory.
I think it was even, it was highly critical or critical, highly critical the, which was about the REST module in Drupal 8. And basically if you formed the payload of the requests in the correct way Drupal would unserialize that data that you injected and execute the code. So That's why it was highly critical, because as soon as you had, basically, as soon as you had the REST module enabled, [00:10:00] um, it let attackers basically execute any code on your, on your Drupal installation.
And that's obviously not good. Um, and I will, I will share this article with you cause it's really interesting read. Um, so here's described like they, they have some tool that has a database of serialized data payloads that can be used for exploits and they generate one and embed it into requests like this.
And the code that is injected here is basically running a system command line command that gives you the ID of the current user. And when they send this request to the server, Drupal responded with the output of that command, which basically proves that command was run. And not only that, [00:11:00] even the output was sent back and if an attacker can do that, they can basically do whatever they want.
Um, so this clearly shows why unserialized in PHP can be problematic even more interesting security problem that this one is a little bit older is from 2017. Um, and it's for Drupal 7 and the services module, module there. Um, And the way this module worked is by default it allowed multiple content types and like it, it supported XML and JSON, like we usually do but then, it also accepted this application [00:12:00] vnd.PHP.Serialized data format, which I have to admit until reading this article, I wasn't even aware that it existed, but the, the, the, the whole point was that instead of like sending JSON payload to services module, you could use PHP serialized payload, and post it to the server. And yeah, since we already know that we should never unserialize uh, untrusted user input, that is obviously a really bad idea.
And this article describes how this can be exploited. And there is even a script at the end of the document that you can run and basically execute this exploit. Um, I checked the diff and they basically solved that by removing [00:13:00] support for this type of payloads in the services module. Um, but it's, it's really interesting read to see how easy it is to exploit such problems.
So bottom line, try not to use anything that executes code when it serializes or unserializes any, any data and good practices also not to store sensitive data on on user's computer and like cookies or local storage or anything like that. Um, and, but even if you do, because I've seen some frameworks that do store sensitive data in cookies, then encrypt those things, [00:14:00] uh, so users cannot manipulate and try to use that for exploits.
And if the data is not sensitive, but you are aligned with some data that you send to the user and then it's coming back, use hashes or digital signatures to verify that the data didn't change and protect yourself like that.
Another important thing that I have to mention when it comes to serialized data is caches. Um, for mostly, if you let the attacker access your cache servers, like memcache REDIS they will probably find a way to, to control [00:15:00] your site. Um, cause. If you have access to caches, you have access to, to data that the site is operating with.
Um, and potentially even, you know, have some code that could be executed through unserialized or some other mechanisms. So protecting caches is really important. Um, I mean it's easy, easily forgotten but you know, something that we should really pay attention to. And another reason why a lot of people don't choose to run their own servers themselves, but outsource this to, to third-party providers, [00:16:00] which have to be skilled and trustful third party providers.
Um, that's also an important aspect.