Hacker News Reader

Comment by stcredzero | Hacker News Reader

People keep on getting hacked. Is it really that hard to prevent that from happening, or is this another case of widespread incompetence and "It won't happen to me" thinking?

EDIT: I've commented here before about the scary potential of the /b/ crowd if some of them ever tried to organize and become activists.

View on HN

The short answer is that it is that hard to fully prevent it from happening. For practical purposes, IT security's job is to make it not worth the effort to break in.

And even if you've built a really secure system all it takes is one user with their daughter's name as their password to make it all moot.

What if you only have one "user" who only logs in through SSH using port knocking and all of the server's other communication with the rest of the net is through encrypted binary data in UDP packets with fixed-size fields?

Then you're fired because the server doesn't actually work.

Then you're fired because the server doesn't actually work.

If I were interviewing you, your answer would be considered nonsense and would cause you to not get hired in the first place. I actually need to write such a server for a product I'm working on. All it ever does is encrypted communications with other machines.

OK, you're right. You'd only be fired in the other 99.9% of cases, where servers have to support standard protocols and normal users.

99.9% of cases, where servers have to support standard protocols and normal user.

True. True for all small and big companies' IT. But if you are a security or even just a forensics firm, then you ought to be in the other 0.1%

OK, so then forget your "super secure" server. I would instead focus on compromising one of the admin computers that has the "special user" ssh key and the port knock sequence; or maybe I will hit one of the servers communicating with this "secure" computer and see if you remembered to bounds check all the data coming in; maybe even see if you network stack has any exploits in its tcp/udp implementations while I am at it...

OK, so then forget your "super secure" server. I would instead focus on compromising one of the admin computers that has the "special user" ssh key and the port knock sequence

Juicy! [making notes to buy a laptop for the express purpose of logging into the server]

maybe I will hit one of the servers communicating with this "secure" computer and see if you remembered to bounds check all the data coming in

All fields are fixed length.

I have to wonder why you consider port knocking to be a useful security-usability tradeoff. If SSH alone isn't "secure" enough for you, then adding a port knock doesn't actually lift it over that boundary.

I just feel better that most of the time, other parties won't be able to even see the actual port.

That sounds like a bad balance of usability to security.

The entire purpose of the machine is to manage session keys. Yes, this is part of a system that will make money. No, it's not a web app. Warning: answering programming/security questions as if web apps are the whole of computing won't win you points with everyone.

Well, for the highly specialized purpose that I didn't know about before you explained it in this comment, your solution works.

And for seeing if someone has the knowledge and imagination to come up with such a purpose, I think I've found a good filter.

> one user with their daughter's name as their password to make it all moot.

I see what you did there.

> And even if you've built a really secure system all it takes is one user with their daughter's name as their password to make it all moot.

If your security design allows anyone to SSH in to obtain significant system access using only a user selected password, it isn't "really secure."

likewise, you could prevent your users from creating such passwords.

Unlike benmathes, I'm going with "incompetence". The /b/ crowd hasn't shown much sophistication (yet) - then again, if this kind of straightforward social engineering works, why bother? (Seriously, a security firm that falls for "please drop the firewall and e-mail me the root password"?)

This is insane and should be cause for extreme suspicion.. As a sysadmin if someone asks you to do this, the correct response is "haha not likely", and at the very least confirm their identity - call them or something. Don't sent the password over email.

It might be that they have never been hacked in this way before, so they don't even consider it. Probably seen older employees do it when they were new giving them the impression that it's just how thing are done.

Not really the answer to the question, but this was the result of social engineering -> http://pastie.org/1535735

So, even if it was secure, in this case it would have happened..

I think if they required the use of a shibboleth or key phrase in the email they could have avoided this.

http://en.wikipedia.org/wiki/Shibboleth

http://en.wikipedia.org/wiki/List_of_shibboleths

Or, have an agreement that all password resets will be silently ROT13'd against what is requested.

So if you say "Can you reset my password to foobar" then your admin knows to actually set it to "sbbone."

They can then just send a normal reply saying "ok your password has been set to 'foobar'" and then as long as both parties remember the secret protocol, you are OK.

You could then also watch for login attempts using "foobar" to warn you of foul play.

That's mostly security by obscurity, in which you're bound to get burned.

Could you elaborate?

The security of that system comes from hoping nbobody will guess your key exchange protocol. The security in real key exchange protocols comes from mathematics problems that would take more computer power than the universe has available to solve. So 'your way' is clearly inferior; the attacker guesses (or is told) that ROT13 is what's going on, and you're 0wned and you will never know. Problem.

Yeah this is really obvious now. When I wrote that, I didn't make the mental comparison to PGP or similar; obviously that provides actual cryptography with essentially the same information-exchange workflow.

Nothing educates like brainstorming in public and being shot down by experts, thanks :)

Though it could be effective, assuming attacker WILL try non-translated version first. Basically run honeypot on default password: if successful login attempt then go into panic mode.

But seriously, the only password in SSH auth procedure should be the one you decode your private key with.

But once you have access to a person's email, you could just go back through the history and look for past communications like this and mimic them. That's my guess about how they were able to ask specific questions about the root password.

Some method of verifying the requester's identity out of band (e.g. 'call me for the password') is really the only way to go.

>'call me for the password' is really the only way to go.

Nope.

"From what I hear - yes... My friends who worked for whitehat security companies would first try to hack staff before hacking servers. Best was to call up the ceo on his personal homephone every night at 3am, until they knew what he sounded like raving mad. Then they called up the admins doing a very good impression of the irate ceo demanding his passwords were reset there and then. Worked a stupid amount of times apparently..."

http://news.ycombinator.com/item?id=2067063

You kind of ignored my point about verifying the person's identity while you have them on the phone.

LAST EDIT: Fine. shibboleths, passwords, pins, safeword cards, emails, texts, callerid, voice, and face to face conversations are all great tools to use when trying to secure some asset. All I'm saying is Go out of band when you want to verify a person's identity. If you are emailing, call. If you are on the phone, and you don't trust them, call them back at their home. Or text them a code and ask them for the code. Or meet in a trusted place and take a DNA sample. Whatever is appropriate for the thing you are securing.

Sure, any of these methods can be compromised through social engineering, blackmail, theft, or violence. That's not the point.

If you care about a password, don't send it through the same channel that you use to verify the person that you are sending the password to. Shibboleths and ROT13ing won't solve the problem of knowing who you are talking to.

How would you identify the person on the phone? Their voice clearly isn't enough. Caller ID can be spoofed. With another password? What happens when they forget that as well? I guess you could require a face to face meeting to reset that password. But by having two alternative passwords, you have increased the attack surface. The user is much more likely to write the second "emergency" password down I expect.

Also, what happens when your helpdesk's VoIP system gets hacked in the same way that the email system got hacked in this case?

Only document the full procedure on paper, and forbid people from mentioning the full procedure except in person. If an admin gets an email asking for a password, they should reply with a fake password, and then await a call to give a real password. Or vice versa. If the person contacting them tries repeatedly, they should feign incompetence and / or laziness, escalating if it gets out of hand (even if escalating means passing to another equal-rank admin.)

This is the right idea. A feedback loop is critical to hacking. If you take away the feedback loop it becomes nearly impossible.

Or just PGP encrypt any emails with root passwords or other details about your system.

Just make sure you decide before the emergency who needs to be trusted with that information, and be smart about how you exchange keys with everyone involved.

>If you are on the phone, and you don't trust them, call them back at their home.

Didn't think of that. Great idea.

We used to do this when managing unreachable firewalls. Dial out to the modem attached to the firewall console and type in that modem's password. The remote modem drops our call, then dials us back with a console login prompt. So even if you had the password, you had to at least be dialing in from our phone line.

old school BBS callback verification!

Reminds me of these tricks: http://www.skepticfiles.org/cowtext/bbs/cbv.htm

A company with truly good security practices would put into place a protocol for transferring passwords over voice comms. I'm making a note right now.

I think it really is that hard to prevent it from happening. Every organization/system is going to have vulnerabilities from time to time. If you are drawing the ire of those who want in, it's just going to be a matter of time. I really think the best way to secure yourself, is not to piss off folks like Anon.

There is nothing such as a perfectly secured system. There are just less and more secured systems.

The effort put in securing the system pretty much defines how much effort and ingenuity is required to penetrate it. Kind of a cat and mouse game or chess.

I'm reminded of the mitnick/tsutomu tales. I think Anon may be in for some hurt with a guy like Hoglund pissed at them. He's been on the front lines of security research for at least a decade.

I had the same thought. Hoglund is a bamf. It'll be interesting to see what goes down.

It is difficult. In this case I am sure they knew Anon will come after them and they were SURE they were secure. But when you play with fire you gona get burned

Reply on news.ycombinator.com