Exploit Protection – ochrona Windows przed wykorzystaniem podatności

Exploit Protection to zestaw mechanizmów bezpieczeństwa Windows, którego zadaniem jest utrudnianie wykorzystania podatności w aplikacjach i systemie operacyjnym.

To ważne rozróżnienie:

Antywirus próbuje wykryć złośliwy kod, natomiast Exploit Protection może próbować uniemożliwić wykorzystanie podatności nawet wtedy, gdy atakujący próbuje wykorzystać legalny program.

Exploit Protection a malware

Wyobraźmy sobie podatną aplikację:

Vulnerable Application
          |
          v
      Memory Bug
          |
          v
     Exploitation
          |
          v
   Attacker Code

Exploit Protection dodaje kolejną warstwę:

Vulnerable Application
          |
          v
       Exploit
          |
          v
+----------------------+
| Exploit Protection   |
|                      |
| Mitigations          |
+----------------------+
          |
       BLOCK / LIMIT

Celem jest ograniczenie możliwości przejścia od:

„mam podatność”

do:

„mogę wykonać własny kod”.

Exploit Protection nie jest jednym mechanizmem

To ważne.

Pod nazwą Exploit Protection Windows grupuje wiele różnych mechanizmów mitigacji exploitów.

Możemy myśleć o nich jako o zestawie barier:

             Exploit
                |
      +---------+---------+
      |         |         |
     DEP       ASLR      CFG
      |         |         |
      +---------+---------+
                |
        Other Mitigations
                |
                v
          Exploitation

Konkretny zestaw zależy od wersji Windows, aplikacji i konfiguracji.

DEP – Data Execution Prevention

DEP ogranicza możliwość wykonywania kodu z obszarów pamięci przeznaczonych na dane.

Uproszczony przykład:

Memory
+-------------------+
| Code              | → executable
+-------------------+
| Data              | → non-executable
+-------------------+

Atakujący próbuje:

Data Buffer
    |
    v
Inject shellcode
    |
    v
Execute

DEP może zablokować próbę wykonania kodu z pamięci oznaczonej jako niewykonywalna.

ASLR – Address Space Layout Randomization

ASLR utrudnia przewidywanie adresów pamięci.

Bez ASLR:

Library
0x10000000

Atakujący może próbować wykorzystać znany adres.

Z ASLR:

Run 1 → 0x183A0000
Run 2 → 0x5F210000
Run 3 → 0x72C40000

Adresy są losowo rozmieszczane.

To utrudnia część exploitów wykorzystujących przewidywalne położenie kodu i danych.

CFG – Control Flow Guard

CFG (Control Flow Guard) chroni określone ścieżki przepływu sterowania programu.

Uproszczony model:

Program
  |
  v
Indirect Call
  |
  v
+-------------------+
| CFG Validation    |
+-------------------+
      |
  +---+---+
  |       |
VALID   INVALID
  |       |
 RUN    BLOCK

Jeżeli exploit próbuje skierować wykonanie programu do nieoczekiwanego miejsca, CFG może ograniczyć taką możliwość.

Dlaczego ASLR + DEP + CFG?

Każdy mechanizm utrudnia inną część ataku.

Przykładowo:

Exploit
   |
   +--> Need predictable address
   |         |
   |        ASLR
   |
   +--> Need executable injected memory
   |         |
   |        DEP
   |
   +--> Need redirect control flow
             |
            CFG

Dlatego wielowarstwowość jest tutaj kluczowa.

Exploit Protection a memory corruption

Wiele exploitów wykorzystuje błędy związane z pamięcią, np.:

Buffer Overflow
Use-After-Free
Out-of-Bounds Access
Memory Corruption

Schemat ataku może wyglądać:

Bug
 ↓
Memory Corruption
 ↓
Control Flow Hijacking
 ↓
Code Execution

Mitigacje próbują przerwać ten łańcuch.

Bug
 ↓
Memory Corruption
 ↓
+----------------------+
| Exploit Mitigations  |
+----------------------+
 ↓
Exploit becomes harder

Exploit Protection vs antywirus

To bardzo ważne.

Antywirus

Pyta przede wszystkim:

Czy ten plik/proces zachowuje się jak zagrożenie?

Exploit Protection

Pyta raczej:

Czy ten proces może wykonać operację typową dla wykorzystania określonego rodzaju podatności?

Czyli:

Antivirus
   ↓
Threat Detection


Exploit Protection
   ↓
Exploit Mitigation

Obie warstwy się uzupełniają.

Exploit Protection vs HVCI

To również nie jest to samo.

HVCI:

Kernel Code Integrity

Exploit Protection:

Process / Application Exploit Mitigations

Uproszczony model:

                 Windows
                    |
        +-----------+-----------+
        |                       |
       HVCI             Exploit Protection
        |                       |
   Kernel Code             Application
    Integrity              Mitigations

HVCI koncentruje się przede wszystkim na integralności kodu, zwłaszcza w kernel-mode.

Exploit Protection zabezpiecza aplikacje przed określonymi technikami wykorzystania podatności.

Exploit Protection a DEP/ASLR

DEP i ASLR są często kojarzone z klasycznymi mechanizmami utrudniającymi exploity.

Można to przedstawić:

DEP
 ↓
No execution from non-executable memory


ASLR
 ↓
Harder address prediction


CFG
 ↓
Harder control-flow hijacking

Razem:

DEP + ASLR + CFG
       ↓
Exploit Development
       ↓
More Difficult

Nie oznacza to oczywiście, że każdy exploit zostaje zablokowany.

Exploit Protection można konfigurować

Windows pozwala zarządzać ustawieniami Exploit Protection na poziomie:

System

oraz:

Individual Application

To bardzo istotne.

Możesz mieć:

Global Policy
     |
     +--> Application A
     +--> Application B
     +--> Application C

i w określonych przypadkach zastosować bardziej restrykcyjne ustawienia dla konkretnego procesu.

Windows Security

W interfejsie Windows można znaleźć:

Windows Security → App & browser control → Exploit protection

Tam dostępne są ustawienia związane z ochroną przed exploitami.

Możesz zobaczyć konfigurację:

System settings

oraz:

Program settings

PowerShell

Konfigurację Exploit Protection można również sprawdzać i zarządzać nią za pomocą PowerShell.

Przykładowo:

Get-ProcessMitigation -System

A dla konkretnego procesu/aplikacji:

Get-ProcessMitigation -Name example.exe

Dostępne polecenia zależą od wersji Windows i konkretnej konfiguracji systemu.

Dlaczego nie włączać wszystkiego „na maksa”?

Bo mitigacje mogą powodować problemy z kompatybilnością.

Stara aplikacja może zakładać określone zachowanie środowiska:

Legacy Application
       |
       v
Exploit Mitigation
       |
       v
Compatibility Problem

Dlatego w środowisku enterprise sensowny model to:

Test
 ↓
Pilot
 ↓
Monitor
 ↓
Deploy

a nie:

Enable everything
 ↓
Hope

Exploit Protection i aplikacje legacy

Szczególną ostrożność trzeba zachować przy:

• starych aplikacjach biznesowych,
• starszych przeglądarkach,
• niestandardowym oprogramowaniu,
• aplikacjach wykorzystujących nietypowe mechanizmy pamięci,
• starszych rozwiązaniach wymagających specyficznych bibliotek.

Jeżeli aplikacja zacznie się zamykać po zmianie mitigacji, warto sprawdzić Event Viewer, konfigurację mitigacji i kompatybilność aplikacji, zamiast od razu wyłączać wszystkie zabezpieczenia.

Exploit Protection + Defender for Endpoint

I tutaj łączymy poprzedni temat.

                    Endpoint
                       |
          +------------+------------+
          |                         |
 Exploit Protection             Defender
          |                         |
     Prevent Exploit          Detect Threat
          |                         |
          +------------+------------+
                       |
                 Defender for
                    Endpoint
                       |
                 Investigation
                       |
                    Response

Czyli jedna warstwa próbuje utrudnić exploit, a druga może wykryć podejrzane zachowanie i zareagować.

Exploit Protection + HVCI + WDAC

Możemy teraz zbudować jeszcze ciekawszy model:

                    Windows
                       |
       +---------------+---------------+
       |               |               |
      WDAC            HVCI       Exploit Protection
       |               |               |
 Allowed Code     Kernel CI       Process Mitigations
       |               |               |
       +---------------+---------------+
                       |
                 Defender / MDE
                       |
               Detection & Response

To już jest bardzo solidna architektura defense in depth.

Przykład ataku

Załóżmy, że użytkownik otwiera specjalnie przygotowany dokument.

Malicious Document
        |
        v
Vulnerable Application
        |
        v
Memory Corruption
        |
        v
Exploit

Teraz kolejne warstwy:

              Exploit
                 |
        +--------+--------+
        |        |        |
       DEP      ASLR     CFG
        |        |        |
        +--------+--------+
                 |
                 v
          Exploit blocked/
             disrupted

Jeżeli atak mimo wszystko przejdzie dalej:

Exploit
   ↓
Suspicious Process
   ↓
Defender
   ↓
MDE Detection
   ↓
Alert / Response

To jest właśnie sens wielowarstwowej ochrony.

Czy Exploit Protection eliminuje podatności?

Nie.

To jedna z najważniejszych rzeczy.

Jeżeli aplikacja ma:

CVE

Exploit Protection nie naprawia tej podatności.

Nie zmienia:

Vulnerable Code

w:

Patched Code

Zamiast tego utrudnia wykorzystanie określonych klas błędów.

Dlatego:

Patch
 +
Exploit Protection

jest znacznie lepszym podejściem niż poleganie tylko na mitigacjach.

Exploit Protection vs patching

Najlepszy model:

          Vulnerability
               |
        +------+------+
        |             |
      PATCH       MITIGATION
        |             |
      Fix bug     Reduce exploitability
        |             |
        +------+------+
               |
          Better Security

Patch usuwa przyczynę.

Mitigacja utrudnia wykorzystanie błędu.

Najważniejsze do zapamiętania

Exploit Protection
        |
        +-- DEP
        +-- ASLR
        +-- CFG
        +-- Other mitigations

Jego zadaniem nie jest znalezienie każdego malware.

Jego zadaniem jest zmniejszenie możliwości wykorzystania podatności w aplikacjach i systemie.

A cały model bezpieczeństwa Windows wygląda coraz ciekawiej:

TPM 2.0
   ↓
Secure Boot
   ↓
VBS
   ↓
HVCI
   ↓
WDAC
   ↓
Exploit Protection
   ↓
Microsoft Defender
   ↓
Defender for Endpoint
   ↓
SOC / Incident Response

Najważniejsza różnica: HVCI chroni przede wszystkim integralność kodu w chronionym środowisku, natomiast Exploit Protection stosuje zestaw mitigacji utrudniających wykorzystanie podatności w procesach i aplikacjach. To nie zastępuje patchowania — jest dodatkową warstwą ochrony.

Polecane wpisy

Jak usunąć konto YouTube – poradnik

Oto poradnik krok po kroku, jak usunąć konto YouTube: Jak usunąć konto YouTube - poradnik Krok Czytaj dalej

AMD FSR vs NVIDIA DLSS – porównanie technologii upscalingu w grach

AMD FSR vs NVIDIA DLSS – porównanie technologii upscalingu w grach Współczesne gry komputerowe stają się coraz bardziej wymagające – Czytaj dalej