Interesting run down of the incident that took Zeus offline. Seems like it was connected to the BTCPay Server thing, but not necessarily the Boltz thing.
On August 5th, an attacker gained access to ZEUS infrastructure. The entry point was a recently disclosed vulnerability in BTCPay Server, which we use for auxiliary functionality in our stack including providing fiat currency exchange rates and accepting donations. The vulnerability allowed attackers to obtain the admin macaroon for a connected LND node, the credential that grants full access to that node. This wasn't unique to us. The same bug was exploited against many BTCPay instances across the ecosystem.
The attacker stole funds from ZEUS's own operational wallets. That loss is ours alone. The company absorbed it, and no customer funds were involved at any point. It's the deal you sign up for as a non-custodial operator: your funds are yours, the operational risk is ours. We took the hit, but the model held.
Credential files at rest on disk. Macaroon files, the credentials that grant access to a Lightning node, should never sit where other services can reach them. Ours could be reached from the compromised service, and that's what turned a web vulnerability into node access. That pattern is gone from our infrastructure. It's also the single most transferable lesson here: if you run a node, go look at where your macaroons live. Right now.
One point of precision on our original advisory: we said we found no evidence this incident resulted from a vulnerability in Lightning node software. That holds. The vulnerability was in BTCPay Server. LND did exactly what it was designed to do when presented with valid credentials. The failure was that those credentials were reachable at all. That part's on us, and we've fixed it.
This part sounds familiar:
Our attacker was more capable than a script kiddie. They were also clearly not a Bitcoin specialist. Their actions during the incident showed a limited understanding of how Lightning actually works, which shaped what they could and couldn't do with the access they had.
Although they kind of later add color to this by saying, "a leading frontier AI model couldn't find the underlying bug on its own" and that "The models aren't moonshotting these attacks. They still need an operator with real context to point them."
Sad to read! Tired of all the thefts. Just because you can steal something doesn’t mean you should!
North Korean honeybadgers also dgaf
y tho?
cuz it's deemed morally defensible to steal from evil.
We the evil ones I see.
To them, sure. There's always 2 sides to a conflict. 2 evil sides, 2 good sides.
ahhh 😆😆😆
As I always said: compartmentalization is key.
I just laugh seeing people still using those bundle nodes like Umbrel, Start9 etc... running nodes together with all kind of crap apps.
Systems design is still a thing. Even if you have a massive k8s cluster, all it means is that instead of designing physical systems, you'll have to design namespaces... there is no quick fix / just gotta do the work.
Damn! So it was the attacker who closed the channel! I was wondering what was up.
Best of luck to you Zeus, you have a great product and service and the community should support your transparency!
compartmentalization's right but the macaroon scope is what bit them. a btcpay box only needs to read rates and issue invoices, it never should've held the admin macaroon at all. admin macaroon is node root, and scoped macaroons exist exactly so a web bug can't escalate
compartmentalization's right but the macaroon scope is what bit them. a btcpay box only needs to read rates and issue invoices, it never should've held the admin macaroon at all. admin macaroon is node root, and scoped macaroons exist exactly so a web bug can't escalate