Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2015-11-09 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Protecting Users and Enterprises from the Mobile Malware Threat

Published: 2015-11-09
Last Updated: 2015-11-09 21:47:36 UTC
by John Bambenek (Version: 1)
3 comment(s)

With recent news of mobile malicious adware that "roots" smartphones, attention is again being paid to mobile security and the malware threat that is posed to it. While mobile ransomware is also a pervasive and growing threat, there are mobile RATs (such as JSocket and OmniRAT) that are also able to take full remote control of mobile devices.  Some of the functionality of those tolls includes the ability to use the microphone to listen in on victims and to view whatever is in front of the camera while the unsuspected victims goes about their day.

It's important to realize that mobile malware, in essence, is just a question of apps.  Even in the adware "rooting" apps above, it all still begins with installing an application which means there are some defined ways users and enterprises can protect themselves.  The other danger is that most of the time, these devices are on the cellular network so they operate outside all of the network protective technologies an enterprise has to detect, if not prevent, compromise.  Here is a quick list of what users and enterprises can do. 

For users:

  • Never install applications outside of the mobile "app" stores (i.e. Google Play, Apple's App Store)
  • Ensure that smartphones are set to NOT install apps from unverified sources
  • Do NOT root/jailbreak your phones as this removes a great deal of the security features
  • Observe what permissions applications are requesting on install and reject those that want the Christmas Tree list of permissions (i.e. all of them)
  • Install a mobile anti-malware solution of your choosing

For enterprises:

  • For phones under your control, ensure all the above are set and are unmodifiable by the end-user
  • Provide users in sensitive positions a corporate provided phone so that you can do the above and restrict sensitive information to the corporate phone
  • Provide a BYOD network for personal mobile devices and monitor that network for indicators of compromise and respond accordingly.  Encourage users to use that network.

What else would you add to this list?

--
John Bambenek
bambenek\at\ gmail /dot/ com
Fidelis Cybersecurity

3 comment(s)

ICYMI: Widespread Unserialize Vulnerability in Java

Published: 2015-11-09
Last Updated: 2015-11-09 15:45:41 UTC
by John Bambenek (Version: 1)
1 comment(s)

On Friday, a blog post from Fox Glove Security was posted that details a widespread Java unserialize vulnerability that affects all the major flavors of middleware (WebSphere, WebLogic, et al).  There is a lot of great details, including exploitation instructions for pentesters, in the post so go take a look. It didn't get much press because admittedly it's complicated to explain.  It also doesn't have a logo.

In this case, they describe how to use this class of vulnerabilities for remote code execution of Java-based web applications.  This vulnerability is present in the "common-collections" library in Java.  As you can imagine from the name, this has a huge surface area of attack of applications all over including those that are custom-coded that use those class files.

The exploits demonstrated have to be initiated from the local network, but in poorly configured environments this may lead to truly remote attacks being successful.

The short version is that many programming languages (in this case Java), accept serialized input from users and convert it to unserialized data.  If that data is not otherwise sanitized (or ideally, never take untrusted input in the first place, at least for unauthenticated users).  It's the oldie but goodie of unsanitized input with a mix of OWASP A9 of Components with Known Vulnerabilities.

At present, these does not appear to be a patch for the vulnerability but the blog post above does layout a very ugly mitigation that can be deployed.

P.S. From the blog, "No one gave it a fancy name, there were no press releases, nobody called XXXXXX (insert firm I shouldn't mock here) to come put out the fires.". Well played, good sir, well played.

--
John Bambenek
bambenek\at\ gmail /dot/ com
Fidelis Cybersecurity

1 comment(s)
Diary Archives