Page 18 - FIGI: Security audit of various DFS applications
P. 18

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
   13   14   15   16   17   18   19   20   21   22