Full Frontal: Is it OK to Expose Weaknesses?

Sunday, September 18, 2011

David Martinez

3ebd200287a032cf6d13d6b75a570c94

Full Frontal: Is it OK to Expose Weaknesses to an Organization?

After the attention my Julian Chang SQLi posting got, and my previous disclosure to the public library, I realized that ethical vulnerability disclosures can be both very satisfying, and very frustrating.

The reactions of organizations can run the gamut from openly embracing ethical disclosures, to flat out ignoring your disclosure. Each situation is further complicated by the type of vulnerability, it’s impact, and if there is user data at risk.

So how do you disclose serious security holes, when you don’t know how it will be received, or even fixed? What level of severity should be brought to the attention of the organization, and what should their response be?

Let’s compare both of my recent disclosures.

Miami-Dade Public Library System

Read the posting here

The disclosure to MDPLS was a success. I found that every public library was using WEP-40 encryption for their private networks, and that one of the two DNS name servers for their domain was vulnerable to a Zone Transfer. No actual attack had taken place, but what was disclosed could have very easily been used as both an entry-point, and road map to a serious breach.

I contacted the person listed on their WHOIS info, who turned out to be their DNS Administrator. It took a few weeks for him to get back to me, and I advised him of my findings. A few weeks later, he contacted me to check the Zone Transfer problem once again. It had been fixed, and he informed me that the WEP problem had been forwarded to the right person.

I received another phone call a few weeks later from that person, letting me know that because of my post, he had been approved to upgrade all the WEP networks to WPA2, and that it should be done my mid-September. (I haven’t had the chance to go check for myself yet.)

So it wasn’t perfect, and a bit disjointed, but the problems got fixed, and all is well.

Julian Chang SQL Injection

Read the updated posting here

This one was probably one of the most frustrating things I’ve ever had to deal with. I had found that the designers website was vulnerable to bare-bones SQLi on a majority of pages. I was able to dump the entire database. On reviewing it, I found their admin had used a simple hash for his password.

I cracked the hash as proof of my claims. I then found several tables with customer data from transactions and mailing lists. The tables included CC numbers (in the form of an MD5 hash which were left untouched), full name, telephone number, and home address. On seeing this, I immediately decided to notify the organization.

The WHOIS info provided no information besides a generic forwarder through their webhost. In the DB I dumped, I found both the personal email for Julian Chang himself, as well as who I assumed was the web developer. (It was listed under the admin user name in the DB). I sent various emails to these addresses, all with no response. I also placed 3 phone calls to the organization, none of which have been returned.

Frustrated that all the customer info was sitting basically unprotected, and that nobody was showing any initiative to help clean it up, I took matters in to my own hands. I filed complaints with the Better Business Bureau, the FTC, and US-CERT. Also, I was able to get in contact with appropriate law enforcement officials about this.

To date, this issue has still not been fixed, the customer data is still vulnerable, and I’ve still received no word from the organization. My complaint with the BBB has gone unanswered, and I haven’t heard back from neither the FTC, or US-CERT.

Comparing situations

In comparing the two disclosures, you can see the wide disparity between what should be important, and what’s ignored.

The MDPLS disclosure was actually fairly mild. No severe vulnerability was available that would have given someone direct access to private information, and no security systems were breached. Yet the potential existed for a severe breach.

The Julian Chang SQLi was obviously a severe vulnerability. Not in the big scheme of modern data breaches obviously, but for a small organization, it could spell disaster.

Ironically, the responses were opposite of what I would have expected for each situation.

The Library System is a big, ugly, government beast. If you live in S. FL, you know that anything government run is a pain to deal with. I was honestly expecting to be tossed around from department to department, with nothing getting done. Instead, I was able to contact their DNS admin directly.

Granted, he did take a bit to respond, but I understand that he must have had a million other things on his plate as well. When we finally spoke, he was understandably skeptical of my claims, until I provided him with internal IP addresses and their DNS names.

Just the fact that he fixed the problem and even took the correct step in forwarding the WEP problem to the proper person shows that he was genuinely concerned. I even appreciated that he replied asking if I could check if the problem had been patched.

Julian Chang might be a big name in the South Florida fashion scene, but his organization is fairly small. His primary base of operations is a small shop on Biscayne Blvd in Miami’s Design District. Obviously, their not going to have an IT team, or even anyone on staff who would know what I’m talking about, and that’s completely understandable.

But the problem wasn’t their lack of tech experience. It was their sheer ignorance of the problem. In my emails to them, which are available here, I tried my best to lay out the problem in the best non-tech terms I could. I even expected one or two emails to go ignored. But on my first phone call, I spoke with his sister Angela, who runs his local shop.

I explained my reason for the phone call, and the fact that I had sent various emails already. Her response was to take down my number, and that she’d have their computer guy call me in a week. I’m still waiting for that call. My two followup phone calls went directly to voice mail, and I left two very clear, easy to understand messages with all my contact information.

In total, 6 emails, and 3 phone calls were ignored. One would think that as a small business owner, Mr. Chang would value his clients and the privacy of their data much more then a larger organization would. You can argue the fact that “he’s obviously not a tech person, he didn’t understand what you were talking about.” Agreed, but if that’s the case, put me in contact with the person doing your site, and I’ll discuss it with him and get the problem fixed.

How should it go?

In a perfect world, ethical disclosures wouldn’t even be an afterthought. You’d find something wrong with a site, an infrastructure, or an application; be it SQLi, DNS Zone Transfer, or a buffer overflow. You document your findings, find the correct contact person, and advise them of the problem, how you found it, and how to potentially fix it.

They respond promptly, possibly ask for more information, and work with you to patch the issue. Once it’s patched, they ask you to check again, and let them know. You verify the problem was patched, advise the vendor, and write up the CVE if needed. Life is good. Will this ever happen in exactly this process? Not exactly.

The closest I’ve ever seen to this situation was the SQLi on the Sun-Sentinel, posted on n00bz.net. Jason found a simple SQLi which would give him DBA access to the entire newspapers SQL DB. He cracked the root hash, contacted the DBA, and within a few hours he was working with their developer, and had it patched. Clean, no mess, problem solved.

Sadly, this is rare.

What can be done?

From the outside, there’s not much that can be done physically to address the vulnerability besides telling the organization in an ethical manner. Sadly, it’s up to their discretion to either fix or ignore it. Even in speaking with law enforcement about the Julian Chang SQLi, I was informed that all they can really do is inform the organization again in person.

However, I realized that the problem isn’t really the (lack of) security in the infrastructure. It’s the fact that after being informed of the breach, clients were not informed and notified. I did some digging and found a Florida Law requiring that if an organization suffers a breach, and client information may have been leaked, the organization has 45 days to notify the clients. There are very expensive fines that can be placed on the organization after 45 days.

The Florida Statue referenced above is Title XLVI, Chapter 817.5681. The link to it can be found here.  

Overall Impressions

While it might be interesting and a bit exciting finding vulnerabilities in systems, keep in mind that reporting them to the appropriate people might be more hassle then it’s worth, especially when your doing it pro bono. As I discovered, some will be more then willing to have your help in pointing out and patching the problem, while some won’t even ignore you.

So should you go around reporting every %27 or WEP network you find in the wild? Obviously not. You’d have no life. But then why did I choose to disclose to MDPLS and Julian Chang? They were both vulnerable in their own ways to different types of problems. The library is a publicly funded institution.

As a taxpayer, I felt responsible for bringing this to light to prevent my tax money from being wasted cleaning up after a breach. In the case of Julian Chang, I felt a responsibility to help protect those users personal data, especially now that I now that they have no interest in protecting it.

Overall, I think there should be some sort of government agency that is solely dedicated to both informing organizations about the dangers of bad security practices, as well as taking on reports of vulnerabilities and helping companies take the appropriate steps to fix them.

Having to jump through hoops to file complaints with different agencies, who in the end can’t do anything is ridiculous. What’s even more frustrating is the fact that the state law exist, but getting someone to enforce it gets tricky.

Cross-posted from Down South Hacking

Possibly Related Articles:
14655
Vulnerabilities
Information Security
SQl Injection Disclosure Application Security Hacking Vulnerabilities WEP Julian Chang
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.