Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 106 reacties

Beveiligingsonderzoekers hebben een veertien jaar geleden ontdekte kwetsbaarheid in Windows een nieuwe draai weten te geven. De onderzoekers wisten smb-logingegevens buit te maken met behulp van een malafide website, claimen ze.

De kwetsbaarheid bevindt zich onder meer in Windows 10, en is de eerste kwetsbaarheid in die nieuwe Windows-versie die van buitenaf te misbruiken is. Dat claimden beveiligingsonderzoekers Jonathan Brossard en Hormazd Billamoria op de Black Hat-beveiligingsconferentie in Las Vegas. Het beveiligingsprobleem dat ze misbruikten is een ontwerpfout van het smb-protocol, waar Microsoft wel maatregelen tegen heeft genomen maar nooit helemaal heeft opgelost.

De aanval is gericht op smb, het filesharing-protocol van Windows. Bij de zogenoemde smb-relay-aanval uit 2001 wordt smb-verkeer omgeleid naar een server die onder beheer van een aanvaller staat. Die krijgt daardoor de beschikking over de gebruikersnaam en de hash van het wachtwoord van de gebruiker. Die kan vervolgens in een aantal dagen worden gekraakt, omdat verouderde hashing-algoritmes worden gebruikt.

Brossard en Billamoria slaagden er in om die aanval over het internet te laten verlopen, bijvoorbeeld met behulp van een website. "Een website bezoeken is dan genoeg om gegevens te kunnen ondervangen", aldus Brossard. "De enige manier om je daartegen te wapenen, is de smb-poorten te blokkeren", zegt Brossard tegen Tweakers.

De impact van het beveiligingsprobleem hangt af van de configuratie van het slachtoffer. Gebruikt hij geen firewall op zijn pc of router en staat hij smb-verkeer van buitenaf toe, dan zou een aanvaller van buitenaf kunnen inloggen. Dat kan niet als een gebruiker een firewall heeft, maar het buitmaken van gegevens werkt dan wél, aldus Brossard tegen Tweakers.

De onderzoekers demonstreerden ook een aanval waarbij ze het beveiligingsprobleem vanuit een e-mail misbruikten; nadat het slachtoffer de mail opende, wisten ze met zijn logingegevens in te loggen op de Exchange-server en de mailbox door te sluizen.

De aanval is onder meer te misbruiken vanaf de Edge-browser in Windows 10, maar volgens de onderzoekers is vrijwel alle Windows-software zonder eigen tcp/ip-stack kwetsbaar. Chrome zelf is in ieder geval niet kwetsbaar, omdat die browser om toestemming vraagt voordat verbinding wordt gemaakt met een smb-server, maar plug-ins die vanuit Chrome worden aangeroepen mogelijk wel.

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (106)

De impact van het beveiligingsprobleem hangt af van de configuratie van het slachtoffer. Gebruikt hij geen firewall op zijn pc of router en staat hij smb-verkeer van buitenaf toe, dan zou een aanvaller van buitenaf kunnen inloggen
Of te wel, het risico is minimaal, zeer laag. Beetje overdreven geschreven door de redacteur |:(
Hier staat duidelijk geen firewall op zijn pc of router elke huis tuin en keuken router, elk modem tegenwoordig, elk routertje heeft standaard een firewall aan staan. Daarnaast staat op Windows standaard ook de Firewall aan. En elke goede virus scanner houd dit soort dingen ook in de gaten.

Verder noemt de onderzoeker
wisten ze met zijn logingegevens in te loggen op de Exchange-server en de mailbox door te sluizen.
waarschijnlijk een kwestie van overal de zelfde inloggegeven gebruikt.

En @tweakers, waarom staat er naast het linkje van wiki geen enkele referentie in het artikel? Nog enige link naar het onderzoek / het verhaal van de onderzoeker? Normaal gesproken worden artikelen toch wel iets beter gefundeerd. Voor het zelfde geld heeft de redacteur dit zelf bedacht met behulp van wikipedia. Want kom op zeg. 1 referentie in een heel artikel? Niet eens de link naar het verhaal? ;( :X


edit:
Toch lijkt het me zeer onwaarschijnlijk dat dit zomaar over het publieke internet gaat werken, omdat in normale omstandigheden wat poorten opengezet moet worden waaronder NetBIOS: nbsession(139), nbdatagram(138), nbname(137).

Verder zoals @mkools24 aangeeft
"Ook al zit je recht op het inet met je pc vrijwel alle isp's blokken netbios udp 139"
en dat klopt helemaal, zoals je kan vinden in t.net topic Welke provider blokkeert welke poort(en) hierin zie ik toch zeer duidelijk terug dat veel providers netbios blokkeren. Of te wel hoe lek samba ook is, als je provider niet open staat voor deze poorten, dan zou het op geen enkele manier vanaf het publieke internet mogelijk zijn, in tegen stelling tot wat het artikel beweert vanaf een e-mailtje.

@joost dankje, ja er bestaat inderdaad nog erg veel onduidelijkheid hier over

[Reactie gewijzigd door mmjjb op 6 augustus 2015 13:52]

Ik heb ook het gevoel dat het verhaal niet helemaal klopt, op zijn minst onduidelijk is. Internet Explorer (of Edge) is volgens mij de enige browser die standaard "Windows Authentication" (SMB/NTLM) naar een server stuurt. Dit doet hij default echter alleen naar sites uit de "Trusted Zone" of "Intranet Zone" (zie IE Security Settings). Dat zijn dus geen machines op internet, tenzij je die zelf hebt toegevoegd aan die zones. Ik zie niet in hoe je dat dan kan misbruiken, tenzij de aanvaller al een host heeft bemachtigd binnen het LAN van de user.

Andere browsers hebben meestal een bevestiging of policy setting met DNS namen nodig waarvoor SMB/NTLM authenticatie actief wordt gemaakt.

De link in het artikel gaat naar een aanval waarbij men SMBRelay gebruikt. Dit is echter een tool die moet draaien op de machine van de user, en onder Administrator permissies. Als de aanvaller dat voor elkaar krijgt is de machine sowieso al gekraakt, en is dit in verhouding niet echt een issue meer.

Al met al begrijp ik dus niet goed hoe de attack dan kennelijk werkt, en exploitable is vanaf internet.

Edit: Na nog wat verder hebben gelezen in andere artikelen: SMBRelay draait de aanvaller zelf op de machine die hij gebruikt als man-in-the-middle device. Dat hij daar Admin rechten heeft is logisch. :) Snap ik echter nog steeds niet hoe er SMB/NTLM authenticatie naar een server wordt verstuurd die op internet zit. Je kan inderdaad een mail sturen, met een embedded plaatje. Afhankelijk van de email client zal hij die automatisch proberen op te halen. Maar als dat geen server is op het LAN, dan gaat daar toch geen SMB/NTLM authenticatie naar toe default?

[Reactie gewijzigd door Joop op 6 augustus 2015 00:58]

Maar als dat geen server is op het LAN, dan gaat daar toch geen SMB/NTLM authenticatie naar toe default?
Volgens de onderzoekers in kwestie dus wel...
Ok. Ik had het interessant gevonden om nog wat meer te lezen hoe dat dan precies zit. Er zullen vast wel wat meer details nog over naar buiten komen komende uren/dagen.

Ik vind het iig erg leuk om te zien dat een Tweakers redacteur daar (Black Hat) bij is, en uit de eerste hand rapporteert.
Ok. Ik had het interessant gevonden om nog wat meer te lezen hoe dat dan precies zit. Er zullen vast wel wat meer details nog over naar buiten komen komende uren/dagen.
Ik zal ook proberen om de onderzoekers te benaderen voor wat extra vragen, omdat ik merk dat dit voor onduidelijkheid zorgt. :)
Mischien zou je dat soort vragen kunnen stellen en beantwoorden voordat je een artikel op Tweakers zet? Lijkt mij toch wel de meest journalistieke manier, dit is geen Twitter.
Is het niet zo dat Windows standaard de credentials van de ingelogde gebruiker gebruikt als een share om inloggegevens vraagt?
Niet eens de link naar het verhaal? ;( :X
Ik zat zojuist bij de talk waar dit werd gepresenteerd, dus helaas, dit ís het verhaal.

Verder: als jij vindt dat het stelen van logingegevens geen nieuws is, dan ben ik dat niet met je eens.
Kom op Joost, als je aan diverse randvoorwaarden moet voldoen en je stelt het alsof bij elke Windows gebruiker er gevaar dreigt, ben je niet goed bezig. Hoe interessant Black Hat conf ook is, wel reëel blijven.
Ach sommige mensen vinden het leuk om slecht te kunnen praten over Windows.
Ja, het kan voor onnodige zorgen zorgen. Maar vind je niet dat dit op Tweakers thuis hoort? Al dan niet in een wat genuanceerdere vorm.
Oke, maar een titel:
Windows lekt logingegevens smb naar internet
Lijkt wel erg gericht op sensatie ;)
Als een beetje firewall dit tegen houdt, en elke standaard W10 pc de firewall aan heeft staan, achter een router met ingebouwde firewall, is er toch niks aan de hand?
Of werkt deze aanval door de W10 firewall en de firewalls van de meeste routers?

Edit @ hieronder: Dat heb ik dus gedaan, en de titel en de inhoud spreken elkaar (voor mij iig) een beetje tegen daarin, de titel doet vermoeden dat het een extreem ernstig lek is waar we allemaal op dit moment slachtoffer van (kunnen) worden, de inhoud doet vermoeden dat 'een' firewall het al oplost, vandaar mijn vraag aangezien er dus nog geen artikel met uitgebreidere informatie is van de onderzoekers zelf.
Zeker met de zin:
Gebruikt hij geen firewall op zijn pc of router
Vraag ik me dus af of de standaard Windows Firewall hier ook onder valt, vandaar de vraag: houdt de Windows Firewall, die standaard aan staat, dit dus out of the box al tegen of niet? Want dat wordt nu niet duidelijk.

Verder bedoel ik het uiteraard niet om te klagen, als dit lek dus inderdaad zo ernstig is lezen we het graag, en zijn we heel blij dat je het plaatst, maar zoals het nu is, is het een beetje verwarrend zeg maar :)

Edit2: Goed, na vrijwel alle reacties door te hebben gelezen wordt duidelijk dat ondanks een firewall de logingegevens worden gelekt, maar dat een firewall misbruik van die logingegevens voor SMB zou voorkomen, dat die logingegevens in een andere aanval misbruikt kunnen worden is dan het directe probleem.
Had dat dan in het artikel gezet, dan is de titel ook een stuk duidelijker, zoals het nu staat lijkt het op click-bait terwijl het wel degelijk een goed punt heeft.
(Wat dus niet in het stuk te lezen viel...)

[Reactie gewijzigd door RGAT op 6 augustus 2015 04:19]

Of werkt deze aanval door de W10 firewall en de firewalls van de meeste routers?
Ja, wat je had kunnen weten als je het stuk had gelezen.

[Reactie gewijzigd door Joost op 6 augustus 2015 00:41]

Hi Joost,

Niet op de kast gaan zitten. Ik lees zelf een kritisch maar deels positive feedback op je stuk. Des al niet te min top als er door een Auteur even op de comments gereageerd wordt.

Back to basic inhoud ik snap je reactie nu even niet. Op de reactie " Of werkt deze aanval door de W10 firewall en de firewalls van de meeste routers?" zeg je ja. Terwijl ik uit het stuk haal dat dit dus enkel kan zonder firewall en als de betreffende smb-poort open staat.

Werkt deze kwetsbaarheid nu wel of niet indien de "standaard" firewalls / AV pakketten aanwezig zijn?

De intro van het door jou geschreven stuk doet vermoeden / genereerd de gedachten dat er een ernstig lek is maar zoals ik het lees is het naar me dunkt slechts kleine kwetsbaarheid met een zeer beperkte impact in uitzonderlijke situaties.
Je windows firewall of NAT router blokkeert wel inkomend SMB, dus het 'jatten' van je username en hash is mogelijk, het terug inloggen op je SMB share is in 99,999% van de gevallen onmogelijk.

Echter (zoals in het artikel staat) stel dit gebeurt op je kantoor PC, die netjes in een AD Domain zit, en de aanvaller weet dat mail.bedrijf.nl julllie exchange server is kan hij die username en password hash misbruiken om op je mailbox binnen te komen (en die bijvoorbeeld leeg te trekken), gebruik je dit lek in een gerichte aanval kan je in nog wel veel meer applicaties en diensten van een bedrijf binnen komen.
Echter (zoals in het artikel staat) stel dit gebeurt op je kantoor PC, die netjes in een AD Domain zit, en de aanvaller weet dat mail.bedrijf.nl julllie exchange server is kan hij die username en password hash misbruiken om op je mailbox binnen te komen (en die bijvoorbeeld leeg te trekken), gebruik je dit lek in een gerichte aanval kan je in nog wel veel meer applicaties en diensten van een bedrijf binnen komen.
Precies. Als je dus andere services naar buiten hebt open staan zoals vpn, mail, etc waarvoor dezelfde login wordt gebruikt dan ben je wel degelijk kwetsbaar. Bij heel veel bedrijven is dat ook zo. Dit is dus een zeer ernstig lek!
Inderdaad. Ik vind het ook heel duidelijk. Er wordt maar een gedeelte elke keer gequotes, maar er staat 'dat er niet met een firewall kan worden ingelogd via SMB' maar dat 'de gegevens wel gestolen kunnen worden met een firewall' in de zin erna.

Hoe dan ook ben ik erg benieuwd naar de extra informatie. Anders moeten er hoe dan ook toch maatregelen getroffen worden.
I beg to differ.

By default laat de Windows firewall (iig. op Windows 10) weliswaar outbound SMB traffic toe, maar dat is wel expliciet beperkt tot het lokale subnet.

De eigenlijke vulnerability is dus gewoon de gebruiker achter het toetsenbord.
En daar is geen enkele vorm van beveiliging tegenop gewassen ongeacht de software waar hij/zij mee werkt.
De impact van het beveiligingsprobleem hangt af van de configuratie van het slachtoffer. Gebruikt hij geen firewall op zijn pc of router en staat hij smb-verkeer van buitenaf toe, dan zou een aanvaller van buitenaf kunnen inloggen.
Wellicht dat deze zinsnede voor de nodige verwarring zorgt...........
Wokke kan mooi morgen hier een 'nuance' artikel over maken. Duidelijk sensatie artikel waar pas in de vierde alinea de belangrijke informatie wordt gebracht dat nagenoeg niemand last heeft van dit beveiligingslek door de standaard aanwezige Windows Firewall en in de meeste gevallen een router.
Is het sensatie of is het daadwerkelijk een probleem?

Voor thuisgebruikers zal dit probleem waarschijnlijk niet zo groot zijn... Voor bedrijven echter veel groter (en zeker voor bedrijven die thuisgebruik van de laptop toestaan).

Het probleem is namelijk dat de aanval wel degelijk door de firewall gedaan kan worden. Althans, deel 1, het verkrijgen van de username passhash. Dit is namelijk verkeer naar BUITEN. De meeste thuisnetwerken laten standaard alle verkeer naar buiten toe door. Dus ook SMB. Weinig gebruikers hebben een dichtgetimmerde firewall, waarbij ze niet de mogelijkheid hebben om gewoon op JA te klikken om een verbinding toe te staan.

Deel 2 echter (het inloggen vanaf het internet op een SMB share) is minder schokkend voor thuisgebruikers. PAT staat dit soort verbindingen simpelweg niet toe zonder een bewust gemaakte instelling (een port-forward) in de router.

Voor bedrijven is dit echter lastiger, aangezien de meeste bedrijven ofwel een webmail oplossing hebben, ofwel een VPN achtige oplossing. Aangezien SMB met je AD user geauthenticeerd wordt, en je AD user ook toegang heeft tot webmail en waarschijnlijk ook de VPN, is dit voor bedrijven wel degelijk een zeer serieus probleem. Aangezien deze aanval dus vanuit 2 verschillende plekken opgezet kan worden is het als bedrijf ook niet mogelijk om je hier goed tegen te wapenen (zonder de productiviteit van je gebruikers te beinvloeden). Je kunt namelijk alleen wat doen als je mensen verbiedt om thuis hun laptop te gebruiken.

Nagenoeg niemand last van is dus pertinent niet waar, en een sensatie artikel is het zeer zeker niet.
Die post gaat voorbij aan de volgende 2 feiten:
1. Bedrijfslaptops kunnen ook thuis en elders gebruikt worden waar SMB outbound niet geblokkeerd wordt.
2. ARP of DNS aanpassingen of overnames van machines binnen het lokale netwerk zijn niet nodig. een file:// redirect authenticeert ook automatisch op internet.
Hmmm. wrong button :)

[Reactie gewijzigd door TagForce op 6 augustus 2015 13:58]

Even offtopic. Als ik het goed begrijp zit je dus nu bij black hat confrence kunnen we hier een artikel of video item over verwachten?
NAT is geen firewall, het is geen security feature.
Idd, dat NAT 'vaak' een positieve bijdrage levert aan security is slechts een mooie bijkomstigheid.
NAT voegt in deze niets toe aan beveiliging, bijna nooit tot zelfs helemaal nooit.
Niets positiefs en niets negatiefs, het werkt nl. twee kanten uit.

De connectie wordt van binnen naar buiten opgezet waarbij interne ip via nat wordt vertaald naar een extern ip en die vertaling wordt in de state table van de firewall gezet.
De firewal zal ook automatisch de omgekeerde vertaling in de state table zetten.
Al het verkeer in omgekeerde richting zal daarom dus automatisch worden doorgelaten vanwege deze entry in de statetable.

In deze voegt de firewall zelf zelfs niets toe aan enige vorm van beveiliging tegen dit probleem.

Echter kijkende naar windows firewall (win 10) die bij default dit type verkeer beperkt tot het lokale subnet zal het bijzonder moeilijk zijn om dit probleem te misbruiken.

De vulnerability is dus eigenlijk alleen maar te misbruiken als willens en wetens alle vormen van beveiliging is uitgeschakelt.
De gemiddelde gebruiker zal niet eens weten hoe dat moet, en de gevorderde zal zoiets niet doen als hij een beetje z'n verstand gebruikt.
NAT voegt in deze niets toe aan beveiliging, bijna nooit tot zelfs helemaal nooit.
Niets positiefs en niets negatiefs, het werkt nl. twee kanten uit.

De connectie wordt van binnen naar buiten opgezet waarbij interne ip via nat wordt vertaald naar een extern ip en die vertaling wordt in de state table van de firewall gezet.
De firewal zal ook automatisch de omgekeerde vertaling in de state table zetten.
Al het verkeer in omgekeerde richting zal daarom dus automatisch worden doorgelaten vanwege deze entry in de statetable.

In deze voegt de firewall zelf zelfs niets toe aan enige vorm van beveiliging tegen dit probleem.
Maar de connectie van binnen naar buiten en buiten naar binnen is niet hetzelfde...
Van binnen naar buiten een SMB verbinding maken gaat van een willekeurige poort naar de poort van SMB (445)... Als je echter weer terug een verbinding op wil zetten met een SMB share binnen het netwerk vanaf het internet gebeurt dat ook met destination poort 445... En die staat niet in de state table... Even een voorbeeld:
lokale machine: 192.168.0.2
externe machine: 123.123.123.123

SMB van lokaal naar extern geeft het volgende in de statetable:
192.168.0.2 32547 123.123.123.123 445
123.123.123.123 445 192.168.0.2 32547

Nu wil je een verbinding maken naar een SMB share op de lokale machine vanaf de externe machine:
123.123.123.123 54753 192.168.0.2 445
Deze socket staat niet in de statetable, en zal dus gedropped worden.
Dat heb je verkeerd, het return verkeer van de opgezette SMB connectie komt altijd terug naar de random source poort en die staat wel degelijk in de state table en zal derhalve worden toegelaten.
Ik hoef helemaal geen nieuwe connectie te maken als er al een is, en dat is het hele probeem met NAT en waarom het geen enkele veiligheid biedt voor het issue dat hier wordt aangekaart.
Als je een share wilt benaderen op de aangevallen machine zul je wel degelijk een nieuwe connectie moeten opbouwen. De machine luistert namelijk niet naar SMB requests op de willekeurige poort. Dat doet de SMB daemon, en die luistert echt ALLEEN op poort 445. Dus wil je een SMB share openen op mijn machine, dan zul je een verbinding op moeten zetten met poort 445 op MIJN machine... Je kunt geen verbinding opzetten over de socket die mijn machine gebouwt heeft met de jouwe.
Je kunt slechts 1 verbinding laten lopen over een socket om data heen en weer te sturen. Wil je een nieuwe verbinding (bijvoorbeeld een extra share openen) maken dan moet je een nieuwe socket op laten bouwen.
Ik hoef voor dit probleem alleen niet een connectie op te zetten naar een share op de aangevallen machine, ik hoef er alleen maar voor te zorgen dat de aangevallen machine een connectie met mij opzet, daarna heb ik volledige controle en daar helpt NAT niet tegen, en dat was de bron van het hele betoog.
Jawel. Het enige wat jij krijgt met de verbinding die ik eerst met jou opzet is mijn username en password hash. Met die gegevens (en een snelle machine) kun jij binnen een dag mijn username en password bemachtigen. Maar met die gegevens zul je echt eerst nog verbinding met mijn machine moeten maken om ze te kunnen misbruiken.
Ik heb ook niet gezegd dat NAT een firewall is
Ook al zit je recht op het inet met je pc vrijwel alle isp's blokken netbios udp 139
netbios != smb

SMB is poort 445 (je kunt immers ook een share mounten op IP adres, en niet op Netbios naam).
Wat @TagForce hieronder zegt. Ik zit hier op m'n Fedora laptop verboden met m'n desktop in een andere ruimte via een SMB share. Via de firewall is poort 139/udp dicht (firewall-cmd --zone=public --permanent --remove-port=139/udp) op beide machines, en toch werkt m'n samba share gewoon nog. Zou, volgens jouw logica, niet mogen werken, maar toch werkt het
waarschijnlijk een kwestie van overal de zelfde inloggegeven gebruikt.
Als je in een bedrijfsnetwerk in een active directory zit, is dit natuurlijk al snel het geval. En dat is nou precies de situatie waar je de combinatie smb en exchange meestal tegenkomt. Overigens ook de situatie waar de impact van dit specifieke lek inherent het kleinst is: een beetje bedrijfsnetwerk blokkeert die smb poorten beide kanten op.

Ben het verder eens dat deze onderzoekers het risico hiervan erg overdrijven.
[...]
een beetje bedrijfsnetwerk blokkeert die smb poorten beide kanten op.
Ja, maar niet als je je gebruikers toestaat hun laptop elders te gebruiken (bijvoorbeeld bij klanten, of thuis)... Dan doet je router/firewall op kantoor helemaal niks meer aan het externe verkeer, en er zullen maar weinig bedrijven een software firewall oplossing gebruiken die verkeer naar buiten ook filtert op de juiste manier. 1. Dat is te duur, 2. Dat is moeilijk te beheren voor gebruikers die niet op kantoor zijn. 3. Waarom zou je, er is al een hardware firewall.
Als je in een active directory omgeving zit gebruik je tickets om je te authenticeren (Kerberos tickets om precies te zijn). De enigste uitzondering is naar de Domain Controller toe, die wilt je wachtwoord en in return krijg je tickets. Als je vervolgens naar een Exchange connecteert toont hij dat ticket waar min of meer opstaat => dit is persoon x onder autoriteit van Domain Controller X , Exchange controleert dat ticket op geldigheid en vervolgens kan je verder.

Je voordoen als een fileserver (wat de onderzoekers hier kort gezegd doen) in een AD omgeving gaat je dus nooit een wachtwoord opleveren, hoogstens een ticket.
Oke, een openlijk (wireless) netwerk dan in waarin gegevens worden onderschept en / of geinjecteerd dan? :)

Als je achter een router zit dan is het meeste namelijk automatisch al dicht. Een router kan je niet zonder fatsoenlijke forwarding van buitenaf benaderen naar binnen. Daar moet je echt ports gaan staan forwarden, je kunt niet zomaar op SMB, FTP of WEB komen.
Je provider blokkeert dan wel netbios naar het internet toe, maar word dit ook geblokkeerd tussen de eigen klanten?

En met de komst van IPv6 verdwijnt het gebruik van NAT opnieuw. NAT is trouwens nooit bedoeld of ontworpen om beveiligingsproblemen op te lossen. Dat is iets dat je er als bonus bij krijgt. Een goede firewall blijft belangrijk.

De standaard Windows firewall zal inkomend verkeer wel blokkeren, maar aangezien de aanval gestart word met behulp van het bezoeken van een website lijkt mij dat je hier eerst een uitgaande verbinding maakt, met andere woorden: de windows firewall zal niet veel blokkeren.

Een virusscanner zal ook het versturen van credentials niet tegenhouden, die moet virussen blokkeren, geen logingegevens beschermen.
Je weet dat bedrijfsnetwerken domain joined zijn en je windows username/password (die dus makkelijk te onderscheppen is) daarmee eigenlijk altijd gelijk is aan bijvoorbeeld een exchange server?
Als het klopt dat je wel de login gegevens te pakken kunt krijgen dan vind ik dat erg genoeg, ook als je vervolgens niet via smb remote kunt connecten. Het probleem daarbij is ook nog eens dat Windows 10 (en 8 daarvoor ook al geloof ik?) je met je Microsoft account in laat loggen. Met andere woorden, als je die logingegevens eenmaal hebt dan zijn er heel wat andere services ook ineens kwetsbaar.
[qoute]Verder noemt de onderzoeker
wisten ze met zijn logingegevens in te loggen op de Exchange-server en de mailbox door te sluizen.
waarschijnlijk een kwestie van overal de zelfde inloggegeven gebruikt.
[/qoute]

beetje nuance.. Lijkt mij...

Een enterprise user, met AD account. Heeft Exchange en zijn windows login en dus ook SMB gelijk.
Daar kan de gebruiker niets aan doen en de beheerder ook niet. Microsoft hangt daar erg op de AD structuur en dus ook users en wachtwoorden zullen gelijk zijn..

Zou ook lastig zijn als je nu al kijkt dat ik op het werk op 8 verschillende systemen 8 verschillende gebruikers accounts en wachtwoorden heb. Gebruiker hebben hier gemiddeld genomen 3 a 4 gebruikers gegevens..
Dat je Exchange dezelfde login heeft dan de andere servers in je netwerk lijkt me niet meer dan normaal (Active Directory).
Hier staat duidelijk geen firewall op zijn pc of router elke huis tuin en keuken router, elk modem tegenwoordig, elk routertje heeft standaard NAT en een firewall aan staan.
Wat je zegt is onzin. Ik heb de afgelopen maand nog een modem bij een kennis vervangen waar geen router in zat. Het was van Ziggo, en na een telefoontje werd het modem vervangen door een exemplaar met modem, dus dat probleem is opgelost. Maar ik durf te wedden dat er genoeg modems hier in het land zijn die geen router zijn, en dus geen firewall zijn.

Het is natuurlijk kwalijk dat Ziggo deze dingen niet uit zichzelf vervangt. Zeer slechte dienstverlening, en zelfs nalatig te noemen. Ze weten goed waar die modems staan en ze kunnen ook zien welk modem is aangesloten, dus wat houdt ze tegen, behalve een paar euro besparen?

[Reactie gewijzigd door kwikstaart op 6 augustus 2015 09:40]

..en dat klopt helemaal...
Helaas niet allen voor ipv6 en tunnels al helemaal niet. Met dat laatste heb je ook niets aan je nat router met ingebouwde firewall.
Je vergeet te quoten:
Dat kan niet als een gebruiker een firewall heeft, maar het buitmaken van gegevens werkt dan wél, aldus Brossard tegen Tweakers.
Die firewall beschermd je shares dus wel, maar niet het stelen van de login gegevens die vervolgens mogelijk misbruikt kunnen worden op andere diensten waar men hetzelfde wachtwoord gebruikt. En ja, dat is een probleem aangezien heel veel mensen overal hetzelfde wachtwoord gebruiken.
Verder zoals @mkools24 aangeeft
"Ook al zit je recht op het inet met je pc vrijwel alle isp's blokken netbios udp 139"
En zoals daaronder ook al staat, netbios != samba. Netbios is alleen voor (oude OS'en) die willen verbinden op naam.
Ik denk ook dat mensen met name kijken naar hun situatie en dat van bekenden. Zo zal het in Nederland vaak zo zijn dat de provider een router levert. Vergeet niet dat Nederland niet representatief is voor de gemiddelde situatie :)
Verder noemt de onderzoeker
wisten ze met zijn logingegevens in te loggen op de Exchange-server en de mailbox door te sluizen.
waarschijnlijk een kwestie van overal de zelfde inloggegeven gebruikt.
Ehm, je begrijpt het concept van een AD?

Normaliter koppel je je exchange accounts gewoon aan je algemene windows accounts zodat het allemaal overal werkt.

Dat is zo ongeveer 1 van de grootste selling points bij bedrijven qua MS-infrastructuur : Single sign-on en het werkt.
De gemiddelde gebruiker heeft daar nog niet eens invloed op.
Wat meer achtergrond .. het zal waarschijnlijk om iets dergelijks gaan : http://blog.cylance.com/redirect-to-smb

De webserver doet een redirect naar een file://ip-adres/ waarna de browser je smb naam en hash meestuurt. Dat stopt geen enkele router of huis-tuin-keuken firewall.

Als je een niet te moeilijk wachtwoord hebt, dan is via rainbowtables je wachtwoord makkelijk te achterhalen.

Er daarna gebruik van maken om bij je in te loggen, zal meestal niet werken, omdat je router/firewall dat niet toestaat. Maar gezien het hoge percentage mensen dat wachtwoord hergebruikt, is het een valide risico. Je wilt je wachtwoord niet lekken.

Voor de duidelijkheid, voor het lekken van je wachtwoord is het dus irrelevant of je smb verkeer blokkeert of niet. De gemiddelde huis-tuin-keuken router staat uitgaand al het verkeer toe (en het is trouwens poort 445 .. netbios-over-tcp)

[Reactie gewijzigd door Li0nHeart op 6 augustus 2015 08:20]

Op mijn oude Dlink 804 waren juiste de SMB poorten standaard naar binnen en naar buiten geblokkeerd ... het kan dus echt wel, ook op huis-, tuin- en keuken-routers.

Dat het bij veel mensen open staat is nog niet zon issue aangezien de optie voor het doorsturen van Windows credenials niet standaard aan staat voor de internetzone.
(IE openen -> Internet opties -> (tab) Geavanceerd -> [kop beveiliging] -> Geintegreerde Windows verificatie inschakelen.)
Dit soort issues is eigenlijk al heel lang bekend. Wat me opvalt is dat er blijkbaar nog steeds weinig onderzoekers weten dat er ook nog een fallback bestaat naar WebDAV. Dat wil zeggen: als bijv. Internet Explorer het niet lukt om over SMB een bestand op te halen, wordt het nog geprobeerd over WebDAV. En WebDAV, dat gaat natuurlijk mooi over HTTP, poort 80. En ja, ook daar kun je NTLM-hashes opvangen.
Dat geld alleen als je de webclient services aan gezet hebt of office 2010 gebruikt.
Op zich logisch dat deze kwetsbaarheid ook in Windows 10 zit als Microsoft zelf toegeeft dat ze de kwetsbaarheden in SMB nooit volledig op hebben kunnen lossen.

Zelf geef ik de voorkeur aan NFS, hoewel ik dat nooit fatsoenlijk aan de praat heb gekregen i.c.m. mijn NAS'sen.
Meeste mensen zitten ook achter een router. Denk dat het probleem zo niet groot is. Wel kun je als je bij een bedrijf een kabel kan inprikken vieze dingen doen
Ik mis een beetje wat nieuw is aan deze aanval tov deze van april van dit jaar die ook via internet ging.

Tenzij ik wat mis moeten er twee heel belangrijke zaken bestaan om dit te kunnen misbruiken:

Optie 1:
1) geen firewall op router, ofwel beter gezegd uitgaande SMB paketjes toestaan. (aka sysadmin faal |:( )
2) ARP level re-routing op het intranet. Ofwel men heeft een router of DNS server 'overgenomen'.

Optie 2:
-) een server 'overgenomen' hebben op het intranet netwerk.

Het "het werkt ook op Windows 10" is mooie marketing want niet verrassend. Maar wel nieuw is dat men het nu via het internet kan starten. Men doet een redirect naar een intranet adres. Dit wordt dan of gerouteerd naar een externe server, of een gecompromeerde inttranet server.

In beide gevallen moet een hacker echter al eerder toegang gekregen hebben tot het intranet. Het is dus een opvolg-aanval.
Ik zit met mijn laptop regelmatig in flexkantoren te werken. Hier zitten allemaal ondernemers op hetzelfde netwerk. (Zo'n 80 stuks)

Lijkt mij dat dit een mooie plek is voor een dergelijke aanval. Ik zie nu al als ik iets wil printen aan de lijst beschikbare printers wie er allemaal aanwezig is met zijn laptop :-)
Lijkt mij dat dit een mooie plek is voor een dergelijke aanval. Ik zie nu al als ik iets wil printen aan de lijst beschikbare printers wie er allemaal aanwezig is met zijn laptop :-)

Fantastisch _/-\o_

Echter dit kan enkel indien de ondernemers hun firewall op 'privaat netwerk' hebben gezet ipv de default 'publiek netwerk'. Maar indien ze private hebben gezet, kun jij ook gewoon met Wireshark al diezelfde hashes opzuigen.
Optie 1:
1) bedrijfslaptops kunnen ook elders gebruikt worden. Daar heeft een sysadmin geen vat op, en SMB outbound kan daar makkelijk toegestaan worden.
2) Waarom is dit nodig? Je kunt een file:// redirect doen naar een internet IP. Daarop wordt ook gewoon automatisch geauthenticeerd. (anders zou het blokkeren van poort 445 en 139 naar buiten toe ook niet nodig zijn, wat volgens CERT en Cisco in hun security bulletins een manier is om deze aanval te pareren).

Optie 2: Moot point. Optie 1 werkt al zonder problemen.
2) Waarom is dit nodig? Je kunt een file:// redirect doen naar een internet IP. Daarop wordt ook gewoon automatisch geauthenticeerd

Nee, niet automatisch. Dat is het punt, de redirect moet naar een intranet adres zijn.

Gewoon een URL file://www.teakers.net produceren zorgt er écht niet voor dat jouw PC jouw huidige login naam/password-hash naar Tweakers gaat versturen :)

Optie 2: Moot point. Optie 1 werkt al zonder problemen.

SMB outbound wordt standaard echter niet toegestaan bij de Windows Firewall. Immers anders zou er masaal al reeds gebruik gemaakt worden van dit lek. Het bestaat immer al meer dan 10 jaar. Dus wel degelijk een sysadmin faal als dat op eeen bedrijfsnetwerk wel kan.

Nu ik er wat meer over na heb kunnen denken, kom ik tot de conclusie dat dit laatste onderzoek echt helemaal niets toevoegt. Enkel wat hypen dat het in Windows 10 ook kan. Ja, dat is dus logisch.

Maar de volgende aanval had ik mij nog niet beseft. Ofwel, een variant van optie 2. Namelijk men hacked een PC op een intranet, maar heeft geen admin access. Door daarna phishing emails te sturen, kan men proberen de SMB hashes naar die PC door te sluizen. Met die wachtwoorden probeert men dan een gebruikersnaam te krijgen die meer rechten heeft.

Maar goed, die variant is enkel nuttig als de initieel gehackte PC niet zelf al packet sniffing kon doen. Immers anders kan men rechtstreeks op het intranet gaan sniffen.
Meeste mensen zitten ook achter een router. Denk dat het probleem zo niet groot is. Wel kun je als je bij een bedrijf een kabel kan inprikken vieze dingen doen
Behalve als je je wachtwoord hergebruikt op andere plekken en het om een gerichte aanval gaat.
Lekker kort door de bocht antwoord. Want het probleem van hergebruiken van wachtwoorden is iets algemeen bekends. Dat heeft weinig direct te maken met het 'gevonden' probleem.
Ook webportals in de bedrijfsomgeving voor bepaalde toegang zijn hierdoor automatisch kwetsbaar, net als inloggen via VPN omdat de un/pw combo vaak via een AD loopt en daarmee gelijk is voor één gebruiker op t netwerk.
Lijkt me nogal omslachtig; het meenemen van een geïnfecteerde USB-stick lijkt me handiger als je kwaad in de zin hebt. Het valt bovendien minder op om bedrijfsgeheimen mee te smokkelen dan ergens een netwerkkabel in te prikken.
Wat een foute titel. Zeer generaliserend en vermoedelijk denkt menigeen dat smb 'Smal & Medium Business' betekent.
Geen firewall? Wie gebruikt er tegenwoordig geen firewall, het staat standaard ingeschakeld.
SMB poorten van buitenaf open? In routers? Zeer onwaarschijnlijk.
Ligt het aan mij of is er weer een mooie lijst aan randvoorwaarden nodig? Ik ben ook 'kwetsbaar' als ik in m'n adamskostuum de snelweg bezoek.
Ja, tuurlijk hoor, "Windows lekt SMB LOGIN gegevens naar het internet". Ik had van Tweakers meer serieus werk verwacht. Jammer hoor.

Edit: kom op zeg, -1 voor een on topic menig?

[Reactie gewijzigd door geertdo op 6 augustus 2015 00:41]

Geen firewall? Wie gebruikt er tegenwoordig geen firewall, het staat standaard ingeschakeld.
Ik kom anders genoeg pc's tegen die geen Firewall en/of virusscanner hebben. Er zijn er ook legio die het (tijdelijk) uitzetten omdat een of meerdere programma's anders niet werken en men dit niet krijgt uitgezonderd.
Ja, tuurlijk hoor, "Windows lekt SMB gegevens naar het internet". Ik had van Tweakers meer serieus werk verwacht. Jammer hoor.
Dat is niet wat de kop luidt. Verder werkt het lekken van logingegevens ook als er wél een firewall is.

[Reactie gewijzigd door Joost op 6 augustus 2015 01:18]

Ok, 'logingevens', typefoutje van mij, maakt de titel en het artikel niet minder fout.
Ok, 'logingevens', typefoutje van mij, maakt de titel en het artikel niet minder fout.
Logingegevens buitmaken is een valide aanval. Die logingegevens kun je vervolgens weer bij een andere aanval gebruiken.
Het gaat erom dat de kop suggereert dat Windows continu smb logingegevens stuurt naar het internet.
Dit is niet het geval.
Een hacker kan achter de logingegevens komen als A) de pc geen firewall aan heeft staan B) de router geen firewall aan heeft staan C) IE/Edge zo ingesteld staat dat niet-vertrouwde sites Windows-credentials mogen gebruiken.

Deze combinatie van factoren maakt dat het lek nauwelijks te exploiteren valt.

Je doet alsof er een zeer groot probleem is, terwijl dat relatief mee valt.
Verder is je reactie naar @0:41 RGat niet echt netjes, aangezien in je stukje nota bene vermeld wordt dat e.e.a. niet door firewalls heen gaat.
Verder is je reactie naar @0:41 RGat niet echt netjes, aangezien in je stukje nota bene vermeld wordt dat e.e.a. niet door firewalls heen gaat.
De bug waardoor logingegevens kunnen worden afgevangen dus wél. Alleen inloggen op smb werkt standaard niet, want dan moet je inderdaad wel iets hebben opengezet. Maar: vind jij het wenselijk dat logingegevens kunnen worden doorgesluisd naar websites, ongeacht wat er vervolgens mee gebeurt?
Ik weet het niet hoor. Heb jij verschillende logins voor elke plek waar je kan inloggen? Alleen voor samba is het al handig als je je server login gelijk houdt aan je windows login.

Joost heeft een punt. Je wilt je account niet naar buiten hebben, ook al heb je een firewall. Dan eindigt hij in een attack dictionary en ben je volgende week op een ander platform of site wel gehackt.
Dit was met Defcon 18 ook al gepresenteerd. En met DC 22 laatst ook weer een talk die dit omvatte. Waarom blijft dit 'nieuws'? Het kon al een tijd en het kan nog steeds en het is bekend dat het al 14 jaar kon, het is gewoon slecht en dat weten we allemaal als het goed is.

Natuurlijk zijn er mensen die blind vertrouwen in moeilijk te controleren software, maar die zullen met dit soort nieuws niet echt opeens hun gewoontes opzij zetten...
Voor sommige mensen is dit wel nieuws. Ik heb dit nooit gelezen, dus in dat opzicht ..
Ja, natuurlijk zijn er mensen die dingen niet weten of een nieuwsbericht de eerste drie keer missen ;) Ik doelde eigenlijk ook meer op mensen die überhaupt van het bestaan van SMB af weten, en bijvoorbeeld weten wat NTLM is en hoe credentials werken.
Wie heeft SBM poort openstaan? Welk jaar is dit?
Toevallig ben ik voor de Chromecast aan het kijken of ik kan streamen via SMB :). Ja, NFS zou ook kunnen maar bij SMB heb je geen extra software/services nodig. Het lijkt me dus dat er zeker wel mensen zijn die SMB shares gebruiken maar dan in hun eigen netwerk. Je gaat dus in de router niet de poorten voor SMB openzetten. Voor hen die het niet gebruiken is het al in Windows Firewall geblokkeerd.
En als de router de buggy UPnP actief heeft naar internet toe?
Want men vind het zo handig, dat deuren automatisch open gaan naar en van internet.

[Reactie gewijzigd door 631029 op 6 augustus 2015 09:40]

Iedereen met een windows machine in huis?
Zou dit probleem ook in OS x zitten. Heb de laatste tijd veel mails van Apple research. Gebruik het Dev beta plan van Apple met OS X El Capitan. waar nog veel beveiligings bugs in zitten. Kan geen kwaad om eens te na te checken. :?
Nee, want OS X doet niet aan NTLM auth zonder meer. Je moet daadwerkelijk op een AD zitten en zelfs dan is meestal NTLM niet mogelijk en alleen Kerberos.
idd, Netbios wordt standaard geblokkeerd door de meeste isp's, dus niks aan het handje.
Had wel nice geweest als Microsoft de zwakheden zouden patchen van SMB aangezien het hun protocol/product is en zoiets beter bij de bron opgelost kan worden.
Netbios != SMB
SMB is poort 445 en die wordt gewoon doorgelaten door ISPs.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True