PG - Black Magic and Secrets: How Certificates Influence You - Robert Lucero

hi everybody um cool well welcome to my talk um it's called Black Magic and secrets how certificates influence you uh I'm Robert lero uh my mentor is Andrew Case who helped me get through uh all the fun parts of putting together a presentation and presenting publicly so uh I chose this title for my talk because certificates are kind of confusing if you don't really work with them all the time and and basically they're everywhere so anytime that you're using a web browser to connect to a secure SSL htps website you're using a server certificate you might not even realize that you're using server certificates behind the scenes when you're authenticating to third parties and it's just a critical part of our

security infrastructure so uh a little bit about me um I'm a physics major turn software developer um I've been working in software development for the last eight years and my first feature was actually working on um is Management's UI server certificate feature which is a way to make certificate requests generate self-signed certificates uh import signed certificates set up bindings uh and then in turn creating client authentication certificates and setting up client uh certificate authentication so I had an opportunity to learn a lot about them I continue to work in this space in my current job um it's really interesting challenging space it's critical part of what we use on the internet today so what I want to kind of go over

when I hope that you guys will take away from the talker two things uh number one is if you've never ever used certificates before hopefully you come away with kind of how they work or the ideas behind them and if you use Sears on a regular basis maybe you'll learn a couple ways to test exploit and maybe Identify some best practices with the certificates that you use or the systems that you uh use certificates that you work with on a daily basis so let's jump right into it um a public key certificate is basically an asymmetric cryptographic public key with a verification signature and the idea is that I can encrypt stuff with a public key and in addition to

that public key is a signature that you can ver ify to determine if you trust me or if I'm uh saying if I I'm trustworthy to encrypt with and the example is this is if I wanted to share secrets with everyone in the room I could give everyone locks that only I can open and you share back boxes and locks that only we can open that's the cryptography part but the challenging part is the the signature part the verification part how do you know who I am so even real life and kind of this public setting uh to determine my identity to verify my identity you can ask me for my license you can ask me in

person you can ask my friends you can look up online and there's various ways that you can verify my identity now with certificates you have a built-in systematic way with operating systems and phone osses to determine if a public certificate that you're using is is valid and the way that that works is it works through root certificate authorities which are installed automatically on your os's on your phones and they're globally trusted authorities so things like verisign diger Microsoft all have put certificates on your boxes for you to use um cool so why do they matter they matter because basically if you're using web communication this is the standard way to protect your web communication if

you're protecting a signin page you're probably doing it over htps uh if you're logging into a bank htps if you're communicating with a web API uh sensitive data it's probably over htps um and the other interesting thing about it is that they're implicitly trusted because you get the root Casa on your box automatically you have to go out of your way to remove those root authorities and if you do that you know you can't use a lot of things but the idea is that they're everywhere you use them everywhere and that's a way that you've implicitly trusted a system so let's look at a couple of examples on on how they work the ideas behind them here we have client to

server communication uh it's basically HPS and SSL and the things that use them are web servers and web browsers that's an example so you have Apache Microsoft's IIs enginex they have a server certificate and on the opposite side your client authentic or your client verification is in Chrome I.E Safari your web browsers and the clients are determining if they trust the endpoints and that's kind of one example uh beyond that people are using uh public certificates to uh encode data in Json web tokens so uh hiding certific or signatures and claims uh they're also used in API tokens so you encrypt a bit of data that you use as an authorization header and that's then used for

communicating over a web API um beyond that Beyond there just the encrypting communication it's also used for authentication uh if you've ever used client certificate authentication if you've ever requested one if you're use a badge that has your client sht built into it um that's one example another example is saml behind the scenes while you're communicating over saml you actually use a certificate um and it's also in other things like SSH authentication you can actually put a public keyy that's then automatically trusted by the host that you're trying to connect to and another kind of limited use example that I've seen um at a couple companies that I've worked at is that they encrypt data

using a certificate and then store it on the local uh file server or they store it in a database that they can then decrypt and use but it's the same idea same technology and there they're validating the trust so what makes certificates vulnerable I mean there are a ton of ways that you can bypass this tool that people use you can use you can forge identities of certificate you can forge Casa uh you can bypass the certificate systems Al together um you'll find out that if you're using test certificates in your development environments that's another way to get a hold and get past the public or the the production level deployments of certificates uh if I can

inject my own certificate Authority into your trusted store you now trust everything that I issue and the other part of it less of the trust more of the encryption portion of it is you can force people to use weak encryption or if I've set weak encryption for performance Reasons I'm basically uh putting myself at risk for having my my secrets decrypted so take a look at exploiting all of this so there's two sorts of things that can be exploited one of them is the library so the things that are on the operating system things that are on your phone the other thing is is if you're doing custom implementations so if you're using certificates on a device

or on the phone application or on a rich desktop client application those custom implementations put you at risk the examples here this Library vulnerability Microsoft basically had a bug where um you could Forge and spoof certificates if they were improperly issued so again forging your identity of a of a signature and then in open SSL there's a way to force people to use a weaker encryption and at that point you can then brute force your way through to the to the secrets but if you're doing custom implementations all of this is handled not by a large company or uh an organization it's handled by the developers that you work with or yourself if you're doing development the

custom implementations are how do I handle certificates when I interact with them and there's a few examples up here that um I've seen and I've tested with and I've actually found myself writing bad code in those examples so let's take a look at some of the bad development practices now my experience is I've seen developers do a lot of these things uh I've seen developers explicitly write in code in debug blocks you know uh bypassing signature checks so I've also seen developers explicitly check in test certificates and have blocks of code that say if I see a test certificate just trust it implicitly um I've also seen developers leave HTTP active when they're protecting an

endpoint with htps so they're bypassing the H the the certificate system completely at that point so the idea is that libraries can't protect you if you've implemented it wrong systems can't protect you if you've implemented certificates incorrectly and what's at risk is everything that you're trying to protect so if it's uh your communication with your client if it's service to service within your organization if it's even things like issuing client certificates client authentication certificates you've basically exposed yourself to these sorts of vulnerabilities so what I'd like to do is I'd like to give you a basic overview of the demo um that I'm going to show you and the idea is this is that you

have a you have a client application a rich client application now this can be anything this can be uh a phone application this can be another web application it could be a service endpoint uh and the idea is that that client application the everything that they do their communication is dependent on endpoint trust so in this example there's no authentication it's basically talking to an endpoint and if it's trusted via SSL or https it's going to talk to it and everything's fine and in this case uh with this workflow The Client app is posting data to the evil web API the evil web API grabs the data stores it and then relays the data back

to the good web API and the good API the good web API does whatever it was supposed to do throws back a response the evil API can then do things with it and then our evil man in the middle then forges a response back so real basic man in the middle except there's no authentication and it's all based on um basically SSL and htps Trust so it's basically that um before we jump into the demo any questions kind of about [Music] this no Okay cool so let's jump right into it so I need just one moment to kind of prep all this so you guys can see it

oops keep changes okay so let's take a look at the browsers first off so here we are um I'm going to be using a tool called Postman Postman is basically a we Chrome plugin that lets you make web requests and you get to craft the requests um it's kind of like curl but in the browser um so let's take a look at the two uh endpoints so here we have the the good endpoint can you guys all read this yes great so here we have the the good endpoint if you look you'll see that Chrome is is connecting to the website and it's trusting it here it says identity verified it's got a little green lock everything's

cool um Chrome is is basically trusting the server certificate that I'm is I have issued for my endpoint and it gives some great information now if we take a look at the the evil web application you'll notice chrome doesn't like it so much it's got this nice X it's got htps with a big slash in it it's warning you uh if you look on it if you click on it basically says Hey the identity of this website has not been verified it does not match the URL it is not trusted what are you doing here that's kind of bad so the other thing is is I'll open this up in IE real quick kind of give you the other the

other half of it iie is going to love the the good endpoint you know it's trusted it's got a little lock everything's great and then if we look at the evil end point it gives a big warning um it says click here to close this web page that's the good option for uh clients and customers and the users of the browser and the red the bad action is to not is to continue to to go on and if I continue get this big red what are you doing I don't trust this endpoint I don't know why you're here um just recently browser started doing this you probably have started to see this happen more and more um it

wasn't up until about I would say four or five years ago did all the browsers start basically showing this error to you and start forcing you to make decisions if it didn't trust the certificate so now let's take a quick look at the um the API so the API it's fairly simple um if you're not familiar with web apis or you haven't done any development with it before um come catch me afterwards and we can talk more about it but all I'm doing is I'm getting some information from my trusted endpoint I have some sensitive data that's in there I have an ID I have a name I have a credit card which is my my sensitive

information and here you know we can we can post some data to it Robert Lucero and then my credit card number my my sensitive information and if I go back to to get the data I'll find out that it's stored everything's good um I've sent sensitive data over the wire and it's relatively protected so let's take a look at the rich client application so what I've written here and hopefully you guys can see this can everyone read this yeah cool so this this client application this Windows client this console application is representative of anything it can be a desktop application it can be a web application it can be a phone application but the idea is that I've

written some bit of code that now talks to a a web API and an SSL endpoint so let's just start it up so by default we're going to we're going to connect we're going to send some sweet data over the wires so Sally Ides give it an ID give some sensitive information like a credit card number um debugging sent it now let's go back and let's go take a look at the the the endpoint let's go do a get on that that web application you'll see you know Sally bides got added it's kind of down towards the bottom there so what happens when I I force my clients to start connecting to other endpoints was is one way that they can

protect themselves so there's lots of ways that we can force clients to do bad things things like fishing attacks things like uh malware misconfiguration you know configuration for where it's going to talk to forced relaying forced redirecting there's a whole bunch of examples where I can get a client application to talk to something else and in this example in this demo all we're going to do is we're going to force it to talk to Evil Base URL so now it's talking to the evil endpoints now we're going through the workflow that we showed in the diagram which is I have a client that's now talking to an evil endpoint that's not trusted so we verified that it wasn't

trusted in the browser right you saw the big red bar so here we're going to say Johnny compromised is now trying to send his credit card information all right let's see it let's go hey it worked why did it work when we went through the browser right we saw a big warning basically the browser is telling us why are you doing this and it's giving the user an option to choose it's giving the user an opportunity to say yes I trust it anyway or no I don't because you've obviously failed some sort of check inside of the rich client I didn't get that option and if we go back and we look and see what happened

we see that the man in the middle sort of work so if we go to the evil API he's now got Johnny compromised data if we go to The Trusted API because we just forwarded the request Johnny compromised shows up here down at the bottom it's a little hard to read and then if you go to the evil API endpoint we find out they're just posting credit cards because they were able to grab the secret they ripped it open and they sent it along because they were able to relay it so let's take a quick look at the code let's figure out what was wrong why did why did that happen and if anybody here's the developer and you're welcome

to speak up and and call out the the line the bug we have this this thing called configure H Tob client we're doing some stuff here what what's gone wrong what's the bug anybody that's right here we are bypassing every server certificate check what we've done is we've basically listened to the libraries when they've connected over https and we ignore what they say it's basically what it comes down to so what happens when we we fix the bug we can comment it out let's post some data so Billy safe he's posting his credit card information sure enough we get an exception there's a failure the underline connection was closed could not establish trust relationship for the SSL TLS secure

Channel and specifically the remote certificate is invalid according to the validation procedure so the libraries were trying to tell us to do the right thing they were basically telling us don't trust this endpoint it's not valid it's not signed I don't trust it we we shouldn't trust it but built into the code I basically ignored that I basically found a way to to bypass the the signature check entirely now what ends up happening is is if you're developing inhouse or you're forced to use real certificates real certificates are expensive right you have to go and you have to go to veras sign and spend anywhere from 100 to you know thousands of dollars to get a an SSL certificate

but if I'm deploying this to a test environment I'm not using the same trusted certificates I'm using a test certificate or I'm using an SSL certificate uh or sorry uh self-sign certificate and I may not be going through the same rigors of trusting that or making that a trusted environment I might just be bypassing it in the code so if you're ever auditing code if you're ever doing code reviews if you're ever doing uh you know testing an actual like application that's connecting to web Point these are some things that you can try out so now that we fixed it let's go try talking to let's go say we're not uh compromised anymore and then you'll notice Billy

Billy safe fixed his

problem he's posting his credit card info again we send it it goes on Rich uh Client app doesn't notice anything seems like it's right we go back to postman we're going to go get the data and sure enough Billy safe his stuff went right on through it's trusted everything worked out great all right cool so any questions about the demo kind of the idea Simple Man in the middle so let's go back to the slides

uh whoops so here are some of the examples of bypassing certificate checks in sort of like client libraries here we have IOS if you go to that page it basically tells you hey here's how to bypass the certificate checks Android same thing S A csocket library.net this is their their example and if you want the links they're going to be in the slides they're the straight links um but the interesting thing too is if you ever go look at stack exchange or if you go at like stack Overflow and you search for Bypass or Trust self- sign certificates or bypass certificate check you'll see all sorts of examples where people have asked this question and there's a

snippet of code just like the one that we commented out where people are dropping them into their applications just so they can test just so they can get around this issue um kind of last thing I want to cover cover uh in regards to certificates is uh trust chains so if you're ever in a position where you're having to manage multiple certificate authorities or you're issuing lots of certificates intermediate authorities are really good ways at uh mitigating risk and they're really good at um kind of Distributing the the providing identity for your certificates so the example is is if I have a website I'm going to issue certificates with my website CA and if I'm doing client

authentication I'm going to issue certificates with my client CA um fairly basic when the validation happens you'll notice that server service B certificate is signed by intermediate CA generally your clients aren't going to know what intermediate CA is but inside of intermediate ca's certificate it will then say hey I was signed by this root CA you can trust me and the trust chain gets validated that's the basic premise um they matter because again it's really easy to minimize service impact if one of your certificate authorities is compromised so if all of a sudden my web server certificate Authority was compromised I don't have to reissue all of my certificates I can revoke a single certificate re redeploy

my CA reissue the certificates without redeploying potentially thousands of certificates or hundreds of certificates um but the challenge is is you're managing more secrets if you're doing like open SSL deployments of public or private keys if you're doing it with Microsoft it's another ad machine that you have to manage which is a giant pain um but the biggest thing is is if you're using a lot of certificates this is a great way of mitigating the risk so let's jump into the last part of it the idea the best development and test practices test and test with broken things that's really what it comes down to test with an expired certificate test with a self sign certificate test with

an expired certificate basically find ways to test your systems if you're doing your own development to use broken certificates to identify issues and the idea is if you know that you broke something in the certificate but the system still works something's wrong uh the other thing is auditing endpoints goes back to that https and HTTP and Yahoo Twitter T and Facebook for a long time allowed you to log in Via htps or HTP everyone who went over HTP basically had their creds sniffed if you went over htps you know you were you were relatively protected um if you know what SSL pinning is so if you are doing like a mobile device uh uh development

you can pin a specific certificate signature which is then trusted and if that certificate changes behind the scenes you'll fail the certificate check entirely so I can issue a new trusted certificate for an endpoint but because it wasn't the original one I will still fail to check um and if you're using certificate revocation lists basically ways to tell everybody don't trust these shts anymore know how to use them try them out and make sure that you you've developed the right uh pattern in there um and the last thing I want to talk about is if you are using test certificates often times they're checked into code they're sh uh hashes are checked into config know that they're

deployed know that they're available and If someone were to compromise your code they could potentially steal your test certificates and use it against your real site uh and that's it so if you go to GitHub you can get the demo code um I'll be posting the slides to um GitHub this is how you can get a hold of me um representing myself I'm Robert Lucero I got Twitter I got LinkedIn I got all those cool things um um and that's pretty much it uh are there any questions

anything well it depends that that's always the answer right right so the libraries themselves are fairly well vetted they're they're developed by like apple they are developed by Google and Microsoft and they go through their own sort of um security audits but the default behavior is to fail everything that's not trusted so if developers were to grab those apis and start using them they need to know what the other half of the system is which is the certificates so if I go and I go buy a veras signed search and I use that against my API everything's cool but as soon as I go grab create like a self- sign certificate then I'm having to start

playing this game by installing that certificate to a trust store or bypassing the check or doing a debug case am I using a test certificate yes or no so that's that's kind of where the the split happens and that question

most of them are and like and it depends the larger libraries the more generally used libraries are are going to go through their internal audits at least that was the case with with Microsoft apis and I imagine it's the same thing for Android open source apis are probably going to go through a similar practice but more through Community Driven so I would I wouldn't I wouldn't say that they're all secure by default because they all have vulnerabilities and they're always getting patched but at least you're not doing the custom implementation and you can manage that risk differently uh you had a question or

yeah uh okay so so in my example what I did was I basically changed the configuration I basically said don't use this website use this other website and from Net's implementation I could have an app.config that's not protected and I could write something there with malware or it's it's a little contrived because there's just to just redirect the traffic quickly but that's that that would be the idea is you get somebody to go to an endpoint that um that they don't intend to

uh no not off hand um generally at least my experience is your operations team because they're doing the deployments they and because they're if if you're especially if you're doing like an OP SSL deployment they're keeping very close tabs on the private keys so they'll generally have an inventory of the certificates that they're using

cool cool so I have one last slide to kind of drop up here uh I want to thank Andrew case he was my mentor uh took a lot of time out of his busy day job um you can get a hold of him on Twitter with ATC and uh his book just came out the art of memory forensics uh if you have a black hat badge you can get a hold of him he will be doing a book signing but uh I really appreciate everything you did thank you Andrew uh and that's it thank you guys very much for coming to my talk