We do a lot of work helping protect small and mid-sized business (SMBs), and it’s great to see these organizations get attention.

An article over at at Dark Reading covered the Visa discussion well: Small Business: The New Black In Cybercrime. Interesting tidbits:

• Improved security at large organizations is driving criminals to target the less secure SMB business sector.
• 85% of all fraud (in Canada, at least) occurs at SMBs
• SMBs struggling to meet PCI compliance should move to using payment processing gateways and other means to avoid having to deal directly with card data.

Do you buy that first point? Sure there have been incremental improvements in large business security in recent years, but hardly enough put a dent in the number and magnitude of their data breaches.

It’s easier to attack small businesses, but they have so much less to steal. It takes a little more effort and time to crack a large business, but a success nets criminals millions of card numbers, accounts, personal identities or dollars.

If large business security improvements were having a real effect I’d expect black market prices to trend upward. Most data sold on the underground originates from breaches of large businesses, yet prices continue to fall. For example, Symantec’s Internet Threat Report Jan- Jun 07 and July to December reports show still prices falling:

Regardless of trends, small and medium business are especially at risk, but from lack of resources and lack of awareness, not targeted attacks. The security attacks we’ve dealt with at small organizations have all been from standard malware, script-kiddie exploits and untargeted phishing.

Small and medium business security is yet another security blind spot, but of a different kind. The blind spot of the organizations themselves is in failing to see where they are most at risk.

Right now, the only exposure most small organizations have to a security standard is PCI DSS. Sadly that standard is myopic: it only addresses confidentiality.

Yet the biggest risk facing most small organizations is continuity: infrequent and untested backups, no offsite storage, no fallback web presence, etc.  Most small businesses never recover from a business interruption longer than a few days. Too bad continuity and availability in general are outside the scope of PCI DSS.

Obviously, losing merchant status due to repeated breaches of card data would also shut down a business, but in reality that’s far less likely than banal incidents like hard drive failures, a smash-and-grab or a fire.

Sadly, we see organizations spend all their resources chasing PCI compliance at the expense of overall risk management.

So the third point above is good advice: if at all possible, transfer the risk of card processing to a payment gateway. It costs more per sale, but until sales reach a fairly high level overall winds up being less expensive (and risky). Plus resources are freed to identify and address higher risk security concerns such as continuity.

No related posts.

• The official announcement from Adobe
• CVE numbers: CVE-2007-3456 , CVE-2007-3457 and CVE-2007-2022

Now, normally I avoid posting vulnerability notices on this bog… there are plenty of other services for that… but this announcement doesn’t seem to be getting a lot of exposure.

As I wrote last year when another big vulnerability in Flash was made public, Flash is considered by many administrators to be an inert, vegetable-like format immune to security issues. I’ve never seen an organization that regularly updates the Flash player on desktops or even consider Flash to be an executable file format. Another security blind spot and perfect fodder for attackers to gain access to desktops.

By the way, on the Windows if you have both MS Internet Explorer and better browsers like Firefox or Opera installed, you have to upgrade twice: MSIE uses an ActiveX-style plugin but other browsers use the traditional Netscape plugin interface. A single download will not install both. Visit the Flash install site with both browsers to get the appropriate Flash player for each.

Related posts:

• Remote exploit in Adobe Flash player
• Port scanning with Adobe Flash
• Avoiding the Adobe PDF reader plug-in vulnerability

As I’ve written before, testing of these beasts is usually minimal yet the calculations they produce are trusted as gospel. Spreadsheet errors are estimated to cause billions in losses each year, yet the issue remains a blind spot for most organizations.

Oregon State University has announced a unusual tool they’re calling “GoalDebug” that attempts to help reduce spreadsheet errors. I say “unusual” because the software isn’t an auditing tool to verify spreadsheet accuracy in any definitive way, but rather what sounds like an expert-system driven suggestion system. According to the announcement, the tool identifies ways humans commonly make mistakes then “gives end users a chance to explore, apply, refine, or reject suggested changes”. From the announcement:

For instance, if someone sees a figure in a spreadsheet that seems suspicious or is clearly incorrect, they can plug in the correct number, and the OSU system can suggest several programming mistakes that might have created the error – which the user can then sort through and use to identify the problem.

I’m sure the system bears no resemblance but that description reminds me of the “Clippy” assistant for MS Office. As an end-user on-the-job training tool such a tool might have value, but should software regularly used for critical financial analysis be debugged with such a loose approach? Compare the functionality to other statements in the announcement:

“…it has been observed that up to 90 percent of the spreadsheets being used have non-trivial errors in them.”

“…the costs or financial misrepresentations are far more serious, and companies have lost millions or billions of dollar”

“There are dozens of places an error can be made… A person can click their mouse in the wrong spot, a simple mechanical error. They could use a plus instead of a minus, add a row at the end of a data area instead of in the middle, and get a completely different result.”

What other form of software is widely used and trusted yet results in errors 90% of the time, costs millions or billions and can be broken dozens of trivial ways? If spreadsheets are this bad, maybe it’s time to rethink using spreadsheets at all.

Related posts:

• Spreadsheets considered harmful

The paper covers a few of the recent VM-specific malware like the SubVirt rootkit (PDF) but mostly concentrates on methods of detecting the presence of virtual machines, including proof of concept code for detecting VMWare, MS Virtual PC, Parallels, Hydra, QEMU, and even good ol’ BOCHS.

An interesting paragraph:

“A more serious vulnerability potentially exists in hardware-bound virtual machine emulators, if the guest can interact with third-party devices on the system.  For example, if a buffer-overflow vulnerability exists in a network driver in the host environment, it might be possible for an application within the guest environment to send a specially crafted network packet that reaches the host network driver intact, and thus exploit that vulnerability.”

I think that’s the most likely avenue of attack against “enterprise VMs” like VMware ESX which run on the “bare metal” and use their own proprietary drivers for hardware. Drivers are yet another security blind spot no one has paid much attention to until recently. For example, the ongoing saga of vulnerabilities in the Intel wireless drivers, allows most laptops to be compromised despite personal firewalls and other OS-level protections because the bugs are at the driver level.

This is yet more to ponder if you’re considering relying on VMs to provide the same level of isolation as physical hardware: it doesn’t. I think projects that are using VMs to run software firewalls and to provide virtual DMZs are eventually going to have a very rude awakening as more methods to escape VMs are found.

Related posts:

• Fuzzing virtual machines
• CIS releases virtual machine security guide
• Security of virtualization

However, Google code search has made this capability more public and the predictable has happened: a flood of articles in industry publications and blogs about how this “new” search can reveal vulnerabilities in applications, followed by predictions of how “hackers” will use this to launch a flood of exploits and accusations by security “experts” of irresponsible behavior on the part of Google (by the way If you want to have fun finding vulnerabilities in published code, Gadi Evron over at Securiteam is maintaining a list of queries, as is the Bugle project).

Using using search engines to find vulnerabilities has been well documented for years, yet every once in a while someone notices that search engines actually (gasp!) index the contents of publicly available files on the Internet and that (shock!) some of that content probably shouldn’t have been made public. Google and other search engines aren’t cracking into private intranets and password-protected file repositories… they are simply indexing files made accessible to the general public. That is, after all, what they do.

The real story, if there is one, highlighted by this new code search is that too many developers still do stupid things… like hard-coding passwords in source code and not validating input. Yet most stories are focusing on how Google code search makes such stupidity easier to find. You’d think by now that most people understand what the Internet is and how search engines function. How is it possible to be surprised that files made publicly accessible via web, ftp, or anonymous CVS are found and indexed by search engines? Is this yet another security blind spot?

In some cases, surprise is understandable. People generally don’t think of CVS and other code repositories as being indexable by search engines… and many, many people put up public web and FTP servers for internal use and think search engines can’t find them because no web page links to the URL (of course eventually someone always saves a link to it in del.icio.us or a similar public site, or a web master sees the link in their server’s http_refer log and follows it, etc).

My favorite experience with search engines was when I worked at a certain large multinational. They were rolling out an intranet search engine for the first time and every night all the records in certain databases got deleted. No one could figure out who was doing it. It turned out that Filemaker Pro at that time had a simple “publish to web” function that created a simple web-based front end automatically. Unfortunately, management functions like “insert”, “modify” and “delete” were provided as standard HREF links on each page. Everyone assumed that only humans would visit intranet web pages and no employee would ever maliciously click “delete”, so no steps were taken to secure those functions. Each night the search engine crawler dutifully “clicked” each link it found, including “delete”, wiping out each database one record at a time.

I guess knowledge of search engines is a basic topic that needs to be covered in a security awareness session for developers and managers. The points for such a session might look something like this:

1. The Internet is a global collection of interconnected public networks.
2. Everything that can be accessed from the Internet will be, unless you restrict that access using authentication, firewalls, or by some other means.
3. Search engines follow every link they find, and eventually all links are found. See point 2.
4. It’s not just humans accessing web pages.

Update: This article is a good example of the drivel some security “experts” have been saying about Google code search.

No related posts.

Serious vulnerabilities in Flash have been discovered many times before (CVE-2006-3587, CVE-2006-0024, MPSB05-07 and CVE-2002-0477). The interesting thing is that though most of the planet has some version of the Flash Player installed in their browsers, reported vulnerabilities are largely ignored.

Few organizations think about the browser plug-ins they have installed. They may be aware that things like Flash, Java and Adobe PDF viewer are installed but few seem to keep records of the version or have ways to deal with them in their patch management system. The stats I see on web sites we manage show that about 90% of the visitors are running the vulnerable versions 7 or 8 of Flash player.

This is another security blind spot. Flash vulnerabilities never seem to get much exposure. It may because the idea that Flash was completely safe became accepted ten years ago when it was first introduced. PDF files enjoy that same status… most think of PDFs as inert read-only file types, yet for several years authors have been able to embed scripting, executables and exploitable Windows multimedia in them. (Interesting experiment: if you have a copy of Acrobat, embed some malware inside a PDF and see if your anti-virus systems detect it. Many AV systems are either incapable of scanning PDFs or are configured to ignore that file type)

Anyway, the official vulnerability announcement from Adobe is found here. Update your systems soon.

Related posts:

• Major new flaw in Adobe Flash Player – Windows, Linux and Mac
• Port scanning with Adobe Flash
• Disarming Adobe PDF Viewer