Strengthening security in the Bitcoin ecosystem: the case for improved vulnerability communication

How to inform users about critical vulnerabilities when you don't know who they are

Disclaimer: This article is not meant to assign blame or point fingers to any projects mentioned in it. The purpose is to educate and improve overall security posture of the bitcoin ecosystem. It particularly focuses on lightning due to the hot nature of the funds.

Vulnerabilities happen. Open source is not immune to this, and no matter how many eyeballs are on the code SHTF sometimes. That is inevitable, and critical vulnerabilities in tools used by the entire world in the last 15years have proven that much. We had Log4j, Heartbleed and Struts exploits to name just a few that impacted huge parts of the internet. And bitcoin ecosystem is no exception, but it can make things a bit more complicated due to the nature of what we're dealing with - money.

Last year Burak's adventures showed us how bugs can effect everyone immediately. But with open source there is no list of customers. No software phoning home where you can quickly see which customers might still run vulnerable version, no emails or phone numbers to contact them that their funds are at risk. As luck will have it the lightning industry was (is?) still small at the time and most of us degenerates spend too much time on twitter, telegram groups and discords. So it was fairly easy to drum up together a large number of impacted companies and node operators and inform them of the issue. But this doesn't scale. And bigger blocks don't solve this scaling issue. Also not everyone reads developer mailing lists 24/7 in case something might happen.

We need better ways to communicate with users of open source projects.

While financial industry has always been a juicy target bitcoin made it that much more interesting. No more stealing credit cards and social security numbers, making it cumbersome and complex to monetize your hacking expeditions. With bitcoin, if you have an access to the server (hot wallet), you have access to the funds. And transactions are final. Which means that security and fast reaction times are that much more important.

Everything in lightning network is a hot wallet. That means that we need to not only write the best code (it will still have bugs), but we also need to have the processes to address the inevitable situations where things go wrong.

I've already mentioned lnd issues last year, but that is not the only example. Recent LNBank vulnerability that lead to at least one confirmed loss of funds is a good example. Luckily the vulnerability was in the plugin, not btcpayserver itself, but next time we might not be that lucky. It was announced on twitter, nostr and shared on various chat platforms. But how many of the 1000s btcpayserver installations were updated immediately because of that? Surely the usage of LNBank is probably significantly smaller than the number of btcpayserver deployments, but what happens next time when the vulnerability is in the btcpayserver itself.

Another example is lnbits which is a very popular tool that mostly has publicly exposed instances connected to lightning nodes. It also has a rich plugin system and rapid pace of development which makes it a great target for malicious actors. LNbits has a system for notifying their users about potential issues, but its based on the admin being logged in and visiting install page for plugins. I don't know about you guys, but I don't visit that frequently, neither I'm that frequently logged in to the lnbits itself. But I use the services of my amazing lnbits instance daily!

I could go on and on with more examples of popular software in this space, but lets focus on how we could address this.

Proposal

IT Security industry has a long established practices on how to deal with vulnerability information dissemination - they use good old RSS feeds. RSS has been around for ages, its very simple to integrate into everything. From chat clients to incident management tooling, any everything in between. And this is something every popular software and implementation should do. Maintain an RSS feed that is used exclusively for announcing critical vulnerabilities in your software. This can't be your blog's rss feed because people don't want to get woken up in the middle of the night by notifications about your new product release. But if there is a 0day vulnerability in part of my software stack that is touching a hot wallet I very much want to be woken up by my alerting system.

PSA: New release on github is not a sufficient way to announce urgent updates.

There are a lot of examples of this in the wild, Microsoft is publishing information about public vulnerabilities that haven't been patched yet on its rss feed. AWS is using RSS feeds to inform its customers about security issues impacting them, so are other big vendors.

To make this article more than just a rant - I've already mentioned this idea to btcpay crew both on mattermost and in a github issue. If you read the blog post by Dennis possibility of adding RSS to btcpayserver as future improvement.

Alternatively dedicated security mailing lists could be used to similar effect, but the overhead of collecting emails, running mailing list services (or paying for them) makes it suboptimal. Not to mention much bigger composability of RSS over email.

Opportunity

Having a public feed also enables nudging users to start implementing some operational awareness of what is going on with the their software stack. It is not the same as asking users to follow you on twitter for product updates. And I’m by no means saying that we should stop announcing things on popular venues like nostr, twitter and SN - far from it. The point is that it should be done as an addition to the dissimination over RSS, not as a replacement.

I’m not keen on starting another “spec” group but if there is enough interest there could be an opportunity to create a blueprint for open source projects in the space to remove the burden of implementing this on their own.

If any project or company wants to jump on implementing this for their own project and needs help feel free to get in touch (email or X) , I’ll be happy to assist.