By Cameron Hodson, Audit Senior, Larson and Company CPAs
Mobile applications or “apps” have been part of everyday use for the past decade and companies have potentially dozens of apps available for employees and customers. Should we be worried if the industries’ race to get an app in front of users has outpaced standards for mobile application security?
The answer to this question was a clear “yes” several years ago. Today, many* developers are aware of security traps and have built security into their mobile software development life cycle (SDLC). However, the need to monitor security and privacy of data will continue, especially with the increase in regulations internationally and in the United States.
The following are some basic ways a specialist may test mobile applications as well as some best practices in mobile development.
The main focus in mobile security testing is to ensure compliance (do data handling practices conform to internal/external standards, e.g. GDPR), security (how data is protected in general), and privacy of data (what types of data is stored). A specialist should focus on these criteria in reviewing two main areas of mobile data: data at rest and data in transit.
Data at Rest
When specialists are assessing the security of data at rest they should identify two areas of vulnerabilities: (1) the type of data that is stored and (2) where the data is stored on the mobile device.
If personally identifiable information (PII) or confidential information (i.e. proprietary information) is stored on the device, the risk of compromise due to unauthorized access (hacking) is present. Possible locations for data storage include the keychain, private app folder, SD card, RAM, source code, log files, and web cache. The best way to protect something is not to store it at all on the mobile device. Specialists should carefully identify what type of data is stored and then determine whether it is necessary for the functionality of the application and specific user. If unnecessary PII or confidential information is identified during their assessment, further actions should be taken to minimize the amount of personal information that is contained within the mobile device.
Where the mobile application stores data is also important because of the various personal information that can be shared between applications based merely on an application’s privacy settings (e.g. location services, camera, Bluetooth, contacts, apple pay, etc.). Due to the apathy of users when it comes to apps and data permission, users may not realize that a downloaded app could potentially access another app’s data. Therefore, specialists should perform hacking and searching techniques to determine how easy it is for unauthorized individuals to access and locate PII or confidential information.
Data in Transit
When data moves from the mobile application through the web to business servers, it is “in transit”. During this transit phase, numerous vulnerabilities could occur if a secure method of transport is not utilized. Those who steal or alter data maliciously (hackers) mainly uses two types of attacks on data in transit: Man in the Middle attacks and SQL injection.
A Man in the Middle attack is when a third party intercepts traffic by pretending to be a destination site using a false certification, or none at all (usually by being on the same network, at least initially) and views and/or changes the content of that traffic before sending it on to the actual destination site or some other destination. This could allow the third party, or proxy, to view unencrypted content in the traffic and potentially gain access to PII or confidential information that is transmitted. In today’s world, food, shelter, clothing, and access to data are included on most people’s basic needs list. So, it is inevitable that your data will be vulnerable to this kind of attack while traveling or at your favorite hot spot. To protect against this kind of attack, many apps use certificate pinning to ensure validation is obtained from the device they are expecting to communicate with before communication occurs. Some other useful prevention methods include the use of TLS 1.2 or 1.3 to create secure data transfer connections, encrypting data in transit to protect data even when it is intercepted, and making sure session tokens expire after logout to protect a compromised account.
SQL injection is when attackers use common SQL statements which are inserted into an entry field instead of actual username and password to trick an application into unknowingly running a query on the database and return information to the attackers or grant them access without ever knowing a user’s username and password. For example, in a SQL injection attach, an attacker may add an SQL formula within the username and/or password field [ ‘ OR ‘1’=1’ ]. The application, may then read the logic of the SQL statement to determine whether ‘1’ truly does equate to ‘1 instead of searching its access database for the username and password. Since the SQL statement is ‘TRUE’, the software may return the ‘TRUE’ result to the application authorizer which then grants access. This can be avoided with intelligent code development to reduce such vulnerabilities in the software. Tools like Veracode are available to specialists for purchase to check for code vulnerabilities.
Evaluating Results
A common way to evaluate the results of the specialist’s analysis is using a scoring system, such as the Common Vulnerability Scoring System (CVSS – first.org/cvss). CVSS assesses a risk using factors such as how sensitive the accessed data is, what kind of access was needed to attain it, how complicated the attack needed to be, etc. While the evaluation of security is still subjective, a system like CVSS allows the specialist to communicate how a particular conclusion was reached and specifically what aspect of security was considered the weakest/strongest.
Mobile Security Plan
As the use of mobile apps now permeates our daily lives, companies should began implementing mobile security plans to help mitigate the security vulnerabilities mobile devices bring. A good mobile security plan should start with an inventory: identify how many applications are used, who develops them, who has responsibility for oversight, monitoring, and testing. It should also define how often security is assessed at various phases of development and production.
Putting a plan in place is half the battle. A qualified team is also important as mobile development can be vastly different from web development and requires a different skillset/mindset. A specialist with experience in reverse engineering and data analysis can be invaluable to see what a potential hacker could do with available data.
Many open source tools are also available to help the mobile team with testing and development. Just a few include Frida and Radare (reverse engineering tools), Drozer (an Android security assessment tool), and mitmproxy (data in transit analysis). Researching some of these tools can assist the development team to become more secure in their development practices and gain access to the most updated industry practices in battling new mobile security concerns.
As the number of mobile applications available for business and personal consumption continues to grow, companies should be aware of the potential security risks affecting their private data and implement strong security measures specifically surrounding the mobile development life cycle and mobile app consumption to mitigate potential vulnerabilities.
For more information on security measures for your business’ information, contact Larson & Company today.
*Based on NowSecure, a mobile app security company, proprietary scoring system, the average security score for applications on both iOS and Android is between 70-80% (nowsecure.com).
