보안 업체가 자사의 호스팅 플랫폼을 오프라인으로 전환했다면 주목할 필요가 있다. N-able N-central 제로데이 취약점 33건이 공개된 후 실제로 그런 일이 일어났으며, 이 취약점들은 관리 대상 시스템을 탈취 위험에 노출시킬 수 있는 결함들이다. N-able은 자사의 호스팅 N-central 서버를 오프라인으로 전환했고, 고객들에게도 자체 배포 환경에 대해 동일한 조치를 취하라고 안내했다.
이 글에서는 보도된 내용을 바탕으로 알려진 사실, N-central과 같은 도구가 왜 그렇게 큰 위험을 수반하는지, 그리고 중소기업과 관리형 서비스 제공업체(MSP) 고객이 지금 당장 할 수 있는 일을 다룬다.
N-central의 33개 결함이 의미하는 것
N-central은 N-able의 원격 모니터링 및 관리(RMM) 플랫폼이다. MSP는 이와 같은 도구를 사용해 자사가 지원하는 기업의 컴퓨터와 서버를 모니터링, 업데이트, 관리한다. 보도에 따르면, 새로 공개된 33개의 취약점으로 인해 관리 대상 시스템이 탈취될 수 있다.
여기서 "제로데이"라는 용어가 중요하다. 이는 수정 패치가 광범위하게 제공되기 전에 결함이 공개되었음을 의미하며, 따라서 방어자들은 준비할 시간이 거의 또는 전혀 없었다. 이것이 N-able이 패치 주기를 기다리는 대신 호스팅 서버를 오프라인으로 전환한 이유이며, 자체 인스턴스를 운영하는 고객에게도 같은 조치를 취하라고 권고한 이유이다.
원문 기사가 짧기 때문에, 우리가 검토한 보도 내용에서는 각 결함의 작동 방식과 실제 공격에 악용되었는지 여부를 포함한 일부 세부 사항이 아직 확인되지 않았다. 우리는 이 두 가지 점에 대해 추측하지 않을 것이다. 독자들은 상황이 전개됨에 따라 벤더 자체의 권고문을 권위 있는 출처로 삼아야 한다.
RMM 하나의 침해가 여러 기업으로 연쇄되는 이유
RMM 플랫폼은 관리하는 머신에 대해 깊고 신뢰받는 접근 권한을 갖도록 설계된다. 이 플랫폼은 스크립트를 실행하고, 소프트웨어를 배포하며, 여러 기기에서 동시에 설정을 변경할 수 있다. 바로 이것이 MSP에게 유용한 이유이자, 공격자에게 매력적인 이유이다.
위험은 집중에서 비롯된다:
- 하나의 콘솔, 다수의 고객. MSP는 단일 플랫폼에서 수십 또는 수백 개의 고객 조직을 관리할 수 있다. 해당 플랫폼을 장악한다는 것은 그 모든 조직에 접근할 수 있다는 것을 의미할 수 있다.
- 설계상의 특권. RMM 에이전트는 일반적으로 엔드포인트에서 높은 권한으로 실행되므로, 서버를 장악한 공격자는 그 신뢰를 그대로 물려받는다.
- 최종 고객에게는 보이지 않음. IT를 외주화한 중소기업은 공급업체가 사용하는 도구나 그 도구의 패치 여부를 직접 확인할 수 없는 경우가 많다.
이것이 N-central 공개 사건의 핵심 교훈이다. 취약점은 전혀 자사 네트워크에 있지 않을 수 있다. 다른 누군가가 운영하는, 한 단계 상류에 위치한 관리 도구일 수 있는 것이다.
N-able과 고객들이 지금까지 취한 조치
보도에 따르면, N-able은 취약점 공개에 대응하여 자사의 호스팅 N-central 서버를 오프라인으로 전환했다. 고객들에게도 같은 조치를 취하라고 안내했으며, 이는 상황이 해결될 때까지 자체 N-central 인스턴스를 오프라인으로 전환하라는 의미로 보인다.
핵심 관리 플랫폼을 오프라인으로 전환하는 것은 중대한 조치이다. MSP의 경우 일정 기간 동안 고객 시스템을 모니터링하고 패치하는 능력을 상실할 수 있다. 그들의 고객에게는 지원 응답이 느려질 수 있다. 이러한 트레이드오프는 벤더가 위험을 얼마나 심각하게 보는지를 보여주는 신호이다. 취약한 플랫폼을 그대로 노출시키는 것보다 일시적인 가시성 상실이 더 낫다고 판단한 것이다.
수정이나 복구 일정과 같은 구체적인 내용은 우리가 참고한 원문에 자세히 나와 있지 않으므로, 현재 상태는 N-able의 공식 권고문을 확인하기 바란다.
이것이 당신에게 의미하는 것
이 사안이 당신에게 미치는 영향은 당신의 위치에 따라 다르다.
N-central을 직접 운영하거나 MSP에서 근무하는 경우: 벤더의 지침을 긴급 사안으로 다뤄야 한다. 인스턴스를 오프라인으로 전환하라는 N-able의 지침을 따르고, 권장 수정 사항이 적용되었음을 확인할 때까지 인스턴스를 다시 가동하지 말아야 한다.
MSP를 이용하는 기업인 경우: N-central에 로그인한 적이 없더라도, 공급업체의 도구가 자사가 보유한 모든 기기에 접촉할 수 있다. 공급업체에 N-central을 사용하는지, N-able의 지침을 따랐는지, 그리고 자사 시스템이 영향을 받은 경우 어떻게 알려줄 것인지 물어보아야 한다.
개인 또는 가정 사용자인 경우: 직접적인 영향을 받을 가능성은 낮지만, 고용주나 IT 공급업체가 사용하는 소프트웨어도 당신의 위험 요소가 될 수 있다는 유용한 알림이다.
영향받은 사용자를 위한 체크리스트: 패치, 접근 검토, 관리자 모니터링
귀하의 조직이 직간접적으로 N-central을 사용한다면, 다음 단계를 차례로 진행하라:
- 패치 상태 확인. 공개된 결함을 해결하는 수정 사항이 있는지 N-able의 공식 권고문을 확인하고, 서비스를 복구하기 전에 해당 수정 사항이 적용되었는지 검증하라.
- 오프라인 지침 준수. 인스턴스를 오프라인으로 전환하라는 안내를 받았다면, 벤더가 안전하다고 할 때까지 오프라인 상태를 유지하라.
- 관리자 접근 검토. RMM 플랫폼에서 관리자 권한을 가진 모든 계정을 나열하라. 사용되지 않거나, 공유되거나, 낯선 계정은 제거하라.
- 자격 증명 교체. 관리자 비밀번호와 플랫폼에 저장되거나 연결된 모든 API 키 또는 비밀 정보를 변경하고, 다중 인증을 강제하라.
- 관리자 활동 모니터링. 예상치 못한 로그인, 새 계정, 새 스크립트 또는 예약된 작업, 그리고 승인하지 않은 엔드포인트로의 소프트웨어 배포가 있는지 로그를 검토하라.
- MSP에 직접 질문. 노출 여부, 취한 조치, 그리고 발견 사항을 어떻게 통보할 것인지에 대한 서면 업데이트를 요청하라.
- 노출 제한. 가능한 경우 관리 콘솔에 대한 접근을 제한하여 공개 인터넷에서 접근할 수 없도록 하라.
핵심 요점
N-able N-central 제로데이 취약점은 공급망 위험의 명확한 사례이다. 결함이 있는 관리 도구 하나가 여러 조직을 동시에 같은 상황에 빠뜨릴 수 있다. 벤더가 오프라인 전환을 결정한 것은 그 노출이 얼마나 심각할 수 있는지를 보여준다.
실질적인 다음 단계는 간단하다. 패치 상태를 확인하고, 누가 관리자 접근 권한을 갖고 있는지 검토하며, 관리자 활동을 면밀히 주시하라. MSP에 의존하고 있다면, 통보를 기다리지 말고 오늘 바로 N-central에 대해 문의하라. 가장 최신의 정확한 세부 사항은 N-able의 공식 보안 권고문과 공급업체의 커뮤니케이션에 의존하라. 이와 같은 사안에 대한 지침은 빠르게 바뀔 수 있기 때문이다.
