Seria Kompendium wiedzy ma na celu zebranie podstawowych informacji oraz przydatnych linków w jednym miejscu, aby każdy mógł w pełni zrozumieć wybrany temat oraz samodzielnie go zbadać. W pierwszym artykule zajmiemy się podatnościami - podstawowe definicje, wprowadzenie do oceny CVSS oraz jak rozszyfrować informacje, które można znaleźć przy każdej z nich.
Ze względu na fakt, że spolszczanie niektórych sformułowań jest…okropne, będę umieszczać w nawiasach angielskie sformułowania, odpowiadające spolszczeniu. Nie będę używać też języka polskiego na siłę, więc w niektórych miejscach zostawiam oryginalne zwroty.
Czym jest podatność (vulnerability)?
Najkrócej mówiąc, jest to słabość w systemie informatycznym wykorzystywana przez tzw. cyberprzestępców (threat actors). Podatność może istnieć w systemie, w oprogramowaniu (software) lub bezpośrednio w fizycznym urządzeniu (hardware).
Powszechne typy ataków/luk, które wykorzystują podatności
-
Brak poprawnej walidacji wprowadzanych danych (input validation)
- Wstrzyknięcie kodu (code injection)
- SQL (SQL injection)
- komendy systemowe (OS injection)
- Cross-site scripting (XSS)
- Path traversal
- XML External Entity (XXE)
- Wstrzyknięcie kodu (code injection)
-
Błędnie zaprojektowany system/oprogramowanie
- Brak szyfrowania danych
- Brak autentykacji dla funkcji krytycznych oprogramowania
- Brak autoryzacji
- Używanie skompromitowanych algorytmów szyfrowania (np. DES)
- Ustawienie haseł podatnych na ich odgadnięcie (ataki typu bruteforce)
- Bugi
- Brak weryfikacji sum kontrolnych pobieranych pakietów np. aktualizujących oprogramowanie
-
Błędy w pamięci
- Przepełnienie bufora (buffer overflow) - zapisanie przez programistę nadprogramowych, nieprzewidzianych danych w określonym miejscu w pamięci.
-
Hardware
- Side-channel attack - analiza parametrów fizycznych (pobór prądu, temperatura, czas wykonywania żądań, fale elektromagnetyczne), aby obejść zabezpieczenia. Przykładem może być analiza temperatury przycisków terminala, w celu otrzymania kodu PIN kupującego.
-
Eskalacja uprawnień (priviledge escalation) - wykonanie żądania aplikacji/atakującego przez aplikację uprzywilejowaną np. systemową na prawach systemu.
Najbardziej niebezpiecznymi podatnościami są takie, które po ich wykorzystaniu pozwalają na zdalne wykonanie kodu (RCE - remote code execution). Pozwala to atakującemu działać w systemie/oprogramowaniu niezauważalnie, szpiegować ofiarę przez długi czas, rozdystrybuować przygotowane złośliwe oprogramowanie (malware), infekować powiązane urządzenia w sieci, przeprowadzać rekonesans itd. Przy wykryciu podatności RCE w swoim oprogramowaniu należy niezwłocznie ją przeanalizować oraz jeśli to możliwe - wdrożyć zalecenia producenta.
Co zawiera w sobie opis podatności?
W opisie podatności (na stronie producenta, w bazie NVD (National Vulnerability Database), w Mitre) można znaleźć:
- Krótką informację o podatności lub luce.
- Numer CVE.
- Podatne wersje systemów/oprogramowania.
- Zalecane możliwości złagodzenia wpływu podatności (mitigation) i jej obejścia (workaround).
- Wycena dotkliwości (Severity) wykrytej podatności.
- Określenie możliwości wykorzystania podatności oraz jej wpływu za pomocą CVSS (Common Vulnerability Scoring System).
- Referencje, odnośniki do strony producenta, linki do Proof of Concept/Exploit’ów w sieci.
- Wskazanie kategorii CWE (Common Weakness Enumeration), w której nie dopilnowano dobrych manier w zabezpieczaniu oprogramowania dla danej podatności.
Gdzie można zgłosić odkrytą podatność?
Bug Bounty
Jeśli zauważy się jakąkolwiek nieprawidłowość techniczną działania oprogramowania/systemu, która może naruszyć bezpieczeństwo, to zawsze można to zgłosić organizacji poprzez tzw. program Bug Bounty.
Bug Bounty jest to akcja stworzona przez firmy, która ma na celu zachęcić do zgłaszania podatności przez osoby z zewnątrz poprzez wynagrodzenie pieniężne, znalezienie się na liście sławy, gadżety itd. Popularnymi korporacjami, które aktywnie je prowadzą są np. Facebook, Google, Paypal, Spotify itd. Najczęściej formę zgłaszania przez Bug Bounty wybierają obeznani w temacie tzw. bug hunter, którzy na co dzień szukają dziur w całym w oprogramowaniu.
Całkiem sporą listę programów bug bounty można znaleźć na stronie BugCrowd.
security.txt
Drugą możliwą opcją, jest sprawdzenie pliku security.txt na stronie web serwisu/firmy/producenta. Ten plik walczy o prawa standardu RFC - jego celem jest ułatwienie komunikacji z analitykami bezpieczeństwa z różnych środowisk, którzy zauważyli jakąś nieprawidłowość i chcieliby ją zgłosić do osoby odpowiedzialnej za wadliwy komponent.
Ten plik można znaleźć wpisując dane ścieżki:
https://example.com/.well-known/security.txt
lub
https://example.com/security.txt
Plik security.txt składa się zazwyczaj z pól:
- Contact - specjalna skrzynka mailowa, adres strony do zgłaszania bugów
- Encryption - wskazanie klucza PGP do bezpiecznej komunikacji z działem cyberbezpieczeństwa
- Acknowledgments - wskazanie na galerie sław, podziękowania dla badaczy
Dodatkowo można znaleźć:
- Preffered-Languages - wskazanie w jakim języku najlepiej się komunikować
- Canonical - wskazanie adresu URL na którym jest plik security.txt
- Policy - wskazanie na ustaloną politykę zgłaszania bugów, niuansów prawnych, reguł itd.
- Hiring - miejsce na podzielenie się ofertą pracy dla “bezpieczników”
W sieci można znaleźć oficjalną stronę pomysłu security.txt, która udostępnia kreator umożliwiający stworzenie tego pliku wedle ustalonych reguł - Securitytxt.org.
Przykładowe strony, które mają umieszczone security.txt:
- Google -
https://google.pl/.well-known/security.txt
- Niebezpiecznik -
https://niebezpiecznik.pl/security.txt
Trzeba pamiętać, że nie jest to przyjęty ogólnie standard, stosowanie security.txt jest dobrą manierą, więc można się napotkać na brak tego pliku w innych firmach/korporacjach. Idea jest wciąż rozwijana.
CVE - Common Vulnerabilities and Exposures
Jest to lista unikalnych podatności oraz luk, które są kategoryzowae ustalonym oraz globalnym schematem. Celem CVE jest ułatwienie dzielenia się informacjami o podatnościach dla ludzi/narzędzi/usług/repozytoriów, stosując ich unikalną numerację - tzw. CVE ID.
Aby otrzymać CVE ID należy zgłosić się do CVE Numbering Authorities (CNAs) wedle instrukcji: https://cve.mitre.org/cve/request_id.html
Zazwyczaj prośby o numery CVE ID są zgłaszane przez producentów, a osoba zgłaszająca podatność jest wyręczona z tego obowiązku.
Więcej o systemie CVE można przeczytać tutaj.
Severity
Dzięki wycenie severity można szybko ocenić możliwy wpływ podatności, gdyby została ona wykorzystana. Jest określane w skali:
| Severity | Points |
|---|---|
| None | 0.0 |
| Low | 0.0-3.9 |
| Medium | 4.0-6.9 |
| High | 7.0-8.9 |
| Criticial | 9.0-10.0 |
Im większa liczba punktów, tym podatność ma większy wpływ na bezpieczeństwo podatnego systemu/oprogramowania. Punkty są przydzielane na podstawie systemu punktowania podatności CVSS.
Mitygacja
Odpowiednio mitygując zagrożenie, jesteśmy w stanie ograniczyć jego potencjalne skutki, gdyby atakujący wykorzystał daną podatność przeciwko nam. Takimi działaniami może być np. przeprowadzenie aktualizacji, ustawienie dodatkowej konfiguracji, detekcja ruchu w systemach bezpieczeństwa dzięki odpowiednio zbudowanej regule itd.
Workaround jest czasem wskazywany przez producenta jako możliwa mitygacja zagrożenia, poprzez np. nie korzystanie z podatnego komponentu.
aktualizacja > workaround oficjalny (producenta) > workaround nieoficjalny (pasjonatów)
Aby mieć pewność, że podatność nie zostanie wykorzystana nawet po aktualizacji, warto zaimplementować detekcje próby wykorzystania np. specjalną sygnaturą/regułą od np. producenta w systemie IDS (Intrusion Detection System).
CVSS - Common Vulnerabilities Scoring System
CVSS jest systemem punktowania podatności w skali od 0-10, którą wykorzystuje severity do określenia poziomów ważności wykrytych luk. Obecnym standardem jest punktowanie CVSS w wersji 3.1 - wersje te odnoszą się do poprawek oceniania i podliczania punktów przez określony algorytm.
CVSS bazuje na trzech metrykach: Base, Temporal, Environmental.
Metryka Base wskazuje na jej domyślną wycene, niezależnie od sytuacji osoby/firmy, która akurat podatność posiada. W niej wyróżnia się metryki wpływu (Impact) oraz możliwości jej użycia w złych celach (Exploitability).
Metryka Temporal bierze pod uwagę pojawienie się możliwości aktualizacji podatności (powoduje to obniżenie punktacji w tej metryce), wystąpienie eksploit’a publicznie dostępnego w sieci (punktacja rośnie).
Z kolei Environmental skupia się na konkretnej sytuacji w firmie lub u użytkownika. W niej wskazuje się, czy jesteśmy w stanie załagodzić/obejść podatność czy też nic nie możemy zdziałać sami, aby się przed jej konsekwencjami obronić.
Metryki Temporal oraz Environmental są opcjonalne przy wyliczaniu punktacji, lecz są przydatne przy głębszej analizie wpływu podatności.
Dla każdej z tych trzech głównych metryk są określone podkategorie np. Wektor ataku (Attack Vector), dla których są ustalone parametry do wybrania. Poniżej w tabelach z opisami podkategorii w nawiasach są umieszczone skróty, które odpowiadają oznaczeniom w takiej formie zapisu CVSS, z którą najczęściej można się spotkać:
Każda podkategoria w tym ciągu znaków jest rozdzielana za pomocą /, a po : znajduje się wybrany parametr. Powyżej podany przykład dokładnie opiszę w dalszej części, na postawie podatności CVE-2020-0796 tzw. “CoronaBlue”.
Na potrzeby artykułu skupię się głównie na opisie podkategorii dla metryki Base.
Opisy podkategorii dla metryki Base
Wektor ataku (Attack Vector) - wskazuje na potencjalne źródło ataku oraz możliwość jego rozprzestrzeniania.
| Attack Vector (AV) | Opis |
|---|---|
| Network (N) | Podatność jest dostępna z zewnątrz w sieci dla atakującego oraz można ją rozpropagować po Internecie - jest możliwa do eksploitacji zdalnie (przykładem ataki DDoS). |
| Adjacent (A) | Podatność jest dostępna z sieci, lecz atakujący musi być w tej samej sieci fizycznej (np. w sieci lokalnej LAN, połączeniu Bluetooth) oraz dystrybucja ataku jest ograniczona do sąsiadującej topologii. |
| Local (L) | Podatny komponent nie jest dostępny z poziomu sieci, lecz np. po SSH, linii komend lub wymaga fizycznego dostępu do klawiatury i myszki. W ten parametr wlicza sie dodatkowo socjotechnikę, gdy atakujący liczy na otworzenie złośliwego załącznika przez użytkownika. |
| Phisical (P) | Atakujący osobiście, mając fizyczny kontakt ze sprzętem, manipuluje wrażliwym komponentem by wykorzystać podatność np. (Evil Maid Attack). |
Trudność ataku (Attack Complexity) - wskazuje na poziom trudności wykonania poszczególnych czynności, które zostaną podjęte w celu wykorzystania podatności.
| Attack Complexity (AC) | Opis |
|---|---|
| Low (L) | Wykorzystanie podatności przez atakującego nie wymaga zaawansowanej wiedzy oraz zdolności. |
| High (H) | Atakujący, aby wykorzystać podatność, musi podjąć wiele dodatkowych kroków, które mogą zwiększać ryzyko niepowodzenia/wykrycia jego działań - czyli np. wzbogacić wiedzę o infrastrukturze, konfiguracji podatnego systemu, podjąć się dodatkowych działań, mających na celu rekonesans. |
Wymagane uprawnienia (Privileges Required) - wskazuje jakie uprawnienia musi posiadać atakujący przed wykorzystaniem podatności, aby wykonać atak.
| Privileges Required (PR) | Opis |
|---|---|
| None (N) | Atakujący nie potrzebuje żadnych uprawnień, aby wykorzystać podatność. |
| Low (L) | Atakujący nie potrzebuje wysokich uprawnień, wystarczy mu dostęp do poświadczeń użytkownika. |
| High (H) | Atakujący potrzebuje uprawnień na prawach administratora/root’a aby wykorzystać podatność. |
Interakcja użytkownika (User Interaction) - wskazuje na potrzebę działań użytkownika (otwarcie złośliwego pliku, linku, strony etc.) lub jej brak, aby wykorzystać podatność.
| User Interaction (UI) | Opis |
|---|---|
| None (N) | Atakujący może działać bez potrzeby interakcji z użytkownikiem. |
| Required (R) | Atakujący musi nakłonić socjotechniką użytkownika do podjęcia nieprzemyślanych działań. W tym parametrze uwzględnia się też instalowanie/uruchamianie oprogramowania na prawach administratora przez użytkowników. |
Zasięg (Scope) - wskazuje na możliwe pole rażenia, jeśli atakujący wykorzysta podatność - czy może wpłynąć na inne komponenty/zasoby, które są poza normalnymi możliwościami zaatakowanego komponentu.
| Scope (S) | Opis |
|---|---|
| Changed (C) | Wykorzystanie podatności dotyka inne komponenty poza tym zaatakowanym. |
| Unchanged (U) | Wykorzystanie podatności wpływa tylko na podatny komponent. |
Poufność (Confidentially) - wykazuje, czy atakujący ma dostęp do danych wrażliwych (np. numery PESEL) po wykonaniu ataku.
| Confidentially (C) | Opis |
|---|---|
| High (H) | Atakujący może uzyskać dostęp do danych wrażliwych/poufnych/tajnych, haseł, kluczy szyfrujących. |
| Low (L) | Atakujący ma dostęp do nieokreślonych danych, lecz nie są one krytyczne w działaniu systemu/usługi - mogą skutkować obniżoną reputacją, w razie wycieku tych danych. |
| None (N) | Atakujący nie otrzyma dostępu do danych. |
Integralność (Integrity) - wykazuje, czy atakujący byłby w stanie modyfikować/usuwać/nadpisywać/tworzyć pliki/konfiguracje/dane po wykorzystaniu podatności.
| Integrity (I) | Opis |
|---|---|
| High (H) | Atakujący może wpływać na integralność danych wszystkich plików lub tych kluczowych do działania podatnego komponentu. |
| Low (L) | Atakujący może wpływać na ograniczoną liczbę plików, albo ma ograniczoną liczbę możliwości modyfikacji. |
| None (N) | Atakujący nie otrzyma możliwości wpływania na integralność danych. |
Dostępność (Availability) - wpływa na dostępność podatnego komponentu po wykorzystaniu podatności przez atakującego.
| Availability (A) | Opis |
|---|---|
| High (H) | Atakujący może swobodnie wpływać na dostępność działania komponentu - może spowodować np. DDOS, lub wyłączyć dostępność usługi dla wszystkich użytkowników. |
| Low (L) | Atakujący może wpływać na dostępność działania komponentu, lecz nie jest w stanie tego w pełni kontrolować - np. może uniemożliwić dostęp do usługi tylko wybranym użytkownikom. |
| None (N) | Atakujący nie otrzyma możliwości wpływania na dostępność komponentu. |
Przeliczanie metryk
Po uzupełnieniu powyższych pól, specjalnie opracowany algorytm przelicza uzyskane punkty i określa je w skali od 0-10.
Istnieją specjalnie przygotowane kalkulatory CVSS, które po wybraniu odpowiednich parametrów wyliczają wynik CVSS oraz generują wektor CVSS, o którym wspomniałam wcześniej.
Kalkulator CVSS - https://www.first.org/cvss/calculator/3.1
Więcej szczegółów o przeliczaniu konkretnych parametrów i zastosowanym algorytmie znajdziesz tutaj.
Czym jest Proof of Concept i Exploit?
Proof of Concept (PoC) jest zazwyczaj obszernym artykułem, pracą, przykładowym kodem, dowodem technicznym na możliwość skompromitowania celu, aby udowodnić powagę podatności. Często jest on publikowany dopiero po wyjściu aktualizacji, która łata podatność. Często nie oznacza zawsze ;)
Przykładowy PoC - https://github.com/eerykitty/CVE-2020-0796-PoC?files=1
Exploit jest to już przygotowane narzędzie/skrypt/program do przeprowadzenia ataku przez cyberprzestępców, bądź pentesterów. Do wykorzystania eksploit’u nie potrzeba obszernej analizy jak on działa. Bardzo często gotowymi rozwiązaniami cyberprzestępcy dzielą się w darkweb’ie, a dopiero potem są one dostępne publicznie (np. Github/Metasploit).
PoC może być również od razu exploitem!
Obszerną bazą exploit’ów jest strona https://www.exploit-db.com.
Aktywne działania cyberprzestępców, mające na celu stworzenie własnego exploit’u, określa się często jako “zbrojenie się” (Weaponization).
Security Researcher, który monitoruje rozwój zainteresowania podatnością, jest w stanie zwiększyć scoring CVSS (metryka Temporal), ze względu na istnienie PoC’a, exploit’a, bądź zauważą “zbrojenie się” cyberprzestępców. W procesie Threat Management’u priorytet działań mitygujących/naprawiających zwiększa się, a czas wdrożenia poprawek skraca się do trybu przyśpieszonego, w zależności od aktywności w temacie PoC’ów, exploit’ów dla podatności.
Rzadko kiedy producenci/właściciele wadliwego komponentu dzielą się takimi informacjami, częściej można znaleźć przypuszczenia, czy dana podatność jest łatwa do eksploatacji.
Microsoft nie chwali się, że exploit’y już są, tylko czy jest takie prawdopodobieństwo.
CWE - Common Weakness Enumeration
Jest to lista typowych słabości w oprogramowaniu/sprzęcie. Słabościami są podatności, luki, bugi, błędy itd. Jej celem, podobnie jak listy CVE, jest zebranie tych słabości w jedno miejsce, uporządkowanie ich wedle określonych reguł, aby zachować jednolity standard w przedstawianiu możliwych błędów w algorytmie/kodzie/hardware’rze na całym świecie. Ułatwia to pracę architektom systemów oraz badaczom bezpieczeństwa w zrozumieniu, jaki błąd popełniono.
Więcej o CWE tutaj.
Przykład opisu podatności - CoronaBlue CVE-2020-0796
Na koniec, zobaczymy ile da się wyciągnąć z biuletynu bezpieczeństwa odnośnie podatności, która zrobiła ostatnio duże zamieszanie w świecie security. A mowa o tzw. CoronaBlue, czyli podatności na protokół Microsoft Server Message Block (SMBv3), który zazwyczaj jest stosowany do udostępniania zasobów (drukarek, plików).
Przykuwa ona uwagę ze względu na fakt, że parę lat wcześniej podobne podatności na ten sam protokół, lecz w wersji 1 (SMBv1), wykorzystał jeden z najbardziej znanych ransomware - WannaCry (w 2017). Korzystał z podatności o numerach:
- CVE-2017-0143
- CVE-2017-0144
- CVE-2017-0145
- CVE-2017-0146
- CVE-2017-0147
- CVE-2017-0148
Ale wracając do tematu…
Biuletyn znajduje się tu: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0796
Na pierwszy rzut oka widać, że dla odkrytej podatności jest przydzielony numer CVE oraz, że można ją wykorzystać zdalnie, czyli prawdopodobnie Severity jest na poziomie Critical (9-10). Dodatkowo czytając opis można dowiedzieć się, że atakujący nie musi mieć poświadczeń, ale musi przekonać użytkownika do połączenia ze złośliwym serwerem SMBv3, aby wykorzystać podatność.
Przeglądając dalej, możemy uzyskać informację o prawdopodobieństwie możliwości wykorzystania podatności przez atakujących oraz jakie produkty są podatne. Dodatkowo widać, że jest możliwa aktualizacja oraz Severity jest wycenione na poziom Critical.
Po przejściu w zakładke CVSS Score mamy wycenę metryki CVSS Base i Temporal osobno dla każdej wersji systemu. Jej wynik punktowy wskazuje, że wpływ wykorzystania podatności jest bardzo duży, jeśli ktoś ją wykorzysta (10/10!). Otrzymujemy też wektor CVSS, o którym wspomniałam wcześniej:
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:P/RL:O/RC:C
Spróbujcie go sami rozszyfrować ;).
Podpowiedź: 3 ostatnie podkategorie odnoszą się do metryki Temporal.
Przeglądając niżej, Microsoft wskazuje na brak możliwości załagodzenia podatności i zaleca obejście problemu, do czasu aktualizacji (ale całe szczęście jest!).
Pamiętajmy: aktualizacja > workaround oficjalny > workaround nieoficjalny !
Na samym końcu umieszczone są FAQ oraz odnotowane zmiany w biuletynie.
No dobrze, to co nam to dało?
Jeśli przeanalizowaliście wektor CVSS to wiecie, że należy jak najszybciej sprawą się zająć i się zaktualizować, ale dla leniwych, zestawię go poniżej:
| Fragment wektora | Podkategoria | Parametr | Opis |
|---|---|---|---|
| /AV:N/ | Attack Vector (AV) | Network (N) | Atakujący działa zdalnie oraz nie musi być w naszej sieci + może propagować się po całej naszej infrastrukturze. |
| /AC:L/ | Attack Complexity (AC) | Low (L) | Atakujący nie musi się napracować, by efektywnie wykonywać zdalnie kod. |
| /PR:N/ | Priviledges Required (PR) | None (N) | Atakujący nie potrzebuje poświadczeń, by wykorzystać słabość. |
| /UI:N/ | User Interaction (UI) | None (N) | Atakujący nie prowadzi interakcji z użytkownikiem, aby nakłonić klienta SMBv3 do połączenia się ze swoim serwerem. |
| /S:C/ | Scope (S) | Changed (C) | Atakujący po kompromitacji, może wpływać na inne komponenty systemu. |
| /C:H/ | Confidentiality (C) | High (H) | Atakujący ma dostęp do danych wrażliwych po przeprowadzeniu ataku. |
| /I:H/ | Integrity (I) | High (H) | Atakujący może modyfikować pliki do woli. |
| /A:H/ | Availability (A) | High (H) | Atakujący ma możliwość wyłączenia/przerwania usługi, zarządzania nią wedle swojej woli. |
I 3 ostatnie podkategorie (Temporal):
| Fragment wektora | Podkategoria | Parametr | Opis |
|---|---|---|---|
| /E:P/ | Exploit Code Maturity (E) | Proof of Concept (P) | Dla tej podatności występuje dowód możliwości jej wykorzystania (kod, artykuł), lecz nie został on przystosowany do uniwersalnego wykorzystania przez cyberprzestępców. |
| /RL:O/ | Remediation Level (RL) | Official Fix (O) | Wskazanie, że Microsoft opublikował oficjalne aktualizacje, aby usunąć podatność. |
| /RC:C | Report Confidence (RC) | Confirmed (C) | Microsoft potwierdził lukę w swoim protokole SMBv3. |
Przy analizie podatności warto również sięgnąć do innych źródeł, które mogą zawierać więcej informacji:
- NVD - https://nvd.nist.gov/vuln/detail/CVE-2020-0796
- Mitre - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0796
Dla bardziej zainteresowanych podatnością, linki są poniżej:
- https://twitter.com/hashtag/coronablue?src=hash
- https://github.com/eerykitty/CVE-2020-0796-PoC?files=1
- https://www.mcafee.com/blogs/other-blogs/mcafee-labs/smbghost-analysis-of-cve-2020-0796/
Kończąc, najważniejszą rzeczą przy analizie podatności względem swojej infratruktury jest zrozumienie jej powagi oraz możliwego wpływu. Dlatego warto czasem samodzielnie rozpracować podatność lub na podstawie PoC’a, wycenić ją w standardzie CVSS dla swojego środowiska metryką Environmental oraz przemyśleć możliwość jej mitygacji, jeśli aktualizacji nie ma jeszcze od producenta.
