CVE to skrót od Common Vulnerabilities and Exposures i globalny katalog referencyjny publicznie znanych podatności bezpieczeństwa. Program prowadzi MITRE Corporation od 1999 roku, a finansuje go amerykańska agencja cyberbezpieczeństwa CISA. Każda podatność otrzymuje unikalny identyfikator w formacie CVE-ROK-NUMER, na przykład CVE-2021-44228 dla Log4Shell, dzięki czemu producenci, skanery, badacze i artykuły prasowe mówią o tej samej luce. Identyfikatory nadaje kilkaset CVE Numbering Authorities (CNA) na całym świecie. Wagę danego CVE ocenia się w Common Vulnerability Scoring System (CVSS), skali od 0.0 do 10.0 rozwijanej przez FIRST: od 9.0 ocena brzmi Critical, od 7.0 do 8.9 High, od 4.0 do 6.9 Medium, a poniżej Low. Skala zjawiska rośnie gwałtownie: w samym 2024 roku opublikowano ponad 40 000 nowych CVE, a w ekosystemie WordPressa ujawniono w 2024 roku niespełna 8 000 podatności, z czego około 96 procent dotyczyło wtyczek.
Co oznacza skrót CVE?
Zanim powstało CVE, każdy dostawca zabezpieczeń opisywał podatności własnymi słowami i nikt nie potrafił stwierdzić, czy przepełnienie bufora z jednego biuletynu to ten sam błąd co zdalny exploit z innego. Program Common Vulnerabilities and Exposures, uruchomiony przez MITRE w 1999 roku, rozwiązał to czymś pozornie banalnym: jedną unikalną nazwą na lukę. Rekord CVE zawiera ten identyfikator, krótki opis, odnośniki do biuletynów i poprawek oraz listę produktów, których dotyczy.
Format identyfikatora to CVE-ROK-NUMER, gdzie rok oznacza rok nadania, niekoniecznie odkrycia, a numer ma cztery cyfry lub więcej. Oficjalna baza znajduje się pod adresem cve.org. Nad nią nadbudowana jest National Vulnerability Database (NVD), prowadzona przez amerykański instytut standardów NIST, która wzbogaca rekordy CVE o oceny wagi, zakresy podatnych wersji i klasyfikacje słabości. Gdy Twój skaner bezpieczeństwa pokazuje dane o wadze danego CVE, zwykle pochodzą właśnie z NVD.
Jak podatność dostaje identyfikator CVE?
Identyfikatory CVE nadają CVE Numbering Authorities, w skrócie CNA. To producenci oprogramowania, firmy bezpieczeństwa i organizacje badawcze upoważnione do nadawania identyfikatorów dla własnych produktów albo dla przypisanego im obszaru. Sieć rozrosła się do kilkuset CNA w kilkudziesięciu krajach, dlatego badacz, który znajdzie lukę na przykład w produkcie Cisco, zgłasza ją bezpośrednio do Cisco, a Cisco samo nadaje numer CVE.
Typowy przebieg wygląda tak: badacz odkrywa podatność i zgłasza ją właściwemu CNA, CNA rezerwuje identyfikator CVE na czas przygotowywania poprawki, a gdy poprawka trafia do użytkowników, rekord jest publikowany razem z biuletynem. Ta faza rezerwacji tłumaczy, dlaczego czasem widzisz publicznie wspomniany numer CVE, przy którym nie ma jeszcze żadnych szczegółów.
Dla użytkowników WordPressa jest tu istotny szczegół: Wordfence, WPScan i Patchstack są CNA. Zdecydowana większość numerów CVE dla wtyczek i motywów WordPress pochodzi od jednej z tych trzech organizacji, dlatego właśnie ich bazy podatności są najpełniejszym źródłem dla ekosystemu WordPressa.
Czym jest ocena CVSS?
Sama nazwa nie mówi, jak groźna jest dana luka. Od tego jest Common Vulnerability Scoring System, otwarty standard rozwijany przez FIRST, światowe stowarzyszenie zespołów reagowania na incydenty. CVSS sprowadza techniczną charakterystykę podatności do oceny między 0.0 a 10.0. Wersja 2 pojawiła się w 2007 roku, wersja 3.0 w 2015, uściślenie 3.1 w 2019, a wersja 4.0 w listopadzie 2023 roku. W praktyce większość baz i biuletynów mówi nadal językiem CVSS 3.1, a adopcja wersji 4.0 rośnie powoli.
Oceny wagi CVSS od None do Critical
| Ocena | Wynik CVSS | Typowe znaczenie |
|---|---|---|
| None | 0.0 | Brak wpływu |
| Low | 0.1 do 3.9 | Trudna do wykorzystania albo o bardzo ograniczonym wpływie |
| Medium | 4.0 do 6.9 | Realny wpływ, ale przy spełnieniu warunków, takich jak interakcja użytkownika lub posiadane uprawnienia |
| High | 7.0 do 8.9 | Poważny wpływ, często ujawnienie danych lub eskalacja uprawnień |
| Critical | 9.0 do 10.0 | Zwykle zdalne wykorzystanie bez uwierzytelnienia i pełne przejęcie |
Osławione 9.8, które widzisz w tylu biuletynach, to charakterystyczna ocena zdalnego wykonania kodu bez uwierzytelnienia: osiągalne przez sieć, bez uprawnień, bez potrzeby interakcji użytkownika. Pełne 10.0 dodatkowo wychodzi poza podatny komponent do innych systemów, co udało się właśnie luce Log4Shell.
Jak liczy się ocenę CVSS?
Ocena bazowa wynika z kilku metryk opisujących, jak można dosięgnąć luki i co ona psuje. Po stronie możliwości wykorzystania są to: Attack Vector (sieć, sąsiednia sieć, lokalnie, fizycznie), Attack Complexity, Privileges Required i User Interaction. Po stronie skutków: wpływ na Confidentiality, Integrity i Availability, a w wersji 3.1 dodatkowo metryka Scope, która oddaje to, czy szkoda przechodzi na inne komponenty. Poszczególne wybory zapisuje się w zwięzłym ciągu wektora, który znajdziesz przy każdym wpisie w NVD:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
AV:N osiągalne przez sieć
AC:L niska złożoność ataku
PR:N brak wymaganych uprawnień
UI:N brak potrzebnej interakcji użytkownika
S:U zakres niezmieniony
C:H/I:H/A:H wysoki wpływ na poufność, integralność, dostępność
Wynik: ocena bazowa 9.8, CriticalZaletą wektora jest to, że mówi więcej niż sama liczba. Ocena 7.5 z PR:N i 7.5 z PR:H to dla Twojego modelu zagrożeń zupełnie różne zwierzęta, a odczytanie wektora zajmuje dziesięć sekund, gdy znasz już skróty.
Co nowego w CVSS 4.0?
Wersja 4.0 odpowiada na najczęstszą krytykę wersji 3.1. Zniknęła myląca metryka Scope, zastąpiona osobnymi ocenami wpływu na system podatny i na systemy następcze. User Interaction jest teraz bardziej zniuansowana, z wariantem pasywnym i aktywnym, a nowa metryka Attack Requirements opisuje warunki, które muszą zaistnieć po stronie celu. Dawne metryki czasowe przerobiono na metryki zagrożenia, a standard nazywa teraz wprost odmiany oceny: CVSS-B dla samej oceny bazowej, CVSS-BT z danymi o zagrożeniu i CVSS-BE z kontekstem środowiskowym. Koncepcyjnie to wszystko krok naprzód. Praktycznie ekosystem zmienia się powoli, więc wektory 3.1 będziesz czytać jeszcze przez lata.
Dlaczego wysoka ocena CVSS to nie automatycznie Twoje największe ryzyko
Oto niewygodna prawda o CVSS: mierzy wagę, a nie prawdopodobieństwo. Przytłaczająca większość opublikowanych CVE nigdy nie zostaje wykorzystana w praktyce, a jednocześnie część luk z oceną średnią jest atakowana w ciągu godzin, bo exploit jest publiczny, a cel wszechobecny. Tę lukę pomagają zasypać dwa zbiory danych. Ocena EPSS, również od FIRST, szacuje na podstawie realnej telemetrii prawdopodobieństwo wykorzystania podatności w ciągu najbliższych 30 dni. A katalog CISA KEV wymienia podatności z potwierdzonym wykorzystaniem, co jest najmocniejszym dostępnym sygnałem.
Praktyczna zasada ustalania priorytetów dla właściciela witryny: łataj najpierw to, co jest w KEV albo ma wysoką ocenę EPSS i siedzi w komponencie wystawionym do internetu. Ocena 9.8 we wtyczce, którą wyłączyłeś rok temu, znaczy mniej niż 7.5 we wtyczce formularza kontaktowego dostępnej dla każdego odwiedzającego. Waga to kwestia kontekstu, a Twój kontekst znasz tylko Ty.
Podatności CVE w ekosystemie WordPressa
Sam rdzeń WordPressa jest dziś trudnym celem i odpowiada za znacznie mniej niż jeden procent ujawnianych podatności. Wszystko dzieje się w ekosystemie rozszerzeń: według Patchstack w 2024 roku ujawniono w ekosystemie WordPressa niespełna 8 000 nowych podatności, z czego mniej więcej 96 procent we wtyczkach, a większość reszty w motywach. Najczęstsze kategorie to cross-site scripting, cross-site request forgery i błędna kontrola dostępu. Nie znaczy to, że WordPress jest niebezpieczny, znaczy to, że o bezpieczeństwie Twojej witryny decyduje to, jakie wtyczki instalujesz i jak szybko je aktualizujesz. Wtyczka ze 100 000 instalacji i znaną, niezałataną luką staje się celem masowego skanowania w ciągu dni, czasem godzin.
Znane przykłady podatności CVE
- CVE-2014-0160, Heartbleed: wyciek pamięci w OpenSSL, który pozwalał atakującym odczytywać klucze prywatne z serwerów. Błąd, od którego podatności zaczęły dostawać logo i nazwy.
- CVE-2017-0144, EternalBlue: luka w SMB stojąca za falą ransomware WannaCry w 2017 roku.
- CVE-2021-44228, Log4Shell: ocena CVSS 10.0 w bibliotece logowania Log4j dla Javy. Jeden spreparowany ciąg w dowolnym logowanym polu prowadził do zdalnego wykonania kodu, a pół internetu logowało dane od użytkowników.
- CVE-2023-4966, Citrix Bleed: wyciek tokenów sesji w Citrix NetScaler, wykorzystywany przez grupy ransomware przeciwko tysiącom urządzeń.
Jak InspectWP wykorzystuje dane CVE?
InspectWP wykrywa wtyczki i motywy analizowanej witryny WordPress i zestawia je ze znanymi danymi o podatnościach, dzięki czemu raport potrafi powiedzieć, że konkretny zainstalowany komponent ma opublikowane CVE, jak poważne ono jest i że dostępna jest aktualizacja. Zamyka to irytującą lukę między istnieniem CVE gdzieś w bazie danych a Twoją wiedzą o tym, że dotyczy ono jednej z Twoich stron. W połączeniu z zaplanowanymi raportami automatycznymi dostajesz praktyczną wersję zarządzania podatnościami dla WordPressa: wiedz, co uruchamiasz, wiedz, co jest zepsute, i aktualizuj najpierw to, co naprawdę ma znaczenie.