Our Mission:

To reduce your personal and business risks by deriving action items from recent news stories.

Note: Brent LaReau is your point of contact for this blog.

« Previous 10 | Next 10 »

018

A Web Site Can Reset Your Samsung Phone to Factory Defaults

Permalink Brent LaReau, designsbylareau.com
Posted: Oct 12, 2012

The headline shown above seems too extreme to be true, doesn't it? But in fact, if you are reading my blog on a specific type of Android phone made by Samsung, I could have instantly "wiped" your phone RIGHT NOW by simply embedding a specific "USSD" code here. You wouldn't even have had time to read these sentences. Instead, your phone would have begun to reset itself as soon as it loaded this web page. When it was finished you would have found:

• Your text messages were deleted.
• Your installed apps were gone.
• Your contact list (address book) was empty.
• Your photos were missing.
• Your e-mail messages were erased.
• Your Wi-Fi network passwords were forgotten.
• Etc.

(You can see all of my cartoons here.)

Fortunately, not all Samsung Android phones are vulnerable to this attack. Full details are not yet known, but at least we know the following Samsung phones are vulnerable:

• Galaxy S2 with Android 2.3.6 or 4.0.3
• Galaxy Advance

How did this enormous vulnerability creep into Samsung phones? There is a short answer and a longer answer. The short answer is that Samsung's software development teams created a "dialer" app for its Android phones, which will instantly execute any USSD code without asking the user to confirm this action. One of those USSD codes will wipe the phone (reset it to its factory original condition). And if any of those USSD codes is embedded in a web page, the code is immediately executed when the page loads.

That was the short answer. Now for a longer answer that some people won't like: agile software development methodologies permit companies like Samsung to make 10,000 software modifications—new features and bugfixes—each year in a frantic race against their competitors. We have to admit this rapid, incessant march forward is quite an accomplishment, but how can an agile design team consider the consequences of each software modification when their main goal is to do more and do it faster?

How can an agile culture that revolves around optimization of business processes (not security processes) avoid oversights and mistakes that place end users at risk—to the delight of malicious hackers, teenagers, and blog writers like me?

How can the "user stories" embraced by agile methodologies include security considerations when the "user" is just an average consumer instead of a security expert?

And how can the "unit tests" embraced by agile software developers even begin to address system security issues at all? Especially since many lean, agile teams act as if unit tests can replace integration testing and system testing!

[Update: February, 2013—Samsung isn't the only vendor that fails to assess security issues when developing its products and software. The Federal Trade Commission (FTC) has announced a settlement with HTC over complaints about lack of security in its mobile phone software. The FTC stated that HTC made little or no effort to address user security when HTC customized Android and Window Phone software for its smartphones. HTC's software was claimed to be sloppy; HTC didn't train its design teams in secure software development practices; HTC didn't perform any penetration testing on its mobile devices; and HTC's staff used software development methods that are well-known to be poor security practices.]

Let's peruse the facts of this case and generate some action items that we can use to reduce our risks:

• Fact: Galaxy S2 with Android 2.3.6 or 4.0.3, and Galaxy Advance phones are vulnerable. The bad news is that the full list of vulnerable phones isn't widely published. To reduce our risks we will need to perform some Internet searches (such as "samsung ussd") to discover if our Samsung phone is vulnerable. After this vulnerability became widely publicized, Samsung (to their credit) took some rapid corrective action, at least for some of their Galaxy phones. But in a way, this "corrective action" is like closing the barn door after the horse has bolted, since not all phones are updated automatically. Often we need to update our phones manually, which most people don't bother with (or don't know how to do).
  
  Besides performing some Internet searches, we can also reduce our risk by assessing how our particular phone handles USSD codes. The easiest way to start this process is to use our phone's web browser to visit some harmless test pages set up by security companies and Android-oriented web sites (such as here and here. The results may be surprising.
• Fact: All GSM cellular service providers and cell phones support "USSD" codes for administrative or informational purposes. USSD stands for "Unstructured Supplementary Service Data". In short, dialing a USSD code on our cell phone (just like we would dial a regular phone number) will cause our phone or our cellular service provider to take specific action. These actions include:
  
  
  • Querying the available balance or minutes remaining on a pre-paid phone.
  • Viewing advanced cellular network statistics (such as cell site information).
  • Displaying the phone's International Mobile Equipment Identity (IMEI) number, which is a sort of serial number.
  • Displaying or changing the "call forwarding" settings.
  • Viewing wireless data usage statistics.
  • And of course, resetting the phone to factory default settings.
  
  USSD codes are not standardized; many are specific to a service provider or a phone. Many cell phones are designed to ask the user to confirm a USSD-generated action before proceeding. To mitigate risks related to USSD, we need to explore what codes exist for our particular combination of service provider and phone. This information is not easy to find; we will need to perform some Internet searches (such as "t-mobile ussd" or etc). Obviously, if we experiment with USSD codes on our phone we must be very careful!
• Fact: "HTTP" and "HTTPS" are not the only URL/URI prefixes that desktop, laptop, tablet, and mobile web browsers know about. Everyone knows that typing "http://google.com" into our web browser will cause it to load Google's web page. "HTTP:" tells our web browser to use the HyperText Transfer Protocol when fetching Internet content. But most people don't know that Internet Explorer, Firefox, Opera, Chrome, Safari, and other web browsers are able to understand many additional URL/URI prefixes. It is one of those "other" URL/URI prefixes that allows USSD codes to potentially wreak havoc on a smarphone.
  
  To reduce our risks, we need to understand just what our web browsers are capable of doing! Here are a few examples, some of which are supported only on specific platforms (such as smartphones):
  
  
  • FTP (File Transfer Protocol). This protocol allows our web browser to access an FTP site on the Internet or on a local area network. Example: ftp://ftp.freshrpms.net.
  • FILE. This protocol allows our web browser see our computer's internal disk file system. Examples: file:/// or file://c:/.
  • TEL. This protocol allows our web browser to dial a telephone number or execute a USSD code (which is the basis for the vulnerability discussed in this blog entry). Example: tel:8885551212.
  • SMS. This protocol allows our web browser to send a text message. Example: sms:8885551212.
  • MAILTO. This protocol allows our web browser to send an e-mail message. Example: mailto:bill@nowhere.com.
  • TELNET. This protocol allows our web browser to access a TELNET server on the Internet or on a local area network. Example: telnet://towel.blinkenlights.nl.
  
  Try clicking on some of the harmless examples shown above, using various mobile and non-mobile devices.
• Fact: Anyone can enter a potentially dangerous USSD code into our phone unless we take steps to prevent this. In every crowd there's always somebody who likes play tricks on other people, or get revenge for something. If we leave your phones unlocked, someone can quickly enter a USSD code and wreak havoc on our phones (or on our lives).
  
  To reduce our risks we need to lock our phones when our phones are unattended. Automatically locking our phones is a good idea even when we're carrying them, as anyone who has been around children can attest. I know from experience that it only takes three seconds for a young child to suddenly grab a cell phone out of someone's purse or holster, turn it on, start an app, and run away at top speed.
  
  And let's face it, our teenagers are Internet-smart and sometimes very angry at having to live within our rules. If they wipe our phones when our backs are turned, it's quite likely that we'll never be able to pin it on them.

You can read an original news article about this topic here. You can contact me here.

Permalink

---

« Previous 10 | Next 10 »