Collin Mulliner gave an updated version of his presentation at 23C3 in Berlin titled ‘Advanced Attacks Against PocketPC Phones’ (we originally blogged about it in August). As I previously mentioned, one of the vulnerabilities he discussed had, to my knowledge, still not been patched. Well Collin confirmed this in his presentation and also released a working exploit for the vulnerability to liven things...
Ciao! Back in May, at the Microsoft Embedded Developer Conference in Las Vegas, Microsoft provided a number of presentations on Windows CE 6. The following is a summary of the improvements in Windows CE 6, which either directly or indirectly impact upon the security. The points below are taken from the slide decks of the presentations and are distilled down with some commentary added. It should be noted that it is not currently clear when or if Windows CE 6 will be adopted by the Windows Mobile Group. This entry follows up on the blog regarding Windows CE/Mobile 5, which I posted earlier this week.
From the talk Windows CE 6 Overview by David Kelly & Tim Kiesow of Microsoft, I have taken the following points away:
It supports safe SEH for security compliance (/GS)
Bonjour! Carrying on from my previous blog post, here is some more information on Windows CE/Mobile 5 security.
Shatter
Windows CE and Mobile, like its desktop cousin, can suffer “shatter attacks” across processes. This includes processes running at different levels of trust (please see my previous blog post and the section on One-tier versus Two-tier). For those of you unfamiliar with what shatter attacks are, there is a Microsoft TechNet bulletin that addresses the original assertion that the shatter attack condition can exist.
As municipal Wi-Fi networks begin to roll out, I've begun to notice a trend that isn't surprising, but is still a bit worrisome. Business users are beginning to use the muni Wi-Fi in the office. While the signal doesn't often penetrate too deeply into buildings, conference rooms and window offices seem to get a sufficient signal in many cases. The problem is that I see people using the muni Wi-Fi signal instead of the office IT-supported network. Sometimes they just use it because it's more convenient. The office IT network is "secure" and requires extra work, such as entering keys or using a VPN. Sometimes they do it because they explicitly want to avoid the local IT policy controls (access to restricted sites, use of restricted applications, etc.)
So, why is this a problem? First, it exposes the user’s computer to the Internet without the normal protection of the office IT security safeguards (like a firewall). While it's quite possible to...
Hola again! Well, that’s my Spanish out the way. Oh, wait – dos cervezas por favor ;-). Anyway, I was invited down to Spain by the kind folk of NoConName (thanks to Nico and crew – Majorca is lovely!) to deliver a presentation on some research I had done at the start of the year when I first joined the Advanced Threat Research team (research that I had alluded to in an earlier blog entry on an attack surface analysis of Windows CE 5 and Windows Mobile 5.
This is a rundown of the NoConName version of my presentation:
• Introduction & Context • Overview of Windows CE • Windows CE Security Model • Analysis Findings • Windows CE and Security Patches
The first three sections are pretty self explanatory and way too long to cover...
Back in 2004, I presented some research at CanSecWest entitled “Bluetooth Security: Toothless?” One of the items I covered in this presentation was the ability to recover link keys over the air. My research was missing a key feature, which was how to force a re-pair between two devices in order to be able to observe the new pairing to be able to get the required data. Fast-forward to June, 2005, and Yaniv Shaked and Avishai Wool improved the attack in many aspects and released the paper “Cracking the Bluetooth PIN,” including many novel aspects. Well, it’s now 2006 and Thierry Zoller has just given an interesting presentation at the hack.lu conference (with input from ...
Be warned: this may sound a little odd. Imagine if I told you that some television and radio content is broadcast using IP, over the air. (You'd probably think I’d been working with too much paint thinner over the weekend.) Well, this broadcast method is how a live service in the UK works. It’s called digital audio broadcasting – IP (DAB-IP) and in short, your mobile device just got another network connection.
The UK has just had the “Lobster” (a mobile handset) launched on the Virgin mobile network, which uses DAB-IP for its TV and radio content. DAB is a standard owned by ETSI (the same people who own GSM). With DAB-IP, content is basically being tunneled over IP, over DAB, to your handset. One of the first interesting things I read in relation to this topic was a...
The University of Santa Barbara's software group released the source code for their proof of concept 'Feakk' worm that was developed by Paul Haas in March 2005. The worm uses SMS to send a hyperlink to its target. The targeted user then has to visit the hyperlink and download and acknowledge three sets of prompts in order for the worm to install, at which point it will immediately start to run in the background. It will scan the user's contact list and send a message to each contact (including the recipients' names) and will also scan for new contacts at certain intervals.
Upon installation, the worm checks for a contact with the first name "HACKME." If this isn't found the worm will exit. If it is found, then the worm sends itself to every mobile number it finds in the user's contact list. The author did not write a payload because this was for demonstration purposes only and it should be noted that it can be removed via...
A few months ago, my boss plonked a box on my desk and said "see what you can do with that." That's how I was introduced to the Blackberry. I've been interested in all kinds of PDAs and mobile phones for years now, but I'd never come across a Blackberry. I suppose that up until recently, it has been the preserve of key government and corporate employees, not average-Joe software engineers like me. However, the Blackberry is emerging as an ever more popular platform for the general public. In the next few weeks that followed, I noticed a common thread in the architecture and features of the device: security first and functionality second.
What do I mean? Well, take Bluetooth for example. When you're looking at the box of your shiny new Blackberry and you see that it has Bluetooth support, you might think "great, I can use it with my laptop to go online while on the move." Bzzzt—wrong. Although the Blackberry does...
Back to municipal Wi-Fi security again (I'll get onto other topics as soon as I get all of this out, I swear). There are two important things left to cover though: transmission security and device security. If you're new to this topic of muni Wi-Fi security, please have a look at some of my previous posts first, in order to catch up (Part I, Part II, and Part III).
I'll start with transmission security, which generally gets a lot of discussion. Transmission security really covers everything that you send or receive over the wireless network after you're "connected". Now...
In a time not so long ago the world was a very different place—in terms of mobile phone software upgrades at least. For many years now, several smaller companies in the cellular handset industry have provided a means for users to upgrade the firmware of their devices at home. These firmware upgrades are typically carried out using a computer—on which the firmware files are stored—and a connecting cable (or desk stand) for the cellular device. Sadly, this was not always true for the larger players; the result of which was that when a vulnerability was discovered, the user would first have to learn of it and then take their handset into a service center to be upgraded. This method isn’t very practical and would be pretty low on the priority list for most, if not all but the seriously security conscious.
Well, I applaud Nokia for their recent change of heart to allow users to perform their own D-I-Y...
I spoke in my previous entry about how, when using Symbian's C++ descriptors for variables, traditional buffer overflows can be turned into denial of service (DoS) conditions. Well, I thought it might be important to point out that traditional overflows can still exist in Symbian-developed software to this day. Although not recommended, Symbian does allow the inclusion of 'libc\string.h', among other headers; this allows programmers to utilize all of the unsafe “C” functions we have become accustomed to (such as strcpy, strcat, sprintf, etc.).
The subject of buffer overflows, the danger they pose, and how best to mitigate them is well documented on the Internet; so, for brevity’s sake I won't cover it here yet again. However, what I will say is that some of the research I've done at Symantec has shown that these overflows...
With the advent of the Symbian mobile operating system we have been introduced to several new descriptors for different types of variables. These descriptors are used when writing software with Symbian's C++ API and are not standard C-style strings, but instead “classes” that perform strict type and length checking. These classes are designed to protect against buffer overflows and general memory corrupt bugs, among other things.
While this design is helpful because it stops overflows from overwriting the stack and heap, developers could develop a false sense of security. For what traditionally would have been a vulnerability that leads to arbitrary code execution, it is now potentially a vulnerability that causes a denial of service (DoS) condition.
In a previous blog I wrote about security in municipal Wi-Fi networks and talked about what I called network identification. I wanted to talk a little more about that now. I think this is actually one of the hardest problems to deal with.
Just to recap, the problem is that when you attempt to connect to a wireless network, you do so based on the network name (the SSID). That name, however, is a very poor identifier. The administrator of the access point can name it whatever they like. So, if I want to setup an access point and name it "GoogleWi-Fi", I can. And now when anyone in range attempts to connect to a wireless network they will see one called "GoogleWi-Fi". So, how do you know who you're connecting to?
People have suggested a number of approaches. I've heard some suggestions around educating users...
I posted a blog in May that spoke about the potential for remote code execution on Windows CE devices and the problems involved with patching. I also alluded to some research Symantec had been doing at the time. Well, at DefCon this past weekend, Collin Mulliner demonstrated a remote code execution flaw via MMS on Windows CE.
Collin's slides show how he used a malformed MMS message to achieve arbitrary code execution on a device, simply by having a user view the message. This is obviously of great concern; Windows Mobile devices are becoming more and more prevalent and the substantial challenges with patching continue to exist.
At the end of 2005, the Symantec Advanced Threat Research team performed a detailed...
