The OpenMoko project ( http://www.openmoko.org ) has “freed” the cell phone. OpenMoko is an open development platform with complete hardware specs (as complete as possible) that runs linux, can be recompiled from scratch from source code, and operates as a normal “unlocked” cellular device. This news isn’t new, but it is the first time I’m writing about it.  The openmoko team actually released their second version of the cellphone hardware earlier this month (called GTA02 but nothing to do with the video game) with some significant new features including WiFi and accelerometers.

If you are like me, then you remember seeing the word “linux” in the hallowed directory listings of ftp.cdrom.com circa 1994 and thinking… hey what’s this new word? A few hours/days later, after borrowing a laptop from the school A/V department, getting comfy trashing the existing operating system fdisk style and loading slackware from a lot of floppy disks, you were greeted by a fully-bootable operating system that measured its speed in BogoMips and could do most of the things the computers in the Sun lab could do  except that you were root (legitimately).

So now we’ve had Linux for a while, its used all over the place and is a system that people seem to have gotten pretty comfortable with.  This level of ease and comfort is now available in the form of “the device you take with you everywhere” …your cellphone is now just a little linux box.  Why is this cool?  Because now I can talk to my friends, and ssh into my server from my cell phone (or vice versa).  Oh yeah, and do all that other stuff that Linux does, like run Apache, FTP, NFS, torrent, or scan your systems with Nessus (theoretically).

The OpenMoko project has already suffered/gained from the normal Linux way of things and there are a few different distributions available.  Developers being the way they are have splintered off from the official OpenMoko distribution and created their own distros already.  One in particular, an “Underground” distro has even gone so far as to scrap X11 for windowing and use the framebuffer directly.  The wheel gets reinvented once again.  Hopefully this time with built-in battery powered spinners.

There are numerous ways this little toy could be used for security testers. Since it has both WiFi and can use the GSM networks (AT&T and T-Mobile work ok in the states), this would make a nice little remote access device.  All you need to do is leave it in the proximity of a location with WiFi then dial in (pppd) from across the world or anywhere cellular data connections can go (if you don’t like the idea of being in physical proximity of your targets or aren’t good at talking to beefy security guards who wonder why your laptop is beeping.) Alternatively, since it has USB, plug into a corporate computer, then dial in from the cellular side and route through newly-befriended corporate system. The possibilities here are numerous. GPS-activated, bluetooth aware, motiondetecting wifi gprs connection machine…

All in all, a cool device.  Stay tuned for fun stuff to do with it.

- theOtherAaron

Those who have worked with me, or at least had a beer with me, know my feelings on web based SSL VPNs. They are very useful, very complicated, and can be very insecure. Useful because they allow a mobile work force to connect to the enterprise from any computer with a web browser; complicated because they need to do so with minimal inconvenience to both users and network managers; and insecure because this convenience is achieved through automation.

The automation starts with the browser based installation of client side components (ActiveX/Java applets). Network teams, management, and help desk personnel alike, love the fact that users can get the required client side software simply by visiting a web site. Once the components are installed, they can even maintain themselves by automatically download and installing updates and patches! Hallelujah!

Unfortunately, this type of behavior can be easily abused as Haroon from Sensepost has revealed. He disclosed a vulnerability in a Juniper SSL VPN ActiveX control that allows an attacker to execute code on a victim machine by getting them to view a malicious web site. The vulnerability is simple to exploit; the malicious web page invokes the ActiveX, calls one of its functions, and the ActiveX sends an HTTP request to the web server asking for commands to execute on the client machine. No stack smashing required!

Funnily enough, I reported an almost identical vulnerability to another large SSL VPN/firewall vendor. This other company makes it even easier. Instead of requesting a string of commands, their ActiveX will request, download, and execute an attacker supplied .EXE file. No signature checking or anything. Altogether, I have knowledge of these types of vulnerabilities in 4 of the leading SSL VPNs. Details will be discussed pending responsible disclosure.

We all know that SSL VPNs have similar features – you can spend days comparing vendor product descriptions. What I find interesting, and have spent much time researching, is that while SSL VPNs from different vendors share the same features, they also share the same vulnerabilities in their application logic. This research has provided most of the material for my upcoming talk at BlackHat 2008, “Leveraging the Edge: Abusing SSL VPNs”.

My talk is in the network track, but a lot of what I’ll be talking about is purely application security. This is funny to me, because during my time at Whale Communications (a Microsoft subsidiary) supporting Whale’s SSL VPN, the device was usually managed by network people who were not versed in application security at all. The “networking” (and security) in SSL VPNs terminates with the SSL connection. Beyond that, abusing gaps in access control, and other areas of application logic, can provide an attacker with all he needs to compromise clients and the networks they connect to.

-Schmoilito

A few weeks ago I was grabbing a couple of beers in town with my buddy, John. We had a couple of rounds before John noticed what he thought was a Nintendo Wii sitting at the back of the bar, next to a cash register/point-of-sale terminal. It definitely was a Wii, but even more interesting to me, was a wireless access point right next to it in plain site.

John was probably excited at the possibility of playing Guitar Hero. I, on the other hand, wondered if the Wii and the cash register terminal were all on the same network, along with the WAP.

After a few more drinks, I developed the following equation:
Wireless Access Point + POS terminal = free beer

I pulled up the list of the available wireless networks on my Iphone, and sure enough there was one with the name of the bar. Unfortunately, it was encrypted. Time to break out the social engineering skills.

Me (to the bartender): “Hey, I’m trying to show my buddy my blog on the Inter-”
Bartender: “Oh! You need the password! Hold on one sec, let me ask the manager.”
…1 minute later…
Bartender: “Try clubbarroom”
Me: “That worked. Thanks.”

I didn’t go any further at that point, since that would be unethical. My buddy was also already impressed that I got the password without even directly asking for it.

However, I couldn’t help but wonder what kind of data is actually at risk. They obviously swipe credit cards on those point-of-sale terminals. I’m also sure that the bar doesn’t have a security budget or staff, other than the human firewall who was checking ID’s at the door. If credit cards could be stolen from T.J. Maxx, why not a rinky-dink bar in Hoboken?

I don’t need to wonder so much any more. On Monday, news agencies started reporting that three men were charged with installing packet sniffing software at a number of Dave & Busters locations here in the U.S. From one location near me in New York, they were able to obtain 5,000 credit/debit card numbers.

Obviously, companies that do business on the Internet need to be aware of security issues surrounding credit card transactions, and many are well aware that they need to be PCI compliant. But what about small brick and mortar shops, bars, restaurants, etc? They think they are immune from all this hacking/identity theft non-sense because they don’t take credit cards via a web site.

Hacking one large online retailer like Amazon may prove lucrative, but could be difficult and dangerous to pull off AND get away with. Small businesses on the other hand, lack the technological expertise to protect themselves. While each target individually may not contain the wealth of sensitive data that an Amazon or eBay has, these soft-targets, collectively, could be just as lucrative.

-Schmoilito

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