Insecurity of SMS One-Time Passwords in Modern Mobile Devices

Zain Khan The insecurity of SMS One Time Passwords against local attacks in modern mobile devices Based on a paper by Zeyu Lei, Yuhong Nan, Yanick Fratantonio, and Antonio Bianchi. (Lei et al.)

Motivation SMS one time passwords (SMS-OTPs) are used everyday Purposes include two-factor authentication (2FA) and changing of security settings SMS-OTPs reduce the burden on the end user of having to remember passwords for each app Used in many popular messaging apps such as Telegram

The problem with SMS-OTPs The SMS communication channel has been proven to be insecure on many occasions Examples include SIM-swapping attacks and local attacks (although literature focuses on local attacks) Many apps poorly implement generation and verifications of SMS-OTPs

A typical SMS-OTP scenario for 1FA

Malicious ways of accessing SMS-OTPs Deceiving users Assumptions Understanding user reactions to deception attacks Bypassing OS and market permissions Exploiting weaknesses in APIs Methods e.g. Retriever and Token Cryptographic weaknesses Inbox management

Design weaknesses in SMS-OTP systems Users do not have a reliable way to identify the identity of the app in which they are asked to copy an SMS OTP message The system interface asking for the permission to read SMS do not explain the severe security implications that this choice can have. Market-level policies are not verified for updated versions of an already published app. Market-level policies and OS-level policies are not aligned The usage of the SMS Retriever API is error prone. The usage of the SMS Token API (createAppSpecificSmsToken) for authentication purposes is unsafe due to its vulnerable design. The SMS Token+ API (createAppSpecificSmsTokenWithPackageInfo) documentation suggests using it in the same way of the SMS Token API, thus making its usage equally insecure. SMS OTP Messages are stored in the SMS inbox (making them readable by any app with proper permissions), even when obtained with APIs designed to deliver them only to a specific app. The SMS Retriever API does not respect security guidelines in terms of hashing strength. The market does not check for hashcode collisions.

SMS Retriever and Token how unsafe they are SMS Retriever is unsafe if app developers implement the backend logic of their apps in a different and vulnerable way Common! This is because computing the hashcode is unintuitive Developers commonly hard-code hashcode into their code UNSAFE SMS Token is unsafe as a API regardless of implementation Malicious apps can use the same mechanisms in the API to lure the victim app s backend to authenticate themselves No proper way of recognising the legitimacy of the token An attempt to refine SMS Token, SMS Token+ only adds in a existence of a custom prefix. However documentation suggests same way of use thus SMS Token+ is just as equally unsafe to use.

Case study #1 - KakaoTalk Popular messaging app in South Korea A malicious app was installed onto the victim s device The app invokes the SMS Retriever API method from the backend Attacker alters the KakaoTalk app behaviour and initiates a SMS- OTP session using the hashcode which meant messages can be seen by the attacker Attacker spoofs the OTP message thus gains access to the victim s account

Case Study #2 - Telegram One of the most popular instant messaging apps used worldwide Identified as vulnerable in a previous run of the same experiment in 2019 It used SMS Retriever and Token, where the use of Token has led to vulnerability as explained Many Telegram unofficial apps exist not as regular updates as the official app

Mitigation Strategies Ideal properties The OTP-carrying SMS should be automatically forwarded to the appropriate app The SMS should only be delivered to the proper app using an SMS Retriever- like method Appropriate documentation Use proper cryptographic methods An OTP-carrying SMS should never reach the SMS inbox The user should be able to see the received messages, so to prevent that the presence of this functionality in a device can be exploited to silently send text messages to a phone number, which could result in financial damage Easily usable by existing apps on existing mobile devices

Mitigation Strategies (cont.) A proposed API that works like the SMS Retriever API but has these improvements: SMS OTP messages using this API must start with a precise prefix (e.g., ). Messages starting with the specific prefix, under no circumstances, are delivered to the SMS inbox. Messages starting with the specific prefix can be visualized by the user using a dedicated system app. Messages are delivered to the app whose hashcode is contained in the message itself. The hashcode is computed as in the current SMS Retriever API, but its length is truncated to 38 base64 characters instead of 11 (ensuring 228 bits of entropy, as suggested by NIST guidelines).

Mitigation Strategies (cont.) The current documentation is updated to clearly state that, the backend server should not obtain the hashcode value from an app. Alternatively, in case supporting several legitimate client apps is needed, the server must verify that the hashcode sent by the app matches one of the legitimate apps hashcodes. Developers should be offered a tool to easily compute the hashcode of a given app (starting from its APK file). The hashcode should also be shown in standard development tools, such as Android Studio and the Developer Console on the Google Play Store.

Questions?