Linux Capabilities
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON é o evento de cibersegurança mais relevante na Espanha e um dos mais importantes na Europa. Com a missão de promover o conhecimento técnico, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e cibersegurança em todas as disciplinas.\
Linux Capabilities
As capacidades do Linux dividem os privilégios de root em unidades menores e distintas, permitindo que processos tenham um subconjunto de privilégios. Isso minimiza os riscos ao não conceder privilégios de root completos desnecessariamente.
O Problema:
Usuários normais têm permissões limitadas, afetando tarefas como abrir um socket de rede que requer acesso root.
Conjuntos de Capacidades:
Inherited (CapInh):
Propósito: Determina as capacidades transmitidas do processo pai.
Funcionalidade: Quando um novo processo é criado, ele herda as capacidades de seu pai neste conjunto. Útil para manter certos privilégios durante a criação de processos.
Restrições: Um processo não pode ganhar capacidades que seu pai não possuía.
Effective (CapEff):
Propósito: Representa as capacidades reais que um processo está utilizando em qualquer momento.
Funcionalidade: É o conjunto de capacidades verificadas pelo kernel para conceder permissão para várias operações. Para arquivos, este conjunto pode ser uma flag indicando se as capacidades permitidas do arquivo devem ser consideradas efetivas.
Significado: O conjunto efetivo é crucial para verificações imediatas de privilégios, atuando como o conjunto ativo de capacidades que um processo pode usar.
Permitted (CapPrm):
Propósito: Define o conjunto máximo de capacidades que um processo pode possuir.
Funcionalidade: Um processo pode elevar uma capacidade do conjunto permitido para seu conjunto efetivo, dando-lhe a capacidade de usar essa capacidade. Ele também pode descartar capacidades de seu conjunto permitido.
Limite: Atua como um limite superior para as capacidades que um processo pode ter, garantindo que um processo não exceda seu escopo de privilégio predefinido.
Bounding (CapBnd):
Propósito: Coloca um teto nas capacidades que um processo pode adquirir durante seu ciclo de vida.
Funcionalidade: Mesmo que um processo tenha uma certa capacidade em seu conjunto herdável ou permitido, ele não pode adquirir essa capacidade a menos que também esteja no conjunto de limites.
Caso de uso: Este conjunto é particularmente útil para restringir o potencial de escalonamento de privilégios de um processo, adicionando uma camada extra de segurança.
Ambient (CapAmb):
Propósito: Permite que certas capacidades sejam mantidas durante uma chamada de sistema
execve
, que normalmente resultaria em um reset completo das capacidades do processo.Funcionalidade: Garante que programas não-SUID que não têm capacidades de arquivo associadas possam reter certos privilégios.
Restrições: As capacidades neste conjunto estão sujeitas às restrições dos conjuntos herdáveis e permitidos, garantindo que não excedam os privilégios permitidos do processo.
Para mais informações, consulte:
Capacidades de Processos & Binários
Capacidades de Processos
Para ver as capacidades de um processo específico, use o arquivo status no diretório /proc. Como ele fornece mais detalhes, vamos limitá-lo apenas às informações relacionadas às capacidades do Linux. Observe que para todos os processos em execução, as informações de capacidade são mantidas por thread; para binários no sistema de arquivos, são armazenadas em atributos estendidos.
Você pode encontrar as capacidades definidas em /usr/include/linux/capability.h
Você pode encontrar as capacidades do processo atual em cat /proc/self/status
ou fazendo capsh --print
e de outros usuários em /proc/<pid>/status
Este comando deve retornar 5 linhas na maioria dos sistemas.
CapInh = Capacidades herdadas
CapPrm = Capacidades permitidas
CapEff = Capacidades efetivas
CapBnd = Conjunto de limites
CapAmb = Conjunto de capacidades ambientais
Esses números hexadecimais não fazem sentido. Usando a utilidade capsh, podemos decodificá-los nos nomes das capacidades.
Vamos verificar agora as capabilities usadas pelo ping
:
Embora isso funcione, há outra maneira mais fácil. Para ver as capacidades de um processo em execução, basta usar a ferramenta getpcaps seguida pelo seu ID de processo (PID). Você também pode fornecer uma lista de IDs de processo.
Vamos verificar aqui as capacidades do tcpdump
após ter dado ao binário capacidades suficientes (cap_net_admin
e cap_net_raw
) para monitorar a rede (tcpdump está rodando no processo 9562):
Como você pode ver, as capacidades dadas correspondem aos resultados das 2 maneiras de obter as capacidades de um binário. A ferramenta getpcaps usa a chamada de sistema capget() para consultar as capacidades disponíveis para um determinado thread. Esta chamada de sistema só precisa fornecer o PID para obter mais informações.
Capacidades de Binários
Os binários podem ter capacidades que podem ser usadas durante a execução. Por exemplo, é muito comum encontrar o binário ping
com a capacidade cap_net_raw
:
Você pode procurar binários com capacidades usando:
Removendo capacidades com capsh
Se removermos as capacidades CAP_NET_RAW para ping, então a utilidade ping não deve mais funcionar.
Além da saída do capsh em si, o comando tcpdump também deve gerar um erro.
/bin/bash: /usr/sbin/tcpdump: Operação não permitida
O erro mostra claramente que o comando ping não tem permissão para abrir um socket ICMP. Agora sabemos com certeza que isso funciona como esperado.
Remover Capacidades
Você pode remover capacidades de um binário com
User Capabilities
Aparentemente é possível atribuir capacidades também a usuários. Isso provavelmente significa que cada processo executado pelo usuário poderá usar as capacidades do usuário.
Baseado em isso, isso e isso, alguns arquivos precisam ser configurados para dar a um usuário certas capacidades, mas o que atribui as capacidades a cada usuário será /etc/security/capability.conf
.
Exemplo de arquivo:
Capabilidades de Ambiente
Compilando o seguinte programa, é possível gerar um shell bash dentro de um ambiente que fornece capacidades.
Dentro do bash executado pelo binário de ambiente compilado, é possível observar as novas capacidades (um usuário regular não terá nenhuma capacidade na seção "atual").
Você só pode adicionar capacidades que estão presentes tanto no conjunto permitido quanto no conjunto herdável.
Binários cientes de capacidade / Binários sem capacidade
Os binários cientes de capacidade não usarão as novas capacidades fornecidas pelo ambiente, no entanto, os binários sem capacidade as usarão pois não as rejeitarão. Isso torna os binários sem capacidade vulneráveis dentro de um ambiente especial que concede capacidades a binários.
Capacidades de Serviço
Por padrão, um serviço executado como root terá todas as capacidades atribuídas, e em algumas ocasiões isso pode ser perigoso. Portanto, um arquivo de configuração de serviço permite especificar as capacidades que você deseja que ele tenha, e o usuário que deve executar o serviço para evitar executar um serviço com privilégios desnecessários:
Capabilities in Docker Containers
Por padrão, o Docker atribui algumas capacidades aos contêineres. É muito fácil verificar quais são essas capacidades executando:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON é o evento de cibersegurança mais relevante na Espanha e um dos mais importantes na Europa. Com a missão de promover o conhecimento técnico, este congresso é um ponto de encontro fervente para profissionais de tecnologia e cibersegurança em todas as disciplinas.
Privesc/Escape de Container
As capacidades são úteis quando você quer restringir seus próprios processos após realizar operações privilegiadas (por exemplo, após configurar chroot e vincular a um socket). No entanto, elas podem ser exploradas passando comandos ou argumentos maliciosos que são então executados como root.
Você pode forçar capacidades em programas usando setcap
, e consultar essas usando getcap
:
O +ep
significa que você está adicionando a capacidade (“-” removeria) como Eficaz e Permitida.
Para identificar programas em um sistema ou pasta com capacidades:
Exemplo de exploração
No seguinte exemplo, o binário /usr/bin/python2.6
é encontrado vulnerável a privesc:
Capacidades necessárias pelo tcpdump
para permitir que qualquer usuário capture pacotes:
O caso especial das capacidades "vazias"
Dos docs: Note que é possível atribuir conjuntos de capacidades vazios a um arquivo de programa, e assim é possível criar um programa set-user-ID-root que altera o set-user-ID efetivo e salvo do processo que executa o programa para 0, mas não confere capacidades a esse processo. Ou, simplificando, se você tem um binário que:
não é propriedade do root
não tem bits
SUID
/SGID
definidostem conjuntos de capacidades vazios (por exemplo:
getcap myelf
retornamyelf =ep
)
então esse binário será executado como root.
CAP_SYS_ADMIN
CAP_SYS_ADMIN
é uma capacidade Linux altamente potente, frequentemente equiparada a um nível quase root devido aos seus extensos privilegios administrativos, como montar dispositivos ou manipular recursos do kernel. Embora seja indispensável para contêineres que simulam sistemas inteiros, CAP_SYS_ADMIN
apresenta desafios significativos de segurança, especialmente em ambientes containerizados, devido ao seu potencial para escalonamento de privilégios e comprometimento do sistema. Portanto, seu uso exige avaliações de segurança rigorosas e gerenciamento cauteloso, com uma forte preferência por descartar essa capacidade em contêineres específicos de aplicativos para aderir ao princípio do menor privilégio e minimizar a superfície de ataque.
Exemplo com binário
Usando python, você pode montar um arquivo passwd modificado em cima do arquivo passwd real:
E finalmente monte o arquivo passwd
modificado em /etc/passwd
:
E você poderá su
como root usando a senha "password".
Exemplo com ambiente (Docker breakout)
Você pode verificar as capacidades habilitadas dentro do contêiner docker usando:
Dentro da saída anterior, você pode ver que a capacidade SYS_ADMIN está habilitada.
Montar
Isso permite que o contêiner docker monte o disco do host e acesse-o livremente:
Acesso total
No método anterior, conseguimos acessar o disco do host docker. Caso você descubra que o host está executando um servidor ssh, você poderia criar um usuário dentro do disco do host docker e acessá-lo via SSH:
CAP_SYS_PTRACE
Isso significa que você pode escapar do contêiner injetando um shellcode dentro de algum processo em execução no host. Para acessar processos em execução no host, o contêiner precisa ser executado pelo menos com --pid=host
.
CAP_SYS_PTRACE
concede a capacidade de usar funcionalidades de depuração e rastreamento de chamadas de sistema fornecidas por ptrace(2)
e chamadas de anexação de memória cruzada como process_vm_readv(2)
e process_vm_writev(2)
. Embora seja poderoso para fins de diagnóstico e monitoramento, se CAP_SYS_PTRACE
estiver habilitado sem medidas restritivas, como um filtro seccomp em ptrace(2)
, isso pode comprometer significativamente a segurança do sistema. Especificamente, pode ser explorado para contornar outras restrições de segurança, notavelmente aquelas impostas pelo seccomp, como demonstrado por provas de conceito (PoC) como esta.
Exemplo com binário (python)
Exemplo com binário (gdb)
gdb
com a capacidade ptrace
:
Crie um shellcode com msfvenom para injetar na memória via gdb
Depure um processo root com gdb e copie e cole as linhas gdb geradas anteriormente:
Exemplo com ambiente (Docker breakout) - Outro abuso do gdb
Se GDB estiver instalado (ou você puder instalá-lo com apk add gdb
ou apt install gdb
, por exemplo), você pode depurar um processo do host e fazer com que ele chame a função system
. (Esta técnica também requer a capacidade SYS_ADMIN
).
Você não poderá ver a saída do comando executado, mas ele será executado por esse processo (então obtenha um rev shell).
Se você receber o erro "No symbol "system" in current context.", verifique o exemplo anterior carregando um shellcode em um programa via gdb.
Exemplo com ambiente (Docker breakout) - Injeção de Shellcode
Você pode verificar as capacidades habilitadas dentro do contêiner docker usando:
Liste processos em execução no host ps -eaf
Obtenha a arquitetura
uname -m
Encontre um shellcode para a arquitetura (https://www.exploit-db.com/exploits/41128)
Encontre um programa para injetar o shellcode na memória de um processo (https://github.com/0x00pf/0x00sec_code/blob/master/mem_inject/infect.c)
Modifique o shellcode dentro do programa e compile-o
gcc inject.c -o inject
Injete e pegue seu shell:
./inject 299; nc 172.17.0.1 5600
CAP_SYS_MODULE
CAP_SYS_MODULE
capacita um processo a carregar e descarregar módulos do kernel (init_module(2)
, finit_module(2)
e delete_module(2)
chamadas de sistema), oferecendo acesso direto às operações principais do kernel. Essa capacidade apresenta riscos críticos de segurança, pois permite a escalada de privilégios e a total comprometimento do sistema ao permitir modificações no kernel, contornando assim todos os mecanismos de segurança do Linux, incluindo Módulos de Segurança do Linux e isolamento de contêineres.
Isso significa que você pode inserir/remover módulos do kernel no/do kernel da máquina host.
Exemplo com binário
No exemplo a seguir, o binário python
possui essa capacidade.
Por padrão, o comando modprobe
verifica a lista de dependências e arquivos de mapa no diretório /lib/modules/$(uname -r)
.
Para abusar disso, vamos criar uma pasta falsa lib/modules:
Então compile o módulo do kernel que você pode encontrar 2 exemplos abaixo e copie para esta pasta:
Finalmente, execute o código python necessário para carregar este módulo do kernel:
Exemplo 2 com binário
No exemplo a seguir, o binário kmod
possui esta capacidade.
O que significa que é possível usar o comando insmod
para inserir um módulo do kernel. Siga o exemplo abaixo para obter um reverse shell abusando desse privilégio.
Exemplo com ambiente (Docker breakout)
Você pode verificar as capacidades habilitadas dentro do contêiner docker usando:
Dentro da saída anterior, você pode ver que a capacidade SYS_MODULE está habilitada.
Crie o módulo do kernel que vai executar um shell reverso e o Makefile para compilá-lo:
O caractere em branco antes de cada palavra make no Makefile deve ser uma tabulação, não espaços!
Execute make
para compilá-lo.
Finalmente, inicie nc
dentro de um shell e carregue o módulo de outro e você capturará o shell no processo nc:
O código desta técnica foi copiado do laboratório de "Abusing SYS_MODULE Capability" de https://www.pentesteracademy.com/
Outro exemplo desta técnica pode ser encontrado em https://www.cyberark.com/resources/threat-research-blog/how-i-hacked-play-with-docker-and-remotely-ran-code-on-the-host
CAP_DAC_READ_SEARCH
CAP_DAC_READ_SEARCH permite que um processo ignore permissões para leitura de arquivos e para leitura e execução de diretórios. Seu uso principal é para fins de busca ou leitura de arquivos. No entanto, também permite que um processo use a função open_by_handle_at(2)
, que pode acessar qualquer arquivo, incluindo aqueles fora do namespace de montagem do processo. O identificador usado em open_by_handle_at(2)
deve ser um identificador não transparente obtido através de name_to_handle_at(2)
, mas pode incluir informações sensíveis, como números de inode, que são vulneráveis a manipulação. O potencial de exploração dessa capacidade, particularmente no contexto de contêineres Docker, foi demonstrado por Sebastian Krahmer com o exploit shocker, conforme analisado aqui. Isso significa que você pode ignorar as verificações de permissão de leitura de arquivos e as verificações de permissão de leitura/execução de diretórios.
Exemplo com binário
O binário será capaz de ler qualquer arquivo. Portanto, se um arquivo como tar tiver essa capacidade, ele poderá ler o arquivo shadow:
Exemplo com binary2
Neste caso, vamos supor que o binário python
tenha essa capacidade. Para listar arquivos do root, você poderia fazer:
E para ler um arquivo, você poderia fazer:
Exemplo em Ambiente (quebra de Docker)
Você pode verificar as capacidades habilitadas dentro do contêiner docker usando:
Dentro da saída anterior, você pode ver que a capacidade DAC_READ_SEARCH está habilitada. Como resultado, o contêiner pode debugar processos.
Você pode aprender como a seguinte exploração funciona em https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3, mas em resumo, CAP_DAC_READ_SEARCH não apenas nos permite percorrer o sistema de arquivos sem verificações de permissão, mas também remove explicitamente quaisquer verificações para open_by_handle_at(2) e pode permitir que nosso processo acesse arquivos sensíveis abertos por outros processos.
O exploit original que abusa dessas permissões para ler arquivos do host pode ser encontrado aqui: http://stealth.openwall.net/xSports/shocker.c, a seguir está uma versão modificada que permite indicar o arquivo que você deseja ler como primeiro argumento e despejá-lo em um arquivo.
O exploit precisa encontrar um ponteiro para algo montado no host. O exploit original usou o arquivo /.dockerinit e esta versão modificada usa /etc/hostname. Se o exploit não estiver funcionando, talvez você precise definir um arquivo diferente. Para encontrar um arquivo que está montado no host, basta executar o comando mount:
O código desta técnica foi copiado do laboratório de "Abusing DAC_READ_SEARCH Capability" de https://www.pentesteracademy.com/
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON é o evento de cibersegurança mais relevante na Espanha e um dos mais importantes na Europa. Com a missão de promover o conhecimento técnico, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e cibersegurança em todas as disciplinas.
CAP_DAC_OVERRIDE
Isso significa que você pode contornar as verificações de permissão de escrita em qualquer arquivo, então você pode escrever em qualquer arquivo.
Existem muitos arquivos que você pode sobrescrever para escalar privilégios, você pode obter ideias daqui.
Exemplo com binário
Neste exemplo, o vim tem essa capacidade, então você pode modificar qualquer arquivo como passwd, sudoers ou shadow:
Exemplo com binário 2
Neste exemplo, o binário python
terá esta capacidade. Você pode usar o python para sobrescrever qualquer arquivo:
Exemplo com ambiente + CAP_DAC_READ_SEARCH (quebra do Docker)
Você pode verificar as capacidades habilitadas dentro do contêiner docker usando:
Primeiro de tudo, leia a seção anterior que abusa da capacidade DAC_READ_SEARCH para ler arquivos arbitrários do host e compile o exploit. Em seguida, compile a seguinte versão do exploit shocker que permitirá que você escreva arquivos arbitrários dentro do sistema de arquivos dos hosts:
Para escapar do contêiner docker, você poderia baixar os arquivos /etc/shadow
e /etc/passwd
do host, adicionar a eles um novo usuário e usar shocker_write
para sobrescrevê-los. Então, acessar via ssh.
O código desta técnica foi copiado do laboratório de "Abusing DAC_OVERRIDE Capability" de https://www.pentesteracademy.com
CAP_CHOWN
Isso significa que é possível mudar a propriedade de qualquer arquivo.
Exemplo com binário
Vamos supor que o python
binário tenha essa capacidade, você pode mudar o proprietário do arquivo shadow, mudar a senha do root e escalar privilégios:
Ou com o binário ruby
tendo esta capacidade:
CAP_FOWNER
Isso significa que é possível alterar as permissões de qualquer arquivo.
Exemplo com binário
Se o python tiver essa capacidade, você pode modificar as permissões do arquivo shadow, alterar a senha do root e escalar privilégios:
CAP_SETUID
Isso significa que é possível definir o id de usuário efetivo do processo criado.
Exemplo com binário
Se o python tiver essa capacidade, você pode abusar dela muito facilmente para escalar privilégios para root:
Outra maneira:
CAP_SETGID
Isso significa que é possível definir o id de grupo efetivo do processo criado.
Existem muitos arquivos que você pode substituir para escalar privilégios, você pode obter ideias daqui.
Exemplo com binário
Neste caso, você deve procurar arquivos interessantes que um grupo pode ler, porque você pode se passar por qualquer grupo:
Uma vez que você tenha encontrado um arquivo que pode abusar (via leitura ou escrita) para escalar privilégios, você pode obter um shell se passando pelo grupo interessante com:
Neste caso, o grupo shadow foi impersonado, então você pode ler o arquivo /etc/shadow
:
Se o docker estiver instalado, você pode impersonar o grupo docker e abusar dele para se comunicar com o docker socket e escalar privilégios.
CAP_SETFCAP
Isso significa que é possível definir capacidades em arquivos e processos
Exemplo com binário
Se o python tiver essa capacidade, você pode facilmente abusar dela para escalar privilégios para root:
Observe que se você definir uma nova capacidade para o binário com CAP_SETFCAP, você perderá essa capacidade.
Uma vez que você tenha a capacidade SETUID, você pode ir para sua seção para ver como escalar privilégios.
Exemplo com ambiente (Docker breakout)
Por padrão, a capacidade CAP_SETFCAP é dada ao processo dentro do contêiner no Docker. Você pode verificar isso fazendo algo como:
Esta capacidade permite dar qualquer outra capacidade a binários, então podemos pensar em escapar do contêiner abusando de qualquer uma das outras quebras de capacidade mencionadas nesta página. No entanto, se você tentar dar, por exemplo, as capacidades CAP_SYS_ADMIN e CAP_SYS_PTRACE ao binário gdb, você descobrirá que pode concedê-las, mas o binário não conseguirá executar após isso:
From the docs: Permitted: Este é um superconjunto limitante para as capacidades efetivas que a thread pode assumir. Também é um superconjunto limitante para as capacidades que podem ser adicionadas ao conjunto herdável por uma thread que não possui a capacidade CAP_SETPCAP em seu conjunto efetivo. Parece que as capacidades Permitidas limitam aquelas que podem ser usadas. No entanto, o Docker também concede o CAP_SETPCAP por padrão, então você pode ser capaz de definir novas capacidades dentro das herdáveis. No entanto, na documentação desta capacidade: CAP_SETPCAP : […] adiciona qualquer capacidade do conjunto de limites da thread chamadora ao seu conjunto herdável. Parece que só podemos adicionar ao conjunto herdável capacidades do conjunto de limites. O que significa que não podemos colocar novas capacidades como CAP_SYS_ADMIN ou CAP_SYS_PTRACE no conjunto herdável para escalar privilégios.
CAP_SYS_RAWIO
CAP_SYS_RAWIO fornece uma série de operações sensíveis, incluindo acesso a /dev/mem
, /dev/kmem
ou /proc/kcore
, modificar mmap_min_addr
, acessar chamadas de sistema ioperm(2)
e iopl(2)
, e vários comandos de disco. O FIBMAP ioctl(2)
também é habilitado por meio dessa capacidade, o que causou problemas no passado. De acordo com a página do manual, isso também permite que o detentor realize uma variedade de operações específicas de dispositivos em outros dispositivos
.
Isso pode ser útil para escalonamento de privilégios e quebra do Docker.
CAP_KILL
Isso significa que é possível matar qualquer processo.
Exemplo com binário
Vamos supor que o python
binário tenha essa capacidade. Se você pudesse também modificar alguma configuração de serviço ou socket (ou qualquer arquivo de configuração relacionado a um serviço), você poderia criar um backdoor, e então matar o processo relacionado a esse serviço e esperar que o novo arquivo de configuração fosse executado com seu backdoor.
Privesc com kill
Se você tiver capacidades de kill e houver um programa node rodando como root (ou como um usuário diferente), você provavelmente poderia enviar o sinal SIGUSR1 e fazer com que ele abra o depurador do node para onde você pode se conectar.
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON é o evento de cibersegurança mais relevante na Espanha e um dos mais importantes na Europa. Com a missão de promover o conhecimento técnico, este congresso é um ponto de encontro fervente para profissionais de tecnologia e cibersegurança em todas as disciplinas.
CAP_NET_BIND_SERVICE
Isso significa que é possível escutar em qualquer porta (mesmo nas privilegiadas). Você não pode escalar privilégios diretamente com essa capacidade.
Exemplo com binário
Se python
tiver essa capacidade, ele poderá escutar em qualquer porta e até se conectar a partir dela a qualquer outra porta (alguns serviços exigem conexões de portas privilegiadas específicas)
CAP_NET_RAW
A capacidade CAP_NET_RAW permite que processos criem sockets RAW e PACKET, permitindo que gerem e enviem pacotes de rede arbitrários. Isso pode levar a riscos de segurança em ambientes containerizados, como spoofing de pacotes, injeção de tráfego e contorno de controles de acesso à rede. Atores maliciosos poderiam explorar isso para interferir no roteamento de containers ou comprometer a segurança da rede do host, especialmente sem proteções adequadas de firewall. Além disso, CAP_NET_RAW é crucial para containers privilegiados suportarem operações como ping via solicitações RAW ICMP.
Isso significa que é possível monitorar o tráfego. Você não pode escalar privilégios diretamente com essa capacidade.
Exemplo com binário
Se o binário tcpdump
tiver essa capacidade, você poderá usá-lo para capturar informações de rede.
Note que se o ambiente estiver concedendo essa capacidade, você também pode usar tcpdump
para capturar tráfego.
Exemplo com binário 2
O seguinte exemplo é um código python2
que pode ser útil para interceptar o tráfego da interface "lo" (localhost). O código é do laboratório "The Basics: CAP-NET_BIND + NET_RAW" de https://attackdefense.pentesteracademy.com/
CAP_NET_ADMIN + CAP_NET_RAW
A capacidade CAP_NET_ADMIN concede ao detentor o poder de alterar configurações de rede, incluindo configurações de firewall, tabelas de roteamento, permissões de soquete e configurações de interface de rede dentro dos namespaces de rede expostos. Também permite ativar o modo promíscuo nas interfaces de rede, permitindo a captura de pacotes entre namespaces.
Exemplo com binário
Vamos supor que o binário python tenha essas capacidades.
CAP_LINUX_IMMUTABLE
Isso significa que é possível modificar atributos de inode. Você não pode escalar privilégios diretamente com essa capacidade.
Exemplo com binário
Se você descobrir que um arquivo é imutável e o python tem essa capacidade, você pode remover o atributo imutável e tornar o arquivo modificável:
Observe que geralmente este atributo imutável é definido e removido usando:
CAP_SYS_CHROOT
CAP_SYS_CHROOT permite a execução da chamada de sistema chroot(2)
, que pode potencialmente permitir a fuga de ambientes chroot(2)
através de vulnerabilidades conhecidas:
CAP_SYS_BOOT
CAP_SYS_BOOT não apenas permite a execução da chamada de sistema reboot(2)
para reinicializações do sistema, incluindo comandos específicos como LINUX_REBOOT_CMD_RESTART2
adaptados para certas plataformas de hardware, mas também habilita o uso de kexec_load(2)
e, a partir do Linux 3.17, kexec_file_load(2)
para carregar novos ou assinados kernels de falha, respectivamente.
CAP_SYSLOG
CAP_SYSLOG foi separado do mais amplo CAP_SYS_ADMIN no Linux 2.6.37, concedendo especificamente a capacidade de usar a chamada syslog(2)
. Essa capacidade permite a visualização de endereços de kernel via /proc
e interfaces semelhantes quando a configuração kptr_restrict
está em 1, que controla a exposição de endereços de kernel. Desde o Linux 2.6.39, o padrão para kptr_restrict
é 0, significando que os endereços de kernel estão expostos, embora muitas distribuições definam isso como 1 (ocultar endereços, exceto do uid 0) ou 2 (sempre ocultar endereços) por razões de segurança.
Além disso, CAP_SYSLOG permite acessar a saída de dmesg
quando dmesg_restrict
está definido como 1. Apesar dessas mudanças, CAP_SYS_ADMIN mantém a capacidade de realizar operações syslog
devido a precedentes históricos.
CAP_MKNOD
CAP_MKNOD estende a funcionalidade da chamada de sistema mknod
além da criação de arquivos regulares, FIFOs (tubos nomeados) ou sockets de domínio UNIX. Permite especificamente a criação de arquivos especiais, que incluem:
S_IFCHR: Arquivos especiais de caractere, que são dispositivos como terminais.
S_IFBLK: Arquivos especiais de bloco, que são dispositivos como discos.
Essa capacidade é essencial para processos que requerem a habilidade de criar arquivos de dispositivo, facilitando a interação direta com hardware através de dispositivos de caractere ou bloco.
É uma capacidade padrão do docker (https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19).
Essa capacidade permite realizar escalonamentos de privilégios (através de leitura completa do disco) no host, sob estas condições:
Ter acesso inicial ao host (sem privilégios).
Ter acesso inicial ao contêiner (privilegiado (EUID 0) e efetivo
CAP_MKNOD
).O host e o contêiner devem compartilhar o mesmo namespace de usuário.
Passos para Criar e Acessar um Dispositivo de Bloco em um Contêiner:
No Host como um Usuário Padrão:
Determine seu ID de usuário atual com
id
, por exemplo,uid=1000(standarduser)
.Identifique o dispositivo alvo, por exemplo,
/dev/sdb
.
Dentro do Contêiner como
root
:
De Volta ao Host:
Esta abordagem permite que o usuário padrão acesse e potencialmente leia dados de /dev/sdb
através do contêiner, explorando namespaces de usuário compartilhados e permissões definidas no dispositivo.
CAP_SETPCAP
CAP_SETPCAP permite que um processo altere os conjuntos de capacidades de outro processo, permitindo a adição ou remoção de capacidades dos conjuntos efetivos, herdáveis e permitidos. No entanto, um processo só pode modificar capacidades que possui em seu próprio conjunto permitido, garantindo que não possa elevar os privilégios de outro processo além de seu próprio nível. Atualizações recentes do kernel apertaram essas regras, restringindo CAP_SETPCAP
a apenas diminuir as capacidades dentro de seu próprio conjunto permitido ou dos conjuntos permitidos de seus descendentes, visando mitigar riscos de segurança. O uso requer ter CAP_SETPCAP
no conjunto efetivo e as capacidades alvo no conjunto permitido, utilizando capset()
para modificações. Isso resume a função central e as limitações de CAP_SETPCAP
, destacando seu papel na gestão de privilégios e no aprimoramento da segurança.
CAP_SETPCAP
é uma capacidade do Linux que permite que um processo modifique os conjuntos de capacidades de outro processo. Ela concede a capacidade de adicionar ou remover capacidades dos conjuntos de capacidades efetivas, herdáveis e permitidas de outros processos. No entanto, existem certas restrições sobre como essa capacidade pode ser usada.
Um processo com CAP_SETPCAP
só pode conceder ou remover capacidades que estão em seu próprio conjunto de capacidades permitido. Em outras palavras, um processo não pode conceder uma capacidade a outro processo se não tiver essa capacidade. Essa restrição impede que um processo eleve os privilégios de outro processo além de seu próprio nível de privilégio.
Além disso, em versões recentes do kernel, a capacidade CAP_SETPCAP
foi ainda mais restrita. Ela não permite mais que um processo modifique arbitrariamente os conjuntos de capacidades de outros processos. Em vez disso, só permite que um processo diminua as capacidades em seu próprio conjunto de capacidades permitido ou no conjunto de capacidades permitido de seus descendentes. Essa mudança foi introduzida para reduzir os riscos de segurança potenciais associados à capacidade.
Para usar CAP_SETPCAP
de forma eficaz, você precisa ter a capacidade em seu conjunto de capacidades efetivas e as capacidades alvo em seu conjunto de capacidades permitido. Você pode então usar a chamada de sistema capset()
para modificar os conjuntos de capacidades de outros processos.
Em resumo, CAP_SETPCAP
permite que um processo modifique os conjuntos de capacidades de outros processos, mas não pode conceder capacidades que não possui. Além disso, devido a preocupações de segurança, sua funcionalidade foi limitada em versões recentes do kernel para permitir apenas a redução de capacidades em seu próprio conjunto de capacidades permitido ou nos conjuntos de capacidades permitidos de seus descendentes.
Referências
A maioria desses exemplos foi retirada de alguns laboratórios de https://attackdefense.pentesteracademy.com/, então se você quiser praticar essas técnicas de privesc, recomendo esses laboratórios.
Outras referências:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON é o evento de cibersegurança mais relevante na Espanha e um dos mais importantes na Europa. Com a missão de promover o conhecimento técnico, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e cibersegurança em todas as disciplinas.
Last updated