Podcasts

It's been easy to see why, historically, most Mac users haven't felt the same level of security-related anxiety as Windows users. Until now, no one has really bothered targeting them.

When commentators like this one dared suggest, in 2003, that Apple's OS X software was susceptible to the same sorts of vulnerablities that have plagued other operating systems, the reader reaction was so severe it was worrying.

Indeed, one of the comments posted on the piece by a particularly passionate reader suggested ZDNet's Sydney bureau would make an excellent destination for a truck laden with explosives.

Keep in mind that in 2003 there were few vulnerabilities being disclosed in OS X, leading most consumers to genuinely regard it as more secure. But from there, a trickle of bugs began to be disclosed. By 2008, OS X was giving Windows a real run for its money in terms of the number of bugs being disclosed and patched. The myth of OS X as a "secure" operating systems was destroyed among the more savvy types in the IT industry, and Apple dropped its rhetoric about its operating system's amazing invulnerability to malware.

Yet in the years since the malware never showed up. Sure, anyone with half a clue could trigger a client-side exploit in OS X, but what then? The science of writing Trojans for Windows-based operating systems is mature; staff at CERT teams and AV companies have actually found comments and evidence of revision control in modern PC malware.

Mac malware has been primitive in the extreme by comparison -- the bad guys just haven't built up their OS X chops yet.

Last year, news of simple script-based Mac malware doing the rounds surfaced. The badware would simply alter the user's DNS settings, so it was pretty simple stuff. Some may argue that's actually pretty serious -- if an attacker can control their target's DNS, a man-in-the-middle hack is trivial, thanks to browser insecurity (Hi, Safari!). Still, this early Mac malware was hardly what you'd call sophisticated.

But now we're seeing some much, much nastier stuff. Risky.Biz forwarded a recently obtained Apple malware sample to two parties -- Paul Ducklin at Sophos (disclaimer: Sophos is a sponsor) and a contact who'd prefer not to be named.

Paul had seen that sample before, and Sophos's products detected its payload. But it was what the other had to say that I found particularly interesting.

His analysis indicated the sample -- which pops up as a flash installer on, err, "video sites" -- may in fact automatically trigger upon download. How? Well, every time Safari downloads a file with a DMG (Apple disk image) extension, it will auto-mount it when the download's complete.

That's really handy, but also a security issue, especially when you remember that there have been buffer overflow vulnerabilities in the code OS X uses to mount DMG disk images. So if a user hadn't patched against the DMG overflow, all they'd have to do is click "ok" to a bogus Flash installer notification, served from the domain apple-updates.com. OS X would do the rest for you.

My contact couldn't be 100 percent sure the sample was trying to trigger the DMG bug, but even the possibility should give us pause; it would mean the badware is getting much smarter.

To be fair, Windows still does some similar, super-daft things. The Conficker malware is currently spreading left right and centre because it's basically impossible to disable autorun in Windows without resorting to a registry hack.

The payload in the Mac malware sample in question was a 'dloader,' tasked with connecting to some shady data centre in Eastern Europe and downloading more bad stuff.

This is much more sophisticated than a script that just alters some DNS settings. It's closer in sophistication to the malware we've been seeing targeting PCs for the last 10 years.

Interestingly, we haven't seen this dloader actually grabbing a payload yet. That tells me these guys haven't bothered actually writing a serious Trojan yet -- they've just sent the first stage of the attack out there to see how many bots they wind up with.

If they get enough, undoubtedly they'll actually create some "real" malware for it, and begin distributing it to pre-infected hosts.

So that's it folks. Mac malware has arrived, and what a party it's going to be. Most Mac users are convinced they're using a magical, impenetrable platform, so they don't actually use antivirus software. Apple's advertising campaigns of yesteryear actually encouraged that mentality. Combine that with Apple's expanding market share, and the average Mac user is now a very tempting target. A sitting duck, if you will.

Enjoy the next couple of malware free months, Mac users, because you're in for a rough ride in '09.

Patrick Gray is the managing editor of Risky.Biz and the host of the Risky Business security podcast.

The online environment is just like the real world, yet for some reason many consumers completely abandon their street smarts the second they fire up their browsers. When a leather-clad, toothless ruffian is walking up and down the street saying "give me $500 and I'll come back in an hour with a computer worth $1000," everyone knows not to trust him. Yet this is the same premise by which many scams, such as online auction fraud, are perpetrated.

The success of online criminals is harming consumer confidence.

In late 2008 I released the findings of the Consumer Trust and Confidence Online Survey [pdf] which was aimed at determining the level of trust and confidence of Australian Internet users within the online environment. The survey focused on e-commerce, social networking and online safety.

There were some interesting results. For example, 35 percent of respondents were more trusting of online transactions than two years ago. That sounds great until you realise 65 percent were either less trusting or had the same level of trust as two years prior.

Considering the increasing value and importance to the Australian economy the Internet plays, these statistics should ring alarm bells for anyone with a vested interest in online commerce.

Let's dig a little deeper.

The two most important factors considered by survey respondents when considering purchasing goods and services online was the reputation of the merchant and the payment method. Now we have some actionable information that tells us organisations must boost their reputation to bolster consumer confidence. Here's how:

• Be transparent -- give honest and open responses to customer questions and feedback
• Be flexible -- recognise change in systems and behaviour and implement swiftly
• Establish a reputation system -- it's a popular feature for eBay transactions
• Reflect reality - customers (and the media) are smarter than you think [They sure are.. ;) -- ed], they can sniff out a fake quickly.

Which leads into payment methods. While plenty of organisations abide by the Payment Card Industry Data Security Standards, some just don't. Media reporting of e-commerce organisations that have been compromised with the loss of customer credit card and personal information is a weekly occurrence.

But it's not just targeted hacks that are causing problems, there are far simpler forms of fraud. Consumers have proven willing to send payment for non-existent goods to unknown beneficiaries in international destinations via money transfer systems like Western Union.

Why do consumers engage in this risky behaviour? Maybe it's because online consumers are usually at home in a relaxed and comfortable environment where they can't see the normal visual cues that make us suspicious. Like the guy who's trying to sell you the Blu-ray player is covered in prison ink and has no teeth.

In a real world transaction their radar is far better attuned to detecting the potential for fraud.

The successful integration of e-commerce into the Australian economy is dependent upon the level of trust and confidence consumers have in the digital environment.

Developing new kinds of commercial activities utilising the Internet hinges on assuring consumers that their use of networked services is secure and reliable, that their transactions are safe and that they will be able to verify information about transactions and transacting parties. There are too many organisations that have a commercial interest in establishing customer trust and confidence in online technologies for this not to be taken seriously.

Nigel Phair was the Team Leader of Investigations for the Australian High Tech Crime Centre from 2003 to 2007 and the author of Cybercrime: The Reality of the Threat. He is an active cyber crime analyst.

This week's podcast is brought to you by Tenable Network Security and hosted, as always, by Vigabyte virtual hosting.

It's a special day for us at Risky Business HQ -- we've launched our new Web site: http://risky.biz/

We now publish two podcasts, video and written news and opinion. There's also forums, so by all means go and sign up for an account! We'll see you in there.

On this week's show we're talking to L0pht/@stake/Veracode co-founder Chris Wysopal about the rebirth of L0phtCrack, the legendary password cracking package.

In this week's sponsor interview, Tenable Network Security analyst and Open Security Foundation dude Brian "Jericho" Martin pops in for a chat about dataloss -- are you more likely to lose data through a USB key, lost laptop or an actual attack?

Adam Pointon also pops by for a look at the week's news.

In this first post in our fresh new RB2 podcast feed, you'll hear Krusher's presentation to the second Kiwicon conference in New Zealand.

It was recorded in September 2008.

H D Moore has also done some interested work with wardialling. You can hear him discuss his work on WarVOX here.

Sure, maybe its not 1994AD any more. But let me posit this, which I culpably dub Metlstorm's Assertion:

The cost of owning a corporation is a fraction of a percent of their annual infosec spend.

Lets go with 0.1%. Can you think of any organisation you've worked for, or on, or with, or pwned that you couldn't own for the sales margin on a single Check Point device?

Let's assert the value of owning a corporation -- if you're any good at the order-fulfillment bits of crime, which I'm not -- is proportional to its market cap.

The ratio of cost-of-ownership to value-of-ownership is so low as to have an ROI to an attacker that is nearly infinite.

Stated more concisely (unusual for me, I know); the incremental cost to an attacker between not hacking you and hacking you is so close to zero we have to assume they actually do.

Which means you should proceed on the assumption that your corp is already owned.

We live in a world where our desktop machines get USB autorun worms, where a garden or variety botnet worm owns entire Ministries of Health, where insider attacks are commonplace, where biometrics doesn't work, where routers are backdoored by offshore manufacturers with various political goals, where we pay janitorial services staff minimum wage because they've only got physical access to, well, everything via their trivially clonable RFID proxcards running on building management software off a crappy old NT4 box in the basement. Ok Metl. Breathe.

You see where I'm going with this. There is no infosec industry. We're just doomsayers who take the chumps money while they've still got it, and when they don't we just scare the next lot senseless until someone pays up. We don't actually improve anything.

The infosec industry is a trinity; the boxpushers (vendors), the chumps (the users), and the doomsayers (us, the pentesters).

Boxpushers sell kit to the chumps, who've been goosed into thinking they need it. The doomsayers occasionally pity the chumps, but are generally stuck in io-wait, writing off the boxes being pushed as useless, impractically complex, and that highest criticism of all; boring.

Us doomsayers take the chump's money, then tell them in excruciating and savage detail how much they and the boxes they got pushed suck.

And they invariably do.

When we're on a typical gig we sit around, amusing ourselves intellectually by doing something we'd all probably just do for fun anyway, call it work, and then tell the chumps in serious sounding language quite how poked they are today.

There is doom. Unending grimness. Like the darkened frostbitten forests of Ukranian blackmetal album covers.

Hell, in the case of boxpushers, they actually make it worse (Hi mail antivirus gateways! Hi IDS consoles, hi shatter-prone desktop asset management and patch deployment solutions, giving up localadmin like [security researcher] Brett Moore slipped you his best Mr December smile under the digital cyber eMistletoe.)

I ask you again -- is there any corporation you've seen where the upper bound of cost to own them wasn't proportional to the janitor's hourly rate? We all know, deep in our guts, that we could own anyone. And we wouldn't be doing it with Ben Hawkes' heap technique -- that stuff's for impressing cons and talking shit in bars, not wasting on actual attacks. We'd just roll like it was 1994AD; and we'd win. Every time. You know it. And how much would it cost? To own a bank, a telco, an ISP, a critical infrastructure provider? Really, we all know the turgid, sodden, doomladen truth.

How much would it cost?

Yeah. Exactly. Fractions, my man. Fractions of a percent.

Metlstorm is a New Zealand-based freelance security consultant. He's created several tools including Hai2IVR, Winlockpwn and SSH_Jack. He's also an organiser of the annual Kiwicon security conference in Wellington, New Zealand.

1. Misunderstanding.

Don't treat PCI DSS as a purely technical standard. A few minutes browsing through it and you'll know why -- there is a stack of technical requirements.

Usually, however, it's hard to meet the technical requirements without first taking care of policy issues. For example, it's a bit backwards to install new firewall when you don't yet have configuration standards.

The trick for achieving compliance is to read the PCI DSS backwards. Start at requirement 12 and have your risk management framework in order, then your policies, then procedures, configuration standards, then implement it, and audit it.

Don't let a technical manager own your PCI compliance responsibilities. The path of least resistance is down, and generally the most difficult challenges for compliance are within the business and business process -- not technology. Make sure PCI lands on the desk of someone who has the authority to enforce it throughout the organisation.

That said, of course the staff responsible for PCI DSS Compliance need to have a full and complete knowledge of the standard. Someone with "just enough" knowledge of the standard can be dangerous and wind up costing you more than you bargained for.

2. Misinterpretation.

The requirements and the priorities of the standard are well laid out by the PCI council, but it is important to fully understand the scope of compliance within your business. If you have card data used across many systems, you cannot be compliant as an organization until ALL cardholder systems are compliant.

Many fall into the trap of investing too much time and resources into deciding on the minimum effort required in order to achieve compliance. It buys time from the banks, but it's not a long term approach.

This distortion of the intent of the standard is not only damaging to compliance, but can distract from the security of your organisation as a whole. Apply PCI in accordance with the "spirit" of the rules.

3. Validation.

Validation is not compliance, and compliance is not validation. While organisations that come under PCI DSS must be fully compliant at all times, validation is periodic and its rigour depends on the size of the merchant.

If you are genuinely compliant, staying that way will not be hard, and passing a validation check won't be difficult. If you've cut corners to do the absolute minimum, ongoing validation is when your poor approach will bite you on the ass. Also remember you could be asked to validate your compliance at any time -- especially after a security incident.

4. Cause.

The specific requirements of the PCI DSS are nothing extraordinary, rather they are generally considered to be best practice. If you're not compliant, you really have to ask why.

For each and every point, find out what the root cause of non-compliance is. Is it poor risk management? Lack of resources? Legacy systems? While this can be an overwhelming task at first, if it's performed from a top down approach (as suggested in the first point) it will pay dividends.

5. Framework.

An ad-hoc approach simply does not work. Tying it all together into a framework is the only way to achieve continued compliance. This must cover and have support from all aspects of the business that PCI touches. This can be everyone from HR, project managers, data entry staff, receptionists, etc. Have a plan and work to it.

6. Beware Snake Oil.

You may have noticed the discussion of specific products has been avoided. That's deliberate. There are endless combinations of products that can be used to achieve compliance, but there is no specific product that is required for compliance. If anyone suggests otherwise to you, vendor, QSA, consultant etc -- you are best to politely escort them from the building.

Declan Ingram works for Securus Global, a Sydney-based security consultancy. He has a pwnie-tail and likes to fly aeroplanes dangerously.

The idea was simple. We'd install a bunch of anti-virus products and see who could modify existing viruses to sneak them past detection engines. There'd be beer and banter, a fun afternoon. It wasn't really a scientific contest -- most of the functionality of the scanners was actually turned off. We'd only test the CLI-based signature and heuristic components of the suites.

I'm one of those poor, poor souls who's been forced to repeatedly deploy appalling, sub-standard, anti-virus shit in enterprise environments over the last few years. Sick of trying to fight a virtual wildfire armed only with the IT equivalent of a warm leaf of lettuce, my friend Rich and I decided to stage RaceToZero as a form of protest.

We'd show the world just how awful antivirus software had become. The world would finally understand our pain.

When we announced the contest, some AV commentators and journalists went virtually lost their minds. The first RaceToZero contest, held at DEFCON XVI in Las Vegas last year, was indeed a tad on the controversial side.

Some commentators seemingly expected the headless horseman of the Apocalypse to come riding through the casino when the contest began. Kasperky antivirus founder and CEO Eugene Kaspersky actually compared the Race To Zero with bank robbery and the distribution of narcotics to children. In the minds of some, we were showing the bad guys how to do stuff they couldn't have learned on their own.

Others were a tad friendlier. They saw RaceToZero for what it was -- a bit of fun designed to demonstrate the ineffectiveness of signature-based antivirus technology as a sole method of defence against modern threats.

Either way, we didn't expect the publicity we got last year. In the words of George Carlin, the whole thing turned into a "huge, prick-waving dick fight". A circus, if you will.

So we're doing it again.

To live up to our critics we had planned a HERF gun making contest (hai2EugeneK) but decided on slipping viruses past AV products again instead. The friendly team from OffensiveComputing.net provided the samples we used last year and this year will be taking over the running of the competition.

RaceToZero is still my baby, but I'm happy to send it off to temporary but loving foster care.

OffensiveComputing.net's extensive knowledge of malware, reverse engineering and all things anti* will definitely lift the contest to another level. It won't be as half-assed as last year, (it's more likely to be fully-assed) and may actually produce some results that can be seen as useful benchmarking for endpoint security products.

The Anti-Malware Testing Standards Organization (AMTSO) has published guidelines for dynamic testing and RaceToZero will stick to them.

That means getting all fancy and scientific. As much fun as the last contest was, we didn't really prove much. This time we're trying to create a methodology that might actually tell the people responsible for buying endpoint security something useful, like which products did better.

That's right, vendors, you really should be scared now. We're going to empirically show the world how useless you are, instead of just heavily implying it.

While this balanced, unbiased testing of behavioural AV engines is happening, there will be a live scoreboard so that contestants and spectators alike can see how well the teams are doing and how effective each engine is at detecting the threats.

Another upgrade to the contest is automated unpacking and analysis of samples submitted by contestants, which will be validated against the contest guidelines.

Over the coming weeks more information will become available on the RaceToZero Website and the DEFCON Forums, we look forward to seeing all past and future contestants in Vegas again this year!

bogan \\m/

Bogan is security engineer and researcher from .nz. He is also instrumental in the organisation of Kiwicon, New Zealand's real-deal security conference. In his spare time bogan likes cooking, wearing black and admiring a good burnout.

Thanks to a stellar effort by Gold (his real name, no kidding) at Evolved Development, we've been able to put together what we hope will be Australia's premier information security news site.

Along with the regular Risky Business podcast, Risky.biz will host:

• The Risky.biz blog:
  • We hope to have several dozen contributors from various sectors of the infosec community on board within the first few months. Get the inside scoop straight from the horse's mouth. Giddy up! Nyeeeeeeah!
• News articles:
  • We also plan to publish news articles written by professional journalists in the blog feed. They will be labelled NEWS:
• Risky Business 2, or RB2
  • Risky Business 2 is our new, second podcast. In Risky Business two you'll hear talks as recorded at various conferences, as well as single-shot interviews recorded by Risky.biz staff and freelance contributors. The RSS feed will include sponsored content, but it'll be clearly labelled.
• Forums
  • Once you sign up for an account you can join the conversation!
• Video
  • This section will take a little while to get rolling, but we plan on bringing you video features from interviews to HOWTOs.
• Webinars
  • Within a couple of months we'll be rolling out a new site section called "The Pitch", a monthly Webinar hosted by security vendors who want to make sweet, sweet love to Risky.biz readers, listeners and viewers.

The Risky Business podcast first launched in February, 2007, and has published 100 editions, along with special content recorded at conferences like AusCERT, GovCERT, Kiwicon and Ruxcon.

We hope we can make a red-hot go of this site in 2009, despite business conditions being, err, sub-optimal. Speaking personally, I look forward to getting to know you all through our forums. So what are you waiting for? Sign up and let's get started!

Patrick Gray
Managing editor
Risky.biz

Risky Business is brought to you this week by Check Point Software and hosted, as always, by Vigabyte virtual hosting.

This week's feature is all about wardialling. H D Moore pops in to discuss his latest project, WarVOX.

WarVOX is a wardialler with a difference -- instead of trying to connect to any modem that may be found when you're dialling, WarVOX just records a snippet of audio when the line answers, then analyses it to see what it is.Risky Business is brought to you this week by Check Point Software and hosted, as always, by Vigabyte virtual hosting.

This week's feature is all about wardialling. H D Moore pops in to discuss his latest project, WarVOX.

WarVOX is a wardialler with a difference -- instead of trying to connect to any modem that may be found when you're dialling, WarVOX just records a snippet of audio when the line answers, then analyses it to see what it is. Think of it as nmap for the PSTN.

Juniper Networks Senior Security Research Manager Steve Manzuik is this week's news guest, and Steve MacDonald checks in for this week's sponsor interview.

If you'd like to comment on anything you've heard on Risky Business, or suggest something you'd like to hear on the show, you can call Sydney 02 8569 1835 or USA +1 877 688 8417 (Toll free).

We'll be sure to include your comments in next week's show!

The music heard at the end of this week's show is by Peregrine. Buy their stuff! See their shows!

This edition of Risky Business is sponsored by Sophos.

On this week's show we take a look at a recent survey [pdf] released by Oracle in conjunction with the Independent Oracle User Group.

It found 11 percent of Oracle administrators had never applied a critical patch. In fact, 70 percent of Oracle DBAs surveyed were at least three months behind the patch release times.

How did we get here? Securus Global's Declan Ingram pops in to discuss the possible root cause of such startling data. Race To Zero organiser and master chef Simon Howard also shares his thoughts on database host security.

Paul Ducklin pops by for this week's sponsor interview. We ask Paul how endpoint security providers like Sophos can be expected to battle 0day threats such as the recent PDF and Excel flaws.

If you'd like to comment on anything you've heard on Risky Business, or suggest something you'd like to hear on the show, you can call Sydney 02 8569 1835 or USA +1 877 688 8417 (Toll free).

We'll be sure to include your comments in next week's show!

UPDATE: Due to a production glitch in the original podcast recording, certain audio snippets (music, bumpers) were incorrectly rendered. The file has been fixed and replaced!