Anonymity Mobile Autumn 2018 Tadayoshi (Yoshi) Kohno - - PowerPoint PPT Presentation

▶
anonymity
SMART_READER_LITE
LIVE PREVIEW

Anonymity Mobile Autumn 2018 Tadayoshi (Yoshi) Kohno - - PowerPoint PPT Presentation

Dec 15, 2023 482 likes •866 views

CSE 484 / CSE M 584: Computer Security and Privacy Anonymity Mobile Autumn 2018 Tadayoshi (Yoshi) Kohno yoshi@cs.Washington.edu Thanks to Dan Boneh, Dieter Gollmann, Dan Halperin, Ada Lerner, John Manferdelli, John Mitchell, Franziska

slide-1
SLIDE 1

CSE 484 / CSE M 584: Computer Security and Privacy

Anonymity Mobile

Autumn 2018 Tadayoshi (Yoshi) Kohno yoshi@cs.Washington.edu

Thanks to Dan Boneh, Dieter Gollmann, Dan Halperin, Ada Lerner, John Manferdelli, John Mitchell, Franziska Roesner, Vitaly Shmatikov, Bennet Yee, and many others for sample slides and materials ...

slide-2
SLIDE 2

Admin

  • HW 3 due Nov 30
  • Lab 3 out this week, due Dec 7 (Quiz Section on Nov 29)

11/28/2018 CSE 484 / CSE M 584 2

slide-3
SLIDE 3

Admin

  • Final Project Proposals: Looked great!
  • Final Project Checkpoint: Nov 30 – preliminary outline and

references

  • Final Project Presentation: Dec 10 – 12-15-minute video –

must be on time

  • Explore something of interest to you, that could hopefully

benefit you or your career in some way – technical topics, current events, etc

11/28/2018 CSE 484 / CSE M 584 3

slide-4
SLIDE 4

Review: Onion Routing

11/28/2018 4

R R4 R1 R2 R R R3

Bob

R R R

Alice

[Reed, Syverson, Goldschlag 1997]

  • Sender chooses a random sequence of routers
  • Some routers are honest, some controlled by attacker
  • Sender controls the length of the path
slide-5
SLIDE 5

Review: Route Establishment

11/28/2018 5

R4 R1 R2 R3

Bob Alice

{R2,k1}pk(R1),{ }k1 {R3,k2}pk(R2),{ }k2 {R4,k3}pk(R3),{ }k3 {B,k4}pk(R4),{ }k4 {M}pk(B)

  • Routing info for each link encrypted with router’s public key
  • Each router learns only the identity of the next router
slide-6
SLIDE 6

Tor

  • Second-generation onion routing network

– http://tor.eff.org – Developed by Roger Dingledine, Nick Mathewson and Paul Syverson – Specifically designed for low-latency anonymous Internet communications

  • Running since October 2003
  • “Easy-to-use” client proxy

– Freely available, can use it for anonymous browsing

11/28/2018 6

slide-7
SLIDE 7

Tor Circuit Setup (1)

11/28/2018 7

  • Client proxy establishes a symmetric session

key and circuit with Onion Router #1

slide-8
SLIDE 8

Tor Circuit Setup (2)

11/28/2018 8

  • Client proxy extends the circuit by establishing

a symmetric session key with Onion Router #2

– Tunnel through Onion Router #1

slide-9
SLIDE 9

Tor Circuit Setup (3)

11/28/2018 9

  • Client proxy extends the circuit by establishing

a symmetric session key with Onion Router #3

– Tunnel through Onion Routers #1 and #2

slide-10
SLIDE 10

Using a Tor Circuit

11/28/2018 10

  • Client applications connect and communicate
  • ver the established Tor circuit.
slide-11
SLIDE 11

Tor Management

  • Many applications can share one circuit

– Multiple TCP streams over one anonymous connection

  • Tor router doesn’t need root privileges

– Encourages people to set up their own routers – More participants = better anonymity for everyone

  • Directory servers

– Maintain lists of active onion routers, their locations, current public keys, etc. – Control how new routers join the network

  • “Sybil attack”: attacker creates a large number of routers

– Directory servers’ keys ship with Tor code

11/28/2018 11

slide-12
SLIDE 12

Is Tor Perfect?

  • Q: What can “go wrong” with the use of Tor?

11/28/2018 15

slide-13
SLIDE 13

Issues and Notes of Caution

  • Passive traffic analysis

– Infer from network traffic who is talking to whom – To hide your traffic, must carry other people’s traffic!

  • Active traffic analysis

– Inject packets or put a timing signature on packet flow

  • Compromise of network nodes

– Attacker may compromise some routers

  • And powerful adversaries may have “too many” routers (e.g., a

super computer at a national lab)

– It is not obvious which nodes have been compromised

  • Attacker may be passively logging traffic

– Better not to trust any individual router

  • Assume that some fraction of routers is good, don’t know which

11/28/2018 16

slide-14
SLIDE 14

Issues and Notes of Caution

  • Tor isn’t completely effective by itself

– Tracking cookies, fingerprinting, etc. – Exit nodes can see everything!

11/28/2018 17

slide-15
SLIDE 15

Issues and Notes of Caution

  • The simple act of using Tor could make one a

target for additional surveillance

  • Hosting an exit node could result in illegal

activity coming from your machine

11/28/2018 18

slide-16
SLIDE 16

Mobile Security

11/28/2018 CSE 484 / CSE M 584 19

slide-17
SLIDE 17

Roadmap

11/28/2018

  • History, How we got here
  • Mobile malware
  • Mobile platforms vs. traditional platforms
  • Dive into Android

20

slide-18
SLIDE 18

Questions: Mobile Malware

Q: How might malware authors get malware

  • nto phones?

Q: What are some goals that mobile device malware authors might have?

11/28/2018 21

slide-19
SLIDE 19

Smartphone (In)Security

Users accidentally install malicious applications.

11/28/2018 22

slide-20
SLIDE 20

Smartphone (In)Security

Even legitimate applications exhibit questionable behavior.

11/28/2018 23

Hornyack et al.: 43 of 110 Android applications sent location or phone ID to third-party advertising/analytics servers.

slide-21
SLIDE 21

Mobile Malware Goals

  • “Unique” to phones:

– Premium SMS messages – Identify location – Record phone calls – Log SMS

  • Similar to desktop/PCs:

– Connects to botmasters – Steal data – Phishing – Malvertising

11/28/2018 30

slide-22
SLIDE 22

Malware in the Wild

[Zhou et al.]

Android malware grew quickly! Today: millions of samples.

11/28/2018 31

slide-23
SLIDE 23

Mobile Malware Examples Over Time

  • DroidDream (Android)

– Over 58 apps uploaded to Google app market – Conducts data theft; send credentials to attackers

  • Zitmo (Symbian,BlackBerry,Windows,Android)

– Poses as mobile banking application – Captures info from SMS – steal banking 2nd factors – Works with Zeus botnet

  • Ikee (iOS)

– Worm capabilities (targeted default ssh password) – Worked only on jailbroken phones with ssh installed

11/28/2018 32

slide-24
SLIDE 24

Background: Before Mobile Platforms

Assumptions in traditional OS (e.g., Unix) design:

1. There may be multiple users who don’t trust each other. 2. Once an application is installed, it’s (more or less) trusted.

11/28/2018 35

slide-25
SLIDE 25

Background: Before Mobile Platforms

Assumptions in traditional OS (e.g., Unix) design:

1. There may be multiple users who don’t trust each other. 2. Once an application is installed, it’s (more or less) trusted.

11/28/2018 36

slide-26
SLIDE 26

Background: Before Mobile Platforms

Assumptions in traditional OS (e.g., Unix) design:

1. There may be multiple users who don’t trust each other. 2. Once an application is installed, it’s (more or less) trusted.

11/28/2018 37

Apps can do anything the UID they’re running under can do.

slide-27
SLIDE 27

What’s Different about Mobile Platforms?

  • Isolation: Applications are isolated

– Each runs in a separate execution context – No default access to file system, devices, etc. – Different than traditional OSes where multiple applications run with the same user permissions!

  • App Store: Approval process for applications

– Market: Vendor controlled/Open – App signing: Vendor-issued/self-signed – User approval of permissions

11/28/2018 38

slide-28
SLIDE 28

More Details: Android

  • Based on Linux
  • Application sandboxes

– Applications run as separate UIDs, in separate processes. – Memory corruption errors only lead to arbitrary code execution in the context of the particular application, not complete system compromise! – (Can still escape sandbox – but must compromise Linux kernel to do so.)  allows rooting

11/28/2018 39

[Enck et al.]

slide-29
SLIDE 29

Challenges with Isolated Apps

So mobile platforms isolate applications for security, but…

  • 1. Permissions: How can applications access

sensitive resources?

  • 2. Communication: How can applications

communicate with each other?

11/28/2018 42

slide-30
SLIDE 30

Permission Granting Problem

Smartphones (and other modern OSes) try to prevent such attacks by limiting applications’ access to:

– System Resources (clipboard, file system). – Devices (camera, GPS, phone, …).

Standard approach: Ask the user.

How should operating system grant permissions to applications?

11/28/2018 43

slide-31
SLIDE 31

Two Ways to Ask the User

Prompts (time-of-use)

11/28/2018 44

Manifests (install-time)

slide-32
SLIDE 32

Questions

  • Q: What are the pros and cons of the

manifest-based permission model?

  • Q: What are the pros and cons of the “ask

each use” permission mode?

11/28/2018 45

slide-33
SLIDE 33

Two Ways to Ask the User

Prompts (time-of-use) Manifests (install-time)

Disruptive, which leads to prompt-fatigue.

11/28/2018 46

slide-34
SLIDE 34

Two Ways to Ask the User

Prompts (time-of-use) Manifests (install-time)

Out of context; not understood by users. In practice, both are overly permissive: Once granted permissions, apps can misuse them. Disruptive, which leads to prompt-fatigue.

11/28/2018 47

slide-35
SLIDE 35

Are Manifests Usable?

Do users pay attention to permissions?

[Felt et al.]

… but 88% of users looked at reviews.

11/28/2018 48

slide-36
SLIDE 36

Do users understand the warnings?

Are Manifests Usable?

[Felt et al.]

11/28/2018 49

slide-37
SLIDE 37

Do users act on permission information?

“Have you ever not installed an app because of permissions?”

Are Manifests Usable?

[Felt et al.]

11/28/2018 50