WIXLIB

User Smartphonewith Mobile AppShared Root Key(Pre-stored inthe SIM Card)MNO CoreNetwork SystemApp ServerShared Root KeyAKA ProcedureSMC ProcedureTempEquipment IDSecure Connection EstablishedApp-Specific Data① Temp Equipment ID,PhoneNum Token Generation AppID, PhoneNum,Token ②TokenTokenAuth Result③④ TokenPhoneNum ⑤⑥Fig. 2: Key design of the OTAuth Scheme.developers to pay less fee for user authentication [4], [15],[16], which provides a strong motivation for developers tointegrate this service.Key design. The most unique part in this OTAuth schemeis that the local phone number is obtained neither throughuser input nor by requiring any system permissions (i.e.,READ PHONE STATE or READ PHONE NUMBERS). Instead, the local phone number here is obtained based onthe MNO’s capability of recognizing phone number. Theonly requirement for this OTAuth scheme is (1) the app hasintroduced MNO’s service, and (2) the smartphone has accessto the cellular network.Figure 2 presents the high-level design of OTAuth services.Before the OTAuth procedure actually starts, the user’s smartphone needs to interact with the MNO Core Network Systemto perform the Key Agreement procedure (AKA procedure)and the Security Mode Control procedure (SMC procedure) forauthentication. The instances of such procedures may vary indifferent networks [17]–[19]. After this, the user’s smartphoneand the MNO Core Network System have established a secureconnection based on a shared root key [20].The OTAuth procedure begins right after the secure connection is established. First, the app on user’s smartphonesends app-specific data to the MNO server through cellularnetwork. Since MNO has the capability of recognizing phonenumber, the MNO’s server can generate a token that isassociated with this phone number, and transfer it back to theuser’s smartphone. Then, to perform authentication, the user’ssmartphone needs to send this token to the app server. The appserver will forward this token to the MNO server in order toget the phone number related with this token. In this way, theapp server can know the phone number of user’s smartphone,and decide whether to allow its login or sign-up request.B. OTAuth Scheme DetailsFigure 3 shows the protocol flow of the OTAuth schemestep-by-step. The whole process can be divided into threephases:(1) Initialize. In this phase, the app first detects whether theruntime environment supports OTAuth. If this statement istrue, it then tries to obtain the masked local phone number(not the full local phone number), in order to display it on theuser interface (see Figure 1).Specifically, the user starts the OTAuth flow by tapping onthe login (or sign-up) button (step 1.1), which actually sends anOTAuth request to the app. After receiving the user’s request,the app calls a specific API of the MNO SDK (e.g, the APIloginAuth in the SDK of China Mobile), together with appIdand appKey as the parameters (step 1.2). Here, both appId andappKey are exclusive to a specific app, which is pre-assigned toAppServerSmartphoneUserAppMNOServerMNO SDK1.1 Request login/signup1.2 Ask for initializationappId, appKeyInitialize1.5 Ask for authorizationInterface with masked phoneNum2.1 Give authorizationRequesttokenObtainphonenumber2.4 Responsetoken1.3 Request Masked PhoneNumappId, appKey, appPkgSig1.4 Responsemasked phoneNum, operatorType2.2 Request TokenappId, appKey, appPkgSig2.3 Responsetoken3.1 Ask for login/signuptoken3.4 Responseapproval/rejection to login/signup3.2 Ask for PhoneNumappId, token3.3 ResponsephoneNumFig. 3: The protocol flow of OTAuth based on MNO’s SDK.

TABLE I: Cellular network based mobile OTAuth services worldwide (ranked by MNO’s total number of subscriptions)Product / Service Number Identification [21]unPassword Identification [22]Number Identification [23]Operator Attribute Service [24]Mobile Connect [25]Mobile Connect [1]ZenKey [26]Fast Login [27]Mobile Connect [28]MNOChina MobileChina TelecomChina UnicomVodafone, O2, ThreeAmérica MóvilTelefónica SpainAT&T, T-Mobile, VerizonTurkcellMobilinkCountry / RegionMainland ChinaMainland ChinaMainland ChinaUKMexicoSpainAmericaTurkeyPakistanPASS [29], [30]SKT, KT, LG UplusSouth KoreaT-Authorization [31]SKTSouth KoreaIpification-HK [32]Ipification-Cambodia [33]3 Hong KongMetfoneHongkong ChinaCambodiaBusiness ScenarioLogin, RegistrationLogin, RegistrationLogin, RegistrationIdentity verificationLogin, RegistrationLogin, RegistrationLogin, RegistrationLoginLogin, RegistrationPaymentIdentity verificationLogin, RegistrationMoney transfer / Payment verificationLogin, RegistrationLogin, Registration This table demonstrates the prevalence of mobile OTAuth services worldwide but does not imply all of them are vulnerable. In our research, we onlyconfirmed the first three services [21]–[23] in mainland China are vulnerable for the SIM ULATION attack. As of Mar 2022, we have got confirmationfrom the ZenKey experts, who told us that ZenKey for AT&T is not subject to this vulnerability as its authentication flow is different.app developers by the MNO SDK vendor. The MNO SDK thencollects the fingerprint of the signing certificate [34] inside itshosted app (i.e., appPkgSig), through the API getPackageInfoand sends it to the MNO server, together with the appId andappKey (step 1.3).Since MNO has the capability of recognizing phone number,the MNO server already knows the phone number (i.e., phoneNum) after receiving the request data. Thus, after confirmingthat the appId, appKey and appPkgSig are legitimate, the MNOserver returns the user’s masked phoneNum to the MNO SDK,together with the operatorType (e.g., CM for China Mobile,CU for China Unicom, CT for China Telecom) to facilitatethe app’s display (step 1.4). Lastly, the MNO SDK pulls upan interface (like the ones shown in Figure 1) and asks foruser’s authorization (step 1.5). Here, the authorization refersto whether the user allows the app to obtain the phoneNum.(2) Request token. In this phase, the app client obtainsa token, which is associated with the appId, appKey andthe phoneNum. With this token, the app server can learnthe phoneNum in the next phase. If the user approves theobtainment of local phone number (step 2.1), MNO’s SDKwill send the appId, appKey and appPkgSig to the MNO serverthrough cellular network again, in request for the token (step2.2). After the appId, appKey and appPkgSig get verified, theMNO server will generate a token and send it back in response(step 2.3 and 2.4).(3) Obtain phone number. In this phase, the app server willobtain the user’s phoneNum and decide whether to approvethe user’s login or sign-up request based on this. First, theapp client will send the token to the app server in requestfor login or sign-up (step 3.1). After receiving the token,the app server will send it to MNO server in exchangefor the phoneNum (step 3.2). After confirming that the appserver’s IP is legitimate (i.e., has been filed) and that the tokenand appId are corresponding, the MNO server will respondthe phoneNum to the app server (step 3.3). Based on thephoneNum, the app server can decide whether to approve orreject the app client’s request (step 3.4).C. OTAuth Ecosystem in Mobile AppsGiven the huge convenience of OTAuth schemes, manypopular mobile apps have fully integrated this service. Someof them even set OTAuth login as the default login option.Based on a recent report from China Mobile (the largest MNOin China) [35], as of October 2021, its OTAuth service hasbeen called more than 1.69 trillion times.There are two ways for an app to introduce MNO’s service.The app can either integrate the SDK developed by MNO,or integrate a third-party SDK that includes functions of allMNOs’ SDKs. In mainland China, there are three MNOs:China Mobile, China Unicom, and China Telecom. Note thatSDKs of all the three MNOs support authenticating through anarbitrary operator. For example, an app could utilize the SDKdeveloped by China Mobile to seamlessly supports OTAuthservices of the other two MNOs (e.g., China Unicom) as well.Other than the official SDKs made by MNOs, there arevarious third-party SDKs that support OTAuth as well. TheseSDKs typically integrate MNO’s SDKs and provide easierto-use APIs for app developers to integrate. Such SDKs alsoinclude other authentication functions as a syndicator, such asauthentication based on SMS One-Time-Password.D. Scope of Our StudyIn this paper, we focus on the OTAuth scheme. Particularly,as instances of this authentication scheme, our research lookedinto the OTAuth services provided by all the three MNOs inmainland China. Table I presents a list of OTAuth serviceswe have found in different countries and regions. While thereare similar OTAuth services in other countries and regions,they are not included in this study, due to the followingreasons. Firstly, due to locality constrain, it is difficult for us toobtain the real SIM cards and perform the testing for OTAuthservices in other regions. Secondly, unlike the OTAuth servicesdeployed in mainland China, the OTAuth services provided insome other countries have not yet been widely deployed byapp developers [3]. We envisioned our analysis and findingscould bring insights for securing similar OTAuth services in

other countries and regions. For example, our preliminaryinvestigation showed that the Fast Login [27] developed byTurkcell (the largest MNO in Turkey) is similar to the OTAuthschemes of three MNOs in mainland China.In addition, previous works [36] have discussed relatedissues under quite different assumptions (e.g., assuming theattacker has physical access to the victim’s SIM card andcan perform side-channel power analysis) and these problemsdo not belong to the scope of the SIM ULATION attack weproposed.III. E XPLOITING OTAUTH S CHEMESIn this section, we show how to perform a SIM ULATIONattack by exploiting a critical design flaw in such OTAuthschemes. We first illustrate our attack model. Then, we presentthe core idea of the attack as well as its implementation details.A. Attack ModelWe assume the adversary can perform the attack undereither of the following two scenarios (shown in Figure 5).In the first scenario, we assume the attacker can install aninnocent looking malicious app to the victim device. Here, themalicious app does not need to require any sensitive permissions other than the INTERNET permission. Note that sincethe INTERNET permission is widely used by a large portionof normal apps for app-server communication nowadays, thispermission can be easily obtained from the victim user. Thisassumption is aligned with many previous works that performattacks on mobile platforms [7], [8]. In the second scenario, weassume the attacker is within the same network as the victim’sdevice. This typically happens when the adversary connectsto the hotspot shared by the victim’s device. We consider thisscenario is more likely to happen in an attack that targets aspecific individual. For example, the adversary is a colleagueof the target victim in the same company, and the adversaryaims at logging in to the victim’s account and stealing sensitiveinformation.The key point here for the above two scenarios is that weassume the adversary can perform her actions under the samecellular network IP address as the victim, for communicatingwith the MNO server (see section III-D for more details).In the meantime, we assume that the victim is under thelegitimate usage scenario of OTAuth provided by MNOs.Specifically, there is a SIM card on the victim’s smartphoneand the Mobile Data switch has been turned on. Note thatsince the OTAuth scheme only takes the cellar network as theauthentication channel, our attack can succeed regardless ofwhether the victim phone’s WLAN switch has been turnedon.B. Attack OverviewOur research identified that, due to a fundamental designflaw in the OTAuth scheme, the MNO server cannot effectivelyvalidate whether the authentication request is sent from alegitimate client or a malicious one. Therefore, under certainscenarios, an attacker can easily obtain the authenticationtoken that is associated with the victim’s phone number. Withthis token, the attacker can log in to the victim’s account onthe attacker’s own smartphone.Root cause. The root cause of the flaw is the app’s incapability of securely using mobile device identity. The operatingsystem does not participate in the design architecture ofOTAuth. Such a flawed design makes the MNO server unableto distinguish different apps on the same device, which makesthe SIM ULATION attack possible.As mentioned earlier in Section II-B, the MNO serververifies the app client via three factors, namely, the appId,appKey and appPkgSig. Unfortunately, all such informationare not confidential and can be easily obtained by an attacker.From the MNO server’s perspective, there is no way toeffectively identify whether the one requesting token is indeeda legitimate one. More specifically, if the attacker makes theauthentication request under the same network environment(i.e., via a malicious app on the victim device, or connectingto the victim’s hotspot), the MNO server will always returnthe valid token since the authentication factors it received areindeed correct.Impacts. Exploiting this design flaw, the attacker can bypassthe app’s authentication and log in to the victim’s account.In other words, the attacker can remotely log in to thevictim’s account through an app client (on her own device)and continue to perform malicious actions. When the victim’sphone number is not bound to any account, the attacker canregister new accounts on behalf of the victim. In addition, theattacker can also easily obtain the victim’s phone number (e.g.,log in a specific app that displays the phone number on theapp’s user-profile page).C. Attack DetailsWe divide the whole attack process into three phases, as described in Figure 4. Here, the appId, appKey and appP kgSigare specific to the affected victim app; phoneN umA andphoneN umV refer to the attacker’s local phone number andthe victim’s local phone number, respectively; tokenA andtokenV refer to the valid token distributed to the attacker andthe victim by the MNO server, respectively.(1) Token stealing phase. In this phase, the attacker launchesthe malicious app to obtain a tokenV . Specifically, the attacker“simulates” the behavior of the MNO SDK and sends theappId, appKey, and appP kgSig to the MNO server (step1.1 and 1.3). As mentioned earlier, these three pieces of dataare not confidential and can be obtained through various waysin advance. For example, many app developers hard-code theappId and appKey in the source code of their distributedapps, which can be trivially recovered via reverse engineering.The appP kgSig can be obtained by Keytool [37] when theapp (i.e., the APK file) is given. In addition, the attacker canalso intercept the network traffic of the legitimate OTAuthscheme (e.g., on her own device) and obtain these information.(2) Legitimate initialization phase. In this phase, the attackerperforms the normal OTAuth process of the victim app on herown smartphone (step 2.1 to 2.7). This is because the attacker

im AppVictim AppServerMalicious App1.1 Request Masked PhoneNumappId, appKey, appPkgSig1.2 Responsemasked phoneNumV1.3 Request TokenappId, appKey, appPkgSig1.4 ResponsetokenVTokenStealingPhase1.5 Send TokentokenV2.1 Request login/signupLegitimateInitializationPhase2.2 Request Masked PhoneNumappId, appKey, appPkgSig2.3 Responsemasked phoneNumA2.4 Ask for authorizationInterface with masked phoneNumA2.5 Give authorization2.6 Request TokenappId, appKey, appPkgSig2.7 ResponsetokenA3.1 Ask for 2 Ask for login/signuptokenV3.3 Ask for PhoneNumtokenV3.4 ResponsephoneNumV3.5 Responseapproval to login/signup with phoneNumVFig. 4: The attack model against OTAuth scheme.needs to launch a legitimate app client to communicate withthe victim app’s back-end server for her (future) unauthorized login. Note that, since the operations in this stage areperformed entirely on the attacker’s smartphone, the attackerhas complete control over the entire process. Therefore, theattacker has the ability to initialize the authentication, and inthe meantime, prevent the app client from sending tokenAto the app’s back-end server. More specifically, the attackercan use the hooking technique [38] to intercept and block thelegitimate authentication process. The tokenA will be furtherreplaced by tokenV for the upcoming authentication scheme.(3) Token replacement phase. In this phase, the attackerbypasses the authentication of the app’s backend server by replacing the tokenA with the previously obtained tokenV (step3.1 and 3.2). Since the tokenV is a valid token associated withthe appId (exclusive to victim app) and the phoneN umV , theapp’s back-end server will get the phoneN umV when it triesto exchange the received tokenV for a phone number (step3.3 and 3.4). In this case, the app’s backend server mistakenlyApp MaliciousVictimVictim'sAppApp Attacker'stokenVSmartphoneSmartphone3(a) Attack via a malicious app.treats the attacker as the holder of the phoneN umV andapproves the login (sign-up) request on the attacker’s device.D. Attack ImplementationAttack via a malicious app. The overall process of thistype of attack is shown in Figure 5(a). In this attack, with theinstalled malicious app, the attacker can obtain the victim’stoken by sending app-specific data through the victim’s mobilenetwork. As an instance of this attack, we take Alipay [39], oneof the most popular payment app that has more than 1.2 billionusers worldwide [40], as the target app for exploitation. We implemented the malicious app and hard-coded the appId,appKeyand appPkgSig of Alipay in it. We uploaded the malicious appto VirusTotal [41] on August 12 in 2021 and VirusTotal reportedthat “No security vendors flagged this file as malicious”.To perform the attack, we installed the malicious app on anon-rooted Redmi K30 Ultra phone (as the victim’s device)with Android 10 OS. The app installation process does nottrigger any security alert by the system. The entire tokenApp Server Victim'sSmartphoneMNO Server2tokenV5tokenVappIdappKeyappPkgSig6Victim AppAttacker'sappId, appKey, appPkgSig1Smartphone4tokenVMalicious AppVictim's hotspot(b) Attack by connecting to victim’s hotspot.Fig. 5: Two attack scenarios against OTAuth scheme implemented by our research.

IV. L ARGE - SCALE MEASUREMENT STUDYTo better understand how real-world apps are affected by theissues identified above, we perform a large-scale measurementover a set of popular Android and iOS apps. Our resultsshow a large portion of highly popular apps confirmed to bevulnerable due to the integration of such OTAuth Scheme.A. DatasetOur final dataset includes a total number of 1,025 Androidapps and 894 iOS apps. These apps were downloaded between July 19, 2021 and November 20, 2021. As most appstores explicitly prohibit any form of automated app infocollection [43] [44], we referred to Qimai Data [45], a thirdparty mobile app data analysis platform to help label the mostpopular apps.Android app set. To build the Android app set, we firstidentified an app list containing 15,668 apps based on the17 unique app categories provided by Huawei App Store [46](i.e., top 1,000 apps for each category). Further, based on thedownload statistics collected from Qimai Data, we selectedall those apps with more than 100 million downloads. Notethat users in mainland China rarely use Google Play as theirsource for app downloading, and Huawei App Store is one ofthe most popular markets instead. As a result, apps collectedfrom this source can represent well the prevalence of OTAuthSDK usage in Chinese markets. We consider such a dataset cansufficiently cover a wide range of highly popular app acrossdifferent ca

about One-Tap Authentication scheme, including its overview, the protocol design, as well as the ecosystem of its usage in mobile apps. A. One-Tap Authentication (OTAuth) Scheme One-Tap Authentication is essentially a third-party-based authentication scheme supported by Mobile Network Oper-ators, similar to other login options such as Single-Sign-