Capturing antique browsers in modern devices: �A security analysis of captive portal mini-browsers

Ping-Lun Wang, Kai-Hsiang Chou, Shou-Ching Hsiao, Ann Tene Low,

Tiffany Hyun-Jin Kim, and Hsu-Chun Hsiao

ACNS, 06/19 2023

What are captive portals?

2

Captive portals are everywhere!

3

How do devices detect captive portals?

4

http://captive.apple.com/hotspot-detect.html

Authentication for full Internet access

5

User portal browser

Satisfy access condition

Passwords, credit cards, …

Authentication for full Internet access

6

User portal browser

Satisfy access condition

Passwords, credit cards, …

We are sending our passwords, credit cards, … to an attacker!

What makes captive portal different?

Challenges to secure captive portal

• User portal browsers
• Different from normal browsers
• Security protection: unknown!

​

7

• Limited Internet access
• Cannot query safe browsing check, WHOIS, ChatGPT, …
• Authenticate a captive portal with offline information!

Our work: analyze mini-browsers and protect them

8

* https://github.com/csienslab/Wi-Fi-Chameleon

Assessment tool: Wi-Fi Chameleon

• Perform security checks on user portal browsers
• Implement on a Raspberry Pi

9

In the next few slides…

1. How Wi-Fi Chameleon works
2. Simulated attacks
3. Evaluation metrics

Wi-Fi Chameleon: simulate captive portal attacks

10

User portal browser

Wi-Fi Chameleon

• Captive portal attacks

• Evil-twin attack
• History-stealing attack

Evil-twin attack: fake Wi-Fi AP with the same SSID

11

SSID: CMU

SSID: CMU

▲ Real Wi-Fi AP

▲ Fake Wi-Fi AP

▲ Phishing captive portal

Performing evil-twin attack: URI modification

• TLS certificates (HTTPS) protect the authenticity of the URI
1. Perform an SSL stripping attack

https://captive-portal.com → http://captive-portal.com

• Use a fake TLS certificate

Self-signed certificate, revoked certificate, …

• Use a similar URI with modified domain

https://captive-portal.com → https://captive-porta1.com

12

HTTP warnings!

Validate certificates!

Verify domain name!

History-stealing attack: steal browsing history

13

• Cookies
• Local storage
• HSTS records

→ violate privacy and infer location history

Evaluation metrics to check vulnerabilities

Evil-twin attacks

• Warning messages and indicator
• HTTPS/HTTP indication
• Warnings for insecure/deprecated protocols
• Certificate validation
• Expired, self-signed, revoked
• Common name mismatch
• Untrusted root CA

14

History-stealing attacks

• Cookie and local storage
• Secure and HttpOnly cookies
• Clean storage after a session ends

Security analysis of user portal browsers

• 18 devices (2020 ~ 2022)

15

In the next few slides…

1. Evaluation results for each metric
2. Attack vulnerability analysis

​

Warning message and indicator: not provided

• HTTP/HTTPS indication
• Warnings for insecure protocols
• Warnings for deprecated protocols

16

✕

✕

✕

Certificate validation: mostly secure

17

Cookie and local storage: not cleaned for Android

18

Under attack: mostly vulnerable!

• Evil-twin attack
• No warnings for an SSL stripping attack! (HTTPS → HTTP)
• Xiaomi devices vulnerable to fake certificates
• No device can detect a modified domain
• History-stealing attack
• Android and Xiaomi devices are vulnerable

19

Challenge: how to verify the captive portal URI?

• Which URI is real/fake?

20

1. https://sbux-portal.globalreachtech.com

2. https://sbux-portal.globalroutetech.com

Our work: browser extension + identity verification

• Secure browser extension
• Trust on first use + HTTPS list
• Records the correct URI
• Prevents URI modification

​

21

• AP identity verification
• Binds SSID with URI
• Verifies with TLS certificate
• Prevents evil-twin attack

low deployment cost vs. no trust assumption

How browser extension detects URI modification

• First connection

22

HTTPS List

sbux-portal.globalreachtech.com

• Under attack

http://sbux-portal.globalreachtech.com

https://sbux-portal.globalroutetech.com

Can we remove the trust assumption?

How identity verification detects an evil-twin

23

How identity verification detects an evil-twin

24

Starbucks – globalreachtech.com

▲ Real Wi-Fi AP (modified)

Starbucks – globalreachtech.com

▲ Fake Wi-Fi AP

After – invalid AP

How identity verification detects an evil-twin

25

Starbucks – globalreachtech.com

▲ Real Wi-Fi AP (modified)

Starbucks – globalroutetech.com

▲ Fake Wi-Fi AP

After

Related work on captive portal protection

• Client-side defense scheme
• Fingerprinting
• Network probing
• Require prior knowledge of the real AP or baseline network environment
• Passpoint*
• Includes server’s logo and name in the TLS certificate
• Enforces Online Certificate Status Protocol (OCSP) stapling
• More difficult to deploy

26

* https://www.wi-fi.org/discover-wi-fi/passpoint

Takeaways

• Captive portal mini-browsers lack essential security protections
• Attackers can easily steal sensitive information
• Our defense authenticates URI and AP identity

27

Thank you for listening!

• Github: https://github.com/csienslab/Wi-Fi-Chameleon
• Contact: pinglunw@andrew.cmu.edu