구글의 또 다른 비밀 브라우저

 (matan-h.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Google Play Services 안의 숨겨진 브라우저가 Contacts 앱의 웹사이트 링크로 열리며, Google 자녀 보호의 일반 제한과 lock-down mode를 우회할 수 있음
  • 우회가 가능한 이유는 lock-down mode에서도 Google Play Services와 전화용 Contacts 앱이 남아 있고, Contacts가 여는 deeplink는 자녀 보호 차단을 받지 않는 구조에 있음
  • ` Android “what’s new” 화면으로 이어지며, Google 도움말과 Google 페이지를 거쳐 브라우저처럼 사용할 수 있음
  • Android 11+의 screen pinning도 Contacts 앱에서 ` 열어 Google Podcast 팝업을 띄운 뒤 기본 브라우저로 이동하는 방식으로 우회 가능함
  • Google은 자녀 보호 우회와 screen pinning 우회 신고를 별도 사례로 받았지만, screen pinning 우회는 intended behavior라고 답했고 중복 처리도 별도 보상 프로그램 문제로 돌림

Contacts 링크로 열리는 Google Play Services 브라우저

  • Google Play Services 안에는 링크로 접근 가능한 비밀 브라우저가 있으며, Contacts 앱의 연락처 웹사이트 필드에서 열 수 있음
  • 실행 흐름은 Contacts 앱에서 연락처를 편집하거나 새로 만든 뒤, “Website” 필드에 https://gds.google.com/gmsdrops를 넣고 저장한 다음 링크를 여는 방식임
  • 이 링크는 Android의 “what’s new” 화면으로 이어지는 deeplink임
    • “Show me”와 “Learn more”를 거치면 브라우저 화면에 들어갈 수 있음
    • 이후 햄버거 메뉴에서 “Google Help”를 누르고, 다시 메뉴에서 “Google”을 선택하면 Google 페이지로 이동 가능함
  • 이 브라우저는 Google 계정에 로그인돼 있을 수도 있고 아닐 수도 있음
    • 여기서 Google에서 로그아웃해도 Chrome 브라우저에는 영향이 없음
  • lock-down mode에서는 Google이 Android 런처와 시스템 일부를 포함한 앱들을 잠그지만, 팝업 표시와 제한 적용에 쓰이는 Google Play Services와 전화용 Contacts 앱은 남겨둠
  • 자녀 보호는 deeplink 열기를 허용하지 않지만, 연락처의 웹사이트 필드를 클릭할 때는 Contacts 앱이 링크를 열기 때문에 차단되지 않음

Android screen pinning 우회와 Google 응답

  • Android screen pinning은 Android 11+에서 특정 앱에 화면을 고정해, 허가 없이 다른 앱으로 이동하지 못하게 하는 기능임
  • 같은 gmsdrops 링크는 screen pinning 상태에서 새 앱을 여는 방식이라 사용할 수 없음
  • 대신 Google Podcast deeplink는 전체 앱이 아니라 팝업 창으로 열림
    • Contacts 앱의 웹사이트 필드에 https://podcasts.google.com을 넣고, 앱이 고정된 상태에서 링크를 열면 Google Podcast 팝업 창이 나타남
    • Google 계정 아이콘에서 “Content policies”를 누르면 기본 브라우저로 이동할 수 있음
    • 이후 Google Help와 Google 메뉴를 거쳐 Google 페이지로 이동 가능함
  • Google에는 두 건이 별도로 신고됨
    • 자녀 보호 우회 사례
    • Android screen pinning 우회 사례
  • Google은 자녀 보호 우회 건을 screen pinning 우회 건에 병합했고, 이후 중복 사례 처리가 혼동된 상태가 됨
  • screen pinning 우회에 대한 Google 답변은 “Android screen pinning bypassing is the intended behavior”였음
  • 중복 처리에 대해서는 “potentially another issue”의 중복으로 닫혔고, 별도 보상 프로그램이라 자신들의 문제가 아니라는 취지의 답변이 있었음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 보안 취약점 제보를 받는 팀이라면 “그건 다른 내부 팀 일이니 그쪽에 물어보라”고 해서는 안 됨
    사실 조직 내부의 거의 누구든 그럴듯한 취약점 제보를 받았다면 적절한 사람에게 전달되도록 해야 하고, 그냥 넘겨버릴 일이 아님

    • “다른 내부 팀”이라는 답은 취약점 자체보다 버그 바운티 쪽에 대한 말이었을 가능성이 커 보임
      그래도 반대로 보자면, 외부 고객이든 내부 이해관계자든 지원 업무는 폭탄 돌리기 같아서, 다른 사람에게 넘기지 못한 첫 사람이 데임
      모두가 실제 권한이나 책임이 누구에게 있든 고객 불만 해결을 맡아주면 좋겠지만, 현실에서는 많은 사람이 코펜하겐식 윤리 해석처럼 행동함
      책임자에게 전달하는 것조차 위험하고, 그 이상 관여하면 실제 관련성과 무관하게 문제에 얽혀 책임을 지게 됨
      이걸 주인-대리인 문제라고 부를 수도 있고, “요청자가 자기 요청에 응해줄 사람을 사냥하는 세상에서 살아남기”라고 부를 수도 있음
      예전에는 업무와 조금이라도 관련된 내부 요청을 다 처리하려 했지만, 직속 관리자가 1분 넘게 걸리는 도움에는 프로젝트 ID나 과금 코드를 요구하라고 했음. 안 그러면 실제로 돈 받고 해야 할 일을 못 하게 된다는 이유였음
    • Google은 “내 부서 아님”의 왕임
      “Google 안의 다른 부서 연락처는 모른다”, “Google의 다른 팀 누구의 이메일도 모른다”니, 대체 뭐 하는 건가 싶음
    • 이건 시스템 침해로 이어지는 의미의 취약점은 아닌 듯함
      OS에 추가한 기능의 설계 결함인 건 맞지만, 대규모 조사가 꼭 필요한 사안인지는 별개임
    • 그들이 말한 “그쪽에 물어보라”는 건 왜 이슈를 닫기로 했는지에 대한 것이고, 이미 누군가 검토했다는 뜻도 담겨 있음
      “우린 볼 생각도 없다”는 식으로 말한 건 아닌 듯함
    • 애초에 맞는 담당자를 어떻게 찾는지도 모르겠음
      우리 회사에서도 어떻게 해야 할지 감이 안 옴

  • 어릴 때 은행 같은 기관 로비에는 회사 웹사이트만 열리는 특수 브라우저가 깔린 컴퓨터 단말기가 있었고, 그 시절엔 Best Viewed In 배지도 흔했음
    부모님 심부름을 따라가면 그런 컴퓨터를 찾아 Help 페이지 같은 곳을 클릭하다가 그 배지를 찾았고, 그러면 단일 사이트 브라우저 제한을 우회해 netscape.com 같은 곳으로 나갈 수 있었음
    거기서 검색 엔진 링크를 찾아 원하는 곳을 둘러볼 수 있었음

    • Sears, CompUSA 같은 매장에 전시된 PC들이 데모 소프트웨어만 띄워놓고 정작 PC를 살 때 해야 할 일, 즉 실제 사용을 못 하게 하던 게 떠오름
      그래서 CTRL+ALT+DEL로 작업 관리자를 열어 데모 소프트웨어를 죽이곤 했음
      더 끈질긴 데모는 바로 재실행되니 msconfig를 열어 시작 프로그램에서 빼고 재부팅했음
      옆에서 보던 사람들이 놀라워하며 자기 PC도 그렇게 해달라고 부탁했고, 그러면 그들도 지뢰찾기나 핀볼을 해볼 수 있었음
      지금은 아마추어처럼 들리지만, 90년대 중반의 CTRL+ALT+DEL은 숙련자만 아는 일종의 파워 도구였음
    • 고등학교 컴퓨터에서 웹 필터를 우회하던 기억이 남
      MS Word에서 URL 열기를 선택하고 검색 엔진이나 원하는 사이트를 입력하면 브라우저가 열리면서 웹 필터를 피해갈 수 있었음
    • 예전에는 도서관에서 여러 edu 호스트에 telnet으로 접속하곤 했음
      그 서버들은 보통 motd를 more로 보여준 뒤 lynx 같은 소프트웨어로 넘겼지만, restricted mode를 쓰지 않아서 !sh를 입력해 셸을 열 수 있었음
      좋은 시절이었음
    • 대학 때 체육관 컴퓨터에도 이런 제한이 있었음
      웹으로 이메일을 열 수 있었기 때문에, 검색 엔진 링크를 내게 메일로 보내고 이메일에서 우클릭해 같은 프레임에서 열었음
      그 뒤로는 검색 결과에서 찾을 수 있는 곳이면 어디든 갈 수 있었음
    • “Best Viewed In” 배지가 어떤 것인지 잘 모르겠고, 그걸로 어떻게 우회가 됐는지 궁금함
      2000년대 고등학교에서 제한을 우회하던 경험은 있어서, 지나가는 누군가가 자세히 설명해주면 좋겠음

  • Google의 자녀 보호 기능은 아쉬운 점이 너무 많음
    Play Store 앱 비활성화 요청이 오래전부터 있었지만 아직도 adb 없이는 불가능하고, adb는 다른 문제를 낳기 때문에 좋은 해법이 아님
    실제 아이들이 자녀 보호 기능을 테스트하지 않는 느낌임
    한동안은 YouTube 시간 제한을 걸어도 Play Store를 열고, 스크린샷 목록에 동영상이 있는 앱으로 가서 거기서 YouTube로 넘어가면 아주 쉽게 우회됐음
    아들이 직접 발견해서 보여줬음

    • Google 자녀 보호 기능은 사실상 방치된 소프트웨어에 가깝고, 동작도 서툴며 Google Home이나 Google TV 같은 다른 제품·서비스와도 잘 통합되지 않음
      이 문제를 정리한 5쪽짜리 문서를 써놨지만 보낼 사람이 없음
      가장 큰 불만은 유아가 아닌 큰 아이 둘과 여러 Google 기기, 즉 휴대폰, 태블릿, Google TV, Google 계정으로 로그인한 PC가 함께 있을 때 생김
      Google은 자녀 보호를 “Billy의 폰을 부모가 물리적으로 건네주고 끝나면 돌려받는” 감독 상황으로 상정하는 듯함
      근본적으로 계정 수준이 아니라 기기 수준이라 번거롭고 우회도 쉬움
      예를 들어 Jill이 집 안의 Google TV 3대에 자기 계정으로 접근할 수 있다면, Family Link는 각 TV에서 하루에 몇 시간을 허용할지 따로 설정하게 함
      하지만 Jill에게 TV는 그냥 TV라서, 혼자 집에 있으면 첫 번째 TV의 할당량을 다 쓰고 다음 TV로 옮겨갈 뿐임
      근거는 없지만, 서로 다른 제품팀이 실제로 긴밀히 협업하지 않거나 오히려 협업하지 않도록 보상받는 것 같고, 이런 팀들은 Google 안에서 막다른 팀일 수도 있음
      Family Link 팀에 오는 제품·엔지니어링 담당자들이 실제 아이가 없거나 너무 어리고, 있어도 어린아이 하나 정도만 있는 것 같음
    • “실제 아이들이 자녀 보호 기능을 테스트하지 않는 느낌”이라는 말은 접근성 서비스에도 그대로 적용된다고 봄
      접근성 권한을 얻는 순간 사용자 기기를 완전히 제어할 수 있음
      권한을 나눠 더 세밀한 제어 API를 노출할 수도 있었을 텐데, 완전히 시각장애가 있는 사용자가 접근성 앱을 모든 상호작용의 인터페이스로 써야 하는 아주 극단적인 사례를 중심으로 설계한 듯함
      그 결과 그 API의 어떤 기능 하나만 쓰고 싶어도 앱을 완전히 신뢰하고, 기기에서 무엇이든 할 수 있는 백지수표를 줘야 함
      결국 “우리가 의도한 사용 시나리오는 이것뿐이고 다른 용도는 타협하지 않는다”는 이유만으로 플랫폼 보안에 거대한 구멍이 생김
    • 자녀 보호 기능은 묘한 물건임
      또래 집단에서 완전히 격리하려고 지하실에 가두는 게 아니라면, 조금만 관심 있는 아이에게도 기술적으로는 거의 이길 수 없음
      이 기능은 부드러운 한계선으로 가장 잘 동작함. 우회하면 명백하고 애매하지 않은 불복종이 되도록 하는 정도임
      결국 자녀 보호 기능이지 NSA를 막는 보안이 아니고, 기술적으로 완벽하게 만드는 건 모두에게 더 나쁠 수도 있음
    • Android나 iOS에서 자녀 보호 기능을 실제로 많이 쓰는 사람은 별로 없다고 봄
      소비자가 더 안전하다고 느끼게 하려고 들어간 기능이지만, 실제로 쓰려 하면 금방 포기하게 됨
      작은 예로 iOS Screen Time에서는 웹사이트를 허용 목록으로 제한할 수 있어 유용해 보이지만, 그렇게 하면 여러 앱의 로그인 화면 같은 것이 잔뜩 깨짐
      무엇을 고치려면 어떤 URL을 허용해야 하는지 단서도 주지 않음
      현대 기술을 쓰다 보면 “이건 너무 복잡하고 망가져 있어서 실제 사용자가 많을 리 없다”는 생각이 들 때가 있는데, 자녀 보호 기능이 딱 그런 느낌임
    • 예전에는 자녀 보호 기능을 썼지만 이제는 그만뒀음
      결국 부모의 대체품일 뿐임
      아이에게 관심을 갖고 뭘 하는지 알거나, 아니거나 둘 중 하나임
      아이가 웹의 무언가에 취약하다고 생각한다면 애초에 휴대폰을 주지 않는 편이 맞을 가능성이 큼
      아이가 충분히 이해할 나이라면 필요한 건 소프트웨어 자녀 보호가 아니라 부모이고, 좋은 부모라면 아이 앱에 자녀 보호 기능이 필요하지 않음
      자녀 보호 기능은 다른 출처에서 앱을 설치하는 것도 막는데, Play Store 앱보다 F-Droid 앱을 선호함
      마지막으로, 이 기능은 우리가 어떤 소프트웨어 회사에 의해 통제되고 “위험에서 보호받는다”는 환상을 가르치고 훈련하며 강화함

  • 이건 Windows 98 로그인 화면 우회 같은 해킹 트릭임
    https://i.imgur.com/BULPmCI.gif
    솔직히 Google이 시스템 설계에서 Microsoft Windows 98 수준으로 나빠질 줄은 예상하지 못했음

    • 훌륭한 익스플로잇인 이유는 버퍼 오버플로 같은 난해한 지식을 몰라도 되기 때문임
      일반 사용자도 절차를 따라 할 수 있음
      보안의 상당 부분은 생각해야 할 것을 줄이기 위해 공격 표면을 최소화하는 일 같음
      로그인 대화상자에서 툴팁을 인쇄할 수 있어야 할 이유가 대체 뭔가 싶음
      인쇄가 들어오는 순간 안전하지 않은 온갖 서드파티 요소가 함께 들어옴
      툴팁이나 도움말 인쇄를 허용하더라도 그런 기능이 꺼지는 보안 컨텍스트를 뒀어야 함
      PDF도 비슷해서, 3D 모델이나 스크립팅 같은 임의 기능의 99%는 보안 익스플로잇에 쓰였음
      기본은 단순하게 두고 그런 기능은 피하는 게 좋음
    • 이건 잠금 화면을 우회하는 건 아님

  • 이 고전 짤이 떠오름: https://imgur.com/BULPmCI?r

    • 바로 그 생각이 났음
      Craigslist에서 중고로 산 Pixel 2의 FRP 우회에 원문과 비슷한 기법을 쓴 적이 있음
      어릴 때 지루해서 이 화면을 몇 시간씩 들여다보다가 결국 뚫고 들어가 첫 “손맛”을 봤던 순간이 내 인생 전체의 방향을 잡아준 것 같다는 생각도 들었음

  • 내 첫 “해킹”과 컴퓨터 시스템 내부를 만지던 경험이 떠오르고, 그게 IT와 엔지니어링 경력으로 이어졌음
    Halo PC를 불법 복제하다 트로이목마로 가족 컴퓨터를 망가뜨렸고, 아버지가 집에 오기 전에 고치는 방법을 알아내야 했음
    부모님이 우리 개인 컴퓨터에 갑자기 NetNanny 같은 자녀 보호 기능을 설치했을 때도 우회해야 했음. 이미 몇 년 동안 인터넷을 쓰던 뒤였고, 아마 위의 허술한 불법 복제 때문에 Comcast에서 편지가 왔을 수도 있음
    수정 흔적을 남기지 않고 넷북을 다시 쓸 만하게 복구하는 과정에서 Linux Live CD와 Linux를 접했음
    내일의 해커들도 여전히 그런 교육을 받고 있다니 반가움

    • 비슷하게, National Capital Feenet's](https://www.ncf.ca/en/)'s) Gopher 페이지를 꽤 오래 뒤지던 기억이 있음
      임의의 telnet 연결을 만들 수 있는 링크의 링크의 링크를 찾아서, 무료 전화접속 서비스를 자기들 서비스에만 쓰게 하려던 제한을 우회하려 했음
      예컨대 tamu.edu의 공개 서버에서 Nethack을 하려던 것인데, 정확한 도메인 이름은 이제 기억나지 않음
    • NetNanny 우회는 확실히 내 컴퓨터 실력을 올려줬음
      고전적이었음

  • 관련된 이전 글도 있음
    Google has a secret browser hidden inside the settings - https://news.ycombinator.com/item?id=36478206 - 2023년 6월, 댓글 312개

  • Google Play Services가 자신에게 새 권한을 부여할 수도 있다고 읽었음[1]
    이게 어떻게 가능한가? root 권한이 있는 건가?
    [1]https://developers.google.com/android/guides/permissions

    • root는 아니지만 권한 있는 시스템 앱이라서, 설치 앱이 root 없이 할 수 없는 일을 거의 공장 한가득 할 수 있음
    • 시스템 앱이나 벤더 앱도 manifest에 권한을 미리 정의해야 하므로 모든 시스템 앱이 모든 일을 할 수 있는 건 아님
      하지만 그런 앱들이 접근 가능한 권한 목록이 너무 넓어서, 개발자가 충분히 많이 정의해두면 사실상 root처럼 쓸 수 있음
    • 맞음
      실제 root 사용자는 아니지만 맹목적으로 신뢰받고, 사용자 확인 없이 앱 설치 같은 일을 할 수 있음
      GMS에 관한 다른 블로그 글에서 다룬 것처럼, JS 브리지는 특권 범위에서 실행될 수 있음
      Android를 설치할 때 Google 개인정보처리방침에 동의하면서 여기에 동의한 셈임
    • 다행히 권한 있는 앱이 아니라 샌드박스 안에 설치할 수 있음
      예를 들면 GrapheneOS에서 가능함
    • 이건 백도어라고 부르는 게 맞음
      이미 사용자 허락 없이 앱을 설치하고 제거할 수도 있음
      과거에 이걸로 문제가 된 적도 있지만, 충분한 일이 벌어지지는 않았음

  • 샌드박스 처리된 Play Services를 쓰는 GrapheneOS는 영향이 없어 보임
    Phone 앱은 연락처의 웹 URL을 보거나 열 수 없는 것 같고, Contacts 앱도 고정 모드에서 글에 나온 두 URL을 여는 데 실패함

  • 2023년의 이전 논의가 궁금하다면 여기 있음, 댓글 312개
    https://news.ycombinator.com/item?id=36478206

답변달기