웹사이트는 정상, CMS는 문제: Drupalgeddon2 이해

Source: Dev.to

당신이 회사 웹사이트를 담당하고 있다고 상상해 보세요.
모든 것이 정상적으로 보입니다.
페이지가 빠르게 로드됩니다.
사용자들이 로그인할 수 있습니다.
콘텐츠 편집자들이 매일 기사를 게시합니다.
고객들은 문제를 보고하지 않습니다.
외부에서 보면 모든 것이 완벽해 보입니다.

그런데 어느 날 놀라운 사실을 발견하게 됩니다:
공격자는 당신의 웹사이트가 건강해 보이는지에 신경 쓰지 않습니다.
그들은 뒤에 있는 소프트웨어가 취약한지에 관심이 있습니다.
바로 이것이 Drupalgeddon2에서 일어난 일입니다.
최근 몇 년간 가장 중요한 CMS 취약점 중 하나이며,
오늘날 개발자, DevOps 엔지니어, 보안 전문가에게도 여전히 귀중한 교훈을 줍니다.

큰 사무실 건물을 떠올려 보세요.
회사는 건물 관리자를 고용합니다.
관리자는 다음을 담당합니다:

• 방문자
• 배달
• 유지보수
• 일정 관리
• 방 접근

직원들은 이러한 세부 사항에 신경 쓰지 않습니다.
그들은 관리자를 믿습니다.

콘텐츠 관리 시스템(CMS)도 비슷하게 작동합니다.
모든 페이지와 기사를 일일이 수동으로 관리하는 대신, 조직은 CMS에 의존합니다.

Website
    ↓
CMS
    ↓
Content

CMS가 중앙 제어 시스템이 되며, 그래서 매력적인 표적이 됩니다.

Drupal은 오픈소스 콘텐츠 관리 시스템입니다.
조직은 이를 사용해 다음을 관리합니다:

• 기업 웹사이트
• 정부 포털
• 대학
• 미디어 플랫폼
• 엔터프라이즈 애플리케이션

단순화된 아키텍처는 다음과 같습니다:

Visitor
    ↓
Drupal
    ↓
Database
    ↓
Content

모든 요청이 Drupal을 거치므로, Drupal은 애플리케이션 공격 표면의 일부가 됩니다.

예를 들어 공격자가 다음에서 취약점을 발견했다고 가정해 보세요:

Custom Internal Tool

몇몇 조직만 영향을 받을 수 있습니다.

그런데 이제는 다음과 같은 대중적인 CMS에서 취약점을 발견한다면?

Popular CMS

수천 개의 조직이 영향을 받을 수 있고,
수백만 명의 사용자가 위험에 처할 수 있습니다.

하나의 취약점, 많은 표적.
그래서 CMS 플랫폼은 큰 관심을 받습니다.

Drupalgeddon2는 다음을 가리킵니다:

CVE-2018-7600

Drupal에 영향을 미치는 원격 코드 실행(RCE) 취약점입니다.

중요한 교훈은 특정 기술적 결함이 아니라, 개념적으로 무슨 일이 일어났는지를 이해하는 것입니다.
사용자 제어 입력이 절대 닿아서는 안 되는 기능에 도달했습니다.
애플리케이션은 공격자가 제어하는 데이터를 예상치 못한 방식으로 처리하기 시작했습니다.

결과는 다음과 같습니다:

User Input
    ↓
Application Logic
    ↓
Code Execution

이는 어떤 애플리케이션에서도 위험한 경로입니다.

많은 취약점은 정보를 노출하거나, 인증을 우회하거나, 데이터를 유출합니다.
원격 코드 실행은 다릅니다.
공격자가 서버 자체에서 명령을 실행할 수 있게 해줍니다.

다음 차이를 생각해 보세요:

• 창을 통해 보는 것
• 건물 안으로 들어가는 것

RCE는 공격자를 두 번째 시나리오에 훨씬 가깝게 만듭니다.

많은 개발자는 다음과 같은 기능에 집중합니다:

• 폼
• API
• 인증
• 검색
• 콘텐츠 편집

이는 충분히 합리적입니다.
하지만 모든 기능은 애플리케이션에 새로운 경로를 만들게 됩니다.
개발 중에 유용한 질문은 다음과 같습니다:

이 입력이 의도적으로 악의적이라면 어떻게 될까?

단순히 잘못됐거나, 예상치 못한 것이 아니라, 악의적인 경우를 말합니다.
이 사고 전환은 위험을 훨씬 일찍 드러내는 경우가 많습니다.

Drupalgeddon2는 또한 운영 현실을 강조합니다:
많은 침해 사고는 조직이 취약점을 알고 있음에도 업데이트를 미루기 때문에 발생합니다.
웹사이트는 작동하고, 애플리케이션은 안정적으로 보이며, 다운타임을 원하지 않기 때문에 업데이트가 연기됩니다.
공격자는 이런 상황을 좋아합니다.

공개된 취약점이 알려지면:

Researchers
    ↓
Attackers
    ↓
Automated Scanners

이들은 패치되지 않은 시스템을 찾기 시작합니다.

시스템을 보호하기 전에 조직은 가시성이 필요합니다.
다음과 같은 질문을 해야 합니다:

• 현재 어떤 Drupal 버전을 사용하고 있나요?
• 어떤 환경에서 사용하고 있나요?
• 스테이징 시스템은 패치되었나요?
• 개발 환경이 외부에 노출되어 있나요?

이 질문들은 운영 질문처럼 들리지만, 동시에 보안 질문이기도 합니다.

Drupalgeddon2는 단순히 CMS 취약점 이상의 것을 보여줍니다.
현대 애플리케이션은 생태계입니다.

Web Server
    ↓
CMS
    ↓
Plugins
    ↓
Database
    ↓
Infrastructure

각 레이어는 서로에게 의존합니다.
한 구성 요소가 실패하면 영향은 그 구성 요소를 넘어 널리 퍼집니다.
공격자는 왜 당신이 그것을 사용하는지 신경 쓰지 않습니다.
그것이 접근 가능하다는 것만 신경 씁니다.

시간은 종종 몇 달로 늘어납니다.
공격자는 보통 더 빠르게 움직입니다.

다음은 어떨까요:

• 스테이징
• 테스트
• 개발
• 잊혀진 환경

공격자는 조직이 잊어버린 부분을 자주 발견합니다.

Drupal은 널리 사용되는 CMS 플랫폼이며, 인기 소프트웨어는 공격자의 관심을 끕니다.
Drupalgeddon2는 원격 코드 실행을 가능하게 했습니다.
RCE는 가장 심각한 취약점 종류 중 하나입니다.

개발자는 유효한 입력뿐 아니라 악의적인 입력도 생각해야 합니다.
DevOps 팀은 패치를 보안 활동으로 다뤄야 합니다.
가시성과 자산 관리는 핵심 보안 통제입니다.
가장 신뢰받는 시스템일수록 가장 가치 있는 표적이 됩니다.

Drupalgeddon2가 여전히 중요한 사례 연구인 이유는 단순히 취약점 이야기가 아니기 때문입니다.
그것은 신뢰에 관한 이야기입니다.

조직은 CMS를 신뢰했고,
개발자는 프레임워크를 신뢰했으며,
운영 팀은 배포를 신뢰했습니다.
공격자도 무언가를 신뢰했죠:
어딘가에, 누군가 아직 업데이트하지 않은 시스템이 있다는 것을.

그리고 사이버 보안에서는 그 가정 하나만으로도 충분히 위험합니다.