I built a vulnerable app and spent $1,500 seeing if LLMs could hack it

Who Should Read

LLM을 보안 연구나 펜테스트(침투 테스트) 자동화에 활용하고 싶은 보안 엔지니어 또는 백엔드/모바일 개발자. Firebase나 Supabase 기반 앱을 운영 중인 개발자도 자신의 앱 취약점 패턴을 이해하는 데 유용하다.

Core Mechanics

• 실험 설계는 React Native(Expo) + FastAPI + Firebase로 구성된 북리뷰 앱이다. API 자체는 보안이 잘 되어 있지만, APK 안에 포함된 google-services.json을 통해 Firebase에 직접 접근하면 다른 사용자의 비공개 리뷰(flag)를 읽을 수 있는 구조다.
• 이 취약점은 실제 현장에서도 흔히 발견되는 패턴으로, 'Broken Access Control' 또는 'Missing Object-Level Authorization'이라고 부른다. API는 잘 막아뒀지만 Firebase/Supabase 규칙은 열려 있는 경우가 많다.
• GPT-5.5가 7/10(70%) 성공률로 가장 높았다. 거의 모든 실행에서 APK를 압축 해제한 뒤 곧바로 Firebase에 집중했고, API 쪽에서 헤매는 시간이 거의 없었다. 비용은 실행당 평균 $6.62, 성공당 $9.46이었다.
• Deepseek V4 Pro는 3/10(30%) 성공률로 두 번째였다. 단 실행당 평균 비용이 $0.19로 GPT-5.5 대비 35배 저렴해서, 성공당 비용은 $0.62로 오히려 가장 경제적이었다.
• Claude Sonnet 4.6과 Opus 4.8은 각각 2/10 성공률이었는데, 이는 실력 부족이 아니라 보안 가드레일 때문이다. Opus는 정답에 근접했다가 세션 도중 거부로 중단된 경우가 많았고, Claude는 실행 중간에 갑자기 작업을 중단하는 'late refusal' 패턴을 보였다.
• Gemini 3.1 Pro Preview는 10회 모두 즉각 거부(0/10)했는데, 중간 토큰 수가 9k로 다른 모델의 100k+ 대비 극단적으로 낮아 사실상 시도조차 안 한 것으로 해석된다.
• Deepseek V4 Flash는 Firebase를 인식하기는 했지만 모든 실행에서 'API가 안전한 것 같다'는 보고서를 내고 종료했다(0/10). 방향은 맞지만 실행까지 이어지지 못한 케이스다.
• 부분 실행된 모델 중 Kimi K2.6이 1/1(100%)로 완료했고 실행당 비용이 $1.02에 불과해 가성비 측면에서 주목할 만하다. GLM 5.1도 1/4(25%) 성공했고 성공당 비용은 $34.73이었다.
• 모든 실행은 실행당 $10 예산 상한과 2시간 제한을 두었다. Claude를 제외한 모델은 pi + pi-goal-x 확장을 사용해 중간에 멈추지 않도록 강제했고, Claude는 Claude Code의 -p 모드를 사용했다.

Evidence

• Claude의 낮은 점수가 가드레일 때문이라는 점에 대해 커뮤니티는 공감했다. 한 댓글에서는 'Anthropic이 릴리스마다 보안 제한을 강화하고 있어 로그인 수행, 자격증명 처리 같은 정상적인 작업도 거부하기 시작했다'며, 결국 모델 능력과 제한 사이에서 선택해야 하는 시점이 올 것이라는 우려를 표했다.
• GPT-5.5가 보안 연구용으로 사전 승인된 계정을 사용했다는 점을 두고 불공정하다는 지적이 있었다. '가드레일이 걸린 일반 계정으로 테스트하면 비교가 더 공정할 것'이라는 의견이 나왔고, 이는 실험 결과를 해석할 때 중요한 맹점이다.
• 모델 혼자 완전히 자율 실행하는 방식이 너무 단순하다는 비판도 있었다. GLM 5.1로 고급 크랙미(crackme) 문제를 풀어본 사람이 '방향을 살짝 알려주는 식으로 함께 작업하면 훨씬 효과적'이라는 경험을 공유했다. 완전 자율 실행은 CI 통합에는 유용하지만, 실제 보안 리뷰에는 사람의 판단이 여전히 필요하다는 결론이었다.
• 모델이 거부하는 문제를 우회하는 실용적인 팁이 공유됐다. 한 댓글에서 '모델은 로컬 환경이라고 생각하면 보안 작업을 잘 수행하는 경향이 있다'며, 실제로 라이브 타깃을 localhost로 프록시하거나 JS VM을 오프라인 아티팩트로 추출해 별도 세션에서 분석하는 방식으로 GPT-5.5 xhigh의 거부를 우회했다는 경험을 공유했다.
• 현재 LLM을 보안 자동화에 쓰는 것이 비용 효율적이지 않다는 현실적인 의견도 있었다. 'False positive(실제로 없는 취약점을 있다고 잘못 탐지)가 너무 많고, 이를 다시 검증하는 데 추가 비용이 든다'는 지적이었다. 다만 '이미 알려진 일반적인 취약점(CVE 등)을 찾는 데는 AI가 효과적이고, 버그 바운티에 활용할 만하다'는 실용적 조언도 덧붙였다.

How to Apply

• Firebase나 Supabase를 데이터 레이어로 쓰는 앱을 배포하기 전에, APK 또는 앱 번들 안에 포함된 google-services.json이나 설정 파일로 Firebase에 직접 접근할 수 있는지 확인해야 한다. API 보안만 신경 쓰고 Firebase Security Rules를 열어둔 채 배포하면 이 실험과 동일한 방식으로 데이터가 노출될 수 있다.
• LLM 기반 펜테스트 자동화를 구축할 계획이라면, 완전 자율 실행보다 '방향을 살짝 제시하는 반자동 방식'이 더 효과적이다. 특히 Deepseek V4 Pro는 성공당 비용이 $0.62로 가장 저렴하므로, 예산이 제한적인 초기 스캔 단계에 활용하고 이상 징후 발견 시 더 강력한 모델로 심화 분석하는 계층형 접근을 고려할 수 있다.
• Claude를 보안 관련 자동화 작업에 사용할 때 거부가 발생한다면, '본인이 앱 개발자임을 명시'하거나 대상 환경을 localhost로 프록시하는 방식으로 우회를 시도해볼 수 있다. 단, 이런 우회 방법은 Anthropic의 정책 강화에 따라 앞으로 막힐 가능성이 있어 장기적으로는 다른 모델을 대안으로 검토하는 것이 좋다.
• 모델이 취약점을 발견했다고 보고해도 곧바로 신뢰하지 말고 반드시 검증 단계를 넣어야 한다. Step 3.7 Flash처럼 실제로 익스플로잇하지 않고 발견했다고 잘못 보고하는 false positive 문제가 있으므로, 자동화 파이프라인에서는 '성공 기준(what a successful exploit looks like)'을 명확히 정의하고 검증하는 로직을 포함해야 한다.

Terminology

Related Papers

• Clustered Self-Assessment: A Simple yet Effective Method for Uncertainty Quantification in Large Language Models

  LLM이 여러 답변을 의미 단위로 묶어 객관식으로 만들고 스스로 채점해서 '이 답 얼마나 확신해?'를 수치로 뽑아내는 기법.

• SkillHarm: Lifecycle-Aware Skill-Based Attacks via Automated Construction

  AI 에이전트가 사용하는 'Skill 패키지'에 악성 페이로드를 심으면 최신 모델도 86%까지 뚫린다는 보안 벤치마크.

• MemTrace: Tracing and Attributing Errors in Large Language Model Memory Systems

  RAG, Mem0 같은 LLM 메모리 시스템이 왜 틀린 답을 내는지 자동으로 찾아주는 디버깅 프레임워크

• DeepSWE: A contamination-free benchmark for long-horizon coding agents

  기존 SWE-bench의 데이터 오염 및 검증 오류 문제를 해결하기 위해 처음부터 새로 만든 코딩 에이전트 벤치마크로, GPT-5.5가 70%로 1위를 차지하고 모델 간 성능 격차가 훨씬 뚜렷하게 드러난다.

• Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

  LLM 코딩 에이전트는 구조적 제약(아키텍처 패턴, ORM, DB 설계)이 쌓일수록 성능이 급격히 떨어지는 'constraint decay' 현상을 보인다는 연구 결과로, AI 코딩 도구를 프로덕션에 쓰려는 개발자라면 반드시 알아야 할 한계다.

• AMEL: Accumulated Message Effects on LLM Judgments

  LLM을 자동 평가자로 쓸 때 이전 대화 기록의 긍정/부정 분위기가 이후 판단을 오염시킨다는 걸 75,898개 API 호출로 증명한 연구.

Related Resources

• 원문: I built a vulnerable app and spent $1,500 seeing if LLMs could hack it
• 취약한 앱 APK 및 챌린지 설명 ZIP (직접 풀어볼 수 있음)
• GLM 5.1로 crackme 챌린지 해결 사례 (댓글 링크)