Page 18 - FIGI: Security audit of various DFS applications

authenticated, Thus they can be modified to car- test. For example, the detection of insecure cryp-
ry out malicious attacks. tographic operations does not necessarily imply that
The server response was tampered during test- sensitive information will not be encrypted in a safe
ing and user’s current balance showing on the manner. Another example is the fact that App1 does
app was modified� not encrypt the details of transactions (names and
amounts) that are transmitted through HTTPS. Since
3.3.6 M8: Code Tampering the application uses certificate pinning, there is a
limited chance that the information can be intercept-
√ T8.1 The app does not run on a rooted Android ed by an adversary.
device. Still, all the tests are related to best practices which
should be followed by financial applications. The
3.3.7 M9: Reverse Engineering results should thus be read as a standardized evalu-
ation of whether the applications are built according
√ T9.1 The app code has been obfuscated. to best practices. Whether an application is vulnera-
ble to a specific attack cannot be deduced from the
test results without additional investigation.

4 CONCLUSIONS 4�2 Comparing to the FIGI SIT DFS Security Assur-
ance Framework
The method excludes analysis the logic of the appli- The Security, Infrastructure and Trust working group
cations, as this would require reverse engineering of of the Financial Inclusion Global Initiative (FIGI) has
the application code. All three tested applications established a DFS security assurance framework .
13
make use of code obfuscation, which would make In its chapter 9 of the DFS security assurance frame-
reverse engineering particularly challenging. work report, a template of five categories of securi-
ty best practices are provided. The following table
4�1 Evaluating the results maps the 18 tests of the proposed method to the five
Since we do not analyse the logic of the applica- categories of best practices:
tions, it is difficult to estimate the impact of a failed

Best practice from DFS Assur- Corresponding tests
ance Framework
9.1 Device integrity T1.2 Android: debuggable
T1.4 Dangerous permissions
T8.1 The application should refuse to run on a rooted device
9.2 Communication Security and Certifi- T3.1 Application should only use HTTPS connections
cate Handling
T3.2 Application should detect Machine-in-the-Middle attacks with untrusted certificates
T3.3 Application should detect Machine-in-the-Middle attacks with trusted certificates
T3.4 App manifest should not allow clear text traffic
T5.1 The app should not use unsafe crypto primitives
T5.2 The HTTPS connections should be configured according to best practices
T5.3 The app should encrypt sensitive data that is sent over HTTPS
9.3 User authentication T4.1 Authentication required before accessing sensitive information
T4.2 The application should have an inactivity timeout
T4.3 If a fingerprint is added, authentication with fingerprints should be disabled
9.4 Secure Data Handling T1.1 Android: allowBackup
T1.3 Android: installLocation
T2.1 Android.permission.WRITE_EXTERNAL_STORAGE
T2.2 Disabling screenshots
9.5 Secure Application Development T9.1 The code of the app should be obfuscated

16 Security audit of various DFS applications