Incompetence or arrogance?

Image by Loutron Glouton via Flickr

Respected security analysts and consultancies have now confirmed what many industry watchers, pundits and commentators suspected last week - that the 'upgrade' pushed to tens of thousands of BlackBerry mobile devices in the UAE by telco Etisalat was, in fact, not what it seemed to be, an 'upgrade for Blackberry service. Please download to ensure continous service quality.'

Interestingly, this rather flies in the face of the somewhat belated statement made by the telco itself, which I reproduced in full here at the end of last week. That statement rather annoyed a number of BlackBerry users who found it facile and lacking the one element that tens of thousands of frustrated customers whose mobile devices were affected wanted to see - an apology. Many of those users say their BlackBerrys were rendered inoperable or suffered significantly downgraded performance. A number reportedly bought new batteries for their BlackBerrys, believing the battery was at fault when, in fact, it was the software update they had accepted from the operator.

A press release was issued on the 15th July by security company SMobile Systems. The company, which positions itself as 'the leading provider of security solutions for mobile phones and maker of the only antivirus and antispyware applications in the world for BlackBerry devices, has released a solution for the (in their words) 'recent spyware-laden update sent out to BlackBerry users on the Etisalat network'. That press release in full can be found here.

The company's release claims, 'The BlackBerry Spyware, which intercepts email and drains battery life quickly, was pushed as an update to BlackBerry's on the Etisalat network. Sent to users as a wide-area protocol (WAP) message, the Java file intercepts data and sends a copy to a server without the user's knowledge.'

That is an extraordinary claim to make regarding a piece of software that Etisalat's official statement says was software 'required for service enhancements particularly for issues identified related to the handover between 2G to 3G network coverage areas.'

It is perhaps worth noting that the Chairman of SMobile Systems, quoted in the release, is a former White House Deputy Chief of Staff and so, we must reluctantly admit, carries some weight.

SMobile is not the only expert testimony that claims the notorious update is other than it seems. Besides the many people who believe that the Etisalat network is 100% 3G now and therefore does not present 2G to 3G cell handover problems, there are also a number who point out the fact that BlackBerrys haven't experienced cell handover issues for some time now - in fact, the only online references I can find to the handover issue date back to 2006.

Added to this, you have those who have examined the code - Qatar based programmer Nigel Gourlay was quoted widely in the initial coverage of the issue, but his assertions that the network update was in fact an attempt to install monitoring software have been backed up by respected security blog Chirashi Security - a white paper analysing the code in some detail, written by Sheran Gunarsekera, is linked here.

That white paper asserts that the code is a monitoring application. It also points out that the application was not properly implemented, pointing out that the application developers had not used any form of source code obfuscation - in other words, it shouldn't have been as simple to trace, upload and analyse the code as it in fact was. The code, according to the White Paper, is set up to hide itself from the user, attach itself to network events and report these to the service-provider's server and look out for control messages that enable interception of user messages. If enabled, the application will forward a copy of emails sent by the subscriber to the service provider's servers.

Damningly, the White Paper asserts that the code 'was not mature enough to be deployed. This is especially relevant if Etisalat planned to conduct full-scale legal interception on BlackBerry users.'

The Chirashi White Paper is scrupulous to point out that the application only forwards outgoing emails and not other message types and then only when the application has been enabled to do so - it does not report on emails by default. But it does make the point that the version of the interceptor software it analysed should not have been deployed - particularly not as part of a legal interception.

The White Paper also strays out of geekland into my domain when it asserts, in the context of requiring legal interception software to meet two criteria, to do no harm and to be thoroughly tested: 'A service provider should always be prepared for the worst. In case things do not work out as planned, there needs to be a dedicated PR team who is ready to step up and deal with the public. Users should not be lied to or ignored, they will accept it better if they know the provider is well within legal rights to perform such interception.' (The italics are mine, BTW)

Security company Veracode also analysed the upgrade last week, asking whether the fact that the implemented update contained both .jar and .cod versions was down to 'arrogance or incompetence?'. That's an area explored by a journalist from the region's leading telecommunications magazine, Comms MEA, here. Again, Veracode's Chris Eng reports that the clear purpose of the update, in his expert view, is to install a piece of software that, when activated, will forward user data to a third party server, presumably owned by the service provider.

All of this leaves me wondering quite what on earth Etisalat thought it was doing. And quite how our media is standing by and allowing Etisalat to simply claim that the great big elephant in the cupboard is in fact a pair of shoes.

Nobody I know has a problem with legal interception. I think most of us would recognise that it is highly desirable that the security agencies employed by our governments have access to the information they need in order to protect society in general. Those agencies are constantly monitoring network traffic, legally and within the charters and frameworks that govern their activity. We need them to be competent and we desperately need to believe in their competence and efficacy.

Similarly, we need to trust our telcos. As a commercial entity operating in a regulated and competitive free market environment, even the biggest telco has a duty towards its subscribers and a duty to tell the truth - not only to earn the trust of its customers, but to underpin the level of trust required by investors and multinational companies who wish to trade in that environment. Mendacity and silence are not good enough - people are still facing problems with their terminals even now because there has been no clear attempt to reach out to customers and fix this issue - let alone roll back the update. There are critical issues related to privacy and security that the operator has refused to address - and questions are now being asked by a wider community about the long-term implications for BlackBerry security in general as a result of this whole farago.

Finally, there is the issue of responsibility. Someone was responsible for this Keystone Cops attempt to police BlackBerrys and the subsequent lack of timely and appropriate response that turned a customer service problem into a full-blown case study in how fumbled issues management rapidly evolves nto crisis management and how ignoring a crisis simply, in today's commercial environment, won't do.