Breaching the Perimeter: Understanding (and avoiding) the BlackBerry security vulnerability
Security consultant Jesse D’Aguanno caused quite a stir recently when he revealed a way to attack a company’s internal network by installing an application on an employee’s BlackBerry. This vulnerability might have been new to the press, but it’s old news to anyone who’s ever installed a BlackBerry Enterprise Server (BES). However, it’s certainly true that RIM downplays the risk. Here’s what you need to know to understand and protect yourself from this security vulnerability.
The BES Connection
A BlackBerry’s access to corporate email and calendaring functions is proxied via a BES, as shown here:
The BES connects directly to the mail server (Microsoft Exchange, Lotus Notes, Novell Groupwise) to gain access to the user’s mailbox, calendar, and related data stores. The BES also connects to RIM’s network operations center (NOC) via an outgoing (client-initiated) socket connection on port 3101. Once the connection is established and the identity of the BES is authenticated (a unique authentication key is delivered with every BES) the connection then serves as a two-way tunnel for communication between the NOC and the BES. Since each carrier also connects to the NOC, this enables the NOC to relay data from the BlackBerry to the BES and vice-versa.
In order to secure the communication between the BlackBerry and the BES, the BlackBerry must be “paired” to the BES. The pairing — currently a device can only be paired to one BES at a time — generates a unique encryption key that only the device and the BES share. All communication between the device and the BES is encrypted using this key — even RIM can’t decrypt it. This end-to-end security is one of the BlackBerry’s big selling points.
Locating the BES
Because the BES requires administrative access to the mail server, the natural configuration for locating the BES is on the same network as the mail server. Assuming the existence of a DMZ (demilitarized zone), a typical BES configuration actually looks like this:
Notice that the BES is not in the DMZ, but is rather on the corporate intranet, just like the mail server. For the longest time this was the only recommended (and supported) deployment scenario. Moving the BES into the DMZ was certainly possible, and many companies did this as a matter of course, but it required special configuration of the inner firewall to allow the necessary protocols to pass back and forth between the BES and the mail server.
Placing the BES on the intranet is by itself not a huge security risk if it’s only email that’s involved. (Though there are some issues related to malicious users changing devices to get access to another user’s mail.) Where things get tricky is when the MDS service is enabled.
Enabling Browsing
MDS is an optional component that acts as a Web proxy server for the BlackBerry devices paired to the BES. With MDS enabled, users can browse the Web regardless of what network or carrier is being used. Page requests get sent to MDS via the BES; MDS fetches the actual page and delivers it to the device for rendering. In the simplest configuration the MDS proxy is also on the intranet and therefore has access to internal servers as well as (by going out through the firewalls) the Internet:
And this is where the security breach occurs: while unfettered access to the intranet is useful to employees, it also circumvents the perimeter security infrastructure that protects internal servers from attack by outside entities. In effect, a BlackBerry device in such a configuration becomes a direct hole into the corporate intranet. This is the problem that D’Aguanno highlighted: in these situations, untrusted third-party applications running on a BlackBerry can run amok accessing internal servers with impunity. And it’s not just limited to HTTP access: MDS also acts as a proxy for socket connections. No wonder the security guys were having a field day with it.
Multiple Solutions
As I said before, this security problem doesn’t have to be a problem. There are different solutions available to plugging this security hole:
- Turn off MDS. Probably the simplest solution, but it may prevent your users from browsing the Web if the carrier they’re using doesn’t support direct Internet access and does not use RIM’s hosted BIS solution for browsing.
- Use a proxy server. MDS can be configured to use a proxy server for Web access. By configuring the proxy server appropriately you can restrict what sites users can browse to.
- Put everything in the DMZ. Configure the firewalls to let the BES talk to the mail server. Users can’t browse the intranet but they can still browse the Internet.
- Use a segmented network approach. Instead of placing everything in the DMZ, use internal routers and firewalls to isolate the different parts of the BES architecture. RIM has a whitepaper on how to do this.
Of course, judicious use of the BlackBerry IT policies can also go a long way to plugging potential security breaches. See RIM’s malware whitepaper for more info on the relevant policies.
Conclusion
So there you have it. I’ve simplified the BES architecture somewhat for this discussion so as to not bog you down with too many details. The security documents that RIM publishes are very verbose, on the other hand, with most of the details of what you need to know to implement a good security solution. Note that versions 4.0 and higher of the BES software split the BES functionality into different components, some of which can be installed separately from each other, and so of course this complicates the final network architecture.
Mostly I just wanted to make sure that you understood the basics. You should read all the relevant RIM security documents to get all the details — a good place to start is with the BlackBerry Security Overview section of the BlackBerry website.
Technorati Tags: BlackBerry, BlackBerry+security, security, BES, BlackBerry+Enterprise+Server, MDS, firewall, DMZ
