Helper tools for Delorean

Have a look to other posts of this serie:

[1] NTP MitM Attack using a Delorean

[2] Mac OS X Time Synchronization

[3] Fedora / Ubuntu Time Synchronization

[4] Microsoft Time Synchronization

[5] Attacking HTTP Strict Transport Security

[6] Attacking the Public Key Infrastructure

[7] Other Attacks
[8] Helper tools

Disclaimer: All this information has been obtained from empirical tests and in a specific period of time, so they could have changed.

We are finally in the last post of this serie about Deloran. At this point, I have talked about the attacks that were tested, about the tool and many other things. However, if you pay attention to the Delorean repository, you will see that there are  couple of additional python scripts there. They are small tools that I created as a helper tools, because I needed a feature but I didn't make sense to integrate it with Delorean, so I keep them as separate tools.

The first one is hsts_catcher.py which is a simple tools that just connects to a website an returns its HSTS configuration. Nothing that you couldn't do with curl and grep:

$ ./hsts_catcher.py -U https://accounts.google.com -A "Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)"

max-age=10893354; includeSubDomains

The second tools is crl_checker.py which is much cooler than hits_catcher.py. When I was looking for certificates that I could use, I faced a big problem: Some certificates that I found had issues in their certificate chain, for example it root CA was expired or similar problems. Unfortunately, checking all possible issues is a pain in the ass a manual process that can take valuable time, so the most convenient option was to use a browser to check if the certificate chain was valid or no. However, I had another problem here: A web server needs both the certificate and the private key, and to find the private key is the hardest part here, so I prefer to do it only for those certificates where I know I will be successful in advance. It seemed the egg and the chicken problem.

That's why crl_checker.py was born. It implements the first stages of the SSL handshake, where the private key is not really needed before the certificate validation, so we can check it just using our browser and running the following command:

$ ./crl_checker.py -p 10443 -c /etc/apache2/ssl/ietf.crt

Sometimes you need to refresh several times to have this warning message. Probably my SSL handshake implementation is too much hardcoded, but I haven't go in depth of this since the tool is still useful.

You will always see a warning message even if the certificate chain is perfect, because you are not connecting to the correct hostname, but this doesn't really matters. There are other warning messages that doesn't matter as well, such us the expiration one, since we will use Delorean to bypass this. If you only have these warning messages... that's great! your certificate can be used for a successful attack. Now you need to get the private key as we did in previous posts.

If you aren't lucky, you will see other warning messages such as "the issuer certificate is unknown" which means that the issuer CA was removed from trusted CAs list or other similar issues. You probably should try with another victim.

Other Attacks using Delorean

Have a look to other posts of this serie:

[1] NTP MitM Attack using a Delorean

[2] Mac OS X Time Synchronization

[3] Fedora / Ubuntu Time Synchronization

[4] Microsoft Time Synchronization

[5] Attacking HTTP Strict Transport Security

[6] Attacking the Public Key Infrastructure

[7] Other Attacks
[8] Helper tools

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.