How to handle discovered security flaws in software?

Suffice it to say, two of my small business clients use the same software package to manage their business. Sadly though the software fails miserably at protecting the financial information contained within the database. Worse yet, this particular franchise is nationwide with potentially thousands of customer financial information at high risk.

I am currently writing an analysis paper on the security flaws to submit to the corporate offices of this particular franchise. In the meantime I'd like to hear from anyone who has experience in dealing with such matters and what steps are recommended in alerting not only the software vendor, franchise corporate offices, but also what kind of timeline should be set before making the information public.

Also of interest are any agencies or groups such as CERT who would most likely be interested in this information.

bump

if you're going to make the information public (which you should) you shoul do it without bringing the client into it in any way, shape, or form. you may also want to contact CERT or someone directly and ask their opinion on how to handle he situation giving only the info you've given us keeping it vague at first.

Mitigation for such circumstances is largely dependant upon where you found the hole. If the problem is network based, then some type of tunneling or transport modification might work (ssh, vpn, ipsec, etc.)

Without revealing what software, can you describe the likely attack vector?

rcolbert said:

Mitigation for such circumstances is largely dependant upon where you found the hole. If the problem is network based, then some type of tunneling or transport modification might work (ssh, vpn, ipsec, etc.)

Without revealing what software, can you describe the likely attack vector?

Click to expand...

While several flaws exist, the most glaring are the fact tha CC #s as well as bank account information is being stored in plain text within an Access database. Anyone with a copy of the database can have complete access to the above along with the customer information.

2nd part is the software has a web reporting feature which uses ASP forms in IIS to gain access to the above information *without* using SSL or any other form of encryption. The instructions provided are for using IIS within client based OSs such as Windows 2000 and XP.

It's ironic the software vendor has employed some form of basic encryption on employee passwords stored in the database, but yet fails to protect the very customers that keep them in business in the first place.

Given the above information, attack vectors can be internal as well as external through various means that can be simple or complex.

While the above should be simple to fix, I can't fathom how or why someone hasn't pointed out this information earlier.

SJConsultant said:

but also what kind of timeline should be set before making the information public.
Also of interest are any agencies or groups such as CERT who would most likely be interested in this information.

Click to expand...

First find contact information for the vendor either via their website or jump on bugtraq and request contact information for the vendor's security department (assuming they even have one). The hardest part will be getting in touch with someone who will actually a) understand your concerns and b) care enough to do something about them.

Best case is that the vendor will work with you to find a solution to the problem on a reasonable timetable. That timetable will have to be worked out between the two parties. You can give them a period of time in which to produce a workaround or a patch, once the fix is available you can them publish the exploit in full or just a proof of concept or just describe the problem and encourge swift patching. The worst case is you turn over the information and they do nothing, at that point you have to decide is it better to release the information to encourge them to work to fix the problem.

I've seen some groups release exploit PoC within days of notice to a software company and I've seen people sit on exploits for months while problems were sorted out. It's depends on the serveity of the exploit, the possible risk to the companies running the software. it's not an easy call unfortunately.

Good luck with the paper, I look forward to seeing it when it's done (and hopefully with the patch news as well).

talk with them about it. if they refuse to fix it. i say 30days or so is enought time to tell if there going to fix it or care about it. if not release the information public.

Yeah first confront them about the issue in private... if nothing is done, blow the whistle!

SJConsultant said:

While several flaws exist, the most glaring are the fact tha CC #s as well as bank account information is being stored in plain text within an Access database. Anyone with a copy of the database can have complete access to the above along with the customer information.

2nd part is the software has a web reporting feature which uses ASP forms in IIS to gain access to the above information *without* using SSL or any other form of encryption. The instructions provided are for using IIS within client based OSs such as Windows 2000 and XP.

It's ironic the software vendor has employed some form of basic encryption on employee passwords stored in the database, but yet fails to protect the very customers that keep them in business in the first place.

Given the above information, attack vectors can be internal as well as external through various means that can be simple or complex.

While the above should be simple to fix, I can't fathom how or why someone hasn't pointed out this information earlier.

Click to expand...

I don't know if i would classify those as security flaws. It just seems like poor application design to me. I can't imagine anyone (today) writing any type of database app that involves cc# not considering any type of encryption. Especially with Sarbanes-Oxley and the California law's requiring companies to notify consumers whose information has been stolen. However it is possibe =)

However, normal processes are for you to contact the vendor directly and give them reasonable time to address your concerns. (if they do at all).

If within a reasonable time frame, they have not responded to your concerns, you can go public by publishing your information to bugtraq and ntbugtraq. I've seen security companies find vulnerabilities, and present a firm date for a fix. If the fix hasn't been addressed by that time, the go public.

here is a nice example by Eeye.

http://www.eeye.com/html/research/upcoming/index.html

Thanks for all the input. I am almost finished writing a comprehensive analysis paper that includes suggested solutions to the most glaring problems that exist.

The web reporting application is coded in ASP to which I have very little experience. There very well may be additional flaws that I have yet to uncover simply because I don't have enough time to uncover every single little detail.

I'll start with what I have so far and for the rest...... well........ I'll post back when I receive repsonses to my analysis.

If you can keep the clients and server all at 2003/XP level then IPSec can be employed to alleviate any clear-text going across the network. It doesn't sound like that's an option.

One way to protect the database file itself is to use either Citrix or plain ol' terminal services and force people to run the app from the terminal server session. That way, you can fairly easily prevent people from copying the access file outright. You could also secure the terminal server and application servers on an isolated subnet and employ a firewall or rudimentary packet filtering to ensure only the terminal server and/or backup servers have access to the database.

Also, you probably want to look into encrypting the backups of the database due to all the recent press coverage that lost backup tapes in transit have caused. Lost tapes that are encrypted don't need to be reported.