본문 바로가기

블로그

IT 트렌드의 최신 소식을 만나보세요.

보안

[보안동향] ‘순식간에 뚫린다’ 편리한 간편인증의 두 얼굴

2022.03.07

비대면 업무가 증가하면서 온라인에서 신원을 확인하고 인증(로그인)하는 절차가 더욱 중요해졌습니다. 2020년, 공인인증서 사용의무가 폐지되면서 다양한 인증 수단이 등장했는데요. 이에 보안 검증은 제대로 이루어지고 있는지 우려하는 목소리가 높아지고 있습니다. 메타버스, 블록체인과 같은 신기술이 인증 기술과 결합되면서 복잡도는 더욱 증가하고 있기 때문이죠.

인증에는 보안성 외에 편의성도 고려되는데요. 사용자 편의성을 강화한 간편인증 영역에서는 다양한 업종의 기업이 치열한 경쟁을 벌이고 있습니다. 작년 말, 55개 공공기관에 간편인증을 적용하겠다는 계획이 있었으며, 민간의 유통, 보험, 금융, 서비스 등 다양한 업종에 간편인증이 적용돼 활용되고 있습니다.

간편인증이 적용된 서비스는 나날이 증가하고 있는데요. 그렇다면 서비스에서는 인증에 문제가 없는 것일까요?

LG CNS RED팀은 2021년 침투테스트를 통해 간편인증을 점검했습니다. 그 결과, 다수의 서비스에서 치명적인 실수가 발견됐는데요. 타인이 비밀번호 없이 로그인할 수 있는 보안 허점을 찾을 수 있었습니다. 계정 도용 가능성은 개인 이용자 입장에서 심각한 이슈입니다. 이번 글에서는 사례를 통해 간편인증 연동상의 문제를 짚어보고, 간편인증 대란을 막기 위해 SW개발사가 빠르게 조치할 수 있도록 가이드를 알려드리겠습니다.

A회사 점검 사례

A사는 예약 시스템을 구축하면서 F사 간편인증을 연동했습니다. 간편인증 창에 본인 ID와 비밀번호를 입력한 후 클라이언트로 반환된 F사의 SNS ID값을 변조해 A사 서버로 전달하면 타인 로그인이 가능했는데요. 타인 예약(탑승객, 편명) 정보 조회, 예약 변경 및 취소를 할 수 있었고, 예약 포인트를 사용할 수도 있었습니다. 취약점을 이용하면 발권 업무를 방해할 수 있어 예약 업무의 정상적인 수행은 불가능해 보였습니다. 그뿐 아니라 다른 취약점과 함께 공격하면 고유식별정보 등의 개인정보가 대량으로 유출될 가능성이 높았습니다.

취약점의 심각성을 이해하기 위해 RED팀에서 공격자의 시각으로 바라보겠습니다. 예약은 신원 확인이 전제가 되어야 하는데 간편인증 취약점으로 인해 ‘누가 예약했는지’를 알 수 없게 된다면 어떻게 될까요?

남이 나의 좌석을 취소해 여행 스캐줄을 망쳐버릴 수도 있고, 화물 예약의 목적지를 변경해 버려서 화물 분실이 발생할 수도 있습니다. 연휴에 모처럼 여행 티켓을 예약했는데 알 수 없는 이유로 취소돼 있고, 서비스센터에 문의하면 ‘취소는 본인이 한 것이 맞다’고 할 지도 모르는 상황이 됩니다. 다수의 예약 정보를 조작해 이용자 불편을 초래하는 경우 고객센터 항의로 업무는 마비될 수 있죠. 원인을 해결하지 못해 지속적인 문제가 발생하면 기업 이미지 훼손은 물론이고 주가에 악영향을 미칠 수 있습니다.

타인 계정 로그인을 자동으로 수행하는 도구를 제작해 실행하면 누가, 언제, 어디를 여행했고, 누구와 동행했는지 등 정보를 대량으로 수집할 수 있습니다. 수집된 정보는 다크웹이라는 암시장에 거래될 수 있죠. 범죄조직이 이를 구매해 피싱 범죄에 악용할 수 있습니다. 구체적인 예약정보를 이용해 불륜관계 폭로, 자녀 납치 협박 등의 문자를 보낼 수도 있습니다.

B회사 점검 사례

쇼핑몰 업체인 B사는 인터넷 로그인 방식에 기존 로그인 외에 E사, F사, G사 간편 로그인을 추가했습니다. LG CNS RED팀은 B사의 간편인증을 선택 후 아이디와 패스워드를 입력하고, 회신되는 SNS ID를 프록시 도구를 이용해 다른 값으로 변조했습니다. 리턴된 숫자 12345678을 임의의 숫자 98765432로 변경했더니, “OOO 고객님, 환영합니다” (OOO는 도용된 타인 이름) 라는 메시지와 함께 접속됐습니다. 그리고 메뉴를 통해 고객 등급, 상품 구매이력, 배송현황과 배송지가 그대로 노출됐는데요. 고객 이름과 생년월일, 집주소와 휴대폰 번호까지 조회할 수 있었습니다.

간편인증 제공 업체가 사용하는 SNS ID는 여덟 자리 숫자 일련번호의 형태를 사용하기 때문에 쉽게 유추할 수 있습니다. 00000001부터 99999999의 숫자를 순차적으로 대입하면서 타인 계정 도용을 시도해 볼 수 있죠. 존재하는 SNS ID 값에서 1을 증가시켜 입력해 보았더니, 20 분의 1 확률로 타인 계정을 도용하는 데 성공했습니다. 이는 수작업으로는 3분, 자동화하면 2초에 한 명 꼴로 계정을 탈취할 수 있는 속도인데요. 정상적인 트래픽을 이용하므로 기존 보안 관제 시스템으로는 탐지가 거의 불가능합니다.

간편인증 제공업체의 가입자가 3,000만 명이라 한다면, B사 150만 회원의 쇼핑몰 계정은 한 달 내에 모두 액세스 할 수 있습니다. 150만 명의 회원 이름, 상세 주소, 휴대폰번호, 이메일 주소, 주문내역(상품명/금액/수량/거래일시/주문번호)을 DB화할 수 있죠. 개인정보는 2차 가공돼 범죄조직을 위해 맞춤화될 수도 있는데요. 가령, 빅데이터 분석을 통해 ’20대 미혼 고객’, ‘특정 브랜드를 선호하는 고객’을 선별해 배송지 확인하고 범죄에 악용할 수 있습니다.

또한, 다른 회사의 정보를 결합해 범죄에 활용할 수도 있는데요. 예를 들어, A사의 예약 정보와 결합하면 고객 거주지가 현재 빈집이라는 것을 확인할 수 있어 거주지 침입이나 절도가 발생할 수 있습니다.

뿐만 아니라, 해킹한 계정으로 구매물품에 허위 상품평을 등록해 제품 공급사(중소기업)에 피해를 줄 수도 있습니다. 이용자 계정을 임의 탈퇴하거나 휴면 계정을 활성화해 타인이 점유하는 등 문제를 야기할 수도 있죠.

C회사 점검 사례

C사는 E사, F사 간편로그인을 연동한 업체입니다. 간편인증에 성공한 후, 그 결과 값을 Cookie Header라는 곳에 저장해 인터넷 요청 응답에 활용했는데요. Cookie Header에 저장된 값은 클라이언트 단의 값이고 평문 형태이므로 SNS ID를 변조하기 용이했습니다. 간편로그인 결괏값은 변조된 후 타인 명의로 로그인 됐습니다. 이로 인해 도용된 고객의 계좌번호(마스킹), 상세주소 등을 수집할 수 있게 됐고, 발급된 할인권이나 쿠폰을 공격자가 사용할 수 있게 됐습니다.

C사의 월간 활성 이용자 수는 수 백 만 명이었는데요. 1인당 176원의 개인정보 가치를 적용(* 개인정보 유출 사고 소송 사례 배상금 참고)하면 수 억의 배상금이 발생할 수 있는 사안이었습니다. 더불어, 소송 과정이나 해킹 사고 대응 과정상의 기업 이미지 훼손이나 주가에 미칠 악영향도 상당할 것으로 예상됐습니다.

LG CNS RED팀은 C사에 취약점에 대한 상세 설명과 대응 가이드를 제공했습니다. C사를 포함한 점검 대상 회사는 자체적으로 보안 활동을 수행하는 회사입니다. 소스코드에 대한 취약성을 분석하고, 취약점 점검도 수행하죠. 그럼에도 불구하고 간편인증 연동 취약점이 발견된다는 것은 신기술 응용에 대한 점검의 어려움과 회사 간 시스템 연동 시 발생하는 점검 사각지대가 있다는 것입니다.

ID와 패스워드를 사용하는 방식의 점검은 오래 전부터 체크리스트에 정착돼 왔지만, 간편인증은 체크리스트에 명시적으로 없기 때문에 보안팀의 사정에 따라 점검이 누락될 수도 있습니다. 회사 간 시스템 연동 시 존재하는 사각지대는 항상 문제가 되는 약한 고리인데요. E사나 F사의 개발자API(Application Programming Interface)를 이용해서 간편인증을 연동하다 보면 기능 위주의 연동에서 개발이 완료되고 보안은 놓치게 된다는 것이 문제입니다.

간편인증 취약점의 발생 원인과 대응 가이드

간편인증 연동 취약점이 발생하는 데 있어 이용자 개인은 아무런 책임이 없습니다. 간편인증 제공사 및 이용사의 SW개발 책임을 중심으로 간편인증 취약점 발생 원인과 대응 방안을 살펴보겠습니다.

1.간편인증 제공 회사

간편인증 제공사는 인증에 필요한 회원DB를 보유하고 인증 연동 API와 인증용 유저인터페이스를 제공합니다. API에는 클라이언트 SNS ID의 위변조 여부를 검증할 수 있는 서버 매커니즘인 콜백(callback)이 제공되는데요. 이에 대한 엄격한 상호 검증 과정이 수행돼야 합니다. 콜백에 대한 개발사 구현이 미흡한 경우, 적극적으로 알람을 제공하고 가이드를 제공할 필요가 있죠. RED팀에서 점검한 회사의 대부분은 콜백에 대한 구현을 제대로 하지 못하고 있었고, 클라이언트 단 인증에 전적으로 의존해 로그인을 구현하고 있었습니다.

2.간편인증 연동 회사

첫째, 간편인증 개발자 API 가이드의 콜백을 구현해야 합니다. 둘째, 클라이언트 단의 SNS ID를 위변조하는 보안 테스트를 수행해 취약점이 발생하지 않도록 검증해야 합니다. 셋째, 기존의 소스코드정적분석, 취약점진단, 개발자 시큐어코딩, 교육으로 간편인증 취약점을 탐지하지 못했다면 절차나 방법을 보완해야 합니다.

1) API 콜백 구현은 개발과 운영 단계의 콜백 URL을 구분 지정하고, 운영 서버의 콜백은 누락 없이 구현돼야 합니다. 서버 대 서버 검증이 성공한 후에 클라이언트의 값을 신뢰하도록 개발이 돼야 합니다.
2) 통합 테스트 단계에서 SNS ID 위변조 테스트를 수행할 경우, 프록시 도구를 이용한 동적인 테스트를 수행할 수 있어야 합니다.
3) 시큐어코딩 가이드에는 ‘이전 로그인 IP를 기록 및 변경된 IP로 로그인한 경우 팝업으로 고객에게 알려야 한다’는 내용이 포함돼 있습니다. 타인이 계정을 도용한 것으로 의심되는 경우 팝업으로 접속지IP를 알리는 방법을 고려해 볼 수 있습니다.

RED팀 모의해킹

개발부서는 정상적인 간편인증 기능을 개발하는데 주안점을 두며, 품질 부서는 성능이나 코드품질에 중점을 둡니다. 회사 보안팀은 경우에 따라 다르지만 신기술 보안이나 연동 개발에 대한 점검을 세부적으로 진행하지 못하는 경우가 많습니다.

LG CNS RED팀은 기존 보안 취약점 점검에서 간과했던 신기술 적용 시의 취약점을 식별하고 간편인증 연동에 관한 취약점을 확인해 드립니다.

글 ㅣ LG CNS RED팀

챗봇과 대화를 할 수 있어요