Posts tagged ‘Blackberry’

Blackberry security

All the security settings in the world don’t matter if they aren’t turned on.

According to the Washington Examiner, the social security numbers names and addresses of nearly 700 Prince William County Virginia residents was potentially disclosed when a county issued Blackberry was stolen.  The Blackberry stolen from a vehicle parked in a county employee’s driveway overnight.  

Like most news we’ll probably never hear the rest of this.   It sounds IT negligence to deploy a Blackberry without a PIN timeout requirement and encryption enabled.  There wasn’t an existing policy about PII on the Blackberry.   And of course we have to think about physical security.   Its easy to have a false sense of security about the things we leave in our cars.

iPhone (in)security in the enterprise – Followup

Back in November I wrote a summary of several concerns we have about the iPhone in the enterprise.
Four months later lets take a look at see what’s changed.
One of the other guys at work took that list of concerns to our AT&T rep, who then took them to a unnamed, untitled Apple contact. Next they ran it the questions by the magic 8 ball. The responses are below.
Problem 1: Encryption and PIN bypasses reported at iPhoneinsecurity.com
Apple’s Response:
We take iPhone security very seriously and have made consistent improvements in all areas.For example, in the most recent iPhone 3.1.3 update we made the changes detailed in the following KB – http://support.apple.com/kb/HT4013 One to highlight is CVE-ID: CVE-2010-0038 related to recovery mode. This is a big improvement to thwart those who are using tools to modify the iPhone software.
That doesn’t really answer the question though. Is the encryption bypass which Zdziarski is only talking to law enforcement about fixed or not? Due to the lack of public disclosure there is no way to know. Zdziarski does mention using recovery mode so it is possible that the attack is patched. But I dont give the benefit of the doubt to non-disclosers.
I suppose some would argue that the evil maid attack allows bypass of Full Disk Encryption on computers so I shouldn’t have my data there either. Of course using a smart card or bitlocker with TPM I could protect myself from this attack.
The evil maid attack requires an attacker to have physical access to the device. Then I log in. The the maid returns to harvest the results. The iPhone encryption bypass can occur when you leave the iPhone unattended for a few minutes. I dont think that is comparable.
2. iphoneinsecurity shows a password bypass in addition to the encryption bypass.
Apple’s” response indicates that the enterprise passcode policy is completely different than the consumer four diget pin and thus not vulnerable. I’m not sure I’m buying that.
3. Lack of Centralized Config Management
Apple’s Response indicates that its possible to force the iphone to have enterprises configuration in order to be able to connect in order to connect to the enterprise. I’m not sure exactly how that is supposed to be done.
Further Apple claims that the iPhone is more secure than the Blackberry because its Unix. Its also more secure because you can only run one application at a time and every app is approved by Apple. lolz.
4. Patching
With the BES we can deploy them as forced updates over the air.
Apple’s Response:
We (Apple) don’t view them as patches, but as major, free OS upgrades and updates..a typical OS update for us is 200-300 meg ( very unwieldy to do OTA) and is packed with useful new features , security upgrades, OS enhancements, etc…
“we dont view them as patches”. Sorry, I didn’t read the rest. Laughing too hard.
5. iTunes
Apple Responded that its best practice to not supply full itunes to everyone. Apparently there is some way to skinny down itunes so its basically a sync software.
6. App Store
This issue goes back to is this a business device or not. Are the users going to have the device on their Apple account and take the applications with them or what?
Apple’s response was basically, yes the user takes the app with them when they leave the company even though the company bought the app.
7. Jailbroken phones maybe less secure.
Apple’s response is dont let jailbroken phones connect to the network. No word on how to do that. Authentication alone doesn’t do that. Is ActiveSync going to check for that? I think not.
8. Repeaters. This is more an ATT issue. If we buy X iphone’s can we get repeaters for free.

Messege Encoding and Blackberry

Last week a user reported trouble reading a message on his blackberry. He would get an error “This S\MIME message was formatted using an encoding that is not supported on handheld.” He could still read the message correctly in Outlook 2007 and in Outlook Web Access.
It turned out the commonality to the problem was him. On this Blackberry, he couldn’t read S/MIME signed messages where people were replying to him. Others couldn’t read his S/MIME signed messages on their Blackberry.
Since the error referred to the encoding of the message, I wanted to see what the encoding was. The headers in Outlook didn’t seem to include that so I opened the message in Thunderbird. In there, it was clear that the message body encoding was Cyrillic. Kind of weird that the Blackberry reads the message just fine if its not digitally signed but gets the error above when it is digitally signed.
RIM wasn’t much help. Their support gave the same answer found in a knowledge base article. Their choices are

    ,li>Do not sign and encrypt the message.

  • In Microsoft Outlook, go to Tools > Options > Mail Format > International Options and select Auto select encoding for outgoing message.
  • In Microsoft Outlook, go to Tools > Options > Mail Format > International Options > Preferred encoding for outgoing message and select Unicode UTF-8 encoding.

Not signing the email isn’t much of a solution. I worry that changing the encoding options in Outlook would effect the readability of email in other situations.
Microsoft has an article on configuring message encoding options in Outlook 2007. There we read that “Outlook uses automatic message encoding by default, scanning the entire text of the outgoing message to determine a minimal popular encoding for the message. Outlook selects an encoding that is capable of representing all of the characters and that is optimized so the majority of the receiving e-mail programs can interpret and render the content properly.” The KB has a table showing supported encodings and whether they are considered for autoselection by Outlook. The article does not state whether we could remove an encoding option however.
Through some trial and error, I found that the problem was in the signature (footer not the digital signature) of the person reporting the problem. He had used what looked like a pipe to separate portions of the signature (like Title and Company). It wasn’t a pipe, it was actually a character inserted through the Symbol key. If I replaced this symbol with a standard pipe character the problem went away completely.
While this was a quick fix for this user, its not very satisfying. Most likely this user saw someone else’s signature and copied it for his own use. I doubt this user was using ASCII codes or hitting the symbol button. If others did the same they would have the same issue. I prefer a better solution than put it in our KB for next time it gets reported.

iPhone (in)security in the enterprise

Just when you thought you’d successfully killed it off, its back. The email from management who is getting pressure from the c levels asking why the iPhone isn’t supported. It comes in on schedule every two month.
“iPhone version 3.1 has solved all the security problems, right?”
Um, no.
“There is now a Wolfram Alpha app for the iPhone. This would really help our business development”
Are you serious?
Who can blame them. Apple and their willing co-conspirators in the tech media have been repeating the mantra. “iPhone 3GS is secure for the enterprise.” Secure or not companies are adopting the iPhone, even to the point of allowing personal devices. Lets summarize what we know and what we dont know about the
Problem 1: Encryption
It is of critical importance to protect data privacy through encryption. iphoneinsecurity.com, a site dedicated to iphone forensics has posted video demonstrating the bypass of the iPhone 3GS encryption.
I suppose some would argue that the evil maid attack allows bypass of Full Disk Encryption on computers so I shouldn’t have my data there either. Of course using a smart card or bitlocker with TPM I could protect myself from this attack.
Problem 2: passcode bypass
The passcode on a iPhone is bypassable
Problem 3: Lack of Central Config Management
Enterprises are used to controlling phone configuration centrally a la through a Blackberry Enterprise Server. iPhones configuration is sort of voluntary. TrustDigital would say they solve that issue. I need to talk with them (again) because I think they can enforce a configuration at the time the iPhone connects to the server, but I dont think they have a permanent enforcement agent. Could be wrong.
Problem 4: patching
While patches can be pushed from the BES, iPhone users need to install each patch individually through iTunes
Problem 5: iTunes
Speaking of iTunes, that isn’t exactly a corporate type product. What if we dont want that on our computers. RIM has worked to make Blackberry work without installing any desktop software in a BES environment.
Problem 6: App Store
Whose account is used in iTunes? Do they use their personal account? In that case the end user really owns any applications purchased by the corporation on that account. When the employee terminates they would essentially walk out with the applications the company owns. If a corporate account is created then the opposite problem occurs.
Problem 7: Jailbroken phones
Jailbroken phones are susceptible to security problems. Besides the ikee worm, they allow unapproved applications to be run, bypassing Apple’s whitelisting security model. How can an enterprise prevent jail broken phones from being used?
Problem 8: Repeaters
Like a lot of company headquarters, ours is like a unintentional Faraday Cage. We’ve had to put up repeaters for Verizon and Nextel. Are we supposed to pony up and install AT&T repeaters?
While the iPhone remains exceedingly popular, it still has Apple’s consumer mindset at the core. (sorry bad pun) At least at our company I dont see it making headway until the encryption issue is solved. Then I’ll talk with TrustDigital again about their management solution.
update
The day I posted this I got emailed an announcement of Good Technology’s support for the iPhone. Good uses their own application and would keep the corporate email encrypted in that. However any other corporate data that made its way on to there wouldn’t be protected. In an era of cutbacks its hard to provide support for both Good and Blackberry.
Commenters have pointed out that the iPhone still does not support S/MIME or PGP. I had thought to check on that but it didn’t make the article. S/MIME support is mandatory for my company.

Tech Support Engrish

“Are on the Internal network where the following IP addresses are reachble?”
How’s that again? The funny thing is when I glanced at this question on my blackberry I didn’t even notice anything was wrong.

iPhone and CIS Secure Config Guide

The Center for Internet Security released a secure configuration benchmark for the iPhone.
SCMag touts this as a good thing “For the first time, enterprises can apply security configuration best practices to Apple iPhones being used by their employees.” I would argue that there are a couple things wrong with this statement.
First it seems to admit that the iPhone isn’t secure and needs to be locked down. When Microsoft releases a hardening guide, Alan Paller of SANS goes ape and encourages the government to use their buying power to force Microsoft to apply a “secure” configuration prior to shipment. Second, reading the document, I’m not convinced that the CIS config allows enterprises to to enforce security best practices.
The first half of the CIS security guidelines are settings for the user to do on their phone. Fine for the individual, but not for a enterprise. The second half focuses on settings in the iPhone Configuration Utility. I’ve never used this utility and I dont own an iPhone, but it appears that this utility creates a config file you then mail to the user to apply or place on a website. Great way to distribute security policy. Doesn’t seem like a mandatory security policy either. There are a few mentions of ActiveSync which would enforce policy, but it is not explored enough for my tastes in this document.
Recommendation: Keep firmware up to date.
Doing this requires the installation of iTunes. My skin kind of crawls when someone wants that buggy bloated software installed in a business environment in order to load phone firmware. But hey, at least the user gets to sync their music at the same time. The CIS paper does not report a way that the enterprise could verify the installed versions on each deployed iPhone.
Recommendation: autolock at 5 minutes I wish we could enforce an autolock at five minutes. Ours is a bit longer.
With the Blackberry you can set it to lock when holstered. I dont believe the iPhone can do that.
If you needed someone to tell you to set a PIN and a password timeout on a device with, you probably need someone to tell you to come in out of the rain.

Blackberry and S/MIME part 2

Back in June I wrote about the Blackberry and S/MIME.
There was a BES upgrade that fixed the “an unexpected error has occurred” message. We still can’t open attachments on signed or encrypted emails. To me this is a trivial thing, but to the Management this is a horrible horrible thing.
The 4.5 software has been released by some vendors on some models. As expected phones with this software didn’t have the problem with attachments. Although Verizon has not yet released the 4.5 software for the 8830, I downloaded a rogue copy and installed it. It resolved the attachment problem. Unfortunately for me although SecurID for Blackberry was supposed to work on this build, I can’t get it to work.
None of this actually helps. Waiting for Verizon to release 4.5 is like waiting for Godot.

iPhone password bypass

Caught up with this one via Digg
Earlier this week Jesus Diaz posted on Gizmodo how to bypass the iPhone login pin/password protection.
Its kind of funny the typical comment response to that article is “who uses a password on their phone anyway.” My opinion is more with the commenter who pointed out that “whether the typical user used a password or not if this was a Microsoft vuln the reaction would be different.”
It is serious. Apple is trying to position themselves as the new Blackberry, not just from the functionality and the coolness, but also the security. They need business customers, otherwise they wouldn’t be licensing ActiveSync. No business that values its data is going to put the data on a phone that doesn’t have encryption (iPhone doesn’t) and doesn’t even have an effective login password.
The article says that rumor is this will be fixed in the next iPhone firmware update. With the Blackberry I’m pretty sure you could push out required updates wirelessly (not positive I”m not a Blackberry admin). With the iPhone you have to ask your users to synch with iTunes (not a iPhone admin either, but thats my understanding).

Blackberry and S/MIME

We’re in the early stages of rolling out digital certificates for signing and encrypting email (S/MIME). In what seemed like a stroke of good timing, Blackberry is no longer charging a separate Client Access License to use S/MIME. Prior to June 2nd, it would have cost us $10,000 to purchase 100 S/MIME CALs.
One might think that because they were charging such an exorbitant rate that S/MIME support would actually work. Sadly this is not the case. We’re running what I believe is the latest S/MIME for Blackberry client, and users regularly get a message that “an unexpected error occurred” when they attempt to open some signed or encrypted messages. Thanks that’s very a helpful error message.
Blackberry Enterprise Server v4.1 SP 5 (which we are already running) provides support for encrypted attachment viewing in version 4.5. Unfortunately Blackberry 4.5 is sort of like the Locke Ness Monster. Some people claim to have seen it, but no one knows when it will officially be discovered.
At this point, I’m not sure the problem is even consistently reproducible, but it seems to be enough that my Director wants to stall my project until Blackberry 4.5 is out. That’s just great. This project began over three years ago and hundreds of thousands of dollars have been spent. Lets not deploy because 5% of the company might not be able to open 1% of their messages.

Adobe Reader Exploit Drops Trojan.Zonebac

As I was driving into work this morning, my blackberry was flooded with Trojan.Zonebac alerts. When I got into work, I could see that a single computer at one of our sites was getting this detection on pretty much every major exe. When I read the Technical writeup of Trojan.Zonebac at Symantec, I found out why. Zonebac searches for files referenced in the following registry subkeys:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

For all the files found referenced in the registry subkey values, the Trojan creates a copy of the referenced file in a folder named “bak” at the same path as the original file. Then the Trojan will replace the original file with a copy of itself.
Now that is a mess. Normally, I see it as a fun challenge to clean machines, but in this case with so many EXEs suspect, and with the computer being remote, it seemed to be a better bet to wipe the system.
This evening the SANS Handler Diary had an entry revealing that the Adobe Reader/Professional vulnerability is currently being exploited and Zonebac is being dropped. That explains what happened.
It looks like I may have to move up my implementation of Adobe Reader 8.2.1
Brian Krebs’ writeup on this reports that according to iDefense this was spreading through banner ads. http://blog.washingtonpost.com/securityfix/2008/02/hackers_exploiting_adobe_reade.html