0xmedeiros - Tumblr blog

0xmedeiros · 5 years ago

Text

STUXNET - O Primeiro tiro da Ciberguerra

Se você ler muito sobre Malwares, ou o mínimo, já deve ter ouvido falar do Stuxnet, o malware que deu início a um novo cenário de guerra que ninguem até então se importava. O stuxnet foi um worm[1] governamental altamente sofisticado e silencioso criado pela suposta parceria EUA-Israel para atrasar o enriquecimento de urânio do Teerã. O motivo é que o urânio é o elemento essêncial para a criação de armas nucleares, ou seja, o objetivo era atrasar o desenvolvimento nuclear do país, o que funcionou, já que mil centrífugas de urânio foram danificadas, atrasando o enriquecimento mais ou menos em 2 anos. O stuxnet não foi apenas um malware qualquer criado por qualquer hacker de 20 anos, foi uma arma digital governamental extremamente sofisticado que precisaria de muito investimento. O malware foi o primeiro tiro que representou o início de um novo cenário de guerra: A CiberGuerra/CyberWar.

Se futuramente a ciberguerra tomar proporções gigantescas, com toda certeza vamos lembrar do stuxnet como o ponto zero desse novo tipo de guerra. Já penso que legal estudar o Stuxnet nos livros de História?

OBS: Esse post foi escrito em uma madrugada de 4 horas, que por coincidência, é o tempo de duranção média da cafeína no sistema nervoso. Erros de português, como tempo verbal ou falta de coesão, serão comuns ao longo dessa jornada, perdoe-me.

[1] Worm é um malware que tem a habilidade de se espalhar sozinho. [2] Agência Internacional de Energia Atômica [3] https://www.correiobraziliense.com.br/app/noticia/mundo/2010/11/28/interna_mundo,225248/wikileaks-rei-da-arabia-saudita-pediu-aos-eua-ataque-militar-ao-ira.shtml [4] https://oglobo.globo.com/mundo/israel-admite-ter-atacado-suposto-reator-nuclear-na-siria-em-2007-22510494 [5] Zero day é o termo técnico usado para vulnerabilidades que ainda não possuem correções, e portanto, continuam funcionando.

# Da política até os códigos

Bom, tudo tem uma política por trás, com o stuxnet não foi diferente. Então vamos a um resumo dos acontecimentos.

A história começa bem lá atras, em 1968, com a criação do Tratado de Não Proliferação de armas nucleares (TNP), o tratado visava a limitar o desenvolvimento nuclear das grandes potências nucleares, sendo elas Estados Unidos, Rússia, Reino Unido, França e China. O acordo permitiu que esses grandes paises pudessem permanecer com os poderes que já possuiam e proibiu o compartilhamento de armamento ou informações de tecnologias nucleares com países que não possuiam tal tecnologia. Mas o acordo não começou bem por conta da desigualdade nuclear dos signatários, quando as grandes potências assinaram o acordo eles já possuiam um poder bélico nuclear muito avançado, e os paises que não tiveram tempo de desenvolver nenhuma dessas armas ficaram incomodados com as restrições e o monopólio bélico das grandes potências. Por esse motivo muitos países, inclusive o Brasil, discordaram e tiveram muitas diplomacias até os países concordarem e ratificarem o tratado.

Porém o tratado continuou gerando problemas por conta da dificuldade da AIEA[2] de fiscalizar e garantir que os países signatários estão cumprindo com os acordos, inclusive as grandes potências, que prometeram diminuir o seu arsenal. Mas o grande causador de problemas até hoje é o irã; que já causou, e causa, diversos alvoroços por conta do seu programa nuclear iraniano, que alega ter apenas intuitos tecnologicos pacíficos.

Em 2003, e meio a tanta confusão, o irã assina a adesão ao protocolo adicional do tratado TNP e concorda em suspender o enriquencimento de urânio, e todo mundo fica mais calmo, especialmente o Ocidente que diz não confiar o irã com armamento nuclear. Em 2006 o irã fica puto, mete o foda-se pra todo mundo e inicia pesquisas nucleares com alegação de que é para fins civís (kkkk) e ainda diz que limitará as visitas da fiscalização, nada suspeito huehueirã. O resumo é que desde de 2003 o irã descumpriu 4 acordos preocupando os Estados Unidos, Israel e os países do Ocidente, que não ficaram nada contentes. O incomodo fez com que muitos paises, entre eles Estados Unidos e Israel, apoiassem e incitassem alguma forma ofensiva de impedir o avanço nuclear do irã. Em dos documentos vazados pelo Wikileaks, o rei da Arábia Saudita pediu ao EUA que atacasse o irã por conta do seus avanços nucleares[3] e o presidente egípcio, príncipe herdeiro de Abu Dhabi e outros também apoiavam o ataque. Basicamente geral tava puto pedindo ajuda para o papai EUA pra descer o cacete no moleque teimoso do irã.

Apesar da insistencia de Israel para apoiar um ataque aéreo nas instalações do irã, George Bush, o presidente do Estado Unidos na época, estava contra por medo da população achar que o EUA estavam apenas procurando pretexto para atacar o irã. Não era a primeira vez que Israel pedia apoio para bombardear instalações, em 2007 os agentes da inteligencia de israel invadiram o quarto de hotel de um importante funcionário sírio e simplesmente plantaram um malware no notebook dele, através do malware descobriram que os sírios estavam montando um reator nuclear para construir armas com ajuda da Coreia do Norte. Com isso eles ganharam suporte do EUA para atacar o reator nuclear da síria, o ataque foi nomeado de Operação Pomar[4].

-- Aprendizado de hoje: nunca deixe seu notebook sozinho em nenhum lugar e criptografe seu HD, aproveitando vá ler meu post sobre criptografia com luks e veracrypt ;) --

Israel agora queria fazer o mesmo com as instalações do irã, porém, o cenário não era tão simples como na síria, o ataque era muito mais complexo em questões técnicas e sociais, e possivelmente causaria diversos problemas até mesmo econômicos; por essas e outras razões o ataque aéreo estava fora de cogitação para G.Bush, o presidente do EUA. Depois muitas opções de ataques não muito boas eles chegaram a uma ideia genial: Um ataque digital. Essa opção era a melhor que eles tinham conseguido, pois seria os mesmos resultados e com poucas consequencias e riscos. A operação foi chamada de Jogos Olímpicos(OG, Olimpic Games) e mais tarde nomeada de stuxnet pela mídia e empresas de segurança.

O plano era um malware altamente sofisticado, inteligente e independente, ele se espalharia por outros computadores e saberia identificar o seu alvo, agiria de forma silenciosa mas que desse resultado significativos. O plano não era destruir totalmente, e sim atrasar os avanços nucleares do Irã até que as situações diplomáticas sejam resolvida de alguma forma, plantando um malware na principal instalação em Natanz.

Sem barulho, sem mortes, sem digitais, e capaz de penetrar em qualquer instalação e com poucos riscos, uma arma digital silenciosa, era o plano perfeito.

Isso me lembra aquela frase do wallpaper do kali: "more quieter you become more you able hear"

Se você quiser saber mais detalhadamente sobre a história por trás do Stuxnet eu recomendo o livro Contagem Regressiva ao Zero Day, o livro no qual o post está sendo baseado. Também recomendo o documentário ZeroDay.

# Uma monstro à solta

A primeira versão do Stuxnet foi então instalada fisicamente através de agentes duplos de Israel que tinham acesso a Natanz, já que a mesma era isolada da internet exterrna, e por isso passava um sentimento de segurança. Inicialmente o malware não era tão agressivo, na verdade era bem mais simples e precisava de uma execução manual para funcionar, mas a ambição de agressividade de Israel fez com que o malware recebesse atualizações e fosse ficando cada vez mais forte, agressivo e inteligente, até demais. O malware foi contando cada vez mais com zerodays[5] e funções que o permitiam ser mais eficaz no seu propósito, o plano seria perfeito se não fosse por israel.

Israel não estava satisfeito, sempre incitando a NSA à deixar o malware mais e mais agressivo, eles não percebiam o que eles estavam criando e nem nas consequências disso. O malware foi então sendo desenvolvido até chegar em um ponto onde eles não tinham mais controle, o stuxnet, que deveria ser uma operação precisa e secreta, começou a criar vida própria e se espalhar pelo mundo inteiro sem controle, até eles perceberem a merda que fez quando o malware chegou nas instalações da Rússia e caiu nas mãos do Serviço de Segurança Federal da Rússia (FSB). O malware começou também infectar o EUA, o que alertou as agências de segurança, mas como o projeto era ultra secreto só um pequeno grupo de pesssoas sabia sobre, então o EUA começou a se defender de um ataque feito pelo próprio governo.

Mas Israel novamente não satisfeito pegaram o código do malware, modificaram e sem o conhecimento da NSA executaram. O update causou algum bug no sistema que começou a desligar os computadores, fazendo as máquinas entrarem em loop de reinicialização, o que alertou os engenheiros e as empresas de antivírus.

# Identificando o alvo

PLC, Programmable Logic Controller é um hardware que tem como função controlar, gerenciar e monitorar equipamentos e máquinas indústriais que precisam de um controle mais rígido e monitorado. São geralmente usados em infraestruturas críticas como Usinas de energia, fábricas, redes de energia e qualquer ambiente industrial que precise de um controle e monitoramento maior. Esses mini computadores são controlados e monitorados por um software específico da produtora. Esses softwares são nomeados de SCADA (Sistema de supervisão e aquisição de dados).

Uma das grandes marcas responsáveis por criar esses hardwares e softwares SCADA é a Siemens.

Em 2009 o governo do irã publicou um total de 48 fotos mostrando o presidente Mohammed fazendo um tour pela usina de enriquecimento de urânio em Natanz. Olhando parcialmente você só percebe homens de jalecos brancos em lugares cheios de máquinas, mas em uma análise profunda é possível reconhecer softwares SCADA, o tipo e marca de hardware, equipamentos, etc.

Um dos cientistas atras do presidente foi assassinado pouco tempo depois da foto.

Em uma olhada mais detalhada na tela do software SCADA no computador, é possivel identificar que haviam seis grupos de centrífugas e em cada grupo havia 164 peças, o que "curiosamente", é o numero exato encontrado no payload de ataque do stuxnet. E com uma analisada mais profissional, é possivel identificar que o hardware/software usado é da empresa Siemens. Portanto, a instalação de Natanz estava usando PLCs Siemens para controlar e monitorar as centrífugas de enriquecimento de urânio.

# O ataque

O stuxnet ao infectar uma máquina procurava por uma configuração e software específicos, caso a máquina não tivesse essa configuração ele ficaria ali sem representar nenhum perigo. Caso sim, ele procurava por modelos de PLCs extremamente específicos que não conhecidentemente pertencia a Siemens. Ao reconhecer a infraestrutura e os PLCs, o stuxnet começava silenciosamente registrar as informações de monitramento das PLCs ligadas a centrífugas por 13 dias sem se mover.

Ao passar dos exatos dias então, o stuxnet começava a entrar em jogo. Ele acionava um PLC rootkit que alterava os códigos baixo níveis dos controladores PLCs para aumentar a velocidade da centrífuga em 80%, assim com um tempo nesta velocidade elas se destruiriam. Ao alterar o código o rootkit enviava as informações antigas, registradas durantes os 13 dias, ao software SCADA, enganando assim os engenheiros que monitoravam e os alarmes de segurança. Assim os operadores olhavam para a tela e viam que as centrífugas estavam girando a 1000hz, enquanto na verdade estavam se destruindo girando a 1800 hz. E quando os operadores tentassem apertar o botão vermelho de desligar tudo, o stuxnet interceptaria e ignorava o comando.

Mas acelerar as centrífugas à essa velocidade causa um barulho notável muito grande, o que uma hora ou outra alguem desconfiaria. Então o stuxnet foi atualizado para tentar outro tipo de ataque, de vez acelerar as centrífigas causando aquele barulho ele iria fazer o inverso, ele iria desacelerar as centrífugas a 2hz, isso causaria uma oscilação fazendo elas quebrarem.

- O stuxnet foi o primeiro malware a mostrar um Rootkit para PLC, que até então nunca tinha sido visto antes em qualquer lugar.

# Arquitetura o stuxnet contava com diversos tipos de vulnerabilidades e técnicas que tornava possivel a sua disseminação. Como por exemplo:

- Propagação por pednrives. Ele fazia uma cópia de si para pendrives usando um zeroday que permitia se auto executar quando o pendrive infectado fosse conectado. [BID 41732] http://www.securityfocus.com/bid/41732 - Propagação através de vulnerabilidades zerodays SMB. [MS08-067] http://www.securityfocus.com/bid/31874 - Propagação através de zerodays no serviço de impressão Windows Print Spooler. [MS10-061] http://www.securityfocus.com/bid/43073 - Propagação através de computadores com WinCC databse server. - Escalação de privilegio através de vulnerabilidades [MS10-073]. https://docs.microsoft.com/pt-br/security-updates/securitybulletins/2010/ms10-073 - Controlava o sistema operacional através de um drive assinado windows rootkit nomeado de "mRxnet.sys". - Assinava o drive do rootkit mRxnet.sys com certificado roubado da Realtek, assim o sistema tinha confiança no drive.

# .DLL Grande parte das funções vitais do stuxnet se localizava em um arquivo criptografado .dll, é a tabela de funções e recursos que o malware exportava para executar as atividades e instalações no sistema. É onde fica todo o sistema de controle do malware.

- DLL(Dynamic-link library) é uma biblioteca dinâmica composta por uma tabela de funções que serão carregadas para algum programa quando chamadas. Abaixo uma imagem de todas funções dll.

Em vez da tabela dll ser carregada no disco, ela era injetada em um outro processso em execução através de técnicas avançadas de Process Injection, assim mantendo o DLL na nuvem (RAM). O stux escolhia o seu processo alvo que seria injetado com base nos softwares de segurança instalados, alguns eram processos pré-definidos, como processos de antivírus:

Kaspersky KAV (avp.exe) Mcafee (Mcshield.exe) AntiVir (avguard.exe) BitDefender (bdagent.exe) Etrust (UmxCfg.exe) F-Secure (fsdfwd.exe) Symantec (rtvscan.exe) Symantec Common Client (ccSvcHst.exe) Eset NOD32 (ekrn.exe) Trend Pc-Cillin (tmpproxy.exe)

Outros processos padrões do windows que poderiam ser usado

Lsass.exe Winlogon.exe Svchost.exe

Um desses acima poderia ser escolhido com base no AV.

# Privilégio Adminstrativo Após a dll ser carregada ele fazia algumas verificações como versão do windows, se o computador já está infectado, qual software de antivirus está instalado e se ele tinha ou não acesso de Adminstrador. Se caso ele detecte que não tem permissões de administrador, ele escolhe um zeroday baseado na versão do sistema operacional windows para Escalação de Privilégios. Em Windows XP ele explorava a falha MS10-073.

O stuxnet só executaria em uma dessas versões do windows: Win2K WinXP Windows 2003 Vista Windows Server 2008 Windows 7 Windows Server 2008 R2

Após a exploração ser bem sucedida ele criava um novo processo, dessa vez com permissões adminstrativas e injetava novamente o arquivo dll nesse processo.

# Instalação Depois das etapas anteriores bem sucedidas e acesso adminstrativo, o stuxnet então partia para a sua instalação principal que contava com a infectação diversos processos para a disseminação, inclusive o processo service.exe afim de poder infectar pendrives, e exportava alguns arquivos criptografados para o disco:

O arquivo de log - oem6C.PNF O arquivos de configuração - mdmcpq3.PNF Arquivo dll de funções principais do stuxnet - Oem7a.pnf

Nesta mesma etapa ele extrai também dois arquivos criptografados para o disco, ambos chamados de Mrxnet.sys e Mrxcls.sys. Esses eram os drives com rootkit que a após instalado ocultava alguns arquivos do stuxnet e mudava a data de criação deles para a mesma data de outros arquivos no sistema para evitar suspeitas, também fazia com o que o stux se iniciasse quando o windows fosse iniciado.

Abaixo uma imagem da rotina do stuxnet.

# Command and Control (C&C) Após todo a sua instalação e reconhecimento do sistema o stuxnet enviava informações sobre o sistema infectado para domínios disfarçados de sites de futebol.

www.mypremierfutbol.com www.todaysfutbol.com

Dessa forma a equipe que pesquisava sobre o malware conseguiu acessar o domínio e redirecionar os dados, permitindo o rastreio mundial de cada computador infectado pelo malware.

# O reconhecimento do erro

Apesar do stuxnet ser uma ciberarma altamente sofisticada pensada em um plano perfeito, o projeto não ocorreu como deveria. O malware que o EUA-Israel criou para atrasar o irã não foi tão eficaz, o que era pra ser um ataque silencioso, na verdade, foi extremamente barulhento. A suposta frase dita por Obama na sala de Situação quando foi avisado pelos Coroneis de que o malware havia vazado.

"Me disseram que os iraniano nunca descobririam do malware, eles descobriram. Me disseram que ninguem saberia que foi o EUA, agora sabem. Me disseram que isso teria um grande efeito no programa nuclear deles, e não teve."

O irã após a descoberta do stuxnet não demorou até revidarem:

Aramco, a maior companhia de petrolífera do mundo teve 35.000 computadores destruidos em questão de horas, a estrutura da companhia que oferece 10% do óleo mundial estava em risco. https://money.cnn.com/2015/08/05/technology/aramco-hack/ https://www.nytimes.com/2018/03/15/technology/saudi-arabia-hacks-cyberattacks.html

Ondas de ataque a vários bancos no EUA deixaram todos sem acesso as suas contas https://en.wikipedia.org/wiki/Operation_Ababil https://www.forbes.com/sites/thomasbrewster/2016/03/24/iran-hackers-charged-bank-ddos-attacks-banks/#42a8e0677255

Isso foi uma bela fudida mensagem do irã ao EUA dizendo: "Nós também podemos brincar". Não é atoa que hoje o irã tem uns dos maiores ciberexército do mundo.

e se aviões pudessem ser hackeados? ou hospitais e bancos sem sistemas, ou um pais com sua comunicação interrompida, desastres tecnológicos, a ciberguerra não é mais algo de filme cyberpunk, agora é real.

O Estados Unidos não apenas fracassou como também apresentou ao mundo um novo cenário de guerra perigoso, iniciou uma nova corrida armamentista, um novo tipo de exército. E isso não pode ser parado, talvez limitado, assim como armas nucleares e químicas foram limitadas, talvez em um longo futuro de desastres as cyberarmas sejam tão perigosas quanto uma bomba nuclear.

Be safe!

fontes: Zerodays Documentário sobre stuxnet https://www.amazon.com.br/Countdown-Zero-Day-Stuxnet-Digital/dp/0770436196 https://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf

1 note · View note

0xmedeiros · 6 years ago

Text

Uma breve conversa sobre Rootkits.

Geralmente quando ouvimos a palavra Rootkit pensamos logo em um fucking código baixo nivel extreme master power que só engenheiros formado pela NSA conseguem fazer, mas não é bem assim, basicamente rootkit é tipo de malware que atua no kernel space, espaço onde fica drivers e códigos vituais para o funcionamento de um sistema, portanto tem mais "poder" dentro de um sistema do que os que atuam em user space. Se você não consegue entender estes termos fique tranquilo porque vamos falar sobre eles mais abaixo.

Antes de começar nossa explicação técnica do que é um rootkit, precisamos conhecer mais sobre arquitetura do sistema operacional, mais especificamente sobre Kernel, Kernel Space e User Space.

KERNEL

Kernel é um conjunto de códigos que formam o núcleo do sistema operacional, é o responsável por intermediar a conversa entre o software e o hardware, gerenciar a memoria, fornecer abstrações para o software, etc. Ele abstrai a complexidade da comunicação com o hardware para que vc não precise se comunicar com ele diretamente só para dar um print. Ele também gerencia as memórias impedindo que os softwares possam ter acesso fisico a memória livremente, ja pensou que caos seria se todo software pudesse ter acesso a memoria de outros livremente ?.

Enfim, o kernel é o que gerencia as permissões de usuarios, os prints na tela, memorias, arquivos no hd, é a base do sistema operacional por isso o nome núcleo.

KERNEL/USER SPACE

O sistema operacional então é dividido em 2 partes, o kernel space e o user space. O kernel space é onde fica localizado todos os códigos que conhecemos como drives, ou kernel modulos, importantes para o funcionamento do sistema. Já o User Space é onde fica localizado todo os softwares do usuario, como gimp, firefox, gnome, bash, etc., todos eles dependem das abstrações do kernel para o seu funcionamento, mais conhecidas como Systems Calls, ou syscalls.

SYSCALL

Syscalls são funções/abstrações que o kernel oferece para os softwares em User Space. Esses softwares chamam essas funções quando precisam de algo que envolva uma permissão ou uma complexidade maior. Por exemplo, quando algum software tentar ler qualquer arquivo no sistema a função sys_open é chamada por ele - a função sys_open é responsável por abrir um arquivo no sistema - o kernel então detecta a chamada, pausa a execução do software, executa a syscall e retorna um valor numerico que indica o resultado da operação: aberto, sem permissão, arquivo não existe, etc.

Mas não adianta ficar só na teoria né? por que não verifcamos com nossos proprios shells instalado o comando strace?

Strace é um comando que intercepta a syscalls que um comando/software faz durante sua execução. O uso dele é fácil, basta colocar ele antes de qualquer comando e veremos todas as syscalls que ele executou ou executa, recomendo brincar com ele. Mas vamos então criar um script de teste simples para dar print em C e executar ele com strace pra gente ver o que acontece.

Essa lixarada toda que vc ve na sua tela é todas as syscalls que o nosso script faz antes de printar. O que nos interessa é o

- write(1, "Se me atacar eu vou atacar\n", 27) = 27

O sys_write, ou write na imagem, é a syscall responsável por escrever dados em algum arquivo. A syscall write necessita de 3 argumentos, o endereço do local que será escrito, os dados, e o tamanho total dos dados que serão escritos. O resultado apos o simbolo de igualdade é o retorno da syscall que, neste caso, representa o total de bytes que foram escritos com sucesso.

Simplificando:

- write(addr, msg, tamanho_de_msg) = total de bytes escritos com sucesso

Por quê o endereço ali está 1? porque 1 é o endereço do stdout, o arquivo de saida padrão que é impresso na sua tela. Isso é uma simplificação, caso queira entender realmente pesquise por "file descriptor".

Porque colocamos printf e no strace aparece write? porque printf não é uma syscall do kernel, é uma abstração do write para formatação de texto oferecida pela biblioteca padrão do C. Mas e se quisessemos usar a syscall diretamente? Pra isso teremos que baixar no nivel, bora pro assembly. Eu não vou explicar codigo por código do asm pq não é no nossso foco.

O primeiro 1 é o numero de endereço da sys_call na tabela das syscalls, sim, isso existe. A Syscall table é uma tabela onde fica armazenado em ordem numerica as syscalls. Essa tabela muda dependendo da arquitetura x86 ou x86_64. https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl

Beleza, agora vamos ve se essa bagaça funciona mesmo.

E pow, deu certo, usamos a syscall diretamente.

É muito importante que vc tenha entendido essa parte pra continuação do post. Recomendo que pesquise caso essa explicação não foi suficiente.

LKM - LOADABLE KERNEL MODULE

Agora que você manja o básico sobre kernel linux, bora aprender o que bagaça é LKM, ou modulo carregável do kernel. O kernel Linux geralmente não trabalha sozinho, ele possui extensões, códigos externos, que estão fora da base original do kernel, podem ser carregados ou descarregados em tempo de execução. O modulo é carregado no kernel space e chamado quando for preciso.

você pode encontrar modulos carregados no seu sistema usando lsmod.

O comando que temos para gerenciar modulos é o modprobe, atraves dele vc pode ter informações sobre um modulo, carregar ou descarregar.

Para descarregar um modulo usamos modprobe -r module

Vamos escolher um modulo para descarregar, no caso psmouse, verificar com lsmod se está realmente descarregado e depois carrega-lo novamente.

:Brinque com cuidado com isso, seria burrice descarregar o modulo errado e ficar sem teclado pra carregar ele novamente KKK.

beleza, ele está descarregado. Agora vamos carregar novamente e verificar

Funcinou! toma essa comunistas do caralho.

Pooooorém, modprobe serve para carregar modulos que estão no /lib/modules/$KERNEL...

Então, quando quiser carregar um modulo local fora desse diretório, use insmod no lugar e rmmod para descarregar.

insmod [module] rmmod [module]

LINUX KERNEL MODULE PROGRAMMING

Então meu pudimzinho já que vc entendeu o que é LKM e como gerencia eles, vamos agora aprender a programar, sim, bora fazer um caralho de um modulo kernel nessa porra caralho. Malz to empolgado, deixa eu mijar e a a gente continua. ...

Voltei, então, onde paramos? Ah sim, você provavelmente deve achar que programação para o kernel linux é um fucking hardcode que você só aprende capturando sangue de 7 virgens grávidas, but it's not. Dificuldade é sinal que você ainda tem o que aprender, e isso é bom! significa que você ainda tem muitos universos à explorar, é como descobri que a série que vc ama tem mais uma temporada.

Deixando as putaria de lado, aqui irá ser levado em conta que você sabe o básico de C, caso não saiba ta na hora de aprender. Bora lá

Para programar em kernel linux temos que primeiro definir para que versão do kernel queremos programar. Cada versão do kernel possui diferenças de estruturas, tornando antigos modulos incompatíveis com versões mais atuais. Mas vamos ver isso la na frente quando formos programar nosso rootkit.

A estrutura básica de um kernel é a função de inicio e a função de saida. A função de inicio é executada quando o modulo é carregado ao kernel, e a função de saida é executada quando o modulo é descarregado. A função de saida serve pro modulo limpar sua bagunça no sistema antes de ser descarregado.

Vamos nomear nossa função de entrada como mod_init, e nossa função de saida como mod_exit. Como na imagem a baixo.

module_init e module_exit servem para definir qual função ira ser executada quando o modulo for carregado ou descarregado. Sem isso seu modulo vai ser carregado ao sistema mas não será exeutado. A função de saida não precisa retornar nada, por isso, void.

printk? que diabos é isso? No kernel space não usaremos o printf porque não escreveremos no stdout, escreveremos nos logs do kernel e para isso usaremos printk. Printk e Printf tem o mesmo jeito de uso. Não esqueça de colocar "\n" no final, sem isso o kernel pode acabar ignorando a mensagem.

OK babe, salve em .c e agora vamos compilar essa bagaça, mas como? Para compilar kernel modules é um pouco diferente de como compilamos arquivos em C. Pra isso vamos precisar de um makefile bem simples.

FILENAME := mymodule obj-m += $(FILENAME).o

all: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules clean: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

mymodule é o nome do arquivo do nosso modulo ".c". Recomendo que vc use os mesmos nomes de arquivos e variaveis aqui para evitar confusões futuras.

Beleza, criado os arquivos necessarios execute o comando "make" para compilar o nosso módulo. Se tudo ocorreu como esperado você vai notar que foram gerados uma caralhada de arquivo mas o que nós interessa é o .ko, pois é ele que carregaremos no kernel.

Para carregar nosso módulo vamos usar o comando insmod, por quê não o modprobe? porque como explicado anteriormente o modprobe não carrega modulos locais. E não esqueça de usar sudo ou usuario root para carregar o módulo.

Ok, bora carregar.

Ok, o módulo foi carregado, mas o que acontece agora?

Primeiro, vamos verificar se nosso módulo foi realmente carregado, lembra do comando de verificar os modulos carregados? bora usar.

ok então, nosso módulo foi definitvamente carregado, mas e o nosso print, cadê? lembra la trás quando eu expliquei sobre printk? então, nosso printk está imprimindo mensagens nos logs do kernel, para acessar os logs do kernel vamos usar o comando dmesg.

olá viu? nosso "Hey kernel" apareceu nos logs, isso quer dizer que tudo funcionou como esperado. Mas e o outro print? ele só vai ser executada quando o modulo for descarregado, para descarregar o modulo vamos usar rmmod, que seria como o modprobe -r para modulos locais.

$ sudo rmmod mymodule.ko

ok, agora vamos ver se nossa função de saida foi executada com o dmesg.

Se tudo saiu como esperado, parabéns, você criou seu primeiro kernel module.

Vamos apimentar um pouco mais a nossa conversa e começar falar sobre rootkits.

HOW TO DO A ROOTKIT

Sim, finalmente chegamos na parte mais gostosa desse texto, rootkits. A maioria dos rootkits se baseiam em módulos, tipo esse que criamos, porém maliciosos. Nestes exemplos abaixos vamos estar usando o kernel 2.6, porque por conta de ser antigo ele também é mais simples, que é o objetivo do texto.

SYSCALL HOOK

Lembra quando falamos sobre syscalls? mais especificamente sobre a tabela de syscalls? essa tabela existe na memória, o que vamos fazer é encontra-la e sobrescreever o endereço de uma syscall especifica pela nossa função, que será uma syscall fake. Esse processo é chamado de hook.

A imagem acima demonstra um exemplo de hooking. O rootkit altera o endereço de sys_read() para evil_sys_read() que é a função maliciosa que irá ser executada quando sys_read for chamada. O sys_read() é chamado e então evil_sys_read() é executado. Evil_sys_read após manipular alguma informação ele executa a verdadeira sys_read. Isso provavelmente vai ficar mais claro mais pra ferente.

Nosso rootkit aqui vai ser simples, ele tem apenas um objetivo, evitar que um arquivo específico seja lido. Quando um usuario comum, até mesmo root, tentar ler o arquivo que vou nomear de "secreto.txt", o rootkit vai intercepta e retornar que o arquivo não existe, quando na verdade ele existe e possue um conteúdo dentro. Bora lá seus malware devs.

Vamos logo criar nosso arquivo chamado secreto.txt que vai ter uma mensagem dentro.

Primeiramente temos que entender como um programa ler um arquivo no linux, quais syscalls ele chama, e pra isso vamos usar nosso amigo strace.

$ strace cat secreto.txt

Perceba que o cat chama a syscall open passando o nome do arquivo que ele quer abrir e ela retorna o numero 3, ok, mas o que isso significa? vamos procurar informações na documentação dela.

Segundo a documentação, o valor positivo retornado por sys_open é o endereço do arquivo que pode ser usado pra ler, escrever, etc. Mas e se o arquivo não existir ? o que sys_open irá retornar? bora testar

$ strace cat arquivo_inexistente

hm, maneiro, sys_open acusou que o arquivo não existe retornando o numero negativo -1. Ou seja, o que temos que fazer é criar uma sys_open falsa que quando executada irá ler o nome do arquivo e caso seja igual ao nome do arquivo que queremos esconder, retornamos o numero negativo -1, que irá ocasionar em um erro "arquivo ou diretório não encontrado".

Antes de tudo temos que descobrir o endereço da nossa syscall table, pra isso existe vários métodos como bruteforce na memória, porém, como queremos simplicidade, vamos procurar o endereço dela no arquivo de símbolos do kernel localizado em /boot/System.map-$(uname -r).

Perceba que ele me retornou duas syscall tables, a sys_call_table corresponde as syscalls x64, enquanto a ia32_sys_call_table corresponde as syscalls x86. Como nosso rootkit vai ser simples vamos focar apenas na tabela x64.

0xffffffff81309260

Beleza, então esse é o meu endereço da tabela de syscall no sistema, em sistemas diferentes os endereços serão também diferentes. Ok, bora codar.

criamos a variavel my_sys_call_table que vai apontar para a nossa tabela de syscalls para podermos alterar ela.

Agora temos que fazer uma função que seja igual a syscall que queremos alterar, neste caso a sys_open. Dando uma olhada na documentação a gente consegue achar o protótipo dela.

Agora que sabemos vamos fazer a função que tem o mesmo prototipo.

O argumento pathname é o que vai possuir o caminho e nome do arquivo a ser aberto, precisamos procurar se há alguma menção ao nosso arquivo secreto, caso tenha, então retornaremos um erro. Eu vou usar a função strstr da biblioteca linux/string.h para verificar se existe ou não alguma ocorrencia do nome "secreto.txt"

Ok, estamos quase lá. Precisamos agora criar um pointeiro de função que vai guardar o endereço da sys_open original.

Voltando a nossa função evil_sys_open, esquecemos de colocar para que caso pathname não possua a palavra "secreto.txt" retornar a sys_call original, esse simples detalhe pode fazer com que a sys_open n funciona mais e quebre o sistema.

Pronto, a maior parte está feita, agora basta a guardarmos o endereço da sys_open original e depois substituirmos ela pela evil_sys_open na nossa tabela de syscall my_sys_call_table. Porém a sys_call_table é setada para apenas leitura, para podermos ter permissão de escrever iremos usar 2 pequenos comandos. write_cr0 (read_cr0 () & (~ 0x10000)) - desativa a proteção de escrita write_cr0 (read_cr0 () | 0x10000) - ativa a proteção de escrita de volta

Agora vamos fazer o processo inverso na funçao mod_exit, para que quando o modulo for descarregado ele retorne o endereço original da syscall, não queremos que nosso sistema quebre depois que o rootkit for descarregado ne?

Ok, então esse é o nosso codigo completo.

Pronto porra, agora vamos compilar e ver se essa bagaça funciona mesmo porque senão nosso kernel e a porra toda vai pro espaço kkkkk.

ai caralho funcionou, nosso rootkit impediu que conseguissemos ler o arquivo secreto.txt. Agora vamo ver se essa porra descarrega sem foder o kernel.

Pelo o que eu vejo nosso rootkit funcionou como esperado, entrando e saindo sem foder o kernel. O que fizemos nesse post foi extremamente básico, e usamos o kernel 2.6 pra facilitar nossa vida, kernels mais atuais possuem uma caralhada de proteção mais complexa pra dificultar nossa vida. Caso queria continuar com estudos eu deixo aqui abaixo algumas fontes sobre kernel hacking e códigos de rootkits maneiros. É isso pessoas, vou dormi.

LINKS

https://linux.die.net/lkmpg/x978.html https://github.com/m0nad/Diamorphine https://github.com/vanhauser-thc/THC-Archivepapers/LKM_HACKING.html https://lwn.net/Kernel/LDD3/

0 notes

0xmedeiros · 6 years ago

Text

Buffer Overflow Pwnable.kr [WRITEUP]

[ ATENÇÃO ] ALERTA DE SPOILERS, CASO NÃO TENHA FINALIZADO A CHALLENGE.

Há um tempo já estava com a ideia de escrever uma writeup dos meus desafios, percebi que é uma boa maneira de estudar tanto hacking quanto produção de texto ao mesmo tempo. Então eu decidi aumentar o brilho do monitor e começar a registrar os desafios que eu matei. É útil informar que a minha área é Low Level, ou seja, enquanto minha sanidade mental estiver saudável nenhum php aparecerá por aqui.

ANALISANDO O SOURCE

Vamos primeiramente analisar a nossa situação. Esse abaixo é o código fonte do binário.

O binário possui a função func() que recebe como argumento um inteiro, a key, e caso ele seja igual a 0xcafebabe o programa executa uma shell. Porém a função é chamada com a key incorreta. Portanto, o objetivo aqui é mudar o argumento da chamada por 0xcafebabe para valida-lo e executar o nosso shell de cada dia.

BOTANDO A MÃO NO SHELL

Inicialmente já temos o conhecimento de qual falha nos brincaremos, o Buffer Overflow. Para fazer o debugger usarei o meu velho amigo GDB puro e sem plugins. Porque eu acho que o aprendizado se tornar melhor trabalhando com ferramentas puras, ou talvez eu sou esteja com preguiça de instalar o plugin PEDA.

Ao jogar um amontoado de dados aleatório no programa recebemos o alerta de segurança STACK SMASHING. Podemos definir ele como uma proteção do binário, ele detecta a entrada em grande volume e mata o programa. Mais para frente falaremos dele.

O lado bom é que isso significa que nosso binário já corrompeu, ou seja, já conseguimos quebrar o limite do buffer.

Vamos agora fazer um disassembler rápido no código.

A instrução marcada acima, cmpl, está comparando 0xcafebabe com 0xdeadbeef. Mas preste atenção, para fazer comparação ele busca o dado(0xdeadbeef) na stack pelo seu endereço (ebp - 0x8) . Perceba que a chamada da função gets, o que causa nosso overflow, está imediatamente atras dele. Portanto, já que o dado a ser comparado está na stack, e é executado logo depois da chamada gets, podemos tentar encontra-lo na stack e sobreescreve-lo por um dado novo.

Ok, então vamos setar um breakpoint nessa exata instrução e analisar o estado da stack.

Ya Bitch! Perceba que o nosso overflow (0x41"A") quase sobrescreeveu o 0xdeadbeef, então vamos calcular o quanto falta parar chegar no 0xdeadbeef e gerar a entrada. 1 + 4 + 4 + 4 = 13 * 4 = 52

Com 52 caracteres podemos alcançar o 0xdeadbeef.

O que queremos é que a instrução seja verdadeira para que execute nosso shell. Portanto, sobreescrevendo o 0xdeadbeef por 0xcafebabe fazemos ele comparar 0xcafebabe == 0xcafebabe, e assim executando nosso shell.

Mas ué, o que aconteceu ? O stack smashing está matando nosso processo ao detectar o buffer overflow. Uma boa técnica para dar bypass nessa segurança, é executar sem fechar o pipe de comunicação do processo, assim o programa continua executando. Para fazer isso você pode utilizar o comando "cat [file] -".

ow bitch, deu certo!

Agora é só dar o mesmo comando usando a conexão com o server do pwnable.

0 notes

0xmedeiros · 6 years ago

Text

Linux process communication - Signals

Para conseguir ler e entender esse post, é necessário que vc saiba o mínimo de Linux e da linguagem de programação C.

Primeiramente, o que é signals? signals(em português, sinais) é o método de comunicação entre processos Linux. Ou seja, através desses signals, eles podem pedir, ou avisar, algo para outros processos em execução.

Um bom exemplo para entender signals, é o comando kill, quando executamos o comando kill para um determinado processo, estamos enviando um sinal chamado SIGTERM para a ele. Esse sinal é um PEDIDO de finalização ao processo, isso quer dizer que, se você enviar esse signal para o processo do Chrome, por exemplo, ele estará pedindo ao chrome para que ele finalize a sua execução, esse pedido pode, ou não, ser ignorado. Agora, caso você utilize o argumento "-9" no comando kill, você estará enviando um signal chamado SIGKILL para o processo. Diferente do SIGTERM, o SIGKILL não pode ser ignorado, não importa o que o processo esteja fazendo, se ele receber esse sinal, ele imediatamente é finalizado.

Existem diversos outro signals no Linux, não irei explicar todos, então deixarei uma tabela aqui em baixo de alguns desses signals.

A = abort T = terminate I = ignore S = stop

Signal

Default Action

Description

SIGABRT

Process abort signal.

SIGALRM

Alarm clock.

SIGBUS

Access to an undefined portion of a memory object.

SIGCHLD

Child process terminated, stopped,

[XSI]

or continued.

SIGCONT

Continue executing, if stopped.

SIGFPE

Erroneous arithmetic operation.

SIGHUP

Hangup.

SIGILL

Illegal instruction.

SIGINT

Terminal interrupt signal.

SIGKILL

Kill (cannot be caught or ignored).

SIGPIPE

Write on a pipe with no one to read it.

SIGQUIT

Terminal quit signal.

SIGSEGV

Invalid memory reference.

SIGSTOP

Stop executing (cannot be caught or ignored).

SIGTERM

Termination signal.

SIGTSTP

Terminal stop signal.

SIGTTIN

Background process attempting read.

SIGTTOU

Background process attempting write.

SIGUSR1

User-defined signal 1.

SIGUSR2

User-defined signal 2.

[XSI]

SIGPOLL

Pollable event.

SIGPROF

Profiling timer expired.

SIGSYS

Bad system call.

SIGTRAP

Trace/breakpoint trap.

SIGURG

High bandwidth data is available at a socket.

SIGVTALRM

Virtual timer expired.

SIGXCPU

CPU time limit exceeded.

SIGXFSZ

File size limit exceeded.

Tirando o SIGKILL e o SIGSTOP, todos os outros processos podem ser ignorados, ou interpretado de outras formas. Olhando na tabela, você verá um sinal chamado SIGUSR1, sua ação padrão é finalizar um processo, porém, programas podem interpretar esse sinal do modo que bem quiser. Podemos usar como exemplo, o comando dd, que serve para copiar arquivos, geralmente usado para gravar arquivos do tipo ISO em pendrives. Se vc enviar o sinal SIGUSR1 ao dd, enquanto ele estiver em execução, ele irá receber o sinal e retornar informações sobre o progresso atual. Exemplo abaixo.

Ou seja, ao invés de finalizar o processo, como ele faz por padrão, ele interpreta o sinal SIGUSR1 como um pedido de informações sobre o progresso.

AGORA, PROGRAMANDO...

Se você quiser entender melhor, siga-me, vamos voar como cavalinhos com asas no mundo das condicionais binárias. Traduzindo, bora lá codar em C.

Para tratar sinais em C, precisamos incluir a biblioteca signal.h e a biblioteca de syscall, a unistd.h.

Primeiramente, vamos começar com um programa bem simples, ele vai ignorar quando o usuário tentar parar o script com ctrl+c. Para isso, é importante saber que, quando vc lança essa combinação de teclas, vc está enviando um signal SIGINT ao processo. Vamos usar uma função bem chamada sigignore.

#include <stdio.h> #include <unistd.h> #include <signal.h> #include <stdlib.h> int sigignore(int sig); int main () { sigignore(SIGINT); for(int x=0; x<5; x++){ sleep(1); printf("olan"); fflush(stdout); } printf("finalizein"); return 0; }

Agora, todas as tentativas de finalizar o processo com ctrl+c irão ser falhas.

Ai neste gif que passei meia hora pra fazer, vimos o ctrl+c não fez efeito nenhum, ele continuou executando até finalizar o processo. OK, isso ficou um pouco sem graça, vamos fazer algo mais legal. Vamos fazer que, quando a usuário mande SIGINT, o programa execute uma função e imprima ou faça algo. Para isso, vamos usar a função signal(), passando o sinal que queremos tratar e a o ponteiro para a função que será acionada. signal(SIG, &FUNC). A função deve ter o parametro para a entrada do signal.

#include <stdio.h> #include <unistd.h> #include <signal.h> #include <stdlib.h> void exitsafe(int signal); FILE *fd; int main(void) { signal(SIGINT, &exitsafe); int cnt = 0; fd = fopen("output.txt", "w"); while(1) { cnt += 1; fprintf(fd, "%s%dn", "Ola", cnt); puts("Data Writed"); sleep(2); } } void exitsafe(int signal) { puts("nSIGINT DETECETADO: Fechando arquivo com segurança"); fclose(fd); exit(0); }

Ok, agora vamos ver como ficou. (lembrando que ^c significa ctrl+c)

O código apenas abre um arquivo e começa escrever nele em um looping fechado com um delay de 2 segundos para não flodar. Em um caso sem a nossa função de exitsafe, o programa iria apenas parar sem fechar o arquivo aberto, porém, com a nossa função quando ele recebe o sinal para parar ele aciona a função exitsafe() para finalizar o programa corretamente.

Neste caso parece ser algo besta e simples, mas softwares mais complexos se parado instântaneamente pode ocorrer de lixos no sistema ou algum problema mais sério.

Por hoje é isso, essa foi apenas uma preview sobre as funções do signals no sistema linux, creio que valha a pena dá uma estudada mais profundamente neste assunto futuramente.

0 notes

0xmedeiros · 6 years ago

Text

Hidden Volume - Veracrypt

Veracrypt é uma ferramenta de criptografia de volumes on-the-fly, uma alternativa ao cryptsetup. On-the-fly, ou também chamada de real-time, é um conceito onde toda os dados criptografados são trabalhados e armazenados apenas na memória RAM, sem intervenção do usuário. Por exemplo, imagine que você tenha uma música dentro desse dispositivo criptografado, quando vc montar ele e iniciar a música com um player, esses dados estarão sendo descriptografado em tempo real na memória RAM e sendo enviados ao player a medida que for preciso. Ou seja, todos os dados descriptografados que você "exportar" estarão armazenados unicamente na memória RAM(on the fly).

Diferente do cryptsetup, que é uma ferramente cli feita e voltada ao linux, veracrypt é uma ferramente criada e voltada para o windows, portanto, é mais voltada a parte gráfica. Ela chega a ser mais simples e intuitiva do que o cryptsetup. Há quem diga que ela pode ter um backdoor em seu código, por conta de ser uma fork do Truecrypt, mas tudo não passa só de teoria. E mesmo que tivesse um backdoor no Truecrypt, já não seria mais compativel, por conta da ferramenta ser agora incompativel com o Truecrypt, algoritmos diferentes etc. De qualquer forma, funciona basicamente como o cryptsetup, cria um container(local criptografado onde fica seus arquivos, pode ser um dispositivo ou um arquivo tratado como dispositivo mesmo)

Como dito antes, ela é muito voltada a GUI, como a doc, por exemplo, que é toda voltada a GUI. Então, mesmo sendo fácil, tive um pouco de dificuldade em aprender a cli.

CRIANDO VOLUME

A primeira facilidade do veracrypt, é na hora de criar um volume. Se você não passar um argumento necessário, ele irá perguntar posteriormente. A segunda é que, basta você colocar o nome do containerfile e ele irá criar, ao contrário do cryptsetup, que usamos o dd para criar o containerfile.

Neste comando, vamos passar apenas 2 argumentos: -c [nome_do_volume] flag para criar um volume. Se você não der o nome no argumento ele irá perguntar posteriormente. --size [tamanho] tamanho do volume. Aqui, a mesma coisa.

Então, vamos la.

OPÇÕES ESCOLHIDAS:

volume type = normal algorithm = AES Hash = SHA-512 fileystem = FAT

[code] $ veracrypt -c containerfile --size 500M Volume type: 1) Normal 2) Hidden Select [1]: 1 Encryption Algorithm: 1) AES 2) Serpent 3) Twofish 4) Camellia 5) Kuznyechik 6) AES(Twofish) 7) AES(Twofish(Serpent)) 8) Camellia(Kuznyechik) 9) Camellia(Serpent) 10) Kuznyechik(AES) 11) Kuznyechik(Serpent(Camellia)) 12) Kuznyechik(Twofish) 13) Serpent(AES) 14) Serpent(Twofish(AES)) 15) Twofish(Serpent) Select [1]: 1 Hash algorithm: 1) SHA-512 2) Whirlpool 3) SHA-256 4) Streebog Select [1]: 1 Filesystem: 1) None 2) FAT 3) Linux Ext2 4) Linux Ext3 5) Linux Ext4 6) NTFS 7) exFAT Select [2]: 2 Enter password: WARNING: Short passwords are easy to crack using brute force techniques! We recommend choosing a password consisting of 20 or more characters. Are you sure you want to use a short password? (y=Yes/n=No) [No]: y Re-enter password: Enter PIM: Enter keyfile path [none]: Please type at least 320 randomly chosen characters and then press Enter: Characters remaining: 240 Characters remaining: 207 Characters remaining: 186 Characters remaining: 174 Characters remaining: 147 Characters remaining: 131 Characters remaining: 118 Characters remaining: 103 Characters remaining: 54 Characters remaining: 24 Characters remaining: 19 Characters remaining: 5 Done: 100.000% Speed: 85 MB/s Left: 0 s The VeraCrypt volume has been successfully created. [/code]

nesses logs, vimos que eu não passei o argumento de algoritmo, hash ou de filesystem, etc., eu poderia, mas optei por responder dps. Outra coisa interessante, é que no final, ele pede para você digitar 320 carecteres aleatórios para gerar o algorítmo.

Feito essas opções, o seu containerfile estará pronto para ser montado. Pode ignorar o PIM apenas dando enter.

MONTANDO VOLUME

Montar o volume é também algo extremamente fácil, basta colocar como primeiro argumento o seu containerfile, e como segundo, o ponto de montagem do container. Se

[code] # veracrypt containerfile pmnt/ Enter password for /home/berim/armz/TesteVeracrypt/containerfile: Enter PIM for /home/berim/armz/TesteVeracrypt/containerfile: Enter keyfile [none]: Protect hidden volume (if any)? (y=Yes/n=No) [No]: [/code]

Primeiramente, ele irá pedir sua senha, como visto acima. Depois o PIM, keyfile e o Hidden volume - caso você tenha iniciado como user normal, ele irá pedir no final a senha de root, ou a do seu user para montar o dispositivo. Lembrando que pode deixar o hidden volume em No. Irei explicar do que se trata mais adiante.

para ver o seu dispositivo montado, vamos listar os volumes, com a opção --list.

[code] $ veracrypt --list 1: /home/berim/armz/TesteVeracrypt/containerfile /dev/mapper/veracrypt1 /home/berim/armz/TesteVeracrypt/pmnt [/code]

[POSIÇÃO]: [CONTAINER_PATH] [DISPOSITIVO] [PONTO DE MONTAGEM]

DESMONTANDO VOLUME Para desmontar o volume, basta usar a opção -d [volume_name]. Caso não seja passado o nome do volume, ele irar desmontar todos os volumes montados. Desmontando o volume containerfile.

[code] # veracrypt -d containerfile [/code]

Desmontando tudo

[code] # veracrypt -d [/code]

CRIANDO HIDDEN VOLUME - VOLUME OCULTO

Em alguns casos, revelar a senha do seu volume criptografado pode não ser uma escolha, por isso, seria muito mais inteligente se você tivesse, dentro desse volume, um outro volume escondido criptografado. Assim, a pessoa que forcou vc a dar sua senha, só teria acesso ao volume externo, onde não há nada de importante, sem saber da existência de outro volume secreto. A graça é que é impossível de se provar que existe algum volume secreto ali, já que ele fica camuflado entre os bytes. Seria como ter um cofre escondido dentro de outro cofre.

Hidden volume é um volume oculto criptografado dentro do container. O hidden volume é criado no espaço livre do volume externo criptografado. Como são bytes aleatórios, se torna impossivel de saber se tem ou não algum volume secreto ali, e assim, o seu hidden volume fica "camuflado" entre os bytes, sendo impossivel para uma outra pessoa confirma sua existência. Irei deixar uma imagem abaixo sobre isso.

Então, para criar um hidden volume, nós temos que primeiro criar um volume normal. Vamos seguir as etapas recomendadas pelo veracrypt.

1) criar um volume externo/normal sem sistemas de arquivos.

vou criar um container chamado volumeout, com 100MBs e sem filesystem, como indicado.

$ veracrypt -c volumeout --size 100M --volume-type normal --filesystem none

2) Criar um hidden volume dentro do volume externo use a opção de criar um volume e coloque o nome do volume ja criado, neste caso, o "volumeout". Mas dessa vez não vamos selecionar o tipo do volume como hidden(oculto). Selecionamos o tamanho do hidden volume, obviamente tem que ser menor do que o tamanho do volume externo. E logo depois o sistema de arquivos, vou escolher FAT.

NUNCA COLOQUE A MESMA SENHA NOS DOIS VOLUMES. VOCÊ PERDE ACESSO DO VOLUME OCULTO AO FAZER ISSO.

$ veracrypt -c volumeout --size 20M --volume-type hidden Encryption Algorithm: 1) AES 2) Serpent 3) Twofish 4) Camellia 5) Kuznyechik 6) AES(Twofish) 7) AES(Twofish(Serpent)) 8) Camellia(Kuznyechik) 9) Camellia(Serpent) 10) Kuznyechik(AES) 11) Kuznyechik(Serpent(Camellia)) 12) Kuznyechik(Twofish) 13) Serpent(AES) 14) Serpent(Twofish(AES)) 15) Twofish(Serpent) Select [1]: 1 Hash algorithm: 1) SHA-512 2) Whirlpool 3) SHA-256 4) Streebog Select [1]: 1 Filesystem: 1) None 2) FAT 3) Linux Ext2 4) Linux Ext3 5) Linux Ext4 6) NTFS 7) exFAT Select [2]: 2 Enter password:

3) Montar o volume externo usando o hidden volume protection.

Hidden volume protection, é uma opção que limita o tamanho do volume externo até onde o hidden volume começa na hora de montar, evitando que você sobreescreva o volume oculto. Toda vez que for escrever no volume externo, sempre escolha essa opção. Ele irá pedir a senha do volume externo e do oculto.

É importante que você coloque a opção de sistema de arquivos None, porque se não ele irá tentar montar e retornará um erro.

$ veracrypt volumeout pmnt/ --protect-hidden=yes --filesystem=None Enter password for /home/berim/armz/TesteVeracrypt/volumeout: Enter PIM for /home/berim/armz/TesteVeracrypt/volumeout: Enter keyfile [none]: Enter password for hidden volume: Enter PIM for hidden volume: Enter keyfile for hidden volume [none]: The hidden volume is now protected against damage until the outer volume is dismounted.

Provavelmente irá aparecer um aviso no seu, mas não se preocupe.

4) Criar um sistema de arquivos no dispositivo virtual do volume externo.

Para saber onde está o dispositivo virtual do nosso volume externo, vamos ver no comando --list.

$ veracrypt --list 1: /home/berim/armz/TesteVeracrypt/volumeout /dev/loop0 -

No segundo espaço, mostra que o dispositivo virtual do nosso container é /dev/loop0. Ok, agora vamos instalar um sistema de arquivos nele. Vou instalar FAT, sinta-se a vontade para instalar o seu.

$ sudo mkfs.vfat /dev/loop0 mkfs.fat 4.1 (2017-01-24)

5) Monte o novo sistema de arquivos e coloque dados.

Agora com o sistema de arquivos instalado, vamos montar ele.

$ sudo mount /dev/loop0 pmnt/ $ veracrypt --list 1: /home/berim/armz/TesteVeracrypt/volumeout /dev/loop0 /home/berim/armz/TesteVeracrypt/pmnt

No último comando, demos um list para verificar se nosso volume externo foi montado. Caso tenha dado tudo certo, vc ja pode colocar arquivos no volume externo. Lembre-se que o volume externo é apenas de faixada, portanto, não coloque nada importante nele. Eu coloquei arquivos aleatórios.

$ pwd /home/berim/armz/TesteVeracrypt/pmnt $ ls photo_2018-10-30_19-21-58.jpg powershell_v2_owners_manual.pdf projeto.pdf

6) Desmonte o volume externo && Montando hidden volume

Agora que ja montamos nosso volume de faixada, vamos montar nosso volume oculto. Use o -d para desmontar o volume externo.

Montando hidden volume

Agora, vamos montar nosso volume oculto. Para fazer isso, basta você fazer o procedimento de montagem normal, porém, colocando a senha do hidden volume, ao invés do volume externo, cool !.

$ veracrypt volumeout pmnt/ Enter password for /home/berim/armz/TesteVeracrypt/volumeout: Enter PIM for /home/berim/armz/TesteVeracrypt/volumeout: Enter keyfile [none]: Protect hidden volume (if any)? (y=Yes/n=No) [No]: $ veracrypt --list 1: /home/berim/armz/TesteVeracrypt/volumeout /dev/mapper/veracrypt1 /home/berim/armz/TesteVeracrypt/pmnt

Para confirmarmos que é o volume oculto montado, daremos o --volume-properties [nome_do_volume]

$ veracrypt --volume-properties volumeout Slot: 1 Volume: /home/berim/armz/TesteVeracrypt/volumeout Virtual Device: /dev/mapper/veracrypt1 Mount Directory: /home/berim/armz/TesteVeracrypt/pmnt Size: 19.9 MB Type: Hidden Read-Only: No Hidden Volume Protected: N/A Encryption Algorithm: AES Primary Key Size: 256 bits Secondary Key Size (XTS Mode): 256 bits Block Size: 128 bits Mode of Operation: XTS PKCS-5 PRF: HMAC-SHA-512 Volume Format Version: 2 Embedded Backup Header: Yes

Se você observar, no Type está escrito Hidden. Isso quer dizer que o tipo do volume montado é hidden, ou seja, volume oculto. Ai mostra algumas outras infos, como tamanho, key, etc.

Agora, vamos gravar algumas infos no volume oculto, vou colocar uma imagem chamada "nude.jpg".

Dentro do hidden volume.

$ ls nude.jpg $ pwd /home/berim/armz/TesteVeracrypt/pmnt

Pronto, agora é só desmontar e está pronto o nosso esquema. Agora, quando quiser montar um dos dois, é só colocar a senha correspondente. Lembre-se, se for gravar no volume externo, monte com protection-hidden para não sobreescrever os arquivos.

vamos ao teste simples.

[code] $ veracrypt volumeout pmnt/ Enter password for /home/berim/armz/TesteVeracrypt/volumeout: 123 Enter PIM for /home/berim/armz/TesteVeracrypt/volumeout: Enter keyfile [none]: Protect hidden volume (if any)? (y=Yes/n=No) [No]: $ ls pmnt/ photo_2018-10-30_19-21-58.jpg powershell_v2_owners_manual.pdf projeto.pdf $ veracrypt -d $ veracrypt volumeout pmnt/ Enter password for /home/berim/armz/TesteVeracrypt/volumeout: 12345 Enter PIM for /home/berim/armz/TesteVeracrypt/volumeout: Enter keyfile [none]: Protect hidden volume (if any)? (y=Yes/n=No) [No]: $ ls pmnt/ nude.jpg [/code]

Yeah, funcionou. Agora nossos nudes estão salvos.

Uma coisa legal que dá pra fazer com ele, infelizmente apenas em sistemas windows, é colocar ele no boot para descriptografar o HD, desse modo, o Sistema operacional que iniciar vai ser aquele que é correspondente a senha que você colocou. Imagine que você colocou o windows 10 em um volume com a senha 123, e um Kali Linux no hidden volume com a senha 1234. Quando você digitar a senha 123 do volume externo, iniciará o windows 10, quando digitar a senha 1234, iniciará o kali, interessante né?. Mas infelizmente só funciona com sistemas MBR. Mas vai que rola um gambiarra ai com cryptsetup né non? caso consiga, comenta ai em baixo. fui.

0 notes

0xmedeiros · 6 years ago

Text

Hidden Volume - Dmcrypt

Criptografar um volume pode ser muito útil, pois só vc tem acesso e pode guardar o que quiser lá dentro. Mas tem certas situações onde isso torna inútil. Imagine que você tenha lá o seu dispositivo criptografado e cheguem dois caras na sua porta e ameaçam afogar seu porquinho da índia no vazo sanitário se você não der a senha do seu dispositivo. Em um caso como esse não há como negar a sua senha, você não viveria sem o Tom. Por isso, um método muito bom, seria você ter, dentro desse dispositivo, um volume oculto criptografado onde ficaria os dados sigilosos. Seria como um cofre dentro de outro cofre, sacou? vamos lá.

CRIANDO O CONTAINER EXTERNO

Bom, vamos criar agora nosso container externo chamado cofre.img com o tamanho de 100MB e adicionar um endereço de loop. O endereço de loop vai apontar para o nosso img criada. Então /dev/loop0 = cofre.img

$ dd if=/dev/zero of=cofre.img bs=10M count=10 $ losetup /dev/loop0 cofre.img

Vamos criptografar ele com luks simples. Aqui, não é importante que você tenha uma senha forte, pois aqui será apenas uma faixada para o nosso cofre verdadeiro. Vamos também abrir ele com o nome de cofre1. Esse dispositivo irá ficar localizado em /dev/mapper/cofre1.

$ cryptsetup luksFormat /dev/loop0 $ cryptsetup luksOpen /dev/loop0 cofre1

aberto o nosso container, agora vamos enche-lo de dados aleatórios para ajudar na camuflagem do nosso volume oculto. Por que não zeros? porque com zeros seria fácil perceber que tem um amontoado de dados ali no meio.

$ dd if=/dev/urandom of=/dev/mapper/cofre1

Agora vamos formatar um sistema de arquivos para o dispositivo. Vou usar FAT. Sinta-se livre para escolher o seu.

$ mkfs.vfat /dev/mapper/cofre1

Agora, vamos montar cofre1 e jogar arquivos aleatorios para lá, só para deixar o volume externo de fachada mais convicente. Vou jogar uns books que tenho aqui só para exemplo.

É importante lembrar que, é extremamente perigoso escrever dados no volume externo após criar o volume oculto, há grandes chances de sobreescrever os dados dele. É recomendado que você grave os arquivos que você quer no volume externo antes de criar o volume oculto.

$ ls -l mount_pointer/ -rwxr-xr-x 1 root root 1597605 Dec 10 18:40 aprenda_computacao_com_python3_k.pdf -rwxr-xr-x 1 root root 7314537 Dec 10 18:40 Botnets.pdf -rwxr-xr-x 1 root root 173437 Dec 10 18:40 canivete-shell.pdf

Pronto, criamos nosso volume de faixada. Agora seu porquinho da índia Tom já tem uma chance de viver. Desmonte-o e vamos para o proximo passo

CRIANDO O VOLUME OCULTO CRIPTOGRAFADO

Bom, para criarmos nosso volume oculto, não usaremos LUKS. LUKS, por padrão, possui um header, onde possui informações sobre o volume como hash da senha, versão etc., Isso estragaria nossa camuflagem. Continuaria criptografado, porém não escondido, o que não é o nosso objetivo. Então, ao invés de usar o LUKS, vamos usar em modo Plain. O modo Plain, ao contrário do LUKS, é puro, então ele deixa que a gente mexa com blocos brutos sem nenhuma outra interferência. Portanto, ele não avisará se você colocar a senha ou o bloco incorreto, ele apenas irá aplicar o algoritmo.

O mais importante aqui é o offset, o setor de onde irá começar a leitura. Cada setor tem o tamanho de 512 bytes. Vamos olhar quanto setores tem no total do nosso container de 100MB usando o fdisk.

$ fdisk -l /dev/mapper/cofre1 Disk /dev/mapper/cofre1: <strong>98 MiB</strong>, 102760448 bytes, <strong>200704 sectors</strong> Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000

Nós temos o total de 200704 setores, como vamos colocar o nosso volume no meio, o valor do offset vai ser de 100352. 200704/2 = 100352.

Ele irá pedir uma senha e criará nosso volume oculto chamado de cofre2. Lembrando que, o modo plain não tem verificação de senha.

$ sudo cryptsetup --cipher=aes-xts-plain64 --offset=100352 plainOpen /dev/mapper/cofre1 cofre2

Pronto, agora temos nosso volume oculto criptografado. Agora vamos apenas formatar um sistema de arquivos para ele.

$ mkfs.vfat /dev/mapper/cofre2

Yeah, está feito, salvamos o Tom. agora é só montar ele e guardar suas tralhas. Lembrando que você tem que saber tanto a senha quanto o offset e a cifra, todos devem estar junto para descriptografar corretamente.

Agora vamos testar.

# cryptsetup luksOpen /dev/loop0 cofre1 Enter passphrase for /dev/loop0: # mount /dev/mapper/cofre1 mount_pointer/ # ls mount_pointer aprenda_computacao_com_python3_k.pdf Botnets.pdf canivete-shell.pdf # umount mount_pointer # sudo cryptsetup --cipher=aes-xts-plain64 --offset=100352 plainOpen /dev/mapper/cofre1 cofre2 Enter passphrase for /dev/mapper/cofre1: # mount /dev/mapper/cofre2 mount_pointer/ # ls mount_pointer/ HIDDEN receita_do_tom.txt

CONCLUSÃO

Este método é muito bom para esconder volumes para situações que a senha é inegável, porém, por conta de ser bruto, tem mais riscos de você fazer caca e acabar perdendo esses dados. De qualquer forma, salvamos a vida do Tom!

OBS: Eu perdi a referência original desse post, caso eu consiga achar será posto denovo aqui.

0 notes

0xmedeiros · 6 years ago

Text

Arquitetura de computador

A arquitetura de um computador descreve a suas características, como organização e funcionalidades. Para entendermos melhor, vamos falar sobre a arquitetura de um matemático húngaro chamado john von Neumman, mais conhecida como Arquitetura de von Neumman. Basicamente, a arquitetura de von Neumman se baseia em um banco de memória(chamado de Memoria Principa, ou Memoria Ram) e uma CPU(Central Processing Unit), ambos conectados por um barramento, mais chamado de bus, sua tradução em inglês.

A Memória Principal armazena tanto instruções, como dados, ambos são cadeia de bits, portanto, armazenados da mesma forma. A CPU é divida em duas unidades, a primeira é a UC(Unidade de Controle), que é responsável por buscar as instruções e dados armazenados na memória, através do barramento, para a segunda unidade ULA(Unidade Lógica Aritmética) que é responsável por executar essas instruções ariméticas, como(AND, NOT, etc). Algumas características dessa arquitetura:

- A Memória Principal Armazena apenas 0 e 1. dã. - Instruções e dados para a memória ram, são a mesma coisa, e armazenados na mesma forma. - Células são endereçadas na ordem, começando de 0. O tamanho de cada célula pode variar. John von Neumman acreditava que cada bit deveria ter seu endereço porém, hoje, as células são separadas em bytes, 8 bits.

ARQUITETURA INTEL 64

A intel vem desenvolvendo a sua arquitetura baseada na arquitetura de von Neumman, adicionando extensões para resolver alguns problemas. Vamos dar uma rápida visão na arquitetura intel 64.

Pilha de hardware é uma estrutura de dados que suporta apenas duas operações: push(inserção, o valor é copiado para a memória apartir do valor obtido da ESP) e pop(remoção, o elemento que está no topo da pilha é copiado para o registrador/memoria e removido). Ela é manipulada através de registradores de uso específico, como por exemplo, o ESP, que aponta para o ultimo elemento da pilha. Uma pilha pode ser usada para armazenar variáveis locais e salvar contexto de funções, por exemplo, se a função A chama a função B, ela guarda todo o contexto de A na pilha, para quando a função B terminar de executar ela poder retornar a execução da função A novamente.

Interrupções Essa extensão permite que eventos externos possam alterar a execução de um programa. Um sinal é captado e o programa passa a executar um outro código especifico para aquela situação. Por exemplo, uma tentativa de executar uma instrução inválida ou restrita.

Aneis de proteção Muito parecido com as permissão do linux, users, group etc. Cada anel define um conjunto de instruções permitidas. o Anel zero permite todas a as instruções existentes na CPU, seria como o root. o terceiro permite apenas instruções consideradas seguras, que não afetarão o Sistema Operacional. Praticamente todas as aplicações rodam no terceiro anel, afim de assegurar que o software não irá modificar dados criticos do sistema e também não irá trabalhar com diretamente dispositivos externos, sem consultar o SO. O primeiro e o segundo anel não são usados.

Memória Virtual Esse tipo de memória é uma abstração na memória física, criando um ambiente e isolado para os programas.

Registradores São células de memória temporária localizadas na parte interna da CPU, são extremamente rápidas(e caras) porém pequenas, o que faz que a memoria ram ainda seja necessária. Os registradores são classificados como:

- Registradores de uso geral: Podem ser usadas de várias formas. Se manja um pouco de assembly, ja deve ter visto em códigos x86 registradores como EAX, EBX, ECX, EDX, todos eles são registadores de uso geral. - Registradores de uso específico: São registradores específicos para uma tarefa importante. Acessado diretamente pela UC(Unidade de controle). Alguns deles em asm, ESP(stack pointer, indica o ultimo elemento da pilha), EIP(Instruction Pointer, indica a próxima função a ser executada). Se você já explorou a vulnerabilidade Buffer Overflow, provavelmente deve conhecer muito bem o EIP, é o registrador que usamos para desviar a rota de execução do programa para o nosso código na stack.

Memória Cache. Com o avanço da tech, os processadores foram podendo trabalhar cada vez com mais dados mais rápidamente, porém, isso gerou um problema, a velocidade de transmissão entre a Memória Principal e o CPU é limitada, o que ocasionou em um gargalo, prejudicando seriamente a velocidade do processador. Alguns mecanismos foram criados para "suavizar" esse problema. Baseado nisso, foi desenvolvido a Memória Cache, uma memória rápida que se localiza na CPU, como um registrador. E com isso veio junto o Principio da Localidade Temporal e espacial.

Localidade Temporal. Diz que um objeto acessado recentemente, tem grande probabilidade de ser acessado novamente, como por exemplo um em um loop.

Localidade Espacial. Diz que se um objeto A foi acessado recentemente, tem grande probabilidade de um objeto próximo a ele ser acesssado, no caso, B, C e D.

Após copiar uma parte dos dados da memória ram para a memória cache, esses dados são dividos em partes baseado na sua importância. A memória cache é, geralmente, divida em dois níveis(em alguns processadores é em três), L1 e L2. Em ordem crescente, cada nível tem mais espaço que o outro, porém, é mais lento. A CPU tenta organizar deixando os dados com mais importância, ou dados pequenos, nos niveis mais rápidos.

Então, basicamente, ele vai levar para a memória cache o que é mais usado, ou provavel irá ser usado, servindo como uma alternativa mais simples para evitar comunicação com a Memória Principal, e portanto, evitando tempo ocioso. Seria como colocar um vazo no quarto para evitar ir no banheiro e consequentemente o tempo afk, não que eu que faça isso claro.

Hierarquia de Memória

A hierarquia de memória, como na memória cache l1, l2, etc., funciona como um pirâmide, onde o topo é a memória mais veloz, porém a que tem menos espaço, e a base é a memória com maior espaço, porém a mais lenta. Quando um processador vai acessar uma determinado dado, ele procura do topo da pirâmide(registradores) até a base. Primeiro ele procura nos registradores, nos niveis da memória cache, e por ultimo, quando ele não achar nada nas memória superiores, ele parte para a Memória Principal(RAM).

0 notes

0xmedeiros · 7 years ago

Text

Bluetooth Network (PAN)

One day i was talking to my friend about a hacking with raspberry i wanted do, but i found a problem, how could i connect to raspberry ssh through bluetooth. At the first, i thought existed already app for this. But i discovered it's not so easy as i thought.

For make this connection, we need make a PAN(Personal Area Network) with Berry bluetooth.

So, lets go, baby.

IT'S SHOW TIME, BITCH!

First, we have make our Network Interface. This process is very simple, is just follow these following commands. If you are newbie in Linux, keep calm, i assure you these commands will not remove your HD. Or maybe will. hue.

Our network interface will be named pan0.

pan0 - 10.1.0.1/24

$ brctl addbr pan0 $ brctl setfd pan0 0 $ brctl stp pan0 off $ ifconfig pan0 10.1.0.1 netmask 255.255.255.0

Or if you are lazy, you can copy this and paste in your "/etc/network/interfaces".

auto pan0 iface pan0 inet static address 10.1.0.1 netmask 255.255.255.0 broadcast 10.1.0.255 bridge_ports none bridge_fd 0 bridge_stp off

Now we've created our interface, we need two python scripts.

btnap.py - this will do the magic.

blueagent5.py -this will create the pin for the pairing.

The script have two mode, the client mode and the server mode. But we'll use only the server mode. The script will also the network interface. In this case, pan0.

I put "&" in the end because i don't wanna open a new terminal.

$ python2 btnap.py server pan0 &

Now we'll start the our other script, blueagent5, it will do the pairing..

$ python2 blueagent5.py --pin 6666 &

Maybe your mobile i'snt discovering the berry bluetooth. If this is happening, allow the discovery mode with this following command.

$ hciconfig hci0 pisca

hci0, in this case, is our bluetooth interface, if your is different, just change there.

Done, bitch! we finished. Now is just connect the network, with your mobile, and connect the Berry ssh.

In my case, i use the terminal emulator Termux in my mobile.

YEAH!! i'm connected to the network! Now, i'll try connect to the berry ssh.

Yeah, we got, throught the bluetooth, make a ssh connection to the our raspberry.

Some mobiles don't allow you connect to the wifi and bluetooth at same time.

Good byte.

https://elinux.org/Bluetooth_Network

https://stackoverflow.com/questions/283 ... s/40579423

https://www.raspberrypi.org/forums/view ... p?t=182843

0 notes

0xmedeiros · 7 years ago

Text

PGP - GnuPG software

OpenPGP

OpenPGP é um padrão de criptografia que fuciona através de chaves assimétricas. Neste padrão, o usuário gera 2 chaves, uma pública e outra privada. A chave pública pode ser distribuída livremente, assim, o usuário que a possuí pode criptografar dados de modo que só quem tem a chave privada correspondende pode descriptografar. A chave privada também permite que o usuário possa assinar dados, assim, com a chave pública correspondente pode verificar se os dados foram realmente enviados pelo o dono e se o conteúdo não foi alterado.

GPG

Gnupg(GNU Privacy Guard) é uma ferramenta de Criptografia que segue o padrão OpenPGP, desenvolvida pelo FSF(Free Software Fundantion).

Para obter-lo no arch, nada mais do que

Code: Select all

$ sudo pacman -S gnupg

Gerando par de chaves

Para gerar um par de chaves no gpg, colocamos seguinte comando "gpg --full-gen-key". Em seguida ele pedirá o tipo de chave, podemos deixar padrão apenas dando [enter]

Code: Select all

Logo em seguida ele pedirá o tamanho da chave, podemos deixar padrão(2048 bits) dando [enter]

Code: Select all

Aqui podemos especificar o tempo de validade da chave.

w = semanas

m = mêses

y = Anos

0 = A chave não expira

Então eu posso colocar a data de validade de 2 anos ou seja 2y.

Se não quiser que sua chave tenha validade, coloque 0 ou apenas dê [enter]. Em seguida ele pedirá confirmação, coloque "y".

Code: Select all

$ gpg --full-gen-key gpg (GnuPG) 2.2.1; Copyright (C) 2017 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Por favor selecione o tipo de chave desejado: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (apenas assinatura) (4) RSA (apenas assinatura) Opção? RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) O tamanho de chave pedido é 2048 bits Por favor especifique por quanto tempo a chave deve ser válida. 0 = chave não expira = chave expira em n dias w = chave expira em n semanas m = chave expira em n meses y = chave expira em n anos A chave é valida por? (0) 0 Is this correct? (y/N) y

Aqui ele pedirá o nome, email e Comentário. O mais importante é o nome. Depois coloque "O" de para confirma

Code: Select all

Agora ele Abrirá uma janela pedindo sua nova senha e depois começará a gerar o seu par de chaves.

Tome cuidado para não perde a senha.

Importanto e exportando chaves

Para exportar sua chave pública, do par de chaves que você acabou de criar, digite o comando "gpg --export [USER-ID]"

Code: Select all

$ gpg --export darko > chave.key

Você tambem pode usar a opção "-a", irá produzir uma saida ASCII.

Code: Select all

$ gpg -a --export darko > chave.key

Você tambem pode exporta sua chave privada.

Ele solicitará a senha.

Code: Select all

$ gpg -a --export-secret-key darko > chave.key

Agora vamos pensar que seu amigo te mandou a chave pública dele e agora você precisa importa-la no seu chaveiro.

Code: Select all

$ gpg --import NomeDoArquivo

Agora podemos verificar chaves no seu chaveiro, com o comando

Code: Select all

$ gpg --list-keys

Criptografando e descriptografando dados

Para exemplo, vou criar um arquivo chamado "file" com "ola" dentro dele.

Para criptografar um arquivo com uma chave publica, vamos usar a opção "-e" ou "--encrypt". Use o comando "gpg -r [USER-ID] -e [nomedoarquivo]"

Code: Select all

$ gpg -r darko -e file

Ele criará um arquivo com o mesmo nome, porém, com o final ".gpg".

Do jeito anterior ele criará um arquivo binário, com a opção "-a", ele criará um arquivo com saida ASCII, isso pode ser útil para quem deseja usar isso por email.

Você tambem pode usar a opção "-o" para nomear o arquivo de saida. .

Code: Select all

$ gpg -a -r darko -o file.cript -e file $ cat file.cript .-----BEGIN PGP MESSAGE----- hQEMA6kU8t5a6kdXAQf/RjLO/tlUQglDJ2WKiN1BdXp5aPmSeN/4/xI0oRh8Sqgz +BYWeTayAIEtAw2XCNbcFasaPIdz97s06DyCjD1/UG2PIBys/ZjQQk6/loDbPE9r kOhDdebty4DwR3WgNmZxZ/rBjYmZSoMpK2LlOtD14n6HxJKRR3PzSowllKYwxdm2 neYrebOVWYczKdi25xh5bS2Ewmr14eY4WFgPGNmtSQbow5kGyQ9wqzNUfDtcay8w uUPHh3ROFB4z6tx9SVuAZm03uf5aT5JDLkzOjGpOP2BRtW0uzY3VVEJZCrGFbdA+ /EeBHmLSUzGHAd5acj/sd2nx7Ts6qM+CFxIBbIcYZNJDAUUvfSRot0qdD+xMvjBq DWuJFsnrhCqD2GkMojlG/TE3n3q8DrFFfMKD8QsvWj0pla7pNlaWRkfAzQUrCC3V sXvQDA== =IIO3 .-----END PGP MESSAGE-----

Isso tudo é o simples "ola".

Agora seu amiguinho nerd e tarado te mandou um nudes criptografado com sua chave pública, vamos descriptografar com a opção "-d" ou "--decrypt".

A senha da sua chave privada será solicitada.

Code: Select all

$ gpg -r darko -o file.decrypt -d file.cript gpg: encrypted with 2048-bit RSA key, ID A914F2DE5AEA4757, created 2017-11-05 "darko <[email protected]>" $ cat file.decrypt ola

Assinar chave pública

O que assinatura de arquivos? assinatura é basicamente o caminho inverso. Com a chave pública ao vai descriptografar seu arquivo criptografado com a chave privada. Assim, confirmando que o arquivo foi enviado realmente por você. Assim você pode provar que documentos, script, msgs e etc., foram enviadas por você.

GPG fuciona em uma relação de confiança. Quanto mais assinaturas na sua chave, maior será o relação de confiança, tome cuidado.

Code: Select all

$ gpg --sign-key [USER-ID]

Para assinar um arquivo usando sua chave privada.

Para fazer uma assinatura em ASCII você pode trocar "--sign" por"--clearsign".

Lembrando que é mais fácil você usar na hora de criptografar um arquivo.

Code: Select all

$ gpg --sign [nomedoarquivo]

Para verificar assinatura.

Code: Select all

$ gpg --verify [nomedoarquivo]

Se encontrar um erro, seja técnico quanto gramátical, pode deixar ai embaixo.

Bom, por hoje é só, até.

0 notes