The thing that jumps out at me regarding this patent application is the fact that RIM is certainly becoming more consumer friendly.  In the country where I reside at the moment, one thing is apparent.  BlackBerries rule.  I have seen teenage girls in malls who have their faces buried in their BlackBerry.  I have also seen the regular business user owning not one but two.  It is easily the most popular phone sold here.  While corporates praise RIM for their security, consumers will not feel the same way.  In my brief, personal experience with alleged power-users, I came away feeling like no one really understood security at all.  This will most likely multiply with regular end-users.  So, in an effort not to appear too anal, RIM seems to have decided to provide a way for a user to remember his password.  Of course the patent refers to “unique version data” and remains fairly nebulous on what it can be.  In it’s patent application, RIM states that this unique data can be a date, integer or string.  It might be that the end-user will have the ability to configure an option like “prompt me with the 3rd and 8th character of my password”.  I know the maximum limit for incorrect passwords is no more than 10.  I still think it won’t be possible to guess a password in 10 attempts.  Thus this is quite a good move in helping make the device both secure and consumer-friendly.  I expect they will roll it out in one of their next OS updates.

1. You don’t know if your “Input Simulation” permission is set to “Allow”.  If it is allowed, any application can make key-presses on your handheld as if they were you.  Potential: an application can answer your phone calls.
2. You’re not sure your “Security Timer Reset” permission is set to “Allow”.  If it is, then any application can render your screen lockout useless.

I can almost hear you asking me, “Why tell me about it? You think I don’t know about this?” and the truth is, its an even split.  There are users out there that are blissfully unaware of things like Default Application Permissions.  The BlackBerry is going the way of the consumer, and fast.  With the rise in popularity of the BlackBerry Internet Service, a user no longer needs to be a part of an large organization to reap the many benefits of a BlackBerry.  The flip side?  There is no enterprise security administrator or policy to protect these users.  Thus when they decide to go with BIS, they take on the task of remaining secure.  For a second, leave these users out of the picture.  Pick the other half of the users who are aware.  Suppose they set some permissions and then forgot about them?  Maybe they allowed access based on an application requesting them to do so and they never set the permissions back.  What then?

I thought about this and came up with a solution of sorts.  Why not have a list of the most important security permissions and check them at a timed interval to see if they have been changed?  If they have, then send the user an alert.  Here’s the code I came up with:

package com.zensay.sectest;

import java.util.Timer;
import java.util.TimerTask;
import net.rim.device.api.applicationcontrol.ApplicationPermissions;
import net.rim.device.api.applicationcontrol.ApplicationPermissionsManager;
import net.rim.device.api.system.Application;
import net.rim.device.api.system.Bitmap;
import net.rim.device.api.ui.Manager;
import net.rim.device.api.ui.Screen;
import net.rim.device.api.ui.Ui;
import net.rim.device.api.ui.UiEngine;
import net.rim.device.api.ui.component.Dialog;

public class Main extends Application
{
    public static void main(String args[])
    {
        Main app = new Main();
        app.enterEventDispatcher();
    }

    public Main()
    {
        TimerTask tm = new TimerTask()
        {
			public void run()
			{
				reqPerm();
			}
        };
    	Timer t = new Timer();
        t.schedule(tm,10000, 10000);
    }

    public void reqPerm()
	{
		ApplicationPermissionsManager apm = ApplicationPermissionsManager.getInstance();
		int input = apm.getPermission(ApplicationPermissions.PERMISSION_INPUT_SIMULATION);
		if(input == ApplicationPermissions.VALUE_ALLOW)
		{
			synchronized(Application.getEventLock())
			{
				UiEngine ui = Ui.getUiEngine();
				Screen screen = new Dialog(Dialog.D_OK, "Input Simulation is allowed!!",
						Dialog.OK, Bitmap.getPredefinedBitmap(Bitmap.EXCLAMATION), Manager.VERTICAL_SCROLL);
				ui.pushGlobalScreen(screen, 1, UiEngine.GLOBAL_QUEUE);
			}
		}
	}
}

To explain it a little bit, the code (when compiled, signed and executed on your BlackBerry) will check your “Input Simulation” permission.  If it is set to “Allow” the application will pop open a message window and notify the user.  It does this every 10 seconds.  Its annoying as hell, but I think you get the general idea.  I tested this on my Bold and it works very well.  I’m thinking about making it an additional feature in Kisses; with a slightly longer timeout of course.  Its a feature I would find useful.

The Security Timer Reset permission is set to Deny by default.  This is good.  Be wary of applications asking you for Allow permissions on this.  One of the things you can do with this permission enabled is to delay your lock screen.  Indefinitely.

The lock screen usually appears when your Security Timeout is exceeded.

Device Lock Screen

For example, if you have a Security Timeout set to 2 minutes, your screen will lock automatically and you will have to enter your password to access the device again.  This is handy to have, if you leave your BlackBerry on your desk at work and are afraid someone will pick it up and install nasty stuff on your BlackBerry.

Security Timeout

Let’s take the case where you download a malicious application (you don’t know its malicious of course).  It is such a compelling one (read: porn slideshow) that you just HAD to download it.  Now the application innocently asks you for the “Event Injection” & “Security Timer Reset” permission to ‘advance’ the slides back and forth.  “Sure”, you think, “no problems there now is it?” and you grant Allow access to the application.  What this application could do is to then inject a key event every 15 seconds.  This can be done so that you don’t notice.  When this key event is injected every 15 seconds, its as if you are moving the trackball or clicking a key.  This delays the device lockout because the timer is reset every 15 seconds.  The device will now never lock itself out.

So be wary of granting Allow Permissions on almost everything.  I know UberTwitter is an application that asks for a lot of Allow permissions (although it doesn’t ask you for the Security Timer Reset permission).  I think it might be worthwhile starting a Permissions Hall of Shame on my site, just to list such offenders.

Permission Change Request

Allow All

...like really!

Knowing the APIs of the BlackBerry, I can confirm that this will work only if and when a target has conference calling enabled.  The theory is simple again.  The application hooks the “callConnected” method on the PhoneListener class.  Then when it detects a specific number that has been specified, it sends an SMS to a pre-defined number.  Once that same pre-defined number calls in during an active call, the phone automatically answers and adds the user into a three-way conference.  So its dependent on the target and his phone plan.  Thus this feature is not a guaranteed one.  One thing I plan to try out is to see if the target will actually hear the call-waiting tone before the third call is connected.  Here’s a graphic that explains how it works:

Bob calls Alice on her bugged phone

Alice's phone sends an SMS to Charlie

Charlie calls Alice's phone & is added to the conversation

In the scene above, Bob is a friend who calls Alice.  Alice has had her phone bugged by Charlie.  Charlie wants to listen into conversations between Bob and Alice.  For this to work, Alice needs to have the ability to make conference calls.  This is typically a value-added service from the mobile network operator.  Thus this attack is dependent on Alice having subscribed to such services.

Like all the other things, I’ve written about, I need to conduct some more research on it.  I’ve been busy these days with the day job and my research is taking a back seat.  Sad really.  Maybe its time to look for a job that pays me to do this stuff??  If you want the tool that lets you test out how you can remotely listen in on ambient noise and conversations, look here.

Before I released the tool, I had a lot of people asking me if it will detect the FlexiSpy program.  While I didn’t want to spend close to $200 just to find out if it does, I am very certain that Kisses can detect it.  How do I know? Because Kisses will probe 2 areas of your handheld:  1) All running processes belonging to all applications on your handheld 2) All installed applications regardless of whether they are hidden or not.  This gives you an idea of exactly what is running on your handheld at any one time.  By letting you drill down further, you can discover more details of each application module.  With these capabilities, you’re bound to find not only FlexiSpy, but other bits of spyware  or suspicious applications as well (provided an undiscovered variant exists).

This is a project I’m very keen in and will be actively pursuing its upkeep.  I have a whole list of enhancements and features to add to it.  You can check the website for updates.  Alternatively subscribing to this blog, following me on twitter or LinkedIn will also keep you updated.

I took a look at the new BlackBerry version 5.0.0 Operating System API.  RIM is offering the simulator and development kit as a Beta release and I think the OS has already been leaked online.  One excellent feature that RIM have added is the CodeModuleListener.  This interface allows a developer to design an application that knows when applications or modules are installed, deleted or scheduled for deletion on the handheld.  Its got three methods:

1. moduleDeletionsPending()
2. modulesAdded()
3. modulesDeleted()

Once implemented correctly, you can look at it like a security guard that sits in front of a room, guarding the door.  Nothing is allowed into or out of the room without the guard knowing.  Once the guard knows somethings coming in, he can call up central that tells him what to do next: block the entry, for example.

I plan on implementing this interface in my Kisses application; most likely in a later release as most of my code is ready to go and I’m only testing things out right now.  Once completed, Kisses will not only be able to detect hidden processes and programs, but it will also be able to warn you when something is either being installed or removed from your handheld (that is, only if you have 5.0.0).  You can jury rig a similar set of functionality, but you’d have to write a lot of code for it and even then, it won’t be as real-time as using CodeModuleListener so I’m not going in that direction.

The trick is, that it can be a double-edged sword, though.  If an application can use this feature for good, then an application might be able to use this feature for evil purposes as well.  It requires a bit more research and I’ll share the results here.

I first blogged about PhoneSnoop, a component of Bugs, a few days ago.  PhoneSnoop demonstrates how a BlackBerry can be used to spy on its owner.  It cannot listen into phone conversations or conduct phone taps on BlackBerry handhelds at the moment.  It is, however, possible to add a feature that makes phone taps work.  I have written more on how to tap phone calls here.  FlexiSpy is offering this service in its new version.  Incidentally, I took apart FlexiSpy and wrote a brief post on it.  While the BlackBerry remains one of the more secure devices out there, user awareness and education is paramount to remaining completely safe from spyware.  I tweaked the application since my first post now allowing anyone to download, install and try it.  PhoneSnoop now has the ability for a user to customize the ‘trigger number’; rather than me having to give out customized versions.

Download PhoneSnoop and take a look at the User Guide

“You can’t compromise an application using XSS”

Before I open up this can of worms, I can tell you that both vendor and client have told me this.  I then try to explain to them how things are generally interwoven and connected to each other and how you CAN own an application through XSS if done in a correct manner.

With XSS, you usually end up owning the USER of the application and thus can build up on your attack.

“You cannot alter any data using XSS”

With a reflected XSS attack, yes, you cannot change any stored data on an application.  You can, however, change the User Interface significantly.  You can swap out an entire page using a reflected XSS attack to make a user think he is on another screen of the application.  Like the login page for example or injecting an iframe.  The only catch is that you have crafted this login page using HTML and JavaScript and have presented it to him as if it were part of the legitimate site.  The login form sends his password to a server you control, but nothing is altered on the application database to begin with.

In the above examples and all cases of XSS, one thing is common.  The scope of this vulnerability is confined to that of the application user.  You do not use XSS to attack the application directly.  You use it to attack the user and indirectly attack the application.  So an XSS is more comparable to a pseudo social-engineering attack where you are tricking the user into revealing his credentials (enter his password on a crafted password screen or stealing his cookie).

The easiest way I find to present an XSS vulnerability, even before I put it in a report, is to call all the project stakeholders into a room and demo it to them.  I tell them that I have some findings to share with them and would like a few minutes to show them a live demo.  I then load up the application page that they are all familiar with.  Open up my email client to a received message[1], click on the XSS laden link[2] and show them a perfectly legitimate login screen of their application.  I log in using credentials I was given and then continue to access one of the application’s functions as normal.

After a few seconds, I stop and tell them that I was just a victim of an XSS attack.  Then I move into the technical details.  I find this approach to be quite effective[3].  It raises awareness in a way that the client can relate to.  What they perceive to be a legitimate session turns out to be an attacker controlled phishing attack of sorts.

[1] I create this message and send it to myself to simulate a company employee receiving an email from another person.

[2] I sometimes obfuscate the link, but usually I use HTML mail to show them an underlined “Click Here” phrase when the actual link is a stager.  I send an include (hex encoded <script src> tag) to a remote JavaScript file that contains the code to render the fake login page.

[3] My setup includes a remote site under my control where I host the malicious, custom written JavaScript files.  I have a backend script to pick up the posted information and send me a neat little email containing the cookie (if any), username and password and some other relevant data.  If one of the executives has a connected laptop, I will invite him to try it himself.  In the early days, I would send the link out to all the application users first by spoofing an internal email.  Then, I’d compile a list of the users affected and share the information with the executives in the meeting.

I’ve had more positive responses using this approach than trying to put it in the report only to have several opinions thrown back from the client and the vendor that show a lack of knowledge on the subject.

XSS attacks are very common and can be used to great effect.  I am not alone when I say that XSS is very badly misunderstood and the threat that it poses is often ignored.  I think a hands-on approach of this nature, even though it takes more time and effort, is worthwhile in spreading the word.  Sometimes, you just have to spend the effort to demo your vulnerabilities to put things into context.  Your clients will appreciate it and remember it more than just reading a report.

Now, onto the unsurprising stuff.  I’ve been onsite in Oil & Gas exploration and production plants in the Middle East.  They’re quite impressive plants run with the strictest of controls and paramount importance given to health and safety.  As a security consultant, I was, however, appalled at the lack of security awareness the plant personnel have.  Understandably, this is to be expected.  The plant production teams have only one thing on the mind: ensure the plant functions and production is not hindered.  Availability is paramount.  Security is secondary.

In a SCADA* environment, there are two major domains.  The Production Domain is where you’ve got all your components like the Control System, Remote Terminal Units and/or Programmable Logic Controllers, communications network, Human Machine Interface and the Data gathering system.  The Enterprise Domain is where you have all your daily supporting infrastructure.  So your Microsoft Windows Domain, file servers, print servers, etc will reside here.  Your Internet connections will also reside here; so people can browse and check their email.

* I’m referring to SCADA here to encompass everything.  Including the DCS, RTUs/PLCs, HMIs, network, etc.

I don’t care what anyone says, these two domains need to be kept separate; at least until there is a much better understanding of the technology and security within the SCADA environment.  There should be no reason why the two have to ever touch.  Sadly, this is still something that has not begun to filter down to the various companies owning and operating such large scale critical infrastructures.  During my project in the middle of the desert, I had first hand experience where these two domains were hopelessly enmeshed.  As a matter of fact, I was there to separate the two domains by using a firewall. I collected a considerable amount of data.  A high percentage showed well known virus and worm activity on the network.  So here are the reasons why you should segment your SCADA networks.

Reason 1: SCADA Computer systems run older patch levels of operating systems

SCADA system vendors design and develop their software based on a specific revision of an operating system.  If you are running different versions of the operating system, older or newer, they will refuse to support you.  Well, they will insist that you bring your OS revision down to the correct version before going any further.  This is not something uncommon, I’ve seen the same setup in the Banking industry where Internet Banking system or Core Banking system will depend on specific versions of Oracle or Tomcat.  If you run a different version the vendor says, “Well, we don’t really support that version.”

In most cases, vendors of such software will never be able to keep up with the incessant flood of updates and security patches to operating systems.  Bottom line, you will always be running an older version of an operating system which will be prone to publicly disclosed vulnerabilities.

By segmenting and keeping this set of unpatched systems away from the high-threat environment of the Internet is plain good sense.  Sure, its not the ideal situation (like having a patch management system in place), but its a start.

Reason 2: SCADA system operators will not know not to click on that link in the email

Take the case in eWeek with the energy company.  One of the operators fell victim to an email asking him to click on the attachment.  As I stated before, the production or process team guys are only interested in production.  SCADA is a vast, specialized and complex subject.  You can spend quite a while studying its myriad of topics and subtopics.  The process team guys are not going to spend any extra time getting to know topics on information security.

I believe that there should be a security awareness project that is more or less entwined into the everyday lives of the operators – much like you have a health and safety program.  However, that’s a topic for another post.

Splitting the two areas will act as a barrier between a compromised operator’s PC and the sensitive production servers.

Reason 3: The inconvenience provides a grounding on the topic of security

Having to shuttle between two PC’s to do ones job is a pain in the ass.  I’ve done it before.    Back when I was working at one of the Telecommunications providers we had a PC for the corporate network (no Internet access) and a PC that was capable of Internet access.  I still think that in my case it was stupid (although the corporate network never suffered any external attacks), but in a SCADA environment, it will give the operators an idea of how important it is to have distinct networks like this.  It sets the foundation for rolling out a SCADA security program.  (It really looks like I need to write that topic in the future.)

Lets face it, the vendors will care about security, but most likely not to an extent where it is attended to in minute detail.  Further, vendors doing security is usually a recipe for failure and a conflict of interest.  I’ve seen at least 7 banking systems fall victim to this.  You need to have your systems audited by a third party if you are to have a true picture of how capable you are of withstanding attacks.  Having said this, jumping in and hacking a live SCADA network is an even bigger recipe for disaster.  The approach to SCADA security should be a carefully built one.  I will cover more topics on this in a future post.