Quando o Windows era mais suscetível a vírus e outros tipos de malware, ter um antivírus instalado era imprescindível. A primeira característica analisada era a eficiência dos algoritmos de detecção e heurística, mas outro fator também “pesava”: o impacto do monitoramento em tempo real no desempenho do computador.
O equilíbrio entre proteção e transparência é uma das metas mais difíceis de se alcançar quando se fala em segurança digital, especialmente para consumidores domésticos. O desafio não é tornar um sistema seguro, mas alcançar isso sem comprometer muito a experiência de uso.
Em dispositivos móveis isso também é válido, embora o dilema tenha outro foco. Pela sua característica nata, a mobilidade, perdas e roubos são merecedores de maior atenção. O mecanismo mais básico e um dos mais eficientes para minimizar danos em casos imprevistos é o código de bloqueio da tela — numérico, alfanumérico ou por padrão. (mais…)
A RSA Data Security emitiu alerta sobre um malware chamado Bolware.
Segundo a investigação, que é conduzida pela Polícia Federal do Brasil e o FBI, o Bolware pode ter comprometido quase meio milhão de boletos e gerado prejuízo na casa dos R$ 8,57 bilhões. Além de fraudar esses documentos, o malware ainda captura credenciais usadas para acessar sites. A RSA diz ter detectado quase 200 mil instâncias do Bolware em diferentes IPs, todos rodando Windows.
Em pauta está o “boleto” (oficialmente “Boleto Bancario”), um método de pagamento popular no Brasil que é usado por consumidores e a maioria dos pagamentos B2B. Os brasileiros podem usar boletos para completar compras online através do site do seu banco, mas diferentemente de pagamentos com cartão de crédito — que podem ser contestados e revertidos –, os feitos via boletos não estão sujeitos a cobranças e só podem ser reembolsados via transferência bancária.
Enquanto os culpados não são identificados e o esquema, derrubado, a RSA recomenda a utilização de apps móveis para realizar o pagamento através da leitura do código de barras. O método usado pelo Bolware para comprometer boletos consiste em trocar o código numérico na hora do pagamento, mas ele é incapaz de modificar o código de barras.
Outra saída, essa indicada pela FEBABRAN, é recorrer ao DDA, ou débito direto autorizado. Nunca tinha ouvido falar disso. Parece uma boa, mas este site horrendo que explica o sistema com uma animação tosca feita em Flash não é o tipo de coisa que transmite segurança.
Falhas de segurança em sistemas computacionais são, infelizmente, comuns. Mesmo com todo o aparato técnico e organizacional de que dispomos para programar sistemas, o elo fraco (nós, humanos) ainda existe e por isso, como em tudo que tocamos, a programação também é suscetível a falhas.
Normalmente correções de bugs se limitam a ganhar uma linha no changelog de uma aplicação. São quase sempre ignoradas; se muito, xingadas por nos obrigar a instalar uma nova atualização — mais ainda quando é preciso reiniciar o sistema inteiro, né Windows? Só que, às vezes, uma falha é tão grave, tão impactante, que quebra algumas barreiras e chega até aos ouvidos de quem não se liga muito em tecnologia. Foi assim com o bug do milênio e parece que é o caso do Heartbleed, uma grave falha no OpenSSL divulgada essa semana por pesquisadores da Codenomicon e do Google.
O que é essa falha? Como ela te afeta? Por que está todo mundo tão preocupado com ela? Após ler um punhado de artigos sobre o assunto, este vai ao ar com a missão de responder essas perguntas da forma mais didática e completa possível.
O básico de criptografia, SSL e OpenSSL
Você já deve ter ouvido algum especialista em segurança dizendo para prestar atenção na barra de endereços do navegador quando estiver fazendo alguma transação via Internet. Nesses casos, ela deve apresentar um cadeado e ter um “https” no início do endereço, como nesta imagem:
Este site é seguro!
Esses dois detalhes indicam sessões seguras, protegidas pelo protocolo SSL (Secure Socket Layer) ou TLS (Transport Layer Security). Esses dois criptografam a troca de dados entre cliente (você) e servidor (site, servidor de e-mail, bate-papo, VPN), o que impede que um terceiro leia o conteúdo que transita entre essas duas pontas. Ainda que ele consiga acesso aos dados, tudo o que esse cara terá nas mãos será um punhado de caracteres que não fazem sentido algum. Isso é, resumidamente, criptografia: sem as chaves que descriptografam o conteúdo, é impossível lê-lo.
SSL e TSL são usados desde a década de 1990 e padrões para aplicações sensíveis na Internet. Por “aplicações sensíveis”, leia-se qualquer informação que na posse de alguém mal intencionado consiga causar danos. Informações como senhas e números de cartão de crédito, por exemplo, e coisas mais triviais, como alguns sistemas de bate-papo baseados no protocolo XMPP e e-mails (protocolos SMTP, POP e IMAP).
Existem várias bibliotecas SSL/TLS usadas em servidores, todas com a mesma finalidade. O OpenSSL é uma das mais populares por ser aberto e gratuito — é aqui, aliás, nos bastidores da Internet que o software livre é largamente usado. Servidores populares, como Apache e nginx, que juntos respondem por 2/3 dos sites existentes, utilizam o OpenSSL. Qualquer problema nesse, pois, é automaticamente de grandes proporções. Serviços e sites pequenos e gigantes confiam no OpenSSL para blindar conexões seguras.
O que nos leva ao Heartbleed.
O que é o Heartbleed?
A falha descoberta no OpenSSL ganhou esse nome porque é explorada a partir de uma extensão chamada “hearbeat” (batimento cardíaco, em inglês): quando está se comunicando com um servidor via conexão segura, o cliente manda “batidas” constantes apenas para se certificar que a comunicação está ativa, que ela não caiu, e continuar trocando informações.
Com algum conhecimento, uma pessoa mal intencionada de olho em um servidor comprometido pela falha pode utilizar-se dessa extensão para obter respostas do servidor. A cada “batida”, ele consegue 64 Kb de informações — ocorre, pois, um vazamento de memória, um “sangramento no coração”. Parece e é, de fato, pouca coisa, mas o processo pode ser repetido indefinidamente e, com isso, formar porções mais suculentas de informações. Essas, que em um cenário ideal seriam indecifráveis, pelo Heartbleed chegam de forma bastante legível a quem as requisitou.
Com isso dá para pescar entre um monte de caracteres inúteis coisas valiosas, como as já mencionadas senhas e números de cartão de crédito. Existe, porém, algo ainda mais cobiçado: os certificados de segurança dos servidores.
Usando outra analogia, os certificados funcionam como se fossem as chaves para decifrar o conteúdo enviado pelo cliente (você) que fica embaralhado durante o transporte graças ao SSL/TLS. Quem explora o Heartbleed tem grandes chances de localizar o certificado naqueles blocos de 64 Kb. Esses pequenos pedaços de dados vêm da RAM, a memória volátil que o servidor (qualquer computador, na realidade) usa para alocar dados temporariamente, aqueles estão sendo usados no momento. Como um servidor que lida com senhas e informações sensíveis sempre recorre ao SSL/TLS, os certificados recorrentemente aparecem na RAM.
O certificado permite ler qualquer conteúdo interceptado no passado e que porventura venha a ser obtido futuramente, desde que as chaves criptográficas não sejam alteradas no servidor (mais sobre isso abaixo). Não só: ele também pode ser muito útil para scams, ataques em que um site falso se passa pelo original para obter dados dos usuários.
Como me protejo disso?
Os pesquisadores que identificaram o Heartbleed comunicaram o pessoal do OpenSSL antes de divulgar o problema. Isso deu tempo para desenvolver patches (correções) para as principais distribuições Linux. Espera-se, agora, que os serviços de hospedagem e grandes sites apliquem essa correção, como muitas já fizeram — o Yahoo, que ganhou destaque por ter vários logins e senhas de e-mail vazados logo após a divulgação da Heartbleed, afirma já ter tapado o buraco nos seus principais sites e que o trabalho em suas propriedades menores está em andamento.
E eu e você, o que podemos fazer? A princípio, quase nada. Depois que um dado site tiver sanado a falha, trocar a senha é uma boa ideia. Mas pode não ser suficiente, se alguém tiver obtido com sucesso aquele certificado. Aqui entra o segundo passo que os responsáveis por esses serviços que usam o OpenSSL deveriam tomar: atualizar os certificados. O problema? É um processo lento e, em muitos casos, custoso. Alguns analistas estimam que as consequências do Heartbleed reverberarão daqui a um ano…
Não dá para saber quando a falha no OpenSSL é explorada, o ataque não deixa rastros e é transparente para usuário e servidor. Pior: ela existe desde dezembro de 2011 e ninguém garante que tenha passado despercebida nesse meio tempo. Pensar no cenário mais grave é o ideal na hora de remediar casos graves como esse, mas nem sempre o comedimento ganha a queda de braço com o financeiro. É de se esperar que Facebook, Google e Yahoo, bem como serviços que provêm infraestrutura para outros, como Amazon e Heroku, façam todo o possível para evitar o pior, mas e a hospedagem de US$ 5/mês? E aquele site novo, semi-desconhecido, que cumpre uma função no seu trabalho ou para você mesmo?
É difícil abordar o assunto sem soar alarmista, embora talvez seja o caso. Ao The Verge, Nicholas Weaver, pesquisador de segurança da ICSI, disse que o Heartbleed “é catastroficamente ruim, simplesmente um bug incrivelmente danoso”. No blog do Tor Project, a recomendação é de que “se você precisa muito de anonimato ou privacidade na Internet, talvez seja desejável ficar completamente fora dela pelos próximos dias, até que as coisas se ajeitem”. Eles oferecem um navegador que se gaba de não deixar rastros de navegação.
Esta ferramenta indica, de forma nem sempre confiável (há falsos-positivos), que sites ainda não corrigiram o OpenSSL. O LastPass, um gerenciador de senhas, colocou no ar outra semelhante. Na nossa ponta, na condição de usuários, o máximo que dá para fazer é esperar e ter cautela relação aos sites que visitamos e como os acessamos.
***
Os textos abaixo serviram de base para o que você leu acima e são úteis para aprofundar a leitura:
The Heartbleed Bug. Página explicativa criada pelos pesquisadores que descobriram a falha.
Um smartphone moderno é composto por um punhado de sensores, módulos e recursos. É esse arsenal que faz com que ele seja tão versátil, tão útil no dia a dia. Os desenvolvedores podem utilizar essa gama de poderes para facilitar ou mesmo viabilizar o funcionamento dos seus apps. Só que é como dizia o tio de um super-herói: com grandes poderes vêm grandes responsabilidades. Você presta atenção nas permissões que os apps exigem antes de instalá-los?
A Tatiana contou, na Galileu, os motivos que a levaram a desinstalar o app do Facebook em seu smartphone Android: o excesso de permissões que o app pede para ser instalado. Como ela nota, algumas fazem sentido, outras soam estranhas mesmo sob a bandeira da comodidade.
Todo smartphone vendido atualmente conta com um sistema de permissão destinado aos apps. Como eles funcionam em sandboxes, ou seja, isolados entre eles e do sistema, as permissões funcionam como um contraponto de flexibilidade nessa estrutura orientada à segurança, como pontes seguras entre os apps e os recursos que o smartphone tem.
Por padrão o sistema operacional bloqueia acesso a esses recursos em prol da segurança. Um app, para usufruir desses recursos, precisa declarar explicitamente quais são necessários e apenas com a anuência do usuário as portas virtuais que os guardam são abertas.
Nós temos a chave, mas somos proprietários displicentes. Raramente atentamos para as permissões que um app pede e, nessa, acabamos abrindo a porta de casa para qualquer um. Um jogo gratuito precisa mesmo saber a minha localização? Por que uma rede social quer saber meu histórico de ligações, ou ficar aberta o tempo todo em segundo plano? E esse app de piadas, quer minha lista de contatos para quê?
Abaixo, faço um passeio pelos sistemas de permissões das três principais plataformas móveis: Android, Windows Phone e iOS.
No Android, é tudo ou nada
Ao instalar um app no Android, o Google Play exige confirmação para as permissões que ele pede. Surge uma lista delas na tela com um botão de confirmação embaixo. Clique nele e o app é instalado; discorde e você volta para a Play Store, sem o app.
Ou você aceita tudo e recebe o app, ou cancela a instalação.
Essa abordagem é oito ou oitenta, não há meio termo do tipo “ok, app, você pode saber a minha localização e acessar as fotos do celular, mas nada de ler meus contatos”. Alguns apps até permitem configurações granulares de permissões após a instalação — no Facebook, talvez o exemplo-mor de app que extrapola nesse ponto, dá para deixar a localização desativada por padrão, por exemplo. No geral, porém, é aquela abordagem rígida do aceite total que vale.
Abordagem que, claro, não é a ideal, mas que tem sua validade. Dependendo do app e do que ele pede, é melhor deixá-lo de lado — em muitos casos é de se pensar se o risco vale a pena. Existem aqueles chatos, mas mais amenos, em que você verá propagandas assustadoramente precisas, de anunciantes próximos, graças à concessão da sua localização via GPS. Outros são mais graves; você pode acabar vítima de um golpe, como o do Balloon Pop 2 que sequestrava conversas no WhatsApp para revendê-las depois.
O Android carece, ainda, de uma central de privacidade. O recurso fez uma rápida aparição na versão 4.3: o App Ops abria todas as permissões de cada app instalado e permitia revogá-las individualmente. Era preciso usar algum programa que criava a interface para o App Ops, como o da Color Tiger1.
Screenshots: EFF/Reprodução.
Ele não durou muito. Na versão 4.4.2 o App Ops sumiu com a justificativa, do Google, de que sua aparição recente fora um descuido e que na prática trata-se de um recurso usado apenas internamente para testes. Triste, mas compreensível: muitos apps simplesmente “quebram” quando permissões vitais são revogadas.
O melhor a se fazer, por ora, é ficar atento às permissões na hora de instalar um app — e desistir ao menor sinal de desconfiança.
As permissões de apps são ainda piores no Windows Phone
No Windows Phone, requisitos dos apps são apresentados discretamente na Loja de Aplicativos.
No Windows Phone a situação é similar à do Android, com uma agravante: as permissões são listadas na Loja de Aplicativos, só que essa não pede confirmação do usuário na hora de instalar algum — com apenas uma exceção, a do acesso à localização.
A lista de permissões de um app fica soterrada na página “Detalhes” dele na loja de apps. Em texto puro, logo depois da descrição e entre links legais que recebem ainda menos atenção, o posicionamento ruim de informações tão importantes é preocupante. Elas deveriam estar em local mais acessível e ter mais destaque ali.
O mais triste é que nas configurações do sistema existe uma aba “Aplicativos” que, em vez de contemplar todos, fica restrita a alguns nativos, pré-instalados do sistema. A exceção é o item “Tarefas em segundo plano”, que lista apps capazes de rodar em segundo plano e permite revogar esse privilégio.
iOS: demorou, mas é assim que se faz
O iOS é o sistema que melhor lida com permissões de apps.
Não foi sempre assim. Antes do iOS 6, essa parte do sistema era um desastre. Foi preciso um escândalo envolvendo o app Path para que a Apple tomasse providências e desse a devida atenção às permissões dos apps.
No iOS, as permissões são concedidas durante o uso do app.
No começo de 2012 o app do Path foi flagrado enviando listas de contatos dos usuários para seus servidores sem notificá-los disso. Até então o iOS só informava e pedia autorização do usuário para o uso do sistema de notificações push e dos serviços de localização que um app porventura precisasse; todo o resto era concedido de pronto, sem aviso algum.
Com o estouro do caso Path, que repercutiu até no Congresso dos EUA, mudanças foram feitas no iOS 6. Além de notificações e localização, o sistema passou a regular outras permissões nos apps, a saber:
Contatos
Calendários
Lembretes
Fotos
Compartilhamento Bluetooth
Microfone
A App Store continua sem listas de permissões para os apps por lidar com elas de maneira diferente. Ao instalar um app de lá, ele não ganha acesso imediato às permissões de que precisa. É durante o uso que o usuário concede (ou não) as necessárias. O app vai perguntando na medida em que uma função que dependa de certa permissão é acionada e aí cabe ao usuário concedê-la ou não.
Não existe o risco de “quebrar” apps porque as diretrizes da App Store exigem que o desenvolvedor preveja comportamentos alternativos para quando certas permissões forem negadas. As notas de lançamento do iOS 6 para desenvolvedores esclarecem isso:
“Além dos dados de localização, o sistema agora pede permissão do usuário antes de liberar o acesso a apps terceiros a certos dados do usuário.
(…)
Para dados de contatos, calendários e lembretes, seu app precisa estar preparado para ter o acesso negado a esses itens e ajustar o comportamento de acordo. Se o usuário ainda não foi questionado sobre a liberação do acesso, a estrutura retornada é válida, mas não contém registros. Se o usuário negou o acesso, o app recebe um valor nulo ou nenhum dado. Se o usuário garantir permissão ao app, o sistema consequentemente notifica o app de que ele precisa ser reiniciado ou reveter os dados.”
No iOS, permissões são concedidas durante o uso dos apps e podem ser revogadas a qualquer momento.
Nas configurações do sistema existe, ainda, uma área chamada Privacidade. Ela concentra as permissões que o sistema oferece e dá ao usuário o poder de vetá-las, para qualquer app, a qualquer momento.
Permissões de apps são importantes
As permissões de apps são meio como a EULA do Windows, ou os termos de uso das redes sociais: a maioria aceita sem ler. Nem o fato de serem compostas por poucas linhas anima o usuário médio a prestar atenção nos privilégios que ele concede sempre que instala um app. O que é um perigo.
Este é um assunto importante. Ler aquelas poucas linhas e tentar entender por que um app pede certas permissões é um esforço válido. Na próxima vez que fizer uma parada no Google Play ou na Loja de Apps do Windows Phone, ou que um app no iOS começar a pedir muita coisa, abra de olho, questione.
A Color Tiger oferece, agora, o App Ops X. Ele não está disponível no Google Play porque o método de instalação viola as regras do Google — a saída, pois, é fazer sideloading do app. Os desenvolvedores garantem que o app funciona mesmo no Android 4.4.2 e prometem um futuro cheio de atualizações, integração com o Tasker, pré-configuração de permissões a serem desativadas de pronto e outras vantagens. Mais informações no Lifehacker. ↩︎
