AI 법률 플랫폼 Filevine 보안 취약점 사건 정리
핵심 요약
한 연구자가 AI 법률 플랫폼 Filevine의 서브도메인에서 인증 없이 접근 가능한 API를 발견했고, 이를 통해 특정 로펌의 Box 전체 파일 시스템에 대한 관리자 토큰이 노출되는 중대한 취약점을 찾아 책임 있게 제보했다. 이 사건은 AI·클라우드 기반 법률 서비스가 다루는 초민감 정보를 얼마나 엄격하게 보호해야 하는지, 그리고 보안 취약점 발견 후 어떻게 대응해야 하는지를 잘 보여준다.
AI 법률 플랫폼과 데이터 보안의 긴장 관계
AI를 활용한 법률 플랫폼은 문서 요약, 검색, 추천 등 다양한 기능을 제공하기 위해 방대한 사건 기록, 의료 정보, 계약서, 내부 메모 등을 수집·저장한다.
이 데이터는 종종 의료 정보(예: HIPAA 대상), 비공개 합의서, 재판 전략, 급여 및 인사 정보 등 가장 민감한 범주에 속하기 때문에, 보안이 무너지면 단순한 개인정보 유출을 넘어 재판 결과와 신뢰도, 심지어 변호사 윤리 문제까지 직격탄을 맞을 수 있다.
Filevine처럼 높은 기업 가치를 가진 AI 법률 플랫폼일수록 많은 로펌이 의존하고 있으므로, 한 번의 보안 사고가 여러 기관과 수많은 의뢰인에게 연쇄 피해를 줄 수 있다는 점에서 "성장 속도"보다 "보안 성숙도"가 더 중요해진다.
서브도메인에서 시작된 탐색: margolis.filevine.com
연구자는 플랫폼을 직접 체험해 보려 했지만, 일반 사용자에게는 바로 기능을 열어주지 않는 구조를 보고, 별도의 데모 환경이 있을 것이라 추측했다.
이를 확인하기 위해 서브도메인 열거(subdomain enumeration) 기법을 사용했는데, 이는 이미 알려진 도구와 방식으로 xxx.example.com 형태의 숨겨진 하위 도메인을 찾아보는 전형적인 보안 조사 방법이다.
그 과정에서 특정 로펌 이름으로 보이는 margolis.filevine.com에 접속했고, 겉으로는 로딩 화면만 보이고 실제로는 아무 데이터 요청이 일어나지 않는 이상한 상태를 발견했다. 이 "겉으로는 멈춘 듯한 페이지"가, 내부 동작을 파고들어 볼 필요가 있다는 신호가 된 셈이다.
브라우저 개발자 도구와 자바스크립트 분석
페이지가 멈춘 것처럼 보이는데도 네트워크 요청이 보이지 않자, 연구자는 화면 뒤에서 어떤 스크립트가 어떤 API를 호출하려 하는지 자바스크립트 파일을 직접 살펴보기 시작했다.
여기서 fetch(${BOX_SERVICE}/recommend) 형태의 코드 조각을 발견했고, 이 BOX_SERVICE라는 변수가 어디에서 정의되는지 역추적했다. 압축·난독화된(minified) 자바스크립트를 뒤지는 것은 매우 번거롭지만, 실제 서비스가 어떤 외부 API와 통신하는지 알아내는 데에는 여전히 유효한 방법이다.
결국 dxxxxxx9.execute-api.us-west-2.amazonaws.com/prod라는 AWS API 게이트웨이 엔드포인트를 찾아냈고, 이 주소가 Filevine의 추천 기능이나 파일 시스템과 연동되는 핵심 백엔드 역할을 할 것으로 추정할 수 있었다.
인증 없는 API 요청과 Box 관리자 토큰 노출
연구자는 추가로 자바스크립트를 분석해 /prod/recommend 엔드포인트에 필요한 요청 형식을 알아냈고, 다음과 같이 매우 단순한 JSON을 보내면 된다는 것을 확인했다.
{"projectName":"Very sensitive Project"}놀라운 점은, 이 요청에 어떠한 인증 토큰이나 세션 정보도 필요 없었다는 것이다. 즉, 인터넷 어디에서든 이 URL과 형식을 아는 누구나 요청을 보낼 수 있었다.
응답에는 추천 폴더 목록과 함께 boxToken이라는 필드가 들어 있었는데, Box API 문서를 확인한 결과 이 토큰이 특정 폴더가 아니라 로펌이 사용하는 Box 전체 파일 시스템에 대한, 가장 강력한 수준의 관리자 권한을 가진 토큰이라는 사실이 드러났다.
이는 "회사 공유 구글 드라이브" 전체의 마스터 열쇠를, 문 앞에 자물쇠 없이 매달아 둔 것과 다를 바 없는 상황이었다.
취약점의 실제 영향: 로펌 전 파일 시스템 접근 가능성
연구자는 이 토큰의 위력을 검증하기 위해 Box 내에서 "confidential"이라는 단어로 검색해 보았고, 거의 10만 건에 가까운 결과가 나오는 것을 확인했다. 이 단계에서 이미 실질적인 피해 가능성이 입증되었기 때문에, 더 이상 파일을 열어보거나 다운로드하는 추가 테스트는 하지 않고 즉시 중단했다.
이 토큰을 악용하면 해당 로펌이 Box에 저장해 둔 모든 문서에 접근할 수 있었을 것으로 보인다. 여기에는 의료 정보처럼 법적 보호를 받는 자료, 내부 인사 문서, 재무 자료, 의뢰인 신상, 재판 전략 문건, 비공개 합의 서류, 법원 명령으로 보호되는 문건까지 포함될 수 있다.
만약 악의적인 공격자가 이 취약점을 먼저 알게 되었다면, 단일 로펌의 문제를 넘어 의뢰인, 제3자, 병원, 보험사 등 수많은 이해관계자에 대한 광범위한 2차 피해로 이어질 수 있었고, 로펌과 플랫폼 양측에 치명적인 신뢰 상실과 법적 책임을 야기했을 것이다.
책임 있는 공개 절차와 Filevine의 대응
취약점을 확인한 연구자는 추가 공격 가능성을 탐색하기보다 곧바로 Filevine 보안팀에 사실을 알리는 책임 있는 공개(responsible disclosure) 절차를 선택했다.
10월 말 발견 직후 제보가 이루어졌고, 11월 초에는 회사 측이 문제를 인지하고 신속히 검토 및 수정에 착수하겠다고 답변했다. 11월 후반에는 연구자가 패치가 실제로 적용되었는지 재확인하는 과정을 거쳤고, Filevine은 취약점이 해결되었음을 공식적으로 회신했다.
이후 연구자는 12월에 기술적 분석과 교훈을 담은 글을 공개했는데, 이는 "문제가 해결된 뒤에야 세부 내용을 공개한다"는 보안 커뮤니티의 기본 원칙을 잘 지킨 사례다. Filevine 역시 취약점의 심각성을 인정하고, 제보자와 협조하며, 소통을 지속한 점에서 모범적인 대응을 보였다.
AI·클라우드 서비스 보안을 위한 교훈
이 사건은 특히 "AI 기능을 빨리 붙여야 시장에서 살아남는다"는 압박이 클수록, 보안 검증과 설계가 얼마나 쉽게 뒷전으로 밀릴 수 있는지 보여준다.
첫째, 외부에서 접근 가능한 API는 기본적으로 "인증 필요"가 원칙이어야 하며, 관리자 수준의 토큰이나 키를 직접 반환하도록 설계하는 것은 피해야 한다. 필요한 경우에는 권한이 매우 제한된 단기 토큰을 발급하고, IP·도메인·시간 등 다단계 제약을 거는 것이 안전하다.
둘째, 테스트·데모·파일럿 환경이라 하더라도 실제 고객 데이터나 본 서비스의 관리자 권한과 섞이지 않도록 철저히 분리해야 한다. 많은 사고가 "테스트용이라 대충" 관리된 환경에서 시작한다.
셋째, 법률·의료·금융처럼 규제가 강한 분야일수록, 외주 개발이나 스타트업 협업 시에도 보안 설계·코드 리뷰·침투 테스트를 필수 과정으로 요구해야 한다. 클라우드와 AI 도입 자체가 문제가 아니라, 그 위에 구축되는 보안 통제의 수준이 핵심이다.
인사이트
AI와 클라우드 기반 법률 서비스는 업무 효율을 크게 높일 수 있지만, 이번 사례처럼 보안이 허술하면 그 이득을 한 번에 날려버릴 만큼 큰 리스크를 안고 있다.
법률 관련 조직이라면, 새 플랫폼을 도입할 때 보안 인증, 데이터 저장 위치, 접근 권한 관리, 취약점 공개 정책 등을 체크리스트로 만들어 점검해야 한다. 단순히 "유명하고 큰 회사니까 믿어도 된다"가 아니라, "민감 정보를 맡길 만한 보안 체계가 있는가"를 구체적 질문으로 따져봐야 한다.
개발자와 제품 팀 입장에서는, 기능 출시 속도를 잠시 늦추더라도 인증·권한·토큰 관리·테스트 환경 분리 같은 기본 보안 원칙을 코드와 아키텍처에 녹여 넣는 것이, 장기적으로 회사의 평판과 법적 리스크를 줄이는 가장 값싼 보험이라는 점을 기억할 필요가 있다.
출처 및 참고:
https://alexschapiro.com/security/vulnerability/2025/12/02/filevine-api-100k
