CVE-2019-1068: SQL Server 내부 함수 처리가 무너지면 서비스 계정까지 간다

이미지 출처: CISA KEV

2019년 7월 패치 화요일은 실제로 악용되고 있던 윈도우 제로데이 두 건 때문에 시끄러웠다. 그 소란 속에서 조용히 목록 한 줄을 차지하고 지나간 것이 CVE-2019-1068, Microsoft SQL Server의 원격 코드 실행 취약점임. 제로데이가 아니었고 공개 익스플로잇도 돌지 않았으니 대부분의 조직이 "다음 정기 점검 때"로 미뤘고, 그렇게 미뤄진 DB 서버가 몇 년 뒤 내부 침투 단계에서 발목을 잡는 경우를 심심찮게 보게 됨.

핵심 요약

• SQL Server가 내부 함수 처리를 잘못하는 지점에서 발생하는 원격 코드 실행 결함으로, 조작된 쿼리 하나가 SQL Server 데이터베이스 엔진 서비스 계정 권한의 코드 실행으로 이어짐
• "인증된 사용자만 가능"이라는 조건은 안심의 근거가 못 됨. 웹 애플리케이션의 SQL 인젝션이 그 인증을 대신 제공해 주기 때문임
• 방어의 핵심은 패치 + 서비스 계정 최소권한 + sqlservr.exe의 자식 프로세스 감시. 이 셋이 갖춰지면 미패치 상태에서도 피해 반경이 크게 줄어듦

결함의 성격: 데이터가 아니라 코드가 넘어간다

공개된 설명은 짧음. SQL Server가 내부 함수(internal function) 처리 과정을 올바르게 다루지 못할 때 발생하며, 공격자가 영향받는 인스턴스에 특수하게 조작된 쿼리를 제출하면 코드 실행이 가능하다는 것. 짧은 문장이지만 방어자 입장에서 뜯어볼 지점이 세 개 있음.

• 진입점이 '쿼리'임 — 별도 프로토콜 취약점이나 파일 업로드가 필요 없음. DB가 평소에 정상적으로 받아들이는 입력 경로 그대로 들어옴. 즉 네트워크 계층의 시그니처 탐지로 걸러내기가 대단히 어려움.
• 실행 컨텍스트가 서비스 계정임 — SQL 로그인 권한이 아니라 sqlservr.exe를 구동하는 OS 계정 권한으로 코드가 돌아감. 여기서 조직 간 피해 격차가 극단적으로 벌어짐.
• 인증이 선행 조건임 — 익명 공격은 불가. 다만 이 조건이 실무에서 얼마나 헐거운지는 아래에서 따로 다룸.

영향 범위는 2014부터 2017까지의 지원 버전대에 걸쳐 있었고, 서비스 팩과 누적 업데이트 라인별로 각각 수정본이 배포됨. 자기 인스턴스가 해당하는지는 SELECT @@VERSION으로 빌드 번호를 뽑아 해당 라인의 수정 빌드와 비교하는 게 가장 확실함.

"인증된 계정이 있어야 하잖아요"라는 말의 함정

이 CVE를 보고받으면 열에 아홉은 이렇게 반응함. 내부망이고, 로그인 계정도 앱 서비스 계정 하나뿐이고, 그 계정 비밀번호는 안전하다는 논리. 과연 그럴까?

• SQL 인젝션이 곧 인증 우회임. 취약한 웹 애플리케이션은 이미 인증된 세션으로 임의 쿼리를 실어 보내주는 대리인 역할을 함. 공격자는 DB 자격증명을 몰라도 됨. 이 구조에서 CVE-2019-1068은 "SQLi로 데이터 유출"을 "SQLi로 서버 장악"으로 승격시킴.
• 저권한 계정이면 충분함. public 수준의 읽기 전용 로그인도 쿼리는 던질 수 있음. 권한 분리를 잘해 놨다는 사실이 이 결함 앞에서는 방어가 되지 않음.
• 내부망 전제도 위험함. 초기 침투에 성공한 공격자가 횡적 이동 중에 만나는 DB 서버는 대개 도메인 자산의 중심임. 서비스 계정이 도메인 계정이면 여기서 권한 상승 사슬이 시작됨.

탐지: 로그를 어디서 봐야 하는가

페이로드 자체를 잡는 건 현실적이지 않음. 대신 익스플로잇이 남기는 부수 효과를 노리는 게 훨씬 성공률이 높음. 개인적으로는 아래 순서대로 깔아두길 추천함.

• 프로세스 계보 감시(가장 가성비 좋음). Sysmon 이벤트 ID 1에서 부모 프로세스가 sqlservr.exe인 cmd.exe, powershell.exe, wmic.exe, rundll32.exe를 탐지 규칙으로 걸어둘 것. 정상 운영 환경에서 이 조합은 거의 발생하지 않으므로 오탐이 적고 신호가 선명함.
• SQL Server ERRORLOG의 예외 흔적. 메모리 손상형 결함은 성공보다 실패가 많음. 액세스 위반(0xC0000005), 스택 덤프 생성, SqlDumpExceptionHandler 기록, 예기치 않은 엔진 재시작이 짧은 간격으로 반복된다면 누군가 오프셋을 맞추고 있는 중일 가능성을 의심해야 함.
• 구성 변경 감사. sp_configure를 통한 xp_cmdshell, CLR, Ole Automation Procedures 활성화는 공격자가 발판을 굳히는 전형적인 다음 수순임. SQL Server Audit이나 확장 이벤트(Extended Events)로 반드시 남길 것.
• 세션 메타데이터의 이질감. sys.dm_exec_sessions의 program_name, host_name, 접속 IP를 평소 값과 대조해 보면 sqlcmd나 관리 도구 문자열이 애플리케이션 서버가 아닌 곳에서 튀어나오는 순간이 보임.
• 아웃바운드 트래픽. DB 서버는 원래 밖으로 나갈 일이 거의 없는 장비임. DB에서 인터넷으로 향하는 신규 연결은 그 자체로 조사 대상이 되어야 함.

완화: 패치 이전에 피해 반경부터 줄이기

패치가 1순위인 건 당연하지만, 24시간 무중단 DB는 재기동 일정을 잡는 데만 몇 주가 걸리기도 함. 그 기간을 버티는 방법이 필요함.

• 서비스 계정을 LocalSystem에서 내릴 것. 이 하나가 사고의 등급을 바꿈. 전용 저권한 도메인 계정이나 gMSA로 전환하고, 필요한 로컬 정책 권한만 최소로 부여함. 서비스 계정이 로컬 관리자가 아니면 RCE가 성공해도 공격자는 DB 프로세스 권한이라는 좁은 상자 안에 남게 됨.
• 애플리케이션 DB 계정에서 sysadmin·db_owner를 회수할 것. 취약점 자체를 막지는 못해도 이후 확장 저장 프로시저 활성화 같은 후속 동작을 차단함.
• SQL 인젝션 점검을 병행할 것. 앞서 말했듯 이 CVE의 선행 조건을 실질적으로 공급하는 통로임. 파라미터 바인딩과 저장 프로시저 사용 여부를 코드 레벨에서 다시 확인하는 게 결국 가장 근본적인 대응임.
• 노출면 정리. 1433/TCP와 1434/UDP가 인터넷이나 사용자 대역에서 직접 닿는 구조라면 방화벽과 세그먼트부터 손봐야 함. DB는 애플리케이션 서버에서만 접근 가능해야 함.
• 지원 종료 버전 정리. 수정본이 나오지 않는 구버전이 남아 있다면 그건 완화가 아니라 이전 계획의 영역임.

마무리하며

CVE-2019-1068을 지금 다시 꺼내 보는 이유는 이 결함이 특별히 화려해서가 아님. 오히려 평범한 CVE 하나가 조직의 구조적 약점을 그대로 증폭시키는 방식을 보여주기 때문임. 서비스 계정을 편하다고 LocalSystem으로 둔 선택, 앱 계정에 넉넉하게 준 권한, 미뤄둔 SQLi 점검 — 이런 것들이 평소엔 아무 일도 일으키지 않다가 취약점 하나를 만나면 한꺼번에 청구서로 돌아옴.

오늘 당장 하실 수 있는 건 두 가지예요. 하나는 SELECT @@VERSION으로 빌드 확인하기, 다른 하나는 SQL Server 서비스가 어떤 계정으로 돌고 있는지 서비스 속성 창 열어보기. 둘 다 5분이면 끝나는데, 결과에 따라 다음에 할 일이 완전히 달라질 겁니다. 확인해 보시고 예상 밖의 계정이 나왔다면 댓글로 공유해 주세요. 비슷한 상황 정리해 본 경험이 있으니 같이 방법 찾아보아요!