Linux Session/Beacon Wont Check-in Unless Localhost Time is Correct

[omnitheon]

Describe the bug Hello Sliver Dev team,

I was experimenting with a Linux payload in one of my labs but could not get the host to properly register for whatever reason. I did some network logging and the connectivity was definitely fully established, so I enabled debugging on the client and checked the server logging output with DEBUG (5) set. I kept seeing repeated errors around the OTP step of the connection process, client would report that server said 404 on POST, and server would say that there was no match and OTP was invalid.

To test, I went to server/cryptography/cryptography.go and inspected the "ValidateTOTP" function. I noticed that it used "time.Now().UTC()". On a hunch, I checked the lab machine to find that the date was incredibly unsynced and in the past (about a month ago). I updated the date to reflect the proper time within a 24 hour period, but still didnt have any success. I updated the lab VM to be fully update and near 100% accuracy via NTP, and then the beacon successfully checked in. This presents a concern around hoping that the client has NTP/proper time settings configured for the beacon to fully register and check in. I have not noticed this behavior on Windows, and I believe that it's only recently started for Linux as I do not recall needing to do this pre-work prior to the 1.5.0 update.

To Reproduce Steps to reproduce the behavior: Setup a VM that has a wrong date in the past Generate a Linux beacon with debug and send to the VM Execute beacon on VM, and observe error with reconnect sleep at bottom. Update time to be valid and near-accurate, e.g. NTP or manual date commands. Re-execute beacon on VM, and observe that the session is connected successfully now that time is correct.

Expected behavior Beacon should check in regardless of accuracy of time on victim side.

Desktop (please complete the following information): -Sliver Server is running on GCP Debian 10 -Sliver Beacon was executed on CentOS 7.

[rkervella]

@omnitheon is this only on the HTTP transport? If so, you can disable the OTP verification with --disable-otp in the listener command like this:

http --disable-otp

[omnitheon]

@rkervella

I am using HTTP only, correct. Thanks for sharing this command. Is this currently expected behavior, as disabling the OTP verification will reduce the operational security of the C2 itself?

[rkervella]

My understanding is you can't have OTP if there's too much desynchronization between the sliver server and the target host running the implant. So your two solutions are to either disable OTP on the listener, or avoid running the implant on such hosts. @moloch-- would know more about the internals, I have not taken the time to look at it since it's been merged.

Having the implant fallback to non-OTP in case of a clock desync and having the server accept that by default would completely neuter the idea to use OTP in the first place imo.

[moloch--]

Yes, disabling OTP does reduce some of your operational security but if your target's clock is off then you don't have much of an option.

As @rkervella suggests a middle ground would be to start two http listeners, with the primary enforcing OTP

[jamesgol]

This should have been fixed by #881