LTE security and protocol exploits

advertisement
LTE security and protocol exploits
Roger Piqueras Jover
Wireless Security Research Scientist – Security Architecture – Bloomberg LP
ShmooCon – January 2016
About me
•
Wireless Security Researcher (aka Security Architect) at Bloomberg LP
http://www.bloomberg.com/company/announcements/mobile-security-a-conversation-with-roger-piqueras-jover/
–
•
Formerly (5 years) Principal Member of Technical Staff at AT&T Security Research
http://src.att.com/projects/index.html
–
•
Mobile/wireless network security research
LTE security and protocol exploits
– Advanced radio jamming
– Control plane signaling scalability in mobile networks
– 5G mobile networks and new mobile core architectures
–
•
If it communicates wirelessly, I am interested in its security
Bluetooth and BLE
– 802.11
– Zigbee, Zigwave
– LoRa, SIgFox…
–
•
More details
–
2
http://www.ee.columbia.edu/~roger/ - @rgoestotheshows
Mobile network security
•
Often thought at the “app” layer
Certificates
– Encryption
– SSL
– Recent examples
–
•
•
•
•
iOS SSL bug
Android malware
XcodeGhost iOS infected apps
Long etc
•
My areas of interest
PHY layer
– “Layer 2” protocols (RRC, NAS, etc)
– Circuit-switched mobile core architecture for
packet-switched traffic  No bueno!
– Recent examples
–
•
•
•
•
3
LTE jamming
Low-cost LTE IMSI catchers and protocol exploits
IM app causes huge mobile operators outage
Mobile operators trouble with “signaling storms”
Mobile network security
The first mobile networks were not designed with a strong security focus (no support for encryption in 1G!!!)
“Old” encryption
Device
authentication
Strong encryption
Mutual
authentication
Stronger encryption
Mutual
authentication
Basic security principles
•
•
•
4
Confidentiality
Authentication
Availability
Protecting user data
Mobile connectivity availability
against security threats
LTE basics…
5
LTE mobile network architecture
6
Decode PSS and SSS to synchronize in
time and frequency.
LTE Cell Selection and Connection
Decode PBCH
RACH
Obtain
System
Configuration
Random
Access
•
–
Power up
Idle
Radio Access
Bearer + (Attach)
Connected
System configuration
–
8
Cell Search
Procedure
Decode Master Information Block (MIB) from PBCH
Decode System Information Blocks (SIBs) from PDSCH
User traffic
LTE frame
9
LTE NAS Attach procedure
10
Mobile network user/device identifiers
IMEI – “Serial number” of the device
IMSI – secret id of the SIM that should never be disclosed
TMSI – temporary id used by the network once it knows who you are
MSISDN – Your phone number.
XYZ-867-5309
11
LTE security and protocol exploits…
13
LTE security and protocol exploits
•
•
•
•
•
•
14
Sniffing base station and network configuration broadcast messages
LTE security
LTE IMSI catchers
Mapping of {phone number, TMSI, IMSI}
Bricking/blocking devices and SIMs
LTE location leaks and tracking target devices
Sniffing base station configuration
Time: 00:02:10.087204 Frame: 93
Subframe: 0
BCCH-BCH-Message
message
dl-Bandwidth: n50
phich-Config
phich-Duration: normal
phich-Resource: one
systemFrameNumber: {8
bits|0x17}
spare: {10 bits|0x0000|Right
Aligned}
LTE PBCH MIB packet
15
Sniffing base station configuration
Time: 00:02:10.102204 Frame: 94 Subframe: 5
BCCH-DL-SCH-Message
message
c1
systemInformationBlockType1
cellAccessRelatedInfo
plmn-IdentityList
PLMN-IdentityInfo
plmn-Identity
mcc
MCC-MNC-Digit: 3
MCC-MNC-Digit: 1
MCC-MNC-Digit: 0
mnc
MCC-MNC-Digit: 4
MCC-MNC-Digit: 1
MCC-MNC-Digit: 0
cellReservedForOperatorUse: reserved
trackingAreaCode: {16 bits|0x2713}
cellIdentity: {28 bits|0x0075400F|Right Aligned}
cellBarred: notBarred
intraFreqReselection: allowed
csg-Indication: false
cellSelectionInfo
q-RxLevMin: -60
freqBandIndicator: 17
schedulingInfoList
SchedulingInfo
si-Periodicity: rf8
sib-MappingInfo
SIB-Type: sibType3
si-WindowLength: ms10
systemInfoValueTag: 11
Padding
Mobile operator
RX power to select
that cell
16
Cell ID
Sniffing base station configuration
RACH config
Paging config
Etc…RRC timers
User traffic
config
17
LTE PDSCH SIB2/3 packet
Sniffing base station configuration
•
MIB/SIB messages are necessary for the operation of the network
–
–
•
Things an attacker can learn from MIB and SIB messages
–
–
–
–
–
–
–
18
Some things must be sent in the clear (i.e. a device connecting for the first time)
But perhaps not everything
Optimal tx power for a rogue base station (no need to set up your USRP to its max tx power)
High priority frequencies to force priority cell reselection
Mobile operator who owns that tower
Tracking Area of the legitimate cell (use a different one in your rogue eNodeB to force TAU update messages)
Mapping of signaling channels
Paging channel mapping and paging configuration
Etc
LTE security
RACH handshake
between UE and eNB
RRC handshake between
UE and eNB
Connection setup
(authentication, set-up of
encryption, tunnel set-up,
etc)
Encrypted traffic
19
LTE security
Unencrypted and unprotected. I can
sniff these messages and I can
transmit them pretending to be a
legitimate base station.
Other things sent in the clear:
• Measurement reports
• Measurement report requests
• (Sometimes) GPS coordinates
• HO related messages
• Paging messages
• Etc
20
LTE security
Regardless of mutual authentication and strong encryption, a mobile device engages in a
substantial exchange of unprotected messages with *any* LTE base station (malicious or
not) that advertises itself with the right broadcast information.
21
LTE open source implementations
•
There are a few somewhat fully functional LTE open source implementations
OpenLTE – End to end implementation: RAN and “EPC”.
–
•
gr-LTE – Based on gnuradio-companion. Great for people new to software radio.
–
•
https://github.com/kit-cel/gr-lte
OpenAirInterface – Industry/Academia consortium.
–
•
http://www.openairinterface.org/
srsLTE – Almost complete implementation. Includes srsUE, device open source implementation.
–
•
•
http://sourceforge.net/projects/openlte/
https://github.com/srsLTE
Hardware setup
USRP B210 for active rogue base station
– BUDGET: USRP B210 ($1100) + GPSDO ($625) + LTE Antenna (2x$30) = $1785
– Machine running Ubunutu
– US dongles (hackRF, etc) for passive sniffing.
–
All LTE active radio experiments MUST be performed inside a faraday cage.
22
LTE traffic captures
•
Sanjole WaveJudge 5000 with IntelliJudge traffic processor
–
–
–
–
–
•
Reception and sniffing from multiple eNBs simultaneously
Decoding of messages at very low SNR regime
Retransmission of captures
Thanks to Sanjole for helping out and providing all the captures shown in this presentation!
http://www.sanjole.com/our-products/lte-analyzer/
Other options
openLTE pcap traffic dump
– WireShark LTE RRC library
– hackRF
– Other LTE open source implementations
–
23
LTE IMSI catcher (Stingray)
•
Despite common assumptions, in LTE the IMSI is always transmitted in the clear at least once
If the network has never seen that UE, it must use the IMSI to claim its identity
A UE will trust *any* eNodeB that claims it has never seen that device (pre-authentication messages)
IMSI can also be transmitted in the clear in error recovery situations (very rare)
–
–
–
•
Implementation
USRP B210 + Ubuntu 14.10 + gnuradio 3.7.2
LTE base station – OpenLTE’s LTE_fdd_eNodeB (slightly modified)
–
–
•
–
•
24
Added feature to record IMSI from Attach Request messages
Send attach reject after IMSI collection
Stingrays also possible in LTE without need to downgrade connection to GSM
LTE IMSI catcher
25
LTE IMSI catcher
26
Mapping {phone number, TMSI, IMSI}
•
Given a phone number
–
–
•
Setting up a rogue base station
–
–
•
27
Paging messages broadcasted in the clear and addressed to the TMSI
Silent text messages to target device
UE will attempt first with TMSI
Then intercept IMSI
Cool new tricks in a paper I will discuss shortly…
Mapping {phone number, TMSI, IMSI}
28
(Intermission) - Some excellent related work
•
A team at TU Berlin, University of Helsinki and Aalto University doing excellent work in the same area
–
–
–
–
•
Prof. Seifert’s team at TU Berlin responsible for other previous VERY COOL projects
–
–
–
–
•
Respond to phone calls and receive text messages that are intended for somebody else (USENIX 2013)
Preventing signaling-based attacks coming from smartphones (IEEE DSN 2012)
SMS baseband fuzzing (USENIX 2011)
Mobile botnets (MALWARE 2010)
The authors have submitted their Wireshark LTE dissectors and are being merged into the application
–
29
More results on SIM/device bricking with Attach/TAU reject messages
LTE location leaks
Detailed implementation and results
Paper to be presented at NDSS: http://arxiv.org/abs/1510.07563
Really looking forward to this…
Device and SIM temporary block
•
Attach reject and TAU (Tracking Area Update) reject messages not encrypted/integrity-protected
•
Spoofing this messages one can trick a device to
–
–
•
Believe it is not allowed to connect to the network (blocked)
Believe it is supposed to downgrade to or only allowed to connect to GSM
Attack set-up
–
USRP + openLTE LTE_fdd_eNodeB (slightly modified)
Devices attempt to attach (Attach Request, TAU request, etc)
Always reply to Request with Reject message
–
Experiment with “EMM Reject causes” defined by 3GPP
–
–
Real eNodeB
These are not the droids we are looking
for. I am not allowed to connect to my
provider anymore, I won’t try again.
REQUEST
30
REJECT
These are not the droids you are looking for… And you are not
allowed to connect anymore to this network.
Rogue eNodeB
Device and SIM temporary block
•
Some results
–
–
–
–
–
•
The blocking of the device/SIM is only temporary
Device won’t connect until rebooted
SIM won’t connect until reboot
SIM/device bricked until timer T3245 expires (24 to 48 hours!)
Downgrade device to GSM and get it to connect to a rogue BS
If the target is an M2M device, it could be a semi-persistent attack
Reboot M2M device remotely?
– Send a technician to reset SIM?
– Or just wait 48 hours for your M2M device to come back online…
–
31
Soft downgrade to GSM
•
Use similar techniques to “instruct” the phone to downgrade to GSM
–
•
Only GSM services allowed OR LTE and 3G not allowed
Once at GSM, the phone to connects to your rogue base station
–
–
–
–
Bruteforce the encryption
Listen to phone calls, read text messages
Man in the Middle
A long list of other bad things…
(Much more dangerous)
rogue GSM base station
I will remove these restraints and
leave this cell with the door open…
and use only GSM from now on…
and I’ll drop my weapon.
REQUEST
32
REJECT
You will remove these restraints and leave this cell with the
door open… and use only GSM from now on.
Rogue eNodeB
LTE location leaks and potential target device tracking
•
RNTI
PHY layer id sent in the clear in EVERY SINGLE packet, both UL and DL
Identifies uniquely every UE within a cell
Changes infrequently
–
–
–
•
•
–
33
Based on several captures in the NYC and Honolulu areas
No distinguishable behavior per operator or per base station manufacturer
Assigned by the network in the MAC RAR response to the RACH preamble
LTE location leaks and potential target device tracking
34
LTE location leaks and potential target device tracking
35
LTE location leaks and potential target device tracking
•
Potential RNTI tracking use cases
Know how long you stay at a given location
–
•
Estimate the UL and DL load of a given device
–
•
–
•
Signaling traffic on the air interface << Data traffic on the air interface
Potentially identify the hot-spot/access point in an LTE-based ad-hoc network
Phone # - TMSI – RNTI mapping is trivial
–
36
and meanwhile someone robs your house…
If the passive sniffer is within the same cell/sector as the target
Handoff between cell 60 and cell 50
Cell ID = 60
37
Cell ID = 50
38
Handoff between cell 60 and cell 50
39
Handoff between cell 60 and cell 50
40
Handoff between cell 60 and cell 50
Handoff between cell 60 and cell 50
0x2A60 = 10848
41
Handoff between cell 60 and cell 50
0x2A60 = 10848
42
Handoff between cell 60 and cell 50
RNTI = 112
43
44
Handoff between cell 60 and cell 50
LTE location leaks and potential target device tracking
•
According to 3GPP TS 36.300, 36.331, 36.211, 36.212, 36.213, 36.321
–
–
–
•
No specific guidelines on how often to refresh the RNTI and how to assign it
–
–
45
C-RNTI is a unique identification used for identifying RRC Connection and scheduling which is dedicated to a particular
UE.
After connection establishment or re-establishment the Temporary C-RNTI (as explained above) is promoted to C-RNTI.
During Handovers within E-UTRA or from other RAT to E-UTRA, C-RNTI is explicitly provided by the eNB in
MobilityControlInfo container with IE newUE-Identity.
In my passive analysis I have seen RNTIs unchanged for long periods of time
Often RNTI_new_user = RNTI_assigned_last + 1
Challenges and solutions
•
Potential solutions
Refresh the RNTI each time the UE goes from idle to connected
Randomize RNTI
Analyze the necessity of explicitly indicating the RNTI in the handover message
–
–
–
•
If RNTI is not refreshed rather frequently
MIT+Bell Labs work - LTE Radio Analytics Made Easy and Accessible (SigComm’14)
Track a device and map measurements to it based on RNTI (paper’s section 8.7)
When RNTI changes, PHY layer measurements still allow to map it to a given UE (SINR, RSSI, etc)
–
–
–
•
•
MIMO measurements and metrics
Recent discussion with GSMA
–
The RRC Connection Reconfiguration message should be sent encrypted – This would make tracking more difficult
But one could monitor traffic from adjacent cells and wait to see new RNTI with similar RF/traffic signature
– Ongoing discussions to address these potential issues
–
46
Some final thoughts…
48
LTE security and protocol exploits
Mobile security research very active since ~2009
• Most cool mobile security research exclusively on GSM (until now)
•
–
–
–
–
–
–
•
GSM location leaks (NDSS’12)
Wideband GSM sniffing (Nohl and Munaut – 27C3)
Hijacking mobile connections (Blackhat Europe’09)
Carmen Sandiego project (Blackhat’10)
GSM RACH flooding (Spaar – DeepSec’09)
…
Recent availability of open source LTE implementations
–
–
I expect a surge in LTE-focused security research
Very interesting PhD topic
•
The more research in the area, the more secure networks will be
•
I am actively advocating for specific protocol security focus in 5G and next-gen standards
49
Thanks!
Q&A
50
http://www.ee.columbia.edu/~roger/ ---- @rgoestotheshows
Huge THANK YOU to Sanjole for providing the captures used in this presentation.
http://www.sanjole.com/
Download