Thursday, July 26, 2007

Security vulnerabilities and the realm of the really-really-hard

Some security vulnerabilities are easy to exploit. E.g., brute-force
guessing of passwords when trying to login to a device that's on the

Others are practically infeasible -- like factoring two 20-digit
prime numbers to find somebody's encryption key.

But somewhere in the middle, you the exploits that are really-really-

One thing I do commonly is setup an SSH server, give it a public IP
address, and setup a firewall to allow only a few specific IP
addresses to login to it. The weakness in this design is that it's
subject to IP spoofing. And it uses reusable passwords.

But is it? To take over, and gain remote access to the SSH server,
you have to login to it. Somehow you have to get into the middle of
the stream.

Let's call those permitted IPs the "clients". To even get a chance to
guess passwords against this SSH server, you'd need to:
-- Know the clients' addresses that are allowed through the firewall
-- Be able to eavesdrop on the traffic from the SSH server and the
-- Be able to prevent the FIN'ing connection traffic for those
connections it didn't start; i.e., interrupt the flow of traffic. If
you just inject a packet with a spoofed IP address toward the SSH
server, when the SSH server responds, it'll go back to the true
client. The true client will usually send a TCP FIN because it's not
a connection that the true client initiated.

Unless you have control of an ISP along the path -- you really can't
do this. Even if you have control of that data, it could be really
hard to get in this one path.

Almost anybody can transmit a spoofed packet. But if you don't have
control over an ISP along the path, all you can do is inject packets.
But if you can't see the SSH response coming back, you can't
participate in the DH key exchange. Your attempt to attack would be
immediately squashed.

This is an example of a security practice that's not the strongest
possible thing, but it's really-really-hard to break.

No comments: