Salt Typhoon 이후 드러난 통신 스택의 불안정성

 (soatok.blog)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Salt Typhoon 침해 이후 통신 오픈소스를 확인하는 과정에서, FreeSWITCH에 번들된 XMLRPC 라이브러리에서 인증 없는 버퍼 오버플로가 발견됨
  • 취약점은 공격자가 제공하는 Request URI를 4096바이트 스택 변수에 sprintf()로 기록하는 코드에서 발생하며, 브라우저 제한과 별개로 4096자 초과 요청이 가능할 수 있음
  • SignalWire는 2025년 2월 GitHub에 수정 PR 3개가 공개됐다고 답했지만, FreeSWITCH Community의 새 릴리스는 2025년 여름까지 계획이 없다고 밝힘
  • Shodan에는 FreeSWITCH 검색 결과가 약 8,300건 있었고, 릴리스 태그가 없는 운영자는 소스 빌드나 방화벽 차단으로 직접 대응해야 하는 상황임
  • 이 사례는 통신 보안의 위험이 취약점 자체뿐 아니라 취약점 관리와 릴리스 대응에서도 커진다는 점을 보여주며, 2025년 4월 30일 CVE-2025-44087이 배정된 뒤에도 FreeSWITCH 릴리스는 없었음

Salt Typhoon 이후 FreeSWITCH를 살펴본 계기

  • 2024년 말, 중국 정부와 연관됐다고 알려진 Salt Typhoon 그룹이 T-Mobile과 다른 통신사를 침해했다는 소식이 출발점이 됨
  • 이동통신사 네트워크를 직접 조사할 수는 없었지만, GitHub에는 통신 관련 오픈소스 프로젝트가 많았음
  • 과거 Asterisk와 FreeSWITCH를 쓰는 회사들과 일한 경험은 있었으나, PBX, SIP, 오디오 인코딩을 깊게 분석한 경험은 없었음
  • 통신 분야에는 뛰어난 C 프로그래머, 오래된 해커 커뮤니티, Bell Labs 출신 엔지니어들의 전통이 있어 단순한 취약점은 이미 발견됐을 것이라고 예상함
  • 하지만 FreeSWITCH 소스코드를 열어본 직후 취약점이 발견됨

XMLRPC HTTP 요청 처리기의 버퍼 오버플로

  • FreeSWITCH에 번들된 XMLRPC 라이브러리의 HTTP 요청 처리기가 고정 크기 스택 버퍼 z[4096]에 URI를 기록함
  • 문제 코드는 sprintf(z, "Index of %s" CRLF, uri); 형태이며, uri는 Request URI의 path 부분에서 오기 때문에 공격자가 제어할 수 있음
  • 일반 브라우저는 2048자보다 긴 URL을 잘 지원하지 않는 경우가 많지만, 관련 RFC는 대부분 약 8KB까지 허용하고 Cloudflare는 32KB까지 지원함
  • 공격자가 4096자를 넘는 Request URI를 보낼 수 있다고 보는 것이 합리적이며, 이 조건이 XMLRPC 라이브러리의 무인증 버퍼 오버플로로 이어짐
  • 원격 코드 실행으로 확장하는 과정은 다루지 않음

수정 방식과 공개된 패치

  • 수정 방향은 sprintf() 대신 snprintf() 를 사용하는 것임
  • 이는 기본적인 방어적 C 프로그래밍 관행에 해당함
  • SignalWire는 문제가 최근 수정됐다며 다음 PR을 제시함
  • 패치가 이미 GitHub에 공개된 상태였기 때문에 공개 글 작성이 가능하다고 판단함

취약점 공개 과정과 릴리스 공백

  • 2025년 1월 27일, FreeSWITCH 보안 정책에 적힌 이메일 주소로 취약점 세부 내용을 보냄
  • 2025년 2월 7일, 보고서를 받았는지 확인하는 후속 이메일을 보냄
  • 같은 날 Andrey Volk가 취약점이 최근 수정됐고 관련 PR을 보라고 답함
  • 새 보안 수정이 포함된 릴리스 태그 일정을 묻자, FreeSWITCH Community 릴리스는 2025년 여름까지 계획이 없다는 답변을 받음
  • 이로 인해 FreeSWITCH Advantage를 지불하지 않는 사용자는 정규 릴리스 시점까지 취약한 상태로 남을 수 있음

노출 규모와 운영자 영향

  • 당시 Shodan에서 FreeSWITCH 검색 결과는 약 8,300건이었음
  • 이 인스턴스들이 모두 엔터프라이즈 지원을 지불한다고 보기 어렵기 때문에, 전 세계 수천 개의 통신 스택이 여름까지 취약한 상태로 남을 수 있다고 봄
  • 패치가 GitHub에 공개됐더라도 릴리스 태그가 없으면 일반 운영자가 쉽게 업데이트하기 어려움
  • FreeSWITCH 운영자는 SignalWire의 릴리스를 기다리는 대신 다음 조치를 고려해야 함
    • 소스에서 직접 재빌드
    • 방화벽 수준에서 FreeSWITCH 스택의 공개 HTTP 접근 차단

통신 보안의 구조적 문제

  • 통신 업계 지인과의 대화에서는 FreeSWITCH의 대응 속도조차 빠른 편이라는 반응이 나옴
  • 2024년 12월에도 전화망에 17년 동안 존재해온 SS7 취약점에 대한 경고가 다시 나왔음
  • 이 경험 이후 Asterisk나 다른 소프트웨어를 추가로 살펴보지 않음
  • 결론적으로 오늘날 통신 보안은 좋지 않은 상태로 평가됨
  • 이런 시스템을 안전하게 만드는 데 돈을 벌 유인이 거의 없다는 점이 큰 원인으로 보임

이후 상태

  • 2025년 4월 30일 업데이트에서, 보고된 버퍼 오버플로에 CVE-2025-44087이 배정됨
  • 같은 시점에도 FreeSWITCH의 태그나 릴리스는 없었음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 글쓴이는 통신사급 인프라 경험이 전혀 없다고 인정하지만, 의심 자체는 대체로 맞음
    실제로 여러 주요 통신사를 대상으로 4G/5G 침투 테스트와 보안 연구를 꽤 해봤는데, 통신사와 장비 업체마다 차이는 있어도 여전히 완전한 공포 쇼에 가깝다
    아주 최근까지 보안은 사실상 은닉에 의한 보안뿐이었고, 4G/5G 표준이 이를 다루기 시작했지만 아직도 심각하게 우려할 만큼 큰 구멍이 남아 있음
    통신사에 교두보를 만들려는 중간 수준 이상의 위협 행위자는 가능하다고 보는 게 과장이 아니며, 직업적으로 여러 번 시연해 봤다
    특정 동아시아 국가의 장비 업체들은 소프트웨어 스택 품질이 너무 낮아 거의 APT로 분류해도 될 정도이고, 보안은 사실상 존재하지 않음
    서방 국가들이 이들을 금지한 데는 타당한 이유가 있으며, 서방 장비 업체의 소프트웨어는 훨씬 성숙하지만 그래도 우리가 현대적 보안 모범 사례라고 여길 수준보다 여러 해 뒤처져 있음

    • 몇 년 전 영국은 Huawei 장비를 구매하면서 정부/Huawei 공동 연구소를 만들어 소스 코드를 분석해 안전성을 확인하려 했음
      GCHQ는 코드 품질이 검토 불가능한 수준이고, 제공된 소스 코드가 실제 장비에서 실행되는 코드인지조차 보장할 수 없다고 봤음
      Huawei가 직접 업데이트할 수 있었기 때문이며, 해당 장비는 2020년 이후 금지된 것으로 알고 있음: https://www.washingtonpost.com/world/national-security/brita...
    • 특정 장비에 대한 공개 분석 글이 있는지 궁금함
      AliExpress에서 하나 사서 들여다보고 싶은데, 이 링크가 출발점으로 괜찮을까?
      https://vulners.com/search/types/huawei
    • 일반 해커가 이런 장비를 어떻게 구해서 연구할 수 있는지 궁금함
    • 특정 동아시아 국가 장비 업체들의 소프트웨어 스택이 형편없어 거의 APT라고 할 수 있다는 말은, 보안을 아주 진지하게 다루는 특정 북미 국가의 하드웨어·소프트웨어 업체들이 있어서 참 다행이라는 식으로 비꼬고 싶어짐

  • 2025년에도 이동통신 표준에서 사전 공유 키를 쓰는 이유를 정말 이해할 수 없음
    RSA와 Diffie-Hellman[1]은 수십 년 전부터 있었고 인증기관 체계도 오래됐는데, SIM 카드는 여전히 카드와 통신사만 아는 사전 공유 키로 발급되고 이후 인증과 암호화가 모두 그 키에 기반함
    통신사가 해킹당해 키가 유출되면 할 수 있는 일이 없음
    더 나쁘게는 그 키를 SIM 카드 제조사가 통신사에 보내야 하고, 제조사가 다른 나라에 있어 외국 정부 요구를 받을 수도 있으니 제조사 해킹이나 전송 중 탈취 기회가 충분히 생김
    이건 NOBUS 취약점처럼 느껴지며, SIM 제조사나 코어망 장비 업체가 NSA와 결탁해 키를 넘기면 전 세계 이동통신 트래픽을 잠재적으로 도청할 수 있음
    [1] 이 알고리즘들이 이제 모범 사례가 아니고 타원곡선이 더 낫다는 건 알지만, 지금보다는 RSA라도 나음
    [2] https://nickvsnetworking.com/hss-usim-authentication-in-lte-...

    • Gemalto는 15년 전에 해킹당했음
      “Edward Snowden이 제공한 NSA 1급 비밀 문서에 따르면, 미국과 영국 스파이들이 세계 최대 SIM 카드 제조사의 내부 컴퓨터망을 해킹해 전 세계 휴대전화 통신 프라이버시를 보호하는 데 쓰이는 암호화 키를 훔쳤다”
      https://theintercept.com/2015/02/19/great-sim-heist/
    • 전화 엔지니어들과 얘기해 보니, 기지국에 붙어서 디버깅할 때 지나가는 SMS 전체를 그대로 읽을 수 있었다고 했음
      지금도 그런지는 모르겠지만, 예전에는 휴대전화가 안전한 통신 수단이라고 보기 어려웠다
      아마 단말 간 암호화된 데이터 통신으로 대화하는 편이 필요할 것임
    • 일부 알고리즘은 SIM 카드에서 돌아야 하는데, 적어도 과거의 스마트카드는 RSA나 비타원곡선 Diffie-Hellman을 지원하려면 비용을 올리는 보조 프로세서가 필요했음
      대칭키 알고리즘은 양자 안전하다는 장점도 있음
      그래도 2025년이면 최소한 ECC는 지원했으면 하고, 이제는 대부분의 스마트카드가 기본 지원할 수 있어야 함
      SIM 카드 업체를 신뢰할 수 없다면 사실상 답이 없음
      비대칭 방식에서도 공격 경로가 조금 달라질 뿐, 카드에서 돌아가는 소프트웨어를 믿지 못한다면 비결정적 알고리즘의 난수 선택을 통해 평문을 유출하지 않는다고 어떻게 알 수 있겠나
    • 키를 직접 배포할 수 있다면 비대칭 암호화는 얻는 것에 비해 복잡도를 더함
      대칭 시스템에 RSA를 넣으면 더 안전해진다는 생각은 근거가 약하고, 오히려 반대에 가깝다
      “NOBUS 취약점”이라는 표현도 특히 이상한데, 이런 시스템의 신뢰 루트는 통신사이기 때문임
      미국 통신사가 미국 정보기관과 “결탁”했는지 물을 필요도 없이, 이미 그렇다고 봐야 함
    • 대형 통신사에서 기술지원/고객서비스 일을 했는데, 보안 문제가 여러 개 보였고 고객 서비스를 개선할 해결책과 함께 제기했더니 회사가 돈을 잃는다는 답을 들었음
      사기꾼은 통신사의 큰 고객이고, 잡혀서 차단되면 다시 돌아와 새 회선 가입비를 내고 같은 과정을 반복함
      사기꾼 덕분에 부가 기능 상향 판매도 가능해져, 문제를 해결하지 않는 쪽에서 또 수익이 남음

  • 블로그 글의 결론처럼 Freeswitch가 커뮤니티 릴리스 일정을 바꾸지 않는다는 점은 전혀 놀랍지 않음
    예전의 Freeswitch에는 강한 커뮤니티 정신이 있었지만, 몇 년 전 더 공격적으로 상업화된 뒤 분위기가 바뀌었음
    그 이후로는 공개되어야 할 것에 접근하려면 “등록” 절차를 거쳐야 했고, 기억으로는 APT 저장소 같은 것이 등록 벽 뒤에 숨겨졌던 것 같음
    자유 소프트웨어 커뮤니티 콘텐츠에 접근하려고 상업 회사에 등록하고 싶지 않다
    기술 업계에서 상업 회사에 정보를 주면 영업 담당자가 상향 판매·교차 판매로 귀찮게 하고, 원하지 않은 메일링 리스트에 넣는 일이 벌어진다는 걸 다들 알기 때문임

    • SignalWire를 변호하자면, 오래된 메일링 리스트를 읽어보니 수년 동안 Freeswitch 개발을 이끌었지만 하위 프로젝트들로부터 제대로 보상받지 못한 느낌이 들었음
      VoIP 커뮤니티의 다른 부분들도 오픈소스에 대한 관대함을 재조정하는 걸 봤고, 솔직히 탓하기 어렵다
      Matrix.org 팀도 FOSDEM’25 발표 중 하나에서 비슷하게, 상업 벤더들이 개발에 무임승차하는 문제를 얘기했음
    • 틀렸다면 정정해 달라지만, 패치된 소스 코드는 공개되어 있지 않나?
      APT 저장소까지 무료로 업데이트해 주면 정말 고맙겠지만, 딱 그 정도로 “고마운 일”일 뿐임
      그들의 코드에 의존하면서 지원 비용을 내고 싶지 않다면 APT 패키지를 직접 빌드하면 된다
      이런 식으로 단일 회사가 유지보수하는 프로젝트에서 어떤 커뮤니티 정신을 기대해야 하는지는 잘 모르겠음

  • 외국 위협 행위자, Five Eyes 같은 서방 동맹, 그리고 숫자를 계속 올려야 하는 압박을 고려하면 온라인에 진짜 익명성은 없다고 보는 게 타당함
    그들이 당신을 원한다면 잡을 수단도 갖고 있음
    실제로는 인터넷 이전 시대와 크게 다르지 않다
    가로채이고 싶지 않다면 대형 보안기관이 전자적으로 쉽게 접근할 수 없는 방식으로 암호화해야 함
    물리적 쪽지, 구전, 손짓 같은 방법 말이다
    또한 국가 행위자가 실제로 데이터를 활용할 자원을 배정했을 때, 온라인에서 한 말과 행동의 결과를 감당할 준비가 필요함

  • 기사만 봐서는 “오늘날 통신 보안은 엉망”이라는 결론에 완전히 설득되지는 않음
    Freeswitch를 임의로 골라 버퍼 오버플로를 찾은 것에 가깝기 때문임
    “통신 스택”이 취약할 수도 아닐 수도 있지만, 여기서 제시된 근거는 매우 약함
    Salt Typhoon 공격은 Cisco 취약점을 악용했다고 알려졌지만, 분석가들은 공격자가 정상 자격 증명을 사용했을 가능성도 제시함: https://cyberscoop.com/cisco-talos-salt-typhoon-initial-acce...
    그러니 Freeswitch와는 무관함

    • Cisco Unified Call Manager에는 거의 확실히 취약점이 있을 것이고, Microsoft가 공개적으로 죽인 뒤에도 네트워크 코어에서 질질 끌려온 Metaswitch도 마찬가지임
      Oracle SBC는 기본 동작만 해도 종종 불안정하고, Teams가 이번 주에 내놓는 TRouter 구현의 난장판에도 제대로 분리해내지 못한 서비스 거부 버그가 분명히 있을 것임
      MF Tandem의 혼란이나 거의 모든 통신사가 원시 비암호화 UDP SIP 트래픽을 인터넷에 그대로 흘리는 건 말도 꺼내지 말자
      이 분야에서 안전한 시스템을 만드는 건 가능하지만, 현실은 주요 통신사 대부분이 Nortel, Metaswitch 같은 오래전에 죽은 회사나 프로젝트의 독점·수정 불가능 플랫폼과, 네트워크를 이루는 낡고 패치 안 된 장비보다도 더 나쁜 기술 부채 더미를 운영하는 상태임
    • SignalWire가 엠바고를 깨고 난 뒤, 통신 보안에 더 익숙한 보안 괴짜들과 몇 차례 대화했음
      “모든 게 엉망이고 고칠 동기가 없다”는 표현은 요약일 뿐임
      솔직히 그 대화들은 전문용어를 모르면 따라가기 매우 어렵고, 나도 이 분야를 충분히 이해하지 못해서 서투르게 설명하려 들고 싶지 않아 그렇게만 썼음
      내 블로그가 Hacker News에서 보일 줄은 전혀 예상하지 못했다
    • 통신 코드를 다뤄봤음
      여러 세대의 레거시를 가진 복잡한 네트워크 프로토콜을 파싱하는 코드이고, 흔히 비밀리에 작성되며, 대개 C/C++임
      이게 취약할 리가 없겠지. 그렇지
    • 통신 스택에는 프로토콜 수준에서 비롯된 것까지 포함해 의심스러운 보안 결정이 가득함
      SS7 같은 프로토콜은 해커나 악의적 행위자라는 개념 없이 설계됐음
      그 위에 방화벽을 얹을 수는 있지만, 원하는 기능과 충돌하고 그렇지 않더라도 추가 투자가 필요함
      DIAMETER는 더 낫지만 여전히 구멍이 많다
      최근 몇 년 동안 통신 보안이 우선순위가 되면서 개선되고는 있지만, 수십 년치 레거시 하드웨어·소프트웨어·펌웨어·네트워크 설계를 감싸야 함
      통신망에서 표준 Freeswitch를 그대로 돌리는 곳은 없을 것 같지만, 오래된 통신 제품으로서 보안을 기대만큼 찾지 않았던 Freeswitch의 문제 유형은 곳곳에 널려 있음
    • 이 블로그 글은 “내가 직업적으로 하는 일을 해봤다”와 “내 보고를 받은 쪽이 나와 보안 업계의 가치를 공유하지 않는다”가 결합된 뒤 통신 보안이 엉망이라고 결론낸 것임
      글쓴이가 여가 시간에 코드를 보고 버그를 찾아 보고한 건 훌륭하고, 전혀 막고 싶지 않다
      하지만 소프트웨어 하나의 유지보수자 한 명이 보안 업계 모범 사례에 맞춰 저자에게 굽신거리지 않았다는 사실만으로 “오늘날 통신 보안은 엉망”이라고 말하기엔 근거가 약함
      누군가 당신 코드의 버그를 가져왔는데 실제 악용 중이라고 주장하지도 않고, 악용 가능성을 확인할 PoC도 제공하지 않았다면 그냥 일반 버그로 다루면 안 될 이유가 있나?
      지금 고치고 다음 릴리스에 넣으면 된다
      변경 사항을 사람들이 볼 수 있다고? 그렇다, 다른 변경 사항도 다 볼 수 있다
      exploit을 찾을 수 있다면 행운을 빌 뿐이고, 보고자는 찾지 못했음
      Linux 배포판에서도 같은 일이 일어난다
      보안 버그가 보고되고, 때로는 업스트림 작성자가 고집 센 정도가 아니라 말 그대로 세상을 떠난 상태임
      자기 일정에 맞춰 바꾸고 싶다면 직접 릴리스하면 된다

  • Freeswitch가 꽤 자주 쓰일 것 같은 영역은 학교와 대학의 BigBlueButton 설치임
    가상 교실 시스템이고, 지원 계약 없이 쓰는 경우도 많을 텐데, 통신사보다 이쪽이 더 걱정됨

  • XML RPC 모듈을 실제로 쓰는 사람이 얼마나 될지 궁금함
    기본으로 로드되지 않음
    수정: Shodan 기준 468개임
    XML RPC 모듈에서 senddirectorydocument가 실제로 쓰이기는 하는지도 궁금함

    • 이어서 확인해 봤는데, 아무 동작도 유도하지 못했음
      curl --show-error --get --request GET --user freeswitch:works "http://localhost:8080/${SIXTEEN_THOUSAND_RANDOM_CHARACTERS}";
      트리거할 방법에 대한 아이디어가 있나?
      최소한 세그폴트라도 내는 PoC가 나오면 보안 릴리스를 할 가능성이 더 커질 것 같음

  • 정말 괜찮은 해킹은 CAMEL MAP 주입에서 일어남
    SMS, USSD, 그리고 왕관의 보석인 위치 서비스까지 온갖 좋은 것을 제어함
    카리브해의 부유한 섬들이나 인도네시아 같은 곳의 많은 “대량 SMS” 업체들이 스팸 전송보다 훨씬 많은 일을 하고 있음

    • 덧붙이면 MAP은 2G와 3G 기술임
      그래서 오래됐고, 2G는 1990년대에 설계됐음
      사람들이 뭘 기대하는지 잘 모르겠다
      솔직히 동작하기만 해도 다행임

  • 주요 통신사가 코어에서 FreeSwitch나 Asterisk를 돌리지는 않음

    • Motorola의 저가형 911 전화 시스템 Emergency CallWorks(ECW)는 Proxmox 위의 Linux에서 독점 모듈과 함께 도는 Asterisk임
      물론 Motorola가 그 제품을 종료하고 있지만, 현장에는 존재함
      내가 돌보는 것은 강하게 방화벽으로 막혀 있지만, 전부가 그렇지는 않을 것 같음
    • 코어에서는 아니어도, 통화 녹음, 전사, IVR, 음성 분석, CRM 연동, 통화 대기열, 자동 발신, SMS/채팅 기능처럼 통화 데이터를 처리하는 많은 사업자는 스택 어딘가에서 FreeSWITCH, Asterisk 또는 유사한 것을 돌릴 가능성이 큼
      기본 통화 라우팅과 PSTN 연결 이상의 일을 하려는 PBX 보유 기업은 대부분 서드파티 도구를 쓰고 있을 것임
      그리고 그런 도구 상당수가 FreeSWITCH, Asterisk 또는 비슷한 것 위에 만들어져 있음
    • “주요”의 정의에 따라 크게 달라짐

  • 모바일 통신 보안과 관련한 P1 Security 발표를 강력히 추천함: https://www.slideshare.net/slideshow/day1-hacking-telcoequip...
    오래된 자료지만, 나아졌다고 믿을 이유는 없음
    개선할 유인이 전혀 없기 때문임
    게다가 소프트웨어 보안 취약점은 문제의 일부일 뿐이고, 다른 한쪽은 통신사들이 제어권과 핵심 접근 권한을 최저가 입찰자에게 기꺼이 외주화한다는 점임: https://berthub.eu/articles/posts/5g-elephant-in-the-room/

답변달기