 Has anyone of you heard about the OpenSSL Debian Bag? First, sorry about our English, we know it's pretty poor, so our apologies. It's pathetic, the word is pathetic, according to the dictionary. It's pathetic, the word. Let's go again. Has anyone of you heard about the Debian OpenSSL Bag? How many of you? How many? This will be easy. So I start with a brief introduction and some history about how the bag was introduced in OpenSSL and how it affected this package and cryptography. And then Luciano will show the most funny part, the live demo, and maybe even how to conquer the universe. So he became a master of the universe. So this bag was caused by a Debian-specific patch introduced almost two years ago and remained unseen until this year, a couple of months ago, when our friend Luciano discovered this problem that affected the random number generator in OpenSSL in Debian. This bag affected not only OpenSSL, but the underlying library, LiveSSL, and every packages that linked against this library. And not only did it affect Debian distro, but any other distributions that are based on Debian such as Ubuntu. It also affected other operating systems which, although not based on Debian, may have imported wikis into them. So how did it affect the random number generation? Well, in fact, the entropy got reduced to just 15 bits. So the key space and any random number generated had to be inside this very little key space of just 15 bits. Other aspects, other features we should bear in mind when that limit the key space are the platform that is the architecture and the endianness, little endian, big endian, 32 or 64 bits. And the length of the keys, for example, if they are 1024 or 2048. And well, these are just some examples of cryptographic schemes that got affected by this bag. As you may know, cryptography is heavily based on random, secure random numbers, so this bag affects all of them. These are some of the affected packages which are linked against LiveSSL, either dynamically or statically. And some of them were showed off in some other presentations such as OpenSSH and Tor. So they all relied on the security and unpredictability of the random numbers. So how did it start? It began, as I said, two years ago when Debian users submitted a wishlist severity bag to the Debian backtracking system about some uninitialized variable warning that was being printed by Bygreen. Bygreen is an online debugger that checks for memory leaks and something like that. So we show a brief demo. We have here a program that just requests some random bytes into a buffer from OpenSSL and prints them. It's just that. So can you hear? We compile it and link LiveSSL. We see it's linked and let's try it. It prints just random numbers. So let's see what this user was complaining about. We'll just link with the original version of this here. We're linking with the original version of OpenSSL that of two years ago and we're running with Bygreen just to check for any problem. So we can see here many warnings about uninitialized variables, quite a lot of errors. So this is what the user was complaining about. In fact, it affected every package that linked against LiveSSL. So the deviantainer analyzed the source code and just found out that it was due to just two lines of the OpenSSL source code which are these two lines which are identical. They are syntactically identical but they are in two different functions in different contexts. We should notice that the second line is surrounded... We should run? Maybe we should run any time. I'm not sure. Who puts the fight alarm? Okay. You look calm, that's good. I'm not calm, that's bad. They hacked our presentation. Should we continue? What he said? I'm checking. He's checking, be careful. Sorry? Sorry? What? Okay, I try to continue. It's pretty hard. Oh my God. There's people clumping, so... The exit? The exit is over there. Super epic fan. It smells like sabotage. Oh my God. This is not the light button, this is the alarm button. Please don't touch it. What should we do? We can continue. It's quite confusing. Stop it. Okay. Okay. If it happens again, should we do something? We have water here, we can use it. Okay. Okay. Let's go. Mom, I'm okay. Are you looking me? I'm okay. She gets water. Okay. So these two lines are the ones to blame for these unanationalized variable warnings. But we should notice that the second line is surrounded by this macro. It's about other dividing tool, very like Bygreen, that's called Purify. This is just the original source code from OpenSSL so that this line may get into the binary program or not depending on the compilation options. So let's continue. There were several proposals to... or solutions to this problem, but the most... the one that looked most suitable was the option just to comment out these lines. Because, oh, sorry. They're adding just... what these lines are doing. In some cases, they're taking this parameter, the buffer, both as input and as output. They take the input from the buffer and add it to the entropy pool. So when the buffer was uninitialized, the warning was being printed. So the... In fact, this entropy added by some initialized variable is almost negligible. So it looked like a good idea just to comment out these two lines. So the package maintainer asked the OpenSSL mailing list about these two lines. And the answer from an OpenSSL developer was that it was okay just to comment out those two lines for divine purposes because they didn't add any significant entropy to the entropy pool. So, okay, this is the most famous patch lately. It just commented out those two lines. But how did this affect the random number generator? You remember the function we just saw a few minutes ago? It was runbytes. When a user wants to get a random string, it calls this function runbytes with a buffer, which is both input and output. This function takes some entropy, almost negligible from this buffer, and when the state of the random number generator hasn't been initialized, it calls the run pool function, which takes care of this, taking or adding entropy from several sources, such as the system random device, the user ID, the process ID, and the current time. This is all through the run add function. Finally, we got the process ID again, just in cases for multiprocess and forking just to avoid the collisions in the random number generator. So, here is the result of commenting out the second line, which was surrounded by the macro. We saw it doesn't add any significant entropy, so it's not a big deal. The problem relies on the first commented outline, which affected the run add function, so in such a way that none of these entropy sources, or randomness sources were read into the entropy pool, and as a result, the only source of entropy remaining is the current process ID. This is what limits the entropy to just 15 bits, which is the maximum process ID of the system. So, we may wonder why the second line was commented, which has this effect. Well, in fact, the deviant developer tested the open SSL with Byring, just running the open SSL regression tests. In many cases, the run add function is called directly that is not from run byte function, for example. So, in this function, which is open SSL API, which loads some entropy or some randomness from a file, as the comment says, there may be the case when the buffer we're using more bytes from the buffer than those read from the file, and in this case Byring would print the warning too. So, okay, so this is time to get to the funny part. Do you get this part? The third parameter of the run add function is how much entropy is adding to the Pyreng state, and as you can see, the number is only i, which means only the part you read. So, the initial values are not taking as entropy in that case. I mean, the value will be zero. That means that the entropy by initialization memory is negligible. That's why. Let's see how can we take advantage of these problems. Well, as Maxi says, random numbers are everywhere in cryptography, so we will see few scenarios when we can exploit this flow. The first one is authentication by challenge, also known as hours less authentication. How many of you are familiar with this concept? Okay, we will be quickly in this part. The client generates a pair of key randomly. When the client wants to create, wants to login with a power load dedication, the server creates a random number, they decipher with the public key, they send the challenge, the clients decipher the challenge, get again the random number, and sends to the server the challenge response. And if it's okay, access granted. Yeah, fix with your concept. Cool. So let's introduce another character. It's a hacker. You know, the hackers use common lines, so that's why. And this hacker uses really big fonts. I don't know why. Okay, this hacker, notice that the client generate this pair of key, this one's, I'm not sure if you can see the arrow. This one pair of key was generated by random and was generated in an unsecured Debian system. So there's a limited space for this key pair. So the attacker creates all of the possible keys, which is two to power 15. And try with the first one, try with the second one, trying to respond to the challenge. Sooner or later, the servers will grant the challenge because one of that pairs will be exactly the clone that used by the client. Yeah? So this is really, really easy to get. I mean, it's not rocket science, but any of you didn't see this problem? Okay, let's see an example. Let's see here. Okay, HDMood provide us a lot of the complete space for all SSH keys. It's available in his website. For example, in this case, we have the spaces for the 1024 and 2048 length. For example, for the two... As you can see, it's a really small space. I mean, you can get many of these ones. Let's see how we can try it. We have made a little script called Exploiter, which is a really simple script. Yeah, as you can see, the script tries to, with each pair of keys, tries to get logged into the server. Yeah, so let's try to see how it's working. Of course, you should know the user. For example, and let's try the random server. I don't know. Okay, let's go. And the port probably is 22, so let's run. Well, let's see if this works. As you can see, all the keys are the fingerprint and the number, which is the Peter, use it for create that pair. Oh, how nice. So, you know what an alarm is. You heard it, so should we run this script? I mean, push red button, it sounds? No. Yeah. Okay. Oh, gosh. You're loud? We'll say that. We shouldn't. Well, the script is not working well, but you can die with it by just script. Okay, let's continue with this, so I think. Okay, well, this is the first attack. It's a really simple attack. I mean, you can literally be in a script key, because it's a script, so you can use it. So, let's continue with the other one, but this one is really simple, I mean. Let's see how I attack Diffie Helman. How many of you are familiar with Diffie Helman key exchange? Okay, good. So, Diffie Helman, you know about that. Yeah? Too many math for you? Okay. Both parts select random number, and after some math magic, they get a shell secret. It's something simple, I mean. Let's see, how many of you are familiar with Diffie Helman, ephemeral Diffie Helman? Okay, I can teach you something new. The ephemeral Diffie Helman is just like Diffie Helman, but you should discard the private exponent. Yeah? So, after the key exchange, you discard the private exponent. If an attacker takes control of one of the parties, he can't recalculate the shell secret. So, if you want to decipher the communication, you should go against K, which, of course, is a really big number, so you need to brute force it. But in this case, probably you see the problem. In this case, the private exponent are random. So, if those keys was generated in a vulnerable Debian system, we can look for all of them. Yeah? So, let's see how this works. We just generate a list with all the possible x. We first, and we try to get the private part of one of the parties. Yeah? So, if we get the private part of the client, that means that we get the x for the client. And if we can get the private part of the server, that means that we get the x of the server. Notice that even if one of the parties are vulnerable, you are able to recalculate the shell secret. That's something interesting. So, we have a demo here. Okay. This is Warshack. Probably you are familiar with it. Maxi, me, and Paolo. Paolo is that guy who is looking for a show. If you have a show for him, please contact me. So, we made a modification to the Warshack in order to decipher SSL and TLS connection with Diffie Helman. With Diffie Helman. So, for example, in this case, the Cipher Suite was used with Diffie Helman ephemeral. That means DHE, Diffie Helman ephemeral. So, as you can see, the connection, it's... Cipher it? I didn't notice. Okay. And of course, you can decipher it because it's Cipher. Of course. But, if one of the parties is vulnerable, you can look for all the possibilities. So, we got the preference, protocols, SSL. And this box, this new box was created for us. Let's see if I have the... This file contains all the possible X. Yeah? The all possible X can be in two lengths. Can be 64 lengths or 128. 128 bits, yeah, of course. We are talking about the length, yeah. Bits. So, that's why this kind of lines. It's 2 power 16. So, that's why it is. So, we put this here. And this here. Yep. And that's okay. In this moment, we are trying to root for the connection looking for one of the public keys. That's why it's taking a while. In fact, it looks like hanging, but it's not... It's working. Believe me. Oh, there it is. So, okay. And there is the connection deciphered. Thank you. Thank you. Thank you. Don't thank me. Thanks, Kurt. Kurt is the... Okay, that's okay. It's the guy who comments the line. Fuck. He's gonna kill me. Okay. Well, that's... As you can see, this is a really big problem. I mean, you can do the same thing for SSH. So, if you triumph as secrets with SSH connections in the last two years, you should note it that you are compromised it. A lot. For example, if you copy your private PCP over SCP and no passphrase there was not ciphered symmetrically. In that case, your PCP is compromised, too. Sorry. So, as you can see, it's a really big problem. Continue. Another scenario, and this one is really, really... I don't know, really strange scenario, but it's really fine, too. It's DSA. How many of you are familiar with DSA? Digital Signature Algorithms, I think. Again, sorry. Oh, many of you. Cool. Well, that's good. More math, sorry. Okay, that's as many as you know, that has many public valuables. There's P, G, which are primes. G is a generator. Y is the public part. X is the private part. And if Alice wants to sign a message M, she needs to calculate two numbers, R and S. As you can see in this part, the only purpose of R is obfuscate the X, which is the private part. And R only depends on K, which is a random number. Of course, you are seeing the problem now. If a message is signed in an insecure environment, in a weak environment, in a vulnerable deviant, in that case, you can recover the X. You just make some math workout magic, and you can unisolate the X. I'm not sure if the correct word, but you can put the X alone in one part of the equation. And of course, as you can see, S, it's a public value, K, it's a value which what we're reinforcing, the hash of M, of course, you should know it, and R is the public value, of course, Q2. So you can calculate the X, which is the private part. That means, even if the SA key pair was generated in a secure and safe system, if that pair had been used in an insecure system, then your pair is compromised too. Sorry, again. So, can you see this? No, somebody said no? Say it's lower. Yes, yes, yes, we can go. Let's go, let's go, finish it. So we have a really, really good scenario here. I mean, deviant is the universal operating system, so we can conquer the universe, as Maxi says. We can do it in five single steps. Of course, we should choose an application. It can be SSH, SSL, whatever. You should see what algorithm is using. For example, if an SSL connection, if you had a pickup of the last two years, maybe you work for the NSA and you have all the pickups in the world. That would be great in that case. It's not great, the way it's not great. But you need to see which algorithm is using in the Cypher Suite. Then you should generate all the possible key. That means two to the 15th, minus one, because open cell cannot run as in it, so you can save one of the keys. Times three, why times three? Because there's a free combination with the Indianness and bits. I mean, deviant runs in 32 bits, little Indian, 32 bits, bigger Indian, 64, little Indian. I'm not sure if I said in the correct way, but that's three combinations. Three combinations, so you should generate all the keys. Of course, if we are going to conquer the universe, you should conquer all the platforms, so that way you should multiply by three. All this space can be something really easy to generate. In a few hours, you can generate all the possible keys. And then you should brute force. There are many options here. You can authenticate yourself in a symmetric, using a symmetric keys as we see. You can contact the White House.gov and try to brute force him. In this case, you need a quick public key on a server, so it's a possible situation. You can do a man-in-the-middle attack in the same way that we generate all the clones of the pairs. You can generate many clones for RSE, RSA certificate. RSA certificate, yeah. So you can create a phishing situation or something like that. Of course, in this case, you need to create a man-in-the-middle scenario. That is really hard. You need a multi-vendor DNS bug. You need to poison in caches. That's really hard. You didn't go to the damn talk? Okay. It's tomorrow. Tomorrow is the damn talk. So that's why you are not laughing. Okay. He was in Black Hat too. I have news for you. Internet is going to be exploding these days because this little problem with DNS, where are you living in the Tupperware? You should know this one. Let's continue. Gosh. Yeah, if you prolly dance wants to give you the surprise tomorrow, I am so stupid. Don't take him. Don't take him. Another possible scenario is the Cypher connection made it with one of the parts vulnerable, just as we did with Wireshark. There are many other tools you can attack SSH2. In that case, you need one of the parts outdated, which runs a deviant vulnerable in this moment. At least, you captured traffic in the last two years. Maybe don't... There's agency that made these kind of things. I don't know. Maybe if you didn't know the damn problem, maybe you don't know about these things, so I am noticing you. Another problem, another scenario, a possible scenario is attack Cypher symmetric encryption, storage or connections. You know in many cases when, for example, in a storage, if you want to Cypher than a storage, you create a random key, which is symmetric. In that case, you need to create all the possible keys and just decipher it. It's something like that. Many backup systems are vulnerable to this flow in that way. And of course, as we see, you can attack the DSA private part. There are tools made in this. We want to give you the URL in the next slides, I think. In that case, you need a message sign it in a weak system. That means that the non-reputable... I don't think it's... Reputable means something for you? Non-reputable. Okay, that's strange word. Non-reputable? The property of non-reputable was losing in DSA. Reputable? Reputability. Reputability? Oh! Thank you, James Bondo. And of course, the last step, ensure your power. Wow. Okay, that is the related work. The first one is the... Open the HDMode tools, which has all the key spaces for SSH. You can download there. There's many left, so you don't need to calculate them. The second link is our patch for Wyshack. The third link is a Ben Snort plugin to detect communications using weak Diffie-Hell man-exponent in SSH. So you can get an alert if one of the parties are running weak... Okay, weak keys. So Ben, are you here? No, he ran with the final alarm, I think. With the rocket issue. The third one is SSH tools. In that link, you can find ways to decipher SSH connection when one of the parties are vulnerable. And in that link, you can find a tool for getting DSA parts with a sign-in message in a weak environment. The other, the Firefox SSL Blacklist add-on, it's a plugin for Firefox. In order to detect when you are connected with a SSH server, if they certificate, it's blacklisted. You need to install two extensions there. One is the extension for check itself, and the other one, it's the database with all the blacklisted certificates. The other, the OpenID, Debian, PRNG, DNS, cache, poison, advisory. It's from yesterday. I mean, tomorrow we... I think we get drunk, but we found this and we decided to put it anyway. Nowadays, since yesterday, you can't trust in OpenID anymore, sorry. If you combine the problem with the PRNG, that means clone certificates with the DNS cache poisoning with the Kaminsky problem, OpenID can be fakeable. That's why that's because OpenID doesn't use CRL, certificate location list, CRL. So, in fact, nobody used CRL. Not nobody. How many of you are Windows Vista user? So, you are the only one who uses it by default. Sorry. Yes, please, please. You're safe. The other ones should install by hand, but the only people who have CRL by default are the Vista users. You have other problems, but you are safe in this case. And the last link is the Debian wiki, where you can find all the packages affected and how you should regenerate the keys for each package. So, let's continue. So, some contra-measures. Of course, you should read the Debian wiki for more details, but one of the contra-measures is update, leave a cell. Of course, if you are a Debian user, how many of you are a Debian user and how many of you are a Vista user? Okay. Well, probably most of you do an upgrade daily. I see some faces like... Okay, in that case, you should upgrade it. The other problem, the other contra-measure is look for compromises keys. Debian provides you a nice tool to do that. Maybe I can show you. It's called SSH boolkey. I don't know if you are familiar with these tools. Debian users, are you not familiar with these tools? Okay. Dump up. Okay, that's good because you are learning something. So, let's see. For example, in this case, there are some compromises keys here. For example, this one, which is host compromises, as you can see. There are some ones that are not blacklisted, so it's safe. This checks for your... Of course, this is on purpose. I'm not using compromises keys. Cool. In one of the cases, it's unknown. I can't find it. Okay. But let's go on. You know this tool now. You can write like this and you can check all the keys on your system. Of course, you need to be rude because you need to read it. Okay, let's continue. Well, you should look for weak keys even if you are not a Debian user. Maybe one of your Debian users export to your system weak public keys. So, in that case, you have a hole in your system. A really big hole. You can put a little elephant in that hole. You should regenerate all these keys if you use it in an affected Debian system. Of course, you can mitigate the problem with Firefox, with the blacklist add-on. This is nothing work in all the issues, but let's leave the details. And if you are a Debian user, if you are an SH server in the Debian user, you can check this option in order to avoid that users with weak keys connect to your systems. Of course, all the traffic affected in the last two years, you can do nothing for it. I mean, the mail is already split. So, let's see some repercussions. Okay, these numbers are from our friend Jordan. Oh, my God. Okay. He is German. He works in Heisek. And they make a survey with 100,000 web servers. They are looking for money in the middle situations. So, they detect three percent of the service of the people who have a signage, a CA, are running weak certificates. This is a number from two weeks after publications of the advisory. So, if we extrapolate this number to the global numbers, maybe 224,000 weak certificates are running these days. Combine this with the DNS problem and you will get a perfect fishing situation. So, another repercussion on Debian. Of course, I am the Debian developer. This problem touched my feelings. We get the Pony Award there. We go on the Pony Award to the most epic fail. We have it here. Say hello to the Pony. There are some things that you should know before criticizing us. One of these is that Debian needs to patch the systems. I mean, all the distribution patch software. That's because, in most of the cases, AppStream has not the same goals than the distributions. In this case, for example, for open cell, it's not something big to have bad green problems. In Debian, this is something really huge. So, that's why the problem starts. In some cases, AppStream is hostile. I think the word is hostile. I mean, they are bad guys. No, not bad, but not friendly. Not friendly, yeah. Well, open cell, guys are from the BSD school and they are not friendly guys. So, of course, we can audit all the code because it's a lot of lines of code. So, let's see. Debian is working on visibility. Do you know about the Linux law? The Linux law says, given enough eyeball, all the bugs are shallow. So, we are working on creating many eyeballs. So, we are working on visibility. So, many eyeballs will see the code. In that case, we are trying to get public the version control systems for all the sources and working on patches.debian.org which will be a place where the patches will be there. The issue here is maybe it's not a technical problem. I mean, maybe the AppStream has not an easy way to see the patches. Maybe it's a policy problem. The developers are not obliged to public the patches. Maybe it's a social problem. Maybe we should be more friendly with our code developers and we should ask in better ways. Maybe the problem is in the conjugation of all that sets. So, let's see some conclusions. We are hurry as you notice. The first problem here is review twice patch once. If the Debian developer follows the data flow problem, he will notice that the only part where buff is touching it's there in the lining comment. So, the problem is if you notice that right now don't have nothing, that's a problem. So, another issue is don't write fancy code. I mean, if Aniselli said memory doesn't contribute with something substantial, so don't do that. Of course, make a lot of comments on your code. That will be good. Ask with details. The Debian developer just asked with few lines. You should put the context of the line. You should put what are you trying to do. If many people complains about something, maybe it's something huge. A lot of people complains about binary problems in OpenSSL from many years ago. In fact, one year ago, a frequency-hacking question is why OpenSSL has a lot of warning problems in background. Of course, another big issue here is OpenSource, and I'm a TVist of OpenSource, but OpenSource doesn't complain the Linux low conditions per se. That means OpenSource doesn't mean a lot of eyeballs. How many of you are activists of OpenSource? Well, many of you. It's not enough with OpenSource. You should see the code. That's what that line means. Here is the thanks. Of course, we are answering questions in room number... 105, down this corridor straight across the hallway. 105. We're releasing your insults there.