최신 BGP 하이재킹, 호스팅 소프트웨어 업체를 노리다

AI 요약

호스팅 소프트웨어 업체 Softaculous는 BGP 하이재킹과 유효한 TLS 인증서를 결합한 공격을 받았습니다. 공격자는 Virtualizor 업데이트 패키지에 악성 코드를 넣어 소수의 설치 환경에 전달했습니다. APNIC 글은 경로가 어떻게 전파됐는지, TLS 인증서 발급이 왜 막히지 않았는지, 네트워크 운영자가 어떤 설정과 감시를 적용해야 하는지 살펴봅니다.

/24 경로가 /16 경로를 밀어내다

2026년 8월 28일 20:57 UTC, 162.55.80.0/24 경로가 전역 라우팅 테이블에 나타났습니다. 이 주소 범위는 Hetzner Online(AS24940)이 정상적으로 광고하던 162.55.0.0/16에 포함되며, Softaculous의 업데이트 엔드포인트와 고객·결제 사이트에서 쓰였습니다. 새 경로의 AS 경로는 6204 62390 24940이었습니다. 글은 경로가 중간 AS인 NexonHost(AS62390)에서 시작됐을 가능성을 제시하며, 시스템 침해 또는 보안 공백을 이용한 고객 계정을 원인으로 들었습니다.

공격자는 AS 경로 끝에 실제 기원 AS인 24940을 위조해 붙였습니다. Hetzner의 ROA(Resource Origin Authorization)는 기원 AS로 AS24940을 요구했지만, 허용 가능한 프리픽스 길이를 /16부터 /24까지 열어뒀습니다. 그 결과 /24 경로는 RPKI 검증에서 유효한 경로로 판정됐습니다. RPKI-invalid 경로를 거부하는 네트워크도 이 경로를 걸러내지 못했습니다.

162.55.80.0/24에 맞서는 기존의 더 구체적인 경로가 없었고, 인터넷 라우팅은 가장 긴 프리픽스를 우선하는 longest-prefix match를 적용합니다. 따라서 이 /24 경로가 정상적인 /16 경로보다 우선하면서 해당 주소로 향하는 트래픽을 공격자 쪽으로 돌렸습니다. 경로는 8월 28일 처음 나타난 뒤 여러 차례 사라졌다 다시 나타났습니다. AS24940은 12시간가량 지나 해당 /24를 직접 광고하기 시작했고, 이후에도 경로를 철회하고 재광고하는 일이 반복됐습니다. 공격 경로는 정상 경로보다 전파 범위가 조금 좁았지만, 상당수 네트워크에 영향을 줄 만큼 퍼졌습니다.

BGP 하이재킹과 TLS 인증서 발급

경로 탈취만으로는 공격을 완성할 수 없었습니다. 공격자는 탈취한 경로를 이용해 도메인 소유권을 확인하는 인증 기관(CA)의 검증 트래픽을 가로채고, 도메인에 유효한 TLS 인증서를 발급받았습니다. TLS 자체의 암호화가 뚫린 것이 아니라, 인증서 발급 절차가 올바른 서버에 도달한다는 라우팅 인프라의 신뢰를 악용한 방식입니다. 글은 2022년 KLAYswap 공격에서도 같은 취약점이 쓰였다고 설명합니다.

Let’s Encrypt는 이런 위험을 줄이기 위해 MPIC(Multi-Perspective Issuance Corroboration)를 운영합니다. 한 지점에서만 도메인 제어권을 확인하지 않고, 지리적·네트워크상으로 떨어진 여러 위치에서 동시에 검증한 뒤 일정한 수의 응답이 일치해야 인증서를 발급합니다. 일부 지점에만 영향을 주는 지역적 하이재킹은 검증 결과의 불일치로 드러날 수 있습니다. 그러나 이번 공격처럼 더 구체적인 경로가 널리 전파되면 여러 검증 지점이 모두 공격자의 경로를 따라갈 수 있습니다. 글은 공격 경로가 넓게 퍼져 MPIC 검증 지점의 정족수(quorum)까지 공격자 통제 아래 들어갔다고 설명합니다.

예방과 감시

RPKI ROV(Route Origin Validation)는 잘못된 경로의 전파를 줄이는 데 도움을 주지만, 공격자가 AS 경로의 기원을 위조하는 상황까지 완전히 막지는 못합니다. 다만 Hetzner가 실제 라우팅에 맞춰 ROA의 최대 프리픽스 길이(maxLength)를 엄격하게 설정했다면 /24 경로의 전파가 줄었을 수 있습니다. 그랬다면 여러 위치에서 진행하는 MPIC 검증이 서로 다른 결과를 내 인증서 발급을 막았을 가능성이 있습니다.

네트워크 운영자는 새 프리픽스가 등장했는지만 보지 말고, 그 경로가 어떤 상위 네트워크를 거치는지도 감시해야 합니다. 이번 사례에서는 새 /24의 상위 경로에 상대적으로 알려지지 않은 NexonHost가 나타났습니다. 이 경로가 BGP 관측 지점 대부분에서 NexonHost를 통해서만 전달된 점도 이상 징후로 볼 수 있었습니다. BGP와 DNS 감시를 운영하고, 인터넷 기반 의존성의 변경도 확인해야 합니다.

글은 ROA에서 실제 라우팅과 일치하는 프리픽스 길이를 사용하고, RPKI-invalid 경로를 거부하라고 권고합니다. RFC 9319는 특정 예외를 빼면 ROA의 maxLength 사용을 피하는 편이 현재 권고 사항이라고 명시합니다. maxLength를 생략하면 기본 프리픽스 길이와 같은 효과가 납니다.

사건 이후 설정 변경

글이 게시된 뒤 Hetzner는 162.55.0.0/16 ROA의 maxLength를 16으로 바꿔 같은 방식의 하위 프리픽스 공격 가능성을 줄였습니다. 213.133.96.0/19와 213.239.192.0/18도 각각 실제 경로 길이에 맞춰 수정했습니다. 다만 AS24940의 ROA 50개에는 여전히 실제 경로보다 긴 프리픽스를 허용하는 설정이 남아 있었습니다. 예를 들어 실제 /15로 광고되는 78.46.0.0/15가 /24까지 허용하고 있었습니다.

Cloudflare의 Bryton Herdes는 Hetzner가 AS24940의 허가된 제공자를 열거하는 ASPA(Autonomous System Provider Authorization) 레코드도 추가했다고 전했습니다. ASPA를 확인하는 네트워크는 AS24940의 상위 제공자로 허가되지 않은 AS62390이 들어간 AS_PATH를 거부할 수 있습니다.

Lobsters 반응

• @whjms — 공격자는 공격을 실행하기 전에 새 경로를 이용해 유효한 TLS 인증서도 발급받았습니다. 섬뜩한 일이네요.

원문: APNIC / 번역·요약: Trawling