‘모두의창업’ 정보 유출, 전문가들이 짚은 API 보안

정부 창업 지원 플랫폼 ‘모두의창업’에서 발생한 정보 유출 사고는 데이터베이스 침입이 아닌 ‘백엔드 애플리케이션 프로그래밍 인터페이스(API)’에 비정상적으로 접근하는 과정에서 발생한 것으로 파악됐다.

중소벤처기업부(이하 중기부)는 지난 22일 브리핑에서 이번 사고와 관련해 “권한 없는 이용자가 인공지능(AI) 도구를 활용해 권한이 있는 것처럼 시스템에 접근한 것으로 보고 있다”고 밝혔다. 이메일 주소와 창업 아이디어 요약본, 심사평이 외부로 나갔으며, 국가정보원 조사에서는 9개 인터넷주소(IP)의 비정상적인 API 호출이 확인됐다.

노용석 중기부 제1차관은 권한 없는 사람이 AI 도구를 이용해 권한이 있는 것처럼 백엔드 API에 비정상적으로 접근하고 데이터를 가져간 것으로 보고 있다고 설명했다. 다만 공격자가 어떤 API를 호출했는지, 인증정보나 요청값을 어떤 방식으로 조작했는지, AI 도구를 어느 과정에 활용했는지는 아직 공개되지 않았다. 9개 IP의 사용 주체와 실제 API 호출 횟수, 정보 접근 규모도 조사 중이다.

이번 사고와 관련해 API 보안을 다루는 보안 기업들은 공개된 정황만으로 공격 방식을 확정하기는 어렵다고 분석했다. 다만 화면에서 숨긴 정보가 API 응답에도 포함됐는지, 서버가 요청자의 접근 권한을 확인했는지, 반복적인 정보 조회를 탐지했는지를 중심으로 사고 구조를 살펴볼 수 있다고 설명했다.

화면에 안 보여도 API 응답에는 남을 수 있어

웹서비스는 이용자가 보는 프론트엔드와 데이터를 처리하는 백엔드로 나뉜다. 이용자가 웹페이지를 열면 프론트엔드는 백엔드 API에 데이터를 요청한다. 서버는 요청을 처리한 뒤 화면 구성에 필요한 정보를 프론트엔드에 돌려주는 구조다.

화면에서 이메일 주소나 심사평을 표시하지 않더라도 서버가 API 응답에 해당 정보를 포함하면 별도 도구로 확인이 가능하다. 브라우저 개발자 도구를 사용하면 웹페이지와 서버 사이에서 오간 요청과 응답도 살펴볼 수 있다.

API 보안 전문기업 관계자는 “프론트엔드 화면에서 정보를 숨기는 것과 백엔드 API가 해당 정보를 반환하지 않도록 통제하는 것은 별개의 문제”라며 “화면에 보이지 않아도 API 응답값에 비공개 정보가 들어 있다면 개발자 도구나 자동화 프로그램으로 확인될 수 있다”고 분석했다.

그는 “데이터베이스 조회 결과에서 화면에 필요한 항목만 골라내지 않고, API 응답으로 보내면 이용자에게 필요하지 않은 정보까지 전달될 수 있다”고 덧붙였다.

관리자용 API와 일반 이용자용 API가 같은 응답 구조를 사용하는 경우에도 문제가 생길 수 있다. 목록 조회용 API가 상세 정보나 내부 평가 정보까지 함께 반환하는지도 점검해야 한다.

‘모두의창업’ 플랫폼에서 어떤 API가 어떤 응답을 보냈는지는 현재 조사가 진행 중이다. 중기부는 이용자가 보는 프론트엔드에는 비공개 정보가 나타나지 않았지만 백엔드에서 해당 정보가 제공됐다고 설명했다.

식별자 바꿔 다른 사람 정보 조회했나

네트워크·보안 전문기업 파이오링크 관계자는 “사용자 번호나 신청 번호처럼 데이터를 구분하는 식별자가 어떻게 처리됐는지 확인할 필요가 있다”고 설명했다.

화면에서는 자신의 정보만 보이더라도 API 요청에는 사용자 번호나 신청 번호가 포함될 수 있다. 이용자가 이 값을 다른 번호로 바꿨을 때 서버가 요청자의 권한을 다시 확인하지 않으면 다른 사람의 정보가 반환될 수 있다.

그는 “화면에서는 자신의 정보만 조회되는 것처럼 보여도 API 요청의 식별자 값을 바꿨을 때 서버가 권한을 확인하지 않고 응답하면 타인의 정보가 노출될 수 있다”며 “서버 애플리케이션이 요청자와 요청 대상 데이터의 권한 관계를 직접 검증해야 한다”고 말했다.

웹 애플리케이션 보안 분야의 국제 비영리 단체 ‘OWASP(Open Worldwide Application Security Project)는 이런 취약점을 ‘객체 단위 권한검사 실패(BOLA)’로 분류한다. 객체는 이용자 계정과 신청서, 주문서, 문서처럼 API가 처리하는 개별 데이터를 뜻한다.

예를 들어 이용자가 자신의 신청번호로 정보를 조회할 수 있더라도 다른 사람의 신청번호를 입력한 요청은 서버가 차단해야 한다. 로그인에 성공했다는 사실과 특정 정보에 접근할 권한이 있다는 것은 서로 다른 영역이다.

API 보안 전문기업 관계자는 “신청 ID나 사용자 ID를 요청값으로 받는 API는 다른 사람의 ID로 바꿔 호출했을 때도 차단되는지 확인해야 한다”며 “로그인 여부만 확인하고 데이터 소유권이나 역할을 검사하지 않으면 정보 노출로 이어질 수 있다”고 설명했다.

다만 모두의창업에서 유출된 정보가 실제로 BOLA 취약점 때문인지는 확인되지 않았다. 중기부는 권한 없는 이용자가 권한이 있는 것처럼 시스템에 접근했다고 밝혔지만, 구체적인 인증·인가 우회 방식은 밝혀지지 않았다.

정상 형식 요청은 보안 장비만으로 구분 어려워

권한 없는 이용자가 정상적인 형식으로 API를 호출하면 웹방화벽이나 웹 애플리케이션·API 보호(WAAP) 기술만으로 모든 접근을 막기는 어렵다는 분석도 나온다.

가령 이용자가 자신의 신청 정보를 조회하는 정상 요청에서 신청번호만 다른 값으로 바꾸더라도 인터넷 통신 방식이나 데이터 구조는 그대로일 수 있다. 보안 장비 입장에서는 공격 코드가 담긴 요청이 아니라 형식상 정상적인 요청으로 보일 수 있다.

파이오링크 관계자는 “웹방화벽과 WAAP는 API 공격과 오남용을 탐지하는 다층 방어 수단”이라며 “특정 데이터에 대한 최종 접근 권한은 애플리케이션이 직접 판단해야 한다”고 말했다.

보안 장비는 운영 중인 API를 식별하고 등록되지 않은 API를 찾는 데 활용할 수 있다. 허용된 API만 접근하도록 제한하거나 요청값과 데이터 구조가 정해진 형식에 맞는지도 검사한다. 특정 이용자나 IP가 짧은 시간에 같은 API를 반복 호출하면 단위 시간당 요청 횟수를 제한하는 ‘호출량 제한’도 적용할 수 있다.

다만 이런 기능은 서버의 권한검사를 대신하지 않는다. 애플리케이션이 접근 권한을 검사하고 보안 장비가 반복 호출과 비정상적인 이용 패턴을 탐지하는 방식으로 역할을 나눠야 한다는 설명이다.

AI, API 분석과 반복 호출 문턱 낮춰…권한 통제 구조 살펴야

중기부는 이번 사고에서 AI 도구를 활용한 비정상 접근을 한 정황이 있다고 설명했다. 과거에는 웹페이지와 서버 사이의 네트워크 요청을 확인하고 API 응답 구조를 분석하려면 일정 수준의 개발 지식이 필요했다. 여러 요청을 반복하는 프로그램도 직접 작성해야 했다.

API 보안 전문기업 관계자는 “AI 도구를 활용하면 브라우저의 네트워크 요청과 프론트엔드 자바스크립트, API 응답 구조를 분석하는 작업이 쉬워질 수 있다”며 “반복 호출을 위한 자동화 프로그램 작성도 이전보다 간단해졌다”고 말했다.

AI가 새로운 API 취약점을 만드는 것이 아니라 이미 존재하는 구조를 파악하고 반복 작업을 자동화하는 문턱을 낮추고 있다는 것이다.

API 요청에 신청 번호나 사용자 번호, 페이지 번호가 포함돼 있다면 AI 기반의 자동화 프로그램으로 값을 순서대로 바꿔가며 요청할 수 있다. 서버가 요청마다 이용자의 권한을 확인하지 않으면 다른 이용자의 정보가 연속해서 반환될 수 있다.

모두의창업 사고에서 AI가 API 구조 분석과 요청값 변경, 자동화 프로그램 작성 가운데 어느 과정에 사용됐는지는 확인되지 않았다.

파이오링크 관계자는 “생성형 AI로 API 분석과 자동화 도구를 쉽게 만들 수 있어 단순한 호출 횟수만으로 정상 이용과 자동화 수집을 구분하기 어려워지고 있다”며 “요청 횟수뿐 아니라 접속 IP와 세션, 토큰, 요청값 변화, API 호출 순서를 함께 분석할 필요가 있다”고 분석했다.

동일한 이용자가 짧은 시간에 여러 사람의 정보에 접근하거나 사용자 번호와 신청 번호를 순차적으로 바꾸는 경우 자동화 수집을 의심할 수 있다. 정상적인 화면 이용 과정에서 발생하지 않는 API 조합을 호출하는 행위도 점검 대상이다.

중기부는 9개 IP에서 비정상적인 API 호출이 발생했다고 밝혔다. 그러나 IP별 호출 횟수와 정보 반환에 성공한 요청 수, 실제 조회된 이용자 수는 밝혀지지 않았다.

보안 전문가들의 설명을 종합하면, AI는 API 구조를 분석하거나 반복 호출을 자동화하는 수단으로 사용될 수 있다. 실제 정보 유출이 가능했던 이유를 규명하려면 서버가 이용자별 접근 권한과 반환 정보를 어떻게 구분했는지 확인해야 한다.

API 주소는 이용자가 웹페이지를 사용하는 과정에서 브라우저에 나타날 수 있다. API 주소를 감추거나 화면에서 일부 정보를 보이지 않게 만드는 것만으로는 접근을 통제하기 어렵다.

API 보안 전문기업 관계자는 “API는 외부에서 호출될 수 있다는 전제 아래 설계해야 한다”며 “모든 요청의 인증과 인가를 백엔드에서 다시 확인하고 이용자에게 필요한 정보만 반환하도록 설계해야 한다”고 강조했다. 공개 프로필에는 공개가 허용된 항목만 보내고 이메일 주소와 심사평, 내부 평가 정보는 권한을 확인한 이용자에게만 제공해야 한다는 설명이다.