Category: Ethical Hacking

  • HTTP/1.1 mora umreti: zakaj desinhronizacija ubija varnost in zakaj je čas za HTTP/2

    HTTP/1.1 mora umreti: zakaj desinhronizacija ubija varnost in zakaj je čas za HTTP/2

    HTTP/1.1 mora umreti: zakaj desinhronizacija ubija varnost in zakaj je čas za HTTP/2

    1) Zakaj je HTTP/1.1 tako ranljiv

    HTTP/1.1 trpi zaradi “dvoumnih” zahtevkov: različne naprave (CDN-ji, WAF-i, reverse proxyj-i, aplikacijski strežniki) lahko različno razčlenjujejo glave in telo (Content-Length vs. Transfer-Encoding, presledki, CR/LF odstopanja). Napadalci to izkoristijo za request smuggling/desync – prisilijo “front-end” in “back-end” v nesoglasje o tem, kje se en zahtevek konča in začne naslednji, kar odpre vrata za zastrupljanje predpomnilnikov, krajo sej, SSRF in obvode WAF-a. PortSwigger je letos pokazal nove razrede teh napadov in jasno sporočilo z Black Hat: desync je še vedno povsod, še posebej tam, kjer se HTTP/2 potiho pretvarja v HTTP/1.1 zadaj.

    Dodaten problem je “nevidno zniževanje protokola”: mnogi robni sistemi sprejemajo HTTP/2 od brskalnika, nato pa tiho pretvorijo promet v HTTP/1.1 proti aplikaciji. Ta dodatna plast kompleksnosti spet odpre stara vrata za desync, če parserji na poti niso popolnoma skladni.

    Opomba: tudi HTTP/2 ni čarobna krogla – v 2023 smo videli Rapid Reset (CVE-2023-44487), kjer napadalec zlorabi multiplexing in s hitrim pošiljanjem/preklicevanjem streamov povzroči nesorazmeren porast porabe CPU (DoS). To je treba zakrpati in omejevati, a ranljivost je drugačnega tipa kot klasični desync v HTTP/1.1.

    2) Kako napadalci pristopijo (na visoki ravni – za modre ekipe)

    • Iščejo neskladja parserjev: primerjajo, kako rob (CDN/reverse proxy) in aplikacijski strežnik obravnavata CL/TE, neobičajne presledke, glave “TE: trailers” ipd. Razlike nakazujejo potencial za desync.
    • Izrabljajo “HTTP/2 → HTTP/1.1” znižanja: ciljajo poti, kjer front-end sprejme h2, back-end pa pričakuje h1. Če se pravila razmejitve razlikujejo, lahko s “fantomskim” delom zahteve manipulirajo naslednji zahtevek žrtve.
    • Posledice uspešnega desynca: zastrupljanje cache-a (stran A vrne vsebino B), kraja sej ali prijavnih tokov, obvoz WAF-a in interni “pivot” (SSRF).
    • Za DoS na h2: poskušajo “Rapid Reset” – množično odpiranje in takojšnje resetiranje streamov, kar ceneje izčrpava strežnik. Obramba: posodobitve in omejitve stopnje/streamov.

    3) Remediacija: prehod na HTTP/2 + varne nastavitve (Apache & Nginx)

    Ključna načela

    • TLS + ALPN: za brskalnike se HTTP/2 pogaja prek ALPN pri TLS; ne zanašajte se na Upgrade: h2c. Onemogočite h2c (cleartext).
    • Doslednost na poti: zmanjšajte ali odstranite “nevidna znižanja” (CDN/reverse proxy → origin). Če znižanje ostane, poskrbite za enoten, strogo skladen parsing na vseh točkah.
    • Posodobitve: namestite popravke proti CVE-2023-44487 in uvedite omejitve (rate limiting, max concurrent streams, request buffering).

    Apache (2.4+)

    1. Omogočite module in ALPN h2 v TLS vhostu (443):
    a2enmod http2 ssl headers
    <VirtualHost *:443>
    ServerName example.com
    SSLEngine On
    SSLCertificateFile /pot/do/fullchain.pem
    SSLCertificateKeyFile /pot/do/privkey.pem

    # HTTP/2 prek ALPN, brez h2c
    Protocols h2 http/1.1

    # (priporočeno) MPM event + PHP-FPM namesto prefork+mod_php
    # in redni varnostni headerji ...
</VirtualHost>

    Za stabilnost/zmogljivost preklopite na mpm_event + PHP-FPM (HTTP/2 in prefork se slabše razumeta). Uradna dokumentacija: mod_http2 in vodič za HTTP/2.

    Dodatno:

    • Onemogočite h2c, zanašajte se na h2 (TLS/ALPN).
    • Če uporabljate posrednike, testirajte CL/TE skladnost (desync) na stagingu.

    Nginx

    V strežniškem bloku za HTTPS dodajte http2 (in uporabite veljaven certifikat):

    server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /path/fullchain.pem;
    ssl_certificate_key /path/privkey.pem;

    # ...
}

    To omogoči HTTP/2 na robu. Poskrbite za TLS in redno posodabljajte Nginx na izdaje, ki naslovijo h2 DoS (Rapid Reset).

    Opomba: nekateri reversni proxyji/CDN-ji lahko še vedno govorijo HTTP/1.1 proti originu. Kjer je to mogoče, izberite pot, ki ne uvaja skrite pretvorbe ali zagotovite identična pravila razčlenjevanja ter testirajte desync scenarije (PortSwigger priporočila)

    Povzetek

    • Ključ do varnosti je doslednost na vseh sklopih (edge ↔ origin), izklop h2c, redne posodobitve in preizkusi desync na stagingu.
    • HTTP/1.1 je nagnjen k desyncu zaradi zgodovinskih dvoumnosti.
    • HTTP/2 prinaša varnejše ograje (in boljšo zmogljivost), a zahteva pravilno ALPN/TLS nastavitev in popravke (npr. Rapid Reset).

    Reference:

    • https://portswigger.net/research/http1-must-die
    • https://www.youtube.com/watch?v=n3Bw8CASnHE

  • 🎧 Napad na slušalke: Ko Bluetooth postane orodje za prisluškovanje

    🎧 Napad na slušalke: Ko Bluetooth postane orodje za prisluškovanje

    Varnostna ranljivost, ki omogoča oddaljeni nadzor nad slušalkami – in celo prisluškovanje okolici

    V dobi brezžičnih naprav pogosto pozabimo, da udobje prinaša tudi tveganja. V nedavni varnostni raziskavi smo praktično prikazali, kako lahko z uporabo odprtokodnih orodij napadalec brez vednosti žrtve prevzame nadzor nad brezžičnimi slušalkami.

    Kako poteka napad?

    1. Napadalec zazna Bluetooth naprave v okolici.
    2. Z uporabo orodij, kot so btmon, bluedump ali bt-audio, ugotovi, da so slušalke pogosto samodejno odprte za povezavo brez PIN-a ali potrditve.
    3. Po uspešni povezavi napadalec:
      • Prek aktivnega mikrofona slušalk začne prisluškovati okolici.

    Prisluškovanje z mikrofonom slušalk

    ❗️ Osebna izkušnja raziskovalca: Po uspešni povezavi s slušalkami je bilo možno v realnem času poslušati okolico preko njihovega vgrajenega mikrofona – brez da bi žrtev to zaznala.

    Več povezav = več možnosti za napad

    Veliko modelov omogoča funkcijo “multipoint pairing”, kar pomeni, da so slušalke lahko hkrati povezane z dvema ali celo več napravami (npr. telefon in prenosnik).

    Kaj to pomeni za varnost?

    • Napadalec lahko postane druga “nevidna” naprava, ne da bi prekinil trenutno povezavo žrtve.
    • Žrtev nima nobenega opozorila, da je dodana še ena povezava.
    • Napad se lahko izvaja tudi v ozadju, brez motenja uporabnika – razen, če se namenoma vmeša v zvok.

    Demonstracija v živo

    Oglej si dejanski prikaz tega napada:

    Kako se zaščititi?

    • Vedno izklopite Bluetooth, ko ga ne uporabljate.
    • Redno brišite seznanjene naprave s seznama slušalk.
    • Če slušalke podpirajo izklop mikrofona, to storite, ko ga ne potrebujete.
    • Uporabljajte Bluetooth naprave, ki zahtevajo avtentikacijo ob vsaki novi povezavi.
    • Po možnosti izklopite multipoint funkcijo, če je ne potrebujete.

    Zaključek

    Bluetooth ranljivosti so resnične – in nevarne. Tudi vsakdanji pripomočki, kot so brezžične slušalke, lahko postanejo orodje za vohunjenje. Pomembno je, da razumemo, kako te tehnologije delujejo, in jih uporabljamo odgovorno.

    Za profesionalno varnostno svetovanje ali predstavitev v živo nas kontaktirajte na info@cyber-sec.si ali obiščite cyber-sec.si

  • Zaščiten sistem… ali res? Preizkus napada na moderni Sophos XDR (27.01.2023)

    Zaščiten sistem… ali res? Preizkus napada na moderni Sophos XDR (27.01.2023)

    Zaščiten sistem… ali res? Preizkus napada na moderni Sophos XDR (27.01.2023) (RAZISKOVALNO DELO!)

    Uvod

    Kljub naprednim funkcijam razširjenega zaznavanja in odzivanja (XDR) rešitev, kot je Sophos XDR, napadalci še vedno iščejo poti, kako obiti obrambo in izvesti svoje napade. V tem prispevku predstavljam preizkus varnosti, kjer sem uspel izvesti simulacijo ransomware napada in zakriptirati testne datoteke, ne da bi Sophos XDR pravočasno zaznal ali blokiral aktivnost.

    Pregled napada: Zagon ransomware napada kljub zaščiti Sophos XDR

    Cilj testa je bil preveriti, ali lahko napreden napadalec zaobide zaznavanje Sophos XDR in izvede napad, pri katerem pride do šifriranja datotek – torej klasičnega vedenja ransomwareja.

    V tem varnostnem preizkusu sem uporabil lastno prilagojeno različico ransomware simulacije, ki je uspešno izvedla šifriranje testnih datotek, pri čemer Sophos XDR ni pravočasno zaznal grožnje ali sprožil zaščitnega ukrepa.

    Tehnike zaobida in uspešnega napada

    Pri simulaciji sem uporabil naslednje tehnike:

    • Diskretna dostava in izvedba: Datoteka z ransomware kodo je bila prenešena na sistem z uporabo orodja, ki je posnemalo legitimno delovanje, kar je zmanjšalo verjetnost sprožitve varnostnih opozoril.
    • Postopno šifriranje: Šifriranje datotek je potekalo počasneje in segmentirano, kar je preprečilo sprožitev vedenjskih opozoril Sophos XDR.

    Rezultat: Vse testne datoteke so bile uspešno zakriptirane, brez takojšnje zaznave ali zaustavitve procesa s strani Sophos XDR.

    Zaznava in priporočeni ukrepi

    Predlogi za izboljšanje zaščite:

    • Izboljšanje vedenjske analize: Sophos XDR bi moral zaznavati postopno šifriranje ali sumljive IO operacije tudi pri novih (nepodpisanih) binarnih datotekah.
    • Uvedba nadzora nad neznanimi aplikacijami: Dodatne varnostne politike, kot je nadzor izvajanja neznanih binarnih datotek, bi lahko preprečile izvedbo napada.
    • Uvedba honeypot datotek: Implementacija sistemskih vabečih (honeypot) datotek bi lahko omogočila zgodnjo zaznavo ransomware obnašanja.
    • Napredna segmentacija in pravice dostopa: Šifriranje testnih datotek bi lahko bilo omejeno z bolj strogim nadzorom dostopa in nadzora nad pravicami pisanja.

    Zaključek

    Ta test dokazuje, da tudi napredne varnostne rešitve, kot je Sophos XDR, niso neprepustne za kreativne in prilagojene napade. Ključno sporočilo je jasno: varnost ne sme temeljiti le na enem orodju, temveč na večplastnem, proaktivnem in neprekinjeno izboljševanem varnostnem modelu.

    Z deljenjem teh spoznanj želimo spodbuditi varnostne strokovnjake, da redno preizkušajo svoje obrambne sisteme in implementirajo rešitve, ki upoštevajo tudi manj očitne metode napadalcev.

    Omejitev odgovornosti

    Problem je bil javljen na Sophos in vrjetno tudi odpravljen. Ob tem želim poudariti, da so vsi postopki, opisani v tem blogu, izvedeni izključno v raziskovalne in učne namene. Obvod ali napad na varnostne sisteme, kot je Sophos, brez dovoljenja in v skladu z zakoni je nezakonit in neetičen. Moje dejavnosti niso bile usmerjene v škodovanje, temveč v razumevanje, kako se lahko izboljša varnost in zaščita pred napadi v realnem okolju.

  • XDR Bypass – 08.12.2024: XDR ≠ Nepremagljivost

    XDR Bypass – 08.12.2024: XDR ≠ Nepremagljivost

    XDR Bypass – 08.12.2024: XDR ≠ Nepremagljivost (RAZISKOVALNO DELO!)

    V svetu kibernetske varnosti si proizvajalci varnostnih rešitev neprestano prizadevajo za odkrivanje in blokiranje orodij, kot je Mimikatz – eno najbolj znanih orodij za pridobivanje poverilnic v sistemih Windows. Toda kot v vsakem kibernetskem “orožju proti ščitu”, tudi tukaj obstajajo poti mimo obrambnih mehanizmov.

    Na dan 8. 12. 2024 sem uspel izvesti uspešen bypass XDR rešitve in zagnati Mimikatz na končni napravi, brez sproženega opozorila, alarma ali blokade.

    Kontekst

    Kot etični heker sem imel priložnost testirati večino platform EDR/XDR, ki so med bolj pogostimi med uporabniki na našem območju sveta. Test se nanaša na stanje platforme v času izvajanja testiranja in odkritja so bila javljena podjetju, zato so imeli možnost pomanjkljivosti tudi odpraviti. Cynet je dobro poznana platforma za zaznavanje in odzivanje na grožnje (XDR), ki zaznava poskus kraje poverilnic in je namenjen zaščiti končnih naprav. Njihov agent analizira vedenjske vzorce, z namenom zaznati nenavadne in zlonamerne aktivnosti v realnem času.

    Toda varnostne rešitve se večinoma zanašajo na znane vzorce, hash-e, povezane IOCs, ali vedenjske signale. Če napadalec razume, kako varnostna rešitev zaznava nevarnost, lahko potencialno razvije način, da jo obide.

    Pristop

    Uporabil sem napredne tehnike obfuskacije z modifikacijo Mimikatz izvlečene kode:

    1. Analiza Cynet-ovega delovanja:
      • Spremljal sem procese, katere Cynet aktivno nadzira.
      • Ocenil sem metode, ki jih uporablja za detekcijo (npr. lsass dostop, OpenProcess, ReadProcessMemory).
    2. Preoblikovanje Mimikatz:
      • Prevedel sem izvorno kodo z izločenimi poznanimi IOCs.
      • Vključil sem runtime obfuscation – imena funkcij in nizov sem šifriral in dešifriral šele ob izvajanju.

    Rezultat

    Po uspešni izvedbi napada:

    • Cynet ni sprožil nobenega alarma.
    • Ni bilo zaznane nenavadne aktivnosti v konzoli upravljanja.

    To sem preveril s spremljanjem:

    • Event logov
    • Cynet XDR nadzorne plošče

    Kaj to pomeni za organizacije?

    Uspešen bypass takšne rešitve kaže na naslednje ključne izzive:

    • Zanašanje izključno na EDR/XDR ni dovolj – defense-in-depth pristop ostaja ključen.
    • Redno testiranje varnostnih rešitev z napadalnim razmišljanjem (red teaming) je nujno.
    • Behavioral detekcija mora biti dopolnjena s heuristiko in kontekstom

    Zaključek

    Ta eksperiment ni bil le tehničen izziv, temveč dokaz, da tudi najbolj moderne varnostne rešitve niso nezlomljive. Znanje napadalca, razumevanje notranjih mehanizmov EDR/XDR, in kreativnost so ključni za uspešen bypass.

    Zato nikoli ne pozabite – orodja ne zavarujejo sistema, ljudje in postopki ga.

    Zavrnitev odgovornosti

    Problem je bil javljen na Cynet in vrjetno tudi odpravljen. Ob tem želim poudariti, da so vsi postopki, opisani v tem blogu, izvedeni izključno v raziskovalne in učne namene. Obvod ali napad na varnostne sisteme, kot je Cynet, brez dovoljenja in v skladu z zakoni je nezakonit in neetičen. Moje dejavnosti niso bile usmerjene v škodovanje, temveč v razumevanje, kako se lahko izboljša varnost in zaščita pred napadi v realnem okolju.

  • PXE Boot: Delovanje, ranljivosti in zaščita s pomočjo močnih gesel

    PXE Boot: Delovanje, ranljivosti in zaščita s pomočjo močnih gesel

    PXE (Preboot Execution Environment) boot omogoča računalnikom, da se zaganjajo prek omrežja, kar je še posebej uporabno v velikih organizacijah in podatkovnih centrih. Vendar pa lahko, če napadalec uspe pridobiti dostop do internega omrežja, neustrezno zaščiteni PXE strežniki postanejo tarča napadov. V tem članku bomo podrobneje raziskali, kako PXE deluje, kakšne so njegove ranljivosti in zakaj je uporaba močnih gesel – kot je primer gesla PxeThief – ključnega pomena, še posebej ob integraciji s sistemi, kot je SCCM.

    Kako deluje PXE boot

    PXE boot proces vključuje več ključnih komponent in protokolov, med katerimi so:

    • NIC (Network Interface Card): Ni vse strojne opreme enaka. Medtem ko so mnoge potrošniške kartice omejene, sodobni strežniki v podatkovnih centrih običajno že vključujejo PXE-kompatibilne NIC-e.
    • DHCP: Ko se PXE klient (računalnik) zažene, pošlje zahtevo v omrežje. DHCP strežnik odgovori z dodelitvijo IP naslova in dodatnih omrežnih parametrov, vključno z informacijami o strežniku, ki bo nudil PXE zagonsko sliko.
    • TFTP (Trivial File Transfer Protocol): Ta preprost, UDP osnovan protokol se uporablja za prenos zagonskega programa (Network Bootstrap Program – NBP) s PXE strežnika na klienta. Zaradi svoje preprostosti, vendar tudi pomanjkanja varnostnih funkcij (nima avtorizacije ali preverjanja pristnosti), predstavlja potencialno ranljivo točko.

    PXE Workflow:

    1. Obvestilo o PXE: Klient pošlje omrežno sporočilo, s katerim obvešča, da uporablja PXE.
    2. DHCP odziv: DHCP strežnik dodeli IP naslov in posreduje dodatne PXE parametre, vključno z IP naslovom PXE strežnika.
    3. Seznam strežnikov: Klient prejme seznam razpoložljivih zagonskih strežnikov in operacijskih sistemov.
    4. Prenos zagonske slike: Klient identificira ustrezen strežnik, prejme ime zagonske datoteke in jo prenese preko TFTP protokola.
    5. Zagon operacijskega sistema: Prenesena zagonska slika se izvrši in naloži osnovne komponente operacijskega sistema.

    Če strežnik ni opremljen s PXE zmogljivostmi, bo preprosto prezrl PXE kodo, s čimer se prepreči motenje standardnih DHCP in Bootstrap protokolov.

    Ranljivosti PXE boot okolij

    Čeprav PXE ponuja izjemno priročnost pri oddaljenem zagonu in distribuciji operacijskih sistemov, ima tudi svoje pomanjkljivosti, ki lahko izkoriščajo napadalci, ko pridejo do dostopa do internega omrežja:

    • Neavtorizirani dostop: Ker TFTP nima integriranih varnostnih mehanizmov (avtentikacije ali avtorizacije), lahko napadalec, ki se znajde v omrežju, preusmeri ali nadomesti originalne zagonske datoteke.
    • DHCP spoofing: Napadalec lahko ponareja DHCP strežnik, s čimer klientom posreduje napačne PXE strežnike in zagonske slike, ki lahko vsebujejo zlonamerno kodo.
    • Pomanjkanje šifriranja: Prenos podatkov med PXE klientom in strežnikom poteka brez šifriranja, kar omogoča prestrezanje podatkov in morebitno vbrizgavanje škodljivih sprememb.
    • Integracijske ranljivosti: Sistemi, kot je SCCM, ki uporabljajo PXE za oddaljeno nameščanje operacijskih sistemov, so še posebej občutljivi, saj morebitna kompromitacija lahko vpliva na širok spekter poslovnih sistemov in naprav.

    Pomen uporabe močnih gesel:

    Glede na omenjene ranljivosti je zaščita PXE okolja nujna. Eden izmed ključnih varnostnih ukrepov je uporaba močnih gesel, ki preprečujejo nepooblaščen dostop in manipulacijo s strežnikom. Geslo simbolizira pristop k tej zaščiti – močno, edinstveno in strojno zahtevano geslo, ki oteži napadalcem uporabo orodij in tehnik za prevzem nadzora nad PXE strežniki.

    Prednosti močnih gesel pri PXE:

    • Preprečevanje zlorab: Močno geslo zmanjšuje možnosti, da bi napadalec lahko preusmeril PXE promet ali zamenjal zagonske datoteke.
    • Integriteta sistema: Zavarovani PXE strežniki pomagajo zagotoviti, da le overjeni uporabniki in sistemi (npr. SCCM) lahko izvajajo kritične operacije, kot je distribucija operacijskih sistemov.
    • Zmanjšanje tveganj: Uporaba robustnih gesel in dodatnih varnostnih ukrepov (npr. segmentacija omrežja in nadzor dostopa) zmanjšuje možnosti vdora in nadaljnjih kompromitacij.

    Integracija s SCCM

    Microsoftov System Center Configuration Manager (SCCM) pogosto uporablja PXE za distribucijo operacijskih sistemov in avtomatizacijo namestitev na številnih napravah znotraj organizacije. V kombinaciji s PXE omogoča SCCM centralizirano upravljanje, vendar hkrati prinaša dodatne varnostne izzive:

    • Avtomatizacija in obseg: Ker SCCM pogosto deluje na velikem številu naprav, lahko kompromitiran PXE strežnik hitro vpliva na celotno infrastrukturo.
    • Varnostni nadzor: Integracija močnih gesel in pravilno konfiguriranih varnostnih politik je ključna, saj mora SCCM zagotoviti, da so samo pooblaščene naprave in uporabniki deležni zagonskih slik.
    • Redni pregledi in posodobitve: Upravljalci morajo redno preverjati in posodabljati varnostne nastavitve PXE strežnikov ter integracijske točke s SCCM, da se preprečijo morebitne ranljivosti.
    1. Generiranje in prenos šifriranih datotek:

    Napadalec začne z generiranjem in prenosom šifrirane datoteke, imenovane “media variables file”, s strežnika MECM, ki se nahaja na naslovu 10.7.10.41. Pri tem uporablja izbran omrežni vmesnik – v tem primeru je naveden adapter Red Hat VirtIO Ethernet Adapter. Poleg tega je ciljna naprava prav tako 10.7.10.41, kar nakazuje, da napadalec neposredno cilja na MECM strežnik.

    1. Pridobivanje lokacij datotek prek ConfigMgr:

    Napadalec pošlje zahtevo ConfigMgr-ju, da posreduje lokacije za prenos dveh ključnih datotek:

    • Media variables file (ki vsebuje konfiguracijske in šifrirane varijable)
    • BCD (Boot Configuration Data)

    Sporočila kažejo, da strežnik odgovori z natančnimi lokacijami, na primer:

    • \\SMSTemp\\2025.02.21.13.44.28.0001.{...}.boot.var
    • \\SMSTemp\\2025.02.21.13.44.26.08.{...}.boot.bcd

    Omrežni prenos:

    Med prenosom se opazi, da napadalec ne najde ciljanega MAC naslova, zato uporabi “broadcast”, s čimer pošlje eno paketno sporočilo, prejme pa dva paketa (od katerih enega zanesljivo prepozna kot odgovor). Poleg tega se opozarja, da je pri PXE boot konfiguraciji najdeno prazno geslo, kar nakazuje na ranljivost v zaščiti zagonskega okolja.

    1. Uporaba TFTP za prenos:

    Napadalec prejme navodila za uporabo TFTP ukazov, s katerimi naj prenese obe datoteki. V nadaljevanju pa se avtomatska eksploatacija sproži, kjer se uporablja privzeti TFTP klient (na primer Windows TFTP, ki je del Windows Features).

    Dešifriranje datoteke:

    V postopku napadalec dobi tudi niz bajtov gesla (v heksadecimalni obliki:

    0x020002004d0005005800610062005300e3fffaff) in ga uporabi za dešifriranje media variables file. Uspešno dešifriranje omogoči:

    • Shranitev dešifriranih podatkov v datoteko variables.xml
    • Izpis ključnih certifikatov (datoteka, ki vsebuje _SMSTSMediaPFX) skupaj s certifikatom in pripadajočim geslom
    1. Identifikacija MECM Management Point:

    Iz dešifriranih medijskih variabel se izlušči URL strežnika za Management Point. Ta URL je ključnega pomena, saj preko njega napadalec nadaljuje komunikacijo in pošilja avtentikacijske zahteve.

    Uvoz certifikata in generacija podpisov:

    • Certifikat iz _SMSTSMediaPFX se uspešno uvozi v Windows Certificate Store.
    • Na podlagi tega certifikata napadalec generira več avtentikacijskih podpisov, kot so CCMClientID, CCMClientTimestamp in ClientToken, kar mu omogoča pošiljanje pristnih zahtev MECM strežniku.
    1. Pridobitev politik in konfiguracijskih datotek:

    Napadalec preko MECM Management Point zahteva:

    • Politike dodelitve, kjer se najde kar 47 URL-jev za različne konfiguracije.
    • Konfiguracijo za Network Access Account, ki je potrebna za dostop do omrežnih virov.
    • Konfiguracijo za Task Sequence, ki določa postopke in poverilnice za namestitev operacijskega sistema (v tem primeru “Install_win10_OS_image”).
    1. Dešifriranje in razkritje poverilnic:
    • Network Access Account: Po dešifriranju konfiguracije se izluščijo občutljivi podatki, kjer so prikazani uporabniško ime in geslo:
      • Uporabniško ime: sccm.lab\\sccm-naa
      • Geslo: 123456789
    • Task Sequence konfiguracija: V okviru Task Sequence se identificirajo dodatni credential polji:
      • V koraku “Apply Windows Settings”:
        • OSDRegisteredUserName (npr. uporabniško ime, ki je lahko povezano z operacijskim sistemom)
        • OSDLocalAdminPassword (npr. vrednost: EP+xh7Rk6j90)
      • V koraku “Apply Network Settings“:
        • OSDJoinAccount in OSDJoinPassword, kjer ponovno najdemo isti račun sccm.lab\\sccm-naa in geslo 123456789

    Te informacije omogočajo napadalcu popoln vpogled v konfiguracijo namestitve operacijskega sistema in dostop do omrežnih virov.

    Zaključek

    PXE boot okolja prinašajo izjemne prednosti pri oddaljenem zagonu in distribuciji operacijskih sistemov, vendar pa niso brez varnostnih pasti. Ko napadalec pridobi dostop do internega omrežja, lahko slabše zaščiteni PXE strežniki postanejo tarča zlonamernih napadov, kot so DHCP spoofing in zlonamerni prenosi prek TFTP. Uporaba močnih gesel – kot je priporočeno geslo PxeThief – ter dosledna varnostna politika, vključno z integracijo in pravilnim konfiguriranjem sistemov, kot je SCCM, so ključni koraki za zaščito celotnega okolja.

    Z varnostjo na prvem mestu in nenehnim nadzorom omrežja lahko organizacije učinkovito zmanjšajo tveganja, povezana s PXE boot okolji, ter zagotovijo stabilno in varno distribucijo operacijskih sistemov.