옆집 계정의 쿼리가 내 데이터베이스에 닿는다: cPanel 권한상승 결함 방어 노트

이미지 출처: The Hacker News

cPanel 서버 한 대에 계정이 400개 올라가 있고, 그중 399개는 서로의 존재조차 모릅니다. 각자 자기 cPanel 로그인으로 들어가 자기 DB만 만지고 나오죠. 그 "각자"라는 경계를 지켜주는 건 물리적인 벽이 아니라 데이터베이스 권한 테이블 몇 줄이라는 게 문제인데, 이번에 알려진 cPanel의 치명적 결함은 정확히 그 몇 줄을 흔드는 종류입니다. 호스팅 고객이 자기 권한 안에서 시작해 결국 데이터베이스 root 권한으로 SQL을 실행할 수 있게 되는 구조라서요.

핵심 요약

• 일반 호스팅 고객 수준의 권한만 있어도 cPanel이 대신 만들어주는 DB 권한 경로를 타고 root 권한 SQL 실행까지 이어질 수 있음
• 공유호스팅 특성상 피해가 한 계정에서 끝나지 않고 같은 서버의 모든 테넌트 데이터로 번지는 게 진짜 위험 지점
• 대응은 cPanel/WHM 최신 빌드 적용 + 자동업데이트 확인, 그리고 mysql 권한 테이블·UDF·원격 3306 노출을 상시 감시하는 쪽으로

1. 이 결함의 성격부터 정리하면

공격자가 되기 위한 준비물이 거의 없다는 게 이 취약점의 무서운 점이에요. 외부에서 인증을 뚫을 필요도 없고, 관리자를 낚을 필요도 없습니다. 정상적으로 돈 내고 만든 호스팅 계정 하나면 출발선에 서 있는 거죠.

• 필요 조건: 해당 서버의 유효한 cPanel 계정(=합법적으로 구매 가능한 것)
• 도달 지점: 데이터베이스 서버의 최상위 권한으로 임의 SQL 실행
• 영향 범위: 취약 계정 하나가 아니라 같은 MySQL/MariaDB 인스턴스를 쓰는 서버 전체
• 등급: 치명적(Critical)로 분류. 공유호스팅 사업자라면 "우리도 해당되나?"를 오늘 확인해야 하는 급

2. 왜 이런 결함이 반복해서 생기는가

cPanel은 편의를 위해 아주 많은 일을 사용자 대신 해줍니다. 그 대행 구조가 이런 취약점의 토양이 되는 것 같은데, 구조를 알아두면 다음에 비슷한 게 터져도 감이 잡히거든요.

• DB 생성·사용자 추가·권한 부여가 전부 root 권한 데몬을 통해 대행됨. 고객은 요청만 하고, 실제 GRANT는 특권 프로세스가 실행함
• phpMyAdmin 자동 로그인처럼 임시 DB 계정을 만들어 붙여주는 흐름이 존재함. 임시 계정의 권한 범위를 만들 때 문자열 조립이 끼어들기 쉬움
• MySQL 권한 문법에서 데이터베이스 이름의 _와 %는 와일드카드로 해석됨. 이름 검증·이스케이프가 한 군데라도 빠지면 "내 DB에만" 주려던 권한이 더 넓은 범위로 나감
• 여기에 GRANT OPTION이나 전역 권한이 실수로 섞이면, 고객이 스스로 자기 권한을 키우는 사다리가 완성됨

공격 재현은 여기까지, 개념 수준으로만 짚습니다. 요지는 "고객 입력이 특권 프로세스의 권한 문장에 영향을 준다"는 한 문장이에요.

3. DB root가 뚫리면 어디까지 무너지나

데이터베이스 최고 권한을 "DB만의 문제"로 보면 대응 수위를 낮게 잡게 되는데, 실제로는 OS까지 이어지는 경우가 흔합니다.

• 서버에 올라온 모든 테넌트의 테이블 열람·변조 가능. 회원 테이블, 주문 테이블, 세션 토큰이 한꺼번에 노출됨
• 워드프레스류 CMS의 wp_users를 건드리면 관리자 계정 탈취로 이어짐. 즉 웹 관리자 권한까지 자동 승계
• 파일 읽기·쓰기 권한이나 사용자 정의 함수(UDF) 적재 경로가 열려 있으면 DB 프로세스 권한으로 명령 실행까지 넘어감
• 백업 덤프, 복제 계정, 크론에 박아둔 자격증명이 함께 털리면서 다른 호스트로 횡적 이동의 발판이 됨

4. 오늘 안에 확인할 것들

패치가 1순위인 건 당연하고, 그 다음으로 제가 개인적으로 꼭 같이 보시길 추천하는 항목들이에요.

• WHM 업데이트 상태 확인 — 자동 업데이트가 꺼져 있거나 오래된 릴리즈 티어에 고정돼 있는 서버가 의외로 많음. 벤더가 배포한 최신 빌드로 올라갔는지 버전 문자열로 직접 확인할 것
• 권한 테이블 감사 — mysql.user, mysql.db에서 전역 권한(Super_priv, File_priv, Grant_priv)이 켜진 계정을 뽑아보기. root와 시스템 계정 외에 낯선 이름이 있으면 그 자체가 사건임
• DB 이름·계정 이름 규칙 — 정상 cPanel 계정은 계정명_DB명 형태를 따름. 이 규칙에서 벗어난 이름이나 와일드카드 문자가 섞인 항목은 별도로 확인
• 원격 접속 노출 — 3306이 인터넷에 열려 있는지, Remote MySQL 허용 호스트에 %가 박혀 있지 않은지 점검
• plugin 디렉터리 — MySQL 플러그인 경로에 최근 생성된 공유 라이브러리가 있는지. UDF를 통한 명령 실행의 흔적이 여기 남음

5. 탐지: 로그에서 무엇을 봐야 하나

이런 유형은 "터진 뒤"에 알게 되는 경우가 많아서, 로그 쪽 준비가 사실상 방어의 절반이라고 봅니다.

• MySQL 감사 플러그인(MariaDB Audit Plugin 등)을 켜두고 GRANT, CREATE USER, SET GLOBAL 같은 권한계 구문을 별도 룰로 분리해 알림 걸기
• 일반 쿼리 로그는 부하가 커서 상시 운영은 부담. 대신 권한 변경 이벤트만 뽑아내는 방향을 권함
• cPanel 접근 로그와 error 로그에서 특정 계정이 짧은 시간에 DB 생성·삭제·권한요청을 반복한 흔적 찾기. 정상 사용자는 그렇게 안 씀
• information_schema나 다른 계정 소유 스키마를 훑는 조회가 갑자기 늘었다면 정찰 단계로 보고 대응
• 파일 무결성 모니터링을 DB 데이터 디렉터리와 플러그인 경로에 걸어두기. 새 .so 파일 생성은 즉시 알림 대상

6. 구조적으로 줄이는 방법

패치는 이번 건을 막지만, 다음 건은 또 옵니다. 그래서 구조를 조금씩 바꿔두는 게 결국 남더라고요.

• 중요 고객 DB는 공유 인스턴스에서 분리하기. 같은 인스턴스에 있는 한 DB root = 전부라는 등식은 깨지지 않음
• DB 프로세스 계정의 파일 권한 최소화, secure_file_priv 설정으로 임의 경로 읽기·쓰기 차단
• 백업은 같은 서버가 아닌 곳에, 그리고 복원 테스트까지 해두기. 데이터 변조형 사고에서 이게 유일한 되돌리기 수단임
• WHM 접근은 IP 제한과 2단계 인증으로. 고객용 cPanel과 관리자용 WHM의 노출면을 분리

공유호스팅은 원래 "적당히 믿고 같이 쓰는" 모델이라, 경계를 지켜주는 소프트웨어가 한 번 삐끗하면 피해가 옆으로 쭉 번지는 구조입니다. 그래서 저는 이런 뉴스가 뜨면 패치보다 먼저 "우리 서버에서 지금 권한이 어떻게 생겼는지"부터 확인하는 습관을 들이려고 하는 편이에요. 패치는 벤더가 주지만, 이미 심어진 흔적은 아무도 대신 찾아주지 않으니 말입니다.

혹시 지금 cPanel 서버 운영하고 계시다면, 위 4번 항목만이라도 오늘 한 번 돌려보시길 권해드려요. 확인하다가 이상한 계정 나오면 댓글로 상황 공유해주세요. 같이 봐요!