웹셸 입문: 오라클 피플소프트 공격 사례로 보는 웹셸

이 강좌를 끝내면 세 가지를 할 수 있습니다. 첫째, 이번 사건에서 중심이 되는 웹셸이 무엇이었는지 한 문장으로 말할 수 있습니다. 둘째, 웹셸이 놓이고 사용된 과정을 순서대로 설명할 수 있습니다. 셋째, 글자를 그대로 비교하는 차단 규칙과 보안 패치 적용이 이 사례에서 어떻게 달랐는지 구분할 수 있습니다. 사전지식은 가벼운 것 두 가지로 충분합니다. 웹 주소를 입력하면 서버가 응답을 돌려준다는 감각, 그리고 주소 뒤에 붙는 /경로/ 부분이 서버에서 부를 기능을 지목한다는 감각입니다.

한 문장으로 이해하기

이번 오라클 피플소프트 공격에서 이 강좌가 중심적으로 살펴볼 웹셸은 침해된 서버에 올려진 .jsp 확장자 파일 두 개, 곧 x.jsp와 u.jsp입니다.

x.jsp는 명령 실행에 쓰였고, u.jsp는 파일을 여러 조각으로 나눠 올리는 일과 명령 실행에 함께 쓰였습니다. 역할을 둘로 나눈 것은 웹 요청을 검사하는 방어 체계인 웹 애플리케이션 방화벽(WAF)의 탐지를 줄이려는 의도로 설명됐습니다. 보도된 웹셸이 이 두 개뿐이라는 뜻은 아니며, 여기서는 역할이 분명한 이 두 파일만 학습 대상으로 삼습니다.

왜 필요한가

왜 이것이 심각한지는 웹셸이 놓인 다음에 일어난 일을 보면 드러납니다. 보도에 따르면 관찰된 명령 가운데 약 4분의 1은 서버의 최고 권한(리눅스의 root, 윈도우의 NT Authority\SYSTEM)으로 실행됐습니다. 나머지는 피플소프트 또는 웹로직 서비스 계정, 곧 해당 서버 프로그램이 평소에 사용하는 계정의 권한으로 실행됐습니다.

또한 보도에 따르면 이 공격으로 수십 개 시스템에 웹셸이 배포됐습니다. 파일이 놓였다는 사실보다, 그 뒤에 이어진 명령의 권한과 범위가 사건의 무게를 결정했습니다.

어떻게 이루어지는가

보도에서 확인된 흐름은 다음 순서입니다.

1. 공격자가 취약한 기능으로 가는 주소 /%50SEMHUB/hub에 요청을 보냅니다. 보통 5회에서 15회를 보냈고, 요청에는 서버가 되살려 읽는 형태로 포장한 자바 데이터가 담겨 있었습니다. 이 단계는 공격이 통하는지 확인하는 과정으로 보도됐습니다.
2. 그 요청으로 원격 코드 실행이 일어납니다. 사용된 취약점에는 CVE-2026-35273이라는 식별 번호가 붙었고, 위험도 9.8점에 로그인 없이 원격으로 코드를 실행할 수 있는 것으로 보도됐습니다.
3. 서버의 PSEMHUB.war 디렉터리에 x.jsp와 u.jsp를 올려 둡니다.
4. 올려 둔 파일에 요청을 보내 명령을 실행하거나 파일을 나눠 올립니다.

하나의 예시로 따라가기

위 네 단계를 보도된 내용 그대로 이어서 보겠습니다. 1단계에서 공격자는 /%50SEMHUB/hub로 요청했습니다. 원래 주소는 /PSEMHUB/인데 앞의 P를 %50이라는 표기로 바꿔 적은 것입니다. 보도에 따르면 많은 웹 애플리케이션 방화벽과 중계 서버는 이 표기를 되돌리기 전의 글자를 그대로 비교했기 때문에 /PSEMHUB/를 막는 규칙을 그냥 통과시켰습니다. 반면 피플소프트 애플리케이션 서버는 경로를 되돌려 취약한 기능으로 요청을 전달했습니다.

2단계로 그 요청이 CVE-2026-35273 취약점을 작동시켰습니다. 3단계로 PSEMHUB.war 디렉터리에 x.jsp와 u.jsp가 놓였습니다. 4단계로 공격자는 u.jsp를 이용해 Ple64.exe를 올렸습니다. 이 파일은 서명된 Light Alloy 미디어 플레이어 설치 파일로 가장한 것으로 보도됐고, 실제로는 SIDEEYE라는 악성 프로그램을 메모리에 불러와 로그인 정보 탈취와 파일·프로세스 관리, 원격 조작 기능을 제공했습니다.

언제 쓰고 언제 쓰지 않는가

이 사례에서 배울 점은 ‘어디서 막을 수 있었는가’입니다. 보도된 권고 조치는 다음과 같습니다. 해당 취약점에 패치를 적용하고, 환경에 따라 환경 관리 허브(EMHub) 기능을 끄거나 PSEMHUB 애플리케이션을 제거하고, 접근 기록에서 글자를 바꿔 적은 요청을 찾아보고, 웹셸이 있는지 점검하고, 서비스 계정이 읽을 수 있었던 로그인 정보를 교체하라는 것입니다.

여기서 한계가 분명해집니다. 글자를 그대로 비교하는 차단 규칙은 표기를 바꾼 요청을 놓칠 수 있으므로 패치의 대체물이 될 수 없습니다. 구글은 공격자가 다른 퍼센트 표기나 대소문자 변형을 쓸 수 있다고 경고했고, 맨디언트는 웹 애플리케이션 방화벽에만 의존하지 말고 보안 업데이트를 설치하라고 권고했습니다. 이 강좌는 개념 설명이며 특정 제품 도입 권유나 보안 자문을 대신하지 않습니다.

핵심 정리와 확인문제

이번 피플소프트 사건에서 이 강좌가 다룬 웹셸은 침해된 서버에 올려진 .jsp 파일 x.jsp와 u.jsp이며, x.jsp는 명령 실행에, u.jsp는 분할 파일 업로드와 명령 실행에 사용됐습니다. 공격자는 주소 표기를 바꿔 차단 규칙을 지난 뒤 원격 코드 실행 취약점을 이용해 두 파일을 놓았고, 그 뒤 실행된 명령의 약 4분의 1은 서버 최고 권한으로 돌아갔습니다. 글자를 그대로 비교하는 차단 규칙은 패치의 대체물이 될 수 없습니다.

확인문제

1. 이번 사건에서 x.jsp와 u.jsp는 각각 어떤 역할을 했나요?
2. 패치 적용과 웹 애플리케이션 방화벽 규칙은 이 사례에서 어떤 차이를 보였나요?
3. 공격자가 차단 규칙을 비껴간 방법은 무엇이었나요?

정답과 해설

1. 정답: x.jsp는 명령 실행에 쓰였고, u.jsp는 나눠 올리는 파일 업로드와 명령 실행에 함께 쓰였습니다. 해설: 역할을 나눈 것은 웹 애플리케이션 방화벽의 탐지를 줄이려는 의도로 설명됐습니다.
2. 정답: 방화벽 규칙은 표기를 바꾼 요청을 걸러내지 못했고, 패치 적용이 권고의 첫 항목이었습니다. 해설: 규칙이 /PSEMHUB/라는 글자를 그대로 비교했기 때문이며, 맨디언트도 방화벽에만 의존하지 말고 보안 업데이트를 설치하라고 권고했습니다.
3. 정답: 주소의 P를 %50으로 바꿔 /%50SEMHUB/로 요청했습니다. 해설: 차단 규칙은 되돌리기 전의 글자를 비교해 통과시켰지만, 피플소프트 애플리케이션 서버는 경로를 되돌려 취약한 기능으로 요청을 전달했습니다.

참고자료

• 웹셸 입문 참고자료
• 웹셸 입문 참고자료