Bug in Windows maakt aanval op gesloten udp-poorten mogelijk

Windows 7, Vista en beide Server 2008-versies bevatten een ernstige bug die het mogelijk maakt om code te injecteren via een gesloten udp-poort. Microsoft heeft een patch uitgebracht om het beveiligingsprobleem te verhelpen.

Microsoft heeft met het uitbrengen van een patch gewacht tot zijn maandelijkse patchronde, wat aangeeft dat de kwetsbaarheid waarschijnlijk nog niet in het wild wordt misbruikt. Dat doet niets af aan de ernst van het beveiligingsprobleem: het stelt kwaadwillenden in staat om code uit te voeren op een systeem met een recente Windows-versie, door een stroom udp-pakketten naar een gesloten poort te sturen.

Dat de door Microsoft als 'kritiek' bestempelde kwetsbaarheid juist werkt op gesloten poorten, maakt deze extra ernstig, evenals het feit dat er op afstand code kan worden uitgevoerd. Volgens Microsoft wordt het probleem veroorzaakt door een bug in de tcp/ip-stack van recente Windows-versies: daar gaat iets fout met het verwerken van udp-pakketten in het geheugen. Udp is een gegevensprotocol dat op hetzelfde niveau werkt als tcp. In Windows worden udp-pakketten verwerkt door de tcp/ip-stack.

Microsoft heeft een patch uitgebracht die het probleem moet verhelpen. Gebruikers van Windows 7, Vista, Server 2008 en Server 2008 R2 moeten de patch installeren om zichzelf tegen het probleem te beschermen; gebruikers van Server 2003 en XP zijn niet kwetsbaar. Hoewel Microsoft de precieze details van de kwetsbaarheid begrijpelijkerwijs niet bekend heeft gemaakt, slagen hackers er vaak in om meer te weten te komen over een hack door de bijbehorende Windows-patch te ontleden.

Naast het udp-lek worden drie andere bugs geplet, waaronder beveiligingsproblemen in Windows Mail en Active Directory en een denial of service-kwetsbaarheid in drivers die op kernelniveau draaien. Voor zover bekend is de bug die door de malware Duqu werd misbruikt, nog niet opgelost. De Duqu-malware werd waarschijnlijk gebruikt om op bedrijven te bespioneren, waaronder in ieder geval één Nederlandse.

Reacties (102)

Kwalijk, maar de gemiddelde consument zit achter een NAT, dus merkt niks en de gemiddelde server hoort achter een losse firewall te zitten, die dit verkeer dropt. Logisch dat Microsoft tot de reguliere patch-ronde wacht.

Hier in België surfen er honderden gebruikers zonder NAT (rechtstreeks met een publiek IP-adres). Die gebruikers zijn afhankelijk van de ISP die deze situatie heeft gecreëerd om de exploit op hun netwerk te blokkeren of moeten direct hun systeem patchen. Nu valt er de ISP in kwestie wel meer te verwijten, maar er is (helaas) wel een redelijke userbase voor deze exploit.

[Reactie gewijzigd door Petervanakelyen op 8 november 2011 22:16]

honderden gebruikers

Dat zijn er niet zo veel?

Bedankt voor de tip. Ik kreeg net al een melding van Windows Update. Weten jullie toevallig welk KB-nummer dit is ? De omschrijving die je in Windows Update krijgt zijn nogal standaard; weet dus nu niet zeker of ik de betreffende patch heb geïnstalleerd.

-Edit-
Nevermind, heb na wat snuffelen op de Windows Update website dit KB-nummer gevonden : KB2588516

Kijk dus even goed in de historie van Windows Update of deze patch er bij staat.

[Reactie gewijzigd door Titan_Fox op 8 november 2011 21:53]

UDP pakketten maakt dit extra gevaarlijk. Een virusschrijver kan zó net iets implementeren als Slammer, gewoon door pakketjes te blijven sturen naar willekeurige IP-adressen.

Een gesloten poort die op een kiertje staat of hoe moet ik dit nu zien, nu hopen dat de bug echt niet 'in het wild wordt misbruikt'.

UDP is een stateless protocol, als poorten niet expliciet gefirewalled worden moet Windows nagaan wat het nu precies met het pakket moet, of het geen reply is op iets wat vanuit windows is geinitieerd. Dit houdt dus in dat het pakket op een gegeven moment ergens in het geheugen terrecht komt, en kennelijk zit in die implementatie een fout die zorgt dat er code binnen dat pakket uitgevoerd kan worden.

een poort is geen echte deur maar een poort is een nummer waardoor een computer weet met welk programma een pakketje afgehandeld moet worden

bijvoorbeeld bij poort 21 weet een computer dat het pakketje (frame) door een ftp programma verwerkt moet worden

Dat klopt ook niet. Het begint namelijk met de switch. Laten we even uitgaan van een domme (unmanaged) switch. Deze kent de protocollen TCP, UDP, ICMP, etc helemaal niet. Computers communiceren met elkaar op een netwerk op basis van het MAC adres (hoe anders kan jouw computer een TCP/IP adres opvragen bij een DHCP server) en in het geval van TCP en UDP worden daarvoor de zogenaamde ARP tables gebruikt. ARP tables zorgen voor de betaling van MAC adres naar IP en vice versa.

Daarnaast worden poorten volgens de BSD stack technisch gezien helemaal niet gesloten of geopend. De computer krijgt de packet namelijk altijd, ook als de port gesloten is. Als programma's zich willen 'binden' aan een port maakt het OS een soort van packet forward aan.

Het lijkt er hier op dat sinds Vista er een wijziging is geweest welke packets naar gesloten porten niet (op tijd) weggooit waardoor deze kwetsbaar is. Maar de reden dat deze bug nog niet wordt misbruikt komt omdat deze bug vanaf het internet vrijwel niet is te misbruiken. Je moet immers packets naar het MAC adres sturen, en dat gaat vanaf internet erg lastig om iedereen tegenwoordig een los modem/router tussen de computer en internet hebben staan..

Echter zou een bot op je prive netwerk wel misbruik kunnen maken van deze bug. En daarom zal de bug alsnog als kritiek zijn bestempeld..

[Reactie gewijzigd door Niemand_Anders op 9 november 2011 09:00]

Waarom zou je ze naar een MAC adres moeten sturen? Het gaat hier om UDP, dat met IP adressen werkt. Dat de switch hier vervolgens geen benul van heeft maakt niet zo veel uit.

Kijk, als je achter een router met NAT zit en geen port forwarding hebt ingesteld zal dat inderdaad niet gaan. Als je PC echter rechtstreeks aan het internet hangt is je publieke IP adres gelijk aan het IP adres van de PC. Via routers op internet is bekend dat een machine voor de IP-range waarin jouw IP-adres valt benaderd kan worden via jou provider, en de provider weet vervolgens weer jouw IP adres te koppelen aan het mac-adres van je modem of PC. Waardoor het kwalijke UDP-pakketje alsnog bij jou aankomt en je dus wel degelijk vatbaar bent voor deze exploit.

edit:
Je hebt ondertussen je reactie gewijzigd zie ik...

[Reactie gewijzigd door MadEgg op 9 november 2011 09:28]

en wanneer is een pakketje "niet op tijd" gedropt? het word toch zeker wel eerste gecontroleerd (minstens om te kijken waar naar het gestuurd moet worden bij ontvangst)? al zou het achterliggende netwerk totaal corrupt zijn. dan is het toch nog de lokale taak om te bepalen of een pakketje gedropt moet worden wanneer de port word gecheckt op of die open staat? je kan toch niet zeggen dat een pakketje verwerkt kan worden voor je weet naar waar het naar gestuurd moet worden (naar welke verwerker)? ik bedoel, ze zegt toch niet van "ga maar door" en 5 minuten later "je bent hier niet welkom omdat je sport schoenen aan heb"? of zie ik dat verkeerd.
het ging hier om "gesloten" poorten. wanneer de destination poort gecontroleerd word dan ziet windows toch al van "dit moeten we niet hebben want deze poort is gesloten" en niet van "ga maar verder, we controleren later wel of je er niet in mag". ook al zou het pakketje totaal corrupt zijn, dan zegt byte 3 en 4 al dat die poort gesloten is.

Onzin.

Als een programma wilt luisteren naar verkeer opent die een deur (poort). Welke dat is kiest hij zelf, het is gewoon zo dat FTP standaard op poort 21 staat. Je kan even goed je httpd laten draaien op 21 als je dat echt wil.

je kan natuurlijk schijt hebben aan protocollen maar de meeste poorten staan vast alleen de reeks 49152 tot en met 65535 zijn dynamisch en dus vrij

http://en.wikipedia.org/w..._TCP_and_UDP_port_numbers

ja, dat klopt. Maar die deur is een software deur die afhankelijk van het resultaat van de scan van wat er door moet (openen packet en destination port opzoeken, vergelijken met lijstje open ports) open of dicht is. Het probleem is dat het packet dan wel degelijk al "binnen" is (inherent aan firewall op de host zelf). Daarom kan een packet gericht op en gesloten pport toch schade aanrichten!

Overigens zou een hostbased firewall enkel mogen dienen om verkeer uit het eigen LAN te blokken; alles wat van buiten komt hoort een dedicated firewall te gaan. Microsoft heeft het over een "continuous stream of crafted packets"; dan gaat het om een gerichte aanval op een target die wellicht even kan duren. Met een beteje geluk beteken t dat "in het wild" deze aanval niet zo interessant is, maar des te meer als hacker met LAN toegang!!!

Als je op Facebook / MSN op 'offline' staat en mensen beginnen toch tegen je te praten en kunnen zo je computer overnemen.

Als je op Facebook / MSN op 'offline' staat en mensen beginnen toch tegen je te praten en kunnen zo je computer overnemen.

¿ ik dacht te lezen dat het over Windows 7, Vista, Server 2008 en Server 2008 R2 met betrekking tot TCP/IP (UDP). en niet zo zeer facebook of MSN.
aan UDP moet je denken aan berichten naar een ip sturen zonder connectie te maken *omdat dat sneller is dan steeds wachten tot de server zegt "ja ik heb je pakketje"*. dus er staat een soort van backdoor (bug of andere reden) open die wel luistert en berichten aan neemt zonder connectie. dit is normaal geen probleem omdat je UDP voor spellen.
maar *en dit weet ik niet 100% zeker. kan iemand er wat bijvoegen?* een UDP port is normaal zichtbaar als (listening) *cmd netstat*. en de bug waar het over gaat toont aan dat er een UDP port (of misschien wel alle poorten) open staat, niet zichtbaar is, maar wel packages accepteert (de bug zou zijn een gemanipuleerde package die je in staat stelt code uit te laten voeren *waarschijnlijk stack overflow*. dit kan/lijkt een driver bug te zijn.

de vergelijking van dat "offline" weergeven niet offline is of door applicaties niet doorgegeven word als offline status vind ik half op gaan *ja het is onzichtbaar en toch verwerkt het pakketjes*. de applicaties/sites hebben er niets mee te maken.

edit : *typo* zal wel meer in zitten maar de essentie lijkt me duidelijk

[Reactie gewijzigd door Madnar op 9 november 2011 21:57]

Ik begrijp het eerder zo: om te weten op welke poort een pakketje binnenkomt, moet het pakketje gelezen worden (de destination port staat immers in het datapakket (http://en.wikipedia.org/wiki/User_Datagram_Protocol).
Bij dat uitlezen kunnen er met geprepareerde pakketjes gericht aan udp poorten fouten ontstaan in de stack (buffer overflow?) die exploiteerbaar zijn.

Ik denk niet dat een gesloten poort zich door deze bug als een open poort gedraagt.

dan maakt :
Windows 7, Vista en beide Server 2008-versies bevatten een ernstige bug die het mogelijk maakt om code te injecteren via een gesloten udp-poort.
een beetje vaag. hoe kun je nog meer fouten maken dan simpelweg weigeren van alle (ook corrupte) pakketjes op een poort als die gesloten is? ergens ontstaat er ineens een fout waardoor pakketjes toch toegelaten worden.

en helemaal gelijk. waarschijnlijk *buffer overflow* en niet wat ik schreef *stack overflow*

edit :
wat aanvullende informatie.
uint16 source port
uint16 dest port
uint16 length
uint16 crc16
{data}

waar gaat het mis? byte 2 tot 3 (0 based) geeft de port toch al aan? dan kan er toch gewoon gedropt worden? dan maakt het niets meer uit of je totaal random values gebruikt voor de eerste 8 bytes (de hele header). hoe kan je dan een pakketje zodanig corrupt maken als het al gedropt word wanneer de dest port gesloten is?. dat vind ik heel mysterieus.
daarnaast ga ik mezelf tegenspreken : windows moet ook controleren welke porten er open zijn voor het kan zeggen dat het gedropt word. ik vermoed dat het hier ergens mis gaat.
mijn gedachte : pakketjes worden toch als pakketjes behandeld? dan kan er toch geen probleem ontstaan dat een mix van pakketjes elkaar kunnen beinvloeden? en zo wel dan denk ik aan dat de length value die te groot zou zijn een ander pakketje kan beinvloeden omdat windows nog op de rest van het te lange pakketje wacht?. maar dit lijkt onwaarschijnlijk omdat het al geblokkeerd moest worden toen de dest port werd gecheckt.
en alle nodes die ertussen zitten controleren toch ook of die crc en length nog klopt? ik snap niet zo heel goed hoe je dan nog een corrupt pakketje kan maken die magische dingen doet. *natuurlijk weet ik niet genoeg over het onderwerp tcp/ip met name udp of hoe windows pakketjes afhandeld. en dit is dus ook alleen mijn mening en redenering*. ook zie ik geen rede als er massaal udp pakketjes word ontvangen dat ineens voor max van uint16 of 32 anders behandeld worden dan de rest. gesloten is gesloten toch? dan ga je niet iemand controleren of die een mes bij heeft of dat die een strafblad heeft (of het pakketje corrupt is), het gewoon niet binnen laten na de eerste 4 bytes gelezen te hebben lijkt mij logisch.
zodra andere programma's zich gaan bemoeien met de afhandeling van pakketjes (drivers misschien) word alles heel fuzzy, dan is het niet zo zeer een windows fiasco, 7,server,whatever probleem.

als jij als portier de opdracht kreeg om niemand binnen te laten. dan laat je toch ook niet iemand binnen die eventjes naar de wc moest? of is het wel zo dat je je baas wel door laat omdat die hoger op je lijst staat < dan is het geen bug meer maar eerder een backdoor. zo kan die iemand die naar de wc moest zich ook voordoen als je baas.

ik vraag me dan af tot hoe verre het een "bug" was.

[Reactie gewijzigd door Madnar op 9 november 2011 22:31]

Wat een onzin. Het 'leuke' aan deze exploit is dat er geen poort (of Facebook of MSN) hoeft open te staan om remote code uit te voeren

Hooguit de hardware firewall die tegenwoordig in routers en/of modems aanwezig zijn - mits de gebruiker natuurlijk DMZ gebruikt. Anders schiet het nog weinig op om die exploit te misbruiken... of zie ik hier nu iets over het hoofd ?!

Het zal eerder NAT zijn waar je mee beschermd wordt, om dat je PC niet extern bereikbaar is. Dan kan je wel of geen firewall hebben, maar niet bereikbaar betekent dat er ook geen packets binnen komen op je LAN, maakt niet uit of het dan UDP/IP of TCP/IP is. Of GRE for that matter.

[Reactie gewijzigd door johnkeates op 9 november 2011 01:37]

Je praat allebei over hetzelfde. NAT schermt je af, DMZ laat alles naar je computer door.
Maw de doorsnee internetter gaat hier waarschijnlijk geen last van hebben. Lokale Windows (bedrijfs)netwerken zijn wel in gevaar.

[Reactie gewijzigd door Sir_Eleet op 9 november 2011 01:47]

DMZ laat alles naar je computer door.

Huh? Een DMZ is een geconfigureerd netwerksegment. En je kunt zelf configureren of en welk verkeer rechtstreeks met computers "binnen" mogen communiceren. NAT daarentegen wordt gebruikt om source- of destination adressen van IP-packets te veranderen.

doorsnee internetter gaat hier waarschijnlijk geen last van hebben

Juist deze hebben er wel mee te maken: vaak is het de enige computer aan een internetmodem/-router en wordt alle verkeer (ook het ongewenste) door de PC verwerkt in plaats van gefilterd door de router.

De DMZ instelling in mijn router laat me per extern IP adres één host aanwijzen waarnaar alle verkeer, zonder firewalls en portforwarding naartoe doorgestuurd wordt. Dat is volgens mij ook het idee; als je slechts enkele poorten open wil stellen naar een host dan kun je beter portforwarding gebruiken.

De DMZ host gebruik ik om het verkeer dat op een router binnenkomt via de internetverbinding rechtstreeks door te schakelen naar een router die daar achter ligt. De eerste router is namelijk een dichtgetimmerd geval van Versatel (inmiddels Tele2) waarbij de nodige instellingen niet aan te passen zijn (zoals custom DNS-server). Voor dit soort dingen is DMZ bij mijn weten bedoeld. Biedt je in ieder geval geen enkele beveiliging.

Wat ik zeg is de simpele waarheid omdat de meeste internetters (in België althans) achter een router met NAT zitten. Ik begrijp je "huh" niet voor DMZ: bij thuis routers kan je 1 host instellen als DMZ host, waarnaar alle verkeer doorgelaten wordt.

Dat noemen routerbakkers zo, maar het is geen DMZ zoals je die in echt netwerkterminologie gebruikt.

Routerbakkers bieden een 'Exposed Host' configuratie aan, maar dat klinkt eng, dus noemen ze het DMZ zodat het minder risicovol klinkt.

Mwa, zou dat zo werken? Ik ken weinig mensen om mij heen weten van het bestaan van de DMZ-host of hem gebruiken. Ik gebruik hem dus wel maar wel volledig bewust van wat voor consequenties het met zich meebrengt. Hoe je het beestje dan noemt maakt geen zak meer uit. "Public Host" of "Catch-all Host" zou je ook nog kunnen overwegen; dan ben je in ieder geval de overeenkomst met DMZ kwijt.

DMZ; demilitarized zone

Niets meer en niets minder dan een zone in een netwerk waar internet-facing devices in gehost worden.

In thuis routers etc. wordt de term DMZ incorrect gebruikt. Het betreft hier een static NAT entry van het outside IP naar een host in de inside.

er zijn genoeg msn clients die mensen die offline staan toch als aangemeld laten zien. heeft er dus niets mee te maken...

Misschien is dat een bug in msn. Als iemand echt offline is kan je deze pc moeilijk overnemen ( Mag ik aannemen).

Als iemand's PHY uit staat kan het niet nee. Als er geen stack is om packets te verwerken ook niet. Als het geen windows is ook niet.

bron?

Zeker kunnen ze het niet weten, maar ze gebruiken bij voorbeeld zogenaamde honeypots. Dat zijn computers die ze laten draaien en waar bijvoorbeeld een worm, virus etc op komt. Regelmatig worden ze bekeken of er iets aangepast is. Als dat het geval is dan gaan ze onderzoeken wat er precies aan de hand is en wat de exploid was die is gebruikt.

Hoe kun je nou code injecteren door data naar een poort te sturen? Volgens mij moet er hoe dan ook een service op die poort luisteren. De poort zelf kan geen instructies aan het systeem geven dus dat moet door iets anders gedaan worden wat achter die poort zit.

Maar een bug vond ik eigenlijk nogal sterk. Een bug die zich 'toevallig' als service op het netwerk manifesteert zeker?

In de TCP/IP stack zit nu éénmaal code die elk TCP/IP packet dat toekomt, analyseert en vervolgens doorstuurt naar je juiste service. Als in die code zich een buffer-overflow bug (of iets gelijkaardig) bevindt, kan dit een exploit worden ongeacht of er een service gekoppeld is aan die poort of niet...

Ik probeer het te snappen...
Dus je stuurt je evil reeks bytes naar een bepaalde poort waardoor in de TCP/IP stack een buffer-overflow optreedt en hij buiten zijn toegewezen geheugengebied gaat zitten schrijven. Die reeks sturen lukt wel met bijv. netcat, maar het zou wel een belachelijke bug zijn als je het mij vraagt.
Maar wat ik sterk vond is dat een systeem al gehackt is voordat er in beide richtingen enige vorm van communicatie is geweest. Het doelwit heeft nog nergens antwoord op gegeven. De netwerkaansturing is al de fout in gegaan bij alleen een binnenkomend signaal.

[Reactie gewijzigd door blorf op 8 november 2011 23:31]

Bij de meeste network exploits is één pakket voldoende om een attack uit te voeren (zeker in het geval van buffer overflows). Kijk maar naar de "ping of death" uit het Windows 95 tijdperk.

Vandaar dat je best altijd surft van achter een NAT firewall, en expliciet poorten openzet voor de services die daadwerkelijk geconfigureerd zijn.

De laatste tijd begin ik me toch ernstig zorgen te maken.. wanneer je op de frontpage kijkt zie je een hele serie nieuws over hacks, exploits, bugs, patches ect. ect.

Het lijkt wel alsof softwaremakers steeds verder achterop raken, of komt dit gewoon meer in het nieuws? Ik check tegenwoordig bijna dagelijks de updates om mijn server 'dicht' te houden. Verder natuurlijk een firewal, en logs bijhouden... maar echt veilig voel ik me niet!!

Vergeet niet dat Windows een complex OS is. Het blijft een monolithisch OS wat zwaar leunt op de RPC-procedure. Deze potentiële kwetsbaarheid kan door een hacker misbruikt worden om je hele systeem te laten crashen.

Doordat er zoveel programma's zijn die verbinding maken met internet, moet het OS zelf ook aan alle kanten worden gepatched om eventuele kwetsbaarheden te corrigeren.

Bij Linux krijg je iedere week ook vele tientallen updates.

Ik raad overigens eenieder van jullie aan om het programma PSI van Secunia (gratis) te downloaden. Dit controleert je hele systeem op de gebruikte software en kijkt in een actuele database of je software nog up-to-date is. Via PSI kun je dit met enkele klikken volledig updaten.

De reden dat er hackers op je systeem komen is niet zo zeer dat Windows niet geupdate is, maar omdat er 3rd-party software gebruikt wordt waarbij security-patches ontbreken.

Linkje : http://secunia.com/vulner...ng/personal/download_psi/

Het houdt ook een score bij en zal je notificeren zodra bepaalde software verouderd is.

Vergeet niet dat Windows een complex OS is. Het blijft een monolithisch OS wat zwaar leunt op de RPC-procedure. Deze potentiële kwetsbaarheid kan door een hacker misbruikt worden om je hele systeem te laten crashen.

Dit gaat over een kwetsbaarheid in de networkstack. Het is niet alsof een wel of niet monolitisch OS of RPC procedures de networkstack bugvrij maken. Theoretisch kan er in elke networkstack van elk OS hetzelfde gebeuren.

Dat snap ik, maar via de netwerkverbinding zou je als kwaadwillende foutieve code kunnen draaien op een ander systeem en bijvoorbeeld de RPC aanvallen. Wat het crashen van Windows tot gevolg heeft.

Dus, stel Linux heeft een dergelijke fout. Dan valt Linux niet onderuit te halen omdat het geen RPC heeft? Beetje vreemd. Punt is dat nu de kernel onder bepaalde omstandigheden onder vuur ligt. Bij ieder systeem betekent dit een groot probleem.

In ieder geval ernstig. Hopelijk is men wel snel met het patchen geweest voordat er problemen komen. Verder weten we ook niet in hoeverre het ernstig. Of beter, we weten niet hoe gemakkelijk het lek is uit te buiten. Toch maar snel updaten.

@Titan_Fox, zeker mee eens! Maar, mijn punt is dat hoe modulair alles is, in dit geval niet uitmaakt. Via deze bug kan kernelmemory aangetast worden. Zowel je Linux als Windows kernel, ondanks een andere opbouw, doen low-level hardware, memory en overige IO zaken.... geen goede combi met een bug dus.

[Reactie gewijzigd door WinL op 9 november 2011 15:31]

In tegenstelling tot Windows ben je onder Linux niet standaard administrator (root). Malware die zich wil installeren heeft simpelweg geen rechten om dit te doen. Ondanks dat Linux wel een monolithische kernel heeft, is het systeem zelf modulair.

Daarbij komt dat door het kleine aantal Linux-gebruikers en de nogal levendige support het (nog-) niet heel erg interessant is om malware voor dit OS te schrijven. De mensen die Linux gebruiken hebben in de regel wel verstand van zaken en weten hoe ze hun systeem moeten patchen.

Uiteraard is ieder OS wel te infecteren op de een of andere manier; het is de truc om hackers te demotiveren in je systeem in te breken. Vergelijk het met een dikke houten deur om inbrekers buiten de deur te houden. Je kunt wel met een kettingzaag en een bijl te werk gaan, maar als bij de buren de deur op een kier staat is dit toch een makkelijker doel.

Nu zijn hackers wel wat fanatieker dan de gemiddelde inbreker maar je moet je uiteraard ook afvragen of je systeem wel de moeite is om op in te breken. Ik heb zelf geen persoonlijke data op mijn interne harde schijf staan. Alleen Windows staat erop, wat simpele spelletjes en mijn torrent-downloads. Denk niet dat dit voor hackers erg spannend is. Internetbankieren doe ik met mijn smartphone.

Ik ben al overgeschakeld op Linux, ik draai voor op mijn thuisserver (productie) Ubuntu en check inderdaad bijna dagelijks op updates, en dat zijn er inderdaad ook veel (alhoewel ik niet bij tientallen kom).

Maar net als Windows zitten er in Linux ook kwetsbaarheden.. ik kijk altijd met argusogen naar de repositories, als daar kwalijke code op komt te staan hengel ik die via apt-get zo naar binnen.

De reden waarom ik me niet meer 'veilig' voel - hoe is bovenstaand bekend geworden? Het lijkt me zeer aannemelijk dat mensen die bugs en exploits vinden deze niet aan de grote klok hangen, maar deze exploiteren.

Ik zou ook graag overstappen. Is voor mij momenteel nog geen optie omdat er geen fatsoenlijke RadeonHD-drivers zijn.

Zolang deze drivers niet dezelfde performance bieden dan de Windows-versie, blijf ik bij Windows 7. Het hardwarematig afspelen van HD-content zou out-of-the-box moeten werken, wat bij Linux dus niet het geval is.

1080p afspelen? Geen probleem hoor met zowel Ati als Nvidia als Intel video. 3d gaming, is vaak een groter probleem.

nee hoor -- de meeste hax enzo waarover je hoort gaat over oude systemen of over websites met amateur beveiliging zoals sql injectie kwetsbaarheden.. over het algemeen staat het met de beveiligingen veel beter nu dan een aantal jaar geleden [citation needed]

Dat controleert Secunia ook voor een groot deel. Verouderde plugins (Flash, DivX, Acrobat, Shockwave (Director), Java enz.). Ook zal het ontbrekende Windows / Office-updates vinden.

De automatische update werkt niet voor alle software; als je Microsoft-software wilt updaten zal Secunia je in de regel naar de betreffende downloadpagina brengen van Microsoft waar je handmatig de MSI- of EXE-bestanden kunt downloaden.

Ik gebruik PSI nu al vele jaren en moet zeggen dat ik er erg tevreden over ben. Op die manier hoef je niet handmatig al je software in de gaten te houden, want er verzamelt zich nogal wat door de tijd heen.

Software met de status "Insecure" kunnen gepatched worden. Software met "End-Of-Life" status kan niet meer gepatched worden en dient vervangen te worden. Dit is bijvoorbeeld bij major-updates van software. Je kunt Adobe Reader 9.0 wel patchen naar 9.3 bijvoorbeeld, maar niet naar Adobe Reader X. Dit moet je handmatig doen. Patches blijven in de regel binnen het huidige versienummer. Gelukkig hebben veel softwarepakketten al een eigen Auto-Updatefunctie ingebouwd.

Software met "End-Of-Life" status kan niet meer gepatched worden en dient vervangen te worden.

Nee, software met een end-of-life status hoef je niet te vervangen.
Software met een gevonden lek wel.
En dat is zeker niet hetzelfde.

Adobe Reader 9 heeft de "end-of-life" status. Hier komen dus geen security-patches meer voor uit en dient daarom bij voorkeur vervangen te worden door Adobe Reader X. Het is naïef om te denken dat een "end-of-life" product klaar is met patchen en daarom veilig is in het gebruik. Het is niet meer dan niet-ondersteunde software.

De software voor mijn Sony MP3 speler (SonicStage) is ook "end-of-life". Echter is hier geen zinnig alternatief voor (voor Linux was er een Java-based applicatie) die ik voor Windows nog niet heb gevonden.

Deze software is dus niet meer te patchen / vervangen. Je kunt dergelijke software die verder geen noemenswaardig veiligheidsrisico met zich meebrengen in de PSI-Ignorelist toevoegen

Meer in het nieuws (omdat er zoveel newssites zijn, dus elke scheet wordt uitgebreid vermeldt). Maar ook wordt software complexer en daardoor dus de kans op 'lekken' groter.

Ik heb de updatecenter even opnieuw laten zoeken, en hij stond erbij. Inmiddels ben ik de digitale pleister aan het opplakken. Ik vraag me af of de firewalls van de meeste routers die UDP connecties al blokkeren?

Dat is een kwestie van instellen. Het is echter altijd beter om zowel het hardware- alsmede het softwaredeel gepatched / geconfigureerd te hebben.

Kijk direct even of je router de laatste firmwareupdate heeft.

Nu ja, elke router dropt die pakketjes by default. De poort is immers gesloten; er zijn geen uitgaande pakketjes vanaf die poort, dus inkomende pakketjes geadresseerd aan de desbetreffende poort worden automagisch gedropt, omdat de poort niet in de routing table staat.

Een router dropt helemaal geen pakketjes. Een router kijkt naar IP adressen (niet naar poorten) en stuurt het pakketje de goede kant op.
En in de routing table staan geen poortnummers, alleen IP en netwerk adressen.

Achter een NAT-router heb je sowieso nergens last van...

Maar er zijn ook pc's die rechtstreeks met het internet verbonden zijn. En er bestaan natuurlijk ook grote LAN's van duizenden pc's waar ook wel kwaadwillenden tussen kunnen zitten - denk aan grote organisaties, universiteiten of LAN-parties.

Tenzij je wel eens e-mule hebt gebruikt en een gaatje in je NAT router had gemaakt om een lage ID te krijgen. E-mule gebruik je niet meer, maar heb je ook je router weer teruggezet??

Dan is de poort juist open, en dan is dit probleem niet aan de orde. Dit probleem doet zich voor op poorten die juist dicht staan...

De poort is open in de firewall van de router, maar voor Windows is deze gesloten wanneer eMule niet aanstaat. Dus ik denk toch dat deze bug best wel ernstig is.

komt die patch via de updates binnen?
edit/ ik zie net KB2603229 zou dat hem zijn?

[Reactie gewijzigd door erikdeperik op 8 november 2011 21:51]

Ja, zoals ik al aangaf is het update KB2588516 (bij Windows 7 32/64-Bits).

Thanks, heb hem inmiddels door het handmatig aanduwen van Windows Update ook binnen op al mijn systemen.

Oz

Sorry, dubbelpost.

Nvm, is nu al boven aan genoemd.

Des ondanks fijn dat er snel een patch is. Al vraag ik me wel af of dit niet al misbruikt werd.

[Reactie gewijzigd door Broken op 8 november 2011 21:54]

Ehm nee. Dit is hem: http://technet.microsoft....ecurity/bulletin/ms11-083

Is ook al gelinkt in het artikel zelf.