Telegram Desktop 취약점, 한 번의 클릭으로 파일 탈취 가능

Telegram Desktop은 외부 링크를 한 번 클릭하는 것만으로 임의의 로컬 파일을 탈취하고, 일반적인 조건에서는 계정을 탈취할 수 있게 했던 고위험 취약점을 수정했다. 이 Telegram Desktop 취약점은 7.2.8까지의 릴리스에 영향을 미쳤으며 Windows에서 확인됐다. 버전 7.2.9에서는 취약한 기능을 제거하고 앱이 프로세스 간 링크를 전달하는 방식을 변경했다.

이 공격에는 악성코드 설치, 악성 실행 파일, 피해자의 Telegram 비밀번호가 필요하지 않았다. 대신 Telegram Desktop 내부의 두 가지 결함과 자동 그룹 다운로드, 브라우저 리디렉션을 결합했다. 공격에 성공하면 공격자는 Telegram이 피해자 컴퓨터에서 선택한 파일을 공격자가 제어하는 그룹으로 업로드하도록 만들 수 있었다.

보안 연구자 BeakSec은 6월 25일 Zero Day Initiative를 통해 보고한 뒤, 2026년 10월 3일 이 공격 체인을 공개했다. Telegram은 9월 16일 독립적으로 취약한 코드를 제거했으며, 다음 날 버전 7.2.9가 뒤를 이었다. CVE-2026-107181은 10월 7일 할당됐다.

핵심 문제는 누락된 이스케이프 문자 하나보다 더 광범위하다. Telegram은 로컬 환경용 릴리스 도구를 신뢰할 수 있는 것으로 취급했고, 이후 이를 외부에서 제공되는 링크에 실수로 노출했다. 편의 기능이 원래 설계에서 도달할 것으로 예상하지 못했던 보안 경계를 넘은 셈이다.

공개 시점에는 이미 패치된 Telegram Desktop 취약점

즉각적인 소식은 안심할 만하다. Telegram Desktop 7.2.9는 기술적 증명이 공개되기 전에 입증된 공격 체인을 차단했다.

연구자의 기술 공개에 따르면 7.2.8까지의 Telegram Desktop이 영향을 받았다. 테스트는 6.9.3부터 7.2.8까지의 Windows 버전을 대상으로 이뤄졌다. 연구자는 모든 Telegram 클라이언트나 운영체제가 취약했다고 주장하지는 않았다.

이 취약점에는 CVE-2026-107181 식별자와 8.1의 CVSS 3.1 점수가 부여돼 고위험 범위에 속한다. 공개된 벡터는 원격 도달 가능성, 낮은 공격 복잡도, 사용자 상호작용 필요를 반영한다. 공격자는 피해자가 링크를 클릭해야 했지만, 사전 Telegram 권한은 필요하지 않았다.

실질적인 영향은 임의 파일 읽기였다. 이 용어는 취약한 애플리케이션이 공격자가 선택한 로컬 파일을 열도록 유도될 수 있음을 뜻한다. 이 경우 Telegram은 선택된 파일을 공격자가 제어하는 Telegram 채팅으로도 전송했다.

이 기능은 Telegram 데이터보다 훨씬 더 많은 것을 노출할 수 있었다. 연구자는 SSH 개인 키, 브라우저 비밀번호 저장소, 클라우드 자격 증명, API 토큰이 포함된 구성 파일을 가능한 표적으로 열거했다. 성공적인 탈취는 여전히 유용한 파일 경로를 알고 있거나 예측할 수 있는지에 달려 있었다.

입증된 계정 탈취는 Telegram Desktop의 tdata 디렉터리 내 세 파일을 표적으로 삼았다. 이 파일들은 함께 인증된 Telegram 세션을 재구성하는 데 필요한 자료를 담고 있거나 색인했다. 공격자는 복구한 파일을 새 설치본에 넣고 피해자의 계정을 열 수 있었다.

이는 비밀번호 복구가 아니라 세션 탈취였다. 세션 인증은 Telegram 서버에 클라이언트가 이미 인증됐음을 알린다. 따라서 유효한 세션 자료를 보유하면 입증된 탈취 과정에서 계정 비밀번호를 알 필요가 없을 수 있다.

공격은 피해자가 로컬 Telegram 암호를 설정하지 않았을 때 가장 직접적으로 작동했다. 이는 Telegram의 클라우드 비밀번호나 2단계 인증과는 구별된다. 로컬 암호는 해당 컴퓨터의 데스크톱 클라이언트에 저장된 데이터를 보호한다.

로컬 암호가 없으면 Telegram은 빈 입력값과 저장된 솔트를 이용해 로컬 래핑 키를 파생했다. 따라서 연구자는 관련 파일을 탈취한 뒤 키를 재구성할 수 있었다. 강력한 로컬 암호가 있다면 탈취된 암호화 데이터를 사용하기는 훨씬 더 어려워진다.

그러나 로컬 암호가 파일 읽기 취약점 자체를 수정하지는 않았다. 취약한 클라이언트는 여전히 공격자가 선택한 파일을 업로드할 수 있었다. 암호는 Telegram의 세션 자료가 손쉽게 재사용되는 것만 막았다.

Telegram의 패치 커밋은 레거시 헬퍼를 제거하고 로컬 메시징 형식을 강화했다. 공개 커밋의 제목은 “Remove legacy interpret path helper”였으며, 이는 보안상 결과를 축소해 표현한 것이다.

동반된 변경 로그도 계정 탈취 취약점을 설명하지 않았다. 연구자의 타임라인에 따르면 버전 7.2.9에는 렌더링 수정만 언급됐다. 따라서 일반 릴리스 노트를 읽은 사용자는 업데이트가 심각한 보안 결함을 차단했다는 사실을 거의 알 수 없었다.

이 조용한 패치 과정은 이번 이야기의 이례적인 시점을 만들었다. 공개 증명이 나오기 전에 취약한 동작은 사라졌지만, 많은 설치본은 즉시 업데이트되지 않는다. 공개는 이전 빌드를 계속 사용하는 사용자 쪽으로 위험을 옮겼다.

세미콜론 하나가 링크 하나를 여러 명령으로 바꿨다

핵심 실패는 경계 처리 오류였다. Telegram은 내부 명령을 구분하는 문자를 이스케이프하지 않은 채 URL을 텍스트로 직렬화했다.

Telegram Desktop은 보통 하나의 실행 인스턴스만 허용한다. 운영체제가 tg:// 링크를 위해 또 다른 인스턴스를 실행하면, 두 번째 프로세스는 링크를 기존 프로세스로 전달한다. 이는 로컬 프로그램이 데이터를 교환할 수 있게 하는 프로세스 간 통신, 즉 IPC를 통해 이뤄진다.

Telegram의 IPC 형식은 각 명령을 명령어, 인수, 세미콜론으로 표현했다. 일반 링크는 이 구분자로 끝나는 OPEN: 레코드가 됐다. 수신 프로세스는 들어오는 텍스트를 각 세미콜론에서 분할했다.

이 형식은 명령 인수에 이스케이프되지 않은 세미콜론이 절대 포함될 수 없을 때만 안전했다. Telegram은 이 조건을 강제하지 않았다. 특별히 구성된 URL은 자체 구분자를 포함할 수 있었고, 이로 인해 수신기는 URL 하나를 여러 내부 명령으로 해석했다.

이는 레코드 구분자 인젝션이다. 주입된 값이 Telegram 자체의 제한된 명령 언어로 들어갔다는 점에서 문제는 명령 인젝션과 유사하다. 공격자는 제한 없는 운영체제 셸에 직접 접근한 것은 아니었다.

지원되는 내부 명령 대부분의 영향은 제한적이었다. 하나는 애플리케이션을 표시할 수 있었고, 다른 하나는 종료할 수 있었다. 위험한 명령은 스키마 제한 없이 URL을 허용하는 또 다른 OPEN: 레코드였다.

이 동작은 interpret:라는 내부 URI 스키마를 노출했다. URI 스키마는 소프트웨어에 주소 처리 방법을 알려주는 접두사다. 익숙한 예로 https:, mailto:, Telegram에 등록된 tg: 스키마가 있다.

Telegram은 interpret:를 운영체제에 등록하지 않았다. 이는 데스크톱 클라이언트 내부에만 존재했고 Telegram의 릴리스 게시 절차를 지원했다. 내부 스크립트는 이를 이용해 텍스트 지시 파일을 읽고 지정된 빌드를 Telegram 채널에 업로드했다.

이 레거시 헬퍼는 대상 채널, 로컬 파일, 선택적 캡션을 설명하는 필드를 예상했다. 또한 from: 필드에 기재된 계정 식별자를 확인할 수도 있었다. 그러나 이 검사는 지시 파일에 해당 필드가 포함된 경우에만 실행됐다.

공격자는 from:을 완전히 생략할 수 있었다. 그러면 Telegram은 계정 비교를 건너뛰고 파일 처리를 계속했다. 더 중요한 점은 헬퍼가 선택한 로컬 파일을 읽고 전송하기 전에 어떤 확인도 요구하지 않았다는 것이다.

신뢰할 수 있는 로컬 릴리스 스크립트가 사용할 때 이 동작의 위협 모델은 제한적이었다. 이를 로컬에서 호출할 수 있는 사람이라면 이미 해당 컴퓨터에 접근할 수 있었을 가능성이 높다. IPC 인젝션은 외부 입력을 통해 interpret:에 도달할 수 있게 하면서 이 가정을 바꿨다.

브라우저가 연결 고리를 완성했다. Telegram 채팅 안에서 직접 처리된 tg:// 링크는 취약한 소켓을 통과하지 않았다. 하지만 일반 HTTPS 링크는 시스템 브라우저에서 열렸다.

공격자가 제어하는 웹사이트는 이 HTTPS 요청에 조작된 tg:// URL로 리디렉션해 응답할 수 있었다. 그러면 운영체제가 또 다른 Telegram 프로세스를 실행한다. 이 프로세스는 이스케이프되지 않은 URL을 기존 인스턴스로 전달하고, այնտեղ 주입된 레코드는 별도 명령이 됐다.

일부 브라우저나 운영체제 구성에서는 Telegram을 열기 전에 확인 메시지가 표시될 수 있었다. 이 메시지는 마찰을 더했지만 숨겨진 명령 순서를 설명하지는 않았다. 표시되는 HTTPS 주소도 최종 Telegram URI와 무관해 보일 수 있었다.

따라서 이 결함은 단일한 극적인 함수 내부가 아니라 여러 구성 요소에 걸쳐 있었다. URL 파싱, 프로세스 전달, 구분자 기반 프로토콜, 신뢰받는 릴리스 헬퍼는 각각 로컬에서는 설계대로 동작했다. 이들의 조합이 익스플로잇을 만들었다.

이 패턴은 개발자에게 중요하다. 내부 인터페이스는 설계자가 신뢰할 수 있는 코드만 접근할 수 있다고 가정하기 때문에 방어적 검토를 덜 받는 경우가 많다. 다른 기능이 예상치 못한 경로를 만들면 이런 가정은 함께 무너질 수 있다.

자동 다운로드가 파일 탈취 경로를 예측 가능하게 만들었다

익스플로잇에는 피해자 컴퓨터에 있는 지시 파일이 필요했고, Telegram의 기본 그룹 다운로드 동작이 이를 알려진 위치에 제공했다.

interpret: 헬퍼는 조작된 링크 내부에서 모든 공격 지시를 직접 받지 않았다. 대상 채팅과 업로드할 파일을 설명하는 로컬 텍스트 파일을 예상했다. 따라서 공격자는 그 지시 파일을 대상 컴퓨터에 배치해야 했다.

Telegram 그룹이 전달 채널을 제공했다. 공개 내용에 따르면 Telegram Desktop은 테스트된 기본 구성에서 최대 8 MiB의 그룹 파일을 자동으로 다운로드했다. 브로드캐스트 채널 다운로드는 다르게 동작했기 때문에, 증명에는 슈퍼그룹이 사용됐다.

공격자는 먼저 슈퍼그룹을 만들고 대상을 추가했다. Telegram의 기본 개인정보 보호 구성은 별도 승인 없이 이 추가를 허용할 수 있었다. 이후 공격자는 특별히 준비한 텍스트 파일을 그룹에 게시했다.

피해자가 그룹을 열면 Telegram은 해당 첨부 파일을 자동으로 저장했다. Windows에서는 파일이 사용자의 Downloads\Telegram Desktop 디렉터리에 저장됐다. 로컬 파일명 충돌이 없는 한, 발신자는 각 첨부 파일의 원래 파일명을 제어했다.

예측 가능성은 필수적이었다. 공격자는 보통 대상의 Windows 사용자 이름을 알 수 없으므로 절대 경로는 신뢰하기 어려웠다. 그러나 Telegram의 헬퍼는 상대 경로도 허용했다.

이 상대 경로는 Telegram Desktop의 애플리케이션 데이터 디렉터리를 기준으로 해석됐다. 이 시작점에서 연구자는 상위 디렉터리로 이동해 사용자의 홈 폴더에 들어간 뒤, 알려진 다운로드 디렉터리로 이동할 수 있었다. 조작된 경로에는 사용자 이름이 필요하지 않았다.

각 지시 파일은 하나의 로컬 대상을 지정하고 공격자의 슈퍼그룹을 목적지로 지정했다. Telegram의 헬퍼는 지시 문서당 최종 file: 값 하나만 처리했다. 공격자는 여러 문서를 제공해 이 제한을 우회할 수 있었다.

조작된 링크 역시 여러 개의 주입된 OPEN:interpret: 레코드를 담았다. 각 레코드는 서로 다른 다운로드된 지시 파일을 가리켰다. 결과적으로 한 번의 클릭으로 여러 업로드를 유발할 수 있었다.

계정 탈취를 위해 증명은 Telegram의 tdata 폴더 내부에 있는 예측 가능한 세 경로를 표적으로 삼았다. 첫 번째는 솔트와 암호화된 데이터 암호화 키를 저장했다. 두 번째는 암호화된 MTProto 인증 데이터를 보관했고, 세 번째는 저장된 계정 데이터를 색인했다.

MTProto는 Telegram의 클라이언트-서버 프로토콜이다. 인증 데이터는 승인된 데스크톱 클라이언트가 전체 로그인 절차를 반복하지 않고도 자신을 식별할 수 있게 한다. 따라서 파일에 읽을 수 있는 비밀번호가 없더라도 가치가 있다.

연구자는 관련 폴더 이름이 기본 설치 환경 전반에서 일관되게 유지된다고 보고했다. 한 폴더 이름은 무작위 설치별 값이 아니라 Telegram의 기본 데이터 이름에서 파생됐다. 이로써 원격 표적화의 또 다른 장애물이 사라졌다.

클릭 후 주입된 헬퍼 명령은 해당 세 파일을 열어 공격자의 그룹으로 전송했다. Telegram은 이 내부 릴리스 경로에 대해 파일 업로드 확인을 표시하지 않았다. 공격자는 이후 다른 컴퓨터에서 해당 디렉터리를 재구성할 수 있었다.

동일한 원시 기능은 경로를 알고 있는 경우 관련 없는 파일도 표적으로 삼을 수 있었다. 개발자는 클라우드 토큰, 패키지 자격 증명, 서명 키, SSH 관련 자료를 관례적인 위치에 보관하는 경우가 많다. 데스크톱 애플리케이션 역시 예측 가능한 프로필 디렉터리 아래에 중요한 데이터베이스를 저장한다.

다만 “모든 파일”이라는 표현에는 신중한 해석이 필요하다. 이 취약점은 공격자가 식별할 수 있는 경로에 있는 읽기 가능한 파일에 Telegram 프로세스가 접근하도록 허용했다. 운영체제 권한은 여전히 적용됐으며, 사용자 이름, 사용자 지정 디렉터리 및 파일명에 대한 불확실성도 남아 있었다.

공격에는 여러 환경 조건도 필요했다. Telegram Desktop이 실행 중이어야 했고, 취약한 버전이 리디렉션된 링크를 처리해야 했으며, 명령 첨부 파일이 예측 가능한 로컬 경로에 도달해야 했다. 이후 피해자가 공격자의 링크를 클릭해야 했다.

이러한 요건은 이 공격이 제로클릭이 아니라 원클릭 공격임을 뜻한다. 자동 다운로드가 첨부 파일 클릭 없이 준비 과정의 일부를 수행했지만, 브라우저 탐색은 여전히 필요했다. 이 구분을 정확히 설명하면 조직이 취약점을 축소하지 않으면서 노출 수준을 평가하는 데 도움이 된다.

편의성과 신뢰가 Telegram Desktop 내부에서 충돌했다

더 깊은 보안상의 절충점은 암호화와 사용성의 대립이 아니라, 신뢰된 자동화와 신뢰할 수 없는 입력에 대한 노출의 충돌이었다.

취약한 interpret: 기능은 제한적인 운영 목적을 수행했다. Telegram의 릴리스 프로세스는 빌드와 변경 로그 텍스트를 채널에 업로드해야 했다. 이 작업을 자동화하면 유지관리자의 반복 업무를 줄일 수 있었다.

그러나 이 헬퍼에는 상당한 권한이 부여돼 있었다. 로컬 경로를 읽고 인증된 Telegram 계정을 통해 결과를 전송할 수 있었다. 반복적인 확인 메시지는 자동화 목적을 훼손했을 것이므로 확인을 요청하지 않았다.

진입점이 비공개이며 로컬에 머무르는 한 이러한 설계는 합리적일 수 있다. 문제는 일반적인 링크 처리가 동일한 경로에 도달하면서 발생했다. 공개 URL을 위해 만들어진 입력 경계가 내부 게시 도구의 권한을 물려받았다.

Telegram Desktop 취약점은 “내부용”이라는 말이 권한 부여를 대체해서는 안 되는 이유를 보여준다. 코드 변경, 프로토콜 핸들러, 플러그인 및 프로세스 브리지는 비공개 기능을 예상치 못한 맥락에서 도달 가능하게 만들 수 있다. 모든 권한 있는 작업에는 자체적인 검증이 필요하다.

IPC 파서는 구두점에서 추론한 구조도 신뢰했다. 구분자 기반 형식은 안전할 수 있지만, 데이터는 직렬화 전에 예약 문자를 이스케이프해야 한다. 수신자는 실제 레코드 경계를 식별한 뒤에만 이를 디코드해야 한다.

Telegram의 수정은 체인의 양쪽을 모두 해결했다. 소켓을 통해 값을 전송하기 전에 레코드 구분자를 퍼센트 이스케이프하고, 레코드를 분할한 뒤 이를 디코드했다. URL 내부의 세미콜론은 더 이상 다른 명령 경계를 만들 수 없었다.

패치는 interpret: 스킴과 그 전송 경로 헬퍼도 완전히 제거했다. 이는 또 다른 조건 검사 뒤에 권한 있는 레거시 기능을 남겨두는 대신 공격 표면을 줄인 조치다. 사용되지 않는 권한을 제거하는 편이 그 주변에 필터를 추가하는 것보다 더 안전한 경우가 많다.

추가 보호 조치는 위험한 명령 조합을 차단했다. 업데이트된 코드는 동일한 연결에 OPEN: 레코드가 포함된 경우 CMD: 및 CTRL: 레코드를 건너뛰었다. 또한 해당 연결에서 비로컬 URL이 나타난 뒤에는 로컬 파일 경로를 거부했다.

이러한 계층은 보안 패치가 대체 경로를 놓칠 수 있기 때문에 중요하다. 세미콜론 이스케이프는 입증된 주입 문제를 해결했다. 권한 있는 스킴 제거는 나중에 또 다른 파서 결함이 나타나더라도 가장 심각한 목적지를 없앴다.

CVE 기록은 이 문제를 출력에서 구분자를 부적절하게 중화한 것으로 분류한다. 이 설명은 첫 번째 결함을 포착하지만 전체 영향을 담지는 못한다. 계정 탈취에는 두 번째의 더 높은 권한을 지닌 동작이 필요했다.

이 차이는 자동화된 취약점 라벨이 연쇄 공격의 심각성을 과소평가할 수 있는 이유를 설명한다. 파싱 버그는 단독으로 검토하면 경미해 보일 수 있다. 그러나 주입된 명령이 로컬 비밀을 업로드할 수 있는 헬퍼에 도달하면 심각도가 달라진다.

이 문제는 데스크톱 메신저 보안에 대한 흔한 가정에도 도전한다. 사용자는 흔히 전송 암호화, 악성 첨부 파일, 피싱 자격 증명에 집중한다. 여기서는 한 번의 조작된 탐색 이후 Telegram 자체가 파일 전송 수단이 됐다.

실행 가능한 첨부 파일은 필요하지 않았다. 따라서 기존 악성코드 검사는 일반 텍스트 파일과 정상 HTTPS 링크만 볼 수 있었다. 의미 있는 동작은 사용자의 기존 파일시스템 권한으로 작동하는 합법적인 Telegram 기능을 통해 일어났다.

기업 보안 통제는 이러한 애플리케이션 수준 위험을 고려해야 한다. 관리형 기기에는 백신 적용 범위뿐 아니라 최소 버전 강제가 필요하다. 보안팀은 로컬 문서, 브라우저 프로필 또는 개발자 자격 증명에 접근할 수 있는 메신저 클라이언트도 목록화해야 한다.

개발자에게도 딥링크, 로컬 소켓, 자동화 훅 및 명령줄 브리지에 동일한 교훈이 적용된다. 이들 사이의 모든 전환은 원래 입력이 로컬인지, 원격인지, 신뢰되는지, 사용자 승인을 받았는지를 보존해야 한다.

데이터가 이러한 경계를 넘을 때 권한이 조용히 확대되어서는 안 된다. 브라우저가 제공한 URL이 결국 문자열이 된다는 이유만으로 릴리스 엔지니어의 로컬 스크립트 권한을 획득해서는 안 된다.

패치는 연쇄를 해결하지만 공개 증거에는 한계가 있다

공개 내용은 신뢰할 수 있고 코드로 뒷받침된 증명을 제시하지만, 광범위한 악용이나 모든 플랫폼에서 동일한 노출을 입증하지는 않는다.

연구자는 Windows에서 익스플로잇을 확인하고 관련 Telegram 소스 코드를 문서화했다. 이 연쇄에는 예측 가능한 Windows 경로와 6.9.3부터 7.2.8까지의 릴리스에서 관찰된 동작이 포함됐다. 이는 테스트된 환경에 대한 강력한 증거다.

그러나 지원되는 모든 운영체제가 동일하게 동작했다는 증거는 아니다. 파일 위치, 브라우저 프롬프트, URI 처리, 샌드박싱 및 다운로드 기본값은 Windows, macOS, Linux에서 다르다. 사용자는 공개된 테스트 범위를 넘어 일반화해서는 안 된다.

사용자 파일이 탈취될 수 있다는 제목의 주장에도 기술적 한계가 있다. Telegram은 클라이언트의 운영체제 계정이 읽을 수 있는 파일에만 접근할 수 있었다. 공격자에게도 사용 가능한 경로나 이를 안정적으로 예측할 방법이 필요했다.

이러한 한계가 취약점을 경미하게 만들지는 않는다. 특히 개발자 워크스테이션에서는 많은 중요한 파일이 관례적인 위치에 있다. 시연에 사용된 Telegram 세션 경로는 설계상 예측 가능했다.

계정 탈취는 로컬 패스코드 상태에도 의존했다. 증명은 로컬 패스코드가 Telegram 데이터를 보호하지 않는 경우 직접적인 세션 재구성이 가능함을 보여줬다. 강력한 로컬 패스코드는 탈취 이후의 손쉬운 복호화를 막을 수 있다.

Telegram의 클라우드 2단계 인증은 이미 승인된 데스크톱 세션의 재사용을 반드시 막지는 못했다. 이 통제는 인증 이벤트를 보호하지만, 익스플로잇은 인증 이후의 세션 자료를 표적으로 삼았다. 사용자는 이러한 방어 계층을 구분해야 한다.

또 다른 불확실성은 실제 악용에 관한 것이다. 공개 자료에는 패치 이전에 악용이 확인됐다는 증거가 제시되지 않았다. 개념 증명은 실행 가능성을 보여줄 뿐, 확산 정도를 보여주지는 않는다.

이 구분은 사고 대응에 영향을 준다. 조직은 오래된 Telegram 릴리스가 설치됐다는 이유만으로 침해를 가정해서는 안 된다. 그렇다고 기술적 세부 정보가 공개된 후에도 취약한 상태로 남아 있던 시스템을 무시해서도 안 된다.

공개 일정은 명확한 노출 경계를 만든다. Telegram은 2026년 9월 16일에 수정 사항을 커밋했고, 버전 7.2.9는 9월 17일에 제공되기 시작했다. 상세 설명은 10월 3일에 공개됐고, CVE는 나흘 뒤에 뒤따랐다.

패치된 소프트웨어가 이미 존재했음에도 공격자는 10월 3일 이후 공개된 공격 로드맵을 확보했다. 방어자와 공격자가 동일한 기술적 연쇄를 연구할 수 있게 되면서 자동 업데이트가 불가능한 시스템의 위험은 커졌다.

Telegram의 공개 저장소는 완화 조치를 검증할 구체적인 방법을 제공한다. 연구자가 식별한 패치 코드 라인은 7.2.9 릴리스에 포함돼 있다. 이후 버전에도 이 변경 사항이 포함돼야 한다.

그러나 버전 번호만으로 과거 악용 여부를 답할 수는 없다. Telegram 계정 보유자는 활성 세션, 예상치 못한 그룹 가입 및 설명되지 않는 업로드를 검토해야 한다. 관리형 환경은 가능한 경우 엔드포인트 및 프록시 기록도 조사해야 한다.

피해자 계정에서 발생한 예기치 않은 파일 업로드는 특히 관련성이 높다. 증명은 탈취한 데이터를 전송하는 데 Telegram 자체를 사용했다. 공개 문서에는 완전한 포렌식 가이드가 제공되지 않았지만, 이 동작은 서버 측 또는 클라이언트에서 보이는 흔적을 남길 수 있다.

tg:// 링크로 연결되는 낯선 브라우저 리디렉션도 주의할 필요가 있다. 원치 않는 슈퍼그룹에서 다운로드된 텍스트 첨부 파일도 마찬가지다. 어느 신호도 단독으로 악용을 입증하지는 않지만, 두 신호의 조합은 입증된 준비 및 전달 경로와 일치한다.

사용자는 의심스러운 다운로드를 삭제하는 것을 업데이트의 대체 수단으로 여겨서는 안 된다. 명령 파일을 제거하면 한 번의 익스플로잇 시도는 중단시킬 수 있지만, 파서를 수정하거나 레거시 헬퍼를 제거하지는 못한다.

마찬가지로 자동 다운로드를 비활성화하면 취약한 코드를 닫지 않은 채 노출을 줄일 수 있다. 공격자는 알려진 경로에 명령 문서를 배치할 다른 방법을 찾을 수 있다. 결정적인 통제 수단은 여전히 버전 7.2.9 이상이다.

Telegram 사용자와 보안팀이 다음으로 주시해야 할 사항

다음 검증 과제는 취약한 설치가 빠르게 사라지는지, 악용 증거가 나타나는지, Telegram이 조용한 수정 사항을 둘러싼 보안 공개를 개선하는지 여부다.

첫 번째 신호는 버전 채택이다. 개인 사용자는 Telegram Desktop 설정을 열어 버전 7.2.9 이상을 실행 중인지 확인해야 한다. 조직은 Telegram 사용이 허용된 모든 관리형 엔드포인트에서 이 기준선을 강제해야 한다.

이후 버전이 제공되는 경우에는 동일한 수정 사항과 후속 유지보수를 포함하므로 더 바람직하다. 사용자는 Telegram의 일반 업데이터 또는 검증된 배포 채널을 통해 업데이트를 받아야 한다. 비공식 설치 프로그램은 별개의 공급망 위험을 초래한다.

즉시 업데이트할 수 없는 사용자는 취약한 데스크톱 빌드 사용을 중단해야 한다. 애플리케이션을 닫는 것만으로는 지속 가능한 기업 통제가 아니지만, 공개된 IPC 경로에 필요한 실행 중인 인스턴스를 제거한다. 웹 또는 모바일 대안은 다른 코드 경로를 사용한다.

두 번째 신호는 신뢰할 수 있는 악용 보고다. 보안 공급업체, 사고 대응 담당자 및 Telegram 자체는 로그를 공개 증명과 비교한 뒤 공격을 식별할 수 있다. 확인된 사례가 나오면 이 사건은 심각한 설계 실패에서 진행 중인 사고로 바뀌게 된다.

그러한 증거가 나타나기 전까지 보도는 악용 가능성과 실제 악용의 구분을 유지해야 한다. 문서화된 연쇄는 긴급 패치를 뒷받침한다. 그러나 이 특정 결함을 통해 Telegram 계정이 대규모로 침해됐다는 주장을 뒷받침하지는 않는다.

세 번째 신호는 Telegram의 공개 관행이다. 보안 수정은 절제된 커밋 제목 아래 반영됐고, 릴리스 노트에는 심각도가 높은 취약점이 언급되지 않았다. 연구자가 세부 정보를 공개하기 전에는 사용자가 업데이트를 우선시할 이유가 거의 없었다.

협조적 공개 절차가 항상 즉각적인 기술 세부 정보 공개를 허용하는 것은 아니다. 공급업체는 업데이트가 확산되는 동안 사용자를 보호하기 위해 권고문 발표를 미루기도 한다. 그럼에도 명시적인 보안 공지는 익스플로잇 제작법을 공개하지 않고도 설치를 유도할 수 있다.

Telegram은 영향을 받는 플랫폼, 텔레메트리, 탐지 지침도 명확히 할 수 있다. 연구에서는 Windows에서의 동작이 확인됐지만, 더 광범위한 플랫폼 노출 여부는 여전히 불확실하다. 공식적인 영향 범위 정보는 보안팀이 안일함과 불필요한 경계 모두를 피하는 데 도움이 된다.

사용자는 몇 가지 보완 통제로 잔존 위험을 줄일 수 있다. 그룹 첨부 파일이 예측 가능한 경로에 자동으로 저장되지 않도록 “각 파일의 저장 위치 묻기”를 활성화하라. 통신 요구 사항에 맞는다면 그룹 추가를 연락처로 제한하라.

강력한 로컬 Telegram 비밀번호도 설정해야 한다. 패치되지 않은 클라이언트에서 발생하는 임의 파일 탈취를 막지는 못하지만, 로컬에 저장된 세션 자료를 추가로 보호한다. 계정 비밀번호나 기기 PIN을 재사용하지 말아야 한다.

Telegram의 활성 세션을 검토하고 알 수 없는 항목은 종료하라. 침해 가능성이 있다면 다른 세션에서 로그아웃하고, 클라이언트를 업데이트한 뒤 다시 인증하라. 위험에 처한 파일을 기준으로 노출된 개발자 키, 브라우저 자격 증명 또는 클라우드 토큰을 교체하라.

조직은 한 단계 더 나아가야 한다. 소프트웨어 인벤토리에서 7.2.8 이하 Telegram Desktop 버전을 조회한 뒤 업그레이드가 성공적으로 완료됐는지 확인하라. 예기치 않은 Telegram 업로드, 의심스러운 그룹 초대, Telegram 프로토콜 링크에 의해 실행된 브라우저를 조사하라.

보안팀은 클라이언트가 읽을 수 있었던 정보도 고려해야 한다. 개발자 워크스테이션에는 SSH 키, 패키지 레지스트리 자격 증명, 클라우드 구성 및 소스 코드 비밀 정보가 있을 수 있다. 같은 익스플로잇이라도 키오스크나 엄격히 제한된 엔드포인트에서는 결과가 달라질 수 있다.

더 넓은 교훈은 애플리케이션 검토에 반영돼야 한다. 딥 링크는 둘 다 같은 파서를 사용하더라도 로컬 명령보다 낮은 신뢰 수준으로 다뤄야 한다. 내부 자동화 엔드포인트는 그 동작이 데이터를 노출할 경우 인증 또는 명시적 사용자 확인이 필요하다.

직렬화된 IPC 메시지는 엄격한 파싱, 이스케이프 처리 및 스키마 검증을 갖춘 구조화된 형식을 사용해야 한다. 원래의 워크플로에 더 이상 필요하지 않은 권한 있는 레거시 핸들러는 제거해야 한다. 보안 경계는 최종 민감 작업 단계에서 강제돼야 한다.

대부분의 독자는 익스플로잇을 재현하거나 Telegram의 소스 코드를 조사할 필요가 없다. 지금 답해야 할 질문은 세 가지다. 데스크톱 클라이언트는 최신 상태인가, 공개 이후에도 취약했는가, 그리고 의심스러운 활동으로 민감한 파일이 노출됐을 수 있는가?

먼저 업데이트한 다음 세션과 최근 그룹 활동을 검토하라. 오래된 Telegram Desktop 취약점이 중요한 자격 증명이 저장된 시스템에 영향을 미쳤다면, 이를 단순한 메시징 계정 위험이 아니라 파일 노출 가능성이 있는 사고로 취급해야 한다. 그러한 대응이 익스플로잇이 실제로 접근할 수 있었던 범위에 부합한다.