Security Weekly News 6 January 2011 – Summary

Feedback and/or contributions to make this better are appreciated and welcome
Highlighted quotes of the week:
“If you ever get the urge to build your own proprietary cipher. Stop. Don’t do that.” – George V. Hulme
“For software security spend as a portion of firm-wide IT spend, we collected data from eight firms with very active software security initiatives. These firms come from a number of diverse verticals. Their software security initiatives vary in maturity as assessed by the BSIMM measurement. The percentages of annual IT spend ranged from 0.13% to 5% with an average of 1.89%. Remember, this is not security spend, but rather software security spend. Given the kinds of technologically intense businesses participating in the BSIMM, this is a healthy percentage.” – Gary McGraw and Sammy Migues (on BSIMM study findings)
“Clearly not enough is being invested in appsec, and $ is not going to be shifted from netsec. the biz case must be made to expand budget.” – Jeremiah Grossman
“Two lessons here. One, running un-trusted code (whether it’s an executable, javascript, or even a swf) is dangerous. Two, protocol handler blacklists are bad.” – Billy Rios
“I concur, breaches will increase and the reason they’ll increase is every dollar you spend on last decade’s threats is a dollar you don’t spend making the criminals’ life harder. I wonder if the infosec managers who spend so many dollars on firewalls get holiday cards from organized crime?” – Gunnar Peterson
“Firewalls can absolutely protect websites if you block port 80… ” – Paul Nelson
“You know, Im thankful for not having to explain why firewalls & ssl dont protect websites. havent had to in 2-3 yrs. awareness = good” – Jeremiah Grossman
“Many companies will go to the cloud .. and some will return from there because they will have dark clouds and no neck to squeeze when a storm takes place” – Chema Alonso (2011 “predictions”, loose translation from Spanish. Original post here)

To view the full security news for this week please click here (Divided in categories, There is a category index at the top): The categories this week include (please click to go directly to what you care about): Hacking Incidents / Cybercrime, Unpatched Vulnerabilities, Software Updates, Business Case for Security, Web Technologies, Network Security, Database Security, Mobile Security, Cloud Security, Privacy, General, Tools, Funny

Highlighted news items of the week (No categories):

Not patched: Currently Unpatched Windows / Internet Explorer Vulnerabilities, Vulnerability in Graphics Rendering Engine Could Allow Remote Code Execution (many Windows versions affected, workarounds in advisory!), Announcing cross_fuzz, a potential 0-day in circulation, and more (more IE 0-day, all other main browsers not fully fixed yet), PHP Hangs On Numeric Value 2.2250738585072011e-308 (fixed in SVN but no release yet), When two public exploits become a bad combo, CA ARCserve D2D r15 Web Service Apache Axis2 World Accessible Servlet Code Execution Vulnerability Poc, Hole in VLC Media Player, Unpatched hole in ImgBurn disk burning application

Updated/Patched: VMWare Security Advisory VMSA-2011-0001, Professional Security Audit for Piwik 1.1

Gary McGraw explains how the 32 firms in the BSIMM study determine the proper mix of security initiatives to maximize efficiency and effectiveness of their security programs.
One of the major goals that the 32 firms in the BSIMM study have in common is the desired ability to constantly adjust their software security initiatives in order to maximize efficiency and effectiveness. Put in simple terms, how do I decide on the right mix of code review, architecture risk analysis, penetration testing, training, measurement and metrics, and so on, and then how do I ensure I can react to new information about my software?
The problem is, nobody is sure how to actually solve this hard problem. In this article we take a run at the problem in the scientific spirit of the BSIMM project – gathering data first and finding out what the data have to say. We describe our findings and our data here in hopes that they may prove useful to other software security initiatives facing the effectiveness mountain.
This post is inspired from a conversation recently had with one of the folks who shapes our security testing tools here at HP Application Security – thanks Sam for dislodging this nugget from the back of my brain.
QA teams have some interesting ideas when it comes to answer this question: ‘Are you doing any application security testing currently?’ … and depending on who you ask it’s possible you will receive a variety of different answers. I am, of course, taking the assumption that you’ve accepted that security testing is as much a part of the QA testing cycle as oxygen is to breathing.
‘Testing for security’ can mean many things to many different people, and I wanted to take a moment to debunk some of the myths that I’ve heard spread over the last 2-3 years. I can’t help but feel like Information Security organizations are at least partially responsible for the existence of some of these myths since we’ve done little or nothing to disspell them amongst our QA brethren.
2010 Annual Security Report  [press.pandasecurity.com]
PandaLabs, the anti-malware laboratory at Panda Security -The Cloud Security Company-, has published its 2010 Annual Security Report covering an extremely interesting year with regard to cyber-crime, cyber-war and cyber-activism. The report is available at: http://press.pandasecurity.com/press-room/reports/
In 2010, cyber-criminals have created and distributed a third of all existing viruses. That is, in just 12 months, they have created 34 percent of all malware that has ever existed and has been classified by the company. Furthermore, the Collective Intelligence system, which automatically detects, analyzes and classifies 99.4 percent of all malware received, currently stores 134 million unique files, out of which 60 million are malware (viruses, worms, Trojans and other computer threats).
Yesterday I got involved in an interesting Twitter discussion with Jeremiah Grossman, Chris Eng, Chris Wysopal, and Shrdlu that was inspired by Shrdlu’s post on application security over at Layer8. I sort of suck at 140 character responses, so I figured a blog post was in order.
The essence of our discussion was that in organizations with a mature SDLC (security development lifecycle), you shouldn’t need to prove that a vulnerability is exploitable. Once detected, it should be slotted for repair and prioritized based on available information.
While I think very few organizations are this mature, I can’t argue with that position (taken by Wysopal). In a mature program you will know what parts of your application the code affects, what potential data is exposed, and even the possible exploitability. You know the data flow, ingress/egress paths, code dependencies, and all the other little things that add up to exploitability. These flaws are more likely to be discovered during code assessment than a vulnerability scan.
And biggest of all, you don’t need to prove every vulnerability to management and developers.

Cloud Security highlights of the week

As data and access get more broadly deployed, CSOs have new issues to plan for
What do CSOs and other IT security experts expect to be top-of-mind cloud security issues in 2011? Here are five things to watch for in the coming year:
1. Smartphone data slinging. More users will be accessing large amounts of data on the devices of their choice, says Randy Barr, CSO at Qualys and member of the Cloud Security Alliance (CSA). “This comes with a lot of unaddressed security issues,” Barr says. “We can expect new solutions to address mobile devices, but could see a large data breach to expose the issue of mobile security before we see a solution.” Among the possible scenarios, Barr says, are insecure cloud-based backup and highly confidential data on mobile devices.
Security Guidance for Critical Areas of Focus  [wiki.cloudsecurityalliance.org]
– Introduction
– Foreword
– Letter from the Editors
– An Editorial Note on Risk
– Section I. Cloud Architecture
Sourcefire Announces Acquisition of Immunet  [investor.sourcefire.com]
Expands Cloud-based Security Infrastructure
Sourcefire, Inc. (Nasdaq: FIRE), the creator of Snort® and a leader in intelligent cybersecurity solutions, today announced the acquisition of Immunet, a leading provider of advanced cloud-based anti-malware technologies. The acquisition expands Sourcefire’s security solutions portfolio – adding an advanced cloud platform for delivery of malware protection – and extending the company’s real-time detection and prevention leadership to the cloud.
Immunet combines the collective intelligence of a growing user community, the speed of cloud computing, advanced data mining, and machine learning technologies to provide a groundbreaking approach to cybersecurity. This acquisition immediately enables Sourcefire to provide endpoint protection from client-side attacks and Advanced Persistent Threats (APT). The cloud-based platform also enables innovative approaches to reputation services, data loss prevention and forensics. Combined with Sourcefire’s next generation network intrusion prevention system (IPS), customers get the most comprehensive protection against today’s threats from cloud to core.

Secure Network Administration highlights of the week (please remember this and more news related to this category can be found here: Network Security):

James McGovern asks why we don’t see enterprisey folks focusing on SOA *and* security? Well there are a lot of reasons here, but lets look at some facts. Most enterprisey folks look at security in binary terms – inside the firewall or outside the firewall. When a transaction is ‘inside the firewall’ they can do silly things like load all their transaction on to something like MQ Series with no authentication, send it to the mainframe which runs their entire book of business, and in essence run their transactional backbone on anonymous ftp. Because its ‘inside the firewall’
Problem is – its just a Visio drawing, its not reality, its historical baggage. We were trained to think about things in these terms in the 90s
Joseph Bonneau, a PhD candidate at the Security Group, University of Cambridge Computer Laboratory, contacted us to report a problem he found with non-Latin character passwords (Unicode) on Gawker Media sites:
I discovered that, after creating an account with the password ‘????????’, I was able to successfully log in by typing ‘????????,’ as well as ‘????????’, ‘©©©©©©©©’. It turns out that any string of exactly 8 characters whose unicode code point is >= 128 will be accepted. I’ve looked carefully at the implementation of crypt in PHP and across several platforms I tried, this is not a library problem-somehow your server is converting all of the non-ASCII characters to some fixed value prior to calling crypt() with them…..
The Windows Server 2008 Security Guide has been replaced by the Windows Server 2008 Security Compliance Management Toolkit, part of the Security Compliance Management Toolkit Series. See the note in the Overview section for the current download location.
I intend this post to be a sort of reference to the Linux capability system, particularly to point out the false boundaries in place with many of the existing capabilities, as I don’t think this topic has been written about in depth before. I’d also like to highlight this as an example of the importance of the PAGEEXEC/MPROTECT concepts in combination with the removal of arbitrary code execution (and in the future, hardened interpreters).
As of Linux 2.6.37, there are 35 capabilities which exist with the intent to split up the privilege associated with UID 0. Before the implementation of file capabilities, the capability support was for capability-aware applications that ran with root privilege. A knowledge of which root privileges were needed allowed the applications to drop any unneeded capabilities. In Linux 2.6.24, file capabilities were introduced, which allowed for the distribution or the administrator to set the capabilities needed for an application via modification of the application’s extended attributes on disk. The immediate application of file capabilities is to remove the need for suid-root binaries on the system. It can also be used however to reduce the capabilities used by a normal root-running daemon, by clearing the effective bit in the file capabilities.
Security: DIY or Plug’n’Play?  [blog.rootshell.be]
Assembly Instructions Appliance or not appliance? That is the question! A computer appliance is a dedicated hardware which runs software components to offer one of more specific services. Information security has always been and is, still today, a common place where to deploy appliances: firewalls, proxies, mail relays, authentication servers, log management, Wi-Fi controllers and much more! This post is just a reflexion about appliances and their alternatives. They are two groups of people: pro & cons. Those who love appliances for their robustness and ease of use and the others who are frustrated by their limitations.
… because it seemed a sensible thing to do, but I couldn’t find a single concise document saying how to do it! These instructions worked for me on a recent Debian testing installation, YMMV.
For specific users (or, the right way)
1. Install the tools:
sudo aptitude install libcap2-bin
2.
Grant the necessary programs the ability to inherit the CAP_NET_RAW capability when execed:
sudo /sbin/setcap cap_net_raw+ei /usr/bin/dumpcap
sudo /sbin/setcap cap_net_raw+ei /usr/sbin/tcpdump
….
 [www.h-online.com]
27C3: danger lurks in PDF documents
At the 27th Chaos Communication Congress (27C3) in Berlin, security researcher Julia Wolf of US company FireEye pointed out numerous, previously hardly known, security problems in connection with Adobe’s PDF standard. For instance, a PDF can reportedly contain a database scanner that becomes active and scans a network when the document is printed on a network printer. Wolf said that the document format is also full of other surprises. For example, it is reportedly possible to write PDFs which display different content in different operating systems, browsers or PDF readers – or even depending on a computer’s language settings.
Man-in-the-middle attacks are old. Really, really old. Maybe even as old as ancient times, when messengers ran between cities. Beat up a messenger, steal his funny hat, and change his scroll to say, “King Sam is really pissed at you guys”. Who knows, maybe start a war, or at least a trade disruption. Beats the heck out of banging rocks with a stick, which was pretty much the cool thing to do before TV.
The LAN version of this attack caught on in full force with the advent of switches. Hubs send all packets to all connected hosts, whereas switches are smart enough to only send each packet to its intended destination. We used to get everyone’s usernames and passwords simply by listening to the wire. Now we had to get a little smarter. This time we beat up Address Resolution Protocol (ARP), steal its funny hat, and read all the great stuff going over port 110.

Secure Development highlights of the week (please remember this and more news related to this category can be found here: Web Technologies):

In the video below, Keith Turpin talks about the secure coding practices quick reference guide. It’s a technology agnostic set of general software security coding practices, in a comprehensive checklist format, that can be integrated into the development lifecycle. Get it here.
I stumbled upon a very strange bug in PHP; this statement sends it into an infinite loop:
(The same thing happens if you write the number without scientific notation – 324 decimal places.)
I hit this bug in the two places I tested for it: on Windows (PHP 5.3.1 under XAMPP 1.7.3), and on Linux (PHP Version 5.3.2-1ubuntu4.5) – both on an Intel Core Duo processor. I’ve written a bug report.
PHP maintainers have yet to weigh in on the report. In the meantime, possible workarounds include adding a “-ffloat-store” flag to CFLAGS or stopping the execution of decimal versions of numbers that are passed as a parameter.
PHP 5.2 and 5.3 are affected, but apparently only on Intel CPUs which use x87 instructions to process floating point numbers. The x87 design has long been known to contains a bug which triggers just this problem when computing approximations to 64-bit floating point numbers. By default, 64-bit systems instead use the SSE instruction set extension, under which the error does not occur.
The PHP development team has fixed this in the forthcoming version 5.3.5. A patch for version 5.2.16 is available from the repository. (courtesy of http://www.h-online.com/security/news/item/Floating-point-DoS-attack-1163838.html)
A few weeks ago, I posted a description of a set of bugs that could be chained together to do “bad things”. In the PoC I provided, a SWF file reads an arbitrary file from the victim’s local file system and passes the stolen content to an attacker’s server.
One of the readers (PZ) had a question about the SWFs local-with-filesystem sandbox, which should prevent SWFs loaded from the local file system from passing data to remote systems. Looking at the documentation related to the sandbox, we see the following:
Understanding Developer Psychology  [h30501.www3.hp.com]
Happy 2011 everyone! I hope everyone’s break was restful… so now on to business.
Towards the end of last year I started to hint that some of the approaches being taken in software security assurance (SSA) needed to change and that one of the foundational pieces of software security was understanding the mind of the developer. To that end I have a request …
Attention developers!
If you’re a code-slinger I’d like to conduct a brief interview …
I need a representative (random) sample of developers to put through a series of questions and a brief interview. If you’re willing to give your name and your company – great, but not necessary. I can’t quite divulge what the details are just yet but the goal of this informal study is to further the understanding of developer psychology.
Spot the Vuln – Banks  [blogs.sans.org]
Spot the Vuln uses code snippets from open source applications to demonstrate vulnerabilities in real world web applications. Every Monday morning a vulnerable code snippet is posted. Take a look at the vulnerable code and try to identify where the security vulnerability is. Every Friday, a solution is posted so you can check your answers. Each exercise is designed to last between 5 and 10 minutes. Do it while you drink your morning coffee and you will be on your way to writing more secure applications.
This week’s bug was an old SQL injection bug that affected PunBB versions < 1.3. In short, a value is taken from an attacker/user controlled POST request and is used to build a SQL statement. This bug actually requires a small amount of tracing, so here we go! First, we see that PunBB takes the attacker/user supplied content here (line 11)
11 $form = array_map(‘trim’, $_POST[‘form’]);
The line above uses the value passed via $_POST[‘form’] to populate the $form variable. The value goes through a trim() function, but is (for the most part) un-sanitized. It’s interesting that PHP allows for the submission of arrays through POST parameters. This behavior is mentioned in the comments on this page
Next, the $form variable (which contains our attacker supplied values from $_POST[‘form’]) is used in a foreach statement and each index of the $form variable value is used in some application logic. You can see this in the following line (line 19)
19 foreach ($form as $key => $input)
The just released CRS v2.1.0 includes Credit Card Tracking rules. These will both track legitimate credit card usage and also prevent full credit card number leakages. Much of the following data was taken from a previous blog post by Ofer Shezaf however many sections have been updated with current ModSecurity and CRS information.
1. Introduction
The Payment Card Industry Data Security Standard (PCI-DSS for short), requires that credit card numbers are not transmitted in clear and are not presented to users unmasked. The following post outlines several detection accuracy issues that must be addressed by a monitoring solution and we will focus on ModSecurity.
On 16th December, TYP03 released a new security update (TYPO3-SA-2010-022) for their content management system. Apparently, this web-based framework is widely used in many important websites.
Within this update, TYPO3 team fixed a vulnerability that I’ve discovered a few weeks ago. In detail, this discovery pertains to a previous vulnerability fixed in TYPO3-SA-2010-020 and discovered by Gregor Kopf.
From the advisory, we can actually deduce two important concepts:
A Remote File Disclosure vulnerability in the jumpUrl mechanism [..] Because of a non-typesafe comparison between the submitted and the calculated hash, it is possible [..]
In a nutshell, the JumpUrl mechanism allows to track access on web pages and provided files (e.g. /index.php?id=2&type=0&jumpurl=/etc/passwd&juSecure=1&locationData=2%3a&juHash=2b1928bfab)
The patch (see this shell script) simply replaces the two equal signs with three (loose vs strict comparisons
Sacha Faust has published a great article on some of the security checking functionality in Visual Studio. From the article
‘Anyone doing ASP.NET development probably admits, openly or not, to introducing or stumbling upon a security issue at some point during their career. Developers are often pressured to deliver code as quickly as possible, and the complexity of the platform and vast number of configuration options often leaves the application in a less than desirable security state. In addition, the configuration requirements for debugging and production are different, which can often introduce debugging settings in production, causing a variety of issues.
Over the years, the ASP.NET platform has matured and better documentation has been made available through MSDN and community blogs, but knowing which feature or configuration setting to use is often troublesome. Even with good knowledge of the security functionality, mistakes can happen that could result in security vulnerabilities in your application.
I am pleased to announce the release of the OWASP ModSecurity Core Rule Set (CRS) v2.1.0. This is a significant update as we have added many new capabilities.
Improvements:
– Added Experimental Lua Converter script to normalize payloads. Based on PHPIDS Converter code and it used with the advanced filters conf file.
– Changed the name of PHPIDS converted rules to Advanced Filters
– Added Ignore Static Content (Performance enhancement) rule set
– Added XML Enabler (Web Services) rule set which will parse XML data
– Added Authorized Vulnerability Scanning (AVS) Whitelist rule set
– Added Denial of Service (DoS) Protection rule set
– Added Slow HTTP DoS (Connection Consumption) Protection rule set

Finally, I leave you with the secure development featured article of the week courtesy of OWASP (Development Guide Series):

Encryption

-Depending upon the type of data that will be handled by the application will determine if none, some, or all of the communications will need to be encrypted. If this is a web application that will be processing orders and cardholder data then the SSL/TLS encryption will be needed for transactions at a minimum. Due care should be taken when mixing unencrypted (http for example) with encrypted (https) areas of the same site. To elaborate in the case of an online store due care would need to be taken with any session tokens/cookies or hidden fields after a product has been processed (use of https) and then accessing unencrypted areas of the same site. Due care should be taken that any sensitive cookies or other parameters or hidden fields are not passed within any unencrypted requests.

-Additionally session tokens should be encrypted whether passed as cookies, hidden fields, etc especially if they contain user identifiable or sensitive information.

-All sensitive information in the application data flow should be encrypted such as the separate authentication requests and responses between a client, web server, and database server or sensitive communications (such as implementing WSE for SOAP requests) between applications.

-Sensitive information such as credit card information should also be stored encrypted. Sensitive information should never be stored clear text.

Source: link

Have a great week and weekend.