Saturday 7 September 2013

Malicious Android APK ‘Sensitive Information Stealer’


Profile of a recently released cybercrime-friendly Windows-based tool that’s capable of generating malicious ‘sensitive information stealing’ Android .apk apps, emphasize on its core features, and most importantly, discuss in depth the implications this type of tool could have on the overall state of the Android malware market.
More details: Sample screenshots of the malicious Android .apk generating ‘sensitive information stealer’:
DIY_Android_Malware_Generating_APK DIY_Android_Malware_Generating_APK_01 DIY_Android_Malware_Generating_APK_03 DIY_Android_Malware_Generating_APK_02
The cybercriminal is capable of stealing WhatsApp messages (only on rooted devices), SMS messages, personal info, contacts and photos, and can also be made to auto-start, or be triggered by a specific SMS message sent to the device. The stolen data can then be configured to be sent back to the attacker, using the existing connection of the victim, or in an ‘all-in-one’ zip file to a pre-configured email account.
Not surprisingly, cracked versions of the ‘sensitive information stealer’ are already circulating in the wild.
What’s also worth emphasizing on in terms of the relevance of such tools in today’s Android malware market segment, is that automation, efficiency and QA (Quality Assurance) are likely to continue getting applied to commercially available underground market releases, that enable virtually anyone who purchases them to generate undetected pieces of malicious software for the Android platform, to be later on monetized through an affiliate network.
Moreover, in times when mobile traffic can be purchased/abused on the fly, and redirected to any given URL provided by a potential cybercriminal, we expect to continue observing an abuse of cybercrime-friendly underground market traffic exchanges, in combination with either the direct compromise of a legitimate host, or actual hijacking of a trusted/verified Google Play account through data mining a botnet’s infected population as a tactic of choice.

Hack First, Policy Second – A Mobile Device Story

Like many of you I was extremely excited when my organization started allowing purchases of iPhones and Android devices.  With the entire buzz around “the consumerization of IT” and “Bring Your Own Device (BYOD),” it wasn’t long before these devices started becoming a necessity for business rather than simply the coolest new gadget.  Syncing my email and calendar was a great first start, although I have to admit the electronic leash has become quite long in the past few years.  When I was able to make travel reservations, submit expense reports, attend internal web conferences, review Statements of Work (SoW) and presentations all without opening my laptop, I became a huge fan. Policy never came to mind much less a hack first mentality.
If you’ve read any of my previous articles, then you will realize I come from a hacking background first and foremost.  Therefore, when I began to delve into mobile security, I didn’t start with learning best practices or how to develop secure mobile applications.  And a corporate policy was definitely the last thing on my mind. I simply wanted to start breaking things.  However, as it wouldn’t do to brick a corporate device, I explored the possibility of purchasing an iPhone/iPad/iPod without a data plan to use as a hardware testing platform.  This was not only a stroke of genius for learning mobile application security, but it led to this article.  So let’s look at a practical business decision, but, from the get-go, approach it as a hacking exercise.

Why Hack First?

I initially didn’t realize the struggle IT departments had dealing with mobile devices, because, let’s face it, ignorance is bliss.  Everything was moving at lightning speed, as business typically does, and it wasn’t long before security concerns started to be called into question.  Then the reins began to be pulled taut.  Are we securing email appropriately when we sync?  Should phones be allowed access to the corporate wireless network or only the guest network?  Do we need antivirus and firewalls on the phone?  Do we allow/support applications on our systems that allow the phones to be backed up?  Do we scan these devices as part of our vulnerability management program when they are connected to the network?  What happens if a phone is lost or the employee is terminated?  All the same issues and more can be applied to tablets as well. I can hear the collective scream of IT departments over the globe yelling, “HELP!!” If there is an app for that, shouldn’t we have a policy for that? But a policy for what? And how do we get it approved? That’s where the hacking comes into play.

My “Harajuku” Moment

Tim Ferriss, author of “The 4-Hour Body” wrote an analogy about a friend of his who had been shopping in the Harajuku area of Tokyo, Japan, and made the statement that it wouldn’t matter what he wore, he wasn’t going to look good anyway.  The story goes that the statement hung in the air like when you say something super-embarrassing in a loud room but happen to catch that one moment of silence and everyone hears you.  That moment was the tipping point for the friend to go on and lose 70+ pounds in less than 12 months.  Tim goes on to write that, “People suck at advice because most people have an insufficient reason for action.  The pain isn’t painful enough.  It’s a nice-to-have, not a must-have.  There has been no “Harajuku Moment.”  So, what was my Harajuku Moment for mobile policies?
As began exploring mobile device security, I investigated what is known as the keychain.  The keychain is a secure location inside iOS where usernames, passwords, tokens, certificates and other information is typically stored.  The data contained within this keychain is encrypted and tied to the action of locking and unlocking the device.  Check out this link to dig into this further and learn about when keychain items should be readable.
If you don’t want to go through all of that, then just keep in mind that if an attacker gains access to the device, all data in the keychain is compromised.  This really isn’t an issue if someone doesn’t have physical access to your device, but how many of us have lost a phone?  Ok, what if we don’t lose it, but simply misplace it for an unexpected amount of time (Wink, wink, nod, nod goes the attacker).
Keeping this in mind, my moment came when I used the tool keychain_dumper from https://github.com/ptoomey3/Keychain-Dumper.  Accessing my iPhone via secure shell (SSH) while it was connected to my laptop, I simply ran the command and discovered the following:
Hack First, Policy Second - Kali Linux Screenshot
Hack First, Policy Second – Kali Linux Screenshot
Those two service headings for AirPort are account settings for wireless networks.  What I discovered is the shop I had purchased the iPhone from had connected to its local wireless networks (guest and internal), and that I now had a Service Set Identifier (SSID) and the password to connect to that network.  I verified this because scrolling down I also found my own home wireless network and password at the same time.  So, why is this such a big deal?
Gaining access to a smart phone can be rudimentary for most attackers.  In this example I could have done the same thing against a ‘borrowed’ device, replaced it, and the user would have been none the wiser.  Then I could have simply accessed the user’s wireless network to further escalate any attacks against the user, or the user’s organization.  What really struck me is the business had used the same wireless network to run my credit card for the purchase!  The potential ability to gain access to credit card information affects Payment Card Industry (PCI) compliance as well as a slew of other privacy and security concerns.

Conclusion

I’ve often argued that an effective security awareness program must have some real world experience from which users can directly relate.  In this scenario, the real world experience hit me square in the face.  Mobile application security or mobile security awareness in general went from ‘it’s a nice-to-have’ to a ‘must-have.’  I had had my “Harajuku Moment.”
The real trick is then taking this moment and relaying it to the higher ups. The beauty is that it’s not just a ‘kewl hack’ that they’ll never understand. You can tie it directly to being a compliance issue. This makes the techie not only look good for knowing the business end of things, but it also has a greater chance of leading to a real policy with management buy-in.  We all know how hard that can be.  And this can all be done by focusing on the hacking aspect first.  How cool is that?
So, based on this experience, what should we be telling upper management about mobile device security?  First and foremost, have a policy.  Then start working on the processes to address situations illustrated above.  Here are some initial guidelines these policies and processes should address:
  • Your policy should remind employees that they have no expectation of privacy if a device is company owned.
  • Whether a device is company owned, or not, you should point back to your standard “Acceptable Use Policies”, i.e. the device should only be used for work-related purposes while on company time or while using company resources, like your organization’s wireless infrastructure.
  • Consider “data usage” restriction clauses in the policy, i.e. PCI data and applications should not be accessed from a mobile device.
  • Consider support restrictions and note that the end-user is responsible for third-party or “beta” release software, unless explicitly listed as being a supported company application.
  • Consider changes in your architecture, i.e. access to an organization’s VPN via a wireless interface should be segmented appropriately.
  • Consider process and technology capabilities, such as:
    • enabling remote wipe of the device.
    • using encrypted containers on the device to store corporate application and data and be able to manage/backup these assets remotely.
    • limiting application loading to only corporate approved software on corporate supplied phones.
    • limiting hot-spot capability when connected to a corporate network.
    • enforcing remote usage monitoring if supported.
If we’re truly ‘ethical’ hackers, then we shouldn’t just be attacking things for the heck of it. We should always have in mind that we are finding security gaps for the purpose of trying to close them. What a better way to justify what we do to those who may not understand, than to do a real-world attack with a real-world consequence.  So rather than learning about this the hard way, I hope my experience will help drive home the point as to why we should be thinking about mobile security and in turn the policies to have in place to protect not only our corporate data, but also the individuals who access it.
I’m sure I’m not the only one that has seen mobile devices cause headaches throughout the wider IT community. By applying our unique perspectives as security professionals with a penchant for digging deeper, we can help others add to their toolbox when dealing with users and management.  It would be very helpful for me to learn from the success or failures of others and their organizations.  So please share with us your stories in the forum thread at the bottom of this article, and we can all benefit from hacking things first.

Watch out for Waterhole Web Attacks

As every kid who grew up watching "Wild Kingdom" knows, there are few places in the jungle more dangerous than a watering hole because of the hungry lions lurking there with hopes of picking off a gazelle or two.
Now hackers are using a similar technique to prey on unwitting website visitors. Alex Watson, director of Security Research for Websense, explains that hackers plant malware on sites popular with their intended victims, catching some of them in the same way a lion catches a gazelle with its guard down.
Earlier this year, for instance, hackers were able to circumvent security systems at Google, Apple, Twitter and Facebook after employees of those companies visited a site popular with software developers. Hackers usually employ a backdoor approach to install malware that is then used to harvest documents, email contacts, social contacts and passwords. In these instances, valuable intellectual property is likely the object of hackers' desire.

More recently hackers targeted visitors to the Central Tibetan Administration website and other sites with a pro-Tibet slant. These attacks were likely motivated by political or social objectives.
Watson called waterholing an "evolution in the security landscape" that occurred when security professionals got better at deflecting email-based attacks that indiscriminately targeted large numbers of users. "That forced criminals to come up with new tactics," he said.

Old Dogs, New Tricks

The techniques used in waterhole attacks aren't new, said Adam Wosotowsky, a messaging data architect for McAfee. But they are facilitated by "the fact that people like their browsing to be 'pretty,' which means our browsers are generally configured to automatically execute Flash ads, Javascript, PDFs, Word docs and the like. All of those things are easily exploitable to use to push a download to someone without prompting them."
The attacks do use many tried-and-true techniques, agreed Watson, but there are some interesting twists. For instance, some of the attacks seem to target only specific website visitors, delivering malware to some but not all who land on a site. Hackers also appear to use varying levels of sophistication, employing simple tactics for small and relatively unsecure sites but stepping up their game for those with stronger security.
"It's interesting to see criminals tailoring their attacks," Watson said. "This avoids giving away techniques and procedures. They do not want to expose their best tools."
As with many Web-based attacks, hackers often leverage sites with outdated software or a lack of patches for known vulnerabilities, Wosotowsky said. That is why it is important to download security updates as soon as they become available.

Defending Against Waterhole Attacks

Wosotowsky recommended using safe search tools like McAfee's SiteAdvisor, which informs users if the sites in their search results are safe. Another helpful McAfee product, he said, is Internet Security for Mac, which is set by default to receive automatic daily updates to ensure PCs are protected from new threats.
Sites using popular programs with well-known security vulnerabilities are a frequent target, Watson said, mentioning WordPress as an example. "It might be better to use managed or hosted WordPress, so you know the infrastructure will be updated regularly." He also suggested using Web application firewalls, disabling Java in the browser if it is not an absolute requirement, and even switching to less popular browsers or operating systems since hackers tend to focus on those with the most users.
Watson said the best defense against these types of attacks is comprehensive data leak prevention solutions such as Websense's Data Security Suite that provide multiple layers of defense encompassing Web, email and mobile security. "When you put these kinds of solutions together so they can talk to each other, it becomes really hard to pull off attacks like this because you will be stopped at some point in the attack chain," he said.