제로 데이 공격

제로 데이 공격

제로 데이 취약점은 소프트웨어 또는 호스팅된 애플리케이션이나 하드웨어의 결함으로 인해 발생할 수 있습니다. 일반적으로 테스트팀의 관심에서 벗어난(발견되지 않은) 버그이므로 개발팀은 이에 대해 알지 못합니다. 알려진 결함이 있는 경우 프로덕션 환경에 공개하기 전까지는 개발팀은 결함 수정을 위한 패치를 만들 수가 없습니다. 이로 인해 공격자가 악용할 수 있는 취약점이 열립니다. 그 이름은 취약점 탐지 시점과 공격 가능성 사이에 제로 데이 간격이 있다는 사실에서 유래되었습니다.

웹 애플리케이션의 개방형 취약점은 기술팀이 취약점의 존재를 인식하기 전에 공격이 발생할 수 있는 가능성을 열어줍니다. 대부분의 경우 취약점은 위협 행위자가 공격을 수행한 후에만 개발자가 버그를 알게되기 때문에 수개월 동안 탐지되지 않을 수 있습니다. 결과적으로 이러한 증상은 고객의 정보 손실 또는 자격 증명 도용으로 나타납니다. 그런 이후에야 개발자는 취약점에 대한 패치를 개발하고 추가 손상을 방지하기 위해서 노력합니다.

 

 

제로 데이 공격의 예

출처: Proofpoint

2017년 4월 초 주로 마이크로소프트 워드 사용자를 대상으로 한 대규모 제로 데이 공격이 호주에서 발생하였습니다. 그것은 트로이 드리덱스Trojan Dridex)를 운반하는 대규모 이메일 캠페인의 일부였습니다. 사용자가 이메일에서 다량의 매크로가 포함된 워드 문서를 다운로드하여 열었을 때, 그들은 드리덱스 봇넷을 설치하였고, 사용자는 뱅킹 트로이 목마의 희생자가 되었습니다. 이 악성 코드는 감염된 워드 파일이 “편집 사용” 기능이 켜진 상태에서 열렸을 때 만 실행되었는데, 대부분의 사용자가 다운로드한 문서에는 부주의하게도 편집 권한을 부여했기 때문에 확산이 멈추지 않았습니다. 마이크로소프트는 곧 보안 문제를 인식하고, 2017년 4월 11일에 관련 패치를 발표했습니다.

 

 

제로 데이 공격 유형

공격자는 수백만 줄의 코드를 살펴보고 리버스 엔지니어링 도구와 기술을 사용하여 애플리케이션의 취약성을 조사한 후 버그 또는 안전하지 않은 코드를 공개합니다. 일단 알려지면 공격자는 이 정보를 사용하여 추가 공격을 전파하거나 다크넷에서 민감한 정보를 판매할 수 있습니다.

사이버 범죄자들은 마이크로소프트 윈도우에서 실행되는 PLC(Programmable Logic Controllers)의 제로 데이 취약점을 악용하는 Stuxnet과 같은 웜을 사용하여 이란 및 인도네시아와 같은 다양한 국가의 제조 산업에서 사용되는 컴퓨터를 표적으로 삼았습니다. 이로 인해 우라늄 농축 과정에 필수적인 이란 핵 시설의 원심분리기가 중단되기도 하였습니다.

또한 공격자는 애플리케이션의 제로 데이 취약점과 여러 공격 방법을 결합하여 오랫동안 악영향을 미치도록 할 수 있습니다. 사이버 범죄자들은 스푸핑, 피싱 등과 같은 기술을 사용하여 사용자가 제로 데이에 웹 사이트를 방문하도록 유도하고, 해커는 취약점을 이용하여 웹 사이트를 방문할 때 악성 코드를 피해자의 시스템에 이식할 수 있습니다.

 

 

제로 데이 공격에 대비하기

제로 데이 취약점을 공격자가 부적절하게 사용하기 전에 탐지하는 것이 중요합니다. 취약성 검사 및 보안 감사는 제로 데이 취약점을 탐지하는데 큰 도움이 될 수 있습니다. 실제 공격 테스트 케이스 시나리오를 시뮬레이션하여 애플리케이션을 더욱 강력하고 버그 없이 만들 수 있습니다.

기존 벤치 마크에 대한 상호 코드 리뷰(peer code review)는 이전에 알려지지 않은 소프트웨어 취약점을 찾는데 도움이 될 수 있습니다. 이렇게 하면 코드를 안전하게 필터링하고 보다 신속하게 애플리케이션을 업데이트 하는데 도움이 됩니다.

버그/취약점 코드 감지를 위한 엄격한 테스트는 제로 데이 공격으로 인한 침입을 방지하기 위한 필수 사항입니다. 애자일 소프트웨어 개발을 채택함에 따라 반복하는 주기가 더 짧고 구체화 되었습니다. 계획된 테스트는 개발팀이 고객과 합의된 기한 내에 제품의 품질을 보장하는데 도움이 될 수 있습니다.

패치 관리를 정의된 관행으로 도입하여 패치로 코드베이스를 정기적으로 업데이트하면 제로 데이 공격의 위험을 줄일 수 있습니다. 패치를 적용하여 버그를 수정하고, 패치 후 신속한 애플리케이션 배포를 지원하는 잘 정의된 프로세스는 애플리케이션을 안전하고 강력한 최신 상태로 유지하는데 반드시 필요합니다.

Ref. https://www.appsealing.com/