Analyzing practical communication security of Android vendor applications
Permanent address of the item is
The development of mobile devices and the new personalized services have gone to the point, where users do not alone control their data. While the devices are in constant communication with the cloud services the user’s data and the data of the user move ever more to the services providers’ cloud services. Little is known about how and how well service providers protect the users’ information. The work studies two biggest western Android based ecosystems, Google’s and Amazon’s, own applications’ practical security in the communication process. The aim is to identify all mechanisms used to protect the information that is communicated with the Android device. The study used one device from Amazon and Google, and the application market was chosen from both service providers for in-depth study. The applications were selected on the basis that they must provide same service in order to make the comparison possible. In practice, the applications and devices were studied by performing active and passive Man-in-the-middle (MITM) attacks in network laboratory. The communications were intercepted and analysed afterwards. Both vendors relied heavily on SSL/TLS protocol. Also in common was the usage, roles and acquirement of authorization tokens. Amazon’s client applications were noticed to use digital signatures. The biggest difference between the market applications was that Google required authentication when buying an application, while Amazon did not require it. During the same authentication Google sent user’s password in plaintext inside the TLS connection. During the less frequently happening registration of the user’s Google account to the device the user’s password is sent instead encrypted inside the TLS connection. An active MITM attack was performed on the Google device and account to demonstrate what the attacker can do in practice, when SSL/TLS connection is compromised. With manipulating traffic and intercepting authorization tokens the attacker is able to spy the victim and access to nearly all the victim’s Google data for the present. In addition, the attacker can “force” the victim to register herself again to the Android device and the attacker can use the victim’s intercepted encrypted password to add the victim’s Google account to her own device.