Kat-en-muisspel rond Google Password Alert duurt voort
Er is inmiddels een waar kat-en-muisspel ontstaan rond de Password Alert-extensie van Google die Chromegebruikers tegen phishingaanvallen moet beschermen, maar inmiddels een aantrekkelijk doelwit van onderzoekers is geworden die de uitbreiding steeds proberen te omzeilen en daar ook in slagen.
Password Alert zorgt ervoor dat gebruikers die hun Google-wachtwoord op een phishingsite invullen een waarschuwing krijgen. Vervolgens is het mogelijk om vanuit de waarschuwing het wachtwoord te wijzigen. Eerder deze week slaagde de Britse securityconsultant Paul Moore erin om Password Alert via een script van zeven regels te omzeilen. Gebruikers kregen in dit geval geen waarschuwing als ze hun Google-wachtwoord op een phishingsite invulden.
Google kwam met een update naar versie 1.4, die ook door Moore werd omzeild. Wederom publiceerde Google een nieuwe versie, 1.5, waarop het Nederlandse beveiligingsbedrijf Securify met een manier kwam om de waarschuwing te omzeilen. Het duurde echter niet lang voordat Google ook deze aanval had afgevangen en versie 1.6 uitbracht. Onderzoekers zijn er nu in geslaagd ook deze versie, wat de meest recente versie is, te omzeilen.
"Inmiddels hebben we weer een nieuwe manier gevonden om Password Alert te omzeilen. Door het loginformulier in een iframe te laden waarvan Javascript is uitgeschakeld, is het niet meer mogelijk voor Password Alert om toetsaanslagen af te vangen. Hierdoor werkt de detectie niet meer", zegt Yorick Koster van Securify tegenover Security.NL. "In feite is dit een kat-en-muisspel. De extensie controleert of een gebruiker zijn Google-accountgegevens heeft ingevuld: e-mailadres en wachtwoord. Wanneer één van die twee niet meer goed doorkomt, dan werkt de detectie niet meer."
Waarom zou je dat denken?
Op deze site heeft u kunnen lezen dat Google Chrome met vijhonderd veiligheidslekken in een jaar, zelfs I.E. van de troon gestoten heeft.
Het opslaan van wachtwoorden in platte tekst is ook niet echt veilig.
"Google doesn't always get security right - far from it. There have, after all, been holes poked in Google's security reputation.
Researchers exposed a gaping hole in code verification on Android due to poor coding.
One week later, well, it was déjà vu all over again.
Chinese researchers found another bug with the same side-effect - a signed-unsigned integer mismatch that once again left a gaping hole in code verification."
Zoek de verschillen:
security.nl
securify.nl
Gelukkig is het domein door/voor een goed doel bezet.
Op het oog minder gelukkig, op zijn minst grappig: securify - vacatures
Als ontwikkelaar ga je meedenken en bouwen aan een nieuw innovatief platform om fraude (malware) mee te bestrijden.
Al zijn de functie-eisen ten aanzien van security ervaring en inzichten voor sommigen nog wel wat hoog gegrepen misschien.
Te vinden op de afdeling Java-vacancies' van die site
https://securify.nl/vacancies.html
Plagerijtje natuurlijk, 'Java is suuper veilig' en 'developers zijn zelf uitermate secuur wat betreft de eigen security' als iedereen tenminste maar zijn software up to date houdt.
Wat eindgebruikers dan weer helaas massaal niet doen.
https://www.security.nl/posting/40193/Ook+Microsoft+gehackt+via+Java-lek
https://www.security.nl/posting/40143/Apple+gehackt+via+Java-lek
https://www.security.nl/posting/40101/Facebook+gehackt+via+Java+zero-day-lek
Oud nieuws, iedereen heeft zijn leven gebeterd!
Zou het? Keep on .. ?
Zonnige vakantie toegewenst met/op Java.
Het fundamentele probleem is dat HTML/Javascript niet ontworpen is om een dergelijke beveiliging te bieden. En dat het mechanisme van het invoeren van wachtwoorden er in de gebruikte vorm ook geen voorzieningen voor heeft.
Het mechanisme dat Windows bijvoorbeeld kent om hergebruik van, en zwakke wachtwoorden te voorkomen is in de kern aanwezig. Dat kan natuurlijk ook wel fouten bevatten in de vorm slechte code, maar is architectonisch robuuster.
Om iets dergelijks te bereiken zou de "Password Alert" al voor het tonen van het originele inlog-scherm moeten ingrijpen en het inlogproces moeten emuleren; bijvoorbeeld met een modal popup. Maar ik ben bang dat dat weer tegen allerlei andere goede beveiligingsprincipes zondigt. Het zou wel het voordeel bieden, dat het Windows mechanisme nu ook biedt: "Voorkomen dat de onwenselijke situatie optreed. Ipv. achteraf waarschuwen".
Het pad dat Google nu heeft gekozen is een "dead end"
Waarom zou je dat denken?
Op deze site heeft u kunnen lezen dat Google Chrome met vijhonderd veiligheidslekken in een jaar, zelfs I.E. van de troon gestoten heeft.
Cijfers creatief interpreteren, dan zou ik ook als anoniem reageren.
Waarom zou je dat denken?
Op deze site heeft u kunnen lezen dat Google Chrome met vijhonderd veiligheidslekken in een jaar, zelfs I.E. van de troon gestoten heeft.
Cijfers creatief interpreteren, dan zou ik ook als anoniem reageren.
Ken je die mop van de ene anonieme tegen de andere anonieme over creatief interpreteren?
- Je moet niet anoniem reageren.
Prachtig opnemen in het grote moppenboek. { :<))
En nog eentje een security specialist die beweerd dat zijn ideale leverancier alles fantastisch doet. Vervolgens reageerd alsof hij persoonlijk aangevallen wordt dat het om creatieve manipulatie gaat. Even checken
http://news.softpedia.com/news/Google-Chrome-Recorded-the-Highest-Number-of-Vulnerabilities-in-January-2015-473426.shtml Waar is de kritische mindset gebleven?
Hebben we het over java-script dan is dat een interpreter. Niet iets waar je security aan ophangt (privilege escalation).
Met als gevolg dat niemand er nog over peinst op zoek te gaan naar al die kritieke gaten in Oracle producten, misbruik van door Oracle aangeleverde kwetsbaarheden volstaat, de meeste klanten lopen immers toch meer dan twee kwartalen in het update circus achterop.
Deze posting is gelocked. Reageren is niet meer mogelijk.