360 Security

Chris Sullo has a post out over on the HP Security Labs blog on his experience downloading Google Chrome. He clicked and it was installed... no download prompt, no installer, nothing. I actually experienced it this morning before I left my apartment but in my haste said I'd wait until tonight to explore further. I really thought I was going crazy... I'm glad to know that I'm not, or at least not in this case.

I don't know if horrified is a strong enough word to express how this makes me feel. Shocked, disgusted, sorry I've ever defended Microsoft in the past... these are a few things that come to mind. Not only did they undermine the security of Firefox... they've destroyed my trust in them. How will I ever feel comfortable accepting another Microsoft update (after all, that's how .NET came to be installed on my computer). Had I went and downloaded it... sure, but I didn't I did what we in the security industry tell every individual to do... I installed my available updates. I even reviewed them but there was no note that read "CAUTION: This will decrease the security of your computer".

Microsoft has managed to successfully allow drive-by downloads in Firefox. My skin is crawling... and unfortunately if my wife is at home browsing right now my computer probably is to.

Adobe had a turbulent start this year and in response to cries from it's disgruntled users, Adobe security has announced several strategic moves. This blog post from Adobe describes the three much-needed things Adobe will be doing to improve security for their popular Reader and Acrobat products.

First, Adobe's existing secure product development standards will now also be used against their existing/legacy code base. Second, Adobe now promises quicker and more in-depth security incident response mechanisms. Finally, Adobe will be moving to a regular patch release cycle.

The three initiatives essentially mirror what we have come to know and appreciate about Microsoft's security processes. About a decade ago, hit by bad press and poor industry reputation, Microsoft embarked on a similar but grander vision. The result of that effort is that today Microsoft is the leader when it comes to managing the enterprise security development lifecycle.

These initiatives are a great start for Adobe to begin rehabilitating their image. These initiatives go a long way, but they are still missing a few important components.

First, Adobe needs to learn how to reign in the bug finders. Both critical security incidents with Adobe so far in 2009 have involved situations where proof-of-concept code was made public before Adobe could repair the bug. Letting bug exploits out into the wild set Adobe back on their heels and left IT security groups in a reactionary mode trying to cover their security assets without much help from Adobe

Second, enterprise IT shops could benefit greatly from centralized tools that allow for product policy changes. If Adobe published means and methods to disable product functionality using active directory group policies, then IT would be in a better position to respond and implement policy-setting changes.

Finally, JavaScript bugs riddled Adobe products in 2008 and in 2009. It would behoove them to consider disabling JavaScript by default.

The long string of critical bugs in Adobe products has disappointed me, among many others. The bugs, coupled with poor company communications and difficult to deploy mitigation steps have made the last six months ever more trying in our security team. Going forward there will be 2 key metrics of Adobe's successful implementation of their new security program. First will the obvious - fewer security holes. The second indicator will be when Adobe has successfully convinced the bug finders to disclose holes to them instead of publishing them online.

The bottom line is that the changes announced today by Adobe are welcome and we all hope that Adobe sees immediate improvement across their install base.

Week 5 of the FBI Citizens' Academy was mostly dedicated to counterterrorism.

First we received an overview of the counterterrorism program from the local assistant special agent in charge for the counterterrorism group. The number 1 priority of the FBI is to protect the United States from a terrorist attack. This includes protecting US interests and citizens both locally and located abroad. We learned about the joint terrorism task force (JTTF) that makes up federal, state and local law enforcement personnel. The JTTF acts as an integrated investigative force to combat domestic and internal terrorism. Here in the Bay Area we also have a northern California regional intelligence center, also referred to as a fusion center. After the overview, speakers led the class thru 2 separate case studies. The first of domestic terrorism related to individuals harming local university professors that worked in areas where animal tested is involved. The second case study demonstrated a case of international terrorism. In this second case, a local bay area resident was found supporting terrorists on foreign soil by monetary means.

The evening ended with a quick discussion of InfraGard. InfraGard is a partnership between the FBI and the private sector for information sharing and analysis. The partnership works towards preventing hostile acts against the United States.

Over the past few weeks, I've been looking at the OWASP Top 10 and thinking back to my time spent as the Sys Admin for a SMB. As the technical resource at the company... web app development also fell on my shoulders. This wasn't simply building the company website, as I worked for a marketing company this included full blown web applications for clients. Now prior to joining nCircle, I lived and breathed security... it was (and still is) my passion. This isn't the case for Sys Admins and developers at other SMBs and even larger enterprises. Security is often an afterthought.... sometimes a "way-afterthought". For these people, the ultimate resource to turn to is the OWASP Top 10, the ten most pressing concerns in web application security decided on by experts in the industry. The OWASP Top 10 "represents a broad consensus about what the most critical web application security flaws are" and the people at OWASP "urge all companies to adopt this awareness document within their organization and start the process of ensuring that their web applications do not contain these flaws." I don't disagree with this, if everyone takes the steps to prevent these flaws, we'll have a safer online world.

That being said, given the OWASP stated purpose of the Top 10, I don't feel that it is written to best represent everyone who uses it. The Top 10 often feels as though it is written by industry experts for the rest of the industry. This isn't, in my mind, what the document was intended to do. The Top 10 may be referred to by pen testers or web application researchers to reference, but it's primary goal is to raise awareness and provide assistance to developers. Many of these developers aren't security oriented and simply write code... look at the colleges and universities, they have programs pumping out plenty of web developer grads who have never seen a course on secure coding. Usability is number one is many of their projects. It is these people that I feel the Top 10 fails... it doesn't give them something they can easily work off and to me that should be the primary goal of a project such as this.

Let's take a look at two scenarios.

Scenario #1

Imagine you work for a small marketing company with less than 30 employees. You are the sys admin with all the regular sys admin duties, however you are also tasked with the responsibility of building web applications and/or web sites for customers and for use within the company. You have limited time and take the OWASP Top 10 as your guide to securing the application you are building. You aren't security oriented and someone pointed you toward the document. If you first tackle A1 (XSS) you'll read the following: "Cross-site scripting, better known as XSS, is in fact a subset of HTML injection. XSS is the most prevalent and pernicious web application security issue. XSS flaws occur whenever an application takes data that originated from a user and sends it to a web browser without first validating or encoding that content." You follow the advice of "Ensure output is passed through htmlentities() or htmlspecialchars()" and continue on to the next line item A2 (Injection Flaws).

Here you read this description, "Injection flaws, particularly SQL injection, are unfortunately very common in web applications. There are many types of injections: SQL, Hibernate Query Language (HQL), LDAP, XPath, XQuery, XSLT, HTML, XML, OS command injection and many more." As stated you aren't a security person, this is a job that you ended up in but one of the things you notice is the mention of HTML Injection. Why does that sound familiar? Oh yeah, A1 was a subset of HTML Injection... well I've protected against A1, that must mean I'm good here and you move on to A3. STOP! How about we look at the other types of injection (perhaps SQL Injection) and protect against those as well. Right now, reading this, you are thinking that no one would ever do that... but it happens. Now why does it happen?

A1 is XSS and A2 is Injection Flaws. XSS is a subset of HTML injection which is a child of Injection Flaws, yet it's also been made a peer of Injection Flaws. There is a logic flaw that exists here and it is enough to cause confusion for many people.

Scenario #2

Now let's imagine that you are an enterprise with separate teams for Development, System Management and Security Auditing. Company policy states that audits must be done before Web Applications go into production and again immediately after going into production. The criteria for the audit is defined by the OWASP Top 10. Development and QA have done their part and the application is audited internally. The application passes audit (no vulnerabilities according to the Top 10) and sent off to System Management for deployment. The system is deployed and a follow-up audit is performed. Again no issues are found and the web app is live. Two months later a report comes in that your web app has been blacklist for serving malware. An investigation ensues and sure enough, live malware is being distributed... the website is pulled down and forensic investigation reveals that a flaw in the server software was used to upload malware to the server. If the auditing team had been using the 2004 edition of the Top 10, they would have discovered this flaw, however Insecure Server Configuration was removed from the 2007 edition of the list.

Now as I said, I've been considering the Top 10 for quite some time, and both of these potential situations have caused me some concern. Last week I started to consider this write-up on the subject and instead decided to contact the Top 10 mailing list to discuss these issues. While the readdition of Insecure Server Configuration seems to have been well received the problem that I see in XSS and Injection Flaws has not. I understand that the people responsible for this list are considered industry experts and I don't meant to slight anyone by making the suggestion that the current list is flawed. That being said, since a new version of the list is planned, that means the current iteration isn't perfect and that there is room for improvement. I believe that this area is one of the areas where improvement can be achieved, but I'm not so full of myself to think that because I believe it, it must be true.

I fully understand that in the past, it made sense to distinguish between XSS and SQL Injection, they were two major issues that needed recognition. I'm not sure though that the categories XSS and Injection Flaws properly represent the issues at hand. With more and more people referencing the Top 10 and the PCI Security Council leaning heavily on it to define web related portions of the PCI-DSS, I feel we need to make it as clear and concise as possible.

That being said, there are three ideas that I feel more properly describe this situation:

1) Drop Injection Flaws from the list, if the important items are XSS and SQL Injection and we don't want to combine them for fear of a loss of importance, then why lump SQL Injection in with anything. XSS and HTML Injection are closer than SQL Injection and HTML Injection yet they are not defined in that way. So A1 would be XSS and A2 would become SQL Injection.

2) Merge XSS into Injection Flaws. Make Injection Flaws A1, leaving A2 open for the current "risk de jour" and lump them together in a way that makes them technically accurate and easier to understand.

3) Create the OWASP Top 20, or two separate Top 10 lists. One that identifies the buckets of larger groupings (Injection Flaws) and the other identifies the specific vulnerability classes (XSS, SQL Injection, etc).

As I said, this didn't receive the warmest welcome on the OWASP Top 10 list, but I can't help but wonder if it's a matter of the experts not being able to place themselves in the shoes of the people using the list. This is a common and easily made mistake in our industry, we become so comfortable and familiar with the material that while it makes sense within our own grouping, we forget that the material needs to be referenced and acknowledged by people that don't live with our mindset.

The date is May 12th 2009 and you are a mild mannered IT manager anticipating a single bulletin from Microsoft and a possible update from Adobe. The team has their assignments; their computers are locked and loaded. The team is ready to execute on the planned patch release mechanisms.

At 10AM Pacific Microsoft releases their patch on time. The single bulletin is the anticipated bug fix for the PowerPoint vulnerability. Some members of the team are a bit agitated by the high CVE count and the lack of updates for the OSX Office platform. You are able to quickly refocus the team and move forward. Hours later, rumors hit that not only did Adobe publish their fix, but also Apple released a new revision of their operating system.

In fact both of these things happen and OSX 10.5.7 includes fixes for 67 vulnerabilities. Together the Apple, Adobe and Microsoft patches account for 83 CVE fixes. Now the team is seriously disheartened. Your job is to draw the group together, review the unexpected workload and set priorities. Did I mention that because of the economy, your team is now smaller, but doing just as much, if not more work.

Microsoft produces their risk categorization. Adobe employs yet another risk methodology and Apple also defines bugs in their own way. The lack of any common metric across the three vendors in combination with the additional calculus needed to accommodate your internal risk equations equals uncertain resource drain.

On any normal Microsoft patch Tuesday, most enterprises IT teams have their risk calculators in hand and resources at the ready. Some teams split up the duties between client and server vulnerabilities. Others take the highest risk first no matter where the bug lies. Either way, the security team adapts in order to deal with the Microsoft specific criticality ratings and their exploitability index.

The same thing ensues on an Oracle CPU day. And even when smaller vendors like Adobe release bug fixes, most enterprises know how to massage the vendor specific risk data into their own risk profile equations. This data manipulation is a completely avoidable step.

CVSS (Common Vulnerability Scoring System) version 2 was finalized two years ago. Even before that, CVSS v1 was in play for a number of years. While everyone recognizes that there are some shortcomings with the standard, it is nonetheless a common means to reliably communicate information about risk. It enables vendors to consistently distribute quantifiable information to enterprises who then use this data in their own decision-making engines.

So with this industry wide tool readily available, why is it that today enterprise IT must differentiate and discriminate the various meanings of the word 'critical' from multiple vendors?

On a day like May 12th 2009, enterprise IT had a whole range of decision making to perform. Which bugs were most important for my enterprise? Where do the greatest risks lie and which patches should be tested and delivered first? Do you tackle the low hanging fruit or the higher risk and possibly more cumbersome patches first?

These decisions are made countless times every year as vendors release patches. Unfortunately for those in the trenches, too many valuable resources are consumed with just trying to normalize the vendor datasets. If all vendors across the board delivered data with standard metrics, then at least enterprise IT would be in a better position to handle the inevitable changes smoothly and with minimal disruption.

Why couldn't Microsoft have kept things easy this month? Last week Microsoft's advanced notification information spelled out a single bulletin for PowerPoint. Given the single outstanding publicly known vulnerability in Microsoft's products, May patch Tuesday certainly looked like it would be an easy one. Alas, we did receive a single bulletin today, but with it came 14 CVEs and a note of more to come.

Don't get caught up in the details

First thing to take away is that newer Microsoft Office products carry on signs of being more secure. Office 2007, with its new office file format, continues to present lower risk levels. Even in the face of zero day bugs like those of Excel in February and now PowerPoint, Office 2007 was noticeably less affected. Now with the PowerPoint 4 format being totally retired, managers have more ammo than ever to go obtain budget for upgrades.

The second important piece not to overlook is that more patches for today's bugs are due out soon. Microsoft recognized that these bugs also affect the Mac Office products, but don't have patches available yet. Releasing patches for only piece of their product line and leaving the Mac users out in the cold is unlike Microsoft. However, given that current exploit samples were less functional on the Mac and given the market share dichotomy between Office Mac and Windows, the split release cycle is understandable.

The third piece of today's puzzle is that after you look over the mass of CVEs patched; don't forget that one of them is the known zero day bug that was described in KB969136. This means that Micrsoft not only patched the known zero day bug as promised, but also went much further at delivering a more secure Office product lineup.

Week 4 of the FBI Citizens' Academy: Violent Crimes, White Collar Crimes and Civil Rights Crimes.

The mission of the FBI violent crimes program is to:
* Effectively address those violent crimes that pose significant risk to citizens of the US.
* Reduce incidents of crimes against children.
* Address other major violent crimes to include Indian Country, transportation and other special jurisdiction crimes.

Common crimes include bank robbery, kidnapping, and extortion. The presenter referred to the uniformed crime report (UCR) for anyone wanting the most up to date crime statistics. He did, however, highlight some interesting statistics. According to the 2006 UCR, there are only 2.4 sworn law officers per very 1,000 inhabitants in the US. Further, according to a number of news outlets, nearly 1 in every 100 adults is behind bars.

The presenter turned our attention to criminal gang activity nationally and locally. According to Morgan and Quinto press, in 2007 the most dangerous cities included Oakland at number 4 and Richmond in9th place. Gangs, as the presenter taught us, fulfill social needs for their members. Whether it is the mimicking of an extended family, creating social or ethnic bonds, the gangs provide members with an identity that is represented by their clothing, hand signs, graffiti and tattoos.

White-collar crime efforts fall into 2 areas of the national FBI priority list - #4 combat public corruption at all levels and #7 combat major white collar crime. Crimes that typically fall under the white-collar division include public corruption, corporate or securities fraud and health care fraud. Of these crimes, the most up and coming are financial fraud including mortgage fraud and Ponzi schemes. The FBI investigates public corruption cases and provides check and balances in the criminal justice system because agents typically have fewer local and political ties.

The final topic for the evening was civil rights. The FBI is the primary federal agency responsible for investigating all allegations of civil rights violations. Selected crimes involving civil rights allegations include: hate crimes, color of law, human trafficking and freedom of access to clinic entrances act.