There has been a bit of chatter today about the first ever Mac-based botnet. This piece of malware actually appeared back in January of this year.

Quite frankly there is not any functionality in this “bot” (some would simply call it a remote access trojan but let’s not split hairs OK!!) that we have not seen before. The only thing of concern here is that it does affect the Mac platform which certainly is fresh territory.

As we had discussed in our previous blog, it is spread through pirated software at this point (a huge No, No anyway) so hopefully distribution will be light and not result in a large numbers. It definitely does highlight the need for security software regardless of platform!

It’s been a week since we’ve seen the new Mac malware, the iWork09 Trojan, which is disguised as pirated software. Since then there have been several reports about new Mac Trojans.

Before this we saw mostly lame malware for Mac OSX, but the iWork09 Trojan represents a new element to Mac Trojans — sophistication. This one contains peer to peer-like characteristics and even encrypts its traffic. It has also been associated with some recent distributed denial-of-service attacks.

One thing to remember when dealing with pirated software is that you might have a high price to pay, in this case ending up a Trojan that turns your computer into a zombie. We have seen this happen for years with Microsoft products and even with AV products. (If you search for “McAfee” on torrents sites, you will find a lot with serial numbers; but you won’t know whether the thing is a Trojan version.) Now this unfortunate trend has arrived on the Mac platform, with several reports of Trojan versions of pirated Mac applications.

Take care — you often get what you pay for.

The Apple iPhone is vulnerable to a new bug related to the signing of iPhone applications.  Applications that are created with the official iPhone SDK need to be cryptographically signed by the author and Apple before they’re allowed into the App store or installed on an iPhone.  The digital signing is a security measure that serves two purposes; helping to identify the developer in case of any problems and making sure that an approved application hasn’t been modified.

An iPhone developer discovered the bug while looking for a way to duplicate a feature of Apple created iPhone applications: dynamic default.png files.  The default.png file is displayed when an iPhone application is launched and can be used as a static splashscreen.  When you quit an Apple created application, it takes a snapshot of the screen when you quit and saves it as default.png within itself.  The next time you start the app it loads the new default.png, and everything looks like it was when it was last run. The application hasn’t fully loaded yet, but the saved default.png trick makes it look that way.

Unlike Apple’s apps, those created by other developers can’t modify their default.png files. Since the default.png is stored within the application as a part of itself, it gets digitally signed.  Modifying the image file and thus the app, makes the digital signature invalid.  An alternative would be to use a default.png in the application’s data directory, but only the file within the application is supported on the iPhone.

The method to replicate Apple’s default.png trick involves a defect in the codesign utility in the iPhone SDK.  codesign is the utility used by developers when they digitally sign their applications.  Normally codesign will take every file within an iPhone application into account when it creates the digital signature.  the problem with codesign is that it doesn’t handle symbolic links (symlinks) properly.

Symlinks are like shortcuts to files; if you want to refer to one file in two locations or with two different names you can create a symlink in the new location.  The symlink isn’t a new file copy, just a pointer to the original file.  codesign doesn’t follow the pointer to the original file, so it doesn’t consider that file during signing.  The new approach is to create a symlink named default.png that points to a location or file outside of the application that can be easily modified.

This is a neat trick, but harmless.  If it were only the codesign utility that has this symlink problem, then the technique would not work for an installed application.  The real trouble arises when symlinks are used to obscure other program files or components during signing.  The digital signature process was intended to ensure that no unapproved or unsafe modifications could occur.  An attacker could arrange for malicious components to be installed using a self-update feature.  Since the digital signature ignores symlinks, the malicious application could contain pointers to the yet to be downloaded parts.  Since the bad portions of the program don’t exist during the approval process, malicious applications can sneak through.  This effectively bypasses the iPhone OS’s protection against the running of malicious code.

Fortunately, since the application is signed, tracking down the author of such malware should be considerably easier.  Given that the vulnerability lies within a utility in the iPhone SDK and within the iPhone OS’s verification system, it should be fixed shortly in a future update.

The iPhone has generated a lot of curiosity in the hacker community. Last year when Apple released its iPhone, hundreds of hackers tried to break the iPhone software in multiple ways. Some of them succeeded in customizing the iPhone in the way they wanted. They changed their mobile service provider and deployed their own applications. Some hackers were able to break the iPhone by exploiting vulnerabilities in applications such as Safari.

Now Apple has released its official SDK to developers. By opening up the iPhone OS and publishing the SDK Apple looks forward to thousands of Mac developers developing iPhone applications. At the same time, Apple announced a lot of new features for enterprise customers.

It appears that Apple is carefully stepping forward to analyze and manage the security implications of opening up its platform for development. In the Leopard OS release Apple added security features such as sandboxing, code signing, etc. The same features are also used as the foundation for iPhone.

Let’s look at some of the security aspects of the iPhone’s application execution environment: Apple issues a certificate to the developer, who signs the iPhone application using this certificate. The iPhone OS then checks the authenticity and integrity of the application before installing and executing it. Each application runs in a sandboxed environment–with very limited access to the file system and other resources. The AppStore application on iPhone manages all third-party application deployments on the iPhone.

One application can interact with other applications using URLs. http://, https://, and feed:// are handled by Safari; mailto:// is handled by the Mail client; and itms:// is handled by iTunes. Third-party applications can declare their own urls (such as myapp://) to handle messages from other apps.

Each application is sandboxed to contain failures if it is compromised. However, an application’s access to a lot of other resources–such as network, phone, camera, address book, mail, and urls–is not controlled. Hackers may now focus on vulnerabilities in applications and also on the mechanisms provided to access iPhone resources.

Enterprise features such as Exchange Server support, and security features such as Cisco IPSec VPN, WPA2/802.1, etc. may encourage wider deployment of the iPhone in enterprises; and thus open up more possibilities for attackers.

Within four days of Apple’s announcement, more than 100,000 SDK downloads indicate the enthusiasm of developers. Sun has announced Java support for the iPhone, and that may attract even more developers.

For now the SDK is still in beta, which gives Apple some time to fix security issues that hackers are going to discover during the next few months. This seems to be a very good strategy. We look forward to Apple’s next steps and the impact they will make on the domain of mobile device security.

Unlocking your iPhone so that you can install third party applications can be fun. Using the Installer.app application on the iPhone and its default repository you can install utilities, games, and other applications. By adding additional repositories to the Installer, it is possible to gain access to a much greater quantity of software.

Occasionally, if you’re not careful you can end up installing malicious software from a bad repository. This happened to a number of iPhone owners a few days ago.

An application calling itself “iPhone firmware 1.1.3 prep” claims to be a tool to prepare your iPhone for the upcoming iPhone update. It actually installs another separate legitimate utility. The damage occurs if you already had the utility installed and you want to remove the false firmware update “prep” tool. Uninstalling the fake tool just uninstalls the real utilities.

Information from the STE Packaging repository site and its owner details how the “prep” tool functions and how it was distributed. Users who added the jmwiki.com repository site to Installer.app were offered the “prep” tool and two other similar packages. It was determined that the malicious repository and applications were created by an 11 year old. The child’s parents were informed and the repository was taken down.

Phone modification (changing the OS, reflashing, unlocking, etc.) can sometimes be dangerous. While corrupting a firmware upgrade for a mobile device might be possible, it is not surprising that someone has created much simpler malicious installation files. On the Symbian platform we have seen quite a few malware, such as SymbOS/Skulls and SymbOS/Appdisabler, that disable or overwrite legitimate applications upon installation.

Users can avoid such problems by:

• Acquiring software only from trusted sources
• Installing only official firmware updates

Websites delivering malicious payload either in the form of web exploits or plain old executables masquerading as multimedia or legit applications is not uncommon. In the past year, we must have blogged a dozen times how the popularity of Internet audio and video has turned them into a malware wonderland – from movie infecting worms to dodgy codec installers, yes even on MacOS; and most recently, Puper trojans capitalizing on the Bhutto assassination video. From widespread infection that hit the headlines the next day, to stealthy backdoors and password stealers aimed to stay quiet and reside in your computer for as long as possible.

McAfee’s SiteAdvisor^TM technology performs behavioral analysis looking for suspicious activities in code that resides within the inter-twined nests of exploited sites. Be it rogue administrators or compromised servers, such sites might certainly host safe downloads, but they are far more likely to host something malicious than your average site.

Just before Christmas 2007, when our crawlers detected dodgy behavior that was attributed to a site linked to a nest of exploits, our system quickly escalated it for human review. It turned out to be a variant of W32/Kibik, a stealthy limited parasitic virus that targets only specific files and stays low under most radar. The website tricks the user into downloading a fake media codec, now detected as W32/Kibik.b.

Figure 1. Instruction to download fake media codec

Like its big brother, the new variant is hard to detect as it infects Winlogon.exe by quietly planting the virus in an unused null-ed out segment of the file, and unlike most viruses, does not change the size of the file. It also does not leave a trace in the Windows registry or modifies other files in the computer, but starts each time the system starts up.

W32/Kibik.b retrieves commands from the server hosted at swf1.flashxyx.com. This domain appears to be hosting free games for download, but is (ab)used as a command and control server for W32/Kibik.b.

On each startup, the following several actions are performed once:
1) A network connection is made to swf1.flashxyx.com.
2) At the time of our investigation, the host was active but not delivering any files, but our static analysis shows it can and will download and execute additional files:

Figure 2. Download and execute code in DLL

It goes on to poll the website in 5-minute intervals to retrieve further commands from the controller.

As its actions are relatively low-noise, and was active during the holiday season, few security vendors have detected W32/Kibik.b, as was its older variant.

More details of W32/Kibik.b are available.

A self-proclaimed Mac user is targeting Mac fan blogs. He has already defaced 2 famous Mac related blogs.

http://www.applematters.com/

http://iphonematters.com/

In his own words ” I’M A MAC USER. I JUST HAVE A STRONG DISTASTE FOR MAC SYCOPHANTS.”

This is possibly the first time a hacker is targeting Mac related websites. This is interesting month for the Mac user base, with multiple Trojans/malware appearing along with a horde of security updates from Apple itself.

Things are definitely heating up in Mac Land!

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Update Nov 28th <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Seems that this defacement may in fact be a hoax:

http://www.applematters.com/index.php/section/comments/sincere-apologies/

http://www.applematters.com/index.php/section/comments/a-bad-pr-stunt/

http://www.glennwolsey.com/2007/11/28/what-really-happened-sincere-apologies/

Pretty odd any way you look at it. Also after a bit more digging we came across another Apple defacement (there are a few more with some Googling):

http://networks.silicon.com/webwatch/0,39024667,39158606,00.htm?r=1

I just read another story that talks about the overreaction to the new Mac OS Trojan, the threat first reported by Intego the other day. Generally the arguments make these points:

• There are far fewer threats for Mac OS compared with Windows
  [my response: True, but it takes only one to get infected.]

• You’re at risk only if you’re surfing porn
  [my response: False. Although the initial report stated porn sites were driving people to the malware, McAfee Avert Labs has found dozens of domains serving the malware, none of which was explicitly related to pornography. They are related to installing a video codec for the purpose of viewing movies in general.]

• A user must take extraordinary actions to get infected: download a file, open it, run the installer, enter in the admin password
  [my response: Yeah, so? Bagle was one of the most successful pieces of malware targeting Windows users. Many variants came as a password-protected ZIP archive attached to an e-mail message. The password was sent as an image attached to the message. Before getting infected, a user would have to open the suspicious email message, open the suspicious ZIP attachment, manually enter the password provided in the other email attachment, and then run the virus. Result: many many thousands of users getting infected. Password-protected archives are an anomaly for most users, on Mac or Windows. I contend that the social engineering around installing a software package to watch a video is greater than that of having to enter a password provided in an email message simply to access what's supposed to be a photo.]

Having said all this, these points are not what make this threat significant. What sets this threat apart from other proof-of-concept Mac threats and low-scale attacks is the entity behind it. Puper (a.k.a. Zlob) is one of the most widely reported pieces of malware for Windows. McAfee VirusScan Online users reported more than 4 million detections during the past two years. Microsoft’s latest security threat report states Zlob was the most frequently disinfected piece of malware. Unlike earlier Windows malware, this Mac Trojan is authored by professionals who likely pull in thousands of dollars a month through click fraud, hijacked affiliate sales, and other illegal activity.

I have to admit that when I first heard rumors of some new Mac Trojan being reported from a vendor I hadn’t heard of, I figured it was likely hype. But when I learned who was behind the threat, I knew this was real.

Now after all of this doom and gloom, I should say that we were able to contact two universities that have rather large Mac user bases to see if they showed traces of infected systems. Thus far their log files show no sign of infection. Thus far.

It took a long time for the Windows threat landscape to evolve to where it is now. Yes, the Mac threat landscape is far behind and will be for a long time, but what OSX/Puper represents is not something to take lightly.

Apple’s shiny new cat is out and it’s not just pretty, but also features some good security enhancements seen for the first time in the Mac OS.

One of the key security features of the Leopard OS is Sandboxing. Sandboxing restricts the sandboxed application to be only able to perform actions or access resources based on whatever they are supposed to do. For example a sandboxed application will only be allowed access to certain files or be restricted to whether they can access the network or not.

By default, however, only a few Leopard applications are sandboxed, like the Helper applications which is used for enabling Spotlight or Bonjour. Surprisingly applications like iChat and the Safari browser, which are generally the first target of attackers, are not sandboxed. Apple, however, might have plans to add them in a future Leopard 10.5.x update.

Lack of API documentation for third-party developers to sandbox their own applications limits the usefulness of this feature right now. However, this may get resolved in the near future as well.

Overall, it’s a big step in the right direction.

On the heals of Allysa’s Crimeware comes to OS X post, I thought it’d be a good time to revisit some earlier research on DNS changing trojans; in particular trojans authored by the same group behind this Mac malware.

A quick overview on how DNS (Domain Name System) works.  When your computer wants to navigate to a domain on the Web, it needs to translate that domain name to a number.  It may first check a local cache, or hosts file, but the next step is to query your machine’s specified DNS server.  That looks something like this:

Request: Hey SERVER, how do I get to domain.com
Response: Hey CLIENT, go here - 123.123.12.3

DNS changer trojans reconfigure your system’s specified SERVER such that your requests go through a server controlled by the attackers.

Request: Hey BAD_SERVER, how do I get to domain.com
Response: Hey CLIENT, go here - 111.222.3.4

Now the expectation is that the attackers who control the rogue DNS server would redirect requests to popular financial sites and other heavily phished sites.  Like ebay, Paypal, banks, etc.  Well, I ran a few thousand requests through rogue DNS servers; focusing on the top websites.  To my surprise only 1 domain was resolving to the wrong address.

adultfriendfinder.com

Adult FriendFinder (and associated FriendFinder.com, which is also rerouted) claims to have the largest affiliate program on the net, with over 150 million registered users.  They pay out for account creations, membership orders, and affiliate referals.  But this statement on FriendFinder’s affiliate page seems more relevant:

Testing a few thousands domain out of millions on the web barely scratches the surface, but this does highlight that top tier, typically phished, sites are not the target by the authors.  Targeting what I call secondardy targets (instead of say financial institutions) is a growing trend.  In general, there is less risk of being prosecuted.

It’s worth mentioning that other behavior was observed by these trojans.  Typically they install a rootkit (such as DNSChanger.f), which redirects search results.  Other domains can get redirected by the rootkit (irrespective of DNS).  Also, non-existed domains (think typo-squatting) may get redirected to domain landing pages by the rootkit or DNS.  While I missed the conference, I just noticed that further research on this topic was presented at Virus Bulletin last month.

There has been a family of malware called Puper which has been plaguing Windows users in increasing numbers since 2005. It’s a nasty beast which has been in the news quite a bit lately for its nefarious installation tactics. Most notably it’s been found to install itself by way of exploits on infected MySpace pages.

Suddenly Puper has its eye on Macs.

What happens is this: Say you’re out searching for a bit of porn with your blissfully malware-free Mac. You’re led to a site which says you need to install a new codec to view the videos they offer. You try to install this codec, but instead you get a nasty and silent surprise. After all that, you still get no videos.

When the newest Puper fake codec site is accessed by a Mac, the file which is offered is a DMG file rather than the usual EXE file one would see on Windows. Depending on your browser settings, this may run automatically. Once it runs, it begins installing an application called “MacCodec”.

The authors behind some of the most wide-spread PC malware (Puper, aka Zlob) have released a Mac version; authors who have experience distributing malware to the masses. This is no PoC. This is not a drill.

Dozens of fake codec sites are serving the malicious disk image file to Mac web browsers (based on the user-agent):

In the background, a script is created which then creates a scheduled task to change the DNS to point to a malicious server. In effect, instead of getting valid entries for websites like you would expect, you’re now getting whatever this malicious site decides to point you to. That could be a phishing site, that could be more malicious files, you can no longer trust that the URL you expected to get will be what is delivered to you.

Again, Avert Labs has identified dozens of different fake codec sites currently serving this Mac malware.

People have been predicting that as soon as financially motivated malware came to the Mac neighborhood, its denizens could no longer be so smug about security issues. This is a very simple piece of malware, and yet it works. Time will tell if this family will wreak as much havoc as it has on Windows.

Today Apple announced the planned release of an SDK in February to allow the development of native third-party Applications on the iPhone. This seems like a logic step after various hacks that allow installation of unauthorized third-party applications, but reading the announcement closely, there is something groundbreaking:

“It will take until February to release an SDK because we’re trying to do two diametrically opposed things at once—provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks, etc.”

In the initial design phase of the SDK security is specifically mentioned as a major aspect for it’s development! This is certainly a great step into the right direction and if everyone would look at security aspects and not just features during development, the electronic world may be a much safer place then it is now.

Also in openly acknowledging that malware for mobile phones is an issue and will become a bigger one with more sophisticated mobile phones, Jobs takes the right step in making the public aware of a problem and taking steps against it, unlike many other who’d rather play it down.

I applaude this move and will heavily recommend this as an example for others to follow.

It seems the days of mobile phone functions have expanded greatly over the years. Phone nowadays can be organizers, email clients, web browsers or music players. The popularity of such devices means that the phone is slowly replacing some of the functions of a computer. In fact, one particular feature that I would like to talk about is the ability to completely customize your phone to have a whole new operating system loaded. In fact, each Windows mobile phone comes with a license for the Windows mobile operating system.

Let’s look into how phones (hardware) are married to the operating system. The process for installing a phone vendor will distribute an operating system for a particular phone model. Once you download the new operating system (usually in a ROM format), you simply flash the ROM file to your phone. The process is fairly straight forward for most people and the end result is the phone now has a fresh new operating system.

Putting aside the legal issues of licensing these operating systems for a moment, there is a trend for phone enthusiasts to install an un-official ROM or a cooked ROM. These ROMs are usually full operating systems that have been heavily customized for performance or functionality gains. Similar to Web 2.0, the content of these ROMs are no longer driven by the provider, but by individual enthusiasts. What’s the concern? Well, like we have seen with the MySpace worms, a ROM author may add an application into the standard ROM which will be automatically installed. Generically, the ROM authors usually post their ROMs online for sharing with other users who may not be as technically savvy and simply lets the application install without ensuring it is safe or not. Now imagine if that program was a BackDoor trojan that attempts to steal the personal information from the phone then sends it to a remote server. Worse yet, the Trojan also has a worm component that spreads itself via SMS, MMS and Bluetooth. Now the malware is spreading itself even further to the victim’s contact lists or other close by phones.

So can this happen? Well, yes it can. Take for instance the wildly popular Apple iPhone’s root password that was cracked within 3 days. Right after that, many of those iPhone users ventured to use their new found freedom but they forgot to do one thing…. close the backdoor on their phone by changing the password on it. Avert Labs has recently blogged about this in the Apply iPhone blog by Marius Van Oers (http://www.avertlabs.com/research/blog/index.php/2007/07/24/apple-iphone/). But the question to ask is Why mobile malware is not as prevalent as Windows malware? The simple answer is that most mobile phones are not used for monetary transactions (yet). Once you introduce a money factor into these phones as a mainstream function, then you can bet that someone will write malicious code to capitalize on their unknowing victims.

On July 31st Apple released the iPhone patch 1.0.1. The next day, Charles Miller released details of a vulnerability that was included in the patch release. The vulnerability was in an open source application on the iPhone, the PCRE (Perl Regular Expression Library) parser used by the JavaScript engine in Safari. Even though Miller found the exploit via fuzzing, he made a really interesting point which can lead to attackers finding easy 0-day exploits for the iPhone: the iPhone is running outdated open source applications. In this case, it was PCRE 6.2 with the latest version being 7.2. Just by simply looking at the changelog you can see that PCRE version 6.7 documented the vulnerability that was used,

18. A valid (though odd) pattern that looked like a POSIX character class but used an invalid character after [ (for example [[,abc,]]) caused pcre_compile() to give the error “Failed: internal error: code overflow” or in some cases to crash with a glibc free() error. This could even happen if the pattern terminated after [[ but there just happened to be a sequence of letters, a binary zero, and a closing ] in the memory that followed.

As more layers are uncovered with the iPhone and the Mac OS X underneath expect more 0-day exploits using the simple technique of open source version diffing. Also, hopefully, Apple will learn from this experience and keep the open source components up to date.

The Apple iPhone was released in the USA on 29 June 2007. Running a stripped down version of OSX makes it very powerful but might also opens the door for malware exploits.

There’s no SDK – Software Development Kit to create native applications on the iPhone device itself, instead Apple seems to want Safari based applications. Developers need to create applications for the iPhone via Web 2.0-based technologies such as Ajax to run on the Safari browser. Web 2.0 applications can access the iPhone to make phone calls and send e-mails. This also might be exploited/abused by malware.

On the other side, the inability to change native Operating System files would make malware creation less tempting. It also means that AV vendors don’t have easy access to direct low level OS system hooks to quickly create and change programs such as on-access scanners etc. Apple decided to launch exclusively with AT&T and at the moment it is not possible to use any other arbitrary simcard with the iPhone. Not many people want to be bound to that contract so there are many projects going on to get around that. Result is that many people are using hacks to activate it. So the iPhone will not be able to make use of your own sim-card and just may be a very expensive iPod! But if people succeed in cracking it then even more people will think about using that crack. Needless to say that this is a huge security risk also. So the exclusive right deals might have a negative impact on security.

While Apple can control content that’s posted on it’s own iTunes website,
it can’t do much with say podcasts with weblinks to adware/malware websites that
are posted to arbitrary websites such as YouTube. Since the Apple iPhone will support
YouTube videos the chance that podcasts/video’s with clickable questionable/malicious weblinks may appear is certainly not zero. The Apple iPhone can access YouTube’s content by using the WiFi or EDGE (using AT&T) connections.

Merely a week after it’s official release on 29 june, on 3 july 2007 the first bugs were discovered. Abusing a Safari web-browser exploit it might be possible to retrieve someone else’s voicemail due to the “easiness” with which one can spoof the caller id of the provider AT&T/Cingular. At the time of this writing, it did not even ask for a password. The iPhone’s root password can also be cracked, the continual bane of passwords overall.

On 23 July 2007 an exploit was discovered which could lead to attackers taking over an iPhone if an malicious website is visited. The malicious website would publish some exploit code to the iPhone which would result in the attackers being in full control over all of the iPhone’s functionality; transmitting files, making phone calls etc. Read those full stories below:

http://www.exploitingiphone.com/
http://www.securityevaluators.com/iphone/

It is to be hoped that such exploits remain proof of concept, allowing the hardware/software vendors to come up with fixes, and that such exploits are not put online/available to the public.

If you visit today the Infosecsellout blog, you will see a blog entry announcing a new Apple Mac OS X vulnerability and a link to the SecurityFocus web site.

There is no detail, but the title suggests that a Mac worm could be created by using that vulnerability. Also there is no mention of the author.

As we were researching this announcement we soon discovered that more accurate and interesting information was originally posted–but rapidly removed–on that blog. If you visited it on Sunday, you were able to read a note from the man who claims to be the worm author. His motivations were clearly visible: “I wrote this for my own purposes and it will be demonstrated to those who asked me to engage in this work. Yes, I am being compensated for this”.

In this blog entry, the possible author gives some details about its proof of concept, which could be easily changed to be more malicious.

He said his code uses a non patched variation of the MDNSResponder vulnerability recently fixed by Apple. According to this guy, the worm gives remote root access, compromises its first system, places a text file on the desktop and moves on to attempting to compromise other systems on the same network.

This story prove both things: the first is that Macintosh with Intel is an interesting target. Real outbreaks are more than ever possible. The second is that the lure of money motivates many people more or less scrupulous. It is another cause for concern.

Just in time for the release of the hottest gadget of 2007, the scammers are up to their old tricks again. In fact, if you use a search engine to try to find a deal on an Apple iPhone, be prepared for scam sites galore.

For example, search for keyword: iphone and check out the advertisers. Two of them allowed spammy e-mail to get sent our McAfee SiteAdvisor service. And not just a little. Our inbox averaged 66 e-mails a week after signing up with easyfreecellphones.com. But our sign-up at giveawaycafe.com resulted in a stunning 511 e-mails per week!

http://www.siteadvisor.com/sites/easyfreecellphones.com

http://www.siteadvisor.com/sites/giveawaycafe.com

The same kinds of sites result from keywords: apple iphone:

http://www.siteadvisor.com/sites/consumerresearchcorporation.com

http://www.siteadvisor.com/sites/giveawaycafe.com

And keywords: free iphone:

http://www.siteadvisor.com/sites/unclaimedfree.org

http://www.siteadvisor.com/sites/consumerresearchcorporation.com

http://www.siteadvisor.com/sites/easyfreecellphones.com

Who Wins? Who Loses? And does anyone actually get an iphone?

McAfee analysis shows that that these sites are experts at bait and switch tactics. They seem to promise a free product, typically whatever is hot at the moment – this summer that means the Apple iPhone. The sites make it seem incredibly easy to win the free merchandise. Just provide your e-mail, your mailing address and fill out an “offer” and you could have the hottest, most revolutionary gadget to hit the market! In reality, almost no one receives the promised “freebie.” These sites require consumers to start and complete three, four or even five “sponsor offers” to qualify. The offers -which require the consumer to apply for a credit card, start a student loan consolidation, or subscribe to a monthly music service– are real and often come from well known brands like eBay, Netflix, and BMG Music Club.

But few consumers are ever able to successfully complete all the requirements to actually get the free prize. Some sites even require the consumer to recruit 5 friends to complete offers. Industry insiders call it “breakage” – this inability to jump through all the many hoops – and they take pride in their ability to break 95% or more of the consumers who try.

PC World looked at this topic and helped us all understand the winners and losers.

Who loses?

• The consumer who has spammy e-mail in his inbox, a bunch of expensive subscriptions and NO IPHONE!
• The legitimate brands which get tarnished by associating with con games like these.

Who wins?

• The bait and switch “breakage” sites that walk away with big referral fees from spam advertisers and name-brand sponsors.

Today we know of over 236,000 malicious malware items. These are mostly meant for the MS-Windows environment. Only about 700 are meant for the various Unix/Linux distributions. Current known Mac OSX malware count is even less with 7, so pretty much non-existent at the moment. For older builds of the MacOS there are 69 known malicious items, with an additional 8 items for MacHC that used hypercard script extensions which had to be manually installed as an addon package.

Malware writers tend to write for systems that are the mostly widely used. With Microsoft Windows being dominant in the desktop market it is clear why the most malware is written for it. Also, prior to Vista, the various Windows versions were pretty much wide open, full access, making it relatively easy for malware to abuse.

The number of *nix malware might not be that big, but if we consider that a large number of E-mail and File servers actually run *nix versions, then the impact of successful *nix malware might be bigger then initially expected. The problem with *nix malware is that there are a lot of different flavors/distributions and kernel versions. ELF binary malware is highly susceptible to these variations and most times will fail to even run properly, resulting in segmentation faults etc. Many malware packages actually come with a set of scripts and have the viral source code in source files like .c embedded in the package and can perform local recompiles, with say gcc, as to enhance the chance of binaries running fine. Such packages are easy to spot but not so very successful when executed.

In fact there are open source implementations of .NET like the mono project. With that, the distribution/flavor/kernel version dependency is pretty much gone. But so far projects like mono have not integrated fully into popular distributions like Suse or Redhat. In fact there also exists support for the SunOS and Macintosh, so in the future this could be mis-used for malware.

Nowadays malware writers do not go for massive attacks but tend to focus on targeted attacks. This is more worrisome then the poor malicious demonstrators that the OSX threats of Leap and Macarena really represent. Nevertheless it is clear that OSX malware is not taking off yet. With an estimated OSX marketshare of about 5 % on the desktop systems one would expect to see more malware for OSX.

OSX is originally based on BSD. One shouldn’t run by default with root access so adding/modifying system binaries should, in theory, not be that easy to achieve. Nevertheless *nix rootkits do also exist, so a perfect guarantee can’t be given.

Also, on OSX systems, the source code is available for many components. This can make it easier for malware authors to write malicious code/exploits.

It’s hard to predict if the number of malware for OSX will remain very low or if it will increase significantly - so stay tuned!!