마이크로소프트 SQL 서버의 보안을 검토해야 하는 이유

마이크로소프트(MS)의 SQL 서버는 윈도우와 긴밀하게 통합되어 있기 때문에 공격자들이 자주 표적으로 삼는 DBMS이다.
 

데이터베이스 서버에 대한 무차별 대입 자격 증명 추측 공격(Brute-force credential guessing attacks)이 증가하면서, MS의 SQL 서버에 대한 공격 시도가 더 늘어나고 있다. 공격자는 마이크로소프트의 데이터베이스 서버가 제공하는 다양한 확장성 기능을 활용하는데, 기타 윈도우 구성 요소 및 기능과 통합하여 권한을 높이고 기본 서버를 완전히 제어하고 있다. 

지난 주 보안 기업 트러스트웨이브(Trustwave)은 전 세계에 분산된 센서 네트워크인 허니팟 프로젝트(global honeypot project)에서 4개월 간 수집한 데이터를 발표했다. 허니팟 프로젝트는 각 나라에 배치한 센서를 통해 취약 시스템 모방 및 공격 정보 모으는 역할을 한다. 이러한 실험에서 허니팟은 디폴트 포트인 MS SQL 서버(MSSQL), MySQL, 레디스(Redis), 몽고DB(MongoDB), 포스트그레SQL(PostgreSQL), 오라클 DB(Oracle DB), IBM DB2, 카산드라(Cassandra) 및 카우치베이스(Couchbase)에서 실행되는 인기 있는 데이터베이스 관리 시스템(DBMS)으로 작동하도록 구성되었다.  

트러스트웨이브는 “MS SQL 관련 공격 활동이 다른 데이터베이스보다 훨씬 더 높은 상황이다. 공격 시도 비율은 앞도적으로 MS SQL이 높아서(>93%) 다른 DBMS와의 비교가 어려운 수준”이라고 설명했다. 

트러스트웨이브에 따르면, 공격은 일정 간격을 두고 계속 되풀이되고 그 횟수가 급격히 증가했다. MSSQL 무차별 대입 공격의 강도는 다른 데이터베이스 공격에 비해 압도적으로 강력했다. 예를 들어, MSSQL 서버 다음으로 많은 공격이 일어나는 MySQL 및 레디스는 로그인 시도가 많았을 경우 그 횟수가 약 15만 건이나 MSSQL은 약 300만 번 이상의 로그인 시도가 일어나는 경우가 있었다. 

또 다른 흥미로운 사실은 트러스트웨이브가 여러 국가의 정보를 취합한 결과, 공격이 유난히 많은 지역이 있다는 것이다. 예를 들어, 수집된 데이터를 기준으로 가장 많은 표적의 대상이 된 국가는 영국이었다. 그 다음은 중국이다. 중국이 인터넷에 노출된 MSSQL 서버의 수가 훨씬 더 많음에도 영국보다 순위가 낮았다. 미국은 우크라이나, 러시아, 폴란드에 이어 6위였다. 

다만 또다른 검색 엔진 쇼단(Shodan)에 따르면, 45만 개 이상의 MSSQL 인스턴스가 인터넷에 있으며, 그 중 13만 3,000개 이상의 인스턴스가 중국에 위치하고 있다. 이런 데이터를 고려했을 때 향후 중국이 공격 횟수에서 1위를 차지할 수 있을 것으로 보인다. 

공격자가 MSSQL을 표적으로 삼는 이유는 무엇일까?
MS SQL은 분명 가장 널리 사용되는 데이터베이스 서버 중 하나이나, 윈도우 서버에서만 사용된다. 따라서 가장 인기가 있거나 널리 배포된 적은 없으며, MySQL, 오라클 및 포스트그레SQL가 늘 인기 순위 1위를 차지한다. 그렇다면 MSSQL 서버가 공격자에게 더욱 흥미로운 표적이 되고 있는 이유는 무엇일까? 

누군가는 이미 윈도우가 리눅스보다 더 인기 있는 표적이기에, 많은 공격자가 윈도우 전용 멀웨어 도구를 갖추고 있을 가능성이 높다고 주장한다. 특히 데이터베이스 서버가 기본 서버를 손상시키는 진입점일 경우, 더 많은 공격자가 MSSQL을 표적으로 삼고 있다는 것이다. 일리 있는 주장일 수도 있다. 동시에 트러스트웨이브의 분석이 보여주듯이 MSSQL는 윈도우 서버와 연계된 강력한 통합할 수 있는 부분이 영향을 줄 수 있다. 
 
공격자가 MSSQL 액세스를 악용하는 방법
트러스트웨이브 연구진은 최근 보고서를 통해 공격자가 취약한 자격 증명을 통해 MSSQL 서버에 접근한 후 사용하는 작업과 침입 후 기법에 대해 공개한 적 있다. 첫째, 무차별 대응 공격 시도에서 가장 일반적인 표적이 되는 계정의 이름은 ‘sa’였다. 이는 ‘서버 인증(server authentication)’을 나타내는 특수 슈퍼 사용자 계정으로, 대부분의 시나리오에서 일반적으로 비활성화된다.
 
마이크로소프트는 공식 지침서를 통해 “이 sa 계정은 잘 알려진 SQL 서버 계정으로, 종종 악의적인 사용자의 표적이 된다. 애플리케이션이 요구하지 않는 이상 이 계정을 활성화하면 안 된다. sa로그인에는 강력한 암호를 사용하는 게 중요하다”라고 제시하고 있다. 

트러스트웨이브 보고서에 따르면, 공격자가 MSSQL 계정에 접근한 후 발견되는 두 가지 페이로드 전송 방법이 있다. 두 방법 모두 플랫폼에 대한 깊은 지식을 보여주며 서버가 다른 기술을 통합할 수 있도록 하는 흥미로운 기능을 사용한다. 그 중 하나가 닷넷 프레임워크 공용 언어 런타임 통합(.NET Framework Common Language Runtime Integration)으로, MSSQL 사용자는 이를 통해 데이터베이스 엔진 내에서 직접 닷넷 코드를 실행해 SQL 서버 기능을 확장할 수 있다. 

트러스트웨이브 연구진은 “봇이 인증되면 SQL 스크립트를 실행해 백도어 CLR(Common Language Runtime) 어셈블리를 설치할 수 있도록 MSSQL 구성을 변경한다”라고 설명했다. 

먼저, 공격자는 어셈블리 코드가 호스팅 될 데이터베이스에 트러스트워디(TRUSTWORTHY) 속성을 설정한 다음 악성 코드가 실행될 수 있도록 CLR 기능을 활성화한다. 그런 다음 이들은 악성 CLR 코드를 사용해 명령줄(cmd.exe)을 통해 기본 윈도우 서버에 4개의 악성 실행 파일을 다운로드 및 실행한다. 

두번째 페이로드 전송 기술은 사용자가 자동화 객체(Automation objects)를 생성할 수 있도록 하는 MSSQL 서버에 있는 객체 연결 및 삽입(Object Linking and Embedding, OLE) 자동화 절차의 악용하는 것이다. 

트러스트웨이브 연구진은 “사용자는 T-SQL 코드에서 자동화 객체를 생성 및 조작할 수 있다. 이는 SQL 서버와 소프트웨어 구성 요소를 위한 바이너리 인터페이스 표준이자 컴포넌트 오브젝트 모델(Component Object Model, COM)이라고 불리는 윈도우 시스템의 다른 구성 요소와의 통합을 가능하게 한다”라고 언급했다.  

공격자는 권한 상승 공격에 대비해 OLE 자동화 프로시저(OLE Automation Procedures)와 기타 서버 구성 옵션을 활성화한 다음 기존 기능을 사용해 다양한 레지스트리 키를 삭제, 추가 및 수정하기도 한다. 그런 다음 이들은 OLE 객체를 생성하기 시작한다. 

트러스트웨이브 연구진은 “익스플로잇(Exploits)은 마이크로소프트의 OLE DB 서비스 컴포넌트(OLE DB Service Component)에서 제공하는 클래스 식별자(CLSID {00000566-0000-0010-8000-00AA006D2EA4})로 참조되는 ‘IDataInitialize’를 활용해 연결을 생성 및 관리한다. 그런 다음 이 봇은 파일 F**kGothin.inf을 만들고 16진수 바이너리 콘텐츠를 작성한다. F**kGothin.inf는 텍스트 파일이다. 이러한 유형의 파일은 소프트웨어, 드라이버 혹은 하드웨어 구성 요소를 설치, 구성 및 관리하는 방법에 대한 정보를 시스템에 제공하는 데 사용된다”고 설명했다. 

다양한 파일을 위한 설명자를 변경하고 권한 상승 프로세스를 완료한 후, 이러한 악성 프로세스는 바이너리 혹은 데이터를 작성할 수 있도록 하는 마이크로소프트의 액티브X 데이터 오브젝트(ActiveX Data Objects, ADO)인 ‘ADODB.Stream’를 사용해 객체를 생성하기 시작한다. 이는 포테이토(BadPotato, JuicyPotato, SweetPotato, EFSPotato) 혹은 PoC(CVE-2018-8639, CVE-2019-1458)와 같은 권한 상승 도구를 포함해 여러 실행 파일을 디스크에 작성하는 데 사용된다. 최종 목표는 암호 화폐 채굴 도구와 함께 다양한 트로이 목마 프로그램을 시스템에 배포하는 것이다. 

트러스트웨이브 연구진은 “OLE 자동화 및 CLR 어셈블리는 상당히 강력한 기능이므로 매우 위험하고, OLE 자동화 및 CLR 어셈블리를 사용하지 않는 경우 비활성화해야 한다. 데이터베이스 내의 불필요한 기능을 비활성화할 경우, 공격 표면을 줄일 수 있으나, 앞서 언급한 바 있듯이 공격 표면을 제거할 수는 없다”라고 지적했다.  

비활성화된 경우에도 공격자는 데이터베이스 서버에 대한 관리 권한이 있는 경우 이러한 기능을 재활성화 할 수 있다. 따라서 ‘sa’와 같은 디폴트 관리 계정을 변경하고 강력한 암호 정책을 사용하는 게 상당히 중요하다. 
ciokr@idg.co.kr