https://appsec-labs.com/portal/wp-content/uploads/2020/12/logo-dark1.png100100Michael Yermakovhttps://appsec-labs.com/blog/wp-content/uploads/2014/07/AppSec_Logo-300x68.jpgMichael Yermakov2020-12-07 14:55:302020-12-07 15:20:06Advanced Testing Of Web Application With Custom Message Signing Using Hackvertor
The cleartextTrafficPermitted flag is one of the options in Android’s Network Security Configurationfile. The online documentation (https://developer.android.com/training/articles/security-config) explains that from Android 9 (API level 28) and higher, it will be set by default to false and it is intended to prevent insecure communication attempts using clear-text HTTP originating from Android applications.
OK, so what does this actually mean? Will all apps that run on the Android 9 platform with a default configuration be protected? Do these flags instruct the system to prohibit any kind of non-secure TCP communications or does it only apply to HTTP? What about 3rd party libraries such as OkHttp, async-http-client, dubbo? What about WebView controllers? What about native libraries issuing network requests? To answer all these questions, we need to understand at which level this configuration is being enforced. Otherwise, we may fall into a false sense of security.
But how does it actually work? What component and at which level enforces these restrictions? Is it a kernel module such as SELinux or AppArmor? It is Linux containers? Is it the Android Runtime environment? Is it a compiler flag that acts at the time of Ahead-Of-Time or Just-in-time compilation to strip the insecure code parts?
In this article, we will try to understand how this flag works by example and how it can help us to make a more secure application. We will also learn by example which use-cases aren’t being protected by the flag.
The importance of TLS
Just before we begin, a short recap on why we need to protect all application communication with TLS.
Potential threat agents include:
Wi-fi layer attackers – Numerous router level vulnerabilities, wi-fi hacking, and results of our private research show that tens of millions of routers could be compromised. As such, even home wi-fi cannot be considered as a secure by default. The app must maintain security at the network layer to provide secure transport for app-server communications.
WAN layer attackers – ISPs logging network traffic or APT and Government level actors monitoring communications at central network hops.
Compromised communications can lead to a number of possible risks including:
Hijacking secrets from client-side libraries via server-initiated redirects (We will talk about this more in the next blog post)
HTTPS connections can be downgraded to HTTP even if a server does not support HTTP
Open redirects to HTTP, both client-side initiated and server-side triggered (for example, the HTTP Desync Attack)
HTML injected resources (img) with http:// link that trigger HTTP communication
In-app user-provided clear-text HTTP link to app’s domain
Cache poisoning resulting in clear-text HTTP redirects
Creating a test-bed
To check how applications actually behave, we created an Android testing application and a python server for the application to communicate with. The test included trying different target APIs for the application and checking for each target API if the app could issue non-secure outgoing HTTP requests using different libraries as well as the default Android WebView controller.
For each library, three requests were sent: standard HTTPS, standard HTTP, and an HTTPS request to a URL which redirects the user agent to HTTP to simulate server-side-issued redirect attacks.
Testing notes
Test results for HTTPS to HTTP redirects were the same as for HTTP. If in normal conditions the library prohibits HTTP connections it will also prohibit redirects to HTTP.
Differences between minimal, target, and compile SDK versions from the manifest file:
Minimal API – minimal API support required for the app to work;
Compile API – IDE compiler used to compile the app
Target API – the API level on which the application should run correctly as it was fully tested by the developers.
Minimum SDK has no impact on how the cleartextTrafficPermitted flag is being enforced; only the API target level affects it.
Most of the security issues arise on outdated Android OS versions. However, these versions are running on a large number of devices according to Google:
The results
This section will go through the results for the different libraries tested.
OkHttp
OkHttp is the most popular Android HTTP library and is maintained by Square: https://square.github.io/okhttp/. For the test the latest 3.* and 4.* versions were used. The results for both versions were the same.
The following table shows the results of using our testing app with different target SDK configurations and without the clearTextTrafficPermited flag set (i.e. the default configuration) on multiple Android devices of different OS versions.
Android 5 API 21
Android 6 API 23
Android 7.1 API 25
Android 8 API 26
Android 9 API 28
Android 10 API 29
target API 21-27
HTTP works
HTTP works
HTTP works
HTTP works
HTTP works
HTTP works
target API 28+
HTTP works
HTTP works
HTTP works
HTTP works
HTTP doesn’t work
HTTP doesn’t work
The following table shows the results of using our testing app with different target SDK configurations and with the clearTextTrafficPermited flag set to “false” on multiple Android devices of different OS versions.
<base-config cleartextTrafficPermitted=“false”>
Android 5 API 21
Android 6 API 23
Android 7.1 API 25
Android 8 API 26
Android 9 API 28
Android 10 API 29
target API 21-27
HTTP works
HTTP works
HTTP doesn’t work
HTTP doesn’t work
HTTP doesn’t work
HTTP doesn’t work
target API 28+
HTTP works
HTTP works
HTTP doesn’t work
HTTP doesn’t work
HTTP doesn’t work
HTTP doesn’t work
The following table shows the results of using our testing app with different target SDK configurations and with the clearTextTrafficPermited flag set to “true” on multiple Android devices of different OS versions.
<base-config cleartextTrafficPermitted=“true”>
Android 5 API 21
Android 6 API 23
Android 7.1 API 25
Android 8 API 26
Android 9 API 28
Android 10 API 29
target API 21-27
HTTP works
HTTP works
HTTP works
HTTP works
HTTP works
HTTP works
target API 28+
HTTP works
HTTP works
HTTP works
HTTP works
HTTP works
HTTP works
When the network security policy is being correctly enforced, the OkHttp library won’t issue the request and will throw the following exception:
We can find multiple instances of checking the flag in OkHttp’s source code (https://github.com/square/okhttp) and can manually verify at which cases the check is being done. However, understanding the libraries internal logic may be required to identify the edge cases in which the flag could be ignored. The screenshot shows the source code for the relevant part of the connection chain:
Other Popular Network Libraries for Android
This section shows results for async-http-client library but the results were the same for multiple other libraries that were tested. For the most part, libraries which use okhttp “behind the scenes” support the flag but other popular Android libraries which don’t use okhttp (like async-http-client and many others) don’t support the flag at all.
The following table shows the results of using our testing app with different target SDK configurations with the clearTextTrafficPermited flag set to “false” on multiple Android devices of different OS versions. Since the flag is unsupported, the behavior is in fact the same as if the flag wasn’t set or if the flag was set to “true”.
<base-config cleartextTrafficPermitted=“false”>
Android 5 API 21
Android 6 API 23
Android 7.1 API 25
Android 8 API 26
Android 9 API 28
Android 10 API 29
target API 21-27
HTTP works
HTTP works
HTTP works
HTTP works
HTTP works
HTTP works
target API 28+
HTTP works
HTTP works
HTTP works
HTTP works
HTTP works
HTTP works
Android WebView
In this section we tested the default Android WebView . This test showed that in fact the WebView controller behaves differently to the OkHttp library in the context of enforcing the configuration flag. In particular:
When the application’s target API is 25 or less, the “cleartextTrafficPermitted=”false”” is being ignored across all tested Android OS versions.
When HTTP redirect occurs, the WebView behaves differently – it forwards the request to the device’s default browser (external) instead of rendering it on its own. This is secure behavior since the browser doesn’t send any sensitive cookies because it runs in a different context to the application’s WebView.
The following table shows the results of using WebView in our testing app with different target SDK configurations and without a value for the clearTextTrafficPermited flag set (default configuration) on multiple Android devices of different OS versions.
Android 5 API 21
Android 6 API 23
Android 7.1 API 25
8 API 26
9 API 28
10 API 29
target API 23-27
HTTP works
HTTP works
HTTP works
HTTP works
HTTP works
HTTP works
target API 28+
HTTP works
HTTP works
HTTP works
HTTP works
HTTP doesn’t work
HTTP doesn’t work
The following table shows the results of using WebView in our testing app with different target SDK configurations and with the clearTextTrafficPermited flag set to “false” on multiple Android devices of different OS versions.
Android 5 API 21
Android 6 API 23
Android 7.1 API 25
8 API 26
9 API 28
10 API 29
target API 23-25
HTTP works
HTTP works
HTTP works
HTTP works
HTTP works
HTTP works
target API 26-27
HTTP works
HTTP works
HTTP doesn’t work
HTTP doesn’t work
HTTP doesn’t work
HTTP doesn’t work
target API 28+
HTTP works
HTTP works
HTTP doesn’t work
HTTP doesn’t work
HTTP doesn’t work
HTTP doesn’t work
When the network policy is being correctly enforced, the WebView will show the following image
In this section we will summarize some of the key questions which we have answered so far in our research:
What happens when the app communicates using HTTP and makes use of a framework/library which does not support this manifest flag
No restrictions will be in place
At which level does the manifest restrict clear-text communications?
Each library reads the flag from configuration flags and enforces the restrictions but only if it supports the flag.
What happens when native code issues a clear-text network request? For example, it sends an HTTP request or sends binary data (such as protobuf)? Will it be protected by this manifest configuration?
Only if the library supports the flag. In most cases these libraries won’t support the flag. The native code libraries and non-HTML libraries mostly have no flag awareness and support. You should rely only on how you configured the library. These configs either can be done in a “config” file or at the actual network request object properties and methods.
What happens when these libraries issue requests using HTTP and nonstandard port?
Generally, if the library supports the flag it will block all outgoing cleartext HTTP communication regardless of the port.
Result analysis and wrap-up
Multiple tests show that manifest flag clearTextTrafficPermited is not being universally enforced by either the Android OS or at the SDK level. IN practice, each client-side library must implement support for the flag on its own and the actual implementation may heavily differ from one library to another.
Certain libraries such as OkHttp (or Volley which uses OkHttp behind the scenes) have full support for this flag according to their documentation. However, many other HTTP libraries which do not use OkHttp do not support it at all and the presence of the flag has no impact on the app’s behavior.
The Android WebView component has support for the flag but actual results show inconsistencies between the WebView and OkHttp implementations. In fact, Android WebView puts more clients at risk compared to OkHttp (refer to the WebView result table) as it does not enforce the flag unless target API is 26+.
Regarding other clients, such as binary communication libraries, etc, do not assume that these libraries will respect the flag. Instead, the source code of each such library should be checked for the code part that enforces the restrictions on outgoing insecure communications. The default assumption for all client-side network libraries should be that they don’t support the flag unless the library explicitly states that it does.
Despite the lack of actual system-wide level protection, the flag still offers a greater level of security in situations where it is supported by the client library and either the application’s target SDK is set to 28+ or the application is running on Android 7.1 or higher.
Recommendations:
Activate the clearTextTrafficPermited protection by setting it to “false” for all outgoing connections.
Set the target API level to 28+.
Check actual support for the flag across different libraries in use in your application.
Be aware that the flag enforcement has its restrictions.
Enforce other supplementary transport security measures, such as:
Using secure response headers such as HSTS.
Using explicit request object configurations to prohibit HTTP.
Implementing custom interception layers for libraries being used which will block clear-text URI schemes.
Removing any HTTP:// links from the code and server’s configuration.
https://appsec-labs.com/blog/wp-content/uploads/2014/07/AppSec_Logo-300x68.jpg00Michael Yermakovhttps://appsec-labs.com/blog/wp-content/uploads/2014/07/AppSec_Logo-300x68.jpgMichael Yermakov2020-06-15 17:58:112020-06-15 17:58:13Understanding the Android clearTextTrafficPermitted Flag
In almost every Android application, developers expose activities without sufficient protections. Exposing activities can lead to various attacks. For example, an attacker or a malicious app installed on the same device, can call those exposed activities to invoke internal pages of the application. Calling internal pages puts the application at risk of phishing by manipulating […]
When performing security (or regular) tests on Android applications, we sometimes need to emulate or fake mobile data or actions; making/receiving calls, sending SMS or setting the exact geo-location are some commands that can be done, using the Emulator Console. Here are a few tricks that will help you through Android application testing using the emulator:
The Monkey is a command-line tool that runs on the emulator instance or on a device. When the Monkey runs, it generates pseudo-random events and sends them to the system.
In Net beans 8, during debugging (in my case, smali debugging), you cannot change char sequence variables, they are shown as read-only strings. An example of usage is Android text-elements (EditText) whose value is stored in Obj.mText.mText in a char sequence. The following screenshot, shows a Tree view, but you cannot change the field in table view either.
So, I tried do the same with Net beans 6.8 and I found that it let me edit char-sequence variables. After some research I figured out that in order to enable editing of those variables I need to disable the auto formatting. You do this in tools menu -> options and remove the V of Default Char sequence formatter:
https://appsec-labs.com/portal/wp-content/uploads/2016/01/keep-calm-and-start-debugging-81.png10801920Israelhttps://appsec-labs.com/blog/wp-content/uploads/2014/07/AppSec_Logo-300x68.jpgIsrael2016-01-27 15:03:242016-08-01 12:24:57How to edit Char Sequence objects in net beans
Prologue: The following post was written and published by Checkmarx (link) on their website as part of a collaboration between AppSec Labs and Checkmarx. Originally published on May 26th, 2015 by Amit Ashbel.
Android…. It is no longer just a mobile phone.
Nowadays Android applications are running anywhere and everywhere. Home Appliances, watches, TVs, car applications and with the Internet of Things kicking in quickly, Android applications will probably become even more prevalent in our lives.
Android is based on a customized Linux OS version. The main differentiation from the classic PC Linux is that the Android OS was adapted to define every Application on the device as a separate User or entity.
Each Application runs on its own Virtual environment within the OS called a “Dalvik Machine (DVM)”*. Application code written in Java is modified to Java Byte Code and then converted to DEX (Dalvik byte code). The DVM will generate, on the fly, machine specific instructions to the ARM CPU (or other CPU in use). All Android applications are packaged as an APK (Android Application Package). The APK is a type of archived file which contains everything the android device needs in order to execute the application downloaded via the Google Play store or an alternate source.
*Dalvik is being shifted aside (Android L). Newer Android OS versions are using ART (Android Runtime) however the general idea stays the same.
https://appsec-labs.com/portal/wp-content/uploads/2015/06/android_dude.png490490Asaf Feigenbaumhttps://appsec-labs.com/blog/wp-content/uploads/2014/07/AppSec_Logo-300x68.jpgAsaf Feigenbaum2015-06-21 12:08:552015-06-23 13:31:21Android Application Security Sucks! Here’s what to do about it
We all know our smartphones contain a lot of sensitive information about us, from credit card details through WhatsApp correspondence, our location, pictures and more.
Today we see serious development of the telephony field; banks and credit card companies are developing account management telephone applications, chat applications which hold a history of our conversations, and much more important information of ours is managed by the smartphone.
The Android operating system (OS) architecture allows the programmer to broadly manage the information; to create components which are accessible to other applications on the device, to save data in dangerous locations and so information can easily be managed incorrectly. In addition, many programmers who have always developed server-side applications are now faced with the need to develop client-side applications and are not aware of the possible risk – which, in turn, increases the known attacking surface available to the attacker.
When a tester performs a penetration test to an Android application, it is divided into to two main areas:
Client-Side Attacks – include client-side vulnerabilities such as saving sensitive information in a dangerous manner, saving passwords in the code, manipulation of activities, broadcast receivers, etc.
Server-Side Attacks – include applicative server-side vulnerabilities such as XSS, SQLi, Authorization Bypass, Authentication Bypass, etc.
Does your application have a page containing sensitive data such as personal or business information? Credit card numbers? Any financial or legal information? You should be aware that when the user presses the iPhone’s home button, and your application performs backgrounding, iOS takes a snapshot of the current page and stores it insecurely on the device. Why? To create an “animation” when the application shrinks into the background and to expand back to the screen, when the user selects it again. If the last page contained sensitive information, this information could be easily stolen. Violation of the user’s privacy and business information leakage are just two of the security impacts it may cause.
This is how its done:
1. The user launches your app, and goes to a page containing sensitive information.
2. The user receives a call, or decided himself to press the home button, and send your app into the background.
3. iOS takes a snapshot of the last pages, for animation… this is how it looks:
Now, lets take a look at the application folder on the device. We’ll go to: {YOUR_APP_UUID}/Library/Caches/Snapshots/ There we can see the file: UIApplicationAutomaticSnapshotDefault-Portrait@2x.png.
Opening it, will reveal all the data that appeared on the last page visited in our app, before going into background.
What can we do about it?
Well… I’m glad you asked! There are a few ways to deal with this issue. Here,I will explain four of them: Read more →
https://appsec-labs.com/portal/wp-content/uploads/2015/01/screen-shot-2014-09-30-at-8-56-25-pm-e1420666516447.png208327Tal Melamedhttps://appsec-labs.com/blog/wp-content/uploads/2014/07/AppSec_Logo-300x68.jpgTal Melamed2015-01-07 23:35:252015-02-25 19:04:29iOS: "I just snapshotted your credit card... I did it for you!"