Android-PIN-Bruteforce - Desbloqueie um telefone Android (ou dispositivo) ao perfurar o PIN de tela de bloqueio

Desbloqueie um telefone Android (ou dispositivo) perfurando o PIN de tela de bloqueio.

Transforme seu telefone Kali Nethunter em um cracker PIN de força bruta para dispositivos Android!

PIN de 4 dígitos Cracking with Masks Configuração para diferentes telefones Popups Teste mensagens de envio de chaves de um aplicativo Como enviar chaves especiais 

🌎 @RubyOfSec

Fonte: KitPloit

XSS Armazenado Via Upload de Foto

Nessa ultima semana (15/05) eu estava estudando por artigos e reports da hackerone, até que me deparei com uma falha de XSS armazenado por uma imagem, achei muito legal a ideia e quis reproduzir em meus clientes e em uma plataforma de bug bounty, por incrível que pareça isso funcionou em ambas! Então hoje irei mostrar detalhadamente essa falha para que você possa aprender mais e testar em seu bug bounty.

https://gabrieldkgh.medium.com/xss-armazenado-via-upload-de-foto-dd9877e63fbf

@hatsecurity

DI.WE.H

Repositório com conteúdo sobre web hacking em português

https://github.com/T635/DI.WE.H

@hatsecurity

git Exposed

Olá, recentemente encontrei uma pasta .git exposta em um programa de Bug Bounty público, e gostaria de mostrar como você consegue explorar essa falha.

https://leonardoprudenci.medium.com/git-exposed-7edb5fdd532

@hatsecurity

Unrestricted File Upload — Entendendo o que é, Como explorar, Tipos de Bypass e Como Prevenir a falha

Olá a todos, hoje iremos falar sobre uma falha muito conhecida que é o Unrestricted file upload (Upload de arquivo irrestrito), essa falha pode ser muito perigosa pois conseguimos executar comandos remotos (RCE) no servidor e até mesmo pegar uma shell, então vamos começar!

https://gabrieldkgh.medium.com/unrestricted-file-upload-entendendo-o-que-%C3%A9-como-explorar-tipos-de-bypass-e-como-prevenir-a-a723d845c375

@hatsecurity

Uma palestra sobre Inteligência Artificial ofertada pelo IGTI

Data do evento: 19 a 22.07
Site: https://t.igti.com.br/click?o=573&a=49768

Ad-Honeypot-Autodeploy - Implantar um pequeno, intencionalmente inseguro, domínio vulnerável do Windows para o pote de mel RDP totalmente automaticamente


Implante um pequeno, intencionalmente inseguro e vulnerável Domínio do Windows para RDP Honeypot totalmente automaticamente.

É executado em virtualização auto-hospedada usando libvirt com QEMU/KVM (mas pode ser personalizado facilmente para soluções baseadas em nuvem).

Usado para configurar sem dor um pequeno Domínio windows do zero automaticamente (sem interação do usuário) para fins de teste RDP Honeypot.

Possui um controlador de domínio, um computador de mesa e um servidor Graylog configurado para registrar as ações dos bandidos.


🌎 @RubyOfSec

Fonte: KitPloit

um estudo bastante interessante com a analise de varios vetores de ataque em pdfs, desde malware apartir de inteligencia artificial ateh tipos de analisis estaticos e dinamicos entendendo a estrutura que compoe os arquivos

"Nos últimos anos, o Portable Document Format,
comumente conhecido como PDF, tornou-se um padrão democratizado
para intercâmbio e divulgação de documentos. Esta tendência tem sido
devido às suas características como flexibilidade e portabilidade
em múltiplas plataformas. O uso generalizado do PDF instalou um
falsa impressão de segurança inerente entre usuários. No entanto,
as características do PDF motivaram os hackers a exploitar vários
tipos de vulnerabilidades, superar núcleos de segurança,
tornando o formato PDF um dos mais eficientes vetores de ataque. Portanto, detectar com eficiência arquivos PDF infetados é crucial para a segurança dos usuarios. Várias técnicas de análise têm
tem sido proposto na literatura, seja ela estática ou dinâmica, para extrair
os principais recursos que permitem a divisão de arquivos infetados
dos benignos. Como as técnicas clássicas de análise podem ser
limitadas em caso de técnicas baseadas em aprendizado de máquina (0day)
surgiram recentemente como uma detecção automática de malware em PDF cujo
método é capaz de cirar um parámetro a partir de um conjunto de amostras de treinamento.
Essas técnicas estão enfrentando o desafio da bypass onde um PDF malicioso é transformado para parecer benigno. Em
Neste trabalho, damos uma visão geral sobre a detecção de malware on  PDF. Damos uma perspectiva sobre os novos desafios e 
 soluções emergentes "

texto original

vou explicar aqui uns trechinhos bem interessantes,ainda to lendo mas algumas coisa merecem alguns comentario

Começo dos Post sobre a Estrutura e Corpo do PDF, seus Vetores de Ataque e seus Exploits Conceituais e Desenvolvidos)
se quiser pular os post's sobre este state of the art acabam aqui

https://news.1rj.ru/str/rubyofsec/1972

Antes de tudo, eh necessário construir uma visao conceitual da estrutura dos arquivos pdf

pdfs são arquivos polimórficos, ou seja, constituídos de duas estruturas primarias (physical and logical)

alterar a estutura física, não alterar necessariamente a estutura logica,
ou seja, o conteudo do pdf

a estutura física é compostra por quatro elementos fundamentais

header
eh a definiçao do arquivo(pdf) e a versao, alem de poder conter metadados, informações do usuario criador e outras informaçoes referentes aos tags do arquivo

pdf1.x

body
eh a parte interessante em si, já que consiste em grupos de objects que constroem o conteudo bruto do arquivos, esses objects podem ser representados como arvores binarias
eles seguem uma ordem inicial de (1..n), essa ordem inicial nao precisa necessariamente ser em ordem sequencial, jah que como falamos, a
alteraçao do corpo esturutural nao modifica o conteudo (obviamente alterar a esturutura que constroi explicitamente o conteudo vai
alterar o conteudo)
vamos ver mais sobre lah na frente


cross-reference
xref
eh composto por um tipo de tabela que aponta a cada inicio de object, assim como seu identificador (1..n), seu tamanho e eh apontado por offset

Trailer
aponta á cross-reference, inclui o tamanho de elementos, indica o
cross-reference por offset e o ponto inicial do body (1..n | 1) ou seja o primeiro object do body
cabe dizer que este espaço eh o primeiro a ser posto na fila de
processamento, ou seja, a ser processado durante abertura

por isso contem os apontadores fundamentais do arquivo, que eh o cross-reference, onde podemos localizar os objects por offset ou seja
xref

esses dois últimos elementos (xref & trailer)são importantíssimos
pra o processamento do pdf, já que definem uma sintaxe rapida de localizaçao do conteudo (body)
jah que o trailer, aponta a quantidades de objects esperada pelo leitor (independente do sistema ou arch) e a tabela de referencia (xref) que permite acceder o conteudo do pdf como parte do pre-processamento, ou seja, o leitor jah sabe qual eh o primeiro item a acceder
alem disso tmb permite que o arquivo seja processado sem encher (alocar) sua memoria com o arquivo inteiro nela, apenas processando o pedaço de body contendo os objects necessario, lendo esse pedaço de bytes
ou seja, apenas os objects necessarios pra a posiçao do usuario no pdf, mais objects podem ser carregados pela interaçao do usuario guiando-se do xref (o offset)
eh interessante lembrar que se um object possui sub-objects dentro de si, seu id vai ser a quantidade dentro dele

lembrando tmb que existem formas mais complexas de encontrar as xref, por exemplo a partir do pdf1.7 que implementou as incrementally ups, os xref possuim subtipos chamado xref streams, essa implementaçao permitiu pdf com mais de 10 gb e que tivesse diversas formas de object
alem dos linearized
outra curiosidade bem interessante, eh que caso o pdf esteja encriptado ele iria conter dois elementos dentro
/encrypt atribui o tipo de diccionario pra o processo de cifra
/info contem o offset que aloca o diccionario


porem, isto eh soh pra criar uma ideia fudamental do corpo estutural
tem bastante conteudo por ai caso algm se interesse em dev estes tipos de arquivos
porem ficou claro as bases que permitem que esse tipo de arquivo seja tao flexivel e tao amplamente utilizado, basta um leitor minimamente bem
trabalhado (ou nem tanto) que sua implementaçao sera bem incorporada por qlqr sistema e arch

caso tenha interesse em saber mais, recomendo pymudf, uma api bem interessante e com bastante docs, alem da iso 32000, tem tmb disponivel uma documentaçao aqui https://www.oreilly.com/library/view/developing-with-pdf/9781449327903/ch01.html e aqui https://blog.didierstevens.com/2008/04/09/quickpost-about-the-physical-and-logical-structure-of-pdf-files/
e é aquilo, basta usar algumas palavras chaves que você acha bastante no duck (physical structure of pdf, reversing on pdf format, pdf syntax, dev docs of pdf files)


bem,agr vamos pra parte mais interessante

body content (tipos de elementos objects)
bem, como jah comentei, o body, eh composto de objects
e como explicar os object??
"eles são os blocos de construção sobre os quais o PDF se sustenta”

os objects sao elementos com os quais podemos criar as propiedades do pdf, alem de escrever o conteudo (logical), existem 8 tipos de dados elementais do tipo object
Boolean, integer, real, name, string, array, dictionary, and stream

cada um deles compartilha suas funçoes e propiedades, mas aqui vamos focar especificamente em dois tipos bem especiais


dictionary
geralmente eh o tipo de object que mais vamos ver presentes numa analise do corpo de um pdf, este tipo de elemento consiste em uma chave e seu valor,
pode ser recursivo e invocar outros tipos de dados, vou explicar melhor

aqui vemos o corpo esturutural e o conteudo de um pdf o qual mostra uma pagina em branco com um hello world (criado como com um tipo stream)em
helvetica e 1 pagina
se vc observou com calma esse code, conseguiu enxergar tdo o que temos comentado ateh agr

a parte em azul eh o body e nele existem essas chaves definindo o
conteudo do corpo, isso sao o tipo de elemento dictionary, um dado associativo com uma chave invocada por /xxxx e sua funçao ou tipo de dado, lembrando que sempre precissamos implementar << ao começo
outra parte interessante eh observar o numero dos objects ( 1..n) ao lado
do seu id e observar que tdo object eh invocado por obj e terminado por endobj
pra aqueles que jah desenvolveram code em c ou python podem encontrar uma sintaxe bem familiar

existem multiplos tipos de definiçoes dictionary, alem de ser recursivo,
ou seja pode definir outro dictionary dentro de si


streams
esse tipo de elemento eh o mais expressivo dentro de um arquivo, ou seja, eh o conteudo bruto em si, podem ser dados comprimidos, imagens, graficos e ateh outros objects dentro de si
fazem que o pdf seja mais potente e pequeno
elementos streams permite carregar javanoscript dentro do pdf, alem de carregar grandes dados dentro de si, que podem ser representados de varias maneiras
por poderem ser codificadas e comprimidas de diferentes tipos de codigo arbitrarios (xml, js, imagens, anotaçoes especiais) outros objects e elementos especiais invisiveis ao usuario final
bem, nem precisso explicar o potencial disso neh

O Espirito Dentro Do Corpo (entendendo o sistema interno do pdf)
bem,tendo entendido esses conceitos, vamos pra uma partezinha bem legal

stream(filters)
certo, jah sabemos que stream podem ser blocos de bytes de grande tamanho, entao a pergunta que fica eh, como comprimimos e descomprimimos (lembrando que essa compressao em multiplos casos eh definida como uma interpretaçao, ou seja, digamos que queremos "comprimir" um tipo de fonte ou imagem de grande tamanho, o mecanismo em si pode ser chamado de codificaçao, mas vamos usar compressao pq geralmente eh o termo que mais veremos na documentaçao original) e eh ai que entra a necessidade dos filters (do tipo dictionary). Como eles podem definir as propiedades de compressao do tipo stream????
alguns filters que geralmente vamos ver em diversos documentos


flateDecode
geralmente vamos ver pra comprimir imagens e fontes, uma propiedade interessante eh que esse filter utiliza o mesmo mecanismo de compressao que zip


DCTDecode/DPXDecode
geralmente veremos em compressao de imagens compativeis com jpeg/jfif

soh uma observaçao que poderia ter feito antes, ha varias formas de chamar e definir os atributos de um tipo stream. existe um tipo de object chamado de external object, geralmente eh um tipo de stream grafico auto-contido, ou seja, ele eh definido dentro do object que invoca o elemento stream, porem fora do bloco de bytes stream, um exemplo facil eh qndo vc define alguns atributos antes de compilar alguma coisa com gcc, ou seja, um external object eh uma diretiva pra invocar um elemento stream onde seu tipo e compressao eh atribuido dentro do propio object e no modulo external-object