How would someone go about preventing MITM type attacks against API secrets/ API keys?
How does facebook/ instagram protect their users against MITM type hacks?
Do they even protect the users? Or they assume that any possible attacks should be shouldered by users?
Some Context on my Answer
I assume that your question is in the context of mobile apps, thus my answer will show how to protect against a MitM attack for APIs serving mobile apps and how it can be bypassed.
Your Facebook/Instagram Related Questions
How does facebook/ instagram protect their users against MITM type hacks?
Do they even protect the users? Or they assume that any possible attacks should be shouldered by users?
This questions are best answered by an insider at Facebook/Instagram or from a security researcher that have done extensive work on their mobile apps and APIs.
Sorry for not being able to elucidate you here.
Preventing MitM Attacks
How would someone go about preventing MITM type attacks against API secrets/ API keys?
This one I am able to help you with and the quick reply its by using certificate pinning against the certificate public key, and we will go in more detail below.
In a first instance you will want to secure the HTTPS communication channel by configuring the mobile app to only establish a connection with the API, during the TLS handshake, if it presents the certificate issued for its domain and that is known and trusted by the mobile app, ignoring any other that may still be valid as per validation against the certificate trust store of the device. I go into more detail about it and how to implement it on the article I wrote Securing HTTPS with 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 to pin?
From the same article I will quote:
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.
Implementing Static Certificate Pinning
The easiest and quick way you can go about implementing static certificate pinning in a mobile app is by using the Mobile Certificate Pinning Generator that accepts a list of domains you want to pin against and generates for you the correct certificate pinning configurations to use on Android and iOS.
Give it a list of domains to pin:
And the tool generates for you the Android configuration:
And the iOS configuration too:
The tool even as instructions how to go about adding the configurations to your mobile app, that you can find below the certificate pinning configuration box. They also provide an hands on example Pin Test App for Android and for iOS that are a step by step tutorial.
Bypass Certificate Pinning
It's important that any developer that decides to implement certificate pinning in their mobile apps also understands how it can be bypassed in order to learn the threat model and evaluate if further protections are needed to prevent certificate pinning bypass.
I wrote two articles on how to bypass certificate pinning on Android where you can learn in one of them how to do it by extracting, modifying and repackaging the APK, while in the other article you learn how to use the Frida instrumentation framework to hook at runtime into the mobile app in order to bypass certificate pinning:
Bypassing Certificate Pinning on Android via APK
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.
How to Bypass Certificate Pinning with Frida on an Android App:
Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.
Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.
Summary
Despite being possible to bypass certificate pinning I still strongly recommend you to implement it in your mobile app, because it reduces a lot the attack surface of your mobile app.
Being aware of how certificate pinning can be bypassed gives you the insights to decide if further protections are needed to be in place. Dynamic certificate pinning and Runtime Application Self-Protection(RASP) may be the next steps to take in your security ladder.
Related
Scenario :
I have pinned public key pin SHAs of 3 certificates : Root CA , Intermediate CA and Leaf CA in my android application.
What I have understood ( Please correct me if I'm wrong anyway here ) :
Public key pinning is used so that we can check if the public key of the cert that our server is issuing is changed or not. source
A certificate is valid if its public key SHA is the one which we have "pinned" in our application. To check the public key , first it will decrypt the signature using the public key and makes sure that the same public key is in the data of that signature also.
When the Leaf cert has expired but is corresponding to the valid "pinned" public key SHA, the chain of certificates is checked to see if they are valid and if one of them is valid , the certificate is accepted and the connection is established.
When the Leaf cert I got is having an invalid public key but is not expired , then that means I got a wrong certificate from someone which may be an attacker.
Question :
Does public key pinning in any way help in security , if an attacker compromises a client and installs his own trusted CA and then does an MITM on the client to intercept all communication by presenting his own forged certificate signed by the CA he has installed on the client device.
How does direct certificate pinning VS public key pinning make a difference here in any way ?
What is the implication of using a self signed certificate in the above questions.
Please help me understand this with as much detail as possible...
When the Leaf cert has expired but is corresponding to the valid "pinned" public key SHA, the chain of certificates is checked to see if they are valid and if one of them is valid , the certificate is accepted and the connection is established.
No. An expired certificate is not accepted. Pinning does not override that basic principal of TLS but enhances it to reduce the number of certificates accepted.
Does public key pinning in any way help in security , if an attacker compromises a client and installs his own trusted CA and then does an MITM on the client to intercept all communication by presenting his own forged certificate signed by the CA he has installed on the client device.
For browsers, manually installed trusted CAs are exempt from pinning requirements. To me this is a fundamental flaw in pinning. Though to be honest once you have access to install root certs on a machine it’s pretty much game over. Anyway, this exception is necessary to allow Virus scanners, Corporate proxies and other intercepting proxies to work - otherwise any pinned site could not be accessed when behind one of these proxies though it does weaken HPKP (HTTP Public Key Pining) in my mind.
For apps (your use case) pinning can be useful to prevent MITM attacks.
How does direct certificate pinning VS public key pinning make a difference here in any way ?
Don’t understand? When you pin a direct certificate you basically pin the public key of that certificate (well actually the SHA of the private key that cert is linked too).
This means you can reissue the certificate from same private key (bad practice in IMHO) and not have to update pins.
You can also pin from the intermediate or even root public key. This means you can get your CA to reissue a cert and again not have to update the pin. That of course ties you into that CA but at least doesn’t allow some random CA to issue a cert for your site.
What is the implication of using a self-signed certificate in the above questions.
For browsers, pinning basically can’t be used with a self-signed cert. because either it’s not recognised by browser (so pining won’t work) or its is by trusting by manually installing the issuer - at which point pinning is ignored as per point above.
For apps (again your use case), I understand self-signed certificates can be pinned. Though it depends on which HTTP library you use and how that can be configured.
One of the downsides of pinning the certificate itself (which might be the only way to do it, if it's a single leak self-signed certificate), is that reissuing the certificate will invalidate the old pins (unless you reuse the same private key but this may not be possible if the re-issue reason is due to key compromise). So if you app makes an HTTP call home to check if there is a new version or such like, then that call might fail if certificate is re-issued and new version of the app has not been downloaded yet.
Nearly browsers have deprecated HPKP as it was massively high risk compared to the benefits and there were numerous cases of breakages due to pinning. See Wikipedia: https://en.m.wikipedia.org/wiki/HTTP_Public_Key_Pinning. Monitoring for mis-issued certificates through Certificate Transparency is seen as a safer option.
Pinning still seems somewhat popular in mobile app space because you have greater control over an app and can re-release a new version in case of issues. But it is still complicated and risky.
My Answer Context
Scenario :
I have pinned public key pin SHAs of 3 certificates : Root CA , Intermediate CA and Leaf CA in my android application.
My answer will be in the context of pinning in a mobile app. anyway the new browsers don't support pinning any-more.
Pinning and Security
Does public key pinning in any way help in security
It helps a lot, because your mobile app only communicates with a server that presents the certificate with a matching pin. For example, if you do public key pinning and you rotate the certificates in your backend while signing it with a different private/public key pair then your mobile app will refuse to connect to your own server until you release a new version of the mobile app with the new pins.
MitM attack and Pinning
if an attacker compromises a client and installs his own trusted CA and then does an MITM on the client to intercept all communication by presenting his own forged certificate signed by the CA he has installed on the client device.
When you are pinning the connection the attacker will not succeed, because this is for what pinning was designed for, to protect against manipulation of the certificates trust store on the device in order to carry on a MitM attack. From Android API 24 user provided certificates are not trusted by default, unless the developer opts-in to trust on them via the network security config file:
<base-config cleartextTrafficPermitted="false">
<trust-anchors>
<!-- THE DEFAULT BEHAVIOUR -->
<certificates src="system" />
<!-- DEVELOPER ENABLES TRUST IN USER PROVIDED CERTIFICATES -->
<certificates src="user" />
</trust-anchors>
</base-config>
You can read the article I wrote to see pinning in action and not allowing for a MitM attack to succeed:
Securing HTTPS with 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.
In the article I go into detail how to implement pinning, but nowadays I recommend instead the use of the Mobile Certificate Pinning Generator online tool, that will generate the correct network security config file to add to your Android app. For more details on how to use this tool I recommend you to read the section Preventing MitM Attacks in this answer I gave to another question where you will learn how to implement static certificate pinning and how to bypass it:
The easiest and quick way you can go about implementing static certificate pinning in a mobile app is by using the [Mobile Certificate Pinning Generator](Mobile Certificate Pinning Generator) that accepts a list of domains you want to pin against and generates for you the correct certificate pinning configurations to use on Android and iOS.
Give it a list of domains to pin:
And the tool generates for you the Android configuration:
The tool even as instructions how to go about adding the configurations to your mobile app, that you can find below the certificate pinning configuration box. They also provide an hands on example Pin Test App for Android and for iOS that are a step by step tutorial.
This approach will not require a release of a new mobile app each time the certificate is renewed with the same private/public key pair.
Certificate Pinning vs Public Key Pinning
How does direct certificate pinning VS public key pinning make a difference here in any way ?
When using certificate pinning a new mobile app needs to be released and users forced to update each time the server certificate is rotated, while with public key pinning no need for this unless the private/public key pair used to sign the certificate changes. For example, if your server uses LetsEncrypt for the certificates you don't need to release a new mobile app version each time they are renewed.
Self Signed Certificates
What is the implication of using a self signed certificate in the above questions.
You will need to opt-in via the network security config file for the Android OS to trust in user provided certificates and instruct the user to add it to his mobile device. This will make an attacker life easier if pinning is not being used. I would recommend you to stay away of using self signed certificates.
I have a problem with insecure SSL certificates. My proyect consist on two parts:
ESP32 iot device with a https server
VUE2 + Vuetify PWA web app deployed to firebase hosting.
Imagine that one client buy my iot device, and connect it to the power. The device will boot in AP mode, creating a WiFi AP net.
The client login to the web app and wants to add his new device. So, for that, the iot device needs clients wifi credentials.
The web app asks to the client his ssid and password, and when the client click on 'Configure device', the web app send a https POST request to the esp32 server, and here is the problem...
Because the SSL certificate used in esp32 server is not validated by an authority, the web app can´t make the POST request...
How can I get a valid server SSL certificate for a lot of iot devices? I don´t know how to manage this situation...
Thanks everyone!!
It is possible to get a valid SSL certificate for the device, but I wouldn't recommend it. Here is how you could do it if you wanted to:
Ensure that when your device is in AP mode, it's always available at the exact same IP address. For example, ensure that the ESP32 is listening at 192.168.1.1.
Register a domain like example.com. Add an A record to your DNS server for iot.example.com, with the value 192.168.1.1.
Obtain a valid SSL certificate for iot.example.com from any trusted authority. Put that certificate and associated key on your device.
Now, when your user connects to your soft AP, they can browse to https://iot.example.com and actually see a valid certificate.
However, I would really recommend not doing this. You'll have three major issues to contend with:
The key for your SSL certificate will be on your device's flash. If anyone extracts it, they can masquerade as iot.example.com. You can mitigate this by using flash encryption, but it's still not great.
The maximum validity period for an SSL certificate is around two years. So your provisioning flow will break after a couple years.
If the CA that issued your certificate hears that the private key is floating around and could potentially be compromised, they will probably revoke your certificate.
Instead, what you should do is secure your soft AP with WPA2, and a password that you can give to users. This will ensure that the connection is encrypted, and you can serve your provisioning form over HTTP instead of HTTPS.
An even better approach rather than trying to implement this yourself, is to use the ESP-IDF unified provisioning API. It takes care of the implementation details, and supports both Wi-Fi and Bluetooth as transports.
Regardless of what you decide to do, I'd highly recommend reading the ESP-IDF documentation on unified provisioning and the documentation on Wi-Fi provisioning, since they'll give you an idea of what's going on under the hood and what all is required for a secure implementation. In particular, you'll see that the Wi-Fi provisioning library does actually use a static WPA2 password like I suggested above.
Suppose I have a mobile app which makes API calls to a server using HTTPS.
Would a malicious user be able to install Wireshark + Android emulator to inspect the API calls and by doing so get access to sensitive data like an API key?
I guess my question is whether Wireshark (or some other tool) can inspect the request before it gets encrypted.
If you control the client, then of course yes. Anything the client knows, its user may also know.
Without controlling the client, no, an external attacker cannot inspect or change https traffic unless they know the session keys. For that, they would typically use a fake certificate and make the client accept it (it won't do it by itself, and we are back at controlling the client).
Would a malicious user be able to install Wireshark + Android emulator to inspect the API calls and by doing so get access to sensitive data like an API key?
I guess my question is whether Wireshark (or some other tool) can inspect the request before it gets encrypted.
Yes this possible if the user controls the device he wants to intercept the API calls.
In the blog post Steal that API Key with a Man in the Middle Attack I show how a proxy tool(MitmProxy) can be used to intercept and introspect the https calls:
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.
In order to protect https calls from being intercepted, introspected and modified the solution is to use certificate pinning:
Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.
and you can learn how to implement it in the article Securing HTTPS with Certificate Pinning on Android:
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.
While certificate pinning raises the bar, its still possible to intercept, introspect and modify https traffic, because it can be bypassed, as I demonstrate in the article Bypassing Certificate Pinning:
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.
Conclusion
While certificate pinning can be bypassed I still strongly recommend its use, because it will protect the https communication channel betwwen your mobile app and API server in all other scenarios where is not the user trying to perform the Man in the Middle attack:
In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communications between two parties who believe they are directly communicating with each other. One example of a MITM attack is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all relevant messages passing between the two victims and inject new ones. This is straightforward in many circumstances; for example, an attacker within reception range of an unencrypted wireless access point (Wi-Fi[1][2]) could insert themselves as a man-in-the-middle.[3]
Going the extra mile?
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
HTTPS request is encrypted on your host (client) before sending over the network, so it is not available for Wireshark. Wireshark can get hostname of the HTTPS web serserver you connect but not the URL.
In our current project, IT rules prohibit anything that is not PROD to be publicly accessible from the Internet. Access to development and review environments must be severely restricted. That said, the project also includes mobile apps that are developed together with the cloud-hosted API layer.
In very general terms, what are the common approaches to securing DEV / REVIEW-stage APIs with mobile apps? We've come up with the following ideas:
IP whitelist on the ingress to the API (least secure, but easiest to use)
VPN gateway to the hosting environment, with corresponding DEV / test devices configuration
Mutual TLS authentication (most difficult to implement and operate)
There are multiple issues to address with each one of the approaches, but I'd like to understand the big picture before diving into any of that.
IP Whitelist
IP whitelist on the in the ingress to the API (least secure, but easiest to use)
I see it as least secure if you are whitelisting IPs that are not exclusive to your company office and/or the the IP is exclusive to your company but used by public WI-fis in your company.
Also in the case you need to whitelist access to remote developers and testers that may or not be in a public IP, this solution will be risky, because people always put convenience in front of security and they may ask to whitelist IPs that are from the coffee shop they like to work from, the shopping mall, the girl friend home, etc..
So I would discard this option, unless you are in a small office where you have the public WI-fi(the one for your clients to use) in a different IP from your main internet connection.
VPN Gateway
VPN gateway to the hosting environment, with corresponding DEV / test devices configuration
This approach seems to be the much wise to follow and only who have been granted access to the VPN will be able to use resources hidden behind it, and VPNs can be even used in public WI-fi.
Mutual TLS Authentication
Mutual TLS authentication (most difficult to implement and operate)
While is difficult to implement and operate they also suffer of the problem of certificate pinning be possible to bypass.
On this article about pinning in mobile apps we can read how easy it can be to implement certificate pinning:
// simplified android example
CertificatePinner certificatePinner = new CertificatePinner.Builder()
.add("publicobject.com", "sha256/afwiKY3RxoMmLkuRW1l7QsPZTJPwDS2pdDROQjXw8ig=")
.add("bikewise.org", "sha256/x9SZw6TwIqfmvrLZ/kz1o0Ossjmn728BnBKpUFqGNVM=")
.build();
OkHttpClient client = OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build();
In this same article we can also see how pinning can be a nightmare... as you said, difficult to operate!!!
The main difficulty with pinning is not technical but operational. By embedding fixed information about the server (the certificate) into the app you create a dependency between the two, as the term pinning implies. This means that whenever you (or your ops team) are planning to change the certificate on the server you must:
Generate the certificate in advance
Build, test and publish a new version of the app with both the new certificate and the old one.
Wait for most (80%, 90%, 99% ?) of your users to upgrade to the new version
Change the cert on the server
Build, test and publish a new version of the app with the old certificate removed.
As if this was not enough, certificate pinning can be by passed by using introspection frameworks, as pointed on the same article I linked above:
Even if you successfully navigate the operational difficulties inherent in implementing pinning, there is still the giant pink elephant in the room that is unpinning. The development of hooking frameworks such as Xposed has reached such a level of sophistication that a rich ecosystem of modules exists to target various aspects of Android apps including the pinning functionality of HTTP libraries. Using them is very straightforward.
Another Approach - Going the extra mile
That said, the project also includes mobile apps that are developed together with the cloud-hosted API layer.
In the context of a mobile apps you can use a technique devised as Mobile App Attestation, that can be used across all environments to protect the API server, for the mobile apps, from responding to requests that are not originated from the genuine mobile app binary you released, signed and registered for that specific environment.
Mobile App Attestation
The role of a Mobile App Attestation service is to guarantee at run-time that your mobile app was not tampered or is not running in a rooted device. It consists of a 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 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 is not aware if is sending a valid or invalid JWT token to the API server.
Conclusion
From your 3 solutions I would go with VPN approach and if you would want to go for the extra mile you should consider implement your own Mobile App Attestation service to guarantee that mobile APIs for any environment only communicate with mobile apps for that specific environment/stage and deny requests from any other source. This solution even allows for your mobile API to be hosted on the public domain without risking leaking any data, thus not needing a VPN on front of it.
I have a secure API for mobile clients. I would like to perform certificate pinning and I achieved it. The problem is if run the command openssl s_client -connect xxx.xxxxxxxxx.com:443 then I can see my certificate. I believe whoever have the URL, they can also see the certificate and they connect to my APIs.
How I can prevent access to my certificate, so that only my mobile can access but not public?
Anyone who connects to an SSL / TLS server can view the server's certificate because is public. This is normal behavior.
But that does not mean it can connect to your API. Normally an authentication mechanism is added where the one that connects has to present credentials, for example user/password.
With SSL/TLS is also possible to require a client certificate to stablish the secure channel. This is called two ways authentication. But it is not usually used from mobile devices because of the difficulty of distributing the electronic certificates
I suggest adding authentication to your api if you have not already done so
Public key cryptography works by having one part (the certificate) freely available publicly. The corresponding private key is needed to decrypt and it should be kept secret.
Therefore there is no problem with openssl having access to the certificate - that's exactly how it should work! A web browser will also be able to grab the certificate for a website it had not been too.
Pinning adds a further layer of security that this but limiting the certificates that a website can use to those certificates that are "pinned" to the site. As discussed without the private key, someone can decrypt the traffic. However there are certain, reasonably sophisticated attacks that involve intercepting traffic and replacing the certificate with another using their own certificate/private key combination so they can read the traffic. Pinning prevents this by explicitly stating which certificate(s) should be allowed in this site.
Pinning does not stop the need for the key to be public, nor does it limit connections from your mobile app only - there are other solutions for that but pinning is not it. It merely is used to address one type of attack against the server.
Pinning is an advanced topic and it is easy to accidentally cut off access to your site by pinning a certificate and then not updating the pins when renewing, or otherwise changing, the certificate. Due to that risk, you should ensure you have a much greater understanding of how all this works before implementing pinning. At the moment you seem to have a misunderstanding of the basics so would advise against advanced topics like pinning.