▲

Android에서 Localhost를 이용한 은밀한 웹-앱 트래킹 기법 공개

 (localmess.github.io)
19P by GN⁺ 3일전 | ★ favorite | 댓글 11개
  • Meta(페이스북), Yandex 등 주요 앱이 Android에서 로컬 포트(127.0.0.1)를 사용해 웹 브라우저와 네이티브 앱 간 식별자·쿠키를 비밀리에 공유한 사실이 공개됨
  • 웹사이트에 심어진 Facebook Pixel, Yandex Metrica 스크립트가 Android 브라우저에서 네이티브 앱(페이스북, 인스타그램, Yandex 계열 앱)으로 브라우징 세션과 식별자를 직접 전달, 사용자 식별 및 탈익명화가 가능해짐
  • 이 방식은 쿠키 삭제, 시크릿 모드, 권한 설정, 광고ID 리셋 등 기존 프라이버시 보호책을 모두 우회하며, 악성 앱이 포트만 맞춰 듣고 있으면 브라우저 방문 이력 수집도 가능함
  • 2025년 6월 3일 공개 이후 Facebook 측은 해당 코드를 대부분 제거했으나, 해당 기법이 수년간 전 세계 수억대 안드로이드 기기에서 이용됨. Yandex는 2017년부터 유사한 방식을 지속적으로 사용 중임
  • 크롬, 파이어폭스, 브레이브 등 주요 브라우저들은 긴급 차단 조치를 도입했지만, 플랫폼 구조적 한계로 완전한 근본 대책은 미흡, Android IPC와 로컬 네트워크 보안 강화 필요성이 강조됨

Disclosure: Localhost를 통한 은밀한 웹-앱 트래킹 기법

  • 연구진은 Meta와 Yandex가 수십억 안드로이드 사용자를 대상으로, 네이티브 앱이 정해진 로컬 포트(예: 12580~12585, 29009~30103) 를 백그라운드에서 열어두고 웹에서 실행된 자바스크립트와 통신하는 방식을 발견함
  • 이를 통해 웹브라우저의 쿠키, 메타데이터, 사용 기록이 네이티브 앱에 전달되고, 앱 계정 정보 및 Android Advertising ID 등과 결합되어 사용자 신원이 웹 방문과 연결됨

How does this work?

Android의 로컬 포트 악용

  • Android OS에서 모든 앱이 INTERNET 권한만 있으면 127.0.0.1(루프백)에 소켓을 열 수 있음
  • 브라우저 역시 별도의 사용자 동의 없이 이 인터페이스 접근 가능
  • 웹사이트에 심어진 자바스크립트가 브라우저와 네이티브 앱간에 표준 Web API를 이용해 데이터 송수신 가능

Meta/Facebook Pixel의 웹-앱 연동 방식

  • Meta Pixel 자바스크립트가 Android 브라우저에서 로드될 때, _fbp 쿠키 값을 WebRTC의 STUN 패킷(UDP 12580–12585 포트)으로 네이티브 앱에 전송
  • 기기 내 Facebook, Instagram 앱(버전별로 515.0.0.23.90/382.0.0.43.84 등)이 해당 포트에서 수신 대기, 브라우저에서 온 _fbp 값을 수신해 자체 서버에 GraphQL로 전송
  • _fbp는 약 25%의 상위 백만 사이트에 심겨있는 주요 쿠키로, 기존엔 사이트별로 별도라 교차 추적이 어려웠지만, 이 방식으론 사용자의 다중 _fbp를 한 계정으로 매칭 가능
  • 2025년 5월 이후에는 WebRTC TURN 방식을 추가, SDP Munging 기법을 피하도록 스크립트가 변경됨
  • _fbp 쿠키는 90일간 유지, 25%의 상위 웹사이트에서 사용될 정도로 매우 흔함
  • Chrome 등 주요 브라우저 대응 후 6월 3일 코드 삭제

Yandex Metrica의 웹-앱 연동 방식

  • Yandex Metrica 스크립트는 2017년부터 HTTP(S)로 로컬 포트(29009, 29010, 30102, 30103 등)에 요청을 보냄
  • Yandex 앱(Yandex Maps, Navigator, Browser, Search 등)이 포트를 열어두고, 받은 요청에 대해 Base64 인코딩된 Android Advertising ID(AAID) 와 기타 디바이스 식별자, UUID 등을 포함한 데이터를 응답
  • 브라우저 스크립트가 이 정보를 수집해 다시 Yandex 서버로 전송, 브라우저-앱-서버 간 식별자 연동 완성
  • yandexmetrica.com 도메인이 127.0.0.1로 리졸브되어 탐지 회피 및 수집 흐름 은폐
  • 로컬호스트 HTTP 사용으로 인해, 만약 다른 앱이 동일 포트를 리스닝할 경우 사용자의 웹사이트 방문 기록 노출 위험까지 있음

실질적 위험: 브라우저 방문 이력 유출

  • HTTP 기반 로컬 통신을 이용할 경우, 임의의 Android 앱도 해당 포트만 듣고 있으면 브라우저 방문 URL 등 히스토리 획득 가능
  • 실제 Proof-of-Concept 앱 개발 및 크롬·파이어폭스·엣지에서 실험해 프라이빗 브라우징, 시크릿 모드도 모두 취약함을 입증
  • Brave, DuckDuckGo 등 일부 브라우저만 자체 블록리스트 및 사용자 동의 요구로 방어됨

Affected Sites

  • Meta Pixel: 580만 개 웹사이트에서 사용, 실제 크롤링 결과 상위 10만개 사이트 중 EU 1.5만, US 1.7만 사이트에서 로컬 ID 공유 관찰
  • Yandex Metrica: 300만 개 웹사이트에서 사용, 동일 방식으로 EU 1,260, US 1,312 사이트에서 로컬 포트 통신 확인
  • 이 중 상당수 사이트는 쿠키 동의 절차 없이도 자동 트래킹 실행됨

History

  • Yandex: 2017년부터 HTTP/HTTPS 포트 이용 시작
  • Meta: 2024년 9월 HTTP, 2024년 11월 WebSocket, 2025년 WebRTC STUN, 5월 TURN으로 단계적 전환

Abuse Vectors

  • 안드로이드의 로컬호스트 소켓 접근 제한 부재 및 샌드박스 정책 미흡이 주요 원인
  • 기존 권한 설정, 브라우저 시크릿 모드, 광고ID 리셋 등 모든 보호책 우회
  • 웹 개발 목적의 합법적 용도와 구분 어려우나, 대규모 트래킹 실증 사례로 남음
  • Chrome, Firefox, DuckDuckGo, Brave 등 브라우저는 긴급 대응 패치 중이나, 근본적으로는 플랫폼 차원의 권한 및 경고, 샌드박스, IPC 정책 강화 필요

Disclosure

  • 크롬, 파이어폭스, DuckDuckGo, 브레이브 등 브라우저 공급사에 책임 공개 및 협력 요청
  • 크롬(137버전), 파이어폭스(138버전), 브레이브 등 취약 포트 차단, SDP Munging 차단 등 단기 조치 시행
  • 장기적으로는 로컬 네트워크 접근 통제, 샌드박스 보강, 사용자 안내 등 구조적 보완 필요성 강조
브라우저 버전 Yandex Facebook 대응/차단 현황
Chrome 136.0+ 영향 영향 137부터 포트 및 SDP munging 차단, 단계적 적용 중
Edge 136.0+ 영향 영향 불명(Chromium 기반)
Firefox 138.0.2 영향 영향없음(1) SDP munging 차단, UDP는 차후 차단 예정
DuckDuckGo 5.233.0 일부 영향(2,3 영향없음(2,3) 블록리스트 기반 차단
Brave 1.78.102 영향 없음(3,4) 영향 없음(3,4) 2022년부터 로컬호스트 요청 사용자 동의 필요, 블록리스트 적용
  • 1: SDP Munging 차단, TURN 포트는 아직 미차단(향후 적용 예정)
  • 2,3,4: 블록리스트, 포트 차단, 사용자 동의 등 다양한 방어

사용자·운영자 인지 현황

사이트 운영자

  • Meta, Yandex 공식문서에는 해당 방식이 공개된 바 없음
  • 2024년 9월부터 Facebook 개발자 포럼 등에서 "왜 Pixel 스크립트가 localhost에 접근하나" 문의 잇따랐으나, 공식 답변 전무
  • 사이트 운영자, 최종 사용자는 대부분 인지하지 못함. 사용자가 로그인하지 않은 상태, 시크릿모드, 쿠키 삭제 등 상황에도 추적 가능

일반 사용자

  • 로그인 상태와 무관하게 트래킹 동작
  • 시크릿 모드, 쿠키 삭제 등 보호책 무력화
  • 쿠키 동의 절차 없는 사이트에서도 작동하는 사례 다수

FAQ 요약

  • Q: 왜 Meta는 공개 직후 해당 방식을 중단했나?
    A: 공식 답변 없음, 공개 이후 안드로이드 유저 대상 패킷 송신 중단 확인
  • Q: 연구가 피어리뷰(동료 검증) 되었나?
    A: 일부 기관에서 검증했으나 논문 심사 전, 악용 규모 때문에 신속 공개 결정
  • Q: Meta/Yandex 공식 문서에 공개되어 있나?
    A: 공식 기술 문서 없음, 개발자 포럼 문의만 존재
  • Q: iOS/타 플랫폼도 영향받나?
    A: 현재까지 안드로이드에서만 확인, 기술적으로는 iOS/데스크톱/스마트TV 등도 잠재적 위험 있음
▲
ethanhur 2일전  [-]

서비스에 돈을 지불하지 않으면 내가 제품인 거죠. 점점 더 데이터를 통해 개인을 추적하려는 시도는 많아질 거고, 이러한 흐름을 되돌릴 수 있어 보이지는 않습니다. 더 나은 대안이 필요한데 자본주의 아래에서 더 나은 대안이 뭘지는 잘 떠오르지 않네요.

답변달기
▲
dhy0613 2일전  [-]

이상하게 배터리를 많이 먹어서 메타쪽 앱들을 다 지웠었는데 이런 일이 있었네요... adb로 나머지 갤럭시에 내장된 시스템 앱도 다 지워야 겠습니다.

답변달기
▲
savvykang 1일전  [-]

저도 메타 앱은 믿을수가 없어서 안쓰고 대신 보안폴더 내 크롬으로만 이용합니다

답변달기
▲
iolothebard 2일전  [-]

하이브리드 웹앱이라고 부르는 프레임워크 류는 대부분 (목적은 다르지만) localhost 웹서버 띄웁니다. 내장 브라우저 라이브러리(웹킷…) 설정이나 커스텀으로도 해결안되는 것들(웹 파트) 것들을 localhost에 띄워놓은 웹서버(네이티브 파트) 쪽에서 해결하는 거죠. 그걸 이렇게 활용할 수도 있었는데… 아까비

답변달기
▲
jeiea 1일전  [-]

제 생각으론 하이브리드 앱에서 웹/앱 간 일반적인 통신 방법은 브릿지라고도 부르는 OS와 브라우저 단에서 제공하는 API를 통한 방식이에요. 로컬 웹 서버는 필수가 아니라고 봐요.
저기서 로컬 웹 서버를 써서 문제가 된 이유는 가령 시크릿 모드 크롬에서 로컬호스트 포트로 접근해서 사용자의 익명성을 깨뜨리는 취약점 등이 가능해서라고 봐요. 이런 기술이 하이브리드 앱에서 필수면.. 하이브리드 앱이 사라져야죠.

답변달기
▲
nemorize 24시간전  [-]

도메인네임이 강제되는 피쳐들, localStorage 등등을 처리하기 위해 앱 내에서 웹 서버를 열어 쓰는게 일반적이긴 합니다.

답변달기
▲
savvykang 2일전  [-]

갤럭시 보안폴더 내-외부 localhost 접근이 격리되는지 궁금하네요

답변달기
▲
savvykang 2일전  [-]

격리가 안 되네요. 보안폴더 밖에서 termux로 파이썬 http.server를 실행시키고 안에서 크롬으로 접속하니 접속이 됩니다

답변달기
▲
forgotdonkey456 2일전  [-]

이거 보안 구멍 아닌가요 -_-??

답변달기
▲
jjpark78 2일전  [-]

sns를 안하는게 정답..인거 같군요

답변달기
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • Meta에서 사용하는 전체적인 트래킹 과정을 내가 이해한 대로 정리해보면, Localmess 블로그를 참고한 내용임

    1. 사용자가 Facebook 또는 Instagram 앱에 로그인 상태일 때, 해당 앱이 백그라운드에서 특정 포트로 들어오는 트래픽을 수신함
    2. 사용자가 휴대폰 브라우저로 웹사이트(e.g. something-embarassing.com)를 방문하면, 해당 사이트에 Meta Pixel이 삽입되어 있는 경우가 많음 (기사에 따르면 580만 개가 넘는 웹사이트에 설치됨)
      인코그니토 모드여도 여전히 추적이 가능함
    3. 위치에 따라 웹사이트가 사용자 동의를 요구할 수 있는데, 기사에서는 자세한 설명이 없지만 아마도 많은 사용자가 아무 생각 없이 동의해버리는 '쿠키 배너'를 의미함
    4. Meta Pixel 스크립트가 _fbp 쿠키(브라우징 정보 포함)를 WebRTC (STUN) SDP Munging 기법을 이용해 Instagram 또는 Facebook 앱으로 전송함
      이 과정은 브라우저 개발자 도구에서도 보이지 않는 부분임
    5. 앱에 이미 로그인된 상태라면 Meta에서는 "익명" 브라우저 활동을 로그인된 사용자 정보와 연결 가능
      앱이 _fbp 정보와 사용자 ID를 Meta 서버에 전달함
      추가로 주목할 점은,

    • 이 웹에서 앱으로 ID를 공유하는 방식은 쿠키 삭제, 인코그니토 모드, 안드로이드 권한 제어 같은 일반적인 프라이버시 보호책을 우회함

    • 심지어 악성 앱이 사용자의 웹 활동을 염탐할 수 있는 가능성도 열려 있음

    • 5월 중순 이후 Meta Pixel 스크립트가 _fbp 쿠키를 WebRTC TURN 방식으로도 보내기 시작했으며, 이 방법은 Chrome 개발팀이 SDP Munging을 차단한 후 도입됨

    • 2025년 6월 2일 기준으로는 해당 새 포트를 통해 Facebook/Instagram 앱이 실제로 수신하는 행동은 관찰되지 않음

    • WebRTC의 주된 활용 사례가 사용자의 로컬 IP 같은 정보를 가져와 익명성을 해제(디아노니마이즈)하는 것이라면, 왜 이런 기능이 별도의 권한 요청 없이 실행되는지 이해가 안 됨

    • 국가에 따라 something-embarassing.com 같은 사이트 방문이 민망함을 넘어서 훨씬 더 심각한 결과로 이어질 수 있음

    • 완전히 이해되는 것은 아니지만, 혹시 필수적인 GDPR 쿠키 동의 공지를 악용해서 사람들을 비밀스럽게 추적하는 것도 포함된 것인지 궁금함

  • 인터넷 광고와 추적을 그냥 금지하고 싶음
    이런 것들 때문에 의미 없는 것들이 너무 많이 쏟아져 나옴
    다 CEO들이 요트 한 척 더 사려고 생긴 문제라고 봄

    • Reddit도 기기 지문 수집을 상당히 많이 하고 있음
      이 데이터들을 AI 모델 학습용으로 판매도 하는 중
      곧 프리미엄 앱에서만 쓸 수 있는 비공개 데이터까지 적극적으로 판매하는 날이 올 거라 예상함

    • 이걸 어떻게 금지할 수 있을지, 또 누가 그 법을 어겼다는 걸 어떻게 증명할 수 있을지에 대한 고민이 남음

    • 브라우저에서 3rd-party 쿠키를 퇴출하자는 움직임이 실제적으로 가장 현실적인 첫 단계였음
      그런데 Google이 Chrome 지배력을 이용해 지난 해 이걸 좌초시켰음
      법적으로는 문제 없지만, 소비자 분노를 샀어야 할 비윤리적 시장조작임
      Google 임원진들은 처음엔 쿠키 없이도 수익 유지할 방법이 있다고 믿은 듯하고, 실제로는 쿠키의 의미를 전혀 이해 못 하거나, 혹은 애초에 제거할 생각이 없었을 가능성도 있음

    • 이런 형태의 행위는 순전히 탐욕임
      수 세기 동안 성공한 전통적 경영자들은 이런 식의 과도한 자기 이익 집착을 멀리했음
      보통 적당한 리더들도 이런 낮은 행동에서 벗어나 회사를 더 잘 이끌 수 있음
      하지만 탐욕만 남은 세상에선 그저 웃어넘길 수밖에 없는 상황임
      만약 더 정직하면서 뛰어난 CEO가 있다면 참 좋겠다는 생각임

    • 'CEO의 요트' 농담에 덧붙여, 사실 소비자들 대부분은 돈 내지 않아도 되는 서비스/제품이 좋아서 광고 모델을 선택함
      실제로 유료와 광고 버전이 있으면, 광고 지원 쪽이 10:1로 인기임
      광고 차단이 오히려 상황을 악화시킴 — 진짜 저항은 서비스를 불매하거나 대안에 직접 지불하는 방식이어야 함
      BAT(Brave Attention Token) 같이 직접 사이트에 소액 결제를 분배해주는 구조가 오히려 합리적이라고 생각함
      이론 자체는: 내가 쓰는 만큼 지불하고, 내가 광고주가 아니라 진짜 고객이 되는 구조임

  • 실제 이슈 리포트: Localmess 블로그
    Google은 남용 사례를 조사 중이라고 하는데, 역설적으로 Google 자체도 Wi-Fi AP 이름 같은 다양한 사이드 채널을 이용해 모두를 추적 중임
    대형 앱 기업은 OS 제한을 피하기 위해 유사한 방식으로 데이터 수집을 계속함

  • 또 하나의 이유: 빅테크의 앱은 되도록 설치하지 않고 꼭 써야 할 때만 웹사이트를 이용함
    웹사이트는 느리고 불편하긴 하지만, 샌드박스 처리로 훨씬 안전함

    • 어떤 Meta 앱이 포트를 여는지 명확하진 않음
      예를 들어 삼성폰은 여러 Meta 앱이 기본 탑재되어 있고, Facebook 앱만 지워도 com.facebook.services 등 숨김 서비스가 남아 있는 경우가 있음
      이 서비스들은 개발자 도구(ADB/UAD)로만 삭제 가능
      아니면 iPhone 또는 Pixel폰을 추천함

  • Meta Pixel 스크립트 관련 테크니컬 정보:
    Meta Pixel이 2024년 10월까지 HTTP로 송신했고, Facebook/Instagram 앱은 해당 포트에서 현재도 수신 대기 중
    새로 생긴 12388 포트로도 대기 중이지만, 해당 포트로 송신하는 스크립트는 아직 발견되지 않음
    이에 대해, 만약 다른 앱이 이 포트로 가짜 메시지를 보내도 될지 궁금하다는 과학적인(?) 궁금증이 있음

    • 이런 트래커들을 혼란시키는 방법은 두 가지가 있다고 봄
      한 번은 아무것도 보내지 않는 방법이고, 다른 하나는 거짓 데이터를 잔뜩 보내는 것
      광고주 추적 쿠키를 P2P로 공유하는 장치도 있으면 좋겠다고 생각함

  • 프로필 간에 이 트래킹이 넘어갈 수 있는지 궁금함
    만약 그렇다면 기업 입장에선 엄청난 보안 이슈임
    Userland 앱에서 8080포트로 서버를 띄워서 테스트해보니 두 프로필 모두 접근 가능했음
    이 말은 한 프로필에 감염된 앱이 다른 프로필에서 접속한 사이트와 데이터를 주고받을 수 있다는 뜻임

    • 단, 해당 사이트가 (인증 없는) 로컬 포트에 바운드된 서비스와 명시적으로 통신할 때 가능하지 않을까 하는 질문임

  • 이러한 방식으로 개인이 남의 컴퓨터에서 정보를 수집하면 CFAA(Computer Fraud and Abuse Act)로 처벌받을 수 있을지 궁금함

    • 이 방법은 한쪽(방문중인 사이트)과 상대방(폰에서 실행 중인 앱) 모두 코드 통제가 필요함
      그냥 마법처럼 임의의 브라우저 히스토리를 탈취하는 해킹 기법은 아님
      따라서 명확하게 해킹이라 보기 어렵고, Google/Meta 등에서 비동의 추적을 한다 해도 CFAA에 해당하진 않음

    • 사실 CFAA로는 단순히 브라우저에서 '페이지 소스 보기'만 해도 기소된 사람들이 있었음
      범죄 행위 자체보다는 누구를 건드렸는지, 네트워크와 관계가 더 중요한 듯함

    • 처벌 가능성 있음

  • 해당 ID 시스템은 악용이 너무 쉬웠고, Google도 이를 인지하고 반드시 남용 방지 규정을 만들어야 함을 알았을 거라 짐작함
    페널티(Play Store 영구밴, 법적 조치, 심지어 형사 고발 등)까지 이어질 수 있는 문제임
    하지만 현실적으로는 Meta 같이 규모가 너무 큰 기업이면 실질적 제재가 거의 불가능한 상태임
    (그리고 Meta가 아니더라도, 이런 수상한 움직임을 정보기관이나 법 집행기관이 암묵적으로 승인한 것일 수도 있음 — 문제를 멈추기는 매우 어렵고, 이야기하기조차 쉽지 않음)

    • Google과 Apple은 운영체제 전체를 소유하고 있음
      자체적으로 추적하는 방법이 50가지도 더 됨
      타 기업들도 사용자 데이터 공유 조항을 대형 기업과 재협상하면서 많은 돈을 벌어감
      이미 딜이 체결되고 권한도 받은 상황이고, 단지 일부 사용자가 이걸로 소란을 피운다는 것뿐임

  • Firefox에서 about:config에서 media.peerconnection.enabled 옵션을 false로 바꿔 WebRTC 차단 가능
    Netguard와 Nebulo를 non-VPN 모드로 조합하면 Meta 서버로의 불필요한 연결을 막을 수 있음

  • 유럽연합(EU)은 이런 문제에 대해 기록적인 수준의 벌금을 부과해야 한다고 생각함
    반복해서 문제를 일으킬수록 1~X%씩 누진적으로 올라가는 세금도 도입하면 좋을 듯함
    각 기업별 위반 사례를 한눈에 볼 수 있는 웹사이트도 동반 구축 필요성 느낌

    • Meta는 매년 벌금 내고도 700억 달러 정도의 순이익을 기록 중임

    • 벌금뿐 아니라, 어떤 경우엔 개인들도 훨씬 가벼운 위반으로 감옥에 간 사례가 있으니 더 강력한 조치도 필요성 존재

답변달기