The Weakest Link is Always the One Behind the Keyboard

Note: this story does not represent my role in my current company, but a gaming community that I run in my spare time.

Let me tell you the story about a server. I, like many of you, host servers for various activities, on various hosts. Each of these servers are secured to a standard that I would like to say is high, at least by comparison to other servers on the web.

Separation of duties for users, ensuring each service has its own account, SSH access on a non-standard port using certificate-based authentication. Firewalls, fail2ban, OSSEC, Suricata.

So, how do you formulate a plan to take down a host such as this? You can probe it all day long, maybe for weeks, scouring for that 0day application vulnerability that will be your stepping stone into the server.

But you’re impatient. Why take all that time?

So you decide to use social engineering to your advantage. You do research on the owner of the server — name, address, phone number. All this information is fairly easy to find, and is probably the number one activity most people do when they want to attack something.

This is exactly what happened to me. I’m pretty careless with my information. I don’t care if people know who I am, where I work, what I do for a living. This was careless of me. While there was no direct attribution to me from my domain, I made the mistake of originally registering it without WHOIS guard.

An individual who decided they wanted access to the databases on one of my servers decided that the direct approach would take too much time. Instead they went the roundabout way of directly contacting my web host.

The person called up the customer care line of the web host and successfully social engineered the customer service representative into resetting the password on the account. This was a major failure on the part of the web host — internal policies were broken. I’ve spoken with a rep from the company, and they fully agree that procedures weren’t followed.

But remember: the entire security of your server is in the hands of a customer service representative who often doesn’t get nearly enough security training, while given access to a plethora of tools that would make the average sysadmin cringe.

Once the account password was reset, the individual was able to use the serial console to gain access into the VPS, reset the root password, and then proceed with exfiltration of the database. All in all, this took less than two hours. Once I noticed I had lost access to the server, I called into the company to start triage. After reviewing the logs, the individual was smart enough to cover their tracks using an anonymous VPN. Not taking chances, the server was restored from a backup taken the day before.

This led to a lot of follow-up work: coordinating with the web host to determine what happened, relying on our BCP to ensure services were restored in a timely fashion, password resets across the board, and the dreaded email to customers informing them about the breach.

This can all be avoided. If you are using a cloud-based provider for any service at all, call them up and ensure you have some form of secondary authentication. Most providers support a callback feature or a code-word system. Anything that can protect you from a social engineering attack can save you time, money, and sanity.

Let this be a reminder: no matter how secure you may be internally, any time you use a host that you don’t directly control, your security is in their hands.