Hacktron이 Rocket.Chat에 24시간 보안을 제공하는 방법
- 평균 1~2분
- PR 하나의 보안 이슈를 리뷰하는 데 걸리는 시간
- 실제 취약점 17건
- 첫 20일 동안 발견 및 분류
- 발견된 이슈의 73%
- 조치 가능했고 실제로 처리됨
“이제 모든 PR에 보안 스캔을 확대할 수 있게 되었습니다.
“Hacktron이 잠재적인 문제를 표시해 주어, 더 주의가 필요한 풀 리퀘스트에 리뷰 역량을 집중할 수 있습니다.”
Julio Araujo
보안 디렉터
Rocket.Chat 소개
Rocket.Chat은 전 세계 정부, 국방, 기업 팀이 사용하는 오픈 소스 기반의, 완전히 맞춤 설정할 수 있는 커뮤니케이션 플랫폼입니다. 이 정도 규모의 소프트웨어에서 보안은 최우선 과제입니다. 보안 취약점을 가장 적은 비용으로 잡을 수 있는 곳 중 하나는 소프트웨어 개발 수명 주기의 초기, 즉 프로덕션에 도달하기 전에 더 나은 설계와 지속적인 코드 리뷰를 거치는 단계입니다.
과제: 코드 작성 속도와 보안 리뷰 사이에서 벌어지는 격차
하지만 AI 이전에도 개발자 대비 보안 엔지니어 비율 때문에 모든 PR의 취약점을 꼼꼼히 리뷰하는 것은 현실적으로 불가능했습니다. 이제 AI가 코드를 작성하고 배포하는 속도를 높이면서, 모든 변경을 보안 관점에서 리뷰하는 일은 그 어느 때보다 중요해졌습니다.
“모든 PR을 철저히 리뷰할 만큼 엔지니어가 충분하지 않습니다. 기존의 SAST, SCA, 시크릿 스캔 도구는 매우 유용할 수 있고 지금도 사용하고 있지만, 비즈니스 로직 취약점 같은 복잡한 이슈를 찾는 데 필요한 컨텍스트가 부족한 경우가 많습니다.
“또한 여러 단계에 걸쳐 추론하거나, 취약점을 연결해 시스템이 실제로 어떻게 악용될 수 있는지 파악하는 데도 어려움을 겪습니다.”
Julio Araujo
보안 디렉터
Hacktron으로 모든 PR에 보안 리뷰 확장하기
이 격차를 메우기 위해 Rocket.Chat은 Hacktron Review로 24시간 지속적인 코드 및 보안 리뷰를 수행하며, 비용이 큰 취약점을 프로덕션에 도달하기 전에 잡아냅니다.
Hacktron은 모든 PR에서 다음을 수행합니다.
- 코드 변경 사항에 대한 심층 보안 리뷰를 수행합니다.
- 명확한 댓글로 PR에 바로 취약점을 표시합니다.
- 개발자가 병합 전에 조치 가능한 이슈를 수정할 수 있게 합니다.
- 보안 팀이 우선순위가 낮은 발견 사항을 추적하고 묶어 주기적으로 수정할 수 있도록 돕습니다.
- 주기적인 감사나 수동 리뷰에만 의존하지 않고 보안 리뷰를 지속적으로 유지합니다.
“Hacktron은 시간이 지나면서 저희 코드베이스와 피드백으로부터 학습합니다.
“의도된 기능, 수용한 위험, 보안 요구 사항에 대한 컨텍스트를 더 많이 제공할수록 오탐이 줄어들어, 정확도가 높아지고 문제가 아닌 항목을 분류하는 데 드는 시간도 줄어듭니다.”
Julio Araujo
보안 디렉터
Rocket.Chat에서 Hacktron이 수행한 리뷰를 분석해 보겠습니다. 어떤 취약점을 찾는지, 그 발견 사항이 얼마나 정확한지, 그리고 팀이 더 빠르게 배포하도록 어떻게 돕는지 살펴봅니다. 첫 20일 동안 Hacktron은 155개의 PR을 리뷰하고 실제 이슈를 찾아냈습니다. 여기에는 로그인한 사용자라면 누구나 다른 사용자의 전체 데이터 내보내기 파일을 내려받을 수 있었던 치명적인 권한 부여 버그, 배포 환경 전반에서 로그인 경계를 약화한 치명적인 Apple OAuth 결함 2건, 그리고 몇 건의 XSS 취약점이 포함됩니다.
발견 사항 분석
첫 20일(2026년 6월 5일~25일) 동안 Hacktron은 들어오는 모든 풀 리퀘스트를 리뷰하며, 변경된 파일 10,744개에 걸쳐 490회의 스캔을 실행했습니다. 다음은 리뷰한 PR, 발견한 이슈, 분류 결과, 그리고 정탐의 실제 심각도를 정리한 것입니다.
모든 PR이 자동으로 리뷰되었고, 일반적인 PR의 리뷰 자체는 약 1~2분 만에 끝났습니다(중앙값 1.4분, 95번째 백분위수 5.3분). 누구의 속도도 늦추지 않고 CI에 넣을 수 있을 만큼 빠릅니다. 다만 PR에 변경 사항이 많으면 Hacktron은 철저하게 테스트하기 위해 시간을 충분히 들인다는 점에 유의해야 합니다.
어떤 취약점을 찾나요?
이제 중요한 질문은 어떤 취약점을 잡아냈느냐입니다. Hacktron은 단순한 패턴 매처가 아닙니다. 보안 연구원처럼 코드를 읽고 추론합니다. 그래서 발견 사항은 취약한 접근 제어, 인증/2FA 우회, XSS, SSRF/오픈 리디렉션, 암호화 실패, 시크릿 노출, 비즈니스 로직 결함까지 OWASP Top 10의 대부분을 아울렀습니다.
Hacktron이 잡아낸 상위 3개 취약점을 자세히 살펴보겠습니다.
Apple OAuth를 통한 계정 탈취
Rocket.Chat이 Hacktron을 워크플로에 통합한 직후 Hacktron이 처음 발견한 취약점으로, 매우 정교하면서도 치명적인 버그입니다.
여기서 중요한 점은 Hacktron이 PR 변경 범위 밖에서 버그를 찾았다는 것입니다. Hacktron의 리뷰는 PR diff에만 좁게 한정되지 않기 때문입니다. Hacktron은 코드베이스 전체의 의존성과 영향을 따라가며 2차 취약점을 찾아냅니다.
높음
Apple OAuth 로그인에서 검증되지 않은 이메일을 통한 계정 탈취
apps/
loginHandler.ts의 Apple OAuth 로그인 핸들러에는 Apple ID 토큰에 이메일 주소가 없으면 클라이언트가 제공한 이메일 주소를 신뢰하는 취약점이 있습니다. loginRequest에서 클라이언트가 제공한 email 필드는 암호학적으로 검증되지 않으므로, 공격자는 임의의 이메일 주소(예: 피해자의 이메일)를 입력할 수 있습니다. 그러면 accounts_meld.js 훅이 이 검증되지 않은 이메일로 기존 사용자를 조회하고, 공격자의 Apple 서비스 ID를 피해자 계정에 연결합니다. 그 결과 공격자는 자신의 Apple ID로 피해자 계정에 로그인할 수 있으며, 이는 완전한 계정 탈취로 이어집니다.
재현 단계
- 공격자가 자신의 Apple ID로 Apple 로그인을 시작하되, Apple
identityToken에email클레임이 포함되지 않도록 합니다(예: 이메일을 공유하지 않은 Apple ID를 사용하거나, Apple이 이메일을 생략하는 이후의 로그인을 이용). - 공격자가 Rocket.Chat 서버로 전송되는 로그인 요청(예: DDP
login메서드 호출)을 가로챕니다. - 공격자가
loginRequest페이로드의email필드에 피해자의 이메일 주소를 넣어{"identityToken": "<attacker_token>", "email": "victim@example.com", "fullName": {...}}와 같이 수정합니다. - 서버가 요청을 처리합니다.
loginHandler.ts에서serviceData.email이 비어 있으므로serviceData.email = email(피해자의 이메일)을 할당합니다. accounts_meld.js훅이 피해자의 이메일로 사용자를 조회해 피해자 계정을 찾고, 공격자의 Apple ID를 그 계정에 연결합니다(Users.setServiceId(user._id, serviceName, serviceData.id)).- 이제 공격자는 피해자 계정에 로그인된 상태이며, 언제든 자신의 Apple ID로 접근할 수 있습니다.
apps/meteor/app/apple/server/loginHandler.ts에서 Apple 로그인 흐름은 Apple JWT에 이메일이 없으면 클라이언트가 제공한 이메일로 대신했습니다.
const serviceData = await handleIdentityToken(identityToken);if (!serviceData.email && email) { serviceData.email = email; // attacker-controlled fallback}공격자는 이메일 클레임이 없는 Apple JWT를 위조하고 요청에 임의의 email을 넣어,
어떤 사용자로든 인증할 수 있었습니다. 이 취약점은 기존 코드에 존재했기 때문에 Rocket.Chat은 이를 치명 등급 보안 권고
(GHSA-wx3c-76rf-wpwf, CVE-
Apple 로그인의 JWT 클레임 검증 누락
같은 핸들러에는 또 다른 버그가 있었습니다. JWT 서명은 검증했지만 클레임 검증은 건너뛰었습니다.
JWS.verifyJWT 대신 JWS.verify(서명만 검증)를 사용했고, aud, exp, nbf를 전혀 확인하지 않았습니다.
iss가 비어 있지 않은 Apple 서명 토큰이라면 무엇이든 받아들였기 때문에, 유출되었거나 다른 대상용으로 발급된 토큰을 재사용해 피해자로 로그인할 수 있었고,
재사용할 수 있는 기간에도 만료가 없었습니다. Rocket.Chat은 이를 높음 등급 보안 권고
(GHSA-c75c-5hc7-j4vp, CVE-
치명
Apple ID 토큰 핸들러의 JWT 대상(aud) 검증 누락으로 인한 계정 탈취
apps/meteor/app/apple/lib/handlePassportIdentityToken.ts의 handlePassportIdentityToken 함수는 Passport.js 기반 Apple 로그인 흐름(apps/meteor/app/apple/server/applePassportOAuth.ts)에서 Apple ID 토큰을 파싱하고 검증하는 역할을 합니다. 토큰의 암호 서명, 발급자(iss), 만료 시각(exp)은 올바르게 검증하지만, 대상(aud) 클레임은 검증하지 않습니다.
OpenID Connect 같은 JWT 기반 인증 흐름에서 aud 클레임은 토큰의 의도된 수신자(Client ID)를 나타냅니다. aud가 Rocket.Chat 인스턴스에 설정된 Apple Client ID와 일치하는지 검증하지 않으면, 애플리케이션은 유효한 Apple ID 토큰이라면 무엇이든 받아들입니다.
공격자는 “Apple로 로그인”을 활성화한 자체 애플리케이션을 만들어 이를 악용할 수 있습니다. 피해자가 공격자의 애플리케이션에 로그인하면, 공격자는 그 피해자의 유효한 Apple ID 토큰을 받습니다. 그런 다음 이 토큰을 Rocket.Chat 서버의 Apple OAuth 콜백 엔드포인트에 제출할 수 있습니다. 토큰이 실제로 Apple의 서명을 받았고, 발급자가 유효하며, 만료되지 않았기 때문에 handlePassportIdentityToken은 피해자의 데이터를 반환합니다. 그러면 상위 Passport 전략(applePassportOAuth.ts의 AppleStrategy)이 이 데이터로 공격자를 피해자로 로그인시키며, 이는 완전한 계정 탈취로 이어집니다.
참고로 apps/meteor/app/apple/lib/handleIdentityToken.ts의 다른 함수인 handleIdentityToken은 대상 검증을 올바르게 구현하지만, handlePassportIdentityToken에는 이 검증이 완전히 빠져 있습니다.
누구나 다른 사용자의 데이터 내보내기 파일을 내려받을 수 있었던 문제
GDPR 데이터 내보내기 다운로드 경로에서 접근 검사가 파일 객체 없이 호출되는 바람에 fail-open 상태가 되어, 로그인한 모든 사용자에게 권한을 부여했습니다. 유효한 내보내기 파일 ID만 있으면 공격자는 다른 사용자의 전체 데이터 내보내기, 즉 비공개 메시지, 프로필, 방 데이터를 가져올 수 있었습니다. PR #40889에서 발견되어 병합 전에 수정되었습니다.
치명
UserDataFiles의 객체 수준 권한 부여 결함(BOLA)으로 인증된 모든 사용자가 GDPR 데이터 내보내기 파일을 내려받을 수 있음
apps/
Rocket.Chat의 파일 업로드 접근 제어 메커니즘에 권한 부여 우회 취약점이 있습니다. 사용자가 UserDataFiles 컬렉션(비공개 메시지, 다이렉트 메시지, 개인 데이터를 포함한 사용자의 매우 민감한 GDPR 데이터 내보내기 파일이 담긴 컬렉션)에서 파일 다운로드를 요청하면, 서버는 요청한 사용자가 그 데이터 내보내기의 소유자인지 검증하지 않습니다.
결과: 더 강한 보안 태세, 그리고 문제가 아닌 항목 분류에 쓰는 시간 감소
Rocket.Chat에 가장 큰 효과는 레버리지입니다. Hacktron은 보안을 엔지니어링 속도의 걸림돌로 만들지 않으면서, 보안 팀이 개발 워크플로 전반에 전문가 수준의 리뷰를 일관되게 적용할 수 있게 해 줍니다.
그 결과 엔지니어링과 보안 사이의 피드백 루프가 더 촘촘해졌습니다. 취약점은 더 일찍 잡히고, 개발자는 변경 시점에 더 명확한 가이드를 받으며, 보안 팀은 노이즈를 걸러내는 데 쓰는 시간을 줄이고 정말 중요한 이슈에 더 많은 시간을 씁니다.