Overview: Software and Data Integrity Failures

Number 8 of the OWASP top 10 in 2021, is software and data integrity failures. Our learning objectives are to describe software and data integrity failures, demonstrate how to test for these types of failures, and explain how to remediate software and data integrity failures. What are software and data integrity failures? This is a brand new category in 2021, newly introduced with some old friends, I guess you could say, that we saw in 2017, like insecure deserialization. We've added some new things in this year in 2021, specifically focused on supply chain issues. What do I mean by that? SolarWinds comes to mind, and that will be the focus of what the article is at the end of this lesson.

‍

But we're looking at software updates or packages, things that are coded without verifying the integrity of them. Now of course in the case of SolarWinds, this was a signed update, so people trusted it, but it brings to light the fact that we rely so much on third parties. We code using third-party libraries, we update our routers with firmware that maybe we don't know the source of the firmware, maybe someone's implanted some kind of malware in that firmware, and plug-ins like WordPress. Do we actually know what we're installing when we have a WordPress site? Do we inspect the code and make sure that it's safe? This is within the software deployment pipeline, are we analyzing everything that we're using? A lot of the time if we're in a large enterprise, we're not, just because there's so many things, for lack of a better word, to track.

‍

So many things are being updated, so many things that we can only trust so much, and if they're signed then we give them our trust. Sometimes we don't even see if they're signed or do any code review, and that's what introduces this failure. What are the factors here? There's 10 CWEs mapped to this category, you can see I put in pink that the average weighted impact is one of the highest. It's almost eight. The exploitability is also somewhat high at 6.94. You can see there's nearly 50,000 occurrences, and there's 1,152 CVEs mapped to these 10 CWEs. I encourage you to go to the link at the bottom for the OWASP site to see what all of this means in more detail, I should say. Let's go over the CWEs, you'll see insufficient verification of data of authenticity, missing support for integrity checks, untrusted search path, download of code without integrity checks.

‍

There's our friend, deserialization of untrusted data, again in 2017, I believe this was Number 8. Reliance on cookies without validation, integrity checking. We'll see a little bit more of that later in an example. Reliance on cookies without validation, integrity checking, and a security decision. Inclusion of functionality from untrusted control sphere, inclusion of web functionality from an untrusted source. You can see the word untrusted here a lot. You can see lack of validation here a lot, and properly controlled modification of dynamically determined object attributes. Again, if you want to check any of these out, they're all on the Miter website, for the CWE that you're looking for here, for a deeper dive. Recently there have been a number of attacks on our supply chain.

‍

Again, SolarWinds is a big one.But if you're in the bug bounty world, Alex Birsan should be a familiar name to you. If not, he is an interesting guy, he has found some very novel attacks. I've linked his medium article, it is a great read. Basically what he did is, a lot of enterprises are using NPM, which is a package manager much like pip for Python, or gem for Ruby, for Node, they use npm. He found through open source means companies that use these packages. Now companies typically use an internal package management system, something like Artifactory, but some also just blindly install things. Npm install, pip install, gem install, and they were installing it from the public library. Now the packages that existed in the private Artifactory packages privately, he would then take them over publicly in the public repos and perform code execution, and he did this with a great deal of success.

‍

Again, I highly recommend you read his article here. But he did this for some large corporations and found that they were incredibly vulnerable because a lot of developers just downloaded what they thought was the correct package, when in fact it was not the correct package. If an attacker can control these packages, again, they can perform attack. I took a look at something like this, and I was able to get a reverse shell simply by creating a public package that was poisoned or malicious, and was able to execute a reverse shell with that. An attacker that does take control of these packages and poisons them is able to do a whole bunch of malicious things. A reverse shell is just one example, download malware or crypto miners are other examples as well. Insecure deserialization. Now this could be a whole talk onto itself because it was it's own category back in 2017, when it was Number 8 in the OWASP top 10.

‍

Now I'm not a developer, I am a hacker and I will probably do, not the best job of explaining what insecure deserialization is, but when we're looking at serialization we're looking at an object. For example, let's say someone's entering their name, and address, and phone number, and that data is an object. All the data that pertains that person, maybe it's at a health insurance website, they're entering all their information. That serialized as an object, and developers want to take that information that the person enters and they want to save that to storage. You can see cookies are another example in this scenario too, from OWASP top 10 in 2017. Now it's put into a byte stream, and for some reason it makes me think of Willy Wonka and the Chocolate Factory, with Wonka vision where you get zapped and then you turn into little particles in the byte stream, and then you were made whole again.

‍

Although they make them small in Willy Wonka, but I guess more like a transporter in Star Trek, where you go from whole form, you're put into a byte stream, and your deserialized, and you are restructured back again into that object somewhere else. This is a type of injection attack. You'll see in this example here that is not an injection attack, it's a super cookie, and if an attacker is able to inject their own data into this serialized object here, they can basically perform privilege escalation, which is actually not this vulnerability per se.

‍

It reminds me more of our Number 1 category in OWASP, broken access control.The things you can do with insecure deserialization, I guess in addition to broken access control and escalating privileges, is remote code execution. An interesting attack back in 2017, when they made this Number 8, it was because of the community survey that they added this. It was not because of the data, the data didn't back it up. They felt like insecure deserialization, there was not enough data to back up having it in the top 10, it's just enough people had selected it in a survey, and that's why they included it in 2017. Now it's been lumped into Number 8, software and data integrity failures. How do we test for this? This is a really hard one to test for. In the case of SolarWinds, it is incredibly difficult to detect.

‍

In the case of deserialization, we have cheat sheets here, like OWASP pass for white and black box testing. Of course white box testing is probably better so you can actually analyze the code and see where deserialization or serialization comes into play. But as far as package management, that's really hard to test for. How do you know that? Unless you're doing some kind of code review. Again, maybe it's a WordPress plugin. Are you analyzing that code? In the case of Alex Birsan, or people like him, they're doing open source intelligence, they're seeing what types of packages companies may have internally, and they're registering them on the public repos, and poisoning them so that when a developer downloads at public package they perform some "malicious action".

‍

In the case of Alex Birsan, it wasn't malicious, it was just emulating an attack. But he was able to pull workstation information through DNS exfiltration, which is another really cool thing because most enterprises are not tracking the DNS protocol. They're not tracking for exfiltration via DNS, which they should be, because that's not even a novel technique, that's a very interesting technique that a lot places don't monitor for or don't properly mitigate that type of exfiltration attack. How do we prevent or remediate software and data integrity failures? Again, I'm sure you're using trusted libraries and dependencies. Verify the software is from expected sources, are you just downloading it from any website? Are you downloading from the proper website, whatever software you are downloading. Ensure there is a review process for code and configuration changes.

‍

Again, are you looking at that plugin for WordPress, or Joomla, or Drupal, are you ensuring that that plugin is a non-malicious plug-in, or that the code is in fact secure? For insecure deserialization, what you want to do to prevent that is ensure that unsigned or unencrypted serialized data is not sent to untrusted clients without some form of integrity check or digital signature to detect tampering or replay of the serialized data that was taken directly from that website down there, for our top 10, that is the guidance from OWASP. We'll get to actually see insecure deserialization, that will be in the lab. It's a pretty cool attack as a hacker. Again, I'm not a developer, so I would encourage you, I think PortSwigger does a great job of explaining insecure deserialization. They of course have their own labs that are pretty cool.

‍

But I think the next lab is pretty cool. It's not like the other labs where I make you figure out what the answer is, it's an open book test, but I want you to get familiar with insecure deserialization attacks and what they are. I will do a demo on that. I'll explain a little bit of that Burp Suite, and the different extensions that there are in Burp Suite. But in summary we've described basically what software and data integrity failures are, how to test, even though it's very hard in terms of package management and things like that, how to test for software and data integrity failures, and ways to remediate or prevent software and data integrity failures.