Denne artikkelen er første i en serie om herding av SMB-protokollen. Vi sammenligner versjoner og ser på noen av de viktige nyansene og problemstillingene når det kommer til sikkerhet.
SMB-Versjoner
| Støtte for signering | Støtte for kryptering | |
| SMB v1.0 | Nei | Nei |
| SMB v2.X | Ja | Nei |
| SMB v3.X | Ja | Ja |
SMBv1 og EternalBlue
I tillegg til at SMBv1 ikke støtter signering eller kryptering er den også svakt designet på flere måter.
Bl.a. kan man opprette en sesjon uten å være autentisert på forhånd. Trusselaktører kan dermed nå SMB-behandlingslogikken direkte over nettverket, og oppnå remote code execution.
Denne svakheten blir kalt MS17-00 også kjent som EternalBlue, og er en av flere exploits i et arsenal av amerikanske cybervåpen, utviklet av en Tailored Access Operations enheten som hører til under National Security Agency (NSA), også kalt The Equation Group.
Denne exploiten ble stjålet av en gruppe som blir kalt The Shadow Brokers, og ble lekket i tidsrommet August 2016 til April 2017, og selv om Microsoft patchet sikkerhetshullet i Mars 2017 ble WannaCry ormen brukt til å infisere store deler av nettet via EternalBlue sårbarheten som mange ikke hadde beskyttet seg mot via patching. Senere i 2017 ble NotPetya sluppet løs, basert på samme sårbarheten.
Fordi SMBv1 er ekstremt sårbar, som ikke er så rart med tanke på at den ble utviklet på sent 80-tall, er det viktig å slå den av i miljøet sitt. Active Directory er skapt for å være kompatibelt langt bakover, og selv nyere installasjoner av Windows Server og Active Directory kan være satt opp til å tillate SMBv1 trafikk.
Dette må eksplisitt nektes i miljøet for å være sikker på at ikke det kan utnyttes.
Kreve Signering
Fra og med SMBv2 og ut ble det mulig å kreve signering av SMB-trafikk. Signeringen gjør det svært vanskelig å utføre relay-angrep dersom både server og klient krever signering.
Her er det viktig å presisere at signering ikke nødvendigvis er påkrevd rett ut av boksen, og må eksplisitt defineres som et krav for å sikre at det håndheves.
Fordi Microsoft har ført en strategi som prioriterer tilgjengelighet over sikkerhet er standardinnstillingene å foretrekke signering, men likevel tillate usignert SMB trafikk dersom motparten ikke støtter det.
Dermed kan en trusselaktør nedgradere sikkerheten ved å si fra sin side at den ikke støtter signering, slik at forhandlingen resulterer i at signering ikke blir brukt.
Slår man på krav om signering vil ikke klient og server kunne bli enige om hvordan de skal kommunisere, med resultat i at sesjonen ikke blir etablert.
Kreve Kryptering
Fra og med versjon 3.0 ble SMB utstyrt med innebygde mekanismer for å kryptere SMB-trafikk. I tidligere versjoner ble trafikken sendt i klartekst, slik at dersom man skulle kryptere trafikken måtte dette gjøres med andre protokoller som innkapslet trafikken, f.eks over IPSec el.l.
Dette er et separat konsept fra signering, og ukryptert trafikk betyr at hele filer – og dermed innholdet i disse filene – kan hentes ut av nettverkstrafikken.
Verktøy som wireshark, tcpdump eller networkminer kan overvåke nettverkstrafikk, og filer kan dras rett ut av pakkestrømmen. Her kan det ligge sensitive filer fra et fileshare ikke alle skal ha tilgang til, eller konfigurasjonsfiler som sendes fra klient til server, og andre ting som ikke må komme på avveie.
Anbefaling
Jeg anbefaler at man skrur av støtte for SMBv1 øyeblikkelig, og at man migrerer over til SMBv2.0 og slår på tvungen signering på kleint og server som et absolutt minstekrav – og aller helst SMB 3.0+ med både tvungen kryptering og signering for å fikse disse sårbarhetene.
Praktiske steg for å gjennomføre dette i Active Directory skal vi se nærmere på i del 2.