Mobile Device Management Limitations

Current MDM frameworks, unless using some kind of container approach, will always play catch-up to hackers wanting to bypass the controls enforced to their phones, as highlighted in the following article describing how to get around Airwatch’s MDM restrictions.

The conclusion of that article is spot on:
MDM solutions are great for employers to manage mobile devices. However, they are not without their problems. Not only was I able to bypass compliance for having a rooted device, but I was also able to bypass the need to encrypt my device from the profileGroupSetting table. Bypassing compliance restrictions for AirWatch is relatively trivial after a few hours and I’m sure it is probably similar with many others MDM solutions.

An MDM container approach will only ensure your corporate data does not leave that secured container and stays safe within it. However, it does not ensure trojan/malware installed on the Operating System host has not made that hosting environment so “toxic” that low level API haven’t been compromised, i.e.: Bluetooth connection to a keyboard, ability to screenshot, access to memory, etc.

This is why a real improvement on today’s MDM solutions, will only occur when provided natively to the devices and offering OS level containers with specific containers/profiles according to the level of security required. One that needs to be provided through and by Apple/Google. Until then, MDM will just be a nice add-on that improves security against common miss-use but not against seasoned hackers. Depending on your business requirements, today’s MDM could be just enough!

The right (way) to disclose vulnerabilities

An article was discussed last month in The Guardian and The BBC explaining how a research paper from the University of Birmingham had been barred by a judge from being published because it discussed weaknesses in the security related to cars starting mechanisms from many manufacturers (BMW, Porsche, Fiat, Peugeot, etc).

This was already discussed publicly at the 21st Usenix Security Sympposium, where an online video is available. A quick search on Google also produces a PDF paper explaining how a car can be gone in 360 seconds through hijacking car key transponders. If that was the paper stopped from publication, then I don’t think it provided enough details that warranted those legal actions.

This opened a debate about free speech, the right to do and publish research versus responsible vulnerability disclosure.
But what is a “responsible way” to disclose vulnerabilities? It seems the common consensus among white hat hackers and researchers is about giving time for the vendor/manufacturer and eventually publishing the vulnerabilities. “Time” is usually 6 months, after which most hackers/researchers will argue the vendor is not reacting fast enough and for the greater good the vulnerability should be published to kick those vendors into action.

But is it really always for the greater good?

In this recent car hijacking example, the researchers have indeed notified the car manufacturers and very little was done 6 months later. All those cars could be hijacked in a few minutes with their knowledge of the vulnerability (and the right RFID equipment), so by publishing a paper describing how this could be done it would force those vendors to finally fix that flaw. But it would also give further knowledge to criminals to potentially steal cars!

How this could be considered responsible disclosure? putting further pressure on vendors, yes. But facilitating in the process further criminal activities, maybe not.

Being responsible in disclosing vulnerabilities is not just about waiting a set amount of time, it is also considering the impact this could have on all the parties involved, including the end users! And therefore trying to balance the need to put pressure on the vendors whilst still protecting users from a given vulnerability, isn’t it the main goal to do the research in the first place?

It is human nature wanting to shout to the world our accomplishments, our Eureka moments, discoveries we feel will have a major impact, etc. That “responsible disclosure” principle goes in the way of this urge to claim/inform others about what is important to us; taking the time to reflect on it is therefore often lost in the process.

A story about Password – The Wrong Formula

In this article I will first talk about some misconceptions regarding what is considered a secure password and then about how you can leverage different technologies to help protect your different credentials.

In the past few years there has been a sharp increase in websites being hacked and their users’ passwords/hashes stolen, in parallel we are using online services for almost everything: to pay for your local pizzeria delivery or your electricity bill, access your bank account, connect to your work email, etc.

The common advice is to use different passwords for each site you register to, but most people don’t. It means that hackers can often reuse credentials they obtained on one website to access another.

One way to counter that risk would be to use some kind of formula so you remember a different password for each site you have registered to. This *could* be the best solution, as remembering a password formula means you do not have to write it down. However, the question is how secure your formula really is? How easily could it be reverse engineered? It may not be possible for an attacker to do it with knowing only one password, but what about 2? or 3? or more? would a pattern start to emerge?

Let’s take an example of a simple password formula, by taking the first letters of an easy to remember sentence tailored to a given site, in this example:

I Love My dog And I Like Google since 1997

The password would be: ILMdAILGs1997

At first, this looks pretty good… especially if you start adding punctuations and special characters.

But if you use the same formula somewhere else, this time for, the password would just have one different letter: ILMdAILYs1997

Even if you were to make your password “expire” by changing the last number on a regular basis, I.e. each January, a pattern would still to be easily identifiable if an attacker gets hold of several of your passwords…

Of course, this means someone would need to get your credentials from different sources, Google and Yahoo in this example. But the point is that with the increasing number of websites we subscribe to, we are also increasing the chances that our credentials get stolen and patterns get discovered.

Passwords need to be unique to each system they are used on and they need to be as random as possible.

Not writing your password down but remembering it feels like the most secure solution. Until you look a bit deeper at how all your different passwords are constructed and realise they are not truly random and unique…

The best way to use unique, random and strong passwords is to save them into a password safe, a software that acts as a safe for sensitive information by storing it into an encrypted database. All your passwords are then protected by a master key/password.

Password safes are not new, in fact one of the most popular has been around since 2002.

But what is new is how you can achieve the following requirements, so you do not compromise on usability:

– Passwords need to be accessible from all your devices;

– Passwords need to be backed up securely;

– Passwords need to be easy to reset.

This is where Cloud storage can help you.

You can use PasswordSafe from Sourceforge to create an encrypted list of strong passwords and store that list onto a cloud storage service such as Dropbox. Then synchronize that Dropbox folder/file on all your different devices.

Because PasswordSafe and Dropbox can be used on most operating systems and platforms, including mobile devices, you will be able to access your passwords from anywhere. More importantly, you will also be able to synchronise any changes from anywhere, securely.

You do rely however on how secure the implementation of Password Safe is on the different medium you install it and if someone installs a key logger on your computer then you could lose access to all your passwords!

The only password you need to remember is the master password to your safe which should not be reused anywhere else.

Evernote hacked, an early warning for the Cloud Storage storm coming?

In recent years I have written various articles warning of the risk related to uncontrolled cloud storage solutions usage in the corporate world.

Evernote is a popular online note storage solution which is often used by mobile users. You could see it as a cut down version of Dropbox as it is more restrictive to what one can store online.

It got hacked a few days ago, as reported by the Verge, what was stolen includes usernames, email addresses and encrypted passwords. We don’t know what password algorithm they used and how hard/easy/feasible it is for the hackers to crack them, but the company behind Evernote now asks *all* its (millions) users to reset their passwords.

This should really serve as a wake up call, to check what policies and controls are in place to prevent your users to transfer all sorts of corporate documents outside of your corporate security controls. If Evernote is used within your company, and those passwords were cracked, how different would it be from having those users loosing unencrypted USB sticks or unencrypted laptops containing corporate documents? Not all users would have access to sensitive data, but those who do should certainly not be free to use any cloud storage solutions they like without extra security controls.

With the increase popularity and demand of BYOD and Mobile Devices, are you restricting your HR, VIP, Financial department users when it comes to syncing data in the cloud? do you know what data is leaving your company to Dropbox? Skydrive? GoogleDoc? … Evernote?
If you don’t, now would be a good time to find out… before a government data privacy agency asks you!

A new iOS 6.1 hack

As seen on the Hacker news, there is currently a way to bypass the iPhone lock screen (iPad with SIM too?) running iOS 6.1.x

I had to change the steps listed in “The Hacker news” slightly for it to work:
-Go to emergency call, push down the power button and tap cancel.
-Dial 112 and tap green and inmediately red.
-Go to lock screen, by pressing the power button
-Go to passcode screen, by pressing the home button
-Keep pushing down the power button …1…2…3…seconds and before showing the slider “turn off”…tap the emergency call button and …voilá!
-Then without releasing the power button press the home button and let go…

From there you gain full access to the phone application and can change/add/delete contact, as well as use the phone to make phone calls but you cannot stop a call you started with that technic.

YouTube Direkt

Mobile devices security, history repeating itself: Harder, Faster, Stronger but not Better!

Following up on my SANS 575: Mobile Device Ethical Hacking course review, below is my take on the current state of Mobile Devices security.

First, let me define what I mean by mobile devices: Smartphone and Tablets, not laptops. Although laptops are “mobile” the level of security available to them is more mature and not in scope for this article.

Then, let’s dive into the past and where mobile device security fits.
Right at the start, when computers where used and interconnected, the security element of it has always been the last “add-on” and security professionals had to play catch-up. This was true with Intranets, where no or poor defences meant companies were often heavily relying on physical security, i.e.: no hackers will be allowed within the premises to connect their portable desktops. The realisation that staff could also be hackers and the arrival of laptops meant better IT access controls were put in place.
When Internet started to pop-up in every houses and sometimes under office desks, companies soon realised they had to connect their corporate networks to the Internet and leverage that powerful communication revolution. But again, the rush and lack of security technology maturity meant this was often done with the wrong or mis-configured controls in place. Security controls’ configuration, update and monitoring were done in a reactive mode rather than having been carefully planned, implemented, budgeted and allowed to be cared for.
Then WIFI/Wireless technology started it all over again, WIFI hotspots started to pop-up everywhere, uncontrolled, mis-understood and mis-configured. Even now, many companies are still trying to improve on their WIFI offering security or just running an insecure wireless infrastructure.

Today, we are seeing a similar trend to the consumer market, where companies are made to consume technology faster than they can digest it.
This is driven both by the consumerization of the work assets and by the promise of new technologies giving companies an edge.

The use of smartphones and tablets in being forced fed onto most companies. Forced, because this computing technology is no longer the exclusivity of a working environment, we are using it at home and have expectations. And also because the previous technology advance allowed for remote working and those mobile devices just leverage what is already there!

But history is repeating itself, and to use some famous DaftPunk Lyrics it is doing it “Harder, Faster, Stronger”… but not “Better”!

1. Harder:
The impact is harder.
All corporate data is now digitalised and accessible somehow from the Internet, through VPN, Bastion hosts or web portals, from chat logs to financial market modelisations. Computer systems are now critical to companies, if they become unavailable, compromised or corrupted this would severely impact employees’ ability to work.

2. Faster:
This is happening faster.
2G yesterday, 3G today, 4G/NFC tomorrow. All with their own weaknesses and vulnerabilities.
Every year sees new mobile device architectures. They are not just iterative improved updates, they often introduce new hardware, new firmware with new functions. This is true from the supporting mobile network infrastructure down to the handsets themselves. Let’s take iOS 6.0 for example, it allegedly fixed about 200 security issues but also introduced hundreds of new features! Not only those new features could have introduced new security vulnerabilities but it also means previous hardware that cannot upgrade to 6.0 are vulnerable to 200 security issues.
Other manufacturers are not better, with some Android phones having a shelf-life of just 6 months in terms of updates!

3. Stronger:
The drive is stronger.
As mentioned earlier, the use of smartphones and tablets are being forced-fed onto most companies.
This pressure to use new technology at work not only comes from the base but from the top of most organisations, this makes the matter worse. It usually means it has to happen yesterday and to happen anyway with very little time for careful planning, design and implementation. In fact, most of the time when security teams start to get involved it has already happened!

There are 3 ways for a technology to be securely implemented, all complementary to each other:
– The best is for it to be secure by design;
– A good approach is to take the time to review and understand it before designing its implementation through pilots and testing;
– The minimum is to review its implementation security through pent testing, on-going monitoring and the all so important care and feed (updates, roadmaps, etc).

When it comes to mobile device security, this is a very new and immature area. My advice is to act NOW and to start setting-up your mobile device security task force if you don’t want to play catch up for the years to come:
– Communicating/Educating your users to the risks associated with the use of mobile devices is a low cost, light and fast way to improve their awareness and behaviours.
– Implementing a Mobile Device Management solution is a must to gain some controls over what and how corporate data is accessed from mobile devices. At the very least it gives you a framework to move forward from.
– Having an Internal Apps review capability will allow for guidelines to be provided on how corporate data should be accessed and stored on such devices and it will help driving security by design. Also, being able to assess Apps’ security before they are being published will give this extra assurance that those guidelines were indeed understood and followed.
– Having a 3rd parties Apps review capability will allow assessing the most common used apps or those 3rd parties apps used to access corporate data. This will help limit the risk of data leakage or malware attacks.
– Monitoring your network and infrastructure for specific mobile malware activity will help detecting any on going attacks against your users mobile device.

The point is that mobile device security is an area that must be taken very seriously, it should not and does not stop with MDM.

SANS 575: Mobile Device Ethical Hacking Review

In the last two years I have been to a few SANS training courses:

508: Advanced Forensic
617: Wireless Ethical Hacking
660: Advance PenTest

Last week I attended the SANS 575: Mobile Ethical Hacking course,
it is a nice complement to the 617 Wireless course and although there is some overlaps, especially around WIFI vector attacks, most of the content is different; and when it is not, you get another perspective for those attacks.

The course gave an overview of the different architectures surrounding the Android, iOS, Blackberry and Windows Mobile phones, how system and app updates are handled, how certificates are managed, attack technics against mobile apps communications as well as against the app code itself through leveraging jailbreaking.
As with most SANS courses your day is not limited to a 9 to 5 schedule and if you want to make the most of it you will end up attending after class presentations or the Netwars hacking contest during the last 2 evenings. Although this means you are most likely to finish your day at around 10pm, you also end up learning a lot more than what is just taught in your course.
Finally, the last day there is a Capture The Flag event in your class where you compete against your fellow students in teams of 3 or 4. It is a great way to apply all what you learnt during the week. It is very similar to Netwars but tailored to the topics you have just been studying .

Below are my key takeaways from that course:
1. History keeps repeating itself.
I will go into more details in a future post, but all the security issues we have had when Internet first appeared in the corporate world, then with WIFI networks are just repeating themselves with the use of mobile devices. Examples?
Mobile devices are more and more like computers yet we tend to only use simple and short passwords to protect how we are accessing them, there are no antivirus or firewalls in most platforms.
What drives mobile devices’ roadmaps is the user experience rather than its security.

2. Jailbreaking as a security tool
Jailbreaking a phone can be very useful, and sometimes the only way, to really understand what data an application is accessing and sending.

3. MDM alone, is not enough
MDM is just one component of what a mobile device strategy should be. Reviewing the security of apps being developed internally as well as the most commonly used 3rd party ones should be core to that strategy. Failing to do so equate to having an open desktop policy where users can install any applications they want, with no firewall/anti-virus.

4. Apps manipulation through HTTP intercept
The majority of mobile device applications uses HTTP as their communication transport protocol.
It often compromises the security model implemented with their counterpart desktop/web portal solutions.
Users often wrongly assume that an application is secure, because there are no visible signs as to how secure its communication is.
An example studied in class showed easily it is to manipulate stock option prices from the built-in iOS Stocks app.

5. 4 PIN on iOS is bad very bad.
I was amazed at the speed it takes to crack a 4 PIN protected iPhone (up to iPhone 4) and iPad (up to iPad 2).
In class we looked at how one needs just 15 minutes to a) take a locked iOS device, jailbreak it in memory, crack the PIN, dump all data, reboot the iDevice and the owner would never know you have just stolen all its data.
Although this is not currently possible on iPhone 4s+ and iPad 3+, this could change if new jailbreaking methods are found.
You would also be amazed as all the potential sensitive information is available in clear text, from WIFI to Emails passwords.

6. Certificate (mis) management
HTTPS certificates are very poorly managed on mobile devices currently and if a user is subjected to an HTTPS Man in the Middle attack, the warnings signs (if any!) could be at best confusing and at worse misleading! (i.e.: Hackers can pretend their certificate is from a valid and known CA).

6. Devices Emulator, Developer Programs and Mobile lab
Device emulators, although not as good as the real handsets, are very useful to do security assessments.
Being part of the major vendors developer programs does not cost much money and gives you access to exclusive tools and upcoming beta versions.
Lastly, having some kind of mobile device lab is useful for your security assessments and combining real handset with emulators should be relatively cheap to setup whilst still giving you enough handset coverage.

What this course has highlighted is how immature the security around Mobile Devices is, and that securing mobile devices in a corporate environment does not stop with MDM.

A very good course I would recommend to anyone involved with Mobile Device security, this will be an eye opener!

Is there a bug with McAfee

There is something quite surreal with what is happening with John McAfee; the author of the popular McAfee Antivirus and who is rich, lives in Belize and has recently been accused by the authority to have murdered his neighbour. Instead of being with the police he has fled, arguing this was a conspiration and that the police (or someone) was after him. This on itself is already a bit odd, but his subsequent actions are even more bizarre…
You would think that someone who believes the whole system is corrupted would try to flee the country, but no. John McAfee is staying in the same city, posting a blog about his escape, offering $25K to anyone who can help him catch the “real” killer and even describing the numerous disguise he has used to approach his house and the police around it, doing his own investigation…

Well, at least it makes for an interesting reading!

Boxcryptor, a great tool to secure your cloud storage solution.

I made my feelings very clear about the use of Dropbox in the enterprise, through a previous post. I still believe Dropbox and similar other cloud sotrage solutions such as Google drive or Sky Drive are a timebomb waiting to happen for many companies who are busy securing their infrastructure but forget to look at the data leaving their premises through the back door. Or just not appreciating how tablets and smartphones are driving their users’ behaviours and requirements.

There will be a lot of red faces if/when Dropbox and Co announce they have been hacked.

However, I have recently come accross a great tool that can help reducing the impact of such a bad scenario. It is called Boxcryptor.

Boxcryptor creates an encrypted folder under your Cloud Storage directory (i.e.: Dropbox) and allows for files to be encrypted on the fly thus making it much faster and transparent than the solution I described before with Truecrypt. The encryption keys are stored locally and only known to you. Their client runs on many different platforms, Mac, PC, iOS, Android.

Boxcryptor works very well but it is important to note a difference in software behaviour between a MAC and a PC.

On a MAC, if you install boxcryptor it will create an encrypted folder in your Cloud Storage directory.
It will also create a new “disk” which gives you direct access to that encrypted folder.

You then have a choice, you can either drop files to this “disk” or to that encrypted folder in your cloud storage directory. Those 2 actions are the sames and the files will be encrypted in both cases.

On a PC, if you install Boxcryptor it will create a folder in your Cloud Storage directory. Note that I did not say encrypted folder. It will also create a new “disk”.
The difference between the PC and MAC implementation of Boxcryptor is that, on a PC, files are only encrypted if you drop them into your Boxcryptor disk. They will not be encrypted if you drop them in your cloud storage boxcryptor folder directly. That folder and the boxcryptor disk are not the same. Those 2 actions are therefore not the same.
This could be confusing, and a user may forget about that difference and copy sensitive files directly onto his cloud storage boxcryptor folder, thinking those files are going to be encrypted when they are not.
To be fair, there is a readme file in the Boxcryptor “encrypted” folder. But the chances are nobody will read it and more importantly, could forget about it.

My recommendation is to get used to copy files to the boxcryptor disk only. That way, you are always sure they get encrypted (and that the software is running in the background!).

I have contacted the authors and they are aware of this behaviour difference. Although they did not commit on any release dates, they are apparently working on it.

IT Security News & BUGS Cryptography Project