PHP 취약점 대처 가이드: 확인부터 PHP 탈피까지

PHP 취약점, 무엇부터 해야 할까?

확인, 업데이트, 임시 조치, 침입 점검. 이 네 단계를 차례로 하면 됩니다. 네 나라의 자료는 말투는 달라도 같은 순서를 권합니다.

동네에 도둑이 돈다는 소식을 들었다고 해 봅시다. 먼저 우리 집 자물쇠가 어떤 것인지 봅니다. 약한 자물쇠는 새것으로 바꿉니다. 바꾸기 전까지는 빗장을 겁니다. 그리고 혹시 누가 이미 다녀가지 않았는지 집 안을 둘러봅니다. PHP 대처도 이와 똑같습니다.

1. 확인: 웹이 실제로 쓰는 PHP 버전과, 누가 서버를 관리하는지
2. 업데이트: 수정판(8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 이상)으로 올리고 반드시 재시작
3. 임시 조치: 바로 못 올리면 PHP 설정 파일(php.ini)과 웹 방화벽(WAF)으로 시간을 번다
4. 침입 점검: 고치기 전에 들어온 흔적이 없는지 보고, 비밀번호까지 바꾼다
5. 근본 해결: 회사 소개 사이트라면 PHP를 쓰지 않는 형태도 검토

공유 렌탈 서버(서버 한 대를 여러 회사가 나눠 쓰는 임대 서버)라면, 2단계는 많은 서버 회사가 대신 처리했다고 공지했습니다. 세입자가 건물 보일러를 직접 고치지 않는 것과 같습니다. 우리 서버 회사의 공지를 확인하는 것이 첫걸음입니다.

위에서부터 하나씩 하면 됩니다.

고치는 길은 업데이트 하나뿐입니다. 나머지는 모두 시간을 버는 일입니다.

PHP 공식 발표와 한국인터넷진흥원(KISA)도 업데이트만이 완전한 해결책이고, 설정 변경은 완전한 방어가 아니라고 밝힙니다.^1·2

진석 대표의 정리순서가 있으면 허둥댈 일이 없습니다. 다만 자물쇠를 바꾸는 2단계를 건너뛰고, 빗장을 거는 3단계에서 멈추면 안 됩니다.

1단계: 우리 사이트의 '진짜' PHP 버전은 어떻게 확인할까?

웹사이트를 실제로 돌리는 PHP를 봐야 합니다. 서버에서 php -v로 보이는 것은 명령어용 PHP라서, 홈페이지가 쓰는 PHP-FPM(홈페이지 요청을 받아 PHP를 실행하는 프로그램)이나 웹서버의 PHP와 다를 수 있습니다.^2·3

한 집에 시계가 여럿 있으면, 거실 시계가 맞다고 부엌 시계까지 맞는 것은 아닙니다. 한국의 보안 기업 Xint는 확인용 PHP 파일을 남이 짐작하기 어려운 이름으로 올려 웹에서 열어 보고, 확인한 뒤 바로 지우라고 안내합니다.⁴

또 하나의 함정은 버전 번호입니다. 번호는 겉에 붙은 이름표일 뿐, 속을 다 말해 주지는 않습니다. Ubuntu나 Red Hat 같은 배포판(서버용 운영체제를 묶어 나눠 주는 곳)은 번호는 그대로 두고 수정만 넣기 때문에, 번호가 낮아 보여도 이미 고쳐졌을 수 있습니다. 이때는 패키지의 변경 기록(changelog)에 CVE 번호(취약점마다 붙는 세계 공통 번호)가 있는지로 확인합니다.^2·5·6

진석 대표의 정리번호 하나로 "괜찮다", "위험하다"를 정하지 마세요. 먼저 물을 것은 "누가 우리 서버를 돌보는가"입니다. 그 답이 나오면 나머지는 쉬워집니다.

2단계: 업데이트했는데, 왜 재시작까지 해야 할까?

이미 돌아가고 있는 PHP 프로그램(워커)은 옛 코드를 그대로 쥐고 있기 때문입니다.⁶

약을 사 두기만 해서는 병이 낫지 않습니다. 먹어야 낫습니다. 새 PHP를 깔아 두어도, 지금 일하고 있는 워커는 옛 PHP로 계속 일합니다. 재시작은 그 워커들을 새 PHP로 바꿔 세우는 일입니다.

지니언스는 Debian·Ubuntu는 sudo apt update && sudo apt upgrade, RHEL 계열은 sudo dnf update 'php*'로 올린 뒤(이 명령은 PHP 말고 다른 프로그램도 함께 올립니다) PHP-FPM·Apache를 반드시 재시작하라고 안내합니다.⁹ 컨테이너(프로그램을 상자째 포장해 돌리는 방식)는 상자 안을 고칠 수 없으니, 새 PHP 이미지로 다시 만들어 배포해야 합니다.^2·10

8.1 이하는 공식 수정판이 없습니다. 지원되는 버전으로 바꾸거나, 배포판이 옛 번호에 수정만 넣어 주는 판(백포트)을 써야 합니다.^1·2

공유 렌탈 서버는 회사가 대신 처리한 경우가 많습니다. 예를 들어 카페24는 10월 21일 밤부터 PHP 8.2 이상 서비스를 같은 계열의 최신 버전으로 순차 업데이트한다고 공지했습니다.¹¹ 지원이 끝난 옛 버전을 쓰고 있다면 서버 관리 화면에서 버전을 바꿔야 합니다. Xserver는 서버 패널의 'PHP Ver. 전환' 메뉴에서 도메인별로 바꿀 수 있습니다.¹²

진석 대표의 정리"올렸다"와 "끝났다"는 다른 말입니다. 재시작하고, 웹에서 다시 확인해야 비로소 끝입니다.

3단계: 바로 올릴 수 없을 때는 무엇을 할까?

PHP 설정 파일(php.ini)이나 PHP-FPM 설정에 임시 설정을 넣고 워커를 재시작합니다. 다만 완전한 방어는 아닙니다.^1·2

비 오는 밤, 깨진 유리창에 비닐을 덧대는 일과 같습니다. 오늘 밤 비는 막아 주지만, 유리를 갈아 끼운 것은 아닙니다.

WAF(웹 방화벽)는 수상한 요청을 문 앞에서 걸러 내는 경비원입니다. 이것도 시간을 벌어 줍니다. Cloudflare는 무료 플랜을 포함해 전 고객에게 방어 규칙을 적용했습니다. 다만 업로드 진행 기능의 이름(session.upload_progress.name)을 바꾼 사이트는 이 규칙으로 막히지 않는다고 밝혔습니다.¹³

PLURA는 업로드가 필요 없는 주소로 오는 파일 전송 형식(multipart) 요청을 막으라고 권합니다.¹⁴ 그래도 미국 CISA는 WAF를 임시 보호 수단으로만 보고, 패치할 수 없으면 오프라인으로 돌리라고까지 권합니다.¹⁵ 경비원이 있어도 문은 고쳐야 합니다.

진석 대표의 정리임시 조치를 넣은 날, "언제까지, 누가 업데이트할지"도 함께 정하세요. 끝나는 날이 정해져 있어야 '임시'입니다.

4단계: 이미 들어왔는지는 어떻게 확인할까?

로그, 프로세스, 파일. 이 세 곳을 봅니다.

도둑이 다녀간 집에는 흔적이 남습니다. 현관의 발자국, 집 안의 낯선 사람, 없던 물건입니다. 서버에서는 로그(서버가 남기는 출입 기록), 프로세스(지금 서버에서 돌고 있는 프로그램), 파일이 그 세 가지입니다. 네 나라 자료가 함께 꼽은 확인 항목은 다음과 같습니다.

1. 로그: PHP_SESSION_UPLOAD_PROGRESS가 들어간 multipart 요청, 업로드 기능이 없는 주소로 온 multipart 요청, 그 전후의 메모리 오류·HTTP 500^16·17·18
2. 프로세스: PHP 워커 아래에 sh·bash·curl·wget 같은 프로그램이 실행된 흔적^15·17
3. 파일: 최근 바뀐 PHP 파일, 업로드 폴더의 낯선 PHP 파일. 중국에는 웹셸(밖에서 서버를 조종하려고 몰래 심는 뒷문 파일)을 찾아 주는 검사 도구의 사용법을 공개한 자료도 있습니다. 이런 도구도 출처와 동작을 확인한 뒤 써야 합니다^17·19
4. 비밀번호·키: 이상이 없어도 데이터베이스·관리자 비밀번호와 API 키를 바꿉니다²

확인 순서는 위험편 4편 「패치 전에 이미 들어왔다면? 공격의 흔적 세 가지」에서 자세히 설명합니다.

진석 대표의 정리흔적이 없다고 "아무도 오지 않았다"고 단정할 수는 없습니다. 열쇠를 바꾸는 데는 큰 힘이 들지 않습니다. 그래서 비밀번호 교체만큼은 모두에게 권합니다.

업데이트 후 사이트가 깨지면 어떻게 할까?

원인이 된 플러그인이나 테마를 찾아 끄거나 바꾸면 대부분 돌아옵니다. WordPress는 디버그 기록(debug.log)을 켜면 어떤 파일이 오류를 냈는지 알려 줍니다.²¹

그래서 업데이트 전에 백업을 받고, 가능하면 시험용 환경에서 먼저 해 보라는 것이 공통 권고입니다. 백업은 돌아올 다리입니다. 다리를 놓고 건너는 강은 두렵지 않습니다.

같은 계열 안의 보안 수정(예: 8.3.x → 8.3.36)은 대체로 사이트를 깨뜨리지 않습니다. 문제는 주로 7.x에서 8.x로 옮기는 것처럼 큰 버전을 바꿀 때 생깁니다.

화면이 하얗게 변했을 때 되돌리는 순서는 개선편 「PHP를 올렸더니 화면이 하얗게 변했다면?」에 정리했습니다.

진석 대표의 정리"사이트가 깨질까 봐" 미루는 것이 가장 위험합니다. 백업만 있으면 어제로 돌아갈 수 있습니다.

근본 해결: PHP를 쓰지 않는 사이트로 바꾸면 어떻게 될까?

PHP의 업데이트·재시작·점검이 필요 없어집니다. 대신 폼·검색·댓글처럼 PHP가 하던 일은 다른 방법으로 해결해야 합니다.

PHP로 움직이는 사이트는 손님이 올 때마다 부엌에서 요리를 새로 하는 식당입니다. PHP를 쓰지 않는 정적 사이트(미리 만들어 둔 HTML 파일만 보여 주는 사이트)는 미리 지어 둔 도시락을 내주는 가게입니다. 불을 쓰지 않으니 불이 날 일이 없습니다. 대신 손님마다 다른 요리를 내기는 어렵습니다.

WordPress 사이트를 HTML 파일로 바꿔 내보내는 Simply Static 같은 도구가 있고, Cloudflare는 그렇게 만든 파일을 자사 서비스에 올리는 방법을 공식 문서로 안내합니다.^22·23 중국에서는 WordPress 글을 Hugo라는 정적 사이트 도구로 옮겨 운영 서버에서 PHP를 없애는 사례도 소개됩니다.²⁴

무료 도구만으로는 폼·검색·댓글이 동작하지 않고, 글을 고칠 때마다 다시 내보내야 한다는 한계도 공식 문서에 적혀 있습니다.^22·23 따뜻한기술의 PHPFree는 이 이전과 이후의 운영을 맡는 서비스입니다.

진석 대표의 정리모든 사이트가 옮겨야 하는 것은 아닙니다. 다만 회사 소개 사이트라면, 해마다 되풀이될 1~4단계를 아예 없애는 길도 있습니다. 문을 잘 잠그는 방법도 있지만, 지켜야 할 문을 줄이는 방법도 있습니다.