Linksys Velop 라우터, Wi-Fi 비밀번호를 평문으로 미국 서버에 전송

 (stackdiary.com)
2P by GN⁺ | ★ favorite | 댓글 2개
  • 벨기에 소비자단체 Testaankoop은 Linksys Velop Pro 6E와 Velop Pro 7 메시 라우터가 Wi-Fi 로그인 정보를 평문으로 미국 AWS 서버에 전송한다고 밝힘
  • 설치 점검 중 전송된 패킷에는 설정된 SSID와 비밀번호, 네트워크 식별 토큰, 사용자 세션용 액세스 토큰이 포함됨
  • 테스트는 당시 최신 펌웨어에서 이뤄졌고, Linksys가 2023년 11월 경고 뒤 펌웨어 업데이트를 냈지만 문제가 해결되지 않음
  • 영향을 받는 사용자는 앱 대신 웹 인터페이스로 Wi-Fi 네트워크 이름과 비밀번호를 바꾸면 읽을 수 있는 텍스트 전송을 막을 수 있음
  • Testaankoop은 해당 모델 구매를 강하게 권하지 않았으며, Velop 제품군이 소규모 사무실에도 권장된다는 점에서 개인·업무 환경 모두에 우려가 있음

평문 전송이 확인된 Velop 모델

  • 벨기에 소비자단체에 해당하는 Testaankoop은 두 종류의 Linksys 라우터가 Wi-Fi 로그인 정보를 평문으로 Amazon AWS 서버에 전송한다고 확인함
  • 대상 모델은 Linksys Velop Pro 6E와 Velop Pro 7 메시 라우터임
  • 일상적인 설치 점검 중 미국 AWS 서버로 여러 데이터 패킷이 전송되는 것이 감지됨
    • 패킷에는 설정된 SSID 이름과 비밀번호가 평문으로 들어 있었음
    • 더 큰 데이터베이스 안에서 네트워크를 식별하는 토큰도 포함됨
    • 사용자 세션용 액세스 토큰도 함께 전송됨
  • 이 전송 방식은 중간자 공격(MITM) 가능성을 키울 수 있음
    • 공격자가 Linksys 라우터와 Amazon 서버 사이 통신을 가로채면, 평문으로 전송되는 SSID와 비밀번호를 캡처할 수 있음
    • 네트워크 이름과 비밀번호를 읽거나 변경하고, 네트워크에 무단 접근할 위험이 생김

펌웨어 상태와 사용자 대응

  • Testaankoop은 테스트 당시 사용 가능한 최신 펌웨어로 검사를 수행함
    • Velop 6E는 여러 차례 테스트됐고, 마지막 테스트는 V 1.0.8 MX6200_1.0.8.215731 펌웨어에서 진행됨
    • 새 Velop Pro 7은 1.0.10.215314 펌웨어에서 테스트됨
  • Linksys는 2023년 11월 첫 경고 이후 펌웨어 업데이트를 냈지만, Testaankoop이 제기한 우려는 해결되지 않음
  • 보안 문제는 Linksys 펌웨어에 사용된 서드파티 소프트웨어에서 비롯됐을 가능성이 있지만, Testaankoop은 이것이 취약점을 정당화하지는 않는다고 봄
  • 이미 해당 라우터를 보유한 사용자는 앱 대신 웹 인터페이스로 Wi-Fi 네트워크 이름과 비밀번호를 변경하는 것이 권고됨
    • 이 조치는 SSID 이름과 비밀번호가 읽을 수 있는 텍스트로 전송되는 것을 막기 위한 예방책임

Linksys 대응과 구매 권고

  • Testaankoop은 발행 며칠 전 Linksys에 다시 연락해 짧은 응답 기회를 줬지만, 제조사로부터 확인이나 해결책을 받지 못함
  • Stack Diary도 7월 9일 Linksys에 대응 계획을 문의했으며, 7월 14일 기준 답변을 받지 못함
  • 긴 테스트 이후 Testaankoop은 Linksys Velop Pro WiFi 6E와 Pro 7 구매를 강하게 권하지 않으며, 네트워크 침입과 데이터 손실 위험이 심각하다고 결론냄
  • Velop 시리즈 같은 메시 라우터는 여러 연결 노드로 넓거나 여러 층의 집에서 Wi-Fi 분포를 개선하도록 설계됐지만, Velop Pro WiFi 6E와 Pro 7의 데이터 전송 방식은 제공해야 할 보안 이점을 약화함

함께 보면 좋은 글 β

halfenif   [-]

지원 요원이 비밀번호를 잊어버린 사용자를 도울 수 있도록 하기 위한 것이라는 변명

아...

답변달기
GN⁺   [-]
Hacker News 의견들

  • 이 댓글들을 읽어보면, 다들 비밀번호를 서버로 보내는 것은 괜찮고 암호화가 없는 것만 문제라고 보는 건가?
    애초에 비밀번호가 서버로 전송될 거라고 기대하지 않음

    • 어느 정도 관련 있음: 2013년 글인데, Google이 전 세계 WiFi 비밀번호를 안다는 내용임: https://www.computerworld.com/article/1496628/android-google...
    • 전혀 괜찮지 않음. 라우터가 사용자가 명시적으로 설정한 경우가 아니라면, 정체 모를 서버로 어떤 데이터도 전송해서는 안 된다고 봄
      그런 일을 하는 라우터는 목적에 맞지 않는 제품이고, 사실 Linksys 라우터는 이미 몇 년 전부터 전반적으로 쓸 만한 제품이라고 생각하지 않았음
    • 개발자들이 이에 동의하지 않아서 내부적으로 의도적 방해를 한 것 아닐까 싶음
      평문은 쉽게 관찰되고 사람들이 알아낼 수 있어서 홍보 타격을 만들 수 있지만, 암호화된 비밀번호는 사실상 추적하기 어려움
    • 나도 괜찮지 않음. 라우터 설정에 휴대폰 앱 사용을 요구하는 것조차 마음에 들지 않음
    • 이 글은 중간자 공격 취약점을 길게 다루지만, 애초에 왜 중간자가 있어야 하는지, 왜 Amazon이 끝단에 사람을 둘 권한이 있는지는 설명하지 않음

  • TR-69 메커니즘을 통해 Verizon FiOS 라우터는 로컬 WiFi 비밀번호를 중앙 관리 시스템으로 보냄
    들은 변명은 “비밀번호를 잊은 사용자를 지원 담당자가 도울 수 있게 하려는 것”이었음 :-/

    • 솔직히 꽤 말이 됨. 지원에서 절약되는 시간이 보안 사고 수습 비용보다 훨씬 클 가능성이 높음
    • 그뿐만이 아닐 것임. 아마 전 세계에서 고객에게 WiFi 라우터가 내장됐든 아니든 모뎀을 제공하는 거의 모든 인터넷 서비스 제공업체가 같은 일을 할 것임
      덧붙이면, 제공업체 앱에서 제공 장비의 비밀번호를 바꿀 수 있다면, 높은 확률로 그 비밀번호는 적어도 TCP/TLS 패킷 안에서 평문으로 오갈 것임
    • 완전히 미친 일임
      예전부터 통신사 제공 라우터를 쓰지 않던 습관이 다행스럽게 느껴짐
    • 지금까지 써본 모든 WiFi 라우터는 리셋 버튼을 몇 초간 누르면 하드 리셋이 되고, WiFi가 기본 비밀번호로 돌아갔음
      그 다음 라우터에 로그인해서 새 비밀번호를 설정하면 됨
    • WiFi 비밀번호의 불편함은 WPS가 해결책일 거라고 생각했음
      내가 인터넷 서비스 제공업체이고 WiFi 비밀번호 관련 지원 요청을 너무 많이 받는다면, WPS를 더 쓰는 쪽을 고민할 것 같음

  • 라우터 업계가 안정적인 로컬 네트워크 장비 대신 스마트 기기로 변한 흐름이 정말 싫음
    다른 업계에서 보던 고객 착취가 여기서도 똑같이 벌어짐. 예를 들어 TP Link는 Roku 같은 회사처럼 라우터에서 다크 패턴을 쓰고, 서비스 약관을 업데이트한 뒤 앱을 쓰려면 팝업에서 수락하도록 강제함
    앱은 대부분의 라우터 설정 기능에 접근하는 유일한 방법이고, 예전처럼 비밀번호로 보호된 웹페이지에 접속해 설정하는 방식과 다름. 새 약관을 받아들이지 않으면 지금까지 제어하던 라우터를 더 이상 제어할 수 없음
    게다가 앱 안에서는 메뉴 항목이나 사용자 인터페이스 요소 옆의 빨간 원형 배지 같은 유도 장치로 쓸모없고 원치 않는 서비스 체험판을 계속 밀어붙임
    Linksys처럼 내 개인정보와 보안을 남용할 수 있게 하는 약관이 들어 있어도 놀랍지 않음
    그런데 어디로 가야 하나? 모든 회사가 이렇게 하고 있음. 아마 이 없이는 생존이 안 되는지도 모름. 그래서 보안 침해에 대한 책임, 서비스 약관 남용 제한 같은 규제가 필요해 보임

  • 이게 실제로 평문인가, 아니면 HTTPS 안의 평문인가? 글과 원자료에서는 말하지 않음
    비밀번호가 HTTPS 요청 안에서 “평문”인 건 꽤 일반적임. 거의 모든 웹 앱 로그인이 그렇게 동작함
    HTTPS가 아니라면 요청 안에 평문 비밀번호를 넣는 것 외에도 다른 문제가 잔뜩 있음
    HTTPS라면 진짜 문제는 비밀번호가 로컬에 머물지 않고 어딘가로 전송된다는 점임. 이 관행은 논쟁의 여지가 훨씬 크지만, 안타깝게도 많은 라우터가 클라우드/앱 관리 기능을 지원하려고 흔히 하는 일이기도 함

    • 관리 기능을 지원하는 데 왜 클라우드가 WiFi 비밀번호를 알아야 하나?
      지금 떠오르는 이유는 메시 구성을 위해 두 번째 장치를 더 “자동”으로 설정하거나, 공장 초기화 후에도 같은 비밀번호를 쓰게 하려는 경우뿐임. 둘 다 더 나은 해결책이 있음
      새 비밀번호를 설정하려는 거라면 왜 기존 비밀번호가 필요한지 모르겠고, 원격 관리 접근 자격증명으로 WiFi 비밀번호를 쓰는 거라면 내 네트워크 접근 권한이 곧 관리 권한이 되어서는 안 되므로 나쁨
      실제로 필요하다면 충분히 솔트를 넣고 해시한 비밀번호만 보내는 식으로 훨씬 낫게 할 수 있음
    • 가로챘다면 진짜 평문이었다고 봐야 함
      Linksys 서버 인증서의 개인 키에 접근할 수 있었다면 그게 훨씬 더 큰 뉴스였을 테니까

  • 소비자 테스트 기관이 이걸 찾아낼 만큼 기술 전문성을 갖췄다는 점이 인상적임
    소비자가 쓰듯이 사용해서는 발견할 수 없고, 보안 버그를 찾기 위해 일부러 노력해야 알아챌 수 있는 문제였음

  • WiFi 라우터 제조사들이 OpenWRT를 쓰면 정말 좋겠음
    원하면 gli.net처럼 스킨을 입히면 되고, 최소한 기반은 OpenWRT를 쓰면 됨. 공개되어 있고, 잘 동작함
    제품 차별화는 안테나를 더 많이 달고 속도 숫자를 전부 더해서 정말 빨라 보이게 만드는 식으로 계속할 수 있음

    • 몇 시간 전에 다른 이유로 알게 됐는데, 실제로 그런 곳이 적어도 하나 있음. GL.iNet은 자체 빌드한 OpenWRT를 실행하는 라우터를 판매함
      https://www.gl-inet.com/support/firmware-versions/
      https://github.com/gl-inet/openwrt
      그리고 OpenWRT의 sysupgrade 방식으로 순정 OpenWRT를 설치하는 것도 간단함
      https://openwrt.org/toh/gl.inet/gl-mt6000#installation
    • Apple이 AirPort도 되살렸으면 함
      설정이 쉬웠고, 성능도 좋았고, 고급 기능도 일부 있었으며, 수년간 보안 업데이트를 받았음
      2년쯤 전 사무실 동료와 내가 Fritz!Box가 고장 났을 때 오래된 AirPort Extreme을 꺼냈는데, 여전히 아주 잘 동작했을 뿐 아니라 802.11ac 라우터로도 꽤 경쟁력이 있었음
    • Linux의 GPL 관련 요소가 걱정된다면 OpnSense도 있음. 잘 동작하고 꽤 평판도 좋다고 봄
      몇 년 전 직접 OpnSense로 라우터를 만들 정도로 괴짜인데, 정말 훌륭하게 동작했음
      그만둔 유일한 이유는 BSD와 특정 Broadcom 10Gbe 카드 사이에 우회할 수 없는 문제가 있어서였고, 결국 ClearOS로 뭔가를 임시로 만들었다가 나중에는 NixOS를 쓰게 됨
    • 테마를 직접 설치해 본 적은 없지만 https://openwrt.org/docs/guide-user/luci/luci.themes처럼 실제로 존재함
      못 할 이유가 딱히 없음
    • 많은 GLI.NET 장치는 Linux 메인라인 커널 지원이 업스트림되지 않은 SoC를 씀
      따라서 GLI.NET을 산다고 해서 “제대로 된 OpenWrt”가 도는 하드웨어를 확실히 얻는 건 아님
      여전히 하드웨어 호환성 목록을 확인하거나, 더 좋고 최신인 방법으로는 현재 OpenWrt git master의 DTS 파일 목록을 확인해야 함

  • 이 문제는 Velop 제품군에만 국한되지 않음
    EA7500을 openWRT로 바꾸는 중에, mylinksys 웹 포털로 로그인을 강제하고 홈 서버와 연결을 맺으려 하면서 정확히 같은 정보가 전송되는 걸 봤음

  • “11월에 Linksys에 경고했음에도 효과적인 조치가 취해지지 않았다”
    11월? 11월이라고? 물론 그 무렵엔 휴일이 많긴 함
    그래도 업체가 적극적으로 작업하거나 소통하고 있지 않다면, 이런 건 늦어도 1월 말에는 공개 공개가 되었어야 한다고 봄

  • 창피한 일임. 몇 달 동안 응답하지 않는 건 적극적으로 악의적인 행동이고, 책임을 떠넘길 일회용 개발자 한 명이 아니라 회사 전체가 그에 맞게 처벌받아야 함

  • Apple이 다시 WiFi 라우터 사업에 들어왔으면 함
    개인정보 보호와 보안 태도는 대부분의 다른 브랜드보다 Apple을 더 신뢰함
    안타깝게도 Apple은 예전 제품의 대체재로 Linksys 라우터를 팔고 있음

    • 미안하지만 기기 구독 사업 모델에는 아무도 관심 없음
      사람들은 자기 하드웨어를 소유하고 싶어 함
    • 다음 조건을 만족한다면 누가 만들든 상관없음
      부트로더와 모든 온보드 장치의 소스가 공개되어 있어야 함
      모든 NPU, 오프로딩 엔진, 이더넷 데이터 경로상의 다른 장치에 대한 펌웨어 소스가 제공되어야 함
      메인라인 Linux 커널이 WiFi/RF를 제외하고 완전히 블롭 없는 부팅을 지원해야 함
      점퍼로 TrustZone 접근을 활성화할 수 있고, 최종 사용자가 완전한 키 관리를 할 수 있어야 함
      내부에 직렬 UART 포트 헤더가 실장되어 있으면 좋음
      하지만 Apple이 이렇게 사용자 친화적이라서 박스에서 꺼낸 지 5분 만에 OpenWrt를 쉽게 설치할 수 있는 장치를 만들 것 같지는 않음. 게다가 아마 비싸게 받아먹을 것임
답변달기