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.
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.
Amateurs die van zero days gebruik maken. Waar hebben we dat eerder gezien? China.
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.
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.
... 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.
Amateurs die van zero days gebruik maken. Waar hebben we dat eerder gezien? China.
Eerder Zuid-Korea...
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
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.
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.
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.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.