Questions regarding publicly exposed Disaster Recovery

Hey everyone,

first of all, I am not familiar at all with Vault but stumbled upon an exposed instance of it while working on a BugBounty Program on HackerOne. I found multiple instances, some requiring a Login and others exposing a Disaster Recovery Page without a login.

Since I am not really familiar with Vault and only read the documentation so far, I am not 100% sure if those exposed instances pose an actual threat to the company and am therefor seeking advice.

Bellow you find a screenshot of the two pages I am able to access( information that could expose the company is greyed out)

Details Page:

“View Primary Cluster” links to an external IP on Port 8200 which does not seem to be accessible.

Manage Page:

Now this page seems to be more interesting.

  • I can access the “Promote cluster” feature, which if I understand correctly, would allow me to promote this cluster, which is currently secondary, to the primary. Would this allow a threat actor to access more features, and possibly the vault?

This feature also allows to specify a “Primary cluster address”. Could a malicious actor just setup their own Vault instance and then promote their own instance as a primary and access data?

  • Generate operation token
    This options seems to allow me to generate a token needed to Promote a Cluster

  • Update Primary
    The description reads "Use a secondary activation token to change this secondary’s assigned primary. This does not wipe all data in the cluster. "
    Could a malicious actor setup their own Vault instance and then use this feature to assign this secondary’s assigned primary to their malicious primary?

I cannot access any other features than the Disaster Recovery it seems, since every other endpoint forwards me back to this Disaster Recovery.

Note: Since I do not have knowledge on the product, I will not try to exploit it but include theoretical vulnerabilities in my report. I also don’t know if they use these instances in production, development etc. and don’t want to cause any issues/outages.

Thank you very much, I appreciate any insights

Hi @yephex,

Performing any of the actions available via the GUI requires the use of recovery key(s) in order to generate a DR Operations Token on the secondary.

This tutorial has more information on how to perform some of the operations:

If you were to be able to promote the DR cluster to a primary, then whatever configuration is synchronized from the actual primary would become accessible, provided you have a valid authentication token. If you have the recovery key(s), then you’ll be able to generate a root token as well.

As for whether it should be accessible or not over the public internet depends on that customer’s risk model. Personally, I wouldn’t expose a Vault instance to the public internet. But if I did, it would be going through a proxy where only the active cluster was accessible and heavily monitored.

Hey @jeffsanicola ,

thank you very much for the thorough explanation!

Since a recovery key is needed in order to generate a DR token, which I obviously don’t have access to, I guess, I won’t be able to do much.

I will report it to the customer anyway, just to make sure they are aware of it.

Thank you very much again, really appreciate your help!

Have a great day