The role of a developer in getting rid of security vulnerabilities at it's very inception is significant!
In my opinion, it's the mindset which makes a big difference. Developers usually work under a constructive mindset, trying to make things happen, while hackers have a destructive mindset, to find the tiniest of the flaws that they can exploit to make the app dysfunctional.
Hence, if devs get to know about the other mindset and try to employ it while creating software, it can help us create really secure apps.
And this is the intention behind this series of blog posts. In this series, I'll share some common vulnerabilities/attacks we have seen on Android lately.
In the first part of this series, let's dig into five generic vulnerabilities that are prominent on Android and how can we protect our app from these.
Random Tip : If you are security researcher, consider making your automated security vulnerabilities scanners that can run and detect apps for issues in categories which are being paid out.
1. Insecure Connections:
These include
Use of insecure network protocols
Data transmission over insecure protocols
Authentication over insecure network protocols
Look out for the network protocols you use for network interactions in your app. If they are insecure such as FTP or telnet or HTTP, an attacker on the same network can potentially replace, remove or inject code. Such that the user might see a screen asking for credentials or account details. This is similar to how people can be phished online on websites when connected through insecure network connections, however there is one significant difference.
In web, we still have a factor of trusted UI, certificates, URL put in URL box, a lock sign etc, however in Android if the user comes across phishing activity there is potentially no way to differentiate the UI from the UI of the legitimate app.
So where all can you dig in for such vulnerabilities?
(i) Look at network security configuration.
The Network Security Configuration feature lets apps customize their network security settings in a safe, declarative configuration file without modifying app code. These settings can be configured for specific domains and for a specific app. The key capabilities of this feature are as follows:
Custom trust anchors: Customize which Certificate Authorities (CA) are trusted for an app's secure connections. For example, trusting particular self-signed certificates or restricting the set of public CAs that the app trusts.
Debug-only overrides: Safely debug secure connections in an app without added risk to the installed base.
Cleartext traffic opt-out: Protect apps from accidental usage of cleartext traffic.
Certificate pinning: Restrict an app's secure connection to particular certificates.
(ii) Common entry point for network: Check out for usage in Web Views
(iii) Scrutinise the JAVA network classes you end up using, e.g. codes should use the right lib like javax.net.ssl.HttpsUrlConnection for secure connection.
Random Tip: It'll be good to have lint check in CI/CD pipeline to detect Insecure Base Configuration flags.
2. Embedded crypto or auth tokens which are leaked and have security impacts.
Several SDKs that we use in our app use hardcoded api keys or tokens. There is always a risk involved regarding leakage of these tokens when saved at client side.
How do you detect such vulnerability?
To find the issues, find the common sdks embedded which use hard coded credentials to authenticate, these include AWS, Twitter API, FB, Google Cloud Services, Flickr etc. And then play around where are the keys stored and if you can access them.
Is there a sure shot way to protect client side embedded keys?
Well not exactly. However, one can spin a server, use it to proxy the requests and hide the API credentials on server itself.
Another approach should be to understand the potential abuses if the key gets leaked and then formulate a plan to mitigate. Is it security critical, what permissions are there is it read or write or both? What all damage can it cause?
3. App's private data exposed:
Such attacks are relatively less on Android as Android sandboxes all the apps. However, still crucial data can get exposed. Some simple ways this can happen is when you mistakenly save the apps data on SDCard (all apps can access that) or you have dumped important tokens in the logs! Minor but costly mistake.
Apart from these, let's talk about a really innovative way in which app's private data can be accessed or overwritten. This happens when your app tries to read a zip file.
Do you know the internals of what exactly happens when you try to unzip a file? Well, les cover that in a separate blog post. Briefly, while unzipping the headers hold the information of relative paths of files in the directory once it's unzipped. A hacker can modify these paths to refer to the app's internal data directory, hence when the file is unzipped, the internal data of the app can get potentially overwritten.
Learn more about ZIP format here: https://en.wikipedia.org/wiki/Zip_(file_format)
Hence, devs should always validate canonical paths of zip path.
4. Incorrect URLVerification: Devs use different ways to validate that they are making connection to the right URL they control. This can go wrong in in numerous ways. For example a very common way to check is :
webView.loadUrl(uri.toString());
}
Do you see the problem?
Well the full-proof way to validate that the uri is the legitimate one is rather long, hence developers usually resort to simpler ways.
How can one spot this kind bug?
Find all instances of URLs used in app, narrow down on the instances that work on user-controlled input, see if part of URL decides different code paths.
Here are some other ways to bypass URL Check:
5. Incorrect sandboxing of scripting language:
Embedding a scripting language or interpreter in an app that can lead to exposure of app internals if security boundaries of interpreter are not well understood.
Reference: https://youtu.be/51S8PeuzlmI
So these were the five vulnerabilities (in no particular importance order) that I came across today! Stay tuned for the next post on some other new vulnerabilities!
Meanwhile, if you found the content useful, please like, share and subscribe. For more insightful conversations, let's get connected on Twitter!
Stay Safe & Keep Hacking!
See you in the next post soon.
Comments