요약
2022년에는 41개의 와일드 제로데이가 감지 및 공개되었는데, 이는 2014년 중반 추적이 시작된 이후 두 번째로 많은 기록이지만, 2021년에 감지된 69개에 비하면 감소한 수치입니다. 40% 하락은 안전성 향상을 위해 삭감해야 할 명백한 숫자처럼 보일 수 있지만 현실은 더 복잡합니다. 2022년 주요 시사점은 다음과 같습니다.
패치 시간이 길기 때문에 N일은 Android의 0일과 유사하게 작동합니다. Android 생태계 전반에 걸쳐 사용자가 장기간 패치를 사용할 수 없는 상황이 여러 가지 있습니다. 공격자는 0일 취약점이 필요하지 않지만 0일 역할을 하는 n일을 사용할 수 있습니다.
제로 클릭 익스플로잇과 새로운 브라우저 완화 기능은 브라우저 제로데이 취약성을 줄입니다. 많은 공격자들이 원클릭 공격 대신 제로클릭 공격으로 전환했습니다. 제로 클릭은 일반적으로 브라우저 이외의 구성 요소를 대상으로 합니다. 또한 모든 주요 브라우저는 취약점 악용을 더욱 어렵게 만들고 공격자가 다른 공격 영역으로 이동하도록 영향을 미칠 수 있는 새로운 방어 기능을 구현했습니다.
40% 이상의 0day 취약점은 이전에 보고된 취약점의 변형입니다. 2022년의 41개 와일드 제로데이 중 17개는 이전에 보고된 취약점의 변종입니다. 이는 이전에 2020년 검토 보고서와 2022년 중간 보고서에서 논의한 불쾌한 추세를 이어갑니다. 20% 이상은 2021년과 2020년 이전의 와일드 제로데이의 변형입니다.
버그 충돌이 높습니다. 2022년에는 공격자들이 서로 동일한 취약점을 활용한다는 보고가 잦아졌고, 보안 연구원들 역시 나중에 발견된 취약점을 공격자가 사용했다는 보고도 있었다. 널리 사용되는 소비자 플랫폼에 대해 0day 취약점이 발견되고 패치되면 다른 공격자의 취약점도 손상시킬 수 있는 가능성이 점점 더 커지고 있습니다.
2022년 0days 분석에 따르면 업계는 다음 영역에 계속해서 집중할 것으로 예상됩니다.
-
변종 및 n일을 0일로 사용하는 문제를 해결하기 위한 보다 포괄적이고 시기적절한 패치입니다.
-
더 많은 플랫폼이 브라우저의 선례를 따르고 전체 취약점 클래스의 악용 가능성을 줄이기 위해 더 광범위한 완화 기능을 출시하고 있습니다.
-
기술 세부 정보를 공유하고 여러 제품에 걸쳐 익스플로잇 체인을 공동으로 탐지하기 위해 공급업체와 보안 유지관리자 간의 투명성과 협업이 지속적으로 확대되고 있습니다.
수치적 관점에서
2022년에 감지 및 공개된 41개의 취약점 중 감지된 모든 제로데이 취약점의 상당 부분을 차지하는 취약점은 발견되지 않았습니다. 상반기에는 20개, 하반기에는 21개로 일년 내내 상대적으로 고르게 분포되어 있음을 알 수 있습니다. 이 두 가지 데이터 포인트의 조합은 테스트가 더 빈번하고 정기적이라는 것을 시사합니다. 또한 우리는 실제로 제로데이를 갖고 있다고 생각되는 조직의 수가 여전히 높은 것으로 나타났습니다. 2021년부터 20개 조직이 69개의 제로데이 취약점을 탐지한 것으로 인정받았습니다. 2022년에는 18개 조직이 41건의 와일드 제로데이 이벤트를 인정받았습니다. 이 문제를 해결하려면 가능한 한 많은 사람이 필요하기 때문에 제로데이 탐지를 위해 노력하는 조직의 수가 여전히 많을 것이라는 점은 유망합니다.
와일드 제로데이는 2021년 69건에서 2022년에는 41건으로 감소했습니다. 2021년에 비해 크게 하락했지만, 2022년에도 여전히 2위를 기록하고 있다. 분석에 사용하는 모든 0일은 이 스프레드시트에서 추적됩니다.
보안 지표로서의 0일 수량 제한
실제로 감지되고 공개된 제로데이 수는 보안 태세에 대해 많은 것을 알려주지 않습니다. 대신 우리는 이를 많은 지표 중 하나로 사용합니다. 2022년까지 우리는 보안 개선과 회귀의 조합으로 인해 2021년부터 2022년까지 감지 및 공개된 0일 수가 약 40% 감소했으며, 계속해서 평균 이상의 0일 수를 기록할 것으로 믿습니다. 2022년에.
긍정적인 변화와 부정적인 변화 모두 실제 상태의 0일 수의 증가 및 감소에 영향을 미칩니다. 따라서 이 수치만으로는 사용자를 안전하게 보호하기 위한 노력이 진행되고 있는지 여부를 나타낼 수 없습니다. 대신, 우리는 그 수치를 사용하여 어떤 요소가 이 결과에 기여했을 수 있는지 분석한 다음 이러한 요소가 성공 영역인지 아니면 해결해야 할 영역인지 검토합니다.
실제 제로데이 탐지 및 공개 건수가 증가하는 요인의 예는 다음과 같습니다.
보안 개선 - 공격자가 동일한 기능을 유지하려면 더 많은 0일이 필요합니다. |
|
안전한 회귀 - 0days는 더 쉽게 발견하고 악용할 수 있습니다. |
|
실제 제로데이 탐지 및 공개 건수 감소에 기여한 요인의 예는 다음과 같습니다.
보안 개선 - 0days를 개발하고 사용하려면 더 많은 시간, 돈, 전문 지식이 필요합니다. |
|
보안 회귀 - 공격자가 동일한 기능을 유지하는 데 더 적은 시간이 필요합니다. |
|
해당 숫자의 증가 및 감소를 유발할 수 있는 다양한 요인을 브레인스토밍하면 숫자 뒤에 무슨 일이 일어나고 있는지 이해하고 그로부터 결론을 도출할 수 있습니다. 2022년에 평균 이상의 유기적 제로데이 숫자를 이끄는 두 가지 주요 요소는 공급업체 투명성과 변형입니다. 탐지 및 투명성에 대한 공급업체의 지속적인 노력은 확실한 승리이지만, 제로데이 변종의 실제 출시 비율이 높지는 않습니다. Deja Vu 섹션에서 이러한 변형에 대해 더 자세히 논의합니다.
마찬가지로 우리는 2021년부터 2022년까지 자연적인 제로데이 숫자의 감소에 기여할 수 있는 몇 가지 주요 요인을 평가합니다. 긍정적인 요인에는 악용 가능한 버그가 감소하여 많은 공격자가 서로 다른 방법을 사용하게 되고 부정적인 영향(예: 덜 정교한 공격 방법으로 0day 취약점만큼 효과적이지만 0day 감지 속도가 느립니다. 야생에서의 제로데이 수만으로는 야생 활용 현황에 대해 많은 것을 알 수 없지만, 이 수치에 영향을 미치는 다양한 요인은 실제 교훈입니다. 다음 섹션에서 이에 대해 자세히 살펴보겠습니다.
안드로이드에 0day가 필요합니까?
2022년에는 Android 생태계 전체에서 업스트림 제조업체가 이 문제에 대한 패치를 출시했지만 다운스트림 제조업체는 사용자가 적용할 패치 및 릴리스 수정 사항을 수락하지 않은 일련의 사례를 확인했습니다. Project Zero는 2022년 11월 'Mind the Gap' 블로그 게시물에서 이러한 사례 중 하나를 소개했습니다.
업스트림 공급업체와 다운스트림 제조업체 간의 이러한 격차로 인해 n일(잘 알려진 취약점)이 0일처럼 작동할 수 있습니다. 사용자에게는 즉시 사용할 수 있는 패치가 없고 유일한 방어 수단은 장치 사용을 중단하는 것이기 때문입니다. 이러한 격차는 대부분의 업스트림 및 다운스트림 관계에 존재하지만 Android에서는 더 널리 퍼져 있고 오래 지속됩니다.
이는 공격자에게 좋은 사례입니다. 공격자는 알려진 n-day 취약점을 악용할 수 있지만 영향을 받는 모든 장치에 적용되므로 0-day 취약점으로 실행합니다. 2022년 Android에서 이러한 일이 발생하는 예는 ARM Mali GPU의 취약점인 CVE-2022-38181입니다. 이 취약점은 원래 Github Security Labs의 보안 연구원인 Man Yue Mo가 2022년 7월에 Android 보안 팀에 보고했습니다. 이후 Android 보안 팀은 이 문제가 '기기별' 문제이기 때문에 '수정 불가능'하다고 판단했습니다. 하지만 안드로이드 보안 부서에서는 이 문제를 ARM에 회부했습니다. 2022년 10월, ARM은 취약점을 해결한 새로운 드라이버 버전을 출시했습니다. 2022년 11월, TAG는 해당 취약점이 실제로 사용되고 있음을 발견했습니다. ARM은 2022년 10월에 수정된 드라이버 버전을 출시했지만, ARM이 처음 출시된 지 6개월, Man Yue Mo가 처음 보고한 지 9개월이 지난 2023년 4월까지 안드로이드에서는 취약점이 수정되지 않았습니다. 개월.
-
2022년 7월: Android 보안팀에 보고
-
2022년 8월: Android 보안이 '수정 불가능'으로 표시되고 ARM으로 전송됨
-
2022년 10월: ARM, 버그 수정
-
2022년 11월: 실제 취약점 발견
-
2023년 4월: Android 보안 게시판에 포함됨
2022년 12월, TAG는 최신 버전의 삼성 인터넷 브라우저를 표적으로 삼는 또 다른 익스플로잇 체인을 발견했습니다. 당시 삼성 인터넷 브라우저 최신 버전은 7개월 전인 2022년 5월 출시된 크로미움 102에서 구동됐다. 이 체인의 일부로 공격자는 0days로 실행될 수 있는 두 가지 n-day 취약점인 CVE-2022-3038(2022년 6월 Chrome 105에서 패치됨)과 ARM Mali GPU 커널 드라이버 CVE-2022-22706을 악용할 수 있었습니다. ARM은 2022년 1월에 CVE-2022-22706에 대한 패치를 출시했는데, 이는 야생에서 익스플로잇으로 표시되었지만 11개월이 지난 후에도 공격자들은 여전히 이를 0day로 사용할 수 있었습니다. 이 취약점은 2022년 1월에 널리 악용되었지만 2023년 6월까지 Android 보안 게시판에 포함되지 않았습니다.
0일로 간주되는 이러한 n일은 0일로 추적되는지 여부의 회색 영역에 속합니다. 과거에는 CVE-2019-2215 및 CVE-2021-1048을 0일로 계산하는 경우가 있었습니다. 이 두 가지 취약점의 경우 업스트림 Linux 커널에서 버그가 수정되었지만 Linux 표준에 따라 CVE가 할당되지 않았습니다. 널리 발견되기 전에 Android에서 패치가 필요한 보안 문제로 식별되지 않았기 때문에 포함시켰습니다. CVE-2022-38181의 경우 버그가 처음에 Android에 보고되었으며 ARM은 이 문제에 대한 보안 권고를 발표하여 다운스트림 사용자에게 패치를 적용해야 함을 나타냈습니다. 우리는 계속해서 오류의 "회색 영역"을 해독하려고 노력할 것이지만 오류를 추적하는 방법에 대한 의견을 환영합니다.
2021년의 브라우저는 어떤 모습일까요?
전체 수치와 유사하게, 실제 브라우저를 대상으로 탐지된 제로데이 수는 2021년부터 2022년까지 26개에서 15개로 42% 감소했습니다. 이는 공격을 더욱 어렵게 만들려는 브라우저의 노력을 반영한 것으로 평가됩니다. 전반적으로 공격자의 행동은 브라우저에서 장치의 다른 구성 요소를 대상으로 하는 제로 클릭 공격으로 이동하고 있습니다.
최고의 브라우저 방어 기술이 발전하면 다른 구성 요소를 공격 체인의 초기 벡터로 푸시하는 데 영향을 미칠 수 있습니다. 2022년 내내 더 많은 브라우저가 출시되고 악용에 대한 추가 방어 기능이 향상되는 것을 볼 수 있습니다. Chrome의 경우 이는 MiraclePtr, v8 Sandbox 및 libc++ 개선 사항입니다. Safari는 잠금 모드를 도입했고 Firefox는 더욱 세분화된 샌드박스를 도입했습니다. 공격적인 보안 공급업체인 Dataflow Security의 취약성 연구원이자 취약성 개발자인 안기찬은 2023년 4월 Zer0Con 기조연설에서 이러한 유형의 완화가 어떻게 브라우저 악용을 더욱 어렵게 만들고 사람들이 공격 표면을 다른 곳으로 보도록 유도하는지에 대해 언급했습니다.
브라우저는 악용하기가 점점 더 어려워지고 있으며 지난 몇 년 동안 악용 전달이 계속 발전해 2022년 브라우저 버그 수가 감소한 것을 설명합니다. 2019년과 2020년에는 야생에서 탐지된 제로데이의 상당 부분이 워터링 홀 공격을 통한 것이었습니다. 워터링 홀 공격은 공격자가 웹 사이트를 방문할 것으로 생각되는 사람들의 그룹을 표적으로 삼는 것입니다. 사이트를 방문하는 사람은 누구나 최종 페이로드(일반적으로 스파이웨어)를 악용하고 전달하게 됩니다. 2021년에는 원클릭 링크가 초기 공격 벡터가 되는 것을 흔히 볼 수 있습니다. 워터링 홀 공격과 원클릭 연결 모두 브라우저를 장치의 초기 벡터로 사용합니다. 2022년에는 더 많은 공격자가 사용자 상호 작용 없이 트리거될 수 있는 제로 클릭 익스플로잇에 눈을 돌리고 있습니다. 제로 클릭은 브라우저 이외의 장치 구성 요소를 대상으로 하는 경향이 있습니다.
2021년 말, Citizen Lab은 NSO가 Pegasus 스파이웨어에 사용한 iMessage를 대상으로 하는 제로클릭 취약점(CVE-2023-30860)을 포착했습니다. Project Zero는 두 부분으로 구성된 이 블로그 게시물 시리즈에서 취약점을 자세히 설명합니다. 2022년에 와일드 0 히트가 공개적으로 감지 및 공개되지 않았지만 그렇다고 사용량이 부족하다는 의미는 아닙니다. 우리는 다수의 공격자가 0-click 익스플로잇 체인을 사용했으며 현재 사용하고 있다는 것을 알고 있습니다.
제로 클릭은 다음과 같은 이유로 감지하기 어렵습니다.
-
수명이 짧다
-
일반적으로 그 존재에 대한 명백한 징후는 없습니다.
-
다양한 구성 요소가 대상이 될 수 있으며 공급업체는 원격으로 액세스할 수 있는 모든 구성 요소를 항상 인식하는 것은 아닙니다.
-
워터링홀 공격처럼 광범위하게 이용 가능하지 않고 대상에게 직접 전달
-
일반적으로 탐색 가능한 웹사이트나 서버에서 호스팅되지 않습니다.
원클릭 공격의 경우 대상은 공격을 전달하기 위해 표시되는 링크를 클릭해야 합니다. 이는 대상이나 보안 도구가 링크를 감지할 수 있음을 의미합니다. 그런 다음 이 링크는 탐색 가능한 서버에서 공격을 호스팅하는 데 사용됩니다.
반면에 제로 클릭은 일반적으로 들어오는 전화나 메시지를 처리하는 코드를 대상으로 합니다. 즉, 들어오는 메시지나 전화에 대한 표시기가 표시되기 전에 실행될 수 있는 경우가 많습니다. 이는 또한 수명과 "살아있는" 것을 감지할 수 있는 창을 크게 단축시킵니다. 공격자는 계속해서 제로클릭 공격을 시도할 가능성이 높으므로 방어자로서 우리는 이러한 공격을 감지하고 사용자를 보호하는 방법에 집중해야 합니다.
Deja Vu: 완전한 패치는 여전히 가장 큰 기회 중 하나입니다.
2022년 야생에서 발견된 41개의 제로데이 중 17개가 이전에 공개된 취약점의 변종이었습니다. 2020년 리뷰 보고서 "Deja vu-lnerability"에서 관련 내용을 처음으로 공개했는데, 2020년 이후 와일드 제로데이즈에서 발생한 25%가 이전에 공개된 버그의 변종임을 지적했습니다. 이 수치는 계속해서 증가하고 있는데, 그 이유는 다음과 같습니다.
-
방어자들은 변종을 식별하는 데 점점 더 능숙해지고 있습니다.
-
Defender는 야생에서 제로데이 변종을 탐지하는 능력을 향상시켰습니다.
-
공격자가 더 많은 변종을 활용하고 있습니다.
-
취약점 수정은 충분히 포괄적이지 않으므로 더 많은 변형이 존재합니다.
대답은 아마도 위의 모든 사항을 조합한 것일 것입니다. 그러나 우리는 사용자가 악용할 수 있는 제로데이 변종의 수가 줄어들지 않는다는 것을 알고 있습니다. 악용 가능한 변종의 수를 줄이는 것은 기술 및 보안 산업에서 가장 큰 기회 영역 중 하나이므로 공격자는 제로 데이 취약점을 악용하기 위해 더 열심히 노력해야 합니다.
2020년 와일드 0day 변형이 40%를 초과할 뿐만 아니라 20%를 초과하는 버그는 모두 이전 와일드 0day의 변형입니다(2021년에 7개, 2020년에 1개). 제로데이는 야생에서 잡혀서 선물이 됩니다. 공격자는 자신이 어떤 취약점을 갖고 있는지, 어떤 공격 기법을 사용하고 있는지 우리가 알기를 원하지 않습니다. 방어자는 이 능력을 최대한 활용하고 공격자가 0day 취약점을 다시 악용하는 것을 최대한 어렵게 만들어야 합니다. 여기에는 다음이 포함됩니다.
-
공격자가 이 상황에서 이를 악용하기 위해 선택한 방식뿐만 아니라 실제 근본 원인을 찾기 위해 오류를 분석합니다.
-
동일한 오류가 존재할 수 있는 다른 위치를 찾아보세요.
-
버그를 악용하는 데 사용할 수 있는 다른 경로를 평가합니다.
-
패치를 실제 근본 원인과 비교하고 해결 방법이 있는지 확인합니다.
패치가 정확하고 포괄적인 경우에만 패치가 완료된 것으로 간주합니다. 올바른 패치는 버그를 완전히 정확하게 수정하는 패치입니다. 즉, 더 이상 취약점이 악용되는 것을 허용하지 않습니다. 모든 변형을 포함하여 수정 사항을 적용해야 하는 모든 곳에 포괄적인 패치가 적용됩니다. 단일 취약점이나 버그가 악용되는 경우 취약점을 트리거하는 방법이 여러 가지이거나 취약점에 액세스하는 경로가 여러 가지인 경우가 많습니다. 공급업체가 취약점을 전체적으로 해결하기보다는 개념 증명이나 공격 사례에 표시된 경로만 차단하는 경우가 너무 많습니다. 마찬가지로 보안 연구원들은 패치 작동 방식에 대한 후속 조치나 관련 공격 조사 없이 버그를 보고하는 경우가 많습니다.
불완전한 패치로 인해 공격자가 제로데이를 더 쉽게 악용할 수 있다는 생각이 사람들을 불편하게 만들 수도 있지만, 이 결론의 이면은 우리에게 희망을 줄 수 있습니다. 우리는 제로데이를 더욱 어렵게 만드는 명확한 길을 갖고 있습니다. 더 많은 취약점이 정확하고 포괄적으로 패치되면 공격자가 제로데이를 악용하기가 더 어려워질 것입니다.
아래 표에는 식별된 모든 취약점 변형이 나열되어 있습니다. 실제 제로데이가 어떻게 변형되는지 자세히 살펴보려면 FIRST 컨퍼런스 프레젠테이션[비디오, 슬라이드], Zer0Con 슬라이드, OfffectiveCon 프레젠테이션[비디오, 슬라이드] CVE-2022-41073을 확인하세요. , CVE-2022-22620에 대한 이 블로그 게시물이 있습니다.
제품 |
2022 ITW CVE |
변종 |
윈도우즈 win32k |
CVE-2022-21882 |
CVE-2021-1732(2021 itw) |
iOS IOMobileFrameBuffer |
CVE-2022-22587 |
CVE-2021-30983(2021 itw) |
웹킷 “좀비” |
CVE-2022-22620 |
버그는 원래 2013년에 수정되었으며, 패치는 2016년에 재발되었습니다. |
파이어폭스 웹GPU IPC |
CVE-2022-26485 |
2021년에 해결된 퍼징 충돌 |
ARM Mali GPU의 Android |
CVE-2021-39793 CVE-2022-22706 |
CVE-2021-28664(2021 itw) |
소포스 방화벽 |
CVE-2022-1040 |
CVE-2020-12271(2020 itw) |
크롬 v8 |
CVE-2022-1096 |
CVE-2021-30551(2021 itw) |
크롬 |
CVE-2022-1364 |
CVE-2021-21195 |
윈도우 '쁘띠포탐' |
CVE-2022-26925 |
CVE-2021-36942 – 패치가 재발되었습니다. |
윈도우 '폴리나' |
CVE-2022-30190 |
CVE-2021-40444 (2021년 2월) |
아틀라시안 컨플루언스 |
CVE-2022-26134 |
CVE-2021-26084(2021 itw) |
크롬 인텐트 |
CVE-2022-2856 |
CVE-2021-38000(2021 itw) |
SSRF “ProxyNotShell” 교환 |
CVE-2022-41040 |
CVE-2021-34473 "프록시쉘" |
RCE "ProxyNotShell" 교환 |
CVE-2022-41082 |
CVE-2023-21529 "프록시쉘" |
인터넷 익스플로러 JScript9 |
CVE-2022-41128 |
CVE-2021-34480 |
Windows “인쇄 스풀러” |
CVE-2022-41073 |
CVE-2022-37987 |
웹킷 JSC |
CVE-2022-42856 |
2016년 테스트 실패로 인한 버그 발견 |
악용은 저작권으로 보호되지 않습니다
세계의 많은 상품과 달리 제로데이 자체는 제한이 없습니다. 한 사람이 제로데이 취약점의 존재를 발견하고 이를 익스플로잇으로 개발한다고 해서 다른 사람도 독립적으로 이를 발견하고 익스플로잇에 사용하는 것을 막을 수는 없습니다. 자체적으로 취약성을 연구하고 악용 개발을 수행하는 대부분의 공격자는 다른 사람이 동일한 작업을 수행하는 것을 원하지 않습니다. 이로 인해 가치가 감소하고 신속하게 감지 및 수정될 가능성이 높아지기 때문입니다.
지난 몇 년 동안 우리는 한 명 이상의 연구원이 동일한 취약점을 발견하는 대규모 버그 충돌 추세를 인식하게 되었습니다. 이는 벤더와 보안 연구원에게 버그를 보고하는 공격자 사이에서 발생합니다. 버그 충돌은 항상 발생하며 발생하는 정확한 비율을 측정할 수는 없지만, 보안 권고에서 동일한 취약점으로 독립적으로 식별된 서로 다른 엔터티의 수, 두 개의 서로 다른 취약점에서 발견된 동일한 0일, 심지어 대화에서도 마찬가지입니다. 연구자들은 이러한 일이 더 자주 발생한다고 제안합니다.
허위 충돌 수가 증가하면 공격자가 전체적으로 더 적은 수의 0days를 사용한다는 의미이므로 방어 측면에서 승리합니다. 공격 표면을 제한하고 악용 가능한 버그 클래스를 줄이는 것은 확실히 연구원들이 동일한 버그를 찾는 데 도움이 될 것이지만, 자신의 연구를 발표하는 더 많은 보안 연구원들도 기여할 수 있습니다. 사람들은 동일한 연구를 읽고 다음 프로젝트에 대한 아이디어를 촉발하지만 많은 사람들에게 유사한 아이디어가 촉발됩니다. 플랫폼과 공격 표면도 점점 복잡해지고 있어 새로운 구성 요소나 대상에 대한 전문 지식을 구축하려면 상당한 시간 투자가 필요합니다.
보안 연구원과 취약성 보고서는 공격자가 사용하는 것과 동일한 0일을 수정하는 데 도움을 주며, 이러한 특정 0일이 아직 실제로 감지되지 않았더라도 이를 통해 공격자의 취약성을 손상시킬 수 있습니다. 우리는 공급업체가 계속해서 연구원을 지원하고 버그 포상금 프로그램에 투자하기를 바랍니다. 이는 사용자를 대상으로 할 수 있는 동일한 취약점을 수정하는 데 도움이 되기 때문입니다. 또한 보안 연구원이 알려진 자연적인 버그와 취약점을 철저히 패치하는 것이 왜 중요한지 강조합니다.
우리는 지금 무엇을해야합니까?
2022년을 되돌아보면 우리의 전반적인 결론은 업계가 올바른 길을 가고 있지만 많은 기회 영역이 있으며 그 중 가장 큰 것은 보고된 취약점에 대한 업계의 대응이라는 것입니다.
- 사용자가 스스로를 보호할 수 있도록 수정 사항과 완화 조치를 신속하게 제공해야 합니다.
- 우리는 취약점의 근본 원인이 해결되었는지 확인하기 위해 상세한 분석을 수행해야 합니다.
- 우리는 가능한 한 많은 기술적인 세부 사항을 공유해야 합니다.
- 우리는 보고된 취약점을 활용하여 가능한 한 많이 배우고 수정해야 합니다.
이 중 어느 것도 쉬운 일이 아니며 이 분야에서 일하는 보안 팀에게는 놀라운 일이 아닙니다. 사용자를 신속하게 보호하는 것과 포괄적인 보장 사이에서 균형을 맞추는 패치 프로세스에 대한 투자, 우선 순위 지정 및 개발이 필요하며 이는 때때로 스트레스가 될 수 있습니다. 필요한 투자는 각 상황에 따라 다르지만 인력/리소스, 인센티브 구조, 프로세스 성숙도, 자동화/테스트, 릴리스 흐름 및 파트너십과 관련된 몇 가지 공통 주제가 있습니다.
이 게시물에서는 근본 원인, 패치, 변종 및 악용 기술 분석을 포함하여 버그를 적절하고 포괄적으로 수정하는 데 도움이 되는 몇 가지 노력에 대해 자세히 설명합니다. 우리는 이러한 분석을 수행하는 데 계속 도움을 줄 것이지만, 플랫폼 보안 팀과 기타 독립적인 보안 연구원들도 이러한 노력에 투자하기를 희망하고 장려합니다.
최종 생각: TAG의 새로운 익스플로잇 팀
2023년 하반기를 바라보며 앞으로 어떤 일이 일어날지 기대됩니다. 이전 보고서가 Plan Zero 블로그에 게시되었음을 알 수 있습니다. 당사의 0day in the wild 프로그램은 취약성 분석, 탐지 및 위협 행위자 추적 전문 지식을 하나의 팀으로 통합하고 추가 리소스를 활용하여 궁극적으로 다음을 달성하기 위해 프로그램 0에서 TAG로 이동했습니다. TAG 취약성! 앞으로 더 많은 기능이 제공될 예정이지만 이것이 제로데이 공격으로부터 사용자를 보호하고 제로데이 공격을 어렵게 만드는 데 어떤 의미가 있는지 매우 기대됩니다.
출처: https://security.googleblog.com/2023/07/the-ups-and-downs-of-0-days-year-in.html
xbear의 원본 기사, 복제 시 출처 표시: https://cncso.com/kr/연도-0일의-기복-in-html