Computer security breeches happen a lot. More than you care to know. Big business, small business, or home user, it doesn’t matter. You’ve got something the bad guys want. Even if it’s just to use your computer for their own nefarious purposes.
The Call No One Wants
Back before my company offered security consultation as a service, one of our small engineering clients got a nasty surprise. They received a call from their internet service provider (ISP) saying that there was an inordinate amount of email being sent from their IP address. To find out what was happening, the company tried logging into their server. They couldn’t. The password wasn’t working. That’s when they called us.
The Diagnosis
It wasn’t hard to deduce what had happened. The server had been hijacked and was most likely being used to send out gobs of email spam. But because the crook had changed the passwords, there was no way to log in and see. We were going to have to hack the administrator password in order to regain access. This is not a normal practice and takes a knowledgeable user with the right tools to do, and is only possible if you have physical access to the computer.
Caught in the Act
Well, a funny thing happened. While I was preparing to reboot the server and reset the password, the attacker actually logged in. I observed him doing all sorts of interesting stuff for a few minutes, amused and amazed at my luck of catching him in the act.
After watching him poke around for a bit, I finally decided that I couldn’t stand by any longer and disconnected the network cable. This, of course, cut him off completely.
Later, we were informed by the ISP that they had received a call from someone claiming to be the server’s operator. He told them he lost his connection and asked that they reset the server for him. Obviously, it was the hacker. He didn’t realize the connection was lost because someone (me) disconnected him. What’s more, he didn’t actually understand who the server belonged to. He thought it was the ISP’s and was mistakenly asking them to fix it for him.
Done Damage
So now, because the hacker had logged in for us, we had access to the server again. Wasn’t that nice of him? However, at that point, there wasn’t really anything we could do to save it. Our only safe option was to completely wipe the hard drives and reload the server, then restore the company data from a backup before the attack.
The reason is that once the attacker has that level of access, he could have installed anything. We could have tried removing all his stuff and kept using the server as it was, but who knows what malicious software he had tucked away deep down in the file system somewhere?
In the end, it cost the company several thousands of dollars in damage control and lost productivity. We consulted with their internet service provider to see what kind of legal action could be taken. Their rep basically told us it was a lost cause. The company would lose more money pursuing it legally than it cost to fix it. And it would more than likely end up at a dead end anyway. The best we could do was report it and move on.
So now, since the server was not going to become forensic evidence, we took a look at it ourselves. I couldn’t believe how much software the attacker had installed. Several different spam servers, remote access programs, and tons of stuff I didn’t recognize.
Made Mistakes
Checking the server logs, it wasn’t hard to figure out how the attacker got in. He had hacked in through Remote Desktop Protocol (RDP) which was wide open to the internet. There were several things that could have been done to prevent this:
- The password was insecure
- The number of login attempts was not restricted
- The port was not disguised
It turns out the company was using a common dictionary word as the administrator password. This, of course, was human error. Not a weakness of the security system. There is a huge lesson here.
The attacker gained access by using a basic brute force dictionary attack to crack the password. There should have been a login failure limit for remote access. Without that measure in place, it didn’t take long to crack the simple password they were using.
Remote Desktop Protocol is port 3389. Everyone knows that. It’s possible to disguise this by giving it a different port number on the outside. That makes it harder for hackers to tell what protocol is being used when they’re foot-printing the network (kind of like “casing the joint”). Of course, the other option was to not have RDP open at all. Nowadays, there are plenty of more secure remote-access methods out there that don’t require any open ports to work.
The Takeaway
It’s unfortunate that it takes an actual breech for most users to understand the reality of the threat against them. Staying one step ahead means adopting persistent security habits into your routine. The mistakes here were so simple it’s sad. This could have been prevented so easily with the most basic preventative measures. If you think you’re not a target, then you’re actually the best target and it’s only a matter of time before you find that out.