
okay so we're gonna get started with the next talk please welcome John Stickle and the name of his talk is vulnerabilities and modern cryptography give him a warm welcome thank you so it was my first presentation super nervous so sorry if my voice is stuttering all right so let's fit alright thank you thanks so yeah today I'm going to talk about vulnerabilities in modern-day crypto and how to exploit them so my name is John Stickle I'm a security researcher with coal fire labs mostly doing penetration testing and exploit dev so we're gonna start today with an overview of some commonly seen vulnerabilities on Penn test such as poodle heartbleed then we're gonna get into some more technical
attacks like stream cipher attacks side channel attacks and then then we're gonna move on to some developer flaws like apples go to fail and back doors that people for whatever reason decided a bug crypto great so we'll start off with saying that vulnerabilities in encryption or everywhere they're just appearing seemingly every day for a lot of different reasons a lot of people try to implement their own crypto a lot of times there's programming mistakes improper QA which we'll see in a minute and backdoors placed by different agencies or organizations so let's jump right in here and we'll talk about poodle so poodle was found in late 2014 I think it was it's a man-in-the-middle style attack
that allows for a tls/ssl downgrade followed by a padding Oracle attack which is pretty cool pretty cool the downgrades not too cool but padding Oracle attacks pretty cool so this is how the this is how the downgrade works all right so we have the client here the server there we're just chilling right here with a man in the middle and so when the client goes to establish a connection with the server it's like hey you speak TLS and then we say no we don't speak TLS we only speak SSL because the cell was vulnerable and then he's like really what about TLS 1.1 nope TLS 1.0 no and then finally the client gives in and
he's like all right let's speak in SSL 3.0 and that's great because now we can go ahead and perform a padding Oracle attack on it so in order to understand padding Oracle attacks let's first understand a little bit about padding so this this slides kind of weird but somewhat straightforward I hope so with the stream cyphers stream cipher encryption if if we go to encrypt one byte of data we get one byte of data out two bytes a day that we got two bytes of data out but with block ciphers which CBC mode encryption works in blocks if we go to encrypt one by today 2 we get 16 bytes out 2 bytes of data again 16
bytes out now the rest of the bytes that we get are padding and it's also the first example here if I wanted to encrypt crypt the character J we'll go ahead and do that and it's going to add 15 15 pads on there so our goal is to figure out what the value of the pads are because if we can figure out what the value of the pads are and an encrypted message then we can go ahead we have known plaintext and then we can go ahead and perform a known plaintext attack on it so how do we know what value these pads have well the what's it called PC KS seven states that the
padding value equals the number of pads left to fill so here we only encrypted a J we have 15 pads left so the pad value is 15 and then for the message hello we have 11 pads left oh the pad value there it's 11 so this is how we this is how we go ahead and perform the padding Oracle attack to figure out what these pad values are we start guessing and the beautiful thing about the server is the server tells us whether we're right or wrong with the padding value so the server's gonna be like hey you have a padding err you have a padding err when we're trying one two and then once it doesn't say that we
have a padding err we know that we have the correct padding so here's a visual example of it I'm really glad that that text isn't too small so in order to start guessing the padding value we begin incrementing values within the initialization vector right here we do this all the way until we don't receive a padding error once we don't receive a padding error we know that we have the correct padding so once we do have the correct padding we go ahead and we XOR that with the modified initialization vector value so if we had to change this one to a four in order to get the right padding then we XOR our padding value
with four and then after that we receive a bite from the keystream once we have a bite from the keystream we can go ahead and have fun and decrypt the rest of the day to buy X owing that against the original IV value so that would be a 1 in this case and then we receive our plaintext all right so enough with block ciphers love to talk about stream ciphers and a common attack on them so the stream cipher encrypts data as we mentioned earlier one bit at a time and unlike block ciphers which encrypt data in blocks so also unlike block ciphers the number of bytes in the plaintext remains the same number of
bytes in the ciphertext like we just mentioned one byte in one bite out so as we can see here about how it works the plaintext is X sword against a key and then you get your cipher text there's a really simple example of it it's not all of them and then then we're gonna want to change that key we want to change that key so that we don't get collisions because if we get collisions we can go ahead and perform a key reduce attack like if I wanted to encrypt the plaintext John then I get my ciphertext then I want to encrypt the plaintext of John again I don't want to get the same ciphertext that's that's not cool so as
we just said collisions occur when we utilize the same key to encrypt two different messages so the XOR is pretty cool so let's imagine that we just encrypted two different messages with the same key if we XOR those two messages together the encryption key cancels out and we get an overlay of the actual text here is a visual example of that so so if we go ahead and we XOR these two messages together we receive an overlay right there seen a smiling face the same cache that's that's how that goes so key reuse is pretty bad don't do it so side channel attacks are indirect attacks on crypto systems these are pretty sweet so we can think of them as
utilizing information that either utilizing information like the power that the machines using what the time on the clock is how much battery is left we can use cool stuff like that to go ahead and attack a crypto system so here's a theoretical example so it's our birthday friend got us a gift we want to figure out what that gift is here's an example of a side channel so this right here's a side channel boom alright so we ask him hey is it a new watch and he looks at us and he goes no with the neutral facial expression staring it to your eyes and then you ask is it a hat he looks to you
again same it's same neutral expression now and then we asked him is it a computer his expression gets all excited his eyes light up well and looks like it's a computer so that's how we that's how we use to side-channel the information to go ahead and figure that out so we can relate this to crypto in a few different ways let's go from theoretical to practical there we go all right yeah there we are all right so what this code right here does is takes two different strings comparison returns true if it's equal false if they're not equal so most programming languages designed string comparisons in a way that can pair each other character by character and that
bail out as soon as there's a mismatch so we're gonna see that input string 2 is going to bail out a lot sooner than input string 1 because there's less matching characters so the time that it takes for the application of bailouts and our side-channel we can we can use this to deduce information about the string like let's say it takes 2 seconds to return if these two strings match and then 1 second to return if they don't so just knowing this little bit of information from our side channel we can change our inputs during one character at a time measure the time it takes for the function to return and the sensually brute force the password so
always be aware of what your side channels are leaking because they're they're chatty all right here's one that I think everyone here's got experience with that's heartbleed had to throw it in so it was found in late 2014 it's a vulnerability within open SSL's heartbeat extension and basically when we send a malformed request to the server the server will respond with a bunch of bunch of good stuff that keys to the kingdom which private keys certificate signatures credentials emails weird stuff so this is how a standard heartbeat request works every now and then the client needs to reach out to the server and be like hey you're still alive and kick'n and then the server is like hey yeah and so the way
that it does that the client sends it a heartbeat request which has two parameters it has the text of okay and then the length of the text two bytes and then the server responds with okay which is two bytes this is how the exploit works so there's no bounds checking on this length parameter at all so we can say hey here's an OK and it's 65,536 bytes it'll return with that it'll say ok and then it will barf all over us so that's that's that's pretty cool it returns a bunch of great stuff and a lot a lot of people were affected by this attack whether it was directly or indirectly I mean you know simply
using an online form heartbleed could have indirectly hit you so the way that this relates to crypto is this isn't a flaw within the crypto itself at all TLS can be flawless but if it's not implemented properly then then you're done son so this is Apple's go-to fail this is embarrassing so this is another implementation related failure in which certificates are always accepted just always accepted it it's bad there's so here's how it happens so go to fail is called twice no it's always gonna be called always and then it's going to skip some key verifications right here which have to deal with you know verifying that the certificates valid not malicious so that happened and that's why you should
always QA your code because it's really weird that this bug got passed QA a lot of people there's conspiracy theories around this one saying it's a backdoor you know backdoor in place by either Apple or the developer who's gonna cash out on the CVE later no I'm sure how this happened but it did so apples not the only culprit this hit Linux too this hit a lot of Linux distros including a boon to Debian Arch got a lot of them and it was a vulnerability in the is it the new TLS or new TLS good new thank you and the new TLS library it's really similar to go to fail instead of a misplaced go to fail we
have a misplaced go to clean up which it does similar and so again proper QA would have prevented this bug from being released some validity measures so that's that's not good at all very similar to goto fail but it hit Linux no no and also this failure so what we can do with this is use a self-signed certificate and pose as an authenticated operator of a vulnerable website we could do that we could go ahead and perform a man-in-the-middle attack with the a few things we could do but again proper QA your encryption can be flawless but if you don't implement it right not good right so we can't have a crypto talk without mentioning dual EC
drbg which is it's a random number 8 er that was well it contains a backdoor it was approved by NIST as a standard for seven years and then adopted by companies such as Microsoft and Cisco to use in their crypto so this is how it's supposed to work it might look a little daunting but it's not we have a sequence that goes to an update function that's pretty much all it is nothing too fancy sequence is represented by s update functions represented by F I'm going through these slides way too fast ok so given the random number there's a way that the Duce with the sequence of the output values will be that's what the
backdoor is and because of that we can go ahead and brute-force all of the random numbers so there's a lot of exploits online demonstrating this and its impact hit pretty far and wide pretty far and wide as I mentioned there was a lot of sketchiness surrounding this one - speaking of conspiracy theories it's alleged that mist and the RSA may have been involved knowing that it was a backdoor before releasing it this food for thought it's worth at Google definitely worth of Google so cons talk about unfortunately in a little early but getting their height so the TS 550 Evo so I found this one during some independent research I forget if it was this year last year but
recently so the TS 550 is a large scale fuel management system that controls fuel levels sensor alarms and whatnot so it also has a user that's diagnostic level so this diagnostic user has full rein across the entire system he can do whatever he's better than an admin and so a weird thing is that their password is hiding right here every time that we make a specific post to a specific CGI element a specific key is returned along with the response it's kind of weird so this key when you des encrypt it with two ways and send it back as a valid password for the user talk about a backdoor Wow so I'm not sure if this was a programming mistake
or not though could could have been just a programming mistake can't can't get hit for slander
all right so so today I have a spent through that it's supposed to be another five minutes or so I hopefully there's questions so today yeah we saw a couple of ulnar abilities cryptographic related and backdoors so I'd like the main takeaway from this talk to be always always try to look for vulnerabilities and exploit crypto systems especially if somebody made it themselves you get weird stuff like key reuse attacks non randomized initialization vectors it's it's a mess crypto is hard to implement it's it's really hard to implement it's like a glass house and if one thing's wrong the whole house Falls not good not good at all so and there's a lot more out there that are still undiscovered
like go-to fail that was undiscovered for many years and that was just blatantly obvious and to go to fail was open source so figure that one out and I'm not sure if Knut Els was too but it might have been it might have been it is okay all right thank you pardon me uh-huh you're right yep thank you thank you cool so um I guess we're about five minutes short there any questions sorry I sped through it [Music]
oh that is sweet on a what ah oh man oh that is pretty cool that is cool ah there oh go ahead what you ever sure so on that was basically distilling some independent research on a lot of random stuff out there and we ended up just noticing that a key came back during doing one request that that we made there was just a randomized key that came back that was pretty weird and then just send it up utilizing that is it's a password and within the we were what was it in the manual so the manual was given away a lot about the diagnostic user so we knew to look out for a diagnostic user first and then
from there we went ahead and just made that request got the key and then started looking at the key a little bit more heavily I forgot how we found out that it was two A's that one I was trying to figure that one out before the talk and couldn't do it but it was two A's very weird no sir really yeah oh it's called cracked on Sh okay oh cool I'm gonna write that one down thank you nope no heads oh god yes I did yep yep yes I did I was thinking about it I was thinking about it but I wasn't sure if it was well I guess it is related but yeah next time
probably right probably I mean yeah cuz Microsoft implemented it in Microsoft just everywhere so they might have I mean we did a bowling alley that we were bowling at we found the machine with the Windows XP still running on it it's just crazy yeah probably not a list of all the crypto homes oh the casinos no I'm down let's roll oh cool alrighty well 23 minutes oh thank you guys thank you [Applause]