2P by neo 2달전 | favorite | 댓글 1개
  • 2년 전 집에서 취약점 테스트를 하던 중 이상한 일을 경험함
  • AWS 박스에서 HTTP 서버를 띄워서 취약한 서버에서 파일을 가져오려고 했음
  • 모든 설정이 잘 된 것 같았지만, 취약점 테스트로 돌아가려는 순간 예상치 못한 로그가 나타남
  • 누군가 집 네트워크와 AWS 박스 사이에서 10초 뒤 동일한 HTTP 요청을 가로채 다시 보냈음
  • 이 트래픽은 접근 불가능해야 하고 중개자가 없어야 함
  • 즉시 생각한 것은 내 컴퓨터가 해킹되어 해커가 트래픽을 적극적으로 모니터링한다는 것이었음
  • iPhone에서도 동일한 현상이 발생하는지 확인했고, 알 수 없는 IP 주소가 컴퓨터와 iPhone의 HTTP 요청을 모두 가로채고 다시 보냈음
  • ISP, 모뎀, AWS 중 하나가 침해되었을 가능성이 높아 보였음
  • AWS가 해킹되었다는 터무니없는 생각을 없애기 위해 GCP에서 박스를 켜니 동일한 현상이 발생함
  • 유일한 가능성은 모뎀이 해킹되었다는 것이었지만, 공격자는 누구일까? IP 주소 소유자를 조회해보니 DigitalOcean에 속한 것으로 나왔음
  • 해당 IP는 최근 몇 년간 여러 피싱 사이트와 메일 서버로 사용되었음
  • 침해된 장치는 계속 작동 중이었기에 전원을 뽑고 상자에 넣어둠
  • Cox 가게에 가서 해킹당한 모뎀 반납하고 새 것을 받았음
  • 새 모뎀 설치 후 이상 행동은 멈췄지만 모뎀의 정확한 침해 방법은 알 수 없었음
  • 3년 후 보안 전문가 친구들과 휴가 중 이 사건을 이야기하게 되었고, 그들이 흥미를 갖고 조사를 시작함
  • IP 주소가 등록한 도메인을 살펴보니 대량의 알고리즘 생성 도메인이 있었음. C&C 서버임을 시사함
  • 공격자는 동일 IP에서 여러 악의적 활동을 수행했지만 3년간 정지되지 않음. 의도를 파악하기 어려웠음
  • 새 모뎀 역시 동일 모델이었기에 공격자가 다시 침투했을 가능성도 고려함
  • TR-069 프로토콜을 통해 ISP가 장치를 관리할 수 있다는 점에 주목함. 지원 도구 인프라를 공격하면 모뎀을 장악할 수 있을 것임
  • Cox 비즈니스 포털 JavaScript를 분석해 700개 이상의 API 경로를 발견함. 그중 장비와 고객 계정 접근 기능이 가장 많은 API는 accountequipment, datainternetgateway, account였음
  • 인증 우회가 가능한 취약점을 발견함. HTTP 요청을 반복 전송하면 무단으로 명령을 실행할 수 있었음
  • MAC 주소로 누구의 장비라도 직접 통신할 수 있음을 확인함. Cox는 수백만 명의 고객에게 서비스를 제공함
  • 장비 설정을 덮어쓰고, 라우터에 접근하며, 장치에서 명령을 실행하는 등 ISP 기술 지원팀과 유사한 권한을 얻을 수 있음을 입증함
  • 이는 선행 조건 없이 수백만 개의 모뎀 설정을 변경하고, 고객 PII에 접근하며, ISP 지원팀 수준의 권한을 얻을 수 있는 취약점임
  • 사고 시나리오는 다음과 같음
    1. API로 Cox 비즈니스 고객 검색
    2. UUID로 장비 MAC 주소, 이메일, 전화번호, 주소 등 고객 PII 획득
    3. MAC 주소로 WiFi 비밀번호와 연결된 장치 조회
    4. 임의 명령 실행, 장비 속성 변경, 계정 탈취
  • 취약점을 Cox에 제보했고, 6시간 내 API를 차단하고 인증 문제 수정을 시작함
  • 700개 이상의 노출된 API 중 상당수가 관리자 기능을 제공했고, 모두 동일한 권한 문제가 있었음
  • 이번 사례는 ISP와 고객 장비 간 신뢰 계층의 취약점을 보여줌
  • 내 모뎀이 정확히 어떻게 해킹되었는지는 여전히 궁금함. 공격자가 트래픽을 왜 재전송했는지도 이해할 수 없음
  • 관련 이론이나 의견 환영함

GN⁺의 의견

  • 보안 취약점: 이 기사는 ISP의 보안 취약점이 얼마나 심각한 영향을 미칠 수 있는지를 보여줌. 특히, 원격으로 장치 설정을 변경할 수 있는 기능이 악용될 수 있음.
  • API 보안: API 보안의 중요성을 강조함. 인증 우회와 같은 취약점은 심각한 보안 문제를 초래할 수 있음.
  • 사용자 데이터 보호: 고객의 개인 정보와 장치 설정이 쉽게 노출될 수 있는 위험성을 경고함. ISP는 이러한 데이터를 보호하기 위해 더 강력한 보안 조치를 취해야 함.
  • 기술적 이해: 초급 소프트웨어 엔지니어도 이해할 수 있도록 기술적 세부 사항을 설명함으로써, 보안 취약점을 탐지하고 해결하는 방법을 배울 수 있음.
  • 대안 제시: 이와 같은 문제를 해결하기 위해 더 안전한 네트워크 장비와 보안 프로토콜을 사용하는 것이 중요함. 다른 ISP나 보안 솔루션을 고려해 볼 수 있음.
Hacker News 의견
  • Cox가 문제를 부정하거나 메신저를 공격하지 않고 책임감 있게 대응한 점이 인상적임. 버그가 무엇이었는지 후속 기사를 읽고 싶음.
  • ISP가 자체 모뎀이나 라우터 사용을 강제하는 상황이 불편함. AT&T 라우터를 해킹당할 가능성이 있지만 HTTPS 덕분에 다행임.
  • 훌륭한 기사와 조사였음. Nokia 라우터의 로컬 관리자 인터페이스가 제대로 인증되지 않는 것 같음. 특정 설정을 변경할 수 없었지만 페이지를 해킹해 변경할 수 있었음.
  • 많은 라우터가 수동 펌웨어 업데이트를 요구함. GL.iNet 라우터는 최근 RCE 취약점이 있었음. 펌웨어 업데이트와 SSH 접근 비활성화 등의 조치를 권장함.
  • 공격자가 HTTP 트래픽을 어떻게 가로챘는지 여전히 의문임. Cox가 펌웨어 버전을 확인하고 자동 업데이트를 통해 문제를 해결할 수 있을 것임.
  • Cox가 과거에 이 취약점이 악용된 적이 없다고 주장하지만, 신뢰하기 어려움. 네트워크가 허술함.
  • 큰 기술 회사에서 큰 취약점이 발견된 것은 충격적임. 기사는 훌륭하지만, 이 취약점은 용서할 수 없음.
  • 취약점을 보고한 사람에게 보상이 있었는지 궁금함. 그가 큰 공헌을 했지만, 아무런 보상을 받지 못한 것 같음. 이는 매우 모욕적임.
  • Cox가 과거에 악용된 적이 없다고 주장하는 이유는 로그나 감사 데이터가 부족했기 때문일 것임.
  • 기사 내용은 훌륭하지만, 결심한 공격자는 Cox 기술자로 위장해 접근할 수 있음. ISP는 원격 접근을 기본적으로 비활성화하는 설정을 구현해야 함.