Mobile phishing is on the rise. And while most of us know what phishing is, let’s quickly define it to make sure we’re on the same page. Phishing is the fraudulent attempt to obtain sensitive information or data, such as usernames, passwords, and credit card details, by disguising oneself as a trustworthy entity in an electronic communication. Mobile phishing a particularly insidious attack, because while people are primed to receive phishing attacks on their desktop and laptop computers, they generally feel safer when using a mobile device — even though attacks on mobile apps and devices are increasing rapidly. A 2020 study from cloud security company Lookout found that mobile phishing attacks grew 37% from Q4, 2019 – Q1, 2020, with much of this growth attributed to new attacks related to COVID-19.
By Alan Bavosa, Vice President of Security Products at Appdome
Phishing attacks rely on social engineering, where hackers target unsuspecting mobile users by tricking them to click on a link that takes them to a malicious site.
Hackers have two main goals when they conduct mobile phishing:
- Data Harvesting: Using man-in-the-middle (MiTM) attacks (and other forms of network or session hijacking techniques), a malicious attacker can gain access to valuable data, such as usernames, passwords, secrets, API keys, and other valuable information. They either monetize this information or use it later in other attacks, such as to infiltrate the ‘backend’ systems or server.
- Malware delivery: Sometimes, attackers trick unsuspecting users into downloading malware. For instance, the attacker may pretend to be your bank, your IT department, or some other trusted entity and ask you to download or update a mobile application that looks like the real app but is a fake copy of the real app with malware embedded inside. Once you download the app, the malware activates, usually at some later time so that you don’t suspect it.
Mobile apps need to be secured against phishing if they have messaging capabilities, but there’s not one quick fix to the problem. Like most cybersecurity defenses, mobile phishing protections need to be multi-layered, using measures such as URL whitelisting, MiTM attack prevention, certificate pinning, certificate validation, anti-tampering, and anti-reversing.
So, let’s take a deeper look at the mobile phishing problem and how mobile developers can protect their apps against this kind of attack.
The Mobile Phishing Problem
As noted above, when people think of phishing attacks, they typically think of a spoofed email that pretends to be from their IT department asking them to download a patch that’s a virus or a bogus request from the CEO to send a wire transfer that ends up going to criminals. However, these days phishing attacks are conducted through mobile channels, including social media apps, gaming apps, banking apps, short messaging services (SMS), and multimedia messaging services (MMS). Many games, especially those that involve large numbers of other human players, include chat capabilities that can act as a vector for phishing.
In short, if the app enables people to communicate with one another, a hacker can abuse it. And why not? It’s effective.
Hackers use many different attack methods to convince their victims to take actions that will move an attack along, often disgusting their presence. For instance, “URL padding” is an attack technique where the hacker uses a real and recognizably safe domain up front, but then adds hyphens or other characters to conceal the true, malicious domain. This means a domain like http://mobile.twitter.com—————-a23x.I-will-steal-your-money.com/login.html would show up as “mobile.twitter.com” in the small address bar of the mobile phone … possibly along with a few hyphens that the user won’t notice. Hackers also use tiny URLs from one of many services that create a smaller link that redirects to a much longer one, hiding the actual domain from the user.
Mobile phishing is often blended with a man-in-the-middle (MitM) attack to increase effectiveness. For example, a user might receive a message in their banking app purportedly from their financial institution asking them to log in via their browser and verify account details. The malicious link leads them to a site that looks exactly like their banks’ website.
Other times, the attacker delivers the fake login screen inside the mobile app, placing the fake screen on top of the real screen in what’s known as an “overlay attack.”
Certainly, developers of financial mobile apps understand the stakes — people’s finances are at risk. But even apps focused on entertainment such as games need anti-phishing protections. After all, mobile gaming revenue surpassed $75 billion in 2020, a 19.5% increase over 2019, according to Sensor Tower. And 43% of that gaming revenue comes from in-app purchases, according to a 2020 study from Wappier. That’s at least $32 billion passing through mobile gaming apps in 2020 alone. Hackers are working hard to siphon some of that money off for themselves.
Combatting Mobile Phishing Requires a Multi-Layered Defense
As explained above, mobile phishing attacks are far from simple, so they require several different techniques to defend against them.
Blacklisting, which blocks known dangerous URLs, is a common tactic, but it’s not very effective. Most of the sites to which phishing attacks link only remain active for a few days, at most, and new sites pop up daily. Attempting to identify them all is a never-ending game of whack-a-mole. When possible, URL whitelisting is a far more effective measure because it allows access to a specific list of sites and blocks all others.
A financial app, for example, might whitelist just a few select URLs to its website, and a game might do the same. In this way, no matter what link a phishing attack sends, the user will be unable to connect to it through the app.
Another method to combat phishing is securing the transport or communication channel to prevent MiTM attacks. For starters, apps should always enforce Transport Layer Security (TLS) versions and ensure that trusted, approved cipher suites are used. Cipher suites are sets of algorithms used to secure a TLS connection, and developers have hundreds of options to choose from, many of which may be outdated or insecure. Only approved, current and secure cipher suites should be allowed.
In addition, it’s important to validate the authenticity of the SSL/TLS certificates used in mobile connections. Certificates work on a chain of trust. “Higher” certificates validate the authenticity of “lower” certificates, all of which depend on a certificate issued by a trusted provider. When a server presents a certificate to an end-user, that’s called a “leaf” certificate, and while these certificates are not intended to be used as certificate authorities, they can be used to sign other certificates. This allows an attacker to insert a malicious, fake certificate into the mobile device without the user knowing. The attacker can then redirect the connection or even alter the content/payload.
To stop this kind of attack, developers should consider defenses such as certification validation, certificate pinning, and certificate role enforcement using “Basic-Constraints.”
Anti-Tampering and Code Obfuscation
Finally, it’s important to protect apps against tampering, reversing, and debugging. The more a hacker knows about your app, the better prepared they will be to launch effective attacks. It’s harder for a cybercriminal to create an app overlay without first taking the app apart to understand how it works.
Code obfuscation prevents reverse engineering techniques that rely on disassembling or decompiling an app’s code via static or dynamic analysis tools, but it needs to be implemented carefully because the app can break if the wrong process is obfuscated. Additionally, obfuscation must be updated line-by-line with every new release of the app. Finally, third-party components such as software development kits (SDKs) can’t be obfuscated unless developers have access to the source code, which is rare.
Anti-tampering and reverse engineering protection stop hackers from adding modifications to apps or even create fake versions of apps. And in the case where hackers can modify an app’s code, developers should ensure that the bogus app won’t function. Checksum verification does exactly this by analyzing the binary to generate a unique hash function. Any changes to the binary will result in a different checksum value from the one the genuine app will generate, which should cause the app to close.
Mobile App Security Implementation Challenges
Implementing all of these protections presents a daunting challenge to mobile development and security teams. Not only are some of these measures such as obfuscation extremely difficult to manually code, but the mobile security skills required are also in short supply. And even if a development team has the skills in house, manually implementing security is expensive and time-consuming, ballooning budgets and delaying release dates. Thankfully, there are ways to implement these features without having to do so manually.
Software development kits (SDKs) can be incorporated into apps to provide security, though they do require some manual coding and bring significant limitations when it comes to obfuscation. Another option is a no-code platform that can embed security capabilities into an app binary without requiring changes to source code. By obfuscating at the binary level, even SDKs and third-party libraries may be obfuscated.
Mobile phishing is a growing threat, but app developers are not helpless to defend against it. By taking a multi-faceted approach, app developers can protect their customers and end-users from being compromised.
About the author
Alan Bavosa is VP of Security Products at Appdome. A long-time security product exec, Alan has previously served as chief of product for Palerra (acquired by Oracle) and Arcsight (acquired by HP).
Views expressed in this article are personal. The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same.