Jump to content

ncaio

Apoiadores
  • Content Count

    35
  • Joined

  • Last visited

Everything posted by ncaio

  1. ncaio

    Darkwaves Conference 2019

    until
    DATA DE REALIZAÇÃO: 25/05/2019 - 13:00hs às 17:00hs LOCAL: SEBRAE - NATAL - RN http://www.darkwaves.zone Dark.conf (Darkwaves Conference) é uma conferência de segurança da informação promovida pela comunidade Darkwaves. Darkwaves é uma comunidade virtual que tem como objetivo debater assuntos referentes a segurança da informação em redes sem fio (RF) . Todos os trabalhos apresentados nesta conferência devem, de alguma forma, ter ligação com segurança em comunicações de redes sem fio. Esta será a segunda edição da Darkwaves Conference. E pela primeira vez, teremos um tema. Para edição 2019, o tema é “Mulheres nas Telecomunicações”. Nossa equipe de colaboradores vem realizando pesquisas sobre a importância das mulheres nas telecomunicações e incorporando o resultado na identidade visual e ambientalização do evento. Assim como o início da campanha de divulgação do padre e inventor brasileiro, Roberto Landell de Moura. Um dos pioneiros da transmissão sem fio de áudio a longa distância. Patrono dos radioamadores brasileiros. [- PÚBLICO ALVO -] A Dark.conf é direcionada para atores que estão por detrás dos equipamentos e os usuários finais. Assim como: Alunos em processo de graduação, entusiastas, pesquisadores, curiosos e afins. [- METODOLOGIA -] A conferência é desenhada para acontecer em auditórios ou estabelecimentos do segmento de recepção e eventos. Preferencialmente em lugares neutros e instituições independentes. O tempo de duração do evento são de 4 (quatro) horas consecutivas, com 3 intervalos de vinte minutos para alimentação, networking e mini palestras. Proporcionando assim 4 (quatro) slots para palestras de 40 (quarenta) minutos, cada. E 3 (três) slots de 10 (dez) minutos para as palestras curtas. O horário de início desejado é às 13:00 (treze) horas, encerrando às 17 (dezessete) horas. Durante a execução do evento, é permitido que apoiadores e comunidades realizem atividades paralelas. [- CHAMADA DE PALESTRANTES -] Existem duas modalidade de palestras: Palestra Longa e Palestras curtas. Palestra Longa Realizada no auditório; Duração de 40 (quarenta) minutos. Palestra Curta Realizada no espaço do coffee break; Duração de 10 (dez) minutos. As propostas de palestras deverão ser enviadas para o endereço de correio eletrônico darkconf(arroba)darkwaves.zone . Informações obrigatórias, tais como: Tipo da palestra, título da palestra, Nome(s) do(s) autor(es), resumo e mini currículo do(s) autor(es). Deverão estar presentes no corpo do e-mail ou em anexo no formato TXT. Qualquer solicitação que não obedeça este padrão, será automaticamente descartada. Todos os trabalhos passarão por apreciação de uma banca formada por membros da organização do evento. Serão julgados fatores, tais como: Relevância do assunto e conteúdo prático. Não serão aceitas submissões de palestras comerciais, assim como sobre produtos ou serviços. Temas sugeridos: Segurança em sistemas de telemetria; Segurança em IOT; Segurança no padrão 802.11; Criptografia de sistemas sem fio; Bloqueadores de sinais; Hardening; Interferências; Wardriving; Radioamadorismo; Banda ISM; Hardware; Contra espionagem; Guerra eletrônica; Drones; Internet descentralizada; Sobrevivência após um apocalipse da Internet; Efeitos de campos eletromagnéticos sobre a biologia e a saúde; Rastreamento GPS; APRS; Rastreamento de aeronaves ADS-B; Home assistant; Automação Industrial; Uso de frequências de rádio no campo da ciência; História das Telecomunicações. DATAS IMPORTANTES Início das submissões: 31/03/2019 Limite de envio das submissões: 04/05/2019 [- ATIVIDADES -] CTW - CAPTURE THE WAVE Capture de flag é um tipo de competição sobre segurança da informação e existem algumas modalidades. Para melhor referência, acesse o link https://ctftime.org/ctf-wtf/ . A Dark.conf realiza uma forma diferente de CTF, intitulada CTW (CAPTURE THE WAVE). CTW é uma competição individual que envolve conhecimentos em segurança de redes sem fio, assim como uma diversa gama de conhecimentos variados. Apresentando vários desafios e formas de acesso, permitindo que pessoas com conhecimentos básicos, possam participar. COMO FUNCIONA ? O CTW é individual e precisa de inscrição para participar. A inscrição será realizada no ato do evento ou previamente em formulário via Internet. Será instalado no evento um equipamento de redes sem fio Wifi, padrão 802.11, para realização do CTW. A duração da atividade é igual ao tempo reservado para intervalos, equivalente a 110 minutos - 1.83 horas. No entanto, o CTW pode ser realizado pelo participante em tempo integral do evento, seis horas. Para evitar desvio de atenção, os participantes ativos em tempo integral no CPF, serão realocados nas últimas fileiras de cadeiras do auditório. OBJETIVO Conseguir acesso privilegiado no equipamento. QUEM GANHA ? O vencedor será o primeiro a alterar o SSID da rede sem fio do CTW para seu nickname. COMO ME PREPARO PARA O CTW ? Primeiramente, tenha em mente dois pontos chaves: Ingressar na rede sem fio do equipamento; Você irá precisar de um adaptador Wireless compatível para o modo monitor - https://www.aircrack-ng.org/doku.php?id=compatible_cards Cracking encrypted passwords; Receptor FM Se for utilizar o celular, lembrar de utilizar fones de ouvido COM fios. Celulares utilizam os cabos do fones de ouvido como antena. Saber utilizar aircrack-ng. Obter acesso privilegiado no equipamento; Conhecimentos Linux; Explorar vulnerabilidades em serviços (Fullstack); Paciência; Conhecimentos teóricos sobre segurança da informação; [- TREINAMENTO PRÁTICO - TRANSMISSOR E RECEPTOR -] Esta atividade é realizada, assim como o CTW, em paralelo com as apresentações. A organização do evento disponibilizará Kits GRATUITOS de montagem de transmissores e receptores FM. Assim como o material necessário para montagem e local. E sim, não se preocupe, teremos monitores para acompanhar o desenvolvimento desta tarefa. Os Kits são LIMITADOS e serão sorteados para os participantes presentes e interessados em participar. O KIT é composto por componentes eletrônicos simples e requer soldagem. Isso mesmo, você irá construir o seu receptor ou transmissor FM, do zero, DIY (Do it Yourself) ou como preferir, from scratch. Pretendemos dividir os sorteados em 3 grupos iguais de participantes, e temos a expectativa que você seja capaz de montar o seu KIT em 1 hora. Acreditamos que seja tempo suficiente para uma pessoa que nunca utilizou um ferro de solda, seja capaz de concluir a montagem. “ Fui sorteado e não quero montar no evento, prefiro levar e montar na minha casa. Pode ? “. NÃO !
  2. ncaio

    H2HC 15ª Edição

    until
    H2HC é uma conferência hacker que se realizará em São Paulo, Brasil, de 20 e 21 de outubro de 2018. Após diversos anos de sucesso anteriores, a anual Hackers 2 Hackers Conference será realizada novamente, desta vez em São Paulo, de 20 e 21 de outubro de 2018, e tem como objetivo reunir industria, governo, academia e hackers underground para compartilhar conhecimento e idéias de ponta sobre segurança da informação e tópicos relacionados. O H2HC terá palestrantes e congressistas nacionais e internacionais com amplo conhecimento e experiência no assunto. O clima é favorável à apresentação dos mais diversos lados da segurança da informação e será uma ótima oportunidade para fazer networking com entusiastas e pessoas do ramo. O idioma da conferência é português ou inglês (com tradução simultânea).
  3. Hallo. O protocolo SMTP tem comandos. E é utilizando comandos SMTP que você descobre isso. Quando você vai enviar um e-mail, você inicia este procedimento com o seu STMP server com um helo, por exemplo. Vamos utilizar aqui um SMTP server do google, por exemplo. Utilizando o comando telnet <ipdoservidorsmtp> <porta> telnet 74.125.24.26 25 Trying 74.125.24.26... Connected to 74.125.24.26. Escape character is '^]'. 220 mx.google.com ESMTP f31-v6si5644201plb.212 - gsmtp helo mentebinaria.com 250 mx.google.com at your service MAIL FROM: <gnoo@dominio.com> 250 2.1.0 OK f31-v6si5644201plb.212 - gsmtp RCPT TO: <maria@gmail.com> 550-5.1.1 The email account that you tried to reach does not exist. Please try 550-5.1.1 double-checking the recipient's email address for typos or 550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1 https://support.google.com/mail/?p=NoSuchUser f31-v6si5644201plb.212 - gsmtp RCPT TO: <joaocarlos@gmail.com> 250 2.1.5 OK f31-v6si5644201plb.212 - gsmtp Normalmente, se utiliza o comando RCPT (recipiente) para verificar se a conta existe. Possibilitando enumeração. Veja que maria@gmail.com não existe e joaocarlos@gmail.com, sim. Essa é a razão. Você pode listar os usuários do domínio dessa forma. Alguns sistemas utilizam contas "locais" como base de usuários de e-mail e etc. Isso não significa que no servidor SMTP exista um usuário de sistema chamado joaocarlos, mas pode ser que sim. Por isso se testa enumeração utilizando uma base comum de usuários de sistema, like: www-data, root, postmaster e etc. Eu tenho uma ferramenta que faz uma leve auditoria em servidores SMTP de forma simplificada. Se for do seu interessee, https://github.com/ncaio/mxmap _\,,/
  4. Primeira dica construtiva =]. Já pensou em usar github ? Fica até mais fácil de receber/fazer outras dicas construtivas. valeu =]
  5. Eita, muita hora nessa calma. =] Se você não tem um adaptador wireless e vai adquirir um que entre em modo monitor, você deverá comprar o adaptador baseado em uma pesquisa que você irá fazer sobre compatibilidade. Provavelmente, este link estará no resultado de sua busca: https://www.aircrack-ng.org/doku.php?id=faq#what_is_the_best_wireless_card_to_buy É claro que você não vai arriscar comprar um adaptador e fazer o teste em casa via linha de comando. valeu
  6. ncaio

    Bico

  7. ncaio

    No title

  8. ncaio

    Timestamp

  9. // // // package main // // // import ( "fmt" ) // // // func main() { msg := "Maneiro! movimentacao do array ficou boa ..." for index := 0; index < len(msg); index++ { ascii := int(msg[index]) fmt.Print(ascii) } fmt.Println() } O-fusca.go hahaha
  10. 7797110101105114111333297321091111181051091011101169799971113210011132971141149712132102105991111173298111974632671111051159732100101321131171011093210697321151111021141011173210911710511611132101109321151041011081083211599114105112116326193
  11. Você não acha melhor reinstalar ? Claro que não sei qual é o custo disso para você.
  12. hello @Valeyard, Quando você se tornar um usuário Vim, sim. Provavelmente você precise utilizar algo a mais. Minha IDE de programação é o Vim e 'plugins' para facilitar na hora de programar/desenvolver. * http://coderoncode.com/tools/2017/04/16/vim-the-perfect-ide.html Se você não usa o Vim como IDE, usa como um administrador de sistemas operacionais ou para editar/criar/manipular arquivos eventuais, por exemplo, talvez não precise de Plugins. Mesmo sem plugins, o editor é bastante poderoso.
  13. Massa. O Tour é interessante. Compartilha conosco como foio sua experiência, primeiro contato com o Go =].
  14. Olá pessoal, abri este tópico para que a comunidade Mente Binária possa trocar ideias sobre Go. Links úteis: Go web page: https://golang.org Tour of Go: https://tour.golang.org/welcome/1 Writing, building, installing, and testing Go code:
  15. ncaio

    162321.jpg

  16. ncaio

    107198.png

  17. ncaio

    158730.jpg

  18. ncaio

    Lá no blog do Anchises

    https://anchisesbr.blogspot.com.br
  19. # # # Ncaio - caiogore $! gma1l (..) com # FALANDO SOBRE OOM # REVISÃO 01 31/10/2017 - TXT AND FILES-> http://8bit.academy/doc/OOM/ # # John Von Neumann serrou o pulso e declarou: "Um computador é composto de três partes fundamentais: o processador, os dispositivos de entrada/saída e a memoria.". Ele mudou de forma radical o conceito de computadores em meados de 1930. Estamos falando de calculadoras. Infelizmente, a ideia de armazenar um programa em memória junto com a parte de dados, demorou a entrar em prática por falta de tecnologia para se construir dispositivos de memória. Enquanto isso, os processadores não pararam de evoluir. Isso talvez explique o motivo dos processadores estarem, de longe, mais evoluídos em comparação aos dispositivos de memória. Sistemas operacionais lidam elegantemente com essa diferença de velocidade entre dispositivos de memória primária e processadores. E este delay tem nome, se chama wait states. Bem, mas este assunto rende muito pano para manga. Dentro deste contexto, o assunto segurança não fica de fora. Este documento fala sobre um dos tópicos da filosofia de segurança Linux que é, inclusive, adotada pelo(a) Android: Ensures that user A does not exhaust user B's memory. https://source.android.com/security/overview/kernel-security Em resumo, sistemas operacionais multiusuários como o Linux, por exemplo, o que fazer para evitar que um usuário não monopolize todo o 'espaço' disponível de memória, que não comprometa o sistema operacional e/ou os outros demais utilizadores ? Sabemos que erros ocorridos no processo de desenvolvimento de uma aplicação podem resultar em um alto consumo de memória em sua execução, assim como intencionalmente ( ou não ), um usuário pode desencadear este consumo. Quando um processo ameaça o funcionamento de um computador que utiliza Linux como sistema operacional por causa de sua fome incontrolável de memória, um mecanismo chamado Out of Memory (OOM) Killer entra em ação. O OOM é um cão de guarda que observa a consumação de memória de um processo e o ataca quando ele passa dos limites. Isso significa que o Linux sempre diz sim quando um programa pede mais memória (malloc())! Com isso, ele consegue, ou tenta, executar mais programas. Estamos agora falando de over-commit de memória. Vamos aqui abrir um espaço para falarmos sobre memória virtual. Memória virtual é uma abstração da memória física que possibilita mecanismos de segurança, extensão e compartilhamento, por exemplo, de forma mais eficiente de quê o acesso direto. O over-commit no Linux vem ativo por padrão! Por isso, um pedido de espaço na memória 'nunca' é respondido como NULL. Isso é motivo de muita discussão na comunidade em geral e o que nos interessa no momento, é: * Por padrão, o valor da flag over-commit é zero no Kernel do Linux ( https://www.kernel.org/doc/Documentation/vm/overcommit-accounting ); * Se um aplicativo pede memória, o Linux responde positivamente; * E quando este pedido de memória perde o controle, o OOM killer entra em ação e assassina o processo. Claro que é um resumo genérico e existem algumas entrelinhas. No entanto, este é o conhecimento base para continuarmos a falar sobre o mecanismo OOM. LAB Para acompanhar estes procedimentos de forma prática, é recomendado o uso de uma máquina virtual com o sistema operacional Linux instalado. NÃO execute estes procedimentos fora da máquina virtual! Certifique que a flag de over-commit é zero. cat /proc/sys/vm/overcommit_memory 0 O valor esperado é zero. Como alterar este valor ? echo "0" > /proc/sys/vm/overcommit_memory Os vídeos aqui anexados, apresentam 4 telas de terminais que representam o mesmo host, onde: * Terminal superior esquerdo: É executada a criação de estrutura com o mkdir; * Terminal inferior esquerdo: Pontuação do OOM; * Terminal superior direito: A saída do comando free -m; * Terminal inferior direito: Tabela de processamento. Telas: http://8bit.academy/doc/OOM/img-6.png LAB 01 - NA VIDA REAL Vamos pegar um exemplo do dia a dia de um administrador para a construção de situações que envolvem memória. Chico do Pentest recebeu a seguinte missão: Criar uma estrutura de diretórios com características: Exemplo da estrutura de diretórios: http://8bit.academy/doc/OOM/lista-dir.txt São duas camadas de dez(10) diretórios (0 - 9) que, dentro deles, tem outra camada de dez diretórios. Chico tem um bom conhecimento em shell e utiliza para este procedimento, expansão de variáveis. Como ele criou estes dois níveis ? mkdir -p {0..9}/{0..9}/ De forma simples, Chico resolveu o problema proposto no laboratório 1 LAB 02 - FATIANDO O PROBLEMA Não demorou muito para a equipe de desenvolvimento descobrir que a estrutura de pastas solicitadas não atenderia aos requisitos do sistema. O chamado retornou para a fila de atendimento de Chico, solicitando a adição de mais quatro níveis. Contabilizando agora, seis níveis. Chico aceita o desafio e logo pensa em aproveitar a linha de comando anterior, adicionando a quantidade de níveis solicitada. E assim fez. mkdir -p {0..9}/{0..9}/{0..9}/{0..9}/{0..9}/{0..9}/ bash: /usr/bin/mkdir: Argument list too long Vídeo: http://8bit.academy/doc/OOM/6-levels.webm Temos aqui dois problemas: * Dez elevado a sexta potência, igual a 1 milhão de strings para serem carregadas na memória (10^6=1000000); * 1 milhão de strings é um valor muito alto de argumentos para um único comando mkdir. O Linux faz over-commit de memória, isso significa que o problema número um seria descartado do processo de resolução de problemas de Chico, se não houvesse memória suficiente e que isso fosse degradar o funcionamento do sistema operacional, ele já sabia que o cão e guarda OOM Killer entraria em ação. Esta é uma situação que muitos administradores já passaram ou passarão no decorrer de suas carreiras. E a recomendação para este caso é fatiar o seu problema. Chico agora tem duas situações: Utilizar FOR e realizar a criação unitária em 10^6 ciclos. O exemplo a seguir mostra como o problema 1 não impacta no sistema operacional utilizado. Ele foi capaz de carregar 1 milhão de strings na memória e passar uma por uma ao comando mkdir. for i in {0..9}/{0..9}/{0..9}/{0..9}/{0..9}/{0..9}/; do mkdir -p $i; done Utilizar o comando xargs. Este comando irá passar para o mkdir, por exemplo, apenas a quantidade de argumentos que ele suporta naquele momento. Em comparação a utilização do FOR, é de longe a solução mais recomendada. Chico também aprendeu: * Limitação de recursos é uma prática importante; * Aprendeu sobre o comando ulimit; * Aprendeu sobre ARG_MAX ( https://www.in-ulm.de/~mascheck/various/argmax/ ). PAUSA PARA O OOM A ideia de cão de guardar foi entendida por Chico. No entanto, ele precisou descobrir mais sobre o comportamento do OOM. Principalmente sobre a heurística que determina se um processo passou ou não dos limites. Em sua pesquisa, Chico chegou a seguinte conclusão sobre como a pontuação OOM é calculada. * O primeiro modelo publicado em 2009 não se mostrou efetivo. Já que saia matando qualquer processo e quando necessário, continuava a matar processo sem descrição de importância; * O modelo de 2010 é o que utilizamos hoje; * Existe uma proposta de melhoria para o modelo atual, publicado em 2013; * Cada processo tem sua pontuação; * A abstração fica em proc/<pid>/oom_score; * A pontuação é baseada na porcentagem de uso de memória RAM + SWAP ; * O valor 1000 significa 100% de uso da memória; * 0 significa 0% de uso da memória; * Para processo root, subtrair 3% da pontuação; * Existe como desativar um processo da ação matadora do OOM; * Existe como marcar um processo como alvo preferencial para o OOM; * Este arquivo é /proc/<pid>/oom_score_adj Links de referência: https://lwn.net/Articles/317814/ https://lwn.net/Articles/391222/ https://lwn.net/Articles/548180/ LAB 03 - O CURIOSO Chico resolveu seu problema anterior utilizando o FOR e aprendeu que poderia resolver de outra forma, com o xargs, por exemplo. Descontente e curioso, ele tem a ideia de mandar mais argumentos para o mkdir. Neste caso, ele enviou a criação de oito níveis. mkdir -p {0..9}/{0..9}/{0..9}/{0..9}/{0..9}/{0..9}/{0..9}/ Vídeo: http://8bit.academy/doc/OOM/08-levels.webm O vídeo de exemplo mostra que o gatilho Argument list too long não foi disparado. E com isso, o mkdir começou a pedir memória para armazenar as 10 ^ 8 = 100000000 strings. Que equivalem mais ou menos, contando com NULL e SLASHES -> 15 bytes, 15 * 100000000 = 1500000000 bytes ou 1.3 GigaByte. No canto superior direito ( free -m ) é possível observar o decremento da memória RAM E SWAP, enquanto no canto inferior esquerdo, a pontuação OOM só aumenta, até chegar ao ponto que o interpretador de comandos, no canto superior direito, ser assassinado pelo OOM. OBS: Chico utilizou uma sequência de comandos para esvaziar o CACHE da memória virtual. echo "3" > /proc/sys/vm/drop_caches Chico não para de se perguntar: Por qual motivo 10^6 argumentos geram um Argument list too long e 10^8, não ? LAB 04 - O REVOLTADO Chico desabilita o over-commit e chega a conclusão que é perigoso. Ele tem o receio que o seus programas sejam mortos antes de concluírem seus ciclos de execução. Sem over-commit, o processo é morto, por padrão, quando utiliza 50% da memória física. Vídeo: http://8bit.academy/doc/OOM/disable-overcommit.webm LAB 05 - O MORTO VIVO Para finalizar, Chico teve a brilhante ideia de executar o comando mkdir para a criação de uma estrutura de 8 níveis e desabilitar o OOM do processo executor. Vídeo: http://8bit.academy/doc/OOM/score-prio.webm E para sua surpresa, a pontuação não foi incrementada, o processo consumiu toda a memória RAM + SWAP e mesmo assim foi morto. Até então, tudo ocorreu bem, a não ser pelo fato de do suposto PID assassinado continuar na tabela de processamento com o status Z (zombie process). Depois dos laboratórios, Chico do Pentest aprendeu que tudo precisa de limites e que sempre deve levar o assunto de segurança de recursos a sério.
×
×
  • Create New...