Episode 189 | OWASP Top 10 Part 4: Cryptographic Failures

Most cryptographic findings on your vulnerability report will never be exploited by a real attacker. So why do they keep showing up — and why should you still fix them?

In this episode of the Cyber Threat Perspective, Brad Causey and Jordan Natter break down OWASP Top 10 A04: Cryptographic Failures — the entry they openly call their least favorite on the list. They explain why SWEET32, BEAST, and the other scary-sounding named TLS vulnerabilities almost never translate into real-world compromise, why platforms like Security Scorecard and BitSight inflate their severity anyway, and where genuine cryptographic risk actually lives.

Jordan also walks through a real penetration test finding: a JSON Web Token signed with HS256, an exposed configuration backup sitting on the web server, and the signing secret that turned a standard user into an administrator.

In this episode:

- Why A04 dropped on the OWASP Top 10 without becoming less important
- The difference between exploitable risk, hygiene risk, and brand reputational risk
- An honest take on Security Scorecard and BitSight scores — what they measure, what they miss, and why a perfect score can coexist with a weak password policy and no MFA
- The two halves of A04: data in transit (TLS/HTTPS, integrity, tampering) and data at rest (secure storage of credentials, PII, and payment data)
- What a JWT actually is, and why pen testers love pulling them apart
- Real pen test story: exposed config backup → leaked JWT secret → signature tampering → privilege escalation to admin
- Broken server-side signature validation and other improperly implemented cryptography
- Why MD5 and SHA-1 still show up for password storage 20 years too late — and what to use instead (Argon2, scrypt, bcrypt)
- HSTS, secure renegotiation, and certificate expiration as A04 subcategories
- The coffee shop scenario: the full chain of conditions required to exploit SWEET32 — including roughly 250 GB of captured traffic — and why no one has ever documented it happening in the wild
- Why a decade-plus-old vulnerability in your environment says more about your vulnerability management program than about your crypto
- Quantum computing: how today's theoretical attacks may not stay theoretical

The takeaway: classify your data, choose modern algorithms, retire deprecated protocols, and keep a functioning vulnerability management program. Not because a threat actor is sitting in your local coffee shop waiting to derive your session key — but because leaving decade-old findings in place is a signal about everything else you might be missing.

Next up: OWASP A05, which Brad promises is way cooler than A04.

Blog: https://securit360.com/blog/
Podcast: https://securit360.buzzsprout.com/
YouTube: https://www.youtube.com/@SecurIT360
Contact: https://securit360.com/contact/

Have a topic you want us to cover? Send it our way.

Blog: https://offsec.blog/
Youtube: https://www.youtube.com/@cyberthreatpov
Twitter: https://x.com/cyberthreatpov

Follow Spencer on social ⬇
Spencer's Links: https://spenceralessi.com

Work with Us: https://securit360.com | Find vulnerabilities that matter, learn about how we do internal pentesting here.

Transcript

Jordan Natter: 0:03

Good morning, folks. Welcome back to the Cyber Threat Perspective. You have Brad Causey over here, and you have me, Jordan Natter. I'm doing the intro this time because I just wanted to throw you guys a curveball. So today we are back talking about the OWASP Top 10 for web apps. Right? We previously talked about AO three. Now we're going to talk about AO four. In this case, this is going to be cryptographic failures, right? In our opinion, it's a rather boring topic. So this might be a shorter episode, and we might be rehashing some topics you guys have previously heard us talk about. But there is good reason why we have to talk about this, right? So this has not only been a finding on the top 10 for many, many, many years, but it has also changed positions. The reason it's changed positions is not because it's no longer as exploitable, but because of the other topics are actually like being seen more, right, guys? So just want to keep that in mind while we're talking about this. So no, it's not less important, but it is lower on the top 10, right?

Brad Causey: 1:06

Yeah, no, totally agree. And so, one of the things I will say, and the reason that we don't love this thing so much, right, is the vast majority of the findings that fall into this category are not practically exploitable in the wild. So, do they create risk? Yes, but probably not in the way you think.

Jordan Natter: 1:27

Yes,

Brad Causey: 1:27

right. And we're going to talk about that in today's episode. But generally speaking, when we start talking about Sweet 32 and Beast and what are some of the other goofy ones? I can't. I can't remember all of them, but there are like 15 or 20 different specific, you know, named vulnerabilities that are out there, and most of them are kind of BS. If we're being honest, right? From from a from a realistic threat actor perspective, nobody's exploiting Sweet 32. No, right? So then, why do we even care?

Jordan Natter: 1:58

So in this case, we are specifically talking about it because it gives a hygiene risk or a brand brand brand reputational risk, right? So just having these, so granted, some of this would be exploitable, but the amount of effort you have to do to like actually exploit it is not typically worth it. But it is causing risk for you guys in a brand, in a brand reputational way, right?

Brad Causey: 2:24

Yeah, yeah, I agree. So, so two things, right? So you mentioned hygiene, you mentioned brand rep. To me, that those those things are almost one and the same, right? But we'll talk about them slightly separately. But but they they're both valid points, right? And so there are platforms that exist, Security Scorecard is one of them. BitSight is another one. And for those of you that are unfamiliar with those, they basically go out and try to score you on your security from the outside of your environment using super light touch testing. Right. So they're going to identify web components in your environment that are you know SSL 3.0 or TLS 1.0 or TLS 1.1. These are all depreciated protocols, and so you know again, are they exploited in the wild? No. However, does your score matter? Well, and that it could matter, right? It definitely could, and in most cases, it does to a degree or another. So again, if I am a let's I'm not uneducated is the wrong term, but maybe someone who who doesn't understand all the nuance associated with these things, I go look at a potential business partner on Security Scorecard, and they've got a you know 75 out of 100, and I go look at another potential business partner, and they got out 99 out of 100. Which one are you going to go with? And so

Jordan Natter: 3:48

99,

Brad Causey: 3:49

probably right. If this is an important thing to you, and and again, if you don't really understand how this stuff works, you know, it looks like they have poor, you know, security hygiene. It looks like that they have a lot of vulnerabilities, and in many cases that is not necessarily true. However, brand risk matters, right? Reputational risk matters, and so if your score is out there making you look bad, you could be losing business, right? People's people's opinion of of your organization may be skewed. Again, just to be completely transparent, the scores that are put out by these these these platforms are effectively meaningless. You know, they're they're finding the easiest stuff they can possibly find and artificially inflating the severity of it, so they're making you do work, right? And so they're just trying to be relevant. And so you know, we could debate the value of those all day, every day. You know, for me, it's less than zero because it's just creating unnecessary work for everyone. But it is something that exists, and we have to be aware of it. I would actually, if you don't mind me chiming in, no, I would

Jordan Natter: 4:51

look at the security scorecard as something like this, right? So, as a penetration tester, what we're doing is mostly manual testing, and we're actually like weeding out those. Positives, and then trying to take like vulnerabilities and exploit them further, right? Well, in this case, security scorecard is doing like the smallest amount, and like, and this isn't in a bad way that I'm explaining this, but they're doing like more or less the smallest amount of work that we are doing at the beginning because they're looking at that low hanging fruit. Well, that those low hanging fruit for them is tends to be the higher on their like scoring system, right? So what is really low to us that we're like, oh, it's trivial, it doesn't matter, like at least it doesn't matter in this case. They're like, oh my goodness, this is like make or break because they are using these things that are really old and they shouldn't be using these like algorithms anymore. Yeah, that that's how I would look at it, right? So to them, it's a really big deal because they can only look at the lower hanging fruit. For us, it's not a big deal because we're seeing the whole picture,

Brad Causey: 5:48

right? So, so yeah, beautifully explained, by the way. And I want to add to that just a little bit, right? So I can I can just arbitrarily go pick, and and we're turning this into a security scorecard like like abuse, you know, episode, and that's not what I meant to do. But let me explain why we feel the way that we do. Just, just one last thing, and then we'll move on to to to what some of these different vulnerabilities are. But, but yeah, so like for example, I can go arbitrarily take a a client or or an organization that has a perfect score in security scorecard, and then they have a terrible password policy and no MFA, and I will get into their environment and own everything inside their network in a day. Right? Do I care that they have Suite 32 on their web server? That's probably a brochure server anyway, like like just an informational website. Absolutely not. So they're looking at the things that don't matter. We're looking at things like that are material risk to an organization that a threat actor could take advantage of. Almost none of the findings that show up in Security Scorecard and Bidsight are meaningful in that they are creating true material risk for that organization. However, by the existence of the score, we're creating reputational risk, right? Now, I'm going to back up for just a second because we've said all the reasons why you should not pay attention to these things, and I do want to add one thing to this that you should pay attention to, and this is we call it hygiene, and this is just scanning and patching, vulnerability scanning, pen testing and patching, and just having a general, overall security program that keeps old vulnerabilities from surfacing in my environment, right? And so Suite 32, I think, came out in 2013, right? So it's a 16 year old vulnerability, and so why am I still seeing it in environments, right? Well, the reason that I'm seeing it is because you do not have proper hygiene, because you do not have a vulnerability management program, or your asset management and inventory is out of date, and you have systems out there that are not part of that program. Whichever way you want to look at it, I do not want a 16-year-old vulnerability in my environment. Does that make sense? Whether it's exploitable or not, I don't care. We're talking about hygiene at this point. Like, am I doing a good job as a security practitioner? And the answer is, if I have 16-year-old high-risk vulnerabilities in my environment, probably not, right?

Jordan Natter: 8:11

Well, that, in in my opinion, if I see that, I'm instantly wondering what else are they not keeping up with, right? Bingo. If it's

Brad Causey: 8:18

bingo, yes,

Jordan Natter: 8:19

especially for things that tend to be easier to fix, even if they are just those hygiene issues. Like if you're not fixing those, what else aren't you fixing? Especially if those are easy to fix. Like what big thing that's hard to fix that's even more vulnerable are you not fixing because of how old it

Brad Causey: 8:34

is? And that's actually that that's actually exactly why you could make the case that security scorecard and bitsight matter, right? Because if I've got a 75 score, which I mean, that's still passing, right? I guess so. Like that's a C, isn't it? Yeah. So like, if I have a 75 score, and and and security scorecard is able to find all these issues, then maybe I have other things going on that are pretty serious, right? So so again, I don't mean to be completely dismissive of the platforms. Maybe they provide value to somebody who, again, usually people who don't know how this stuff works are the people that are in security scorecard that are that care about those scores, and again, not not being dismissive of their opinion or anything like that. So, said all of that to say, the cryptographic failures of A 04 really focused in for the most part on two broad categories, right? Data in transit, which is where HTTPS comes into play, right? How secure is the information I'm sending back and forth across the network, and then the second half of that is is data stored, right? Storage of data securely, and so that comes down, and we're going to further break both of those down into two broad categories of of problems that we're solving. The first one is going to be the integrity of my data. All right, when I send it over the network, does it arrive at its destination without being modified, right? Or somewhat can. One in the middle tamper with my stuff. Okay, so so we're going to call that you know the transport security, which is literally what the T in TLS stands for. And so so yeah, so so the the movement of data securely, but then the storage of data securely so that it can't be read, right? And so if I'm sending sensitive information or storing sensitive information like credit card numbers, like like passwords, for example, in a database. Am I adequately protecting that information as it's being stored? And this goes into like all different kinds of subcategories, right? And we're going to talk about one of them. I think because you got a pretty cool story that we're going to dive into. In fact, we should probably dive into that and then dissect it afterwards. I think that would be a really good segue into, like, hey, let's tell you about some things that actually matter. You know what I mean?

Jordan Natter: 10:51

Is this the JWT one? Yeah, yeah, let's do that one. Yeah, yeah, if

Brad Causey: 10:54

you don't mind.

Jordan Natter: 10:55

All right, first, I'm going to let Brad talk about what a JWT is because he always likes to steal the thunder for that part. So, take it away, and then I will tell the story.

Brad Causey: 11:04

So, JSON Web Token JWT. If for for those of you that listen to the to the podcast on the regular, you've heard us talk about this many times. You know, we find them for the most part in these web applications and APIs, mobile apps, and they're generally they're almost like a more complex session token, and so you know at at its core, a JWT is comprised of you know it's JSON, right? Big surprise, and and inside of it's a base 64 encoded JSON key value pair structure, and so inside of it, though, we we are going to sign the body of that, and that's where the cryptographic stuff comes into play. But at the end of the day, JSON is basically just a way for the web server or the web service to identify who I am, and in some cases, what I'm allowed to do or not do. And there there are usually like timestamps in there, and there's all these different things, and and I've seen some JWTs. They're huge and full of like group memberships and access and permissions and all this crazy stuff. And so they are interesting, they are valuable, but we still have to protect them. And now it's back to you.

Jordan Natter: 12:15

Yes, and as you've heard from us many many times, we do talk about JWTs a lot because that happens to be a thing we commonly see and one thing that we actually, for whatever reason, enjoy. It's fun to take

Brad Causey: 12:28

it apart so we can do with it, right?

Jordan Natter: 12:29

Yes, yes. I mean, who doesn't like to decode a JWT? I'm just saying you can find you can find some interesting things. So, on that note, in this story, it has to do with JWT's magic. So in this case, I started off the pin test, right? I noticed they're using a JWT for authentication. Cool, nothing special about that, right? So I go ahead and decode the JWT. All right, it's still normal stuff, right? I see a user ID, I see an email, role, expiration. Nothing typically surprising, but pin tester brain is already like okay I see a role so that is telling me telling the web server what role my like user has permissions for right so in this case I'm that's pretty common yes yes nothing nothing inherently bad about that right this is all very typical right now so I'm like okay cool pin test your brain I see I have a role. Can I somehow make that role a higher privileged user? Right? Maybe I want to go from a user to an administrator. All right, cool, cool. All right. So what are they signing the token with? Well, in this case, they're using HS 256 again. Not inherently bad by itself. All right. That's totally fine. That's just a totally fine algorithm, right? But in this case, what we ended up having a weird component where we actually were able to get the JWT secret with from a configuration backup that was left exposed on the web server. That is where it becomes secret.

Brad Causey: 13:56

Okay. Yes. All right. That's jacked up, man.

Jordan Natter: 13:59

So now I can take that. Wow, it's my secret now. So now I have the secret, right? So now I can tamper with the signature, and that now gives me access to tamper with everything within the JWT. So now I can change what the user is and change it to administrator, then re-sign it and then send it off to the web server.

Brad Causey: 14:25

Yeah, absolutely. And and this story that you describe is not even that uncommon, right? Yeah. There are variations of that that I've seen in web apps where like the the mechanism on the web server side that's supposed to do the validation is just off. So like even though it's signed and I don't know what the key is, I can just tamper with it, and the server's like, "Yeah, Roger that, Sergeant, and it's just like kicking back whatever I ask for. So there's a lot of variance in there, but but but improperly implemented cryptography is really what we come at what we're coming down to, and that can take the form of like you describe loss of key. Right, and and this can be anything, right? Like, I mean, you know, compromising private keys on SSL and TLS and stuff like that. So, like, there there are some practical exploits that are relevant to A 04.

Jordan Natter: 15:15

Yes.

Brad Causey: 15:16

All right, cool. No, I love that. Absolutely love that. And one other thing I do want to mention really quick is for those of you that have been around the web dev world for a little while, and you're used to seeing passwords stored in MD five and SHA one format. We stopped doing that like 20 years ago, by the way. I still see it all the time. No, I mean maybe maybe I'm projecting. Okay, maybe I'm projecting a little bit, but but but what I'm getting at though is these libraries are still out there, right? And so I know you see it in the in the mobile world all the time, so much where where it's like you know non-random numbers being used for secrets. We see the use of MD5 and SHA for what should be encryption and or or even secure hashing. So there are better ways to do that. So there's a Argon 2s Crypt for password has like really good password hashes, and then you know I think it also and I'm going to step off the side for just a second when we start talking about TLS SSL, all of the headers that go with that right HSTS Secure renegotiation, expiration-all of those kind of fall into this session management category, which again are just kind of subcategories of A04. No, I love that. I think that's absolutely good. I'm trying to see if there's anything else in my notes that we want to hit on. Do you have anything else that you want to cover before I kind of wrap up? There's one thing I do want to mention before we wrap.

Jordan Natter: 16:47

I was thinking we talk about the kind of coffee shop incident where we talk about how difficult it is to actually exploit. Let's do that.

Brad Causey: 16:54

Yeah. Okay. So, so what Jordan's talking about here is is is another reason that we don't love a lot of these like Sweet 32 Beast, I wish I had the list in front of me because there's like there's a there's like 15 of them, right? But the point is like these name they sound super scary, you know. And then you go read about them, they're like, oh, dude, I can totally like steal all the data in your session if I'm in the man in the middle type scenario. So the reason that we don't love these cryptographic vulnerabilities in the context of things like TLS SSL is because the barrier for exploitation is so high, and so the the example that Jordan's talking about is let's say I want to steal your banking information, right? I've got to follow you to a coffee shop because doing it at your house is very difficult if you're you know using appropriately secured Wi-Fi or wired or whatever. So I'm going to have to find you on a unsecured wireless network. Be physically present at that location at the same time that you are, and you need to be doing something interacting with like an online banking system at the same time that I'm capturing traffic off the network, and it has to have a sufficiently vulnerable implementation of TLS, which would be like I think Suite 32 actually goes back to SSL 3.0 if I if I remember correctly, or maybe an early version of TLS like 1.0. But the moral of the story is is that I'm going to have to get there. And if you go, you can literally go to the Suite 32 website and read this for yourself. It's going to take like 250 gig of captured data for me to derive the key. For those of you who have never captured web traffic, like in a in in Wireshark or Burp, like there, it would take a week of constant communication with a system to generate 250 gig worth of data. Like it's absurd how much information that is. Not realistic.

Jordan Natter: 18:42

No, I'm sure you're not going to sit that long at a coffee shop.

Brad Causey: 18:45

No, and and to my knowledge, there have there's never been a documented instance of Suite 32 being exploited in the wild. It's never happened because that barrier is so high, and all these things need to take place. And again, like if if you're not going to unsecured Wi-Fi, it's almost impossible. Like I would have to compromise your ISP, or I would have to get on your online banking's network and their DMZ and somehow figure out how to capture traffic. And it's just like, I mean, if I'm going to do all that, I just want a password spray something. You know what I mean? Like it's easier. There's just so many better ways to go about accomplishing this, and that is the case for. And we see this on like SSH, for example, right? We see SSH all the time with with with old CBC ciphers, or we'll see like I mentioned before, TLS 1.0. Yeah, man, fix it, right? But is it something to burn the house down over? Are we really that worried about it? Not really. Most of these, you know, fall down to a much lower severity once you actually put them in context. So,

Jordan Natter: 19:44

and and that's why kind of at the beginning you heard us mention the fact that this is probably one of our least favorite in the top 10, and why we don't necessarily think that this is something you're to fret about other than the hygiene risks. It's because of like the security scorecard. Is they're taking that and they're. Oh, it's crazy! But in pen testing, brain, it's like I'd just much rather like steal your laptop or find another way to exploit something else, other than just doing sweet 30 to you because it's not worth the bang for its buck. If I said that analogy right?

Brad Causey: 20:15

Yep. No, you're absolutely right, and and there are just other things that are much more important than that, from my perspective. Now, one thing I do want to mention, just super quick, and that is in regard to what you should care about. From a, we talked a little bit about reputational risk. We talked a little bit about all those different things, but again, classify your data and just be smart about what you're using from an encryption algorithm perspective, or from a hashing algorithm perspective, and so you know that's going to be the biggest thing that you can do to prevent or protect yourself from having these in your environment. But at the end of the day, again, you know these things. Oh, that was the other thing I wanted. I was I was actually trying to buy time so I could remember the thing that I want to talk about quantum computing. All right, there is a reasonable possibility that in the future that these theoretical attacks are going to become realistic, right? So quantum computing is absolutely coming. In fact, you you might even be able to say it's already here, and so you know as we get more powerful computational capability, cracking things is going to become easier, right? I mean, we're we're cracking 24 plus character passwords at this point. You know what I mean? Using some pretty fancy shadow, you know, methods with hashcat and stuff like that, but take all of that and now go throw that on a quantum computer and see what you can do with it. Right now, I'm cracking 50 characters. I don't know, but the point that I'm getting at is, while it is true today that most of these are theoretical, most of the vulnerabilities that fall into a 04 a 04 are theoretical. They may not be in the future, so I would encourage you guys to you know, yeah. If you have 16-year-old versions of TLS and SSL, like maybe go upgrade that, right?

Unknown: 22:07

Just maybe.

Brad Causey: 22:08

Just maybe. All right, folks, that's all we have time for today. I hope you enjoyed this episode. We'll see you guys next week, and then we'll be doing A 05 soon, and it's going to be way cooler than A 04. So stay tuned.

Jordan Natter: 22:21

Yes.