We might finally have some decent mobile viruses to worry about.

Why is it that McAfee’s VirusScan Mobile is only Windows Mobile 5 and 6? Simply put, it’s because that platform gives the end-user enough rope to hang themselves. Users can grab a .CAB file of the brick breaker game from only god knows where and install it themselves through Activesync.

Surely tech-savy users don’t just install any hackware from untrusted sources right? If you believe that then you haven’t spent much time on http://www.howardforums.com/ or http://www.mobile-files.com/forum/ where every day, technophiles repackage and swap DLLs and other tasty bits from one carrier’s phone to another. Users don’t care about running untrusted code. To them, it’s just an annoying split second while they click away the nag window so they can dive into Justin Timberlake-screensaver-ring-tone wallpaper bliss.

It goes beyond running untrusted code from untrusted sources. Users will replace entire operating systems through unofficial channels:
Windows Mobile 6 for the XV6700: www.downloadsquad.com

If you step outside of your tech circle for a moment you’ll notice that most of your friends and family (you know, the people that will be watching football over Thanksgiving while you’re fixing their computers) don’t have windows mobile, RIM, or palm phones. If they have a typical Verizon phone then they follow a path like this to get applications:
Developers create and sign BREW code, that code is then tested and certified via Qualcomm’s NSTL site: https://www.nstl.com/brew/ . Ultimately the wireless carrier decides on what application they put in their catalog. (Usually after they test it themselves.)

Some see this path as a way to lock the user into the carrier’s applications. Another way to look at is the carrier is certifying that code for your phone. Given that the wrong code can put your handset into a chronic state of reboot permanently ruining the device I can see why carriers like to keep tabs on what users load on the phone.

The masses are crying about an open iPhone API. I’m sure they’ll get the open API, along with everything else that comes with it.
If you look at any of the press surrounding Android, the mantra is clearly openness and convenience. Openness and convenience; security’s best friend? <borat> NOT! </borat>

-higB

Here at Intrepidus Group, we do a lot of mobile application security reviews.  Much like standard web application reviews, some clients consistently turn out very secure apps.  However some apps have a detailed finding list longer then a copy of War and Peace.  One trend can often be seen across applications regardless of the client’s understanding of security.  Mobile applications, at some point of their process, typically rely only on a phone number and short numeric pin for authentication to a remote server.

We’ve all know that weak passwords are one of the easiest way on to a system. If you let users have the option of choosing a secure or weak password, they will often take the easier to remember, less secure choice.  I would say most major web based applications now require users to choose passwords with at least 6 characters, using mixed case and at least one number or special character.  Typing in complex passwords with your standard QWERTY keyboard isn’t such a problem, but can you imagine trying to multi-tap some of your complex passwords on a 0-9 keypad? And into a stared out password field? It’s somewhat understandable that most mobile apps only require a numeric pin for authentication.

The problem of course is that most of these server side components can’t be limited to only allowing access from mobile devices (break out your old school User-Agent hacks and give some “.mobi” addresses a try). Limiting access to restricted IP address pools usually don’t help either and typically is a nightmare if client is supporting multiple providers. So in almost all cases, you have to assume an attacker can easily script a brute force attack against some part of the authentication (with mobile apps, it’s typically not just the front door login, but also a web service burried somewhere in the site that will handle authentication).

What’s a mobile vendor to do? CAPTCHAs, you say? Some of these are barely readable on a 22″ monitor. Good luck figuring out that text on your 1.5″ Nokia screen.

Account lockouts seem to be a reasonable recommendations at this point. But even with a low number of attempts (lets say 3 just for fun), I bet I could script something to get into at least 25% of your user base. What are these magic pin numbers?

1234, 5555, 1111

Yup, that’s some 13373 H@x0r shiznit right there. And if I have more login attempts, lets try the last four digits of the mobile number as the pin. Oh, that mega-hurtz now!!! For the sake of security, we need something stronger than an all numeric pin. Maybe it’s in the form of one time token over SMS, or maybe just a decent password multi-tap box for now (I saw this well done on the Blackberry Pearl recently). If you know of any other good solutions to this issue, drop us a line. I’ll be talking about this and more mobile security issues next week at the NJ/NY OWASP meeting.

-b3nn