▲

Google의 대대적인 안티-애드블록 업데이트 우회 방법

 (0x44.xyz)
1P by GN⁺ 22시간전 | ★ favorite | 댓글 1개
  • Chrome의 MV3 업데이트는 기존 애드블로커의 기능을 약화시키기 위해 webRequestBlocking 권한을 제거함
  • 필자는 MV3 환경에서도 webRequestBlocking을 우회할 수 있는 버그를 2023년에 발견함
  • 이 버그는 JavaScript 바인딩의 허술한 구조와 옛날 코드가 그대로 남아 있었기 때문에 발생함
  • WebView 인스턴스 ID를 조작해 권한 체크를 우회함으로써 MV3 환경에서도 블로킹 기능을 사용할 수 있었음
  • 현재는 패치가 적용되어 더 이상 이 우회 방법이 작동하지 않음

MV3와 애드블로커 변화

  • Chrome은 MV2 익스텐션을 단계적으로 폐지하고, 대신 MV3로 전환을 진행함
  • MV3는 webRequestBlocking 권한을 제거하여, 애드블로커가 네트워크 요청을 스크립트로 동적으로 차단하는 것을 막음
  • 해당 권한이 빠진 대신 declarativeNetRequest API가 추가됐지만, 같은 수준의 유연성을 지원하지 않음
  • 이 변화로 인해 애드블로커의 성능이 대폭 낮아지는 현상이 나타남

JavaScript 바인딩 구조의 한계

  • Chrome은 코어는 C++ 로 개발되어 있지만, 익스텐션은 JavaScript로 동작하며, 확장 API도 JS 바인딩을 통해 접근함
  • 2015~2016년까지는 사이트에 JS 파일(익스텐션 바인딩 모듈)을 삽입해 API를 초기화하고 검증함
    • 이 방식은 JS 전역 함수·프로토타입 오버라이딩에 취약하여 Universal XSS 버그 여러 건이 발생함
  • 이후 Google은 주요 바인딩을 C++로 이전했으나, 일부 JS 바인딩 파일은 여전히 남아 있음
  • 아직까지도 chrome.webRequest와 같은 특정 API는 JS 바인딩 구조를 사용하고 있음

웹 요청 이벤트 클래스를 활용한 우회

  • MV2에서는 웹 요청 차단이 아래 코드로 구현 가능했음

    chrome.webRequest.onBeforeRequest.addListener(() => { return { cancel: true } }, { urls: ['*://*.example.com/*'] }, ['blocking'])

  • MV3에선 blocking 옵션이 금지되어 정상적 차단이 불가능함

  • 하지만 webRequest 이벤트의 .constructor를 통해 임의의 이벤트 객체를 생성할 수 있음

  • 내부적으로는 JS 바인딩의 특수 래퍼 클래스가 이 이벤트 객체를 관리함

  • 생성자 파라미터 중 하나인 opt_webViewInstanceId를 지정하면, 플랫폼 앱 전용 허용 로직을 우회하여 블로킹 권한 체크를 뛰어넘을 수 있음

    let WebRequestEvent = chrome.webRequest.onBeforeRequest.constructor
let fakeEvent = new WebRequestEvent("webRequest.onBeforeRequest", 0, 0, 0, 1337)

fakeEvent.addListener(() => { return { cancel: true } }, { urls: ['*://*.example.com/*'] }, ['blocking'])

  • 원래 플랫폼 앱만 사용할 수 있도록 설계되었지만, WebView ID 검증이 미흡하여 일반 익스텐션에서 악용 가능했음

결과 및 보안 패치

  • 이 취약점으로 MV3 환경에서도 완벽한 애드블로커 개발이 실제로 가능했음
  • 필자는 해당 버그를 2023년 Google에 보고했고, Chrome 118에서 WebView 권한 소유 여부를 제대로 확인하는 방식으로 패치됨
  • 보상금은 지급되지 않았으며, 이는 추가 데이터 노출 없이 권한 우회만 가능했던 구조적 특성 때문임
  • 본 사례는 수십 줄의 코드 수정이 거대 기업의 보안 업데이트를 무력화할 수 있음을 보여줌

결론 및 참고

  • 버그는 현재 패치되어 더 이상 작동하지 않음
  • 유사하게 흥미로운 Chrome 익스텐션 관련 취약점 사례로, 실제로 CVE 번호와 $10,000 보상을 받은 이슈도 존재함 (별도 블로그 글 참조)
▲
GN⁺ 22시간전  [-]
Hacker News 의견

  • Firefox를 한번 써보고 싶음에도 불구하고, 간혹 발생하는 웹사이트 로딩 버그와 더불어 PWA(Progressive Web Apps)를 설치할 수 없다는 점이 가장 큰 걸림돌임. Chrome과 그 계열 브라우저는 오래전부터 이 기능을 지원해왔는데, 왜 Firefox는 아직 구현하지 않았는지 잘 모르겠음. 서드파티 확장 프로그램(PWAs for Firefox)을 찾긴 했지만, 개인정보 보호 측면에서 사용하는 게 꺼려짐

  • Google의 행동을 우회하는 방법이 있더라도, 그건 올바른 방향이 아니라고 생각함. 만약 사람들이 Google의 움직임에 동의하지 않는다면, Chrome 및 Chromium 기반 브라우저를 모두 버리는 게 유일하게 올바른 방법임. Google의 독점에 타격을 주어 웹의 미래 방향에 대한 지배력을 빼앗는 것이 중요함

    • 오늘날의 독점은 모두가 IE에서 얻어야 했던 교훈을 잊은 탓이라 생각함. Web 표준을 배우지 않고 Chrome을 애플리케이션에 번들로 함께 배포하는 행태가 원인임
    • 기사 요지는 이게 아니고, 실제 기사에서는 이 우회법이 Chrome 118에서 패치됐다고 언급함
    • "독점에 타격을 줘야 한다"라고 해서 실제로 뭔가 달라진 적이 있냐고 비꼬고 싶음
    • 현실적으로 그런 일은 일어나지 않을 것임
    • 많은 사람이 Google 추적 기능이 제거된 Chromium 브라우저로 갈아타는 건 충분치 않다고 여기는데, 사실 그건 Google이 오히려 바라는 프레임이라고 생각함. Firefox는 Chrome과 확실히 다르고 Chrome에서 넘어오기가 쉽지 않음. 반면 Brave, 커스텀 Chromium, Vivaldi 등은 Google 추적 없는 Chrome 수준이라 거의 동일함. "Google이 여전히 Chromium을 통제하고 있어 안된다"는 주장이야말로 Google 입장에서 유포할 만한 FUD(공포, 불확실성, 의심)라고 봄

  • 진정한 우회는 Firefox를 쓰는 것임. uBlock Origin이 Firefox에서 가장 잘 작동함
    uBlock Origin works best on Firefox

    • 나는 늘 Firefox를 써왔기 때문에 이런 일이 일어나는 줄도 몰랐었음. 아내가 YouTube에서 광고를 본다고 해서 보니, 예전에 uBlock을 설치해줬는데도 그랬던 것임

  • Google이 MV3가 MV2보다 진짜 더 안전한지도 의문임. MV3로 바꾼다고 본질적으로 보안이 더 강화되는 게 아닌 것 같음

    • 솔직히 이걸 정말 믿는 사람이 있을지 놀랍게 느껴짐. 기사 자체도 명백한 이해 상충으로 시작함. 어떤 확장 프로그램이 사용자가 방문한 사이트와 요청 정보를 알 수 있도록 두는 건 확실히 취약한 환경임. 그럼에도 불구하고, 나는 광고회사와 데이터 수집업체들보다 uBO를 더 신뢰하기 때문에 그냥 그렇게 쓰는 중임

  • 누군가 adblocker 우회법을 찾아내서 Google에 알려준 경우에 대해, “찾아내고 바로 Google에 고자질하는군, 멋지다”는 반응이 있음

    • 사실, adblocker가 이걸 이용하기 시작했다면 Google이 즉각적으로 패치했을 거고, 해당 개발자는 아무 이득도 얻지 못했을 것임. 결국 아무것도 얻지 못하긴 마찬가지였다는 점이 아이러니임

  • OP가 Google에 아무 문제 없는 “이슈”를 보고해서, 애드온 개발자가 MV3 제한을 우회할 수 있는 방법을 막았음. $0의 가치가 있었기를 희망함

    • 이런 우회법은 길어야 하루 안에 Google에게 바로 제거됐을 것임. 오히려 OP가 금전적 보상을 받을 수도 있었으니, 충분히 할 만했다고 생각함. 비난하고 싶지 않음
    • 결론에 동의하지 않음. 모든 책임은 Google이 지는 것이 맞음. 만약 OP가 이슈를 알리지 않았다면, 나중에 다른 adblocker가 이 방법을 써도 Google이 금방 이걸 금지했을 거라 봄. 어쩌면 해당 확장 프로그램 자체를 Web Store에서 아예 삭제하는 극단적 조치도 했을 수 있음
    • 실제로 사람들이 사용하던 adblocker가 이 방법을 구현했다면, Google은 당연히 바로 막았을 것임. 무한정 활용 가능한 치트키 같은 게 아님
    • 나도 같은 생각임. OP는 대기업을 위해 공짜로 일해준 셈이고, 결과적으로 웹 환경을 더 불편하게 만들었음. 이유는 뭐... "보안 때문"이라고 하겠지. 대단함

  • Brave를 쓰기 시작한 뒤로 Chrome이 전혀 그립지 않음
    Brave

    • 오히려 Brave가 Chrome보다 더 불편함. Brendan Eich의 문제도 있지만, 브라우저 안에 각종 임의 기능, 광고 차단(Brave Shields)을 완전히 끌 수도 없고, 암호화폐 관련 요소, 끌 수 없는 웹앱 다운로드 버튼, 지울 수 없는 UI 등 쓰레기가 너무 많음
    • Brave는 여전히 영리 기업이고, 기본적으로 불필요한 기능들이 과하게 많다는 점에서 거부감을 느낄 수밖에 없음. 하지만 "Brave 다이어트 하는 법"처럼 설정을 슬림하게 바꾸는 팁 콘텐츠도 적지 않음
    • 엔진은 결국 Blink라서 외관만 바뀐 셈임. Manifest V2를 계속 유지하는 Blink 브라우저는 본 적 없음. 만약 있다 해도, 그건 소프트 포크라서 오래 못 버팀
    • Brave도 결국 Chromium 기반이니까, Chrome과 사실상 마찬가지임. Manifest V3는 결국 적용될 수밖에 없음
    • Brave 브라우저를 쓰지 말라는 비판적 시각도 있음
      Stop using Brave browser

  • "adblocker는 webRequestBlocking이 꼭 필요하다, Google이 광고로 수익을 내니 이 기능을 뺀 건 매우 의도적이다"라는 주장에, "사실이 아니고 누구나 uBlock Origin Lite를 Chrome과 manifest v3에 쓸 수 있으며, 성능은 좋고 기존 uBlock Origin과 차이를 못 느끼겠음. 모두 C++에서 필터링되어 훨씬 빠름. 물론 rule 최대치 제한이 있지만 지금은 충분히 감당 가능한 수준"이라는 의견도 있음

    • 그렇지만 Lite는 Lite이기 때문에 가능성이 제한돼 있음. 그 자체로 원래 adblocker가 아니기에 완전히 같지는 않음

  • 업무용 노트북 외에는 크롬을 쓸 일이 없고, 평소에는 Firefox를 계속 쓰는 중임. 그래도 업무상 웹 서핑(자료 조사, 문서 등)에 도움 됐던 uBlock Origin을 못 쓰게 되는 점이 아쉬움

  • 그냥 우회를 원한다면 Firefox를 설치하면 됨

    • Firefox는 웹브라우저로서도, 베이스로서도 별로라고 생각함. Zen이 Chromium을 쓰지 않은 것이 안타까움
답변달기