The Open Source Vulnerability Database

I had the opportunity to listen to a great interview on episode 19 of the Tenable Network Security Podcast during my morning commute yesterday. The interview was with Jake Kouns the President and co-founder a of the Open Security Foundation which oversees the Open Source Vulnerability Database (OSVDB) and the DatalossDB. The interview is certainly worth a listen and for those not familiar with OSVDB, take a few minutes to check it out. To quote OSVDB's about page;

OSVDB is an independent and open source database created by and for the security community. The goal of the project is to provide accurate, detailed, current and unbiased technical information on security vulnerabilities. The project will promote greater, more open collaboration between companies and individuals, eliminate redundant works, and reduce expenses inherent with the development and maintenance of in-house vulnerability databases.

I just wanted to take a few minutes to point out the interview and OSVDB's Winter 2010 Fundraiser. So if you use the database please consider donating as it is a fantastic resource that would be missed.

Is a Warning a Mitigation?

On Friday the good people at The Internet Storm Center posted some notes on a readers experience with a recent targeted phishing attempt of his corporate OWA (Outlook Web Access) users. The email used to target the end users is convincing. It explains that their mailbox settings have been changed due to a security update and includes a hyperlink to what appears to be an URL residing on the corporate domain. Once clicked, the unsuspected recipient is brought to another site that offers up an executable containing the ZBot Trojan.

Soon after reading the post, I chatted with a few people who stated that they too had witnessed this attack at their place of employment. None of this is very surprising to me, except that it does not seem to occur more often. At first glance, one might be inclined to believe this is a low risk attack vector. It's just OWA right? I disagree however. Many organizations allow OWA untethered from the internet. OWA runs on Microsoft Exchange which indicates it is a Microsoft Active Directory environment. In almost all cases OWA is using the same login credentials that is used to authorize the access to corporate resources such as Windows end nodes, file shares, VPN's, databases, and web applications. It is the "keys to the kingdom" if you will. Combine this with end users running as local adminitrators and there are multiple opportunities for compromise.

OWA has been no stranger to vulnerabilities in the past. An URL redirection vulnerability affecting Exchange 2003 has gone unpatched and almost unnoticed by many Exchange administrators for years. With the exception of some frustrated forum posts from a handful of systems administrators and security practitioners, there seems to be little mention of the issue. The user is presented with the organizations OWA login page and after providing credentials is redirected to the attackers server. An example of the redirected URL:

https://[victim]/exchweb/bin/auth/owalogon.asp?url=http://[attacker/file.exe]

Such vulnerability would only make the aforementioned phishing attempt more effective. The Open Web Application Security Project (OWASP) recently released release candidate 1 of the The Top Ten Critical Web Application Security Risks of 2010. Number eight on this list is  UnvalidatedRedirects and Forwards. To quote the summary of this risk:

"Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages."

Again there is no official Microsoft patch for the issue but the aforementioned OSVDB link does contain a comment describing a mitigation tactic. By hard coding the redirectPath variable in login.asp to you company's full URL path for the locale you’re using, you can prevent the redirection. It should be noted however the redirectPath should be hardcoded in each of the locale's being used (i.e. language set in the user’s browser). While Exchange 2007 is not affected by this example it is affected by a similar URL Redirection described here. Upgrading to Exchange Service Pack 1 or higher fixes the issue.

So I am not sure why I was surprised when I recently received an email from one of the email lists I subscribe to. In it, Dan from http://www.madjic.net/ describes a similar redirection issue with Exchange 2007 SP1. He had verified that with some modifications, URL redirection is still possible via:

https://[victim]/owa/[user]@[victim]/redir.aspx?URL=http%3a%2f%2f[attacker/file.exe]

One would need to include the victim's login name but this would be trivial since in many Exchange environments the email address is the same as the Windows username. Now here is the rub. Once redirected the end user is presented with the following warning:

So my question is this; is a warning a mitigation? (Please comment as I am truly curious on everyone's opinion on this) While certainly an improvement, I would not consider it a fix or mitigation. Users have a tendency to click through warnings. SSL Certificates are a great example of this. This actually reminds me of another Microsoft mitigation from almost a decade ago (I am dating myself now).

This warning was included in Outlook 2000 Service Pack 2 and above and was a direct result of worms such as the ILOVEYOU virus which leveraged VBA in Outlook to spread to the others in the victims contact list. Did it stop the propagation of such malware?

Certainly properly architecting OWA and placing it behind a proxy with appropriate ACL's that restrict outbound connections would be a better solution than a warning. This may not be feasible for small businesses, however. End User education is always a must but with spam and attacks becoming more streamlined and targeted this is not a realistic solution in itself. I purpose the better solution would be to provide systems administrators with an easy way to turn redirection off (that is a hint Microsoft). Hey let's get a bit crazy! Let's make the default setting be disabled.

I think most of us understand the concept of the path of least resistance. Attackers will always take the road that is less bumpy. History has proven that phishing, is one such avenue. Many attack vectors have come and gone but yet phishing attacks still exist. Let’s not give the bad guys anything that is going to make their jobs any easier. Now go forth and mitigate!

What's in a Word?

So I am doing the post holiday vacation catch up with my email last night and I found several emails in my inbox referencing a Boston Globe article published yesterday. The article is titled Data Breaches Affect Million State Residents .

To summarize, the article briefly reviews the amount of data loss containing Personal Identifiable Information (PII) of Massachusetts residents reported since MGL Chapter 93H was put into effect in October 2007. I was happy to see some general media coverage of the 2007 law and the newer 201 CMR 17.00 law which is scheduled to become effective in March 2010. I quickly became annoyed however.

What struck me was a quote in the article from Barbara Anthony, Undersecretary of the Office of Consumer Affairs and Business Regulation.

“In 60 percent of the cases, the breaches were due to criminal acts,’’ said Anthony. “Forty percent were negligence.’’

<disclaimer>I am not an attorney nor do I play one on TV!</disclaimer>

I live and work in Massachusetts so I am familiar with both these laws. I have to say I have a real problem with this statement. Lets first look up the definition of the word negligence. It is after all a legal term which therein lies my issue with her statement.

From dictionary.com

–noun
3. Law. the failure to exercise that degree of care that, in the circumstances, the law requires for the protection of other persons or those interests of other persons that may be injuriously affected by the want of such care.

–adjective
4. Law. pertaining to or involving a civil action for compensation for damages filed by a person who claims to have suffered an injury or loss in an accident caused by another's negligence: a negligence suit; a large negligence award.

So if a criminal act was used to obtain data by way of an individual or company's neglect to adequately protect that data would that not be considered “negligence”? I would argue that most of the 807 cases reported by the Commonwealth of Massachusetts were probably caused by some form of negligence. If an employee of a company storing such data, copies the data to his/her laptop against company policy, and that laptop is stolen from the front seat of his/her vehicle, then that is a criminal act caused by negligence. If a company's System Administrator forgets to apply a security patch to a critical system prior to leaving for two weeks of vacation, the server is compromised, and the data is stolen, I would also consider that a criminal act resulting from negligence.

My point is I would like to know how the Commonwealth is differentiating between a criminal act and negligence since the later can often lead to the former. I believe their logic and consequently their statistics are flawed. Moreover, neither law seems to outline such terminology.

So why is this important? I believe companies should be held legally liable. The term negligence implies that I as a consumer residing in the Commonwealth of Massachusetts should be able to hold a company that is storing my Personal Identifiable Information liable in criminal and civil court if they have been negligent in protecting my data. Is that not the purpose of Law? Until then, I do not believe laws and regulations will have any substantial positive effect. They are just security theater.

On a related note, I found this great post on philosecurity.org blog waiting in my RSS reader last night;  Why Data Breaches Don't Get Reported.

Adobe's "0 Face"

As you may already know, Adobe acknowledged another public security vulnerability in their products on December 15, 2009. APSA09-07 affects all current and earlier versions of Adobe Acrobat and Reader with JavaScript enabled and is currently being exploited in the wild. There is no doubt Adobe products have been in the cross hairs of attackers over the past two years and Adobe's use of JavaScript seems to provide an easy opportunity for exploitation.

Upon reading the advisory, it was no surprise that disabling JavaScript was the mitigation. Many users in my environment do not use this functionality and it can easily be turned off via the Windows registry. The problem is it does not remain off. When opening an Adobe JavaScript enabled .pdf the user is presented with a prompt to re-enable JavaScript. To date Adobe does not provide any way to permanently disable JavaScript via the Adobe Reader preferences menu or the registry. We all know how useful warnings are for end users right? <insert self-signed ssl certificate here> But I'll save the use of a warning as a form of mitigation of badly thought up functionality for a later blog post.

<my rant>

So Adobe products are increasingly being targeted and although Adobe seems to have picked up the pace with their security stance, I have often questioned if they have enough internal resources to do anything but be reactive. Once again, a zero day leveraging JavaScript in an Adobe product is flying around and the patch for this vulnerability will not be available until January 12, 2010. In my opinion, this is unacceptable. Adobe seems to be struggling with putting out the fires and are not being preventative by fixing their code or providing systems administrators with the tools or patches they need to properly mitigate. I can personally tell you my corporate IDS and Antivirus have been lighting up like a Christmas tree (tis the season) with attacks using this exploit.

Soon after the advisory dropped, I listened to Dennis Fisher and Ryan Naraine interview Brad Arkin on the Digital Underground podcast. Brad Arkin is currently Director of Product Security and Privacy at Adobe and has held previous positions at Symantec and @stake. Now Brad seems like an intelligent guy and I applaud him for taking on such a challenge. I became annoyed while listening to the interview, however. Ryan Naraine repeatedly queried Brad during the podcast on what I have suspected for quite some time. Does Adobe have enough resources in place for dealing with the current trend of attacks targeting their products? Brad seemed to repeatedly side step the question. He attempted to explain the complexity of dealing with such vulnerabilities with such a large and diverse install base.

<disclaimer> While I may have no experience dealing with what Brad has stepped up to do, I do have a lot of experience mitigating vulnerabilities in the corporate environment and my opinions here are based on that experience. </disclaimer>

Now while I have no doubt that this is a challenge indeed, maybe Adobe needs to stop, glance around, and take a cue from the company that has the largest and most diverse install base I know of. That company would be Microsoft. While far from perfect, Microsoft seems to have made some significant advances with their security program over the last 5-6 years. When MS08-067 dropped in October 2008 (for those not familiar, that’s the vulnerability used by the Conficter variants), Microsoft did what any responsible software vendor should do. They released an Out-Of-Band patch!  So what gives Adobe?

I almost jumped out of my skin when Brad stated Adobe often needs to shift resources off of other security projects and research to handle an exploit such as this. So to answer Ryan’s question, I guess you do not have enough resources then? My point is if you have to shift all your resources to handle each and every fire and it still takes you a month to put out the fire, then you will never be preventative. Maybe I am being naive here but I don't believe so.

</my rant>

Ok so with my ranting out of the way, I did state that I thought Adobe was making improvements. One such improvement is their implementation of the JavaScript Blacklist Framework mentioned during the podcast. It is still reactive but it is at least something. Thank you to Dennis, Ryan, and Brad for bringing this to my attention. To quote Adobe’s tech note located here;

“The Adobe Reader and Acrobat JavaScript Blacklist Framework introduced in versions 9.2 and 8.1.7 provides granular control over the execution of specific JavaScript APIs. This mechanism allows selective blocking of vulnerable APIs so that you do not have to resort to disabling JavaScript altogether.”

Brad admitted during the interview that this is only effective for specific vulnerabilities and it may break legitimate uses of functionality in Adobe Acrobat and Reader. He further stated Adobe has many more improvements coming during 2010. I can only hope this includes some preventative improvements to their code base and internal resources dedicated to the current target on their back.

More can be found on using the blacklist framework to mitigate the vulnerability in APSA09-07 here.

For an entertaining and informative Adobe rant (that puts mine to shame) checkout the latest post on the Sourcefire VRT Team blog, entitled Matt's Guide to Vendor Response

Happy New Years to Everyone!

Update:

More reports of sophisticated Adobe exploits have been appearing this week. Some have little to no coverage by the AntiVirus vendors. I noted the following article describing Adobe's plans to begin testing a silent Adobe updater. Someone needs to tell Adobe an updater only works if you actually provide the update and explain to them the basics of enterprise change control.

Details of the attacks can be found here and here.

Another Update:

Adobe has release patches for the Acrobat/Reader vulnerability as well as another vulnerability in Illustrator.  The Advisories can be found here:

http://www.adobe.com/support/security/bulletins/apsb10-02.html
http://www.adobe.com/support/security/bulletins/apsb10-01.html

I also found a great ADM template for tuning Adobe Acrobat and Reader JavaScript settings on the Praetorian Prefect Blog. Again, just note that the user will be prompted with a warning when opening a .pdf containing JavaScript.

OK Last Update

The Sourcefire VRT team posted an excellent article this week on the using the Acrobat JavaScript Blacklist Framework on common exploited functions within Adobe Acrobat and Reader. An example taken from their post for Adobe Acrobat 9 would be as follows:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Adobe Acrobat\9.0\FeatureLockDown\cJavaScriptPerms]"tBlackList"="Collab.getIcon|DocMedia.newPlayer|Util.printf|Spell.customDictionaryOpen|Doc.syncAnnotScan|Doc.getAnnots"

 Additionally, they provide benign Adobe Acrobat files using each of these functions to test with.

Didier Stevens also pointed out during a recent interview on PaulDotCom Security Weekly that the new version of Adobe Reader and Acrobat has changed the way it warns users that JavaScript is disabled. While not quite the administrative control I had hoped for, it is a slight improvement as it renders the .pdf regardless of the action taken by the user.

Yet Another Update on the Symantec Vulnerability

It looks like DSHIELD has picked up on an increase in probes for port 12174 associated with the Symantec Advisory covered previously on this blog here and here. In some cases of upgrading from previous versions of Symantec Corporate Antivirus to 10.1 MR8, servers are still vulnerable to this exploit. So make sure AMS and Intel File Transfer service (xfr.exe) is not running and listening on TCP Port 12174.

Update on Symantec Vulnerability

So I wanted to give everyone an update on the Symantec Antivirus vulnerability I outlined in my previous post entitled; Lessons Learned: Vulnerability and Expectations Management. It appears that the exploit code has been published to the Exploit Database and has also been added to the Metasploit Framework. If you have not read my previous article, please make note here. In some cases of upgrading from previous versions of Symantec Corporate Antivirus to 10.1 MR8, servers are still vulnerable to this exploit.

The problem is due to the fact that AMS2 does not get removed in all cases of upgrading from version 9 to 10. If the Intel File Transfer service (xfr.exe) is running and listening on TCP Port 12174 then you are still vulnerable. Disabling the service or completely uninstalling and reinstalling Symantec Antivirus were the two options given to me by support at Symantec. I use the term "support" loosely here as I'm the one that told them disabling the serviced mitigates the issue.

I have attempted to get Symantec to edit their advisory with this information without success. So make sure you verify your patches with the attached code or favorite vulnerability scanner. Tenable Nessus does have a plugin available here.

CMD.EXE Incident Response Cheat Sheet

Recently, I have been putting together some incident response tools and documentation for our systems administrators and wanted to provide an easy to use reference of Windows command line tools available at their disposal. There is a a lot of great information and resources available but I could not find a single one page cheat sheet of all the cmd.exe commands one might use during incident response. The closest thing I found to containing all the commands I wanted to cover was Russell Butturini's Hak5 U3 Switchblade which is an awesome resource but my aim was to teach what each command does. Consequently, I began creating a cheat sheet myself using Jeremy Stretch's popular PacketLife.net cheat sheet template he recently made available here.

I have attached v1.0 and am hoping others can find some value with using it or maybe make some suggestions or additions to it. I would love to do one for Linux and maybe a more detailed one on WMIC. Let me know what you think.

RBS Worldpay: It's Not Child's Play

I have found the RBS Worldpay ATM heist fascinating. Although the dollar amount stolen cannot compare to some larger compromises in recent history, the coordination the attackers and thieves displayed is unprecedented. Moreover, it appears the corporation of law enforcement spanning three continents was able to bring an indictment on November 10, 2009. A copy of that document can be found here. Not much is known about the technical details of the compromise but I recently decided to put together a diagram of what is known about the heist for a training I am scheduled to do next month. I used the Crayon Network Visio Stencil found here to create it and though some might find it amusing.

More articles and coverage on the compromise and arrests can be found here:

http://www.fbi.gov/page2/nov09/atm_111609.html
http://atlanta.fbi.gov/dojpressrel/pressrel09/atl111009.htm
http://www.veracode.com/blog/2009/11/we-need-to-learn-more-about-the-rbs-worldpay-atm-attack/

Only You Can Prevent Forest Fires - A Smokey The Bear Approach to Security

A few weeks back Larry Pesce from PaulDotCom posed the following question on Twitter:

"Hmm. If you had to deploy ONE security technology in your organization, what would it be? What is the risk reduction vs, total effort?"

Many people quickly replied. Some answers included: a comprehensive patch management solution (my pick), Security Information Management (SIM) system, network based firewall, Intrusion Prevention System (IPS), incident response plan, and my personal favorite "a very large dog..." . Larry quickly followed up asking what would the second technology be and why?

I struggled with that question. After all it is a "no win" situation. A proper incident response plan would certainly be needed but is reactive. Network defenses would be beneficial but do not take in account a mobile workforce. I finally settled on some sort of central system that would facilitate the system hardening of the end nodes. The reasoning for my answer is the result of experiences I had early in my information systems career.

During my time as a desktop support tech, I spent most days putting out fires. The lack of centralized patch management, host based firewalls, build procedures, and asset management was the source of chaos for the desktop and systems administration teams. Worm outbreaks, improper configuration, and end users running with local administrator rights were the norm not the exception. Consequently, the team was too busy chasing their tail around to be proactive. Those experiences resonated heavily with me and ever since I have insisted in being proactive whenever possible.

Would have proper incident response or a SIM solution have helped my former employer? Maybe. Incident Response procedures and SIM's are important parts of any defense infrastructure but they are reactive, not preventative. Consequently, I would certainly place them in my top five but only after implementing the basics of defense.

While Larry's hypothetical situation is enough to give any security practitioner nightmares, I found it to be a great source of self reflection. Larry discusses the replies in more detail during Episode 172 of PaulDotCom Security Weekly, so check it out when you get a chance. I'm interested to know what you would choose and how fast you would update your resume if you found yourself in the same situation.

DojoCon 2009

I have had several things I have been meaning to post but my day job has been keeping me crazy busy lately. However, I did manage to find a few hours to check out some of the talks streaming live from DojoCon 2009. For those not familiar with DojoCon, it was created by Marcus J. Carey this year and was held November 6-7, 2009 in Maryland. Marcus not only coordinated the conference but also donated a large amount of the proceeds to Hackers for Charity (HFC). I had the opportunity to watch several talks including the keynote from Marcus Ranum, a great talk by Matt Watchinski of Sourcefire VRT, and a fantastic breakdown on lock picking by Deviant.

I haven't had the opportunity to watch the remaining talks yet but I am looking forward to it. I recommend you check out some of the recordings, drop Marcus a thank you note, and donate to HFC. Marcus did a great job with the con and HFC is a great cause.

Thank you Marcus!