NetEqualizer News Blog

By Zack Sanders, NetEqualizer Guest Columnist

It’s almost three in the morning. Brian and I have been at it for almost sixteen hours. We’ve been trying to do one seemingly simple task for a while now: execute a command that lists files in a directory. Normally this would be trivial, but the circumstances are a bit different. We have just gotten into EZTrader’s blog and are trying to print a list of files in an unpublished blog post. Accomplishing this would prove that we could run any command we wanted to on the Web server, but it’s not working.

There must be something wrong with the syntax – there always is, right? We have to write the command into an ASP user control file, upload it via the attachment feature in the blog engine, and then reference it in a blog post. It’s ugly, but we are so close to piecing it all together.

I think it’s time for another cup of coffee.

EZTrader is a fictitious online stock trading company. Their front end is relatively basic, but their backend is complex. It allows users to manage their entire portfolio and has access to personal information and other types of sensitive data.

EZTrader came to us with an already strong security profile, but wanted to really put their site through the ringer by having us conduct an actual attack. They run automated scans regularly, have clean, secure code for their backend infrastructure with great SEO, and validate every request both on the client side and the server side. It really was impressive.

In the initial meeting with EZTrader, we were given a login and password for a generic user account so that we could test the authenticated portion of the site. We focused a lot of time and energy there because it is where the highest level of security is needed.

After days of trying to exploit this section of the website with no results, frustration was growing in each of us. Surely there must be some vulnerability to find, some place where they failed to properly secure the data.

Nope.

So what do you do when the front door is locked? Try a window.

We started looking around for possible attack vectors outside of the authenticated area. That’s when we came across the blog. Nobody writes a custom blog engine anymore. They use WordPress or some other open-source blog software. It’s almost always the right choice. These platforms have large communities of developers and testers that look for security holes and patch existing ones right away.

If you stay diligent on keeping your software up to date, you can’t go wrong with choosing an open-source blog platform. Problems arise when keeping this software current falls too low on the priority list. The primary reason this is so dangerous is that all of the bugs and security holes from your dated version are published for the world to see. That was precisely the case with EZTrader. They had an old version of OpenBlogger running on their website. We had finally found a chink in the armor.

We ran a few brute-force password crackers against the blog login form but they weren’t succeeding – access denied. Hmm, maybe it’s simpler.

Let’s do a quick Google search: “OpenBlogger default username and password.”

I’m feeling lucky.

The result: “Administrator/password.” This never seems to work, but it’s worth a shot…“Welcome back Administrator!” Wow. Now we are getting somewhere!

Many of the published vulnerabilities for open-source blog platforms reside in authenticated portions of the blog engine. Logging in with the default credentials was a major step, and now all we have to do is look for security weaknesses associated with that version. Back to Google.

“OpenBlogger 3.5.1 vulnerabilities.” Interesting.

What we find is that you can write code in the blog post itself and have it access any file on the system – even if it is outside of the Web root. This was billed as a “feature” of OpenBlogger. Haha, okay, thanks!

We already knew that the file upload feature of the blog puts files outside the Web root (we had tried accessing an uploaded file directly through the Web browser earlier, but that wasn’t possible due to this segregation). The key was to upload our custom code and reference it through code in the blog post. Once we figured out the path to the uploaded file, we just had to call that path in the blog post and our code would run. Our uploaded file had a simple job. If executed, it would run the “dir” command on the C:\ drive and print out the contents of the directory in a blog post. If we got this to work, the server was ours.

Maybe it’s the coffee, but suddenly I don’t feel so tired. I think we finally have the syntax right. Time to see if this dog will hunt.

Boom! There it is. The entire contents of the C:\ drive. If we can run the “dir” command, what else can we run? Let’s try to FTP one file off of their Web server to our Web server.

Okay, that worked. Let’s now try the entire C:\ drive.

That worked, too.

We now have the source code and supporting files for the entire Web server. This is where a molehill becomes a mountain. First, let’s upload a file that will give me persistent shell access to the drive so we can remove our shady looking blog post and poke around at will. Let’s also upload a file that will send me a text message when an administrator logs into the Web server. At that time, we’ll steal the authentication token and try it on other hosts connected to the network. Maybe it will work on the database server. While we are waiting for the administrator to log in, we’ll review all of our newly acquired source code for security holes that might have eluded us before.

The possibilities from here are endless. We could completely ruin EZTrader’s reputation by destroying their front page, their backend code, or their blog. We could upload more backdoors for access and sell them on the black market. We could sell their source code to E-Trade. We could compromise their other servers that are attached to that subnet.

We could run them out of business.

But luckily, our hats are white. When the CEO sees our report, she is astounded but relieved that we found these issues before the bad guys exploited them.

There are a few lessons that come out of an assessment like this:

It is important to be diligent with security EVERYWHERE. EZTrader’s great infrastructure was rendered obsolete because of one tiny oversight.
Security should exist in layers, and monitoring is crucial. Even if we were able to access the blog, some other process should have thwarted our advances. McAfee or Tripwire should have prevented us from uploading executables or FTPing files off of the server.

In short, security for an online business is paramount. Unlike a breach in the physical world, customers have little tolerance for digital break-ins. Reputation is everything.

In the end, EZTrader’s proactive decisions may have saved their company. It is much easier to prevent an attack than to deal with one after the fact. The cleanup can be messy and expensive. It is increasingly important for all executives and IT personnel to have this mindset, and putting public facing sites to tests like this can be the difference between prosperity and peril.

About the Author(s)

Zack Sanders and Brian Sax are Web Application Security Specialists with Fiddler on the Root (FOTR). FOTR provides web application security expertise to any business with an online presence. They specialize in ethical hacking and penetration testing as a service to expose potential vulnerabilities in web applications. The primary difference between the services FOTR offers and those of other firms is that they treat your website like an ACTUAL attacker would. They use a combination of hacking tools and savvy know-how to try and exploit your environment. Most security companies  just run automated scans and deliver the results. FOTR is for executives that care about REAL security.