How to Prevent Man in the Middle Attack on Android
At some point in your engineering career, you might face challenges in mitigating man-in-the-middle (MiTM) attacks. The attack can intercept the communication between your backend API and Android App to exploit your authentication/authorization and to modify/redirect your data on the fly.
Challenges
A few possible solutions are available, such as enabling Certificate Pinning (limiting the set of trusted CAs), Client Certificate Authentication, or a combination of those. However, none of these is easy to implement and involve higher operational costs subsequently.
Certificate Pinning
For example, Certificate Pinning ensures the app is talking to the server it expects to talk to. However, it is falling out of favor and is not advised/supported even by developer.android.com.
Also, there are a lot of tradeoffs in which level Certificate pinning should be implemented: Leaf -> Intermediate -> Root.
Implementation of Leaf will be more secure. However, it will be expired very frequently than Intermediate or Root. The Root has a longer expiration time, but it is less secure.
Client Certificate Authentication
Also, Client Certificate Authentication works the other way around. It adds an extra layer of security so that the server can be sure only clients with the certificate can communicate successfully. However, since the app can be decompiled without a lot of effort, this client certificate can ‘easily’ be obtained by a malicious user. So this isn’t a silver bullet.
Possible Solutions
However, a better solution relies on DNS and is more sustainable in the long run from an operational cost perspective.
DNS Over HTTPS
DNS Over HTTPS (DoH) is a protocol for performing DNS resolution over HTTPS. And OkHttp starting from version 4.10.0 and above, comes with the DoH feature, which you can enable on your Android app. If you are unfamiliar with OkHttp, we recommend trying it for your app networking. Here is the example code for your reference:
DNSSEC
DNSSEC requires minimal developer involvement. Also, it has some advantages over Certificate Pinning. See the table below for a comparison of mitigating attacks using SSL Pinning and DNSSEC[Lynn]:
+------------------+---------------------+--------+
| Types of Attacks | Certificate Pinning | DSNSEC |
+------------------+---------------------+--------+
| SSL Hijacking | No | Yes |
| SSL Stripping | Sometimes | Yes |
| DNS Spoofing | No | Yes |
+------------------+---------------------+--------+DNS Certification Authority Authorization
The CAA record specifies which certificate authorities are allowed to issue certificates for a domain. It is defined by RFC 6844. Here is an example of how you can enable the DNS CAA record in AWS Route53:
- Prepare CAA record in JSON file, e.g.:
$ cat caa-record.json {
"Comment":"Either create or update CAA record",
"Changes":[
{
"Action":"UPSERT",
"ResourceRecordSet":{
"Name":"example.com",
"Type":"CAA",
"TTL":300,
"ResourceRecords":[
{
"Value":"0 issue \"amazontrust.com\""
}
]
}
}
]
}2. Run the following command to either update or create the CAA record:
aws route53 change-resource-record-sets --hosted-zone-id YOUR_ZONE_ID --change-batch file://caa-record.jsonYou can find the hosted-zone-id from your Route53. Also, the CAA record value should be one of these domains; you can read more about it here:
- amazon.com
- amazontrust.com
- awstrust.com
- amazonaws.com
Conclusion
At this moment, there is no single silver bullet to mitigate man-in-the-middle (MiTM). We suggest you implement all solutions described above. First, start by enabling DNS Over HTTPS for your Android app and securing your domain with DNSSEC. And later, implement DNS Certification Authority Authorization.
Please let us know if your Android app’s network is still exploited by burp suite, mitmproxy, or any other proxy tool.
