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.

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.