Reading up on OS internals

I was looking at the preview chapter from the upcoming Symbian Internals book. I was hoping that it would give some insight on some of the current generations(ver. 6,7) of the Symbian OS. The book is more of an Inside OS/2 for the upcoming realtime Symbian version 9.

The chapter covered platform security, mostly a high level description of application security. Some highlights:

• No Execute is used to make buffer overflows more difficult.
  
• Security is based on directory(hidden from user) rather than file
  
• Nothing is trusted on removable media; HW-like security
(integrity checking via hash stored in secured location)
• Capabilities(access rights, r/w system directory) granted to processes based on bits in the header of the binary.
  
• The key to all this is that the installation system is considered part of the trusted base system. A good decision as it is unlikely that somone would deliver malware in SIS packages. :)

The spread of Cabir has made one thing clear, it is that one should never understimate people's willingness to accept gifts.

Updated Dumpsis; Other SIS tools

I've added dumping of all available language variants. Previously only the file for the first language in the set was dumped. The first language is not necessarily the default, as that is determined by the user's system settings and not the developer's PKG file settings.

The language is appended to the filename for all but the first file. This is similar to what Sisunpack does with language variants, except with long language names(e.g. UK_English,Spanish). Interestingly, Sisunpack is written in the D programming language. One page of source code and portable to Linux with a recompile. Not bad; the Windows binary is 130K.

The key with the latest versions of Dumpsis is that most of the SIS file handling code has been moved into the Sisdump perl module. Import Sisdump.pm and you've got relatively easy perl-OO access to SIS files from your perl script or program. This is good for simple utilities and one off scripts. A good example is a little script that outputs the md5 hash for each file in the SIS. Saves time in analyzing files. Combine it with file extraction and a small known file database and you only deal with the previously unseen. Of course due to all the news about MD5 collisions, it might be a good thing to take a page from the integrity checkers(Tripwire,AIDE) and add SHA1 hashing as well.

I've got a version of that tool nearly done. More stuff to add to the SIS analysis toolkit.

Commwarrior worm

I've gotten a sample from the distributor's site. As yet, I have not run across a second version. From preliminary analysis it looks like the worm picked up the SIS writing trick from Cabir. The boot up trick is defective, but the run on install is correct.

Vallez, author of Cabir, originally decided against using MMS as Bluetooth involves no direct monetary charges. This worm's author must not want the worm to spread very far.

Cabir in the U.S.A., OMG! :)

There have been some really good fear-inducing stories in the news lately. Steve Litchfield has written the Symbian virus hype-busting article.

F-secure's blog has a good explanation of why Cabir in the U.S.A. is not really something to worry about -- mainly because Series 60 phones do not have much market penetration.

Sony-Ericsson UIQ interface phones do make up more of the market, due mainly to cingular wireless.

As of January of this year the source code for two different versions of Cabir have been released. It is surprising that no one has made the changes necessary to port Cabir to UIQ. A large number of Cabir variants are simply hex edited versions of the original. The new breed of cell phone virus writers either hasn't shown up for work yet or is just incredibly lazy and unskilled.

Trend Micro has apparently considered this as well as the potential size of the American cell phone market in making the decision to sell a UIQ version of their scanner. They are a bit early as no UIQ malware has yet been released.

Kaspersky entering Symbian AV Market?

Kaspersky Labs is apparently beta testing a new scanner for Series 60 phones. We can probably expect a product release before Summer.

The market is certainly getting crowded.

Locknut notes

The Locknut samples consist of 3 files, 2 RSC files and an app. The app is 6 bytes long, obviously an invalid size.

RSC files are not 'active' files. Data in RSC files are interpreted by individual apps, the OS just loads your buffers. One of the RSC files, the largest appears to be a plain text file.

Apparently the Appserver crashes when attempting to run the locknut app. Per other descriptions it appears that only Symbian version 7.0s and later are affected.

Attempting to load a 6 byte file that is too small to contain either a standard app header or even a rom exe header seems like a big oversight on the part of Symbian's developers. Considering that earlier versions are not affected, the question becomes what has changed in program loading with the arrival of version 7.0s. It occurred to me that perhaps it has something to do with the new compressed executable feature introduced in that same version.

The Symbian executable file format has been the same from ER5 through to version 6. This format is documented with symbian's release of the source code of petran. The new version, compressed executable modifies the header a bit to provide flags for compression and compression type. These are not yet publically documented.

The crash of the appserver could be attributed to buggy new code involved in handling compressed executables. It would be bad if this were the case, as similar to the recent J2Me vulnerabilities fixing the problem would require ROM replacements. Depending on number of units sold, this may be more feasible to prevent with software and prudence.

On Marcos Velasco

Mr. Velasco mentions on his security site that he has not gotten as much attention in the past two years for all of his security tools and research than he has received for writing a Cabir clone and SIS file infector. I agree that it is not very heartening to see your good works ill received.

AntiSpy clears out a number of interesting tracking keys in the Windows registry. The readme file included in the install package covers most of what you would need to know about these keys. The key being that they're recreated on reboot, necessitating a tool like antispy to remove them. For that purpose it beats a general purpose spyware scanner like Spybot.

MV RegClean identifies invalid registry entries like other registry cleaning tools on the market. Its interface is clean with straightforward options for scanning the registry as well as performing backups.

Regarding Cabir (H & I) , according to Mr. Velasco these are clones of Cabir developed by reverse engineering the original Cabir worm. For someone involved in the computer security industry writing viruses is a no-no.

Regarding innovation, Mr . Velasco's creation of a SIS file infector/dropper while not a completely new technique it is the first implementation of an archive infector on the Symbian OS. For this he certainly deserves credit.

All the same he has stepped over the line, if you are in the business of securing computers do not endanger them at the same time.

Original Cabir Source code released

29a has released the source to Cabir in its latest issue.

Interesting notes on the rationale behind choosing the distribution channel (Bluetooth , rather than MMS or email). Cost and providing warnings to the recipient are stated as some of the key reasons to use Bluetooth.

29a is releasing Cabir in source only without 'helpful' batch files to automate compilation. The recent attention from the authorithies might have something to do with that, although it is in line with their track record. The same can not be said of the author of the H and I variants.

Cabir Source Code?

Per their blog, Kaspersky has received a couple of Cabir variants with a threat from the author.
Something about having the source code and releasing more dangerous versions of Cabir.

As 29a has been getting attention from the authorities lately and with rumors about the arrest of some of its members, I doubt Vallez is the one making such a threat.

according to Kaspersky, the new variants have not managed as yet to disable the OS install warning.

I do not currently have samples of these variants.



-----
On a side note, McAfee has added a generic detection for Cabir as of the 22 of December.

Python for Series 60 released

The official Symbian Python distribution for the various Series 60 versions has been released.

I haven't installed the SDK yet, though I notice that there is a Bluetooth example in the package. From the readme it appears that aside from some console display and time issues most scripts should work fine.

Aside from Win32.remabl, I'm not yet aware of any python worms. The cost of entry for Symbian malware authors is now much lower.

Given the size of trojans like Skulls, I would not be surprised if the Python interpreter was installed on a large number of S60 phones by the middle of next year if not sooner. Never underestimate the lure of a free lunch.

More Cabir variants

A spate of minor Cabir variants has arisen in the past few weeks. Looks like it's up to G now.

Not really of much interest except that F-Secure now has a generic detection for Cabir. Considering that most "variants" are simply the Cabir worm with a few internal strings modified it is interesting that it has taken until now.

The size of detection databases has been a point of discussion on the Win32 side for some time. It is even more relevant with regard to the relatively limited resources of smartphones. As mentioned recently, types of detections can sometime be an indication of the limitations of a given scan engine. Six to seven independent detections for highly similar variants is a bit wasteful.

Unlike certain Win32 trojans and worms, the source code for Cabir has not been made available. Lacking source code but having a number of functional descriptions it is of note that no copycat/clones of Cabir have been released. The existing variants are minor "script kiddie" alterations. Essentially, the threat is minimal and could have been handled by a generic detection around the time of the C and D variants.