On 8th of August, Kevin Joensen, a researcher at Doyensec (opens new window), contacted our core contributors and responsibly disclosed a vulnerability found in BTCPay Server.
# Impact
Impacted - Third-party hosts. Users that enabled registration for other users and are hosting their server to an unknown, potentially malicious actor.
Not impacted - Regular, self-hosted instances. Users that don't allow registration to unknown, potentially malicious actors.
# How to fix it
There is no evidence that the vulnerability has been exploited in practice. However, we encourage the impacted users to update their servers.
We patched the potential vulnerability in version 1.0.3.127 (opens new window). To mitigate, update (opens new window) your server to version 1.0.3.127 or above.
# Attack Vector
Several XSS (opens new window) issues were present in BTCPay Server where a malicious merchant could create a page which would leak the private SSH key of the host if the host was browsing the infected page.
BTCPay Server has three types of users:
- Host (Admin)
- Merchant (Users)
- Customers (Users paying to a merchant)
If you self-host BTCPay Server, then you are at the same time a host and a merchant. If you are a third party host provider (opens new window), host and merchant are not the same user, because you're allowing other users to register and use your instance.
The vulnerability influences only third-party hosts, that enabled registration for the untrusted users in Server Settings > Policies and their users. The registration for other users is disabled by default when BTCPay Server is deployed.
This vulnerability can only be leveraged by a malicious merchant and target the host, in the self-hosted case the host and merchant are the same person.
Third-Party hosts - If a malicious third-party target a third-party host, and the host clicked on the malicious link, the host could potentially reveal the SSH key of their server allowing a malicious third-party to control it. This could be used in an escalating manner and get control of the server and steal the funds from the Lightning Network
Third-party host users - Merchants of third party hosts could potentially get their information xpub and email address exposed to an untrusted party if the third party host clicked on a malicious link.
# How did it happen:
For several of our features, we allowed users to inject HTML or styles into the rendered page. Some places were incorrectly sanitized allowing a maliciously registered party to inject javascript.
While investigating the extent of the issue we also found out that we were exposed to CVE-2018–0784 (opens new window) found by security researcher at Microsoft (@blowdart (opens new window)).
On top of it, it was a common pattern in the code to inject server-side variable into javascript scripts such as:
<script>var name = “@Model.Name”;</script>
This is however unsafe, and we should have used JavaScriptEncoder or JsonHelper (opens new window) to encode properly.
Kevin Joensen of Doyensec (opens new window) provided a proof of concept that showed us how the attack can be executed.
# Timeline
- 2019-08-07 - Kevin Joensen disclosed the vulnerability.
- 2019-08-08 - Kevin Joensen provided the proof of concept.
- 2019-08-09 - Vulnerability has been patched and pull request submitted
- 2019-08-09 - Pull request reviewed and merged, making sure no breaking changes are made.
- 2019-08-09 - we reached out to publicly known third-party hosts and notified them about the issue, those who we reached out to updated their instances.
- 2019-08-10 - 1.0.3.127 released
- 2019-08-11 - We acknowledged the vulnerability and wrote a blog post, (opens new window) urging affected users to update.
# What we will do:
To mitigate the escalation in case a bug is discovered in the future, we will make sure that the SSH key can’t be retrieve with an ajax request.
# Recommendation:
You don’t need to do anything if:
- You are self-hosted (ie. not sharing your instance with merchants (users) you don’t trust)
- If you have not clicked onto any link made by a merchant using your server
If you do not fall in those category, and believe you may be affected, besides updating, our recommendation is:
- Edit ~/.ssh/authorized_keys on the host, and remove the ssh key of BTCPa and review that there is no key you do not recognize
- Remove ~/.ssh/id_rsa_btcpay
This SSH key is used by the “Update” button in BTCPay Server.
Regenerate keys and commit the changes:
ssh-keygen -t rsa -f /root/.ssh/id_rsa_btcpay -q -P “” echo “# Key used by BTCPay Server” >> /root/.ssh/authorized_keys cat /root/.ssh/id_rsa_btcpay.pub >> /root/.ssh/authorized_keys . btcpay-setup.sh -i
If BTCPay Server gets enough funding in the future, we will definitively consider hiring Doyensec (opens new window) to perform a deeper security audit of our software.
We would like to thank Doyensec team for disclosing the vulnerability in a professional manner and making sure our users stay safe throught the process. We would like to invite other security researchers interested in reviewing the code of an open-source project, to take a look at our GitHub (opens new window).