Classification

Overview

Use of reflection: it is possible to execute arbitrary malicious code or use undocumented methods which would be rejected at the Apple Review if used explicitly.

The method that implements reflection takes data from an untrusted source as an argument. This allows an attacker to control the application control flow graph, as well as to bypass authentication mechanisms and access restrictions.

The situation becomes especially dangerous if, in addition to the described vulnerability, an attacker can upload files into a directory that is present in the application’s classpath or edit the classpath. In this case, he/she can add arbitrary malicious code to the application and execute it. Thus the attacker can use reflection to introduce new, malicious behavior into the application.

• An attacker might be able to execute code that is not directly accessible to him/her. Alternately, the attacker could call unexpected code in the wrong place or the wrong time, possibly modifying the critical system state.
• An attacker might be able to use reflection to call the wrong code, possibly with unexpected arguments that violate the API. This could cause the application to exit or hang.
• By causing the wrong code to be invoked, he/she might be able to trigger a runtime error that leaks sensitive information in the error message.

Code Tampering vulnerabilities take the eighth place in the “OWASP Top 10 2016” mobile application vulnerabilities ranking.

References

1. OWASP Mobile Top 10 2014-M7
2. CWE-470: Use of Externally-Controlled Input to Select Classes or Code (‘Unsafe Reflection’)
3. OWASP Mobile Top 10 2016-M8-Code Tampering