Patches komen beschikbaar voor Badlock-kwetsbaarheid in Samba en Windows

Er zijn patches beschikbaar gekomen voor kwetsbaarheden in verschillende versies van Samba, bekend onder de naam 'Badlock'. Ook Windows is getroffen door het lek, dat een aanvaller onder andere in staat stelt een man-in-the-middle-aanval uit te voeren.

Het lek was drie weken geleden al aangekondigd op een speciaal ingerichte site en treedt daarmee in de voetsporen van andere branded kwetsbaarheden zoals Heartbleed en Drown. Er werd veel gespeculeerd over de ernst van het lek en de verwachting was dat het op afstand te gebruiken zou zijn via remote code execution. Dit blijkt nu echter niet het geval te zijn, omdat een aanval niet van buiten het netwerk uitgevoerd kan worden.

De kwetsbaarheid, met nummer cve-2016-2118, maakt een man-in-the-middle-aanval tegen Samba-protocollen mogelijk, waarmee verschillende acties op het netwerk uitgevoerd kunnen worden via het onderschepte verkeer van een gebruiker. In het geval dat het bij deze gebruiker om een beheerder gaat, kunnen bijvoorbeeld gegevens in de Active Directory-database ingezien en aangepast worden, zoals wachtwoord-hashes. Bij een standaardserver kunnen onder andere gebruikersrechten aangepast worden. Ook kan een aanvaller een Denial of Service-aanval uitvoeren, zolang hij in verbinding staat met de Samba-dienst.

Badlock hangt samen met een aantal andere kwetsbaarheden en heeft met een cvss van 7.1 een risico-inschatting in de categorie 'hoog' toegewezen gekregen. Daarmee gaat het niet om een kritiek lek. Getroffen versies van Samba waar geen patches voor uitkomen, zijn 3.6.x, 4.0.x en 4.1.x. Deze worden namelijk niet meer ondersteund. Voor de nieuwere versies zijn patches uitgekomen met versies 4.4.2, 4.3.8 en 4.2.11. Er wordt dan ook aangeraden om een update uit te voeren. Ook Microsoft heeft patches beschikbaar gesteld.

Samba is een opensource-implementatie van het smb/cifs-netwerkprotocol. Dit protocol is aanwezig in Windows en maakt het mogelijk om bestanden en printers via het netwerk te delen. Om interoperabiliteit met andere besturingssystemen als Linux, Unix en BSD te faciliteren is Samba in het leven geroepen. Daardoor kunnen bijvoorbeeld Linux-servers deelnemen in een Active Directory en ook fungeren als domain controller.

De kwetsbaarheid werd ontdekt door Stefan Metzmacher. Hij maakt deel uit van het Samba-team en werkt bij het Duitse SerNet, dat zich onder andere bezighoudt met de ontwikkeling van de software. De patch is in samenwerking met Microsoft tot stand gekomen, nadat Metzmacher het bedrijf op de hoogte had gesteld.

De manier waarop Badlock is aangekondigd stuitte op kritiek uit de beveiligingscommunity. Volgens SerNet is er voor een ruime aanloop gekozen om zoveel mogelijk aandacht voor de kwetsbaarheid te genereren. Anderen zeggen echter dat daarmee potentiële aanvallers de tijd kregen om de Samba-broncode te onderzoeken en zelf de kwetsbaarheid te ontdekken. Ook zou SerNet zelf profiteren van alle publiciteit. Daarnaast zou Metzmacher zelf verantwoordelijk zijn voor een groot deel van de code, waarin hij de kwetsbaarheid heeft ontdekt.

Nu blijkt dat de kwetsbaarheid een stuk minder ernstig is dan verwacht, is het mogelijk dat deze vermoedens meer voeten in de aarde krijgen.

Reacties (37)

[Jorgen]

Of hij de code nu wel of niet grotendeels zelf heeft geschreven, het is goed dat hij het gemeld heeft. Nu profiteert hij misschien van de exposure, maar dat vind ik altijd nog beter dan iets proberen te verzwijgen.

[Verwijderd]

Nee, dat is veel te simpel. Lees evern: https://www.riskbasedsecu...ng-badlock-vulnerability/ en je verwijderd je post (alsjeblieft? Ik weet dat het aardig wat complex leeswerk is) . Herr Metzmacher heeft heel wat uit te leggen.

Als hij het helemaal niet doorgegeven had dan was de boot natuurlijk helemaal aan. Maar het melden van een behoorlijk groot gevaar is geen plus maar een plicht voor iedereen die vind dat veiligheid op het internet belangrijk is.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 10:51]

[EnigmA-X]

Herr Metzmacher heeft heel wat uit te leggen.

Voor de mensen die geen zin hebben om te lezen (en vervolgens gaan zitten downvoten), degene die de kwetsbaarheid heeft "ontdekt" lijkt dezelfde persoon te zijn die in 2006 aan het stukje code heeft gewerkt.

Voor meer info: https://www.riskbasedsecu...ng-badlock-vulnerability/

[mae-t.net]

En dat het dezelfde persoon is, is ook volgens het aangehaalde artikel volstrekt irrelevant. Het gaat immers niet om een fout die hij heeft gemaakt.

En zelfs al zou hij die fout zelf hebben gemaakt, dan nog is er niets mis mee dat hij hem als eerste ontdekt. Des te beter zelfs, kennelijk zit hij dieper in de materie dan de meeste anderen.

Waar het volgens het artikel foutgaat, en daar heeft het een punt, is dat het disclosen op een wat aparte manier is aangepakt waardoor er relatief veel aandacht uitging naar een relatief niet zo zwaar probleem.

[EnigmA-X]

En dat het dezelfde persoon is, is ook volgens het aangehaalde artikel volstrekt irrelevant. Het gaat immers niet om een fout die hij heeft gemaakt.

Irrelevant vind ik het zeker niet, dat zegt het artikel overigens ook niet (volgens mij). Hij heeft in een periode van ruim 10 jaar in meer dan 450 bestanden bijdrages geleverd, ik heb de diffs nog niet bekeken. Het artikel zegt wél dat hij niet persé de boosdoener is.

Beter geformuleerd dan een "aparte manier van aanpak":

It is certainly eye opening when someone develops a piece of software for over a decade, then finds a critical vulnerability in it a couple years after their name starts disappearing from soure code copyright, and will most likely capitalize on it directly.

Verder is dit zeker een serieuze vulnerability en al helemaal omdat hij kennelijk al zo lang bekend was, maar niet publiekelijk. De impact is groot, ik vind het dus wel terecht dat hier zoveel aandacht voor is.

[mae-t.net]

Dus de enige klacht die volgens jou overblijft is dat het aandachtszoekerij zou zijn... Dat hij de fout al jaren kent, MS daar nooit van op de hoogte heeft gesteld, en hem in zijn eigen software pas verhelpt als hij te weinig aandacht krijgt?

Kan natuurlijk allemaal, maar het ligt meer voor de hand dat hij in de tussentijd betere dingen te doen had en daarna met een verse blik nog eens naar zijn oude project keek.

[Reactie gewijzigd door mae-t.net op 26 juli 2024 10:51]

[Verwijderd]

"degene die de kwetsbaarheid heeft "ontdekt" lijkt dezelfde persoon te zijn die in 2006 aan het stukje code heeft gewerkt."

Maar de fout zit ook Microsoft Windows. Dus hoe zit dat? Metzbacher heeft die Windows-code toch niet geschreven?

[EnigmA-X]

The SAMR and LSAD remote protocols are used by Windows and Samba (for UNIX-like platforms) to authenticate users to a Windows domain. A flaw in the way these protocols establish RPC channels may allow an attacker to impersonate an authenticated user or gain access to the SAM database. CVE-2016-2118 identifies this vulnerability in Samba, while CVE-2016-0128 identifies this vulnerability in Windows.

Bron: http://www.kb.cert.org/vuls/id/813296

Ze maken beiden dus gebruik van hetzelfde protocol en zijn dus beiden kwetsbaar.

[Soldaatje]

En dat zegt wat precies?
Ik zie niet in wat daar mis mee is.

[bommel]

Samba is ontwikkeld als een Open Source implementatie van SMB, het kan dus heel goed dat betreffende ontwikkelaar (Herr Metzmacher) deze vulnerability heeft overgenomen van de protocol specificatie (of via reverse engineering)?

[Reactie gewijzigd door bommel op 26 juli 2024 10:51]

[mae-t.net]

Zou je me aanbevelen om, alvorens te besluiten niet mee te doen aan de lynchpartij, veel tijd en moeite te steken in het aandachtig lezen van een artikel dat al vrijwel bovenaan een omineuze dooddoener heeft staan als:

With thousands of talented exploit developers out there, the odds of someone finding the same issue, or one equally serious, is considerable.

?

Hoewel ik niet meedoe aan de lynchpartij, lijkt het er wel op dat de melding van de vulnerability niet helemaal volgens de regelen der kunst is gegaan. Richtlijnen waar overigens ook veel discussie over is maar waar het artikel absoluut de vinger op de zere plek legt. Zelfs al is het gezien bovenstaand citaat ook niet helemaal zuiver op de hype-graat

[Reactie gewijzigd door mae-t.net op 26 juli 2024 10:51]

[robvanwijk]

Nee, dat is veel te simpel. Lees evern: https://www.riskbasedsecu...ng-badlock-vulnerability/ en je verwijderd je post (alsjeblieft? Ik weet dat het aardig wat complex leeswerk is) . Herr Metzmacher heeft heel wat uit te leggen.

Met alle respect, maar de belangrijkste paragraaf van die pagina waar je naar linkt:

RedHat’s advisory for Badlock offers more clarity on the issue than Microsoft or Samba, and strongly suggests these are protocol flaws, saying it “affects all applications implementing [the DCE/RPC-based SAMR and LSA protocols], including Samba, and Microsoft Windows.”

(emphasis added)

Ik vind het niet realistisch om te verwachten dat iedereen die een protocol implementeert het in detail bestudeert en exact naloopt op security issues. Dat is (naast interoperability) nou juist één van de grote voordelen van een protocol: de ontwerper zorgt dat het protocol goed in elkaar zit, jij hoeft alleen te zorgen dat je geen fouten maakt (kwetsbaarheden introduceert) bij je implementatie.
Als het SMB protocol zegt "Doe A, B en C." dan is het hartstikke logisch dat hij code schrijft die A, B en C doet. Wat mij betreft hoeft hij niet uit te leggen waarom het in de goede volgorde en met precies de juiste parameters aanroepen van die dingen een gat in de beveiliging oplevert; die vraag zou ik in eerste instantie willen stellen aan de ontwerpers van SMB.

Voor de duidelijkheid, de soap die ze gemaakt hebben van deze disclosure vind ik stompzinnig en lijkt weinig goeds gedaan te hebben; als je hem dat aan wil rekenen heb ik daar geen enkel probleem mee. Het verhaal hierboven dient enkel om uit te leggen waarom ik hem het introduceren van het probleem niet aan wil rekenen.

[Reactie gewijzigd door robvanwijk op 26 juli 2024 10:51]

[Troepje]

Was niet een van de ideeën van dat open source beter zou zijn, dat omdat iedereen het kan lezen, de kans groter is dat dit soort lekken gevonden worden?

[sfc1971]

Het probleem is door een opensource developer gevonden en gemeld aan een closed source bedrijf die het zelf niet had opgemerkt, of had je gemist dat Windows ook kwetsbaar is?

[elmuerte]

Blijkbaar zit de bug ook in Windows, en niet alleen Samba. De titel en content van het artikel laten anders overkomen.

Op zicht wel interessant dat 2 onafhankelijke implementaties dezelfde security bug bevat.


De nieuwe trend van catchy namen en speciale websites voor security issues bevalt me niet echt. Te veel sensatie.

[SunnieNL]

Vind inderdaad dat in het artikel ook een verwijzing mag komen naar de update van Microsoft om het probleem ook in Windows aan te pakken

[EnigmA-X]

Op zicht wel interessant dat 2 onafhankelijke implementaties dezelfde security bug bevat.

De kwetsbaarheid zit in het protocol, dus opzich is het niet zo bijzonder.

Any authenticated DCE/RPC connection that a client initiates against a server could be used by a man-in-the-middle attacker to impersonate the authenticated user against the SAMR or LSA service on the server. As a result, the attacker would be able to get read/write access to the Security Account Manager database, which could reveal all passwords and any other potentially sensitive information.
The client-chosen application protocol, authentication type (for example, Kerberos or NTLMSSP), and authentication level (NONE, CONNECT, SIGN, or SEAL) do not matter in this case. A man-in-the-middle attacker could downgrade the authentication level to CONNECT and take over the connection. The Badlock issue is fixed along with a series of CVEs as documented here:
Important Security flaws in Samba released on 12-April-2016 (CVE-2015-5370, CVE-2016-2110, CVE-2016-2111, CVE-2016-2112, CVE-2016-2113, CVE-2016-2114, CVE-2016-2115, CVE-2016-2116) .

[duqu]

Goede opmerking, ik maak het wat duidelijker

[i-chat]

ik ben benieuwd hoe dit uit gaat pakken voor oudere versies van samba zoals 3.6, met samba 4 hebben ze namelijk nogal wat keuzes gemaakt die gewoon niet handig zijn... het intergreren van een hele MS-ADC clone bijv, leuk als je met jouw device gemakkelijk bestanden wilt delen met een windows pc, maar of je kiest voor het verouderde en niet langer ondersteunde samba 3, of je mag gelijk een hele zut aan dependancies en systeem-verslindende services gaan introduceren.

zo vraag ik me oprecht af hoe bedrijven als synology dit hebben aangepakt. \
en of deze iets denken te gaan doen aan dit soort issues.

[goarilla]

Je kan samba 4 nog altijd inzetten als stand alone fileserver en dan heb je hun kerberor, ldap service en dns hooks toch niet nodig ? Je kan zelfs nog altijd een NT4 style domain draaien (https://wiki.samba.org/index.php/Samba_NT4_PDC_quickstart).

[rbr320]

Toch is de vraag van @i-chat relevant. Ik draai thuis een Ubuntu 14.04 LTS server en deze komt met Samba versie 4.1.6, die dus officieel niet meer ondersteund wordt. Nu gebruik ik Samba thuis niet als domain controller maar inderdaad als stand alone fileserver met een paar simpele shares, maar ik kan me voorstellen dat er bedrijven en instanties zijn die wel gebruik maken van deze features en dus nu met een kwetsbaarheid in hun IT omgeving zitten. Canonical komt nog deze maand met zijn nieuwe LTS release van Ubuntu (16.04) die wordt geleverd met Samba 4.3.6, maar in een grote IT omgeving doe je niet zomaar even een upgrade zodra er een nieuwe release is.

Ik hoop dus dat bedrijven als Canonical en ook Red Hat en Suse de fix indien mogelijk zullen backporten naar releases van hun distro die nog ondersteund worden maar die met een oudere versie van Samba geleverd worden.

[Reactie gewijzigd door rbr320 op 26 juli 2024 10:51]

[MadEgg]

Debian backport vrijwel alles aangezien zij zeer star zijn in het upgraden van versies naar een nieuwe versie. Als de maintainer zelf geen nieuwe versie uitbrengt dan backport Debian de wijzigingen naar de oudere versie. Canonical plukt hier de vruchten van, en doet het soms zelf ook wel. Maar aangezien Samba toch server software is verwacht ik in dit geval dat de backport van Debian afkomstig zal zijn.

Het lijkt me aannemelijk dat Red Hat wel iets soortgelijks zal doen voor de enterprise distributies.

[Valhorth]

Red Hat heeft hier inderdaad ook de nodige stappen ondernomen en de nodige backports gemaakt.

https://access.redhat.com/security/vulnerabilities/badlock
https://www.redhat.com/ar...unce/2016-April/date.html

En uiteraard kan CentOS niet achterblijven

https://lists.centos.org/...unce/2016-April/date.html

[goarilla]

maar in een grote IT omgeving doe je niet zomaar even een upgrade zodra er een nieuwe release is.

Nee inderdaad. Het kan wel is heel erg zijn in een "professionele omgeving" zeker als de turnover van je IT personeel hoog is en vervanging lang uitblijft. Maar soms moet je ook een hogere versie installeren dan je distro's versie ookal is hij gebackport. Omdat je anders bepaalde clients niet kan ondersteunen (Windows Vista destijds). Dus zorg dat je altijd zelf RPM of DEB's kan bouwen voor de Enterprise distro die je gebruikt.

De grootste problemen die ik ondervond toen ik van een stand alone 3.6 naar een 4.2 samba server ging was het overhevelen van de juiste tdb files naar de juiste plek. Deze pagina kan daarmee helpen (https://www.samba.org/sam...HOWTO-Collection/tdb.html). En files execute permissies geven omdat samba4 die wel respecteert. Voor een workaround (https://wiki.samba.org/index.php/Shares_with_POSIX_ACLs).

[rbr320]

Het gedoe met die tdb files wist ik van. Dit was helemaal een ramp op Debian en aanverwante distro's omdat die het net even anders deden als dat het Samba team het bedacht had. Ik meen dat dit met de introductie van Samba4 is rechtgetrokken maar ik heb er nog weinig ervaring mee.

Fijn om te weten dat Samba4 eindelijk de execute bit respecteert, hoewel ik hier niet direct een use case voor zie. Als je een .exe file kan lezen kan je hem altijd gewoon even kopiëren naar de lokale schijf en hem daar uitvoeren.

[goarilla]

Fijn om te weten dat Samba4 eindelijk de execute bit respecteert, hoewel ik hier niet direct een use case voor zie. Als je een .exe file kan lezen kan je hem altijd gewoon even kopiëren naar de lokale schijf en hem daar uitvoeren.

Ja maar je weet mogelijk niet wat je allemaal moet meekopieren. Het programma verwacht zijn data meestal relatief aan z'n locatie.

[rbr320]

Klopt dat het niet op gaat voor complexe software pakketten, maar voor simpele programma's die maar uit 1 binary bestaan zoals Putty werkt het prima. En laat dat nou juist ook het geval zijn bij veel malware.

[bommel]

Why You Should Stop Saying “CIFS” and Start Saying “SMB”

[MadEgg]

Interessant. Knap staaltje van onhandige naamgeving van Microsoft. Kort samengevat: ze nemen SMB, ontwikkelen het een tijdje door, gaan dan over op CIFS, besluiten dat dat niet goed is en maken een nieuw protocol en noemen dat wederom SMB. Ok, SMB2, maar die 2 klinkt als een nieuwe versie van hetzelfde protocol, waarbij je het protocol dus gewoon SMB blijft noemen.
Onhandig. Hadden ze beter een compleet andere naam kunnen verzinnen (zoals de overgang van FAT naar NTFS, dat is duidelijk).

Maar goed, naamgeving / nummering is nooit het sterktste punt geweest: Windows 1, 2, 3, 95, 98, Me, XP, Vista, 7, 8, 10.. Xbox, Xbox 360, Xbox One. Volstrekt logisch allemaal.

Kunt mensen de verwarring dus moeilijk kwalijk nemen, als ze CIFS gebruiken waar het eigenlijk SMB2 zou moeten zijn (En dus ook niet SMB).

[bommel]

CIFS dateert van 1995/1996 en is in 2006 opgevolgt door SMB2, om maar een botte vergelijking te maken: SMB2/3 CIFS noemen is hetzelfde als Windows MS-DOS noemen

[MadEgg]

Alleen is de constructie hier nog wat bizarder. Eigenlijk zou het vergelijkbaar zijn als Microsoft Windows 10 nu MS-DOS 10.0 had genoemd, waarna het ons verweten zou worden als we het toch nog Windows zouden noemen. Volgens het artikel wat bommel aanhaalt is CIFS namelijk weer gebaseerd op SMB1 wat in Windows for Workgroups gebruikt werd.

[PolarBear]

Maar goed, naamgeving / nummering is nooit het sterktste punt geweest: Windows 1, 2, 3, 95, 98, Me, XP, Vista, 7, 8, 10.. Xbox, Xbox 360, Xbox One. Volstrekt logisch allemaal.

Zijn allemaal marketingnamen, de versie nummering van de kernel in de 9x branch en de NT branch zijn redelijk consistent hoor. Ok, met Windows 10 is een rare sprong gemaakt, maar nog steed opvolgend.

[MadEgg]

Ja, maar het gaat er dus om hoe het bekend staat. Zo gaan in ieder geval de consumenten het herinneren, en waarschijnlijk de meeste techies ook. Hoeveel mensen noemen Windows XP nou daadwerkelijk Windows NT 5.1? Behoorlijk weinig.

Die naamgeving maakt het er niet duidelijker op.

[SunnieNL]

Zit het probleem alleen in Samba of ook in het SMB protocol/implementatie van Microsoft?

Edit: al gevonden. Ook Microsoft heeft een hotfix uit voor Vista en hoger
https://technet.microsoft.com/library/security/MS16-047

[Reactie gewijzigd door SunnieNL op 26 juli 2024 10:51]

[ColdRain]

Zit (gelukkig) ook in de wsus update-cycle van vanavond.

[Verwijderd]

Let op, de hotfix gaat niet over SMB direct, maar over het downgraden van de security zodat de gebruiker meer kan. Het verschil tussen Important en Critical zeg maar:

Q: My application or product uses the SMB protocol, does this issue affect me?
A: No. Only applications and products that use the SAM or LSAD remote protocols are affected by this issue. The SMB protocol is not vulnerable.

Daarnaast moet je wel altijd je windows updates draaien, en in dit geval (sowieso) nooit publiekelijk de RPC poorten open hebben staan.

https://technet.microsoft.com/library/security/MS16-047
https://support.microsoft.com/nl-nl/kb/3148527

[Reactie gewijzigd door Verwijderd op 26 juli 2024 10:51]

[goarilla]

Versies lager dan 3.6 worden dus niet getest, hier (https://www.samba.org/samba/history/) is dit te lezen:

Affected Versions: 3.6.x, 4.0.x, 4.1.x, 4.2.0-4.2.9, 4.3.0-4.3.6, 4.4.0 (earlier versions have not been assessed)

En in een gerelateerde samba CVE https://www.samba.org/samba/security/CVE-2015-5370.html staat ook het volgende:

Note that versions before 3.6.0 had completely different marshalling
functions for the generic DCE-RPC layer. It's quite possible that
that code has similar problems!

Dus mensen met (oude NAS) appliances. Zoals ik met mijn Synology DS410 (samba 4.1.18) hebben pech. Alsook mensen met verouderde overgeerfde domeininfrastructuur. Zoals ik met RHEL4 (samba verisie.is.zo.oud.dat.ik.het.niet.durf.melden) hebben ook pech.