Unable to enroll client

[John Foster]

Hi,

I'm attempting to enroll a (CIS Level 2) Windows Server 2022 client to a Velociraptor server, using self-signed SSL, but having issues. Client version is 0.6.8-2.

The client trace, excerpt below, appears to indicate an EOF while getting server.pem.

However, hitting the same https://<VelociraptorServerFQDN>:8000/server.pem URL with either curl (with -k) or from Edge successfully brings back the certificate as expected indicating that underlying connectivity (via both port 8000 and 443) is fine and that the issue may be certificate related? However, my knowledge of diagnosis in that area is limited so any guidance appreciated! 

thanks,

John

>> velociraptor --config client.config.yaml client -v

.

.

[INFO] 2024-01-11T16:31:21Z Loaded 357 built in artifacts in 161.3754ms
[INFO] 2024-01-11T16:31:21Z Installing Dummy inventory_service. Will download tools to temp directory.
[INFO] 2024-01-11T16:31:21Z Starting Crypto for client C.<redacted>
[INFO] 2024-01-11T16:31:21Z Expecting self signed certificate for server.
[INFO] 2024-01-11T16:31:21Z Ring Buffer: Creation {"filename":"C:\\Program Files\\Velociraptor\\Tools/Velociraptor_Buffer.bin","max_size":1073741874}
[INFO] 2024-01-11T16:31:21Z Starting HTTPCommunicator: HTTP Connector to [https://<VelociraptorServerFQDN>:8000/]
[DEBUG] 2024-01-11T16:31:21Z Sending client info update hostname:"<redacted>" fqdn:"<ClientFQDN>" system:"windows" release:"Microsoft Windows Server 2022 Datacenter" architecture:"amd64" client_version:"0.6.8-2" client_name:"velociraptor" build_time:"2023-03-27T02:34:10Z" install_time:1704821675
[INFO] 2024-01-11T16:31:21Z While getting https://<VelociraptorServerFQDN>:8000/: Get "https://<VelociraptorServerFQDN>:8000/server.pem": EOF
[INFO] 2024-01-11T16:31:21Z Waiting for a reachable server: 1m28s
[INFO] 2024-01-11T16:31:23Z Compiled all artifacts.
[INFO] 2024-01-11T16:31:25Z Failed to fetch URL https:// <VelociraptorServerFQDN>:8000/reader: No certificate found for destination
[INFO] 2024-01-11T16:31:25Z Sleeping for 1m9s
.

.

>> curl https://<VelociraptorServerFQDN>:8000/server.pem -k

-----BEGIN CERTIFICATE-----
MIIDVzCCAj+gAwIBAgIQWsNNF/Hc7LjWpTxh ...

[Mike Cohen]

This looks like it should work. Did you have any kind of proxy in front of the server?

I would check that the TLS version is high enough. It looks to me like maybe the client is refusing to talk with TLS 1.2 

I think later versions can be configured to accept lower TLS versions.

You should repeat the test with the latest client in any case as 0.6.8 is quite old now

--
You received this message because you are subscribed to the Google Groups "velociraptor-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to velociraptor-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/velociraptor-discuss/bca65478-e8e4-4df1-adb2-82259d928138n%40googlegroups.com.

[John Foster]

Hi Mike,

Thanks for the quick response - appreciated. Having had a closer look at TLS, I think everything looks ok but have supplied a little more information below just in case there's anything that stands out.

These are the results from sslscan, indicating - if I'm interpreting it properly - that the Velociraptor server supports and prefers TLSv1.3? With the --show-certificate flag, sslcert also successfully retrieves the Velociraptor certificate.

>> sslscan.exe <VelociraptorServerFQDN>:8000

Version: 2.1.1 Windows 64-bit (Mingw)
OpenSSL 3.0.9 30 May 2023

Connected to  <VelociraptorServerIP>

Testing SSL server <VelociraptorServerFQDN> on port 8000 using SNI name <VelociraptorServerFQDN>

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   disabled
TLSv1.3   enabled

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Session renegotiation not supported

  TLS Compression:
Compression disabled

  Heartbleed:
TLSv1.3 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Curve P-521 DHE 521
Accepted  TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve P-521 DHE 521
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve P-521 DHE 521

  Server Key Exchange Group(s):
TLSv1.3  128 bits  secp256r1 (NIST P-256)
TLSv1.3  192 bits  secp384r1 (NIST P-384)
TLSv1.3  260 bits  secp521r1 (NIST P-521)

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength:    2048

Subject:  VelociraptorServer
Altnames: DNS:VelociraptorServer
Issuer:   /O=Velociraptor CA
Not valid before: Apr  8 10:44:54 2023 GMT
Not valid after:  Apr  7 10:44:54 2024 GMT

Couple of additional bits that may be relevant:

 - I've noticed is that on the (Azure) Firewall, through which the clients traffic initially egresses, there are logs that it's denying requests for 'velociraptorserver' (without a Domain name) from the client on port 8000 which doesn't resolve.  Is this normal / expected behaviour?

- Have given v0.7.1 of the Velociraptor client a spin with exactly the same results unfortunately.

- A Wireshark trace appears to indicate that, following a 'Client Hello', a 'Server Hello' is never actually received back, though the server does acknowledge the client hello

Again, thanks for your help here.

cheers,

John

[Mike Cohen]

 

Couple of additional bits that may be relevant:

 - I've noticed is that on the (Azure) Firewall, through which the clients traffic initially egresses, there are logs that it's denying requests for 'velociraptorserver' (without a Domain name) from the client on port 8000 which doesn't resolve.  Is this normal / expected behaviour?

This seems very interesting - is this egress firewall attempting to do TLS inspection? When you verify the connection with Curl are you running curl from the same endpoint (and therefore through the same egress that the client is running on?) Just to eliminate the possibility of network filtering can you spin up a client on your own workstation in debug mode (with the -v flag) as shown in the troubleshooting guide https://docs.velociraptor.app/docs/deployment/troubleshooting/

Thanks

Mike

[John Foster]

Hi Mike,

No, no TLS inspection on the egress firewall (though, either way, the client has initiated that particular flow for some reason?)

Curl was executed from the same endpoint and I've subsequently also tried the client from a 'vanilla' Windows 10 machine (in the same subnet) without any GPOs applied to eliminate as many variables as possible with the same results. Unfortunately, I can't try the same from my own laptop as I'm accessing the target environment 'remotely' and not on the same network as such.

I have a relatively strong suspicion that there's "something" attempting to intercept / examine the traffic between the client and the target Velociraptor server so am going to try to get a better handle on that in the next couple of days from people more in the know about the networking environment than myself and will update here if there's any progress / a resolution found.

cheers,

John

[John Foster]

Hi Mike,

Finally identified the specific issue and have a solution.

It transpires that the Azure Firewall that's monitoring the egress traffic is the underlying problem - while it's not configured to do any form of TLS Inspection, ruling that potential cause out, the rule that allowed the traffic out to the target Velociraptor server was an application rule and, therefore, the traffic is always SNAT'd (as per this blog post)

The solution was to dispense with the Application rule allowing traffic to the FQDN of the Velociraptor server and, instead, simply replace it with a Network rule - not subject to any SNAT'ing! - to the Velociraptors IP address and port which both allowed the Velociraptor certificate to be successfully retrieved and also removed the unusual 'velociraptorserver' name from the traffic logs (no idea what was happening there!)

cheers,

John