Recently there have been several reports of security flaws in a product provided by a company called Mobile Spy. The product is an application for Windows Mobile smartphones. The application logs various forms of communication data transmitted to and from the phone and sends it to a hosted database. A user can log in to the web service and view all the data that has been logged.
The idea behind this product is that it’s installed on a device without the knowledge of that device’s user (for example, an employee, child, spouse, etc.). The party who installed it can then monitor the user’s activity to ensure that the device is not being abused. A company manager, for example, can make sure that an employee is not making personal calls or sending personal text messages from a company device.
For the most part, this seems like a reasonable idea, but the security flaws in both the...
I was interested in getting some rough numbers on publicly disclosed vulnerabilities in Symbian and Windows CE/Mobile platforms and applications. I cannot say with any degree of confidence that what I present below is reflective, simply due to the fact that different bugs get categorized under different vendors, platforms, or keywords. What I can document is the method I used to arrive at the below numbers. I used cve.mitre.org and did the following:
• searched by vendor, platform for Windows Mobile & Windows CE • searched for keyword MMS picking out those relevant • searched for keyword SMS picking out those relevant • searched for keyword Symbian • searched for keyword Nokia picking out those relevant
So the summary is that there are 16 for Windows CE/Mobile and six for Symbian. I guess this demonstrates people are finding vulnerabilities in these two platforms. If we take out the third party applications on Windows CE/...
All of the recent rumors about Google releasing a "gPhone" were finally put to rest with their release of Android, which is a software stack for mobile devices. Android includes an operating system (Linux), middleware, and some default applications like a browser.
(Click for larger image)
Applications are developed using Java and use a framework provided by Google including their own virtual machine (Dalvik virtual machine). The entire framework is open source and Google (as part of the Open Handset Alliance) wants to bring openness to the mobile ecosystem, allowing anyone to write applications and make use of all of the functionality available on handsets.
Well, we’ve arrived at where we’ve been trying to get to for some time. That is to say that we now have the ability to release security advisories for Windows CE & Windows Mobile after working through the accepted responsible disclosure process with Microsoft. It hasn't been easy, with us initially reporting issues back in February 2006, but we’ve finally got here. This really marks a milestone for COTS mobile platforms even though we did achieve something similar back in 2003 with Nokia and their proprietary OS and recently with Palm OS, but getting vendor responses on mobile security issues (with maybe the exception of RIM) has historically been hard work.
A quick thanks to all those involved here at Symantec: Katie (before she left), Tyler, as well as the folks over...
On the day I got my iPhone I submitted a bug report to Apple. It wasn’t truly a bug, but I didn’t know of a better way to express my disappointment involving the absence of a software development kit for the iPhone. It just seemed like too unique of a device to not be able to create applications for it. Perhaps a bug report was a bit of a low blow, but I never expected I'd hear anything back. However, the day after Apple announced they were going to release an iPhone dev kit in February of '08, I got an email in response to my "bug." Now, this email was identical to what Apple posted in the "Hot News" portion of their Web site and while I'd seen it before on many of the Apple news sites, this time I actually read it. One big section stood out in particular:
“It will take until February to release an SDK because we’re trying to do two diametrically...
Let's say that an employee in your company gets a new laptop. He's excited about the laptop's WiFi capabilities, but the company he works for doesn't have wireless capabilities. What's he do?
One option is to bring in his own wireless router. He goes down to the local computer store, picks up a router for $39.95, and brings it to work. He plugs it in, boots up his laptop, connects to the network called "default," and is happy to use his laptop from anywhere in the building.
Another possibility is that he opens up the "wireless connections" panel of the laptop and sees a list of possible networks to join. He may not realize that the access points are on networks belonging to other individuals or companies. In the unlikely scenario of a targeted attack, he may even see an official-looking access point named after his company. In either case, he connects to somebody else's wireless work, finds that he can access the Internet, and...
O.K. - firstly - long time no blog. Secondly, apologies for that - a mixture of vacation, work, and work travel has recently seen me distracted a little from my blogging duties (my plate spinning is improving, however). Anyway, with the apologies out of the way, onto the subject of this blog. Recently I was invited by Microsoft to speak at BlueHat on Windows CE/Mobile security, even being given a guest spot on their blog and doing a podcast for them. Pedram from TippingPoint has provided a good summary of the talks that saves me from...
Further to the research already done on unlicensed mobile access (UMA) by our security researchers, I've been looking at a couple of alternatives to UMA services. As you’ll recall, most UMA threats surround increased exposure to the operator’s core network, as they are basically an extension of the core network and its protocols.
The services that I’ve been looking at are very similar but are not true UMA in this regard; rather, they may be best described as Mobile VoIP. A new crop of providers are appearing in this space, fuelled by WiFi-capable smart phone handsets. And, when they do appear, they don’t have any of the operator baggage to worry about, so are free to adopt the next generation standards rather than modify existing ones.
So, where’s the security point to this post? Well, when I say “looked at” these services, I didn’t mean admiring the user interface. I set up a couple of handsets...
Wireless Equivalency Protocol (WEP) has been one of the hottest topics in Irish news over the last few days. One of the leading providers of DSL in Ireland has supplied users with wireless routers protected using WEP. What made this newsworthy is that it has emerged that the WEP keys used to encrypt the network traffic and to control access to a private network were generated using the (Service Set Identifier) SSID. The algorithm used to generate the encryption keys has been analyzed and a tool is freely available which allows anyone within range of the router to trespass on a wireless network that has been secured using the default settings.
The DSL provider and media reports are advising customers that if they change their WEP keys, they will be safe from any trespassers or malicious attackers trying to get onto their network. While it is true changing the default WEP settings will mitigate this particular attack it will not make your wireless network secure.
So far in this series, I've posted a blog that talked about municipal Wi-Fi security in general and a second blog that talked specifically about Wi-Fi network identification. In this post, I want to cover muni Wi-Fi network authentication. There are essentially two parts involved with Wi-Fi authentication. The first part is how you authenticate to the network and the second is how the network authenticates to you.
Most people are familiar with the first part. Many Wi-Fi networks will dump your browser to a login page where they ask for a username and password, or even a credit card number to use to bill you. Some of the more secure networks will ask you to provide authentication information more directly. I...
On the desktop we have many different executable compactors, compressors and encryptors. These are used to protect and/or obfuscate binary files. These can be employed by software authors and malicious code authors to protect their code from reverse engineering (though, typically in vain). A while back, we saw a surge of malicious code authors using these tools to obfuscate their code against signatures. It became a case of:
10 Download executable compactor
20 Pass existing malicious code through it
30 Release on Internet
40 Wait for signature to be added to antivirus
50 GOTO 10
This got a bit boring for antivirus vendors like Symantec, so we introduced executable decompression support to our AV engines (as discussed in the Internet Security Threat...
With the advent of Symbian 9 came a new capabilities model that could be seen as akin to mandatory access control, or MAC, which I’ve touched on briefly in the past . If you’re interested more in the Symbian 9 capabilities model, I recommend you go read the Embeddec.com article or purchase a copy of Symbian Platform Security Development Architecture from Symbian Press.
FlexiSpy is spyware program that runs on either the...
Some of us (Ollie Whitehouse, Eduardo Tang, and myself) are happy owners of the iPhone. However, not because we are constantly listening to music or using a pinching motion with our fingers to see pictures zoom and shrink, but because we get to analyze the attack surface. While the iPhone itself will surely evolve via new models, software, and patches, this blog will consist of a rundown of our initial thoughts.
In the default out-of-the-box configuration for the average user, you can not run code on the device. This makes the platform less risky than other mobile platforms and desktop operating systems like Windows. If you can't run code, you can't run malicious code. Further, the AJAX/Web 2.0 applications that can utilize the phone's services (such as the ability to make calls) normally prompts the user before the action takes place. This prevents automatic dialing and things like SMS worms.
If you Google for either "Windows CE", "Windows Mobile" along with "rootkits" [1] [2] you don’t find anything on the subject. Back in the early part of this year I started a little skunk-works project (which resulted in an internal whitepaper) to understand the techniques that could be employed in rootkitting Windows Mobile devices, and how you would detect them if the bad guys got nasty and started doing so.
The results were, in short, not surprising. There are publicly known methods of API hooking on Windows CE. There is a publicly released keyboard logger in the compact .NET framework and there are numerous ways to load/inject DLLs into other processes. And, of course, direct kernel object modification is also possible.
The caveat about some of these methods and techniques is that your process needs to be fully trusted in order to weave its magic. So in a properly configured one-tier device that requires signing, or...
Many people have said that the lack of attacks upon Apple’s operating systems and devices can be attributed to a lower market share than Microsoft Windows-based PCs. With the shift towards malicious code being written for financial gain, it makes more economic sense. (I know that there are other arguments to be made, but bear with me.) Why write a Trojan that only runs on about 10% of computers when you can write one that is capable of affecting closer to 90% of them? Far more bang for the buck.
At the same time, there haven’t been many attacks on cellular phones and mobile devices. There have been several proof of concept Trojans, worms, and viruses for Symbian Smart Phones as well as a few for the Windows Mobile platform. Some of these have even resulted in small, localized outbreaks. Again, the lack of attacks on these devices has been attributed to a smaller user base.
On June 29th, however, these two platforms will converge when Apple’s iPhone is released in the...
