Tweede zerodaylek in Google Chrome nog niet gepatcht
Gebruikers van Google Chrome zijn via twee zerodaylekken in de browser met malware besmet en voor de tweede kwetsbaarheid is nog geen patch verschenen. Google kwam afgelopen donderdag met een beveiligingsupdate voor een kwetsbaarheid en meldde dat het lek in Chrome actief werd aangevallen.
De kwetsbaarheid werd door Google als "high" bestempeld. Het gaat in dit geval om lekken waardoor een aanvaller code binnen de context van de browser kan uitvoeren. Het is dan mogelijk om bijvoorbeeld data van andere websites te lezen of aan te passen. Ook kwetsbaarheden om uit de Chrome-sandbox te ontsnappen vallen hieronder. Het beveiligingslek (CVE-2019-13720) alleen is niet voldoende om systemen te compromitteren. Hiervoor zou een tweede kwetsbaarheid zijn vereist. Verdere details over de aanval werden echter niet door Google gegeven.
Die blijkt er inderdaad te zijn. De twee zerodaylekken werden door onderzoekers van antivirusbedrijf Kaspersky ontdekt en aan Google gerapporteerd. De virusbestrijder heeft nu een analyse van de aanval online gezet. Het gaat om een zogeheten "watering hole attack". Hierbij plaatsen aanvallers exploits op gecompromitteerde websites die beoogde doelwitten al uit zichzelf bezoeken. In dit geval werd de exploit op een niet nader genoemde Koreaanse nieuwssite geplaatst.
Volgens Kaspersky maakt het grootste deel van de exploit gebruik van een bepaald kwetsbaar onderdeel van de browser. "Aangezien deze bug nog steeds niet is verholpen, geven we geen details over dit specifieke kwetsbare onderdeel", zo laat het bedrijf in de analyse weten. Wanneer de exploit succesvol is wordt er malware op het systeem geïnstalleerd. Tevens maakt de malware verschillende taken aan in de Windows Taakplanner. Verdere details om wat voor soort malware het gaat is niet bekendgemaakt. Ook is onbekend wanneer Google het tweede zerodaylek patcht.
Reacties (9)
Off topic...maar niet helemaal:
Als ik bijvoorbeeld denk aan webbrowser kwetsbaarheden die je financiële positie kunnen benadelen, waarmee ik heel eenvoudig denk aan het zogenaamde internetbankieren, vraag ik mij af, als gewoon doorgewinterd computergebruiker, ik ben dus géén IT'er!, of de mogelijkheid slechts een zelfs onzinnige utopie is dat bijvoorbeeld een bankinstelling een sand-boxed web'browser' zou kunnen bouwen die uitsluitend verbinding kan maken tussen klant en bank, dus uiteraard niet voorzien is van een URL invoerbalk. Dus elke andere poging dan communicatie tussen vooraf geprogrammeerde IP adressen (klant en bank) zouden geblokkeerd zijn.
Deze afgeschermde werkomgeving moet dan verder andere scripting dan exact vastgelegd/geprogrammeerd resoluut blokkeren en zou - zo denk ik dan - niet kunnen communiceren met vreemde code-injectie omdat die niet voorkomt in een lijst met toegestane verwerking binnen de werkomgeving.
Ook zou deze 'browser' uitsluitend gestart moeten kunnen worden na zo streng mogelijke authenticatie, anders niet.
Voor alle helderheid: Dit programma zou dus een autonome 'browser' moeten zijn die alleen verbinding kan maken tussen één host en één client.
Als ik bijvoorbeeld denk aan webbrowser kwetsbaarheden die je financiële positie kunnen benadelen, waarmee ik heel eenvoudig denk aan het zogenaamde internetbankieren, vraag ik mij af, als gewoon doorgewinterd computergebruiker, ik ben dus géén IT'er!, of de mogelijkheid slechts een zelfs onzinnige utopie is dat bijvoorbeeld een bankinstelling een sand-boxed web'browser' zou kunnen bouwen die uitsluitend verbinding kan maken tussen klant en bank, dus uiteraard niet voorzien is van een URL invoerbalk. Dus elke andere poging dan communicatie tussen vooraf geprogrammeerde IP adressen (klant en bank) zouden geblokkeerd zijn.
Deze afgeschermde werkomgeving moet dan verder andere scripting dan exact vastgelegd/geprogrammeerd resoluut blokkeren en zou - zo denk ik dan - niet kunnen communiceren met vreemde code-injectie omdat die niet voorkomt in een lijst met toegestane verwerking binnen de werkomgeving.
Ook zou deze 'browser' uitsluitend gestart moeten kunnen worden na zo streng mogelijke authenticatie, anders niet.
Voor alle helderheid: Dit programma zou dus een autonome 'browser' moeten zijn die alleen verbinding kan maken tussen één host en één client.
"Tevens maakt de malware verschillende taken aan in de Windows Taakplanner."
Amateurs die van zero days gebruik maken. Waar hebben we dat eerder gezien? China.
Amateurs die van zero days gebruik maken. Waar hebben we dat eerder gezien? China.
Door Wilbert Wintergaard: Off topic...maar niet helemaal:
Als ik bijvoorbeeld denk aan webbrowser kwetsbaarheden die je financiële positie kunnen benadelen, waarmee ik heel eenvoudig denk aan het zogenaamde internetbankieren, vraag ik mij af, als gewoon doorgewinterd computergebruiker, ik ben dus géén IT'er!, of de mogelijkheid slechts een zelfs onzinnige utopie is dat bijvoorbeeld een bankinstelling een sand-boxed web'browser' zou kunnen bouwen die uitsluitend verbinding kan maken tussen klant en bank, dus uiteraard niet voorzien is van een URL invoerbalk. Dus elke andere poging dan communicatie tussen vooraf geprogrammeerde IP adressen (klant en bank) zouden geblokkeerd zijn.
Deze afgeschermde werkomgeving moet dan verder andere scripting dan exact vastgelegd/geprogrammeerd resoluut blokkeren en zou - zo denk ik dan - niet kunnen communiceren met vreemde code-injectie omdat die niet voorkomt in een lijst met toegestane verwerking binnen de werkomgeving.
Ook zou deze 'browser' uitsluitend gestart moeten kunnen worden na zo streng mogelijke authenticatie, anders niet.
Voor alle helderheid: Dit programma zou dus een autonome 'browser' moeten zijn die alleen verbinding kan maken tussen één host en één client.
Als ik bijvoorbeeld denk aan webbrowser kwetsbaarheden die je financiële positie kunnen benadelen, waarmee ik heel eenvoudig denk aan het zogenaamde internetbankieren, vraag ik mij af, als gewoon doorgewinterd computergebruiker, ik ben dus géén IT'er!, of de mogelijkheid slechts een zelfs onzinnige utopie is dat bijvoorbeeld een bankinstelling een sand-boxed web'browser' zou kunnen bouwen die uitsluitend verbinding kan maken tussen klant en bank, dus uiteraard niet voorzien is van een URL invoerbalk. Dus elke andere poging dan communicatie tussen vooraf geprogrammeerde IP adressen (klant en bank) zouden geblokkeerd zijn.
Deze afgeschermde werkomgeving moet dan verder andere scripting dan exact vastgelegd/geprogrammeerd resoluut blokkeren en zou - zo denk ik dan - niet kunnen communiceren met vreemde code-injectie omdat die niet voorkomt in een lijst met toegestane verwerking binnen de werkomgeving.
Ook zou deze 'browser' uitsluitend gestart moeten kunnen worden na zo streng mogelijke authenticatie, anders niet.
Voor alle helderheid: Dit programma zou dus een autonome 'browser' moeten zijn die alleen verbinding kan maken tussen één host en één client.
Een programma dat op een untrusted OS moet draaien heeft altijd verloren.
Het OS kan (met meer of minder moeite) alles zien/doen/wijzigen in het programma . Of gewoon die dichtgetimmerde bank-browser vervangen door ééntje die niet dichtgetimmerd zit maar er hetzelfde uit ziet.
Een "bank-browser" voor een reguliere desktop voegt dan niet zo veel toe .
Vanuit de bank gezien kunnen ze weinig garanderen - en hebben ze wel het probleem dat als mensen werken met de bank-browser op een systeem vol trojans de bank wel de schuld krijgt.
Ik weet niet meer of jij een van de mensen was die ageerde tegen bank-apps, maar op een hoop manieren is dat precies wat een bank-app op een mobiel device is.
Waar mogelijk hangt het starten/benaderen van de app af van de fingerprint (of face id) van het mobiele device - precies de strenge authenticatie die je wilt.
En hoewel compromised mobiele devices bestaan, zijn ze heel veel zeldzamer dan compromised desktops.
Als je nog voorzichter wilt zijn zou je een dedicated device moeten gebruiken voor je bankier-zaken.
Hi W.W.,
Als een browser veilig houden voor een gigant als Google al zo'n punt is,
wat verwacht je dan van een "veilige" bank-browser die in een zandbak draait?
Aan de andere kant als je dit door Google laat doen met een bank-zandbak omgeving,
gaan ze meteen al met al je bank-data aan de haal.
En stel dat een malcreant je zo'n Bank-Security-Browser voorzet?
Browsermaker hou je bij je leest, dus.
J.O.
Als een browser veilig houden voor een gigant als Google al zo'n punt is,
wat verwacht je dan van een "veilige" bank-browser die in een zandbak draait?
Aan de andere kant als je dit door Google laat doen met een bank-zandbak omgeving,
gaan ze meteen al met al je bank-data aan de haal.
En stel dat een malcreant je zo'n Bank-Security-Browser voorzet?
Browsermaker hou je bij je leest, dus.
J.O.
Door Wilbert Wintergaard: Off topic...maar niet helemaal:
... dat bijvoorbeeld een bankinstelling een sand-boxed web'browser' zou kunnen bouwen die uitsluitend verbinding kan maken tussen klant en bank, dus uiteraard niet voorzien is van een URL invoerbalk. Dus elke andere poging dan communicatie tussen vooraf geprogrammeerde IP adressen (klant en bank) zouden geblokkeerd zijn....
Ook zou deze 'browser' uitsluitend gestart moeten kunnen worden na zo streng mogelijke authenticatie, anders niet.
Voor alle helderheid: Dit programma zou dus een autonome 'browser' moeten zijn die alleen verbinding kan maken tussen één host en één client.
... dat bijvoorbeeld een bankinstelling een sand-boxed web'browser' zou kunnen bouwen die uitsluitend verbinding kan maken tussen klant en bank, dus uiteraard niet voorzien is van een URL invoerbalk. Dus elke andere poging dan communicatie tussen vooraf geprogrammeerde IP adressen (klant en bank) zouden geblokkeerd zijn....
Ook zou deze 'browser' uitsluitend gestart moeten kunnen worden na zo streng mogelijke authenticatie, anders niet.
Voor alle helderheid: Dit programma zou dus een autonome 'browser' moeten zijn die alleen verbinding kan maken tussen één host en één client.
In feite doen de bankieren apps op de telefoon dit. Die vereisen eerst strenge authenticatie, en bezoeken daarna via een browser die geen andere website kan bezoeken de website van de bank.
Ze gebruiken daarvoor wel gewoon de "browser" van de telefoon. Maar op zich is dat niet slecht, want ik heb liever dat die browser wordt gebruikt als een "nieuwe" browser die ontwikkeld wordt door een aantal developers bij de bank. Dan ben je afhankelijk van hoe snel zij bugs ontdekken en verhelpen in "hun" browser. De grotere browsers hebben meer ogen die naar bugs zoeken. Een bug als deze gevonden in Chrome zou misschien wel jaren in de "bank-browser" kunnen zitten voordat hij überhaupt opgemerkt wordt.
Het zelfde zou gelden voor desktop gebruikt. Wat je dan krijgt is een telebankieren applicatie. Dan ben je overigens ook weer afhankelijk van de leverancier, in dit geval de bank, dat ze een applicatie maken die op alle OS'es draait. En ook weer afhankelijk hoeveel tijd de bank erin steekt om bugs op te sporen en te verhelpen. Aangezien hun core-business bankieren is, en niet software ontwikkelen kun je er denk ik van uit gaan dat de "normale" webbrowser beter worden onderhouden en gepatcht als die van de bank als ze die helemaal opnieuw ontwikkelen.
Door Anoniem:
Amateurs die van zero days gebruik maken. Waar hebben we dat eerder gezien? China.
Amateurs die van zero days gebruik maken. Waar hebben we dat eerder gezien? China.
Eerder Zuid-Korea...
Waarom mocht toch in het land van de "bold and the free" Kaspersky
niet meer op gouvernementeel niveau gebruikt worden?
Had men zich te onafhankelijk opgesteld bij de analyse van tal van zaken,
die men liever daar niet zo aangekaart zag?
Wie hebben en hadden er hier boter op het hoofd?
Zonder Kaspersky blijkt de wereld dus een stuk onveiliger en niet door of vanwege Kaspersky's.
Google via Google Chrome krijgt te veel macht binnen de browser-arena.
Ze laten alles en iedereen door hun hoepeltjes springen.
Mono-cultures maken de wereld onveiliger, ja ook de Google mono-cultuur.
luntrus
niet meer op gouvernementeel niveau gebruikt worden?
Had men zich te onafhankelijk opgesteld bij de analyse van tal van zaken,
die men liever daar niet zo aangekaart zag?
Wie hebben en hadden er hier boter op het hoofd?
Zonder Kaspersky blijkt de wereld dus een stuk onveiliger en niet door of vanwege Kaspersky's.
Google via Google Chrome krijgt te veel macht binnen de browser-arena.
Ze laten alles en iedereen door hun hoepeltjes springen.
Mono-cultures maken de wereld onveiliger, ja ook de Google mono-cultuur.
luntrus
Door Anoniem:
Eerder Zuid-Korea...
Door Anoniem:
Amateurs die van zero days gebruik maken. Waar hebben we dat eerder gezien? China.
Amateurs die van zero days gebruik maken. Waar hebben we dat eerder gezien? China.
Eerder Zuid-Korea...
In China werkt men in cellen. Er zijn mensen die exploits maken en er zijn er die ze gebruiken. De laatste categorie werd/wordt bevolkt door amateurs. Ze vallen westerse strategische doelen aan met verhalen voor Zuid-Chinese Zee. Alsof men daar belangstelling voor heeft in het westen.
04-11-2019, 12:26 door
hanspaint
Door Wilbert Wintergaard: Off topic...maar niet helemaal:
Als ik bijvoorbeeld denk aan webbrowser kwetsbaarheden die je financiële positie kunnen benadelen, waarmee ik heel eenvoudig denk aan het zogenaamde internetbankieren, vraag ik mij af, als gewoon doorgewinterd computergebruiker, ik ben dus géén IT'er!, of de mogelijkheid slechts een zelfs onzinnige utopie is dat bijvoorbeeld een bankinstelling een sand-boxed web'browser' zou kunnen bouwen die uitsluitend verbinding kan maken tussen klant en bank, dus uiteraard niet voorzien is van een URL invoerbalk. Dus elke andere poging dan communicatie tussen vooraf geprogrammeerde IP adressen (klant en bank) zouden geblokkeerd zijn.
Deze afgeschermde werkomgeving moet dan verder andere scripting dan exact vastgelegd/geprogrammeerd resoluut blokkeren en zou - zo denk ik dan - niet kunnen communiceren met vreemde code-injectie omdat die niet voorkomt in een lijst met toegestane verwerking binnen de werkomgeving.
Ook zou deze 'browser' uitsluitend gestart moeten kunnen worden na zo streng mogelijke authenticatie, anders niet.
Voor alle helderheid: Dit programma zou dus een autonome 'browser' moeten zijn die alleen verbinding kan maken tussen één host en één client.
Als ik bijvoorbeeld denk aan webbrowser kwetsbaarheden die je financiële positie kunnen benadelen, waarmee ik heel eenvoudig denk aan het zogenaamde internetbankieren, vraag ik mij af, als gewoon doorgewinterd computergebruiker, ik ben dus géén IT'er!, of de mogelijkheid slechts een zelfs onzinnige utopie is dat bijvoorbeeld een bankinstelling een sand-boxed web'browser' zou kunnen bouwen die uitsluitend verbinding kan maken tussen klant en bank, dus uiteraard niet voorzien is van een URL invoerbalk. Dus elke andere poging dan communicatie tussen vooraf geprogrammeerde IP adressen (klant en bank) zouden geblokkeerd zijn.
Deze afgeschermde werkomgeving moet dan verder andere scripting dan exact vastgelegd/geprogrammeerd resoluut blokkeren en zou - zo denk ik dan - niet kunnen communiceren met vreemde code-injectie omdat die niet voorkomt in een lijst met toegestane verwerking binnen de werkomgeving.
Ook zou deze 'browser' uitsluitend gestart moeten kunnen worden na zo streng mogelijke authenticatie, anders niet.
Voor alle helderheid: Dit programma zou dus een autonome 'browser' moeten zijn die alleen verbinding kan maken tussen één host en één client.
Door Wilbert Wintergaard: Off topic...maar niet helemaal:
Als ik bijvoorbeeld denk aan webbrowser kwetsbaarheden die je financiële positie kunnen benadelen, waarmee ik heel eenvoudig denk aan het zogenaamde internetbankieren, vraag ik mij af, als gewoon doorgewinterd computergebruiker, ik ben dus géén IT'er!, of de mogelijkheid slechts een zelfs onzinnige utopie is dat bijvoorbeeld een bankinstelling een sand-boxed web'browser' zou kunnen bouwen die uitsluitend verbinding kan maken tussen klant en bank, dus uiteraard niet voorzien is van een URL invoerbalk. Dus elke andere poging dan communicatie tussen vooraf geprogrammeerde IP adressen (klant en bank) zouden geblokkeerd zijn.
Deze afgeschermde werkomgeving moet dan verder andere scripting dan exact vastgelegd/geprogrammeerd resoluut blokkeren en zou - zo denk ik dan - niet kunnen communiceren met vreemde code-injectie omdat die niet voorkomt in een lijst met toegestane verwerking binnen de werkomgeving.
Ook zou deze 'browser' uitsluitend gestart moeten kunnen worden na zo streng mogelijke authenticatie, anders niet.
Voor alle helderheid: Dit programma zou dus een autonome 'browser' moeten zijn die alleen verbinding kan maken tussen één host en één client.
Als ik bijvoorbeeld denk aan webbrowser kwetsbaarheden die je financiële positie kunnen benadelen, waarmee ik heel eenvoudig denk aan het zogenaamde internetbankieren, vraag ik mij af, als gewoon doorgewinterd computergebruiker, ik ben dus géén IT'er!, of de mogelijkheid slechts een zelfs onzinnige utopie is dat bijvoorbeeld een bankinstelling een sand-boxed web'browser' zou kunnen bouwen die uitsluitend verbinding kan maken tussen klant en bank, dus uiteraard niet voorzien is van een URL invoerbalk. Dus elke andere poging dan communicatie tussen vooraf geprogrammeerde IP adressen (klant en bank) zouden geblokkeerd zijn.
Deze afgeschermde werkomgeving moet dan verder andere scripting dan exact vastgelegd/geprogrammeerd resoluut blokkeren en zou - zo denk ik dan - niet kunnen communiceren met vreemde code-injectie omdat die niet voorkomt in een lijst met toegestane verwerking binnen de werkomgeving.
Ook zou deze 'browser' uitsluitend gestart moeten kunnen worden na zo streng mogelijke authenticatie, anders niet.
Voor alle helderheid: Dit programma zou dus een autonome 'browser' moeten zijn die alleen verbinding kan maken tussen één host en één client.
Door Wilbert Wintergaard: Off topic...maar niet helemaal:
Als ik bijvoorbeeld denk aan webbrowser kwetsbaarheden die je financiële positie kunnen benadelen, waarmee ik heel eenvoudig denk aan het zogenaamde internetbankieren, vraag ik mij af, als gewoon doorgewinterd computergebruiker, ik ben dus géén IT'er!, of de mogelijkheid slechts een zelfs onzinnige utopie is dat bijvoorbeeld een bankinstelling een sand-boxed web'browser' zou kunnen bouwen die uitsluitend verbinding kan maken tussen klant en bank, dus uiteraard niet voorzien is van een URL invoerbalk. Dus elke andere poging dan communicatie tussen vooraf geprogrammeerde IP adressen (klant en bank) zouden geblokkeerd zijn.
Deze afgeschermde werkomgeving moet dan verder andere scripting dan exact vastgelegd/geprogrammeerd resoluut blokkeren en zou - zo denk ik dan - niet kunnen communiceren met vreemde code-injectie omdat die niet voorkomt in een lijst met toegestane verwerking binnen de werkomgeving.
Ook zou deze 'browser' uitsluitend gestart moeten kunnen worden na zo streng mogelijke authenticatie, anders niet.
Voor alle helderheid: Dit programma zou dus een autonome 'browser' moeten zijn die alleen verbinding kan maken tussen één host en één client.
Als ik bijvoorbeeld denk aan webbrowser kwetsbaarheden die je financiële positie kunnen benadelen, waarmee ik heel eenvoudig denk aan het zogenaamde internetbankieren, vraag ik mij af, als gewoon doorgewinterd computergebruiker, ik ben dus géén IT'er!, of de mogelijkheid slechts een zelfs onzinnige utopie is dat bijvoorbeeld een bankinstelling een sand-boxed web'browser' zou kunnen bouwen die uitsluitend verbinding kan maken tussen klant en bank, dus uiteraard niet voorzien is van een URL invoerbalk. Dus elke andere poging dan communicatie tussen vooraf geprogrammeerde IP adressen (klant en bank) zouden geblokkeerd zijn.
Deze afgeschermde werkomgeving moet dan verder andere scripting dan exact vastgelegd/geprogrammeerd resoluut blokkeren en zou - zo denk ik dan - niet kunnen communiceren met vreemde code-injectie omdat die niet voorkomt in een lijst met toegestane verwerking binnen de werkomgeving.
Ook zou deze 'browser' uitsluitend gestart moeten kunnen worden na zo streng mogelijke authenticatie, anders niet.
Voor alle helderheid: Dit programma zou dus een autonome 'browser' moeten zijn die alleen verbinding kan maken tussen één host en één client.
Gebruik de bankapp op je telefoon of tablet is veiliger dan internetbankieren met een browser. En voldoet grotendeels aan je wensen.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
