토론토에서 잡힌 'SMS 블래스터' - 가짜 기지국으로 문자 폭탄을 뿌리는 신종 수법

캐나다에서 처음 잡힌 사건

캐나다 토론토 경찰이 흥미로운 보도자료를 냈어요. 'SMS 블래스터(SMS Blaster)' 라 불리는 장비를 차량에 싣고 도심을 돌아다니며 무차별 피싱 문자를 뿌린 일당 3명을 검거했다는 소식이에요. 토론토 경찰 입장에서는 처음 잡아본 케이스라 '전례 없는 검거(unprecedented arrests)'라고 표현했고요. 우리나라에서 흔히 보는 보이스피싱이나 스미싱과 비슷해 보이지만, 동작 원리가 완전히 달라서 보안에 관심 있다면 한 번쯤 짚고 갈 만한 사건이에요.

SMS 블래스터가 도대체 뭔가요

'SMS 블래스터'가 뭐냐면, 한 마디로 이동식 가짜 기지국이에요. 좀 더 기술적으로는 IMSI 캐처(IMSI Catcher) 또는 셀 사이트 시뮬레이터(Cell Site Simulator)라 불리는 장비의 변종이고요. 원래 IMSI 캐처는 경찰이나 정보기관이 특정 휴대폰의 위치를 추적할 때 쓰던 도구인데, 이걸 사기꾼들이 거꾸로 활용한 거예요.

동작 원리를 풀어볼게요. 휴대폰은 가장 신호가 강한 기지국에 자동으로 붙는 성질이 있어요. 사기꾼이 차량에 강력한 송출기를 싣고 도심을 다니면, 주변 수백 미터 안에 있는 휴대폰들이 진짜 통신사 기지국 대신 이 가짜 기지국에 붙어버리는 일이 벌어져요. 더 교묘한 점은, 이 장비가 휴대폰 통신을 강제로 2G 방식으로 다운그레이드시킨다는 거예요. 2G는 1990년대에 만들어진 오래된 표준이라 기지국이 자기가 진짜인지 증명할 필요가 거의 없거든요. 즉, 휴대폰은 자기가 붙은 기지국이 진짜인지 가짜인지 확인할 수단이 없어요. 이렇게 한번 붙들면 사기꾼은 자기가 원하는 발신번호와 내용으로 SMS를 마음대로 쏠 수 있어요.

왜 무서운가요 - 통신사 필터링을 통째로 우회

이 수법이 무서운 이유는 통신사 필터링을 완전히 우회한다는 점이에요. 보통 우리가 받는 스미싱 문자는 어딘가의 통신사 망을 통해 들어오기 때문에, 통신사가 의심스러운 발신자를 차단하거나 사용자에게 경고를 띄울 수 있어요. 그런데 SMS 블래스터는 통신사 망을 거치지 않고 휴대폰 단말기에 직접 신호를 쏘기 때문에, 발신번호도 마음대로 위조할 수 있고 차단도 불가능해요. 사용자 입장에서는 '[국세청]', '[OO은행]' 같은 멀쩡한 번호로 메시지가 들어오는 것처럼 보이거든요. 토론토 사건에서도 가짜 은행 알림, 가짜 택배 알림 문자가 대량으로 살포된 것으로 알려져 있어요.

사실 처음 있는 일은 아니에요

이런 사건은 사실 처음이 아니에요. 영국 런던에서는 2024년에 이미 비슷한 일당이 적발됐고, 베트남, 태국 같은 동남아 국가에서도 조직적인 SMS 블래스터 갱이 활동 중이에요. 장비도 다크웹에서 수천 달러대에 거래되고 있어서 진입 장벽이 점점 낮아지고 있어요. 통신 보안 업계에서는 이 문제를 막기 위해 GSMA(세계 이동통신사업자 협회) 차원에서 2G 망을 단계적으로 폐쇄하자는 논의가 진행 중이에요. 미국, 호주, 싱가포르는 이미 2G를 거의 끈 상태고요. 안드로이드 14부터는 사용자가 설정에서 '2G 연결 강제 차단' 옵션을 켤 수 있는 기능이 추가됐는데, 이것도 같은 맥락에서 나온 방어 수단이에요.

한국은 안전한가

한국 상황은 어떨까요? 다행히 KT, SKT, LG U+ 모두 2G망을 이미 종료했거나 종료 단계에 있어서, 이런 형태의 공격이 그대로 통하지는 않아요. 다만 3G나 LTE 다운그레이드를 노리는 변종도 보고된 적이 있어서 완전히 안심할 단계는 아니에요. 그리고 더 큰 문제는, 한국에서는 통신사 망 자체를 우회하지 않아도 발신번호 변작 SMS가 워낙 많이 돌고 있다는 점이에요. 즉 공격 통로가 다를 뿐이지 사용자가 받게 되는 피싱 문자의 양은 비슷하거든요.

개발자가 가져갈 교훈

개발자로서 이 사건에서 배울 점은 '인증 없는 다운그레이드'의 위험성이에요. 어떤 시스템이든 새 버전을 만들면서 이전 버전과의 호환성을 어떻게 끊을지를 함께 설계하지 않으면, 결국 가장 약한 고리를 통해 공격이 들어와요. TLS 1.0/1.1 다운그레이드 공격, JWT의 'none' 알고리즘 허용, OAuth의 implicit flow 잔존 같은 사건들이 다 같은 구조예요. 우리가 만드는 API나 인증 흐름에서도 "구버전 클라이언트를 위한 fallback"이 남아 있는지, 그게 공격자에게 빠져나갈 구멍을 주고 있지 않은지 한번 점검해볼 필요가 있어요.