Symternals.com

Been a while since last post, new employer.

I mentioned a few months back about Job de Haas and ITSX's security research on Symbian. They've got a nice set of Python based tools for analyzing Symbian ROM images. The tools are available for download from their site Symternals.com.

From Symternals.com

"This site is dedicated to information about the internals of Symbian OS and its uses for security research."

If you have any interest in Symbian Security research, this site is one to keep an eye on. I have not contributed anything yet, still need to get up to speed with Python.

SISscan now up on Sourceforge

I've uploaded Sisscan to Sourceforge.

Sisscan scans one SIS file at a time. Identification is based on hash matching so coverage is traded for speed. The included hash files cover only up to Fontal, none of the recent trojans are currently included. It is relatively easy to add a new hash set and names for new malware.

SIScan is in CVS but the detection data files are not.

52 New Trojans arrive on the scene

Somebody has a lot of time on their hands.

This is the type of situation I had in mind which would require a tool like Sisscan. Apparently the set of 52 trojans consists of a number of previously known trojans(Fontal?) and a few new items.

Running a scan on a suspect SIS file would give you an indication of how much of the file consists of Cabir variants. :) It would also help in avoiding running some of them more troublesome malware. Your standard on-demand AV scanner does the same thing albeit with more flexible identification methods and a bit more overhead. AV firms tend to already have similar lightweight analysis tools in house.

An AV firm whose specialty is Symbian malware has reported having the samples as of Monday, it is now Thursday. This set of trojans has even slowed their pace. If the trend keeps up their might be more demand for 'Mobile Phone Virus Researchers'.

Sisscan, perl virus hash scanner

The scanner is essentially ready, the data is taking longer. I've got most samples except for Hobbes. Detections are compatible with ClamAV simple signatures(MD5). To speed up scans, I've added a stage that checks hashes for pure samples.

So far sisscan is useful for seeing which files to ignore in large collections like Skulls.

Sisscan should be up in the next few days.

Next step after that is graphing SIS files.

F-Secure is looking for a Mobile Phone virus researcher

F-secure is looking to add a Mobile Phone researcher to their team.

Symbian programming(Series 60 most relevant) and reverse engineering experience (not symbian specific, think) are necessary.

ARM assembly experience or any embedded(non x86) experience is a plus.

Virus writers are out, but HW hackers should fit right in.

Job info: http://www.f-secure.com/jobs/ click on 'Mobile phone virus researcher '

SISHash utility added to toolkit

I've added the SISHash utility to the Sis Analysis toolkit. It functions like md5sum over all files in a given SIS file.


Collect the signatures for known bad files and you've got yourelf a quick and dirty malware scanner. This is only useful for static malware, such as most trojans and some network worms.
An implementation, SISscan, will be added in a few days.

SISHash

* Accquire MD5 and SHA1 hashes of each file within the SIS file.

* Identify previously seen files.




Usage:

SIShash - Get Hashes from SIS File
Copyright 2005 Jimmy Shah All rights reserved.

Usage: SisHash.pl [-as] filename

Options:
-a Display both Md5 and SHA1 hashes.
-s Display only SHA1 hashes.

Default is MD5 only.

Command Line:

SisHash.pl -a Caribe.sis
Output:

988ff12b5f9819ce8a84a14245c2297f *caribe.rsc
75e1e12706649fa45c289c92f2f9775d2437c13f
12a0af974995c3d9428eb751e8da638b *flo.mdl
3cfdcecd905c509f319346db40c193821d77e3d8
05fbae15bb8a0042a7755e898d18c439 *caribe.app
49e753fe862c9a0ceb04f1984933e53017bec524


Mabir and Fontal

The past week has brought some new malware. A short time after the release of commwarrior, we've got a mass mms sending/Bluetooth worm . The bit where it sends its SIS file via MMS exploits the automatic running of install files under Symbian. If sent to any non-Symbian phone the result is simply the cost of the MMS message. I assumed from Vallez's notes on Cabir that he had decided against MMS as a transport mechanism in part because there is no way to tell if the recipient can run the worm. On Win32 , due to market penetration , it is very likely that addresses in the address book belong to other Win32 machines. Symbian phones do not currently have a similar market distribution.

--

Font files that prevent warm rebooting. Troublesome. It used to be common for people with Psion handhelds to backup their data in case of dead or dying batteries. Restoring from a backup after a cold boot was a rare but occasionally necessary part of maintenance. Users doing the same today with Symbian smartphones is more than we can expect. Few users would know how or even if they have all the right equipment(cables, I/R port, mmc reader). Malware that kills its host doesn't travel very far.

Blackhat Europe 2005, Symbian security

I recently noticed the presentation of Job de Haas of ITSX. It's not likely that I'll be attending any Black Hat conferences outside of the country so I wouldn't have been able to see it live.

The presentation mentions a Python toolkit for handling ROM images. If it gets released publicly I might not get around to writing a ROM file dumper.

Currently, I believe IDA is the only other software that handles Symbian ROM files. The python toolkit apparently allows one to browse the rom image, file to file.

The presentation also mentions acquiring the ordinals for the functions in the ARM binaries by converting from the emulator binaries while debugging with symbols. Nope, I misread that. It appears to state retrieving the ordinals from the Libs, a reference to the import libraries in the SDK. Makefn does something similar. The output from the nm in the Symbian SDK can also be used with suitable polishing. Using the emulator binaries with debug symbols is good for exploring the OS itself, but not as useful with analyzing ROM format malware. The python toolkit's browising capability provides the necessary ROM context in this case.

Good pointers on the Symbian 7.0 base porting guide. The guide includes the ROM formats with hex offsets. Clearer than the header files.

DumpSIS updated, moved to Sourceforge

DumpSIS handles multilanguage SIS files with option blocks.

DumpSIS is now avilable as part of the SIS Analysis Toolkit project on Sourceforge. Current working source code is available through CVS.

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.