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

31–40 of 175 posts

Re: The story around the Linode hack

#31

Post by soulclap »

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…

I already upvoted this but wanted to take the extra time to say thanks for your post.

This whole thing really makes me wonder how many hacks and deals behind the scenes are going unnoticed.

Re: The story around the Linode hack

#32

Post by tiredofcareer »

caf wrote: post #19
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…

If you've redelegated a domain which you don't have a full copy of to your own servers, couldn't you just proxy all the requests that you don't want to hijack to the original name servers?

To save vertical space, I'll refer you here: https://news.ycombinator.com/item?id=5667471

Re: The story around the Linode hack

#33

Post by [deleted] »

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.)

[deleted]

Re: The story around the Linode hack

#35

Post by sillysaurus »

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…

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.

Hm, why? Any modern CPU is blazingly fast. Writing it in Ruby probably wouldn't be smart, but Python + PyPI or Lua + LuaJIT would easily get within a factor of 10x of C.

Re: The story around the Linode hack

#37

Post by tiredofcareer »

sillysaurus wrote: post #35
tiredofcareer wrote: post #27

Earlier quoted context omitted.

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…

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. Hm, why? Any modern CPU is blazingly fast. Writing it in Ruby probably wouldn't be smart, but Python + PyPI or Lua + LuaJIT would easily get within a factor of 10x of C.

I didn't say it would be technically impossible, I said it would be noticed. If you make it a theoretical problem, and it most certainly isn't (there are a lot more practicalities involved), you're adding at least another string compare to every query. That's enough of a latency shift for me to notice in my graphs -- I notice when the Internet reroutes itself and my DNS latency goes up by 5 milliseconds.

This isn't a "could it be done?" exercise, it's more of a "could it be done without detection?" exercise. For this specific case, it's a pretty big risk.

Re: The story around the Linode hack

#38

Post by amitdugar »

EvilLook wrote: post #36
amitdugar wrote: post #34

Slightly OT, Is it possible to have a web application (using popular tech like RoR, PHP etc.) that cannot be cracked by anyone ?

Only if the server is switched off and disconnected from the network.

Ha :) I guessed so .. It is impossible to make an un-crackable system .. not sure if that is a good thing or bad ...

Re: The story around the Linode hack

#39

Post by bstpierre »

[deleted] wrote: post #33
jrockway wrote: post #8

Earlier quoted context omitted.

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.)

[deleted]

It said "not redirect from http to https" -- meaning that when someone requests http://example.com they would normally be redirected by the site owner to https://example.com, but the attacker could just leave the original request alone. The point is that most people wouldn't notice.

HTTPS Everywhere or similar browser plugin would probably pop up an alert if this did happen.

Re: The story around the Linode hack

#40

Post by sillysaurus »

tiredofcareer wrote: post #37
sillysaurus wrote: post #35

Earlier quoted context omitted.

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. Hm, why? Any modern CPU is blazingly fast. Writing it in Ruby probably wouldn't be smart, but Python + PyPI or Lua + LuaJIT would easily get within a factor of 10x of C.

I didn't say it would be technically impossible, I said it would be noticed. If you make it a theoretical problem, and it most certainly isn't (there are a lot more practicalities involved), you're adding at least another string compare to every query. That's enough of a latency shift for me to notice in my graphs -- I notice when the Internet reroutes itself and my DNS latency goes up by 5 milliseconds. This isn't a…

I wasn't speaking theoretically. I don't understand how a pipe read + string compare + pipe write would add 5ms per query.

As for detection, that was the reason I brought up CPU power. Modern CPUs are so fast that that it seems like this redirector would hardly generate a blip in any chart (such as top).

I don't care about proving anybody wrong. I care about filling my knowledge gaps. I.e. it's interesting to try to figure out how something like this would be detected in practice.

Post reply on HN