목차
- SS7 취약점으로 페이스북 계정 탈취 가능
- 공격이 작동하는 방법
- 왜 네트워크는 SS7을 패치하지 않는가
- 실무적 대응: 개인과 조직별 체크리스트
- 반례: 이 공격이 실패하는 경우
- 용어집, FAQ와 요약
SS7 취약점으로 페이스북 계정 탈취 가능
요약하면, SS7(Signalling System 7)은 통신사업자들이 전화 통화 설정, 문자 전송, 번호 변환, 선결제 청구 등 여러 핵심 기능에 쓰는 신호 규약입니다. 1975년에 개발된 이 프로토콜은 전 세계 PSTN(공중교환전화망)에서 통화와 메시지를 연결하는 데 쓰이며, 설계 당시 보안 위협을 전제로 하지 않았습니다. 그 결과 SS7은 여러 해 동안 반복적으로 취약점이 보고되어 왔습니다.
최근 연구자들이 시연한 바에 따르면, 공격자는 SS7 네트워크를 조작해 특정 휴대전화로 전송되는 SMS 또는 기타 네트워크 인증 메시지를 가로채거나 전달 경로를 바꿀 수 있습니다. 이 기술을 이용하면, 서비스 제공자의 ‘비밀번호 재설정’ 또는 ‘계정 찾기’ 기능으로 전송되는 일회용 코드(OTP)를 공격자 장치로 전달하게 할 수 있습니다. 페이스북 계정도 예외가 아니며, 전화번호 기반 복구 수단을 사용하는 계정은 특히 위험합니다.
중요: 이 취약점은 통신 네트워크의 설계와 글로벌 상호연결 구조에서 비롯된 구조적 문제입니다. 단순한 소프트웨어 패치만으로 전 세계에 일괄 적용되기 어렵고, 일부 국가나 사업자는 정치·정보 수집 목적으로 취약점 유지를 선호할 수도 있습니다.
공격이 작동하는 방법
- 표적 선정: 공격자는 피해자의 휴대폰 번호만 알면 됩니다. 번호는 공개 프로필, 데이터 유출, 또는 기타 소셜 엔지니어링으로 확보됩니다.
- SS7 네트워크 조작: 공격자는 SS7 메시지를 보내 통신사 네트워크에서 해당 번호의 SMS나 음성 전화를 자신이 제어하는 장비로 전달하도록 요청합니다. 이 단계에서 공격자는 네트워크 노드 간 신호를 위조(스푸핑)하거나 부적절한 라우팅을 유도합니다.
- 계정 복구 시도: 공격자는 페이스북 로그인 화면의 “계정 찾기(또는 비밀번호 재설정)” 기능을 사용해 피해자의 번호를 입력합니다.
- OTP 수신: 페이스북이 번호로 전송한 일회용 코드(OTP)가 이미 조작된 네트워크 경로를 통해 공격자에게 도달합니다.
- 인증 우회 및 계정 장악: 공격자는 OTP를 입력해 비밀번호 재설정을 완료하거나 계정 접근 권한을 넘겨받습니다.
이 과정을 설명한 연구 시연 영상: https://youtu.be/wc72mmsR6bM
참고: 연구자들이 만든 도구(예: SnoopSnitch 같은 앱)는 특정 SS7 공격 징후나 IMSI-catcher(가짜 기지국) 탐지를 도울 수 있습니다. 그러나 이들 도구는 완전한 방어 수단은 아닙니다.
왜 네트워크는 SS7을 패치하지 않는가
SS7 취약성은 기술적·정치적·운영적 이유가 복합적으로 얽혀 있어 전면적인 수정(또는 대체)이 매우 어렵습니다.
- 글로벌 상호연결성: SS7은 전 세계 수많은 사업자와 장비 제조사가 상호 연결한 오래된 표준입니다. 한 사업자의 패치만으로 문제를 해결할 수 없습니다.
- 비용과 호환성: 기존 네트워크 장비와 서비스의 호환성을 유지하면서 보안 기능을 추가하려면 대규모 장비 교체와 긴 테스트 주기가 필요합니다.
- 정보기관의 요구: 일부 정부 및 정보기관은 위치 추적·감청 목적 때문에 취약점이 유지되기를 원할 수 있습니다. 이러한 정치적 요인이 패치 진행을 지연시킵니다.
- 우선순위 문제: 사업자들은 상업적·운영적 이슈에 따라 보안 문제의 우선순위를 다르게 둡니다. SS7의 근본적 개선은 단기간의 수익으로 환산되기 어려운 투자가 필요합니다.
결과적으로 완전한 해결책은 국제 표준과 각국 규제, 통신사 간 협력 없이는 어렵습니다. 일부 사업자는 자체 방어(번호 이전 모니터링, SIM 변경 알림, SMS 라우팅 검증 등)를 도입하지만 범세계적 차원의 보안 보완은 아직 진행 중입니다.
실무적 대응: 개인과 조직별 체크리스트
중요: 모든 권장 사항은 보안 수준을 올리지만, 완전한 안전을 보장하지 않습니다. 여러 권장 조치를 함께 적용하세요.
개인 사용자 체크리스트
- 전화번호 기반 복구 대신 앱 기반 2단계 인증(Authenticator) 또는 하드웨어 보안키(U2F/WebAuthn)를 우선 사용하세요.
- 페이스북 등 주요 서비스에서 보안키(물리적 토큰) 등록을 활성화하세요.
- 통신사에 ‘SIM 이동·교체 시 PIN/추가 확인 절차’ 도입을 요청하세요. 가능하면 통신사 계정에 별도 PIN을 설정하세요.
- 계정 보안 알림을 활성화하고, 로그인 알림과 세션 관리를 주기적으로 확인하세요.
- 의심스러운 문자나 전화는 즉시 무시하고, 공식 채널(앱 내 알림, 설정 메뉴)을 통해 직접 확인하세요.
기업/IT 관리자 체크리스트
- 직원의 계정에 강제 앱 기반 2단계 인증 또는 보안키 사용 정책을 적용하세요.
- 중요 관리자 계정은 하드웨어 보안키만을 허용하는 정책을 검토하세요.
- 통신사와 협업해 직원 번호의 변경·이전 모니터링을 설정하고, SIM 스와핑 의심 시 즉시 차단 프로세스를 마련하세요.
- SSO(단일 로그인)와 로그 모니터링 시스템에 비정상 OTP 요구 및 위치 기반 이상 징후 탐지 규칙을 추가하세요.
통신사(사업자) 권고사항 요약
- SS7 메시지의 인증·검증 강화 및 이상 라우팅 탐지 도입
- SMS 라우팅에 대한 송신자 검증 및 의심 트래픽 모니터링
- 고객의 SIM 변경 요청에 대해 다단계 인증 및 수기 확인 절차 도입
반례: 이 공격이 실패하는 경우
- 계정 복구 수단이 전화번호(SMS)에 의존하지 않을 때: 앱 기반 또는 하드웨어 인증만 있을 경우 OTP 가로채기로는 계정 접근이 불가능합니다.
- 통신사가 SS7 보호 또는 보안 게이트웨이를 적용했을 때: 일부 통신사는 SS7 필터링으로 악성 신호를 차단합니다.
- 계정 소유자가 이미 비정상 로그인 알림을 설정하고 즉시 대응한 경우: 추가 인증 또는 계정 잠금으로 공격을 좌절시킬 수 있습니다.
대체 접근법과 권장 보안 모델
- 강력한 2단계 인증 모델: SMS 대신 TOTP(앱 기반) 또는 FIDO2/WebAuthn 기반 보안키 사용을 기본으로 권장합니다.
- 최소권한 및 관리자 계정 보호: 관리자 권한은 보안키로만 접근하도록 제한하고, 관리자 활동 로그를 강화하세요.
- 위협 모델링: 조직은 SS7과 같은 인프라 수준 공격을 위협 모델에 포함해 리스크를 평가해야 합니다.
간단 용어집
- SS7: 전화망 신호 규약. 통화·문자·번호 변환 등 핵심 기능을 제공.
- PSTN: 공중교환전화망, 전통적인 전화 네트워크.
- IMSI-catcher: 가짜 기지국 장비로서 주변 휴대폰을 유인해 통신을 가로채는 장치.
- SIM 스와핑: 통신사 절차를 악용해 다른 SIM으로 번호를 이전하는 공격 기법.
FAQ
SS7로 내 계정이 실제로 탈취될 가능성이 얼마나 되나요?
가능성은 환경에 따라 다릅니다. SMS 기반 복구 수단을 쓰고 있고, 통신사가 SS7 보완을 하지 않았다면 위험이 존재합니다. 그러나 앱 인증이나 보안키를 쓰는 계정은 공격에 안전합니다.
페이스북에서 어떤 설정을 바로 바꿔야 하나요?
전화번호 기반 복구를 제거하거나, 가능하면 앱 기반 인증 또는 보안키를 우선 등록하세요. 로그인 알림과 신뢰할 수 있는 연락처 설정을 확인하세요.
통신사에 요청할 수 있는 구체적 조치는 무엇인가요?
SIM 이동 시 추가 인증 도입, SIM 이전 알림, 계정 재설정 시 고객 신분증 확인 등 수기 확인 절차 강화를 요청하세요.
요약
- SS7은 오래된 신호 규약으로 구조적 취약점이 있어 SMS 기반 인증을 가로챌 수 있다.
- 공격자는 휴대폰 번호만으로도 페이스북 같은 서비스의 OTP를 탈취해 계정을 장악할 수 있다.
- 근본적 해결은 글로벌 협력과 네트워크 교체를 필요로 하며 단기간에 이루어지기 어렵다.
- 개인과 조직은 SMS 대신 앱 기반 인증 또는 보안키를 사용하고, 통신사에 보호 조치를 요청해야 한다.
중요: 보안은 계층적 방어가 핵심입니다. SMS는 편리하지만 유일한 복구 수단으로 의존하지 마세요.
