1. 개요
- 스마트폰을 통한 비대면 금융 서비스의 특성상, 금융 서비스를 이용하는 주체가 실제 권한을 가진 주체인지 확인하는 것이 매우 중요
- 인증 수단 자체에 대한 보안성은 확보했더라도, 인증 절차의 검증이나 절차 간의 연계에 대한 보안성 확보 등은 강구해나가야 할 과제
- 최근 이러한 인증 수단 및 절차의 허점을 이용한 금융 서비스의 명의 도용 및 인증 우회 피해 사례가 증가해 인증 서비의 보안이 더욱 중요
- 금보원은 간편 비밀번호·생체인증 등 다양한 금융 인증 체계를 해커의 관점에서 심층 분석한 ‘레드아이리스 인사이트 리포트 : Campaign Poltergeist’를 발간 [1]
※ 내용의 민감성을 고려하여 요약본 게시
2. 주요 내용
- 인증 수단 자체의 보안성이 강화되었더라도, 인증 절차의 설계와 구현 과정의 미흡함은 공격자에게 취약점을 노출하는 원인이 됨
2.1 인증 수단 및 절차 분석
- 서비스 이용 주체의 명의를 확인하는 데 사용되는 인증 수단의 분류
| 분류 | 인증 수단 및 설명 |
| 지식 기반 | - 인증 요청자의 지식으로써 알고 있는 정보를 통해 인증을 수행 - 별도 절차 없이 지식과 기억에 의존하여 인증하므로 간편하게 인증 절차를 수행 가능 - 인증 정보를 잊어버린 경우를 대비한 재발급 절차 마련 및 안전한 인증 절차를 거치도록 해야 함 > ID/PW, 거래비밀번호, 계좌비밀번호, 문답식, 패턴 등 |
| 소지 기반 | - 인증 요청자가 보유하고 있는 매체나 기기를 황용하여 인증을 수행 - 지식 기반 인증 비밀번호가 유출되어도 소지 기반 인증을 2-Factor 인증 수단으로 활용해 보다 안전한 설계 가능 - 단말이나 매체를 분실할 수 있으므로 안전한 재발급 및 재등록 절차를 마련해야 함 > SMS/ARS, 이메일, OTP(One-Time-Password)/M-OTP(Mobile-OTP), 비대면 실명인증(신분증 인증), 타행/타사 계좌 인증(1원 인증), 앱 기반 인증, 생체인증 등 |
| 지식 기반 + 소지 기반 | - 보유한 지식과 매체 모두를 동시에 활용하여 인증하는 방식 - 둘 중 하나만 유출되었을 때 공격자가 인증 과정을 우회할 수 없도록 더 안전한 인증 과정 설계 가능 - 망각이나 분실에 대비하여 안전한 재발급/재등록 절차를 마련해야 함 > 공동인증서, 민간인증서, 기기 종속 인증(간편인증서), 신용카드 인증 |
- 인증 절차 분석
> 인증 수단 자체가 가지는 안정성도 중요하나, 이를 어떻게 절차적으로 설계하고 구현하는지가 취약점을 결정짓는 핵심 요소
| 인증 절차 단계 | 설명 |
| 인증 정보 획득 | - 사용자가 인증을 위해 필요한 정보를 획득하는 단계 |
| 인증 정보 요청 | - 사용자가 획득한 인증 정보를 인증 기관이나 인증 요청 기관에 전달하는 단계 - 인증 정보의 성격에 따라 네트워크 구간 암호화와 함께 종단간 암호화(E2E Enctyption)을 적용해 전달 |
| 외부 기관 인증 | - "인증 정보 요청 단계 이전"이나 "인증 정보 검증 단계"에서 클라이언트나 서버가 외부 기관을 통해 인증을 수행하는 단계 - 인증 정보를 외부 기관에 전달하여 응답으로 받은 값을 가져오고, 해당 값을 통해 인증 절차의 정상 수행 여부를 판단 > 외부 기관을 통해 인증을 수행할 때는 금융 기관이 직접 구현하지 않고 외부 기관이 제공하는 코드, 모듈, API 등을 활용 > 인증 절차를 구현해야 하는 플랫폼별 언어가 다양해 외부 기관 인증의 구현체 코드를 각 언어에 맞춰 구현해야 하는 부담 |
| 인증 정보 검증 | - 사용자가 전달한 인증 정보에 해당하는 주체와 서비스를 요청한 주체의 일치 여부를 검증 |
| 인증 결과 응답 및 서비스 요청 |
- 서버에서 처리한 인증 결과를 사용자에게 전달하는 단계 > 인증 결과값을 받아 다음 인증 단계 또는 서비스 이용을 위한 요청을 전송 > 인증 결과값은 프록시 도구로 변조가 가능하므로 인증 결과의 클라이언트단 검증은 신뢰해선 안됨 |
2.2 인증 우회 취약점 분석
- 인증 절차는 일반적으로 인증 정보 획득, 요청, 검증, 응답 및 서비스 요청 단계로 구성
> 인증 요청자는 클라이언트, 인증 검증자는 서버로써 인증 정보를 주고 받으며 전체적인 인증 절차를 수행
> 외부 기관과 연계하여 인증을 수행하는 경우, 인증 정보 획득, 검증 단계에서 클라이언트 혹은 서버가 외부 기관과 통신하여 인증 절차를 진행
| 인증 절차 단계 | 취약점 명 | 설명 |
| 인증 정보 획득 | 공격자 명의 인증 수단으로 인증 수행 (인증 정보 획득 시) |
- 인증 절차 수행을 위한 서비스가 완전히 모듈화되어 있고, 인증 절차 진행을 위해 사용자 정보를 웹 요청(Request) 파라미터를 통해 받는 경우 > 인증 절차 진행을 위한 사용자 정보를 공격자 명의로 변조하여 인증 절차를 진행할 수 있음 > 인증 절차가 정상적으로 진행됐는지 유효성만 판단하는 경우 사용자 명의가 다르더라도 인증 절차를 통과되었다고 간주하여 인증 결과가 정상으로 반환되는 것을 악용 가능 |
| 타 사용자 인증 정보 획득 | - OSINT 활용, 기유출된 인증 정보 등을 통해 타 사용자의 인증 정보를 획득할 수 있는 공격 > 인증에 사용되는 여러 인증 정보는 여러 인증 수단에서 공통적으로 사용되는 경우가 많음 > 또한, 그 값이 변하지 않는 경우가 많기 때문에 인증 정보를 획득함으로써 다른 모든 인증 우회 공격 시나리오의 시작이 되는 경우가 많음 |
|
| 피해자 명의 인증 수단 임의 발급/등록/변경 | - 인증에 필요한 지식 정보, 인증 매체 등을 피해자의 의사와 관계없이 공격자가 임의로 발급/등록/변경할 수 있는 공격 > 다른 취약점이나 공격으로 획득한 피해자 정보를 통해 정상적인 절차를 밟아 인증 수단을 발급/등록/변경 > 인증 수단 외에도 회원 정보에 등록된 이메일, 휴대전화 등을 공격자 명의로 변경하여 해당 수단을 이용하는 인증 절차 우회 가능 |
|
| 인증 정보 획득시 응답값에 인증 정보 노출 | - 서버로부터 인증 정보 획득을 위한 요청 응답값에 인증 정보가 노출되어 공격에 악용 > 구현상의 실수로 인증 정보 그 자체를 응답으로 넘겨주는 경우가 있음 |
|
| 인증 정보 요청 | 공격자 명의 인증 수단으로 인증 수행 (인증 정보 요청 시) |
- 처음 인증 정보 요청은 피해자 명의로 했으나, 실제 인증 정보를 서버에 전달할 때 공격자 명의 인증 수단으로 진행하는 공격 방식 > 인증 정보를 보낼 때 인증 수단에 대한 정보를 함께 보낸다면 그 정보를 공격자 명의로 변조하거나 공격자 명의의 인증 정보를 보냄 > 모듈화 된 인증 서비스로 인해 본 서비스 요청 처리 전 인증 수행 및 명의 검증 절차가 정확히 지켜지지 않아 발생하는 취약점 |
| 인증 정보 변조 및 생성 | - 인증 수단을 통해 획득한 인증 정보를 공격자가 유추할 수 있거나 생성해낼 수 있는 경우, 인증의 정상 수행 여부와 상관 없이 인증 정보를 요청할 때 정보를 변조 또는 생성하여 서버를 속일 수 있음 > 인증 결과를 서버에서 검증/처리하지 않고, 클라이언트 단에서 인증 정보 검증 결과를 받아 그 결과를 다시 서버에 요청하고 인증의 정상 수행 여부를 처리하는 경우 발생 가능 |
|
| 테스트 페이지/테스트 파라미터를 통한 인증 | - 테스트 용도로 만들어 둔 페이지나, 특수한 파라미터를 받았을 때 어떤 인증 요청이 와도 항상 정상적으로 인증된 것처럼 인식하는것을 악용 > 개발/테스트 시 복잡한 인증 절차를 모두 수행하기 어려워 항상 인증 절차를 통과하도록 만들어 둔 테스트 인증 절차가 배포 과정에서 운영 코드에 들어가 발생 |
|
| 외부 기관 인증 | 클라이언트 단에서 외부 기관 인증 정보 검증 | - 외부 기관 인증 요청 및 결과에 대한 검증을 서버에서 수행하지 않고 클라이언트 단에서 수행할 때 발생 > 공격자는 앱 변조, 응답값 변조, 결과 변도 증을 통해 인증 절차를 우회할 수 있음 > 서버단에서의 인증 절차 수행 여부 검증이 없기 때문에, 단순히 최종 서비스 요청 패킷을 변조하여 전송하는 것만으로도 목적을 이룰 수 있음 |
| 외부 기관 접근 권한 획득 | - 인증 절차에 사용되는 외부 기관의 접근 권한이 탈취되었을 때 발생하는 취약점 > 슈퍼앱(여러 금융 계열사의 서비스를 하나의 앱으로 서비스)을 운영하는 금융기관이 늘어남에 따라, 앱 내 법인이 다른 동일 그룹 계열사 기관을 지정하여 타행/타사 계좌 인증을 우회할 수 있음 |
|
| 취약한 인증 결과 응답값 오용 | - 외부 기관으로 부터 인증을 수행하고 전달 받은 결과값이 단순히 인증 결과만을 반환하거나 변조/생성될 수 있는 값일 경우 인증 우회에 사용할 수 있음 > CI 값의 경우 DI 값과 달리 사용자별로 변하지 않는 고유한 값이기 때문에 다른 기관에서 CI 값이 유출되었을 시 이를 이용해 인증 절차를 우회할 수 있음 ※ CI(Connecting Information, 연결 정보) : 특정 개인을 고유하게 식별할 수 있도록 연결하는 정보 ※ DI(Duplicated Information, 중복 정보) : 특정 서비스 또는 기관에서 동일한 사용자가 중복 가입하는 것을 방지하기 위해 활용하는 정보 |
|
| 인증 정보 검증 | 인증 절차 정상 수행 여부 미검증 | - 하나 혹은 여러 인증 수단의 각 절차가 정상적으로 진행되지 않았을 때 서버에서 인증 절차의 정상 수행 여부를 검증하지 않는다면 인증 절차와 관계 없이 공격자가 요청한 서비스가 정상 처리 될 수 있음 > 여러 인증 수단을 복합적으로 사용하는 경우 각 인증 수단에 따른 인증 절차가 정상적으로 진행되었는지, 각 절차별로 결과에 대해 서버에서 상태(State)를 관리하여야 함 |
| 인증 정보 검증의 잘못된 예외 처리 | - 인증 정보 검증 시 발생한 에러에 대한 예외 처리 구현이 잘못되었을 경우 오류가 발생했음에도 서비스는 정상 처리되는 등의 문제가 발생할 수 있음 > 타 사용자로 로그인 되는 등 인증 관련 보안 사고가 발생할 수 있으므로, 인증 관련 구문의 예외 처리 구현을 견고히하여야 함 |
|
| 인증 정보 검증 오류 횟수 미제한 | - 오류횟수 제한을 두지 않았을 경우, 무작위 대입 공격을 통해 공격자가 비밀번호를 추측해 알아낼 수 있음 > 계좌 비밀번호, 거래 비밀번호, 카드 유효기간, 카드 비밀번호, 카드 CVC 번호 등은 금융 거래에 핵심이 되는 지식 정보이지만 복잡성이 낮은 정보들이 많기 때문에 오류횟수 미제한은 심각한 결과를 초래할 수 있음 |
|
| 인증 결과 응답 | 공격자 명의 인증 수단으로 인증 수행 (인증 결과 응답 이후) |
- 인증 절차를 공격자 명의의 인증 수단으로 진행하고 인증 결과 응답에 포함된 공격자 명의의 정보를 피해자 명의의 인증 정보로 변조 > 클라이언트에서 변조된 정보가 자동으로 서명 및 암호화 과정에 사용되어 인증 우회가 용이함 > 서버는 정상적인 인증 응답으로 인식하기 때문에 보안 검증을 우회할 수 있음 |
| 인증 결과 응답값을 정상 응답값으로 변조 | - 인증 결과 응답값을 정상 응답값으로 변조하여 클라이언트에선 마치 인증이 완료된 것처럼 인식되게 하고 인증 절차의 다음 단계로 넘어갈 수 있음 > 응답값을 변조한 것이기에 서버단에서의 검증에는 영향 없음 > 공격자가 요청시마다 일일히 공격자 명의 인증 정보를 피해자 명의 인증 정보로 변조하지 않아도 되기 때문에 공격 난이도와 복잡성을 낮출 수 있는 방법 |
2.3 Campaign Poltergeist
- 인증 우회 취약점의 연계를 통해 타 사용자의 계정 권한을 탈취, 추가 공격을 감행
> 마치 다른사람이 된 것처럼 인증 수단들을 발급하고 금융 서비스를 이용
| 구분 | 설명 |
| Simple Path | - 간편함이 핵심인 모바일 뱅킹 환경에서 사용자 편의성과 접근성을 위해 인증 수단들은 간편화되기 시작 > 6자리 간편 비밀번호, 생체기반 인증, 간편인증서 등이 도입 > 간편 인증정보들이 탈취되었을 경우 그 위험성 또한 몇 배로 증가 |
| Shadow Twin | - M-OTP, 공동인증서, API를 사용해 계좌 이체, 대출 등을 수행할 수 있음 > 간편 인증서 탈취 후 여러 인증 수단과 절차를 우회하거나 발급받아 금전적 피해가 발생할 수 있음 > 피해자의 모든 인증 수단과 권한을 공격자가 얻게 됨 |
| Spectral Vault | - 비대면 금융 서비스의 등장으로 명의 도용 등으로 대포통장과 사기계좌로 이용될 수 있음 > 계좌 개설 프로세스는 사기 등의 범죄 조직들의 악용을 막기위해 강력한 인증 절차를 갖춤 > 인증 우회 취약점의 연계를 통해 계좌 개설 프로세스에 사용되는 인증 절차를 모두 우회해 계좌 개설이 가능 |
2.4 근본 원인
① 여러 인증 수단의 복합적 사용
- 각 인증 수단 결과를 서버에 기록 및 검증하는 절차 역시 복잡해져 구현 실수 발생
- 하나의 인증 수단이 우회되거나 공격자가 임의로 발급받을 수 있다면 다른 인증 수단의 발급/등록 과정을 연쇄적으로 우회될 수 있음
② 복잡한 외부 인증 기관과의 연계
- 여러 인증 수단의 구현을 위해 금융사 자체적으로 모든 인증 서비스를 구현 및 운영할 수 없어 외부 인증 기관과 연계
- 클라이언트가 서버로 전달한 외부 인증기관 인증 결과의 정상 여부, 명의 일치 여부 등의 확인 과정이 복잡해짐
③ 인증 서비스 코드 통합 및 유지보수의 어려움
- 외부에서 개발한 코드를 통합하였기 때문에 코드에 대한 이해도가 떨어지고, 복잡한 인증 절차가 맞물려 연계 및 검증에 허점이 발생
- 또한 수정 또는 변경사항이 있을 시 유지보수를 위해 코드를 수정하는 과정에 문제가 발생 가능
2.5 대응방안
① 견고한 인증 프로세스 설계
- 여러 인증 수단의 복잡한 사용과 외부 인증기관과의 복잡한 연계로 견고한 인증 프로세스 설계가 필요
- 모든 발생 가능한 공격 유형에 대비하고, 그 결과를 서비스 최종 요청 처리 시 확인할 수 있도록 설계해야 함
- 인증 과정과 관련된 로그를 남기고 이상 행위를 탐지할 수 있도록 설계
② 인증 절차 구현 시 보안 요구사항 적용
- 인증 수단별로 발생 가능한 모든 취약점 유형을 고려하여 보안 요구사항을 적용
- 다양한 인증 서비스 코드를 통합하고 유지보수하는 과정에서도 이러한 요구사항이 적용될 수 있도록 해야 함
- 하나의 인증 수단 뿐만 아니라 전체 인증 절차를 연계하는 과정에서도 요구사항을 충족하는지 검증 및 보완
③ 인증 우회 취약점 분석 및 대응
- 불가피한 사유로 인증 우회 취약점이 남아있거나 기능 수정 등을 통해 새롭게 발생 가능
- 주기적인 취약점 분석과 모의해킹을 통해 잠재 위협을 제거
- 대목적을 두고 공격 방식의 제한없이 수행하는 모의해킹을 통해 위협을 식별
2.6 결론
- 모바일 앱을 통한 금융 서비스 이용이 보편화되면서 비대면 신원 확인의 중요성이 증가
- 하나의 인증 수단이 우회되어도, 다른 인증 수단으로 신원을 확인하여 부정 행위를 차단할 수 있도록 복합적인 인증 절차가 정확히, 제대로 구현되어야 함
3.참고
[1] https://www.fsec.or.kr/bbs/detail?menuNo=1011&bbsNo=11640
[2] https://www.dailysecu.com/news/articleView.html?idxno=164205
'취약점 > 기타' 카테고리의 다른 글
| STARLINK 관리 패널을 통한 Subaru 차량 해킹 (2) | 2025.02.21 |
|---|---|
| 터널링 프로토콜 취약점 (CVE-2024-7595, CVE-2024-7596, CVE-2025-23018, CVE-2025-23019) (0) | 2025.01.23 |
| LDAPNightmare 취약점 (0) | 2025.01.07 |
| 통신 인프라 관련 보안 가이드라인 (3) | 2024.12.10 |
| LotL (Living off the Land) 대비 가이드라인 (5) | 2024.10.21 |
