[API보안] API 공격 예시 (객체 수준 권한 위반:Broken Object Level Authorization)

API 공격 예시 : BOLA

오늘은 API 공격의 중에서 대표적이며 가장 치명적이 BOLA에 대해서 알아보도록 하겠습니다.

 

Broken Object Level Authorization 줄여서 BOLA라고 하는데요,
우리말로 번역하면 ‘객체 수준 권한 위반’ 정도가 됩니다.
사용자 정당한 인증 절차를 거친 후에라도 객체 수준에서 권한 검사가 제대로 이루어지지 않아 공격자가 인가되지 않은 객체 즉 데이터 등에 접근할 수 있는 취약점을 의미합니다.

은행 앱을 예로 들어서 설명 드려 보도록 하겠습니다.
사용자 벤자민 올리비아가 핸드폰 은행 앱에 접속을 하였습니다. 
그리고, 통장 잔액을 조회하려고 한다고 가정해 봅시다.
당연히 자신의 계좌 정보를 잘 가져올 것입니다.

BOLA 예시 - 정사적인 응답

 

그런데, 벤자민 올리비아가 캐를로트 아멜리아의 계좌 정보를 가져올 수 있다면 어떻게 될까요?
이것은 큰 문제이고, 또 더 큰 문제를 발생시킬 수도 있을 것입니다.
하지만 통계에 따르면 약 60%의 API들이 이러한 공격에 취약하다고 합니다.

BOLA 예시 - 비정사적인 응답

아래의 화면은 앞으로 제가 소개할 노네임 서비스의 화면을 캡쳐한 것인데요,
프란시스라는 사용자가 자신의 정보만을 조회할 수 있어야 하지만,
아래에 붉게 표시된 줄들이 그렇지 않고, 다른 사람의 정보도 조회하고 있다고 판단하여 이슈를 제기한 화면입니다.

BOLA 예시 - 정사적인 응답

 

정상적인 응답에서는, 로그인한 사람에 해당하는 프란시스의 정보를 리스판스 값으로 응답하는 것을 확인 할 수 있습니다.

하지만, 비정상으로 판단되는 트래픽에서는 요청한 사람은 여전히 프란시스이지만…

응답으로 보내는 패킷을 보면 프란시스가 아닌 노아라는 사람의 정보를 전달하는 것을 확인할 수 있습니다.

BOLA 예시 - 비정사적인 응답

 

해커가 가져가고 싶은 만큼의 데이터를 가져갈 수 있게 되는 것입니다.
한 사람의 계정으로 접근되지 말아야할 정보에 접근을 하여 정보를 가져가거나, 심한 경우 데이터를 조작할 수도 있게 됩니다. 뿐만 아니라 BOLA공격으로 시스템에 부하를 주어 서비스거부 상태를 유발 할 수도 있을 것입니다.
이러한 취약점은 기존의 시그니처 방식의 웹방화벽이나 API Gateway 등에서는 탐지가 거의 불가능 할 것입니다. 그래서 여전히 Top 10의 No. 1으로 남아 있는 것일 수도 있구요.

 

BOLA - 해커는 권한이 없는 데이터를 원하는 만큼 가져 갈 수도 있습니다.

여기서 중요한 사실 중 하나는 기존의 웹방화벽(WAF) 같이 시스니쳐 기반의 장비들은 이러한 데이터 유추를 감지해 낼 수 없다는 것입니다.

 

API Transaction들에 대한  Context 인식이 가능한 API Security Platform 필요

 

API 취약점의 증거 - 다크웹에서 거래되는 JSON 파일 형식의 데이터들

국내의 API를 이용한 침해 사고를 직접 말씀 드릴 수 있으면 좋겠지만,
솔직히 국내에서 사고가 났을 때 직접적으로 API가 문제가 되었다고 리포팅 된 적은 없습니다. 그리고, 그렇게 보고할리도 만무 할 것이구요.
하지만… 다크웹에서 거래되는 자료의 변화를 보면 API가 문제가 되고 있다는 것을 유추해 볼 수는 있습니다.

API 보안 취약점을 이용한 것으로 유추되는 다크웹에서 거래되는 JSON 형식의 정보들

이전에 다크웹에서 거래되는 자료들은 주로 액셀파일이나 CSV 같은 테스트 파일이였습니다. 
하지만, 최근에는 API 연동을 할 때 주로 사용되는 JSON 형식으로 수집된 데이터들이 유통된 다는 것입니다.
정확한 분석은 어렵지만 이런 자료는 API의 취약점을 이용하여 권한이 없는 데이터를 대량으로 접근, 수집하여 유통시키는 것으로 유추해 보는 것은 어렵지 않을 것 같습니다.
이렇게 API에 문제점들이 있는데, 현장에서는 어떤 패인포인트를 가지고 있을까요?

 

API 보안 관련 Pain Points

미국의 선도적인 은행 중 한 곳에게 물었습니다. API 관련해서 어떤 점이 문제인지?
첫번째, API에 관한 가시성 확보가 어럽다는 것입니다.
우리는 무언가를 관리하려면 먼저 무엇을 관리해야한는지 알야야 합니다. 하지만 좀전 말씀 드린것 처럼 API 현황 파악이 되지 않고 있다는 것입니다.
두번째, API 관련 보안 리스크를 확인 할 수 있는 방법이  없다는 것입니다.
세번째, API가 개발자를 위한 것이고 개발단에서  예방할 수 있으면 가장 좋겠다는 것입니다.

API 보안 관련 Pain Points

 

 

이러한 시장의 요구를 모두 만족시키는 제품이 있는데, 앞으로 제가 소개할 노네임 이라는 회사의 API Security Platform 입니다. 

 

도움이 되는 이전 글

[IT이야기] - API 보안 - 여러분의 API는 안전하십니까?

[API보안] 여러분의 API는 안전하십니까?