Nieuwe kwetsbaarheid in SMB-protocol laat aanvallers van afstand code uitvoeren

Er is een nieuw lek ontdekt in de implementatie van het SMB-protocol in Windows. Met het lek zou het mogelijk zijn op afstand code uit te voeren op een netwerk. Er is op dit moment nog geen patch beschikbaar voor de kwetsbaarheid.

Microsoft bevestigt het bestaan van de kwetsbaarheid, die bekendstaat als CVE-2020-0796. Er zijn nog geen technische details bekend over de kwetsbaarheid. Microsoft meldt dat de kwetsbaarheid voor zover bekend niet actief misbruikt wordt. Op maandagavond verscheen het lek kort in een advisory op de site van Cisco's beveiligingsafdeling Talos, maar inmiddels is de informatie daar weer verwijderd.

Verschillende deelnemers van het Microsoft Active Protections Program zouden al wel details hebben gekregen over het lek. Die plaatsten screenshots waarin wordt gesproken over een 'wormable' aanval. Daardoor trokken sommige experts parallellen met andere soortgelijke kwetsbaarheden zoals BlueKeep. Die kwetsbaarheid in het Remote Desktop Protocol zorgde voor veel schade via de EternalBlue-exploit. De huidige kwetsbaarheid zou daar overeenkomsten mee hebben. "Een aanvaller kan deze bug uitbuiten door een zelfontworpen pakketje naar een kwetsbare SMBv3-server te sturen waar het slachtoffer mee verbonden moet zijn", schrijft Microsoft in de waarschuwing.

Microsoft zegt dat het op dit moment nog geen patch beschikbaar heeft voor het lek. Wel raden beveiligingsexperts aan bepaalde maatregelen te nemen op het netwerk om schade te voorkomen. Zo zouden ze SMBv3-compressie moeten uitschakelen en tcp-poort 445 moeten blokkeren. Op dit moment lijkt het alsof Windows 10-versies 1903 en 1909 en Windows Server-versies 1903 en 1909 kwetsbaar zijn. Mogelijk komen daar nog andere versies van het besturingssysteem bij, omdat SMBv3 ook al in oudere versies zoals Windows 8 zat.

Door Tijs Hofmans

Nieuwscoördinator

11-03-2020 • 10:36

62

Submitter: n9iels

Reacties (62)

62
60
39
4
0
14
Wijzig sortering
SMBv3 compressie uitschakelen:
https://portal.msrc.micro...idance/advisory/adv200005
Workarounds

The following workaround may be helpful in your situation. In all cases, Microsoft strongly recommends that you install the updates for this vulnerability as soon as they become available even if you plan to leave this workaround in place:

Disable SMBv3 compression

You can disable compression to block unauthenticated attackers from exploiting the vulnerability against an SMBv3 Server with the PowerShell command below.

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force

Notes:

No reboot is needed after making the change.
This workaround does not prevent exploitation of SMB clients.

You can disable the workaround with the PowerShell command below.

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 0 -Force
Dit moet je helemaal niet doen, als consument is dit helemaal niet interessant. Zolang jij je SMB server niet direct open aan het grote boze internet hebt hangen of in een groot netwerk wacht gewoon op de patch.
Is get gevaar niet dat als iemand binnen je netwerk getroffen raakt, via een foute download of een link uit de mail, het hele huishouden gevaar loopt?

Misschien toch niet zo'n verkeerd idee, want voorkomen is beter dan ...
En, aangezien je r een worm voor kunt maken, kan je problemen krijgen als een ander geïnfecteerd persoon gebruik maakt van je thuisnetwerk. Bijvoorbeeld via wifi.
Dat bedoel ik idd, zo ging het ook met de ransomware.
Anoniem: 1322 @royb311 maart 2020 11:43
Wat betreft blokkeren van TCP poort 445, dit is meer een algemene aanbeveling. Als je echt wilt 'voorkomen is beter dan genezen', blokkeer dan alle client naar client communicatie op je netwerk (client isolation). Dit is iets wat al standaard op veel wifi netwerk gebeurd maar reken er dan wel op dat bepaalde functionaliteit ook kapot gaat. Voorbeeld van client-to-client zaken zijn (chrome) casten en Airplay .

[Reactie gewijzigd door Anoniem: 1322 op 22 juli 2024 19:51]

Je kijkt teveel spannende series. Er is geen 'hacker' op deze aardbol die zoveel moeite doet om jouw vakantiefotos te downloaden.

Voor een zakelijke omgeving is deze work-around te adviseren. Voor je NASje thuis.. lekker boeiend.
Sorry? Daar is het toch niet om te doen? Denk aan ransomware, al je bestanden ineens versleutelt. Dat gebeurd bij consumenten ook, niet alleen bij de bedrijven die vervolgens in het nieuws komen omdat ze stil liggen. Vrij veel mensen moeten teleurstellen omdat zij hun foto's en documenten nooit hadden geback-upt, want het is niet voor het eerst dat een lek in SMB voor dit doeleind is gebruikt.
Dit ransomware verhaal heeft zich een paar jaar geleden bij mijn moeder voorgedaan onder Windows 7. Gelukkig had ik alle bestanden ook op een Linux partitie staan, maar ik kan me voorstellen dat het anders heel vervelend was geweest. Ze heeft sindsdien ook alleen maar Android telefoons gebruikt en sinds kort heeft ze een laptop waar Kubuntu op draait. Windows gaat ze waarschijnlijk nooit meer gebruiken.
Net zoals dat niemand moeite zou doen om jouw bestanden te versleutelen? Het gaat ze juist om dit soort potentiele slachtoffer, omdat die geen backups van hun vakantiefoto's hebben, en deze niet kwijt willen raken.
Er is misschien inderdaad een verschil tussen consument en bedrijfsmatig, maar elke tweaker mag voor zichzelf uitzoeken of hij/zij dit wel of niet toepast prive of bedrijfsmatig, het is puur ter informatie voor de tweaker. :)

Edit:
Ik weet niet of het standaard is, maar als thuisgebruiker die toch nooit bestanden en printers deelt kan je het hele file and printer sharing natuurlijk beter uitschakelen. :)

[Reactie gewijzigd door Rudie_V op 22 juli 2024 19:51]

onzin. ik zou zelf gewoon lekker even SMB uit zetten tot het gepatched is. alsof je niet een paar dagen zonder kan als consument. Als je echt niet zonder kan de bovengenoemde fix. het is echt compleet onzinnig om onnodig risico te lopen als de consequenties klein zijn. heb zelf na het lezen van dit bericht ook gewoon SMB uitgeschakelt op al mn windows apparaten.
Totaal oneens en zeker geen goede security hygiene.
1 geïnfecteerde PC in je organisatie (die hoogstwaarschijnlijk via SMB kan communiceren met een fileserver) kan via deze vulnerability remote code executen op de fileserver.
Hoezo niet interessant. (Consumenten werken ook bij bedrijven)
Jij hebt dus een antivirus en firewall ontwikkeld waar 100% van de malware wordt tegengehouden? Ik zou het gaan verkopen, daar kun je heel erg rijk mee worden.
Gaat ons prima af.. Watchguard firewalls en SentinalOne AV. In combi met de juist GPO's.
GPO's zijn meer bedoeld voor het beperken van de mogelijkheden die eindgebruikers hebben. Het kan helpen in het geval van malware wat door de gebruiker uitgevoerd moet worden, maar dat is het ook wel zo'n beetje. Als malware admin privileges kan krijgen door een willekeurige exploit, heb je niet zoveel aan GPO's.
Er kan altijd malware binnenkomen, hoe goed je beveiliging ook is.

[Reactie gewijzigd door mjz2cool op 22 juli 2024 19:51]

Als het inderdaad een lek in het protocol is, en niet zozeer de server, kan samba dan ook kwetsbaar zijn?
Het is een buffer overflow in de compressie.: https://fortiguard.com/encyclopedia/ips/48773
Is dus implementatie en niet zozeer het protocol, dus normaal geen impact op samba.
Dat zou veranderd moeten worden in de titel, het is idd niet het protocol wat lek is.
Zo zouden ze SMBv3-compressie moeten uitschakelen en tcp-poort 445 moeten blokkeren.
Laten we realistisch zijn: het eerste is makkelijk te bewerkstelligen (een enkele registersleutel aanpassen en een service/server herstart, met weinig kans op regressies), het tweede is vergelijkbaar met de winkel sluiten omdat je binnen je organisatie geen file sharing naar Windows servers meer kan gebruiken.
Op dit moment lijkt het alsof Windows 10-versies 1903 en 1909 en Windows Server-versies 1903 en 1909 kwetsbaar zijn. Mogelijk komen daar nog andere versies van het besturingssysteem bij, omdat SMBv3 ook al in oudere versies zoals Windows 8 zat.
En in oudere versies van Windows 10 en Windows Server. En Windows 7. Die laatste wordt enkel nog ondersteund voor betaalde klanten, maar Microsoft heeft wel eens eerder kritieke updates uitgebracht voor niet meer ondersteunde besturingssystemen. Windows 7 ondersteunt maximaal SMB 2.1. Zie ook de reactie van @SuperDre.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:51]

Microsoft adviseert "Block TCP port 445 at the enterprise perimeter firewall" en "Follow Microsoft guidelines to prevent SMB traffic leaving the corporate environment" in hun advisory (dank aan Djaro hieronder voor de link). De bug zit specifiek in SMB versie 3.1.1, en die wordt niet ondersteund op Windows 8 en ouder.
Op onze routers zie ik al heel lang poort 445 attacks, dan wel pogingen op SMB shares uit te komen.
Natuurlijk hebben we geen SMB shares open staan aan de WAN kant. Maar die 445 poort attacks zijn wel opmerkelijk.
Wat wij doen is: IP's die pogen een 445 poort te benaderen meteen op de blacklist te zetten. Dat IP kan vervolgens meteen 7 dagen lang geen enkele connectie met ons WAN netwerk maken. Zelfs geen mail droppen op SMTP/25.
Zoiets dergelijks doen we ook met poort 22, 23, 3389 en zo nog wat poorten. Iedere IP die iets probeert wat niet 'normaal'is blokkeren we meteen geheel.
Voor de duidelijkheid die genoemde poorten hebben we op geen enkele wijze toegankelijk vanaf de WAN kant, maar elke poging die te benaderen vinden we verdachte acties.
Mag ik vragen waarom slechts 7 dagen blacklisten?
Anders lopen de IP blacklist adreslijsten enorm op. Ik 'vang' per 7 dagen zo'n 70.000 unieke IP's die dit soort pogingen doen.Die adreslijsten kosten memory van de firewall.
Checken van inkomend verkeer tegen een adreslijst kost ook CPU power en dat geld dan ook voor 'normale' connecties want die worden ook gecontroleerd.

En na die 7 dagen worden de IP's die weer wat proberen er meteen weer er weer op gezet.

Mijn routers kunnen dit wel makkelijk aan, maar ik heb uit praktische overwegingen gekozen voor 7 dagen.
Binnen kost ga ik testen met 14 of meer dagen.

Voor je referentie ik gebruik hiervoor een Mikrotik CCR1036 EM versie met 16GB memory.
Duidelijk en helder verwoord. Maakt het duidelijk voor me, ik had niet het idee dat je zóveel unieke IP-adressen moest onderscheppen, vandaar mijn vraag. Bedankt voor je tijd!
Microsoft adviseert "Block TCP port 445 at the enterprise perimeter firewall" en "Follow Microsoft guidelines to prevent SMB traffic leaving the corporate environment" in hun advisory (dank aan Djaro hieronder voor de link).
Wat een beetje captain obvious opmerking is, want je moet uberhaupt niet 445 naar buiten open hebben staan. Dat is allang bekend. Als je daar nu een probleem mee hebt, dan had je waarschijnlijk ook al een probleem met WannaCry.
Het probleem met WannaCry was niet alleen het naar buiten open hebben staan.

Het probleem was meer dat het op wat voor manier dan ook binnen kwam en daar huis begon te houden. Bijvoorbeeld via email attachments, of een laptop die besmet is via gebruik van een onveilig netwerk. SMB staat bijna nooit naar buiten open en zeker niet bij de grote organisaties die getroffen zijn geweest door WannaCry.
Het probleem met WannaCry was niet alleen het naar buiten open hebben staan.
En nergens claim ik anders. Wel is het zo dat als TCP 445 naar buiten open stond dat je het tijdens WannaCry al gemerkt zal hebben dat het geen goed idee is. ;)

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:51]

Dat is voor heel veel systeembeheerders hopelijk super obvious, maar het zal ook veel voorkomen dat zulke technische bezwaren aan de kant gezet worden voor functionele eisen ("Jamaar de directeur wil het"). Met zo'n bulletin van Microsoft heb je wat extra munitie om duidelijk te maken dat poort 445 naar de buitenwereld openzetten echt, echt, echt geen goed idee is.
Windows 7 heeft nooit SMBv3 gehad, daarom moesten wij sowieso upgraden naar 10 ivm explorer integratie naar azure storage..
Windows 7 heeft nooit SMBv3 gehad,
Correct. De maximale versie is SMB 2.1. Reactie aangepast.
Het 2e is meer te vergelijken met het sluiten van een overdekt winkelcentrum, waarbij de winkels zelf nog wel openblijven.
445 blokkeren? Dan werkt je hele netwerk toch niet meer met smb? Of bedoelen ze alleen buiten > binnen? Dan ben je sowieso niet handig bezig als dit open staat.
Inderdaad, als je een organisatie hebt van > 100.000 desktops die ook gewoon hun werk moeten doen, dan heb je toch een groot probleem als er zoiets binnen komt en gaat lopen wormen. Intern poort 445 dicht zetten is ook niet echt een optie want dan kan niemand meer printen (en filesharing als je dat gebruikt - wij niet meer).

Niettemin, compressie uitzetten zou ook voldoende moeten zijn. En is redelijk pijnloos.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 19:51]

Intern poort 445 dicht zetten is ook niet echt een optie want dan kan niemand meer printen (en filesharing als je dat gebruikt - wij niet meer).
...en vergeet niet dat als je inlogt op je computer in een Windows domein, filesharing al wordt gebruikt voor het ophalen van group policies.
Als die 100.000 desktops in 1 netwerk stopt en die kunnen allemaal met elkaar lullen doe je per definitie al iets verkeerd, denk je niet?
Nee, niet echt. Er zijn applicaties die P2P moeten kunnen werken. Zo worden patches verspreid (1E Nomad) en er zijn ook videoconferencing applicaties die dit nodig hebben.

Uiteraard worden P2P SMB verbindingen wel geblokkeerd op langere afstand maar deze vulnerability betreft ook servers en die zijn natuurlijk wel wijder bereikbaar.
Er van alles zijn maar daar gaat het niet om, als men een netwerk met 100.000 clients bouwt die met elkaar kunnen praten is het per definitie flawed by design. Daar is niks veilig aan en dus is het van jou kant gewoon een heel slecht voorbeeld wat hopelijk in de praktijk nooit meer voorkomt.

Op servers kun je die compressie uitzetten maar voor clients zou ik wachten op een patch.
Vanaf extern inderdaad, maar dat zou je voorafgaand aan deze vulnerability ook al niet moeten willen...
Ik zou inderdaad SMB sowieso altijd dichtzetten van buiten naar binnen.
Dus als ik het goed begrijp dan is mijn Synology NAS niet vatbaar voor deze exploit?
Neen, het is de implementatie in Windows die de oorzaak is.
Hoe weet je dat zo zeker dan? Het artikel spreekt over een kwetsbaarheid in het protocol. Zonder verdere technische details is het gissen wat precies het probleem is. Aangezien Samba (Synology maakt gebruik van Samba voor SMB) een implementatie is van het SMB-protocol zou ik niet bij voorbaat uitsluiten dat Samba niet kwetsbaar is voor dit lek.
Thanks, dat is een belangrijk detail.
Een fout in het protocol zou veel erger zijn (samba ed)
Ik kan in de instellingen van de SMB service geen vermelding over SMB compressie vinden. Dat wil niet zeggen dat het niet beschikbaar is, maar het lijkt me dat "we" deze compressie niet kunnen inschakelen en/of dat het niet ingeschakeld staat. Ik weet niet hoe het staat met performance maar aangezien onze Synology alle performance nodig heeft om grote bestanden te kunnen serveren vermoed ik dat het standaard ook niet aan staat.
Ik heb er net de handleiding van Synology nog eens op nageslagen maar nergens wordt er over SMB compressie gesproken.
alleen server core installaties van Windows Server zijn geraakt en windows 10 veel varianten.

hier meer info
https://www.tenable.com/b...soft-server-message-block

[Reactie gewijzigd door Djaro op 22 juli 2024 19:51]

Dat klinkt niet echt aannemelijk; Windows Server Core is een gestripte Server versie. Het idee is dat je geen kwetsbaarheden kunt hebben in software die niet geïnstalleerd is. Maar Server Core heeft nog steeds dezelfde SMB stack als de gewone Windows Server, en dus dezelfde vulnerabilities. Ook de firewall is identiek.
Het gekke is dat de CVE pagina zelf nog steeds op 'gereserveerd' staat. Buiten geen technische details is er daar nog helemaal niets over bekend.

Het is duidelijk dat dit nog niet de bedoeling was om gecommuniceerd te worden. Ik denk dat er wel een nood-patch aankomt want gisteren was patch tuesday en een maand is lang...

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 19:51]

Nee een nood patch gaat hier naar alle waarschijnlijkheid niet voor komen. Waarom niet. Het is een lek wat privately disclosed is. Niemand weet dus hoe de exploid werkt.

Een noodpatch zal enkel gereleased worden als microsoft detecteert dat het lek misbruikt wordt. Tot nu toe geen reden voor paniek. Noodpatches zijn vreselijk voor de enterprise business en daar houdt microsoft veel rekening mee.
Als je een grote organisatie hebt met niet heel dikke wan verbindingen naar bijkantoren, is uitschakelen van de smb3 compressie niet fijn.
Titel is misleidend. Het is mogelijk, maar wordt nog niet actief gedaan voor zover bekend (geen PoC voor deze exploit).
Hoezo is het misleidend? Het is een kwetsbaarheid, en indien hij gebruikt wordt stelt hij daadwerkelijk iemand in staat om op afstand code uit te voeren. Er staat niet dat het actief misbruikt wordt. Sterker nog, in het artikel zelf staat
Microsoft meldt dat de kwetsbaarheid voor zover bekend niet actief misbruikt wordt.
Ik interpreteer de titel van dit artikel alsof het op dit moment al misbruikt wordt. Er is alleen bevestigd dat dit mogelijk kan gebeuren. Maar goed, zal wel mijn doemdenken zijn.
En dat nu net een hoop mensen thuis moeten werken....

Op dit item kan niet meer gereageerd worden.