Jump to content

Search the Community

Showing results for tags 'red team'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Supporter area
    • Tools of the Trade
    • Finance transparency
  • MBConf
    • MBConf v1
    • MBConf v2
    • MBConf v3
  • Mente Binária
    • General
    • Computer Architecture
    • Certifications
    • Quantum computing
    • Cryptography
    • Challenges and CTF
    • Hardware Hacking
    • Electronics
    • Conferences
    • Forensics
    • Games
    • Data privacy and laws
    • Code breaking
    • Networking
    • Pentest
    • Speak to us!
    • Software releases
  • Career
    • Study and profession
    • Jobs
  • Reverse Engineering
    • General
    • Malware Analysis
    • Firmware
    • Linux and UNIX-like
    • Windows
  • Programming
    • Assembly
    • C/C++
    • Python
    • Other languages
  • Operating Systems
    • GNU/Linux and UNIX-like
    • Windows
  • Segurança na Internet's Discussão

Categories

  • Portal Mente Binária
  • Specials

Categories

  • Tech basics
    • Text comprehension
    • English
    • Mathematics
  • Computing Basics
    • Lógica de Programação
    • Computers Architecture
    • Cryptography
    • Data Structures
    • Network
    • Operating Systems
  • Specifics
    • SO Internals
    • Web
    • Python
    • Javascript
    • Infrastructure
    • Go
    • Reverse Engineering
    • DevOps
    • C/C++
    • Log Analysis

Categories

  • Crackmes
  • Documentation
  • Debuggers
  • PE tools
  • Books
  • Util
  • Packers
  • Unpackers
  • Virtual Machines

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


GitHub


Twitter


LinkedIn


Website

Found 2 results

  1. Durante o estudo de exploração de binários executáveis, uma das primeiras e mais importantes coisas que vemos são as proteções como NX, PIE, ASLR, de entre outras. Hoje vamos ver um pouco mais de perto cada uma delas. NX No eXecute (NX) é uma das proteções mais simples e mais lógica, implementada por volta de 2004. Durante a execução de um binário sem essa proteção ativada, a sua stack, heap e outras regiões possuíam poder de execução, simples assim. Os processadores da família x86 tardaram muito para implementar o bit NX, que basicamente é uma forma de sinalizar uma página em memória como executável ou não. Isso gerou projetos para tentar emular tal proteção via software, como o Exec Shield, um projeto da Red Hat que continha um patch no kernel do Linux para emular o funcionamento do NX. No kernel Linux, o suporte para o NX foi adicionado oficialmente em 2004. Patches como o mencionado acima, do Exec Shield, já existiam desde 2002. No Windows, a proteção está presente desde 2003 com o nome de DEP (Data Execution Prevention), porém a DEP emulada via software funciona de uma forma diferente: ela não se baseia no bit NX, mas sim checando sempre que uma exceção é realizada se o endereço da execução bate com a tabela de funções do binário. Essa proteção é ativada ou não durante o carregamento do binário na memória. No Linux isso é controlado com uma flag exec no segmento PT_GNU_STACK do binário. Já no Windows, as configurações ficam no arquivo Boot.ini, podendo ter até quatro opções diferentes: OptIn: Apenas em binários do sistema a proteção é ativada. OptOut: A DEP é ativada por padrão para todos os processos. AlwaysOn: Todos os processos têm a DEP ativada e não existe a possibilidade de desativar para um processo específico. AlwaysOff: A proteção não é habilitada para nenhum processo. PIE/PIC O Position-Independent Executable (PIE) ou Position-Independent code (PIC) não é em si uma proteção, mas uma técnica para criar código, assim como o nome diz, independente de posição. Isso significa que, onde o código for alocado, ele conseguirá executar sem problemas, diferente de binários comuns, os quais precisam ser carregados em lugares específicos para fazerem referências de forma correta. Essa técnica é usada principalmente para bibliotecas (shared libraries). O problema disso durante a exploração é que os endereços do binário também são randomizados com a ASLR, proteção que vai ser explicada a seguir, impossibilitando, assim, conhecer os endereços do binário e consequentemente utilizar Return Oriented Programming (ROP) para explorar uma vulnerabilidade deixa de ser viável. A solução para fazer bypass dessa proteção é conseguir um vazamento (leak) de memória, pois é possível calcular a base já que os offsets continuam os mesmos. Como o PIE é uma forma de gerar código, não é possível "desabilitá-lor", porém se a ASLR estiver desligada, o endereço base se manterá o mesmo, não tento efeito prático para mitigar uma ROP, por exemplo. ASLR A Address Space Layout Randomization (ASLR), assim como o nome diz, tem a função de randomizar endereços como os da heap, stack e bibliotecas. Como uma proteção em nível de sistema, cada sistema operacional mantém uma implementação própria. No Linux, a ALSR já está presente desde a sua versão 2.6.12, lançada em 2005. Executáveis PIE também possuem um endereço base randômico desde 2003, porém ambos com uma implementação fraca e com pouca aleatoriedade. O PaX e o Exec Shield (mencionado acima) foram responsáveis por patches com uma implementação mais complexa e segura. O endereço da stack com essas alterações podem ter até 524.288 variações diferentes. Por padrão, a ASLR é configurada no Linux através do arquivo /proc/sys/kernel/randomize_va_space e pode possuir três valores diferentes: 0 para desabilitar, 1 para randomizar stack, bibliotecas e executáveis PIE e 2, o valor mais alto, para randomizar também a base da heap. É possível, também, ativar ou desativar para processos isoladamente usando um recurso chamado personality . O Windows teve sua implementação da ASLR lançada em 2007 com uma abordagem diferente: a ASLR só é ativada em executáveis e DLLs que possuírem uma "flag" no processo de linkagem e todos os membros precisam possuir essa "flag". Por exemplo, suponha que A.exe dependa de B.dll e C.dll. Caso C.dll não tenha ASLR habilitada, A.exe não terá a proteção ligada. Hoje em dia essa é uma situação rara, pois apenas programas mais antigos não possuem suporte para ASLR. Canary O canary é uma proteção muito interessante. Ao compilar algum código com essa proteção, o compilador adiciona um fragmento de código no começo e no final de cada função. No prólogo da função, se cria uma variável local na stack com um valor aleatório e no final se acessa essa mesma variável para verificar a integridade do valor, validando se continua o mesmo. Caso tenha mudado, uma função de callback é chamada para gerar um abort, assim evitando transbordamentos de memória. O GCC, LLVM, Intel compiler entre outros compiladores possuem implementações do canary. O valor aleatório citado acima é o chamado canary ou stack cookie. Esse cookie pode ser classificado de três formas: terminator O terminator Canary se baseia na observação de que a maioria das vulnerabilidades de buffer overflow acontecem em cenários de manuseio de strings que finalizam com um null byte (\0). Em contrapartida, o cookie é construído com null byte (\0), CR (\r), LF (\n) e FF (\f). Como resultado, isso mitiga um buffer overflow em funções como strcpy(), pois, mesmo sabendo o valor do cookie, não é possível copiá-lo com esse tipo de funções, já que ela ira retornar assim que ler o nullbyte. random Neste tipo, Random Canaries são gerados randomicamente a cada execução a partir de alguma fonte de entropia. Além disso, esse valor não é facilmente lido, pois no carregamento do binário esse valor é armazenado em uma variável global, que é alocada em uma região não mapeada de memória para dificultar ainda mais seu acesso. As formas mais viáveis de ler o cookie são com um vazamento da stack ou sabendo o endereço exato da variável global. random XOR O random XOR Canary é o tipo mais complexo. Seu valor é basicamente determinado a partir de operações XOR de vários valores de controle, como stack pointer, endereço de retorno, etc. Dessa forma, se o Canary ou os dados usados no cálculo forem corrompidos, o programa irá gerar um abort. Para conseguir enganar essa checagem de integridade, é necessário vazar não apenas o cookie, mas também os dados usados no cálculo e o próprio algoritmo para gerar o mesmo. RELRO A RELocation Read-Only (RELRO) é uma proteção exclusiva do Linux, ou melhor, do formato ELF, que tem como intenção deixar as seções relacionadas a realocação como somente leitura (read-only). As seções de realocação, de forma resumida, são onde são armazenados os endereços de funções externas, como as da libc. Por padrão, essas regiões de memória possuem permissão de leitura e escrita (read/write), pois normalmente é utilizada lazy bind, uma forma de resolver esses endereços não em tempo de carregamento, mas durante a execução, logo antes da chamada. Essa proteção foca exatamente nessa região de meória. A realocação dos endereços é feita antes de passar o controle para o programa e a região é marcada como somente leitura, impossibilitando, assim, que um atacante a sobescreva com endereços maliciosos. Existem dois tipos de RELRO: partial e full, onde a partial marca como somente leitura a maioria das seções, exceto a Global Offset Table (GOT), na seção .got.plt. Já a full, como se deve imaginar, força que todos os símbolos e endereços sejam resolvidos durante o carregamento do binário, permitindo que a GOT seja completamente read-only. Referências - A hardware-enforced BOF protection: - http://index-of.es/EBooks/NX-bit.pdf - Windows ISV Software Security Defenses - https://docs.microsoft.com/en-us/previous-versions/bb430720(v=msdn.10) - Position-Independent Code with GCC for ARM Cortex-M - https://mcuoneclipse.com/2021/06/05/position-independent-code-with-gcc-for-arm-cortex-m/ - Effect of ASLR to Memory Deduplication - https://www.semanticscholar.org/paper/Effect-of-ASLR-to-Memory-Deduplication-Ratio-in-)-Piao-Sung/3f74d25c72322315ec3b6552e6c3d4413af95022 - Exploit Protection Mechanisms - https://ocw.cs.pub.ro/courses/cns/labs/lab-06 - Hardening ELF binaries using Relocation Read-Only (RELRO) - https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro
  2. Para que a proteção de sistemas de uma empresa funcione, é preciso fazer a avaliação sobre sua segurança, e para que isso seja bem feito, depende da atuação de dois profissionais: os que trabalham fazendo ataques simulados para medir a força dos recursos de segurança existentes em uma organização, e os que identificam como proteger as áreas que precisam de melhoria e estão mais expostas a esses riscos. São eles que compõem as equipes conhecidas como Red Team e Blue Team, respectivamente. Normalmente, o que vemos é que Red Team, a área de pesquisa ofensiva, é muito sedutora, sempre mostrada nos filmes ou na mídia, com hackers invadindo sistemas e conseguindo encontrar e explorar vulnerabilidades. O que sabemos é que esse trabalho é muito importante, sim, para ajudar as empresas a saberem onde estão suas possíveis falhas e, assim, protegê-las. É aí que a equipe de defesa, ou o Blue Team, entra. Mas nem sempre ouvimos falar tanto sobre a atuação desses profissionais. "Fazer um vírus que um antivírus não pega é muito fácil. Eu quero ver fazer um antivírus que pegue todos os vírus. Esse é o desafio real", diz Fernando Mercês, pesquisador na Trend Micro e fundador do Mente Binária. A segurança ofensiva fica ainda mais "glamourizada" com a quantidade de programas de bug bounty, ou caçadores de recompensa, que hoje existem oferecidos por empresas que querem estimular pesquisadores a encontrar possíveis vulnerabilidades em seus sistemas em troca de uma boa quantia em dinheiro. Mas nem sempre quem vai participar possui tantas habilidades técnicas a ponto de encontrar falhas que realmente impactem o negócio de uma empresa. "A importância desse trabalho [de pesquisa ofensiva] para as empresas depende muito do que o pesquisador quer fazer com o achado (vulnerabilidade)", diz Joaquim Espinhara, líder do time de Red Team & Adversarial Simulation na Tesserent. Para ele, a importância deste profissional para a segurança das empresas está sujeita à motivação do próprio pesquisador. Espinhara destaca que alguns profissionais que procuram por vulnerabilidades em softwares, depois de provar que é possível explorá-lo, acabam vendendo-a para alguma empresa ou governo que vai usar para fins de espionagem, ao mesmo tempo que pesquisadores normalmente encontram uma falha em um site/aplicação de uma empresa e decidem reportá-la, seja por recompensa ou não. Tem ainda o perfil do pesquisador que coleciona falhas, mostrando-as aos amigos para ganhar os chamados "street credits" – ou seja, pontos por ter feito algo considerado legal ou impressionante. Habilidades da pesquisa ofensiva – O conhecimento técnico que o pesquisador deve ter para buscar vulnerabilidades também depende do tipo de falha que ele está procurando, e onde está procurando, diz Espinhara. "Existem muitas classes diferentes de vulnerabilidades. Normalmente o que eu vejo no Brasil e na bolha do bug bounty são falhas relacionadas a aplicações web (SQL Injection, Cross-Site Scripting, File Include, etc)", destaca. Ele ressalta que existem outras vertentes de pesquisa de falhas em sistemas operacionais e software nativos, ou mais recentemente pessoas que estão focadas em blockchain e smart contract security. Na sua visão, os programas de bug bounty são válidos para que pesquisadores tenham opções de rentabilizar o esforço em achar determinada vulnerabilidade. "Empresas deveriam (e até acontece) recompensar de acordo com o impacto da vulnerabilidade ao negócio", avalia Espinhara. Mas ele pontua que este mercado, no Brasil, ainda não é tão atrativo, em especial por conta da desvalorização do real perante o dólar. "Normalmente as empresas pagam o bounty em dólar americano. Algumas já se adaptaram a isso no Brasil, mas ainda não é a maioria. Normalmente, quanto maior a recompensa em um programa de bug bounty maior será a quantidade de pesquisadores mais habilidosos/experientes reportando", diz. Espinhara começou a atuar na área ofensiva há bastante tempo e já tem mais de 10 anos de experiência. "Assim como muita gente na área, eu fiz o caminho padrão: entrei na universidade (que não concluí), comecei a fazer alguns estágios e em um deles fiquei alocado na área de segurança de redes. Foi um caminho sem volta", conta. Atacar só se for para defender – Espinhara pontua que existe uma má interpretação sobre o que é, de fato, o Red Team. "Conversando com alguns amigos que atuam nesta área de verdade no Brasil, eles me falam que o maior desafio é explicar que Red Team não é apenas um pentest com mais dias de execução", diz. Para explicar a melhor definição para Red Team, Espinhara utiliza uma citação de Joe Vest and James Tubberville no livro Red Team Development and Operations: A practical guide: "Red Teaming é o processo de usar táticas, técnicas e procedimentos (TTPs) para emular uma ameaça do mundo real, com o objetivo de medir a eficácia das pessoas, processos e tecnologias usadas para defender um ambiente". "O nosso trabalho é preparar o Blue Team para responder a ameaças reais. Ou seja, sem Blue Team não existe Red Team" – Joaquim Espinhara Assim, ele avalia que um dos objetivos do Red Team é mostrar para o Blue Team a perspectiva de um atacante. "O Blue Team faz uma 'leitura' dessa simulação e se prepara para responder a ameaças iguais ou semelhantes em termos de TTPs", diz. "Red Team e Blue Team têm que trabalhar juntos. Por exemplo, aqui na empresa nós só realizamos exercícios de Red Team se o cliente tiver um Blue Team. O nosso trabalho é preparar o Blue Team para responder a ameaças reais. Ou seja, sem Blue Team não existe Red Team". Essa também é a visão de Thiago Marques, Security Researcher na Microsoft. Segundo ele, as duas áreas trabalham juntas, apesar de alguns grupos manterem uma certa rixa. "O Red Tem dá muita informação de como proteger. Eu vejo como duas áreas que realmente se completam", avalia. Ele pontua, contudo, que é comum ver pessoas mais interessadas pela área ofensiva, por ter uma idealização sobre conseguir invadir um sistema e quebrar proteções. "Já na parte defensiva, poucas pessoas veem o trabalho do pesquisador, e quando veem é porque você não conseguiu proteger", destaca Thiago. Na sua visão, o lado negativo é que existem muitas pessoas que se intitulam profissionais ofensivos, mas somente executam scripts. Oportunidades na área defensiva – Thiago Marques diz que as oportunidades para quem quer atuar com pesquisa defensiva no Brasil são grandes. Isso porque muitas vezes empresas estrangeiras veem a necessidade de ter pessoas que entendam sobre o ecossistema brasileiro para monitorar e se defender de certos ataques. "Por anos o Brasil tem estado no topo de ameaças, principalmente financeiras, com malwares feitos aqui. E a dificuldade de empresas de fora é que tudo é feito em português. Isso gera uma barreira, porque um estranegito olha uma ameaça específica do Brasil e não consegue entender exatamente o que está acontecendo", conta. "Há profissionais bem habilitados no mercado para realizar pesquisas defensivas, mas nem sempre eles são vistos" – Thiago Marques Um exemplo é uma ameaça comum no Brasil que envolve boletos. "Um estrangeiro não sabe o que é um boleto. Essa necessidade tem feito com que muitas empresas queiram aumentar a visibilidade dentro da América Latina, buscando profissionais aqui para monitorar e entender esses ataques". Thiago destaca ainda que há profissionais bem habilitados no mercado para realizar pesquisas defensivas, mas nem sempre eles são vistos. "Tem bastante gente boa, que trabalha em qualquer empresa em qualquer lugar do mundo", pontua. Segundo ele, para quem quer atuar na parte de defesa, primeiramente é preciso saber analisar malware, ou seja, ter a capacidade de analisar um arquivo. "Isso seria o principal. E para fazer a análise de malware é preciso ter uma noção básica de programação", diz, contando que ele mesmo sempre gostou de programar e começou a fazer isso usando macros do Word. Desde 2007, Thiago é analista de malware, e no ano passado, ele começou a trabalhar na área de proteção da Microsoft, entendendo a forma com que os atacantes usam seus métodos de ataque, e identificando como alertar e bloquear esses ataques, até mesmo aprendendo e tentando prever movimentos que atacantes podem fazer no futuro. "Nunca trabalhei muito na parte ofensiva. Eu escolhi a defensiva porque eu gosto, mas já tive ofertas de trabalho para o Red Team", conta. Thiago ressalta que para aproveitar as oportunidades que a área oferece, as pessoas precisam querer entender como as coisas funcionam. "Os ataques usam sistemas que ninguém está olhando, e é preciso conhecer isso para identificá-los. Ter uma boa base de conhecimento sobre sistema operacional e programação, saber como é o processo entre o que você escreveu até o resultado chegar na sua tela, entender esse fluxo leva tempo, e por isso muita gente acaba pulando essa etapa", diz. Para ele, dedicar um tempo para entender as coisas básicas de funcionamento é essencial antes de focar no que você gosta. "A parte de defesa abrange análise de dados, engenharia reversa, depende muito. Mas ter uma base de como as coisas funcionam vai ajudar em qualquer área", complementa.
×
×
  • Create New...