WIXLIB

Mobile network hacking – All-over-IP editionBlackHat EU, Dec 4 2019, LondonLuca Melette luca@srlabs.de Sina Yazdanmehr sina@srlabs.de SRLabs Template v12

Mobile networks are evolving, and research is hardly keeping upResearchquestionAfter severaldecades ofintercept attacks(A5/1, SS7, IMSIcatchers),will RCS finallyprotect textmessages?2

Agenda1. Mobile attack recap2. Attacks on new technologies3. Mitigations3

Known mobile network attacks can be categorized into 5 classesAttack impactAttack scopeAttack detailsInterceptIcalls and textsLocal Passively sniff and crack weak encryption (A5/1, A5/2), run IMSI catcherRemote Reroute voice flows enabling call forwarding via SS7ImpersonateIIuser identityLocal Grab TMSIs over-the-air, spoof originating call or SMS via radio interfaceRemote Send SMS or USSD code on behalf of another user via SS7Local Collect IMSIs from the radio interface, verify user presence with silent SMSRemote Globally locate mobile subscribers by requesting serving tower via SS7No charge Disable call barrings and prepaid data limits via SS7Charge others Spoof calls and SMS to premium numbers, steal bank OTP codes in SMSSubscriber Make users unreachable via detach message (radio) or cancel location (SS7)Network Exhaust MSC/HLR resources via SS7 requests (RESET, PRN, ATI, PSI)III Track usersIV Conduct fraudDoS users orVnetwork4

Only some parts of a telco networks have been publicly dissected by security researchersMobile GIMS, RCSCFemtocellPacket coreWiFiAccesspointSIMPSTNVoice coreePDGHLRIMS partiallycovered:most of ternetSeveral vulnerabilities havebeen identified in thesetelco components:A. Malicious applicationscan be remotelyinstalled in SIM cardsB. Weak radio encryptionallow call/SMS and datato be interceptedC. Devices in user handscan provide privilegedaccess to core nodesD. Hackers can remotelyintercept calls/SMS andtrack users because ofmissing authenticationE. Like point D, but fordata connections5

Legacy standards are being replaced by new technologies: IMS (VoLTE, VoWiFi) and RCSVoice calls are moving from dedicated channels to voice-over-IP (VoIP)Dedicated voicechannels(CSFB)Basic VoIP(IMS)Data4G/5GVoice3GDataVoice4G/5GVoIPRCS messaging is similar to WhatsApp, iMessageThe mobile uses legacy networks totransmit voice, the fast 4G link is onlyused for internet trafficIMS makes the fast LTE interface usablefor both internet and voice trafficRCS is supported by an increasing number of networksAdvanced VoIP(IMS RCS)6

RCS is already implemented by at least 100 mobile operators900mobileoperatorsLower-bound estimate for deployment status of‘next-generation’ mobile network technologies300 LTE200VoLTEIMS150VoWiFi100 RCS Functional RCSdeployments wereidentified through DNSand HTTP queries towardsRCS-related domains [1] European telco groupsconstitute a large part ofthe current RCSdeployments:- Orange (17 countries)- Vodafone (16 countries)- T-Mobile (9 countries)[1] config.rcs.mncYYY.mccXXX.pub.3gppnetwork.org, where XXX and YYY are valid MCC and MNC values7

Active RCS deployments span 67 countries, while a few others are conducting trialsAt least one networkimplements RCSRCS in trial8

Agenda1. Mobile network attack recap2. Attacks on new technologies3. Mitigations9

What attacks are possible in RCS?Example hacking goalTrack usersExample method using RCSA Get IP address of victim / verify if user is onlineImpersonate usersB Caller-ID spoofing in calls / messagesConduct fraudCWebsite DDoSD Send file attachment forcing auto-preview on victimIntercept textsAttack scopeInject traffic / hijack session if victim is behind the same NATE Connect to RCS with user credentials or hijack user sessionThese hacks shouldwork against manyRCS deployments asthey do not requiresecret informationabout the victim;they do rely onconfiguration issuesin the networkRequires victim’sconfig file or DNSMITM capabilities10

A User presence and coarse location can be disclosed by replies to SIP OPTIONS requestsOnce connected to RCS, a malicious user can collectinformation about other users by sending theSIP OPTIONS request to sequential mobile numbersIn addition to presence, the response messagediscloses the local IP of the victim, potentiallyrevealing its locationMobile operator ASIP OPTIONS 4917xxx0011SIP OPTIONS 4917xxx0022AttackerSIP reply: user not foundSIP OPTIONS 4917xxx003SIP reply: user availableIMSRCS3001SIP/2.0 200 OKCSeq: 1 OPTIONSContact: sip: 49xxx01@111.22.33.44:5060;transport tls Mobile operator BThanks to number portability and commercialagreements between operators, users in othernetworks can be also paged and later attackedIMSRCSSIP reply: user available00311

B Missing verification of user supplied heat SBC allows caller-ID spoofingAttacker registers with1 their own identityBobIMSRCSBob receives a callfrom Alice’sspoofed identityAttacker2AliceThen spoofs another user’sidentity to make a call1 SIP REGISTER2 SIP INVITEREGISTER sip:mno.net SIP/2.0From: sip: 4917.@mno.net ;tag 291412310To: sip: 4917.@mno.net .INVITE sip:bob@mno.net;phone-context mno.net SIP/2.0To: sip:bob@mno.net;phone-context mno.net From: sip:1337@mno.net ;tag 291412310P-Preferred-Identity: sip:1337@mno.net .12

C Traffic injection is possible if victim and attacker share the same public IP address1aAttackscenario 1The attackerand victimare behindthe sameNATUser and attacker connect behind thesame NAT and share an external IPUserPCSCF1VPNInternetAttackerAttackscenario 2The attackermanipulatesuser trafficusing arogue AP-Demo-WiFiNATRCS coreUserIPPCSCFuser-1[Ext IP]pcscf 2PCSCF2XUserAttacker1b Attacker controls Internet uplink of victimAttacker identifies2 the correct PCSCFby trying all optionsIn some implementations,attackers can injectmessages into the RCS core3because users are solelyidentified by their mobilenumber and public IP13

D Automatic media preview of malicious links enables DDoS and sensitive info leaksRCS can send media contentThe Message Session Relay Protocol isused to share files (images, videos,audio) between RCS users. This protocolis similar to SIP and HTTP, and carriescontent metadata in XML format.FiletransferserverBobAlice3- SIP/MSRP message including media transferScenario 1 - Leverage RCS clients to DDoS a websiteScenario 2 - User trackingScenario 3 - Account takeover1. Attacker identifies a large file on a target website1. The attacker starts a webserver on a public IP1. The attacker conducts theattack as in scenario 2, andcollects headers sent bythe victim2. Attacker crafts an XML message where the thumbnail URL(indicated as a small file) points to target large file3. Attacker sends the crafted XML message as a SIP/MSRPmessage to many thousands of subscribers4. Each RCS client automatically attempts to download the fileoverloading the target website2. The attacker sends an RCSmessage includingpreview-able contentshosted on that server3. The victim attempts todownload the contentdisclosing their IP address2. If an RCS session token isincluded, the attacker canimpersonate the victimsending messages andstarting calls14

E Intercept can be achieved abusing RCS signaling in multiple waysAttack scenario 1Set callforwardingsabusing the XCAPinterfaceImplementation issues (vendor dependent)We found some buggy XCAP implementation that does not properly validate theidentity when interacting with the server, thus enabling XCAP settings manipulationConfiguration issues (network dependent)If the XCAP server uses password authentication instead of the secure SIM-basedauthentication, the password could be brute-forcedAttack scenario 21Malicious appsSteal the configfile so you canprovision onbehalf of thevictim2Mobile hotspot sharing3Malicious open WiFi with captive portal4Brute force identity/OTP via web5Redirect SIP traffic to a rogue P-CSCFAttack scenario 3SIP MITM via DNSspoofingDetails in the next slides15

E1 2Malicious app or rogue hotspot can get in the middle of RCS provisioningUser1 HTTP request including user’s IMSI2aServer respondswith 200 OKHTTP status code,and includes avalid session IDas cookie in casethe IMSI is validSMSCConfig server2b HTTP reply with session ID as cookieConfig server generates an OTPand delivers it to the user via SMSBinary SMS carrying the OTPTLS connection3HTTPS request including IMSI,OTP and session ID4 XML config fileServer returns the XML config file ifall received information is correctAttack scenario 1 Malicious appAttack scenario 2 Mobile hotspot sharing The app is installed on victim’s device The app uses victim’s LTE connection to fetch config file If the app has SMS READ permission, it can retrieveeven OTP code, for networks that require it Attacker uses victim’s LTE connection viahotspot sharing Attacker can request config file throughvictim’s connection, and retrieve it16

E 3 Rogue WiFi can steal victim’s config file injecting JavaScript codeAttack sequenceRCS configserver3LTEInternetUser412Rogue APAttacker’sserver1 Victim tries to access a website1.through a rogue AP2 The rogue AP retrieves the content of2.the website requested by the victimand forwards it back injectingmalicious JavaScript. Immediately after,the AP pushes back the victim to LTE,terminating the WiFi access3 The malicious JavaScript code retrieves3.the RCS config file via LTE connection4 The malicious JavaScript code uploads4.the retrieved XML config file to theattacker’s server on the internet-Demo17

E 4 Some networks requiring OTP verification are prone to user account brute forceValid IMSIs found1. Enumerate valid IMSIsEnumerate IMSIs.Perform GET over1 HTTP supplying arandom IMSI untila 200 is returnedGet cookie (invalid IMSI)HTTP 40XGet cookie (valid IMSI)AttackerHTTP 200 CookieRCS autoconfig serverCorrect OTP foundBrute force OTP.Quickly performGET over HTTPS2trying all possibleOTP values (up to6 digits)1. Enumerate valid IMSIsGet config (IMSI, cookie, OTP1)HTTP 40XGet config (IMSI, cookie, OTP2)AttackerHTTP 200 XML configRCS autoconfig server18

E11-4Intercept first step: Login using victim’s RCS account, activate SMS-over-IP in HSSSteal victim’s RCS config file (using any of the 4methods described in the previous 2345678YesYes2 User attaches to the LTE networkAttacker registers to the RCS, announcing the3 SMS over IP capability in the SIP bilitiesConnection12345678[ g.3gpp.smsip]tcp:1.1.1.1:5060Attacker19

E1-4Intercept second step: Wait for SMS deliveryAs SMS-over-IP is activated,4 the HLR returns the GT ofthe IP-SM-GW for MSenderwants toauthenticateuserthrough OTPSMSCforwardSMThe IP-SM-GW forwardsthe message first via IP.5 If the delivery fails, themessage is delivered asSMS-using-CS fallbackOTP is sent as second factor;6 Both the victim and the attackerreceive the OTP SMSIP-SMGWMSCMMEeNBUser-Demo20

E 5 Local DNS spoofing enables MITM attacks against default Android RCS implementationThe lack of strict domain matching between initial RCS config parameters and actualTLS certificates allows hackers to fully hijack RCS sessions with any valid SSL certificateAttack sequence1.1 Victim’s RCS client tries to resolve theIP address of the P-CSCF2.2 The rogue AP replies with a fakeresponse that points to a fake P-CSCFcontrolled by the attacker3.3 Victim’s RCS client successfullyestablishes a TLS connection with thefake P-CSCF (valid certificate)4.4 The fake P-CSCF transparently forwardsall RCS traffic between the victim userand the legitimate P-CSCFVictimRogue WiFiaccess pointAttacker uses a valid certfor pcscf.attacker.ioFakeP-CSCFLegitimateP-CSCF1 DNS: SRV pcscf.operator.com?2 DNS: 5060, pcscf.attacker.io3a TLS hello3b TLS hello (valid cert)Trusted TLS connection to the attacker4 SIP REGISTERTLS connectionto legitimateP-CSCF-Demo21

Agenda1. Mobile network attack recap2. Attacks on new technologies3. Mitigations22