When SSL Fails: Tracing the SSL vuln to the most shocking real world impacts - Michelle Simpson

Yeah. Okay. Good morning, Dublin. Um, it's a pleasure to be here. Welcome to my talk. Thank you for coming this morning. Um, to my talk on when SSL fails, tracing the SSL vulnerabilities to the most shocking real world impacts. So, my name is Michelle Simpson. Um I am the head of pentesting for Instill, formerly vertical structure. I've been working in security for about 20 years. Quite passionate about security um and in particular the security community. So I was um a regular member of OASP Dublin when I lived here uh about it's about 11 years since I moved away. So and I was here for 12 years. So um I also uh founded um OA was Belfast in 20 2014. Um

basically loved the security community here in Dublin and there didn't seem to be one when I moved up to Belfast. So I created one. Um I'm also a director for Bides Belfast since we started that in 2016. Uh and I'd like to tell a little story so uh humor me. Um when I was about 10 or 11, my uncle used to he used to give me puzzles to solve all the time. Um one day he came to me uh with a briefcase. He sold office equipment. The briefcase was locked. His customer couldn't get into it. So I proceeded to do a brute force attack against combination and got it opened for him. Little did I know at the time

that this would be uh very aligned to my future career. So, why am I talking to you about weak ciphers? Um, crypto is kind of tricky, but I like it. Not a lot of pentesters dive into it. However, almost every pentest report has a bunch of SSL issues. Um, at the very least weak ciphers. So I've been questioned on these by colleagues, clients, and I started digging and research came up lacking like YouTube videos compared to other vaults and and and exploits just over a year ago. Then I had the pleasure of interviewing Jeff White for his book Rinsed. And honestly, the stories that he tells in his books um that and other books are so incredibly real and

shocking. So I wanted to forge a link between those kind of stories and the little old SSL issues that I was reporting. Was it possible? So I said about my mission to find out why we should care about weak ciphers and should we should we even care? Uh and I wanted to see it in action. Let's do a demo. See how hard that can be. So some demo fun. So just to start off for anyone who's maybe not familiar um I'll talk a little about weak ciphers. Um this is a list of uh encryption ciphers. The red ones are considered weak currently and the others are not. Um when I talk about weak ciphers, what do I mean? Well, ciphers

are every website that uses encryption should be all of them now because certificates are free. uh it has configured which encryption cipher ciphers can be used to connect to that site. So you connect to a site using a browser and a web browser has certain encryption ciphers supported and preferred for use. The browser and and the website then establish an encrypted connection using a chosen cipher that communi communi communications pass back and forth through. Ideally this is completely protected from anyone who can see the traffic. So, we'll come back to some of these when we're looking at results of testing later. Um, very quickly, I'll fly through a breakdown of what the cipher means cuz

it can look like double Dutch if you're not familiar with it. TLS at the beginning is the protocol in use, the older ones for SSL. DH DHC ECD denotes the key exchange algorithm being used. RSA is the authentication mechanism. AES is the session cipher. 128 256 is the key length in bits. That's important. CBC, GSM, CBC in this case is the type of encryption. SHA is the hash function for signature mechanism and 256 or 384 is the digest size. So again, we'll come back to some of this later. So to set the scene, I want to give a brief history of SSL and TLS. And hopefully you can see that. Okay, I'll talk through it. Um, first of all,

SSL, TLS, what does it mean? SSL stands for the secure sockets layer and TLS is transport layer security. So, let's begin. SSL version one was actually never released. Um, it was developed but never released. So, we start with SSL version 2 in March 1995. It was immediately vulnerable. In December the same year, SSL version 3 was submitted. Only a year later, development began for the next version, SSL 3.1. And if you're thinking, I've never heard of that. Um, thanks to Microsoft, that was renamed transport layer security TLS. So, that was TLS version 1.4. And there was a 4-year gap. In April 2006, TLS version 1.1 was released, another 7-year gap. In August 2008, TLS version 1.2 was

released and a two-year gap. So quite a lot of activity in development addressing issues in in versions and improving on them. In March 2011, enough progress was made for SSL version 2 to be formally deprecated. And then we have some major vulnerabilities. In June 2011, the beast attack was made public. Crime, the compression attack in September 2012. still more development in the background. Some security mechanisms then in November 2012 were designed to help mitigate some of the common issues. Uh HSTS, HTTP strict transport security and the CSP content security policy headers were implemented. Then we have lucky 13 attack in February 2013 or C4 in March 2013, breach in August 2013. So in August 2013, development begins for

TLS version 1.3. In the meantime, heartbleleed hit the public with a wave of attacks in April 2004. In September 2014, Cloudflare made SSL or TLS certificates free. In October 2014, Poodle attack affecting SSL version 3 was released. It was not as big an issue as it could have been because it was easy for most people to disable SSL version 3 at this point. Moving on then, in December 2014, the Pu Poodle attack was found to also affect TLS due to poor implementation defenses. In February 2014, RC4 was also incredibly broken that it was it wasn't just deprecated, but it was prohibited from use. In May 2015, we had the log jam attack. In June 2015, SSL version 3

was deprecated. In November 2015, more advances in enabling the use of certificates with um automated issuance made available by Let's Encrypt. In March 2016, the drown attack. In August 2016, sweet 32 attack against weaknesses in block ciphers. In January 2017, modern browsers stopped accepting SHA1 uh certificates, seemingly before it was broken. Uh and a month later, it's finally broken with the publication of Shattered. 5 years after the development of TLS version 1.3 began in that was in 2013. In March 2018, the proposed standard was approved, still not released. In July 2018, TLS version 1.0 was deprecated. In August 2018, finally TLS version 1.3 was published, a gap of 10 years from the previous version. So, this is where we're at with

TLS version 1.3, our latest version. In July 2020, both TLS version 1.0 1.1 had support removed from the top browsers. That leaves us with TLS version 1.2 2 and 1.3 suitable for use. I'm just going to jump back. I think I have a I have a reference there um by Sudok where I got a lot of that timeline and there's some really really interesting additional information there especially about certificate authority compromises um that's worth worth a look. So, the most heinous crimes I mentioned, what I really wanted to do was to link the crimes and the hacks from Jeff's book to point to the exploitation of ciphers along the way. I did investigations, interviews, and

none of them were suggesting that. Um those are some really interesting stories that he has presented but the details that I would have needed to establish those links unfortunately was above my clearance level out of my reach. So overwhelmingly what I was seeing from those interviews was essentially the path of least resistance. So think about two houses on the street. One house has an alarm and one has not. burglar is going to focus on the one without the alarm. So the primary avenues of attack are glaringly the business email compromise, fishing, outdated software, vulnerable systems, authentication weaknesses, and bypasses. So this got me thinking, but I'm not satisfied. What when would SSL or TLS be

a factor? So think of a row of houses. All of them have alarms. All but one house have multi-pointter mortise locks and one has a regular lock. So when all the other doors are closed, what organizations are going to have all of their other security gaps so well secured that ciphers are the remaining viable avenue? We're talking about highv value targets, nation state hackers, banks, governments. I do have it on high authority that nation states are known to be using weak ciphers. Um, but again, above my above my clearance level. So, should we care though? Should we care? Harping back to the path of least resistance, I like this post. Often hacking is just as simple as asking

someone for their password. it's too hard. There's usually an easier method. Uh and and what I'm really focused on, what I was really wanting to drill into is the the strongest weak ciphers, which I might add are widely report or widely still supported for backwards compatibility. Understandably, products have um will have limited number of users or will have limited users if people using older phones can't access them. So, the Android 10 I think still requires the TLS version 1.3 CBC ciphers to work. Uh really that phone is not that old and it's used by a lot of people. Um but no longer supported. So, um is not getting the newer stronger ciphers. So what is the effort maybe for

requiring or for what is the effort required to decrypt cipher text encrypted with a TLS version 1.3 CBC cipher? If you know the answer I want to know. I haven't been able to determine that. Um, but the older, more significant vulnerability with a practical attack available known as sweet 32 is reported to take two days to retrieve a session cookie. So imagine we're talking years potentially for now um for the TLS 3.1 CBC cipher. So really hard to do, no practical attacks. Usually easier methods not worth the effort. H. Um, another one I like usually easier avenues. But hold on, consider this quote from Crypto Pals who work worth checking out cryptoals.com if you're interested in

playing with crypto. Um, the systems we are relying on today that aren't known to be fatally broken are in a state of just waiting to be fatally broken. In a state of waiting to be fatally broken, so it's not a problem until it is. Let's think back to our timeline. SSL version 2 now fake broken. SSL version 3 fagely broken. TLS version 1.0 broken. TLS version 1.1 broken. TLS version 1.2 mostly broken. TLS version 1.3 were already reporting weaknesses in ciphers. So it's only a matter of time. Demo time. So I'm going to demo heart the hearted vulnerability. In heartbleleed, the exploit script is sending a malformed heartbeat request to the to that specifies the length field larger than

the actual payload size that causes the server to return additional data from memory. So bear with me for one second while I switch over

All right.

Okay. And should be able to see my screen now. Okay. So, I've got a couple of VMs, couple of virtual machines um set up. This one is BWAP. It's a an OASP vulnerable application and it is vulnerable to Oh, spoiler alert, right? Um, and I've got a a Kali Linux, which is a bunch of tools for pentesting. Um so first thing I'm going to do is um I want to check this application for um vulnerabilities. So I'm going to run got a bigger one here. Uh I'm going to run my favorite SSL testing tool test SSL.sh. uh and I'm going to run it against the target application which is sitting on uh 123.128 on port 8443.

So I'm going to run that. That is going to take a little bit of time. So I'm going to open up one I created earlier. So test SSL creates a fabulous in my opinion um output that's colorcoded for what's okay and not okay and it says it's okay or not okay. Um so here this is this is the output of the scan against um against the BWAP application. So we can see it's offering SSL version 3 really not okay. It's offering TLS1 TLS 1.2 uh 1.1 and 1.2. Uh we can see here triple dez and idea ciphers are supported. CBC ciphers are supported. Um we have our list of all the ciphers that are supported.

Uh got some more really nice information. Shiaan is in use. Um certificate issues. We have vulnerabilities called out. Heart bleed vulnerable. CCS vulnerable. Hood vulnerable. Lots of vulnerabilities on this. Um, okay. So, while that's I think that's maybe still running, I'm going to open another H.

Uh, I'm going to run N mapap, another tool that we can use to to validate the finding, verify it. Uh so run admap scan against not that one. Uh hold on go here.

[Music]

Just that's the one. So I'm going to run that the SSL heart script against can you see that against port 8443 against the application. So it's all done for us.

Okay, that's going to take a second to run. [Music]

Okay, we'll come back to that. Um, spoiler alert, yes, it's vulnerable. So, um, what I'm going to do is show two different methods of exploiting it. So first of all, we're going to use just a Python export uh exploit script. So Python 2, this script is publicly available on the internet. Um and we'll run it against the application. Right, here we go. So we got lots of we got lots of memory back, lots of blank memory. And if I scroll up all the way to the top, h I can see some data there, but it's not not particularly useful. Now, if I go back into the application here, log out, just to remind you that the

vulnerability is taking data from memory. So, there was maybe nothing in memory at the time. So, we're going to log in again debug and do that again. Okay. Right. Let's see. Did we get anything different this time?

Okay. Right. Okay. There we have it. login username and password that we have extracted from memory. Uh I'll show you another method of of exploiting it using MSF. Uh so metas-loit msf console we are going to

um search heart bleed. Okay, we're going to use the auxiliary scanner. Auxiliary scanner SSL heart plate. Okay. Show options scan. Uh so if we scroll up here, we need to set the remote host and the remote port is set 443 by default. So we'll change that. So set our hosts to 1 192.168.123 dot uh what was it? Uh 128 128. Uh set our port to 8443 and show run

actually. It's set to scan. So actually show if I do show actions. So that's saying that the heartbeat response uh with the leak was confirmed with bytes of data returned. But if we show actions, it's just set to scan. So we need to set h action dump and um run uh I just want to refresh the memory. So we'll go in here, log out again. Log out. Log in the bug. [Music] login um and run. [Music] Okay.

Okay. So, it has taken the output into this folder, this file. a copy selection and

I'll use strings. It's possibly the same. No, strings and paste. Okay, so that has pulled out all the strings in the memory that has the refer header here. It has cookie session ID and it has the username and password. Okay. Um, so it's easy, right? Very easy. And the point is that um let me do this is an old an old vulnerability but the point is that all of the newer all of the vulnerabilities are coming out and they're getting easier and easier. So I'll jump through. I'm running out of time. So um that was the video. So what are the most shocking real world impacts? I'll do this in 30 seconds. state sponsored espionage

and I'll give some examples critical infrastructure attacks financial scams and fraud and long-term vulnerabilities from back doors. So state sponsored attacks, the ransomware epidemic with wann to cry, the HSSE conte um and the recent M&S and retail attacks. Uh, I have loads more examples. Um, and I probably don't have time, so I'm gonna have to wrap it up there. Um, I have, yeah, I've missed some examples as well, but uh, just come and ask me questions afterwards and I can share the rest of it. So, thank you very much.