PowerShell 코드가 제한된 언어 모드를 우회하는 빈틈을 방지하는 방법

안내서: 제한된 언어 모드는 PowerShell 공격을 완화하는 방식으로 서명하지 않은 코드의 실행을 막을 수 있습니다.
소개
제한된 언어 모드는 PowerShell 공격을 완화하는 방식으로 서명되지 않은 코드의 실행을 막을 수 있습니다.Device Guard나 AppLocker가 강제 모드에 있을 때 가장 실제적이고 효과적인 강제 보안 조치입니다. 정책이 허용하지 않은 스크립트나 모듈이 제한된 언어 모드에 있기 때문에 공격자가 서명하지 않은 코드를 실행하는 것을 심각하게 제한합니다.언어 제한 모드를 통해 Add-Type 호출을 제한합니다.Add-Type을 제한하는 것은 실행 공간에 임의의 C# 코드를 컴파일하고 불러올 수 있다는 것을 고려한 것이 분명하다.
그러나 정책이 허용하는 PowerShell 코드는 "Full Language"모드에서 실행되며 Add-Type을 실행할 수 있습니다.이렇게 하면 마이크로소프트가 서명한 PowerShell 코드는 Add-Type을 호출할 수 있다.안 믿어?아래의 명령을 실행하면 내가 정확하다는 것을 알게 될 것이다.
활용단어참조
다음 PowerShell 모듈 코드가 Microsoft에서 서명한 것으로 간주됩니다.

ls C:* -Recurse -Include '*.ps1', '*.psm1' |
 Select-String -Pattern 'Add-Type' |
 Sort Path -Unique |
 % { Get-AuthenticodeSignature -FilePath $_.Path } |
 ? { $_.SignerCertificate.Subject -match 'Microsoft' }

그러면 제한된 언어 모드에서의Add-Type 입력에 영향을 줄 수 있는 것은 무엇입니까?
우리 함께 생각해 봅시다.
1. Add-Type은 형식 정의로 전역 변수에 전달됩니다.그것은 전체적인 것이기 때문에, 우리와 공격자를 포함하여 누구든지 방문할 수 있다.
문제는 서명된 코드가 Add-Type을 호출하기 전에 전역 변수를 정의했기 때문에 사용자 정의 악성 C#코드를 사용하면 합법적인 코드로 덮어쓰일 수 있다는 것이다.
3. 변수를 Set-Variable cmdlet으로 설정해서 읽기만 할 수 있는지 아세요?내가 지금 무슨 생각을 하는지 알겠지?
무기화
좋습니다. 제한된 언어 모드에서 코드를 Add-Type에 주입하기 위해 공격자는 악성코드를 읽기 전용 변수로 정의하여 서명을 거부하는 전역 "Source"변수를 설정해야 합니다.이것은 무기화된 개념의 증명이다.

  $Global:Source = @'
  public class Test {
    public static string PrintString(string inputString) {
      return inputString;
    }
  }'@
Add-Type -TypeDefinition $Global:Source

Add-Type 주입 결함을 간략하게 설명합니다.제한된 언어 모드의 한 가지 제한은 네가 비 화이트리스트 종류를 호출할 수 없다는 것이다.NET 메서드, 하지만 두 가지 예외가 있습니다. 속성(getter 메서드)과 ToString 메서드입니다.위의 PoC에서 저는 정적 ToString을 실현하는 방법을 선택했습니다. 왜냐하면 ToString은 매개 변수를 전달할 수 있기 때문입니다. (getter는 안 됩니다.)나의 종류도 정적이다. 왜냐하면.NET 클래스의 화이트리스트는 New-Object 실례화 객체에만 적용됩니다.
그렇다면 위의 빈틈 코드는 실제와 부합되지 않습니까?너는 이렇게 생각할 수 있지만, Microsoft.PowerShell.ODataUtils 모듈의 Microsoft.PowerShell.OData Utils에도 이 구멍이 있어요.마이크로소프트는 CVE-2017-0215, CVE-2017-0216, CVE-2017-0219에서 그것을 복구했다.솔직히 나는 그다지 기억하지 못한다.Matt Nelson과 나는 이 주입 버그들을 보고했다.
공격 완화
비록 마이크로소프트가 이 빈틈을 해결하도록 추진하고 있지만, 우리는 무엇을 할 수 있습니까?
UMCI가 바이너리를 우회하는 데 유효한 블랙리스트 규칙은 파일 이름 규칙으로 PE 파일의 버전 정보 자원의 원시 파일 이름을 바탕으로 프로그램의 실행을 막을 수 있다.PowerShell은 PE 파일이 아니라 텍스트 파일이므로 파일 이름 규칙이 적용되지 않습니다.하지만 해시 규칙을 사용하면 빈틈이 있는 스크립트를 강제로 막을 수 있다.Okay... 같은 스크립트에 빈틈이 한 군데가 아니라면?지금까지 해시 하나만 막았어.너는 이 문제에 주의하기 시작했니?이전의 모든 빈틈이 있는 버전의 스크립트를 효과적으로 막기 위해서는 빈틈이 있는 버전의 해시를 알아야 한다.마이크로소프트는 문제를 의식하고 이전에 발표된 모든 빈틈 있는 스크립트를 스캔하기 위해 최선을 다했으며, 해시를 수집하여 그들을 블랙리스트에 통합시켰다.
그들의 해시를 통해 모든 버전의 빈틈이 있는 스크립트를 막는 것은 어느 정도 도전적이지만 공격을 어느 정도 막을 수 있다.PowerShell 5의 실행만 허용하고 스크립트블록 로그 기록을 열어야 하는 이유입니다.리홈즈에는 이전 버전의 PowerShell을 효과적으로 막는 방법에 대한 박문이 있다.
다른 방식은 시스템의 대부분 스크립트와 바이너리가catalog와Authenticode에서 서명하는 것이다.Catalog 서명은 스크립트에 내장된Authenticode 서명을 의미하는 것이 아니라 마이크로소프트가 서명한 catalog 파일에 저장됩니다.따라서 마이크로소프트가 업데이트를 할 때, 오래된 버전의 해시는 기한이 지나면 더 이상 서명되지 않을 것이다.이제 공격자도 오래된 서명된catalog 파일을catalog 저장소에 삽입할 수 있습니다.이 문제에 관해서는 Device Guard UMCI를 우회할 수 있는 많은 방법이 있습니다.빈틈 스크립트를 검색하는 연구원으로서, 우선 Authenticode 서명이 내장된 빈틈 스크립트를 찾아야 한다.Matt Nelson은 이런 바이패스 스크립트가 존재한다고 말했다.
보고
만약 당신이 우회하는 것을 찾았다면, 그것을 상부에 보고해 주십시오[email protected], 당신은 CVE를 얻을 수 있습니다.PowerShell 팀은 주입 결함을 적극적으로 해결하지만, 코드 실행에 영향을 주는 방식도 주동적으로 해결합니다.
총결산
제한된 언어 모드가 서명하지 않은 코드의 실행을 효과적으로 막을 수 있지만, PowerShell과 서명한 모듈이나 스크립트는 여전히 공격면이 많다.나는 모든 사람들이 더 많은 주입 결함을 찾아 그들에게 보고하고 정부의 MSRC를 통해 영예를 얻으며 PowerShell 생태를 더욱 안전하게 하도록 격려한다.또한 PowerShell의 코드 작성자가 직접 검토하기를 바랍니다.
현재 나는 모든 내용을 설명했지만 디자인 결함으로 경쟁 조건을 이용할 수 있기 때문에Add-Type을 호출하는 데 아직도 주입된 빈틈이 있다.나는 이 문제들을 계속 논술할 수 있기를 희망하며, 마이크로소프트가 이 기초 문제를 해결할 것을 고려할 것이라고 희망한다.