vu-ls/crassusWindows 권한 상승 발견 도구로, Process Monitor 부트 로그를 분석하여 DLL 하이재킹, 취약한 ACL 및 기타 권한 상승 경로를 식별하고, 자동으로 프록시 DLL 소스 코드를 생성합니다.
Enable Boot Logging 옵션을 선택합니다.
raw.PML).Ctrl-R을 눌러 기본 Process Monitor 필터를 초기화합니다.boot.PML).Crassus.exe boot.PML을 실행합니다.results.csv의 해당 항목을 조사합니다.Accenture는 Windows에서 DLL 하이재킹 기회를 찾는 Spartacus라는 도구를 만들었습니다. Spartacus를 출발점으로 삼아 Crassus는 단순히 누락된 파일을 찾는 것 이상으로 Windows 권한 상승 발견 기능을 확장했습니다. 권한 있는 프로세스의 파일과 디렉터리에 사용되는 ACL은 목표를 달성하기 위해 누락된 파일을 찾는 것보다 더 많은 것을 찾을 수 있습니다.
...하지만 Crassus는 SysInternals Process Monitor를 활용하고 원시 PML 로그 파일을 파싱한다는 점에서 차별화됩니다. 일반적인 사용법은 Process Monitor를 사용하여 부트 로그를 생성한 다음 Crassus로 파싱하는 것입니다. 또한 취약한 DLL에 대한 모든 관련 내보내기가 포함된 프록시 DLL의 소스 코드를 자동으로 생성합니다.
version.dll을 통한 DLL 하이재킹에 취약한 경우 Crassus는 모든 내보내기가 포함된 version.cpp 및 version.def 파일을 생성합니다. 기본적으로 프록시 DLL은 calc.exe를 실행합니다. Visual Studio 또는 MinGW에서 DLL을 빌드하기 위한 빌드 스크립트가 포함되어 있습니다.Crassus가 작동하는 방식을 요약한 순서도입니다:
Crassus는 Visual Studio 2019 프로젝트로 개발되었습니다. Crassus.exe를 빌드하려면:
Crassus.sln을 엽니다.Ctrl+Shift+B를 누릅니다.다른 사람의 코드가 무엇을 하는지 모르고 실행해도 괜찮다면, Crassus.exe가 이 저장소에 제공됩니다.
Enable Boot Logging 옵션을 선택합니다.
Ctrl-R을 눌러 기본 Process Monitor 필터를 초기화합니다.boot.PML). 로그 파일을 다시 저장하는 이유는 두 가지입니다:
| 인수 | 설명 |
|---|---|
<PMLFILE> | 기존 ProcMon 이벤트 로그 파일의 위치(파일)입니다. |
--verbose | 자세한 출력을 활성화합니다. |
--debug | 디버그 출력을 활성화합니다. |
boot.PML에 저장된 Process Monitor 부트 로그를 파싱합니다. 모든 취약한 경로는 results.csv로 저장되고 모든 프록시 DLL 소스 파일은 stubs 하위 디렉터리에 저장됩니다.
C:\tmp> Crassus.exe boot.PML
아래는 프록시 DLL을 생성할 때 사용되는 템플릿입니다. Crassus가 찾은 DLL의 경우 프록시 DLL에는 %_EXPORTS_%에 지정된 것과 동일한 내보내기 이름과 .def 파일에 지정된 동일한 서수가 포함됩니다. Crassus는 부모 프로세스의 아키텍처를 확인하여 DLL을 32비트 라이브러리로 빌드할지 64비트 라이브러리로 빌드할지 감지하고 그에 따라 %_BUILD_AS_% 필드의 소스 코드에 태그를 지정합니다.
Process Monitor 로그에서 실제 DLL을 찾을 수 없거나 내보내기 이름에 문제가 있는 경우 빌드 스크립트는 내보내기가 지정되지 않은 DLL을 생성하는 방식으로 대체합니다.
#pragma once
//%_BUILD_AS%
#include <windows.h>;
extern "C" {
VOID Payload() {
// 여기에 페이로드를 실행하세요.
WinExec("calc.exe", 1);
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
Payload();
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
#ifdef ADD_EXPORTS
%_EXPORTS_%
#endif
}
OPENSSLDIR 변수 값을 안전하지 않게 사용하는 애플리케이션의 경우, 조작된 openssl.cnf 파일을 해당 위치에 배치할 수 있습니다. 이 예제에서는 소프트웨어가 C:\tmp\calc.dll을 로드합니다. 32비트 프로세스를 대상으로 하려면 32비트 라이브러리를, 64비트 프로세스를 대상으로 하려면 64비트 라이브러리를 사용해야 합니다.
[openssl_init]
# 그러면 OpenSSL 초기화의 일부로 파일 c:\tmp\calc.dll을 로드하려고 시도합니다.
# 빌드 스크립트는 calc.dll 라이브러리를 32비트 또는 64비트 중 어떤 것으로 빌드해야 하는지 감지해야 합니다.
/tmp/calc = asdf
Visual Studio에 포함된 cl.exe 바이너리를 사용하여 컴파일할 수 있습니다. 구체적으로는 다음과 같습니다:
cl.exe /DADD_EXPORTS /D_USRDLL /D_WINDLL <target>.cpp /LD /Fe<target>.dll /link /DEF:<target>.def
라이브러리를 64비트 또는 32비트로 지정하는 것을 포함하여 빌드 프로세스를 자동화하려면:
build.bat 스크립트로 DLL을 빌드합니다..dll로 끝나지 않는 경우 필요에 따라 컴파일된 파일의 이름을 바꿉니다.참고: vcvarsall.bat의 불행한 동작(확실히 버그는 아닙니다)으로 인해 동일한 Visual Studio 개발자 명령 프롬프트 세션에서 build.bat를 두 번 이상 실행하는 데 문제가 발생할 수 있습니다. 오류가 발생하면 창을 닫고 다시 시작하세요.
Visual Studio를 바로 사용할 수 없는 경우 MinGW-w64로 대신 프록시 DLL을 컴파일할 수 있습니다. 예를 들어 Ubuntu 플랫폼에서는 다음 명령으로 MinGW를 설치할 수 있습니다: sudo apt install g++-mingw-w64-x86-64-win32 g++-mingw-w64-i686-win32
# 32비트 DLL 생성
i686-w64-mingw32-g++ -c -o <target>.o <target>.cpp -D ADD_EXPORTS
i686-w64-mingw32-g++ -o <target>.dll <target>.o <target>.def -s -shared -Wl,--subsystem,windows
# 64비트 DLL 생성
x86_64-w64-mingw32-g++ -c -o <target>.o <target>.cpp -D ADD_EXPORTS
x86_64-w64-mingw32-g++ -o <target>.dll <target>.o <target>.def -s -shared -Wl,--subsystem,windows
라이브러리를 64비트 또는 32비트로 지정하는 것을 포함하여 빌드 프로세스를 자동화하려면:
bash ./build.sh를 실행합니다..dll로 끝나지 않는 경우 필요에 따라 컴파일된 파일의 이름을 바꿉니다.VU#114757에 설명된 대로, 이전 버전의 Acronis 소프트웨어에는 여러 권한 상승 취약점이 포함되어 있습니다.
openssl.cnf 배치.C:\ProgramData\Acronis 디렉터리의 부적절한 ACL.Crassus는 이 두 가지 문제를 자동으로 찾습니다.
컴파일된 curl.dll 파일을 C:\ProgramData\Acronis\Agent\var\atp-downloader\ 디렉터리에 심고 새 Process Monitor 부트 로그로 재부팅하면 calc.exe를 실행하는 페이로드가 SYSTEM 권한으로 실행되는 것을 볼 수 있습니다.
취약한 Acronis 소프트웨어는 두 개의 다른 위치에서 openssl.cnf를 로드하려고 시도합니다. 템플릿 openssl.cnf 파일을 c:\jenkins_agent\workspace\tp-openssl-win-vs2013\17\product\out\standard\vs_2013_release\openssl\ssl에 배치하고 32비트 calc.dll 페이로드를 c:\tmp에 배치합니다.
VU#240785에 설명된 대로, 이전 버전의 Atlassian Bitbucket 소프트웨어는 설치 디렉터리의 취약한 ACL로 인해 권한 상승에 취약합니다. C:\Program Files\ 또는 기타 ACL로 제한된 위치 외부에 설치되는 다른 Windows 소프트웨어와 마찬가지로, 소프트웨어 설치 프로그램이 대상 디렉터리에 ACL을 명시적으로 설정해야 합니다.
Crassus는 이 소프트웨어에서 권한 상승을 달성할 수 있는 여러 방법을 찾습니다. 여기에는 다음이 포함됩니다:
Crassus 출력에서 c:\atlassian\bitbucket\7.9.1\elasticsearch\bin\elasticsearch-service-x64.exe가 권한이 있지만 실행 중이므로 단순히 교체할 수 없음을 알 수 있습니다. 그러나 다른 트릭을 사용하여 하이재킹할 수 있습니다. 해당 파일이 있는 디렉터리의 이름을 바꾸고 동일한 이름의 새 디렉터리를 만든 다음 동일한 이름으로 페이로드를 심으면 됩니다.
Process Monitor 부트 로그로 재부팅하면 심어진 elasticsearch-service-x64.exe 파일이 실제 파일 대신 실행되는 것을 Windows 계산기 아이콘을 통해 확인할 수 있습니다.
VU#287178에 설명된 대로, 이전 버전의 McAfee 소프트웨어는 openssl.cnf를 통한 권한 상승에 취약합니다. 살펴보겠습니다:
이 부트 로그에 openssl.cnf에 대한 두 개의 다른 참조가 있는 이유를 확인하려면 results.csv 파일을 참조하십시오:
D:\ 경로에서 openssl.cnf 파일을 로드하는 것은 해당 플랫폼과 시스템에 대한 액세스 가능성에 따라 추가 수동 조사가 필요합니다. 광 디스크를 생성하여 광 드라이브로 확인되는 경로를 참조하는 openssl.cnf 파일을 제공할 수도 있습니다.
SQL Server 2022는 표준 위치가 아닌 곳에 설치되지 않는 한 취약한 ACL로 인해 권한 상승에 명백히 취약하지 않습니다. C:\Program Files 외부의 위치에 설치된 경우 Crassus는 권한 상승 가능성을 여러 개 발견합니다. 권한 있는 구성 요소를 포함하는 대부분의 Windows 애플리케이션은 기본적으로 보안 ACL이 없는 디렉터리에 설치된 경우 이러한 방식으로 악용될 수 있는 것으로 보입니다.
Crassus가 사용자가 심거나 수정할 수 있는 파일의 권한 있는 로드를 보고한다고 해서 반드시 악용 가능한 시나리오라는 의미는 아닙니다. Crassus는 잠재적으로 흥미로운 파일 유형을 찾지만, Process Monitor 로그 파일은 연관된 프로세스가 파일이 존재했을 경우 무엇을 했을지를 직접적으로 나타내지 않습니다. 단순히 프로그램 아이콘을 추출하는 것일 수도 있습니다. Process Monitor에서 파일 작업의 호출 스택을 조사하면 어떤 작업이 수행되었을지에 대한 힌트를 얻을 수 있습니다. 또는 더 쉬운 무차별 대입 경로를 선호한다면 파일을 배치하고 새 Process Monitor 부트 로그로 동작을 조사하면 됩니다. 또한 Crassus가 어떤 내보내기가 있어야 하는지 알기 위해 라이브러리를 찾을 수 없거나, Crassus가 찾은 내보내기가 적절한 DLL 컴파일을 방해하는 방식으로 충돌하는 누락된 라이브러리를 만날 수도 있습니다. 이러한 경우 Crassus는 함수 이름을 내보내지 않는 DLL을 생성하는 방식으로 대체합니다. 대상 애플리케이션이 라이브러리를 로드하는 방식에 따라, 예상되는 함수 이름 및/또는 서수 번호가 없으면 대상 애플리케이션이 라이브러리를 성공적으로 로드하지 못할 수 있습니다. 이 시나리오에서는 프록시 DLL이 어떻게 생겨야 하는지 결정하기 위해 수동 작업이 필요합니다.
Crassus는 관심 있는 경로를 발견하기 위해 권한 있는 파일 작업을 찾습니다. 권한 있는 프로세스와 권한이 없는 프로세스가 모두 경로에 액세스하지만, 권한이 없는 프로세스만이 존재할 수 있는 파일을 실행하는 시나리오를 만날 수 있습니다. 또는 부모 프로세스가 권한으로 실행되지만 자식 프로세스를 명시적으로 낮은 권한으로 생성하는 시나리오를 만날 수도 있습니다.
특히 소프트웨어를 처음 설치하거나 업데이트를 설치할 때, Process Monitor는 악용 가능해 보이지만 시스템이 부팅될 때마다 발생하지는 않는 파일 작업을 기록할 수 있습니다. 이러한 작업을 악용하는 것은 그러한 이벤트가 발생한 후 첫 번째 재부팅에서 가능할 수 있습니다. 이러한 극단적인 경우를 피하려면 후속 부트 로그에 동일한 파일 작업이 후속 재부팅에서도 보고되는지 확인하십시오.
오타, 버그 또는 새로운 기능에 관계없이 Crassus는 다음 사항에 동의하는 한 기여에 매우 개방적입니다: