Adicionando o controle de versão

Primeiramente é necessário criar o controle de versionamento de código para adicionar o repositório ao cpanel, para realizar isso basta navegar na página inicial da hospedagem e acessar o controler de versionamento.

Após acessar, clique em criar!

Nesta aba é onde será configurado o repositório. Para então adicionar o repositório tem que adicionar uma chave SSH para o CPANEL conseguir se comunicar com o GitHub, em caso de um repositório privado, caso seja um projeto open-source poderá pular a etapa de configuração da chave SSH.

Adicionando uma chave SSH

Para adicionar uma chave SSH, clique em SSH Access dentro da página representada anteriormente. Agora nesta nova aba, clique em Manage SSH Keys.

Depois de realizar essas operações então em Generate a New key para gerar uma nova chave SSH, essa chave será adicionada porteriormente dentro do GitHub.

Com a nova aba aberta, preencha as informações e prossiga clicando em Generate Key.

Depois disso, a chave será criada então volte para a lista de chaves clicando em Go back.

Agora é necessário liberar a chave para uso. Na página inicial do gerênciamento de chave clique em Manage.

E, então clique em Authorize para liberar a sua chave para uso. Feito isso clique em Go Back.

Na página incial do gerenciamento de chaves há 2 chaves que foram geradas. Clique para visualizar a chave pública em View/Download.

Agora tem a sua chave autorizada, copie ela!

Neste passo, então, abra uma nova aba e acesse a sua conta no GitHub e acesse o seu perfil. No menu lateral clique na opção SSH and GPG Keys. Apos fazer isso clique em New SSH Key.

Adicione um título e cole a chave SSH pública que foi copiada nos passos anteriores. Feito isso, clique em Add SSH key.

Agora foi adicionado a chave SSH ao seu GitHub e o CPANEL poderá ter acesso ao seu repositório privado ou público.

Finalizando a configuração do repositório

Se o seu repositório for privado, é importante que antes de começar está etapa você tenha configurado corretamente a chave SSH, conforme demonstrado na etapa anterior*.*

Para começar vá até o repositório que deseja adicionar ao CPANEL copie o link de cópia dele.

Cole o link do seu repositório no campo Clone URL. Logo após, clique em create para criar o versionamento de código do seu repositório.

Configuração do repositório finalizada com sucesso no CPANEL, agora clique em Manage para gerenciar o seu repositório adicionado.

Nesta página poderá realizar algumas configurações, como por exemplo definir qual branch será a padrão do projeto. Neste caso está a branch main como padrão. Mantenha o que está e clique em Pull or Deploy.

Nesta aba é a que será utilizada para realizar o pull e deploy da aplicação.

Entretanto antes de clicar para realizar o pull e deploy da sua aplicação é necessário realizar algumas configurações no seu repositório. Crie um arquivo chamado .cpanel.yml e adicione o seguinte conteúdo:

deployment:
  tasks:
    - export DEPLOYPATH=/home/hsesafetycom/public_html/
    - rm -rf $DEPLOYPATH
    - /bin/cp -R build/. $DEPLOYPATH

Neste conteúdo estamos dizendo que vamos deletar e copiar todos os arquivos de dentro pasta build para a pasta public_html. Para que isso seja obedecido é necessário remover do .gitignore a pasta build.

Agora compile o seu projeto rodando npm run build e então efetue o push para a sua branch remota. Sua branch de deploy terá que conter a pasta build pois ela será movida para a public no momento do deploy.

Se o seu repositório estiver assim na branch de deploy você pode voltar para o Cpanel baixar as atualizações e clicar em deploy.

Recarregue a página e clique Deploy HEAD Commit feito isso seu deploy já está pronto. Agora toda alteração dentro da sua branch main você terá que entrar no CPANEL, baixar as atualizações e realizar o deploy! Para confirmar se está certo você poderá acessar o file manager e clicar em public_html feito isso seus arquivos da pasta build vão estar lá!

OBS: Infelizmente não consegui deixar isso automatizado e essa foi a melhor forma para fugitr do FTP.

Sorry about any english errors, I'm practicing and learning english.

What is Security Misconfiguration?

A security misconfiguration is a vulnerability that explore the bad configuration in application. This can be included:

• Apps with default credentials
• Bad configuration on the server like S3 bucket.
• Error messages that allow the attacker explore more about the system.
• IoT devices with default passowords.

Generally this vulnerability allow the attacker lead to more vulnerabilities like data explosure, XXE Attacks, RCE and others.

Where to find labs to practice?

Labs to practice can be find on some platforms like Try Hack Me and another alternative is practice yourself devices that have default credentials with this your leave more security the house devices and avoid the external attacks while are praticing.

Obs: Para começar o reconhecimento deste desafio é necessário fazer o download dos arquivos do web site dentro da plataforma do hack the box.

Reconhecimento

Depois de fazer o download dos arquivos comecei então a navegar pela página web do site para ver se encontrava algum campo que possibilitasse a exploração de alguma vulnerabilidade, entretanto foi sem sucesso e então comecei a analisar o código em PHP. Logo de cara me deparei que a página principal do site estava sendo serializada dentro do cookie que é gerado ao carregar a página index.

Analisando previamente esse código o que ele está fazendo é:

Ao carregar a página é invocado a função spl_autoload_register que armazena uma função anônima que inclui um arquivo PHP. Após essa inclusão é verificado se existe um cookie na sessão identificado por PHPSESSID, caso não tenha será registrado utilizando a função setcookie onde:

• PHPSSEID: é a chave de acesso para o cookie;
• base64_encode(serialize($page)): é o conteúdo do cookie;
• time()+60\*60\*24: é o tempo que o cookie vai durar;
• /: é o local em que o cookie ta indexado.

Mas o mais importante neste caso é o conteúdo do cookie que possui um objeto serializado:

 Utilizando a função serialize($page) para serializar um objeto você obterá a seguinte saída: 

O:9:"PageModel":1:{s:4:"file";s:15:"/www/index.html";}

Onde: 
   O:9:"PageModel": representa o objeto serializado; 
   s:4:"file"; Representa o atributo da classe que está sendo utilizado; 
   s:15:"/www/index.html"; Representa o conteúdo do atributo file e também o arquivo que será incluído na página ao ser carregada;

E por final temos a função base64_encode que codifica em base64 a string retornada pelo serialize(). 
Representando a seguinte saída: 

Tzo5OiJQYWdlTW9kZWwiOjE6e3M6NDoiZmlsZSI7czoxNToiL3d3dy9pbmRleC5odG1sIjt9

Agora que o código está explicado fica fácil de continuar a exploração, significa então que podemos alterar essa string codificada em base64 apontando o arquivo que queremos encontrar na raiz do sistema e incluí-lo na página. Então utilizando o burp suite Community utilizei o recurso de proxy para interceptar a requisição e mandar para o repeater para conseguir enviar payloads ao servidor de uma forma mais fácil.

Dentro do repeater podemos então modificar o cabeçalho da requisição, mas antes de começarmos a injetar payloads vamos dar uma analisada no arquivo de configuração do servidor que é o nginx.conf, esse arquivo é responsável por toda a configuração do servidor.

Neste arquivo temos:

O mais interessante deste arquivo é que temos o caminho completo do arquivo de log do servidor, com isso sabemos que todo o header da requisição é registrada neste arquivo. Sabendo disso podemos visualizar o arquivo de log seguindo a mesma lógica que é codificar o objeto serializable e colocar no PHPSESSID.

Depois de codificado em base64 é necessário colocar essa string no header da aplicação e enviá-lo para o servidor nos retornando assim o arquivo de logs.

Bom, agora que sabemos que todo o header é registrado neste arquivo de log e que podemos acessar este arquivo através do payload, vamos evoluir essa exploração para execução de código remoto enviando um código em PHP através do body.

Note que o payload foi executado com sucesso e que temos um arquivo de flag no diretório raiz do sistema, podemos então usar a mesma lógica que é usada para acessar o arquivo de log para acessar o arquivo de flag!

E agora é só substituir o novo valor do PHPSESSID e pontuar!!!

Vamos lá!

Reconhecimento: Para iniciar o reconhecimento da máquina comecei com uma varredura utilizando o nmap.

sudo nmap -sV -sC 10.10.11.156

Enumeração: Note que há 2 serviços rodando nesta máquina, um fornecendo um acesso ao site através do protocolo HTTP e o outro um acesso SSH.

Após acessar o site, resolvi então navegar um pouco no código fonte para ver se encontrava algo de útil para começar a explorar mais a fundo e encontrei o seguinte trecho de código:

Repare que há um link dizendo que podemos utilizar um editor de imagem dentro do site, no entanto para conseguir acessar este subdomínio é necessário configurar o arquivo hosts da sua máquina local ficando da seguinte forma:

Salve o arquivo e agora você poderá acessar o através do dns images.late.htb Repare que nesta página tem várias informações úteis para dar início a uma exploração mais avançada, como com o que foi desenvolvido o conversor de imagem para texto. Antes de sair buscando por vulnerabilidades da tecnologia do Flask resolvi testar um pouco e entender como funciona o conversor de imagem, então subi uma imagem JPG e o conversor me retornou um arquivo results.txt contendo:
<p></p>

Através desse resultado não ficou muito claro o que estava fazendo em si, então resolvi buscar alguns conversores de imagem para texto no GitHub feito em flask e encontrei o seguinte exemplo: Extractor Image Text.

Com esse código ficou mais claro o que o conversor estava fazendo que era: pegar uma imagem e extrair o texto que está nela e não um texto que está como esteganografia; Sabendo disso, então resolvi injetar alguns payloads de Server Side Template Injection (SSTI) como texto das imagens e para isso eu desenvolvi um exploit para facitar a manipulação dos payloads e envio da imagem para ser através do script e não do site.

Exploi: Late Hack the Box - Exploit SSTI

Utilizando o exploit que criei, então fiz um payload simples:

Olhe que há um teste de soma, se o aplicativo estiver vulnerável o exploit deverá retornar o 2 como saída pois foi efetuado a soma, e ao executar o exploit temos a seguinte saída:

Boom! Está vulnerável, agora podemos buscar payloads mais avançados e evoluir a exploração para remote code execution, para isso eu utilizei o repositório Payload All The Things e peguei o seguinte payload:

Veja que eu peguei um payload que me permite fazer a excução de comandos do sistema operacional, e alterei o exploit para que ele receba esse novo payload com os comandos do sistema operacional, ao executar o exploit.py com essa alteração ele retornará a seguinte saída:

O comando ls -l foi executado com sucesso! Agora podemos visualizar os usuários do sistema com o os_command: cat /etc/passwd

Repare que temos um usuário chamado svc_acc e que também podemos visualizar o diretório deste usuário com: ls -la /home/svc_acc

Neste diretório temos um arquivo chamado user.txt que representa a nossa primeira flag!

Mas e agora, Acabou a exploração? Ainda não! Precisamos da segunda flag que é a system e para isso precisamos conseguir acesso ao sistema operacional para elevar nossos níveis de usuário e procurar a próxima flag. Ué, mas já temos acesso ao sistema por command injection não temos? Sim, mas desta forma é muito ruim para manter uma exploração efetiva dentro do sistema, teremos que usar o serviço de ssh para conseguir acesso. Para isso vemos na listagem dos arquivo dos usuário svc_acc que tem um diretório .ssh que geralmente costumam ficar as chaves de acesso ssh.

Temos uma chave ssh para acessar o sistema como o usuário svc_acc, para pega-lá execute: cat /hove/svc_acc/.ssh/id_rsa

Bom, conseguimos a chave id_rsa agora podemos utiliza-lá para conectar através do protocolo ssh como o usuário svc_acc. Copie a chave id_rsa para um arquivo chamado id_rsa e utilize: ssh svc_acc@[machine_ip] -i id_rsa para conectar como o usuário svc_acc.

Provavelmente ao tentar se conectar o seu pode ter dado este erro também, isso se dá porque a chave pode ser lida pelo usuário, grupo e qualquer acesso remoto ao computador e sendo assim é considerada uma chave não segura.

Para resolver basta alterar as permissões de acesso da chave para somente o usuário conseguir acessar/ler/escrever na chave com: chmod 600 id_rsa

Agora que foi alterado a permissão podemos executar novamente: ssh svc_acc@[machine_ip] -i id_rsa para conectar a máquina.

ATENÇÃO: cuidado ao copiar a chave id_rsa, pois qualquer linha a mais mesmo em branco pode resultar na saída que a chave está inválida.

Então já que temos acesso precisamos conseguir acesso root ao sistema. Primeiro vamos olhar o que há no crontab do sistema.

O PATH:/usr/local/sbin/ é o caminho onde fica os scripts de execução do cronjob no sistema, se você der crontab -e não mostrará nenhuma configuração adicionada pois essa configuração foi realizada somente para o usuário root então pode existir X jobs configurados se você não tiver permissão não irá conseguir ver. Agora liste os arquivos do diretório /usr/local/sbin/ e teremos:

Um arquivo executável que provavelmente será executado em algum momento por algum trigger ou agendamento de tarefas, repare também que podemos ler e executar esse arquivo, então iremos ler primeiramente:

Com uma leitura básica do código da para perceber que o script é acionado toda vez que um usuário acessar a máquina via SSH. Sabendo disso vamos ver as propriedades do arquivo através do comando lsattr esse comando permite fazer alguns tipos de alterações no arquivo, caso não conheça pode dar uma olhada em:

Trabalhando com atributos de arquivos

Note que possui o atributo “a” que significa que podemos modificar este arquivo anexando o conteúdo nele, então com isso podemos atribuir um shell-reverso dentro do arquivo ssh-alert.sh

Agora pode conferir se o shell foi atribuído ao arquivo que será executado:

Repare que o comando foi adicionado ao arquivo e assim que o arquivo for executado já poderemos acessar através do shell reverso, para isso ligue uma porta para ouvir uma conexão do alvo:

Agora com o nc ouvindo a conexão podemos executar o trigger do arquivo ssh-alert.sh através de uma nova conexão ssh com o usuário svc_acc.

E então conseguimos acesso root ao sistema!!!!

Agora é só visualizar a sua flag e pontuar!!!

Considerações finais:
Pessoalmente achei esta máquina relativamente difícil pois não estava conseguindo encontrar uma forma de conseguir acesso root, e para isso precisei olhar alguns outros writeups desta máquina. Entretanto de modo geral consegui resolver 85% da máquina conseguindo chegar até ao acesso do usuário svc_acc sozinho.