Live data from Hacker News

Hijack of Amazon’s domain service used to reroute web traffic for two hours

doublepulsar.com

271–280 of 291 posts

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#271
post #151

Earlier quoted context omitted.

> HSTS just means use HTTPS. It doesn't validate the previous cert. That is HPKP which almost nobody uses unless they control the client, such as mobile apps. I thought HPKP is TOFU, not (necessarily?) preloaded? Meaning you don't need to control the client for the client to be able to take advantage of it?

There might be a small preload list for HPKP. I'm pretty sure google uses key-pinning on their domains on chrome. Not sure if they use HPKP for that though.

I think chrome now ignores HPKP headers, and only respects the pre-load list. The risk of someone hijacking a domain, and inserting a malicious HKPK header had become too high.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#272
post #170

Earlier quoted context omitted.

Not an expert either, but I think it was slightly different. Firstly, I believe BGP hijacking works by announcing a more specific prefix rather than path-length. That is to get to 3.3.3.3 A 3.3.0.0/16 route takes precedence over a 3.0.0.0/8 route. Secondly, this attack did not obtain a valid cert. They probably could have using spoofing (either of MX or just of A records and using lets-encrypt), but they did not. Thi…

Yeah you're correct. There was a great defcon presentation on this in 2015: https://www.blackhat.com/docs/us-15/materials/us-15-Gavriche... Really the hardest part of the attack, and what makes it so infrequent, is the social engineering aspect of registering the AS and getting an influential peer to accept your advertisements. To really cover your tracks you would need fake identities, fake businesses, fake bank acc…

what's an AS?

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#273

Earlier quoted context omitted.

The TLS WG can haggle about DANE all it wants, but DANE is a dead letter: it was tried in two of the four major browsers and failed, and a third (Safari) briefly had nascent framework support for it and jettisoned it. Without support from the browser vendors, DANE is irrelevant. The big problem Chrome had with DANE was that they couldn't (and presumably still can't) assume reliable DNSSEC/DANE record lookups. If you…

So, you should not be surprised (but perhaps you are anyway) that how to work around not having DNSSEC on end systems is exactly what this work was about. Specifically, the idea is you shove DNSSEC RRs into TLS. Now the client doesn't need working DNSSEC, because the DNSSEC records were delivered with the connection. Hence the pinning question.

There's also https://tools.ietf.org/html/rfc4956 , which allows a domain to sign that a range of DNS entries does not exist; under this system, a client resolver could demand cryptographic proof that a domain was missing certain records, which stops the MitM RR-stripping attack.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#274
post #176

Earlier quoted context omitted.

> But MEW doesn't have HSTS? I would never use it personally on a public Wifi, but many people will for sure and they have no idea they'd be MITM'd. Even without HSTS a bad actor would have to either trick a user to install a root cert or trick a certificate authority to generate a cert for the domain. Both of these are possible and have happened in the past, but they're also are a requirement for the attack you ment…

No they wouldn't, without HSTS a bad actor (public wifi) could just do an SSL strip attack. Sure, observant users would notice that the page isn't over https, and with browsers adding warnings on all http pages, that'll become more obvious, but it's still not something most people notice. Are you thinking of HPKP?

ah, yes, I was confusing HSTS with HPKP.

Now I need to re-read the whole thread with this context. Thanks for the correction!

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#275
post #149

Earlier quoted context omitted.

It is extremely unlikely that they did what this article claimed. If they did, this is what would have happened (this ignores specific implementations which may make certain parts of this impossible which in turn would completely block this kind of attack): 1. Attackers would have noticed that either AWS does not register their prefixes or some of the prefixes were not registered or their registered policies did not…

It looks like Amazon announces /23s, but there were announcements for the more specific /24s today, starting from around 11:05:42 UTC, the routes were withdrawn at 12:55:35 (to be more specific, that's when RIPEs probe saw the changes). https://stat.ripe.net/205.251.192.0%2F24#tabId=routing As far as I know, most of ASNs only filter routes coming from their direct customers (if even that and even in that case they ar…

Well, in that case Amazon needs to hire better backbone engineers. For anycast they should always be announcing both covering routes and de-aggregated routes.

They should also be constantly monitoring views of AWS network from other BGP speaking networks, allowing them to immediately detect such poisoning. If other important BGP speaking network does not want to provide them the view, they can go to a single-homed with BGP customer of such network and buy the view.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#276
post #249

Earlier quoted context omitted.

Because large networks do not register all their prefixes or enforce policies on what they accept from other large networks. So a large network can do this. Allowing a small network to do this demonstrates incompetence. Frankly, I am having a hard time believing that HE.NET failed that badly. AS7007 incident demonstrated this being a bad idea in the nineties.

> Frankly, I am having a hard time believing that HE.NET failed that badly. Believe it. HE has many, many netiron-based routers in their network and many, many ASNs as transit customers. the hardware doesn't have the capacity to implement complete filtering for everyone. between hardware-constrained equipment being replaced and the tireless work Job Snijders (& others) are doing with route security, these kinds of ep…

Half if not all of HE business model is to sell dirt cheap flat rate IPv4 with BGP to other companies in major carrier facilities. I find it extremely hard to believe that not filtered access to HE.NET is possible.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#277

Earlier quoted context omitted.

Yeah you're correct. There was a great defcon presentation on this in 2015: https://www.blackhat.com/docs/us-15/materials/us-15-Gavriche... Really the hardest part of the attack, and what makes it so infrequent, is the social engineering aspect of registering the AS and getting an influential peer to accept your advertisements. To really cover your tracks you would need fake identities, fake businesses, fake bank acc…

what's an AS?

AS = Autonomous System (see Wikipedia). This is the corporation or entity to which an IP prefix (min /24) is registered, and which shows up in queries on sites like ipinfo.io.

BGP Path to Target IP prefix = ordered list of autonomous systems to reach target IP prefix

The point of BGP is to find the shortest AS path to an IP. Each AS has at least one router, and each router has at least one other AS peer. A router will forward the packet as far as it can given the peers it knows, until the AS list is length 0, at which point the controlling AS routes traffic to its destination.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#278

Earlier quoted context omitted.

I'm trying really hard here not to be snide, but it is amazing to me that an organization that is responsible for securing the world wide web is basing that security on the hope that nobody can spoof 3 AS's at once. Just give up on BGP. Strongly suggest people use DNSSEC. For TLDs that don't support DNSSEC, require a public key issued to the registrar. You (the Certificate Authority) can get the public key from [R]WH…

> Strongly suggest people use DNSSEC. For TLDs that don't support DNSSEC, require a public key issued to the registrar. I think this is absolutely unreasonable and damaging to me as a small player. I don't want to give my registrars more power to mess with me, they already refused to support DNSSEC on my domain because I am not using their hosting service, I don't want them to be responsible if I can get certificates…

DNSSEC is a limited hack. Ok? I only suggested using it at all because it can be used right now to secure the process of generating certs. There is a very good reason I don't want to put all my eggs in that basket.

The root servers and TLD are not supposed to be the authoritative source of trust for your domain. That is the registrar's job. That is the registrar's only job: control my domain, and don't let anyone fuck with it. Hence, they should be the ones to keep a record that you can control to tell people where trust should lie. If you don't like your registrar, you can transfer your domain to a different one.

The purpose of DNS is to be a phone book. When you call a number from the phone book, the person you are calling might not be who you expect, even if you got the number from a very trustworthy source. Perhaps a spy is sitting on the other end of the phone. After you connect to the phone number, you should authenticate the other end.

Why not put the authentication information in the phone book? Because you got the phone book from one place. The spy could have compromised the phone book, and now you have no way to know if your authentication is real. It is a better idea to have one phone book for calls, and one separate authentication book that you get from a separate source.

DNSSEC's security depends on one child publishing one key to one parent. If you attack that one factor successfully, the security is broken, and there are multiple vectors to attack. There is no defense in depth. For a highly motivated state actor, this is not difficult to circumvent. The more you lean on DNSSEC, the more fragile the entire internet's security becomes. A better method is to decentralize and distribute trust into multiple organizations and processes, so that it would be very difficult to compromise an entire internet system.

I haven't mentioned the many fundamental problems with DNSSEC rollout and use because I think those are mainly a problem of lack of incentives, and are addressable. Go ahead and use DNSSEC if you want. Just don't tie a rope around your neck by making all internet security dependent on it.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#279

Earlier quoted context omitted.

Yeah you're correct. There was a great defcon presentation on this in 2015: https://www.blackhat.com/docs/us-15/materials/us-15-Gavriche... Really the hardest part of the attack, and what makes it so infrequent, is the social engineering aspect of registering the AS and getting an influential peer to accept your advertisements. To really cover your tracks you would need fake identities, fake businesses, fake bank acc…

what's an AS?

Autonomous System.

Basically, a top level Internet shard. You need to become a Real ISP to pull off this attack.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#280

Earlier quoted context omitted.

what's an AS?

Autonomous System. Basically, a top level Internet shard. You need to become a Real ISP to pull off this attack.

That may be technically true, but not by any layman’s definition of an ISP. An AS can be a tiny company (I’ve been one) as long as it has some IP space SWIPed (registered) to it with ARIN/RIPE. All you need is to fill out a form.

Then you need to find other ASes to peer with you of course.

Also note that technically all you need is the ability to advertise routes. That could be mutually exclusive from AS status if your server provider is willing to advertise routes from their AS on your behalf (like vultr does, I think). In that case the provider is acting irresponsibly and should validate the routes.

Post reply on HN