--- title: "취약한 앱 하나 만들고 1,500달러 태워서 LLM들이 해킹할 수 있는지 돌려본 후기" published: 2026-06-04T00:56:32.000Z canonical: https://jeff.news/article/3714 --- # 취약한 앱 하나 만들고 1,500달러 태워서 LLM들이 해킹할 수 있는지 돌려본 후기 보안 연구자가 일부러 취약한 리액트 네이티브 앱과 파이썬 백엔드를 만들고, 여러 대규모 언어 모델(LLM)이 실제 취약점을 찾아낼 수 있는지 실험했어. 핵심 취약점은 API 자체가 아니라 앱에 들어 있는 파이어베이스 설정을 이용해 직접 가입하고 파이어스토어 데이터를 읽는 접근제어 실패였어. 결과는 GPT 5.5가 10회 중 7회 성공으로 가장 좋았고, 다른 모델들은 보안 거부, 엉뚱한 API 분석, 비용 폭발에 많이 막혔어. - 보안 연구자가 일부러 취약한 앱을 만들고, 여러 대규모 언어 모델(LLM)이 실제로 해킹할 수 있는지 돈을 태워가며 실험했음 - 앱은 리액트 네이티브 엑스포(React Native Expo) 기반의 가짜 책 리뷰 앱임 - 백엔드는 파이썬 패스트API(FastAPI)로 만들었고, 목표는 어떤 사용자의 비공개 리뷰 안에 있는 플래그를 찾는 것임 - 총비용은 1,500달러까지 올라갔고, 작성자도 ‘과학적 평가는 아니고 재미로 한 것’이라고 선을 그음 - 취약점 구조가 꽤 현실적임. API는 안전한데 데이터 계층이 열려 있는 케이스임 - 앱 안의 google-services.json에 파이어베이스(Firebase) 정보가 들어 있음 - 공격자는 이 정보를 이용해 파이어베이스에 직접 사용자 가입을 하고, 파이어스토어(Firestore) 데이터베이스를 읽으면 됨 - 작성자는 이 패턴을 실제 파이어베이스·슈퍼베이스(Supabase) 앱에서도 여러 번 봤다고 함 - 분류하자면 접근제어 실패(Broken Access Control) 또는 객체 수준 권한 검사 누락(Missing Object-Level Authorization)에 가까움 > [!WARNING] > API만 단단하게 만들고 Firebase나 Supabase 보안 규칙을 열어두면, 공격자는 API를 예쁘게 우회해서 데이터 계층으로 바로 들어감. 모바일 앱에 들어 있는 설정값은 비밀이 아니라고 봐야 함. ## 어떤 모델이 풀었나 - 10회씩 제대로 돌린 모델 중에서는 GPT 5.5가 가장 잘했음 - 10회 중 7회 성공함 - 평균 실행 비용은 6.62달러, 성공 1회당 비용은 9.46달러였음 - 실행당 중앙값 토큰은 26만 토큰임 - 대부분 APK를 풀어본 뒤 바로 파이어베이스 쪽에 집중했고, API나 앱 내부에서 엉뚱한 취약점을 찾느라 오래 헤매지 않았다고 함 - 딥시크 V4 프로는 성공률은 낮지만 비용이 압도적으로 쌌음 - 10회 중 3회 성공함 - 평균 실행 비용은 0.19달러, 성공 1회당 비용은 0.62달러였음 - 5회는 파이어베이스를 아예 건드리지 않고 API나 앱만 분석했음 - 나머지 5회는 파이어베이스 가능성을 봤지만, 그중 2회는 파이어베이스 인증을 API에 붙여 쓰려는 식으로 방향을 틀었다고 함 - 클로드 계열은 아깝게 실패한 케이스가 많았음 - 클로드 소넷 4.6은 10회 중 2회 성공했고, 평균 실행 비용은 9.15달러였음 - 5회는 맞는 방향으로 가다가 최대 예산에 걸려 멈췄음 - 클로드 오퍼스 4.8도 10회 중 2회 성공했지만, 여러 번 정답에 가까이 가다가 보안 가드레일 때문에 늦게 세션이 끊겼다고 함 - 즉 초반 거부가 아니라, 꽤 진행한 뒤 보안 정책에 걸리는 패턴이 문제였음 - 아예 못 푼 모델들도 패턴이 갈림 - 딥시크 V4 플래시는 파이어베이스 기능은 알아봤지만 결국 ‘API는 안전하고 익스플로잇을 못 찾았다’는 보고서로 끝났음 - 제미나이 3.1 프로 프리뷰는 보안 이유로 즉시 거부하는 경우가 많았고, 중앙값 토큰도 9천 토큰으로 매우 낮았음 - 제미나이 3.5 플래시는 초반 거부가 많았고, 일부는 시도하다가 나중에 거부함 - 미니맥스 M2.7은 열심히 했지만 계속 API와 앱에만 집착했고, 파이어베이스를 직접 때리는 접근으로 넘어가지 못했음 - 스텝 3.7 플래시는 API 매핑은 잘했지만, 실제 취약점이 아닌 것을 취약점으로 착각하는 false positive가 있었다고 함 ## 추가로 돌린 모델들은 더 혼란스러웠음 - GLM 5.1은 4회 중 1회 성공했지만 작성자가 비용에 질렸음 - 평균 실행 비용은 8.68달러, 성공 1회당 비용은 34.73달러였음 - 중앙값 토큰이 125만 토큰까지 갔음 - 작성자는 API 장애와 토큰 사용량 때문에 다시 쓰고 싶지 않다는 식으로 꽤 노골적으로 말함 - 큐원 3.7 맥스는 기대 대비 크게 실망한 케이스임 - 6회 중 0회 성공함 - 로컬 테스트에서는 GPT가 아닌 모델 중 유일하게 풀었던 적이 있었지만, 긴 실행에서는 재현하지 못했다고 함 - 대부분 API의 IDOR 가능성에 꽂혀서 정답 경로로 못 갔음 - 실행당 중앙값 토큰이 732만 토큰임. 이건 진짜 돈 녹는 소리임 - 키미 K2.6은 단 1회만 돌렸지만 성공함 - 1회 중 1회 성공했고, 평균 비용과 성공당 비용 모두 1.02달러였음 - 속도와 토큰 사용량은 딥시크 V4 프로와 비슷했다고 함 - 더 돌리지 않은 이유는 키미 API가 동시 에이전트 사용에 약하고, 캐시 토큰까지 포함한 분당 토큰 제한이 낮았기 때문임 - 무료라서 돌린 아울 알파는 10회 모두 실패함 - 테스트 케이스 안에서 오래 헤맸고, 많은 실행이 파이어베이스를 보는 단계까지도 못 갔음 - 한 실행에서는 API에 200개 넘는 요청을 날렸다고 함 ## 이 실험에서 진짜 갈린 능력 - 핵심은 ‘취약점이 어느 레이어에 있는지 재프레이밍하는 능력’이었음 - 실패한 모델 상당수는 API가 안전하다는 결론을 내리고 멈췄음 - 하지만 정답은 API를 더 때리는 게 아니라, 모바일 앱 설정에서 파이어베이스 프로젝트 정보를 찾고 데이터베이스에 직접 접근하는 것임 - 보안 테스트에서 이 전환을 못 하면 보고서는 그럴듯해도 실제 취약점은 놓침 - 모델의 보안 가드레일도 결과에 영향을 줬음 - 작성자는 오픈AI 계정이 보안 연구 승인을 받은 상태라 GPT가 거부하지 않았다고 함 - 반면 제미나이나 클로드 오퍼스 일부 실행은 보안 정책 때문에 중간에 막혔음 - 흥미롭게도 작성자는 중국 모델들이 데이터베이스 공격 시도에 더 편했다고 느꼈고, 다른 모델들은 ‘라이브 데이터베이스에 영향 줄 수 있다’는 식으로 멈칫하는 순간이 있었다고 함 - 실험 인프라 만드는 일이 오히려 제일 힘들었다고 함 - 대부분 모델은 같은 목표를 계속 시도하게 하려고 별도 harness를 썼음 - 클로드는 클로드 코드의 -p 모드를 사용했음 - 각 실행은 최대 10달러, 최대 2시간으로 제한했음 - 트랜스크립트가 너무 커서 로컬 디스크를 먹어치웠고, 그래서 모달(Modal)을 썼는데 러너 약 10%가 선점 종료되어 실행을 날렸다고 함 - 작성자는 그냥 AWS를 쓸 걸 그랬다고 후회함 > [!TIP] > 모바일 앱 보안 점검할 때는 API 엔드포인트만 보지 말고, 앱 번들 안의 Firebase·Supabase 설정과 실제 데이터베이스 보안 규칙까지 같이 봐야 함. LLM에게 맡겨도 이 레이어 전환을 명시적으로 요구하지 않으면 엉뚱한 곳만 파는 경우가 많음. ## 개발자에게 남는 포인트 - LLM 보안 에이전트는 꽤 쓸모 있지만, 아직 ‘혼자 맡기면 끝’은 아님 - GPT 5.5도 10회 중 3회는 실패했음 - 성공한 모델도 비용, 시간, 정책 거부, false positive 문제가 계속 있음 - 특히 취약점 유형이 API 밖에 있을 때는 모델이 사고 범위를 넓히는지가 중요함 - 비용 대비 성능은 성공률만 보면 안 됨 - GPT 5.5는 가장 많이 풀었지만 실행당 비용이 높음 - 딥시크 V4 프로는 성공률은 30%지만 성공당 비용이 0.62달러로 싸게 나옴 - 큐원 3.7 맥스처럼 토큰을 엄청 쓰고도 못 푸는 케이스는 운영 관점에서 치명적임 - 이 글의 제일 현실적인 교훈은 파이어베이스·슈퍼베이스 앱에서 보안 규칙을 다시 보라는 것임 - 클라이언트에 들어 있는 설정값은 공격자가 볼 수 있음 - API가 아무리 튼튼해도 데이터베이스 직접 접근 경로가 열려 있으면 끝임 - 앱 출시 전에 실제 클라이언트 번들을 풀어서, 공격자가 어떤 경로로 데이터 계층에 접근할 수 있는지 확인해야 함 --- ## 기술 맥락 - 이 실험의 핵심 선택은 취약점을 API 안에 심지 않고, 모바일 앱이 쓰는 Firebase 데이터 계층에 심었다는 점이에요. 왜냐하면 실제 서비스에서도 백엔드 API는 열심히 막아놓고, 정작 Firestore 보안 규칙은 느슨하게 둬서 데이터가 새는 경우가 꽤 있거든요. - LLM 입장에서 어려운 이유는 단순히 코드를 읽는 문제가 아니에요. APK를 풀고, 클라이언트 설정을 보고, API가 아니라 Firebase를 직접 호출해야 한다는 공격 경로 전환이 필요해요. 이 전환을 못 하면 아무리 API를 잘 매핑해도 정답 근처에 못 가요. - IDOR에 집착한 모델들이 실패한 것도 그래서 중요해요. IDOR는 웹 보안에서 흔한 패턴이라 모델이 먼저 떠올리기 쉽지만, 이 문제에서는 식별자만 바꿔 API를 두드리는 게 아니라 데이터베이스 권한 모델 자체를 봐야 했어요. - 보안 에이전트 평가에서 비용이 중요한 이유는, 성공률이 같아도 운영 가능한 모델이 다르기 때문이에요. 한 번 풀 때 0.62달러가 드는 모델과 수십 달러가 드는 모델은 실제 취약점 스캔 파이프라인에 넣었을 때 완전히 다른 선택지가 돼요. - 실무에서는 LLM에게 ‘취약점 찾아줘’라고만 던지는 것보다, 클라이언트 번들 분석, 외부 서비스 설정 추출, 데이터베이스 보안 규칙 검증처럼 범위를 나눠 지시하는 게 더 나아요. 왜냐하면 모델이 첫 가설에 꽂혀 API만 파다가 끝나는 실패 모드가 꽤 자주 나오기 때문이에요. ## 핵심 포인트 - 실험 대상 취약점은 강화된 API 뒤에 열려 있는 파이어베이스 데이터 계층으로, 실제 모바일 앱에서도 흔히 나오는 접근제어 실패 유형임 - GPT 5.5는 10회 중 7회 성공했고 평균 실행 비용은 6.62달러, 성공 1회당 비용은 9.46달러였음 - 딥시크 V4 프로는 10회 중 3회 성공했지만 평균 실행 비용이 0.19달러로 매우 낮았음 - 클로드 소넷 4.6과 클로드 오퍼스 4.8은 각각 10회 중 2회 성공했고, 여러 실행이 예산 제한이나 보안 가드레일에 걸림 - 큐원 3.7 맥스는 6회 모두 실패했는데 실행당 중앙값 토큰이 732만으로, 비용 대비 결과가 특히 나빴음 ## 인사이트 이 실험의 재미는 ‘어떤 모델이 제일 똑똑하냐’보다, 보안 작업에서 모델이 취약점의 레이어를 제대로 바꾸어 볼 수 있느냐에 있음. API만 두들기다 끝나는 모델과, 모바일 앱 설정에서 백엔드 데이터 계층으로 이동하는 모델의 차이가 그대로 성능 차이로 나왔어.