South Korea’s online security dead end 번역

Owned by Woojin Kim
Last updated: 2023-01-29
6 min read

IT_NEWS_BOT이 올린 ‘한국 인터넷뱅킹 보안을 지적한 외국 보안 연구자의 글’을 통해 'South Korea’s online security dead end'를 읽었습니다. 최근 몇 년 사이에는 스마트폰을 통해 어느 정도 완화되기는 했지만 지난 수십 년에 걸쳐 한국 인터넷 뱅킹 사용자들을 고통스럽게 만드는 문제에 대한 글입니다. 글을 작성하신 ‘Wladimir Palant’님의 허락을 받아 한국어로 옮겼습니다. 번역에 대한 의견과 지적은 마스토돈이나 트위터로 부탁 드립니다.

원문은 이 주소를 참고하세요:
https://palant.info/2023/01/02/south-koreas-online-security-dead-end/

이후 공개되는 글의 번역은 아래 주소를 참고해 주세요:

https://github.com/alanleedev/KoreaSecurityApps

막다른 골목에 다다른 한국 온라인 보안

2023-01-02

수정 (2023-01-07): 2월 공개 일정을 하나 더 추가.

지난 9월 저는 비정상적으로 사용자가 많은 한국 애플리케이션을 조사하기 시작했습니다. 문서가 거의 없어 실제로 이 애플리케이션이 무슨 역할을 하는지 파악하는데 시간이 걸렸습니다. 결국 저는 이 애플리케이션이 보안 문제로 가득하며 보안 애플리케이션이라고 광고됨에도 불구하고 문제를 악화 시킨다는 점을 깨달았습니다.

그렇게 한국의 아주 특별한 보안 애플리케이션 환경으로 여정을 시작했습니다. 그 후로 저는 다른 여러 애플리케이션을 조사했고 이전에 처음으로 조사했던 애플리케이션만의 문제가 아니라는 점을 깨달았습니다. 이들 모두는 심각한 보안 문제 및 개인정보 문제를 일으켰습니다. 그러나 이들은 한국의 거의 모든 컴퓨터에 설치되어 인터넷 뱅킹이나 정부 웹사이트를 사용하기 위한 조건이었습니다.

애플리케이션 각각의 단점에 대해 이야기하기 전에 이 상황이 어떻게 시작됐고 정확히 무엇이 잘못 되었는지를 요약하고 싶었습니다. 제가 아는 한 한국인 지금 보안 상 아주 열악한 상황에 처해 있으며 최대한 빨리 출구를 찾아야 합니다.

목차

역사적 개요

종종 저는 한국이 아주 특별하다는 말을 들었습니다. 주제를 완전히 이해했다고 말하기는 어렵지만 이를 설명하는 위키피디아 항목이 있습니다. 분명히 1990년대 미국의 강력한 암호화 기술에 대한 수출 제한으로부터 문제가 시작되었습니다. 이로 인해 한국은 자체 암호화 솔루션을 개발하게 됩니다.

이로 인해 미국에서 나온 보안 기술에 대한 근본적인 불신이 시작된 것 같습니다. 따라서 수출 제한이 해제된 후에도 한국은 SSL 위에 자체 보안 레이어를 계속해서 추가했습니다. 모든 사용자는 인터넷 뱅킹을 사용하기 위해 별도 애플리케이션을 설치해야 했습니다.

이러한 애플리케이션은 마이크로소프트가 독점한 액티브X 기술을 사용했습니다. 이는 인터넷 익스플로러에서만 작동했으며 한국에서 다른 브라우저 채택을 심각하게 방해했습니다.

위키피디아에는 이런 상황을 개선하기 위한 여러 대중 운동이 나열되어 있습니다. 이들의 압력에도 불구하고 실제 상황이 바뀌기 시작한 것은 2010년이 훨씬 지나서였습니다.

기술적으로 이 솔루션은 여러 차례에 걸쳐 나타나고 사라지기를 반복한 것 같습니다. 처음에는 비 마이크로소프트 브라우저에서 액티브X에 가장 가까운 NPAPI 플러그인 형태였습니다. 또한 NPAPI 플러그인보다 훨씬 단순한 브라우저 익스텐션을 기반으로 하는 솔루션도 있었습니다.

현재 애플리케이션 제작사는 브라우저에 접근할 필요가 없음을 깨달은 것으로 보입니다. 대신 웹사이트와 애플리케이션 사이에 통신 채널만 있으면 됩니다. 이제 이런 모든 애플리케이션은 웹사이트와 통신하는 로컬 웹서버를 실행합니다.

현재 상황

오늘날 일반적인 한국의 인터넷 뱅킹 웹사이트는 로그인 전에 보안 애플리에키션 다섯 개를 설치해야 합니다. 이 애플리케이션 동물원을 관리하기 위한 애플리케이션을 하나 더 설치합니다. 그리고 웹사이트마다 서로 다른 애플리케이션 세트가 필요하기 때문에 한국의 일반적인 컴퓨터는 아마도 그저 웹을 사용하기 위해 대여섯 개의 서로 다른 제작사에서 제공하는 다양한 애플리케이션을 실행할 겁니다.

이런 애플리케이션 각각은 웹사이트에서 설치해야 하는 SDK와 함께 제공되며 대여섯 개의 자바스크립트 파일로 구성됩니다. 따라서 일반적인 한국 인터넷 뱅킹 웹사이트는 로딩하는데 상당한 시간이 걸립니다.

흥미롭게도 이런 애플리케이션 대부분은 중앙 집중식 다운로드 서버를 제공하지도 않습니다. 애플리케이션 배포와 업데이트는 애플리케이션을 사용하는 웹사이트(은행)로 완전히 떠넘겨져 있습니다.

예상대로 정확하게 동작합니다. 단순히 사용성만 보면 이들 중 일부는 몇 년 전에 브라우저 익스텐션을 사용하는 것에서 통신을 위해 로컬 웹서버를 사용하는 형태로 기술적 변화를 겪었습니다. 몇몇 은행은 여전히 오래된 버전을 배포하고 동작하기를 기대하며 다른 은행은 새 버전을 사용합니다. 사용자들은 애플리케이션이 설치된 이유를 알 수 없지만 은행들은 그렇지 않다고 주장합니다. 그리고 은행과 사용자는 함께 불평합니다.

당연히 애플리케이션을 배포하는 웹사이트 역시 표적이 됩니다. 그렇게 많은 다운로드 서버를 적절하게 보호하는 것은 비현실적입니다. 그래서 몇 년 전 북한의 라자루스 그룹은 악성 코드 배포를 위해 보안 애플리케이션 배포 서버 일부를 공격했습니다.

소프트웨어 품질

한국에서 널리 사용되는 여러 보안 애플리케이션의 구현을 면밀히 살펴봤습니다. 이후 블로그 게시물을 통해 문제 각각을 살펴보겠지만 몇몇 경향이 보편적으로 나타납니다.

국가 전체의 보안에 대한 책임이 있는 소프트웨어의 제작사는 훨씬 주의해야 한다고 생각할 수 있습니다. 하지만 제가 살펴본 바로는 그렇지 않았습니다. 보안 측면에서 이러한 애플리케이션들은 최신 기술보다 수십 년 뒤처지는 경우가 많았습니다.

이는 단순한 사실에서 시작합니다. 애플리케이션 일부는 C++가 아닌 C로 작성됩니다. 이는 로우레벨 프로그래밍 언어이기 때문에 요즘에는 일반적으로 디바이스 드라이버 같은 하드웨어와 가까운 곳에서 동작하는 코드에 사용됩니다. 그러나 여기서는 복잡한 방식으로 웹사이트와 상호작용하는 대규모 애플리케이션에 사용됩니다.

C의 메모리 관리에 대한 수동 접근 방식은 버퍼 오버플로와 같은 악용할 수 있는 메모리 안전 문제의 일반적인 원인입니다. C에서 이를 피하려면 대단히 주의해야 합니다. 이로 인한 버그는 제 조사의 초점이 아니었지만 이런 애플리케이션들은 이들의 개발자가 메모리 안전 문제를 피하는데 경험이 많음을 보이지 못했습니다.

최신 컴파일러는 이런 문제를 완화하는데 도움을 주는 다양한 보안 메커니즘을 제공합니다. 하지만 이런 애플리케이션은 최신 컴파일러를 사용하지 않고 약 15년 전에 출시된 비주얼 스튜디오에 의존합니다.

그리고 ASLR(Address Space Layout Randomization)이나 DEP(Data Execution Prevention)처럼 고대의 컴파일러가 지원하는 기본적인 보안 메커니즘도 비활성화 되는 경향이 있습니다. 이럴만한 타당한 이유는 없습니다. 이는 무료로 제공되는 순수한 보안 혜택입니다.

설상가상으로 이런 애플리케이션에 포함된 오픈소스 라이브러리는 전혀 업데이트 되지 않는 경향이 있습니다. 지금까지 최고 기록은 10년 이상 된 라이브러리입니다. 지난 10년 사이에 여러 개선사항과 보안 수정사항이 포함된 50회 이상의 릴리즈가 이루어졌습니다. 그러나 이들 중 어느 것도 애플리케이션에 포함되지 않았습니다.

은닉응 통한 보안

한국의 보안 애플리케이션 모두가 암호화에 관한 것이라는 점을 감안할 때 이들은 놀랍게도 여기에 서투릅니다. 대부분의 경우 암호화는 알고리즘을 리버스 엔지니어링 할 수 없는 공격자에 대해서만 보호하는 단순한 난독화 수준입니다. 제가 발견한 다른 문제는 수십 년 전부터 더 이상 사용되지 않는 알고리즘 파라미터에 의해 완전히 암호화하지 않는 것이었습니다.

실제로 이런 애플리케이션 제작사는 리버스 엔지니어링을 주요 문제로 보는 것 같습니다. 여기에는 투명성이 거의 없고 은닉응 통한 보안만 있습니다. 이런 접근 방식이 실제 공격자를 저지하는데 효과가 있는지 아니면 우리가 성공적인 공격 사례를 확인하지 못한 것 뿐인지 구분하기 어렵습니다.

어느 쪽이든 여러 애플리케이션이 리버스 엔지니어링을 방지하기 위해 런타임에 디크립트 소프트웨어 보호를 사용하는 것을 보았습니다. 이런 메커니즘에 대한 경험이 많지는 않지만 런타임에 x64dbg로 프로세스에 연결해 Scylla 플러그인을 사용하면 디스어셈블러에 연결할 수 있는 디크립트 된 exe/dll 파일을 얻을 수 있다는 것을 알았습니다.

디버거가 연결되면 애플리케이션을 즉시 종료하는 서비스가 있습니다. 또 어떤 애플리케이션은 브라우저의 개발자 도구를 사용할 수 없도록 시도하기도 합니다. 두 메커니즘 모두 보안 위험을 완화하지 않습니다. 목표는 동작을 은닉한 상태로 유지하는 것입니다.

설명 시도

여기서 주요 문제는 사용자가 애플리케이션의 고객이 아니라는 점입니다. 애플리케이션의 역할은 아마도 사용자들의 안전이지만 실제 고객은 은행입니다. 사용자들은 애플리케이션 설치 여부를 선택할 수 없으며 모두 필수로 설치해야 합니다. 그리고 은행은 책임을 위임할 수 있습니다.

누군가 해킹으로 돈을 잃어버리면 은행의 잘못일 수 없습니다. 은행은 모든 것을 올바르게 처리했습니다. 이는 사용자가 모든 중요한 보안 애플리케이션을 설치하게 만들었습니다. 이것이 은행의 잘못일 수 없는 논리인 것 같습니다.

이는 가짜 보안 애플리케이션 시장을 만들어냅니다. 이들 대부분은 문제를 제대로 해결하지 못합니다. 이들은 심지어 문제를 상당히 악화시킵니다. 그리고 몇 안되는 보안 상 의미 있는 기능이 있다면 최신 웹 브라우저는 이런 애플리케이션 없이도 완벽하게 기능을 수행합니다.

그러나 은행이 이런 애플리케이션을 계속해서 구매하는 한 이 중 어느 것도 중요하지 않습니다. 은행이 계속해서 애플리케이션을 구매하는 행동은 애플리케이션이 의미 있는 동작을 하는지 여부가 아니라 그들을 위한 가치 때문입니다.

애플리케이션 제작사는 당연히 이를 알고 있습니다. 이는 그들이 수십 년 동안 애플리케이션 보안에 투자하지 않는 이유입니다. 단순히 이는 중요하지 않습니다. 중요한 것은 은행이 사용하게 될 기능입니다. 중요한 것은 애플리케이션을 커스터마이징 하는 방법, 더 많은 사용자 데이터를 수집하는 방법, 주목할 만한 노력 없이 그저 돈을 사용해 보안을 얻는 방법입니다.

막다른 골목으로부터 벗어나기

불행하게도 저는 한국 사회에 대해 아는 것이 너무 적어 그들이 이 완벽하지 못한 상황으로부터 어떻게 벗어나야 할 지 말할 수 없습니다. 그러나 한 가지 확신할 수 있는 것은 기존 보안 애플리케이션을 개선해도 소용 없다는 것입니다.

그렇습니다. 제가 발견한 보안 문제와 개인정보 보호 문제를 보고했습니다. 이 정보가 공개되기 전에 애플리케이션 제작사에게 사용자를 보호할 시간을 주었습니다. 그리고 그렇게 되길 바랍니다.

하지만 실제로 상황을 바꾸지는 않을 것입니다. 이런 문제 중 많은 부분이 의도적으로 설계되었기 때문입니다. 그리고 이 문제를 모두 고치면 더 이상 판매할 제품이 없을 것입니다.

사실 이상적인 결과는 한국의 특수한 보안 상황이 해소되는 것입니다. 이런 보안 애플리케이션에 의존하지 않는 것이 보안에 큰 도움이 될 것입니다. 그러나 이는 확실한 입법 조치 없이는 불가능합니다. 이상적으로는 사용자에게 다시 선택권을 주고 기본적인 온라인 서비스를 사용하기 위해 서드파티 애플리케이션을 강제 설치하는 것을 금지해야 합니다.

이후 공개 일정

보안 문제를 보고하면 제작사는 일반적으로 90일 안에 문제를 해결합니다. 마감일이 끝나면 제 연구를 공개합니다. 공개될 내용에 관심이 있다면 이 블로그의 RSS 피드를 구독하거나 예정된 일정에 블로그를 확인할 수도 있습니다.