Hi All!

Life has been busy for me lately outside of the tech blogger life so my apologies in the delay between articles.

In this article I want to discuss why, when downloading “Apps” for your Android phone you should stick to the “Play Store” or a trusted source. Although there has been many reports as of the recent mentioning Apps that made it into the Play Store with malware attached (ex: Judy Malware), it is much less common to have an App in the Play Store be infected than to download an “Untrusted APK” from elsewhere containing malware.

I was inspired to write this article after a friend told me he was using an app that you have to download from a random website as it is not allowed in the Play Store. I asked why it wasn’t allowed in the Play Store and he said because it helps you “cheat” in a game called “Pokemon Go” by giving you stats on the Pokemon creatures you caught in the game that you wouldn’t otherwise have direct access to. For this reason it is believed that this app “IVFly” was denied from the Play Store at the request of the creators of Pokemon Go – Niantic.

I thought to myself, if I was the creator of IVFly and I really wanted to steal a good amount of peoples sensitive data, I don’t think it wouldn’t be too hard. Everyone who is using it is downloading it from random links and then telling their phone to create an exception for this “untrusted” APK. Real quick for those who don’t know – APK (Android Package Kit) is basically the install file for Android applications. I plan to show you today how installing an untrusted APK can lead to the leaking of sensitive information on your device. Note- This isn’t an issue specifically with IVFly – it can be done with almost any untrusted app.

The first step I’m going to take is to grab a copy of the IVFly APK file and download it to my Kali Linux machine. I am going to utilize it to hide my Meterpreter payload.

ivdownload

Next, I want to inject the payload into the APK. However in order to do so I need to determine a few things.

  • Will the target be on the same LAN? If so you can use your “listener/handler” machines local IP. If the target phone is on a remote network, not connected to the same network as you, you will need a public IP address for the callback payload to connect to, you may also need to port forward depending on the setup you have.
  • In the screenshot below you will either use your local IP address, or the external IP address you are “listening” from in the “LHOST” parameter. In my example, my listening device was an EC2 instance in the Amazon Cloud so I use the public IP of that machine. I talk more about setting up EC2 instances in one of my past articles HOWTo: Crack Hashes Faster in the Cloud!

In my example I log in to the AWS console and fire up my EC2 instance loaded with Ubuntu – complete with Kali Linux repositories. Once it’s powered on I will be shown my public IP address. With the public IP address I can do 2 things.

  1. SSH into the machine to set up the listener
  2. Note the IP for the payload

Next I create the payload and inject it into the APK with MSFVenom referencing the IP of the listener in LHOST and also choosing port 4444 which is commonly used in these types of scenarios but not much elsewhere…

msfvenomapk.png

We now have a meterpreter reverse TCP callback payload loaded into what will appear on the target phone as the normal IVFly app.

The method for getting the app onto the target phone will most likely have to be social engineering. But as mentioned earlier – people are downloading this app just because of “word-of-mouth”, in other words they know someone else who is using it so they decide to use it too. I could hypothetically set up a dropbox or apache server and advertise myself as a mirror download site for the app for users looking to download it. If they chose my “mirror” link they would get the malicious version instead of the non-malicious version. A technically inclined person would see if the non-malicious original source published a form of hash to compare it to my mirror and would instantly know it’s been modified because the hashes wouldn’t match… however we will assume the vast majority of people are not doing that who are using this app.

When the user downloads and attempts to install this APK they will receive multiple warnings, however that is because this app isn’t from a “trusted source” like the Play Store. So they are receiving these warnings even if they were getting the original APK rather than the malicious one we created (since IVFly is currently hosted from a DropBox link.)

downloadinstall1install2

Assuming our user has clicked through the warnings and installed the APK anyway, they will have installed the app and the only thing we have left to do is ensure our listener machine has a handler running to receive the callback from the payload.

I will use Metasploit for this on my AWS Ubuntu EC2 machine. While setting up the handler/listener in metasploit the LHOST IP should be the machines LAN IP address, not the WAN IP we set in the payload.

Lastly, the user just needs to open the app and BOOM we have a Meterpreter shell on the Android device. They don’t even need to do anything in the app, simply just open it.

Below are screenshots of the app opened on the phone, and the sysinfo command within the Meterpreter shell confirming we have connected to the Android device.

ivflyopen.png

MSFListen

Another command you see in the above screenshot is the getuid command. This will tell you what user the shell is running as. While a meterpreter shell has tons of fun tools/commands, the only ones that will work as of the moment are the ones user u0_a265 would have permission to access. For example one of the meterpreter commands an attack may want to run is geolocate which would essentially return the physical coordinates of the phone. However, because our current user does not have access to the location feature of the Android device, we will get an error.

geo.PNG

However it appears we do have the ability to remote screenshot as the current user.

screenshot.PNG

Now that we have made it this far we have some things to think about.

  • Are there privilege escalation vulnerabilities that exist on this version of Android/Linux?
  • Can we compile the APK manually in a different way to ask the user who installs the malicious APK for additional permissions, hoping the just say “ok”?
  • What information can we leak knowing we have at least the ability to screenshot?
  • Where do we go from here to further this attack?

Well quite honestly this is as far as I’ve had time to get recently… but I hope to continue this research and perhaps release a “Part 2” to this article.

If anyone makes it further than this or has suggestions, I would love to hear them! Drop a comment or reach me via the “contact” page. Also feel free to do the same if you have any questions! Remember I’m still learning too so I may not have the answers, but I’m more than happy to try and assist – hence my slogan “Grow with me”.

I appreciate your views, shares, and emails via the contact page!

-N0ur5

Advertisements