James Stanley

Spelunking the Web Servers of the Lightning Network

Wed 29 August 2018

Tagged: bitcoin

I've finally got around to playing with Bitcoin's Lightning Network over the past couple of days. I managed to buy one of the "I got Lightning working and all I got was this sticker" stickers from BlockStream's Lightning store, and I'm in the process of adding Lightning payment support to SMS Privacy.

Lightning Network's (current) method of operation involves every node knowing about every other node. That means it's super easy to get a list of all the nodes on the network. So I did the obvious thing and made an HTTP request to every node for which I knew an IPv4 address, just to see what was out there.

The initial requests were performed with curl -i http://$ip/ . I later manually followed redirects where applicable.

There were 1207 nodes in total and 229 of them responded to HTTP on port 80.

Category Nodes No response 978 (81%) Default web server page 53 (4.4%) Running nginx 120 (9.9%) Running apache 74 (6.1%) Personal page 47 (3.9%) Business page 32 (2.6%) Short cryptic message 14 (1.2%)

(It sums to more than 100% because some nodes are counted in more than one category).

The "Personal" pages included blogs, software repositories, information about the server hardware, Lightning Network donation forms, Lightning Network statistics, etc.

Most of the "Business" nodes were running websites for obviously-Bitcoin-related businesses, but a handful were just ordinary non-technical business websites. I suspect in these cases the corporate firewall redirects all HTTP traffic to the company home page, and some employee of the company happens to be running a Lightning Network node, at work, behind the corporate firewall.

The "short cryptic messages" were messages like "Nothing to see here", "Check back later". I was surprised that over 1% of nodes responded in this manner.

There were 4 nodes with a Server header indicating that they run nginx, but with content claiming to be an Apache default page. I suspect this is caused by nginx sitting as a reverse proxy in front of Apache rather than any attempt to deceive.

I found 2 nodes each that were running Nextcloud, Mastodon, SynologyNAS, or a Tor exit node.

And some of the most interesting pages included:

Some company's internal email-deleting tool. Presumably not intended to be public, and with an interface that implies that its mode of operation is SQL injection (it asks you to input some "database code" to select emails). I couldn't work out what company this belonged to so have unfortunately been unable to inform them that this is public.

A seemingly-infinite stream of MP3-encoded silence. My bash loop that was running the curl invocations spent quite some time trying to download this one before I realised what was going on.

invocations spent quite some time trying to download this one before I realised what was going on. And a JSON dump of one Lightning Node's channel states, including channel balances, which is more info than is publicly available. Publicly, you only get to see channel capacities. Showing channel balances allows an attacker to repeatedly request the information and learn when, and by how much, this node's channel states have changed.

107 of the nodes reported their OS in either the Server header or the page content:

OS Nodes Ubuntu 75 (70%) Debian 16 (15%) Windows 5 (4.7%) Raspbian 4 (3.7%) CentOS 2 (1.9%) Gentoo 1 (0.9%) Fedora 1 (0.9%) Unix 1 (0.9%) OpenBSD 1 (0.9%) FreeBSD 1 (0.9%)

I suspect CentOS is under-represented here as it does not report its OS out of the box. Probably the same applies to others too.