Archive for January, 2009

Gnome Do Microblogging Plugin Authenticates Over Clear Text

Friday, January 30th, 2009

I love the Gnome productivity tool Gnome Do. Its great! What’s not so great is the fact that the installation default Twitter plugin “Microblogging (Twitter)” version 1.0 authenticates to Twitter over clear text. In general, its a great plugin… easy to post updates and wonderful balloon popups when friends post their’s… but this is a killer problem.

I’ve filed a bug report with the plugins group here.

With the ubiquity of wireless networks and the ease of promiscuously monitoring wireless networks, it is no longer acceptable to authenticate over clear text. Twitter shouldn’t allow authentications over none SSL channels, and applications shouldn’t support them even if non-SSL is supported. I discovered this while a friend was toying around with Kismet at a local cafe. I typically connect to an OpenSSL VPN whenever I use public networks, but due to the nature of the plugin it connects before I have a reasonable chance to enable the VPN… hence my friend captured my password. Fun.

I would also like to take this oppurtunity to remove any liability from myself for anything posted to my Twitter account in the future ;)

Tags: , , ,
Posted in Attacks | No Comments »

Responsible Home Wi-Fi

Wednesday, January 28th, 2009

Wi-Fi.  Everyone’s got it nowadays.  Your Comcast or Verizon broadband connection at home probably comes with a wireless router.  But do you really know how to set it up??  Better yet – do you really know how yours is set up currently?  Or does it “just work”?

I want to briefly share my thoughts on the subject and give you some advice on making a secure – or perhaps intentionally insecure – wireless network at home.

Let me explain some fundamentals.  The first thing that you need to keep in mind is that all wireless traffic is visible to everybody.  Your XBOX live session.  Your online banking from your laptop.  Your IM sessions.  It’s all out there, just waiting to be listened in on, on a very well-defined and well-understood protocol, 802.11.

Before you panic, you need to remember the second important thing – nearly all wireless traffic can be well-protected.  Walter has been doing a nice series on encryption, and even if you don’t follow all the details, the major takeaway can be that data can be wrapped up pretty tightly if you set it up correctly.

For most people, I am going to advocate running a closed network – encrypting your traffic and only allowing authorized users to use your home access point (AP).  This is the subject of some debate among the security community, most notably from Bruce Schneier (who advocates for keeping your wireless network open), but I’ll say that for the “average user” it’s better to close it off.

Your network can be secured through a combination of obscurity, exclusions, and encryption.  Obscurity is not openly advertising the name of the AP.  Exclusions are preventing unauthorized network cards from joining your network.  Encryption is wrapping the traffic in a difficult-to-break code that can only be understood by your wireless devices and your wireless router.  The first two methods are relatively trivial to subvert – any ‘serious’ attacker could get themselves onto your network if they were the only two barriers to entry.  But the third is the most important, and here your choice is pretty clear – definitely encrypt!

But which encryption and authentication method to choose?  Home APs commonly come with a couple varieties of encryption options – WEP, WPA-PSK, and WPA2-PSK.  WEP has had known vulnerabilities since almost its inception, and is now easily broken in less than 10 minutes of work.  So don’t use it. Use WPA or WPA2, although WPA2 is relatively new and supported by less devices than WPA.

PortForward.com has an excellent guide to the details of setting up security on many wireless routers.  I would personally recommend against masking the SSID (the “name” of the wireless network) and implementing MAC address filtering, just because they’re easily compromised anyways, and make the network a hassle to administer.  The slight tradeoff in security is worth it for the increased usability.  As long as you’re using WPA or WPA2 with a relatively long pre-shared key – at least 15 characters – you’re better off than many networks.

Finally, if you choose to run an “open network” – a network that freely allows any client to associate with it, with no encryption – there are a few ways to still be safe.  First, keep in mind, that while the wireless traffic may be easily ‘sniffed’, if the data itself has already been encrypted via SSL (look for the ‘lock’ icon displayed in your browser) or a VPN tunnel, it’s a moot point – it’ll be garbage to an attacker.  So even though I menacingly mentioned that your bank traffic is visible earlier in this post – it’s only visible as encrypted gobbledygook, so no reason to panic just yet.

Summary – use WPA or WPA2.  Don’t bother with MAC filtering or SSID masking.  Don’t use WEP unless you really have to.  And you probably don’t want to run a wide-open network, but if you do so, don’t panic too much – most ‘important’ traffic is probably encrypted anyways.

In another post I’ll go into some ideas for running a secure, yet open home wireless network.  But until then, keep my simple recommendations in mind and you’ll be just fine!

Tags:
Posted in Fundamentals, Network Design | 3 Comments »

HOW-TO: Cutting edge wireless drivers in Ubuntu

Wednesday, January 28th, 2009

MADWIFI has been the wireless driver of choice for wireless hacking for quite a while, but recently a lot of development time has been moved to the official kernel wireless subsystem drivers. They are slowly gaining and surpassing MADWIFI’s functionality, and are generally more supported and stable. One downside to these drivers is that recompiling the kernel is time and labor intensive and waiting for a distro’s kernel update can put you behind the curve in recent driver functionality.

The COMPAT-WIRELESS project pre-packages the latest wireless code as loadable kernel drivers on a (near) daily basis. This is a convenient way to download pre-patched and archived source… but in order to get the most recent changes (as they are committed) you have to pull the source directly from the kernel.org GIT tree. GIT is a code versioning system similar to CVS, SVN, Bazaar, etc. Below is a simple example of how to do this and compile / install the code. I’m writing this from an Ubuntu installation, but the same concepts should work on other distros. This isn’t an especially difficult process, but it isn’t necessarily obvious either.

There are a few prerequisites for the below instructions to work correctly:

  • Kernel greater than 2.6.21

  • Kernel headers (“apt-get install linux-headers-generic” in Ubuntu)

  • Build tools (“apt-get install build-essential” in Ubuntu)

1. Make a new directory and clone the source trees:

mkdir wireless-testing
cd wireless-testing
git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
git clone git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6.git

2. Make the packages

cd compat-wireless-2.6
export GIT_TREE=../wireless-testing
scripts/admin-update.sh
make

3. Install

cd compat-wireless-2.6
sudo make install

4. Update and repeat steps 2-3 when you want the latest and greatest

cd wireless-testing
git-pull
cd ../compat-wireless-2.6
git-pull

After step 3 you can try reloading the modules dynamically by running “make unload” and “make load” but this probably won’t work if you’re currently using your wireless drivers. Your best bet is to reboot your machine. You can confirm that you’re running the new(er) drivers by listing your kernel modules and look for the mac80211 module.

lsmod | grep mac80211
modinfo mac80211

If there are problems you can uninstall the drivers by running “make uninstall” from the compat-wireless-2.6 directory. Hope this is helpful!

Tags: , ,
Posted in How-to | 4 Comments »

Hashes – not just for breakfast

Wednesday, January 28th, 2009

Consider the problem where you need to know for sure that information you are looking at has not been altered since it was first created. A simple example that kids can relate to is a report card from school. The model for report cards is that the school gives a kid his/her report card, they bring it home and their parents sign it to show that they read the report card. An obvious problem that the school has is to be certain that the report card isn’t changed while the kid has it.

In cryptography, this problem is referred to as ‘data integrity.’ Cryptographic systems solve this problem by creating a representation of the information that is unique. This representation is referred to as a ‘hash’ (or checksum). A good way to think of a hash is as a digital fingerprint that looks totally different for each set of data that it represents. Functions that are used to create hashes from information are called hash functions. There are a couple of important points about hash functions:

  • The result of the hash function MUST be unique for each message that it processes. That is, you should never be able to get the same result from a hash function if you feed in two different messages.
  • The result of the hash function MUST not look anything like the message that it processed.
  • It MUST be impossible, given the result of a hash function, to determine what the original message was.
  • The result of the hash function is usually smaller than the message that it processed.

If you wanted to exchange a message with another person and be sure that the message hasn’t been changed along the way, you could use a hash function as follows:

  1. Create a message.
  2. Feed that message into a hash function.
  3. Send the message to the recipient along with the hash.
  4. The recipient feeds the message into the same hash function used by the sender.
  5. The recipient compares their hash with the sender’s hash. If they are identical, the recipient is sure that the message wasn’t changed.

Of course this exchange isn’t secure as the hash could be changed in transit as well, but it illustrates how such a system works. I’ll explain how to make this exchange secure in a future post. To find out more about the basics of hash functions, read more.

(more…)

Tags:
Posted in Fundamentals | No Comments »

PGP Followup

Thursday, January 22nd, 2009

I wanted to write a quick follow-up on my post last week about the issues that I had with recovering my PGP-encrypted hard disk.

I was contacted by Nathan Liddle, one of the senior support engineers from PGP and we spoke about my experiences.  I was first off, very impressed to see PGP proactively addressing concerns by contacting me here and it was great to be able to share my feedback.

Nathan graciously listened to my story and got the takeaway of that PGP is going to try and improve their recovery disk tools, to hopefully take some of the guesswork out of the process that I had to go through.  They appreciate that I was a pretty ‘techie’ person and was able to figure it out myself, but the average user of PGP WDE may not be able to do so, and that their tools could use some improvement.

So, I’m extending a shoutout to PGP for listening to customer feedback!  Thanks!!

Tags: , ,
Posted in Securism | No Comments »

Clock arithmetic and security

Wednesday, January 21st, 2009

Quick quiz, what do the following sequence of numbers have in common: 19, 3763, 31, and 67? The answer is, they are all the same! Ok, well obviously that’s not strictly true. More correctly, these numbers all represent the same value in modular arithmetic (7 modulo 12). When you take each of these numbers and divide them by 12, you end up with a remainder of 7 (19 / 12 = 1 remainder 7, 3763 / 12 = 313 remainder 7, 31 / 12 = 2 remainder 7, and 67 / 12 = 5 remainder 7).

Another simple way to think of modular arithmetic is clock arithmetic. Consider the problem when you are looking at an analog 12 hour clock. You need to figure out what time it is going to be 7 hours from now. If the current time is 3 o’clock PM, you add 7 hours and end up with 10 o’clock PM. But, what if it’s 8pm? You don’t simply add 7 hours as there is no such thing as 15 o’clock pm. Instead, when you pass 12 o’clock AM, you restart your counting. So 8 o’clock PM + 7 hours = 12 o’clock AM + 3hrs = 3 o’clock AM.

So what does clock arithmetic have to do with security? Going back to our original sequence of numbers, notice that you cannot possibly determine that these numbers all represent the same mathematical value without having a key piece of information, the modulo value (which in this case is 12). When you think about it, this property is useful from a secrecy perspective because you have 2 pieces of information that have a common value, but you can’t tell what that common value is unless you know some other information. This basic property of modular arithmetic forms the basis of many of the key negotiation and encryption algorithms in use today.

So, for fun, here’s a simple cryptosystem (secure enough to keep your 10 year old little sister from reading your journal) that uses this property. Note this cryptosystem doesn’t authenticate the two parties, but it at least allows them to exchange a pair of secret keys no matter who is listening.

  • Alice and Bob want to exchange a secret message, but they can only talk to each other over an open communication channel.
  • Beforehand, Alice and Bob agree to use the current time as the modulo value for determining the secret value. For example, if the current time is 4pm and Alice and Bob want to agree on a secret key, they will divide their values by 4. Note that the method they are using for choosing a modulo value must remain secret for this system to work.
  • Alice sends her value to Bob in an open channel. Bob calculates the value she sent modulo the current time. The result is Alice’s encryption key.
  • Bob sends his value to Alice again in an open channel.
  • Alice calculates the value she got from Bob modulo the current time. The result is Bob’s encryption key.
  • Now, Alice and Bob can communicate securely using each other’s encryption key to encrypt messages being sent back and forth (using some pre-determined encryption algorithm).

To see the system in action:

  1. The current time is 9pm.
  2. Alice picks a value of 84.
  3. Bob picks a value of 1156.
  4. Alice and Bob send a message to each other via a open channel (normal phone call, ads in the newspaper, or even yelling at each other in a park!).
  5. Alice get’s Bob’s value of 1156 and calculates 1156 / 9 = 128 remainder 4. 4 is Bob’s encryption key.
  6. Bob get’s Alice’s value of 84 and calculates 84 / 9 = 9 remainder 3. 3 is Alice’s encryption key.
  7. Now Bob and Alice can encrypt their messages using their respective encryption keys.

The real beauty of this type of system is that no matter who learns the values that Alice and Bob selected in steps 2 & 3, they will never be able to figure out how they are related without knowing what the modulo value is. In a future post, I’ll expand on this a bit more to show how modular arithmetic is used in non-toy cryptosystems.

Tags:
Posted in Fundamentals | No Comments »

With Great Power, Comes Great Responsibility

Monday, January 19th, 2009

Last week’s SANS newsletter caught my eye for an interesting story mentioned in it – “Wireless Hacking Braggarts Avoid Jail Time”.  It links to a story in the Cleveland Plain Dealer about two security consultants who were caught in a FBI sting for wirelessly stealing data from a fake defense contractor.

These two fellows were approached with a great offer – $100,000(!) – to grab some files wirelessly and discreetly.  The FBI got the idea of approaching them after they mentioned in an article in Crain’s Cleveland Business that they had broken into several networks wirelessly, and that companies should hire them to protect their networks.  Whoops!

This brings up a tricky question about infosec in general – in a business environment that is only slowly becoming aware to the issue of security, how does one generate new business?  It can seem tempting to ‘demonstrate’ the cost of bad security to a client – and cold-calling a business with information about their vulnerabilities is a sure way to wreck that relationship.  The responsibilities of a security professional are to clearly communicate the importance of a strong security posture and to let that information speak for itself.

These two guys took the exactly wrong approach to selling computer security – becoming the ‘bad guys’ that they’re supposed to be protecting clients against!  In the security field, more than many others, the line between ‘good guy’ and ‘bad guy’ can be blurry.  An infosec professional who is only using commercial tools isn’t really getting in the head of a ‘bad guy’ – because the bad guys are using open source tools, not the expensive Foundstone package.  We’ve got to get in the minds of the threats in order to defend against the them.

This is where professional programs like CEH have value.  This program teaches security professionals both the tools of the ‘bad guys’, and the ethics required to use them properly.  The temptation of a quick payday may be lurking for some people, but it’s good to see that the FBI and other government organizations are actively watching out for these type of people.

As Spiderman said – “With great power, comes great responsibility”.  Security professionals need to keep this at the forefront of their mind at all times.  We’d probably be better off by not wearing tights and a mask, though!

Tags: , , ,
Posted in Securism | No Comments »

Summarizing PKI Certificate Validation

Monday, January 19th, 2009

Security certificates and the methods used by websites to show that they are secure enough for users to trust are notoriously complex. To shed a little light on this, I’m going to explain how PKI certificate validation works.

PKI (Public Key Infrastructure) describes a method of asserting the identity and validity of a person (or entity) that you have not previously met or interacted with through the use of certificates containing identifying information and public keys (these certificates are more properly called X.509 certificates). PKI accomplishes this by defining a central authority who is mutually trusted by all users of the system. The following logical diagram shows how this works for a scheme where I am presenting my credentials to a user to setup a trusted communication path between us.

Simple PKI Diagram

Simple PKI Exchange

As shown in the diagram above, the burden of figuring out whether or not a certificate can be trusted ultimately falls on the end user. The user is responsible for going through the step of verifying a certificate with a Certificate Authority to figure out if the certificate presented to him is valid. Ultimately, it is the software used by the user (mostly web browsers) that perform this validation.

Before describing the certificate validation process, let’s spend a few moments first describing what a X.509 certificate contains. In short, a certificate contains information identifying the owner of the certificate, an identifier of the central authority that issued the certificate, a unique serial number, a validity date range, and other optional fields that indicate how the certificate can be used. In addition to this information, a X.509 certificate contains information needed to verify the integrity of the certificate such as a public key that is owned by the certificate owner and a field describing the hash and encryption functions used to create the digital signature of the certificate. The digital signature is an encrypted one way hash of the certificate contents. This signature is created using the private key of either the certificate owner or, for certificates issued by a Certificate Authority, the private key of the Certificate Authority.

Certificate validation, described in RFC 5280, is notoriously complex due to issues of backwards compatibility with older X.509 standards, overloading the meaning of fields contained in certificates, and other technical issues. That being said, it is still easy to describe the overall process used by end user software to perform certificate validation.

The first step of validating a certificate is to first verify the certificate’s integrity. This is done by first creating a one way hash of the certificate contents (using the hash algorithm indicated in the certificate). This hash is stored temporarily in memory. Next, the digital signature embedded in the certificate is decrypted using the public key included in the certificate (or, for CA issued certificates using the public key from the CA root certificate). The decrypted digital signature (which is again a hash of the certificate contents) is then compared to the hash that was computed locally. If the hashes match, then the user knows that the certificate has not been altered since it was created.

Next, the certificate is checked to ensure that it has not expired. This is done by verifying that the current time falls within the validity dates included in the certificate. Next, the certificate usage fields are checked to ensure that the certificate is being used for the purpose it was intended (via the keyUsage field). For example, if the keyUsage field of a certificate is set to cRLSign but the certificate is presented by a bank website, the certificate is not being used as intended and will be rejected. Finally (and probably most importantly), the certificate is checked to see that it has been issued by a trusted certificate authority.

This last step bears more discussion as it is the validation step that is most important in trusting a certificate. An important field embedded in a X.509 certificate is the issuer field. The issuer field lists the name of a certificate authority which has vouched for the validity of the certificate. Recall the step where the integrity checks are performed. The user must decrypt the digital signature using a public key. Instead of using the public key embedded in the certificate, the user looks at the issuer field to identify a Certificate Authority certificate (called a root certificate) that contains the public key that should be used to verify the certificate. The root certificates are stored locally on the user’s computer, so the software searches through this list to fetch the correct root certificate. Once the root certificate has been found, the public key from the root certificate is used to decrypt the digital signature in the certificate being validated. If the signature is validated, the user knows that the owner of the root certificate (the Certificate Authority), has signed the certificate being presented and therefore vouches for the contents of the certificate.

At this point, the only remaining step is to see if the certificate has been revoked by the Certificate Authority (due to a possible compromise of the certificate or of the Certificate Authority itself). Since the list of root certificates that are stored on user’s computers are not frequently updated (the list is usually selected by the OS or browser vendor), there must be a way for the software to dynamically query the Certificate Authority to check if there is a problem with the certificate. This is accomplished using 2 different techniques: certificate revocation lists (CRLs) and an online check called Online Certificate Status Protocol (OCSP).

CRLs are lists that are periodically issued by a CA that contains a list of certificate serial numbers that have been deemed to be invalid by the CA. The CRL also contains a date range indicating when the CRL should be considered expired and a new list should be obtained. Browser software is expected to regularly download the CRLs for all root certificates that it has knowledge of. When using CRLs, the final check for a certificate’s validity is to verify that the certificate’s serial number does not appear in the latest CRL for the CA.

OCSP is a protocol that is used by browser software to query a CA dynamically for the revocation status of a certificate. The query request contains the serial number of the certificate being checked as well hashes of the issuer name and public key. The request is sent to a OCSP server operated by the CA. The response will either indicate that the certificate is valid, revoked, or is unknown. When using OCSP, the final check for a certificate’s validity is to verify that the CA’s OCSCP server reports back that the certificate is ‘good’.

In summary, the certificate validation process is complex and resource intensive. The PKIX community has recognized this as becoming more of a problem with the prevelance of mobile devices that have limited processing resources. A solution that is being proposed is a mechanism to offload the responsibility of performing all of the certificate validation steps to a centralized server that is trusted by users. This mechanism is called Server-Based Certificate Validation Protocol defined in RFC 5055. In a future post, I’ll examine more about SCVP and discuss different use cases for how it can be deployed to provide security in mobile wireless networks.

Tags: , , ,
Posted in methods | 1 Comment »

Recovering a PGP Whole-Disk-Encrypted Drive

Friday, January 9th, 2009

This week I had a frustrating incident occur that I’d never wish upon anyone again – my PGP-encrypted laptop hard drive was corrupted!  Luckily, I was able to recover the data after hours of research and labor.  The whole experience was a painful one and it’s really turned me off from whole-disk encryption as a whole.

The initial problem was caused by one of my least-favorite pieces of software in the world – the Ubuntu graphical installer.  I was installing Ubuntu onto an external hard disk while using a Ubuntu LiveCD, and in the process of installing the OS, it overwrote the MBR on my laptop’s hard disk.  This seems to be a common pitfall affecting Ubuntu users.  Installing GRUB to the first hard disk is apparently the default behavior, according to several posts on the Ubuntu forums.  I must have missed the “Advanced” menu option to specify the bootloader location.

Installing GRUB to the MBR wouldn’t be terrible, if not for the fact that PGP Whole Disk Encryption (WDE) also uses a non-standard Windows bootloader – a piece of software called BootGuard that prompts the user for the decryption key to the drive.  Because GRUB took over the MBR on my hard drive, BootGuard would no longer execute – and thus the contents of my two partitions were stuck as encrypted with no decryption mechanism on the disk.

Adding further frustration to this issue was the fact that Ubuntu (loaded onto the external HD) wouldn’t even boot up without the laptop’s HD – because the GRUB boot loader was on the internal, encrypted HD, rather than the external HD that held the rest of the operating system.

So, I was stuck with an encrypted Windows installation and a halfway-usable fresh Ubuntu install.  What’s a guy to do?

Fortunately, if there’s one thing that our office has, it’s a lot of computers.  I was able to use a backup laptop to begin doing some research into recovery options.

PGP has recovery boot disks that can be used to decrypt a drive, so this was the first thing I tried.  With my encrypted (and inaccessible) disk in the bay of my laptop, I booted with the PGP recovery CD.  Unfortunately, this returned an error – “Internal error accessing disk, 0×80″.  A common error, if you do a little googling.  Something was wrong in the disk’s partition table or boot record – I would need to try another method.

The first method I found in the PGP Knowledge Base was in Tech Note 807 , which suggests creating a Windows PE recovery disk that supports PGP disk recovery.  I followed this path for a while, but had some issues slipstreaming the PGP software into the disk.  I gave up eventually after seeing a few other simpler methods suggested.

The simpler recovery method recommended by the members of the PGP forum and the PGP Knowledge Base was to install PGP Desktop on another PC, slave the encrypted drive to that machine, and decrypt the drive using the second PC.  I was able to get the PGP Desktop software from our administrator and install it temporarily on a new computer, then cable in my encrypted drive with a IDE to USB adapter.  This looked promising at first, with the machine able to recognize the drive and see its (unreadable due to encryption) partitions, but PGP wasn’t able to identify the drive as holding encrypted data on it.  After a few tries (and a few hours), I decided to move 0n and try a different vector.

I had seen a post on the support forum suggesting using a Windows disk to rebuild the MBR to a normal Windows state.  After doing this, the PGP recovery disc may work, since PGP is prepared to deal with a situation like this (somehow!).  By doing this, I realized I would lose the GRUB bootloader info for my Ubuntu installation, so I first pulled that off the drive from within Ubuntu (cat /boot/grub/menu.lst > /home/menu.lst).  This would give the UUID of the Linux installation if I ever want to try and get it working and bootable.

After doing that, I decided to just go for it.  After installing the encrypted drive into a spare laptop chassis, I put the Windows disc into the CD drive, booted to the recovery console (type R when prompted), and then ran the fixmbr command for the drive.  Rebooted, and…. unable to find operating system.  This was progress!  No more GRUB bootloader!

Finally, I put in the PGP recovery disk again, booted off it, and instead of the error I saw before, it continued on to the recovery console – and it recognized my PGP-encrypted disk!.  I typed in my passphrase, and then, very cautiously, chose “D” to decrypt the drive.  It very slowly started to decrypt.

The entire decryption process when running from the recovery disk takes quite a long time – on this disk (60GB), it was only about 15% along after 90 minutes.  I left the computer plugged in overnight and let it run.  When returning to the office this morning – it was done!  I put it back into my original laptop chassis (I was using a temporary one while I rebuilt a new installation of Windows on a spare HD in the main chassis), and it booted up as if nothing had ever happened.  The whole thing was pretty funny, actually – to see the little guy churning along as if it hadn’t been on the brink of death just 24 hours before.

This entire experience has left a bad taste in my mouth regarding whole disk encryption.  It’s very secure, and my experience with PGP prior to this incident had been pretty drama-free, but when it fails, it fails very dramatically.  PGP has very sparse documentation about the recovery process, and seems to take the opinion that their software is so reliable that they don’t need to spend much time making recovery a little bit easier.  For a user who’s done nothing wrong, they make the barriers to recovery too high – I had the decryption passphrase, and a simple mistake was enough to ruin all my data.  I was on the verge of scrapping the drive, suffering an unexpected data loss (which even regular backups can’t protect against perfectly).

I’ll probably avoid PGP WDE in the future, but whole disk encryption as a concept isn’t going away anytime soon.  It would be good for developers to keep disaster recovery methods in mind when creating their software!

Tags: , ,
Posted in Securism, methods | 18 Comments »

Symbian S60 SMS Exploit ‘Curse of Silence’

Saturday, January 3rd, 2009

A lot of very interesting research was presented at this year’s Chaos Computer Club meeting. One very interesting piece of research involved the mobile Symbian S60 operating system and a DOS vulnerability involving a maliciously (or unfortunately long legitimately) crafted SMS message. The original advisory released by Tobias Engel can be found here.

Executing the exploit is trivial and can be performed directly on most SMS capable mobile phones or SMS gateway services. The attacker simply creates an SMS message prefaced with an email address greater than or equal to 32 characters in length followed by a space (ex. “123456789@123456789.1234567890123 DOSed!”). After receiving the malicious message, the target’s phone’s SMS service will either die silently (preventing new messages from being received) or fail to receive new SMS messages after a certain number of malicious messages have been received. This is effectively an SMS DOS.

The problem would appear to be in the way that the S60 OS parses the prefaced email address of the received SMS message. There is a little used SMS standard (3GPP TS 23.040 section 3.8) for sending SMS messages to email targets and this parsing is likely related to the displaying of these messages. Typically when an error like this kills a service it could become a vector for a buffer overflow attack, but because of the hard message length limit on SMS messages, this is most likely not possible.

Symbian is a mobile operating system used mostly by Nokia phones (although some other manufacturers use Symbian; including Sony, and Motorola). According to the advisory any Symbian phone running the below software versions is vulnerable:

  • S60 2nd Edition, Feature Pack 2 (S60 2.6)
  • S60 2nd Edition, Feature Pack 3 (S60 2.8)
  • S60 3rd Edition, initial release (S60 3.0)
  • S60 3rd Edition, Feature Pack 1 (S60 3.1)

You can identify what phones have vulnerable versions by referencing the S60 product page.

The f-secure mobile security product is advertising protection for this exploit. Other than upgrading the operating system of a device (a process which must be vendor/provider supported) or disabling the SMS feature of your calling plan,  a software solution appears to be the only way to mitigate this problem device.

Tags: , ,
Posted in Attacks | No Comments »