The SSL and PHP Situation is Insane (and hilarious)

0:00 It's not looking good, folks. At this point, you probably have already heard about the whole PHP massive vulnerability. And also this week, there was a whole debacle with SSL certificates from a root authority company. And that one is especially absurd, so I'll probably cover that first. I think it's actually kind of funny it's so bad. So I'll give you a rundown of both of those things, and I'll go over stuff that hopefully you haven't heard already. So first of all, the SSL certificate debacle. This involved a company in India called eMudhra . They are a trusted-globally certificate authority. And this is a type of company of which there's only actually a handful in the world. And they are trusted by operating systems and software to issue certificates where you can pay them, and they basically verify that you are who you say you are. And then you can use that certificate to "sign" software or a website that you own. So that way people know when they go to

0:48 example.com, "okay this is really I'm connected to example.com, because I can see that this certificate is signed by a root authority that I trust that says it was made by that." They can also sign software, which is what you would see if you go to the "Digital Signatures" tab in the properties of a program that is signed. These trusted root authorities typically have one or a couple root certificates. These are like their master certificates. And then they use these to sign higher level "Intermediate" certificates, they're called, which then signed customer certificates after they verify the customers. And these root certificates are generally all trusted by major operating systems and browsers internationally. So you got Windows, iOS, Android, Chrome, and Firefox, they all trust pretty much the same ones. However, in this case, eight of this company's

1:36 intermediate certificates were compromised. So anyone could make fake certificates that were trusted by basically all software and operating systems. But "compromised" is not even really the right word, it's way worse than that. So what is the actual problem? Now to understand the problem, you have to understand how signing works. I'll try to give you a really quick rundown version. What you do when you want to create one of these certificates, and I'll explain how they work, is you create a private key and a public key. They're generated together, they're very long. And basically you can use the private key to sign a file or text or data or whatever. And you do a calculation with the data, and then it results in some signature. And this is done with the private key, which you don't want anyone else to know. But then you publish the public key so

2:22 that everyone has it and they can use it to verify. Because the way the math works is without getting too complicated, it lets you use the public key to verify that something was signed using the private key, without actually knowing what the private key was exactly. There's a bit more to it, but that's really the gist of it. Anyway, it's very important that the private key is impossible to guess or brute force. And for that reason, they are very long and can be chosen randomly from an extremely large set of possible values. Specifically, they're supposed to be 384 bits long, which means that it has 2 to the 384th power of possible values, which in base 10 is around 4 times 10 to the 115th power possible values. And for comparison, that is 400 decillion times

3:11 more atoms than in the entire universe. But in this case for these eight certificates, instead of generating a private key that is 384 bits, it seems that apparently they chose numbers that are literally just between the numbers 0 and 384. As you can see, this list of numbers are the private keys. They're supposed to be a lot longer. All of them are actually even less than 256, so it's possible they chose 0 to 256 using whatever function. And yes, you are seeing this correct. One of the private keys was literally the number 4. Not four digits long, just four. And of course, this meant that people were able to brute force all of the private keys instantly simply by counting up. But this is worse than just website SSL certificates, like a lot of people are reporting. Six of the

3:58 certificates indeed were used for SSL certificates. And this does mean that attackers could forge certificates for any website. So if they were able to get in between you and your connection with the website, called a "man in the middle", then you wouldn't even know you aren't on that actual site, but it would show as a verified connection. However, two of their certificates were actually marked as being used for code signing. This means that they could be used to sign software like EXE files. And that often means that it can get past most initial checks from antiviruses, or at least they're a lot more likely to trust something if it seems a little bit suspicious, just because they are signed. Now of course, there are what are called "revocation lists" where authorities can post a list of certificates you should not trust anymore for whatever reason.

4:45 It was stolen or something was wrong with them, or they were generated as just basic numbers. But that also depends on your app or operating system pulling that list and actually staying up to date with it. Now, for the most part this has been done, I'll cover that in a second. But it could also be a big problem for air-gapped systems, which are offline. These are systems which maybe don't connect to the internet. And might not be able to access the revocation list, but they still might have that root authority in their trusted certificate authority list. And even if that offline system didn't have the intermediate certificates downloaded, because eMudhra actually did sign those bad certificates with the root authority and then release them publicly, people now know what that signature would be for those. So then everyone can in turn use them to sign whatever they want.

5:30 That means to an offline system that is signed by one of these bad certificates, it'll see the software. And it'll still think, "Alright yeah, I've never seen this intermediate certificate before, but the root authority signed it, so it must be okay." I would say that the SSL certificate ones are not as huge of a deal because those are used for the internet anyway. So presumably if you're going to connect to anything, you're also going to get the revocation list. So I do think the code signing ones are probably the bigger deal. But theoretically, the SSL ones still could be used for attacks within local networks with servers that don't properly fetch revocation lists. Or in software that uses their own trust lists, and maybe even embedded systems that may still be vulnerable for the same reason. And that's for both SSL and the code signing ones. For this reason, actually, Google and Mozilla both have revoked trust of the root level

6:19 certificate from eMudhra , not just their intermediate ones that were compromised. They actually revoked trust to the big one. And the purpose of that is basically because some devices and software might not reliably actually fetch intermediate level certificate revocation lists or individual ones. Maybe they only monitor root authority revocation lists. So it's better to just do that. But that does seem to be only Google and Mozilla so far. Now, if you want to check, you can actually go to this test site to make sure that your device, whether it's an iPhone or computer, no longer trusts any of these certificates. And if you see a check, that means that it doesn't trust it. So that's correct. It should not trust it. A check is good to see. And it does seem that basically most things are correctly not trusting these anymore. So that's going to be all browsers, Chrome,

7:05 Firefox, Safari. They all have it distrusted and should not require full browser update either. These are lists that are pulled automatically. And Microsoft and Windows, they also updated their lists to not trust it. It shouldn't require running a Windows update or anything. They are also pulled from a different list. And apparently Apple also pushed out a similar thing with iOS when I went and tested it in Safari, which apparently uses the same system level trust things, it didn't trust it there. So it was all good there. And then for Android, Google said that they distributed the update or fix through Google Play services. So you should have a fix on pretty much all your systems. And they did say that "while the majority of Android devices have already received this update, users can also trigger an immediate update by restarting their device." So if you want to be extra

7:50 safe, you can just restart your Android phone and be sure. Another funny thing is that apparently this eMudhra company, they didn't really make a lot from their division with the root authority stuff. And they say they're just going to shut down that part of the business. So I think that's probably the right move. Seems they were not very good at it. Alright so next let's talk about this PHP vulnerability. This is another classic vulnerability. However, there was a major twist for how this was released. Now, if you're not familiar with PHP, it's basically a programming language. That can dynamically create web pages and stuff like that. It's a lot more complicated than that, but that's the gist of it. And a lot of websites use PHP. More so in the past, but still a lot. And you definitely have seen it before if you didn't realize it. For example, if you go on Wikipedia and hit "Edit", then the page for editing stuff will say PHP at

8:39 the end of the URL. Another example is Facebook, they have their login page, is a PHP site. The exploit is being called PHP2Shell, and it's comprised of these two specific identifiers, the CVEs for those exploits. And not only is it very severe, basically allowing anyone to just kind of hack in and control the server through a lot of PHP pages. It basically affects all PHP versions. All of the supported ones, as well as going back several major versions. There's a lot of old websites that maybe haven't been updated in ages that are just going to be vulnerable now. Now you might think, "Alright well surely this was probably patched, right?" Well yes, but there was a problem. Indeed, all the major currently supported versions of PHP did get patches. However, someone apparently

9:24 mistakenly released the proof of concept describing how the exploit works before the actual patches were released. So it effectively became a zero-day where people knew how to exploit this thing before there was any patch available to fix it. So of course, almost instantly, it was seen being exploited and attacks going on. And even the NSA basically said, "Yeah if you have a PHP site, you better just take it down in the meantime until the patch is available, because this is really bad. People could just hack into your site." And you really can't do anything about it yet. Now, apparently the team with PHP did create backported patches for some older versions of PHP, even though they're technically out of support. However, they're not like official patches. So they don't get auto-updated. If you have auto-update software, you kind of have to

10:09 manually use a source patch. I'm not going to get into that, but it's sort of available, but it's not going to be automatic. I will point out there was another CVE that was related to progress bars for uploads. That was a different one. I don't think that's actually been patched yet. That one will be patched in a regular release. So anyway, people with websites definitely need to check whether or not whatever website they're running and whatever control panel they have that works with it, to make sure that if they have PHP, which you might not realize it does, you have to go and check to make sure you're running the latest version and that it auto-updates. If you have any kind of website, you want to do that. But really also anyone with local web servers, like apps that use a web interface, if that web server uses PHP, then it would be vulnerable too.

10:55 Now, that's less of a risk because it's not exposed to the internet, but still it could be exploited by malware that gets onto your system. It could just make things worse. Like if you have some kind of software that runs at the admin level with a web interface, and then you have malware come on that you use as a user, then it could elevate to admin privileges through that exploit. So of course, in general, you just have to follow the typical advice, keep your software up to date. And this is for any operating system because it comes down to the software, not the operating system itself. A lot of software comes bundled with their own little web server, so you have to make sure. But if you do have anything that has a web interface that is exposed to the internet through an open port or something like that, then you do want to be aware, that's the same as having a website. If it's a PHP thing that's exposed, then you could be vulnerable big time. And I

11:41 mean, depending on what it is, like if it's a router or something that has an admin page, you would not want to have that exposed. But for example, if they did, then I don't even know if there would be an update that would be available for that. So just be cautious, and be aware of what things you have exposed to the internet or what software you have, or if you have a website, if it uses PHP. Let me know what you guys think. Did you hear about these already? What'd you think of the SSL certificate? I think it's just so ridiculous. We could talk about that all down in the comments. And of course, if you liked the video, give it a giant annihilating thumbs up, it helps out. If you want to keep watching next up, here's a video where I talked about the new JPEG, it's here, the JPEG2 basically. I'll put that link right there you can click on if you haven't seen it. So thanks so much for watching and I'll see you in that next video.