Google-onderzoeker ontdekt lekken in wachtwoordmanager van Trend Micro

Tavis Ormandy van Googles Project Zero-team ontdekte verschillende lekken in de wachtwoordmanager van Trend Micro, waardoor een aanvaller toegang kon hebben tot de daarin opgeslagen wachtwoorden. Ook was het mogelijk om willekeurige code uit te voeren.

De kwetsbaarheid betreft een remote code execution, die bestond naast het feit dat in totaal zeventig api's die toegang tot de wachtwoorden geven via het internet toegankelijk waren. Hierdoor kon een aanvaller willekeurige code uitvoeren op een kwetsbaar apparaat en had hij toegang tot alle wachtwoorden, zonder dat de gebruiker daar iets van zou merken.

Ormandy claimt de bug 'in minder dan dertig seconden' te hebben vastgesteld. Verder zegt hij dat 'hij niet weet wat hij moet zeggen' over het incident, aangezien de wachtwoordmanager standaard wordt geïnstalleerd met het antivirusprogramma van Trend Micro. Het bedrijf heeft inmiddels een patch uitgebracht die de problemen oplost via de automatische updatefunctie, zo meldt The Register.

Het is niet de eerste keer dat Ormandy kritieke lekken ontdekt in software van andere bedrijven, waaronder AVG en ESET. Vaak gaat dit, zoals ook in het huidige geval, gepaard met kleurrijke uitspraken over de ernst van de kwetsbaarheden.

Reacties (54)

Zonet de berichten gelezen waarnaar gelinkt worden in het artikel en het is wel schandalig dat er zo slecht wordt omgesprongen met de veiligheid. Trend Micro heeft wel relatief snel gereageerd, wat nog wel positief te noemen valt, maar dit is wel een zware nalatigheid.

Trouwens, de quote van dat hij de bug belachelijk vindt slaat vooral op het toevoegen van een oude build van Google Chrome met de sandbox gedisabled als een "safe browser" alternatief:

I happened to notice that the /api/showSB endpoint will spawn an ancient build of Chromium (version 41) with --disable-sandbox. To add insult to injury, they append "(Secure Browser)" to the UserAgent.

I sent a mail saying "That is the most ridiculous thing I've ever seen".

Toevoeging:
Trouwens, het probleem is nu nog niet opgelost. Enkel het uitvoeren vanop het internet is nu via 2 API's onmogelijk gemaakt. Het programma kijkt nu de Referer en Origin headers na, maar deze zijn zeer makkelijk te spoofen als je programma's kan draaien op de lokale computer. Het uitlezen van wachtwoordendatabank is lokaal nog altijd extreem gemakkelijk momenteel. Een goede wachtwoordendatabank zoals KeePass beschermt zich daar veel beter tegen

[Reactie gewijzigd door Glodenox op 12 januari 2016 12:33]

Ik wil het niet goedpraten, maar bij Trend Micro komen dit soort dingen voor omdat ze links en rechts bedrijfjes en technologie inkopen en zonder er goed naar te kijken aan bestaande producten "plakken".

Dit soort producten zit echter alleen in hun soho productlijn.
Die soho productlijn is feitelijk een permanente beta test voor nieuwe snuisterijen die ze opgekocht hebben.

Password manager is overigens een op zichzelf staand product.
Het wordt weliswaar bijgeleverd met Trend Micro anti-virus 2016 maar dat wil nog niet zeggen dat je verplicht bent het te gebruiken.

[Reactie gewijzigd door Alfa1970 op 12 januari 2016 12:07]

Zo gaat het wel vaker bij softwarebedrijven, inderdaad. Ik kan niet meteen vinden of het hier een overname van een ander bedrijf betreft. Het zou in dat geval wel betekenen dat ze bij Trend Micro veel te veel betaald hebben voor dat bedrijf

Het is een op zichzelf staand product inderdaad (met trouwens een prijskaartje van 15 dollar per jaar), maar omdat het samen bij hun antivirus-product zit is de kans bestaande dat mensen er gebruik van gaan maken.

edit: beter verwoord

[Reactie gewijzigd door Glodenox op 12 januari 2016 16:30]

Klopt inderdaad, er stond twee keer 'ridiculous' kort onder elkaar, waardoor ik de verkeerde context las. Het is aangepast.

Helemaal eens.

Voor mij zou dit een reden zijn om het product gewoon te deinstalleren en permanent te verwijderen. Als er op zo'n manier wordt omgesprongen met de security in de applicaties, wat zegt dat dan over de security op hun eigen servers (lees: waar al die wachtwoorden staan)? In de meeste bedrijven is dit nog slechter in orde dan het spul dat ze uitrollen...

Wachtwoord manager in Trend Micro, dat is de consumentenversie mag ik hopen?

Het gaat over dit product. Een wachtwoordenbeheerder voor gebruikers waarbij de wachtwoorden online bij Trend Micro opgeslagen worden.

Precies de reden dat online wachtwoordmanagers verre van ideaal zijn.
Dat het programma een encrypted container ergens in de cloud zet, kan ik nog begrijpen. Hoewel brute forcen een stuk makkelijker is als diezelfde container gestolen wordt. Maar het verhaal is compleet anders als je wachtwoordmanager slechts toegang verschaft tot een online database met (hopelijk) encrypted en salted wachtwoorden. Daarnaast is zo'n bedrijf een stuk aantrekkelijker voor aanvallers dan pogen om individuele cloudaccounts binnen te dringen.

Ik neem aan dat er geen hashes gebruikt word maar met reverseble encryptie. Naar mijn idee is je opmerking over salted dan ook onterecht.

Wie bouwt dan ook een desktop password manager op Node.js

Zouden online apps op node.js ook van die onveilige poorten hebben openstaan? Of is dit gewoonweg een heel domme implementatie van node.js van TrendMicro?

Dit is een hele domme implementatie. (Dat wil niet zeggen dat het gebruik van Node.js op de server wel een goed idee is, maar dat terzijde).

Afgezien van de domme implementatie is het natuurlijk te gek voor woorden om een server-side omgeving te gebruiken voor het maken van een desktop app.

Hmm.. ik gebruik sinds kort Atom editor op mijn desktop omgevingen. Voor dat type apps lijkt mij het toch niet zo erg?

Ik vind het vies, maar ik vind JS sowieso een smerig taaltje.

Waarom moet ik dat onderbouwen ? Lijkt me algemeen bekend dat Javascript een rommeltje is. (Niet sterk getypeerd, alle nummers zijn floats, type coercion die er een zooitje van maakt, dingen gedragen zich niet zoals je verwacht (ook een gevolg van het brakke type system), impliciete declaratie van variablen, gebruik van globals, gebrek aan goede scoping en ga zo maar door) Het is letterlijk in 10 dagen in elkaar gehacked door een gast bij Netscape op wat interactie aan webpagina's toe te voegen. Het is nooit bedoeld geweest om applicaties in te schrijven "The by-design purpose of JavaScript was to make the monkey dance when you moused over it."

Het feit dat er bakken met libraries en tools bestaan zoals b.v. TypeScript om het semi-bruikaar te maken zegt genoeg.

[Reactie gewijzigd door Aaargh! op 12 januari 2016 13:09]

Waarom zou je iets onderbouwen? Moet je dat echt vragen? Jouw mening is geen feit, dus daarom onderbouw je iets.. al is het maar voor de gene die helemaal geen verstand van JS of welke programmeer taal dan ook hebben. Loze comments zoals jij deed mogen wellicht 'waar' zijn, maar niemand heeft er iets aan totdat je er wat context bij gooit

Verder is het nogal appels en peren vergelijken. Er is domweg geen taal zoals JS die in de buurt komt van de kracht en kunnen voor bijvoorbeeld in de browser. Daarbij is al meerdere keren bewezen dat een NodeJS implementatie sneller is dan bijvoorbeeld dezelfde in JAVA... In hoeverre moet je dan JS helemaal gaan afkraken?

JS is goed bruikbaar, net als NodeJS. NodeJS is ook prima te gebruiken als standalone cilent. Zou het mijn eigen keus ooit worden? : nee. Moet je derhalve alles afkraken? : ook niet.

Daarbij is al meerdere keren bewezen dat een NodeJS implementatie sneller is dan bijvoorbeeld dezelfde in JAVA... In hoeverre moet je dan JS helemaal gaan afkraken?

Voor wat voor applicaties ? Bovendien, is snelheid het enige wat telt ? Leesbaarheid v/d code is veel belangrijker (en JS is niet bepaald leesbaar met al die callback-ellende). Security is belangrijk, correctheid is belangrijk.

Er is domweg geen taal zoals JS die in de buurt komt van de kracht en kunnen voor bijvoorbeeld in de browser.

Nee, nogal logisch dat JS de beste taal is die in browsers ondersteund wordt want JS is de enige taal die in alle browsers ondersteund wordt.

Daar is het dan ook voor ontwikkelend en voor bedoelt, om een menuutje uit te klappen als je ergens met je muis over gaat of andere simpele interactieve elementen, het is nooit bedoelt geweest om complete applicaties in te bouwen. Daarvoor mist het simpelweg te veel essentiële features.

Lijkt me algemeen bekend dat Javascript een rommeltje is. (Niet sterk getypeerd, alle nummers zijn floats, type coercion die er een zooitje van maakt, dingen gedragen zich niet zoals je verwacht (ook een gevolg van het brakke type system), impliciete declaratie van variablen, gebruik van globals, gebrek aan goede scoping en ga zo maar door)

JS is dynamically typed ipv statically typed. Het is wel degelijk strongly typed. Anders zou er niet eens sprake zijn van type coercion. Type coercion is nl. niets anders dan het impliciet omzetten van het ene type in het andere type voor bepaalde compatible types of operaties. En dat is iets wat ook talen als C# implementeren. (Ja, C# heeft een implicit type coercion operator. Zoek maar op.)

De type coercion regels zijn daarnaast goed gedefineerd en logisch gekozen, in tegenstelling tot bijv. het broddelwerk wat PHP er van gemaakt heeft.

Impliciet variable declaratie bestaat sinds EcmaScript 5 strict mode niet meer.
Globals worden in de praktijk niet meer gebruikt en in NodeJS moet je zelfs vreselijk je best doen om ze nog aan te kunnen maken, aangezien alles daar als geisoleerde CommonJS modules draait.

En met dat laatste tikken dus ook gelijk het puntje scoping af wat in jouw lijstje stond.


Anders nog iets, of wil je weer terug naar je droomwereld waar het nog 1999 is?

Waarom zou je in een wachtwoordmanager 70 api's inbouwen om toegang ot de wachtwoorden te geven?
Is 1 api niet voldoende?
Als iemand het kan uitleggen hoor ik het graag.

Waarom zou je in een wachtwoordmanager 70 api's inbouwen om toegang ot de wachtwoorden te geven?
Is 1 api niet voldoende?
Als iemand het kan uitleggen hoor ik het graag.

Betreft hier waarschijnljik API endpoints, d.w.z. 70 individuele remote service calls / methods.

Zie hier reden numero uno om geen wachtwoordmanager te gebruiken.

Het alternatief: hetzelfde wachtwoord voor veel verschillende diensten of je gebruikt een eenvoudig algoritme wat makkelijk te kraken valt.
Als je geen fotografisch geheugen hebt is een wachtwoordmanager een redelijk veilig alternatief. Kijk anders eens naar KeePass. Lokale opslag met goede encryptie. Het is gratis en installeert geen adware. Bovendien kun je ook een portable versie downloaden die helemaal niets installeert. Dit is wat mij betreft de meest veilige wachtwoordmanager die er in omloop is.

Ik gebruik passwordcard. Je gebruikt een code, noem het een moederwachtwoord, waarmee je een kaartje kan maken. Hierdoor krijgen je een 30-tal 8-tekens wachtwoorden, of 8 30-tekens wachtwoorden. Hoofdletters, kleine letters, cijfers en je kan eventueel aanduiden om 4 cijfers na elkander te hebben voor alle slimme pasjes (id, visa, bankpas, ...) Niets belet je natuurlijk om de wachtwoorden ook van achter naar voor te gebruiken, of halfweg te verspringen naar een volgende regel.
Je kan dit kaartje afprinten, of je kan een app installeren op je smartphone dat je kaartje weergeeft. Moet je enkel je moederwachtwoord kunnen onthouden, mocht je je kaartje kwijt geraken.

Dat is inderdaad een mooie methode. Vooral als je veel onderweg bent kan dit een uitkomst zijn omdat je dan geen wachtwoorden database bij je hoeft te hebben op bijvoorbeeld een USB stick.
Maar als je dagelijks achter dezelfde pc zit dan kan dat kaartje behoorlijk gaan vervelen lijkt me. Iedere keer je wachtwoord opzoeken kost zoveel meer tijd dan het wachtwoord simpelweg laten invullen door KeePass.

Maar voor mensen met weinig wachtwoorden of mensen die slechts af en toe achter de computer zitten kan dat kaartje wel handig zijn. Ik denk ook dat mijn ouders dit bijvoorbeeld zouden kunnen gebruiken.

Degenen die ik het meest gebruik, ken ik ondertussen uit mijn hoofd

Het alternatief: hetzelfde wachtwoord voor veel verschillende diensten of je gebruikt een eenvoudig algoritme wat makkelijk te kraken valt.

Of gewoon een codeboekje wat in de fysieke kluis ligt. Flink kleiner risico dat daar problemen mee ontstaan dan met software die op een internet-connected device staat.

Klinkt nogal onhandig. Iedere keer als je een wachtwoord moet invullen moet je de kluis openen. Waarschijnlijk ben je dat na 3 keer zo zat dat je codeboekje onder je monitor blijft liggen (wat dus weer heel onveilig is).

Password managers... alsof we onze sleutels aan iemand geven en vragen "pas er even goed op"..

Pak een standaard wachtwoord van jezelf, en voor tweakers, verwerk twe in je wachtwoord op een vaste positie. Doet dit ook bij bol (waar bol in je wachtwoord staat) en je hebt nooit meer een wachtwoord manager nodig.

Zo heb je over 'hetzelfde' wachtwoord, maar hij is toch anders op elke site. Veel veiliger / makkelijker kan het niet geloof ik.

Als je wachtwoord op 2 verschillende sites zou uitlekken val je door de mand. Dus zo veilig zou ik dat niet noemen.

Wachtwoord uitlekken lijkt me uberhaubt geen goed idee (en bij standaard wachtwoorden is 1 al voldoende om alles door de mand te laten vallen.. dan zijn 2 sites nog heel wat lastiger ). Blijft dat de zwakste schakel de sterkte van je chain bepalen.

En dan nog... wie weet nou of je de eerste 3 letters van een pagina hebt, of wat anders wat prominent aanwezig is.

Het is een guide line, voor jou helemaal aan te passen

(mn orginele reactie was btw niet op jou post bedoelt.. daar ging ff wat mis)

[Reactie gewijzigd door DarkUnreal op 12 januari 2016 17:07]

Het uitlekken doe je meestal dan ook zelf niet Je moet maar eens kijken op HaveIBeenPwned.com om in te zien van hoeveel grote websites het al gekend is dat de wachtwoorden of gebruikersinformatie te grabbel lag. Zo weet ik dat ik een oud wachtwoord van mij niet meer kan vertrouwen door het lek bij Adobe.

Als ik jouw systeem op de ongeveer 250 sites waar ik een wachtwoord heb zou doorgevoerd hebben en er zijn er twee die lek zijn, dan loop ik een groot risico als ik een interessant genoeg doelwit zou zijn omdat mijn systeem makkelijk af te leiden valt. Dat lijkt me veel plausibeler dan dat iemand een wachtwoordendatabank kan bemachtigen en het wachtwoord ervoor gaat vinden. En zelfs indien dat het geval zou zijn: je zou meteen weten welke wachtwoorden die persoon kent. Er is geen kans meer dat je een site overslaat bij het herstellen van je account(s).

De grote voorwaarde voor het wachtwoord van je wachtwoordendatabank is dat je natuurlijk wel dat dit nergens anders werd ingegeven, want dan loop je inderdaad een groot risico.

Ik snap je reactie,

Maar wat ik probeer te zeggen, als iets uit lekt ben je altijd de pineut. Echter door verschillende 'dezelfde' wachtwoorden te hebben, is het minder ernstig.
Als je 1 hetzelfde wachtwoord overal hebt, en die lekt uit, heb je toch een veel groter 'probleem'?

Ik zeg ook niet dat het een fool-proof oplossing is, echter geeft het net dat beetje extra, op een erg simpele manier.

Het is sowieso al beter dan 99% van de gebruikers hoor, ik wil niet zeggen dat het een slechte manier van werken is Er zijn echter nadelen verbonden aan die methoden die ik persoonlijk te groot vind.

Persoonlijk heb ik naast mijn wachtwoord ook een ontsleutelbestand dat ik enkel fysiek verplaats, dus de impact van het uitlekken van dat wachtwoord zou zelfs nog geen toegang geven. Mijn wachtwoordendatabank zelf is potentieel iets makkelijker te verkrijgen omdat deze in een cloud staat, maar anders zou deze niet gesynchroniseerd kunnen blijven op verschillende toestellen.

Je hoeft niet meteen het kind met het badwater weg te gooien hierdoor Hoewel je altijd een gezonde dosis scepsis moet hebben als je programma's gebruikt die beweren veilig te zijn, zijn er voldoende wachtwoordbeheerders waarvan de veiligheid al voldoende getest is en een veel veiliger alternatief zijn dan overal hetzelfde wachtwoord te gebruiken of een of andere achterhaalbare structuur te gebruiken in je wachtwoorden.

Geen online wachtwoordmanager. Als je wachtwoordmanager niet via internet te benaderen is en überhaupt geen API heeft om er interactie mee te hebben is er weinig te misbruiken.

KeePass(X) is niet veel meer dan een veredeld encrypted tekstbestandje met daarin gebruikersnaam / wachtwoord combinaties. Geen ingang is ook geen toegang tot de data, anders dan brute force de encryptie breken.

Numero uno om geen wachtwoordmanager te gebruiken die veilig is verklaard

Niets is veilig en alles is te kraken. Denken dat dit niet zo is, is dan weer security fout numero uno.

Niets is veilig

En overdrijven is een kunst.

Hij zegt niet dat je geen passwordmanager mag/moet gebruiken, enkel dat je wel moet nadenken over de gevolgen (omdat inderdaad niks veilig is).

Dat is niet overdrijven, maar mensen met de feiten op de neus drukken

Nee, dat zijn niet 'feiten', dat is generaliserende onzin. 'Veilig' is een relatieve term en jullie noemen nu alles onveilig. Ik reken erop dat jullie geen internetbankieren gebruiken, online chats, videobellen, enzovoorts, aangezien jullie alles zeer onveilig vinden.

En als je alles 'onveilig' bestempelt, dan zul je zeker ook niet in de security industrie werken. Niemand die je aanneemt als je daar met lege handen aankomt met het verhaal dat alle IT'ers hun bedrijf moeten opdoeken door het ontbreken van 'veilige' oplossingen…

Ik denk dat m'n punt wel duidelijk is: als je niets 'veilig' vindt en alles onveilig, dan is een cursus relativeren geen onveilig advies.

Het is niet generaliserend. Het is voor mij reden nummer 1 dat ik geen gebruik maak van een wachtwoord beheerder. 1 kritiek punt van falen en nog digitaal ook, in de digitale wereld is niets veilig.

Ja natuurlijk zijn er genoeg situaties waarbij een wachtwoord beheerder veiliger is dan de overige oplossingen want het lukt niet iedereen om wachtwoorden te onthouden(Excel sheet of notitie boekje is ook niet bepaald veilig). Maar gezien we hier op Tweakers zijn en een beetje Tweaker moet een heel eind komen met wat wachtwoorden onthouden en gaat zijn bankzaken of digid niet via een wachtwoord manager beheren.

Nee, dat zijn niet 'feiten', dat is generaliserende onzin. 'Veilig' is een relatieve term en jullie noemen nu alles onveilig. Ik reken erop dat jullie geen internetbankieren gebruiken, online chats, videobellen, enzovoorts, aangezien jullie alles zeer onveilig vinden.

Jij hebt het over gevoel, wij gewoon over de absolute zin van het woord

Daarnaast ben ik niet bang voor dingen die niet veilig zijn, zo rij ik elke dag auto, en nog met een gerust hart ook, immers relativeer ik wel (zoals ik al aangaf, maar mijn eerste zin lijk je dan ook niet helemaal te begrijpen), maar dat maakt mij niet minder bewust dat dingen in mindere of meerdere maten onveilig zijn...

Wat hier niet vermeld is dat ook de "Safe browsing" applicatie van trend micro ontzettend onveilig is aangezien het een oude chrome 41 meeleverd met sandboxing uitgeschakeld.

https://code.google.com/p...h/issues/detail?id=693#c9

Vanwege dit soort incidenten heb ik er in 2013 voor gekozen om zelf een offline password manager te schrijven; offline omdat ik naar aanleiding van incidenten zoals deze niet 100% garantie heb dat een cloud password manager daadwerkelijk te vertrouwen is waar het de integriteit van mijn gegevens betreft en zelf geschreven omdat de beschikbare offline, open source password managers in de regel bewerkelijke interfaces hebben die niet gericht zijn op gebruiksvriendelijkheid (neem als voorbeeld KeePass; werkt prima, doet precies wat je er van verwacht maar, die interface... werkelijk waar, dit is niet 1996 mensen, dat kan beter, simpeler).

Het meest jammere aan dit specifieke incident is dat Trend Micro best wel een naam heeft te verliezen; het is nou niet bepaald een kleine speler. Met een jaar omzet van bijna een miljard euro.

Hoe zit het eigenlijk met de password manager lastpass? Heb hier alleen maar goede dingen over gehoord en gebruik de betaalde versie nu al een tijdje. Erg over te spreken want het maakt een hoop dingen erg makkelijk en hoop ik ook veiliger.

Hehe. Stiekem vraag ik me af of hier wat irritatie/frustratie in verwerkt zit dat het zo breed uitgemeten wordt dat er een lek in zat.

Trend Micro heeft het Google knap lastig gemaakt door enorm veel nieuwe methodes te verzinnen waarmee stagefright en varianten geexploit konden worden, en de scope en impact dus alleen maar erger en erger werd, en dus ook slechte PR opleverde. In principe een goede zaak, want het was ook gewoon een ziekelijk groot lek.

Dan moet ik toch stiekem een beetje lachen als uitgerekend Google dit lek opspoort en er meteen met veel bombarie berichten over naar buiten stuurt.

Afijn, ook terecht. Ook dit is een gevaarlijk lek. Leip dat TM dat soort dingen niet zelf beter test. Ze hebben absoluut de expertise ervoor in huis. Moet zeggen dat ik dat API verhaal een beetje eng vind. Ik zou niet willen dat mn password manager ook maar op enige wijze reageert op queries, of ook zelfs maar naar huis belt; behalve om te controleren op updates als ik dat vraag.

[Reactie gewijzigd door WhatsappHack op 12 januari 2016 14:14]

Ook was het mogelijk om willekeurige code uit te voeren.

Fout: Ormandy heeft gezegd dat hij "niet verbaasd zou zijn" als je willekeurige code kon uitvoeren, niet dat hij het getest heeft.

Hij heeft het wel degelijk getest. Hij geeft zelfs voorbeelden voor drie remote code exploits aan:

https://localhost:49155/api/openUrlInDefaultBrowser?url=c:/windows/system32/calc.exe
https://localhost:49155/api/openUrlInDefaultBrowser?url=c:/users/blah~1/downlo~1/test.zip/test.hta
https://localhost:49155/api/showSB?url=javascript:alert(topWindow.require("child_process").spawnSync("calc.exe"))

Maar is dat willekeurige code? Alleen bij die laatste kan je imho echt spreken van willekeurige code, en blijf je dat niet beperkt tot wat javascript mag (net ales elke website dus)?...

De rest is gewoon het aanroepen (maar niet besturen) van bestaande apps. Misschien gaat het nog veel verder en is veel meer mogelijk, maar dat blijkt imho dan weer niet uit de voorbeelden.

Het is Proof-of-Concept code.

Als je een willekeurige binary kan executen, ben je binnen. Wat houdt je tegen om via iexplore.exe een binary te downloaden, en die vervolgens aan te roepen?

[Reactie gewijzigd door JackBol op 12 januari 2016 13:51]

Alleen al daarom is het een beetje jammer dat de Google researcher al zo snel na de patch het probleem publiek maakt. Als je programma zo'n fouten hebt moet je (zoals Tavis Ormandy ook voorstelde) eigenlijk het geheel platleggen en een grondig onderzoek laten uitvoeren (externe expert of ander team binnen het bedrijf met de nodige expertise).

Als er zo'n dingen over het hoofd worden gezien moet je ervan uitgaan dat er elders nog andere fouten zitten.

Niet fout: als je de betreffende tread leest: https://code.google.com/p...arch/issues/detail?id=693 Hij heeft een voorbeeld dat calc.exe geopend wordt vanuit de webbrowser en een voorbeeld dat er een commando uitgevoerd wordt op de command prompt. Een aanvaller kan dus alles remote doen waar de gebruikersaccount rechten voor heeft.