The certificate is expired. I did not encounter issues on Beep even though I also did it after the certificate expiry, but there are different ways to attack Beep…
However, I had issues on a retired Windows box with a retired certificate where you absolutely had to make TLS work or the remote connection did not work.
My workaround was to ‘time-travel’ my attack box back to a point of time when the certificate was still valid.
@kireyn by time-travelling I just meant to set the time of your computer back to a point of time when the certificate was still valid - so before April 2018 in case of Beep (and turn off automated sync of the time with an internet time server).
As I said, I used this on Fulcrum not on Beep - but an expired certificate is maybe the only thing that really makes it different to do a retired machine today than at the time when it was still valid. So in case you think SSL might be an issue I would always ‘time-travel’ to rule that out.
Of course the annoying thing is that you then might not be able to research stuff on the internet from that machine as other SSL certificates on Google etc. might appear as ‘not yet valid’.
@kireyn and @fbarrsmith - an update for completeness - re Beep specifically: I also did the machine when it was already retired and when the certificate was expired. Just checked - I even took a note of the fact that I was surprised it worked.
I used an exploit of the ‘phone stuff’ for the initial foothold and the connection over 443 worked.
Most enum tools have an option to turn off certificate validation, for gobuster it is -k
But if you have an exploit or a tool where there is no option to discard cert validation (as it was on Fulcrum I think) then you have to time-travel.
You are right about the VPN of course…another certificate involved that is then not set valid.
My time-travelling of Fulcrum did work because I forwarded the interesting port to another Windows machine, and only changed the time on that machine while the time of the box maintaining the VPN was still OK.
But if I recall correctly, the VPN even stayed active for some time if you connect first, and change the time on the ‘VPN box’ while the VPN is up. After some time (like: minutes, half an hour or so…) it failed and you have to travel back to the present, start the VPN again, then travel back. Yeah, painful I know. But something about the VPN might have changed since I did this…
A completely different solution for Beep specifically would be to use a different exploit and attack vector that does not care about SSL. For the ‘phone-related exploit’ the expired certficate was not an issue.
Sorry for the repost, but I would like to make a comment regarding Beep and the SSL problem, in case it might be useful for somebody in the future who is training in the retired machines.
I struggled with SSL problems trying to use the most obvious exploit for the machine. It seems people managed to get the exploit working with this solution, as well as the other ones proposed on the thread, but none of them worked for me though.
The workaround was to get the URL generated by the exploit, then visit it in my browser. Apparently there are other ways for exploitation, but I wanted to follow this path.
I use IPpsec first way to get root but how do I fuzz for vtiger, dir buster and go buster is laggy, I tried my way in the vtiger exploit and gotten user
By the way, what is interesting.
For me, it turned out to be the easiest way to bypass the old version of the TLS 1.0 and TLS 1.1 protocol, just tweak the configuration in the Mozilla Firefox browser settings.