pull down to refresh

441 sats \ 4 replies \ @frostdragon 4 Apr \ on: I'm Dhruv Bansal, co-founder of Unchained, AMA! AMA

Welcome! I’m super glad you’re here, there’s a specific question I have regarding something you’ve mentioned on podcasts!

I've heard you say you think the future of the internet will run on the lightning network (or something similar), such that every single request sent over the internet will be a literal layer 2 micro transaction.

You've said that will FORCE everyone to take security seriously, because any vulnerability will result in immediate bitcoin loss, and will therefore mostly eliminate zero days and the need for a bug bounty market.

As a security engineer, I don’t understand this reasoning, and I’d love to hear your response regarding the following:

First:

The kinds of vulnerabilities you’re talking about - specifically that would allow an attacker to make requests on behalf of someone else’s server (essentially RCE), or that would allow you to access restricted service functionality (usually SSRF or something similar) - are typically critical level vulnerabilities that DO result in massive financial loss TODAY… And here we are [insert thousands of zero days]. If we wanted to include Lightning transactions via every single request, sure - everyone would have to follow best practices and completely isolate and lock down that specific service. But that would only mitigate a single kind of vulnerability, and does not guarantee ethical or competent developer behavior throughout the rest of the web service.

In other words, destroying the market for zero days doesn’t seem like matter of incentives, it’s a matter of being 100% logically sound all the time. That’s what good code is, and no code can perfectly achieve that. Therefore, it seems bug bounty is a permanent market, even if the internet runs on lightning.

Second:

The methods I’ve seen proposed include sending typical HTTP data via a parameter in a lightning transaction.

In other words, instead of using a data protocol (HTTP) and including payments, we’d be using a payment protocol (lightning), and including data.

That seems inefficient and incredibly restricting, but more importantly, it seems like that would open up entirely new classes of vulnerabilities.

There’s a misconception that security improves over time, but on the contrary¹:

There are classes of vulnerabilities that have not diminished (especially business logic, access controls, or anything that involves a novel implementation)
New services and functionality are constantly emerging, and introducing new classes of vulnerabilities faster than we’re able to keep up with them.

Wouldn't putting the internet on lightning only exacerbates this issue, rather than moving us any closer towards a more secure internet?

All that being said, as a security engineer that’s worked on web2 and web3, I’m sure I have a very biased perspective here. I’m also very exciting for the future of the internet post bitcoinization, I’m very open to being wrong about all of this - so I’d be highly curious to hear more about your perspective!

You can see this reasoning in The Web Application Hacker's Handbook, and this is something I and so many others in cybersec have experienced throughout our careers. ↩

577 sats \ 3 replies \ @dhruv OP 4 Apr

Great question, thanks for engaging me on these ideas -- I think the bitcoin & computer security connection is really interesting and I wish more people talked about it!

To your first question -- you're right, vulns today do lead to significant financial loss. But I think vulns on a bitcoin-powered Internet would lead to even larger and more immediate losses and I believe the difference is large enough to be a distinction.

I'm a bit confused by this point "If we wanted to include Lightning transactions via every single request, sure - everyone would have to follow best practices and completely isolate and lock down that specific service. But that would only mitigate a single kind of vulnerability, and does not guarantee ethical or competent developer behavior throughout the rest of the web service."

^ What do you mean by "that specific service"? In the bitcoin-powered Internet world, any software that can make a network request from your device is software that can be used to steal money from you, since you're directly paying for network requests -- perhaps directly to the source host you're pulling the data from! So if a vuln in my software lets attackers make 1x1 pixel image request to attacker-controlled servers, that's basically a leak of sats my users will suffer. And they'll quickly see it, because it will be exploited quickly, and I'll come to know about it quickly, and I'll have to fix it -- or they'll stop using my software!

RE: the dissolution of the market for zero days -- I'm not making the claim that there will be no bugs on the bitcoin-powered Internet, just that there will be no zero days! Bugs can and will still exist and manifest, but they'll either be unknown to everyone or known to everyone -- the intermediate state of "known to attackers but not known to defenders" (a zero day!) will not exist because as soon as an attacker knows about a bug, if it can lead to the stealing of sats (via, say, the above 1x1 pixel image request attack) then it will be used to attack. It will never be sat on for weeks or months while it gets sold to another attacker in a zero-day market on the dark web. This is not true today -- a vuln in (e.g.) MS Word or some Siemens industrial control software found by some warez blackhat doesn't immediately turn into money, it has to be weaponized somehow first. If web requests cost sats, then it's far easier to turn vulns into money, and therefore selling them on zero day markets doesn't make economic sense.

To your second question -- I totally agree, the current stack is actually very robust after years of engineering on it. If we move to a new stack, that puts data within payments (I like the way you phrased that!) then we will have a boatload of new vulns that we create. You're absolutely right about this. Yet...so what? If the first part of my thesis is true, then these vulns will be quickly exploited because they'll be able to be used to steal sats. So they'll get noticed quickly and can be fixed quickly -- they won't sit as zero days for untold periods of time :)

0 sats \ 2 replies \ @frostdragon 4 Apr

Thanks for taking the time to read and answer my question!

So, I was thinking from the perspective of an attacker being able to leverage a vulnerability that would steal from the app as opposed to other users.

It seems like if I can isolate my application’s payment validation service (similar to the way SSRF is typically mitigated), other vulnerabilities within the application couldn’t be leveraged to access that service and steal from me.

But I hadn’t thought as much about attackers leveraging victim accounts…

But that leads me to the infeasibility of this whole thing in the first place.

It sounds like you’re talking about classes of vulnerabilities that leverage the fact that a browser is happy to automatically make whatever HTTP request the app tells it to. (Fwiw, that doesn’t include all critical severity/zero day vulnerabilities, but that’s a different tangent).

That seems to be based on the idea that LightningInternet browsers will similarly be happy to automatically send payment(request_data).

If that were the case, it’d be INCREDIBLY difficult to convince anyone to join LightningInternet, IMO. I wouldn’t visit ANY website if I had no control over how many requests (payments) are being automatically sent from my browser, no matter how trusted it is. If a single lapse in ethics or security competence can result in a lightning wallet being DRAINED, I’d stick to HTTP apps.

We’d have to build an entirely new internet that functions completely differently that would have an incredibly high security barrier to entry even without the new classes of vulnerabilities that will inevitably emerge.

To me, seems like we can accomplish a lot of the same incentives by building on established security and protocols, and ease into the new unknown a lot more smoothly by simply putting lightning payments into HTTP requests as frequently or infrequently as contextually makes sense.

10 sats \ 1 reply \ @dhruv OP 4 Apr

You're right to frame bitcoin-powered Internet as creating a huge, new space of vulnerabilities. If lightning browsers uncritically call payment(request_data) then bad stuff will happen. People would have to develop rules to limit carefully what kinds of data they're willing to send and receive. Subversions of those rules, or the systems which enforce those rules, would immediately lead to costly and therefore quickly noticed attacks.

Bugs which caused such subversions would not be zero days because they'd be exploited in the wild by their discoverer immediately upon discovery, not hoarded and privately sold in a darkweb market. After all, someone else could find that bug and start profiting from it, exposing it for all to see and squash. The economic incentive (of a blackhat) is to exploit a networking bug immediately before someone else does. This gets bugs fixed faster.

"Data in payments", to use your evocative framing, makes networking more secure by changing the economic incentives of attackers to shorten the lifecycle of bugs. I think this kind of pattern recurs in other areas such as distributed databases. Think of key-value sets and gets in some giant cloud database that is actually just a market. The same zero-day killing behavior will occur there, too. This is how I see a bitcoin-powered Internet emerging over time :)

0 sats \ 0 replies \ @frostdragon 5 Apr freebie

Interesting perspective. Thanks for sharing! I see what you’re saying a little more about vulnerabilities being exploited immediately…

What you’re proposing reminds me a bit of the scene at the end of Dark KnIght Rises where Bruce Wayne can only make the leap without the rope… More lightheartedly, I call this the Claw of Shame fallacy 😆

In other words, it sounds like you’re saying people will choose lightning internet because it has better security, and it has better security because if it doesn’t, the worst case scenario will happen… and I think I’m either missing some reasoning or missing the technical explanation to justify it, because I’m not sure why people would voluntarily opt in to that in the long run, let alone be a guinea pig…

So I remain curious to see what kinds of solutions people are proposing and building, because I’m all for better security!

First:

Second:

Footnotes