Louis Nyffenegger - Those Who Don’t Learn from CVEs Are Doomed to Rediscover Them

Sorry, still keep talking for a minute. We'll give it a minute.

things off. >> Just check with dolls on the sound check. >> We're looking good. Live streaming to at least a dozen people, which is always good. I feel very nervous in front of such a large audience. Uh thank you very much. Um for those that have come in and just doing today and registered, appreciate your support. Thank you very much. Um today's day two, the last day. Uh we'll finish a little earlier today, but we've got a heap of really awesome talks and stuff lined up, which is good. Um housekeeping side of things. So for those that are new on, for those that were here yesterday, you've heard it already. Red shirts are your friends.

So, if you need some support from anybody for anything, just find somebody in a red shirt, give us a tap on the shoulder and we will help. Unless it's for the physical CTF and you're trying to find the access cards that we've got hidden around, in which case we'll be deliberately obstructive and painful and make it difficult for you. Good luck. Um, emergency evacuation, you'll hear the the whoop whoops uh on everything. We'll give you the nudges. Evacuation is out onto the grass area outside, but just be super calm. These buildings don't go up uh in a couple of seconds. Just um take your time, follow the crowds, head outside, stay safe. Um bathrooms and breakout areas straight

outside. Hit a left down the stairs. There's bathrooms. Uh there are more accessible bathrooms down to the right hand side. There's a prayer room as well if you need it. Just down there to the side. Um thanks to Tess and Hannah. They are running the coffee truck and that for us. Free coffees today, free yesterday. It's pretty good coffee. Enjoy. Say thank you. Uh lunch again. We'll be hitting Mac Daddy's for the pizza today. Similar kind of timing. I think for those that were here for the last conference and there was a bit of a gap between the one and the two. It seemed a lot better yesterday. All Yeah, it's really good. It's awesome

pizza. Um, thank you. It's really easy to get this place in an enormous mess when things like the pizza come out. We will never again do the crispy cream sugary glazed donuts as we did before. That was a an unexpected cleaning cost afterwards. uh getting glazed sugar out of the floor, but um yeah, that um we won't do that. Pizza was great. Everyone left it super tidy. Boxes were all in the skips. The bins were all full. Everybody was massively respectful and we're grateful cuz we have to do the cleaning up. Nobody else. So, appreciate that. Um schedule is online. If you want to see that, head to the Bides Perth website, hit the three hamburger bars at

the top, go to schedule, go to the Prattlex kind of link, and you'll get everything. Um, it's up on this screen here if anyone's not seen it. Um, massive thanks to our sponsors. Besides Perth has always been really transparent in sharing its financials at the end. So, when we do the close later on, you'll see just how close we were running this year's conference. Um, if it wasn't for our awesome sponsors, it wouldn't happen or it may happen, but in a much more cut down form where you wouldn't get things like lunches, coffees, those kind of bits. For anyone that's ever been based out here, it is super difficult to walk anywhere and get food or drinks or anything else. You're

kind of a little bit isolated. So, the fact that we can put this stuff on and keep you as a captive audience is amazing. And we thank the people uh UWA, our venue sponsor, uh they've helped us out for the six years that we've been running this massively. And they've probably got the biggest, most closed facility for us to be able to use with this lecture theater. the other one when we've run two tracks in the past and all the breakout rooms for people that just want to listen in on the live stream, do the CTFs, play with badges, those kind of things. Uh, Infosct, massive thank you to them. They got in early, helped us

out. That kind of funding early on from a silver sponsor, helps us do things like lock in the venue. For anybody that runs a conference, locking in the venue is the most important thing because then it's real and everybody else hangs off the back of that. If you've got a venue and it's paid for, it's happening. So, that's a massive step up for us. Uh, Horizon 3, go and have a chat to them. They've got a booth in the lobby. Say thank you. Um, you'll see just where all the funding that comes in from the sponsors goes when we share the financials later on. Uh, and Securo as well. They really helped us round things

out. Equally, they've got a brew. They've got people here from Bri from Melbourne that have come over. So, say hello and a thank you. Uh, and all the supporters. Um, I'll share the details later, but one of these came in a week ago, uh, and actually helped us, and that was the difference between being able to do the food and the coffees and all the other bits or not. So, say thank you. And if you see a red shirt, say thank you. Uh, all the volleys and ourselves are all totally unpaid. We do this for the love of kind of pulling everyone together, starting good conversations. Um, and it's the same crew. You'll recognize the same faces as

the most reliable red shirts that just rock up. Snades when you see him he's like Michael Boué comes out at Christmas only he comes out for Besides Perth and you never see him for the rest of the year but totally solid and we thank everybody that's up on this slide as well. Um the badge there's a lot of fun with the badge. So there are still component packs. We saved some by for people that only register on a Sunday. If you want to grab some components build your badge. The reason that we did it like this is you have a shiny little badge that doesn't scratch people because it hasn't got the components all stuck on it. There's always a lot of

talk about is it just unnecessary e-waste. So, we kept it kind of fairly slick. But equally, there are a lot of people that want to play around, learn soldering, learn coding, those kind of things. So, lots of badges, smaller number of component packs. If you want to build and hack the badge, do it. Uh all the source code is up there. We can do those things. Aside from that, um we will have prize winners and bits announced later. I'll go through all these slides because it's got the details on of um some of those winners. Say thanks to Tim that built the badge. Uh all the usual stuff. Aside from that, and seeing if I'm on time, I'm going to

hand over to our first speaker of today, Louie. Many of you will know Louie uh owns and runs Pentest Lab. Many of you will have uh used the kind of training, educational stuff that's on there and learned a heap of things. Lou has been a huge supporter of besides Perth since our very first one. Uh always kind of comes good and we really appreciate his support over the years. I'll introduce him to talk about those who don't learn from CVS are doomed to rediscover them. Louie, come set up.

Yeah. Go.

Yep.

[Music] >> Yeah. >> Thanks. >> Can you hear me? Okay. Yeah. Okay, cool. Um, good morning everyone. Thanks for waking up so early after last night. It may be hard for a few people, especially since we're going to talk about source code. But basically, so my name is Louie. I run this website, PentaLola, where I train people. And to train people, you want to have good content. And as part of finding good content, I need to look at a lot of CVS, a lot of CVs. And I call myself like a CV coner or a software entomologist or even like a CV archaeologist. I look I love looking at bugs. I don't know why. Just

like I found that very appealing and I've been doing that for a lot of times. It's kind of a weird hobby, but I'm gonna try today to convince you that it's a great thing to do if you want to learn new things. As part of that review of CVS, I came across recently VCV um CV 20254887, which is a missing AES GCM authentication tag validation in encrypted JWE. I know exactly what you're thinking right now. crypto on the first slide of the first talk of the second day. Yeah, let's see that payoff. I know it's hard. We're going to get there. It's only an hour. You you can go for it. So, when I saw that CV, I was

like, "Oh my god, this is amazing." For a few reason. I love JWT. Love JWT. I did a talk here about JWT, I think, five years ago, like pre-COVID. That's how much I like it. and I still love them. I love Ruby and that's a bug in a Ruby library. So, oh my god, that's amazing. And I kind of like crypto as a friend like not so yeah. So, so I'm going on an adventure. Uh if you don't know the reference, that's from Harry Potter. I saw your hat. So, yeah, I'm going to do the same joke in New Zealand. I'm going to get killed. So, GCM is this encryption mode that you can use to encrypt data. And if you

compare GCM to other modes like ECB, CBC, it's a lot better because GCM gives you encryption like all the other modes because you want to encrypt data, right? But the important thing is that GCM gives you authentication. Meaning that if you temper with the data, it's not going to get decrypted. So it's really really good because a lot of attacks you can do against uh crypto is around manipulating data and getting that data to still get decrypted. Even if you can't make sense of what is in the data, you can still temper with it in a way that will trigger unexpected behaviors. So let's look at GCM. So here we have all GCM and it's only boxes. You don't

have to understand the details. It's pretty boring. Yanak, I'm not a cryptographer. I'm just an enthusiast. And so if we add here uh IV, so the nouns, the thing to initialize the the encryption of the decryption, if we change that to vi because everyone loves vi and if they don't, they're wrong. If we do that, right, I'm glad we agree. Um uh if we do that, the decryption is going to fail. It's going to get rejected, right? because we tempered with part of the information that is used to feed GCM and that's where the authentication tag is so important. If we try to modify the cipher text and we change it to cite text again

it's going to get rejected because we tempered with part of the information. So the authentication tag is here to prevent that. Um, if we change the tag, the authentication tag at the bottom here, we change off to a a rejected because we tempered with some of the data used to do the decryption. But what if we change of type to just a approved? So it's not in all implementation, but some implementations have these issues. And so since we can just use one bite instead of the full authentication tag which is that is usually like 16 bytes nowadays um what we can do now with only one bite is try to modify the cipher text and go back to this cipher text.

It's going to get rejected because the authentication is only one bite but it's still there. So we keep going we move to uh what did we do? or we change instead of changing the cypex we change the off tag from A to D again it's get rejected but if we do that for long enough and we go for example with T we may get lucky and it's going to be approved and so we just need to brute force 256 uh combination and we're good and we can start modifying the encrypted data and trigger an expected behavior in the application I didn't know where to put the next slide but I think it's pretty good so and I came up with that idea so

signs of a stroke mouth but currently using I had to use it. Sorry. Um and if you ask uh for example uh GPD to write a bit of decryption in Ruby and to say like oh we want to use GCM they're just going to use the off tag as it is as it is. And the problem is that we have this GCM tag concretion it tag. So that's not in all languages. It's only in a few lucky ones. One of them being Ruby as we saw. So when you think Ruby and you're like a Ruby head like me, you find that you say like, "Oh my god, I know something that is using GCN. That's Ruby on Rails."

So I run run to the GitHub source code of Rubian Rails and I start looking at the code and as part of the code there is this little comment saying like okay um here we check the size of the tag because there is this issue that we know of and I've been doing Ruby for since 2005 I've been doing a bit of app say crypto and it didn't know about I didn't know about this anyone know about that actually no so I'm not the only person Uh yeah, so be there this message and like okay um we want to check the off tag size because otherwise people can reinforce it by just using one bite instead of the

full 16 bytes. So there's a link I clicked on the link and I go to an issue in Ruby/ OpenSSL because that Ruby is trusting OpenSSL and OpenSSL is only requiring is is trusting the off tag you give it. So if it's one bite we check one bite. If it's 16 bytes we check 16 bytes. And that's an issue that is open since 2016, which is not great if you're in software security. Oh, that's my opinion. Um, but thankfully, so that was in July. It's a bit small. Um, but in August, someone like uh in good decided like so since it's hard to fix that, but let's at least add some documentation. So they did that in August to say like, okay,

let's at least warm users, let's at least warm developers. Uh so they add that and that's the documentation of the OpenSSL cipher in Ruby and that's the documentation here. So that's how you need to read all the documentation all the time. So that's Ruby. Um PHP has exactly the same issue but at least it's a little bit uh better in terms of documentation is that you can see it pretty quickly. But same like in so in Ruby and in PHP your off tag if you provide one bite it's going to check one bite. So that's a good way to brute force things and to find like uh unexpected behavior in applications. Now we did Ruby, we did PHP. Let's move

to uh Node. Um Node had an issue about that in 2017 and it's closed now. So we good, right? And the thing with node is that at the time it was only checking four bytes. So a bit better than one bite but still four bytes instead of 16. Not great. So that issue is closed. So as a software developer, as a software security engineer, you expect that to be fixed. No, that issue has been reopened last year saying like okay uh we still at four bytes and that's not great. We should check like at least 12 or make it making it hard to brute force the values. So it exists in Ruby, PHP, node. So what can we do about that? So I took

my like white hat on. I put it on like white hat Louie. That's how I like to call myself when I do like good deeds. And I looked at other Ruby code bases and see if I can find the same thing. And I found one named Reforge where uh I contacted them like two three weeks ago and we got it fixed then. And that's something that is amazingly easy to do with AI nowadays with like LLMs. I asked um code or chip I don't remember which one but like give me that same code in other languages and LLMs are amazing at doing that. And I found the same issue in Erlang Elixir because Lua and Lua they didn't get back to me

but at least they updated the documentation. And then another thing I could have done but I didn't do is look at over encryption mode to see if I can find the same issue. But regardless um I worked on making the world a better place one codebase at the time. And that um issue really made me think about all those bugs that have been around for a long long time or have been around in some code bases and then they disappear and then come back. And I start looking at all these kind of bugs that like kind of happen then we forget and then they come back. And there are like a lot of examples of that. Uh we had HTTP proxy

that uh basically HTTP proxy is when you have uh CGI. So uh CGI is like a way to run application that people are not using for the past 10 years. But somehow that kind of bug reappeared and it was something that was pretty big in 2001 and then no one talked about it for like 10 years and then it came again in 2016 or 2015 and we have this cycle of like okay everyone is talking about it. Everyone is fixing it and then everyone forget about it and it comes back. The same thing happened with zip sleep. Uh you have like CV around like dot dot slash in zips. So you have like a zip

file as a copy and zip where we just have a zip that contains a file that is named dot dot dot dot/c and if we unzip that file with a vulnerable vulnerable application that's going to override potentially uh etc. So that was an issue in 2001 and no one talked about it until 2018 when like the sneak uh team like did like a a nice website which seems very dangerous and they rediscovered the issue and they're very public about like it's not a new thing but like they realized that it's not a new thing but everyone forgot about it and now it's back and if you look at a lot of code bases written in

Golang uh it's everywhere like everywhere in Golang. Um, another bug that was kind of the same way around this is um, uni code character in password reset. So if I have uh an email address lgithub.com with a nice I like g a nice i uh someone can use a reset password and instead of writing github.com they write github.com but they use a Turkish eye that doesn't have a dot and then when you do the string comparison with the database most of the time it's going to be string uh case insensitive. So it's going to get the email address, my email address loudub.com with a normal I like a classic I and that can allow them to

reset my password. So that was a thing in November 2018 in Django. Then uh no sorry in GitHub. Then someone reported the same issue in Django a month later. And nowadays you can find people like rediscovering the same bug that's in u uh node codebase named uh direct and again the same bug again. Um same thing with samol where we had um signature wrapping in 2005. A lot of people were talking about it like s is terrible. Um and then uh no one talked about it for a long time and in two in 2012 a lot of people start rediscovering the same bug and then no one talked about sel for a while and then in 2017

uh do some really good research around like injecting comments and then no one talked about it and 202 this year uh it's pretty crazy like some security is back on and the research they're doing is a mix of uh signature wrapping and the XML command from Joe. So we have like this cycle of like okay everyone talks about it everyone forget and then it's rediscovered. Um and the most interesting thing I saw about that is um this is a podcast critical thinking and this guy here uh with a be is uh Jim Kettle he does a lot of web research probably one of the most well-known web security researcher at the moment and he was talking about the exact same

phenomenon phenomenon like people are doing research everyone is talking about it at blackout conference it's crazy and then everyone forget and then the issue gets rediscovered again and I'm quoting him saying uh the best example of that uh this that I have is request smuggling so most of a lot of his research was around regress smuggling and basically he took a white paper from 2004 and I think he did that in 2012 or 20 like something like like 10 years ago maybe and he copy paste a payload from that white paper from 2004 run it again against Akami and own the hell out of Akamay by just using all research. And that's what he's explaining in that

podcast is like people forget about stuff and then they reimplement the same issue and if you like wait for long enough you can own a lot of people pretty easily because we have all this cycle of like oh my god it's vulnerable the world is on fire then everyone forget and people forget. So the security community forgets but also like all the developers forget. So because as a security community we don't talk about it anymore and then there's a rediscovery and we're back to the oh my god venerable. So that's why I think it's a really good reason to look at CVS and to talk about those. So let's see how we do that. Um the best

source of CVs nowadays um especially if you want to do that kind of fun work is a GitHub advisory database and they're publishing every day of the week. Um new CDs and the good thing about that is that you can pick your language. Uh you can pick your uh severity. Oh, I only want cool box. I want critical and high. You can also pick the CWE. So the root cause of the issue or I only want to look at uh critical directory traversal in Golang. You can filter by that and look at that and look at the source code. And I just picked one randomly. That was a authorization issue in uh go zero. Once

you've done that uh what you used to have to do is get clone the repository. Um, then look at all the tags to find the version you're looking for because you need to find the vulnerable and the fixed version. And then you do a bit of gig between the vulnerable and the fixed version. You keep going until you find something. And if you're lucky, you're going to find the bug and it's not going to be like 20,000 lines of code to review. It's just going to be like few lines. Uh, so that was what I used to do. It was a lot of fun. And nowadays uh GitHub ask people who uh report vulnerabilities and people who fix vulnerabilities to

link to the commit of the fix. And that's what we can see here in the second line. And this is amazing. As a security person, you have exactly what was changed. You don't need to search for hours. You don't need to spend like hours in the source code. You just like click that button, click it, and you got the result. quite success. Um, and so that's that's exactly like that's just picking one of the advisory in the list, finding that there is this button with a commit and clicking on that button and you see that and um and that's yeah just like okay people fixing a bug. So we can see what the old version of the code looks like and we

can see what's the new version of the code look like. Very very easy. So what they were doing is they wanted to allow an origin. So uh trust like a domain or host name and all subdomains and that's what they wanted to do and that's what they meant to do. What they actually did is they allowed uh host name ending with the origin because they didn't have the dot before the allow. So basically if you want to protect pentestella if you were allowing pentestella.com you were also allowing hacked by pentestella.com or whatever the hell you want pentestella.com. Once you've done that a really good advice is to document uh what you found because this way you can quickly look at

it in the future uh because like memory is something that goes away pretty quickly nowadays at least for me. And so you can document that and keep the version of the code before and after. And this way you have references if people ask you about like oh what's the common issue with uh Golang and you can come back to that and that's something I do um I would say on a daily basis at the moment and because you learn so much you learn so so much you learn about traps things that are misleading things that developer will not understand properly and you can see as well since you have a lot of uh CVS you can really see like

okay what are the common mistake they're going to Like for example in uh Golang if you love Golang there's a function named path.cle clean which developer think will prevent directory traversal. It does not prevent directory traversal. It clean uh as in it uh normalize the path. It so if the path start with a slash it's going to remove the dot dot slash but if the path start with dot slash it's not going to remove it. And you can also find patterns. If you look at a lot of CDs you're going to identify patterns of like okay people tend to get that wrong all the time. And the last one is your like spiky sense is like the

more you look at that the more like your spiky sense will be tingling when you look at bad source code. Um so let's look at an example of trap. Uh we're going to talk about the best programming language in the world Ruby. Um yeah okay we all agree. So in Ruby you have 5.c/d debian version and you do read and that's going to read the content of etc debian version. You also have a shortcut named open and we do open SLC version read and we get exactly the same result. The thing is that that shortcut is not file.open, it's kernel.open. And if you do open and something that is user controlled, so fully user controlled, you can get the content of

any file on the file system. Woohoo. Which is obvious. It's used to open files, right? Um, now if you are old school and you remember your Pearl days, Pearl added something really cool around opening files and Ruby has the same thing. If the file name starts with a pipe, Ruby and Pearl are going to execute that as a command, not with file.open, but with open, it's they're going to do that. It's going to do that. So you go from like reading arbitrary files to code execution which is a pretty good win if you're attacking applications. Uh so that's the kind of traps you can come across. Another thing is patterns. You're going to see the

same people doing the same mistake again and again and again. And that's probably one of my favorite pattern is here we are uh Java developers loving life. um we do like okay we want to prevent people from uploading malicious files we want to prevent them I don't know if you can see my mouse we want to prevent them from uh uploading GSP or GSPF files because otherwise they may get code execution so we prevent that by making sure that the the file name doesn't end with JSP or SPF that's what we do here and we throw an exception dangerous extension so that's all filtering So maybe good enough, may not be good enough. We don't care. We're not going

to talk about that. But after that filtering, what we do is we modify the file name. And that's a common pattern you can see if you look at a fair bit of source code is this filter and modify. And when you look at that, your idea should be like, okay, can we bring back the what was filtered using the modification. So here the modification is removing all those bad characters hash um uh double quote semicolon square bracket whatever we want to remove all of those what we can do is what we can leverage that modification to reintroduce something that was filtered for example if we submit hack.jsp JSP with a hash that's going to bypass the

filter because it doesn't end with JSP. But then we go to the modification and the ash at the end will be removed and we go back to actor JSP. So that's a kind of neat trick you can learn. You can also find trends and that's really like that's one hour of writing Ruby of 5 minutes of chat GPT. um is you go through all the CBS that uh in one language and like okay give me extract from the JSON file the CWEB so what's the root cause and you can see over time what is happening and you can see okay if I have a Golang uh codebase what are the bugs that are the most

likely so probably XSS path traversal and denial of service so if you're like a code reviewer or if you're like a pentester you can say like okay I'm going to review a lot of golanging what should I spend my time on what is the most likely to like what's the most likely vulnerable vulnerability if you're like you have you're part of the blue team you can also write work around like strategy to make a go cutbase more secure because you can say like okay every time we have a goat base there's a directory traversal because it's very common what can we do about that and same thing if you want to scale security um you can also look at all the critical

code and the high because you can filter by severity and say like okay what are the most common severity in go and so this way you know like okay we don't care about all the vulnerabilities we want only to cover the the big one like the big impacts and here we have one uh new issue common injection that uh start appearing in 2025 in Golang any ADY MCP MCP server love to run commands. So we can see that in 2025 all of a sudden we have command injection coming to all list of vulnerability for no apparent reason until you think about uh MCPS. Um and you can also compare different code different languages. What is the

issue? What is the most likely issue in Golang? What is the most likely issue in uh Python? uh you need to be aware that there usually like a bit of a timeline between the uh time when people found the bug and the time you have access to the vulnerability. So you're like a bit behind and in the same way we have the serialization coming to Python in 2025 for no apparent reason. LLM love serialization of things. So you can see those trends that are really interesting. Since you are all convinced now that looking at CV is amazing. We're going to look at CVS. So this one is in a codebase name Juju um from Canonical. Canonical is like

Ubuntu simplify it. And um we're going to start with a bit of an introduction. Those are three ways to compute a SH sum. So a hash of a string hack the planet in Golang. And we're going to play uh spot the imposter. So we have method number one here where we get the data, we copy it and then we get the ash sum and then we print it. We have method number two where we do something that is a bit shorter, looks a lot nicer and we have method number three. So who thinks the imposter is number one? Who thinks the imposter is number two? Who thinks the imposter is number three? Ah nice. who doesn't care.

Thank you. Thanks for your honesty. So basically um it's number three. So if we run that code, the first two will return the hash of hack the planet which is really great. The num the third one not so much. And because um function sum and so if you go back to the code those three snippet looks a lot similar but when you run sum and you pass uh an array of by to the same function it's going to add that to the hash before like it's going to prepend that to the hash. So the last one the last hash is a bit longer because we have hack the planet in clear text followed by an empty hash ash of an

empty string. And you may think that's never gonna happen in real life, right? That's exactly why I'm here. So that's a CD from 2025. So very recent again 2025 6224 where um this codebase guju they are creating certificates with uh public private key and they like generating that using golang and as part of that they call this uh ED2551 line with generate key and that's giving us um uh public key that they ignoring here which is underscore then a private key that they name key and then an error they check the error blah blah blah blah and then they create uh a template to finally create the certificate. To create the template we call method number three, the one that

leaks uh the content of the of what we are trying to hash. And so basically this vinarity is nothing short of amazing is this code is generating certificate with the private key in clear text as part of the subject key ID of the certificate. Yeah like the thing you come across it's magical right and it gets better. It gets better. Wait wait wait. Um hopefully I'm not going out of time. And um this variety was introduced in 2024 in uh June by someone from Queensland. Classic Queenslander. No, no, no. I'm No, actually I like to joke about it, but um this person got very very unlucky. Like it's not normal that by using a function like code that

looks all right, they end up with something so bad. But yeah, and what they did at the time is they wanted to move from ED25519 to from RSA to ED25519. And they changed the code a little bit. Um, and they said like, okay, the generate key for E D2519 has a third argument, so we're going to ignore it. But that's a public key. And when we generate the hash, instead of using key N, which is public for RS, I use just key, but key is a private key. Um, so very unlucky. On top of that, uh, the subject key ID, so the field they used to put the private key, you don't need to do that anymore. That code is

not needed since, uh, Golang 1.5, which was, uh, which was released in 20 2020. So they wrote code for something and they introduced like a terrible bug, not their fault because they got very unlucky, but for code something they didn't have to do. And I think there's a good lesson to learn here. So first uh error proofing it shouldn't be that easy to get things wrong. Uh then when you do code review check ignore return values here they're ignoring the public key. So maybe they should have not ignore the public key and use it. uh the name of the variable matters. Like if you uh name something key and it's a public private key, it may bring surprises in the future. So

be aware of that. And um every time you change something, is this code still needed? That's probably something we don't do um as software developers and as security person is that we have code, we change it, but maybe it's not needed anymore. And removing code is a lot more important than updating code. The less code, the less program. Um, another bug I really like and that's the first vulnerability I publicly wrote about in 2018. Um, it's a flow in WordPress. WordPress is a blogging system and they allow people to login using that uh function WP validate cookie and that's a lot of PHP. They get the cookie then uh they split it in three parts based on a pi

characters then they get uh the username uh an expiry time and a signature and basically if you don't have the like GCM if you don't have the right signature you can't go through they check the expiry but it's not expired they check a lot of things then they check um they compute like a hash on their side and then they compare the hash they have on their side with the hash from the client and if they are the same you're locked And if they are not the same, you're a bad hacker. You don't get logged in. And uh this bug is nothing short of amazing. So that's what a lookie a cookie will look like. If you are admin,

you got admin, pipe, expiry, pipe, and your signature. And we're going to split that in three parts. And then we compute the HMAC with a secret. And we compute the secret of admin and the expiry. And all is good. Everything is working well. Now another user comes in. This user is logged in as admin one and we got a cookie where it's admin one the expiry and the signature. We can't forge the signature because we don't have the secret. But what we have is that the code will split in three parts. Admin one, the expiry and the signature. And we compute the hash or the hmach of admin one and the expiry. And that's where it gets really cool is

that if I'm logged in as admin one with that expiry and that signature, I can be a bit naughty and move the one from admin one to the expiry and then um the code is going to split in three parts. compute the hash of admin that new expiry and uh using the secret and then that's the hmark of admin one with that uh long expiry. So the one we had initially is exactly the same as the one of admin with that longer expiry because we have a collision between two value and that's yeah at the time that blew my mind and now they fix that they just added a pie because uh what the problem was that

there was no uh separator between the username and the expiry and um lesson learned and I think it's important to do that every time you look at the CV is like okay always always include like an expire hurry when you sign something because you don't want to sign something that is valid forever. Always use a separator between value when signing and also as an attacker uh people tend to think that if something is signed is temperroof because they don't know how to break the crypto. Um you can break crypto without knowing anything about crypto. Trust me. And yeah, another one uh PlayStation injection that was found in uh 2013 uh officially by the National Australia

Bank Nab and officially by me and basically they have a session management that looks a lot like Rubian Rails where they are again signed session and I'm 500% sure I wouldn't have found this bug if I didn't study the one who we just saw in WordPress and basically what they do is um so for the story I was like reviewing like five different implementation of session in Java as you do and um it's really good like if you're not good at something don't look at one codebase look at five code bases and compare them play spot the difference so much easier and that's a code that is used to pass the session so basically um you give uh no that's a

code that is used to generate the session so you have the session in memory and you want to create a cookie. So what they do is they basically concatenate a null bite key a column value null bite and they keep doing that for every key value in the uh that's a hashmap and basically if you're a code reviewer you think of you look at that and okay they are reinventing a serializer if you want to do that you use JSON you use YAML even if like even use XML what's better than that uh don't record my oh that's recording you here. And what is happening is that we have key value key one value one key

value one and we end up with key null by key1 value one null bite null bite key2 value two and uh if it's Louis and.com we end up with something that is very similar. Now we look at the other way around. When we go from that cookie, that big string with all the null by that is very ugly and we go from that to a session in memory. We have this weird uh regular expression and then we loop through all the elements that uh we get when we match with that weird regular expression. Sorry, I'm pretty low on time. Um and what is interesting is that um if we look at what is happening we get

again this way the other way around. So it's a cookie with null bite key one value one null bite null bite key2 value two null bite that's going to go that's going to be splitted by the regular expression and then we end up with session.put put key one value one and session out.put key2 value two everything is fine. Um and now I keep dig looking and I look at the put function and that put function that is going to be used to add your um value based on the key. Um what they do and that's what gave away the bug at the time for me is that they check that the key doesn't contain a colon because

probably something broke or something like that and there to prevent uh that colon from happening. as part of the key. So they add a filter for that. Uh but they don't have any filter on the uh value. So as an attacker, you can potentially inject a null bite or a colon. And as an attacker, you probably have control over the value, not the key. So again, uh we are like nice person. We're going to login as Louie because Louie is a nice person. It's going to you have to trust me on that. Uh, it's going to end up with session.put username Louie. Okay, we're good. And we have a cookie with null bite username colon Louis null bite. Then we not so

nice. We're a bit naughty. We set our username to Louis null by nullbyte username col admin. That's going to do session.put username and that weird username. I don't know what's going to happen. And then we get a cookie with that uh weird username and that hole that is happening right now with just this weird user with this weird username. But then we reload the page and the application the framework needs to pass our session and that's where the magic happens. It's going to split based on the null bite and the semicolon as a column. It's going to be username Louie not bite and it's going to do session.put username Louie. And then we got it's going to

loop one more time because we have more in the session and it's going to do username admin and do session.put username admin and it's going to override the previous version the previous value and we're going to be logged in as admin even if we didn't have admin privileges or anything. And the really interesting thing is that that looks a lot that like the previous bug we saw like around like okay we need to have a separator. what is happening if we don't have a separator or we have a separator. What if is happening um if we can inject a separator? So, and if you keep doing that over time, you're going to build that knowledge and you're going to know

exactly what to look for. You may say, but those are lucky pigs. So, I looked at the bug. Admittedly, yesterday was a pretty good day for CV, like a really good day. Um, so I looked at the a few like CVS yesterday as I usually do and I came across like a few bugs that were interesting. So one of them was an application uh a shopping application where when you purchase something they log you in and their goal was to make it easier for the customer. You buy something and you logged in with the email that is used in the receipt you ask for. Right? What end up happening is that when they log you in, they either

create a new account or look up the account in the database. So as an attacker, I buy something for five bucks. I put the email address of an admin of the application or anyone else and I'm logged in into the account like that's pretty good fun. Um this one is absolutely amazing. Maybe a bit small. That's in PHP and basically um and that's from yes uh no not yesterday Friday they have a list of bag value you can't use those value too dangerous don't use them and to make sure that uh you don't do that they look up the value you provide and they look up that uh into that list of bad values bad bad and if it's in the list they

throw an exception and that's the change they introduce to fix that issue So the vulnerable code is array search and the fixed code is in array. So what and it's always important to ask yourself like what did the developer meant and what actually happened and so what they meant is like okay if it's if the item is in the denied list we throw an exception what um but what happens is that array search return false if the item is not in the list otherwise it returns the index of the item. Uh, in PHP array indexes start at zero and people are saying where it's going. Um, it's good. Hey, so PHP treat zero as false. So the first item in the list is

not blocked because it's if zero throw an exception. So it's not blocked. I find like I may be a nerd, but that's beautiful for me. Like that's amazing. Um, yeah. And so that's why Ruby is the best language in the world because Ruby object uh zero in Ruby is an object and zero is true in Ruby because we thought about that. Take that Python and PHP. Um you also find some good fun. So that was not Friday but this week. Uh so that's code written by an LLM in 2024 and someone reported a bug. And that's like the yolo of writing source code. Like basically when you want to pass JSON, people usually use a library like JSON.load or

whatever and could have security issues, but like and this code that was I think written by an LLM just do eval. So basically that's yeah at source code and if it's JSON it's going to work. It's going to create a hash table like properly in Python. But yeah, that's very very dangerous. So you can find like good stuff like that. You can also find incomplete fixes from time to time. You're going to be lucky and you can even create good memes. So if you were like born in the '9s, that's an amazing joke. If you're born in the 20 something, it's going to be not as fun. But yeah, no one knows who exhibit is anymore. Um

anyway, so you can find like incomplete fixes like I usually find like a handful per year. Uh so that's one where uh they actually decided to not fix it. Um they had an issue where people could bypass their directory traversal uh prevention using encoding and replacing dot dot with person two. So this way you bypass the check on dot dot because you encoded the value. So what they decided is to decode the value once. So they actually block dot dot to person 2 person 2 e because now it gets decoded at dot dot but they are overwriting the same value. So what you just need to do is instead of sending person 2 person 2 you send

person 25 to person 25 to e which is just dot dot and code it twice and verix decodes it once and then the rest of the application decod it once as well. Uh I found another one this year where uh they add like uh basically as an attacker you can add uh you can purchase it's like a shopping application and you can you get a token that you can use when you purchase something and you can reuse that token again and again and again and again and again. So they fixed it by adding like adding like uh uh first they look up for the uh token and then they update the token. So what they actually did is they

didn't fix the bug. They just make it it harder or the windows of opportunity to exploit it to exploit the race condition is a lot smaller but it's still there. Um so I got them to patch it. I don't think they get issue a CV for that one but yeah so that's what the code to fix it looks like if you're very curious. Uh so they use one single query. So that's a lot of bad bad source code. Um, CV, looking at CV is really good because you're going to learn a lot, but don't just look at bad code. Um, and uh, I know a lot of people who try to get into code review and they're like really

unhappy when they look at source code for like a week, two weeks, two months, and they're like, I didn't find anything. I'm wasting my time. What am I doing with my life? And a few of them in the room apparently. So, um, and, um, I think it's really important to look at good code and be aware that when you're doing that, even if you don't find bugs, you're not wasting your time. Look at it as, um, building a baseline, um, accelerating future review. The more you look at good and bad code, the better you're going to be long term. You're going to get really good at spotting not necessarily vulnerabilities, but things that are unusual because you looked at a lot of

good source code. And what I did recently probably last year is um instead of trying to find JWT algorithm confusion attacks vulnerabilities I decided to let's look at how people prevent that issue which is basically exactly the same question but just a bit like swapped around and fancy way to trick my brain like if you look at for vulnerabilities in J libraries it's likely that you're not going to find a lot of them but if you goal is to say like let's see how people prevent those attacks. You're learning a lot and you may find some bugs and I think I found two. Yeah, I found two uh one in Scala and one in C. It was a pretty good but the thing is

that you're getting a lot better as a code reviewer and you're getting a lot better at as well quickly being able to triage those code as in we need to look into that. That's no way it's vnerable or that's totally vulnerable. So you get better over time if you keep doing that as well. So don't only look at bad code, look at good code. And if you do that, don't think of it as I didn't find a bug. I wasted my time. Everything you like time spending spent looking at source code is never wasted as a security person. really really um in the same way um a lot of people for like uh people who try to break into

like security uh or get into offensive security people recommend like oh get a CV get a CV uh it's really cool get a CV and it's good to have a CV I totally agree like if you're new and you want to break into offensive security getting a CV is really good but um it shows like to an employer that you can find vulnerabilities uh you can understand how they occur um you can explain the vulnerability Maybe you even look at the source code. Uh maybe you can talk about how we fixed it. Uh maybe you can add the CV to your name on LinkedIn. I'm not judging. I am totally judging. But it's uh the problem is that it's

hard. It's hard to find new bugs. Or what you're going to do is you're going to lie to yourself. You're going to look at shitty codebase and find easy bugs because your goal is to not find cool bugs or learn. Your goal is to just find a CV. So let's pick the weakest codebase you can find on the internet and find a CV in it. That's not how you learn and it can be very boring and it's timeconuming and the real problem is that that's a game of luck and you may get super lucky. Good on you but you may get super unlucky and you feel like you're wasting your time. What I recommend nowadays to people is instead

of looking for a CV, analyze CVs. Look at those and you're going to learn a lot of things. do writeups and that shows to an employer that you can understand how vulnerabilities occur, how they get fixed. Uh you can talk about the fixes, you can talk about a lot of things and it's a lot easier, a lot less stressful. It doesn't rely on luck at all because the bugs are already there. It just relies on the time and the energy you're going to spend understanding the issue and you and you're going to learn a lot and you're going to get a lot better at spotting uh issues in the future. So try if you're looking for a job in offensive

security, try to do that. Uh it's probably a little a lot easier and a lot more deterministic than just looking for a CVE. Conclusion, I told you we can do it. Um so we look at CVES, hackers, they look for impact, exploit vulnerable versions. Web developers, they look for impact vulnerable versions. Do we have to patch that? That's basically the idea. Uh the business. The business. Uh I'm not mocking people. It's a business, but I find I find weird that we call something the business. It's like the name is weird. Um it can impact and how much it's going to cost to fix the issue. Um but not a lot of people are looking at the source code. Uh if you're lucky,

one researcher look at the source code because they did a code review instead of just like blackbox test. So that's one person. The maintener looked at the issue. Maybe it's not a security. He doesn't have a security background or she doesn't have a security background. So, we don't know. But they didn't really maybe not fully understand what is happening. And like a few nerves are looking at the diff. That's about it. And we we're losing so much important knowledge because of that. Um and the same thing is like looking for the exploit versus looking at the exploit. very important like try to like try to keep learning learning learning learning learning to get better. I can summarize that in one

uh slide. Read code receive bug. Uh the more code you're going to be reading the better you're going to be. And every vulnerability is a lesson. Um like time wise. Yeah. Good. I'm good. Oh, good. Like I was making fun of the person from Queensland. Uh but like we shouldn't look at venerity like something that is shameful. We should look at that as lessons. Uh I got a friend who is really good at social engineering and he did like a social engineering gig one time and like one of the manager was like oh this person got done we should fire them. He was like, "No, this person is the most valuable person in your team

now." Because they know exactly how they got compromised, what mistake they made. And it's the same thing for vulnerabilities. When people create vulnerabilities, there's this sense of shame. They're bad developers. They don't know what they're doing. Sometimes it's true, but no, but like it should be like, okay, let's learn from that mistake. Let's not blame people. Let's not put shame on. Let's say like, okay, is there something we can learn? Is there something we can do better? Is there like um why this function is named path.clean where when it's not preventing directory reversal? That's weird. Why there is a function in go that has like uh sh and like copies the value? That's something that people

will get wrong. What can we learn from that? And what how can we make apps sec a lot easier for everyone. Um so celebrate finding and fixing bugs and look at a lot of CV because it's a lot of fun. It's not that nerdy I promise. Thanks for your time and if you have any question please don't hesitate

[Applause] any question otherwise I'm going to be around uh yeah no so you everyone is going to look at CVS I'm taking it but the vibe Yeah, now that really like it's I think it's really something like we got all that knowledge right now is really well and easy to access well exposed by GitHub and really easy to access and just like instead of going on Tik Tok Tik Tok once a week once a day or once a week just pick one of those CVs and just like just do that once a week once a month and I promise over time you're not going to eat gold all the time but you're going to learn over

time at least more than on Tik Tok. I can promise that. I swear. Otherwise, thanks for having me and yeah, I'm gonna be around. >> Thank you so much. No worries.