SMS Trojan Targets South Korean Android Devices

It’s a common misconception that mobile malware is a problem limited to users in a particular geographical region such as China or Eastern Europe. Last week, McAfee Labs mobile research department received a mobile malware sample that targets Android mobile phone users in South Korea. The sample pretends to be a popular coffee shop coupon application, but in fact is an SMS Trojan that posts the incoming SMS messages to the attacker’s website.

SMS trojan target on South Korea's mobile phone-1

If a user clicks the familiar application icon, a pop-up message will display the following information:

SMS trojan target on South Korea's mobile phone-2

This is a fake error message reporting that the server is overloaded and unable to process the request. This, together with the icon used for the application, is simply social engineering to fool the victim into believing the application is legitimate but having problems, in the hope that the victim will just quit the application. This malicious app has nothing to do with the popular coffee vendor you may associate with the bogus icon.

While the message is displayed, the application creates a service to run in the background after the device has been rebooted. This service then sends the victim’s phone number to the following URL to “register” the infection.

  • http://it[deleted].com/Android_SMS/installing.php

The following image shows the application’s ability to gather a phone number and send it to the attacker:

SMS trojan target on South Korea's mobile phone-3

Once the application is installed, it monitors any incoming SMS messages. All of these will be sent, together with the phone number of the sending device, to the following URL:

  • http://it[deleted].com/Android_SMS/receiving.php

Furthermore, the malicious application blocks the incoming SMS message as well as the notification, so the victim will never know of the message’s existence.

The following image shows the application code responsible for the incoming message theft:

SMS trojan target on South Korea's mobile phone-4

This malicious application targets only South Korean Android devices by checking for numbers starting with “+82,” the international code for South Korea, as shown in the following:

SMS trojan target on South Korea's mobile phone-5

All intercepted and stolen SMS messages and the originating phone number are posted to the aforementioned URL using “EUC-KR” character encoding, as shown in the following picture:

SMS trojan target on South Korea's mobile phone-6

McAfee Mobile Security detects this malware as Android/Smsilence.A.


The post SMS Trojan Targets South Korean Android Devices appeared first on McAfee Blogs.

More Than 30% of People Don’t Password Protect Their Mobile Devices

Are you guilty as charged?

Whenever I bring this up in a group setting, it astonishes me how many people raise their hands. I wonder if they realize that they are putting all the personal information contained on their mobile device at risk. The unfortunate reality is that everyone loses things, and our devices can get stolen. And when that happens to your smartphone or tablet, it can be devastating.

Many of us use upwards of ten apps on our devices during a typical week. The majority of these apps are logged into our most critical accounts including email, text, banking, social media, payment apps and others that are linked to our credit cards. And because mobile app developers know that we are more apt to use their programs if they are easy to access and convenient to use, a lot of apps are programmed to automatically keep you logged in for days, weeks, months, or until you manually revoke access.

If your devices are not password protected and are then lost or stolen, your accounts are 100% accessible to whoever has control of your device. This is bad—and yet, 36% of us still do not use password protection!

According to a recent global survey by McAfee and One Poll, consumers seem largely unconcerned about keeping data on their mobile devices safe. For example, only one in five respondents have backed up the data on their smartphone and tablet, and more than one in ten (15%) save password information on their phone. This means that if their phone falls into the wrong hands, they risk opening up all sorts of personal information such as bank details and online logins to whoever finds the device.

Setting up a password or PIN is no guarantee that data will stay safe, and over half (55%) of all respondents admitted that they have shared these details with others, including their kids.

What’s particularly interesting is that men and women also behave differently with their mobile devices, not only in terms of how much risk they are willing to take, but also in terms of what they value.


Here are a few steps to make sure you and your mobile devices stay protected:

  • Password protect all your devices (and don’t use easy ones like 1234 or 1111)
  • Never use the “remember me” function on your apps or mobile web browser, and take care to log out of your accounts
  • Consider not sharing your PIN/password—this might be a tough one, but in the long run it will save you from possible heartacheUse a mobile security product like McAfee Mobile Security (and also McAfee All Access), that has not only anti-malware, but web protection and app protection. With app protection, not only are you warned if your apps are accessing information on your mobile that they shouldn’t, but in the event that someone does unlock your device, you can ensure your personal information remains personal by locking some or all of your apps
  • Stay educated on the latest ways to protect your mobile device. For a fun quiz to help you learn about mobile security, visit the McAfee Facebook page. Play the Mobile Mythbusters quiz and get a chance to win a Galaxy Tablet or Kindle Fire!

And if you’re at Mobile World Congress, stop by and see McAfee in Hall 3, Stand C34. If you show our team in the red shirts that you’ve liked them on Facebook or followed them on Twitter, you’ll get a prize!


Robert Siciliano is an Online Security Expert to McAfee. He is the author of 99 Things You Wish You Knew Before Your Mobile was Hacked!. Disclosures.

The post More Than 30% of People Don’t Password Protect Their Mobile Devices appeared first on McAfee Blogs.

MWC 2013: What’s the Hot Ticket?

Mobile World Congress, or MWC to the veterans, has arrived once again. We’ve been busy preparing for this event for the past couple of months, and now that we’re here, we’re faced with sleep deprivation, increased caffeine intake, and indecision as to whether or not we’ll need a sweater in the confusing Barcelona climate.  Nevertheless, we’re all extremely excited to be here for the one week of the year that the mobile industry unites in this beautiful city to update, discuss, and learn what’s going on with everything that is mobile.

Big Changes at MWC

This year’s MWC is set to run from the Monday, February 25th to Thursday the 28th, and it will be the first time we have all descended on the new location of the Fira Gran Via, which will mean a new experience for even the most grizzled MWC attendees.  Possibly the most dramatic change to this year’s show will be the absence of the Google Android stand, which has become well known for its smoothies, ice cream, and crazy slide.


What We’re Waiting For

As always, we’re excited to hear the customary announcements from the big networks, device manufacturers, and accessory businesses, but we’re particularly looking forward to the growing number of cloud service providers that are increasingly attending the show.  For example, this year we have keynotes scheduled from the CEOs at Deezer, Dropbox, Foursquare, and Mozilla.  These names could make for some very interesting talks on the future of mobile devices, driving increased innovations and efficiencies for businesses and consumers alike.

Enjoying the MWC Nightlife

As usual, most of the professional networking that goes on during MWC won’t happen at the show, but rather in the evening in the many bars and clubs of Barcelona.  Here are some of the events we think look too good to miss:

  • Monday 25th Feb: MEF Connects 2013 – Now in its 11th year, this is a chance to do some serious networking with other MEF members. If you’re not a member, don’t fret, there’s always the MWC Networking Event, dubbed by organizers as “THE” networking event of MWC.
  • Tuesday 26th Feb: Mobile Marketing Mixer – This event is open to all, but you’ll need an invite to get in.  The best chance to get your golden ticket is to follow @MMMagTweets, where organizers will give away tickets right up to the show.
  • Wednesday 27th Feb: Swedish Beers, Heroes of the Mobile Fringe Edition – Promised to be full to the brim and buzzing with chatter; organised by Helen Keegan (and “crew”).  There’s no need to RSVP, as there’s no strict guest list, but our tip is to get there early, as it’s always popular and space in the venue (as well as the free drinks) always go faster than you think.
  • Thursday 28th Feb: MLove MWC 2013 After Party – If you’re not planning to leave on Thursday and are still in a condition to party, this event is a must!  It’s a chance to meet, mingle, and celebrate the end of another great show. Tickets are expected to sell out, but they’re currently available through Eventbrite with the promotional code “MLOVE-friends.”

What McAfee is Doing:

We’ll be sharing a booth with our parent company Intel in Hall 3, Stand C34. Stop by to check out McAfee consumer and enterprise mobile demos and chat with members of our team (we’re easy to spot – just look for the red shirts). Even better, if you stop by the booth and show that you’ve Liked us on Facebook or followed us on Twitter, we’re giving away special prizes for our social media fans.

In addition, we’ll also be revealing the results of our global mobile security research report during the show, and for our enterprise audience, we’ll discussing McAfee Enterprise Mobility Management.

Last but Not Least: #MobileMyths Giveaway for Fans at Home and in Barcelona

Whether or not you’re at the show this year, don’t forget to play our Mobile Mythbusters quiz on Facebook. Not only can you help debunk some of the most common mobile security myths, but you can also enter to win a Galaxy Tablet or Kindle Fire HD, complete with McAfee Mobile Security! Once you’ve taken the quiz, be sure to share your results with the hashtag #MobileMyths, and you can get another entry for the prize.

Stay tuned for more updates on Facebook, here in the blog, and on Twitter with @McAfeeConsumer, and for those of you in Barcelona, I hope you take some time to enjoy all that the city (and MWC) has to offer!


Image Source:

The post MWC 2013: What’s the Hot Ticket? appeared first on McAfee Blogs.

Secure USB debugging in Android 4.2.2

It seems we somehow managed to let two months slip by without a single post. Time to get back on track, and the recently unveiled Android maintenance release provides a nice opportunity to jump start things. Official release notes for Android 4.2.2 don’t seem to be available at this time, but it made its way into AOSP quite promptly, so you can easily compile your own changelog based on git log messages. Or, you can simply check the now traditional one over at Funky Android. As you can see, there are quite a few changes, and if you want a higher level overview your time would probably be better spent reading some of the related posts by the usual suspects. Deviating from our usually somewhat obscure topics, we will focus on a new security feature that is quite visible and has received a fair bit of attention already. It was even introduced on the official Android Developers Blog, fortunately for us only in brief. As usual, we like to dig a little deeper, so if you are interested in more details about the shiny new secure debugging feature, read on.

Why bother securing debugging?

If you have done development in any programming environment, you know that ‘debugging’ is usually the exact opposite of ‘secure’. Debugging typically involves inspecting (and sometimes even changing) internal program state, dumping encrypted communication data to log files, universal root access and other scary, but necessary activities. It is hard enough without having to bother with security, so why further complicate things by making developers jump through security hoops? As it turns out, Android debugging, as provided by the Android Debug Bridge (ADB), is quite versatile and gives you almost complete control over a device when enabled. This is, of course, is very welcome if you are developing or testing an application (or the OS itself), but can also be used for other purposes. Before we give an overview of those, here is a (non-exhaustive) list of things ADB lets you do:

  • debug apps running on the device (using JWDP)
  • install and remove apps
  • copy files to and from the device
  • execute shell commands on the device
  • get the system and apps logs

If debugging is enabled on a device, you can do all of the above and more simply by connecting the device to a computer with an USB cable. If you think that’s not much of a problem because the device is locked, here’s some bad news: you don’t have to unlock the device in order to execute ADB commands. And it gets worse — if the device is rooted (as are many developer devices), you can access and change every single file, including system files and password databases. Of course, that is not the end of it: you don’t actually need a computer with development tools in order to do this: another Android device and an OTG USB cable are sufficient. Security researchers, most notably Kyle Osborn, have build tools (there’s even a GUI) that automate this and try very hard to extract as much data as possible from the device in a very short time. As we mentioned, if the device is rooted all bets are off — it is trivial to lift all of your credentials, disable or crack the device lock and even log into your Google account(s). But even without root, anything on external storage (SD card) is accessible (for example your precious photos), as are your contacts and text messages. See Kyle’s presentations for details and other attack vectors.

By now you should be at least concerned about leaving ADB access wide open, so let’s see what are some ways to secure it.

Securing ADB

Despite some innovative attacks, none of the above is particularly new, but it has remained mostly unaddressed, probably because debugging is a developer feature regular users don’t even know about. There have been some third-party solutions though, so let’s briefly review those before introducing the one implemented in the core OS. Two of the more popular apps that allow you to control USB debugging are ADB Toggle and AdbdSecure. They automatically disable ADB debugging when the device is locked or unplugged, and enable it again when you unlock it or plug in the USB cable. This is generally sufficient protection, but has one major drawback — starting and stopping the adbd daemon requires root access. If you want to develop and test apps on a device with stock firmware, you still have to disable debugging manually. Root access typically goes hand-in-hand with running custom firmware — you usually need root access to flash a new ROM version (or at least it makes it much easier) and some of the apps shipping with those ROMs take advantage of root access to give you extra features not available in the stock OS (full backup, tethering, firewalls, etc.). As a result of this, custom ROMs have traditionally shipped with root access enabled (typically in the form of a SUID su binary and an accompanying ‘Superuser’ app). Thus, once you installed your favourite custom ROM you were automatically ‘rooted’. CyanogenMod (which has over a million users and growing) changed this almost a year ago by disabling root access in their ROMs and giving you the option to enable it for apps only, for ADB of for both. This is not a bad compromise — you can both run root apps and have ADB enabled without exposing your device too much, and it can be used in combination with an app that automates toggling ADB for even more control. Of course, these solutions don’t apply to the majority of Android users — those running stock OS versions.

The first step in making ADB access harder to reach was taken in Android 4.2 which hid the ‘Developer options’ settings screen, requiring you to use a secret knock in order to enable it. While this is mildly annoying for developers, it makes sure that most users cannot enable ADB access by accident. This is, of course, only a stop-gap measure, and once you manage to turn USB debugging on, your device is once again vulnerable. A proper solution was introduced in the 4.2.2 maintenance release with the so called ‘secure USB debugging’ (it was actually commited almost a year ago, but for some reason didn’t make it into the original JB release). ‘Secure’ here refers to the fact that only hosts explicitly authorized by the user can now connect to the adbd daemon on the device and execute debugging commands. Thus if someone tries to connect a device to another one via USB in order to access ADB, they need to first unlock the target device and authorize access from the debug host by clicking ‘OK’ in the confirmation dialog shown below. You can make your decision persistent by checking the ‘Always allow from this computer’ and debugging will work just as before, as long as you are on the same machine. One thing to note is that on tablets with multi-user support the confirmation dialog is only shown to the primary (administrator) user, so you will need to switch to it in order to enable debugging. Naturally this ‘secure debugging’ is only effective if you have a reasonably secure lock screen password in place, but everyone has on of those, right? That’s pretty much all you need to know in order to secure your developer device, but if you are interested in how all of this is implemented under the hood, proceed to the next sections. We will first a give a very brief overview of the ADB architecture and then show how it has been extended in order to support authenticated debugging.

ADB overview

The Android Debug Bridge serves two main purposes: it keeps track of all devices (or emulators) connected to a host, and it offers various services to its clients (command line clients, IDEs, etc.). It consists of three main components: the ADB server, the ADB daemon (adbd) and the default command line client (adb). The ADB server runs on the host machine as a background process and decouples clients from the actual devices or emulators. It monitors device connectivity and sets their state appropriately (CONNECTED, OFFLINE, RECOVERY, etc.). The ADB daemon runs on an Android device (or emulator) and provides the actual services client use. It connects to the ADB server through USB or TCP/IP, and receives and process commands from it. Finally, adb is the command line client that lets you send commands to a particular device. In practice it is implemented in the same binary as the ADB server and thus shares much of its code.

The client talks to the local ADB server via TCP (typically via localhost:5037) using text based commands, and receives OK or FAIL responses in return. Some commands, like enumerating devices, port forwarding or daemon restart are handled by the local daemon, and some (e.g., shell or log access) naturally require a connection to the target Android device. Device access is generally accomplished by forwarding input and output streams to/from the host. The transport layer that implements this uses simple messages with a 24 byte header and an optional payload to exchange commands and responses. We will not go into further details about those, but will only note the newly added authentication commands in the next section. For more details refer to the protocol description in system/core/adb/protocol.txt and this presentation which features quite a few helpful diagrams and examples.

Secure ADB implementation

The ADB host authentication functionality is enabled by default when the system property is set to 1, and there is no way to disable it via the system settings interface (which is a good thing). The device is initially in the OFFLINE state and only goes into the ONLINE state once the host has authenticated. As you may already know, hosts use RSA keys in order to authenticate to the ADB daemon on the device. Authentication is typically a three step process:

  1. After a host tries to connect, the device sends and AUTH message of type TOKEN that includes a 20 byte random value (read from /dev/urandom).
  2. The host responds with a SIGNATURE packet that includes a SHA1withRSA signature of the random token with one of its private keys.
  3. The device tries to verify the received signature, and if signature verification succeeds, it responds with a CONNECT message and goes into the ONLINE state. If verification fails, either because the signature value doesn’t match or because there is no corresponding public key to verify with, the device sends another AUTH TOKEN with a new random value, so that the host can try authenticating again (slowing down if the number of failures goes over a certain threshold).

Signature verification typically fails the first time you connect the device to a new host because it doesn’t yet have the host key. In that case the host sends its public key in an AUTH RSAPUBLICKEY message. The device takes the MD5 hash of that key and displays it in the ‘Allow USB debugging’ confirmation dialog. Since adbd is a native daemon, the key needs to be passed to the main Android OS. This is accomplished by simply writing the key to a local socket (aptly named, ‘adbd’). When you enable ADB debugging from the developer settings screen, a thread that listens to the ‘adbd’ socket is started. When it receives a message starting with "PK" it treats it as a public key, parses it, calculates the MD5 hash and displays the confirmation dialog (an activity actually, part of the SystemUI package). If you tap ‘OK’, it sends a simple simple "OK" response and adbd uses the key to verify the authentication message (otherwise it just stays offline). In case you check the ‘Always allow from this computer’ checkbox, the public key is written to disk and automatically used for signature verification the next time you connect to the same host. The allow/deny debugging functionality, along with starting/stopping the adbd daemon, is exposed as public methods of the UsbDeviceManager system service.

We’ve described the ADB authentication protocol in some detail, but haven’t said much about the actual keys used in the process. Those are 2048-bit RSA keys and are generated by the local ADB server. They are typically stored in $HOME/.android as adbkey and On Windows that usually translates to, but keys might end up in in some cases (see issue 49465). The default key directory can be overridden by setting the ANDROID_SDK_HOME environment variable. If the ADB_VENDOR_KEYS environment variable is set, the directory it points to is also searched for keys. If no keys are found in any of the above locations, a new key pair is generated and saved. On the device, keys are stored in the /data/misc/adb/adb_keys file, and new authorized keys are appended to the same file as you accept them. Read-only ‘vendor keys’ are stored in the /adb_keys file, but it doesn’t seem to exist on current Nexus devices. The private key is in standard OpenSSL PEM format, while the public one consists of the Base 64 encoded key followed by a `user@host` user identifier, separated by space. The user identifier doesn’t seem to be used at the moment and is only meaningful on Unix-based OS’es, on Windows it is always ‘unknown@unknown’. 
While the USB debugging confirmation dialog helpfully displays a key fingerprint to let you verify you are connected to the expected host, the adb client doesn’t have a handy command to print the fingerprint of the host key. You might think that there is little room for confusion: after all there is only one cable plugged to a single machine, but if you are running a couple of VMs, thing can get a little fuzzy. Here’s one of way of displaying the host key’s fingerprint in the same format the confirmation dialog uses (run in $HOME/.android or specify the full path to the public key file):

awk '{print $1}' <|openssl base64 -A -d -a 
|openssl md5 -c|awk '{print $2}'|tr '[:lower:]' '[:upper:]'

We’ve reviewed how secure ADB debugging is implemented and have shown why it is needed, but just to show that all of this solves a real problem, we’ll finish off with a screenshot of what a failed ADB attack against an 4.2.2 device from another Android device looks like:


Android 4.2.2 finally adds a means to control  USB access to the ADB daemon by requiring debug hosts to be explicitly authorized by the user and added to a whitelist. This helps prevent information extraction via USB which requires only brief physical access and has been demonstrated to be quite effective. While secure debugging is not a feature most users will ever use directly, along with full disk encryption and a good screen lock password, it goes a long way towards making developer devices more secure. 

Mobile Security Myths

Mobile computing is the new frontier of personal technology. Whether you are on a phone or tablet, if you have a carrier connection, you are mobile.

Today, most of us can’t live without our mobile devices. We live in an always on, always connected world. While this is convenient in many ways, it also brings about new security risks that many people don’t think about.

For example, most of us know that we need to use security software on our PCs. But how many of us know to use security on our mobile devices? Mobile devices are our most personal computers, yet they open the door to many vulnerabilities that don’t exist on a traditional PC.

Here’s some fact vs. fiction around mobile devices:

Mobile Myth #1: The best way to locate my lost phone is by calling it.

  • False. While “Call Me Maybe” may be your theme song, and this is sometimes a viable option, it’s much easier to use security software that lets you locate your phone by GPS or make it “scream” so you can find it (this is much louder than your ring tone). You can also display a message on your lost phone if anyone does find it, so you can tell them how to get in touch with you.

Mobile Myth #2: It’s ok to have my apps automatically log in to my accounts if I have my phone protected with a PIN.

  • False. Even though a PIN is a good start, this is not complete protection. Hackers are often able to guess PIN codes and also have programs to help them quickly figure out your 4 digit combination. Make sure you use a PIN that is not 1111 or 1234 and that you do not set your apps or mobile browser to use the “remember me” function. If your phone falls into the wrong hands, that gives the person easy access to your accounts.

Mobile Myth #3: Phishing is just for PC users.

  • False. In fact, one study showed that mobile users are 3x more vulnerable to phishing scams than PC users. Hackers can use phishing attempts via email (if you access your email via your phone or tablet) but also via text and social media apps. Also, it is much harder to tell if links are “real” in a mobile browser or email, so you should use mobile security software that warns you if you are going to a malicious site.

These are just a few mobile myths that exist out there. To really test your mobile knowledge, play our Mobile Mythbusters quiz on Facebook, where you can also enter to win great prizes like a Galaxy tablet, Kindle Fire, or a copy of my e-book “99 Things You Wish You Knew Before Your Mobile Device Was Hacked,” all with a 1-year subscription to McAfee Mobile Security.


In addition, share you’re your mobile myths with @McAfeeConsumer using the hashtag #MobileMyths to help debunk mobile security myths and protect yourself and others. Top tweeters will win a copy of McAfee All Access or McAfee Mobile Security.

And if you’re going to be at Mobile World Congress, stop by to visit McAfee and see our product demos. We’re in the Intel booth in Hall 3, Stand C34. You may even get a small gift if you show that you’ve liked McAfee on Facebook or followed us on Twitter when you come see the people in the red shirts!


Robert Siciliano is an Online Security Expert to McAfee. He is the author of 99 Things You Wish You Knew Before Your Mobile was Hacked!  (Disclosures)

The post Mobile Security Myths appeared first on McAfee Blogs.