DEV Community: Paulo Renato

Ask me Anything About Certificate Pinning

Paulo Renato — Tue, 07 Mar 2023 16:39:00 +0000

I am Paulo Renato, a Developer Advocate for Mobile and API Security and I am making me available to reply to any questions you may have about certificate pinning on mobile apps.

I am the maintainer for the Mobile Certificate Pinning Generator web page, that allows you generate your certificate pinning configurations for Android and iOS.

You can also find me answering security questions on StackOverflow.

FInally, I am also the author of a series of articles on Mobile and API security, where some of the articles are about implementing certificate pinning, bypassing pinning and secure against bypassing it. You can see the series of articles on this Twitter Thread:

🧵 A thread on #Mobile #ApiSecurity

🗓️ Today a #developer on Likedin asked me for help on how to minimize the risk of #ReverseEngineering an #ApiKey on a #MobileApp

✍️ Turns out that I wrote a series of blog posts to educate #developers on this concern

Read all in sequence ⬇️ pic.twitter.com/H9ssL3ooed
— Paulo Renato (@exadra37) July 12, 2022

Approov Serverless Reverse Proxy in the AWS API Gateway

Paulo Renato — Wed, 23 Sep 2020 18:42:51 +0000

In my previous article, Using a Reverse Proxy to Protect Third Party APIs, I left you without a solution to secure the purple API key inside the mobile devices in the graphic above from being extracted by the bad guy wearing the orange hat. As promised I am going to show you in this article how you can implement a solution for it.

Rather than securing the purple API key, wouldn’t it be better not to have it in the first place or at least to make sure that if it is extracted then it can’t be used at scale by malicious actors? Well that's what a Mobile App Attestation solution is for, and we will start this article by explaining what it is. Spoiler alert: it allows you to secure your API without needing to ship any type of secret inside your mobile app or, if you already have a secret in your mobile app, it allows you to ensure that the secret can’t be used to abuse your API.

Next in this article you will learn what an Approov Serverless Reverse Proxy is, followed by when and why you should use it to protect the access to the Third Party APIs used in your mobile app. In the end we will give you the opportunity to download an e-book that goes into the details of implementing it.

Without further delay, let’s dive into the details of using the AWS API Gateway to deploy a Mobile App Attestation service in order to control access to Third Party APIs.

What is a Mobile App Attestation service?

The Mobile App Attestation role is described in this section of another article I wrote, from where I quote the following text:

Before we dive into the role of a Mobile App Attestation service, we first need to understand the difference between what and who is accessing the API server. This is discussed in more detail in this article, where we can read:

The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

The role of a Mobile App Attestation service is to authenticate what is sending the requests, thus only responding to requests coming from genuine mobile app instances and rejecting all other requests from unauthorized sources.

In order to know what is sending the requests to the API server, a Mobile App Attestation service, at run-time, will identify with high confidence that your mobile app is present, has not been tampered/repackaged, is not running in a rooted device, has not been hooked into by an instrumentation framework (Frida, xPosed, Cydia, etc.) and is not the object of a Man in the Middle Attack (MitM). This is achieved by running an SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and device it is running on.

On a successful attestation of the mobile app integrity, a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud know. In the case that attestation fails the JWT token is signed with an incorrect secret. Since the secret used by the Mobile App Attestation service is not known by the mobile app, it is not possible to reverse engineer it at run-time even when the app has been tampered with, is running in a rooted device or communicating over a connection that is the target of a MitM attack.

The mobile app must send the JWT token in the header of every API request. This allows the API server to only serve requests when it can verify that the JWT token was signed with the shared secret and that it has not expired. All other requests will be refused. In other words a valid JWT token tells the API server that what is making the request is the genuine mobile app uploaded to the Google or Apple store, while an invalid or missing JWT token means that what is making the request is not authorized to do so, because it may be a bot, a repackaged app or an attacker making a MitM attack.

A great benefit of using a Mobile App Attestation service is its proactive and positive authentication model, which does not create false positives, and thus does not block legitimate users while it keeps the bad guys at bay.

What is an Approov Serverless Proxy in the AWS API Gateway?

Serverless is a cloud based computing model, where the cloud provider takes all the responsibility to provision and maintain the real servers on which your code will run. This model allows us to dynamically scale up and down the needed resources, like memory, CPUs, disk capacity, network capacity, etc. .

A Reverse Proxy is a type of service, serverless or not, that sits between a client and one or more other services from where the client needs to retrieve or deliver some data to/from, in any kind of content type. So the reverse proxy acts like a mediator between two parts that shouldn’t and/or don’t need to be in direct contact. You can go in more detail about what a Reverse Proxy is in this section of the previous article.

A good example of a cloud provider that has an API Gateway as a service which can be used also as a Reverse Proxy is AWS. The AWS API Gateway allows us to run code through lambda functions without needing to care about the real server running it. Instead we just need to worry about how much resource we want to use, and we simply pay for whatever we use.

Combining the serverless AWS API Gateway with their Reverse Proxy capabilities allows us to use an authorizer and a lambda function to deliver a completely serverless experience for the Approov Token check within a Reverse Proxy.

The Approov Token check is always performed before the API Reverse Proxy forwards any request to the backend or uses the cache to serve the request. This is done by leveraging the serverless capabilities of the AWS API Gateway authorizers, allowing us to use lambda functions to check the Approov Token and establish the IAM (Identity & Access Management) policies to be used by the Reverse Proxy to allow or deny the request to reach the destination service.

So the Approov Serverless is the part where an authorizer and a lambda function is used to check the Approov Token, and the Reverse Proxy is the part where the requests to the backend are made on behalf of the client, the mobile app, that has delegated to the Reverse Proxy the task of providing and securing the secret necessary to communicate with the API backend. The Reverse Proxy doesn’t expose this secret to the public. You will need to provide it through an environment variable, or for added security a secret management solution can be used, like the AWS Systems Manager Parameter Store or the open source Hashicrop Vault project. You can setup and use these solutions from within your AWS account.

When to use the Approov Serverless Reverse Proxy in the AWS API Gateway?

First and foremost if you already have your backend behind an AWS API Gateway, you will be looking to keep any new security controls within it, thus adding the Approov Token check with only one authorizer and lambda function will be both simple and efficient for you.

The next most natural reason you might use this approach is to protect access to third party services that normally need some kind of secret to identify and authorize access to them.

For the use cases inside your own organization when you don’t own the backend you will want to protect the access to with an Approov Token check.

When you want to centralize the protection to access third party services, backends you don’t own and your own backends, this approach would also make sense.

Why is the Approov Serverless Reverse Proxy in the AWS API Gateway a Good Solution?

On top of all the reasons given in this section of my previous article, we can add:

Saving on Operational Resources

As the name says, it’s serverless, therefore your team of developers or DevOps don’t have to spend their time managing servers, configuring and keeping operating systems up to date, worrying about the application environment or the structure. The only configuration you need to do is the one of the AWS API Gateway itself, the authoriser and the lambda function necessary to implement the Approov token checks.

Caching tokens, permissions and API data

Caching is always a good mechanism to avoid repetitive work, since it’s known to always yield the same result, thus improving the response time of an application while saving on resource consumption.The AWS API Gateway already has a cache mechanism that’s easy to use.

Availability

The AWS API Gateway will automatically scale up to handle any number of requests to your API, without throttling them, unless explicitly configured to do so. Thus you will not need to worry about capacity to handle the incoming requests or about downtime because it’s all done automatically for you by AWS.

Further caching can be enabled if required to alleviate pressure on your backend, thus allowing it to be available to serve much more users simultaneously.

If your service is slow or unavailable, it is very unlikely to be due to the API Gateway. It’s much more likely to be due to your backend because on this you will need to configure the auto scaling policies in order for it to be able to handle more load as needed.

Range of Features and Services

When using the AWS API Gateway as the gatekeeper for third party services and backends, you can leverage many features and associated services in AWS to release more time within your team of developers to spend on what matters, business functionality. Some examples of useful AWS services in this context are authentication and access control, cors, rate limiting, monitoring, logging, API version management, etc..

Another great feature is the possibility to add lambda functions to do something with the incoming requests, thus allowing you as the developer to implement your own custom logic for those situations where the native solutions are not enough or don’t fit well with your use cases.

Only pay for what you use

In the AWS API Gateway at the moment of writing this the APIs are only billed for the calls they receive/process and the amount of data transferred out, but not for the incoming data. These charges can be reduced even further when the previously mentioned cache is used, but you need to account for the fact that the cache is charged on a per hour and size basis.

There are currently some exceptions to this, as you can see here. One particularly relevant example is that AWS doesn’t charge for API Gateway throttled requests when the request rate or burst rate exceeds the preconfigured limits. Another exception which should be considered is that requests for methods that require an API Key are not charged when the key is missing or invalid.

Technically the API Gateway bill can have a zero cost for zero use. For new customers the cost can also be zero provided they don’t go over the limits of the free tier in the first 12 months.

How to Implement the Approov Serverless Reverse Proxy in the AWS API Gateway?

Depending on whether you are already familiar or not with the AWS API Gateway, this can be very easy to implement or a little more involved, but it’s certainly nothing that any Developer, SysAdmin or DevOps engineer cannot achieve. In fact, if you already have an API Gateway in use between your mobile app and API backend, implementation could be very simple indeed.

For a very comprehensive and detailed “how to” for creating an Approov Serverless Reverse Proxy in the AWS API Gateway, we have created this e-book to guide you through the process, no matter your level of experience and expertise with AWS.

Conclusion

If the When and the Why for choosing the Approov Serverless Reverse Proxy in the AWS API Gateway has ticked a few boxes in your use cases, then this is the right approach for checking your Approov Token. Otherwise you may want to take a look into another option, Securing Your API server with Approov and Cloudflare, or going with the traditional approach of doing it directly in your API backend, and for that you can visit our Github Integrations Examples.

If you are not sure yet of the approach you want to use to check your Approov Token, then please contact us to discuss your use case.

Using a Reverse Proxy to Protect Third Party APIs

Paulo Renato — Fri, 26 Jun 2020 11:53:57 +0000

In this article you will start by learning what Third Party APIs are, and why you shouldn’t access them directly from within your mobile app. Next you will learn what a Reverse Proxy is, followed by when and why you should use it to protect the access to the Third Party APIs used in your mobile app.

If you are looking to protect your own API backend, not a Third Party one, there are many articles on this site on this topic. If interested you can take a look at the blog posts tagged with API, or if you prefer you can read this series on Mobile API Security to get you started on the right track.

Let’s dive into the details of what, when and why Third Party APIs are better protected when accessed from within a Reverse Proxy.

What are Third Party APIs?

Any time you need to access a service, free or paid, which is provided by an entity outside your organization, you are using a Third Party API. Common examples are payment providers, social networks, weather services, etc.

Sometimes even APIs from inside your own organization can be considered Third Party APIs, if they come from another part of the company and you have no control over them. In such situations, you might well want to place those APIs in the same categories as the Third Party APIs you use from a security perspective.

Why Third Party APIs shouldn’t be accessed from within a Mobile App?

Generally, all Third Party APIs require a secret in the form of an API key, Access Token or some other mechanism for a remote client to identify itself to the backend server with which it wishes to communicate. Herein lies the crux of the problem of accessing it from within your mobile app, because you will need to ship the required secret(s) within the code (the coloured keys in the above graphic).

Now you may say that you have obfuscated the secret within your code, hidden it in the native C code, assembled it dynamically at runtime, or even encrypted it. However, in the end all an attacker needs to do in order to extract this secret is to reverse engineer the binary with static binary analysis, or hook an instrumentation framework like Frida into the function at runtime which will return the secret. Alternatively an attacker can inspect the traffic between the mobile app and the Third Party API it is connecting to by executing a MitM (man-in-the-middle).

With the secret in their possession, the attacker can cause a lot of damage to an organization. The damage can be monetary, reputational and/or regulatory. Financially, the attacker can use the extracted secret to access your cloud provider and your pay-per-call Third Party APIs in your name, thus causing you additional costs. Further, you may be financially hurt by the exfiltration of data which may be sold to your competitors or used to commit fraud. Reputationally you can be impacted when the attacker uses the extracted secret to post on your behalf on social networks, creating a public relations nightmare. Another reputational damage can occur when an attacker uses the Third Party API and violates its terms & conditions (for example where frequent usage of the API triggers rate limits) such that you get blocked from using the service, creating pain for your end users. Last but not least are regulatory troubles caused when the extracted secret is the only mechanism of protecting access to confidential information from your Third Party API. If the attacker can retrieve confidential information such as Personal Identifiable Information (PII), regulatory fines connected to violations of GDPR in Europe, or the new CCPA Data Privacy Law in the California, may be enforced against your business.

So the take home message is that any secret you ship in your code must be considered public from the moment you release your app or push the code to a public repository. By now it should be clear that the best approach is to completely avoid accessing Third Party APIs from within a mobile app; instead you should always delegate this access to a backend you can trust and control, such as a Reverse Proxy.

What is a Reverse Proxy?

A Reverse Proxy is a type of server, serverless or not, that sits between a client and one or more services, from where the client needs to retrieve or deliver some data to, independent of content type. The Reverse Proxy acts as a mediator between two parts that shouldn’t, and/or don’t need to, be in direct contact. Thus the client doesn’t need to know the address of the service it is trying to contact, nor does it need to expose the credentials required to identify/authorize itself to the service. Instead, this is all delegated to the Reverse Proxy which secures and keeps private both the addresses and credentials related to each Third Party API or service.

When to use a Reverse Proxy

Access to Third Party services is normally protected by some kind of secret, such as an API key, which is used by the backend server to confirm the identity of the remote client who requests to use the service. Consequently you want to keep these secrets private and have direct control of their usage, but since you don’t have access to the Third Party API backend, you cannot implement your own mechanisms to defend against API Keys abuse. This is precisely where a Reverse Proxy can be of great help because you will use it to access the Third Party APIs directly, therefore you will have a server that you are in control of and where you can apply as many layers of defense as you want, while keeping the API access secrets out of reach of the public domain, just like in a vault.

Another use case for a Reverse Proxy is when you have a backend within your own organization of which you have no control. In such cases it is often easier to implement a Reverse Proxy rather than fighting with the internal organisation to get security controls implemented on the API.

By now you may be wondering about how you will secure the secret to access the Reverse Proxy in the first place, namely the purple key inside the mobile devices in the graphic above, from being extracted by the bad guy wearing the orange hat? Keep reading - we are coming to that.

Why is a Reverse Proxy a good solution?

Protect Access to Third Party APIs

As was stated earlier, a golden rule that we always recommend is to not access third party APIs directly from your mobile app because this requires you to ship the secrets required to access the APIs inside the mobile app itself. Instead we strongly suggest that this be done by a Reverse Proxy.

So far we have discussed the use case of a single mobile app accessing several Third Party APIs. However the proposition for using a Reverse Proxy becomes even more compelling when you have several mobile apps accessing the same Third Party service because now you have created a single uniform way to deal with securing the access.

Security and Anonymity

A great reason for using a Reverse Proxy is that allows the different mobile apps in your organization to communicate with Third Party services through a single security gateway. In this way, the real Third Party APIs backend, URLs and IP addresses are not exposed, and all security checks can be carried out in one place.

Moreover, any secrets necessary to access any Third Party APIs will be kept out of the public domain, thus out of reach of attackers. It is of course theoretically possible for an attacker to gain access to the server or cloud service running your Reverse Proxy, but this is a significantly more difficult task compared to reverse engineering or performing a MitM attack against a mobile app to extract the secrets directly.

Caching Identification, Authorization and API data

Caching the result of token or key checking is always a good mechanism to avoid repetitive work, since it is known to always yield the same result. Thus caching will save on resource consumption in the original backend, while at the same time increasing response speed of an application to the end user.

Saving on Operational Overhead

If the Reverse Proxy is used across several mobile apps to unify the access to Third Party APIs and/or backends that you are not in control of, it will require fewer developers/DevOps resources to maintain and secure it, thus freeing those resources up to focus on other tasks.

So your developers can spend more time on business logic while your DevOps people can spend more time in maintaining and securing the rest of your infrastructure.

Summary

A recurring theme in this article was the advice not to access Third Party APIs directly from a mobile app. As we have discussed, once your mobile app is released any secret in it becomes public, thus up for grabs by attackers to use on your behalf. If you are not careful you will be the one paying the bill or finding that your free tier resources have been exhausted by someone else.

The Reverse Proxy is the natural choice to manage access to Third Party APIs, and becomes even more suitable when you have several mobile apps consuming the same Third Party APIs.

I mentioned earlier that I would reveal how best to protect the secret which is used to access the Reverse Proxy, but I want to first give you time to digest and absorb all the above information. I also want to leave you a little curious about my next blog post, so please stay tuned and in the next one article we'll introduce an off the shelf Reverse Proxy specifically designed to work without the need for any secrets to be stored in a mobile app.

See you in the next blog post...

How to Protect Against Certificate Pinning Bypassing

Paulo Renato — Thu, 06 Feb 2020 13:40:04 +0000

In my previous article, we saw how to bypass certificate pinning within a device you control and, as promised, we will now see how you can protect yourself against such an attack.

In this article you will learn how to use a mobile app attestation service to protect your API server from accepting requests that come from a mobile app where certificate pinning has been bypassed. This means that even though the attacker has bypassed the certificate pinning, he will not be able to receive successful responses from the API server. Instead, the server will always return 401 responses, thus protecting your valuable data from getting into the wrong hands.

To demonstrate how to protect against certificate pinning bypassing we will use the same Currency Converter Demo mobile app and API server that was used in the previous article, and we will enhance the security of both the mobile app and the API server, by adding a Mobile App Attestation service to them.

Other ways to break Certificate Pinning

Before I go into details of how the Mobile App Attestation works, I would like to remind you that in the previous article I repackaged the mobile app to bypass certificate pinning. However, other tools exist, such as Frida or xPosed, which can be used to bypass certificate pinning during runtime, therefore not requiring repackaging the mobile app.

If you are interested in those alternative methods, you can see how it’s done with xPosed in this video:

The Role of Mobile App Attestation

Before we dive into the role of a Mobile App Attestation service, we first need to understand the difference between what and who is accessing the API server. This is discussed in more detail in this article, where we can read:

The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

The role of a Mobile App Attestation service is to authenticate what is sending the requests, thus only responding to requests coming from genuine mobile app instances and rejecting all other requests from unauthorized sources.

In order to know what is sending the requests to the API server, a Mobile App Attestation service, at run-time, will identify with high confidence that your mobile app is present, has not been tampered/repackaged, is not running in a rooted device, has not been hooked into by an instrumentation framework(Frida, xPosed, Cydia, etc.), and is not the object of a Man in the Middle Attack (MitM). This is achieved by running an SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and device it is running on.

On a successful attestation of the mobile app integrity, a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud know. In the case that attestation fails the JWT token is signed with an incorrect secret. Since the secret used by the Mobile App Attestation service is not known by the mobile app, it is not possible to reverse engineer it at run-time even when the app has been tampered with, is running in a rooted device or communicating over a connection that is the target of a MitM attack.

The mobile app must send the JWT token in the header of every API request. This allows the API server to only serve requests when it can verify that the JWT token was signed with the shared secret and that it has not expired. All other requests will be refused. In other words a valid JWT token tells the API server that what is making the request is the genuine mobile app uploaded to the Google or Apple store, while an invalid or missing JWT token means that what is making the request is not authorized to do so, because it may be a bot, a repackaged app or an attacker making a MitM attack.

A great benefit of using a Mobile App Attestation service is its proactive and positive authentication model, which does not create false positives, and thus does not block legitimate users while it keeps the bad guys at bay.

The Mobile App Attestation service already exists as a SaaS solution at Approov . The solution supports SDKs for several platforms, including iOS, Android, React Native and Cordova. To deploy, a small check in the API server code to verify the JWT token issued by the Approov cloud service is needed. This check is how the API server authenticates what is making the request.

So let’s see how we can introduce Approov into the Currency Converter Demo mobile app in order that the API server knows which requests it should allow and those it should deny.

Implementing Approov

In order to implement Approov into the Currency Converter Demo mobile app and its API server, you need to clone the project from Github:

git clone --branch 0.4.0 https://github.com/approov/currency-converter-demo.git && cd currency-converter-demo

The Approov integration includes adding the Approov SDK into your mobile app, registering the mobile app with the Approov cloud service, and integrating a check for the Approov token in the API server. Optionally you can also tailor the configuration defaults used by the Approov cloud service to better match your needs, for example by changing the security policy that is used to determine when the Approov cloud service can issue a valid Approov token for the mobile app.

During the Approov implementation we will need to use the Approov CLI tool which can be downloaded and installed by following these instructions, and an admin and developer token will be provided so that you can use it.

API Server

Implementing Approov in the API server just requires the addition of a simple JWT token check.

For a smooth transition of your mobile app and API server to Approov we will create a V2 for each endpoint we want to protect, where we will check the Approov Token. We recommend that after you release the mobile app with Approov, the previous versions of it should be deprecated as soon as possible, and the API server endpoints supporting them removed.

For peace of mind you can start to implement the Approov token check without blocking the requests on invalid tokens or in the absence of them, but after you are confident that your are only blocking unauthorized traffic, you can switch to block the invalid requests.

To implement Approov in a Python Flask server you just need to create a decorator, like the approov_token_decorator.py, and afterwards in each endpoint you want to protect with Approov you just add the @approov_token_decorator.check_approov_token annotation.

Mobile App

The Approov integration in your mobile app can be done in three simple steps:

Approov SDK Integration.
Approov SDK Usage.
Mobile App Release.

Approov SDK Integration

First we need to download the Approov SDK from the Approov cloud service with this command:

approov sdk -getLibrary approov\_sdk.aar

Now, from the official documentation for Approov, we can follow these instructions to add the Approov SDK for Android.

Next we will follow the Approov docs to download the Approov initial configuration:

approov sdk -getConfig app/src/main/assets/approov-initial.config

The initial configuration is not built in the SDK in order to provide downstream flexibility. The Approov configuration is also dynamic, because we support Over The Air (OTA) updates, which enables us to configure the Approov SDK without the need to release a new mobile app version. Every app will include an initial Approov configuration which is obtained and updated as necessary via the Approov CLI tool.

Approov SDK Usage

The Approov SDK needs to be initialized when your App starts, and this same instance reused until the app is closed. The Approov tokens must be added to every request made to the API server, and they can be fetched asynchronously or synchronously.

The OTA updates to the Approov SDK Dynamic Configuration will be done via the response for each Approov Token fetch request, and you can see how its done here.

For a complete overview of the code used to implement Approov in the Currency Converter demo app we can take a look at the Approov package. You can use this as inspiration or as a starting point to integrate Approov into your own mobile app.

Mobile App Release

Let's build a release:

./bin/build-release.bash

Now that we have an APK file it is time to install it on our device:

adb install app/build/outputs/apk/release/app-release.apk

If we launch the mobile app now and try to make a conversion we will get an error:

This happens because the APK has not been registered yet with the Approov cloud service. As a result, each time we try to do an attestation an invalid Approov token is issued, thus the API server rejects the request with a 401 response.

Let’s register the APK in the Approov cloud service:

$ approov registration -add app/build/outputs/apk/release/app-release.apk -expireAfter 600s  

registering app Currency Converter Demo  

LokZ+7MJdkHGINCwXAHo9JBwIKXE7UqtikeDbuhDt7I=com.criticalblue.currencyconverterdemo-1.0\[1\]-1212 SDK:Android(2.0.5)  

registration successful, expires 2019-09-13 17:48:21

So if you try to repeat the currency conversion immediately you may see the same error, just because a short time is needed to propagate the changes. You can either wait or proactively relaunch the mobile app and the changes will be updated. If you then retry the currency conversion you will get a successful response:

You may have noticed the -expireAfter flag which ensures that APK registration will only be recognised for 600 seconds after it is first registered. This is very useful when you are in the development phase and you don’t want to manage the de-registration of temporary versions of the APK with the Approov cloud service. Of course, in production you should not use the -expireAfter flag.

As you can see implementing Approov is very easy and it delivers a frictionless experience for your end customers.

Approov Certificate Pinning Protection in Action

Now that we have implemented Approov in the mobile app and API server we are ready to see how Approov protects us against attempts to bypass certificate pinning. For consistency with the previous article, we will take the same approach, that consists to unpack the APK, change the code, repackage it, and reinstall it on our device. Always remember that this is not the only way of bypassing certificate pinning, thus I challenge you to also try Frida or Xposed as a homework assignment.

Unpack and Modify the APK

To unpack the APK we can use this helper script:

$ ./bin/unpack-apk.sh  

… omitted output  

---> APK decode into: .local/apktool/decoded-apk

Now that the APK is decompiled, its possible to inspect what it does and to modify its behavior. The decompiled code is in Smali code, not Java, and therefore requires you to be familiar with Smali to be able to figure out what is going on.

Attackers of Android apps are usually fluent in Smali code and they can snoop around it and eventually find what they need to change in order to disable certificate pinning. But wait, as you may remember in the previous article, certificate pinning was disabled just by editing the network security config file. So why can’t it be done in the same way now? Well, that’s because Approov handles certificate pinning dynamically, and the initial pin is shipped with the Approov initial configuration, thus the network security file is not required for this purpose.

Aproov Dynamic Pinning overview:

Given that targeting the network security config file is not an option for the attacker any more, the next approach they might take is to find the Smali code that handles certificate pinning, remove it, repackage the app, and then launch a MitM attack to intercept the traffic between the mobile and the API server.

The process for finding the Smali code is out of scope for this article, but I can tell you that the attacker would eventually end up removing this line of Smali code:

invoke-virtual {p1, v0}, Ljavax/net/ssl/HttpsURLConnection;->setHostnameVerifier(Ljavax/net/ssl/HostnameVerifier;)V

If you are curious to know what code it relates to in the Java side, then look it up here:

urlConnection.setHostnameVerifier(pinningHostnameVerifier);

Repackage and Reinstall the APK

Now that the Smali code has been modified to remove the part that handles certificate pinning, it's time to repackage the mobile app and reinstall on the device.

We repackage the mobile app with the help of this helper script:

./bin/repackage-apk.sh

And then we install it on our device with:

adb install .local/apktool/decoded-apk/repackaged-and-signed.apk

Approov Protection in Action

Now that he APK have been repackaged and reinstalled on the device we can launch it to try a new currency conversion, and we can see that the API server is refusing to fulfill the request by returning a 401 response to the mobile app:

If we inspect the Logcat in Android Studio we will be able to see an entry that shows us the Approov Token which was sent to the API server:

2019-09-17 12:18:48.196 11446-11512/? I/VOLLEY\_HTTP\_REQUEST: APPROOV TOKEN: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkaWQiOiJWcGJ2YUh1Rnp0eGhzeDQ3Mlc0VmdnPT0iLCJleHAiOjE1Njg3MTk0MjYsImlwIjoiODAuMjI5LjExMy4yMjAifQ.xS-iNbfVlveTiZ\_H8E2ZT2GF8suKvziauUoD79pYpoM

If you now copy and paste the above Approov Token and use the Approov CLI tool to inspect it, you will find that it is an invalid one:

$ approov token -check eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkaWQiOiJWcGJ2YUh1Rnp0eGhzeDQ3Mlc0VmdnPT0iLCJleHAiOjE1Njg3MTk0MjYsImlwIjoiODAuMjI5LjExMy4yMjAifQ.xS-iNbfVlveTiZ\_H8E2ZT2GF8suKvziauUoD79pYpoM 1 ↵  

invalid: {"did":"VpbvaHuFztxhsx472W4Vgg==","exp":1568719426,"ip":"80.229.113.220"}

The API server saw an invalid Approov token in the request, thus it returned a 401 response, instead of returning the 200 response with its respective data. The token is invalid because the APK has been modified, and this is how Approov protects your data from being breached. Put another way, only genuine mobile app instances can communicate with your API endpoints, not repackaged apps, bots, or to someone trying to probe the API server from a tool like Postman.

To illustrate the depth of security of your API server, if you had just repackaged the APK without actually changing anything in it, the Approov token issued by the Approov cloud service would still have been invalid. This is because the repackaged app will have a different DNA signature to the original app you registered with the Approov cloud and would therefore not pass the Approov authentication process. It should also be noted that if you had attached Frida, Xposed or some other instrumentation framework to disable certificate pinning at runtime, this scenario would also result in a failed attestation from the Approov cloud service.

You might consider a couple of other ways to beat Approov. Firstly you could imagine that the attacker could take Approov out of the app, or perhaps write a script to generate correctly formed API requests. However, in both cases the attacker would not be able to provide an Approov token to the API server and so the API requests would be refused. Secondly, you might think that the attacker could spoof the Approov tokens, but unfortunately this is not possible because they are signed JWT tokens with a very short lifetime, and the secret used to sign them is only known by the Approov cloud service and by the API server.

Summary

Protecting against certificate pinning bypass is done by implementing the Mobile App Attestation concept which allows the API server to detect with high confidence if what is making the request is a genuine mobile app instance or not. This approach will block attackers from accessing data they are not meant to have. The data is protected, regardless if the attempt is made via a script, a bot, a tampered mobile app, or by attaching a run-time instrumentation framework, like xPosed or Frida.

The Mobile App Attestation approach used here is a proactive one, since what is making the request is authenticated before any requests to the API server have been made. Also, because the authentication decision is taken outside of the mobile app itself, it cannot be reverse engineered or circumvented without being detected. This contrasts with traditional API server defenses that either parse requests in realtime and try to decide if they can be trusted or not, or they search for patterns or signatures which have previously been found to be bad. Either way, these approaches are prone to false positives and false negatives, thus requiring constant monitoring in order to relax or increase the severity of the policies being used. The Mobile App Attestation concept used by Approov removes both the doubt about the authenticity of the API traffic and the burden of constant monitoring and fine tuning of policies being used.

Implementing Approov in your mobile app and API server is a straightforward process which does not impact your development and deployment processes, illustrated by the words of one of our fintech customers:

“Approov was a natural choice at the end of our research because of the extensive capabilities of the product. It required minimal integration work while providing maximum security and flexibility. The similar solutions we found were too rigid and required too much initial integration work.”

Bypassing Certificate Pinning

Paulo Renato — Wed, 08 Jan 2020 14:34:47 +0000

In a previous article we saw how to protect the https communication channel between a mobile app and an API server with certificate pinning, and as promised at the end of that article we will now see how to bypass certificate pinning.

To demonstrate how to bypass certificate pinning we will use the same Currency Converter Demo mobile app that was used in the previous article.

In this article you will learn how to repackage a mobile app in order to make it trust custom ssl certificates. This will allow us to bypass certificate pinning.

Certificate Pinning Bypass Context

An attacker may want to intercept the communications between your mobile app and your API server in order to collect enough data to automate attacks against it, or just to modify or redirect your data on the fly. In my previous article you learned how to protect the https communication channel between your mobile app and the API server by implementing certificate pinning to keep the prying eyes of attackers at bay. However, luckily for them and unfortunately for us, it is possible to get around certificate pinning.

Bypassing certificate pinning in a mobile app can be achieved with the use of Instrumentation frameworks like Frida or Xposed, or by downloading the original APK and modifying the network security config file to trust in user supplied certificates and to disable certificate pinning. After the modification it is necessary to repackage the app and install it again in the device, after which it is possible to intercept the traffic again with a MitM attack.

Attackers do not only repackaged an app to use in their own devices, they also upload them to the Google Play store. A good example of this is a repackaged app which is the original, and which uses the original API server, but will display ads where generated revenue will go for the attacker, not to the app author. A further more sophisticated example is a repackaged app that will redirect the payments for in app purchases to the bank account of the attacker.

Setup

Clone the Currency Converter Demo

From Github you will need to git clone the Currency Converter Demo app:

git clone --branch 0.3.0 https://github.com/approov/currency-converter-demo.git && cd currency-converter-demo/mobile-app/android

Keystore

You can use your usual keystore or just create a new one with:

$ ./bin/create-keystore.sh  
... some output omitted ...  
---> Adding, if not already present, properties to your ./local.properties file  
---> Edit your ./local.properties file and add the passwords you have used when you first created the keystore.

As mentioned in the previous output, you need to add the required passwords that will be used to sign the release by editing your ./app/local.properties file. Now edit the file and add the password you entered for Enter keystore password: to the ANDROID_KEYSTORE_PASSWORD and ANDROID_PRIVATE_KEY_PASSWORD properties.

Install the APKTOOL

The apktool is one of the most popular tools used to decompile Android APKs, and it will be the one we will be using too. Just follow their official documentation to install it.

Building a Release

Now that the setup is concluded you should be in the folder currency-converter-demo/mobile-app/android, and to build a release you just need to use bash helper script:

./bin/build-release.bash

Before we repackage the mobile app I recommend you to follow these instructions to make sure that pinning is working with the release you have built.

Repackage a Mobile App

In order to repackage a mobile app we need to have its APK, and for that you can use adb to extract it directly from your device or you can use an online service to download it for you (not recommended for security reasons), but because we have access to the source code we will just use the APK from the release we have just built in the previous step.

Once we have our APK we need to unpack it, and for that we will use the apktool from a bash script, like:

./bin/unpack-apk.sh

If you are curious about how this works just take a sneak peak of the bash script.

The result of unpacking the APK will be stored at .local/apktool/decoded-apk, and we will need to edit the file .local/apktool/decoded-apk/res/network_security_config.xml to enable trust in user supplied certificates, so that the mobile will trust the certificate of the proxy that we will use to perform a MitM attack against the repackaged app.

To disable certificate pinning we need to remove all these lines:

<pin-set>  
    <!-- Pin for: currency-converter-demo.pdm.approov.io -->  
    <pin digest="SHA-256">qXHiE7hFX2Kj4ZCtnr8u8yffl8w9CTv6kE0U5j0o1XY=</pin>  

    <!-- Backup Pin for: currency-converter-demo.pdm.approov.io -->  
    <pin digest="SHA-256">47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=</pin>  
</pin-set>  

<!-- TrustKit Android API -->  
<!-- enforce pinning validation -->  
<trustkit-config enforcePinning="true" disableDefaultReportUri="true">  
    <!-- Add a reporting URL for pin validation reports -->  
    <report-uri>https://report.pdm.approov.io/pinning-violation/report</report-uri>  
</trustkit-config>

Adding trust in custom certificates supplied by the user is as easy as adding the following line to the trusted anchors:

<certificates src="user" />

The final network security file for the repackaged app should look like this:

<?xml version="1.0" encoding="utf-8"?>  
<network-security-config>  

    <!-- Official Android N API -->  
    <!--https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html-->  
    <domain-config>  
        <domain includeSubdomains="false" >currency-converter-demo.pdm.approov.io</domain>  
        <trust-anchors>  
            <certificates src="user" />  
            <certificates src="system" />  
        </trust-anchors>  

    </domain-config>  

</network-security-config>

Now we are ready to repackage the mobile app, and we will use a bash script to help us with the task:

./bin/repackage-apk.sh

Note: the script will prompt you for the keystore and private key passwords.

The repackage APK should be now found at:

$ ls -al .local/apktool/decoded-apk/repackaged-and-signed.apk-rw-r--r-- 1 approov approov 1602366 Jul 15 16:03 .local/apktool/decoded-apk/repackaged-and-signed.apk

Certificate Pinning Bypass in Action

Now that we have repackaged the APK, is time to install it in our device:

adb install .local/apktool/decoded-apk/repackaged-and-signed.apk

Before we try to intercept its traffic with a MitM attack, let’s perform a smoke test to be sure it works, by opening it and try to convert the default value:

The repackaged app works as usual, thus it is time to perform a MitM attack to see if we can bypass the certificate pinning that was shipped with the original APK, and for this we will once more use the mitmproxy. To set up and have it running we just need to follow the Setup for the MitM Attack instructions, then we will see that we will be able to continue to do conversions:

While at the same time we intercept the traffic between the API server and the mobile app, without raising any certificate pinning exceptions:

Therefore, despite the fact that we have learned in a previous article how to implement certificate pinning to protect against MitM attacks, we have now learned how to bypass pinning in a device that the attacker controls. Bypassing pinning is also achievable when an attacker is able to trick a user into installing the repackaged mobile app, and this is an issue that the official Google Play store and the App store are still struggling with in 2019, because you can still find repackaged versions of some of the most popular apps there.

Conclusion

Protecting your mobile app and API server from attackers is not an easy task, and is done in incremental steps. It starts with good and secure coding practices as recommended by the OWASP Mobile Security Project, and will end up with In-App and API defense solutions.

In the next article I will walk you through a solution that will secure certificate pinning from being bypassed, and will allow you to update the certificate pins without releasing a new version of your mobile app. This mobile app attestation solution will be both an In-App and API defense tool. It will protect your mobile app from being repackaged, tampered with at runtime or MitM attacked, and at the same time will guarantee that the API only serves requests from your genuine mobile app.

These are bold claims, but once you see how easy it is to implement and how effective it is, you may wish you had discovered it earlier.

See you in my next article...

Securing HTTPS with Certificate Pinning on Android

Paulo Renato — Fri, 20 Dec 2019 19:06:36 +0000

In a previous article we saw how we could steal an API key by performing a man in the middle (MitM) attack to intercept the https traffic between the mobile app and the API server. In this article we will learn how to mitigate this type of attack by using a technique known as certificate pinning.

In order to demonstrate how to use certificate pinning for protecting the https traffic between your mobile app and your API server, we will use the same Currency Converter Demo mobile app that I used in the previous article.

In this article we will learn what certificate pinning is, when to use it, how to implement it in an Android app, and how it can prevent a MitM attack.

What is Certificate Pinning?

Certificate pinning is the mechanism of associating a domain name with an expected SSL/TLS certificate, technically and more accurately known as an X.509 certificate.

Whenever the user clicks on a link, the device needs to establish a connection with the server hosting that domain name, and for this to happen, a TLS handshake takes place in order that both parties can exchange messages, so that they can verify each other, establish the encryption algorithms to use, and finally to set the session keys to be used thereafter. During the TLS handshake, when the device receives the server certificate, it only establishes the connection if it trusts on that specific certificate, hence it is said that the connection is pinned.

What to pin?

The process of performing certificate pinning can be achieved by pinning against any of the certificates presented in the chain of trust for the domain of the API server as shown below. Normally it is preferable to pin against the leaf certificate, that in the below picture is referred to as the end-entity certificate.

Source: Wikipedia — chain of trust: image originally via Gary Stevens of HostingCanada.org

The easiest way to pin is to use the server’s public key or the hash of that public key, The hashed public key is the most flexible and maintainable approach since it allows certificates to be rotated in the server, by signing the new one with the same public key. Thus the mobile app does not have to be updated with a new pin because the hash for the public key of the new certificate will continue to match the pin provided in the network security config file. We will see an example of this later when we talk about how to setup certificate pinning.

Why do we need Certificate Pinning?

While https gives you confidentiality, integrity and authenticity in the communication channel between the mobile app and the API server, certificate pinning will protect this same guarantees from being broken.

To prevent trust based assumptions

Incorrectly issuing leaf certificates to the wrong domain names by Root and Intermediate Certificate Authorities (CAs) would allow an attacker to intercept any https traffic using them, without the end user noticing anything.

This is possible because any mobile device comes pre-installed with the root certificates for all known Root CA's, which are then trusted by all other Intermediate CA's, thus we now have a chain of trust that are used by the devices to validate the certificates presented in the handshakes that take place to establish a secure connection with an API server. This means that if any of the CA’s in the chain get compromised or issue certificates incorrectly, the chain of trust is tainted and broken, just like in the famous cases of DigiNotar, GlobalSign and Comodo.

To protect against use in hostile environments

A good example of a hostile environment is public wifi, where users can be tricked by an attacker into installing a self signed root certificate authority into the trusted store of the device as a requirement for them to have internet for free. This will allow the attacker to perform a MitM attack and intercept, modify or redirect all https traffic, because the device will now accept all intercept traffic which is now signed by the root CA of the attacker - now trusted by the device. From Android 7 onwards, the operating system no longer trusts user supplied certificates unless the app developer explicitly opts-in to trust them in the network security config file. Even with this huge improvement in security, it is still important to pin the leaf certificate to protect against certificates issued by an attacker’s self signed root certificate, when the developer have opt-in to trust in user provided certificates, and to protect against compromised CA’s, that incorrectly have issued certificates to an attacker.

Other hostile situations certificate pinning can protect us from are DNS cache poisoning and DNS spoofing. In simple terms this is where your device asks where it can find a certain domain name but it gets the wrong reply, for example that google.com is at an attacker’s servers and not at Google’s servers, as in this incident. This is not an isolated incident and DNS Hijacking attacks are becoming more frequent and with harmful consequences.

When to use Certificate Pinning?

The OWASP page on certificate pinning has a good answer for this question:

You should pin anytime you want to be relatively certain of the remote host's identity or when operating in a hostile environment. Since one or both are almost always true, you should probably pin all the time.

So if your mobile app is dealing with Personal Identifiable Information (PII) and/or other sensitive data, which is pretty much true in any mobile app, then you should absolutely pin.

Preventing MitM attacks with Certificate Pinning

Now that you know what certificate pinning is and when you should use it, it’s time to learn how to implement it in an Android mobile app. For this we will use the Currency Converter Demo app, and if you remember from the previous article, the mobile app retrieves the currency rates directly from a free API, that is rate limited, and requires an API key to access it. Therefore we note that if we needed to replace the API key we would need to release a new version of the mobile app and expect all users to update it.

A smart and more secure approach is to always delegate any access to third party services to an API server under your control. This approach allows us to keep all secrets secured in a private place, instead of having them shipped with the mobile app and making them vulnerable to extraction by reverse engineering techniques or by a MitM attack.

The Currency Converter Demo app has been upgraded to extract all the currency conversion logic to a dedicated API server which is under our control, and at the same time allows us to have more control over the certificates we will pin against.

How to Implement Certificate Pinning

Now that you are aware of the changes made to the Currency Converter Demo app used in the previous article, it is time to see how certificate pinning was implemented on it, and if you want to take a closer look, just clone the project from Github:

git clone --branch 0.2.0 [https://github.com/approov/currency-converter-demo.git](https://github.com/approov/currency-converter-demo.git) && cd currency-converter-demo

Implementing certificate pinning on Android API level 24 and above

From Android Nougat onwards, implementing certificate pinning for any mobile app that targets API level 24 and above was made easier with the introduction of the network security config file, as detailed in this blog article by Google.

So, all that is needed is to create this file src/main/res/xml/network_security_config.xml:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>

    <!-- Official Android N API -->
    <!--https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html-->
    <domain-config>
        <domain>currency-converter-demo.pdm.approov.io</domain>
        <trust-anchors>
            <!--<certificates src="user" />-->
            <certificates src="system" />
        </trust-anchors>
        <pin-set>
            <!-- Pin for: currency-converter-demo.pdm.approov.io -->
            <pin digest="SHA-256">qXHiE7hFX2Kj4ZCtnr8u8yffl8w9CTv6kE0U5j0o1XY=</pin>

            <!-- Backup Pin for: currency-converter-demo.pdm.approov.io -->
            <pin digest="SHA-256">47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=</pin>
        </pin-set>

        <!-- TrustKit Android API -->
        <!-- enforce pinning validation -->
        <trustkit-config enforcePinning="true" disableDefaultReportUri="true">
            <!-- Add a reporting URL for pin validation reports -->
            <report-uri>https://report.pdm.approov.io/pinning-violation/report</report-uri>
        </trustkit-config>
    </domain-config>

</network-security-config>

In this file we can see a section dedicated to configure TrustKit, but using TrustKit in your mobile app is only necessary if you want to target devices below API level 24, where TrustKit assumes the role of ensuring that the connection is pinned against the correct certificate.

So now we need to include the network security config file in the AndroidManifest.xml by adding this line into the application tag:

<application
...
    android:networkSecurityConfig="@xml/network_security_config"
...
>

If your mobile app is only targeting Android API level 24 or above, then you are done with your certification pinning implementation. Nowyou just need to rebuild your mobile app and try to MitM it, so that you can see how certificate pinning is protecting the secure communication channel between the mobile app and the API server.

Implementing certificate pinning below Android API level 24

Until now the certificate pinning has been agnostic of the http transport layer being used, but to handle certificate pinning below API level 24 we need to get our hands dirty. Specifically we need to code in the chosen http stack, with the risk that we introduce security flaws which will render certificate pinning useless and worst case turn https into an insecure channel.

In order to avoid all the pitfalls, bugs and security risks that we might introduce with our own implementation, it is best to delegate that responsibility to a community trusted package, and here is where the TrustKit package comes into play, ensuring a secure and well maintained certificate pinning implementation for your mobile app.

Adding TrustKit to an Android App

Unfortunately the README for TrustKit does not include instructions in how to use it with Volley, but it turns out that is not that hard.

So the Currency Converter Demo app is using the Google official Volley library with the request queue singleton pattern, which in their words allows for a more efficient handling of all network activity in the mobile app.

In order to add TrustKit into Volley we need to change the VolleyQueueSingleton class in this method:

public RequestQueue getRequestQueue() {
    if (requestQueue == null) {
        // getApplicationContext() is key, it keeps you from leaking the
        // Activity or BroadcastReceiver if someone passes one in.
        requestQueue = Volley.newRequestQueue(ctx.getApplicationContext());
    }
    return requestQueue;
}

To look like this:

public RequestQueue getRequestQueue() {

    if (requestQueue == null) {

        Context context = ctx.getApplicationContext();

        // TRUSTKIT
        TrustKit.initializeWithNetworkSecurityConfiguration(context);

        String serverHostname = null;

        try {
            URL url = new URL(baseUrl);
            serverHostname = url.getHost();
            Log.i(LOG_TAG, "Server Hostname: " + serverHostname);
        } catch (MalformedURLException e) {
            Log.e(LOG_TAG, e.getMessage());
        }

        // TRUSTKIT
        requestQueue = Volley.newRequestQueue(context, new HurlStack(null, TrustKit.getInstance().getSSLSocketFactory(serverHostname)));
    }

    return requestQueue;
}

So the main difference is in how we instantiate Volley through the VolleyQueueSingleton class. We need to go from instantiating it with only the current context to instantiating it with an additional second parameter to define the http stack we want to use. This in turn lets us define which socket implementation to use, namely the TrustKit one. This will allow TrustKit to take control of all network requests in order to perform the certificate pinning validation.

Before we were instatianting Volley from the VolleyQueueSingleton class like this:

requestQueue = Volley.newRequestQueue(ctx.getApplicationContext());

Now with TrustKit we do it like this:

requestQueue = Volley.newRequestQueue(context, new HurlStack(null, TrustKit.getInstance().getSSLSocketFactory(serverHostname)));

Install the app

Before you are able to build and install the mobile app, it’s necessary to first configure it with the correct API key for the new API server which is accepting requests for currency conversions in this endpoint. So if your curiosity was strong and you clicked on the endpoint link, you probably got an empty response. Remember that we need an API key to query this endpoint.

To set the API key for the mobile app, you will need to execute from the root of the Currency Converter Demo:

$ ./stack setup                                                      
'.env.example' -> '.env'
'./mobile-app/android/app/src/main/cpp/api_key.h.example' -> './mobile-app/android/app/src/main/cpp/api_key.h'

As the output suggests, you now you have two new files, but for running the mobile app, we only care about this one ./mobile-app/android/app/src/main/cpp/api_key.h, which contains the API key to be sent in the header of each request to the API server:

#ifndef API_KEY_H
#define API_KEY_H "the-api-key-will-be-here"
#endif

Time to build and install the Currency Converter demo app, and when you are done with it, you should be presented with this screen:

Note for beginners: how to build and install an Android app is out of scope for this article, but you can refer to the official docs to learn how to do it.

A quick smoke test

Just to be sure that the app is working properly, let's do a quick smoke test by tapping on the convert button, after which we should get something like this:

Certificate pinning in action

In order to validate that the certificate pinning implementation is working properly, we will perform a MitM attack against the mobile app.

Setup for the MitM Attack

Let’s start by following the Setup for the MitM Attack instructions from my previous article, and you can return here after the mitmproxy server is running and the mitmproxy setup in the mobile device is completed.

Perform a MitM attack to check that certificate pinning is working

If we install the app in a device pre Android 7, like one using Android 4.3, and we have followed all the steps in the Setup for the MitM Attack instructions, then we will see this:

As we can see in the image, the exception message clearly states that the pin verification has failed, and even tells us the pins it used to perform the verification. Hurray, it’s working! Now, please do not display the exception message in a production app. I am doing it here to make easier to see that pinning is working.

The exception message does not tell us that it was TrustKit that has thrown an exception, but if you look into your mitmproxy server, you should see a report like this being sent with the certificate pinning failure:

Now if we try the MitM attack with a device using Android 7 or above we will see a different error:

Here we have a different message, which instead of mentioning a failure in the pin validation, says that it failed the certificate validation. If you remember I said earlier that from API level 24 onwards, Android does not trust in user supplied certificates any more. Therefore when we are MitM attacking the https connection, the handshake with the server fails when the Android OS is trying to establish the trust chain for the certificate, by validating each one with the system trust store. Since the mitmproxy certificate we provided is stored in the user trust store, it will not even arrive to a point where we are able to validate the pins for the certificate.

Now if you enable user trust anchors in the network security file, rebuild and install the app on your device, then you should see a new error message:

Now we get the pin validation error because once we have enabled Android to trust in user provided certificates and so the trust chain can be established. However, when the certificate pinning validation is performed it fails as expected because even though the user has been tricked by an attacker into installing a custom certificate, the app will not proceed with the connection to the API server, therefore protecting the user from the attacker.

A word of caution here: do not enable trust anchors for user provided certificates, but if there are good reasons why you really need to do it, for example for internal mobile apps used in networks with a firewall or that are behind a proxy, then please do not forget to pin against the firewall or proxy certificate.

Conclusion

In this article you have learned that certificate pinning is the act of associating a domain name with their expected X.509 certificate, and that this is necessary to protect trust based assumptions in the certificate chain. Mistakenly issued or compromised certificates are a threat, and it is also necessary to protect the mobile app against their use in hostile environments like public wifis, or against DNS Hijacking attacks.

You also learned that certificate pinning should be used anytime you deal with Personal Identifiable Information or any other sensitive data, otherwise the communication channel between the mobile app and the API server can be inspected, modified or redirected by an attacker.

Finally you learned how to prevent MitM attacks with the implementation of certificate pinning in an Android app that makes use of a network security config file for modern Android devices, and later by using TrustKit package which supports certificate pinning for both modern and old devices.

I hope that by now you are convinced that certificate pinning is very important to implement in your mobile app in order to strengthen and harden its security.

So, see you in my next article, which will be about bypassing certificate pinning in some specific scenarios. Wait, I hear you cry, it can be bypassed? Well you need to be patient and wait for my next article to understand the limitations and what you can do about it. (Spoiler alert: there is a happy ending!) .

Steal That Api Key With A Man In The Middle Attack

Paulo Renato — Wed, 04 Dec 2019 18:04:42 +0000

As I promised in my previous article, here it is the follow up article about performing a man in the middle (MitM) attack to steal an API key, and to follow this article you will need to become the man sitting in the middle of the actual channel, using mitmproxy to help you with the task of stealing the API key. Now it should be clear why MitM stands for man in the middle!

In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.

So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.

Setup for the MitM Attack

In order to perform the MitM attack you need to have mitmproxy installed, have both the computer and the mobile device on the same wifi network, set up the proxy on the mobile device, have a free API key for the third party service that provides the currency rates, and then build and install the Currency Converter demo app on the mobile device.

Clone the Currency Converter Demo

From Github you need to git clone the Currency Converter Demo app:

git clone --branch 0.1.1 https://github.com/approov/currency-converter-demo.git && cd currency-converter-demo

Mitmproxy Install

To perform the MitM attack you should use the open source tool mitmproxy which is an interactive https proxy that can be used from the command line or from a web interface, although if you are already using other tools, such as the Charles or Fiddler Proxy, feel free to skip the install and setup for the mitmproxy.

If you don’t yet have the mitmproxy tool installed you should follow the official documentation to install it on your platform, but if you have Docker on your system then you can use their official image.

Using Docker

If you decided to use docker and don't want to type long commands, you can use the ./stack bash script in the root of the demo:

$ ./stack install  
4.0.4: Pulling from mitmproxy/mitmproxy  
911c6d0c7995: Pull complete   
6c177ecba9eb: Pull complete   
4e66c1c16ddc: Pull complete   
0a3a1ba37d3c: Pull complete   
Digest: sha256:2964508c2091f0425d46971cfc11741e67f462cbd6ed6773c465a671d060fb6f  
Status: Downloaded newer image for mitmproxy/mitmproxy:4.0.4

Now it’s time for a smoke test to check that mitmproxy is working:

$ ./stack mitmweb --version  
Mitmproxy: 4.0.4  
Python:    3.6.3  
OpenSSL:   OpenSSL 1.0.2o  27 Mar 2018  
Platform:  Linux-4.15.0-50-generic-x86_64-with

All mitmproxy commands in this demo will be prefixed with ./stack, because we will run them within docker containers, but if you have mitmproxy installed in your computer just remove the prefix ./stack when executing each command.

The Wifi Network

In order to be able to perform the MitM attack you need to connect the computer and the mobile device to the same wifi network.

Next you need to know the IP address for the wifi network. In Ubuntu 18.04 you can discover from going to Settings > Wi-Fi > Visible Networks and click on settings for the wifi network you are connected to:

You should take note of the IP address 10.0.3.55 in order to later use it to set up the proxy in the mobile device and to access the mitmproxy web interface.

Starting the mitmproxy

Now that you know the wifi IP address, it’s time to launch the mitmproxy web interface to listen to all requests made into the wifi network, on port 8080, by issuing the following command:

$ ./stack mitmweb --listen-host 10.0.3.35 --web-iface 10.0.3.35                                                               130 ↵  
Web server listening at http://10.0.3.35:8081/  
No web browser found. Please open a browser and point it to http://10.0.3.35:8081/  
Proxy server listening at http://10.0.3.35:8080

Let's do a smoke test to check if we can see the web interface for mitmproxy, by visiting in the browser http://10.0.3.55:8081:

Now that mitmproxy is listening in all traffic that goes through the wifi, on port 8080 (10.0.3.35:8080), it's time to set up our mobile device proxy to send all traffic through it.

The mitmproxy needs to be launched before you setup the mobile device, because when the mitmproxy web interface starts, a custom authority certificate is auto generated, and it will be later used to setup the proxy on the mobile device.

Proxy Setup on the Mobile Device

In android this is usually done by selecting the wifi network, then advanced options, and set the proxy to manual mode, fill the proxy hostname field with the wifi IP, in this case 10.0.3.35, and the proxy port with 8080, the one where mitmproxy is listening. Depending on your Android version it will look something like this:

In order for mitmproxy to be able to intercept all the https traffic we need to add to the mobile device a custom certificate authority. This was auto generated by mitmproxy when we started the proxy, thus is unique to this mitmproxy installation. To do so, please open the browser in the mobile device and go to http://mitm.it where you should see this page:

NOTE: If you see any other screen that means the traffic from your mobile device is not being intercepted, thus you need to review the previous steps and ensure that you followed them correctly.

Time to click on the Android symbol and install the custom authority certificate for mitmproxy by following the on screen instructions. This will require the mobile device to have authentication enabled when unlocking the screen. If you do not have it done already, you will be prompted to set it up.

Install the Mobile App

For this step you first need to get an API key for the third party service that will provide the currency rates used in the mobile app in order to perform the currency conversion. Just visit this page to get your free API key.

However, before you can build the app, you need to copy/paste the free API key into the file app/src/main/cpp/api_key.h. This file does not exist yet in the project, and is not tracked by git, but you can use app/src/main/cpp/api_key.h.example as a template:

// app/src/main/cpp/api_key.h  

#ifndef CURRENCY_CONVERTER_DEMO_API_KEY_H  
#define CURRENCY_CONVERTER_DEMO_API_KEY_H  "place-the-api-key-here"  

#endif</pre>

If the mobile device you are installing this app on is using Android Nougat or later OS version, then you need to uncomment this line in the code.

So this code:

android:theme="@style/AppTheme">  
<!--android:networkSecurityConfig="@xml/network_security_config">-->

Must become:

android:theme="@style/AppTheme"  
android:networkSecurityConfig="@xml/network_security_config">

This will allow the mobile app to trust the mitmproxy certificate we have already installed because, since API level 24, the Android operating system by default doesn't allow the mobile apps to trust in user supplied certificates, unless explicitly told to do so, and that is what we are doing by providing this network security config file.

Now you can build the app and install it via usb. How to do this is out of scope for this article, but you can refer to the official docs. After you have installed the Currency Converter demo app you should be presented with this screen:

This was the final step in the setup for the MitM attack, so now we just need to play with the app and watch the mitmproxy web interface for the intercepted requests.

The MitM Attack in Action

Assuming that you still have the mitmproxy running from the setup process, just open the browser on http://your-wifi-ip-here:8081 and start playing with the android app in order to see the API requests being used to get the currency rates from a third party API being intercepted.

So let's try to convert £1000 into euros and see if we can intercept and steal the API key when the app calls the third party service to get the currency rate for exchanging pounds for euros.

Well I got €1,163.74 for £1000, and if I look into the mitmproxy web interface I can see that the https request to get the currency rate for the exchange was intercepted:

Can you spot where the API key is in the intercepted https request?

Well, I bet that you quickly found the API key as a parameter in the url, but if you haven’t, then just look a bit closer:

Congratulations, you have been able to steal the super secret API key that the developer thought to be very well protected. So just to be clear, this is the same API key you copy/pasted into the file app/src/main/cpp/api_key.h and then hid in the mobile app binary through the use of the advanced JNI/NDK technique. This technique makes it difficult to reverse engineer the binary using static analysis, but as you have seen the API key can easily be extracted with a MitM attack.

An attacker using a MitM attack to steal an API key can then create huge commercial damage to a company. They can abuse the API resources in the name of the API key owner, thus increasing their usage costs, or they can exfiltrate and exploit the data exposed by the API.

What is the difference between https and http requests intercepted by mitmproxy?

If you edit the mobile app code and switch the url to the third party API to use the http protocol, rebuild, install it again, and do some more currency conversions you will be able to compare the difference between http and https requests:

So can you spot what are the differences between intercepted requests over http and https?

If you are struggling to find any substantial differences… look a little closer:

Although they look exactly the same, there is a difference - the green bar preceding the https requests. So if until now you thought that https was enough to protect your API key, you may now see that during a MitM attack it does not offer any protection at all.

This is possible because of the custom certificate authority we installed on the mobile device when we visited http://mitm.it. Tricking a user into installing this type of custom certificate authority on a device is usually done with fake captive portals to get free wifi in public places, because some users will click on anything just to have free wifi !!!

Mitigating MitM Attacks

We can mitigate the MitM attack by using certificate pinning on the connection between the mobile app and the API server, and we have an excellent article on it, Hands On Mobile API Security: Pinning Client Connections. Therefore I will not go into detail here, but I want to let you know that pinning can be an operational challenge, and unfortunately it can be bypassed, but if you read this article you will understand how to detect and prevent it from happening.

So now you may be wondering what more can be done in terms of mobile API security. I would recommend a deep dive into this series of articles to understand several other security techniques that can be employed to protect a mobile API.

Conclusion

While we can use advanced techniques, like JNI/NDK, to hide the API key in the mobile app code, it will not impede someone from performing a MitM attack in order to steal the API key. In fact a MitM attack is easy to the point that it can even be achieved by non developers.

We have highlighted some good resources that will show you other techniques to secure mobile APIs, like certificate pinning, even though it can be challenging to implement and to maintain. We also noted that certificate pinning by itself is not enough since it can be bypassed, thus other techniques need to be employed to guarantee that no one can steal your API key, and, if you have completed the deep dive I recommended, you will know by now that in the context of a mobile API, the API key can be protected from being stolen through a MitM attack. So if you have not already done it, please read the articles I linked to in the section about mitigating MitM attacks.

See you in my next article...

Google and Samsung Fix Android Flaw that Allowed to Hijack your Camera and Audio to Spy on You

Paulo Renato — Wed, 20 Nov 2019 18:08:01 +0000

In this article we can read how researchers from Checkmarx uncovered a serious security flaw in Android that allows for apps to record video and audio without requesting permissions to do so, and then upload them to a command and control server. This flaw is now patched in Google and Samsung phones, but other manufactures may also be affected by it.

TLDR

How is it possible?

Checkmark:

After a detailed analysis of the Google Camera app, our team found that by manipulating specific actions and intents [2], an attacker can control the app to take photos and/or record videos through a rogue application that has no permissions to do so. Additionally, we found that certain attack scenarios enable malicious actors to circumvent various storage permission policies, giving them access to stored videos and photos, as well as GPS metadata embedded in photos, to locate the user by taking a photo or video and parsing the proper EXIF data [3]. This same technique also applied to Samsung’s Camera app.

Why you should be worried?

Checkmark:

In doing so, our researchers determined a way to enable a rogue application to force the camera apps to take photos and record video, even if the phone is locked or the screen is turned off. Our researchers could do the same even when a user was is in the middle of a voice call.

To properly demonstrate how dangerous this could be for Android users, our research team designed and implemented a proof-of-concept app that doesn’t require any special permission beyond the basic storage permission.

ArsTechnica:

The weakness, which is tracked as CVE-2019-2234, also allowed would-be attackers to track the physical location of the device, assuming GPS data was embedded into images or videos.

When was it fixed?

ArsTechnica:

Google closed the eavesdropping hole in its Pixel line of devices with a camera update that became available in July. Checkmarx said Samsung has also fixed the vulnerability, although it wasn't clear when that happened.

Are other manufacturers affected?

ArsTechnica:

Checkmarx said Google has indicated that Android phones from other manufacturers may also be vulnerable. The specific makers and models haven't been disclosed.

Lets' discuss

ArsTechnica:

The weakness, which was discovered by researchers from security firm Checkmarx, represented a potential privacy risk to high-value targets, such as those preyed upon by nation-sponsored spies.

Do you think that only high-value targets will be exploited, or do you also believe that it can be largely used against the normal citizen?

Bypassing GitHub's OAuth flow

Paulo Renato — Thu, 14 Nov 2019 11:10:42 +0000

Cover image credit goes to the Author of the blog, Tedy Katz

In this article from Teddy Katz we can understand how Github OAuth can be bypassed by abusing the HTPP HEAD requests, and how the culprit his in part a feature of the framework being used, that implements a behaviour for making easier the developer life, but that can backfire.

TLDR

Same endpoint for the Authorization page and Authorize button

Interestingly, the endpoint URL for the “Authorize” button is /login/oauth/authorize, which happens to be the same as the URL for the authorization page itself. GitHub figures out which response to send based on the HTTP request method (GET requests return the HTML authorization page, and POST requests grant permissions to the app).
This behavior switch actually happens within application code. The router forwards both GET and POST requests to the same controller:

Abusing the HEAD requests to Bypass Github OAuth flow

What happens if we send an authenticated HEAD request to https://github.com/login/oauth/authorize? We’ve concluded that the router will treat it like a GET request, so it will get sent to the controller. But once it’s there, the controller will realize that it’s not a GET request, and so the request will be handled by the controller as if it was an authenticated POST request. As a result, GitHub will find the OAuth app specified in the request, and grant it access to the authenticated user’s data.

Why is this even possible?

Naturally, people writing web apps usually don’t want to take the time to implement behavior for HEAD requests. Getting a product that works is understandably considered more important than compliance with niche parts of the HTTP spec. But in general, it’s nice if HEAD requests can be processed correctly, provided that app developers don’t have to deal with them manually. So Rails (along with some other web frameworks) implements a clever hack: it tries to route HEAD requests to the same place as it would route GET requests. Then it runs the controller code, and just omits the response body.

Let's Discuss

Do you will start looking into how HTTP HEAD requests are handled by your framework of choice?

How to Extract an API Key from a Mobile App by Static Binary Analysis

Paulo Renato — Mon, 04 Nov 2019 13:15:08 +0000

An API key is probably the most common method used by developers to identify what is making the request to an API server, but most developers are not aware how trivial it is for a hacker or even a script kiddie to steal and reuse an API key in order to gain unauthorized access to their APIs.

In the previous article we saw why your mobile app needs an API key, and now we will see how to grab that API key from your mobile app by reverse engineering the binary in an effective and quick way with an open source tool. Once we see how easy it can be done, we will realize that it is even achievable by non-developers.

Reverse Engineer the Mobile App Binary

While reverse engineering a mobile binary may seem a very technical task, only achieved by hackers, specialists or skilled developers, it turns out to be easier than one may think. This is possible because the open source world is full of excellent tooling to help security researchers to perform their jobs, but guess what, once they are open source tools, they are accessible to everyone willing to use them, including developers, security engineers, hackers and script kiddies. Scripts kiddies are of course skilled enough to understand how to use these tools, without the need to have any background in IT, just like they are smart enough to learn and master the use of every day software, such as the Microsoft suite of programs. So if script kiddies can do it, we developers must be able to do so too, and learning to think like an attacker must become a regular exercise so we should therefore hack ourselves by trying to reverse engineer our mobile app just as they do.

The range of open source tools available for reverse engineering is huge, and we really can't scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.

Mobile App - Android Hide Secrets

During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.

The first approach a developer may take to provide an API key to the mobile app is to store it in the source code of the mobile app, and we will exemplify this approach with the API key stored in the SOURCE_CODE_API_KEY variable. This approach is easy to reverse engineer and has the disadvantage of being present in the code being tracked by git.

Another approach is to store the key in the Android manifest file, but this one is also easy to reverse engineer and will be tracked by git. A better approach is to get the API key from the gradle file and then we retrieve it from the environment, this way solving the API key being tracked in git, but not the problem of being easy to reverse engineer it.

It's time to look for a more advanced technique to hide the API key in a way that will be very hard to reverse engineer from the APK, and for this we will make use of native C++ code to store the API key, by leveraging the JNI interface which uses NDK under the hood.

MobSF demo

Let’s clone the Android Hide Secrets research project from Github, compile the APK for Android and upload it into the MobSF environment. I will not go into details how to compile the APK for Android, but I can make your life easier and let you grab it already compiled from the Github release page.

I will now show you a quick demo on how you can reverse engineer an APK with MobSF in order to extract the API Key. We will use the MobSF docker image, but you are free to install it in your computer if you wish, just follow their instructions to do it so.

To run the docker image just copy the docker command from the following bash script:

Depending on your system you may need to prefix the docker command with sudo.

When you execute the docker command, if the MobSF docker image doesn't exist yet in your system it will be downloaded and then immediately executed:

Now in your browser got to http://localhost:8000 and upload the APK into it:

Now that you have uploaded the APK, MobSF will start analyzing it. This can take several minutes, so please be patient while you stare at this screen:

When the analysis completes we will be presented with a nice dashboard summarizing the result:

Now we have lots of information to look through, but since we are only interested in the API key we may want to start searching for it in the Android Manifest xml file. We can view it by clicking in the dark blue button in the section “View Code” at the bottom right of the above screenshot, and we will land on this page:

As we can see from the Android manifest file the values for MANIFEST_API_KEY and GRADLE_API_KEY_PLACEHOLDER are readily available, but not the ones for the GRADLE_API_KEY and GRADLE_ENV_API_KEY, though we can see in the Android manifest that they are retrieved as strings, thus we can also easily find them in the strings section of the MobSF report:

The Android manifest xml file is one of the places where developers like to drop their API keys, but you might be interested to take a look into the source code itself by clicking on Security Analysis > Code Analysis on the left menu:

Now we land in a section of the page with links to files with the source code decompiled, and there we should look for this section:

If we click in the link for the file, we will see the source code for it:

As you can see the above code is obfuscated, and if you compare it with the code in Github you will notice that the static variable SOURCE_CODE_API_KEY is not present in the source code of the mobile app APK, but you can see the value for it in the screenshot on the line outlined with an orange background. While is not immediately obvious that this value is for the SOURCE_CODE_API_KEY variable, it will not take to much time to work it out after reading the code.

By now the only API key we have not been able to find is the JNI_API_KEY from the C++ native code, and that is not so easy to do because the C++ code is compiled into a .so file that is in HEX format and doesn’t contain any reference to the JNI_API_KEY, thus making it hard to link the strings with what they belong to.

Using the strings command we can see that the API key value is present, but we cannot associate it with the JNI_API_KEY, thus anyone inspecting the .so file will have to do some guesswork in any strings they find in the file in order to find out which one is the JNI_API_KEY.

After we unzip the downloaded code we can use the strings command:

We are not able to find any occurrences for the JNI_API_KEY, but we are able to find the value for it, although that is because we are the developers of the mobile app and we know the value we assigned to it. Anyone else would have a hard time to make sense from analyzing this file with a HEX editor or with the strings output. Strings with high entropy are likely to be secrets, so one idea is to look specifically for them.

Strings output example:

Did you spot the raw value for the JNI_API_KEY in the above output from the strings method?

As you can see it is not associated with anything useful to give it meaning, but don’t underestimate people who try to reverse engineer your mobile app, because If they cannot reverse engineer the APK statically, they will do it at run-time with introspection frameworks. In this particular case a MITM attack would suffix to extract the API key in the request sent from the mobile app to the API server, thus putting script kiddies back into the game.

Summary

Using MobSF to reverse engineer an APK for a mobile app allows us to quickly extract an API key and also gives us a huge amount of information we can use to perform further analysis that may reveal more attack vectors into the mobile app and API server. It is not uncommon to also find secrets for accessing third part services among this info or in the decompiled source code that is available to download in smali and java formats.

Now you may be questioning yourself as to how you would protect the API key, and for that I recommend starting by reading this series of articles about Mobile Api Security Techniques.

The lesson here is that shipping your API key or any other secret in the mobile app code is like locking the door of your home but leaving the key under the mat!

Stay tuned for my next article in how to perform a MITM attack against a mobile app, where I will demonstrate how it can be done in a device we control, or when we have been able to trick the user into installing some software in order to get free wifi in a public place.

See you soon...

This article was first published here

Let's Discuss

I would love to ear from you in the comments section.

Feel free to:

give your point of view.
discuss the techniques used here.
suggest other techniques.
ask me anything regarding the article.

Discussions help all of us to improve our knowledge ;)

Hackers are using a bug in PHP7 to remotely hijack web servers

Paulo Renato — Mon, 28 Oct 2019 12:20:36 +0000

In this article by GBHackers, and on this other one by the TheNextWeb, we can learn that Emil Lerner have disclosed the vulnerability in the PHP bug tracker, and it have been classified has the CVE-2019-11043.

In a nutshell this vulnerability allows an attacker to take control of any server running PHP7 with Nginx and the PHP-FPM extension, just by adding to the url of the website ?a='payload-here, and you can see the proof of concept for a more detailed explanation on how this remote code execution vulnerability is exploitable.

TLDR

The vulnerability

GBHackers

The vulnerability resides in env_path_info in the file fpm_main.c of the FPM component. The FPM is the php-fpm module used for performance enhancement.

The manipulation of the file leads to memory corruption, chaining with other vulnerabilities allows attackers to remotely execute arbitrary code on web servers with vulnerable configurations.

How can be exploited

TheNextWeb:

With this vulnerability, which has the CVE-ID of 2019-11043, an attacker could force a remote web server to execute their own arbitrary code simply by accessing a crafted URL. The attacker only needs to add “?a=” to the website address, followed by their payload.

Who is affected

TheNextWeb:

Fortunately, the vulnerability only impacts servers using the NGINX web server with the PHP-FPM extension. PHP-FPM is a souped-up version of FastCGI, with a few extra features designed for high-traffic websites.

Mitigation

GBHackers:

Following are the mitigations from Nextcloud

If you are not using NGINX then this vulnerability will not affect you.

Users are recommended to update with the latest versions 7.1.33,7.2.24 & 7.3.11.

Recommended removal of $request_uri

TheNextWeb:

Site owners who are unable to update their PHP install can mitigate the problem by setting a rule within the standard PHP mod_security firewall. Instructions on how to do this can be found on the website of appsec startup Wallarm.

DISCUSSION

Are you gonna take this seriously, and take action or you will just think that only happen to others?

Credits

Cover image credit goes for GBHackers.

Why Does Your Mobile App Need An Api Key?

Paulo Renato — Tue, 22 Oct 2019 10:25:20 +0000

Mobile apps are becoming increasingly important in the strategy of any company. As a result, companies need to release new application versions at a fast pace, and this puts developers under pressure with tight deadlines to complete and release new features very quickly.

Some developers may take shortcuts to achieve this delivery speed while being aware of the trade offs involved, but other less experienced developers will just fall into the trap of starting to code without doing their research first, regarding what are the best practices to develop and secure a mobile application and the API server that it communicates with.

To be able to understand why a mobile app needs an API key to identify itself to the API server, we need to be able to differentiate between WHO and WHAT is making the request to the API server and to understand what the difference is between public and private APIs.

DO YOU KNOW THE DIFFERENCE BETWEEN WHO AND WHAT IS COMMUNICATING WITH YOUR API SERVER?

To better understand the differences between the who and the what are accessing your mobile app, let’s use this picture:

The Intended Communication Channel represents your mobile being used as you expected, by a legit user without any malicious intentions, using an untampered version of your mobile app, and communicating directly with your API server without being man in the middle attacked.

The actual channel may represent several different scenarios, like a legit user with malicious intentions that may be using a repackaged version of your mobile app, a hacker using the genuine version of you mobile app while man in the middle attacking it to understand how the communication between the mobile app and the API server is being done in order to be able to automate attacks against your API. Many other scenarios are possible, but we will not enumerate each one here.

I hope that by now you may already have a clue why the who and the what are not the same, but if not it will become clear in a moment.

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

OAUTH

Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.

OpenID Connect

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

While user authentication may let your API server know who is using the API, it cannot guarantee that the requests have originated from what you expect, your mobile app.

Now we need a way to identify what is calling your API server, and here things become more tricky than most developers may think. The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

For your surprise you may end up discovering that It can be one of your legit users using a repackaged version of your mobile app or an automated script trying to gamify and take advantage of your service.

Well, to identify the what, developers tend to resort to an API key that usually they hard-code in the code of their mobile app. Some developers go the extra mile and compute the key at run-time in the mobile app, thus it becomes a runtime secret as opposed to the former approach when a static secret is embedded in the code.

WHAT IS THE DIFFERENCE BETWEEN PUBLIC AND PRIVATE APIS ?

Public APIs are advertised by their owners as a way to promote access to their services, and they normally include documentation in how to integrate them into your applications, and sometimes they even provide SDKs to make that easier.

Depending on the business model, some APIs may be totally open, thus not using any form of authentication, some will require a secret like an API key in order to be accessed, while others will be based on a paid subscription model that also requires a secret to access it and even may employ more advanced API security techniques in order to lock it down as much as possible from API abuse.

Now just because the documentation for your API is not public or doesn’t even exist, it is still discoverable by anyone having access to the applications that query your API.

Interested parties just need to set up a proxy between your application and the API to watch for all requests being made and their responses in order to build a profile of your API and understand how it works.

Sometimes this is made even easier when the APIs are self discoverable ones, like when their response contains links to extended and related resources. This is usually seen in APIs implementing hypermedia links with the HATEOAS standard where HAL is one of its implementations that allow for dynamically and programmatically transversing the entire API by following such links.

API response with HATEOAS example:

{
    "person": {
        "id": 1,
        "firstName": "test",
        "secondName": "one",
        "dateOfBirth": "01/01/0001 01:10",
        "profession": "im a test",
        "salary": 0
    },
    "_links": {
        "people": {
            "href": "http://localhost:8090/people"
        },
        "memberships": {
            "href": "http://localhost:8090/people/1/memberships"
        },
        "self": {
            "href": "http://localhost:8090/people/1"
        }
    }
}

With all this information, it is then easy to build scripts to automate calls to the API in order to extract data or to abuse it in any way the attacker finds possible and profitable to do.

You might think your API is really private because it is just used by microservices for internal communication. Well even here APIs are not private because you can discover what subdomains exist for a domain by using the Google Transparency Report web interface or by scripting it in Python, NodeJS or by using the Fierce Domain Scanner and then crawling the domain and subdomain to find APIs on it. Sometimes the robots.txt file is a good indicator to find them, because normally we want to tell the good bots that they shouldn’t crawl certain parts of our domain, like the API, but the bad bots will not respect this and it will be the first place where they will look to see what valuable stuff is there.

So an API can be only private when both the API and client consuming it are in the same internal network and both servers are not accessible in any way from the outside world, because even if only the API client is exposed to the outside world, the API is already in danger of being indirectly abused via the client.

WHEN SHOULD I USE AN API KEY IN A MOBILE APP?

I hope that by now that you understand the difference between who and what is accessing your API and the difference between a public and a supposed private API, thus being aware that an API server needs a way to know what it is serving the requests to, even before it is able to know who is making those requests.

It should now be clear that every time you build a mobile app that communicates with an API server, a secret must be used to identify it, and this secret is usually named by developers as an API key.

The API key must be present in every request made to the API server and the best practices recommend to use API keys in the header of the request, not as part of the url or request body.

Bad:

// some code using the api-key in the url:
https://example.com?api-key=some-secret-key

Links are easy to share and may end-up in the web in places like Stackoverflow when you are copy/pasting code to exemplify the API call being made.

Also, links tend to end-up in the logs with the full url, thus your API key will be hanging around in the logs as plain text and they can be easily leaked unintentionally when copy/pasting logs to some public website to get help solving an issue.

So having the API key in the url is like distributing keys for the front door of your home to anyone or losing those keys with a tag attached which contains the address of your home… yes I have seen it!

Also bad:

{
   "Api-key": "some-secret-key",
   "Data": {
       "key": "other data from your application here"
   }
}

Post requests normally contain more data then just the API key, thus when sharing them in the web as an example to query the API or when looking for help, it is easy to forget to replace the real API key with a dummy one.

Better:

// some code using the api-key in the request header
X-api-key: some-api-key

While this is better, headers can still be leaked in logs or when the request examples are saved into third party tools like Postman or API specs.

From all the approaches though, this one has a lower risk of being leaked, thus it should be the preferred one to be used in your mobile app.

IS IT POSSIBLE TO SECURE THE API KEY IN A MOBILE APP?

This is a tricky one and the reply is NO and YES…

Well, it is NO because any static secret stored in the source code of a mobile app can be reverse engineered by using tools that decompile the binary of the mobile app, leaving it exposed to human eyes and tools like grep, but you can even try to use the strings tool to perform a lookup into a binary without the need to decompile it.

Let’s imagine that you are an advanced developer and went the extra mile to protect the API key and calculate it dynamically at run-time. Your effort is appreciated and will put off most of the script kiddies, but will not take away the hackers, that will use introspection frameworks like xPosed and Frida in conjunction with the already decompiled code to understand how and where the API key is generated at run-time in order to intercept and extract it. A better way exists though, using a proxy between the device that the hacker controls and the API server is a fast and easy way to grab an API key generated at run-time.

YES can be achieved by using a Mobile App Attestation solution to enable the API server to know what is sending the requests, thus enabling it to respond only to requests from a genuine mobile app.

The role of a Mobile App Attestation service is to guarantee at run-time that your mobile app was not tampered with or is not running in a rooted device. It consists of an SDK integrated in a your mobile app that runs in the background, without impacting the user experience, and communicates with a service running in the cloud to attest the integrity of the mobile app and device it is running on.

On successful attestation of the mobile app integrity, a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.

The mobile app must send the JWT token in the headers of the request for very API call it makes. This allows the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.

Anyone trying to verify at run-time if a JWT token issued by the Mobile App Attestation is a valid or invalid one will not succeed, because the only difference between them is the secret used to sign it, and this secret is only known at anytime by the Mobile App Attestation service and the API server. This means that even the mobile app is not in possession of the secret, thus it is not aware if it is sending a valid or invalid JWT token to the API server.

SUMMARY

Some developers may think that because they have not published their API, it is private and no one will be able to find it or that authenticating the user will be good while many develop mobile apps without any API protection at all. This means that some mobile apps are being released with a complete disregard to the most elementary of all security measures for a mobile app, the use of an identifier for when it communicates with the API server, normally called the API key.

The lesson I want to convey here is that releasing a mobile app without a way of identifying itself to the API server is like leaving your car with the doors closed but not locked, and the keys in the ignition.

On the other hand, releasing apps with API keys is like locking the door of your home but leaving the keys under the mat. Now to understand why I say that, stay tuned for my next article about extracting an API key from a mobile app with static binary analysis.

Do you have anything to say, ask, recommend? Please leave your comment below, your feedback is appreciated and will help me to improve my future blog posts.

See you soon…

This article was first published here