SANS September 2009 Report - The Top Cyber Security Risks

A report titled “The Top Cyber Security Risks” was recently released by SANS and TippingPoint that may be useful for background on the current internet security risks.

You are encouraged to review findings in this report if you have the time.

http://www.sans.org/top-cyber-security-risks/

Notable in the report is that vulnerabilities within applications now exceed more traditional OS level vulnerabilities.

That said, the security community is mixed on the findings as we would like to see more supporting data as evidenced by this post:

http://newschoolsecurity.com/2009/09/making-sense-of-the-sans-top-cyber-security-risks-report/

July 2009 is “Month of Twitter Bugs” (MoTB)

In an effort to raise awareness for issues within Twitter API as well as 3rd party integration, the “Month of Twitter Bugs” (MoTB) has officially commenced.

More information here:

If you use Twitter (or know colleagues who do), you may want to share this information with them and also make note of which 3rd party apps you have given access to your Twitter account.

It might even be a good time to change your Twitter password right about now, .. =)

New bugs will be posted here daily throughout the month:

Respect Experience and Trust Your Gut

I was inspired to write this post after reading a recent paper/post by Marcus Ranum titled "Ranum's Rants - The Anatomy of Security Disasters" available here. Thank you Ivan for the link.

This post is also available in pdf format here.

So as I was reading Marcus, I felt as though I was connecting with every word he wrote:

I’ve seen major security-critical business decisions get made based on whose golf buddy runs what business unit – I’m very skeptical of the notion that "Risk Management" has any value beyond the butt-covering obviousness of having made an attempt.

Brilliant. Insightful. Spoken from experience. Perhaps a dash (or three) of cynicism. But all true.

As security professionals, we see a lot. We learn a lot. We are all about the details and we HATE TO BE BLIND-SIDED!

If you are new to information security, you need to ingest the words from Marcus as if they were your own.

In the most dysfunctional organizations, you get senior (or sometimes mid-level) executives who 'shop a bad idea' until they find someone who is willing to tell them it is good. One security disaster I was involved with happened in exactly this manner: a senior executive hit upon a bad idea and asked the security team for their input. The security team explained why it was a bad idea; in fact they wrote a brilliantly clear, incisive report that definitively framed the problem. So the executive asked the web design team, who declared it a great idea and "highly do-able" and implemented a prototype. Months later, the "whiners" in the security team were presented with a fait accompli in the form of "we're ready to go live with this, would you like to review the security?"

Like it or not, this is our world! Security is now and will always be the enemy of convenience. Deal with it!

The only way to prevent security disasters is to have a security team that is fearless about feeding back information up to the top of the chain of command, and to have senior executives who make decisions based on reality rather than a projection of their fantasies.

Over the years I have realized that I bring 3 valuable assets with me to the table as a security professional:

1) my experience
2) my professional colleagues/relationships
3) my gut

The first two just naturally come over time but the third takes confidence and a foundational trust in both your abilities and your judgement. As I get longer in the tooth, I have grown to trust this "gut feeling" even more and I venture to speculate that once you learn to trust *your* gut feeling, you too will be a better and more effective security professional, as well.

Sure I have made my share of bad decisions and I do not mean to imply that I have seen every possible iteration of a specific event or incident, .. only that over time, I have learned to appreciate that many events are simply variations of prior events and that it is my gut that allows me to connect the dots and recognize the similarities between these events when this connection may not otherwise be readily apparent.

I have also come to expect, foster and appreciate a work environment that I like to call "unbridled candor" where honesty abounds and you had damn well better not ask a question unless you are willing to hear the honest truth. I know from experience that some people can't deal with the truth.

I believe it is my gut that gives me the confidence to speak truth to power in a way that is not seen as confrontational to business decision makers but simply matter-of-fact and authoritative.

Marcus sums it up this way, ...

What can we do to break the cycle? The most important thing is to make sure you are direct and honest about expectations at all times. Do not allow management or clients to believe that they can do dumb things in safety, and do not hide behind bogus probability guesses. "Safety" is not the same thing as "relative safety."

I believe that Marcus trusts his gut and I think you should trust yours as well.

What is a "canary account"?

A canary account is an account created in a database for the sole purpose of detecting if data has been compromised.

The term "canary account" is based on the notion of a canary detecting changes in the air quality of a coal mine to the point where it was unsafe for humans.  Think of it as a early warning system, ...

Within the context of data protection, the canary account could be monitored to make sure it had not been accessed and if the account is accessed, then you have a high likelihood that the data may have been compromised.

This is somewhat related to the notion of a "honey pot" that acts as 'bait' for attackers drawing their attention away from the real crown jewels in favor of pseudo crown jewels that have been crafted to look even more appealing to the attacker, ..

In a post by Robert Graham related to the phpbb hack earlier this year, canary accounts are mentioned as a possible means for alerting to the attack sooner:

http://erratasec.blogspot.com/2009/02/importance-of-being-canonical.html

The first is to create "canary" accounts. Create accounts that have e-mail addresses, like "something-really-long-xyz-123@gmail.com". This account is not going to get any spam e-mail. When it does get its first spam, you'll know that it came from your database. When I create recommendations for clients, this is always one of the first things I suggest. (Likewise, if you are an e-commerce site, you should get dummy credit cards that only exist in your database). This won't stop you from getting hacked, but it will at least tell you when a hack has happened. (I suspect that this isn't the first time phpbb has been hacked - just the first time it's been made public).

I am not saying that canary accounts are appropriate in all cases but just trying to get you thinking of the possibilities, ..

Security Peer Review Checklist

Here is a very nice checklist for use with Peer Security Reviews

http://trustedsignal.com/secDevChecklist.html

Also, here is original post announcing availability of the checklist:
http://trustedsignal.blogspot.com/2009/04/application-security-checklist.htm

Update on Adobe JBIG2 0-Day from February

The video below from Matthew Watchinski of SourceFire VRT offers some interesting information on the events surrounding the Adobe JBIG2 0-Day from February

http://vimeo.com/4110571

If you have a few moments (and you are a complete geek) you might find it interesting.

Notable from the presentation:

• JBIG2 vulnerability sold on the black market on Jan 1st to a buyer in China for $75K
• first exploit related to this vuln was observed in the wild on January 11th
• ShadowServer crew posted their notification on February 19th
• Adobe knew about it before but sat on it and did nothing
• exploit was used in the wild for approx a month before it became public
• All pdf readers including Foxit and Mac OSX Preview were vulnerable to this exploit
• All of the risk mediation that we were told at the time concerning the 0-day proved to be wrong
• PDF vulnerabilities are easy to find
• PDF vulnerabilities are highly sought after in the darker corners of the internet
• WE CAN EXPECT MORE ADOBE 0-DAYS THROUGHOUT 2009!
  

RMS Titanic was compliant!

This was posted to an interesting blog that I follow and thought that it may interest you all.

http://www.guerilla-ciso.com/archives/651

From the post:

the problem here was that the Titanic indeed did meet all of the safety requirements of the time. And that a big part of the problem was that the safety requirements were drafted in 1894 at a time when there were rapid changes and in the size and design of ships of this kind. Those regulations indicated that all passenger ships over 10,000 tons required 16 life boats, and that’s how many the Titanic had.

The Titanic incorporated many innovative design features but only included the minimum number of lifeboats to satisfy compliance.

Also from this post:

So, the bottom-line was that when the Titanic was reviewed by the safety accountants, they took out their check-list and went over the ship with a fine tooth comb. When the day was done the ship fully met all the safety criteria and was certified as safe.

As technology leaders in our industry, we need to be aware of the consequences for only doing the minimum amount in order to satisfy our compliance concerns since we, too, are one iceberg away from a very bad day.

Just some food for thought, ...

Cisco releases 2008 Annual Security Report

Cisco has released their 2008 Annual Security Report.

Report can be found here.

Registration is required for download but email address is not verified. =)

Highlighting Global Security Threats and Trends

The Cisco Annual Security Report provides a comprehensive overview of the combined security intelligence of the entire Cisco organization.

Encompassing threat and trends information collected between January and October 2008, this document provides a snapshot of the state of security for that period. The report also provides recommendations from Cisco security experts and predictions of how identified trends will continue to unfold in 2009.

Key Findings

This year's report reveals that online and data security threats continue to increase in number and sophistication. They propagate faster and are more difficult to detect.

Key report findings include:

* Spam accounts for nearly 200 billion messages each day, which is approximately 90 percent of email sent worldwide

* The overall number of disclosed vulnerabilities grew by 11.5 percent over 2007

* Vulnerabilities in virtualization products tripled to 103 in 2008 from 35 in 2007, as more organizations embraced virtualization technologies to increase cost-efficiency and productivity

* Over the course of 2008, Cisco saw a 90 percent growth rate in threats originating from legitimate domains; nearly double what the company saw in 2007

* Spam due to email reputation hijacking from the top three webmail providers accounted for just under 1 percent of all spam worldwide, but constituted 7.6 percent of all these providers' mail


Fortunately, responses to these threats and trends are improving. Advances in attack response stem from the increased collaboration between vendors and security researchers to review, identify, and combat vulnerabilities.

SANS ISC is reporting 0-day exploit for Internet Explorer in the wild

Just a heads up that SANS Internet Storm Center is reporting a 0-day exploit for Internet Explorer in the wild.

In these situations it is always wise to exercise caution when using IE until more details emerge.

My apologies if you have seen this already …

Thanks,
Joe

<<<>>>

0-day exploit for Internet Explorer in the wild
Published: 2008-12-10,
Last Updated: 2008-12-10 09:38:03 UTC
by Bojan Zdrnja (Version: 1)

As reported by some other researchers, there is a 0-day exploit for Internet Explorer circulating in the wild. At this point in time it does not appear to be wildly used, but as the code is publicly available we can expect that this will happen very soon.

This is a brand new exploit that is *not* patched with MS08-073 that was released yesterday. I can confirm that the exploit works in a fully patched Windows XP machine.

The exploit is a typical heap overflow that appears to be exploiting something in the XML parser. After setting up the heap (spraying it – allocating 159 arrays containing the shell code) the exploit checks if couple of things are satisfied before continuing:

The user has to be running Internet Explorer
The version of Internet Explorer has to be 7
The operating system has to be Windows XP or Windows 2003



If these things are satisfied, the exploit creates an XML tag as shown above. What is also interesting, and can be seen in the code above is that it waits 6 seconds before executing the code – this was probably added to thwart automatic crawlers by anti-virus vendors.

We have not confirmed yet if other versions are affected (Internet Explorer 6 or Internet Explorer 7 on Microsoft Windows Vista).

How to mitigate? This is a difficult question as we have not analyzed this completely yet. If you use an alternative browser you are not affected. When we get more information we will update the diary.

--
Bojan

CSIS Commission on Cyber Security for 44th Presidency has published its final report

The CSIS Commission on Cyber Security for 44th Presidency has published its final report:

The final document titled Securing Cyberspace for the 44th Presidency is available here.

If you get a moment, this may be worth a look since speculation in the security community is that this report is likely to significantly influence US government actions -- organization changes, regulations, laws, purchasing, and R&D funding, etc.

My apologies if you have already seen this, ..

Over HALF A BILLION records of personal information have been exposed/mishandled in the past eight years

From the Holy $#@! department, this just in from a ComputerWorld article authored by Jay Kline.

From the article:

By my count, over half a billion records of personal information have been exposed or mishandled in the past eight years. And these are only from breaches where a record count has been publicly revealed.

That's more than the population of the European Union, and more than the number of people living in the U.S., Canada, Mexico and all of Central America and the Caribbean combined.

need I say more, ...

WASC Web Application Security Statistics 2007

For those hungry for more web application security vulnerability data, WASC has released its Web Application Security Statistics report for 2007

Direct link to report is here.

Thanks,
Joe

<<<>>>

Web Fraud 2.0

A couple weeks back Brian Krebs at the Washington Post ran a series on Web 2.0 fraud (here). My apologies if you have seen this already but if not, I recommend that you take a few minutes to check out some of these posts.

Think of this as SasS for the bad guys and if you have not yet been exposed to the existence of these services then I am pretty sure you will find this series *very* illuminating.

Web Fraud 2.0: Cloaking Connections
These days, nearly every aspect of the underground online economy that supports commercial crime operations has been automated. Online forums and criminal social networking sites have long offered aspiring newbies tips on getting started. But a slew of extremely popular...

Web Fraud 2.0: Validating Your Stolen Goods
If there is any truth to the old saying that there is no honor among thieves then it is doubly true for thieves who transact with one another yet never actually meet face-to-face. Perhaps that explains the popularity of certain...

Web Fraud 2.0: Digital Forgeries
For businesses, positively identifying someone online - by name, or physical location - is extremely difficult. Many Internet firms seek to verify the identity of customers by requesting scanned copies of their driver's licenses, passports, or utility bills. But what...

Web Fraud 2.0: Distributing Your Malware
The allure of cyber crime lies in its promise of quick riches, much like that of the illegal drug trade. But building a network of hacked personal computers that can distribute your data-stealing malicious software is a time-consuming process that...

Web Fraud 2.0: Thwarting Anti-Spam Defenses
Spammers have made great strides this past year in defeating CAPTCHAs, the distorted text used as a security test to ensure a person and not a machine is behind a computer screen. But automated programs that spammers use to thwart...

Thanks,
Joe

<<<>>>

In a perfect world, ... what is your webappsec “wish list"?

I was recently asked what web application security model/framework I would like to see within the development process that (assuming all requirements were being addressed) would allow me to enjoy a relaxing, albeit hypothetical =), vacation away from broadband access and the constant worries of web application security. =)

I know, I know, this seems like a silly exercise on the surface but bear with me on this one. As I dove into it further, I realized that it was actually quite helpful for fleshing out my concerns and then mapping these concerns back to possible solutions.

I realized that I spend most of my time trying to manage the expectations of others and I had not yet effectively presented my own expectations.

I am also sensing an opportunity to measure progress within the overall web application security effort and possibly map this back to quantifiable and repeatable metrics as well.


Here is an initial cut at my "wish list" (in no particular order and subject to change):

1. No code defects. Period.
a. Effective Static Code Analysis (SCA) tool will help here.
b. Security issues are exponentially less expensive the earlier in the SDLC they are found
c. Processes designed to catch code defects early are consistent with proactive security
d. "Underneath all our security issues lies our inability to write defect-free code. Solve that and we've solved the security issues. Focus on the security alone and we won't solve anything". (Credit to Ivan: http://blog.ivanristic.com/2008/07/ive-come-to-rea.html)

2. All developers are adequately trained and understand how to write secure code
a. Developer incentives for writing secure code
b. Developer incentives for undergoing/completing security training

3. Ongoing incentives for developers to proactively find defects in application code that they are not directly responsible for

4. No XSS in the application
a. Potentially redundant since "no code defects" above implies no XSS

5. No XSRF in the application
a. Again, potentially redundant since "no code defects" above implies no XSRF

6. Web AppSec team involved as early in the feature conception and business case/justification phase as possible

7. Web AppSec team involved within "requirements" phase as well.

8. Web AppSec team involved within user design and feedback phase

9. Web AppSec team involved during clarification of the PRD (including tech specs and tech review)

10. Web AppSec team involved during implementation plan

11. Web AppSec visibility offered within QA process
a. QA process has complete coverage of entire web application
b. QA regression tests are comprehensive and effective

12. The number of ingress/egress points within the web application will be kept to a minimum.
a. Main authentication page cannot be bypassed for direct access to other pages on the site
b. Only one ingress point into the application (login page)

13. No mixed content allowed
a. HTTPS is required for ALL content on the site
b. This includes requirement for "secure" flag on cookies

14. Entry pages to the app will be kept simple.
a. Authentication/gateway access points to the application are control points and these pages should remain simple in order minimize risk for bypassing security.

15. Access to ALL pages in the app will require authentication

16. Support for Current authentication Security Standards.
a. Authentication scalable to accommodate web services

17. Session identifier timeout value is easily and readily adjustable within the range of 0-30 minutes.
a. Preference is for unique session identifier (single use) per user transaction
b. However performance implications of this dynamic session identifier allows the option to readily and easily scale (on demand) session identifier timeout value to as high as 30 minutes when necessary.

18. All user data is required to be encrypted in transit

19. All user data is encrypted "at rest", specifically Personally Identifiable Information (PII)
a. Column level encryption offered for all customers/users

20. No unknown use cases within the web application
a. All possible use cases have been planned for and identified

21. Application offers complete and granular reporting into user actions to assist with forensic analysis

22. All possible user "incidents" have been planned for in terms of security "events" and a pre-determined course of action is available for all events

23. All data is escaped appropriately when rendered back to the user's browser

24. Threat Modeling and Data Flow Diagrams
a. Ongoing Threat Modeling for the entire web application
b. Current Data Flow Diagrams are maintained for the entire web application

25. Defenses against Distributed Denial of Service (DDoS) attacks

26. Defenses against Phishing/Pharming attacks


My apologies for the long post, ... =)

As always, your thoughts/comments are both welcome and encouraged.

thanks,

joe

<<<>>>

Web Application Security Roadmap presentation at OWASP NYC AppSec 2008

I will be presenting my Web Application Security Roadmap at upcoming OWASP NYC AppSec 2008 conference later this year.

Draft of current presentation is available here.

Judge Orders YouTube to Give All User Histories to Viacom

I posted this to the WASC listserv

From the post:

A link to the court ruling is included in the article referenced above and I encourage you to take a moment to read it if you have the time.

The way I see it, at the end of the day, web application security professionals ultimately work to build confidence and a sense of both trust and integrity for the end user experience. Without confidence, trust and integrity then the Internet as we know it falls away and we are likely left without an outlet for our passion.

Many pieces of this court ruling troubled me and I wanted to share it with the list in case others on the list had missed it.

If end users ever get to the point that they fear visiting public and otherwise respected sites then that seems to do us all a disservice. Does this not encourage the further development of a DarkNet that shields end users from unforeseen liability and if so, does this not also complicate efforts to secure and protect web applications by security professionals?

Sure, maybe I am overreacting but in a world based upon precedents, this one troubles me more than others.

Your thoughts?

Using .htaccess as a Web App Firewall (WAF)

Wow! This just in from the 'Totally Cool and Amazing Department", ...

Rewrite your .htaccess file to work as a WAF

From the post:

Alright, so I rewrote my .htaccess today. Made it smaller and far better than it previously was. It basically is a miniature webapplication firewall that can help secure your server and applications too. Don't be fooled by it's size, it maybe fit into 1KB, it still protects you from nearly every webapplication attack there is. Even if you have holes, they can't be exploited anymore, and thus prevents future bugs and attacks. A solution doesn't have to be difficult, often the simple ones are the most elegant ones. Well, if you don't believe me, go try it out! Simple!

The entire post is here

A Security Mindset

Bruce Schneier and I do not always agree but I think in this case he nails it when he discusses what is takes to think like an attacker.

http://www.wired.com/politics/security/commentary/securitymatters/2008/03/securitymatters_0320

I not only offer this in defense of how my brain works but also offer that it may give you some additional insights on how to be proactive about security.

Single Site Browsers (SSB) to mitigate CSRF attacks

In Jeremiah Grossman's recent Unsolved Problems blog post:

http://jeremiahgrossman.blogspot.com/2008/03/unsolved-problems.html

Jeremiah lists the following:

- Develop a CSRF defensive measure that’s effective in the presence of an XSS vulnerability on the same target domain

My thought is to use Single Site Browsers (SSBs) to mitigate CSRF attacks. Unfortunately, I don't think I am the first to think of this since after a quick Google search, it looks like others have already begun to consider this as well.

In any event, I have been playing with Fluid for Mac OS X (http://fluidapp.com/) and the idea of offering a SSB for a specific site now makes a lot more sense to me. Even though Fluid is based on Safari, the thought of offering something similar with a security focus had me pretty intrigued. In theory, if each SSB has its own cookie space, then CSRF-style attacks become more difficult.

It seems to me that forward thinking companies may at some point begin to offer SSBs to their users (might be perfect for SaaS) if the SSB did not offer less functionality in terms of user experience. Essentially what you would need would be some type of 'jail' for the SSB cookie space.

5 axioms of Information Security

1. Threats will always follow the path of least resistance.
2. Security is only as strong as the weakest link.
3. As a general rule, attackers are lazy.
4. Reasonable effort will deter 95% of all external attacks.
5. Once you are perceived as a “trophy”, items 1–4 no longer apply.

The term “trophy” is used as a euphemism to indicate that the organization is now perceived as a desirable target by the elite and most resourceful of attackers. History suggests that it does not take much to call attention to an organization and put them on an attacker’s ‘radar’. A press release or a new deal that gets a lot of attention in the press are all possible stimulus for an attacker to begin poking and prodding around an organizations internet exposure. The motivations of these attackers are outside of the scope of this document but needless to say money, prestige and recognition among their peers are at the top of the list.

Every organization is required to adapt to changes within their respective risk/threat climate. It is also clear that every organization has a risk threshold; the level of tolerable risk where threats are consistent with client expectations and business objectives.

As a proactive step towards addressing these concerns, your organization needs to take the time to both understand and document the current level of acceptable risk. Only when the current level of acceptable risk is known and communicated throughout the organization can risk mitigation measures be formalized and effectively implemented.

The 5 axioms of Information security clearly indicate that the risk/threat climate for any organization can change very quickly (even overnight) and if not prepared, an otherwise successful organization can be blind-sided by these changes.

It is imperative that the organization’s risk threshold be prepared for these events.

The importance of forethought and planning in terms of risk exposure cannot be over emphasized.