brunch

You can make anything
by writing

C.S.Lewis

by penna Jul 29. 2024

불충분한 인증

휴대폰 인증 우회

"이거 조치 어떻게 하면 될까요?

"이름, 생년월일, 휴대폰 번호 등 많은 개인정보가 탈취된 상황이면 저희가 어떻게 할 수 없는 거 아닌가요?

인증 취약점 보고서를 대하는 개발자분들은 여러 가지 반응을 보입니다. 사실 인증이라고 묶이지만 세세한 공격 기법이 다른 경우가 많기 때문에 당연한 현상이기도 합니다.


모바일로 계좌를 발급해 보면, 동의서를 체크하라는 메뉴가 나오고 이름, 생년월일, 휴대폰 번호를 입력하고 인증번호를 받은 다음 신분증 본인확인을 거칩니다. 그러고 나서 계좌번호 비밀번호도 입력합니다. 보통 이런 과정을 거치고 본인을 확인하는 방법이 더 추가되기도 합니다.

우리는 이걸 인증단계라고 부릅니다.


그리고 이런 단계에서 취약점이 발생할 때

인증이 충분하지 않다고 표현합니다.

불충분한 인증


그렇다면 취약점은 어떻게 발생될까요?

인증 취약점 관련해서는 여러 종류의 형태가 있지만 오늘은 휴대폰 인증과 관련된 부분만 이야기해보려고 합니다.


이름/생년월일/휴대폰 번호와 인증번호를 입력하는 단계에서는 우선, 탈취된 정보의 경우의 수를 여러 개로 나눠봅니다.

공격자가 피해자의 이름, 생년월일만 알고 있을 경우,

피해자의 이름, 생년월일, 휴대폰 번호를 모두 알고 있을 경우,

그리고 생각보다 많은 정보가 탈취되어 피해자 이름, 생년월일과 피해자명의의 휴대폰까지 공격자가 획득한 경우 등을 가정할 수 있습니다.


이름과, 생년월일만 알고 있는 경우는 휴대폰 번호를 공격자의 번호로 바꿔보면 됩니다.

피해자의 이름과 생년월일을 알고 있을 경우, 공격자의 휴대폰 번호로 휴대폰인증 과정을 수행해서 다음 단계로 넘어갈 수 있는지를 확인해 본 다음 일치하지 않는 사용자라는 내용을 응답으로 받아오면 그 부분을 변조해 봅니다. 그리고 공격자의 정보로 요청이 된다면 그 부분도 피해자의 정보로 바꿔봅니다. 서버에서 검증을 제대로 하더라도 클라이언트에서 오는 내용에만 의존해 검증을 수행할 경우, 클라이언트단에서 변조하여 인증 우회가 가능할 수도 있기 때문입니다.


이름, 생년월일, 휴대폰 번호까지 알고 있는 경우에는 정상적인 정보를 입력한 뒤 휴대폰 인증번호를 임의로 넣어봅니다. 휴대폰 번호는 알지만 공격자에겐 피해자의 휴대폰이 없기 때문에 인증번호는 모르는 상태입니다. 이때 인증 번호가 일치하지 않아 완료되지 않았다는 응답 패킷이 오면 정상적인 인증이 수행되었을 때 내용으로 바꿔봅니다. 보통 정상 에러코드를 '0000' 등으로 사용하므로 0으로 바꿔보기도 하고 해당 서버에서 정상적인 인증 과정을 거친 다음 정상 응답값을 획득해 덮어 씌워보기도 합니다.


그리고 마지막으로 피해자의 명의로 임의 개통된 휴대폰까지 공격자 손에 들어갔을 경우,

다른 단계에서 추가 인증 정보로 검증하는 수단이 있는지를 살펴봅니다. 그래서 휴대폰 인증 단계 이후의 인증 단계에서 사용자를 식별하는 값이 하나일 경우가 있는지도 찾아보는데요,

보통 고객번호나 ID, 계좌번호 등과 같이 유추나 획득하기 비교적 쉬운 정보 중 한 가지 값만을 이용해서 특정 단계를 우회할 수 있는 인증 취약점이 추가로 확인된다면 추가 검증 로직이 필요하다고 가이드를 드리고 있습니다.


이럴 때는 사용자의 인증을 한 가지 값 만으로 수행하지 않도록 해야 합니다. 휴대폰 번호를 다른 사용자로 변조할 경우 서버에서 현재 입력한 이름, 생년월일과 휴대폰 번호를 대조하여 동일한 사람인지를 검증하는 과정이 필요합니다. 그리고 가급적 서버에서 수행한 인증에 대한 결과를 클라이언트단에 내려주지 않아야 합니다. 인증을 수행하는 서버가 따로 있다면 인증에 대한 부분을 서버 대 서버로 검증값을 주고받아 클라이언트단에서 변조가 가능하지 않도록 해야 합니다.

만약에 휴대폰 인증 단계 이후의 단계에서 한 가지 값이나 쉽게 변조가 가능한 정보로 인증을 수행하는 단계에 대한 가이드를 전달할 때 너무 엄격하게 취약점을 잡는 게 아닌지 문의 전화가 온다면,

이름, 생년월일, 임의로 개통된 휴대폰까지 있는 경우 까지도 가정해서 취약점을 봐야 하며 우리는 서비스 제공자로서 최소한의 방어 로직은 있어야 한다고 전달해 드리면 됩니다.







이전 05화 관리자 페이지
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari