
BGP leaks and cryptocurrencies - jgrahamc
https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/
======
mehrdadn
Taking a step back here... shouldn't proving ownership of a domain involve the
domain _registrar_ some way, rather than involving whoever happens to host
your DNS? They know who you are, so maybe they can provide an interface to let
you prove to others that you own the domain. Like I dunno, maybe just let the
owner of the domain generate a unique one-time key valid for 30 minutes, and
provide an API to allow anybody to check ownership if given that key, e.g. at
a standard URL like

    
    
      yourregistrar.com/domainowner?domain=example.com&ownerkey=8719425131715293085

~~~
kuschku
Much easier — allow people to put a public key into the WHOIS database.

~~~
mehrdadn
I don't think it makes sense to force every domain owner on the planet who
wants HTTPS to understand how to generate, store, use, and maintain (more)
public/private keys, especially in a secure manner. Having to deal with SSL
certificates is enough of a pain already, and for this one you'd have to use
another program to sign requests, so there's an added layer of pain. In fact,
I don't think it makes sense to add to the burden of domain owners so much at
all, even if they could all do this.

Not to mention that, more practically there's no need (and potentially
possible harm) to tie the ownership records to a particular cipher. Really,
it's the registrar's _job_ to deal with domain ownership; ideally it shouldn't
involve you at all. And as a near-corollary, they could probably deal with
long-term key security better than the average domain owner.

~~~
hueving
Ok, then we need to stop using DNS. Your record server being compromised
shouldn't be able to imply ownership.

~~~
kuschku
Or we should require DNSSEC for DV certificates.

~~~
IncRnd
You're right that something should be used, but DNSSEC is a weak solution from
a security point of view.

------
isaack
If I were the hacker:

1\. I would get a proper SSL cert signed

2\. Only hijack one of the ranges, and do not respond to other domains
(causing SERVFAIL), so other domains will resolve unaffected, instead of
causing a scene (see:
[https://www.reddit.com/r/sysadmin/comments/8ejrkk/google_dns...](https://www.reddit.com/r/sysadmin/comments/8ejrkk/google_dns_issues/))

~~~
cjbprime
> 1\. I would get a proper SSL cert signed

Uh, how? Are you assuming that a single BGP leak would be enough to cause e.g.
a letsencrypt misissuance for the domain? It sounds like (from other comments)
they have a global round-robin resolver setup for their DNS challenges.

> 2\. Only hijack one of the ranges, and do not respond to other domains
> (causing SERVFAIL), so other domains will resolve unaffected

I think exactly that's what they did. I saw people posting SERVFAILs during
the outage.

~~~
zyberzero
They do, and they don't. They have a round robin setup, for which resolver
that validates the DNS challenge - however, they do not validate the DNS
challenges from several resolvers[1]. So, if that particular resolver got
caught in the BGP leak while doing a challenge verification you could get a
valid cert. Lots of ifs and buts - but it is certainly possible.

[1]
[https://news.ycombinator.com/item?id=16918382](https://news.ycombinator.com/item?id=16918382)

------
thesimon
>A few things can be done on the upper levels of the network stack.

On DNS, you can use DNSSEC to sign your records. The IPs returned by the fake
DNS would not have been signed as they do not have the private keys.

Would this have helped though? The attacker's DNS resolver could just return
records without DNSSEC.

~~~
tptacek
No, it clearly would not have. In a BGP attack, attackers _control IP
addresses_. Whatever your signed DNS record points to, attackers can simply
inject prefixes for.

~~~
AndyMcConachie
The invalid BGP route advertisements redirected folks to the attacker's DNS
servers, which served invalid responses to queries.

In this instance, had myetherwallet.com been signed, and had a user been using
a DNSSEC validating resolver, they would not have visited the invalid site.
The attacker's DNS responses would not have validated.

Had myetherwallet.com been DNSSEC signed anyone using Google's public DNS
resolver at 8.8.8.8 would not have visited the invalid site.

~~~
tptacek
Again: the attackers _control IP addresses_. All of them (or, enough to
randomly claim AWS addresses from places in the topology nowhere close to
AWS). It doesn't matter what the DNS says.

~~~
lsc
So with global anycast bgp, people usually use it for short sorts of things,
preferably single packet requests, and redirect to non-anycast addresses for
longer TCP streams so that there aren't problems from flapping. The idea is
that if one dns packet goes to ns1 and then next packet goes to ns2 on the
other side of the world, we're cool. I get my answer from both, as those two
packets are different queries. But if it's a webserver and packet 1 of my tcp
stream goes to lb1, and packet two goes to lb2 on the other side of the world?
lb2 is going to send me a rst packet because it has no idea about the tcp
connection I'm speaking

In the legitimate world, this usually means you global anycast your DNS
servers, which then respond to queries with IP addresses of load balancers
that are only announcing from one location, out multiple providers.

I think this maybe could be extrapolated to a BGP attack of this nature and
could explain why the attacker, in this case, focused on attacking the DNS
server rather than a different piece of the stack.

I'm guessing that your global anycast setup in the legitimate world is going
to be way more reliable and flap a lot less than whatever the attacker can
cobble together out of upstreams with inadequate prefix filtering.

Note, I'm not trying to claim that the attacker couldn't take over the end
machines that serve longer TCP streams; I'm just pointing out that the
attacker has good reason to attack DNS first if possible, for the same reasons
as the legitimate operators have for using global anycast for DNS and not for
HTTP.

(as further trivia, I _have_ seen setups where the http server was global
anycast, but that webserver only returned really short responses, 3xx
redirects, again redirecting the request to a non-anycast webserver.)

------
mlosapio
Wonder if services like Let’s Encrypt were affected. I imagine a scenario
where a small hijack of DNS could allow for properly signed certificates for
domains that are not owned. If I operated a CA service, I would carefully
examine the requests received during this time frame. Maybe someone can audit
the Transparency Logs during this period for anomalous activity.

~~~
dannyw
BGP hijacks sadly happen on a weekly basis. It’s not new and there are
hundreds more cases. It’s only noteworthy this time because high profile
targets were affected instead of these being used for spear hijacking, etc.

------
SteveJS
Not the meat of the issue, but when I see ‘what is BGP?’ I like the TLA
expanded.

[https://en.m.wikipedia.org/wiki/Border_Gateway_Protocol](https://en.m.wikipedia.org/wiki/Border_Gateway_Protocol)

~~~
jwilk
Non-mobile link:

[https://en.wikipedia.org/wiki/Border_Gateway_Protocol](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)

------
massaman_yams
In a theoretical scenario like this where a hijacker used Let's Encrypt to
receive a cert, rather than using a self-signed one, it's worth mentioning
that there is a defense against that: HPKP - though much like HSTS, this is
only effective for browsers that have previously visited the site.

[https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning](https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning)

~~~
Diederich
Chrome, at least, is walking away from HPKP:
[https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...](https://groups.google.com/a/chromium.org/forum/#!msg/blink-
dev/he9tr7p3rZ8/eNMwKPmUBAAJ)

------
piracy1
It seems like they would have much better and more effective targets. They
could have attacked bitcoin or crypto coin mining pools and just used the
hashing power. It would have worked almost instantly and they wouldn't have to
deal with SSL/TLS. Say a pool mines 20% of the blocks. After 2 hours they will
have mined 2 blocks of 12.5 btc so 25 btc and $220K

(although they would likly not get all the hashing power because not everyone
is taking that route.)

~~~
foepys
How could redirecting traffic of a Bitcoin mining pool make an attacker money?
The transaction to which the block rewards goes is part of the block hash and
thus still under full control of the miner that has the matching private key.

------
vertex-four
So what’s happening with the deployment of RPKI[0]? It would seem that owners
of IP address space would have the incentive to use it - but perhaps routers
don’t implement BGPSec widely enough?

[0]
[https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastruc...](https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure)

~~~
vbernat
RPKI doesn't really solve the problem as it is a proof of origin. You can
still inject routes, just ensure you add the original AS as origin of these
routes.

BGPsec would solve this issue, but is currently not deployed at all (and won't
be before a long time).

------
edf13
Another excellent write-up from cloudflare of a major issue... good job!

------
lostctown
An interesting aspect of this crypto boom over the last year has been the
stress test on public internet infrastructure. Just the other day
myetherwallet was hit with a nasty hack.

~~~
mjmj
Which was?

------
bluesign
I find it funny how the article concludes basically almost everyone is
responsible.

And probably nobody will be hold responsible for this other than hacker.

Thats why noone in this chain will have any incentive to fix this ever
occuring again.

------
thisisit
> But during the hijack, it returned IPs associated with a Russian provider
> (AS48693 and AS41995).

Curious what stopped cloudfare from naming these providers.

~~~
d215
suit yourself:

[https://stat.ripe.net/AS48693#tabId=at-a-
glance](https://stat.ripe.net/AS48693#tabId=at-a-glance)
[https://stat.ripe.net/AS41995#tabId=at-a-
glance](https://stat.ripe.net/AS41995#tabId=at-a-glance)

~~~
lostmsu
One of them has just a name: Barbarich Viacheslav Yuryevich

------
return1
i wonder why they dont mention a blockchain solution to dns problems.

~~~
jgrahamc
Sure, let's use blockchain for everything. I mean, why not? It's clearly the
perfect solution to every problem that has ever occurred in any distributed
system.

~~~
return1
how is it not a better solution in this case?

~~~
jgrahamc
What DNS problem are you solving with blockchain and how?

~~~
return1
security, like DNSSEC does. but only 1% of domains use DNSSEC. there are other
advantages, like uncensorability, direct access to dns records, disadvantage
is speed

I am not advocating "blockchain for every problem", but name resolution is a
good fit - if only there were blockchains in the 80s. there are already
implementations: [https://medium.com/@jgm.orinoco/ethdns-an-ethereum-
backend-f...](https://medium.com/@jgm.orinoco/ethdns-an-ethereum-backend-for-
the-domain-name-system-d52dabd904b3)

~~~
cjbprime
This implementation requires you to download tens of gigabytes of data to any
device that you want to resolve a name on. It's a non-starter. (For that
matter, last time I looked, Ethereum was at a point where it's not actually
possible to "keep up" with the blockchain on a machine that isn't in a
datacenter.)

