고스트 버그가 여전히 서버를 괴롭히고 있나요?

잊고 있던 취약점이 다시 돌아와 우리를 괴롭힐 수 있습니다. 위험하고 널리 보고된 취약점이 더 이상 위험하지 않을 정도로 충분히 패치 또는 업그레이드를 완료했다고 가정하는 것은 너무 쉽습니다.

하지만 실제로는 보안 팀이 중요한 패치를 놓쳤거나, 자신도 모르게 패치되지 않은 워크로드를 확보했을 수도 있습니다. 예를 들어, 추가 기술 솔루션을 구매하거나 조직이 다른 조직을 인수하거나 합병했기 때문일 수 있습니다.

그렇기 때문에 워크로드가 가장 중요한 취약점에 대해 철저하게 패치되었는지 다시 한 번 확인하는 것이 좋습니다. 이 중 하나는 GNU C 라이브러리 릴리스 2.2에 영향을 미치는 취약점인 Ghost 버그입니다. GNU C 라이브러리는 수많은 애플리케이션과 서비스를 구동하는 오픈 소스 코드 라이브러리입니다.

고스트는 방심하면 위험할 수 있는 버그가 아닙니다: Ghost는 CVSS 최고 점수인 10점을 받았으며, 이는 매우 중요한 버그임을 나타냅니다.

이 글에서는 고스트 취약점이 어떻게 작동하는지 설명하고, 고스트가 여전히 운영에 위험을 초래할 수 있는 이유를 간략하게 설명하며, 시스템에 패치되지 않은 GNU C 라이브러리가 있는지 확인하기 위해 수행할 수 있는 작업에 대해 설명합니다.

콘텐츠:

1. 고스트 버그(글리브 취약점이라고도 함)란 무엇인가요?
2. CVE-2015-0235에 대비하여 서버를 패치하는 방법
3. uChecker로 Ghost에 취약한지 확인해보세요.
4. 정기적인 패치는 Ghost 및 향후 취약점에 대한 핵심입니다.

고스트 버그(glibc 취약점이라고도 함)란 무엇인가요?

이 glibc 취약점은 2015년 1월 보안 공급업체 Qualys의 연구원들에 의해 발견되었으며, 당시 CVE-2015-0235로 지정되었습니다.

Qualys는 GNU C 라이브러리의 __nss_hostname_digits_dots() 함수에 로컬 사용자뿐만 아니라 원격 사용자도 트리거할 수 있는 버퍼 오버플로 취약점이 있다는 사실을 발견했습니다. 원격 공격자는 이 버퍼 오버플로 결함을 사용하여 glibc를 배포하는 애플리케이션을 실행하는 사용자의 권한을 사용하여 서버에서 임의의 코드를 실행할 수 있습니다.

연구원들은 Exim 메일 애플리케이션을 예로 들어 시스템이 어떻게 침해될 수 있는지 보여주는 샘플 분석 결과를 발표했지만, gethostbyname() 또는 gethostbyname2() 함수를 사용하는 모든 Linux 애플리케이션은 __nss_hostname_digits_dots() 취약점을 악용할 수 있는 경로를 제공하기 때문에 취약한 것입니다.

이 취약점을 이용하면 원격 공격자가 사용자도 모르는 사이에 시스템을 완전히 제어할 수 있습니다. 고스트는 구현하기 쉬운 익스플로잇이라는 점도 주목할 필요가 있습니다. 즉, 공격자는 비교적 적은 노력으로 취약한 시스템을 익스플로잇할 수 있으며, 이것이 CVSS 지수에서 Ghost가 최고 점수인 10점을 받아 심각한 취약점이라는 것을 의미하는 높은 점수를 받은 이유 중 하나입니다.

또한 대부분의 Linux 시스템이 이 취약점의 영향을 받는 등 널리 퍼져 있습니다. 영향을 받는 제품 목록은 여기에서 확인할 수 있습니다.

CVE-2015-0235에 대해 서버를 패치하는 방법

한 가지 흥미로운 점은 고스트가 2000년에 릴리스된 glibc-2.2에 포함되었다는 점입니다. 이후 릴리스인 glibc-2.18에서는 GNU C 라이브러리 업데이트의 일부로 이 취약점이 수정되었습니다.

그러나 이 수정 사항은 라이브러리에 대한 정기 업데이트로 인한 것이었기 때문에 보안 릴리스로 '표시'되지 않았습니다. 이러한 이유로 공급업체는 나중에 취약점이 발견될 때까지 glibc-2.2에 대한 업데이트를 자동으로 릴리스하지 않았습니다.

그 사이에 소프트웨어를 업그레이드하여 결과적으로 영향을 받지 않는 새 버전의 GNU C 라이브러리로 업그레이드했을 수도 있지만, 여전히 릴리스 2.2를 사용하고 있을 수도 있습니다.

취약한 라이브러리 버전에 여전히 의존하는 모든 시스템은 패치를 적용해야 합니다. 취약점의 심각성을 감안하여 주요 공급업체에서 패치를 출시했으며, 사용 중인 Linux 배포판을 패치하는 것만큼이나 간단하게 취약점을 해결할 수 있습니다.

운영 체제의 명령줄을 사용하여 glibc 라이브러리를 수동으로 업데이트할 수도 있습니다. 최신 라이브러리는 여기에 있지만 업데이트를 설치한 후에는 항상 서버를 재부팅해야 한다는 점을 잊지 마세요.

물론 현재 TuxCare의 KernelCare Enterprise를 사용 중이고 애드온인 LibraryCare를 배포하고 있다면 걱정할 필요가 없습니다. 고스트 버그 및 기타 여러 취약점은 이미 시스템에 패치되어 있습니다.

그러나 시스템 중 하나라도 더 패치가 필요한 경우 TuxCare ePortal에서 쉽게 패치를 등록할 수 있으며 재부팅하지 않고도 메모리에 패치가 적용될 수 있습니다.

유체커로 고스트에 취약한지 확인하세요.

고스트처럼 위험한 취약점이라면 몇 년 된 취약점이라도 워크로드가 해당 취약점에 대해 철저하게 패치되었는지 다시 한 번 확인하는 것이 좋습니다.

자격을 갖춘 보안팀은 항상 위험한 취약점을 즉시 패치하지만, 사람의 실수가 개입할 수 있으며, 때로는 기업 인수로 인해 또는 패치되지 않은 라이브러리가 포함된 새로운 기술 솔루션을 도입하여 패치되지 않은 워크로드가 몰래 들어올 수 있습니다.

다행히도 고스트로부터 서버를 보호하기 위해 패치가 필요한지 쉽게 확인할 수 있는 방법이 있습니다.

TuxCare에서는 GNU GPL 2에 따라 라이선스가 부여된 무료 사용 도구를 개발했습니다. 이 도구는 uChecker라고 불리며 시스템에서 glibc를 포함한 패치되지 않은 라이브러리를 자동으로 검색합니다. uChecker 설치는 간단합니다. 다음 명령을 실행하기만 하면 됩니다:

curl -s -L https://kernelcare.com/uchecker | python

uChecker를 실행하면 패치가 필요한 모든 라이브러리에 대한 전체 보고서를 볼 수 있습니다. 여기에는 디스크에 저장된 라이브러리뿐만 아니라 현재 메모리에 로드된 라이브러리도 포함됩니다.

보안을 위해 인터넷에서 다운로드한 코드는 시스템에서 실행하기 전에 철저히 확인해야 합니다. 위의 명령은 검사할 코드를 다운로드하는 명령과 실제로 실행하는 명령으로 구분할 수 있으며, 구분해야 합니다. 위에 표시된 방법은 uChecker를 실행하는 편리한 방법일 뿐, 최상의 보안 방법은 아닙니다.

정기적인 패치는 Ghost와 향후 취약점에 대비하기 위한 핵심 요소입니다.

고스트 버그는 여전히 존재하며 시스템을 괴롭히고 공격자를 위한 백도어를 생성할 가능성이 있습니다. 재부팅이 필요 없는 자동 라이브러리 패치 서비스를 이용하면 GNU C 라이브러리를 최신 상태로 유지할 수 있으므로 걱정할 필요가 없습니다.

필요한 만큼 포괄적으로 패치를 적용했는지 확실하지 않으신가요? 무료로 사용할 수 있으며 위험한 고스트 버그에 여전히 취약한지 빠르게 알려주는 uChecker를 사용해 보세요.

결론은 정기적인 패치를 통해 가장 위험한 취약점을 포함하여 해마다 시스템을 안전하게 보호할 수 있다는 것입니다. 항상 새로운 CVE가 발표되고 있으므로 CVE를 주시하고 시스템이 위험에 처해 있는지 확인하는 것이 중요합니다.

예를 들어, 이 글이 작성된 2021년 7월 중순까지 Glibc에서만 5개의 취약점이 등록되었습니다. 이는 매달 한 가지씩 새로운 취약점이 등록되는 셈입니다.

물론 고스트는 (아직 패치를 하지 않은 사람들에게) 가장 위험한 라이브러리 취약점 중 하나였으며 지금도 마찬가지입니다. 하지만 오래된 "Ghost"만큼 위험한 취약점이 또 없을 거라고 누가 장담할 수 있을까요?

새롭고 위험한 취약점을 관리하는 좋은 방법은 무엇이라고 생각하시나요? 귀사의 팀이 CVE-2015-0235와 같은 큰 도전에 대비할 준비가 되어 있다고 생각하시나요? 여러분과 여러분의 팀은 취약한 시스템을 발견하고 최악의 상황이 발생하더라도 즉시 패치를 적용할 수 있나요?

한 가지 확실한 것은 또 다른 위험한 취약점이 곧 발견될 수 있다는 점입니다.