디버그 엔드포인트 노출 (pprof Debug Exposure)

Debug Code Exposure

설명

Go 애플리케이션에서 import _ "net/http/pprof"를 사용하면 기본 HTTP 서버에 /debug/pprof 디버그/프로파일링 엔드포인트가 자동으로 등록됩니다. 이 상태에서 http.ListenAndServe(":8080", nil)과 같이 전체 네트워크에 열려 있는 주소로 서버를 띄우면, 인증 없이 누구나 pprof 정보를 조회할 수 있습니다. 공격자는 /debug/pprof, /debug/pprof/goroutine, /debug/pprof/heap 등의 엔드포인트를 호출하여 현재 실행 중인 goroutine, 메모리 상태, 내부 경로, 일부 요청 정보 등 민감한 런타임 정보를 수집할 수 있습니다. 이 정보는 직접적인 코드 실행 취약점이 아니더라도, 추가 공격(예: 취약한 핸들러 식별, 비밀 값 추측, 서비스 구조 분석)에 큰 도움을 줄 수 있습니다.

잠재적 영향

• 디버그 정보 노출: pprof가 제공하는 goroutine, heap, threadcreate 등의 정보로 내부 구조와 실행 상태가 외부에 드러날 수 있습니다.

• 시스템 정보 노출: 서버의 메모리 사용량, 처리 패턴, 일부 에러 메시지 경로 등 인프라 정보가 유출될 수 있습니다.

• 추가 공격에 활용(정보 수집): 공격자가 이 정보를 바탕으로 취약한 엔드포인트, 성능 병목, 비정상 동작 등을 분석해 후속 공격(DoS, 취약 API 공략 등)을 정교하게 준비할 수 있습니다.

해결 방법

• 내부에서만 접근 가능하도록 바인딩

  • 개발/테스트 환경에서는 http.ListenAndServe("localhost:8080", nil) 또는 127.0.0.1로만 바인딩하여 외부 네트워크에서 접근하지 못하게 합니다.

• 별도 ServeMux로 pprof 분리

  • http.NewServeMux()를 사용해 pprof 핸들러를 별도 mux에 등록하고, 내부 전용 포트/주소에서만 띄웁니다.

• 인증/인가 적용

  • 가능하면 pprof 엔드포인트 앞에 인증(예: mTLS, VPN, 사내 프록시 인증, basic auth 등)을 두고, 운영 환경에서는 인터넷에서 직접 접근할 수 없도록 합니다.

• 운영 환경에서 불필요한 pprof 제거

  • 운영 환경에서는 기본적으로 import _ "net/http/pprof"를 제거하고, 필요할 때만 일시적으로 활성화하거나, 별도 디버그 전용 인스턴스를 사용합니다.

• 방화벽 / 보안 그룹 설정

  • pprof가 열려 있는 포트는 외부에서 직접 접근하지 못하도록 보안 그룹, 방화벽, Ingress 설정으로 차단합니다.

취약한 코드 및 안전한 코드 예시

취약한 코드

package main

import (
    "log"
    "net/http"

    _ "net/http/pprof" // pprof를 전체 서버에 자동 등록
)

func main() {
    // 기본 mux(nil)에 pprof 및 다른 핸들러가 함께 등록됨
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("Hello World"))
    })

    // 취약: 모든 인터페이스(:8080)에 노출, /debug/pprof도 함께 외부에서 접근 가능
    log.Fatal(http.ListenAndServe(":8080", nil))
}

안전한 코드

package main

import (
    "log"
    "net/http"
    "net/http/pprof"
)

// pprof용 내부 전용 서버 설정 예시
func startInternalPprofServer() {
    mux := http.NewServeMux()

    // pprof 핸들러를 별도 mux에만 등록
    mux.HandleFunc("/debug/pprof/", pprof.Index)
    mux.HandleFunc("/debug/pprof/cmdline", pprof.Cmdline)
    mux.HandleFunc("/debug/pprof/profile", pprof.Profile)
    mux.HandleFunc("/debug/pprof/symbol", pprof.Symbol)
    mux.HandleFunc("/debug/pprof/trace", pprof.Trace)

    // 내부 주소로만 바인딩 (예: localhost 전용)
    go func() {
        log.Println("internal pprof listening on localhost:6060")
        if err := http.ListenAndServe("localhost:6060", mux); err != nil {
            log.Println("pprof server stopped:", err)
        }
    }()
}

func main() {
    // 내부용 pprof 서버 시작 (운영에서는 방화벽/보안 그룹으로 접근 통제)
    startInternalPprofServer()

    // 실제 서비스용 서버: 기본 mux 사용, pprof는 등록하지 않음
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("Hello World"))
    })

    // 외부 서비스 포트에는 pprof 미노출
    log.Fatal(http.ListenAndServe(":8080", nil))
}

설명:

• 취약한 코드: 취약 코드에서는 import _ "net/http/pprof"로 인해 기본 HTTP mux(nil)에 /debug/pprof 관련 핸들러가 자동 등록됩니다. 그리고 http.ListenAndServe(":8080", nil)로 전체 인터페이스에 서버를 띄우기 때문에, 같은 포트에서 애플리케이션 엔드포인트와 함께 pprof 디버그 정보도 인터넷에 그대로 노출됩니다. 별도의 인증이나 접근 제어가 없으므로, 누구나 pprof 엔드포인트에 접근해 내부 런타임 정보를 수집할 수 있습니다.

• 안전한 코드: 안전한 코드에서는 pprof를 기본 mux에 자동 등록하지 않고, 별도의 http.NewServeMux()에만 등록합니다. 그리고 이 pprof 서버는 localhost:6060과 같이 내부 주소로만 바인딩하여 외부 네트워크에서 직접 접근할 수 없게 합니다. 실제 서비스용 HTTP 서버(":8080")에는 pprof를 전혀 등록하지 않아, 외부 사용자는 디버그/프로파일링 정보를 볼 수 없습니다. 이렇게 분리와 접근 통제를 적용함으로써 디버그 엔드포인트 노출 취약점을 효과적으로 제거합니다.

참조

• CWE-489