Wade King on CBC Padding Oracles

[Music] Hi, I'm Steve, volunteer director at large with the Vancouver Island Security Research Society. Besides, Vancouver Island is just around the corner. And if you haven't secured your tickets yet, now's the time. Don't miss your chance to be part of one of the most anticipated infosc events on the island. This is your last big chance. On October 3rd, Besides Vancouver Island is taking over the Victoria Conference Center, and it's going to be huge. We're talking worldclass talks and the kind of passionate networking that only happens at a grassroots event like this. Now, here's the deal. We sell out every single year and we're really close to capacity. Once those tickets are gone, that's it. No extra seats, no late

entry, no standing room. So, if you're thinking about coming, don't wait. You do not want to be the person watching everyone's highlight reels after missing the event of the year. Today, I'm proud to spotlight Wade King's Talk CBC Patty Moles in 2025. WDE's research is shaking up how we think about encryption. If you build, defend, or rely on secure systems, this session is a wake-up call and it's only happening at Bides VI. This is eyeopening research for anyone developing or defending secure applications. WDE, I'd love to invite you to introduce yourself to our Besides Vancouver Island community and share a little about your journey in cyber security. What drew you to research encryption vulnerabilities and why the

risks around CBC padding oracles matter so much in 2025? >> Sure thing. So I started this journey about a year ago kind of thinking that CBC was mostly dead, wasn't really used too often. Padding articles were something a little bit more archaic. And then when I was working on a bug bounty for a gumb gambling platform, I discovered that the password reset token was vulnerable to padding oracle and I was able to use it for account takeover. And then later in my own work, I discovered another padding oracle vulnerability in a token that allowed me for another account takeover. And then I found it again in another different client that uh was in the session

cookies. So through my work, I've sort started to realize that CBC is in a lot more places than we expect. And it can cause quite a lot of issues because developers sometimes expect that the plain text resulting from decrypting CDC is going to be trusted when in fact it can easily be manipulated. >> Thank you very much for sharing that eyeopening uh example. Going to be an interesting talk. Let's get things rolling. Uh I've prepared three questions to give our community uh a bit more of a glimpse into this talk. First, UBC encryption keeps appearing in developer toolkits and AI model suggestions. What do you see as the biggest danger of develop developers blindly adopting CDC without

understanding its potential vulnerabilities? >> It mostly comes down to what is trusted user input and what isn't. A lot of times when developers are using CBC CBC encryption, they assume wrongly that the resulting plain text can't be manipulated by an attacker. And using a padding oracle or simply just by modifying the cipher text, you can cause predictable outcomes in the resulting plain text which you can sometimes use to tamper with strings that are meant to be secure and you can sometimes use that to take over accounts or do all sorts of nefarious things. Thank you very much. Second question, your research includes a new method for extracting a padding article without causing a padding error.

How does this technique work in brief and what kinds of systems or situations are most at risk from this subtle attack? So, typically the way a padding oracle attack works is you need two different error messages. You need an a data error and you need a padding error. The padding error is something that's returned by the cryptographic library. And so what a lot of developers do when they have a padding error padding oracle that they're vulnerable to, they will often cause the error messages to be the same. So they'll put a little try catch block around it and they'll have output the same error message if it's a padding error or a data. The issue with this is

that what one person can do is it can put two CPC cipher text blocks tokens side by side. And if the backend server stops after parsing the first set of tokens that it expects and ignores everything else, you can actually turn any data error into any error into a padding error because you're operating on the unchecked version essentially. And so any error you can generate on that unchecked string will always be a padding error and you can use that to perform the classic padding oracle without an error. Finally, your abstract mentions uncovering the initialization vector and decrypting the first block when the IV is static and enough samples are present. Can you walk us through how

this attack unfolds in practice and what defenses modern orgs should consider to prevent it? So, this one is a bit more of a niche case. It's not entirely useful a lot of the time, but it can be very interesting, especially for gathering a little bit more information on what the first block contains. Because typically in a padding oracle attack, the intermediate block is what's combined with the previous cipher text or the initialization vector. And that's why when you're doing a padding oracle attack, you can reveal the plain text of anything except for the first block because that first block depends on the initialization vector which is hidden on the server. You do get the intermediate

block though and what you can do is you know that intermediate block combined with the initialization vector whatever it is must be plain text it must be some sort of asky characters or anything like that. So if you can restrict a range on what the output is supposed to be, you can build enough different initialization or intermediate block bytes in order to create a big list of of numbers that you can use to eliminate any guesses at initialization vector bite. So essentially when I'm going through the intermediate block bite by bite, I'm going to take the the bite from the intermediate block and I take a guess at what initialization vector could be and I'm going to look at the

resulting plain text. And if that plain text is outside of the allowed range, I know that's an invalid guess for the intermediate the initialization vector bite. And so what I'm going to do is I'm going to go through as many different intermediate block bytes as I can to eliminate as many guesses as I can for the initialization vector. And when I'm left with only one valid bite per initialization vector, then I know that's the valid initialization vector bite. And so I can use that to bite by bite discover the initialization vector as long as I have enough different um intermediate block bytes. It's a bit of a lengthy explanation that this is great to >> this is great and this is why people

need to come to BidesVI and see the PowerPoint that will be associated with this. Uh thank you very much for sharing that. That's great. So on that note, secure tickets right now at bsidesvi.com. Check out our full agenda packed with breakthrough content, experts, speakers, and real community buzz. And for those who love sharing, hit our socials. Find the links at besidesvi.com and use #besidesvi. This is your chance to join the island's most passionate infosc minds in person. Remember, we're almost sold out. Take 30 seconds, pause the video, and buy your tickets before someone else grabs your spot. Don't regret missing out. See you October 3rd at Bsides VI.