Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The story around the Linode hack

straylig.ht

Post reply on HN
Print view View original

21–30 of 175 posts

Re: The story around the Linode hack

#21

Post by blibble »

jrockway wrote: post #8
robk wrote: post #4

That seems somewhat scary if they've compromised domain registrars and are intercepting login data from client sites that way.

It's more scary if they've compromised a SSL CA. A simple DNS attack won't stop your browser from displaying a broken certificate warning. (Though they can always not redirect from http to https and most users won't notice, sadly.)

it's very easy to get your own https cert once you control the dns for a domain, you just set up own nameserver that proxies requests to the original NS (except very specific ones, say those from Verisign), request your "domain control validation" https cert, and bam! valid https cert!

Re: The story around the Linode hack

#22

Post by tiredofcareer »

blibble wrote: post #18
tiredofcareer wrote: post #12

Some hopefully-helpful clarifications of the inside baseball talk from just the overview (I haven't read the full zine), enhanced with inside and general knowledge I've gained in my travels on this mortal coil: - HTP claims to have{, had} access to name.com, which Linode currently uses. This access enables an unauthorized party to update authoritative nameservers for your domain; i.e., if you host at Amazon, very lik…

> For this to go down entirely unnoticed is extraordinarily difficult. I won't say impossible, but damned close without a copy of the zone in hand and with Linode running AXFR disabled (you should be too). There are subzones of linode.com; they wouldn't have gotten them all, and it would have been noticed within minutes. what's stopping the bad guys from just proxying dns queries they don't care about to the original…

Hence why I hedged impossibility, and while I can think of a way that would work, it'd be tricky. You could probably hack BIND to do this (in resolver mode) fairly trivially, but I'll defer to the actual security experts here of which there are many to shed light on whether such an attack is commonly observed in the wild.

My usual suspicion is that in general, the volume of DNS traffic should give you pause before you start putting custom code in the path of answering a query. Clearly it's possible -- Route 53 is built upon that very notion -- and I suppose in this scenario it's feasible.

Don't forget every Linode has a hostname under linode.com. I think splicing yourself in and running a conditional on every query would overwhelm whatever you point the firehose at and you'd have to plan accordingly. All it would take would be to add a couple hundred milliseconds of latency to the average DNS query (even before the inevitable carpetbombing of p99 latency) and a competent high-traffic administrator is going to start looking around.

Re: The story around the Linode hack

#23

Post by canttestthis »

conductor wrote: post #17
davidw wrote: post #15

Earlier quoted context omitted.

> tried to cause trouble for HTP. Here's hoping the FBI "causes trouble" for the lot of them. Breaking into other people's stuff is not cool. If I leave my door open by mistake, yes, that makes me a bit absent minded, or foolish, but it does not give anyone the right to wander into my house.

Well then you are not a hacker. And I hope FBI can not cause trouble for them, they did not do anything unethical in my POV. The server is not a house. Black hat hacking is a mixture of art and politics (I never support hackers who hack for stealing money), and if you want the analogy, they just spotted a fancy lock on the door of some institution (not a private house), lock-picked it and looked what's behind the doo…

Please give me the password to your regular email account so I can read your emails. I won't delete any of them, but your email server is not a house, and I should have the right to read your emails.

Re: The story around the Linode hack

#24

Post by blibble »

tiredofcareer wrote: post #22
blibble wrote: post #18

Earlier quoted context omitted.

> For this to go down entirely unnoticed is extraordinarily difficult. I won't say impossible, but damned close without a copy of the zone in hand and with Linode running AXFR disabled (you should be too). There are subzones of linode.com; they wouldn't have gotten them all, and it would have been noticed within minutes. what's stopping the bad guys from just proxying dns queries they don't care about to the original…

Hence why I hedged impossibility, and while I can think of a way that would work, it'd be tricky. You could probably hack BIND to do this (in resolver mode) fairly trivially, but I'll defer to the actual security experts here of which there are many to shed light on whether such an attack is commonly observed in the wild. My usual suspicion is that in general, the volume of DNS traffic should give you pause before yo…

DNS is very compact (a few hundred bytes a query), you're talking about maybe 10mbit of traffic tops: not a hard problem these days

Re: The story around the Linode hack

#25

Post by tiredofcareer »

kijin wrote: post #20
tiredofcareer wrote: post #12

Some hopefully-helpful clarifications of the inside baseball talk from just the overview (I haven't read the full zine), enhanced with inside and general knowledge I've gained in my travels on this mortal coil: - HTP claims to have{, had} access to name.com, which Linode currently uses. This access enables an unauthorized party to update authoritative nameservers for your domain; i.e., if you host at Amazon, very lik…

> The access that HTP obtained does not, full stop, lead to root on Linode instances without at least one shutdown job or change of root password job showing up in your Linode's history that you did not ask for. If they had access to the database, it may have been possible to delete malicious jobs from people's histories. Even if the user had email notifications turned on, an attacker with full access to the database…

That's a good point and I hadn't considered it. It still reboots your Linode, though; worth considering a 'echo "I just rebooted! Did you expect that?" | mail' in your rc.local for this reason, since a reboot should be an infrequent event.

Re: The story around the Linode hack

#26

Post by LatvjuAvs »

davidw wrote: post #15
RoboTeddy wrote: post #13

Here's an attempt at an explanation/translation: HTP ("Hack The Planet") is a group that likes to break into things. Another (unnamed) group of people impersonated a third group of people ("ac1db1tch3z") and tried to cause trouble for HTP. The impersonators located HTP by examining one of HTP's botnets (a collection of compromised computers that are used to launch things like denial of service attacks). Botnets have…

> tried to cause trouble for HTP. Here's hoping the FBI "causes trouble" for the lot of them. Breaking into other people's stuff is not cool. If I leave my door open by mistake, yes, that makes me a bit absent minded, or foolish, but it does not give anyone the right to wander into my house.

If you have nothing to hide, you don't have to worry :D

Re: The story around the Linode hack

#27

Post by tiredofcareer »

blibble wrote: post #24
tiredofcareer wrote: post #22

Earlier quoted context omitted.

Hence why I hedged impossibility, and while I can think of a way that would work, it'd be tricky. You could probably hack BIND to do this (in resolver mode) fairly trivially, but I'll defer to the actual security experts here of which there are many to shed light on whether such an attack is commonly observed in the wild. My usual suspicion is that in general, the volume of DNS traffic should give you pause before yo…

DNS is very compact (a few hundred bytes a query), you're talking about maybe 10mbit of traffic tops: not a hard problem these days

It's not about size, it's about rate and introducing latency. Just the hijack itself is going to add DNS latency, which is monitored by any competent operations team. Expert operations teams, and I know of one, also monitor the BGP path to their public addresses (including nameservers) to detect things like the Youtube kerfluffle.

Adding a conditional ("do I answer or do I proxy?") on every DNS query -- and there are many -- is going to introduce enough latency to be noticed unless you throw a lot of gear at it. And you're still going to introduce latency by inserting another hop. That's my point, though I do agree with you.

Re: The story around the Linode hack

#30

Post by blibble »

tiredofcareer wrote: post #27
blibble wrote: post #24

Earlier quoted context omitted.

DNS is very compact (a few hundred bytes a query), you're talking about maybe 10mbit of traffic tops: not a hard problem these days

It's not about size, it's about rate and introducing latency. Just the hijack itself is going to add DNS latency, which is monitored by any competent operations team. Expert operations teams, and I know of one, also monitor the BGP path to their public addresses (including nameservers) to detect things like the Youtube kerfluffle. Adding a conditional ("do I answer or do I proxy?") on every DNS query -- and there are…

hell, you could run it on linode and probably be right next to the box you're proxying... ;)
Post reply on HN