다운로드 버튼에서 30만 달러 가치의 비밀을 찾은 방법

발행: (2026년 2월 4일 오후 05:05 GMT+9)
13 min read
원문: Dev.to

Source: Dev.to

번역을 진행하려면 번역하고자 하는 본문 텍스트를 제공해 주시겠어요?
코드 블록, URL 및 마크다운 형식은 그대로 유지하면서 내용만 한국어로 번역해 드리겠습니다.

Introduction

그것은 대부분의 재난이 시작되는 것처럼, 약간의 호기심과 한가한 오후에서 시작되었습니다.

저는 애플리케이션을 다운로드했습니다. 해커라서가 아니라. 기업 스파이를 수행하고 있어서가 아니라. 제가 뭘 하는지 전혀 모르는 상황이라서가 아니라. 저는 그걸 사용하고 싶어서 다운로드했습니다.
혁신적인 개념이죠, 알죠.

설치 파일은 .exe 파일이었습니다. 처음 보는 사람에게 이것은 포장된 선물과 같은 소프트웨어입니다. 그리고 인터넷에서 낯선 사람이 보낸 선물처럼, 저는 그것을 뜯어보기로 했습니다.

“안에 뭐가 있을까?” 라고 저는 망치로 시계를 부수기 전에 아이가 시계 안을 궁금해하듯이 생각했습니다.

모든 현대 데스크톱 애플리케이션은 결국 소프트웨어인 척하는 웹사이트에 불과하다는 사실이 밝혀졌습니다. 마치 “집에서 만든” 음식이 사실 냉동팩에서 나온 것이라는 걸 알게 된 것과 비슷합니다—기술적으로는 진짜지만, 철학적으로는 실망스러운 것이죠.

이 특정 애플리케이션은 Electron으로 만들어졌으며, 그 안에는 app.asar라는 파일이 있었습니다. 이것을 압축 파일이지만 절대 압축 파일이 아니라고 생각하게 만드는 일종의 zip 파일이라고 생각하면 됩니다.

npx asar extract app.asar ./unpacked

그 안에는 수천 줄에 달하는 압축·난독화된 JavaScript가 있었는데, 마치 누군가가 키보드에 재채기를 하고 그것을 설계라고 부른 듯했습니다. 그리고 그곳에, 마치 공원 벤치에 놓인 지갑처럼, .env 파일이 놓여 있었습니다.

전혀 모르는 사람들을 위해 말하자면, .env 파일은 개발자들이 비밀을 저장하는 곳입니다: API 키, 데이터베이스 자격 증명 등, 절대로, 절대로, 어떤 상황에서도 프로덕션에 배포해서는 안 되는 것들 말이죠.

그것은 보안 101입니다. 문자 그대로입니다. 그들이 처음 가르쳐 주는 내용이죠:

🚨 소프트웨어 개발 규칙 #1: .env 파일을 커밋하지 마세요.

이것은 고급 지식도, 보안 연구자들의 세대를 거쳐 전해 내려오는 신비로운 지혜도 아닙니다. 소변을 보고 손을 씻는 것과 같은, 소프트웨어 개발의 기본적인 위생 수칙입니다. 그런데도… 거기에 있었습니다. 반짝이며, 암호화되지 않은, 자격 증명으로 가득 찬 채.

저는 이름을 밝히지 않겠습니다. 손가락질도 하지 않겠습니다. 마치 자연 다큐멘터리가 사자를 먹는 영양을 임상적인 거리감과 약간의 공포감으로 묘사하듯, 제가 발견한 것을 그대로 서술하겠습니다.

Discovery

항목심각도내 반응
API Keys🔴 Critical여러 개. 활성화됨. 비용이 많이 듦.
Infrastructure URLs🔴 Critical내부 엔드포인트. 절대 공개되지 않음.
Service Credentials🟠 High분석 로그에 모든 것이 기록됨.
ML Inference Endpoints🟠 High클라우드 GPU가 brrrr 소리를 내며 비용을 잡아먹음.

전체 잠재 노출 규모? 잠시 직업을 바꿀까 고민할 정도로 충분히 심각했습니다.

이제 개인적인 이야기를 해볼게요.

이 코드를 배포한 엔지니어는? 업계 평균, 지역, 그리고 현재 기술 직업 시장 상황을 고려하면 연봉이 $300 000 정도일 것 같습니다.

삼백. 천. 달러.

집 열쇠를 현관 매트 밑에 두는 소프트웨어 버전—하지만 현관 매트는 투명하고 “KEYS UNDER HERE” 라는 표지판을 붙여놓은 상황과 같습니다.

전혀 원망하지 않아요. 전혀 원망하지 않아요. 단지 기록을 위해 적는 건데, 저는 겸손한 호기심을 가진 사람으로서 45 분 정도의 가벼운 조사(남은 피자를 먹으며)만에 이 사실을 발견했습니다. 그 사이에 어느 곳에서는 시니어 소프트웨어 엔지니어가 스톡 옵션을 챙기고 있겠죠.

📍 플롯 트위스트: 피자는 차가웠지만, 자격 증명은 차갑지 않았습니다.

명백한 취약점을 찾은 뒤, 저는 책임감 있는 연구자가 할 일을 했습니다: 계속 탐색했습니다.

JavaScript 번들은 난독화되었지만, 난독화는 트렌치코트가 변장하는 것과 같습니다. 기술적으로는 감추지만, 5초 이상 들여다보는 사람은 그 아래를 볼 수 있습니다. 제가 찾은 것은:

  • 🗂️ Source‑map 힌트 – 내부 저장소를 가리킴
  • 🐛 디버그 심볼 – 제거돼야 할 것들
  • 📋 하드코딩된 설정 – 개발 환경에서 복사·붙여넣기된 것
  • 📡 gRPC 정의 – 전체 API 구조를 설명

각 발견은 마치 중첩 인형을 여는 것과 같았지만, 작은 인형 대신 작은 실패들이 들어 있었습니다.

여기까지 읽으셨다면, 드라마틱한 결말을 기대하실 수도 있겠네요: 회사와의 대면, 버그 바운티 지급, CEO의 진심 어린 사과. 대신 제가 드릴 수 있는 더 가치 있는 것은 교훈입니다.

당신의 빌드 파이프라인은 보안 기능이 아닙니다.
Electron 앱은 추가 단계가 있는 zip 파일입니다.
난독화는 암호화가 아닙니다.

그리고 신성한 모든 것들을 위해, 배포하기 전에 무엇을 배포하고 있는지 반드시 확인하세요.

Quick “Before‑You‑Ship” Checklist

# Extract the asar archive
npx asar extract your-app.asar ./check-this

# Grep for obvious secrets
grep -r "API_KEY\|SECRET\|PASSWORD" ./check-this

그 엔지니어에게 $300 000을 지불하고 있나요? 보안 감사를 위해 $50 정도 예산을 잡아보세요. 제가 해드리겠습니다. 가능하고, 피자도 있습니다.

다운로드하는 모든 애플리케이션은 미스터리 박스와 같습니다. 그 미스터리는 보통 “내 데이터가 얼마나 형편없이 다뤄지고 있지?” 입니다. 답은 보통 “형편없다.”

면책 조항

  • 저는 어떤 것을 악용하지 않았습니다.
  • 저는 접근해서는 안 되는 시스템에 접근하지 않았습니다.
  • 저는 공식 웹사이트에서 다운로드한 애플리케이션에서 사용자로서 제공된 것만 살펴보았습니다.

제가 찾은 모든 내용은 15분과 검색 엔진만 있으면 누구든지 추출할 수 있는 패키지 안에 있었습니다. 제가 사용한 유일한 정교한 도구는 npm과 약간의 불신감이었습니다.

이 글은 어떤 이름도 밝히지 않습니다. 데스크톱 애플리케이션에 자격 증명을 포함해 배포한 행위 자체가 이미 충분히 손가락을 가리키고 있기 때문입니다.

저는 여전히 그 애플리케이션을 사용합니다. 실제로 꽤 좋은 편이죠. 다만 데이터 센터 어딘가에 제가 알면 안 되는 엔드포인트를 실행하는 서버가 존재하고, 제가 기술적으로 호출할 수 있는 API를 통해 요청을 처리하며, 그 자격 증명이 제 Downloads 폴더에 놓여 있다는 사실을 조용히 알고 사용할 뿐입니다.

이 모든 시작점이 된 다운로드 버튼은 그들의 웹사이트에 순수하게 자리 잡고 있어, 사용자를 기쁘게 앱 설치를 유도합니다. 그 아래에는 아마도 다음과 같은 면책 조항이 있어야 할 것입니다:

“이 소프트웨어를 다운로드함으로써, 여러분은 애플리케이션 보안에 대한 무료 교육을 받는 데 동의하는 것입니다.”

Electron 앱을 배포한다면, 다음을 확인하세요

  • 프로덕션 번들에 .env 파일이 포함되지 않음
  • 하드코딩된 비밀(API 키, 비밀번호, 토큰)이 존재하지 않음
  • 소스 맵이 제거되었거나 비공개임
  • 디버그 심볼이 제거됨
  • 모든 서드파티 의존성이 최신이며 검증됨

빌드 체크리스트

  • 하드코딩된 API 키 없음
  • 내부 URL 노출 없음
  • 프로덕션에 디버그 심볼 없음
  • 소스 맵 포함되지 않음
  • .asar 파일을 실제로 검사했음

읽는 동안 자신의 앱에서 자격 증명을 발견했다면, 환영합니다.

만약 당신이 이걸 배포한 $300k 엔지니어라면… 얘기해 봐야겠어요.

저자는 길거리에서 지갑을 찾은 사람이 “탐정”인 것과 같은 방식으로 보안 연구원입니다.

DM은 열려 있습니다. 피자 추천도 환영합니다.

Back to Blog

관련 글

더 보기 »

보안은 안전하게 실패하는 것

시스템은 실패합니다. 사람은 실수를 합니다. 보안은 그렇지 않다고 가장하는 것이 아닙니다. 실패가 생존 가능하도록 하는 것이 보안입니다. 좋은 보안 설계:

복잡함은 쉽다. 단순함은 노력한다.

코드를 추가하면 생산적인 느낌이 듭니다. 코드를 제거하면 위험하게 느껴집니다. 하지만 복잡성은 자연스럽게 증가합니다. 단순함은 방어되어야 합니다. 훌륭한 엔지니어는 entropy와 싸웁니다: - deleti...

소프트웨어 품질에 대한 관점

소프트웨어 품질에 대한 다양한 관점 소프트웨어—또는 어떤 제품—의 품질은 다양한 이해관계자들이 서로 다른 관점을 제공하기 때문에 여러 관점에서 볼 수 있다.