[Security News] 최악의 보안 취약점 ‘Log4j’, 남은 이슈와 보안담당자들의 과제

KISA의 ‘Log4j 위협 대응 보고서 v1.0’ 살펴보니…개요와 원인, 취약점 악용 방식 등 정리

주요 이슈 △보안 업데이트는 여전히 진행중 △취약점 식별 및 내부 침투 확인 어려움 등

보안담당자들의 과제 △보안장비 정책 설정 △주요 시스템 모니터링 강화 △로그 관리 철저 등

2021년 12월 처음 발견돼 사상 최악의 보안 취약점으로 불리는 Log4j 취약점(일명 Log4Shell)이 올해도 가장 큰 보안 위협 가운데 하나로 지목되고 있습니다. 이에 따라 Log4j 취약점에 있어 현재까지 제기되고 있는 이슈와 보안담당자들이 어떻게 대응해야 하는지 알아볼 필요가 있습니다.

[이미지=unsplash]

이러한 가운데 한국인터넷진흥원(KISA)은 Log4j 취약점의 개요와 발생 원인, 취약점 악용 방식 및 유형 등을 정리한 ‘Log4j 위협 대응 보고서 v1.0’를 발표했습니다. 여기에서는 보고서 가운데 주요 이슈와 보안담당자들에게 필요한 노력을 중심으로 살펴봤습니다.

Log4j 취약점 주요 이슈

1. 보안 업데이트는 여전히 진행 중

보통 제로데이 취약점이 발견되면 보안 패치가 공개되고 기업에서는 해당 업데이트를 통해 취약점에 대응하게 됩니다. 다만, 보안 패치를 개발하는 과정에서 추가적인 취약점이 발견될 경우 또 다른 문제점이 발생할 수 있습니다.

이번 Log4j의 경우에는 최초 취약점(CVE-2021-44228) 발견 이후 7건의 추가 취약점이 발견됐습니다. 이후에도 추가 취약점이 발견될 수 있으므로 지속적인 모니터링을 통해 최신 업데이트를 반영하는 것이 중요합니다.

Log4j 이슈는 보안 업데이트가 특정 취약점에 대한 조치일 뿐 프로그램의 완결성을 의미하지 못한다는 점을 집중적으로 경험할 수 있었던 대표적 사례라고 할 수 있습니다. 현재 KISA에서 Log4j 취약점 보안 공지를 지속적으로 업데이트하고 있어 보안담당자들은 KISA의 보안 공지 현황을 수시로 참고해야 하며, 신규 내용이 공지될 경우 신속히 조치할 필요가 있습니다.

▲Log4j 최초 취약점 발견 이후 추가 취약점 발견 및 보안 패치 현황[자료=KISA]

2. 오픈소스 취약점 식별의 어려움

Log4j는 대표적인 오픈소스 프로그램이며, 해당 프로그램은 다양한 제품 내에 패키지 형태로 포함되어 사용되고 있습니다. 보통 취약점이 발견될 때 특정 제품 자체의 취약점일 경우에는 해당 제품에 대한 패치를 진행하면 되지만, Log4j와 같이 제품 내에 패키지 형태로 포함되는 프로그램에서 취약점이 발견될 경우 해당 프로그램 사용 여부를 상세히 파악하기가 쉽지 않습니다.

이번에 Log4j 취약점 이슈가 발생했을 때 기업들이 가장 어려워했던 부분은 자사 기업 내에서 Log4j 프로그램을 사용하는 서드파트(3rd-party) 제품이 있는지 여부를 식별하는 것이었습니다. 특정 프로그램에 대한 보안 업데이트 권고가 발표되었으나 해당 프로그램의 존재 여부를 식별하는 것 자체에 많은 시간이 소요되는 것은 매우 큰 위협이 되기 때문입니다. 이러한 위협에 각 기업에서 어떻게 보안을 유지해 나갈 수 있는지 면밀한 검토가 필요하다는 지적입니다.

3. 내부 침투 여부 확인의 어려움

제로데이 취약점이 발생하면 패치를 완료한 기업에서는 공격자가 내부망에 이미 침투해 있는 것은 아닌지 반드시 추가 점검을 이어가야 합니다. 이러한 점검 방식은 상황에 따라 매우 어려운 작업이 될 수 있습니다. 취약점 공격 성공 여부를 판단할 수 있는 특정 로그나 파일들이 존재하는 경우에는 해당 증거들을 상황을 판단해 나가면 되지만, 뚜렷한 증거가 존재하지 않는 경우에는 네트워크 정보 및 정밀한 호스트 분석까지 진행해야 명확한 상황 판단이 가능하기 때문입니다.

log4j 취약점의 경우에는 현재까지 호스트 분석에 대한 IoC(침해지표)가 공개되지 않고 있습니다. log4j는 여러 서비스에서 사용되는 프로그램이기에 취약점 공격이 성공했더라도 남는 흔적이 정형화되어 있지 않고 서비스마다 다르기 때문입니다. 공격 명령에 사용되는 Class 파일도 피해 시스템에 뚜렷한 흔적으로 남지 않는 것으로 알려졌습니다.

따라서 기업에서는 log4j 취약점 패치 이후 기업 내부 중요시스템을 중심으로 전반적인 비정상 여부 점검을 상세하게 진행해야 합니다. 평소와 다른 외부 통신 발생 여부 및 비정상 프로세스 존재 여부 등 다양한 관점에서의 점검이 필요합니다. KISA에서는 국내외 다양한 기관들과 협업하여 해당 취약점을 악용하는 공격 행위의 유포지 및 명령조종지를 신속히 확보, 차단하고 있다고 설명했습니다. 또한, 신고되는 침해사고는 기술지원 과정에서 해당 취약점이 악용됐는지 여부를 면밀히 살펴보고 있다고 밝혔습니다.

4. APT 공격 그룹들의 취약점 악용 공격 개시

파급력이 큰 취약점이 발견되면 APT 공격 그룹들은 신속히 자신들의 공격 도구에 취약점 공격 기능을 추가하게 됩니다. 과거 워너크라이(WannaCry) 랜섬웨어 공격에 악용된 윈도우 취약점의 경우에도 현재까지 APT 공격 그룹들에 의해 계속 활용되고 있습니다. 향후 언제라도 취약점이 조치되지 않은 사각지대가 내부망에 존재하는 시점이 발생할 경우 다시 큰 위협이 될 수 있다는 것입니다.

MS는 해킹그룹들이 자신들의 공격 키트에 Log4j 익스플로잇을 추가하고 있다고 밝혔습니다. MS가 발견한 Log4j 취약점 공격 해킹그룹은 하프늄(Hafnium), 아쿠아틱판다(Aquatic Panda), 포스포러스(Phosphorus)가 있습니다.

중국 기반 해킹그룹으로 추정되는 아쿠아틱판다(Aquatic Panda)는 2021년 12월, 대형 교육기관이 사용하는 Log4j 취약점이 있는 VMware Horizon 서비스를 정찰하고 파일 다운로드 명령어를 실행했습니다. 이후 타깃 시스템의 내부 환경을 파악하고, 메모리에 리버스 셸을 구성했다. 또한, 메모리 상에 존재하는 자격증명 정보를 수집하고, 정보 유출을 위해 winRAR로 압축을 수행한 것으로 드러났습니다.

이와 함께 이란이 후원하는 해킹 그룹으로 알려져 있는 포스포러스(Phosphorus)는 Log4j 취약점을 악용하여 파워셸(PowerShell) 스크립트가 실행되도록 했습니다. 해당 스크립트는 공격자가 구축한 아마존 서버에서 악성코드를 다운로드해 실행하고, 명령제어(C&C) 서버와 통신했습니다.

[이미지=unsplash]

보안담당자들에게 필요한 노력

1. 보안장비 정책 설정

보안담당자들은 Log4j 취약점 공격을 탐지·차단할 수 있도록 주기적으로 WAF, IPS 등의 보안장비 탐지 룰을 업데이트해야 합니다. 또한, Log4j 취약점 공격을 시도하는 것으로 알려진 IP를 방화벽에서 차단해야 합니다. 서버들의 아웃바운드 방화벽 정책도 점검해야 합니다. 공격 명령은 Class 파일과 추가 악성코드 다운로드를 통해 이루어지는데, 이를 위해서 피해 서버에서 외부 서버 주소로 접속하게 됩니다. 따라서 사내 중요 서버들의 아웃바운드 연결을 점검하고 모니터링하는 것이 매우 중요합니다.

2. 중앙관리시스템 등 주요 자원 모니터링 강화

Log4j 취약점을 악용한 공격의 경우 실제 취약점이 발현되어 공격이 성공했을 때 관련 흔적이 명확히 남지 않는 것으로 알려져 있습니다. 이렇듯 최초 취약점 발현 단계에서 탐지가 어려울 경우에는 공격자들의 추가 공격 행위(내부이동 등) 단계에서 방어자가 개입해 공격을 무력화하는 노력이 매우 중요합니다.

공격자는 중앙관리시스템과 같은 내부 호스트들과 접점이 많은 지점을 거점으로 악용하는 경우가 많습니다. 따라서 공격자가 내부 피해 확산을 위해 거점으로 장악할 수 있는 주요 자원에 대한 선별적 점검과 집중 모니터링은 매우 유용한 대응 방안입니다.

3. 시스템 로그에 대한 철저한 관리

주요 시스템에 대한 모니터링을 강화하기 위해서는 각 시스템별 보안 관점에서 활용 가능한 로그를 철저히 기록하고, 공격자에 의해 삭제되지 않도록 관리하는 것이 매우 중요합니다. 공격자들은 침투 흔적을 남기지 않기 위해 피해 시스템의 로그를 삭제하는 것이 일반적이기 때문입니다. 또한, 실제 피해가 발생했을 경우 로그는 정확한 사고 원인 및 피해 범위 확인 등 매우 유용하게 활용할 수 있습니다.

4. 소프트웨어 관리 체계에 대한 개선

기업에서 사용 중인 SW나 제공하는 서비스에 취약점을 가진 라이브러리가 포함되었는지 파악하는 것은 한계가 있습니다. 수천 개에 달하는 라이브러리로 구성되는 상용 SW는 일반적으로 자체 개발한 코드 외에도 오픈소스 코드와 서드파티 상용 프로그램을 함께 사용하기 때문입니다. 또한, 소프트웨어 개발 시 오픈소스 코드의 일부분만을 가져다 쓰는 경우도 많기 때문에 이를 식별하기가 쉽지 않습니다.

이로 인해 오픈소스 코드 영역이나 서드파티 프로그램과 같이 자체 개발하지 않은 부분에서는 취약성 여부의 확인이 어려워 보안 조치가 제대로 이루어지지 않는 문제가 발생하게 된다고 보고서는 지적하고 있습니다. 이번 Log4j 이슈에서 경험한 오픈소스 취약점 식별 문제 뿐만 아니라, 내부망에서 개발자나 시스템 관리자들에 의해 활용되는 다양한 소프트웨어에 대한 취약점은 지속 발견될 수 있습니다. 이에 소프트웨어 관리 체계에 대한 현황을 점검하고 개선안을 도출하는 노력이 필요하다는 설명입니다.

참고로, 해외에서는 자사 보유 소프트웨어의 취약점을 신속히 확인하기 위해 소프트웨어 출시 또는 배포 때마다 소프트웨어 재료명세서(SBOM : Software Bill of Materials)를 생산·관리하는 것으로 알려졌습니다. 또한, 미국은 2021년 5월, 행정 명령을 통해 연방정부에 공급하는 소프트웨어는 소프트웨어 제공업체의 SBOM 제출을 의무화했습니다.

한편, KISA에서 발표한 ‘Log4j 위협 대응 보고서 v1.0’ 전문은 <보안뉴스> 홈페이지내 시큐리티 콘텐츠 코너나 KISA 인터넷 보호나라&KrCERT 홈페이지에서 다운로드 받을 수 있습니다.

출처 : 보안뉴스 (https://www.boannews.com/media/view.asp?idx=105041&page=1&kind=1&search=title&find=)