• 아티클

Windows PowerShell악성 코드 차단

Don Jones

Windows Vista가 베타 단계에 있는 동안 코드 이름 "Monad"라는 새 명령줄 셸의 초기 버전에 대해 많은 논란이 있었다는 사실을 기억하고 계십니까? 이 명령줄 셸이 바로 지금의 Windows PowerShell입니다. 당시 "첫 번째 Windows Vista 바이러스"에 관한 주요 언론 보고가 상당히 많았습니다. 그러나

이 "바이러스"는 "Monad"를 대상으로 하는 개념 증명 맬웨어일 뿐이었습니다. 이 스크립트는 기본 설정에서는 작동하지 않으며 스크립트를 실행하려면 "Monad"를 특별하게 구성해야 했습니다. 더욱이 이러한 보고가 발표될 당시에는 Microsoft에서 "Monad"를 Windows Vista®에 포함하지 않을 것임을 이미 발표한 뒤였습니다. 결국 아무 일도 아닌 것으로 한 바탕 소동을 벌였던 것입니다.

그러나 Windows PowerShellTM이 점점 보편화되고 다운로드 횟수가 백만 번 이상에 이르면서 악성 스크립트를 만드는 데 Windows PowerShell이 이용되는 경우가 늘어나고 있습니다. Windows PowerShell에서 위험을 초래할 수 있는 스크립트를 작성할 수 있다면 Windows PowerShell, cmd.exe, VBScript 등 그 어떤 관리 도구도 악의적으로 이용될 수 있습니다. 따라서 PS1 파일이 안전하다고 단정할 수만은 없습니다.

다행히 Windows PowerShell은 기본적으로 어떤 스크립트도 실행하지 않도록 구성되어 있으며 악성 스크립트가 실행되기 위해서는 사용자의 개입이 필요합니다. 이번 호에서는 이러한 문제가 어떻게 발생할 수 있는지 살펴보겠습니다. 이 기사에서 Windows PowerShell을 폄하하려는 의도는 조금도 없습니다. 또한 Microsoft에서 여러 위험 요소를 차단하도록 이 스크립팅 셸을 설계했을 거라고 생각합니다. 그렇다 하더라도 이 기사의 내용을 읽고 이와 같은 잠재적 공격을 차단할 만반의 대비를 할 필요는 있겠습니다.

기본 보안

Windows PowerShell은 그 유명한 신뢰할 수 있는 컴퓨팅 이니셔티브를 추진한 이후 Microsoft에서 설계한 첫 번째 언어라는 점을 주목할 필요가 있습니다. 보안 전문가이자 Writing Secure Code의 저자인 Michael Howard가 Windows PowerShell 팀의 "보안 조언자"로 활동했습니다. Howard는 보안이 최대한 유지되는 코드가 작성되고, 특히 이 셸이 기본적으로 안전하게 구성되어 제공될 수 있도록 많은 도움을 주었습니다.

먼저 초기의 Windows PowerShell 보안 설정에 대해 간단히 살펴보겠습니다. 이 셸은 확장명이 PS1인 파일을 두 번 클릭해도 기본적으로 파일을 실행하지 않습니다. 이 확장명은 메모장과 연결되어 있습니다. 실제로는 스크립트가 실행될 수 있는 조건에 대해 설명하는 실행 정책이라고 하는 기본 제공 기능으로 인해 셸에서 기본적으로 스크립트를 실행하지 않는 것입니다. 실행 정책은 기본적으로 Restricted로 설정되어 있으며, 이 설정에서는 모든 스크립트의 실행이 금지되고 셸을 대화형으로만 사용할 수 있습니다. 실행 정책은 Set-ExecutionPolicy cmdlet을 사용하거나 Microsoft에서 제공하는 그룹 정책 관리 템플릿(ADM 파일)을 통해 변경할 수 있습니다. ADM 파일은 go.microsoft.com/fwlink/?LinkId=102940에서 다운로드할 수 있습니다. 그림 1에서는 설정할 수 있는 실행 정책을 보여 줍니다.

그림 1 안전한 실행 정책 선택

그림 1** 안전한 실행 정책 선택 **(더 크게 보려면 이미지를 클릭하십시오.)

실행 정책에는 몇 가지 예외가 있습니다. 예를 들어 Restricted로 설정되어 있을 때에도 셸은 Microsoft에서 제공한 몇몇 특정 XML 구성 파일을 가져와 설치할 수 있습니다. 이러한 파일은 Microsoft® .NET Framework 형식 확장이나 대부분의 .NET 개체 형식에 대한 기본 형식 레이아웃과 같은 특수한 기능을 제공하는 데 사용됩니다. 따라서 이러한 파일은 셸이 시작될 때 로드되어야 하는 파일입니다.

이러한 파일은 실행 코드를 포함할 수 있으며 실제로 포함되어 있지만 Microsoft에 의해 디지털 서명되어 있습니다. 파일이 어떤 식으로든 손상되면 서명이 유효하지 않게 되며 이 경우 셸이 시작될 때 파일을 가져오지 않습니다. 이를 통해 파일에 악성 코드를 삽입하려는 맬웨어로부터 파일을 안전하게 보호할 수 있습니다.

물론 실행 정책을 기본값인 Restricted로 유지하면 Windows PowerShell을 시작할 때 사용자가 만든 고유의 Windows PowerShell 프로필 스크립트가 실행되지 않습니다. Windows PowerShell은 기본적으로 프로필 스크립트를 만들지 않지만, 셸이 시작될 때마다 네 개의 특정 위치에서 특정 파일 이름을 검색하여 있으면 실행합니다. Windows PowerShell과 함께 설치되는 설명서에서 프로필 스크립트에 사용되는 폴더 및 파일 이름에 대한 자세한 내용을 볼 수 있습니다. 프로필은 앞으로 설명할 익스플로잇의 주요 수단으로 이용됩니다.

실행 정책 수정

이달의 Cmdlet

Set-AuthenticodeSignature의 동반 Cmdlet은 Get-AuthenticodeSignature입니다. 이 cmdlet은 디지털 서명된 스크립트를 검토하고 서명에 대한 정보를 제공하도록 설계되었습니다. 원하는 파일을 지정하여 이 cmdlet을 실행하면 파일이 서명되었는지 여부와 함께 서명이 손상되지는 않았는지, 파일 서명에 사용된 인증서는 무엇인지 등을 확인할 수 있습니다. 이 cmdlet은 Windows PowerShell 스크립트뿐만 아니라 다음과 같이 서명된 실행 파일에도 작동합니다.

PS C:\Program Files\Microsoft Office\Office12>
Get-AuthenticodeSignature excel.exe | Format-List *

이 명령을 실행하면 실행 파일이 Microsoft Code Signing CA에서 발급한 인증서를 사용하여 Microsoft Corp에서 서명한 것임을 알 수 있습니다.

명령 결과

명령 결과  (더 크게 보려면 이미지를 클릭하십시오.)

기본 상태에서는 Windows PowerShell에서 악성 코드는 물론이고 어떠한 코드도 실행하도록 하기가 매우 어렵습니다. 실행 정책을 수정하기 전까지는 악성 스크립트가 침투할 여지가 없습니다. 다시 말하지만 이 칼럼에서 Windows PowerShell의 보안 허점에 대해 경고할 생각은 없으며, 다만 시스템을 보다 안전하게 유지하기 위한 몇 가지 최선의 방법을 공유하려는 것일 뿐입니다.

가장 낮은 수준의 실행 정책은 Unrestricted이며 이 수준에서는 모든 스크립트가 제한 없이 실행될 수 있습니다. 이 경우 지난 수년간 VBScript와 배치 파일에서 겪었던 문제가 반드시 발생할 것입니다. 셸을 Unrestricted로 설정하면 악성 스크립트가 침투하여 시스템을 손상시키도록 방치하는 것과 같습니다. Unrestricted 설정을 선택하면 스크립트가 침투해 시스템을 엉망으로 만들 것입니다. 따라서 타당한 이유가 없으면 Unrestricted 설정을 선택해서는 안 되며, 설정할 경우 바이러스로 인해 시스템이 엉망이 되었을 때 이를 책임질 준비가 되어 있어야 합니다.

다행히 Unrestricted로 설정되어 있을 때에도 Windows PowerShell은 인터넷에서 다운로드된 스크립트를 감지하여 실행하기 전에 이에 대해 경고 메시지를 표시합니다. 그렇다 하더라도 실행 정책을 Unrestricted로 설정하는 것은 바람직하지 않습니다.

스크립트 서명

스크립트 실행을 허용하는 가장 안전한 실행 정책은 AllSigned입니다. 이름에서 알 수 있듯이 이 설정에서는 신뢰할 수 있는 인증서를 사용하여 생성된 손상되지 않은 디지털 서명이 있는 스크립트만 실행합니다. 스크립트에 서명하려면 Class III 디지털 인증서, 즉 Microsoft Authenticode 코드 서명 인증서가 있어야 합니다. 이러한 인증서는 회사 내부의 PKI(공개 키 인프라)가 있으면 여기에서 구하거나 CyberTrust, Thawte, VeriSign 등의 상용 CA(인증 기관)에서 구입할 수 있습니다.

다음 cmdlet을 사용하면 스크립트 서명에 사용할 수 있는 인증서가 컴퓨터에 설치되어 있는지 여부를 확인할 수 있습니다.

Get-ChildItem CERT: -recurse –codeSigningCert

Windows® 컴퓨터에 인증서를 설치한 후 Set-AuthenticodeSignature cmdlet을 사용하여 디지털 서명을 만들고 적용합니다. 디지털 서명은 스크립트 맨 아래쪽에 암호처럼 보이는 몇 줄의 주석으로 나타납니다. 일부 스크립트 편집기에는 저장 시 자동으로 스크립트에 서명을 하는 등 스크립트 파일에 서명을 적용하는 편리한 옵션이 있습니다.

AllSigned는 프로덕션 환경에서 사용하기에 가장 적합한 실행 정책입니다. 이 설정은 악성 스크립트를 완전히 차단하지는 않지만 악성 스크립트에도 서명을 요구하므로 스크립트 작성자를 추적할 수 있습니다. 스크립트 작성자 추적은 사용 중인 Windows 컴퓨터가 신뢰할 수 있는 CA만 신뢰하도록 구성된 경우에만 실행되는데, 이 내용은 이 칼럼의 주제를 벗어나는 것이므로 자세히 다루지 않겠습니다. 흥미롭게도 WSH(Windows 스크립트 호스트) 5.6 이상도 디지털 서명을 요구하는 이와 유사한 TrustPolicy 설정을 사용하여 구성할 수 있지만 실제로 이 설정을 사용하는 관리자는 거의 보지 못했습니다.

지금까지의 내용을 요약하면 이렇습니다. 실행 정책을 Restricted로 설정하면 악성 스크립트로부터 안전할 수는 있지만 필요한 스크립트까지 실행할 수 없게 됩니다. 실행 정책을 AllSigned로 구성하면 서명된 스크립트 실행만 허용됩니다. 자신이 만든 악성 스크립트에 검증되고 추적 가능한 ID가 적용되는 것을 원하는 악성 스크립트 작성자는 거의 없기 때문에 이러한 스크립트는 매우 안전합니다. 반면 Unrestricted는 매우 위험한 설정으로 이 설정을 사용할 경우 결국 악성 스크립트의 공격을 받게 될 것입니다. Unrestricted 설정이 특별히 보안상 취약하다고는 생각하지 않습니다. 이 설정은 보호되지 않을 뿐이며 이 설정을 사용하는 사용자라면 이 설정을 사용하는 타당한 이유가 있을 것이기 때문입니다.

틈새 공격

위에서 설명하지 않은 실행 정책 설정이 한 가지 더 있습니다. 바로 RemoteSigned입니다. 필자가 생각하기에 이 설정은 Unrestricted보다는 안전하고 AllSigned보다는 번거롭지 않으므로 대부분의 관리자가 사용하는 것 같습니다. RemoteSigned는 로컬 스크립트에는 서명을 요구하지 않습니다. 따라서 로컬 드라이브에 있는 PS1 파일은 서명되어 있지 않아도 실행됩니다. 원격 스크립트는 주로 Internet Explorer®나 Outlook®을 통해 인터넷에서 다운로드되며 이러한 응용 프로그램에서는 다운로드된 파일을 특수 플래그로 표시하여 구분하므로 스크립트에 서명이 있어야만 실행됩니다.

RemoteSigned 설정은 안전하다는 잘못된 생각을 할 수 있습니다. 하지만 특수 플래그 적용 없이 원격 스크립트를 쉽게 다운로드할 수 있습니다. 예를 들어 타사 브라우저에서는 일반적으로 이 플래그를 설정하지 않으며 이는 대부분의 타사 전자 메일 클라이언트에서도 마찬가지입니다. 이 플래그가 없으면 Windows PowerShell은 다운로드된 스크립트를 로컬 스크립트, 즉 서명이 필요하지 않은 스크립트로 처리합니다. 그렇다 하더라도 이것이 보안상 큰 문제가 되지는 않습니다. 스크립트가 실행되려면 실제로 스크립트를 다운로드해야 하고 Windows PowerShell을 연 다음 직접 실행해야 하기 때문입니다. 누군가를 속여서 이러한 단계를 모두 수행하도록 하는 것은 꽤 어려운 일일 뿐만 아니라 대개 네트워크에서 Windows PowerShell을 설치하여 사용하는 유일한 사용자인 관리자라면 더 잘 알아서 이에 대응할 것이기 때문입니다.

그러나 RemoteSigned는 맬웨어가 침투할 수 있는 꽤 많은 "틈새"를 제공합니다. 앞에서 언급한 Windows PowerShell 프로필 스크립트를 생각해 보십시오. 직접 만든 것이든 맬웨어를 통해 생성된 것이든 간에 이러한 스크립트는 Windows PowerShell을 실행할 때마다 실행됩니다. 또한 RemoteSigned 실행 정책에서는 로컬 프로필 스크립트에 서명을 요구하지 않는다는 문제도 있습니다.

다음은 가정해 볼 수 있는 시나리오입니다.

  1. 맬웨어가 시스템에 침투해 셸 프로필 스크립트를 만들거나 기존 프로필 스크립트에 악성 코드를 삽입합니다. 맬웨어는 대개 사용자가 로그온한 사용자 계정에서 실행되므로 프로필 스크립트를 수정할 수 있는 권한을 가집니다.
  2. 사용자는 프로필 스크립트가 새로 생성되었거나 악성 코드를 포함하도록 수정되었다는 사실을 모른 채 Windows PowerShell을 엽니다. 그러면 코드가 실행되고 피해가 발생합니다. 관리자 자격 증명으로 Windows PowerShell을 연다면 그 피해가 더욱 클 것입니다. 그러나 대개 셸을 사용하여 작업을 수행하기 위해서는 관리 권한이 필요하므로 관리자 자격 증명으로 여는 것이 일반적입니다.

이 경우 프로필은 사용자 모르게 악성 코드가 실행될 수 있는 방법을 제공하고 RemoteSigned 실행 정책은 이러한 일이 발생하도록 허용합니다.

프로필 보호

프로필을 보호하는 좋은 방법은 AllSigned 실행 정책을 사용하는 것뿐입니다. AllSigned 설정에서는 프로필 스크립트도 디지털 서명이 되어 있어야 하며 그렇지 않은 경우 Windows PowerShell이 시작될 때 프로필 스크립트를 실행하지 않습니다. 프로필 스크립트에 서명이 있더라도 스크립트가 악의적 의도로 수정되면 디지털 서명이 손상되므로 스크립트가 실행되지 않게 됩니다. 이 경우 Windows PowerShell은 시작될 때 이러한 문제에 대한 알림을 표시합니다. AllSigned는 스크립트의 실행을 허용해야 하는 프로덕션 환경에서 유일하게 믿고 사용할 수 있는 실행 정책입니다.

복잡하고 신뢰성도 떨어지기는 하지만 다른 방법도 있긴 합니다. 바로 Windows PowerShell이 검색하는 네 개의 파일 각각에 대해 빈 프로필 스크립트 파일을 만드는 것입니다. "Profile Editor"와 같은 새 사용자 계정으로 프로필 스크립트 파일을 만들고 Profile Editor 계정만 파일을 수정할 수 있도록 파일의 NTFS 권한을 설정합니다. 다른 계정은 파일에 대해 읽기 전용 권한만 가질 수 있습니다.

이제 프로필을 편집하려는 경우가 아니면 Profile Editor 계정으로 컴퓨터에 로그온하지 않습니다. 이 방법을 사용할 경우 일반 사용자 계정으로는 프로필 스크립트를 수정할 수 없습니다. 일반 계정으로 로그온해 있는 동안 실행되는 맬웨어 또한 스크립트를 수정할 수 없습니다. 그러나 Profile Editor로 로그온해 있는 동안 맬웨어가 실행된다면 어떻게 될까요? 프로필 스크립트를 편집하기 위해 Profile Editor로 로그온해 있는 동안 맬웨어로 인해 프로필이 변경된다면 이를 알아챌 수 있어야 합니다.

앞에서 설명한 것과 같이 강력한 파일 권한으로 제어되는 모든 사용자 프로필 스크립트를 만들어 고유의 보호막을 치는 방법도 있습니다. 이러한 스크립트 내에, Get-AuthenticodeSignature cmdlet을 사용하여 셸이 검색하는 다른 프로필의 디지털 서명을 검토하는 코드를 작성하는 것입니다. 이렇게 하면 다른 스크립트에는 서명을 요구하지 않으면서 프로필 스크립트에만 서명을 요구할 수 있습니다.

그래도 AllSigned 실행 정책이 프로필을 보호하는 데 더 완벽한 방법입니다. 네트워크에 연결된 모든 컴퓨터에는 가능하면 그룹 정책을 통해 Restricted 실행 정책을 적용하는 것이 좋습니다. 이 경우 로컬 설정은 모두 무시되고 스크립트를 허용하지 않도록 새 도메인 컴퓨터가 자동으로 설정됩니다. 스크립트를 허용해야 하는 컴퓨터에는 AllSigned 실행 정책을 설정하는 다른 그룹 정책을 설정해야 합니다. 물론 모든 스크립트에 디지털 서명을 해야 하지만 식별 가능한 작성자가 만든 신뢰할 수 있는 스크립트만 사용자 환경에서 실행된다는 사실을 알고 있다면 더욱 안심할 수 있을 것입니다.

Don Jones는 SAPIEN Technologies의 수석 스크립팅 전문가이자 Windows PowerShell: TFM(SAPIEN Press, 2007)의 공동 저자입니다. 문의 사항이 있으면 www.ScriptingAnswers.com으로 연락하시기 바랍니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..