Consultation: Velociraptor Client-Server Deployment

[Ankit Bang]

Hi Mike & Team,

I have gone through the blog posts and documentation present on the Velocidex website to understand various aspects of the deployment.

The current documentation indicates an internal PKI setup as follows: 

• Create initial server certificates and any additional certificates for key rotation.

• CA public certificate is embedded in the client’s configuration and is used to verify server communications.

• The CA is used to create API keys for programmatic access. The server is then able to verify API clients.

But the documentation doesn’t indicate any mechanism that the server can authenticate and verify the clients.

1. One way to counter this situation is to implement client-side certificates which the server can verify. But this means the client certificate's private key will be exposed on each endpoint and every endpoint that will be using the same certificate.

2. In our corporate infrastructure we deploy the agent-based clients with static configuration pointing towards the server. We are planning to follow the same method for deploying Velociraptor clients. Unfortunately, this creates a risk in scenarios where a rogue client makes an out of band unauthorized communication with the server. 

Based on the above two situations, is there any method you can suggest where we can limit or restrict the initiation of communication from the client side?

In general, I am looking for a solution that will prevent exploitation of clients or if a client goes rogue while communicating to the server.

I would greatly appreciate it if you could help me provide any solution to the above-mentioned problem and please do let me know if you have any follow-up questions or concerns.

Thanks,

Ankit

[Mike Cohen]

The client config contains a nonce which is a shared secret - the server will refuse to talk to a client who does not present the correct nonce. The nonce ensures that only clients that belong to this deployment (or have a copy of the config file) are able to talk to this specific server.

Thanks

Mike

Mike Cohen  Digital Paleontologist,  Velocidex Enterprises E mi...@velocidex.com

--
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/ddb20124-a175-4777-8763-4a44c2456f6en%40googlegroups.com.

[Ankit Bang]

Hello Mike,

Thanks for the quick response.

I agree with the introduction of nonce on client & server configuration, we can use it as a shared secret and create trust between client & server.

How do we manage the nonce?

1. Does this nonce remain constant? Or is there a method on the server side which can create a new nonce via command or something? Currently, in our infrastructure the client agent binary will be in dormant state and only when required based on investigation task, we will enable the binary.

2. Can we enable a client binary with an updated client.config.yaml(xml) file every time? If this is possible we might be able to use this idea to generate nonce on server side and replicate nonce onto client config and run client with new configurations.

Please do let me know if you have any follow-up questions.

Best, 
Ankit

[Mike Cohen]

You can not change the nonce because this is a feature of the deployment. If you change it all existing clients will stop working as they won't be able to connect.

What exactly is your threat model? 

Velociraptor is a zero registration system with clients not needing to be preassigned to the system. They automatically register when first installed. As such by design, anyone that obtains a copy of the distributed msi ( which includes the config file) is able to join the velociraptor deployment.

Our threat model allows this to make it easier to deploy. Otherwise we would need to create a new config file for every single client in advance which simply can't scale to 100k+ clients.

In the new multi org design in 0.6.6 the nonce is used to control org membership so you can create a new org to have a new nonce and that config file will only allow that client to connect to that org. If you only have a couple of clients and are prepared to create new deployments all the time (with custom config files) then it might be ok.

Thanks

Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/velociraptor-discuss/cf83ec3e-6200-470a-87d9-bb3d9a0bce77n%40googlegroups.com.

[Ankit Bang]

Thanks Mike for the response.

What exactly is your threat model? 

In order to answer your question above, let me provide your more information on our deployment model:
In our infrastructure we have restrictions on deploying velociraptor clients in ad-hoc fashion in order to reduce the threat surface associated with 3p binary etc . Instead, we adopted to deploy client binaries on all the systems in dormant(non-active) state. And during the use case of investigation via an EDR solution we activate the client binaries from dormant to Active states, viceversa on completion of task.

When we deploy client binaries in non-active, we can manage the client updates and runtime via our in-house client management solution. For e.g. to automatically update the velociraptor  client version based on new releases etc.

Our current deployment model in steps.

1.  Velociraptor hosted in an ec2 server with dedicated frontend DNS.
2.  Client deployed in a dormant state in a specific file path on endpoints with client config.yam;(xml) configured with associated server configuration and nonce.

3.  During Security incident,

       a. Activate client from dormant state to active state.

       b. Run client(s) via an EDR solution for e.g. "./velociraptor_client --config <client_config_path>"

    c. After investigation, deactivate the client back to its dormant state.

Based on the above steps, We are looking for more guidance on step 3.b where we run clients with a specified client config path. 

1. Is there a method on the server side where we can create a new nonce via command or something? 

2. Can we run a client binary with an updated client.config.yaml(xml) file every time? If this is possible we might be able to use this idea to generate nonce on server side and replicate nonce onto client config and run client with new configurations.

Please let me know if you require more clarifications on the above approach.

Best Regards,

Ankit

[Ankit Bang]

Hello Mike, 

Hope you had a great weekend. Please let me know if you have any questions regarding the response above.

Looking forward to hearing from you.

Best Regards,

Ankit

[Mike Cohen]

Hi Ankit,

I get wanting to only start the client on demand but it's still not clear to me why you would want a new nonce each time? 

Do you specifically not want the client to be able to run outside of you starting it each time? If so why? This is what I meant by threat model. Does your threat model consider the client running outside those times you specify as being a bad thing? If so why?

If you already have the ability to push a unique config file can't you also just push the client binary at the same time?  

Thanks

Mike