Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Security Response
Showing posts tagged with Mobile & Wireless
Showing posts in English
Ollie Whitehouse | 30 Oct 2006 08:00:00 GMT | 0 comments

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 the "...

James O'Connor | 24 Oct 2006 07:00:00 GMT | 0 comments

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 have Bluetooth...

Brian Hernacki | 22 Sep 2006 07:00:00 GMT | 0 comments

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, remember...

Ollie Whitehouse | 05 Sep 2006 07:00:00 GMT | 0 comments

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...

Ollie Whitehouse | 22 Aug 2006 07:00:00 GMT | 0 comments

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 are no less...

Ollie Whitehouse | 17 Aug 2006 07:00:00 GMT | 0 comments

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.

Take the following code snippet as an example:

TBuf<5> Buf; //5 char buffer
_LIT(Boof,"AAAAAAAAAA"); // 10 chars
Buf.Copy(Boof); // Attempt to overflow

Brian Hernacki | 10 Aug 2006 07:00:00 GMT | 0 comments

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 about what names...

Ollie Whitehouse | 08 Aug 2006 07:00:00 GMT | 0 comments

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...

Ollie Whitehouse | 28 Jul 2006 07:00:00 GMT | 0 comments

I thought I'd write a blog entry around this, as it seems that it is a question that comes up a lot when speaking to press, operators, enterprises, and users alike. The common question is usually along the lines of: "Why not build security into the network to protect mobile devices?" In this case the “network” could be cellular, WiFi, WiMax, or a hybrid of technologies; “mobile devices” can be cell phones, SmartPhones, PDAs or laptops, among others.

Well, there are two reasons why a network can’t mitigate all the risks involving mobile devices. First, mobile devices today are not always connected via a network that is controlled by just one entity. For example, it is feasible (although in my experience, rare) within GPRS (2.5G) or UMTS (3G) to ensure that a roaming user's traffic never touches the home operator’s Gateway GPRS Support Node (GGSN) when the user is, say, accessing the Internet using a mobile device (this is dependent on the policies of the...

Brian Hernacki | 26 Jul 2006 07:00:00 GMT | 0 comments

Lately, there has been a whole bunch of cities announcing plans for the creation of municipal (“muni”) Wi-Fi networks. From San Francisco and Silicon Valley to New York, Philadelphia, Toronto, and even Paris, this seems to be the hot new thing to...