Thinking Security: Oh, Oracle What Do You See?

June 18th, 2018ClearPath


This is the 34th blog in a series about security and how security is about how you think.

Recently, I’ve been looking into the ROBOT attack against the TLS (formerly known as SSL) protocol. It’s a unique theoretical attack that tries to gain information about the server’s private key through a brute-force attack against a TLS server (here called the “oracle”, and no, not the company) to get information.

The way that these blind oracle attacks operate is another way that helps us think about security. Think of a blind oracle attack this way – if you’re trying to log in to your favorite website (say Facebook) and you type your username and password and the website sometimes responds “Your password is wrong” and some other times the website responds “Bad username”. Because of this, you can fix what you are typing in order to log in successfully.

That’s great for you, because you’re the authentic owner, but it also works for an attacker. If they get certain responses, it gives them information about what they submitted so that they can change what they submit to get it correct. Now think about additional responses (you’re using an old password, account locked out, etc.) and these add even more information in the response. This becomes even more sensitive when you think of computer systems with well-known accounts and passwords (like Administrator).

This isn’t only a computer-networking problem. If I make the outgoing message on my voicemail system “Hi, my name is Mike Kain and I’ll be out of the office until April 1st, 2018”, then everyone who would hear that would know information about me – from people that I work with to phone scammers. If a hacker heard that information, he then could look up more information and maybe use it for nefarious purposes. Therefore, the most secure message for voicemail is “I’m not here right now, leave a message.”

This is a very big tradeoff when we THINK about security. Security is about checking and verifying every bit of information (and I didn’t say paranoia) to make sure that it is validated. But then we have to think how we respond to that request. The method that we use and what we say or transmit may be different depending whether it’s over the network (remote) or local.

For example, if our computer system receives a bad username and/or bad password, we may return an error to the remote system saying “Bad username or password” without giving any more information about which part was invalid. The username could be invalid, the password could be incorrect or locked out, or the license with that username could have expired. Our computer system (of course) logs this event as a security event and we continue processing. If we see a few of these attempts from the same IP address, we may block that IP address or not even respond. In any case, the attacker (who may be genuine or fake) does not receive any information to go on.

It all comes down to how we THINK about security in the conversations that we have in order to make them secure. Respond generically so that a remote attacker cannot use that information against us (make us the blind oracle), but note (log) locally so that we can understand if that was just a legitimate user mistyping their password or an attacker into our system.


Tags-   ClearPath ClearPath Forward! Security Thinking Security


ABOUT THE AUTHOR

Michael Kain

Mike Kain is a distinguished engineer and security architect for the ClearPath MCP environment and has held various technical leadership positions during his 30 years of experience at Unisys.