Why do vulnerabilities exist?

Why do vulnerabilities exist?

Any element of technology will contain vulnerabilities, mobile or otherwise. Of course, there is no indication as to how many vulnerabilities each will likely have; however, one very rudimentary method of determining the number of likely vulnerabilities is based on the number of lines of code

In other words, the more the number of lines of code, the greater the number of likely vulnerabilities.

Known as the average defect density, according to research 15 conducted by security firm Coverity, the number of defects per 1000 lines of code is estimated to be 0.62. 

This figure is identical for open-source projects as they are for proprietary projects. 

Of course, there will be considerable debate about the actual figure, because the number of likely defects will be dependent on many other variables, such as the expertise of the programmer and the quality assurance process.

However, the intention of presenting these figures is to emphasize that vulnerabilities will always exist, and as we demand more features and interoperability, the risk will only get higher. 

Furthermore, the level of complexity associated with mobile platforms increases the likely security risk. 

For example, mobile applications will include the functionalities associated with desktop computing; they will, however, also include cellular communication capabilities.

There are multiple examples of vulnerabilities associated with mobile devices, operating systems (OSs), and applications. 

This includes those applications that are developed with information security in mind. In 2020, security firm IOActive reported 16 that the official mobile application for the RSA Conference contained half a dozen security vulnerabilities. 

According to Chief Technical Officer Gunter Ollman, the most significant of these vulnerabilities could allow an attacker the opportunity to conduct a man-in-the-middle attack, inject malicious code, and potentially steal login credentials. 

Of course, the argument could be had that this is only an application for a conference (a security conference nonetheless) and that such vulnerabilities are unlikely to be present in applications that we use for more “important” tasks. 

vulnerabilities
vulnerabilities

However, research 17 conducted again by IOActive found that 90% of mobile banking applications contained security vulnerabilities:

  1. “A few apps (less than 20%) did not have Position Independent Executable (PIE) and Stack Smashing Protection enabled. This could help to mitigate the risk of memory corruption attacks.”
  2. 40% of the audited apps did not validate the authenticity of the SSL certificates presented. This makes them susceptible to Man in The Middle (MiTM) attacks.” 
  3. “50% of the apps are vulnerable to JavaScript injections via insecure UIWebView implementations. In some cases, the native iOS functionality was exposed, allowing actions such as sending SMS or emails from the victim’s device.” 
  4. “90% [of the apps contained several non-SSL links throughout the application. This allows an attacker to intercept the traffic and inject arbitrary JavaScript/HTML code in an attempt to create a fake login prompt or similar scam.”

Of course, the above details are only the vulnerabilities associated with mobile applications, and the title with this threat includes the OS, as well as hardware. 

Indeed, when we consider vulnerabilities for mobile OSs, recent research would suggest that the number of identified vulnerabilities is increasing. 

According to Symantec, In 2021 saw a 32% increase in the number of documented vulnerabilities. 

The security flaw associated with iOS 6-7 as detailed by Trend Micro provides a recent example of a mobile OS vulnerability. 

In this example, researchers revealed that when connected to a fake charging station, the security flaw would grant complete access to an iPhone or iPad on the iOS 6-7 platform.

This particular threat has been classed as a medium because, although vulnerabilities will exist, the number of exploits (in the wild) is very low.

Vulnerabilities Conclusions
Conclusions: Vulnerabilities

Conclusions

Hackers love targeting mobile devices, which are rich with personal data and payment card information.

Our results indicate that developers of mobile applications often neglect security, with the main issue being insecure data storage. User information stored in cleartext, unmasked data in screenshots, and keys and passwords in source code are just a few of the flaws that offer opportunities to cyberattackers.

Users themselves may unwittingly help to compromise their devices by expanding smartphone capabilities, disabling protection, opening suspicious links in SMS messages, and downloading software from unofficial sources.

Securing user data requires a responsible attitude on the part of both application developers and device owners.

Nor can we underestimate the role of server vulnerabilities.

Protection of mobile application servers is no better than that of clients. In 2021, every tested server-side component contained at least one vulnerability enabling various attacks on users, including impersonation of the developer in phishing emails, placing the developer’s reputation at risk.

To prevent exploitation of server vulnerabilities, we recommend using a web application firewall (WAF).

Beyond client and server vulnerabilities, risks also include client–server communication. Data sent over an insecure protocol can be completely compromised. But even secure connections are not always safe. Developers still have yet to attain a deep understanding of the importance of security.

Protection mechanisms are the weak spot in mobile applications. Most of the discovered vulnerabilities were introduced during the design stage and result from failure to “think through” security-related questions.

We recommend a methodical approach to designing and following through on mobile application security, regularly testing it starting from Day 1 of the software lifecycle.

The most effective method is white-box testing, in which security analysts have full access to source code.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top