FLAMING RETORT – Three words for RSA. Promptness. Clarity. Openness.

What a lot of fuss RSA’s security breach has caused! And what a lot of fear and uncertainty and doubt still surrounds it!

In case you haven’t been following the story, it began in mid-March 2011, when RSA admitted that its security had been breached and that “certain information [was] extracted from RSA’s systems.” Some of that information was specifically related to RSA’s SecurID products; the CEO admitted that “this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation.”

The CEO, Arthur Coviello, also assured everybody that the company was “very actively communicating this situation to RSA customers.”

I thought this was a good start, even though it raised more questions than it answered.

An admission and an apology go a long way – provided that they are quickly followed by genuinely useful information which explains how the problem arose, what holes it introduced, how those holes can be closed, and what is being done to prevent anything like it from happening again.

But RSA’s version of “very actively communicating” with its customers didn’t go that way. We still don’t really know what happened. We don’t know what holes were opened up because of the attack. And RSA customers still can’t work out for themselves what sort of risk they’re up against. They have to assume the worst.

What we do know is that US engineering giant Lockheed Martin subsequently suffered an attempted breakin. Lockheed stated that the data stolen from RSA was a “contributing factor” to its own attack, and RSA’s Coviello agreed:

[O]n Thursday, June 2, 2011, we were able to confirm that information taken from RSA in March had been used as an element of an attempted broader attack on Lockheed Martin, a major U.S. government defense contractor. Lockheed Martin has stated that this attack was thwarted.

Additionally, as I reported yesterday, RSA is offering to replace SecurID tokens for at least some of its customers.

What’s fanning the flames in the technosphere is this: why would replacing your existing tokens with more of the same from RSA make any difference?

Because RSA has offered to replace tokens, speculation seems to be that the crooks who broke into RSA got away with a database linking tokens to customers in such a way that tokens for each company could be cloned. With that database, an attacker would only need to work out which employee had which token in order to produce the right “secret number” sequence.

That, the theory goes, lets you mount an effective attack. It goes something like this.

To tie a token to a user, use a keylogger to grab one or more of the user’s token codes, along with his username, network password, and token PIN. (The token PIN is essentially a password for the token itself.)

You can’t reuse the token code, of course – that’s why the person you’re attacking chose to use tokens in the first place – but you can use it to match the keylogged user with a token number sequence in your batch of cloned customer tokens.

So you now have a soft-clone of the user’s token. And, thanks to the keylogger, you have their username, password and PIN. Bingo. Remote login.

I don’t accept this speculation as complete.

Even if it was the method used in the Lockheed attack, why would I accept that it’s a sufficient explanation? And even if it were, why would I accept – in the absence of any other information from RSA – that the same thing won’t happen again? Are they now offering to stop retaining data which makes it possible for an intruder into their network to compromise mine? Why would they insist on doing that anyway?

More confusingly, if the only practicable attack requires an attacker to keylog the PIN of a user’s token, why is the entire SecurID product range considered at risk?

RSA sells tokens in which the PIN is entered on the token itself, which is equipped with a tiny keypad. Those PINs can’t be keylogged.

So why isn’t RSA stating that its more upmarket tokens are safe? Users of those devices could immediately relax. Or is RSA unwilling to make those claims because there are other potential attacks against its devices which might be mounted by attackers equipped with the stolen data?

Perhaps this token-to-customer mapping database theory is a red herring? After all, there might be other trade secrets the attackers made off with which would facilitate other sorts of attack.

For example, a cryptanalytical report might show how to clone tokens without any customer-specific data. Or confidential engineering information might suggest how to extract cryptographic secrets from tokens without triggering any tamper-protection, allowing them to be cloned with just brief physical access.

In short, the situation is confused because RSA hasn’t attempted to remove our confusion.

It’s no good having mandatory data breach disclosure laws if all they teach us is to admit we had a breach. We also need to convey information of obvious practical value to all affected parties. I’ll repeat my earlier list again. When disclosing breaches, we need to explain:

* How the problem arose.

* What holes it introduced. (And what it did not.)

* How those holes can be closed.

* What is being done to prevent it from happening again.

Three words. Promptness. Clarity. Openness.

PS: Lockheed Martin makes the world’s most desirable vehicle. Here it is at Avalon airport, near Geelong in Australia. That’s what I call a flying kangaroo!

Oracle Java 6 update 26 available now

Java logoA little over three months since the last update to Java, Oracle has released Java 6 update 26 for Windows, Linux and Solaris.

This update addresses 17 security vulnerabilities and one non-security-related bug. All 17 vulnerabilities allow remote code execution without authentication.

Oracle has rated nine of the flaws as a risk of ten out of ten. All but one of the vulnerabilities affect the Java Runtime Environment client software that runs in your browser.

We have seen great success among attackers using flaws in Java to exploit Windows computers, but also a broader experimentation with building malware that will run on Mac and Linux.

Unfortunately, Mac users will have to wait on Apple to release an update to address these flaws, as Oracle does not provide Java for OS X.

Windows, Linux and Solaris users can download the latest Java from http://java.com/en/download/manual.jsp?locale=en.

If you haven’t already, I recommend testing out your standard OS images without the Java plug-in. Most people aren’t using Java these days and it reduces the attack surface for exploits delivered over the internet.

Don’t confuse JavaScript with Java either; they are totally unrelated. Not installing the Java Runtime Environment (JRE) has no impact on your browser’s ability to render web pages that require JavaScript.

If you require Java, be sure that you deploy this update. If you aren’t sure it may be worth testing your images without it. The less software plugged into your browser, the harder it is for malcontents to exploit your users.

A Brave New World, IPv6 Day

June 8th marks World IPv6 Day when a number of major organizations offer internet services using the replacement Internet Protocol version 6 standard. From a security standpoint IPv6 raises some new and potentially interesting problems for malware authors, anti-virus companies, and system/network administrators. All non-network centric aspects of malicious code will be unaffected by the eventual migration to IPv6. However, the impact will be notable on malicious code that propagates around networks, attempts to disrupt network services and attempts to profile network enabled attack vectors.

Protocol Version Address Size Example Address Address Range

Version 4

32 bits.

127.0.0.1

4,294,967,296

Version 6

128 bits.

0:0:0:0:0:0:0:1

340,282,366,920,938,463,463,374,607,431,768,211,456

 

Internet Protocol version 4 was first deployed in 1983 for use in “interconnected systems of packet-switched computer communication networks”. It became apparent that the number of IPv4 addresses could not sustain the huge demand for network enabled devices, stopgap measures were introduced to maximize the lifespan of IPv4 32-bit addressing and work began on a replacement protocol, IPv6. Internet Protocol version 6 was first deployed in 1999 and contains a number of improvements over the legacy IPv4. The most notable improvement in IPv6 was the huge increase in possible address space.

With the introduction of IPv6, the massive amount of possible addresses in a default subnet and additional software tweaks has created new challenges for malware authors and cyber criminals. It is now unfeasible to perform brute force IPv6 address scans in order to profile a network or identify a possible attack vector in this way. IPv6 also mitigates a number of existing IPv4 attacks by design. The SMURF or Broadcast Amplification attacks that were popular in the late 90s are made redundant by the introduction of key features in IPv6 and associated ICMPv6. IPv6 also attempts to control data interception, or sniffing, by introducing a security protocol, IPsec, to authenticate and encrypt data transmitted across an IP enabled network.

The adaption of IPv6 may also cause some unforeseen difficulties. Firewall software and hardware can be bypassed if they do not accurately detect and inspect IPv6 traffic. As we move to the replacement protocol we are facing a learning curve where new threats, that are not yet fully apparent, will emerge.

We are slowly moving towards replacing IPv4 and events like World IPv6 Day are important steps towards a full adoption of the replacement protocol. Unfortunately, as IPv6’s profile is raised and we slowly begin implementing the replacement standard, malware authors are certain to take note and begin adapting.

As always, Symantec recommends that you keep your definitions, signatures and firewall rules up to date to ensure protection against threats mentioned in this blog.

More Mac malware – top tips for avoiding infection

More Mac scareware appeared overnight, with the cybercrooks following the same sort of strategy which has worked so well on Windows: regularly change the look and feel of the fake anti-virus software; use legitimate-sounding brand names (or steal genuine product names); stick to a price-point between $50 and $100; keep the fear factor high; but keep the core programming very similar so development costs are negligible.

Scareware, or fake anti-virus, is fake security software which pretends to find dangerous security threats – such as viruses – on your computer. The initial scan is free, but if you want to clean up the fraudulently-reported “threats”, you need to pay.

Once you’ve paid, the scareware stops lying to you about the non-existent threats, as though it really did clean them up. This means that many victims of this sort of fraud don’t even realise they’ve been duped. Until next time.

These latest OS X scareware variants come from the MacDefender stable, though they identify themselves during startup as Mac Shield:

Once activated, the software pretends to look through your files, pretends to find malware, and invites you to clean up:

But the cleanup isn’t free – you’re required to register:

Registration means payment. The minimum you can get away with is $59.95. But for just $40 more, you can get a lifetime software licence and lifetime support – which would be a good deal, were it not for the fact that the software is completely fraudulent, that the “lifetime” of the software ends tomorrow when the crooks move on to the next bogus brand name, and that there’s nothing to support, since there was no malware in the first place.

You even get a 30-day money back guarantee. Good luck claiming it.

Here are some top anti-scareware tips for Apple users:

* If you use Safari, turn OFF the open “safe” files after downloading option. This stops files such as the ZIP-based installers favoured by scareware authors from running automatically if you accidentally click their links.

* Don’t rely on Apple’s built-in XProtect malware detector. It’s better than nothing, but it only detects viruses using basic techniques, and under a limited set of conditions. For example, malware on a USB key would go unnoticed, as would malware already on your Mac. And it only updates once in 24 hours, which probably isn’t enough any more.

* Install genuine anti-virus software. Ironically, the Apple App Store is a bad place to look – any anti-virus sold via the App Store is required by Apple’s rules to exclude the kernel-based filtering component (known as a real-time or on-access scanner) needed for reliable virus prevention.

* Religiously refuse any anti-malware software which offers a free scan but forces you to pay for cleanup. Reputable brands don’t do this – an anti-virus evaluation should let you try out detection and disinfection before you buy.

Macworld's Editor's ChoiceIn a recent Sophos poll, 89% of respondents said they’d recommend their Mac-owning friends and family to use anti-virus software. Why not take their advice, and get Sophos Anti-Virus for Mac Home Edition today?

DownloadFree Anti-Virus for Mac
Download Sophos Anti-Virus for Mac Home Edition

It’s free – no registration, no signup, and no password needed. It detects, prevents and cleans up malware infections.

Note: the Mac Shield scareware described here was detected proactively by Sophos Anti-Virus as OSX/FakeAV-DWN. Apple subsequently added detection to the XProtect system, using the name “OSX.MacDefender.F”.