랜섬웨어가 아무리 극악해도, 열리지 않는 파일까지 암호화시킬 수는 없다. 그렇다면 MS가 윈도 시스템 내에서 공격자가 파일을 열지 못하게 만들면 랜섬웨어는 의외로 간단히 해결될 수 있다. 물론 파일을 열지 못하게 한다는 것 자체가 간단한 건 아니지만.
[보안뉴스 문정후 기자] 최근 필자는 ‘설계에 의한 보안’과 관련된 작은 행사에 참석했었다. 거기서 필자는 마이크로소프트가 미래 랜섬웨어 방어의 열쇠를 쥐고 있다고 주장했다. 다들 뜨악한 표정이라 대단히 놀랐다. 보안과 IT, 인터넷 생태계에 대해 잘 알고 있는 사람들이 모였던 자리였는데 그런 접근 방식에 대해 한 번도 생각해보지 않았었다니 놀랄 수밖에.
랜섬웨어라는 멀웨어는 피해자의 시스템에 저장되어 있는 파일을 하나하나 따로따로 암호화 하는 방식으로 작동한다. 파일에 저장되어 있던 원래 내용물을 볼 수 없도록 뒤바꾸는 건데, 아직까지는 이걸 한꺼번에 할 수는 없고 하나씩 진행하는 것으로 공격은 실시된다. 그런데 윈도에 설치된 소프트웨어들은 CreateFile이라는 API를 사용해 파일들에 접근하도록 되어 있다. 흥미롭게도 CreateFile은 이름 그대로 파일을 생성하는 것이 목적인 API인데 파일을 여는 데에도 주로 사용되고 있다. 랜섬웨어가 파일을 열 때도 이 API가 활용된다.
그러니 열쇠는 MS가 쥐고 있다고 해도 과언이 아니다. MS가 CreateFile API의 활용 방식을 제한하면 어떻게 될까? 즉 특정 프로그램이 CreateFile을 사용해 시스템 내 파일을 연다고 했을 때 횟수 제한을 거는 것이다. 그러면 랜섬웨어 프로그램이 암호화 하는 프로그램에 제한이 생길 것이고, 따라서 랜섬웨어 공격은 크게 약화될 것이 뻔하다. 제한을 넘겨서 암호화 하려고 한다면 경보가 울리고 보안 담당자들이 금방 조치를 취할 수 있게 된다.
하지만 필자는 일이 이런 식으로 진행되기를 원하지 않는다. 왜냐하면 CreateFile API 사용 횟수에 제한을 두게 될 경우 꽤나 복잡한 문제가 발생할 수 있기 때문이다.
어느 정도가 적절한 횟수인가?
복잡한 문제 중 가장 첫 손에 꼽히는 건 ‘횟수를 어느 수준으로 맞춰야 하는가?’이다. 만약 높은 숫자로 정한다면 랜섬웨어의 파일 암호화 기능을 제한한다는 본연의 목적에 부합하지 않게 된다. 너무 낮은 숫자로 정하면 멀쩡한 소프트웨어의 사용이 불편하게 된다. 예를 들어 컴파일러 프로그램의 경우 정말 많은 파일들을 열 때가 있는데 여기서 제한이 걸리게 되면 개발자들은 일을 할 수가 없다. 백업용 소프트웨어는 심지어 더 많은 파일을 열고 닫을 수 있어야 한다.
그러므로 일반적으로 통용될 만한 숫자를 정해서 제한을 걸되 예외적인 경우까지도 허용할 수 있도록 하는 게 필요하다. 하지만 이 예외적인 경우를 공격자들이 그냥 넘어갈 리가 없다. 분명히 파일 열기 제한 횟수의 예외가 적용되도록 한 뒤에 피해자의 파일을 암호화 할 것이 분명하다.
어떤 것들이 예외가 될 수 있을까? 위에서 설명한 대로 컴파일러나 백업 프로그램이라면 예외 대상이 될 수 있다. 그렇다고 모든 컴파일러와 백업 프로그램을 다 예외로 만들 수 없다. 어떻게 믿고? 그러니 MS는 합법적인 컴파일러와 백업 프로그램에 대한 인증서를 발행하기 시작할 것이다. 인증서를 발행하려면 MS가 전 세계 수많은 개발사들의 신청을 받고 점검하는 과정을 추가로 도입해야 한다.
그런 후에는 로깅과 경보 규칙도 새롭게 생성되고 실험되고 세계 곳곳의 실정에 맞게 조정되어야 한다. 윈도 관리 도구인 GPO들도 새롭게 개발돼 문서화 되어야 한다. 로컬에서 합법적으로 개발되는 프로그램들을 위한 CreateFile 호출 신호들이 무엇인지 조사되고, 이를 허용할 방법들까지 등장해야 한다. 이 모든 과정을 거치면서 동시에 랜섬웨어 공격자들이 그 어떤 것 하나 임의로 사용하지 못하도록 방어 장치를 마련하는 것도 당연하다.
이 복잡한 과정을 오류나 실수 없이 진행하여 새로운 방식의 컴퓨팅 혹은 업무 프로세스가 버그나 취약점 없이 도입될 수 있을까? 필자는 그 가능성이 매우 낮다고 본다. 그러므로 CreateFile API를 MS가 손봐서 사용 횟수를 제한시켜야 한다는 주장은, 사실 매우 간단한 개념이지만 실상은 그렇지 않다. 뚜껑을 여는 순간 온갖 벌레들(즉 버그들)이 튀어나올 것이 분명하다. 그렇기에 개념을 발설할 때 그 이면의 디테일들도 고려해야만 한다.
하지만 MS가 나서서 랜섬웨어의 암호화 과정을 의도적으로 어렵게 만드는 행위가 ‘벌레 가득한 상자’를 여는 것이라고 해서 손도 대지 말아야 할까? 오늘 날 우리가 랜섬웨어를 겪으며 입는 피해의 규모를 생각했을 때, 미지의 버그 상자를 여는 게 그리 위험하거나 높은 대가를 지불해야하는 것으로만 여겨지지는 않는다. 어쩌면 그 버그 상자에서 나오는 각종 위험 요소들은 충분히 감내할 만한 것일지도 모른다.
MS는 CreateFile을 수정함으로써 랜섬웨어 공격을 크게 약화시킬 수 있다는 걸 이미 알고 있을 것이라고 생각한다. 그것에 제한을 걸었을 때의 결과 역시 예측하고 있을 지도 모른다. 그리고 랜섬웨어 피해와 CreateFile을 수정했을 때의 피해를 가늠하고 있는 과정일 수도 있다. 어느 시점이 됐든 우리는 MS의 결단이 필요하다.
글 : 아담 쇼스택(Adam Shostack), 위협 모델링 전문가
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스 문정후 기자] 최근 필자는 ‘설계에 의한 보안’과 관련된 작은 행사에 참석했었다. 거기서 필자는 마이크로소프트가 미래 랜섬웨어 방어의 열쇠를 쥐고 있다고 주장했다. 다들 뜨악한 표정이라 대단히 놀랐다. 보안과 IT, 인터넷 생태계에 대해 잘 알고 있는 사람들이 모였던 자리였는데 그런 접근 방식에 대해 한 번도 생각해보지 않았었다니 놀랄 수밖에.
[이미지 = gettyimagesbank]
랜섬웨어라는 멀웨어는 피해자의 시스템에 저장되어 있는 파일을 하나하나 따로따로 암호화 하는 방식으로 작동한다. 파일에 저장되어 있던 원래 내용물을 볼 수 없도록 뒤바꾸는 건데, 아직까지는 이걸 한꺼번에 할 수는 없고 하나씩 진행하는 것으로 공격은 실시된다. 그런데 윈도에 설치된 소프트웨어들은 CreateFile이라는 API를 사용해 파일들에 접근하도록 되어 있다. 흥미롭게도 CreateFile은 이름 그대로 파일을 생성하는 것이 목적인 API인데 파일을 여는 데에도 주로 사용되고 있다. 랜섬웨어가 파일을 열 때도 이 API가 활용된다.
그러니 열쇠는 MS가 쥐고 있다고 해도 과언이 아니다. MS가 CreateFile API의 활용 방식을 제한하면 어떻게 될까? 즉 특정 프로그램이 CreateFile을 사용해 시스템 내 파일을 연다고 했을 때 횟수 제한을 거는 것이다. 그러면 랜섬웨어 프로그램이 암호화 하는 프로그램에 제한이 생길 것이고, 따라서 랜섬웨어 공격은 크게 약화될 것이 뻔하다. 제한을 넘겨서 암호화 하려고 한다면 경보가 울리고 보안 담당자들이 금방 조치를 취할 수 있게 된다.
하지만 필자는 일이 이런 식으로 진행되기를 원하지 않는다. 왜냐하면 CreateFile API 사용 횟수에 제한을 두게 될 경우 꽤나 복잡한 문제가 발생할 수 있기 때문이다.
어느 정도가 적절한 횟수인가?
복잡한 문제 중 가장 첫 손에 꼽히는 건 ‘횟수를 어느 수준으로 맞춰야 하는가?’이다. 만약 높은 숫자로 정한다면 랜섬웨어의 파일 암호화 기능을 제한한다는 본연의 목적에 부합하지 않게 된다. 너무 낮은 숫자로 정하면 멀쩡한 소프트웨어의 사용이 불편하게 된다. 예를 들어 컴파일러 프로그램의 경우 정말 많은 파일들을 열 때가 있는데 여기서 제한이 걸리게 되면 개발자들은 일을 할 수가 없다. 백업용 소프트웨어는 심지어 더 많은 파일을 열고 닫을 수 있어야 한다.
그러므로 일반적으로 통용될 만한 숫자를 정해서 제한을 걸되 예외적인 경우까지도 허용할 수 있도록 하는 게 필요하다. 하지만 이 예외적인 경우를 공격자들이 그냥 넘어갈 리가 없다. 분명히 파일 열기 제한 횟수의 예외가 적용되도록 한 뒤에 피해자의 파일을 암호화 할 것이 분명하다.
어떤 것들이 예외가 될 수 있을까? 위에서 설명한 대로 컴파일러나 백업 프로그램이라면 예외 대상이 될 수 있다. 그렇다고 모든 컴파일러와 백업 프로그램을 다 예외로 만들 수 없다. 어떻게 믿고? 그러니 MS는 합법적인 컴파일러와 백업 프로그램에 대한 인증서를 발행하기 시작할 것이다. 인증서를 발행하려면 MS가 전 세계 수많은 개발사들의 신청을 받고 점검하는 과정을 추가로 도입해야 한다.
그런 후에는 로깅과 경보 규칙도 새롭게 생성되고 실험되고 세계 곳곳의 실정에 맞게 조정되어야 한다. 윈도 관리 도구인 GPO들도 새롭게 개발돼 문서화 되어야 한다. 로컬에서 합법적으로 개발되는 프로그램들을 위한 CreateFile 호출 신호들이 무엇인지 조사되고, 이를 허용할 방법들까지 등장해야 한다. 이 모든 과정을 거치면서 동시에 랜섬웨어 공격자들이 그 어떤 것 하나 임의로 사용하지 못하도록 방어 장치를 마련하는 것도 당연하다.
이 복잡한 과정을 오류나 실수 없이 진행하여 새로운 방식의 컴퓨팅 혹은 업무 프로세스가 버그나 취약점 없이 도입될 수 있을까? 필자는 그 가능성이 매우 낮다고 본다. 그러므로 CreateFile API를 MS가 손봐서 사용 횟수를 제한시켜야 한다는 주장은, 사실 매우 간단한 개념이지만 실상은 그렇지 않다. 뚜껑을 여는 순간 온갖 벌레들(즉 버그들)이 튀어나올 것이 분명하다. 그렇기에 개념을 발설할 때 그 이면의 디테일들도 고려해야만 한다.
하지만 MS가 나서서 랜섬웨어의 암호화 과정을 의도적으로 어렵게 만드는 행위가 ‘벌레 가득한 상자’를 여는 것이라고 해서 손도 대지 말아야 할까? 오늘 날 우리가 랜섬웨어를 겪으며 입는 피해의 규모를 생각했을 때, 미지의 버그 상자를 여는 게 그리 위험하거나 높은 대가를 지불해야하는 것으로만 여겨지지는 않는다. 어쩌면 그 버그 상자에서 나오는 각종 위험 요소들은 충분히 감내할 만한 것일지도 모른다.
MS는 CreateFile을 수정함으로써 랜섬웨어 공격을 크게 약화시킬 수 있다는 걸 이미 알고 있을 것이라고 생각한다. 그것에 제한을 걸었을 때의 결과 역시 예측하고 있을 지도 모른다. 그리고 랜섬웨어 피해와 CreateFile을 수정했을 때의 피해를 가늠하고 있는 과정일 수도 있다. 어느 시점이 됐든 우리는 MS의 결단이 필요하다.
글 : 아담 쇼스택(Adam Shostack), 위협 모델링 전문가
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-05-10] 
.jpg)
