I really enjoy listening to Mac Break Weekly.. Leo Laporte is an excellent host and i would tune in just to hear [Andy Ihnatko's] take on the industry and the (possible) motivations behind certain players moves. (he is sometimes wrong, but always worth listening to). The only time the things ever get a little cringe-worthy is when talk switches to malware and security (although both Andy and Leo for the most part have pretty reasonable balanced views on it).

Disclosure: I am a mac user, and love the hardware.. the fan-boy'ism that surrounds it, not so much..

Most security savvy mac users, dont push Invulnerable-Mac argument too much.. But it does lead to the follow-up "Once Mac gets more market share, we will hit the malware tipping point".. I dont think that this is how it will go down.. Here's my $0.002c on it.

One of the talks we gave at the recent ITWeb Security Summit was titled "One bad Apple".. The aim of the talk was to examine the truth/lies/fud behind the security claims on both the fan-boy and hater end of the spectrum.. I dont want to cover the whole talk here, but do want to touch on just a few of the current annoying red-herrings that normally pop up in this discussion:

Vulnerability counts as a useful Metric

This argument has been had by [many people] far brighter than me, so i wont rehash it here. I think its safe to say that since there isnt really a standard on what gets reported, very few vuln count reports end up comparing apples with apples. What i did pick on during the talk, was that some people dont even bother trying to dress up the stats in a cloak of reasonableness. The table below was taken from ByteSize magazine showing that Apple indeed had more Vulnerability Disclosures than Microsoft:

Vendors with the Most Vulnerability Disclosures (ByteSize - 3rd Ed. 2009)

Instead of muddying the water by asking what a 3.2% disclosure means, or by comparing Apple with Microsoft you have to ask yourself if the table is really comparing Microsoft, with its software, hardware, * against Wordpress with its 60 000 lines of PHP code?

My suggestion there is that if we going to use tables and charts, we should at least stick to the reasonable ones:

Malware defense

Of course the next topic that refuses to die is how mac architecture pixie-dust prevents it from getting worms and viruses.. A quick check should clarify this.. The ILOVEYOU virus which took windows computers all over the world (and according to Wikipedia cost about $5.5 billion in damage) was a snippet of VBS that read your address book, and mailed itself to your contacts (where it did the same). You can hack this up in Automator in seconds.. Same functionality completely..

Memory Corruption Attacks

In recent times, Microsoft has made huge leaps in terms of generic memory corruption protection mechanisms to minimize the effect of buffer overflow/mem corruption attacks. While Apple claimed to do the same with Leopard, they still trail Microsoft in this regard. The 3 points we covered:

1. Non-executable Stack.
2. Non-executable Heap.
3. Address Space Layout Randomization.

(We cover these in more detail in an upcoming [conference in July] - but again, its fairly well understood that OSX in its current form is only randomizing libraries, and that to get the benefit of ASLR, you need to be randomizing everything)

So if we are saying that Apple is just as vulnerable to ILOVEYOU and even more vulnerable today than Windows from a nimda or a code-red, then what explains the fact that we dont see Macs getting owned on the same level as Windows?

The almost global answer is "Market share!". The belief that once more people are running macs, the big bad malware writers will start aiming at them.

If you look at the [netcraft web server survey] (2003) you should notice that at the time that nimda and code-red were running around the Internet, IIS didnt have the lions share of the webserver market either. Their lower market share didnt keep them safe then, why does it keep mac users safer now ?

The real market share difference

One of my guesses here is that we are looking at the wrong data for market share. What Microsoft does have over Apple, is a bigger market share of [developers..]

Microsoft went out of their way to make sure that anyone and their dog could write code for their platform, that any idiot in the world could write an app for them, and many did. I suspect that if you consider that any group will have a proportion of people with evil intentions, then in part what we seeing is just the percentage of the bigger pool.

Different user profiles

The other thing (although it sounds strange) is the question of user culture which is different. My wifes macbook air has very little software that didnt come with the machine. Apples "batteries included" policy means that her machine remains pretty clean.. Her mothers windows machine is a different story

Which means what?

Today, pound for pound, OS X Leopard is indeed more vulnerable than a Vista machine, but the eco system around Mac is holding back the huge embarrassing attacks that shamed Microsoft into action. Apple has a small window during which time they can take action, refine their built in mitigation strategies and come out on the other side acting like they were better all along..

(Recent hires like Ivan give hope for this happening)

If Snow Leopard is done right, it will hopefully be Apples XP-SP2, and us fanboys will be able to keep our securer-than-thou attitude.. If it doesnt, its only a matter of time..

Ron Auger sent an email to the [WASC Mail list] on some fine work presented recently by Microsoft Research. The paper (and accompanying PPT), titled [Pretty-Bad-Proxy: An Overlooked Adversary in Browsers' HTTPS Deployments] is pretty cool and shows several techniques for a malicious inline proxy to sniff SSL sessions passing through the proxy. Its genuinely a bunch of cool findings and has been handled neatly (with the exception of some shocking clipart!).

The attack logic is fairly simple. User tries to browse to https://mybank.com. The browser sends a connect message to the proxy. The proxy returns an HTTP 502 proxy error message. The magic comes in here. The browser interprets the returned 502 message within the security context of https://mybank.com.

So the attack works as follows:

1. User tries to browse to https://mybank.com.
2. Browser sends connect message to evil-proxy.
3. Evil-proxy sends back a 502 message, with evil-Javascript and opens an iframe to https://mybank.com.
4. Evil-proxy lets the request go to https://mybank.com and the page loads in the users browser.
5. Evil-Javascript is now running in the same context as the banking session, so it has full access to page..

With a little more arm bending the paper even goes on to remove the neccessity of full control of an evil proxy, relying on an attacker on the local network sniffing traffic and then racing the valid proxy server..

The findings have been disclosed to the browser vendors and have already been remediated, which means we can collectively breath a sigh of relief, but clearly, it has not been a good year for SSL (and SSL implementations).

The United States committee on Homeland Security's Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology recently held a hearing to determine if "the Payment Card Industry Data Standards Reduce Cybercrime?"

Risky Business played snippets of the hearing under the apt title: "Washington spanks PCI DSS" - Like most episodes of RB, its well worth the listen..

One of the "merchants" giving testimony made his point quite succinctly. The credit card companies require us to keep card details, and shift the burden of fraudulent transactions to the merchant. There are much better ways to handle transactions, but the current method is a cheap way for the CC vendors to shift the burden and the risk to the merchants who historically had no alternative.

Online theft of credit card details reached ridiculous proportions, and so the payment card industry had to react, but they reacted by shifting the burden (and the risk) to the merchants. Now im all for people securing their apps and networks, but when you listen to merchants complaining it becomes pretty clear that the credit card industry is threatening punishment for behavior with one hand that it is actually incentivising with its other.

Now merchants (who are no saints) were willing to grudgingly go along with this cost, but when cases like heartland pop up (guys who PCI certified ok while they were busy bleeding card info to evil hax0rs) - the merchants start baying for blood.

The InfoSec Companies: Many infosec companies saw PCI as a chance to sell more services. They rallied to the PCI flag because anything that sells more services is a good thing. This would kinda be ok (mildly excusable) if they were using PCI to sell existing services (that were created to make customers secure) but the problem got worse when PCI compliance became the goal in and of itself. Now you have a bunch of people eager to sell something to a semi captive market. The situation is built for check boxes that obey the law but miss its essence..

But this isnt new? Its not.. But listening to the merchants testifying you get the sense that they have had enough. The payment card industry has tried to fix the problem the (relatively) cheap way, by shifting the pain to the merchants but its quite clear that this approach is not going to work... it becomes clear that to fix the stolen CC problem, we are going to have to (finally) change the transaction model..

The infosec market isnt going away, but i suspect that the credit-card model we currently use, will. Now this should not scare the infosec companies who have been pointing out that compliance does not equal security, or those companies that have built a reputation working on companies and applications that care about security. For those who have built a business model on checking boxes and handing out compliance stamps, my prediction is that the writing is on the wall..

Its like building a company on the Y2k hype.. Sure you might make a whack load of money for a while, and sure there actually are problems that need solving, but sooner or later the dates going to tick over from 1999 and if all you had was the hype, then im hoping for your sake that you took the lease (not buy) option on your company assets..

/mh

*caveat-1 - SensePost holds both PCI QSA and PCI ASV certifications (because we need to make sure we understand the space). *caveat-2 - Predictions in general should be left to prophets, this posting should be taken less as prognostication, and more as prose to warn against building a business model on shaky foundations..

BusinessWeek reports that VMWare has launched a new product aimed at establishing it as a competitor in the cloud computing space.

-snip-

Dubbed the Virtual Data Center Operating System (VDC-OS), the software creates a bank of computers, storage devices, and networking equipment that a company can tap at will, as computing needs arise—say, during a December spike in Web traffic for an online retailer.

-snip-

VMWare is the leet, so this should be interesting to watch...it should also be interesting as it is being spearheaded by some ex-Microsoft execs...

Interesting times

/nick

The recent widespread carnage caused by the Conficker worm is astounding, but is also comforting, in a strange way.

It has been a good few years since the world saw a worm outbreak of this magnitude. Indeed, since the Code Red, Slammer and Blaster days, things have been fairly quiet on the Interwebs front.

As a community, it seems we very quickly forgot the pains caused by these collective strains of evil. Many people proclaimed the end of issues of that particular bent, whether it be as a result of prolific post-worm hastily induced reaction buying of preventative technologies and their relatives, or whether more faith was placed in software vendors preventing easily "wormable" holes in their software.

Needless to say, Conficker turned those theories a little on their head. Wikipedia notes on the impact of the worm gleaned from various sources seem to say it all:

-snip-

The New York Times reported that Conficker had infected 9 million PCs by 22 January 2009, while The Guardian estimated 3.5 million infected PCs. By 16 January 2009, antivirus software vendor F-Secure reported that Conficker had infected almost 9 million PCs. As of January 26 2009, Conficker had infected more than 15 million computers, *making it one of the most widespread infections in recent times*.

-snip-

We saw similar turmoil when a large organization in South Africa was hit incredibly hard by this worm, and was struggling to resolve the resulting chaos, even with the assistance of their security software vendors. Thankfully, it all ended happily for them, as the issue was resolved, but it's plain to see where this could go wrong and affect many organizations similarly.

I did mention up front that I found this all to be comforting (granted, this may be a slightly twisted viewpoint, but it really is how I feel about it). The reason I find this comforting is that perhaps as a collective, we needed a fresh wake-up call. They say that complacency kills, and I know that many organizations have become rather complacent of late...

Consider how Conficker works and spreads - missing patches leading to RPC-based buffer overflows in the Microsoft Server Service, brute-force attacks on weak passwords, spreading through file shares...hold on...does this sound at all familiar? Aren't these issues all addressed by basic security best practices 1 oh 1?

Organizations that had adopted reasonably robust internal security measures - hardening and patching policies, internal security assessments, solid internal vulnerability and compliance management solutions - they would have smiled through the Conficker onslaught..

I don't only say this because we play squarely in the assessment and vulnerability management spaces - I say this because the same steps that would have protected against Code Red, Slammer, Blaster and friends, would have protected against Conficker... best practice 1 oh 1..

I guess every now and then, we all need a reminder of just how essential the basics that we all tend to overlook actually are :>

/nick