One Click to Leak: Characterizing the Real-World Usage and Threat Impact of MNO-based Single Sign-On Websites

• Source: arXiv cs.CR 2609.12037 / ACM CCS 2026
• Authors: Jiasheng Huang, Mingxuan Liu, Pei Chen, Baojun Liu, Yiming Zhang, Geng Hong, Zhenrui Zhang, Hai Yang, Haixin Duan, Hui Jiang
• Original URL: https://arxiv.org/abs/2609.12037
• Archived original: 원문.pdf
• SHA-256: a78e3265d83ef0df87176139453e7608fc3ef995c8f2be94ecd44a634bc2bcb7
• Tags: MSSO, SSO, Authentication, Identity, Mobile, Privacy, Trust Delegation, Web Security

본 글은 원 논문의 주요 기술적 내용을 이해하기 쉽게 요약·정리한 글입니다. 자세한 내용은 상단의 원문 링크를 참고하세요.

한눈에 보기

이 연구는 이동통신사(MNO)가 사용자의 4G/5G 데이터 세션을 가입자 신원과 연결해 주는 MNO-based Single Sign-On(MSSO)이 웹으로 확장되면서 생긴 신뢰 경계 문제를 분석한다.

핵심은 “휴대폰 번호를 알아내는 새로운 브라우저 취약점”이 아니라, MSSO의 위임 구조가 다음 세 가지를 동시에 신뢰한다는 점이다.

1. 사용자가 실제로 동의했을 것
2. 요청을 보낸 서비스 제공자(SP)가 정당한 주체일 것
3. 발급된 User Identity Token이 의도된 SP와 origin에서만 사용될 것

연구진은 이 세 가정이 웹 환경에서 각각 깨지는 것을 Trust Defect 1~3으로 정리한다.

• TD1 — Unenforced User Consent: MNO가 “사용자가 실제 버튼을 눌렀는지”를 프로토콜 수준에서 확인할 수 없음
• TD2 — Static Credential Exposure: SP 인증용 appid, appkey 같은 정적 개발자 자격증명이 브라우저 JavaScript/설정/트래픽에 노출됨
• TD3 — Origin Validation Blindspot: MNO 또는 reseller가 최종 요청 origin/SP를 종단 간으로 확실히 바인딩하지 못함

이 세 결함이 결합되면 공격자는 피해자가 모바일 데이터로 특정 페이지를 방문한 것만으로 백그라운드에서 MSSO 인증 흐름을 유발하고, 얻은 토큰을 정상 검증 엔드포인트에 전달해 검증된 전화번호를 복원하는 One-Click-to-Leak(OCL) 공격을 구성할 수 있다.

중요한 점은 논문이 단순 가능성만 제시하지 않았다는 것이다. 1년간의 대규모 측정에서 연구진은 729개 apex domain의 116,852개 MSSO-enabled URL을 식별했고, 73.6%가 적어도 하나의 trust defect를 보였다. 또한 실제 악성 생태계와 연결된 101개 사이트 및 5개 upstream platform을 식별했으며, 압수된 대표 플랫폼의 정제된 backend 데이터에서는 3일 동안 14,100개의 고유 전화번호가 수집된 흔적이 확인됐다.

연구 배경

MSSO는 SMS OTP나 전통적인 Web SSO보다 사용자 입력을 줄이기 위해 모바일 네트워크 자체를 신뢰 신호로 사용한다.

일반적인 흐름은 다음과 같다.

1. Pre-authentication
   • 사용자 브라우저가 모바일 데이터 환경에서 MNO에 접근
   • 마스킹된 전화번호 등 사전 인증 정보를 받음
2. Token Issuance
   • 원래 설계상 사용자가 “원클릭 로그인” 같은 UI를 통해 동의
   • SP frontend가 개발자 자격증명과 함께 MNO에 인증 요청
   • MNO가 모바일 데이터 세션을 가입자 신원과 연결해 User Identity Token 발급
3. Backend Verification
   • SP frontend가 토큰을 SP backend에 전달
   • backend가 MNO 또는 provider와 서버 간 교환을 수행
   • 실제 전화번호를 얻고 세션을 생성

네이티브 앱에서는 이 로직이 SDK와 바이너리 내부에 들어 있지만, 웹에서는 JavaScript와 브라우저 트래픽에 그대로 노출된다. 연구진이 강조하는 차이는 바로 이 실행환경의 투명성이다.

공격 모델 / 전제 조건

OCL 공격자는 MNO 내부자 권한이나 통신망 제어권을 가정하지 않는다.

필요한 핵심 조건은 다음과 같다.

• 피해자가 공격자가 통제하거나 공격 스크립트가 삽입된 웹페이지를 방문
• 피해자가 Wi-Fi가 아니라 공격 대상 MSSO가 식별할 수 있는 모바일 데이터 세션을 사용
• 공격자가 적어도 하나의 정상 SP에서 재사용 가능한 개발자 자격증명을 획득
• 해당 MSSO provider가 사용자 동의를 protocol-level proof로 묶지 않음
• 발급된 User Identity Token이 원래 browser origin/session에 강하게 바인딩되지 않아 다른 backend/session에서 검증 가능

공격자에게 피해자의 전화번호나 계정 정보를 사전에 알 필요는 없다.

핵심 Root Cause

Root Cause는 “개발자 키가 JavaScript에 있다” 하나가 아니다.

1. 사용자 의도와 인증 결과가 cryptographically/protocol-level로 묶이지 않음

MSSO UI에는 동의 버튼이 존재할 수 있지만, MNO가 보는 것은 결국 API 요청이다.

즉 MNO가 검증하는 것은 대략 다음과 같다.

유효한 SP 자격증명인가?
+
현재 모바일 데이터 세션이 어떤 가입자인가?

반면 다음 질문은 검증하지 못한다.

이 가입자가 지금 이 SP에 신원을 넘기는 데 실제로 동의했는가?

UI 동작을 untrusted client-side code에 위임한 채 프로토콜에는 consent proof가 없으므로, programmatic invocation과 genuine click을 구분할 수 없다.

2. SP 인증 자격증명을 브라우저에 배포하면서 비밀로 취급함

웹 애플리케이션에서 브라우저로 전달한 정적 secret은 본질적으로 공격자가 읽을 수 있다.

그런데 MSSO는 이 값을 SP의 정당성을 증명하는 trust anchor로 사용한다.

따라서 구조는 다음과 같이 모순된다.

클라이언트에게 배포해야 하는 값
→ 누구나 관찰 가능
→ 그런데 서버는 그 값을 “SP만 아는 자격증명”처럼 신뢰

3. 인증된 intermediary와 실제 terminal SP/origin을 동일시함

Third-Party Reseller가 여러 MNO 인증을 묶어 제공하면 MNO가 관찰하는 주체는 downstream SP가 아니라 reseller일 수 있다.

유효한 reseller credential이 있다고 해서 “어느 웹 origin에서 어떤 최종 SP가 어떤 사용자를 대상으로 호출했는가”가 증명되지는 않는다.

따라서 핵심 Root Cause는:

사용자 동의, SP 신원, browser origin, token redemption context가 하나의 end-to-end authorization decision으로 묶이지 않은 채 서로 다른 계층에서 독립적으로 신뢰되는 것

이다.

핵심 공격 원리

OCL의 핵심 data flow는 다음과 같다.

피해자가 모바일 데이터로 공격 페이지 방문
→ 공격 script가 정상 SP의 노출된 credential 사용
→ 피해자 모바일 세션을 이용해 User Identity Token 요청
→ provider는 실제 클릭 여부와 실제 origin을 충분히 검증하지 못함
→ 피해자 신원에 대응하는 token 발급
→ token이 공격자 측으로 유출
→ 정상 verification endpoint에 token 전달
→ verified phone number 복원

연구진은 controlled validation에서 pre-consent token을 별도 세션에서 동일 SP의 검증 endpoint로 제출했을 때 연구진이 통제하는 전화번호로 정상 해석되는 것을 확인했다.

즉 “토큰이 발급된다”까지만 본 것이 아니라 토큰이 실제 신원 정보로 redemption 가능한지까지 확인했다.

공격 흐름

논문이 제시하는 OCL은 네 단계로 설명할 수 있다.

1. Victim entry
   • 피해자가 공격자가 통제하는 일반 웹페이지에 접속
2. Covert token request
   • JavaScript가 피해자의 MNO에 맞춰 적절한 MSSO 호출을 선택
   • 획득한 정상 SP 자격증명을 이용해 백그라운드 요청
3. Identity token issuance
   • provider가 credential과 모바일 세션을 검증
   • 실제 사용자 동의 여부를 확인하지 못한 채 token 발급
4. Token redemption
   • 공격자 backend가 해당 token을 정상 검증 경로에 제출
   • 전화번호 등 가입자 identity를 얻음

실제 악성 생태계에서는 이 결과가 단순 전화번호 수집에서 끝나지 않고 browsing context나 검색 키워드 등과 연결되어 de-anonymization 데이터로 상품화됐다.

성공 조건 / 실패 조건

성공 조건

• 모바일 네트워크 기반 identity resolution 가능
• client-side static credential 재사용 가능
• consent 단계가 protocol-level enforced가 아님
• token에 origin/session/SP audience binding이 충분하지 않음
• legitimate verification endpoint에서 cross-context redemption 가능

실패 조건 / 방어 조건

다음 중 하나라도 강하게 적용되면 공격 체인이 크게 약화된다.

• token 발급 전에 MNO 자체가 검증할 수 있는 사용자 승인 수행
• credential을 frontend에 두지 않고 backend-only로 이동
• token에 issuer/audience/SP/origin/session/nonce 등 context를 강하게 바인딩
• verification endpoint에서 token을 발급받은 정확한 context와 redemption context를 비교
• reseller가 downstream SP identity를 end-to-end로 전달하고 MNO가 검증
• 마스킹된 번호의 일부를 사용자가 직접 완성하도록 하는 masked-number completion
• pre-consent 단계에서는 identity-redeemable high-privilege token을 발급하지 않음

연구진의 실험 환경

이 연구는 단일 PoC가 아니라 대규모 measurement study다.

• mainstream MSSO provider 14개 확인
• seed endpoint 20개 추출
• 초기 실제 workflow 분석에서 MSSO를 사용하는 사이트 225개 확인
• OCL Detector를 통해 1년간 longitudinal measurement
• 최종 116,852 URL / 729 apex domain 확인
• simulated mobile environment에서 targeted dynamic probing 수행
• 실제 사용자의 인증 트래픽을 수집하는 방식은 피함
• controlled validation은 연구진이 소유한 SIM/전화번호를 이용
• probing rate는 윤리적 제약을 두고 수행
• 실제 제3자 token redemption은 수행하지 않음

이 점은 “실험실 PoC만으로 전체 웹 위험을 추정했다”는 연구와 차이가 있다.

주요 실험 결과

전체 배포 규모

• MSSO-enabled URL: 116,852
• apex domain: 729

Trust Defect 분포

• 적어도 하나의 trust defect: 73.6%
• developer credential exposure: 69.4%
• 사용자 동의 이전 high-privilege token 발급: 27.1%
• reseller 사용 apex domain: 31.8%

주의할 점은 이 수치들이 서로 배타적인 범주가 아니라는 것이다. 하나의 URL/domain이 여러 defect를 동시에 가질 수 있다.

OCL abuse 탐지

스크립트 기반 분석에서:

• OCL 공격 행위와 강하게 연결된 웹사이트: 101개
• 연결된 upstream platform: 5개

실제 악용 사례

법집행기관에 의해 압수된 대표 플랫폼의 sanitized backend data에서:

• 3일 동안 수집된 고유 전화번호: 14,100개
• 전화번호와 browsing activity / search keyword 등 민감한 맥락 연결

이는 “가능한 공격”을 넘어 OCL형 신원 수집이 실제 monetized pipeline으로 운영됐음을 보여주는 강한 근거다.

실제 발견된 취약점 / 사례

이 논문은 단일 CVE를 발표하는 형태가 아니다.

오히려 여러 MNO, reseller, SP에 걸친 ecosystem-level trust design defect를 측정한다.

실제 사례의 가치가 큰 이유는 다음과 같다.

• 악성 사이트 한 곳의 구현 실수가 아님
• 5개 upstream platform을 중심으로 여러 사이트에 공급되는 구조
• exploit-as-a-service / affiliate에 가까운 공급망적 형태가 관찰됨
• 대표 압수 플랫폼에서 identity harvesting의 실제 backend data가 확인됨
• 연구진의 disclosure 이후 적어도 148개 affected site가 masked-number completion 등 권고 방어를 적용

저자 주장 vs 실제 증명 범위

강하게 증명된 부분

• 웹 MSSO에서 세 가지 trust defect가 실제 넓게 존재한다.
• credential이 frontend asset에서 노출되는 사례가 대규모로 존재한다.
• pre-consent 단계에서 강한 권한의 token을 내주는 서비스가 존재한다.
• controlled account/SIM에서 token cross-context redemption이 가능하다.
• 악성 MSSO 활용과 강하게 연관된 실제 사이트/플랫폼 집단이 존재한다.
• 압수 backend 데이터에서 대규모 전화번호 수집이 실제 확인됐다.

주의해서 볼 부분

• 116,852 URL 전체가 실제 OCL exploit에 성공한다는 의미는 아니다.
• “trust defect가 존재한다”와 “즉시 공격 가능하다”는 같은 표현이 아니다.
• provider별 workflow가 다르므로 공격 prerequisite도 다르다.
• 연구는 중국 MSSO ecosystem과 Baidu 기반 measurement가 큰 비중을 차지한다.
• international CAMARA/Open Gateway 계열에 동일 수치가 그대로 적용된다고 일반화하면 안 된다.

기존 공격 / 기존 점검 방식과의 차이

일반 OAuth/OIDC 점검은 다음을 많이 본다.

• redirect URI
• state/nonce
• token audience
• code replay
• session fixation
• account linking

MSSO에서는 여기에 모바일 네트워크 세션 자체가 identity source라는 독특한 trust anchor가 추가된다.

따라서 점검 질문도 달라져야 한다.

누가 token을 요청했는가?
누가 사용자의 동의를 증명하는가?
credential은 정말 비밀인가?
token은 어느 origin/SP/session에 묶였는가?
reseller를 거치면 최종 SP identity가 어디까지 전달되는가?

즉 전통적인 “token validation bug”보다 위임된 신뢰가 어느 계층에서 소실되는지를 보는 것이 핵심이다.

연구의 한계와 주의해서 볼 부분

• 모든 MSSO provider를 포괄하지 않는다.
• pDNS/search-engine 기반 discovery에는 coverage bias가 존재한다.
• 동적 probing은 실제 사용자 환경의 모든 carrier/device/browser 조합을 재현하지 않는다.
• 실제 피해 규모 14,100건은 한 대표 seized platform의 3일 데이터이며 전체 ecosystem 피해 규모가 아니다.
• 실제 affected site 및 raw credentials/HAR는 윤리·보안상 공개하지 않았다.
• 대규모 abuse attribution은 script fingerprinting과 cluster analysis를 사용하므로 “101개 사이트 = 101개의 법적으로 확정된 범죄 사이트”로 해석하면 안 된다.

공개 PoC / Exploit / Tool / Artifact 분석

연구진은 OCL Detector 관련 artifact를 공개했다.

공개 범위에는 다음이 포함된다.

• pDNS correlation 로직
• MSSO service verification 로직
• script profiling / DBSCAN clustering 관련 코드
• seed rule
• sanitized analysis notebook 및 결과
• masked-number defense 사례
• controlled demonstration 자료

반면 다음은 공개하지 않는다.

• raw pDNS/search-engine proprietary dataset
• 실제 live developer credentials
• 피해 사이트의 raw script 전체
• raw HAR
• 제3자 피해자를 대상으로 한 weaponized attack code
• 실제 affected site identity 전체

따라서 “공개 exploit kit”이라기보다 measurement/detection reproduction artifact에 가깝다.

실무에서 이 artifact의 가치도 실제 공격 자동화보다는 다음에 있다.

• 사내 웹 자산에서 MSSO endpoint fingerprinting
• frontend credential 노출 탐지
• consent 전 token 발급 여부 확인
• script에서 MSSO API call chain 추적
• reseller 기반 integration 식별

레드팀 / 모의해킹에서 어떻게 활용할까

MSSO/원클릭 로그인 기능을 발견하면 일반 로그인 기능처럼만 보지 말고 delegated trust chain을 별도 테스트 대상으로 잡는 것이 좋다.

특히 다음 케이스가 중요하다.

1. Consent bypass

정상 UI click 이전과 이후의 요청을 비교한다.

확인할 것은 “버튼을 눌렀는가”가 아니라:

provider가 token issuance를 결정할 때 사용자 동의를 증명하는 별도의 값이나 서버 측 state를 실제로 검증하는가?

이다.

2. Frontend credential inventory

JavaScript bundle, JSON config, network request, source map 등에 있는:

• appid
• appkey
• client identifier
• provider-specific secret-like parameter

를 단순 secret leak으로만 보고 끝내지 말고 그 값이 실제 SP authorization boundary로 사용되는지를 확인해야 한다.

3. Token context binding

연구용 계정으로 얻은 token을 대상으로:

• 다른 브라우저 세션
• 다른 origin
• 다른 backend session
• 다른 host
• 다른 SP endpoint

에서 accept되는지 확인한다.

4. Reseller trust tracing

MNO → reseller → SP 구조라면 MNO가 최종 SP의:

• domain/origin
• app identity
• redirect context
• request nonce

중 무엇을 실제 검증하는지 추적한다.

실무 가치 평가

★★★★★ — 매우 높음

인증 진단 관점에서 상당히 가치가 높다.

특히 좋은 점은 “one-click login 버튼에 CSRF가 있는가” 같은 표면적 테스트가 아니라:

User intent
→ SP credential
→ MNO identity assertion
→ token
→ backend redemption

전체 신뢰 사슬을 하나의 authorization decision으로 봐야 한다는 점을 명확히 보여준다는 것이다.

OAuth/OIDC 진단 경험이 있는 레드팀이라면 이 논문의 사고방식을 MSSO뿐 아니라 passkey broker, telecom identity API, identity reseller, KYC API 같은 delegated identity 구조에도 적용할 수 있다.

결론

이 연구가 보여주는 가장 중요한 문제는 “전화번호가 새어 나갈 수 있다”보다 더 구조적이다.

클라이언트가 증명해야 할 수 없는 것을 클라이언트가 증명한다고 가정하고, 서로 다른 위임 계층의 신뢰를 종단 간 바인딩하지 않으면 인증은 정상 동작하면서도 사용자 의도와 완전히 분리될 수 있다.

웹 MSSO를 점검할 때는 credential secrecy만 보지 말고 반드시 consent binding + SP identity binding + token context binding을 하나의 체인으로 검증하는 것이 핵심이다.