Disclaimer: All this information has been obtained from
empirical tests and in a specific period of time, so they could have
changed.
The attacks shown in the previous posts are the ones that I considered more likely and with biggest impact. However, I was trying other exploitation opportunities using time synchronization attacks. Some of them worked even being unlikely, and some others didn't work at all.
One of the attacks that worked was an attack against the Windows Task Scheduler. As you probably know, there is a service in Windows boxes that run certain maintenance tasks in the background, such as the same time synchronization.
The task scheduler keeps information about the last time when the task was ran and the next time it will do. These fields are important because, depending on the task configuration, "Next Run Time" is sometimes calculated based on the "Last Run time", which gives us the opportunity to manipulate the next run time by manipulating the clock using Delorean.
As I said, not all the tasks calculate "Next Run Time" in this way, but there are some interesting tasks that do, for example the Windows Automatic Updated Service.
So, What happen if we manipulate the the clock using Delorean, as we did in previous posts, and the Windows Automatic Update task is executed? The "Last Run Time" field would be updated to the fake date (let's said 2020), so the "Next Run Time" would be calculated in base of that date, in other words, at some point in 2020. That should't be a problem if the system would maintain that fake date forever, but if the clock is restored to the real date... then the next Windows Automatic Update will take place in 4 years, so the users wouldn't be warned about new updates and fixes if they don't manually check it.
This is an unlikely attack because Windows is the mosts unlikely platform to be a victim for a Delorean attack, and because I couldn't find a way to restore the clock without user intervention. However, other tasks and other platforms (cron in Linux, for example) could be abused in the same way.
Disclaimer: All this information has been obtained from
empirical tests and in a specific period of time, so they could have
changed.
Disclaimer (2): In this post I talk about certificates, SSL keys, etc. Please note that I could talk about (for example) "the certificates's private key" because it's the way I usually speak, but probably it isn't the most correct term. I should talk about "the private key of the certificate's public key", but I think it's easier to understand if we simplify this. Any way, if something sounds confusing, just drop me an email or comment and I'll try to clarify it.
From the number of attacks that I tried using Deloran, this was my favorite one. While I was thinking about what could go wrong when the clock can be tampered, SSL certificates expiration dates came to my mind.
As you probably know, a SSL certificate is valid if:
It was issued by a trusted certification authority (CA) or by an Intermediate CA that was issued by a trusted CA.
Common name matches the server's hostname (wildcards can be used).
Current date is between the "Not valid before" and "Not valid after" dates.
When a SSL certificate expire, we need to get a new one, and the older ones are usually forgotten, because they're invalid (3rd case). However, with Delorean this isn't completely true, since we could tamper the internal clock and make a computer to believe that an old certificate is valid.
But we can't attack all the old certificates in the world using Delorean. We need to find certificates with the following conditions:
We need to reconstruct the old certificate chain: This isn't a problem, since CA certificates have long validity periods, so perhaps the current certificate chain also works with the old certificate, and if not, looking for the "Issuer name" in the Internet usually works.
Root CA (starts the certificate chain) has to be a trusted OS/Browser CA: If the root CA has expired and remove from the browser's certificates database, victim's browser won't be able to validate the certificate chain. This is only a problem for root CAs. Any other Intermediate CA could be expired and that wouldn't avoid our attack.
We need to find the old host certificate: This is harder than it seems. It's not such an easy task. Let's talk about this a few lines below.
We need to be able to get the host certificate's private key: This is the only one private key that we need to know. That's why we're interested in old certificates, because we could find much easier ways to get the private key than in modern ones. Let's talk about this a few lines below as well.
So... we said that we need to get old SSL host certificates. Where could I find them? Unfortunately, I did't grab SSL certificates 10 years ago, so I need to find somebody else in the Internet that did it. I spent a lot of time looking for this kind of database (the oldest the better, of course) and the better and oldest resource that I found was The SSL Observatory from EFF. They crawled the Internet in 2010 and stored a huge database with all the SSL certificates that they found.
Now that we have an old SSL certificates database, we can start looking for certificates that we think we could break and get it's private key. For example, something that came to my mind was the FREAK attack. As a part of this attack, they cracked RSA-512 keys in a few hours, using a big Amazon EC2 cluster, so we could do something similar if we find RSA-512 certificates in our database.
Unfortunately, the most interesting targets (Google, Facebook, etc) didn't use RSA-512 in 2010. Maybe if we had an older database... Anyway, I was able to found some interesting certificates and some funny ones, such as a Disney site (not the main site).
Disclaimer (3): When I do a Delorean demo using a website, I'm NOT attacking the website. The website is NOT vulnerable. I'm attacking a vulnerable client, that is my own testing machine, so I'm attacking myself, not the website.
I'm not going to specify step by step how I crack the RSA-512 certificate, because I would be a post (or some of them) itself, and because It was the fist time that I did it, so you can find much more useful information in the Internet [1][2][3][4]. At the end of the day, I had four EC2 machines running 3 days (as far as I remember) and It was around $150 in total.
Once you have factored the old RSA key, you have the two prime numbers that were used to create the public and private keys, so you just need to do it again (private-from-pq.c) to get the private key. Let's see if it works or not.
It works! The certificate chain is valid again and we have the private key, so we can cheat the browser and impersonate the website. Cool!
As far as I have read (I'm not an expert in this field), Governments and other organizations with enough resources could crack RSA-1024 in a reasonable time. This is even more interesting than my demo, because RSA-512 is now banned from most modern browsers, so they would reject the certificate chain. I did this demo using an RSA-512 certificate because I don't have at this moment enough resources to crack RSA-1024 and because It's exactly the same process, so if we can do this for RSA-512 in a slightly old browser, we definitely could do it for RSA-1024 if we had enough cracking power.
This is not the only one old weakness that we can use:
But there's something that probably came to your mind. What about certificate revocation? This isn't a problem with cracked certificates, because they never were revoked, but hacked certificates, heartbleeded, debian prng, etc ... all those certificates should have been revoked after generating a new one.
A Certificate Revocation List (CRL) is the database where all the revoked certificates are stored. Browsers download them (or request information via online services) and check if a given certificate is revoked or not, If it is, they reject the communication even if all the certificate chain is valid.
When I was facing this problem, the question that came to my mind was: Do those CRLs store ALL the revoked certificates? From the beginning of time? This would make this files HUGE, which is something that could affect performance. Well, I can't be 100% sure about this, but I did some quick tests to check if CAs purge their CRLs when revoked certificates are not valid because of their validity period.
I focused only in one simple test. I opened several well-known websites in my browser and I got their issuer certificate. Then I downloaded the referenced CRL and I looked for big difference between the date when the certificate was issued and the date of the oldest revoked certificate. If the certificate was issued in 2008, and the first certificate in the CRL was revoked in 2012, and the second one in 2014... that's pretty weird. My humble opinion is that those CAs are purging expired certificates because they will be invalid anyway. That's 100% true, but it lets us to use our attack against those certificates, even if they should be revoked.
Online Certificate Status Protocol (OCSP) doesn't really help (it's even easier), because most browsers are configured in order to accept certificates if they can't validate them, so an attacker just needs to drop OCSP connections. More information HERE.
From the list above, I looked for certificates that were generated using the old Debian PRNG bug. The problem was that this happened in 2008 and the SSL database that we have is from 2010, so most interesting websites changed their certificates before 2010.
Looking around the Internet I found CodeFromThe70s. They developed a Firefox extension that detected certificated generated by the Debian PRNG bug. Detections were sent to them so they have a nice blacklist in their website. I used that list to find a certificate that I could use to test if it's still revoked or not.
Next step was to get the private key. This wasn't as fast as I thought, because the pre-generated list published by HD Moore was for SSH keys only, so I needed to generate my own for HTTPS. What I did was to use the original patched "getpid.so" library and "ubunturoot" chrooted environment (original link was broken, so I downloaded it from here), and I developed a couple of shell scripts that just generate all possible SSL key pairs and check if it's the one I'm looking for: $ cat keyfind.sh #!/bin/bash TARGET=0123456789abcdef0123456789abcdef
for PID in `seq 1 32768` do chroot . /generate.sh $PID &>/dev/null openssl rsa -in private.pem -noout -modulus | openssl md5 | awk '{print $2}' | grep "$TARGET" if [ $? -eq 0 ] then cp private.pem found.pem echo "FOUND!" exit fi rm -f private.pem echo $PID done $ generate.sh #!/bin/bash
It took a few hours but I was able to get this private key as well. Maybe it wasn't the most efficient way, but it worked for me. The resulting demo is following:
My DEF CON talk (August 7th, 2015) is online, so you can have a look as well. I presented this as well in Spanish in RootedCON (March 2015) and NavajaNegra/ConectaCON (October 2015), but their haven't published the videos yet:
Disclaimer: All this information has been obtained from
empirical tests and in a specific period of time, so they could have
changed.
In the last few posts we have reviewed how time synchronization works in different operating systems and how we could change the clock using Delorean in each of them. However, we haven't seen any practical attack. What can we do by tampering a computer's clock?
I started this research because I was doing a MitM demo, using SSLStrip, and it didn't work when I tried to visit GMail and other well-known websites. That was weird, because I had done the same demo many times in the past. Debugging the problem I discovered an HTTP header called "Strict-Transport-Security", something that had never seen before.
HTTP Strict Transport Security (aka HSTS) is a security protection that was released in 2012 and, despite is not widely used in the Internet yet, most well-known providers use it at this moment. The server part is really simple, a webserver just needs to set up the "Strict-Transport-Security" header setting the desired policy using the "max-age" and "includeSubdomains" parameters. In the example above, the web server sets a policy in the browser saying "ey! it doesn't matter what happen, please connect to me always using HTTPS for the following 3153600 seconds".
The hardest part in the HSTS feature is in the browser part. A browser needs to read this header and do all the necessary actions to ensure that it follows the policy. Most browsers support HSTS despite IE didn't support it until June 9th 2015. While I was delivering my talk in DEF CON (August 2015), an attendant from the first row correct me when I said "IE doesn't support HSTS". He was right about that, because I'm not an IE user and I tested it for the last time a few months before the talk. I asked him if this was something recent but he told me that "six months ago" (around February) which isn't exactly what I have found documentd. Anyway, It supports HSTS now.
In addition, Google and Mozilla created a Preloaded HSTS list for their browsers (later the idea was used in other browsers). A preloaded list is a list of well-known providers (google, twitter, facebook, paypal, etc) where HSTS is "enforced by default". The goal of this preloaded list is to avoid the security gap when a user have just installed his browser or cleaned his cache, or when he visits a website for the first time, before any HSTS policy has ben set.
Despite information from Google or Mozilla seem to talk about the HSTS preloaded list as a static list, the real truth is that preloaded entries are treated exactly the same than dynamic entries. When a browser is installed or its cache is cleaned, all entries in this list are added as dynamic entries using a default value (10 weeks) and they're updated in the same way than dynamic entries are so, in real life, it doesn't make a difference for a Delorean.
The only browser that I have found in my research which works in a different way is Apple Safari. It stores a .plist a preloaded list and it forces always HSTS in those hosts. It doesn't matter the local clock.
Since we know that HSTS policy will avoid us from intercepting the first HTTP connection and, as a consequence, from using SSLStrip (or intercepting the communication in any other way), in the amount of seconds specified in the "max-age" parameter, our attack against HSTS is based on updating the local clock in order to make HSTS cache to expire. When there isn't any entry in the HSTS cache, a browser will work as usual, so when typing hostnames such as "mail.google.com" it will connect using HTTP before being redirected to HTTPS.
My talk in BlackHat Europe last year was based in this attack, and it was published several months ago, so you can have a look if my accent doesn't hurt you (as a comment in youtube said) ;)
.png "English"){kind=small}
Posts
