국내 비대면계좌개설 보안(Security) 리뷰

국내 비대면계좌개설 보안(Security) 리뷰

비대면 계좌개설?

- 비대면. 즉, non face-to-face로써 은행 영업점에 방문하지 않고도 계좌를 개설할 수 있다는 뜻이다. 

- 2015년 12월경부터 은행을 포함한 각 금융기관별로 차례대로 시행하기 시작한 계좌 개설 방법으로, 은행 방문 없이 스마트폰을 통해 실명 인증을 하고 바로 계좌를 개설해주는 서비스이다.

- 비대면 계좌개설은 핀테크 기술 중 하나이다.

케이뱅크, 카카오뱅크와 같은 인터넷전문은행은 100% 비대면 계좌개설이 이루어진다. 국책은행(기업은행, 산업은행), 시중은행, 제2금융권까지 비대면 계좌 서비스를 런칭했다. 그런데 은행 영업점에 직접 방문하지 않아도 되는 편리함외에 단점(disadvantage)은 없을까? 금융보안원은 비대면 계좌개설에 대해 아래와 같이 언급했다.

디지털 채널 등 다양한 실명 확인 방식을 채널을 이용한 비대면 인증은 편리함 이라는 이면에 해킹사고 가 발생했을 시 다수의 대포통장 개설 가능성 등의 위협이 존재한다. 디지털 채널만으로 인증을 수행하기 때문에 인증과정에서의 취약점으로 인해 보안사고가 발생할 경우 다수의 피해자가 발생할 수 있어 기존 대면인증보다 위험 영향도가 높을 수밖에 없다. 이러한 위험을 감소시키기 위해 인증기술 자체나 인증과정에서의 우회의

가능성을 사전에 제거하여야 한다. 또한 신분증 촬영, 영상통화 등 기존의 인증과는 다른 새로운 방식의 인증기술들이 이용되기 때문에 기존의 애플리케이션과는 다른 위협이 존재할 수 있으므로 사전에 이러한 인증기술에서 발생할 수 있는 취약점을 파악해야 한다. 

<금융보안원 금융회사의 안전한 비대면 인증을 위한 연구 일부 발췌>

즉, 계좌개설이 non face-to-face로 이루어지는 만큼 지금 계좌를 만들고 있는 사용자가 진짜 그 사용자 본인이 맞는지 아니면 타인의 신분증, 개인정보를 도용하여 계좌개설을 시도하는 해커인지 판단해야 한다. 비대면계좌개설 어플리케이션이 어떻게 "개인인증"을 구현하는가? 이것이 핵심이다. 금융보안원은 현재 시장에 있는 비대면계좌개설 앱에서 사용되고 있는 개인인증 기술에 발생할 수 있는 보안 취약점(위험성)을 "금융보안원 금융회사의 안전한 비대면 인증을 위한 연구"로 제시했으며, 본 포스팅은 금융보안원의 자료를 바탕으로한 IBK기업은행 비대면계좌개설 서비스의 보안 리뷰이다.

<그림 1><그림 2>

먼저, IBK 휙 계좌개설 어플리케이션을 설치하고 실행하면 <그림 2> 화면을 볼 수 있다. "첫계좌 만들기"로 비대면 계좌개설을 시작한다.

<그림 3><그림 4>

IBK기업은행의 비대면계좌개설은 "신분증", "휴대폰", "(이미 발급된)본인명의 계좌"를 요구하고 있다.

왜 그럴까? 은행 영업점에서 신분증을 건네고 신원을 조회하는 것처럼 비대면계좌개설에서 위 3가지의 수단을 이용하는 것이다.

이 때 사용되는 개인인증 방식은 은행이 마음대로 할 수 있는 것이 아니며 금융위원회에서 제정한 기준을 따라야 한다.

2015년 5월 18일 금융위원회 금융개혁회의를 통해 ‘계좌 개설시 실명확인 방식합리화방안’이 <그림 5>과 같이 발표되었다.

<그림 5>

국내 각 은행들은 <그림 5>에서 거론된 필수 개인인증 방법 2개를 반드시 따라야하며 금융위원회는 권고 인증방법 1개를 '권고'하고 있다.

즉, IBK기업은행의 비대면계좌개설은 아래와 같은 개인인증방법을 사용한 것이다

[필수 개인인증 방법 2가지] 실명확인증표 사본 제출, 기존계좌 활용

[권고 개인인증 방법] 다수의 개인정보 검증(핸드폰인증)

* IBK기업은행이 위 3가지의 개인인증 방법을 사용하므로 "신분증", "휴대폰", "(이미 발급된)본인명의 계좌"를 준비물로 요구한 것.

이 3가지의 개인인증방법을 이용해서 비대면계좌 개설이 <그림 6>의 순서로 진행이 된다.

<그림 6>

금융보안원은 비대면개좌계설을 "시작-신청-심사-계좌개설-완료" 로 5단계로 나누어 구분했으며 <그림 4>는 그에 따른 흐름도(flowchart)이다.

다시, IBK기업은행 비대면계좌계설로 돌아가보자. <그림 7>가 "신청" 단계 중 휴대폰인증(권고사항)을 나타낸다.

<그림 7><그림 8>

흐름도(flowchart)대로 첫 단계는 핸드폰을 이용한 개인인증이 이루어졌다. 즉, 통신사(SKT, KT, LG)에서 가지고 있는 개인정보를 이용하여 지금 계좌를 만들고 있는 사용자가 진짜 사용자인지 구분하는 방식이다. <그림 9>, <그림 10>은 핸드폰인증에 이은 신분증을 사용한 개인인증을 보여준다.

<그림 9><그림 10>

<그림 11>

<그림 9>, <그림 10>을 통해 알 수 있듯이 모바일기기에 내장된 카메라를 이용하여 신분증을 촬영하여 아래와 같은 결과값을 얻는다

데이터1	촬영된 사진파일(.jpg, .png)
데이터2	OCR로 파싱된 "이름"
데이터3	OCR로 파싱된 "주민등록번호"
데이터4	OCR로 파싱된 "발급일자"

<표 1>

* OCR(광학 문자 인식, Optical character recognition)은 사진에 있는 문자를 해석하는 기술이다. 즉, 주민등록증에 출력되어 있는 이름, 주민등록번호, 발급일자를 읽어 해석했다.

얻어진 [데이터1~데이터4]를 IBK기업은행 웹 서버에 전송한다.

<그림 12>

웹 서버에서는 신분증 진위확인을 진행하고 비대면계좌계설 [신청]단계는 끝난다.

[신청] 단계 다음에는 [심사]가 이루어진다. 은행 영업점에 방문하여 계좌를 개설할때 신분증을 건넨다음 이루어지는 작업과 마찬가지로 내 개인정보를 조회하여 이용자가 계좌를 개설하는데 적합한지 부적합한지 [심사]가 이루어진다.

금융보안원에서는 신분증을 통한 개인인증방식이 앱의 구현에따라 아래와 같은 보안취약점이 존재할 수 있음을 경고했다.

[금융보안원- 신분증을 통한 개인인증방식 보안취약점]

1. 주민등록번호 메모리 정보 노출

2. 악성 앱 호출 가능성 존재

3. 메모리 덤프 후 신분증 사진 복원

4. 캡처 및 백그라운드 스크린 샷을 통한 정보 유출 방지

5. 네트워크 평문 전송

6. 타 이용자 신분증 노출

7. 파일 업로드 기능을 통한 웹쉘 업로드 기능

8. 대용량 파일 업로드를 통한 디스크 자원 고갈

1. 주민등록번호 메모리 정보 노출

주민등록번호 등 실명확인증표에 존재하는 민감 정보가 메모리에 저장되는 경우, 공격자가 메모리 데이터에 접근함으로써 이용자의 중요정보가 유출될 가능성이 존재하며 이를 위해 주민등록번호 사용 후 할당했던 메모리를 해제하거나 다른값으로 덮어 씌워야한다

신분증 사진을 OCR로 파싱하면 <표 1>과 같이 [데이터1-데이터4]가 해당 어플리케이션이 운영체제로부터 할당받은 메인 메모리에 존재한다. 금융보안원은 이 데이터 사용이 끝났으면 즉각적으로 데이터를 지우라고 권고했다. 일반적으로는 MMU(memory management unit)와 운영체제에 의해서 프로세스(A)가 할당받은 메모리영역은 다른 프로세스(B)가 접근할 수 없다. 그러나, 악의적인 공격자가 메모리 덤프(dump) 혹은 memory protection 우회기법을 통해 메모리에 접근할 가능성이 있다고 판단하여 위와 같은 가이드를 제시한 것으로 보인다.

신분증 정보를 전역 변수(global variable)에 저장했다면 데이터를 사용한 뒤 반드시 다른 값으로 덮어쓰기(overwrite)하여 데이터를 지워야 한다. 그렇지 않으면 메모리-RW영역에 프로그램이 종료될 때까지 데이터값이 남아있다. 동적 할당(Dynamic Allocation)을 통해 신분증 정보를 저장한 경우에는 메모리 해제(free)전에 메모리 덮어쓰기를 통해 직접적으로 지워야 한다. 왜냐하면, 메모리를 해제했다는 것은 운영체제의 힙 메타데이터를 수정했을 뿐 실제 할당됐던 메모리가 지워지는 시점은 그 메모리에 새로운 값이 쓰이는 시점이기 때문이다.

+ visual studio의 release build를 통해 확인할 수 있다.

메모리 해제를 하지 않으면 신분증 정보가 메모리 안에 남아있으므로 공격자가 그 값을 읽을 수 있다. 만약, Java와 같이 동적 할당된 메모리를 프로그래머가 해제할 수 없고 Garbage Collector에 의한 메모리 해제가 일어나는 경우에는 할당된 메모리가 해제되는 시점을 예측 할 수 없기때문에 반드시 데이터 덮어쓰기(overwrite)를 진행해야 한다.

2. 악성 앱 호출 가능성 존재

① 실명확인증표 사본제출’과정을 모바일 앱을 통해 진행하는 경우 실명확인증표 촬영을 위해 금융 앱에 내장된 촬영 기능이 아닌, 외부의 촬영 전용 앱을 호출하는 경우가 있다. 이러한 경우 공격자는 촬영 전용 앱과 동일한 패키지 명을 가진 악성 앱을 미리 설치하여 촬영 앱 호출 시 악성 앱이 실행되도록 할 수 있다.

즉, 사용자 단말기에 악성 앱이 설치되어 있는 경우 신분증 촬영에 사용되는 카메라 앱 호출을 기기에 내장된 기본 카메라 앱이 아닌 악성코드가 담긴 카메라 앱(이하 악성 앱)이 실행되도록 할 수 있다. 이러한 경우 악성 앱을 통해 신분증을 촬영하면 촬영된 사진이 해커에게 전송되어 개인정보유출 피해가 발생할 수 있다. 따라서, 비대면계좌 앱에서 카메라 앱을 호출할 때는 단말기 내 기본 카메라 앱의 해시 값(hash value)비교를 통해 위변조 여부를 확인하라고 권고하고 있다. 예를 들어 아이폰 기본 카메라 앱의 해시값(ABCD)를 저장해두고 카메라 앱을 호출시킬 때 지금 호출되는 카메라 앱의 해시 값을 구한다. 이 때 얻은 해시 값이 ABCD가 맞는지 체크한다. 만약, 기본 카메라 앱이 호출되었다면 해시값(ABCD)를 얻어 정상적으로 호출이 될 것이고 악성 앱이 호출되었다면 ABCD가 아닌 해시값(!@D#)을 얻어 비정상 종료될 것이다.

* 해시(hash)? https://en.wikipedia.org/wiki/Hash

3. 메모리 덤프 후 신분증 사진 복원

스마트폰을 사용하여 실명확인증표 사본을 제출하는 경우 미리 스캔한 실명확인증표 파일을 제출하는 방식이 아닌 카메라를 사용해서 즉시 제출하여 진행가능하다. ..(중략)..‘③ 네트워크 전송’이 완료된 이후에는 메모리 내에서 삭제하도록 한다

신분증 사진이 메모리에 존재하여 메모리 덤프(dump)를 통해 복원이 가능하다는 것으로 1. 주민등록번호 메모리 정보 노출과 맥락이 동일하다. 1번에서 언급한 바와 같이 데이터를 사용한 뒤 메모리 데이터를 지워야 한다.

4. 캡처 및 백그라운드 스크린샷을 통한 정보 유출 방지

‘① 실명확인증표 사본제출’시 사진 촬영 직후 대부분의 앱에서는 확인을 목적으로 실명 확인증표 사진을 화면에 보여주는데, 이때 캡처방지 기능이 적용되어 있지 않은 경우 화면 캡처 기능을 통해 신분확인증표가 유출될 수 있다. 또한 iOS의 경우 앱이 백그라운드로 진입 시, 진입 직전의 화면을 스크린 샷으로 저장하므로 실명확인을 진행 중인 화면의 이미지 파일이 snapshots 폴더에 저장되어 실명확인증표의 이미지가 유출될 가능성이 존재한다. 이를 방지하기 위해 화면 캡처 방지 기능을 적용하고, iOS의 경우 백그라운드 진입 시 스냅샷 화면을 교체 혹은 삭제해야 한다.

아이폰(ios)를 예로 들면 홈버튼을 두번 클릭하면 <그림 13> 화면을 보게된다. 즉, 비대면계좌 개설앱을 이용하던 도중 다른 앱을 이용하거나 휴대폰 바탕화면으로 이동하면 앱이 백그라운드로 진입하게 되는데, 이때 <그림 13>와 같이 백그라운드로 진입하는 당시 화면이 스크린샷으로 저장된 모습을 보여준다. 스크린샷이 되면 별도의 파일(file)로 저장이 되므로 악의적인 공격자가 비대면계좌 개설앱이 아닌 파일이 저장된 위치를 공격하여 개인정보가 유출될 수 있음을 보여준다. 금융감독원에서는 캡쳐방지기능을 구현해야 한다고 했으나 IBK기업은행 비대면계좌개설 서비스에 캡쳐방지기능은 없었다.(<그림 7>이 캡쳐된 화면 모습이다.)그러나, IBK기업은행은 촬영된 신분증 사진의 주민등록번호 뒷자리를 자체적으로 모자이크 처리하여 캡쳐된 사진 및 스크린샷 파일이 유출된다 하더라도 주민등록번호 뒷자리가 유출되지 않게 조치했다.

<그림 13>

5. 네트워크 평문 전송

실명확인증표 사진 및 OCR로 인식한 실명확인증표 상의 개인정보를 평문으로 전송하는 경우 네트워크상에서 트래픽 캡처 등에 의해 유출될 수 있으므로‘③ 네트워크로 전송’시 반드시 SSL 등과 같은 통신 구간 암호화 기술을 적용해야 하며, 중요 정보는 E2E 적용을 권장한다.

사용자들 간에 같은 무선네트워크를 쓰는 상황에서 평문(plaintext) 그대로 주요 개인정보가 전송될 경우 해커가 전송되는 모든 데이터를 볼 수 있어 위험하다. <그림 10>은 2014년 국내에서 발생했던 대규모 개인정보 유출피해사례이다. NH 농협카드사의 고객 개인정보가 유출되어 "개인정보 유출 확인"서비스를 제공했는데 그 서비스에서 네트워크에 평문으로 데이터를 전송했던 사례로써 논란이 많았다. 개인정보와 같은 중요 데이터들은 반드시 SSL(TLS)와 같은 암호화 통신기술을 적용하여 전송해야 한다.

<그림 14>

6. 타 이용자 신분증 노출

실명확인증표 전송 후 이미지를 보여주기 위해 ‘④ 실명확인증표 저장’과정에서 서버의 특정 식별번호로 실명증표 이미지를 로드하도록 구현한 경우 식별번호 파라미터 변조를 통해, 타 이용자가 업로드 한 실명증표 이미지 파일 및 정보가 유출될 수 있다. 이를 방지하기 위해 이용자가 직접 URL을 통해 이미지에 접근할 수 없도록 해야 하며, 업무상 반드시 필요한 경우 타 이용자의 신분증표가 노출되지 않도록 이용자 검증 절차를 수행해야 한다. 또한 비대면 인증이 완료된 이용자의 실명확인증표사본은 일정기간이 지나면 반드시 삭제해야 한다.

<그림 7>과 같은 촬영된 사진을 보여주는 기능 구현에 관련된 문제이다. 만약, 사용자가 <그림 11>까지 비대면계좌계설 절차를 진행하고 앱을 종료하면 어떻게 될까? 비대면계좌 앱은 사용자가 진행한 단계까지 데이터를 중간저장하고 사용자가 다시 비대면계좌개설 앱을 실행시켰을 때 저장된 포인트부터 다시 진행할 수 있게 만들어졌다. 금융보안원은 촬영된 신분증 사진을 서버로 부터 가져올 때 악의적인 사용자가 네트워크 패킷의 사진 정보에 대한 키 값을 조작하여 다른 사용자의 신분증 촬영본이 노출될 수 있음을 경고했다.

7. 파일 업로드 기능을 통한 웹쉘 업로드 가능

이미지 파일 업로드 시 파일 확장자 검증을 수행하지 않는 경우 공격자는 명령 실행 및 파일열람 등이 가능한 웹쉘8)을 업로드 하여 서버를 장악할 수 있다. ..(중략).. 화이트리스트 기반으로 허용하는 파일 확장자를 정한 뒤 이외의 확장자에 대해서는 업로드를 차단해야 한다.

웹쉘 공격에 대한 방어기법에 대한 내용이다. (asp, php, jsp, cgi)확장자를 가진 파일 업로드를 통해 악성코드로 서버를 공격할 수 있으므로 앱 구현시 데이터 업로드를 받는 과정에서 .png, .jpg와 같이 요구하는 확장자인 경우에만 파일 업로드를 허용해야한다.

8. 대용량 파일 업로드를 통한 디스크 자원 고갈

이미지 파일 업로드 시 파일 크기에 대한 제한을 두지 않는 경우 대용량의 파일을 지속 적으로 업로드하여 서버의 디스크 자원 낭비를 유도할 수 있다. 서버의 디스크를 가득 채워 타 이용자의 정상적인 이미지 파일 업로드가 불 능하도록 하여 서비스 거부 공격을 수행할 수 있다. 이를 방지하기 위해 서버 설정 및 업로드 파일 사이즈를 서버 측에서 검증해야 한다.

악의적인 사용자가 반복적으로 대용량 파일을 업로드하여 서버가 정상적으로 서비스를 제공하지 못 하도록 하는 DoS(Denial of Service)공격이 발생할 수 있음을 경고한 내용이다.

위 절차로 신분증을 통한 개인인증이 모두 진행되었다면 "(이미 발급된)본인명의 계좌"를 이용한 개인인증이 추가적으로 진행된다.

<그림 15><그림 16>

<그림 16>에서 볼 수 있듯이 내가 지금 사용하고 있는 계좌번호를 입력하면 1원+인증번호를 보내준다. 사용하고 있는 인터넷뱅킹 어플로 인증번호를 확인하고 <그림 18>와 같이 올바른 인증번호를 입력하면 최종적으로 계좌가 개설된다.

<그림 17><그림 18>

금융보안원에서는 신분증 개인인증과 더불어 기존 계좌를 통한 개인인증에서도 앱의 구현에따라 아래와 같은 보안취약점이 존재할 수 있음을 경고했다.

[금융보안원- 기존 계좌를 통한 개인인증방식 보안취약점]

1. 타 이용자 계좌 입력

2. 검증단계 우회

<그림 19>

1. 타 이용자 계좌 입력

① 기존계좌 입력’단계에서 입력된 계좌가 본인 소유의 계좌인지 검증하는 절차가 미비한 경우 타 이용자의 계좌를 입력했음에도 불구하고 검증을 통과하여 진행될 수 있다. 또한 구현상의 실수로 계좌가 존재하는지 여부만 검증하는 경우에도 우회의 가능성이 존재한다. 그러므로 반드시 비대면 인증을 진행하는 대상자와 이용자에게 입력받은 계좌 소유주의 일치 여부를 검증해야 한다.

1원+인증번호을 전송받을 계좌를 내 계좌가 아닌 타인의 계좌로 설정하고 인증절차를 진행했음에도 정상적으로 인증이 되는 경우이다. 이것은 개인인증이 진행되지 않는 치명적인 오류이므로 개발과정 중 반드시 이용자 개인계좌가 맞는지 확인하는 코드가 반드시 구현되어야 한다.

2. 검증단계 우회

일반적으로 기존계좌 입력 및 검증 성공 후 다음 단계 화면을 호출 하도록 되어 있으나, 동적 디버깅 툴을 이용하거나 스크립트 코드를 강제로 실행하여 다음 단계 화면을 강제로 호출 할 수 있으며 이를 이용하여 ‘①~④’ 단계의 검증 절차가 우회될 수 있다. 이러한 검증 절차 우회를 방지하기 위해서 반드시 각 인증 절차별로 성공 유무를 서버 세션에 저장하고 이전 단계 검증 유무를 확인해야 한다.

<그림 20>

안드로이드 ARM 프로세서는 Trace32(T32)라는 디버깅 도구로 디버깅할 수 있다. 즉, 비대면계좌 앱을 실행시키고 T32 장비를 연결시키면 T32로 프로세서의 PC(Program Counter)값을 변경시킬 수 있으므로 ‘①~④’ 단계의 검증 절차가 우회될 수 있다. 따라서, '①~⑤ 각 단계'를 진행 할 때 단계별 인증 성공여부를 서버쪽에 저장하고 매 단계마다 이전 단계의 성공여부를 확인해야 T32와 같은 디버깅 도구를 통한 검증단계 우회를 막을 수 있다.

Reference

- [금융보안원] 금융 회사의 안전한 비대면 인증을 위한 연구

- [금융위원회] 비대면 실명확인 운영 현황 및 향후 계획