Message-ID: <CAJVRA1Qq1w07ap0BXVW1vv=+PifQ4ddD4E2ST98Ue69B_+kWSQ@mail.gmail.com>
Date: Fri, 1 Aug 2014 04:06:59 -0700
From: coderman <coderman@...il.com>
To: Full Disclosure <fulldisclosure@...lists.org>
Cc: Georgi Guninski <guninski@...inski.com>
Subject: [FD] Preferred Roaming List Zero Intercept Attack [was: DEF CON
 nostalgia [before that: going double cryptome at DEF CON 22]][still
 confusing]

### 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@...inski.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-the-hash/
]

"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_goes_corporate_keith_alexander_patents

"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,
'''

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists