Skip to main content

Application Insecurity and Mobile Phone Cybersecurity

July 20, 2017


Phoibe Purcell

As the world becomes connected, personal security has become a top priority for governments, developers, and regular users alike. Because they use mobile applications for day-to-day activities such as banking, social media, and email, users now have a majority of their information stored in databases online. This poses a serious risk if that data is not secured properly, or if it is mishandled.

On February 6, 2017, Sudo Security Group CEO Will Strafach published an article revealing 76 vulnerable applications by taking a closer look at the binary code of popular iOS applications using their app analysis service, (Strafach, 2017). Sudo Security Group found that these mobile applications, which should have been protected by TLS (HTTPS), left connections open to a possible man-in-the-middle attack.

While there were 33 “low-risk” applications, the other 43 were placed in the “medium-high risk” category, putting sensitive user data and other personal information in danger (Strafach, 2017). Apps in the former category put email and other network login information at risk, while the latter included financial and medical information.

This exposure is simply one of the more recent out of a long history. Even larger companies such as MySpace (2015), Ebay (2014), Yahoo (2015, 2014, 2013), Dropbox (2012), and LinkedIn (2012) have experienced data breaches resulting in compromised user information. As a global issue, it is, therefore, even more important for startups, and small and medium-sized businesses (SMBs) to prioritize user security. This is not to say that information safety is not a concern for most companies, however, some developers may place other developmental priorities over security measures (Shackleford), ultimately leaving users and databases vulnerable to attacks.

Man-in-the-Middle Attacks

Man-in-the-middle attacks occur when an outsider intercepts communication between two parties to obtain information or data without their knowledge. The attackers do this through impersonation of the intended recipients. These attacks are even more prevalent over an insecure HTTP connection versus a HTTPS connection. HTTPS connections are more secure because they use TLS (Transport Layer Security) or SSL (Secure Sockets Layer) protocols. These protocols have either public or private keys used to ensure that data sent and received are encrypted, so long as there is a valid certificate to ensure a secure connection is established.

According to Strafach, this vulnerability is caused by an invalid TLS certificate. The invalid certificate allows others to intercept data via wifi connection regardless of location, as long as the outside party is within range. He speculates that this is most likely due to developer error, where many will test applications using network code meant to override the TLS validation, and thus, forget to remove it before publishing to the App Store (Strafach, 2017).

Current Security Requirements for Developers

Earlier in 2016, Apple announced that they would be enforcing policy that would require all applications in the App Store to have TLS protection under Apple Transport Security (ATS), by January 1, 2017 (Inc., Apple). Apple’s developer website states:

On Apple platforms, a networking security feature called App Transport Security (ATS) is available to apps and app extensions, and is enabled by default. It improves privacy and data integrity by ensuring your app’s network connections employ only industry-standard protocols and ciphers without known weaknesses. This helps instill user trust that your app does not accidentally leak transmitted data to malicious parties (iOS Security Guide, 2017).

Previously, this had been optional, and many developers chose not to implement it. Since their initial announcement, Apple has pushed back this deadline in order to give developers more time to make the switch, but has yet to announce an official deadline.

Unfortunately, affected apps are still vulnerable even if they have Apple’s ATS installed, since the error is dependent upon code within the applications themselves. In this regard, Apple is not solely responsible for the insecure connection, and it also falls on the developer to ensure that their code doesn’t allow for any breach of security.


When the original report revealing the security issue was posted, it was estimated that it would take another 60-90 days to publish the names of the medium-risk and high-risk apps in the interest of user safety. As of May 4, 2017 an update was posted, disclosing 27 of the higher risk apps. Among these were apps for banks in India, Costa Rica, and the US, as well as private search and mobile security applications. Many of these issues have been resolved; however, some companies have not yet fixed these vulnerabilities (Strafach, 2017).

Fortunately, users can take steps to protect themselves by using cellular network connections before accessing important data, such as banking or other financial information. While there’s never a guarantee of total safety, cellular networks are oftentimes more secure than public wifi given there is no other option for obtaining a secure connection (Strafach, 2017). This is because open wifi networks may allow easier monitoring access to unencrypted data, and place the public at greater risk for spoofing, or man-in-the-middle attacks.

On the back-end, developers can begin to make their apps more secure by not incorporating code that overrides security features, and by making sure that the function of any borrowed code is fully understood. A report from the SANS Institute suggests placing more emphasis on security measures through educating their developers on potential risks, incorporating good security practices during initial development and ideation, more frequent vulnerability testing and automated assessments, and allowing for increased transparency between stakeholders and consumers.

In addition to developers, a survey compiled by VIPRE revealed that small and medium-sized businesses often compromise on security features due to high costs, a lack of knowledge, and overconfidence in their existing security measures—despite the fact that 50% of SMBs were hacked in the past 12 months (The 2016 State of SMB Cybersecurity, 2016). This shows a serious need for companies and businesses to invest more time and resources in IT and security as SMBs are becoming a frequent target for hackers.


The global usage of iOS apps makes the vulnerability of so many apps particularly problematic, as it transcends physical borders. The total number of downloads estimated for these 76 applications is reported to be around 18,000,000 (Strafach, 2017). With a rising number of cyberattacks and data breaches due to developer oversight and the reluctance of companies to properly invest in endpoint security, this instance is indicative of a larger problem.

In today’s political climate and the movement from physical to digital, personal and national security has become a top priority for governments and ordinary citizens around the world. Users should be able to trust their information is secure, regardless of location, and developers and hosts should take the necessary steps to ensure user data is private and secure.


Inc., Apple. “Supporting App Transport Security.” News and Updates. Apple Developer, 2016. Web. Apr. 2017.

IOS Security Guide [PDF]. (2017, March). Apple.


Shackleford, Dave. Integrating Security Into Development, No Pain Required. Tech. SANS Institute Reading Room, n.d. Web.

Strafach, W. (2017, February 06). 76 Popular Apps Confirmed Vulnerable to Silent Interception of TLS-Protected Data. Retrieved April 20, 2017.

Strafach, W. (2017, May 04). Follow up: 76 Popular Apps Confirmed Vulnerable to Silent Interception of TLS-Protected Data. Retrieved May 7, 2017.

The 2016 State of SMB Cybersecurity. Rep. Keeper Security, 2016. Web.

“The Office of Inadequate Security.” N.p., n.d. Web. May 2017.

This publication was made possible in part by a grant from Carnegie Corporation of New York. The statements made and views expressed are solely the responsibility of the author.