http://securityresponse.symantec.com/avcenter/venc/data/epoc.cabir.html
Series 60 Worm!
Hey,
Blimey! Now that is a first. Well done for finding it.
There has always been talk of virus's for series 60 phones but that is the first one I've seen.
Ian
Everyone take a deep breath. This is a program that sends itself to a Bluetooth device in the area - so the owner needs to go through the installation process before it can carry on - I'm not sure theres a way to auto install on reciept.
Rule one, keep your bluetooth switched off if you don;t tneed ti
Rule two, a lot of virus vendors would love to get $10 per busoiness phone per company, so take the overblown exaggerations in themedia with a pinch of salt.
"proof-of-concept" don't stress too much, but..
Requiring authentication is one of the best first steps you can take here. There may not be per se auto-installation using the default installers (profiles for all diifferent version IIRC 1,1.1,1.2,2 or something like that) are listed in you phone, BUT most third party applications are tagged to the message application with recogs.
EX: (low threat)
1) You receive a 3gp file in your inbox, it looks like a message (bluetooth or not), you open it as multimedia, Real or Helix or whatever open and execute the code.
-here you need an exploit for Real or Helix
EX: (higher threat)
2) You receive what looks like a mobipocket encrypted book. This causes mobireader to launch instead of services and automatically copy the file to your library. The next time you run anything that scans your library it may launch the file or show it as a type launchable by whatever is tagged to your gallery applications
3) You receive anything with recogs turned on for readM, it launches and starts to read the file (book, whatever) it will unzip gz files and display them as text, BUT if it scans your inbox by default you can launch it without ever opening a message and it will open the files in your inbox. This is by far the higher risk.
Steps to protect yourself:
1) don't run sis files that you don't receive from traceable and known vendors.
2) require authentication for most connections to your phone.
3) turn off inbox scanning for any application which supports it by default.
4) search for and delete the named files if you have them
: 15104 (caribe.sis), 11944 (caribe.app), 11498 (flo.mdl), 44 (caribe.rsc)
-you never know when these things get released into the wild
I'm not sure how the automatic transfer to the "APPS" directory occurs, I know an application can be hidden and placed in the installers folder to be used later, but I agree that we shouldn't be paying for antivirus software for this. It's a worm that utilizes an exploit in the operating system, which can and should be closed by Nokia/Symbian.
All it requires is a patch that requires you to authorize 'helper' applications to open a message. It's always bothered me that I click a message and the phone starts running through whatever it wants w/o my input.
:icon13:
JasonT wrote:"proof-of-concept" don't stress too much, but..3) You receive anything with recogs turned on for readM, it launches and starts to read the file (book, whatever) it will unzip gz files and display them as text, BUT if it scans your inbox by default you can launch it without ever opening a message and it will open the files in your inbox. This is by far the higher risk.
Do not try to scare little girls here: any third-party software that scans inbox for compatible file types does not _launch_ them, but _open_ them. So this software must _cooperate_ with a virus to activate it...
gggg wrote:Do not try to scare little girls here: any third-party software that scans inbox for compatible file types does not _launch_ them, but _open_ them. So this software must _cooperate_ with a virus to activate it...
:rofl: I scare them when they see me why would I need to try that here 😉 Yeah I was thinking open, not launch, but it's still going to gunzip it, which is either running it's own gzip utility or an inbuilt one (that's just the .gz files) so it's still a different vulnerability because in that instance it could be using a system decoder or what looks like one instead of its own, which also means that it could gunzip a package w/ a text file and a little payload that is then automatically transfered to your library folder or temp folder or wherever, but is released from the inbox binding (although the authors were probably smarter than that).
Besides, the point is more social engineering than the software. It's often the user cooperating which causes the problem, but the way messaging is to user friendly and 'transparent' is how more exploits will occur. :secruity: