Manage Learn to apply best practices and optimize your operations.

How do hackers bypass a code signing procedure to inject malware

In this expert Q&A, Michael Cobb reveals how malicious applications can actually be approved by Symbian's Express Signing procedure.

How did malware authors bypass the code signing procedure to enable "Sexy View" or "Sexy Space" malware to infect mobile devices?
Sadly they didn't bypass the code signing procedure; their app was submitted through Symbian's Express Signing procedure, and it got approved. This automated approval process scans apps for viruses with a random sample then being submitted for human audit. The hackers, in this case, disguised their malicious code as a legitimate application called ACSServer.exe, which allowed it to pass through the scanning process. The attackers then got lucky by missing a human review.

Users rely on digital signatures as assurance that software is safe and has come from a trusted source. The problem I have with Symbian's process is that the majority of the submitted applications aren't inspected by humans. Yet once they've been accepted, they are often digitally signed by Symbian. Signed apps have the ability to access content that unsigned applications cannot, and users are going to assume that that's ok. Also, because Sexy Space is signed, there's only one prompt during installation: "Install Sexy Space? Yes or No." Unsigned apps require the user to select "Yes" three or four times before installation starts.

Taking advantage of its signed status, the malware performs various tasks, attempting to make a silent HTTP connection to a malicious server, sending back subscriber, phone and network information to the hacker's site. It also sends suggestive SMS messages to everyone in the phone's address book, directing them to a website which then automatically pushes the malware installation package onto their Symbian phones. To protect itself, it looks for and closes certain applications such as App.Manager and Task Spy, making it difficult for the user to attempt to manually end the threat.

Another shortcoming in Symbian's security is that although it revoked both the content certificate and the publisher certificate used to sign the malware, the default setting in most Symbian phones has to be changed to enable users to receive such revocation certificates. (I would certainly recommend that you turn on revocation checking using Application Manager's Settings to set the "Online" certificate check to "must be passed.") Also, an error on Symbian's servers meant that Sexy Space was still available for download for a while after it was discovered to be malware.

The Symbian platform is used in just under 50% of all smartphones, and thankfully this time the malware didn't infect that many users. However, this type of threat is certainly going to continue to increase. Operators and handset manufacturers have not really kept their quality assurance and testing procedures in step with the tremendous increase in the computing power and functionality of the average smartphone.

I'm not encouraged that Symbian has said that one of its aims is to automate the publication of apps as much as possible, mostly because human auditing introduces cost and time delays into the process. I certainly disagree that signing apps without thorough analysis is "still much better than the apps not being signed at all." What could future versions of this threat potentially do using these trusted privileges?

This was last published in November 2009

Dig Deeper on Mobile security threats and prevention