---------- Forwarded message ---------- From: coderman <coderman@gmail.com> Date: Fri, Aug 1, 2014 at 4:06 AM Subject: Preferred Roaming List Zero Intercept Attack [was: DEF CON nostalgia [before that: going double cryptome at DEF CON 22]][still confusing] To: Full Disclosure <fulldisclosure@seclists.org> Cc: Georgi Guninski <guninski@guninski.com> ### The Preferred Roaming List Zero Intercept Attack # SUMMARY # Attackers in position to carry out Monkey-in-the-Middle against CDMA2000 links between customer stations and their carrier BTS equipment can leverage silent push PRL updates to apply a routing list preferring paths through malicious "tower(s)" carrying the subscriber voice and data traffic under threat. The use of a specific PRL version Zero (0), aka Preferred Roaming List Zero Intercept Attack, implements the rogue tower associations with least potential interference to legit carrier bands and devices present in broadcast domain of attack. The presence of PRL version zero (0) on a device indicates malfunction at best and potential maliciousness when supported by other confirming factors. Note that malicious changes to the PRL may happen out of band (at baseband / control plane) regardless of disabled update facilities on the Android, iOS, or other device operating system. Polling must be used to detect silent forced PRL updates at the version level. # IMPACT # All common smart phones deployed on Verizon, Sprint, MetroPCS, US Cellular, and Telus carrier networks appear to support silent force push PRL with insufficient authorization. Any carrier phones or specific builds known to not accept PRL updates without authorization should be noted in response to this thread and the author with specific radio and carrier details. Software defined CDMA2000 implementations observed to date unaffected as manual tower associations are usually required in these systems. # RECOMMENDED MITIGATIONS # 1. Smart phone platforms and OEM distributions should refuse to silently downgrade or set to version zero (0) any PRL updates. Versions always increment, an offset sequence is a signal of something amiss and must require user confirmation to execute overrides. 2. Manufacturers should pressure baseband vendors for strong controls around PRL updates similar to controls around signed firmware updates and defense in depth like TrustZone enforced PRL management. In addition, preferred only bit set (use only preferred systems) should be the default, not the exception. 3. Privacy conscious consumers should communicate via software defined radio stacks rather than proprietary baseband black boxes. Full control over all channels, forward, reverse, supplementary and the content within them compelling transparency for radio comms. 4. Hackers at DEF CON should create apps to monitor for PRL zero status and securely report the results to a hidden site. Unauthorized PRL changes should then force radios off (airplane mode or cell radios down) and trigger counter measures. # BACKGROUND # On Thu, Jul 31, 2014 at 6:13 AM, Georgi Guninski <guninski@guninski.com> wrote:

... Fyodor's Full Disclosure is heavily moderated. He stops me at SMTP level. Quite likely he will sell the list the way aleph1 did with Bugtraq. (I am not posting on FFD).

asking for disclosure or utility seems not unreasonable. [0][1] far from a free for all these days, for sure, ... the rest of the rant after this regularly scheduled programming: [2] # VULNERABILITY ASPECTS # - Vulnerability Classes: Improper Access Control - Remotely Exploitable: Yes - Locally Exploitable: Yes; most devices - Authentication Required: No; only middle position # TECHNICAL DETAIL # Working knowledge of CDMA2000 network principles and protocols is assumed. Explicit PRL updates as may be invoked via dialing ##873283# on Sprint, *228 for Verizon - then opt. 2, or *228 on many other networks are user initiated and properly authorized. Over-the-Air system update facilities on carrier networks may also silently force push PRL updates to customers for better service, as intended, with incrementing versions. When used maliciously, OTA PRL updates with a version of zero (0) function well as in-scope target enabling, having the property that once a target leaves the broadcast area under attack the legitimate carrier update, no matter which real carrier or intervening time period, will always be great than zero, and thus replace the transient malicious roaming list with a legitimate copy of whatever is current. It is this specific aspect: silent force PRL downgrade to version zero (0) which is condemened. Any other aspects of securely communicating provider preferences to customer devices is left as a problem for the reader; CDMA designed to protect carrier base stations and networks, not subscribers from a rogue "carrier". Consider the following original roaming configuration for a device subject to this attack: | PRL Version: 1205 | Primary CDMA Channel: 500 | Secondary CDMA Channel: 425 | 0(SID+NID+AcqIdx+RoamInd): 0x000A+0xFF+1+OFF | 1(SID+NID+AcqIdx+RoamInd): 0x0012+0xFF+7+ON | 2(SID+NID+AcqIdx+RoamInd): 0x0015+0xFF+33+ON | n<=28(...): NULL The attacker desires least interruption to carrier SIDs ...0A, 12, 15, and associated frequencies. Attacker assumes operations on channels 650 and 725 with SID 0x00A1 to co-exist with incidental communications inside the broadcast domain under attack. With the new rogue station operating, a Preferred Roaming List Zero attack can now be mounted, routing targets over the malicious base stations as long as they remain in range of attacker. Such a roaming configuration may look like: | PRL Version: 0 | Primary CDMA Channel: 650 | Secondary CDMA Channel: 725 | 0(SID+NID+AcqIdx+RoamInd): 0x00A1+0xFF+1+OFF ** attacker SID | 1(SID+NID+AcqIdx+RoamInd): 0x000A+0xFF+2+OFF | 2(SID+NID+AcqIdx+RoamInd): 0x0012+0xFF+7+ON | 3(SID+NID+AcqIdx+RoamInd): 0x0015+0xFF+33+ON | n<=28(...): NULL One last note: It is useful to be alerting on scenarios where channel drops, and strong neighbor appears just outside SRCH_WIN_N with a hard hand-off. Investigation of the exchange in detail warranted, in addition to any control messages that followed. # DISCLOSURE PERSPECTIVE # - "State Level" attackers using since before 2008? [how long before?] - Observed "in the wild" 2011. - Paying Fyodor's FD Tithe to public at Fri Aug 1 10:58:20 UTC 2014, plus moderation delay. # ADDITIONAL INFORMATION # Will not be coming from this channel. This includes no press; sorry. Third parties encouraged to continue and disseminate additional inquiry, however! # SOLICITED INFORMATION FOR BENEFIT OF OTHERS # - Are R-UIM based devices affected by force PRL zero? - Can knob frobbing mitigate successfully on carrier devices without root'ing or jailbreak'ing? [PCS, WCDMA, other radio opts] - If you force closed loop power control with constrained codings, can you thwart the effectiveness of attackers using mobile or non-tower emitters? - Will Metasploit deploy GNU CDMA blocks for this and other attacks along with requisite faraday tents? # FOR WANT OF CITES # 0. <citation needed> - i remember Fyodor asking that inflamatory off-topics at least be combined with a disclosure of some technical merit, too. as a way to atone for wasting precious minutes squandered and never to return; alas i can't find the message on a cursory search. i don't have a problem with this policy (Vuln for Voice) but it does seem to raise a high bar! *grin* 1. "Meta: List moderation", "Request to mailing list Fulldisclosure rejected", etc. - http://seclists.org/fulldisclosure/2014/Jul/56 2. # RESUME RANT # - this is in reference to [3] which is actually the gist of my angst. public and named individuals, organizations, institutions overly risk averse. prosecutorial zeal into the absurd squelching independent research while proprietary malcode monopolies from intelligence community to private sector weaponizers fleece talent into un-disclosure prisons with mental inhibitors decades to the future. we're in a strange new future now, and i have no idea what role full disclosure has in it, if any. so, "Vuln for Voice": why not? .. it certainly keeps the signal higher and the n3td3v lower! # END RANT # 3. "DEF CON nostalgia [was: going double cryptome at DEF CON 22]" - https://cpunks.org/pipermail/cypherpunks/2014-July/005269.html ''' a hollow, decrepit shell of its former self.. ... oh the 0ld days, ;) "We'd appreciate some more ethics." - GOBBLES - https://www.youtube.com/watch?v=DAJSxOzrD1g [ GOBBLES Security - still disappointed in 2014 ... ] ---- regarding the current line up: https://defcon.org/html/defcon-22/dc-22-speakers.html "Detecting Bluetooth Surveillance Systems" - what about RFID? "Dropping Docs on Darknets: How People Got Caught" - see also, EPICFAIL "How to Disclose an Exploit Without Getting in Trouble" - if you thought ice cream had many flavors, welcome to the brave new world of 'responsible disclosure'! "NSA Playset: PCIe" - the lack of any VT-d mention makes for mediocre. TAO tools better include a VM breakout and uCode errata exploitation. (spoiler alert - i don't think this is actually dropping NSA exploits) "The Monkey in the Middle: A pentesters guide to playing in traffic" - this middle perspective, however, is absolutely a tailored favorite. a gift that keeps on giving... "Investigating PowerShell Attacks" - this is now pointless, what with pass the hash dead. IT'S ALL OVER, JUST GO HOME. *sobbing* [c.f. http://www.harmj0y.net/blog/penetesting/pass-the-hash-is-dead-long-live-pass... ] "Screw Becoming A Pentester - When I Grow Up I Want To Be A Bug Bounty Hunter!" - one step further to enlightenment. the industry that should not exist; better yet to become build engineer or test automationer or devops devotee and build security in at unsexy day jobs for not fame and not riches. #hashtagInfosuckprotipyolo "In the forest of knowledge with 1o57" - nothing to say here other than i'm selling 1o57's uber badge for bitcoin to highest bidder. come find me :P~ "RF Penetration Testing, Your Air Stinks" - my discriminator for a delicious sw defined deployment: a) new grc blocks or custom sdr pipeline? b) wideband and full duplex? c) opportunistic and ad-hoc capabilities? - if you answered no to any of the following please try again, with more harder! [c.f. http://www.pervices.com/buy-crimson/ dual 10GigE, 100kHz – 6GHz, <= 800MHz bandwidth, 4 x (16 bit, 370 MSPS ADCs), 2 x (quad channel, 16 bit, 2500 MSPS DAC), 10MHz, 10ppb, reference OCXO] P.P.S. if you want do your own training on "WB Quad System" without travel to FVEY facilities this is how ;) "Panel - Diversity in Information Security" - i was not invited to this panel. credibility lost. "Android Hacker Protection Level 0" - because more fingers in the dike is more fingers. "Blinding The Surveillance State" - i am soliciting donations for premium consulting expertise. i don't think Soghoian's free advice will be instrumental, but Cowboy Alexander has some sweet new shit (you get what you pay for? :) [ c.f. http://www.foreignpolicy.com/articles/2014/07/29/the_crypto_king_of_the_NSA_... "Summary of Attacks Against BIOS and Secure Boot" - aka, why to coreboot and kill AMT with fire. ok Intel chipsec peeps i got bones to pick SEE YOU IN VEGAS --- how about the talks you want so much but will never see? those billions for your discretion clearly benefiting profitability over pervasive security. best regards, '''