Hackers might not attack you. Bots will.
When I talk to developers about security, the common theme I hear is:
My app is too small, no one is going to attack me.
This is because developers (and non-developers) assume that their attacker looks like this:
Which is partially true, there are some excellent security professionals and cyber criminals that look great in a hoodie and that are attacking applications and their associated servers — but for the rest of the lower profiled applications, it is more likely that their threat is going to be:
• A search bar, or
• a bot
There are three main attack vectors that an attacker will focus their attacks on. The application binary (your app), the network the app is on, and the server holding the data for your app.
1. The application
Let’s talk about reverse engineering. Now if you’re not familiar with this concept — let me just start with this:
Developers give away their application. Every user has the app and its logic. Within the application is the code and associated values. It’s pretty easy to get those into a human readable form. On Android, it gets it back to almost the exact code a developer wrote.
There are many developers out there storing secrets, storing keys into applications and assuming they’re secret because the app is “compiled”. But as you can see above (and the many tutorials online), they’re easily recoverable.
Reverse engineering is not a new threat, but there have been some pretty amazing advances with Big Data.
So, with one of my clients (https://keyoptions.com) here in Australia, I have the privilege of working with a company called Mi3Security.
Special thanks to the team at Mi3Security for letting me publish some of their data publicly.
I asked my contact there really nicely, if he could tell me how many apps within their database (around 65–70% of all public apps) are currently not implementing Application Transport Security correctly by implementing NSAllowsArbitaryLoads
The result was instant. I was shocked.
I mean.. I know how database lookups work, but holy crap, in front of me was a portal to source code for millions of apps.
So, what do I ask? At the time, the memory of Uber trying to fingerprint user’s information was pretty fresh in my mind. If you’re not familiar with it, you can view the story here.
So we checked how many other apps also used the line of code that got Uber into trouble:
Looks like Uber took the heat, but we know there are many other apps doing something similar.
This information was gathered quite quickly. How many agencies have a database like this? I can think of only a few companies / countries that might have something like this…
Searching with Regex
So, I thought it would be a good idea to try a basic “http only, send password” regex.
I had seen a high-profile example before from Zscaler (research found here) where they found this exact vulnerability in one of India’s top shopping apps. But I figured it didn’t really happen anymore…
I had faith in the development community.
I posted the regex query to the Mi3Security team, and even suffixed this statement to the team saying:
“It’s okay if that query finds zero apps”
What a stupid thing to say…
There are over 30,000 apps that do not implement HTTPS for a query that looks like it involves a password. The worst part is:
You would never know if the app is using HTTPS or not
There’s no green lock, no certificate error or lack of either — there’s just a login page inside an app. It’s impossible to know from an app GUI if they are communicating using a secure TLS connection, have poor TLS configuration or no TLS configuration at all. Thanks to Mi3Security, we now know that at least 30,000 apps have zero login security.
Now obviously — there may false-positives, my regex statement isn’t perfect (and if you have a more precise statement, let me know, I’ll get them to run it and credit you)
What else can we check? I asked InfoSec twitter for feedback:
Three of my favourite suggestions came from Don Lor, Dan Levy and the amazing egyp7.
BEGIN RSA SECRET == 193,329 apps. 🤦🏻♂️🤦🏻♀️
Now this number seemed pretty high to me, so I’ll likely write a follow up to understand why so many developers are storing private keys in their apps
Don Lor had an excellent suggestion to look for AWS keys in mobile apps. This is pretty common mistake for people to store it in github, but I wonder how many apps think it is “secret in their code”
Regex for AWS Private Key is:
This query produced 694 apps out of 1.3m Android apps. That’s not a high number, but it’s still almost 700 applications that have their AWS private key exposed which should never be exposed.
Dan gave me a suggestion extended my set of keywords. I appreciate people who clearly have more field experience than I do 😅, but the results will need more filtering, so I will write a follow up when that’s done.
How can I protect against Reverse Engineering?
There’s not a lot you can do to protect against reverse engineering. You’re giving away your app. However, avoid storing secrets within an app. Keep all secrets on your server.
If you ‘must’ store a secret, you can make it harder for an attacker by obfuscating your secret. This definitely doesn’t make it impossible, just more annoying to find for an attacker.
If you’re on iOS, you can use something like this: https://github.com/pjebs/Obfuscator-iOS
On Android, ProGuard should be used at a minimum. If you have a bit of money, DexGuard or another commercial obfuscator can be quite useful.
2. The Network
There are two main attacks for mobile applications.
• Developers have mis-configured HTTPS / no HTTPS.
• Users are using free wifi
One of the biggest network security concerns in mobile apps that you cannot validate the security of the HTTPS certificate while using the application.
Developers need to do the right thing with their web servers. Here’s are some good resources to make sure your web server is configured correctly:
- Qualys SSL Server Test is an excellent resource to test your server and check the health of your TLS certificate
A comprehensive free SSL test for your public web servers.www.ssllabs.com
2. I’ve come across this website recently that helps people check what security features are exposed in the header. Strict-Transport-Security is the one we care most about for HTTPS security, but the others are good too. (My Bank got a D grade based on their security headers. Something for me to look at the consequences of next week)
Quickly and easily assess the security of your HTTP response headerssecurityheaders.io
3. To set up HTTPS, the amazing Troy Hunt has an excellent resource that every web dev should read.
It's finally time: it's time the pendulum swings further towards the "secure by default" end of the scale than what it…www.troyhunt.com
Once developers have set up proper TLS, they need to assume the users are on a hostile Wi-Fi. A user can be tricked into using a malicious network and one of the methods we use to protect a user from a malicious actor on a network is HTTPS.
Now, in order for HTTPS to be considered secure for an app, two things need to be correct:
1. The Server needs to be configured correctly (see the above resources)
2. The client / app need to be configured correctly.
In order to achieve point 2 — we can utilise Application Transport Security (ATS) on iOS and Network Security Configuration (NSC) file on Android. These move the burden of certificate verification from the app (where developers and libraries have made mistakes in the past) to the Operating System, where we have some level of trust that Apple and Google will do the right thing.
If you want to take an extra secure step, you can also implement Certificate Pinning, which is an excellent way to ensure your app is almost definitely talking to the right server. For more information on Certificate Pinning, view my talk as I go into it with a unique example.
3. Your Server
There are lots of attacks on web servers and web applications . There are books, blog posts, videos, and countless online resources discussing this. This blog post is more focused on automation and attacks, and one of the biggest we’ve seen in the development space is finding simple vulnerabilities using two sources:
- Google Hacking Database — for doing very quick google searches finding poorly hidden information. As an example, here’s an example of websites potentially leaking databases with the table orders in it:
intext:”Dumping data for table `orders`”
Google Hacking Database (GHDB) By Offensive Securitywww.exploit-db.com
2. Shodan search engine for any open port to the internet.
Shodan has servers located around the world that crawl the Internet 24/7 to provide the latest Internet intelligence…www.shodan.io
Security researchers and malicious actors use Shodan to find unauthenticated webcams, industrial control system pages and databases. Many databases have weak, or no authentication blocking them. Shodan researchers published that there was a staggering amount of data being leaked from MongoDB and HDFS databases.
For the whole write up, visit the links below.
There's been much focus on MongoDB, Elastic and Redis in terms of data exposure on the Internet due to their general…blog.shodan.io
I would like to take a moment to discuss databases. Most people use Shodan to find devices that have web servers, but…blog.shodan.io
In light of the recent incident of MacKeeper exposing 13 million accounts through a public, unauthenticated MongoDB…blog.shodan.io
These unauthenticated servers came under attack earlier this year. They were encrypted and held for ransom. Not because of some advanced apex attacker, but due to security not being enabled by default.
An attacker going by the name of Harak1r1 is hijacking unprotected MongoDB databases, stealing and replacing their…www.bleepingcomputer.com
How to fix this? There are hardening guidelines for your web stack.
Let’s go back to my original point:
My app is too small, no one is going to attack me.
A bot doesn’t care that your app is too small. A search engine doesn’t care. If you are low-hanging fruit, you will be attacked. Web servers, email servers have been experiencing this for years. Mobile apps will be joining their ranks soon (and they are already).
What’s the takeaway? Mobile App Developers need to understand these three things:
1. A mobile app is reversible to get to any string / url/ secret within an app
2. Network security need to be configured correctly at the server AND the client to be effective
3. Automating attacks on servers has never been easier, it needs to be hardened and patched regularly.
Lots of 👏🏻 and ❤️ to @sammy_lee12 on twitter who attended my talk and sketched me my talk on a single page. You rule in so many ways!
You made it to the end! Nice one! Press the clap as many times as you like, it gives me warm happy feelings ☺️. Think I’m cool enough to follow on twitter? @proxyblue is where you’ll find me. I post and retweet InfoSec stuff.
The latest Tweets from Louis Cremen 👨🏻💻 (@proxyblue). Mobile Dev & Sec @ Centre of Digital Innovations. Former…twitter.com
Still want to hear a bit more?
Here is my 3-minute lightning talk from the same conference. “How to talk like a developer”.
Here’s a link to the original “How to succeed as a Red Shirt without even dying” talk:
Thanks for reading! Want to read a bit more from me?
So this story stems from the fact that I’ve plopped myself into the InfoSec world from App Development and from my Sec…hackernoon.com