WEBVTT 00:00:00.000 --> 00:00:07.680 JACK: A guy in Iran goes to check his e-mail. He types in gmail.com into his browser and hits 00:00:07.680 --> 00:00:14.490 enter. A strange warning pops up. It says Invalid Server Certificate. He’s unable to get to Gmail. 00:00:14.490 --> 00:00:21.450 He connects to a VPN and tries again. Through the VPN he connects just fine. He thinks there may be 00:00:21.450 --> 00:00:26.850 some funny business going on. He posts a question to the Google forums asking if there’s a possible 00:00:26.850 --> 00:00:32.610 man-in-the-middle attack going on. He also says he suspects his ISP or the Iranian government 00:00:32.610 --> 00:00:38.010 to be doing something fishy. Google responded not only to the forum post but they published 00:00:38.010 --> 00:00:43.410 a security warning to the world and released an emergency patch to their Chrome browser. Mozilla, 00:00:43.410 --> 00:00:48.150 Microsoft, and Apple followed quickly with similar security updates. There was, 00:00:48.150 --> 00:00:52.980 in fact, a man-in-the-middle attack against Gmail users; an attack which undermined the 00:00:52.980 --> 00:00:59.630 security in all browsers, an attack that had devastating consequences. 00:00:59.630 --> 00:01:04.760 JACK (INTRO): This is Darknet Diaries, 00:01:04.760 --> 00:01:12.880 true stories from the dark side of the internet. I’m Jack Rhysider. 00:01:12.880 --> 00:01:20.530 JACK: HTTPS, SSL, and TLS are all technologies that secure the World Wide Web. They all rely 00:01:20.530 --> 00:01:24.760 on certificates which are sort of like an identification card for websites. The 00:01:24.760 --> 00:01:29.230 companies that issue certificates are called certificate authorities, or CA. The concept 00:01:29.230 --> 00:01:33.520 of CAs and certificates is so complicated that I’ll have someone else explain it. 00:01:33.520 --> 00:01:39.850 GERVASE: My name is Gervase Markham and for about the last twelve or so years I’ve been involved 00:01:39.850 --> 00:01:44.740 with the Certificate Authority Root Program at Mozilla. [MUSIC] A certificate authority 00:01:44.740 --> 00:01:53.440 is basically somebody who checks identity and that you trust to check identity. The level of 00:01:53.440 --> 00:01:58.780 checking depends on the type of certificate. They might just check that the person who says they 00:01:58.780 --> 00:02:04.540 own the domain foo.com owns the domain foo.com. They might also say and by the way, it is Foo 00:02:04.540 --> 00:02:11.830 Corporation of 116 Acacia Avenue, Birmingham, UK and this is their phone number and this is their 00:02:11.830 --> 00:02:16.120 company reference number and stuff like that. It may check all of those things but it checks some 00:02:16.120 --> 00:02:23.890 level of information. The primary purpose of a CA is so that when you type foo.com into your 00:02:23.890 --> 00:02:31.990 web browser and that request goes out across the internet, which could be populated by any number 00:02:31.990 --> 00:02:38.530 of hostile or nefarious people controlling various bits of the network, the data you get 00:02:38.530 --> 00:02:45.340 back a) does come from foo.com and b) hasn’t been tampered with or can’t be viewed along the way. 00:02:45.340 --> 00:02:52.120 The certificate system basically underlies the secure connection ability of the web. 00:02:52.120 --> 00:02:58.030 JACK: Web browsers such as Firefox contain an internal list of trusted CAs and hold a list of 00:02:58.030 --> 00:03:03.040 root certificates to use for verification. When you visit a website it will present a certificate 00:03:03.040 --> 00:03:08.200 which identifies the domain of the website. The certificate also says which CA checked 00:03:08.200 --> 00:03:14.140 and verified this information as true. The browser then checks to see if the CA is trustworthy. Your 00:03:14.140 --> 00:03:20.320 browser contains a list of all trustworthy CAs and root certificates. Firefox for instance, has… 00:03:20.320 --> 00:03:23.450 GERVASE: 64 organizations and 159 certificates. 00:03:23.450 --> 00:03:28.820 JACK: This list of trustworthy organizations is called a root store. When a company decides they 00:03:28.820 --> 00:03:32.690 want to become a certificate authority, they need to work with the browsers to 00:03:32.690 --> 00:03:37.190 be added to the root store. If they aren’t added, browsers won’t trust those websites. 00:03:37.190 --> 00:03:40.430 GERVASE: There are four major root stores. There’s us, there’s Microsoft, there’s Apple, 00:03:40.430 --> 00:03:45.050 and there’s Google. The criteria that we have for CAs to be included will include 00:03:45.050 --> 00:03:51.110 particular audits which try to demonstrate that the CA is acting in accordance with 00:03:51.110 --> 00:03:55.250 the relevant security guidelines. The auditors will come in and check 00:03:55.250 --> 00:03:58.910 that and they will be able to present those audits to lots of different root programs. 00:03:58.910 --> 00:04:02.810 JACK: Gervase and his team are in charge of deciding which CAs are trustworthy and which 00:04:02.810 --> 00:04:08.150 aren’t. This is an extremely important job. He is like, the security guard for the internet 00:04:08.150 --> 00:04:13.280 looking out after everyone who uses Firefox and making sure the organizations that are in 00:04:13.280 --> 00:04:19.160 the trusted list are safe for the world. Think about it this way, if you use Firefox then you 00:04:19.160 --> 00:04:23.390 are trusting that this man, Gervase Markham, knows which organizations can be trusted. 00:04:23.390 --> 00:04:25.760 GERVASE: It’s not just me. There are three of us who currently work on 00:04:25.760 --> 00:04:31.640 the CA program but Mozilla runs the only fully open and transparent root program. 00:04:31.640 --> 00:04:35.900 JACK: Gervase thinks this kind of decision making should be open to the public so they 00:04:35.900 --> 00:04:40.550 can see the decision process and even give input into help make the decision. That’s what 00:04:40.550 --> 00:04:44.930 he means by saying his root program is open and transparent because as you can imagine, 00:04:44.930 --> 00:04:48.920 deciding which certificate authorities are trustworthy is a difficult task. 00:04:48.920 --> 00:04:53.180 GERVASE: Trust is an organic thing, right. Trust is not something that results from coming to the 00:04:53.180 --> 00:04:59.660 end of a checkbox. If we read a news article that says, for example, the government of Kazakhstan 00:04:59.660 --> 00:05:06.050 is considering manning-in-the-middle all of its citizens and then we receive an application from 00:05:06.050 --> 00:05:10.520 the government of Kazakhstan to include their root certificate in the browser, even if all of 00:05:10.520 --> 00:05:17.360 the paperwork is in place we might be somewhat reluctant to add that root certificate to our 00:05:17.360 --> 00:05:21.860 browser because we have external information about what that government may be wanting to use that 00:05:21.860 --> 00:05:28.040 certificate for. There is the question of the reputation of the organization who is applying, 00:05:28.040 --> 00:05:35.540 as well. It is not just a simple checklist but we do try and have criteria that at 00:05:35.540 --> 00:05:39.380 least – vaguely objective so that CAs know what they have to do in order to be included. 00:05:39.380 --> 00:05:42.890 JACK: But there’s a few problems with this whole approach to using 00:05:42.890 --> 00:05:47.000 root stores and certificate authorities. Security researchers are still trying 00:05:47.000 --> 00:05:49.790 to find better solutions to this problem. One issue is… 00:05:49.790 --> 00:05:53.840 GERVASE: Is that the certificate system had a weakest link problem. That is to say, 00:05:53.840 --> 00:05:59.180 if you trust 64 different organizations and one of them has sucky security, 00:05:59.180 --> 00:06:04.910 then you have a problem. It doesn’t matter if your particular site uses one of the other 63 00:06:04.910 --> 00:06:09.500 because the attacker can get a certificate from the dodgy one and then impersonate you. 00:06:09.500 --> 00:06:15.470 JACK: That is, if one of the 64 organizations were to be hacked it ruins the trust for all 00:06:15.470 --> 00:06:22.310 other CAs. Basically the hacker would then be on the trusted list. The security of CAs 00:06:22.310 --> 00:06:31.280 has to be top-notch and impenetrable. Comodo is one of the largest CAs in the world. They 00:06:31.280 --> 00:06:37.130 issue certificates for millions of websites around the world and in early 2011 they were 00:06:37.130 --> 00:06:43.520 hacked. [MUSIC] The hacker issued nine fake certificates but Comodo immediately detected 00:06:43.520 --> 00:06:48.170 this and revoked the certificates. A few days later Comodo had fixed the problems 00:06:48.170 --> 00:06:52.340 and publically announced that an intrusion took place, but a few days after that, 00:06:52.340 --> 00:06:58.340 a second intrusion took place. But this time the hacker was unsuccessful. All attempts at 00:06:58.340 --> 00:07:03.440 doing anything failed. [MUSIC ENDS] The hacker was able to get into the network but couldn’t take any 00:07:03.440 --> 00:07:08.630 steps beyond that. They were unable to issue any certificates or do anything significant. 00:07:08.630 --> 00:07:16.590 Then we see a strange post show up on Pastebin. Pastebin is a website where anyone can post a 00:07:16.590 --> 00:07:22.260 message anonymously. This message was written by a person named Comodo Hacker and it reads, 00:07:22.260 --> 00:07:28.290 quote, “Hello. I am writing this to all the world so you know more about us but first I 00:07:28.290 --> 00:07:33.390 want to give some points so you’ll be sure I’m the hacker. I hacked Comodo from instant SSL. 00:07:33.390 --> 00:07:39.630 Their Comodo username/password was GT admin and global trust. I am not a group. I am a single 00:07:39.630 --> 00:07:45.210 hacker with the experience of 1000 hackers.” End quote. The message goes on to explain more 00:07:45.210 --> 00:07:50.490 on how he got in and what he did. At the very end he writes in Persian, “I will sacrifice my 00:07:50.490 --> 00:07:55.650 soul for my leader.” Five days later Comodo announces the second intrusion but mentions 00:07:55.650 --> 00:08:00.150 the hacker was unable to do anything and they fixed the holes in their network. Overall, 00:08:00.150 --> 00:08:04.950 Comodo handled this issue fairly well. They quickly detected and fixed the issue and 00:08:04.950 --> 00:08:11.880 notified the public. Comodo isn’t the only CA. Another popular one is DigiNotar. It’s a 00:08:11.880 --> 00:08:17.220 Dutch-based company and they started out in 1998 doing notarizations in Netherlands. Eventually 00:08:17.220 --> 00:08:21.810 they became a respectable CA. In fact, the Dutch government used DigiNotar as the CA 00:08:21.810 --> 00:08:29.100 for many of their websites. In early 2011 VASCO bought DigiNotar for almost 13 million dollars. 00:08:29.100 --> 00:08:34.590 JOSEPHINE: DigiNotar I think is a case that had really invested heavily into security, 00:08:34.590 --> 00:08:36.540 as you have to if you’re a certificate authority. 00:08:36.540 --> 00:08:38.370 JACK: That’s Josephine Wolff. 00:08:38.370 --> 00:08:42.420 JOSEPHINE: I’m an assistant professor in the Public Policy and Computing Security 00:08:42.420 --> 00:08:45.090 Department at Rochester Institute of Technology. 00:08:45.090 --> 00:08:49.005 JACK: She recently published an article and slate in regarding DigiNotar. 00:08:49.005 --> 00:08:52.980 JOSEPHINE: The network was set up only with all of these segments, with the public facing, 00:08:52.980 --> 00:08:58.380 the external net, and the DNZ internal, and then the several layers beyond that but they 00:08:58.380 --> 00:09:02.670 also had physical controls in place. Once you’re into the most secure portion of the network, 00:09:02.670 --> 00:09:07.830 if you then want to actually access the production servers that are used to issue certificates, 00:09:07.830 --> 00:09:13.320 you had to get to these computers that were stored in a room that’s something 00:09:13.320 --> 00:09:18.420 out of a James Bond movie. There are two sets of doors, there’s a hand-recognition device, 00:09:18.420 --> 00:09:24.220 and a pin code, and you have to insert an electronic key card in order to actually 00:09:24.220 --> 00:09:29.500 begin the certificate-issuing process. There are several levels of security that 00:09:29.500 --> 00:09:33.640 ostensibly you have to get past in order to issue a certificate in this setup. 00:09:33.640 --> 00:09:38.890 JACK: DigiNotar knew security was vital to the reputation of the company and invested 00:09:38.890 --> 00:09:43.210 heavily in its own security. I like to sometimes think of securing a network 00:09:43.210 --> 00:09:48.100 similar to securing a castle that has ten thousand doors and windows. Even 00:09:48.100 --> 00:09:52.390 if you spend the time to go check every door and window to make sure it’s locked, 00:09:52.390 --> 00:09:58.600 you may have missed one or may not be aware of one and over time you’re bound to make a mistake and 00:09:58.600 --> 00:10:04.990 leave a door unlocked. Maybe because you were lazy or distracted, but humans make mistakes. 00:10:04.990 --> 00:10:12.081 In the summer of 2011, DigiNotar made such a mistake and a hacker entered their network. 00:10:12.081 --> 00:10:19.060 JOSEPHINE: [MUSIC] The breach begins by the perpetrator actually connecting to the public 00:10:19.060 --> 00:10:23.050 facing web servers that DigiNotar has up. It’s a little bit out of date. There are 00:10:23.050 --> 00:10:28.900 some patches that they haven’t updated in the content management software. The perpetrator 00:10:28.900 --> 00:10:33.430 connects to their web servers, takes advantages of some of those out of date vulnerabilities, 00:10:33.430 --> 00:10:39.520 and uses those vulnerabilities to tunnel through this incredibly extensive set of 00:10:39.520 --> 00:10:44.530 firewall rules into what’s supposed to be the most secure silo of their network. 00:10:44.530 --> 00:10:49.360 JACK: The hacker eventually made his way to the server that issues certificates but 00:10:49.360 --> 00:10:53.050 DigiNotar had a security check in place, where a physical key 00:10:53.050 --> 00:10:57.250 card had to be present in the computer before a certificate could be issued. 00:10:57.250 --> 00:11:01.660 JOSEPHINE: It turns out that there’s a key card, we think, that’s actually being left in 00:11:01.660 --> 00:11:07.600 permanently. Not just out of laziness but because DigiNotar wants to be able to automatically 00:11:07.600 --> 00:11:13.450 generate what are called certificate revocation lists. Every time a certificate becomes untrusted 00:11:13.450 --> 00:11:20.180 or out-dated or is being revoked for some reason, DigiNotar wants to be issuing automatic lists of 00:11:20.180 --> 00:11:24.350 those certificates so that all of the browsers that trust DigiNotar’s certificates will stop 00:11:24.350 --> 00:11:29.660 trusting those particular certificates. In order to issue those lists, you need to 00:11:29.660 --> 00:11:35.120 have one of these cards inserted into one of the secure servers in this room and so because it’s 00:11:35.120 --> 00:11:41.180 just being left in there, it turns out that all of these layers of security which seem like overkill, 00:11:41.180 --> 00:11:47.480 are able to be bypassed. The intruder is able to issue a bunch of rogue certificates in the 00:11:47.480 --> 00:11:53.480 names of a whole variety of different domains. The big one that comes up are the Google.com 00:11:53.480 --> 00:11:59.660 certificates but I believe there are also cia.gov certificates being issued and many, many others. 00:11:59.660 --> 00:12:05.030 JACK: With these certificates the hacker can now become Google. They can trick the browser 00:12:05.030 --> 00:12:10.160 into believing they are google.com. That is because DigiNotar was one of 00:12:10.160 --> 00:12:15.260 the trusted CAs within the browser. This breach took place on July 10, 00:12:15.260 --> 00:12:27.050 2011 and he ended up issuing 531 rogue certificates. Nine days later DigiNotar 00:12:27.050 --> 00:12:32.150 detected the breach but they didn’t announce it publically. Over a month later is when 00:12:32.150 --> 00:12:36.530 the Google forum post showed up about the man in Iran who couldn’t get to gmail.com. 00:12:36.530 --> 00:12:42.170 JOSEPHINE: The people in Iran who were trying to connect to their Gmail accounts are being 00:12:42.170 --> 00:12:48.710 redirected that directs them to the wrong website that probably looks exactly like the real Gmail. 00:12:48.710 --> 00:12:55.490 Because they’ve got these rogue certificates issued by DigiNotar, the people who created this 00:12:55.490 --> 00:13:00.860 fake Gmail or Google website are able to actually sign it and look like it’s really authentically 00:13:00.860 --> 00:13:05.090 a Google site. But because they’ve got this rogue certificate, they’re able to do that, 00:13:05.090 --> 00:13:09.800 people are going to what they believe are Google sites, entering their credentials. 00:13:09.800 --> 00:13:14.810 We suspect those credentials are then being used to spy on their Google accounts in various ways. 00:13:14.810 --> 00:13:19.130 JACK: The hacker then took these certificates and proceeded to create a man-in-the-middle 00:13:19.130 --> 00:13:24.170 attack. This is where a hacker intercepts the traffic that’s supposed to go somewhere 00:13:24.170 --> 00:13:28.730 else. The rogue certificates is only half of what’s needed to do a man-in-the-middle 00:13:28.730 --> 00:13:34.460 attack. The hacker needs to redirect people to his server instead of the real Google servers. 00:13:34.460 --> 00:13:40.670 We don’t know exactly how he did this but the best theory with the most supporting facts is 00:13:40.670 --> 00:13:46.850 he did a DNS poisoning attack. A DNS server translates a domain like google.com to an IP 00:13:46.850 --> 00:13:52.040 address so routers can find where they need to go. He tricked the DNS servers in Iran 00:13:52.040 --> 00:13:56.990 so that anyone looking for google.com would be redirected to his IP instead. 00:13:56.990 --> 00:14:02.120 JOSEPHINE: There’s no definitive proof that that’s how the redirect happened. There’s circumstantial 00:14:02.120 --> 00:14:09.440 evidence that you can use to try and make that case. It’s possible that there’s an ISP in Iran 00:14:09.440 --> 00:14:14.660 that’s either complicit or has been compromised and is therefore redirecting traffic to these 00:14:14.660 --> 00:14:19.940 fraudulent sites. Another possibility is that it’s a very high level DNS server that has been 00:14:19.940 --> 00:14:28.310 compromised and is propagating those fake records down to the other DNS servers that rely on it in 00:14:28.310 --> 00:14:34.310 the hierarchy. Again, there’s a sense that the investigators have, just based on the evidence, 00:14:34.310 --> 00:14:39.530 that it’s probably not that because when they look at how many people are being redirected and when 00:14:39.530 --> 00:14:45.140 they’re being redirected is very bursty. That is, you see a big spike in the number of people being 00:14:45.140 --> 00:14:49.580 sent to the fake site and then it goes down, and then there’s a spike again which makes them think 00:14:49.580 --> 00:14:54.140 that it’s probably not poisoning happening at a high level. It’s probably some local 00:14:54.140 --> 00:14:59.750 DNS servers being flooded with messages that look like they come from high level trusted 00:14:59.750 --> 00:15:05.210 DNS servers but instead are actually coming from the attackers saying here’s the correct updated 00:15:05.210 --> 00:15:11.570 DNS record for google.com. That will only last a certain period of time because then that DNS 00:15:11.570 --> 00:15:16.700 server will get the correct record from the higher level DNS server so then it will start sending 00:15:16.700 --> 00:15:20.570 people to the right site again. The attacker would have to come back and poison it again. 00:15:20.570 --> 00:15:25.130 JACK: Over 300,000 people from Iran visited the rogue server. 00:15:25.130 --> 00:15:30.010 This attack seemed to be targeting Iranian civilians. This attack would 00:15:30.010 --> 00:15:34.270 have went undetected for some time but Google had a clever way of detecting it. 00:15:34.270 --> 00:15:39.520 JOSEPHINE: They finally noticed because they’re doing this within the Chrome browser, which 00:15:39.520 --> 00:15:44.320 is manufactured by Google, and because Google owns the Chrome browser which is checking these 00:15:44.320 --> 00:15:51.280 certificates, and owns the website that they’re being used to imitate, the browser notices. This 00:15:51.280 --> 00:15:55.420 is a certificate that comes from a trusted certificate authority, right, Chrome trusts 00:15:55.420 --> 00:16:00.700 certificates issued by DigiNotar but we know it’s not the right certificate because we know what our 00:16:00.700 --> 00:16:05.920 Google certificates are. This is not one of them. JACK: This is why the guy in the Google forums 00:16:05.920 --> 00:16:10.990 had a server certificate error. Gervase over at Firefox was on the front line. 00:16:10.990 --> 00:16:16.630 GERVASE: Google notified us that they had detected a mis-issued certificate for starter, 00:16:16.630 --> 00:16:25.390 google.com which was being used in active attacks on users in Iran. We started investigating this. 00:16:25.390 --> 00:16:32.020 I basically took on instant response so I was very busy. In the case of DigiNotar, 00:16:32.020 --> 00:16:39.130 their network was thoroughly penetrated and had been for months. Their logs were a mess. 00:16:39.130 --> 00:16:44.890 Their infrastructure was a mess. There was no way of telling the scope of the 00:16:44.890 --> 00:16:50.560 compromise and therefore no way of containing it to a particular root or a group of root or 00:16:50.560 --> 00:16:59.110 intermediate or group of intermediates. Because of the catastrophic failures of security it was 00:16:59.110 --> 00:17:04.690 impossible to continue any form of trust in the DigiNotar systems and organizations. 00:17:04.690 --> 00:17:09.280 JACK: When Mozilla decided DigiNotar was no longer trustworthy, they removed them from 00:17:09.280 --> 00:17:14.410 the root store but users would have to update their browser in order to receive the version 00:17:14.410 --> 00:17:20.350 of Firefox that didn’t trust DigiNotar. All the other root stores also removed DigiNotar from the 00:17:20.350 --> 00:17:26.200 trusted list. Almost two months after the breach took place and well after Iran had been target 00:17:26.200 --> 00:17:31.060 of a massive man-in-the-middle attack, DigiNotar finally publically admitted they were breached. 00:17:31.060 --> 00:17:37.700 JOSEPHINE: Once this actually becomes a public compromise, then the Dutch government steps 00:17:37.700 --> 00:17:43.910 in and takes control of DigiNotar which is unprecedented in the history of breaches of 00:17:43.910 --> 00:17:50.690 private companies. Once that happened the company is, to a large extent, out of the picture. Their 00:17:50.690 --> 00:17:55.010 leadership is no longer making the decisions about hiring investigators and everything else. 00:17:55.010 --> 00:17:59.480 JACK: The Dutch government was using DigiNotar as their primary CA for numerous government 00:17:59.480 --> 00:18:04.730 sites and applications. When browsers began removing DigiNotar from the trusted root store, 00:18:04.730 --> 00:18:09.350 it broke a lot of systems for the Dutch government. They reached out to the root 00:18:09.350 --> 00:18:15.050 stores and asked to reinstate DigiNotar back into the root store. The browsers did add DigiNotar 00:18:15.050 --> 00:18:20.330 back as a trusted CA but to solve the problem of the rogue certificates, the root stores 00:18:20.330 --> 00:18:26.360 would block any certificates that were issued by DigiNotar after July 2011. This allowed the Dutch 00:18:26.360 --> 00:18:32.660 government to continue and work towards finding a new CA. Eventually the Dutch government moved 00:18:32.660 --> 00:18:37.970 to a new CA and within three months after the breach, DigiNotar was shut down permanently. 00:18:37.970 --> 00:18:45.200 JACK: DigiNotar hired a security firm called Fox-IT to conduct an investigation as to what 00:18:45.200 --> 00:18:49.550 happened. They found numerous problems in the DigiNotar network. They found the Windows domain 00:18:49.550 --> 00:18:55.250 administrator account had a simple password and was easy to brute force. Then all the certificate 00:18:55.250 --> 00:19:00.230 issuing servers were on a single domain. This means a single admin account was able to access 00:19:00.230 --> 00:19:06.410 all eight of their certificate servers. Numerous systems didn’t have antivirus present which would 00:19:06.410 --> 00:19:11.300 have stopped some of these attacks. There was no central logging and no separation of critical 00:19:11.300 --> 00:19:16.460 systems. A combination of all these failures is how the hacker was able to bypass all of 00:19:16.460 --> 00:19:21.770 the security checks. Fox-IT also looked through of the evidence to try to find who did this attack. 00:19:21.770 --> 00:19:28.220 JOSEPHINE: We don’t know who did this. Nobody’s been caught or prosecuted for this breach. 00:19:28.220 --> 00:19:33.800 JACK: It’s true, we haven’t been able to determine who did this but when Fox IT investigated the 00:19:33.800 --> 00:19:39.490 breach, they did find some interesting clues. First they looked at all the IPs the hacker 00:19:39.490 --> 00:19:46.780 used in the network. They were able to trace each IP back to a proxy except for one. This 00:19:46.780 --> 00:19:52.870 IP connected to the DigiNotar network from Iran and it was not from a proxy. It only connected 00:19:52.870 --> 00:19:58.270 for a few seconds and then disconnected. Then a new connection showed up from a proxy. This 00:19:58.270 --> 00:20:02.560 may have been a mistake by the hacker who then corrected himself very quickly. That 00:20:02.560 --> 00:20:09.250 IP was also seen visiting DigiNotar previously which may have been for reconnaissance. Fox-IT 00:20:09.250 --> 00:20:14.650 also found the hacker left a message on the server that was hacked. It read in part, quote, 00:20:14.650 --> 00:20:19.810 “There is not any hardware or software in this world exists which could stop my heavy attacks, 00:20:19.810 --> 00:20:26.110 my brain or my skills or my will or my expertise.” With a message at the end in Persian saying, 00:20:26.110 --> 00:20:31.330 “I will sacrifice my soul for my leader.” We also see a new Pastebin message show up 00:20:31.330 --> 00:20:36.190 from the person who claimed to have hacked the Comodo CA. This Comodo hacker now takes credit 00:20:36.190 --> 00:20:40.840 for also hacking into DigiNotar and also signs his Pastebin with the same message 00:20:40.840 --> 00:20:44.620 in Persian. He also goes onto say he’s twenty-one years old and works alone. 00:20:44.620 --> 00:20:48.490 JOSEPHINE: Certainly DigiNotar and the Dutch government gets very 00:20:48.490 --> 00:20:53.230 caught up in this because they’re the vehicle by which all of this happens, 00:20:53.230 --> 00:20:57.550 but the real target was espionage directed at Iranian citizens. 00:20:57.550 --> 00:21:04.030 JACK: But who would want to read the e-mails of Iranian citizens? The US has had conflicts with 00:21:04.030 --> 00:21:09.520 Iran so it could be suspect. Bruce Schneier, a prominent security expert says it may be the work 00:21:09.520 --> 00:21:15.790 of NSA or an exploit of NSA, but he says it’s mainly because of a leaked NSA document showing 00:21:15.790 --> 00:21:21.370 the NSA had access to DigiNotar. This theory isn’t very strong and has almost no other evidence, 00:21:21.370 --> 00:21:27.970 so who else would be targeting the general people of Iran? The Iranian government itself. 00:21:27.970 --> 00:21:36.340 To understand why, we need to dial back two years before the hack. In 2009 there 00:21:36.340 --> 00:21:42.520 was a presidential election in Iran. Mamoud Ahmadinejad won the election by 63 percent vote 00:21:42.520 --> 00:21:46.480 but there was a strong opposition to this. Many Iranians believed the votes had been 00:21:46.480 --> 00:21:51.550 tampered and the election was rigged. Protests began immediately. This created a divide among 00:21:51.550 --> 00:21:55.360 the people of Iran. Some people became extremely distrustful of the government 00:21:55.360 --> 00:22:00.850 while other people became extremely loyal. Police began arresting protesters and when protesters 00:22:00.850 --> 00:22:05.170 didn’t leave they were pepper-sprayed, hit with batons, and sometimes shot at. 00:22:05.170 --> 00:22:12.730 Within three months of the election, seventy-two protesters died. Corruption was so bad, the police 00:22:12.730 --> 00:22:17.410 forced families to sign papers saying their dead relatives died of a heart attack and not by police 00:22:17.410 --> 00:22:23.950 brutality. As you can imagine, this only incited even more emotion among the people of Iran. For 00:22:23.950 --> 00:22:28.510 years after, the Iranian government worked hard to eliminate any government opposition. 00:22:28.510 --> 00:22:35.320 This continued all the way to when this DigiNotar attack took place. It’s a strong theory that this 00:22:35.320 --> 00:22:40.630 hack was done by the Iranian government itself or someone trying to help the Iranian government. 00:22:40.630 --> 00:22:45.580 They were possibly looking through e-mails trying to find dissidence and those who were unhappy 00:22:45.580 --> 00:22:51.730 with the Iranian president. If they were found it may have resulted in people being arrested, 00:22:51.730 --> 00:23:01.120 tortured, or killed. Certificate authorities and browser developers have learned some 00:23:01.120 --> 00:23:06.640 serious lessons from DigiNotar. Audits have become more strict for CAs to pass in order 00:23:06.640 --> 00:23:12.040 for them to be accepted into root stores. Public key pinning has seen more use. This 00:23:12.040 --> 00:23:16.930 is what Google did with their Chrome browser to detect this breach. They forced Chrome to 00:23:16.930 --> 00:23:22.690 only accept certificates issued from Google’s CA, essentially pinning the certificate to a specific 00:23:22.690 --> 00:23:29.140 CA. More websites have done this since DigiNotar but it has its shortcomings. For instance, 00:23:29.140 --> 00:23:32.890 imagine the problems a website would have if they pinned their certificate to a CA 00:23:32.890 --> 00:23:37.480 that went out of business, or imagine if a hacker were to pin a certificate to a rogue 00:23:37.480 --> 00:23:45.160 CA. Unpinning the certificate is currently a complicated task. Since DigiNotar, Firefox 00:23:45.160 --> 00:23:49.870 has added a new feature to help block rogue certificates. Here’s Gervase to tell us about it. 00:23:49.870 --> 00:23:53.800 GERVASE: We have a system called OneCRL which is, if you like, 00:23:53.800 --> 00:24:01.540 an emergency revocation system. Firefoxes all check for certificates on this black 00:24:01.540 --> 00:24:06.760 list every twenty-four hours. If we need to do an emergency revocation of either an individual 00:24:06.760 --> 00:24:12.730 certificate or in fact an entire tree of certificates based off one intermediate, 00:24:12.730 --> 00:24:17.920 then we can put it into OneCRL and within twenty-four hours every Firefox which has 00:24:17.920 --> 00:24:22.480 this system, and we’ve had it for quite a while now, will no longer trust those 00:24:22.480 --> 00:24:27.640 certificates. It’s not required to install an update in order for us to distrust something. 00:24:27.640 --> 00:24:34.270 JACK: When a hack takes place it does worldwide scale. It changes the way we do security. In a 00:24:34.270 --> 00:24:39.130 way, hackers are like the immune system of the internet. They infect us, we get sick, 00:24:39.130 --> 00:24:45.730 we get better, and we become even stronger afterwards. Even today, six years later, 00:24:45.730 --> 00:24:52.300 when a major breach happens to a company, someone always reminds us of the fate of DigiNotar. 00:24:52.300 --> 00:24:53.448 [OUTRO MUSIC STARTS] 00:24:53.448 --> 00:25:01.230 JACK: Thank you for Josephine Wolff for telling us about DigiNotar and a great big 00:25:01.230 --> 00:25:01.885 over-the-top thank you to Gervase Markham for coming on the podcast because about a 00:25:01.885 --> 00:25:02.583 year after this episode original aired, Gervase passed away. At twenty-two he was diagnosed with a 00:25:02.583 --> 00:25:02.685 malignant salivary gland cancer and after battling it for eighteen years he passed away at the age of 00:25:02.685 --> 00:25:03.059 forty. Gervase made significant contributions to securing Firefox and the Bugzilla tool. We have 00:25:03.059 --> 00:25:04.320 him to thank for keeping us safe in this unsafe world. We’re going to miss you, Gervase. Music 00:25:04.320 --> 00:25:07.200 is provided by Ian Alex Mac and Kevin MacLeod.