5가지 아파치 취약점: 위험성, 예시 및 수정 사항 설명

이 블로그 글의 AI 요약으로 바로 가기

주요 내용

Apache 취약점은 데이터 유출, 서비스 거부 공격, 무단 서버 액세스 등 심각한 위험을 초래할 수 있습니다.
적시에 패치를 적용하는 것이 중요하지만 공식 보안 지원은 Linux 배포판의 수명이 다하면 종료됩니다.
TuxCare의 무제한 수명 주기 지원은 지속적인 보안 업데이트를 제공하여 조직이 EOL Linux 시스템에서 Apache 및 기타 중요 패키지를 안전하게 유지할 수 있도록 지원합니다.

아파치(Apache)는 일반적으로 아파치 소프트웨어 재단(Apache Software Foundation)이 개발한 무료 오픈소스 크로스 플랫폼 웹 서버인 ‘아파치 HTTP 서버’를 가리킵니다. 2025년, 아파치 HTTP 서버 2.4.x 버전에서 여러 건의 중등도 취약점이 공개되었습니다. 아파치는 오랫동안 인터넷의 (대부분을 차지하는) 사실상의 표준 웹 서버 역할을 해왔기 때문에, 이 서버에 영향을 미치는 취약점은 그 영향력이 크지 않더라도 광범위한 파장을 일으킬 수 있습니다.

이 글에서는 Apache 취약점, 취약점이 위험한 이유, 잠재적 위험으로부터 Linux 서버를 보호하는 방법에 대해 알아보세요.

아파치 취약점이란 무엇인가요?

아파치 취약점은 아파치 HTTP 서버에서 발견되는 보안 결함이나 약점으로, 이를 통해 악의적인 공격자가 무단 접근을 시도하거나 서비스를 방해하고 기타 악의적인 활동을 수행할 수 있습니다. 웹 서버인 아파치는 2025년 기준 전체 웹사이트의 25.5%를 호스팅하고 있으므로, 이러한 결함은 모든 분야에 막대한 보안 문제를 야기합니다.

2025년 현재, 아파치 HTTP 서버 2.4.x 버전에서 이미 9건의 취약점이 발견되었으며, 이는 2024년 2.4.x 버전에서 보고된 14건의 취약점과 비교되는 수치입니다.

일반적인 Apache 취약점 유형

Apache HTTP 서버 취약점은 일반적으로 몇 가지 반복되는 범주에 속합니다. 이를 이해하면 조직에서 주의해야 할 사항과 적시에 패치를 적용하는 것이 중요한 이유를 파악하는 데 도움이 됩니다.

원격 코드 실행(RCE)

가장 위험한 취약점 중 하나인 RCE는 공격자가 서버에서 임의의 명령을 실행할 수 있게 해줍니다. Apache의 경우 입력 유효성 검사 결함이나 사용자 요청의 안전하지 않은 처리로 인해 발생하는 경우가 많습니다. 익스플로잇된 RCE는 원격 공격자가 데이터 도난, 멀웨어 설치 또는 손상된 시스템을 사용하여 추가 공격을 시작하는 등 서버를 완전히 장악하는 결과를 초래할 수 있습니다.

경로 탐색

경로 통과 결함은 아파치가 디렉터리와 파일에 대한 액세스를 부적절하게 제한할 때 발생합니다. 공격자는 URL 경로(예: ../ 사용)를 조작하여 웹 루트 외부의 비밀번호 해시 또는 설정과 같은 민감한 시스템 파일에 접근할 수 있습니다. 이러한 노출은 종종 더 심각한 침해를 위한 디딤돌 역할을 합니다. 특히, 아파치 HTTP 서버 취약점 CVE-2021-41773과 CVE-2021-42013은 모두 경로 탐색을 통해 원격 코드 실행으로 에스컬레이션되는 취약점입니다.

서비스 거부(DoS)

Apache의 DoS 취약점은 일반적으로 잘못된 요청으로 서버에 과부하를 주거나 비효율적인 리소스 처리를 유발합니다. 공격이 성공하면 서비스 중단, 운영 중단 또는 성능 저하로 이어질 수 있습니다. 데이터를 도난당하지 않더라도 다운타임은 금전적 손실과 평판 손상으로 직결됩니다. 보고서에 따르면 25%의 조직에서 서버 다운타임 1시간당 30만~40만 달러의 비용이 발생할 수 있어 서비스 거부 공격은 매우 비용이 많이 드는 위험입니다.

권한 에스컬레이션

일부 취약점을 통해 시스템에 대한 접근 권한이 제한된 공격자가 더 높은 권한을 얻을 수 있습니다. 예를 들어, CVE-2019-0211은 권한이 없는 Apache 프로세스가 루트 사용자로 명령을 실행할 수 있게 합니다. 이러한 종류의 에스컬레이션은 공격자가 기업 보안팀의 정상적인 제한을 우회하여 전체 호스트 환경을 손상시킬 수 있게 함으로써 피해 가능성을 높입니다.

반드시 알아야 합니다: 잘못된 설정은 때로는 취약점 자체보다 더 위험할 수 있습니다. 취약한 권한, 기본 설정 또는 사용하지 않는 모듈을 활성화된 상태로 두는 것은 위협 행위자에게 공격의 문을 열어주는 일반적인 공격 벡터입니다.

아파치 취약점의 최근 사례

다음 취약점 목록에서 영향을 받는 Apache 버전은 2.4.0 버전부터 2.4.63 버전까지입니다. 영향을 받는 Linux 배포판에 대해서는 이미 Endless Lifecycle Support로 보호되는 패치가 제공되고 있습니다. TuxCare의 CVE 추적기를 사용하여 CVE, 영향을 받는 버전 및 패치 가용성과 같은 자세한 정보를 확인할 수 있습니다.

알려진 취약점을 자세히 살펴보겠습니다.

47252

첫 번째 문제입니다, 47252는 아파치 HTTP 서버 2.4.63 이하에 영향을 줍니다. 문제는 mod_ssl사용자가 제공한 입력의 이스케이프가 충분하지 않으면 공격자가 로그 파일에 이스케이프 문자를 삽입할 수 있습니다. 이 결함은 다음과 같은 지시어를 사용하는 로깅 구성에서 트리거됩니다. %{varname}x 또는 %{varname}c 와 같은 변수를 사용합니다. 왜냐하면 mod_ssl nor mod_log_config 이스케이핑을 수행하면 클라이언트가 제공한 악성 데이터가 로그에 정제되지 않은 상태로 남을 수 있습니다. 이 경우 서버가 직접적으로 손상되지는 않지만 공격자가 로그 기록을 조작하거나 오염시켜 보안팀으로부터 활동 흔적을 숨기거나 사고 대응 노력을 방해할 수 있습니다.

23048

23048 는 특정 액세스 제어 우회에 대한 우려를 강조합니다. mod_ssl 구성이 필요합니다. 이 결함은 TLS 1.3 세션 재시작이 활성화된 Apache HTTP 서버 버전 2.4.35~2.4.63에 영향을 줍니다. 여러 가상 호스트가 각각 다른 클라이언트 인증서로 제한되는 경우, 이 결함으로 인해 한 호스트에서 신뢰하는 클라이언트가 다른 호스트에 액세스할 수 있지만 다음과 같은 경우에만 가능합니다. SSLStrictSNIVHostCheck 가 활성화되어 있지 않습니다. 기본적으로 가상 호스트 간의 분리가 무너지게 됩니다. 이 취약점은 클라이언트 측 인증서를 액세스 제어에 사용할 때 예상되는 보안 보장을 약화시키며 멀티테넌트 환경에서 심각한 영향을 미칩니다.

49630

CVE-2025-49630은 설정 선택이 어떻게 아파치를 서비스 거부 위험에 노출시킬 수 있는지 보여줍니다. 이 취약점은 아파치가 ProxyPreserveHost를 켜고 HTTP/2 백엔드의 역방향 프록시로 설정되어 있을 때 나타납니다. 이러한 조건에서 신뢰할 수 없는 클라이언트 입력은 mod_proxy_http2 모듈에서 어설션 실패를 트리거하여 아파치를 다운시킬 수 있습니다. 이 결함으로 인해 공격자가 데이터나 코드 실행에 액세스할 수 있는 권한은 없지만 서버를 오프라인 상태로 만들 수 있는 안정적인 방법을 제공하며, 이는 파괴적인 캠페인이나 대규모 공격 체인의 일부로 자주 사용되는 전술입니다.

49812

CVE-2025-49812는 TLS 업그레이드를 허용하기 위해 "SSLEngine 옵션"을 사용하는 mod_ssl 구성과 연관되어 있습니다. 이 설정에서는 연결 중간에 위치한 공격자가 HTTP 비동기화 공격을 실행하여 TLS 업그레이드 프로세스 중에 활성 세션의 세션 하이재킹을 실행할 수 있습니다. 그 결과 공격자가 합법적인 사용자를 사칭하여 세션을 탈취할 가능성이 있습니다. 아파치는 버전 2.4.64에서 TLS 업그레이드에 대한 지원을 제거하여 공격 표면을 효과적으로 제거함으로써 이 문제를 해결했습니다.

40725

마지막으로, CVE-2024-40725는 수정 사항도 새로운 문제를 일으킬 수 있음을 상기시켜 줍니다. 이 결함은 CVE-2024-39884의 부분 수정으로 2.4.60 및 2.4.61 버전에 나타났습니다. 이 결함은 콘텐츠 유형 기반 핸들러 구성에 AddType과 같은 지시문을 레거시 방식으로 사용하는 것을 중심으로 합니다. 특정 조건에서 간접 파일 요청은 PHP와 같은 로컬 스크립트의 소스 코드를 실행하지 않고 노출할 수 있습니다. 의도치 않게 소스 코드가 노출되면 민감한 로직이 유출될 뿐만 아니라 공격자에게 애플리케이션 구축 방식에 대한 귀중한 통찰력을 제공할 수 있습니다. 아파치는 버전 2.4.62에서 이 문제를 완전히 수정했습니다.

참고: 많은 아파치 결함은 그 자체로는 전체 서버 손상을 허용하지 않습니다. 대신 광범위한 공격 체인에서 중요한 첫 단계로 작용하는 경우가 많습니다. 따라서 위협 행위자가 사소한 결함을 중대한 침해로 확대하는 것을 방지하기 위해 중하위 등급의 CVE라도 긴급한 것으로 취급해야 합니다.

아파치 취약점이 위험한 이유

Apache는 전 세계에서 가장 널리 사용되는 웹 서버 중 하나이며, 이러한 인기로 인해 공격자들에게는 매우 가치 있는 표적이 되고 있습니다. 패치되지 않은 Apache 취약점 하나로 인해 시스템뿐만 아니라 잠재적으로 수천 개의 웹사이트와 서비스가 동시에 손상될 수 있습니다.

아파치 취약점이 위험한 또 다른 이유는 취약점 대부분이 익스플로잇하기 쉽기 때문입니다. 개념 증명(PoC) 익스플로잇이 퍼블릭 도메인에 공개되면 공격자는 대규모로 스캔과 익스플로잇을 자동화할 수 있습니다. 메타스플로잇과 같은 도구를 사용하면 숙련도가 낮은 공격자라도 패치가 적용되지 않은 서버에 대한 공격을 쉽게 시작할 수 있습니다.

보안 침해의 결과는 심각할 수 있습니다:

데이터 유출: 보안 침해가 발생하면 개인, 금융 또는 비즈니스 데이터가 노출됩니다.
공급망 공격: Apache 서버가 파트너가 사용하는 애플리케이션이나 API를 호스팅하는 경우 공격자는 다운스트림으로 이동할 수 있습니다.
브랜드 손상: 유명세를 탄 Apache CVE와 관련된 보안 사고는 종종 헤드라인을 장식하며 브랜드 평판과 고객 신뢰에 타격을 입힙니다.

사례 연구: 2021년, Apache HTTP 서버 경로 통과 결함(CVE-2021-41773 / CVE-2021-42013) 가 공개되었고, 연구원들은 몇 시간에서 며칠 만에 인터넷에 연결된 서버를 광범위하게 스캔하는 것을 목격했습니다. 공개 직후 많은 익스플로잇 시도가 보고되었습니다. 익스플로잇의 복잡성은 매우 낮아서 공격자가 조작된 URL로 서버를 쉽게 조사할 수 있었습니다. 공격자들은 다음과 같은 시스템에 대한 정보가 포함된 파일에 접근을 시도했습니다. /etc/passwd, /etc/hosts또는 win.ini 의 경우, 경우에 따라 자격 증명이나 구성 데이터가 노출되어 전체 시스템이 손상될 수 있습니다.

아파치 HTTP 서버 패치 및 보안 방법

아파치 HTTP 서버 보안은 지속적인 노력이 필요합니다. 다음은 아파치 패치와 보안을 위한 가장 일반적인 접근 방식입니다.

공급업체 패치

가장 쉬운 방법은 사용 중인 Linux 배포판에서 제공하는 공식 보안 업데이트를 사용하는 것입니다. 운영 체제가 지원되는 한, Apache HTTP 서버 및 기타 패키지에 대한 보안 패치는 패키지 관리자 apt(우분투/데비안용) 또는 yum/dnf(RHEL/CentOS용)를 통해 사용할 수 있습니다.

수동 업데이트 및 컴파일

또 다른 옵션은 Apache.org에서 최신 Apache 소스 코드를 직접 다운로드하여 수동으로 컴파일하는 것입니다. 이 방법은 최신 버전에 대한 액세스를 보장하지만 패키지를 컴파일할 수 있는 숙련된 사용자에게만 권장됩니다. 이 방법을 사용할 때의 또 다른 단점은 모든 새로운 CVE에 수동 개입이 필요하므로 지속적인 주의가 필요하고 일관된 패치의 위험이 따른다는 것입니다.

TuxCare의 Linux에 대한 끝없는 수명 주기 지원

미션 크리티컬 서버가 수명이 다한 Linux 배포판에서 실행되고 있다면 어떻게 될까요? 공급업체의 공식 패치가 제공되지 않은 상태에서 시스템은 버퍼 오버플로 공격으로 이어질 수 있는 취약점을 비롯한 새로운 Apache 취약점에 취약해집니다. 이는 많은 조직에서 흔히 발생하는 중요한 시나리오입니다.

그렇기 때문에 TuxCare의 ELS(Endless Lifecycle Support) 와 같은 연장 지원 서비스가 필수적입니다. ELS는 공식 지원이 종료된 후에도 Apache HTTP 서버 및 기타 다양한 패키지에 대한 지속적인 보안 업데이트를 제공합니다. 이러한 접근 방식은 공급업체 수준의 보호 기능을 제공하는 동시에 보안 팀이 서두를 필요 없이 원활한 마이그레이션을 계획하는 데 필요한 시간을 확보할 수 있게 해줍니다.

사용 중인 스택이 오픈소스 웹 서비스 프레임워크에 의존하고 있다면, 당사의 심층 가이드를 통해 Apache CXF의 지원 종료(EOL) 관리에 대해 자세히 알아보실 수 있으며, 오픈소스 데이터 웨어하우스 도구를 활용하고 계신다면 Apache Hive의 지원 종료(EOL )에 관한 가이드를 참고해 보시기 바랍니다.

TuxCare의 ELS로 아파치 서버를 보호하세요.

많은 조직에서 보안 업데이트가 더 이상 제공되지 않는 수명이 다한 Linux 배포판 및 기타 오픈 소스 도구에 여전히 의존하고 있습니다. 지원되는 버전으로 업그레이드하는 것이 보안 수정 사항을 계속 받을 수 있는 장기적인 해결책이지만, 원활한 마이그레이션을 계획하는 데 필요한 상당한 비용과 시간은 말할 것도 없고 호환성 문제와 다운타임 위험으로 인해 어려운 경우가 많습니다.

하지만 비용 효율적인 대안이 있습니다: 바로 TuxCare의 ELS(Endless Lifecycle Support)입니다. TuxCare는 다음과 같이 수명이 종료되는 광범위한 Linux 배포판을 지원합니다: CentOS 6, CentOS 7, CentOS 8, CentOS 스트림, 오라클 리눅스 6, 오라클 리눅스 7, 우분투 16.04, 우분투 18.04, 우분투 20.04 및 RHEL 7.

ELS는 Linux 커널 업데이트와 Apache, PHP, Python, MySQL, glibc, OpenSSL, OpenJDK 등과 같은 기타 중요 패키지를 포함하여 140개 이상의 패키지를 지원합니다.

이미 무한 수명 주기 지원 고객인 경우, 위의 Apache 취약성에 대한 패치가 준비되어 있으며 영향을 받는 시스템에 사용할 수 있습니다. 그렇지 않다면 지금이 바로 TuxCare의 ELS를 통해 Apache 서버와 전체 Linux 스택을 수명 종료 후에도 안전하게 보호할 수 있는 방법을 알아볼 수 있는 적기입니다.

요약