I was doing some technical testing for a friend of mine the other day1, let’s call him George, and came across yet another bad example (or a good one) on security by obscurity failing miserably.

George just set up his first online service portal for his customer base.  He’s running a Pro Shop for a small, independent country club, and is trying to cut back on costs.  He decided to invest in a simple online tee-time reservation system, and move all of his reservations there.  He went to a managed service (that he probably found via the same method in the footnote below) to handle this for him, and they fired up a small blade with a basic Linux installation.  The software is Java based (Tomcat) and uses a MySQL backend to drive it.

Freedom, by Dazzie D

I started with what most security guys would and grabbed NMap out of my tool bag.  The first run didn’t take too long, and yielded a treasure trove of options to take for my next move.  I noticed that both imap and pop3 services offered SSL variants, and both the SSL and non-SSL based versions were available for use.  There was the web server of course, a MySQL port exposed to the internet, a few other basic, well-known services, and then this odd one sitting on port 9878.  I quickly noted the MySQL port, and gave it a test.  Thankfully, someone thought to limit access to the TCP port via a TCP Wrapper, but I’d prefer to just not expose the port at all if the server instance is on the same machine as the web server.  That’s what Local IPC Sockets are for.

Then I looked at this 9878 port and scratched my head.  Before poking around, I wanted to do a little research.  My research turned up not so helpful, and in fact referred me back to the TransScout trojan.  I quickly determined that was not what I was dealing with, and fired up Amap to do further investigation.  It matched a web server!

Next step?  Open it up!  I directed my browser there and found a full management console for the machine ready to accept my input.  Given a few obvious choices with a little bit of insider knowledge, I guessed the password and was in to the system with full administrator privileges.

Whoops!  Why would someone think that putting the administrative software on a different port would shoo away the bad guys?  Is this the same person that would not broadcast the SSID from a wireless access point because they thought that it could not be seen?

I told George to get on the phone with his provider and voice his concerns.  If they did not address them, I had some options for George—most involving moving the site to another provider.

Firewalls and VPNs are really cheap nowadays.  With the same basic know how it takes to get that server up and running, an administrator could put together a simple IPTables firewall (free) and provide administrative access through an OpenVPN service (free), or another kind of browser-based SSL VPN (maybe not free).  A country club surely would not want to have someone dump their entire reservation database, or worse yet, start switching people around.  That would quickly turn into a customer service nightmare.

Security controls are getting cheaper and easier to deploy.  Don’t go half-way on this stuff, find a way to do it right (or as close to approximating right as you can) within the budget you have.  As an added bonus, you might learn something in the process!

This post originally appeared on BrandenWilliams.com.

  1. Sometimes security guys get tagged like other techies and we’re some guys best friend’s college roomate’s sister-in-law’s cousin, twice removed on her MOM’s side (that’s very important apparently), and we get to try and “hack our way” into someone’s online presence. []