Software flaws have become serious vulnerabilties for companies today, as the security measures have become much better along the perimeter. And it’s not just the flaws in enterprise and ISV code — even code written by major antivirus companies can be at risk. F-Secure just posted a couple security bulletins around vulnerabilities in their antivirus products. Of particular interest is a buffer overflow in handling LHA archives. Successful exploitation would allow an attacker to execute arbitrary code on the system with elevated privileges.

File format vulnerabilities are nothing new but they are certainly becoming more prevalent, often with far-reaching effects. The ANI vulnerability patched a couple months ago affected every version of Windows since Windows 2000. However, the attack vector relied on the victim visiting a website or otherwise attempting to view a malicious ANI (animated cursor) file. With an antivirus product, the attack vector is even more straightforward, since it is triggered as soon as the scanning engine attempts to unpack and scan the file for viruses. Many people have their AV configured to periodically scan incoming e-mail attachments as they arrive — suddenly, the trusted gatekeeper becomes the weak link in the security chain.

All antivirus products have to deal with this challenge, and F-Secure is certainly not the first AV vendor to have this problem. In fact, most of the major AV products have announced similar vulnerabilities in the past. AV products contain extremely complex unpacking and parsing code due to the variety of file formats that they have to support.

This particular LHA vulnerability is related to the gzip vulnerability from last fall, which affected dozens if not hundreds of vendors whose products relied on the GNU gzip utility. This goes to show that you should apply the same code security testing process to third-party libraries as with the code you develop in-house. Third-party code still needs to be security tested and not simply assumed to be correct.

Analysis of binary files without access to the source code is becoming more prevalent in the last five years or so. Of course Java decompilers have been around almost as long as Java itself, but that’s not machine code. I’m talking about analysis of native machine code (x86 or PowerPC instructions), and not from object code (.o or .obj files), which have relocation and symbol information in them. In other words, the actual programs that run on real computers.

The University of Wisconsin has had their Codesurfer/x86 project since about 2003. It uses a combination of disassembly and custom static analyses to automatically analyze x86 binaries for security vulnerabilities, with a research slant. Of course, Veracode is using static binary analysis for commercial security analysis services. Researchers at the University of Arizona have been investigating alias issues and register liveness of executable code. There has been work on DSP (Digital Signal Processor) binaries in Europe and elsewhere. There are even PhD theses on binary analysis (including my own, currently under examination).

The author of IDA Pro is beta testing a decompiler-like visualization plug-in called Hex-Rays. Phrack Magazine, issue 64 has an article entitled “Automated vulnerability auditing in machine code“. We’ve come a long way since any analysis of binary programs was compared to making pigs from sausages.

It seems to me that the benefits of binary analysis are moving from underground to mainstream. Binary analysis is a superset of source code analysis. Often an organization uses third party applications or libraries in software development and cannot legally or logically access source data. Additionally compiler, optimizer and OS bugs, security vulnerabilities or other malicious behavior can be reflected in an application’s security state. Binary analysis reflects the data flow of the entire compiled application as the OS/Platform may execute the intended and un-intended functionality inherent within the code.

So, you can always compile source code to put it into binary form but you cannot do the reverse for binary code. Binary analysis thus analyzes the part of your software that you have source code for and the binary part that you do not.

The increasing availability of binary analysis tools will surely lead to more effective discovery of vulnerabilities, by all parties including those generating malware. It makes sense that software developers should also take advantage of binary analysis for security checking.

Identity theft and the huge TJX breach have brought information technology and security to the forefront and now the states of Texas and Massachusetts are contemplating bills that would hold corporations financially responsible for security breaches.

Computerworld’s Article states that “Texas mulls bill that would make PCI requirements a state law”. According to the article, Texas Bill HB 3222 passed the House of Representatives 139-0. It should prove interesting to see what the Texas Senate and Governor Rick Perry have to say about this. Is this really the right move for any state? Massachusetts is also considering legislation that will hold a breached entity responsible for the costs associated with consumer protection.

I feel Information (Security) Standards and Frameworks really should be a part of every corporation’s processes and policies. IS027001, ITIL, CobiT and BS7799 have been around for some time and they are comprehensive and well thought out (IMHO). Is PCI DSS really the right standard to work from? I’d have to say anything is better than nothing but the more comprehensive, the better. I also have mixed feelings about additional legislation. Why not let the corporations hammer it out? Then again, unless there are very specific requirements with repercussions, someone, somewhere will avoid them.

In case you’re unfamiliar PCI DSS has 12 basic requirements:

Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
Protect Cardholder Data
Requirement 3: Protect stored cardholder data.
Requirement 4: Encrypt transmission of cardholder data across open, public networks.
Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update anti-virus software.
Requirement 6: Develop and maintain secure systems and applications.
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need-to-know.
Requirement 8: Assign a unique ID to each person with computer access.
Requirement 9: Restrict physical access to cardholder data.
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data.
Requirement 11: Regularly test security systems and processes.
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information.

Seems pretty basic, doesn’t it? As you get deeper into the standard, it becomes somewhat confusing… Then let the bean counters and other wordsmiths at it … Hopefully Texas and the other states that follow suit are smarter than that.

Jeremiah Grossman talked about PCI DSS section 6.6 and the application firewall issues. Some may consider that to be more band-aid work instead of doing the right thing and working on the basic building blocks that build our entire infrastructure – the applications themselves. I would argue that PCI DSS is very close to being a band-aid framework itself. While it is a good small step, it is not comprehensive enough or specific enough to become LAW. Granted, with the Brands backing the standard and certification process, it’s a framework that has some teeth, but I think the jury’s still out on the fines and usage of those “teeth”.

Computers, networks and applications have been around for quite some time (Captain Obvious, there). We rely upon them day in and day out to perform some of our most critical work functions. Protecting these assets, the media &data they control seems (to me, Captain Obvious) to be common sense. Why do we need legislation to force something down our throats? Does this really help us to align Information Security to our business objectives?

Since this is a blog, I should probably venture forth some of my own opinion: I have very mixed feelings about this. As a consultant, I worked with quite a few organizations with an incredibly high tolerance for risk. Controls that would have been very simple to implement were ignored. I witnessed a good deal of ignorant risk avoidance instead of educated risk determination (“if we don’t know about it, we’re not responsible”). Then again, some laws can be used a sales scare tactic: “WE MAKE YOU SOX COMPLIANT” or become a whole industry unto themselves.

PCI is already a requirement at places that take credit cards so a law would only require it in other spheres. Does a blog need to be PCI compliant if they accept personal information in a profile? What is the scope?

Legislation, reasonable or unreasonable, tends to be contagious.

Security awareness is an incredible thing:
California SB1386 brought personal information breach to the forefront of social consciousness. Identity theft has become more prevalent in society. We need to know when/if our personal data has been compromised, so we can determine if it’s being used by someone else. I myself received more than 5 letters from the Veterans Administration when they thought they lost a laptop with Vet’s personal information on it… then received another 5 when they determined they didn’t lose my information and recovered the laptop.

Choicepoint, the first significant public disclosure: of course, they waited quite a bit before disclosing that “identity thieves stole the personal data of at least 163,000 Americans”.

TJX, yet another one:

Would these entities have disclosed their breached status without this legislation?

Bloated legislation, not so hot:
Sarbanes Oxley – Specifically section 404. Whole security industries popped up over night to help with this legislation. Try Googling: “Sarbanes-Oxley act section 404”
Heng Hsieu Lin and Frederick H. Wu wrote about the limitations of Section 404: “This aim is misguided for a number of reasons. First, internal control was not conceptually designed to be a panacea for corporate ills.”

Anecdotal evidence: prior to joining Veracode, I was on site with a customer auditing their IS027001 Information Security Management System. The company had a control (for SOX-404) that stated “An intrusion prevention system (IPS) will be in front of all financial systems”. As part of the diligence process, I requested records of operation, which their policy stated were compiled logs from their IPS. They were unable to produce logs, as the IPS had been turned off. This particular customer had passed their SOX audit with flying colors, yet one of their primary controls had not been active in at least the 9 months preceding their SOX audit.

The Point:
Although I am all for responsibility and actionable policy, why not use common sense, do the right thing and avoid making more bloated laws? If we have to make legislation to cover those that will not perform due diligence in protecting our assets, then make the law actionable, simple, effective, clear and concise. Research before action!

Network World recently published an article entitled Cisco says FTP feature in IOS is a hacker backdoor. The opening paragraph reads as follows:

Cisco says a flaw in the FTP server utility in its IOS router/switch software could be used as a backdoor by attackers.

Do you see the discrepancy? The opening statement is inconsistent with the title of the article. Are they saying that the flaw could be used as a backdoor, or that the flaw itself is a backdoor?

Any vulnerability that is remote, pre-authentication, and trivial to exploit could be used as a backdoor of sorts, once details emerge and somebody publishes an exploit script that the kiddies can use. This would clearly be a big story, considering the sheer number of Cisco routers that will require patching. However, if the flaw itself is a backdoor, that implies that the vulnerability was introduced maliciously, either by an insider or by someone who broke into Cisco’s network and modified the IOS codebase. This would be a HUGE story, because now you have to wonder about the extent to which the IOS codebase has been compromised.

First let’s break down the Cisco advisory. Like most vendor advisories, you don’t get many technical details. However, here is what we do know:

• A remote attacker can bypass the IOS FTP server authentication mechanism
• Having bypassed authentication, the attacker can read or write any file on the router’s filesystem, including the startup-config file
• The vulnerability gets the maximum possible CVSS rating of 10.0 because it is remote, pre-authentication, and trivially exploitable, with full confidentiality, integrity, and availability impact

But wait, what’s this? There’s also a Denial of Service vulnerability? Apparently, you can make IOS reload through the FTP interface, and repeatedly triggering this reload (think reboot) could effectively create an outage. The important part is that there’s a way to force a reload.

The advisory also says that a remote attacker could “cause the affected device to reload, or execute arbitrary code” but I’m not so sure about the arbitrary code part. Maybe they just mean arbitrary IOS commands.

Basically, an attacker could take control of the router a couple different ways. Network security guys, correct me if I am off base here or omitting any good attack vectors:

• Fast but clumsy: Retrieve the startup-config, alter the commands used to set the line password and enable password, upload the modified startup-config, force a reload, and login using the new passwords
• Slower but less obvious: Retrieve the startup-config, crack the passwords (difficulty dependent on whether they are configured as “passwords” or “secrets”), and login using the cracked passwords

Again, the vulnerability is undoubtedly a big deal, in and of itself. But what I really want to know is whether this was an intentional backdoor planted in the codebase or just a horribly dumb implementation error. The ability to not only bypass authentication but also force a reload seems a little suspicious, but we won’t know for sure unless Cisco discloses more information. More importantly, if it does turn out to be a bonafide backdoor, what does this say about Cisco’s SDLC?

[Allow me to introduce Mike VanEmmerik. Mike is one of our engineers, who works closely with Christien Rioux and others on Veracode's analysis engine. Those of you who follow the decompilation community probably recognize his name. We'll have a full bio posted for him soon, and he will be a regular contributor to this blog.]

It Couldn’t Happen To Us!
by Mike VanEmmerik

Surely this was what was going through the minds of the security staff of retailer TJX when they decided that WEP wireless security was “good enough”. One thing they most certainly were not envisaging was a group of organized crackers with telescope-like antennas deliberately trying to steal data from outside a retail store.

But that’s the thing about security — whether it is a wireless network, web-based or stand alone applications, or for the next Olympics: you have to plan for the worst. The same incentive that drives the corporate world (the desire to be financially well-off) also drives the cracker world. Exploiting security vulnerabilities is big business these days, and the costs to business are even higher. Some estimates put the eventual cost of the TJX breach at over 1 billion dollars. So you have to assume that your adversaries are worthy. They know how to use security effectively; the encryption on files left by the intruders remains uncracked today.

Good security is a mind set. The “couldn’t happen to us” mind set just isn’t good enough in 2007, or in fact in 2005 when the TJX breach apparently started. Every possible check needs to be done, without costing a fortune or exhausting the supply of security experts.

Addendum

Hi, this is Chris again. I just wanted to add an ironic twist to Mike’s commentary. Yesterday I spoke with a friend who has been doing security consulting in the Boston area for the past five years or so. As it turns out, several years ago, his company put together a proposal for TJX to conduct a wireless security assessment and penetration test. Unfortunately TJX decided not to go through with it. Typically this sort of assessment would include a review of the overall wireless infrastructure as well as site visits to a representative sampling of the retail stores. In other words, there’s a strong chance that the root cause of this $1B breach could have been discovered before the break-in occurred, for a tiny fraction of the cost. Talk about ROI — ouch.

I never actually posted the rest of my notes from CanSecWest. At this point, I’d be leaning towards leaving it at that, but since I’ve had a couple requests to finish up, I’ll oblige, providing I can still remember the salient points. So without further ado, CanSecWest Day 3:

Andrea Barisani and Daniele Bianco from Inverse Path gave an informative and entertaining presentation on Unusual Car Navigation Tricks in which they explained how RDS-TMC traffic messages could be easily forged to create “events” that would then be received and displayed by TMC-capable GPS devices. Normally TMC is used to indicate that there is a traffic jam at a particular location, so that the GPS can determine alternate routes. However, “traffic jam” is only one of many event codes supported by the protocol; others included “air raid”, “bull fight”, “boxing match”, etc. While this added some humor to the proceedings, the more serious angle was whether or not there could be an impact on emergency services or even national security as we become more reliant on the technology. There was some discussion of encryption in the protocol, which is limited to bitwise XOR on fixed keys, as it was designed to support subscription content as opposed to preventing malicious data.

Jonathan Wilkins from iSEC Partners demonstrated ProxMon, a tool he’d developed to build some automation into web application penetration tests. It basically scrapes WebScarab logs (support for other proxy log formats in the future) and extracts useful information such as server information, cookies generated, common frameworks in use, etc. to build a repository of metadata about the application being tested. It is primarily a passive tool but has some built-in scanning capabilities as well. It seems to do a good job at automating a bunch of tasks that most people currently accomplish using grep, awk, and various Perl scripts cobbled together. With some additional effort — it’s an extensible Python framework — it could evolve into a more valuable tool.

Tavis Ormandy from Google presented Untrusted Code in a Virtual Machine in which he essentially fuzzed various VM packages to determine ways in which code running on a guest OS could potentially affect the host OS. While not a new idea, the research was interesting as it focused on a few select attack vectors applied across a range of VM implementations. The primary targets were BITBLT operations against the emulated VGA device, random I/O port activity, and instruction set fuzzing.

I think around this point I started getting a little lazier with my notes, as I was doing all this on my BlackBerry keyboard. Of the remaining talks I enjoyed the one on Attacks of Nortel VoIP Implementations. Not at all surprising but certainly entertaining.