Malware em Java tem como alvos computadores Windows, Linux e Mac
A possibilidade de execução de código a partir de uma página web pode ter consequências graves, e neste caso o desktop Linux é um dos alvos e pode ser atingido, colocando seu computador sob o controle de uma central externa. Cuidado ao visitar sites que ofereçam execução de aplicativos sem que você tenha plena confiança na origem!
Via idgnow.uol.com.br:
De acordo com pesquisadores em segurança da F-Secure e da Kaspersky Lab, uma nova ameaça de engenharia social utiliza um aplicativo em Java para atacar computadores Windows, Linux e Mac.
Segundo um post do analista-sênior da F-Secure, Karmina Aquino, o ataque foi detectado em um site da Colômbia. Quando os usuários o visitavam, era solicitado executar um aplicativo em Java que não continha qualquer certificado autenticado.
Dada a permissão, o aplicativo verifica qual o sistema operacional do usuário – Windows, Mac OS ou Linux – e injeta um arquivo binário malicioso correspondente.
Os arquivos foram detectados pela F-Secure como “Backdoor:OSX/GetShell.A”, “Backdoor:Linux/GetShell.A” e “Backdoor:W32/GetShell.A”. Eles têm como objetivo fazer uma conexão com um servidor de comando e controle (C&C) e procurar outros códigos maliciosos para serem baixados e executados.
No entanto, desde que pesquisadores da F-Secure começaram a monitorar o ataque, o servidor de controle remoto não liberou códigos adicionais, segundo Aquino.
@brlinuxblog
Feed RSS
Muito democrático esse vírus.
Como isso funciona?
Tanto no Linux quanto no Mac, vc pode até fazer o download do arquivo, mas dai executá-lo é outra estória. Outra coisa, tanto num sistema como no outro, para isso funcionar é necessário acesso de root. O script solicita essa senha? Porque quando tem algo para ser executado no computador, aparece uma janelinha perguntando se pode executar o script, mas não pede senha de root. Se pedir, poxa, tem que ser otário para fornecer.
A Apple está dando um jeito nesse tipo de ataque com a implementação do KeepGate, o sistema de sandbox do Mac.
Eu fiquei curioso para saber como esse vírus funciona. Vou ver se acho algo na net.
Seria bom confirmar se a falha afeta somente a Máquina Virtual da Oracle (incluindo a OpenJDK), ou se isso ocorre também com outras versões da MV Java.
“era solicitado executar um aplicativo em Java que não continha qualquer certificado autenticado”
E os usuários executaram o aplicativo desconhecido e não certificado por livre e espontânea vontade. Tá explicado. Nem pode ser descrito como malware: é apenas um programa que por sua vez injeta um trojan.
O método de infecção não é virótico. É engenharia social e não há nada técnico que possa ser feito para proteger o usuário a não ser a informação (e o bom senso, se a informação falhar).
@Tércio, esse tipo de falha “entre a cadeira e o teclado” vai afetar qualquer versão de Java ou de outra linguagem qualquer. Vc poderia usar qualquer tipo de tecnologia que permita copiar um arquivo para a máquina local.
Pelo que eu sei, Java não permite normalmente isso, pede confirmação do usuário ou verifica certificado digital. Mas se o usuário deu todas as permissões necessárias, babou: o programa vai fazer o que bem quiser.
Acho que devem ser feitos alguns avanços na questão de segurança, mesmo no Linux. O argumento de que o problema esta entre o teclado e a cadeira, pode até ser verdadeiro, mas não deve ser uma desculpa para não fazer nada. Implementar um sistema de SandBox, algo como o projeto Qubes propôs no meu ver é urgente nas distros atuais.
@Artus, segundo o que pesquisei, aplicações java na web já tem sandbox, ainda que o SO que as executa não tenha.
Parece que o que aconteceu é que foi solicitado ao usuário permissão para ignorá-la, e ele concedeu essa permissão.
Computadores e sistemas são feitos para servir e obedecer ao usuário. Se o usuário opta por não se proteger, não há nada que esses sistemas possam fazer a respeito.
@Tiago,
“vc pode até fazer o download do arquivo, mas dai executá-lo é outra estória.”
O vetor de infecção é uma applet Java. O próprio navegador faz o download e executa ao entrar na página.
“Outra coisa, tanto num sistema como no outro, para isso funcionar é necessário acesso de root.”
Por que seria necessário acesso ao root? O objetivo desse malware não é destruir o seu sistema por completo (rm -rf /), mas sim roubar informações, aproveitar o processamento da máquina como parte de uma botnet, ser utilizado como intermediário de outros ataques, etc. Nenhuma dessas tarefas depende do acesso como root.
@Porfírio,
“segundo o que pesquisei, aplicações java na web já tem sandbox, ainda que o SO que as executa não tenha.”
O que o Java tem não é exatamente um sandbox, mas sim um sistema de permissões. Para acessar o sistema de arquivos, utilizar sockets, ou outras tarefas consideradas “perigosas”, a applet precisa ser assinada com uma chave, que pode ser assinada com um certificado válido ou não (self-signed), e quando é aberta o plugin Java mostra uma mensagem dizendo quem criou aquela applet (com base na assinatura) e perguntando se o usuário confia na fonte. No caso do malware aparentemente o certificado era self-signed.
Agora imagine que em vez de pedir permissão ao usuário, a applet explorasse uma falha do Java para evadir o sistema de permissões. Esse tipo de falha já aconteceu dezenas de vezes no passado, e as atualizações do Java contra essas falhas não vinham tão rápido como deveriam. Se fosse esse o caso, o usuário estaria completamente comprometido, porque o Linux não tem sistema de sandbox.
Dou toda a razão ao que o @Artus falou. O sistema de segurança que as distribuições Linux desktop usam é arcaico e está ultrapassado para os dias atuais. Não tem como exigir que o usuário confie na origem de todos os aplicativos que ele executa, muito menos que ele confie que nenhum desses aplicativos tenham falhas acidentais. Qualquer exploit contra algum dos aplicativos é suficiente para comprometer completamente todos os dados e a segurança do usuário. O ideal seria que existisse pelo menos uma isolação entre aplicativos diferentes.
Até o Android tem uma segurança melhor que o Linux desktop nesse sentido, porque ele cria um usuário diferente no sistema para cada aplicativo, além de mostrar uma lista explícita de permissões que o programa pede. Assim, para ter acesso a dados de outros aplicativos sem que o usuário saiba, só se aproveitando de falhas do kernel que permitam obter root.
O Qubes tem uma proposta interessante e é bem isolado por utilizar uma instância Xen diferente para cada aplicativo (que protege inclusive de alguns tipos de falhas que possam existir no kernel), porém perde muito desempenho, principalmente em vídeo, porque ele precisa fazer framebuffer em software para conseguir isolar completamente as instâncias.
O problema do java no linux é que se a pessoa estiver usando a jvm da Sun/Oracle, não é possível atualizar facilmente, já que a maldita licença não permite que as distribuições empacotem e coloquem nos seus repositórios e também não tem um mecanismo próprio e fácil de atualização do java como acontece no windows p.ex.
Muitas vezes é preciso instalar o java da Sun/Oracle porque muitos sistemas e sites, especialmente os governamentais e de bancos, não funciona perfeitamente com o openjdk ou gcj.
Por isso gosto do iOS.
O usuário só executa o que a Apple permite.
Não existe modelo mais seguro para o usuário comum.
“Agora imagine que em vez de pedir permissão ao usuário, a applet explorasse uma falha do Java para evadir o sistema de permissões”
De acordo com as informações a respeito deste malware em particular, não foi o que aconteceu. Caso fosse esse o problema, reparar a falha estaria correto, como já foi feito “dezenas de vezes no passado”. E isso seria muito bom, porque a falha teria conserto.
Certificado auto-assinado dispara um alerta e exige permissão do usuário. Isso ocorre o tempo todo nas aplicações de homologação daqui.
Tem uma tecnologia do java que usamos aqui chamada JWS, com um sistema de segurança superior a applets. Um sistema feito com ela só acessa a máquina cliente mediante serviços, e as permissões são apresentadas ao usuário de forma muito parecida ao Android.
O GNU/Linux poderia se beneficiar com melhores mecanismos de segurança? Sim. Até existem algumas distros para servidores com alguns produtos interessantes, como honeypots (contra vírus) ou algoritmos bayesianos (analisam mudanças tráfego de rede e podem encontrar trojans). Um desktop poderia se beneficiar de um modelo de segurança mais apertado? Sim.
Mas essas tecnologias são “a prova de usuário”? Não. Educar o usuário é fundamental.
Isso também significa que o GNU/Linux hoje é inseguro? Não.
É risível e muito infeliz saber que tem gente com atitudes como a do @Beto, que vende a sua liberdade e aceita ser limitado pela vontade de uma empresa. Transportando essa atitude para o mundo real… Vcs podem imaginar.
Minha posição é: Sistemas seguros que não se permitam enganar. Usuários seguros que não se permitam enganar. Apenas isso é segurança de verdade.
Apesar de que muitos disseram que até o Linux precisa de um sistema de segurança maior e que até o Android tem um esquema melhor criando usuários para cada aplciativos, quanto ao que este vírus utiliza nada adianta. A única solução seria o modelo adotado pela Apple(não defendendo-o, não gosto do modelo dessa empresa. Mas eu tenho conhecimentos técnicos suficientes que faça com que esse modelo seja completamente desnecessário): Todos os programas passam por um mesmo orgão fiscalizador, a Apple, e o que não estiver de acordo não estra no market. Mas é claro que você pode realizar o jailbreak e ficar livre para instalar programs de outras fontes. Mas você faz isso pelo seu próprio risco. E com esse applet é a mesma coisa: Ele pergunta se ele pode copiar arquivos para seu computador e você, claro que lendo todos os detalhes desse aviso, permite. E todas as outras permissões que ele pedir você dará de livre e espontânea vontade. Pronto, você está infectado. Acho que nunca um applet deveria ter a permissão(nem perguntando antes) de alterar o esquema de permissões de um diretório ou de um arquivo. Mas isso só resolveria o problema de execuções no linux e no mac mas ainda continuaria podendo copiar arquivos de e para o seu computador.
Só há uma solução definitiva, e dúvido muito que ela venha a ser aplicada. Assim como não se dirige um carro sem uma licença que diga que a pessoa está apta para a tarefa, também existiria ma carteira para operar computadores. Assim acabariam com os problemas de muitos que trabalham com informática. Existiria carteiras para diersos níveis: operador office, mantenedor, programador, analista, desenhista CAD…
@Porfírio
“Minha posição é: Sistemas seguros que não se permitam enganar. Usuários seguros que não se permitam enganar. Apenas isso é segurança de verdade.”
Perfeito!
Plugin java no firefox tá bloqueado desde abril :
https://addons.mozilla.org/en-US/firefox/blocked/
Computador deve ser só um eletrodoméstico.
Simples e seguro.
Só a Apple caminha nesse sentido.
Usuário comum não quer hackear um eletrodoméstico, só quer que ele funcione.
Apple está dominando geral.
Qualidade inigualável.
http://youtu.be/A7HVt3xgTn4
Concordo que o desempenho d Qubes seja muito comprometido, acho que algo semelhante utilizando LXC/cgroups seria mais viavel, apesar de menos isolado.
Sobre a politica da Apple de permitir instalar apenas oque é verificado, essa politica é equivalente a instalar apenas pacotes através do repositório de uma boa distro como os repos do Debian. Mas acredito que oque ocorre neste caso foje destes controles em ambos os casos.
Verdade, essa idéia arcaica de que linux é seguro porque tem um sistema de permissoes de arquivos é mto igual ao windows, que tambem tem um sistema de permissoes de arquivos. Aliás, será que ninguem nunca ouviu falar em escalada de processos no linux, com usuário guest e que tenha shell bin/false e home /dev/null ?
@MarianaBers: ” Aliás, será que ninguem nunca ouviu falar em escalada de processos no linux, com usuário guest e que tenha shell bin/false e home /dev/null ?”
se for este o problema é só desabilitar o usuário guest
@MarianaBers, ocorre que no Windows normalmente quem está operando é administrador da máquina, já num desktop GNU/Linux o operador é normalmente um usuário comum. Então é mais fácil para um programador de malware, produzi-los para atacar máquinas Windows, pois não precisará lidar com malabarismos para alterar pastas do sistema, e normalmente ele quer alterar arquivos do sistema, seja para se instalar e garantir que será executado depois de um boot, ou abrir portas para outros ataques.
Já no GNU/Linux o tal programador terá que descobrir esquemas para escalação de privilégio, para poder ter o controle total do sistema.
É claro que sempre vai existir uma falha ou outra que permita escalada de privilégio, só que isso é um bug, algo que não deveria acontecer e que será concertado. Daí o método de obter uma escalada, será sempre diferente ao longo do tempo, pois as portas antigas serão sempre fechadas.
@Todos, o SELinux é um esquema que permite limitar a ação de processos, creio que possa caracterizá-lo como uma sandbox. É claro que para limitar a ação de um processo é necessário conhecê-lo, saber onde ele normalmente escreve, onde ele normalmente lê, daí é fácil limitá-lo em suas ações, mesmo que ele tenha as permissões no sistema de arquivos terá que se submeter ao comportamento padrão que a distro definir para ele.
Creio que seja um bom esquema de segurança para um servidor, mas que precisa evoluir mais na área de desktop, talvez seja necessário torná-lo mais fácil de lidar, com ferramentas, pois creio que a maioria dos admins quando descobre que o SELinux está enchendo muito o saco, resolve desabilitá-lo, ao invés de descobrir como adequar o programa que quer rodar ao SELinux. Programa esse que não vem do repositório padrão da distro, pois se viesse já estaria com uma política bem definida.
De qq forma creio que na área de desktop deva se pensar em mais esquemas de proteção dos dados do usuário.
Galera, o sistema da apple também é afetado por essa praga virtual. Nem a tal “superioridade” da apple foi capaz de detê-lo. Ainda penso que o USUÁRIO é a maior ameaça a segurança de um sistema.
Bom dia pessoALL;
Seguinte, nas distribuições OpenSuse e Suse Enterprise existe um serviço que isola as aplicações (tem que configurar as aplicações individualmente) do resto do sistema chamado AppArmor.
Vale a penas estudar esse AppArmor.
Abraços.
É aqui neste caso qualquer isolamento não é capaz de deter este programa(que nem sei se pode ser considerado um vírus, mas apenas um simples programa). Não importa se foi Linux, Windows ou Mac. Não importa se tinha sandbox ou outro esquema de limitações. O programa perguntou se quer desabilitar tal proteção do sandbox, o usuário disse que sim e pronto. Pode ter qualquer proteção, se o usuário puder desativá-la e o programa perguntar se quer que desative o programa poderá fazer o que quiser. O usuário deixou mesmo.
Nem o esquema da Apple é capaz de barrar isso. O único jeito é tirando a liberdade do usuário de desligar as proteções.
@alguem, Não estamos falando do caso desse programa, estamos puxando o gancho para discutir como a segurança das distribuições Linux no desktop tem que evoluir.
@Xinuo,
“Então é mais fácil para um programador de malware, produzi-los para atacar máquinas Windows, pois não precisará lidar com malabarismos para alterar pastas do sistema, e normalmente ele quer alterar arquivos do sistema, seja para se instalar e garantir que será executado depois de um boot, ou abrir portas para outros ataques.”
Não é necessário privilégio de root para se instalar e garantir que será executado depois de um boot. Existem diversas formas de fazer isso. O malware pode se instalar no diretório home do usuário. Todo ambiente desktop tem um mecanismo de autostart que é configurável pelo próprio usuário (em arquivos de configuração existentes dentro da home). É possível também modificar arquivos da home de forma a fazer com que o malware seja ativado sempre que o usuário abrir um terminal ou o navegador web.
E mesmo que isso fosse possível, se o malware simplesmente copiasse todos os dados do usuário e enviasse para seu autor, já seria um tremendo estrago.
O sistema de permissões/usuários do Linux por si só (do jeito que é usado nas distribuições hoje) não oferece nenhuma proteção a mais que o equivalente no Windows. Tudo bem que no Windows os usuários tem a péssima mania de usar a máquina como administrador, mas devido a isso eles criaram no Windows 7 um esquema de privilégio em dois níveis, no qual um programa para efetivamente usar os privilégios de administrador tem que mostrar uma caixa de confirmação para o usuário.
O SELinux e o AppArmor até oferecem uma proteção a mais, mas eles não impedem uma ação maliciosa, apenas dificultam o desenvolvimento dos malwares. Um desenvolvedor de malwares, com conhecimento das regras que podem estar presentes no SELinux ou AppArmor do sistema alvo, pode facilmente desenvolver o malware de forma a não disparar essas regras (imitando comportamentos comuns do programa, o que em um navegador por exemplo é muito fácil). É a mesma questão dos antivírus. Antivírus protege contra vírus? Somente contra os conhecidos. O desenvolvedor de malware sempre vai testar seu novo malware em todos os antivírus para garantir que, pelo menos no momento que ele foi lançado, ele não será detectado por nenhum. A questão do SELinux e AppArmor é a mesma. Não é uma arquitetura segura-por-construção. É um remendo em cima de uma arquitetura insegura.