보안

크리덴셜 스터핑 공격의 주 목표물이 된 금융 API

Lucian Constantin | CSO 2020.02.21
보안 및 콘텐츠 전송 업체 아카마이(Akamai)가 공개한 새로운 데이터에 따르면 사용자 계정을 무단으로 액세스하기 위한 시도 5번 중 1번은 사용자 대면 로그인 페이지가 아닌 API(Application Programming Interfaces)를 통해 이뤄진다. 이 추세는 API가 광범위하게 사용되는 금융 서비스 업계에서 더욱 두드러지게 나타나며, 규정 준수를 위한 요건이 이러한 현상을 부추기는 측면도 있다.

최근 발표된 보고서에 따르면 아카마이는 2017년 12월부터 2019년 11월까지 자사 서비스를 사용하는 전세계 기업을 대상으로 854억 회의 크리덴셜 악용 공격이 발생했음을 확인했다. 이 중에서 20%에 가까운 약 165억 회의 공격은 명확하게 API 엔드포인트로 식별되는 호스트 이름을 목표로 발생했다. 그러나 금융 업계의 경우 2019년 5월부터 9월 사이 API를 목표로 하는 공격 비율이 급증해서 때로는 75%에 이르기도 했다.

아카마이는 보고서에서 “API의 사용과 광범위한 도입으로 범죄자들은 공격을 자동화할 수 있게 됐다. 이것이 크리덴셜 스터핑(credential stuffing) 사고의 규모가 매년 계속해서 증가하고 이러한 공격이 모든 시장 세그먼트에 걸쳐 지속적인 위험 요인이 되는 이유”라고 전했다.
 
ⓒ Getty Images Bank
 

크리덴셜 스터핑 문제

무차별 대입 공격의 한 유형인 크리덴셜 스터핑은 유출된 사용자 이름과 비밀번호 조합 목록을 사용해서 계정 액세스 권한을 획득하는 공격으로, 최근 몇 년 사이 큰 문제로 떠올랐다. 지난 10년 동안 많은 데이터 유출이 발생했고 그로 인해 수십억 개의 도난된 크리덴셜이 인터넷에 공개되거나 지하 시장에서 상품으로 판매된 데 따른 결과다.

공격자는 사용자들이 여러 웹사이트에 걸쳐 동일한 비밀번호를 사용한다는 점에 착안, 데이터 유출을 통해 노출된 크리덴셜을 사용해 이른바 조합 목록(combo list)을 만들었다. 이 사용자 이름과 비밀번호 조합 목록을 봇넷 또는 자동화된 툴에 로드해서 웹사이트를 대상으로 로그인 요청을 쏟아내 액세스 권한 획득을 노린다.

액세스 권한을 얻은 후 고객 페이지를 크롤링해 관련 서비스에서 정보를 추출하려면 일정한 노력과 수작업이 필요한 반면, API를 통해 정보를 요청하고 추출하는 방법은 표준화되어 있고 자동화에도 잘 맞는다. 애초에 API의 용도가 애플리케이션의 상호 통신과 자동 데이터 교환을 촉진하는 데 있기 때문이다.

아카마이 연구진은 “크리덴셜 스터핑에서 우리가 살펴본 API는 REST(REpresentational State Transfer) 및 SOAP(Simple Object Access Protocol)를 사용해서 리소스에 액세스한다. 리소스에는 개인 정보와 계정 기록, 잔고, 기타 플랫폼 내의 툴 또는 서비스가 있는 계정 요약 페이지가 포함된다. 직접 비교할 수는 없지만 REST와 SOAP는 기본적으로 애플리케이션 간의 통신 방법이다. REST는 프로젝트에 따라 다양한 방법으로 구현할 수 있으며 SOAP는 데이터 교환을 위한 표준”이라고 설명했다.
 

공격 집중되는 금융 업계

API는 운영체제 내부를 비롯한 여러 곳에서 오래전부터 사용됐지만 웹 API는 지난 10년 사이 사용량이 급증했다. 웹 API 사용량 증가의 이유 중에는 모바일 생태계도 있다. 모바일 앱은 API를 통해 백엔드 서비스와 통신하기 때문이다. 또한 클라우드 인프라의 도입과 서비스 지향 아키텍처로의 전환으로 전통적인 자급자족형 모놀리식 앱 대신 각자 개별 기능을 처리하고 API를 통해 상호 통신하는 컨테이너화된 마이크로서비스가 들어선 것도 웹 API 사용량 폭증의 요인으로 작용했다.

금융 기술(핀테크) 혁신도 금융 기관이 고객 데이터와 서비스를 API를 통해 제공하도록 압박하는 역할을 했다. 실제로 지난 9월 유럽 연합(EU)에서 발효된 개정된 결제 서비스 지침(PSD2)은 이러한 API 개념과 오픈 뱅킹 원칙을 더욱 촉진했다.

PSD2에 따라 은행을 비롯해 고객 계좌를 보유한 기타 금융 기관은 계좌 소유자가 동의하는 경우 서드파티 서비스가 가용 자금 유무를 확인하고 결제를 개시하거나 계좌 데이터에 액세스할 수 있도록 해야 한다. 이 요청을 준수하는 가장 일반적인 방법은 웹 API를 개발하는 것이고, 대부분의 은행은 PSD2 시한보다 충분히 앞서 이러한 API를 구현하기 시작했다.

PSD2와 비슷한 규제 요건이 없는 유럽 외 국가의 금융 기관 역시 시장의 힘에 따라 혁신하고 경쟁력을 유지하기 위해 같은 방향으로 나아가고 있다. 보안 전문가들은 오래 전부터 뱅킹 API의 구현 오류와 공통 개발 표준의 부재가 데이터 유출 위험을 높일 수 있음을 우려해왔다.

광범위한 API 도입 외에, 금융 서비스 업계가 보유한 방대한 데이터도 사이버 범죄자들이 원래부터 항상 노리는 목표물이었다. 이 데이터를 입수하면 다양한 방법으로 수익화할 수 있기 때문이다. 금융 데이터는 다른 서비스 유형에서 추출할 수 있는 정보보다 더 가치가 높은 만큼 금융 업계 API는 이들에게 더 탐스러운 먹이감이다.

아카마이 연구진은 “범죄자들은 항상 은행 카드, 금융 크리덴셜, 유출된 기프트 카드 잔고, 온라인 뱅킹 계정을 사고 팔고 거래한다. 이러한 자료에 대한 수요가 높기 때문이다. 침해된 자산 일부는 현금으로 교환되고, 나머지는 범죄자 간에 교환되기도 한다. 예를 들어 잔고가 있는 유효한 은행 계좌를 유럽의 신용카드 계좌와 교환하는 식”이라고 전했다.

범죄자들은 크리덴셜 스터핑과 API 악용 외에 금융 데이터에 액세스하기 위한 다른 공격 유형도 사용한다. 아카마이는 24개월 동안 금융 분야에서 4억 7,300만 건의 크리덴셜 스터핑 공격을 감지했는데, 그 사이 다른 웹 애플리케이션 공격도 6억 6,200만 회 발생했다. 금융 서비스 분야를 대상으로 한 웹 애플리케이션 공격 중 상위 유형은 로컬 파일 인클루전(LFI, 47%), SQL 주입(SQLi, 36%), 크로스 사이트 스크립팅(XSS, 7.7%)으로 나타났다. 그 외에 PHP 주입, 명령 주입, 원격 파일 인클루전, OGNL 주입 및 악성 파일 업로드 등의 공격 유형도 관찰됐다.

LFI 공격은 다양한 웹 프로그래밍 언어로 작성된 스크립트 파일을 대상으로 한다. PHP가 가장 주된 대상이지만 ASP, JSP 등도 마찬가지이며, 공격으로 인해 민감한 정보가 노출되는 경우가 많다.
 

부족한 API 보호

아카마이 연구진은 API 개발에서 공격자들의 악용을 쉽게 해주는 여러 문제점을 발견했다. 예를 들어 일부 API는 단위 시간당 인증 횟수에 제한이 없어 해커가 매분 수만 회의 비밀번호 추정 공격을 실행할 수 있다. 인증 요청에 대한 스로틀링은 좋은 방법이지만 이것 하나만으로는 크리덴셜 스터핑 공격에 대한 완전한 방어책이 되지 못한다. 공격자가 요청 속도를 낮춰 차단을 피하도록 스크립트를 구성할 수 있기 때문이다.

또 다른 문제는 실패한 로그인 시도에 대한 API의 오류 응답이다. 이 응답을 통해 사용자 이름이 서비스에 존재하는지 여부에 대한 정보가 유출될 수 있고, 공격자는 이 정보를 활용해서 크리덴셜 목록을 검증, 조정, 정렬해서 트리거되는 오류 비율을 낮추고 결과적으로 향후 탐지하기 더 어렵게 만들 수 있다.

아카마이 연구진은 “단지 금융 기관만이 아니다. 훔친 크리덴셜을 범죄 행위에 이용하는 범죄자의 공격에는 모두가 노출된다. 이 지속적인 공격에 맞서기 위한 툴 중 하나는 제로 트러스트(zero trust)다. 이 프레임워크의 도입이 확산되면 범죄자가 크리덴셜 스터핑과 같은 패시브 공격을 사용해서 네트워크에 침투하기가 더 어려워진다. DNS가 소스에서 차단될 수 있으므로 피싱 또는 맞춤형 지휘통제 서버를 활용하기도 더 어렵게 된다”고 전했다. editor@itworld.co.kr
 

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.