 Good morning, everyone. Our next speaker will be talking about TLS decryption attacks and backdoors to secure systems. Let's all welcome Mr. Chris Hinlen. Welcome to TLS decryption attacks and backdoors to secure systems. What we're going to be covering today is how weak authentication creates backdoors in modern security systems. We're going to be covering how state-sponsored attackers have already exploited those weaknesses. We're going to be talking about ways that you can copy their exploits and ways that you can build on their exploits and do more advanced attacks than what nation states have been caught doing. I suspect that some of them have already used these approaches, but they haven't been caught for quite a few of them. So a little bit about me and why you might want to listen to me. I've been configuring and protecting desktops and servers since 1998. I run a small business helping companies secure their infrastructure and their software development lifecycle. I have a few accepted phones starting with a file system phone in the Linux kernel a long time ago, followed by a couple of Google apps vulnerabilities, one of which got me into the Google Security Hall of Fame. I'm also on the organizing committee for B-Sides Vancouver Island and a totally shameless plug I'd like to encourage you all to try and buy the last eight tickets because there's only about eight tickets left and I'm hoping to see you there. You really need to get permission before doing these attacks or practicing any security testing. I don't want anyone here to go to jail and the laws vary from region to region. So make sure you have appropriate permission for your region and the regions of any machines that you're hoping to test or break into. So TLS was explicitly invented to prevent man in the middle attacks. It even says in early specs from about 1994 what a man in the middle attack is where there's three parties on the conversation, theoretically more, and that a bad guy sits between the client and the server on the network, intercepts the traffic, and effectively pretends to be the server. According to the specs, demand in the middle, oh, sorry, with SSL these attacks are impossible because of server certificates. The spec goes on to more reasons why they would be very difficult, but it depends on server certificates. And that is how attackers decrypt TLS encrypted traffic because many certificate authorities are willing to accept plain text authentication for domain ownership. So this means the plain text authentication makes certificate generation vulnerable to the exact attacks that certificates are supposed to prevent. Attackers then exploit the plain text communication and obtain certificates for domains they don't own and trick users into thinking they're the real server. So how do we know that attackers have decrypted TLS encrypted traffic? Well, the US government issued instructions to various government organizations on how to fix the problem. FireEye had some great details on all the ways the attacks happened and there's been many other, I believe this is a Cisco Talos that one, many other organizations commenting on it. It's hot outside and I'm thirsty. Oh, I think I went back one. So if you wanted to copy them, you could intercept the DNS traffic on the way from the CA to the DNS server for the domain you wanna attack. You could intercept HTTP traffic, SMTP traffic or different DNS traffic. And a lot of people might go, Chris, these all sound like the exact same thing. So I'm gonna leave the top part on there and I'm gonna explain why they're not. Let's say someone was trying to attack the city of Seattle's infrastructure. They have several options. They could attack the, or intercept traffic near the primary DNS server, which appears to be in New York, or near their mail server, which appears to be in Wyoming, or near the web server, which is in Seattle, or near the mail provider. So that would be Office 365's name servers. So these are totally different networks, totally different locations, where the same approximate type of attack can be launched. From the attacker's point of view, they might not just be targeting one domain. They might be trying to get as much data as they can. So if they break in upstream from the name server, there's thousands of domains they can get certificates for. If they break in upstream from Office 365, same thing, and so on and so forth for the other locations. So how would an attacker break into a router? We've seen several firmware vulnerabilities released. We've seen hard-coded passwords. There have been some compromised telecom companies and just this week we saw that AT&T staff had been accepting bribes to infect their own network. Now, sometimes there's alternatives. You don't wanna do those, cause you might get caught. So we've seen quite a few BGP attacks where traffic gets redirected to a different country than it was supposed to go through. You could, if you had say a search warrant, tap the least lines the traffic goes over. If you were wanting to attack a workplace that you had a connection on, you could use art poisoning within there and that approach works to get a certificate for that host's domain name. So people can use that to, a lot of companies will have like vpn.companyname.com or mail.companyname.com that points to the office network. If you were already inside the network, you could use that to get a certificate for their resolvable domain name and then start intercepting VPN traffic. Later on, I will be encouraging the audience if anyone wants to help with that and do a video on that, I will promote your work. You do have other options too. In the case of the successful attacks by the government of Iran or people who seem to be sponsored by them, they were breaking into name servers, domain registration servers, and mail servers are also an option. So most of the time, when I'm talking about breaking into a router, I'm not talking about your home or office router. I'm talking about moderately big routers all the way up to very big routers that may not fit in a single rack. So we're gonna start, this is a very basic attack. If the router was running Linux, you'd just be setting up network address translation. I like to use environment variables for the victim and the attacker or the machine you wanna attack and then that command, because there's colon 53 at the end, it means that it's redirecting DNS traffic. No other traffic's being redirected right now and you can play around with that. If you wanted to, you could only redirect traffic from certain sources so that you were less likely to get caught because the people monitoring that traffic aren't on those IPs. We're setting up a super basic name server on the attack machine that provides new results to anyone querying them. Once we have those new results, we request a certificate from Let's Encrypt. I only have the examples with Let's Encrypt but I've successfully launched the exact same attack against Komodo and GoDaddy, both of whom set the standards for other CAs. CAs are certificate authorities. We test it and many browsers happily mark the site as secure. I chose Firefox because they even use a green lock whereas the other ones have phased out the green locks on secure sites. If we wanted to do it with HTTP, it's pretty much the same. It's just port 80 instead of 53 and for SMTP you're just switching the port again to 25. So we did configure a basic interception mail server. The main important thing is that we put a star in for host names so it intercept all email traffic. Now in this case we did a total fail. We hadn't gotten any certificates for the domain yet but that would only take a minute or two to cover your tracks. Unfortunately, very few organizations verify the certificate or require a certificate when sending confidential data. Kind of covered this one. So quick notes about the email interception. I didn't break into any mailboxes. I'm just sitting on the wire intercepting the mail. If you wanted to avoid detection, I'd highly recommend using a proxy server and relaying most of the traffic to the intended destination. I would probably skip anything mentioned in the words password reset or maybe even skip emails from the certificate authorities so the evidence of your attacks doesn't make it through to the destination mail server. So once we were intercepting email, what we noticed was that a lot of providers would send unencrypted usernames of their users. We were able to intercept the usernames and it went on and on and on. Now I saved all these results in a mailbox to make it easy for me to work with but we haven't broken into anyone's mailbox. This is just the results we got of all different organizations telling us usernames on their systems and in a moment we're gonna try and reset the passwords for those accounts. So this one's AWS, AWS didn't require TLS even though the user signed up with an encrypted connection. So they could have saved a record, this user mail server supports encrypted email but they chose not to. So here we are breaking it, intercepting a username, requesting a password reset link and breaking into a real estate company Cisco Miraki account using the same attacks we've talked about. This is a really big deal because once you break into their Cisco Miraki account you can add VPN connections into their office. You can add port forwarding, you can change the rules that segregate their network and stop certain machines from attacking other machines. It's a gold mine if you can intercept email near Cisco Miraki customers. Kept going and going and going. In the end we got into, we used the interception attacks to reset passwords on Cisco Miraki, firewalls, Google Nest, security cameras, AWS, Dropbox, OneDrive, Salesforce, LogMeIn, Carbonite, pretty much every system you can think of. In a lot of cases we're also able to bypass full disk encryption using these attacks because both Windows and Apple encourage users to set up their cloud account to be able to reset the password on their full disk encryption. So I sort of mentioned in the email portion you really wanna use a proxy to cover your tracks. That's a little beyond the scope of this presentation but if anyone wants to I'm happy to help you get a video going on the proxy style attacks. You can even use my attack server if you want to. So some of you might wanna protect a business from these attacks. I would strongly recommend getting certificates from a CA that doesn't support domain authentication. Some of the CA's that are focused on organizational validation only do org level certs and then you can at least test that the certificates are from that certificate authority. Monitor for certificates generated from your domain. Facebook has a feature for this. This is even recommended by the government. If someone generates a cert, you get an email letting you know. You also get a Facebook notification just in case that person is sitting near your mail server blocking the messages telling you that your fake CA was generated or fake certificate. If you see any fraudulent certs you gotta revoke them right away. You probably need to do a full investigation into how it was generated, how you're gonna prevent it. I'd love to see people in the room fighting for stronger domain authentication standards and you'll probably need to automate testing of your DNS records so you know when they're being manipulated. So how could certificate authorities stop these attacks? They could use the same technologies that they're encouraging for HTTPS on all steps of the validation process. DNS, SMTP, just have mandatory TLS when validating domain ownerships. They could, I would suggest checking all name servers when authenticating a domain. That way if one of them was compromised they would have to compromise all the name servers to use that compromise. To make sure that the name servers that are validating these requests aren't using fake certs that were generated today, yesterday or up until the problem is fixed I'd require organizational validation on the name servers. And in the event that the certificate is no longer has its authentication values sitting on the name server I would set the CAs up to automatically revoke those certs. The only CA that I know of who's doing that right now is Amazon. If you have a cert in place with Amazon they recheck your DNS values to make sure that you still have the value proving your domain ownership and they give you a warning if it disappears I know because I deleted one of those values and then you have a chance to put it back. So I'd love to see the browsers putting pressure on CAs to protect their users and even domain owners. If the site doesn't support encrypted DNS I'd start with a mild not secure message. Not the big red message but just put a little pressure on people because we know that those messages in Chrome get action from customers. Similarly, if they don't support encrypted email warn the user this isn't a site that takes security seriously and it's a lot of government sites that don't support encrypted email because some of the firewalls they use for spam filtering it's block encrypted email by default or block transport layer security on the email. So I think the users visiting those sites should know that the site isn't taking security seriously and it not to trust the site. NECAs that are continue to use plain text authentication to prove domain ownership I would refuse to trust them and then as new standards become more common I would warn users about sites using old certificates that don't meet the modern standards. And that last one of warning I haven't seen it at the browser level but the payment card industry requires that you have a properly generated cert in terms of the random numbers that were used. So I'm hoping that the payment card industry and the web browsers could expand towards warning people about other weak authentication. The main message of today is that weak authentication provides a backdoor to many secure and encrypted systems. If anyone here wants to build on the work I'd love to help you make videos using Cisco or Juniper routers as part of the simulation. I'd love to see an ARP cache poisoning video videos of proxies and other open source tools being used to reduce the risk of being caught. There's quite a few people I need to thank. My friend Adam Bennett helped with a lot of the account creation. John Seymour was my mentor at the Beesides Las Vegas Proving Ground last year and he helped me get some of this ready. Jerry Desim of Micro Focus. He had some related CVs he accepted my LinkedIn in mail and helped me find a lot of resources that helped. Chris Kubeca, she provided some awesome research about a year ago on email interception attacks and the Okanagan Information and Security Group let me practice when I was nowhere near ready and that was very helpful to getting ready. If any of you want to connect with me I'm on Twitter at Chris Hanlon CA. You got an email that will work for a while to reach me. If I get too much spam there I'll probably drop it but works for now and I'd give you my real email if you email me on there. In terms of following me on Twitter if your profile says Infosec or Noob I will follow back. You may wonder why I follow Noobs but I think that they're the future of the industry so anyone who admits that they're a Noob I will follow them. Does anyone have any questions? Yes? We've got a mic for questions. So if you have questions come and line up up here by me and I'll be happy to hand you a mic so everybody can hear you. Is there anything you can do from like the service provider standpoint when if you're concerned that say your password reset emails are getting intercepted in this way or like, you know. Yes. Two-factor authentication is probably your best bet and it needs to be real two-factor because I've found some where they have a downgrade to email and if there's an option to reset the password via email along with an option to get the two-factor token via email that's not two factors. That's one factor twice. So you mentioned one of your suggestions for mitigation was we'll do TLS on everything, right? With TNS and TLS when we're doing the domain validation. So is the suggestion there that just like, so we have to bootstrap our trust from somewhere when we've got a new server so you're saying we'll use some trusted thing where we, because you need it, if you want to do mutual TLS you need to start on both sides already so are you saying we'll just bootstrap our trust from somewhere else where we already have an existing trust? I guess the big thing is, I also asked that the name servers have to have an organizational validation so that typically involves proof that you run the organization which is done offline and there's a relatively limited number of name servers compared to the total number of domains so our trust I guess would be in notaries, lawyers and similar people to prove ownership of name servers. Sounds good, thanks. You mentioned on some of the redirects attacks, I could see how you're doing that if you're already inside the network but functionally or like practically how could that be done from the internet or like on the other side of the world? There's been quite a few firmware vulnerabilities and major routers. There's also the element of insiders at the telecom companies either being bribed or just realizing the potential for money and we have seen the BGP attacks where like millions of dollars of cryptocurrency was stolen from one of them so that and even in the last few months we've seen standard network traffic being redirected through China that was intended to go between the EU and the US so it does happen. Would you agree that if on the firmware argument if you just kept up to date with patches that would lessen your vulnerability? It definitely lessens the vulnerability of the ISP but users don't know how good their customers including government customers don't get a great idea of how well their network presence provider is monitoring for intrusions or keeping their stuff up to date and I think that's really you don't know how well your ISP is doing but it only takes a one time mistake for a huge amount of damage and the whole point of encrypted connections was that we didn't need to trust the certificate authorities. Thank you sir. Or sorry, we didn't need to trust the internet providers. A few years back we used to have extended domain evaluation certificates where the browser is to display like a green bar and it disappeared and so from a consumer point of view doesn't understand cryptography that's using the browser to go to a bank or something like that. There's no difference between some certificates that's gone through extended validation to make sure they're the owner of the certificate but somebody who went to let's encrypt and maybe got a free certificate, right? So why there's no distinction between now I should be able to know as a consumer whether you know how trustworthy it is like a green bar for example. The big reason why those got pulled out is that criminals were getting certificates that met the green bar standard and users who didn't really understand the system put a lot of trust in the green bar. So I think we're moving in a direction of warning when things don't meet good standards with warnings about insecurity rather than trying to guess how secure someone is. If I am a city bank for example, right, I have to really prove that I am really a representative bank that's how to say criminal kind of have the credentials to actually prove like a physical online message to make sure that you are the owner of the domain or something like that. I suppose just an email saying that I own it. Yeah, so that's why we need higher standards on the verification of domain ownership. Would DNS sec provide any form of mitigation or would that just be another attack vector to abuse in this case? DNS sec would likely help but because TLS is on so many protocols I think that DNS over TLS is more likely to gain market share. Thank you very much indeed. Just a quick comment on your previous answer about extended validation certificates. It wasn't so much that users were putting a lot of trust in them and therefore if a, as you mentioned, criminal was able to get hold of one incorrectly it was too powerful. Research was showing that nobody noticed them. Even those people with training and there are some instances for example, a large financial institution through a misconfiguration was failing to serve EV certificates for quite a while and nobody noticed. So they were only adding to confusion with no benefit that number of studies could measure. But you are the point to perfectly correct. Thank you. So what is your recommendation for the next step? You discover that your domain has a rogue certificate issued when certain certificate authorities such as let's encrypt have an explicit policy against revoking certificates that have been determined to be rogue. I was not aware about the failure to revoke let's encrypt. Those ones are only good for three months but you're going to need to investigate how they got that certificate. To some extent you're also going to need to prevent the traffic from getting there but I didn't know that let's encrypt wouldn't revoke. Thank you. Any further questions? Do you share the presentation slides? I will. Okay. I'll tag the crypto privacy village with a link to the slides. Or actually do people, oh. I might have a way to show them right away so you can take pictures. No, well I guess that is a public link. It's pretty long to type. But I was planning on using a little clicker thing and there's radio frequency attacks against them so I went into a lockdown account and this is the public link to the presentation slides but I'll tag the crypto privacy village with a short one very shortly. Any final questions? All right, one more big and random applause for Chris. Thank you.