Author Archive

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 ;)

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!

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.

An Introduction to Protocol Fuzzing

Tuesday, December 30th, 2008

I have been considering running a basic level of protocol fuzzing on some known/unknown services for some recent projects. These are mostly penetration tests, but with particularly locked down or limited points of entry. I look at fuzzing as a way to both demonstrate more value in the penetration test and to potentially find new holes in an environment where known vulnerabilities don’t work or don’t exist.

Fuzz testing” or “Fuzzing” is the process of taking an expected input or output and mux’ing it up with unexpected data. It began as a software testing method, but is now commonly used to detect potential security problems. It’s easiest to understand protocol fuzzing when testing Web applications:

In a typical web application login process you submit a username and password over the network. Fuzzing this communication would likely involve replacing a normal username/password pair with random data of random (and often long) lengths, but might also involve changing other HTTP response data.

The goal is to discover checks in the services programming which don’t parse the data they receive correctly. Under typical expected conditions they work fine, but in the process of fuzzing you try and discover conditions under which they do not work fine. These can lead to the discovery of new buffer overflows, cross site scripting, and other vulnerabilities.

There are a lot of fuzzing tools and frameworks out there, most of them targeting the web application space (I’ll be dedicating a later post to these). Here are a few which can be used in arbitrary protocol fuzzing:

  • ProxyFuzz – A python based proxy which will will randomly change the contents of either side of a communication stream.
  • Taof – A python based GUI proxy with a somewhat easy to use interface to select which parts of a communication are fuzzed. It can also bind itself to a locally running process to better determine when a process is having issues with fuzzed data.

There are many advantages to fuzzing:

  • You can discover interesting vulnerabilities without having a clear understanding of a protocol
  • Fuzzing can operate at all levels of the OSI model. Most fuzzers are built at the application, network, and transport levels, but fuzzing principles can work on any level.
  • Applicable to both the server and client ends of a protocol.
  • Many of the vulnerabilities discovered through fuzzing are buffer overflows and can lead to the execution of arbitrary machine code.

And several disadvantages:

  • If you don’t have much knowledge of the protocol structure, it becomes a more or less a brute-force approach.
  • Encrypted protocols are difficult to fuzz. Most fuzzer’s operate as intermediary or proxy applications and would need to either decrypt communications on the fly or have the client program’s cooperation in mux’ing the traffic.
  • As an automated method of attack, there is often a lot of work involved in finding out what exactly went wrong when an anomaly is detected and how to exploit it in a controlled manner.

Fuzzing is a big topic and an area I’ll be exploring more later.

Security and Persona Development

Friday, December 19th, 2008

I have recently been exposed to some projects which have used “personas” for the development of new products and services. I’ve heard of their use in design (as in product and user-based design) before and been impressed at how they focus design towards the goal of satisfying an eventual end-user need. I can’t help but wonder if the “persona tool” can be used to help security solutions better meet an end-user need and help the overal useability of security.

Personas are basically character profiles meant to represent the personality and use-case of an end-user of a product or service. Wikipedia has a good summary:

A user persona is a representation of the goals and behavior of a real group of users. In most cases, personas are synthesized from data collected from interviews with users. They are captured in 1–2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to make the persona a realistic character. For each product, more than one persona is usually created, but one persona should always be the primary focus for the design.

I can see them being useful in security for visualizing how users will interact with security solutions and use them in “real life.” For example a persona could help someone develop a password policy that not only has strong security requirements but will forsee how user’s will interact and use it.

This is a topic I’ll definately be exploring further. I would like to develop a framework for developing and applying persona’s to the creation of security controls and policies. Seems like it could have a definate impact on how “usable” security solutions are.

Welcome!

Sunday, December 14th, 2008

The Securism Blog is focused on exploring the ever-changing topic of computer and information security. Our goal is to explore relevant topics in a way which both informs and contributes to the on-going discussion of security and its various applications in society.

We are security professionals and enthusiasts who are interested in expanding our own understanding of security and providing commentary on developments in the security world. Please see the about page for more information regarding the Securism Blog or the authors page for information about Securism authors.

The format of this blog will evolve over time. We hope you find it interesting, useful, and informative and we look forward to your comments and discussions.

Thanks, and enjoy!