Do We Really Need SSL?

By Art Reisman, CTO,,

Art Reisman CTO

I know that perception is reality, and sometimes it is best to accept it, but when it comes to security, FUD, I get riled up.

For example, last year I wrote about the un-needed investment surrounding the IPV4 demise, and, as predicted, the IPv6 push turned out to be mostly vendor hype motivated by a desire to increase equipment sales. Today, I am here to dispel the misplaced fear around the concept of having your data stolen in transit over the Internet. I am referring to the wire between your residence and the merchant site at the other end. This does  not encompass the security of data once it is stored on disk drive at its final location, just the transit portion.

To get warmed up, let me throw out some analogies.

Do you fear getting carjacked going 75 mph on the interstate?

Most likely not, but I bet you do lock your doors when stopped.

Do you worry about encrypting your cell phone conversations?

Not unless you are on security detail in the military.

As with my examples, somebody stealing your credit card while it is in transit, although possible, is highly impractical; there are just better ways to steal your data.

It’s not that I am against VPN’s and SSL, I do agree there is a risk in transport of data. The problem I have is that the relative risk is so much lower than some other glaring security holes that companies ignore because they are either unaware, or more into perception than protecting data. And yet, customers will hand them financial data as long as their web site portal provides SSL encryption.

To give you some more perspective on the relative risk, let’s examine the task of stealing customer information in transit over the Internet.

Suppose for a moment that I am a hacker. Perhaps I am in it for thrills or for illegal financial gain, either way, I am going to be pragmatic with my approach and maximize my chances of finding a gold nugget.

So how would I go about stealing a credit card number in transit?

Option 1: Let’s suppose I parked in the alley behind your house and had a device sophisticated enough to eaves drop your wireless router and display all the web sites you visited. So now what? I just wait there, and hope perhaps in a few days or weeks you’ll make an online purchase and I’ll grab your cc information, and then I’ll run off and make a few purchases.  This may sound possible, and it is, but the effort and exposure would not be practical.

Option 2: If I landed a job at an ISP, I could hook up a sniffer that eaves drops on every conversation between the ISP customers and the rest of the Internet. I suppose this is a bit more likely than option 1;  but there is just no precedent for it – and ISPs often have internal safeguards to monitor and protect against this. I’d still need very specialized equipment and time to work unnoticed to pull this off. I’d have to limit my thefts to the occasional hit and run so as not to attract suspicion. The chances of economic benefit are slim, and the chances of getting caught are high, and thus the risk to the customer is very low.

For the criminal intent on stealing data, trolling the internet with a bot looking for unsecured servers, or working for a financial company where the data resides, and stealing thousands of credit cards is far more likely. SSL does nothing to prevent the real threats, and that is why you hear about hacking intrusions in the headlines everyday. Many of these break-ins could be prevented, but it takes a layered approach, not just a feel good SSL layer that we could do without.

Confessions of a Hacker

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.


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.

%d bloggers like this: