Methods to Monitor Ads For Malware on Mobile Devices

Question

I've noticed that malware being introduced to a mobile application or web application through advertisements, unknown to the developer of the application, is becoming increasingly popular. I've been searching around for a tool or method to detect or monitor the advertisements being introduced to the application for malware. My search has not turned up much. I can manually view the advertisements code each time, though that is tedious, non-automated and only a loose solution. Does anyone have any thoughts or experience on monitoring advertisements in a mobile application for malware?

Answer 1

This type of problem really needs to be addressed at a few different levels, the user, the publisher, and the programmer. Each holds a degree of responsibility and as such no matter your role, you are responsible. Based on your plan of inspecting individual code, I suspect that you are an end-user and not a programmer. As such, I'll focus mostly on that realm.

Ways to Reduce Risk as End User

An end-user can do a few things to determine if the ad is malicious. This includes the basics, such as installing a Mobile AV (Such as Sophos on Android). The steps that you are currently taking (Investigating the payload) is generally far more in-depth than most end-users would ever want to do. This gap can easily be filled with an AV and possibly a mobile IDS/IPS (Such as zIPS). The line of host-based IPS and AV are very blurred these days and can lead to some overlap. The key point is that the IPS is designed to work to prevent your system from being breached. Whereas the AV is working to clean-up the breach after the fact.

An example of a normal Advertisement Transaction:

Here's an example of the steps that lead to an advertisement being delivered:

1. You open the App
2. The app opens up and allows you to use it for X number of seconds
3. After a fixed time constraint or a certain criteria is reached (Eg. You complete a level in a game) the app decides to deliver an ad.
4. The app triggers the request to an included library
5. The included library then makes an API request with some of your information to an external site
6. The external site accepts the request and processes the request to determine the best advertisement to deliver
7. The ad is delivered to your device
8. After the ad is complete, you can continue to use the app again until another constraint is reached

An example of malvertising

1. List item
2. You open the App
3. The app opens up and allows you to use it for X number of seconds
4. After a fixed time constraint or a certain criteria is reached (Eg. You complete a level in a game) the app decides to deliver an ad.
5. The app triggers the request to an included library
6. The included library then makes an API request with some of your information to an external site
7. The external site uses the data to determine if you could be vulnerable to a specific exploit. This is determined based off of a number of different factors, which most off includes user-agent inspection, but may include factors like javascript checking.
8. Once the most effective exploit is determined, the payload to sent to the device. This is the point where the security of your device is tested.
9. The payload will either run, or run and then compile, on your machine. If the infection is successful, you may not be able to tell.

What an IPS will do

The benefit of using an IPS is that when a website is requested (In your case an advertisement), it will check the request and the response for signs of malicious activity. A common way that malware is delivered in advertisements is via a base-encoding and decoding formula that serves no real purpose. A smart IPS will detect when a base-encode formula is used in numerous different instances and concatenates results together followed by a final decode of the entire payload.

In the case of the above IPS solution, it will also inform you when you are at risk of MITM attacks and various other issues. It also has a built-in AV function. This falls back into where I stated that the lines are very blurred between the different tools.

Ways to Reduce Risk as a Publisher

Here are some of the ways that a publisher can reduce their risk: - Ensure that your code does not have major vulnerabilities or introduces vulnerabilities on end-users. - Monitor for any suspicious behavior occurring on your ad-network.. This should be checking for unusual advertisement payloads as well as indications that your ad-network have been compromised. - Perform code reviews of advertisements being delivered on your network

Ways to Reduce Risk as a Programmer

It's very difficult to mitigate the risk when the vulnerabilities exist on the user and the advertisements are delivered from your advertising partner. The biggest take-away is that you ensure that the advertising network that you choose is a trusted one. This generally means staying away from unknown third-parties or networks that offer an exorbitant PPC (Pay-per-click). These are generally warning signs. In addition you should offer the following to users:

• Offer a way to report malicious ads in the application
• Perform independent checks for malicious code (This may be difficult to maintain as signature sets change everyday.)
• Log what ads were delivered to submit feedback to the ad-network operators.
• Perform extensive QA with advertisements on numerous different OS versions and device types to check for any obvious malvertising campaigns.

Synopsis

This can really only be addressed using a layered defense tactic. If you rely on only a single link in the chain, it will inevitably break. I found that a recent study, The Dark Alleys of Madison Avenue: Understanding Malicious Advertisements, suggests that up to 1% of ads contain malvertising code. That's a pretty incredible statistic given how many sites offer advertisements. It also highlights that if we relied solely on advertisers to ensure the security of the advertisements, we would be in serious trouble.