Proponha uma correção, faça uma sugestão
Exploit põe em causa segurança do Chrome
O Chrome é tido como um dos Browsers mais seguros da actualidade. Devido à sua diminuta quota de mercado, tem gozado durante algum tempo desse estatuto. Mas há medida que tem registado um aumento galopante na quota de mercado dos navegadores Web, era apenas uma questão de tempo até ser concebida uma extensão engenhosa pondo em causa a sua segurança e a dos seus utilizadores.
O programador Andreas Grech desenvolveu uma extensão para o Chrome, utilizando as bibliotecas de Ajax jQuery, de modo a monitorizar as credenciais de login num formulário e enviá-las para o seu mail. Segundo o próprio:
"O Google Chrome, permite a instalação de extensões desenvolvidas por terceiros que permite estender as funcionalidades do browser. As extensões são escritas em Javascript e HTML e permite uma manipulação do DOM, entre outras potencialidades.
Ao permitir acesso ao DOM, um atacante pode percorrê-lo e ler campos, inclusive o nome de utilizador e palavra pass. Foi esta a ideia que me levou a desenvolver este Proof of Concept
A extensão que apresento é bastante simples. Quando um utilizador submete um formulário, esta tenta capturar o conteúdo dos campos referentes ao nome de utilizador e password, manda-me um mail com esta informação e a url via uma chamada por Ajax a um script e depois procede à submissão normal do formulário de modo a evitar que haja uma detecção deste processo."
O código para conseguir este “exploit”, está disponível no blog do autor. Esta falha demonstra que apesar de o sistema de extensões do Chrome ser uma funcionalidade que há muito tempo era esperada de modo a este browser se aproximar de todo o potencial que conhecemos no Firefox, não deixa de ironicamente ser o seu calcanhar de Aquiles.
Este desleixo da forma como foi pensado o sistema de extensões do Chrome, abre uma porta escancarada ao computador dos seus utilizadores, pronta a ser utilizada por qualquer hacker mal intencionado, que queira injectar várias vertentes de malware. Tudo se resume a uma falha gravíssima de segurança, explorável por um código tão simples.
Talvez seja por isso, que a Firefox sempre apostou numa linguagem própria (o XUL), que é a tecnologia que está por detrás do seu browser, e que é simultaneamente usada no seu sistema de extensões, em vez de HTML e Javacript que são mais de domínio público e de fácil aprendizagem para orquestrar estes ataques. Isto tudo no nosso ponto de vista, demonstra que nesta particular funcionalidade a Google não tem a experiencia da Mozilla e que tem muito ainda um longo caminho a percorrer em aperfeiçoar o frágil sistema de extensões do Chrome.
Fonte: Knowledge-Aholic
Este artigo tem mais de um ano
Loading ...
Dado que o utilizador tem que ACEITAR instalar tal extensão de fontes não confiáveis, não passa de uma “falha de segurança” que já existe desde sempre na informática. Eu também posso enviar um virus para alguém e dizer “olha instala que tem gajas nuas”…
A responsabilidade é de quem instala… mas talvez se consiga fazer alguma coisa para melhorar a “burrice” dos users 🙂
Não é bem assim… Qq extensão que instalas pode ter um aspecto perfeitamente fiavel e executar uma função perfeitamente normal e no seu background estar a enviar os teus dados privados para terceiros.
Nunca se sabe o que uma extensão está a fazer na realidade, por isso sim trata-se de uma falha de segurança.
Por outro lado não sei a que ponto é que esta situação se aplica apenas ao chrome…
Não concordo nada contigo Ricardo.
Repara que, depois de lermos este artigo, podemos dizer que qualquer extensão que instalemos no Chrome pode, sem nós sabermos, fazer o que é descrito.
E agora? Deixamos de usar extensões?
Sendo o browser um dos principais veículos do utilizador na internet, deve existir uma segurança pró-activa por parte do mesmo, ou seja, ele deve garantir um certo grau de segurança ao utilizador.
O que posso dizer? Hm…
Não diga que eu e a Symantec não dissemos para você usar o navegador Opera!!! 🙂
Até ao dia em que… 😀
O melhor…há dúvidas? opera 10.6
E o Opera difere em que?
No caso do uso de userjs, parece que o XMLHttpRequest() apenas funciona dentro do mesmo dominio. O acesso e’ negado a outros dominios. Num script Greasemonkey (Firefox), e’ preciso usar GM_XMLHttpRequest() para passar essa limitacao de seguranca.
No caso dos widget, algo mais equivalente a extensoes, esse acesso e’ negado? O Widget nao consegue comunicar com o DOM da pagina? Nao consegue comunicar com outros dominios? Se for essa a situacao, entao o Opera esta’ a ir para o seguro e pouco pela funcionalidade.
PS: “Publicitarem” outros browsers, software, ou Sistema Operativo quando se fala de uma falha de outro, seria mais interessante se ao menos soubessem dizer o que difere do que voces gostam, ou explicar porque nao acontece.
Fiquem Bem!
Tido como um dos browsers mais seguros do mundo? Aquele que envia informações do que é aberto à google?
Quem use este browser aconselho a SRWare Iron, um chrome com algumas funcionalidades mais seguras.
A primeira parte do último paragrafo esta um pouco esquisita, o que eu concluo de lá: O Firefox apostou no XUL para dificultar a vida aos programadores tornando o desenvolvimento de extensões e deste género de ataques difíceis.
Não acredito que tenha sido essa a razão. =\
De qualquer forma: https://jetpack.mozillalabs.com/ 😉
Em relação ao tópico em si, este tipo de extensões também são possíveis noutros browsers (pelo menos no firefox), exemplo: http://blog.mozilla.com/addons/2010/07/13/add-on-security-announcement/ (destaco a data :D).
Tens páginas a imitar os bancos, onde introduzes os teus dados e não culpas os bancos.
Mas sim acredito que seja uma falha, pois a Google sempre disse que disponibilizava as extensões após aprovação da própria Google.. significa que não andam a fazer o seu trabalho.
De certa forma podes culpabilizá-los, porquê? Porque eles tem muito dinheirinho, e já podiam ter comprado (TODOS) aqueles certificados que tornam a barra de endereço verde e que ajudam a identificar que o site é mesmo o verdadeiro.
Não interessa ter um bom anti-malware, que até pode identificar páginas de phishing… que nunca vai detectar tudo… e as falsificações até um entendido pode ser enganado se elaborarem bem a página e meterem o redireccionamento nos host sem que o entendido se aperceba.
Seguindo a mesma lógica até o linux (e windows, etc) tem a mesma falha de segurança. Sempre que se instala uma extensão o Chrome informa das permissões que a extensão necessita e pergunta se aceitamos. No linux é a mesma coisa, dizemos a um utilizador para instalar aquela aplicação que faz maravilhas mas tem de correr como root. Se ele aceitar está sujeito…
A fiabilidade do risco depende da amostra, quem diz que um browser com menos de 2 anos,pouco usado, é + seguro que outro mais velho só porque falhou menos vezes não percebe mto de estatistica…
É suposto os browsers não o deixarem, agora o que fazes com as extensões…. é que se isso que é descrito no poste não fosse feito, como poderias ter uma extensão para guardar todas os users e pass?
Proponho o Inteligent Super Browser 4 para que as navegações com e sem extensões sejam 100% seguras.
Até hoje nunca ninguém conseguiu quebrar/ atacar o Inteligent Super Browser 4, e nunca irão conseguir pois foi concebido de tal maneira que é 100% seguro… claro que este browser só é assim tão seguro porque não existe, todos os outros que existem mesmo, existe sempre alguma maneira de os comprometer seja com ou sem extensões.
?????
?????
O que ele está a dizer é que em todos os browsers, existe sempre uma ponta solta por onde pegar, por mais difícil que seja dar a volta ao sistema, nenhum é infalível.
Ele fez ver o seu ponto de vista e concordo.
“O código para conseguir este “exploit”, está disponível no blog do autor. Esta falha demonstra que apesar de o sistema de extensões do Chrome ser uma funcionalidade que há muito tempo era esperada de modo a este browser se aproximar de todo o potencial que conhecemos no Firefox, não deixa de ironicamente ser o seu calcanhar de Aquiles.”
As extensões do Chrome não têm metade do potencial das do Firefox. São muito mais limitadas pelo motor do browser.
E é por estas e por outras que a Mozilla faz um controlo muito apertado das extensões que tem na galeria oficial. O que estiver em experimental, só leva um scan anti virus e assim, mas tudo o que é aprovado é submetido a uma revisão muito apertada.
A Google ainda tem muito que andar para chegar ao ponto do addons.mozilla.org
Sempre tive aquele gostinho pelo Firefox, especialmente pelos seus addons.
Dizem que o Chrome é mais rápido e fiável… Até pode ser que seja verdade :b
Eu cá continuo com o Firefox, que com uns tweaks certeiros, ponhem-no a correr tão bem ou melhor que o Chrome.
Todos os browsers são vulneráveis, especialmente quanto mais crescem (e não falo de marketshare).
Porque com a evolução dos mesmos, são adicionados milhares de novas linhas de códigos e códigos…bis .. bis… o que acontece é que aumenta consideravelmente o numero de exploits(bugs) possíveis, e esse crescimento é perfeitamente natural, uma vez que os browsers estão sempre em constante adaptação aos requisitos do clientes. Resolve-se uns bugs daqui, aparecem outros aculá… e será sempre assim.. nunca atingem o pico de segurança a 100%, porque não se esqueçam, eles são a “janela” que nos faz entrar na Web….
O que faz aumentar a fasquia de exploits?
Extensões e especialmente Plugins (ex. Quicktime plugin tinha inumeros exploits e Plugin Flash, o recordista)
Resumindo, sempre que o browser(ou sistema operativo) pedir uma actualização, não deixem para amanhã.. façam logo.
Plugins… igualmente. Extensões, igualmente.
Manter-se sempre actualizado é meio caminho andado para roçar os 99% de segurança. Coisa que infelizmente é ignorado por uma vasta maioria de utilizadores.
Isto não é nenhum exploit, custa a perceber?
A funcionalidade explorada é util para extensões que desejam salvar os login/senha para auto preenchimento. Não é um real problema de segurança no aplicativo, e sim de engenharia social. Retirando esta funcionalidade complicaria vários plugins.
Claro que é possivel criar uma camada de encriptação através do Chrome para acessar os campos do tipo password, assim qualquer extensão que requisitar terá os dados encriptados por uma chave mestra, e assim que ele reenviar a desencriptação de memória é realizado. Também é possivel o chrome salvar esses dados em um outro lugar e apenas passar a referencia as extensões. Bem, inumeras soluções para resolver esse problema de segurança.
Para conseguir o mesmo no Firefox pode-se usar um script para a extensao Greasemonkey, ou mesmo uma extensao para o mesmo. O funcionamento do Greasemonkey e a parte das extensoes que o exploit usa no Chrome sao equivalentes. No inicio da implementacao das extensoes no Chrome, comecou-se por dar suporte a scripts do Greasemonkey para funcionarem no Chrome. Depois a Google foi aumentando as permissoes e criando API para as extensoes.
Em todo o caso, nao e’ uma falha de seguranca, como alguns ja’ referiam aqui. No entanto, pode ser que a Google inclua novas regras para impedir que tal aconteca, ou para minimiza-las. Por exemplo, restringindo acesso (acessos apenas permitidos dentro do mesmo dominio) ou pedindo permissao ao utilizador antes de deixar que se ligue a um servidor que esteja fora do dominio em que o script foi executado, principalmente se usar-se “http://*/*”. Isto nao impede que o malware envie a mesma informacao para o site malicioso ou email. Mas podera’ minimizar.
E o que o Andreas Grech referiu nao e’ nada de novo. A unica novidade e’ funcionar no Google Chrome.
“Talvez seja por isso, que a Firefox sempre apostou numa linguagem própria (o XUL),”
O XUL (XML User interface Language) define as regras para usar janelas, menus, toolbar e outros elementos usando a linguagem XML (algo equivalente a HTML). Faz uso de CSS para definir os “style” (cor, background, margin, etc) dos elementos, com as vantagens que essa linguagem disponibiliza para HTML. Para a parte interactiva, usa-se… Javascript. O que tem a mais sao os APIs que apenas funcionam se o codigo for executado dentro do contexto do XUL, caso contrario falham.
As extensoes do Google Chrome sao escritas usando json, HTML, CSS e Javascript. No caso do exploit apenas javascript, que tem acesso ao HTML/DOM da pagina em que foi inserido. Se nao tivesse, qual seria o objectivo de implementar essa funcionalidade nas extensoes?
O facto de ser mais facil de aprender uma linguagem e’ irrelevante. O contexto em que javascript de um site, da extensao, de outros site que foram incluidos atraves de um iframe, sao todos diferentes. A extensao pode ter acesso a tudo (DOM dos sites e JS), o inverso e’ que e’ grave.
Portanto, nao existe nenhuma vantagem, nem o seu uso faz com que o “exploit” em causa deixe de existir. A razao para o Firefox usar XUL nao e’ definitivamente para evitar problemas destes.
“demonstra que nesta particular funcionalidade a Google não tem a experiencia da Mozilla e que tem muito ainda um longo caminho a percorrer em aperfeiçoar o frágil sistema de extensões do Chrome.”
Esta’ ciente que grande parte dos programadores do Google Chrome trabalharam para a Mozilla? Acho que o pessoal pensa que quando uma empresa se empenha num projecto coloca sempre alguem sem nenhum conhecimento sobre o assunto. Isso e’ muito errado. Quando a Google (ou Apple, Microsoft, Mozilla, …) compra uma empresa, muita das vezes nao estao apenas interessados no produto que estes vendem/produzem; querem e’ o know-how dos programadores, que e’ muito mais valiosa do que o produto em si. Porque se tiverem de dar esse software a outros, vao demorar meses ate’ estes perceberem a logica e conseguirem fazer as alteracoes que possam interessar ‘a empresa. Isto significa tempo, e tempo e’ dinheiro. Enquanto que os programadores originais facilmente conseguem iniciar um projecto novo, sabem os problemas que tiveram, o que funciona melhor, e talvez, no mesmo tempo que um grupo a iniciar, acabam por ter um produto ainda melhor.
Em relacao ‘a seguranca no Google Chrome, isto mostra de certa forma que alguns ficam picados com essa referencia. No entanto, ainda nao vi ninguem a mostrar uma falha nas medidas de seguranca implementadas no Chrome. E esta nao e’. Mesmo quando (e’ tudo uma questao de tempo) alguem conseguir encontrar uma falha, isso nao significa o fim da seguranca, eles vao corrigir, aprender com a falha, e melhorar.
Fiquem Bem!
“Mas há medida que tem registado” –> mas à medida* sff
Mais tarde ou mais cedo seriam descobertas falhas destas no chrome também, como seria de esperar
Não culpo a Google, instalam os plugins porque querem e são avisados que pode ser malicioso 😉
O seguinte link mostra que tambem pode acontecer com as extensoes/addon no Firefox.
“Detalhes do ‘Mozilla’ Sniffer e como foi encontrado”
http://news.netcraft.com/archives/2010/07/15/firefox-security-test-add-on-was-backdoored.html
“Anuncio dos dois addons maliciosos”
“http://blog.mozilla.com/addons/2010/07/13/add-on-security-announcement/
Isto nao significa que devem largar imediatamente o Firefox. Codigo benefico e malicioso muita das vezes apenas diferem nas intensoes. Falhas, encontram-se e corrigem-se. Apenas nao tenham a ilusao que o mesmo nao acontece com o Firefox, ou qualquer outro browser que implemente extensoes.
A Mozilla foi rapida a retirar os addons e tomar as medidas necessarias. As regras para submeter addons talvez sejam ainda mais apertadas. No que toca ao browser em si, pouco podem fazer. As solucoes resumem-se a retirar funcionalidades ou aumentar autorizacoes antes dos addons poderem fazer determinadas accoes. Esta ultima, nao significa que alguem nao consiga usar ‘social engeneering’ para passar essas restriccoes.
“New Proposal for Review Process & Delightful Add-ons”
https://forums.addons.mozilla.org/viewtopic.php?f=19&t=1134&p=3158
PS: O Mozilla Firefox e o Google Chrome continuam a ser os meus dois browsers favoritos.
Fiquem Bem!
A propósito, uso há pouco tempo o Chrome e após ter instalado meia dúzia de extensões agora não consigo instalar mais.
Por exemplo, quero instalar o Jdownloader e quando clico no botão “Instalar” não acontece nada.
Alguma sugestão ?
Obg 😉