* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegrama**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
[**RootedCON**](https://www.rootedcon.com/) é o evento de segurança cibernética 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 segurança cibernética em todas as disciplinas.\\
As capacidades do Linux **fornecem um subconjunto dos privilégios de root disponíveis** a um processo. Isso efetivamente divide os privilégios de root em unidades menores e distintas. Cada uma dessas unidades pode ser concedida independentemente a processos. Dessa forma, o conjunto completo de privilégios é reduzido e os riscos de exploração são diminuídos.
Vamos supor que estamos executando um processo como um usuário normal. Isso significa que não temos privilégios. Podemos acessar apenas dados que nos pertencem, ao nosso grupo ou que estão marcados para acesso por todos os usuários. Em algum momento, nosso processo precisa de um pouco mais de permissões para cumprir suas funções, como abrir um soquete de rede. O problema é que usuários normais não podem abrir um soquete, pois isso requer permissões de root.
**CapEff**: O conjunto de capacidades _efetivas_ representa todas as capacidades que o processo está usando no momento (este é o conjunto real de capacidades que o kernel usa para verificações de permissão). Para capacidades de arquivo, o conjunto efetivo é, na verdade, um único bit que indica se as capacidades do conjunto permitido serão movidas para o conjunto efetivo ao executar um binário. Isso torna possível para binários que não são conscientes de capacidades fazer uso de capacidades de arquivo sem emitir chamadas de sistema especiais.
**CapPrm**: (_Permitido_) Este é um superset de capacidades que a thread pode adicionar a qualquer um dos conjuntos permitidos ou herdáveis da thread. A thread pode usar a chamada do sistema capset() para gerenciar capacidades: ela pode descartar qualquer capacidade de qualquer conjunto, mas só pode adicionar capacidades aos seus conjuntos efetivos e herdáveis da thread que estão em seu conjunto permitido da thread. Consequentemente, não pode adicionar nenhuma capacidade ao seu conjunto permitido da thread, a menos que tenha a capacidade cap\_setpcap em seu conjunto efetivo da thread.
**CapInh**: Usando o conjunto _herdado_, todas as capacidades que podem ser herdadas de um processo pai podem ser especificadas. Isso impede que um processo receba quaisquer capacidades que não precise. Este conjunto é preservado em um `execve` e geralmente é definido por um processo que _recebe_ capacidades em vez de um processo que está distribuindo capacidades para seus filhos.
**CapBnd**: Com o conjunto _limitado_, é possível restringir as capacidades que um processo pode receber. Somente as capacidades presentes no conjunto limitado serão permitidas nos conjuntos herdáveis e permitidos.
**CapAmb**: O conjunto de capacidades _ambientais_ se aplica a todos os binários não SUID sem capacidades de arquivo. Ele preserva as capacidades ao chamar `execve`. No entanto, nem todas as capacidades no conjunto ambiental podem ser preservadas porque estão sendo descartadas no caso de não estarem presentes nos conjuntos de capacidades herdáveis ou permitidos. Este conjunto é preservado em chamadas `execve`.
Para uma explicação detalhada da diferença entre capacidades em threads e arquivos e como as capacidades são passadas para threads, leia as seguintes páginas:
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 todas as informações de capacidade de processos em execução, são mantidas por thread, para binários no sistema de arquivos, elas são armazenadas em atributos estendidos.
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`
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` depois de ter dado ao binário capacidades suficientes (`cap_net_admin` e `cap_net_raw`) para capturar o tráfego de rede (_tcpdump está sendo executado no processo 9562_):
Como você pode ver, as capacidades fornecidas correspondem aos resultados das duas maneiras de obter as capacidades de um binário. A ferramenta _getpcaps_ usa a chamada do sistema **capget()** para consultar as capacidades disponíveis para uma determinada thread. Essa chamada do sistema só precisa fornecer o PID para obter mais informações.
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`:
Aparentemente, **é possível atribuir capacidades também aos usuários**. Isso provavelmente significa que todo processo executado pelo usuário poderá usar as capacidades do usuário. Com base em [isto](https://unix.stackexchange.com/questions/454708/how-do-you-add-cap-sys-admin-permissions-to-user-in-centos-7), [isto](http://manpages.ubuntu.com/manpages/bionic/man5/capability.conf.5.html) e [isto](https://stackoverflow.com/questions/1956732/is-it-possible-to-configure-linux-capabilities-per-user), alguns arquivos precisam ser configurados para dar a um usuário determinadas capacidades, mas aquele que atribui as capacidades a cada usuário será `/etc/security/capability.conf`.\
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").
Os **binários com conhecimento de capacidade não usarão as novas capacidades** fornecidas pelo ambiente, no entanto, os **binários sem conhecimento de capacidade as usarão**, pois não as rejeitarão. Isso torna os binários sem conhecimento de capacidade vulneráveis dentro de um ambiente especial que concede capacidades aos binários.
Por padrão, um **serviço em execução 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 a execução de um serviço com privilégios desnecessários:
[**RootedCON**](https://www.rootedcon.com/) é 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.
As capacidades são úteis quando você **deseja restringir seus próprios processos após realizar operações privilegiadas** (por exemplo, após configurar chroot e vincular a um soquete). No entanto, elas podem ser exploradas passando comandos ou argumentos maliciosos que são executados como root.
Para permitir que qualquer usuário capture pacotes usando o `tcpdump`, é necessário conceder a capacidade `CAP_NET_RAW` ao binário `tcpdump`. Isso pode ser feito usando o seguinte comando:
Isso concederá a capacidade `CAP_NET_RAW` ao binário `tcpdump` localizado em `/usr/sbin/tcpdump`. Com essa capacidade, qualquer usuário poderá executar o `tcpdump` e capturar pacotes sem a necessidade de privilégios de root.
Observe que é possível atribuir conjuntos de capacidades vazios a um arquivo de programa e, portanto, é possível criar um programa set-user-ID-root que altera o ID de usuário efetivo e salvo do processo que executa o programa para 0, mas não confere nenhuma capacidade a esse processo. Ou, simplesmente, se você tiver um binário que:
[**CAP\_SYS\_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) é em grande parte uma capacidade geral, que pode facilmente levar a capacidades adicionais ou a root completo (geralmente acesso a todas as capacidades). `CAP_SYS_ADMIN` é necessário para executar uma série de **operações administrativas**, o que é difícil de remover de contêineres se operações privilegiadas forem executadas dentro do contêiner. Manter essa capacidade é frequentemente necessário para contêineres que imitam sistemas inteiros em comparação com contêineres de aplicativos individuais que podem ser mais restritivos. Entre outras coisas, isso permite **montar dispositivos** ou abusar do **release\_agent** para escapar do contêiner.
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
No método anterior, conseguimos acessar o disco do host do docker.\
Caso você descubra que o host está executando um servidor **ssh**, você pode **criar um usuário dentro do disco do host do docker** e acessá-lo via SSH:
Isso significa que você pode escapar do contêiner injetando um shellcode dentro de algum processo em execução dentro do host. Para acessar processos em execução dentro do host, o contêiner precisa ser executado pelo menos com **`--pid=host`**.
[**CAP\_SYS\_PTRACE**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite o uso de chamadas de sistema `ptrace(2)` e recentemente introduzidas, como `process_vm_readv(2)` e `process_vm_writev(2)`. Se essa capacidade for concedida e a chamada de sistema `ptrace(2)` em si não for bloqueada por um filtro seccomp, isso permitirá que um invasor ignore outras restrições seccomp, consulte [PoC para ignorar seccomp se ptrace for permitido](https://gist.github.com/thejh/8346f47e359adecd1d53) ou o **seguinte PoC**:
Usando o msfvenom, crie um shellcode para o payload que você deseja injetar na memória. Por exemplo, para criar um shellcode para uma shell reversa do Windows, você pode usar o seguinte comando:
Este comando criará um shellcode para uma shell reversa do Windows que se conectará ao seu endereço IP e porta especificados. O shellcode será salvo em um arquivo chamado "shellcode".
Inicie o processo de destino que você deseja injetar o shellcode na memória. Por exemplo, se você quiser injetar o shellcode em um processo chamado "target", você pode usar o seguinte comando:
No gdb, use o comando "info proc map" para obter o endereço de memória do processo. Procure o intervalo de endereços que corresponde à seção de código do processo. Anote o endereço inicial desta seção.
No gdb, use o comando "set {unsigned char} \<endereço> = " para injetar o shellcode na memória do processo. Substitua "\<endereço>" pelo endereço inicial da seção de código do processo e "" pelo valor hexadecimal do primeiro byte do shellcode.
Por exemplo, se o endereço inicial da seção de código do processo for "0x08048000" e o valor hexadecimal do primeiro byte do shellcode for "0x31", você pode usar o seguinte comando:
Em seguida, use o comando "set {unsigned char} \<endereço + offset> = " para injetar o restante do shellcode na memória. Substitua "\<endereço + offset>" pelo endereço inicial da seção de código do processo mais o deslocamento do byte atual do shellcode e "" pelo valor hexadecimal do byte atual do shellcode.
Por exemplo, se o deslocamento do byte atual do shellcode for "0x01" e o valor hexadecimal do segundo byte do shellcode for "0xc0", você pode usar o seguinte comando:
Use o comando "run" no gdb para continuar a execução do processo. O shellcode será executado e a conexão reversa será estabelecida com o seu endereço IP e porta especificados.
Injetar um shellcode na memória de um processo em execução pode ser uma técnica útil para obter privilégios elevados em um sistema. Usando o msfvenom e o gdb, você pode criar e injetar um shellcode na memória de um processo de destino de forma rápida e fácil.
Se o **GDB** estiver instalado (ou você pode instalá-lo com `apk add gdb` ou `apt install gdb`, por exemplo), você pode **depurar um processo do host** e fazê-lo chamar a função `system`. (Essa técnica também requer a capacidade `SYS_ADMIN`).
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_sys_ptrace,cap_mknod,cap_audit_write,cap_setfcap
2. Encontre um **shellcode** para a arquitetura ([https://www.exploit-db.com/exploits/41128](https://www.exploit-db.com/exploits/41128))
3. 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](https://github.com/0x00pf/0x00sec\_code/blob/master/mem\_inject/infect.c))
4.**Modifique** o **shellcode** dentro do programa e **compile**`gcc inject.c -o inject`
5.**Injete** e obtenha seu **shell**: `./inject 299; nc 172.17.0.1 5600`
[**CAP\_SYS\_MODULE**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite que o processo carregue e descarregue módulos do kernel arbitrários (chamadas de sistema `init_module(2)`, `finit_module(2)` e `delete_module(2)`). Isso pode levar a uma escalada de privilégios trivial e comprometimento do anel-0. O kernel pode ser modificado à vontade, subvertendo toda a segurança do sistema, módulos de segurança do Linux e sistemas de contêineres.\
O que significa que é possível usar o comando **`insmod`** para inserir um módulo de kernel. Siga o exemplo abaixo para obter um **shell reverso** abusando desse privilégio.
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_module,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
**O código desta técnica foi copiado do laboratório "Abusing SYS\_MODULE Capability" de** [**https://www.pentesteracademy.com/**](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](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**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite que um processo **ignore as permissões de leitura de arquivos e de leitura e execução de diretórios**. Embora tenha sido projetado para ser usado para pesquisar ou ler arquivos, ele também concede permissão ao processo para invocar `open_by_handle_at(2)`. Qualquer processo com a capacidade `CAP_DAC_READ_SEARCH` pode usar `open_by_handle_at(2)` para acessar qualquer arquivo, mesmo arquivos fora do seu namespace de montagem. O identificador passado para `open_by_handle_at(2)` é destinado a ser um identificador opaco recuperado usando `name_to_handle_at(2)`. No entanto, este identificador contém informações sensíveis e manipuláveis, como números de inode. Isso foi mostrado pela primeira vez como um problema em contêineres Docker por Sebastian Krahmer com o exploit [shocker](https://medium.com/@fun\_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3).\
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
Dentro da saída anterior, você pode ver que a capacidade **DAC\_READ\_SEARCH** está habilitada. Como resultado, o contêiner pode **depurar processos**.
Você pode aprender como funciona a exploração a seguir em [https://medium.com/@fun\_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3](https://medium.com/@fun\_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3), mas, em resumo, **CAP\_DAC\_READ\_SEARCH** não só nos permite percorrer o sistema de arquivos sem verificações de permissão, mas também remove explicitamente quaisquer verificações em _**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](http://stealth.openwall.net/xSports/shocker.c), o seguinte é uma **versão modificada que permite indicar o arquivo que você deseja ler como primeiro argumento e despejá-lo em um arquivo**.
Eu exploro a necessidade de encontrar um ponteiro para algo montado no host. O exploit original usava 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 "Abusing DAC\_READ\_SEARCH Capability" de** [**https://www.pentesteracademy.com/**](https://www.pentesteracademy.com)
[**RootedCON**](https://www.rootedcon.com/) é 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.
Existem muitos arquivos que você pode **sobrescrever para escalar privilégios,** [**você pode obter ideias aqui**](payloads-to-execute.md#overwriting-a-file-to-escalate-privileges).
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
Antes de tudo, leia a seção anterior que [**abusa da capacidade DAC\_READ\_SEARCH para ler arquivos arbitrários**](linux-capabilities.md#cap\_dac\_read\_search) do host e **compile** o exploit.\
Em seguida, **compile a seguinte versão do exploit shocker** que permitirá que você **escreva arquivos arbitrários** no sistema de arquivos do host:
Para escapar do contêiner docker, você pode **baixar** os arquivos `/etc/shadow` e `/etc/passwd` do host, **adicionar** a eles um **novo usuário** e usar **`shocker_write`** para sobrescrevê-los. Em seguida, **acessar** via **ssh**.
**O código desta técnica foi copiado do laboratório "Abusing DAC\_OVERRIDE Capability" de** [**https://www.pentesteracademy.com**](https://www.pentesteracademy.com)
Suponha que o binário **`python`** tenha essa capacidade, você pode **alterar** o **proprietário** do arquivo **shadow**, **alterar a senha de root** e escalar privilégios:
Existem muitos arquivos que você pode sobrescrever para escalar privilégios, [você pode obter ideias aqui](payloads-to-execute.md#overwriting-a-file-to-escalate-privileges).
Depois de encontrar um arquivo que você possa abusar (lendo ou escrevendo) para escalar privilégios, você pode **obter um shell se passando pelo grupo interessante** com:
Se o **docker** estiver instalado, você pode **se passar** pelo **grupo docker** e abusar dele para se comunicar com o [**socket do docker** e escalar privilégios](./#writable-docker-socket).
Esta capacidade permite **dar a qualquer binário outra capacidade**, então poderíamos 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 dá-las, mas o **binário não poderá ser executado depois disso**:
Depois de investigar, li o seguinte: _Permitido: Este é um **subconjunto limitante para as capacidades efetivas** que a thread pode assumir. Também é um subconjunto 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._\
No entanto, na documentação dessa 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 as 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**](https://man7.org/linux/man-pages/man7/capabilities.7.html) 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 `ioctl(2) FIBMAP` também é habilitado por meio dessa capacidade, o que causou problemas no [passado](http://lkml.iu.edu/hypermail/linux/kernel/9907.0/0132.html). Conforme a página do manual, isso também permite que o detentor **execute descritivamente uma série de operações específicas do dispositivo em outros dispositivos**.
Vamos supor que o binário **`python`** tenha essa capacidade. Se você pudesse **também modificar alguma configuração de serviço ou soquete** (ou qualquer arquivo de configuração relacionado a um serviço), poderia colocar uma porta dos fundos nele e, em seguida, matar o processo relacionado a esse serviço e esperar que o novo arquivo de configuração seja executado com sua porta dos fundos.
Se você tiver capacidades de kill e houver um **programa node em execução como root** (ou como um usuário diferente), você provavelmente poderá **enviar** o **sinal SIGUSR1** e fazer com que ele **abra o depurador do node** para que você possa se conectar.
Isso significa que é possível ouvir em qualquer porta (mesmo em portas privilegiadas). Você não pode escalar privilégios diretamente com essa capacidade.
Se o **`python`** tiver essa capacidade, ele poderá ouvir em qualquer porta e até mesmo se conectar a qualquer outra porta (alguns serviços exigem conexões de portas de privilégios específicos).
Linux capabilities are a way to divide the privileges of a superuser into smaller units. This way, a process can be granted only the specific capabilities it needs to perform its task, instead of running with full root privileges.
This command adds the `cap_net_admin` capability to the `ping` binary, which allows it to perform network administration tasks such as setting network interfaces up and down.
If a binary has a capability that it doesn't need, it can be exploited to gain elevated privileges. For example, if a binary has the `cap_setuid` capability, an attacker can use it to gain root privileges by setting the UID to 0.
[**CAP\_NET\_RAW**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite que um processo possa **criar tipos de soquetes RAW e PACKET** para os namespaces de rede disponíveis. Isso permite a geração e transmissão arbitrária de pacotes através das interfaces de rede expostas. Em muitos casos, essa interface será um dispositivo Ethernet virtual que pode permitir que um contêiner malicioso ou **comprometido falsifique****pacotes** em vários níveis de rede. Um processo malicioso ou contêiner comprometido com essa capacidade pode injetar em uma ponte upstream, explorar o roteamento entre contêineres, ignorar os controles de acesso à rede e, de outra forma, interferir na rede do host se um firewall não estiver em vigor para limitar os tipos e conteúdos de pacotes. Finalmente, essa capacidade permite que o processo se vincule a qualquer endereço nos namespaces disponíveis. Essa capacidade é frequentemente retida por contêineres privilegiados para permitir que o ping funcione usando soquetes RAW para criar solicitações ICMP a partir de um contêiner.
O exemplo a seguir é 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/](https://attackdefense.pentesteracademy.com)
[**CAP\_NET\_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite ao detentor da capacidade **modificar o firewall, tabelas de roteamento, permissões de soquete**, configuração de interface de rede e outras configurações relacionadas em interfaces de rede expostas. Isso também fornece a capacidade de **ativar o modo promíscuo** para as interfaces de rede anexadas e potencialmente farejar através de namespaces.
[**CAP\_SYS\_CHROOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite o uso da chamada de sistema `chroot(2)`. Isso pode permitir a fuga de qualquer ambiente `chroot(2)`, usando fraquezas e escapes conhecidos:
* [Como escapar de várias soluções chroot](https://deepsec.net/docs/Slides/2015/Chw00t\_How\_To\_Break%20Out\_from\_Various\_Chroot\_Solutions\_-\_Bucsay\_Balazs.pdf)
* [chw00t: ferramenta de escape chroot](https://github.com/earthquake/chw00t/)
[**CAP\_SYS\_BOOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite o uso da chamada de sistema `reboot(2)`. Também permite a execução de um **comando de reinicialização** arbitrário via `LINUX_REBOOT_CMD_RESTART2`, implementado para algumas plataformas de hardware específicas.
Essa capacidade também permite o uso da chamada de sistema `kexec_load(2)`, que carrega um novo kernel de falha e, a partir do Linux 3.17, a `kexec_file_load(2)` que também carregará kernels assinados.
[CAP\_SYSLOG](https://man7.org/linux/man-pages/man7/capabilities.7.html) foi finalmente bifurcado no Linux 2.6.37 do `CAP_SYS_ADMIN` catchall, essa capacidade permite que o processo use a chamada de sistema `syslog(2)`. Isso também permite que o processo visualize endereços do kernel expostos via `/proc` e outras interfaces quando `/proc/sys/kernel/kptr_restrict` é definido como 1.
A configuração do sysctl `kptr_restrict` foi introduzida no 2.6.38 e determina se os endereços do kernel são expostos. Isso é padrão para zero (expondo endereços do kernel) desde o 2.6.39 no kernel vanilla, embora muitas distribuições configurem corretamente o valor como 1 (ocultar de todos, exceto uid 0) ou 2 (sempre ocultar).
Além disso, essa capacidade também permite que o processo visualize a saída do `dmesg`, se a configuração `dmesg_restrict` for 1. Finalmente, a capacidade `CAP_SYS_ADMIN` ainda é permitida para realizar operações de `syslog` por razões históricas.
[CAP\_MKNOD](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite um uso estendido do [mknod](https://man7.org/linux/man-pages/man2/mknod.2.html) permitindo a criação de algo que não seja um arquivo regular (`S_IFREG`), FIFO (pipe nomeado) (`S_IFIFO`) ou soquete de domínio UNIX (`S_IFSOCK`). Os arquivos especiais são:
É uma capacidade padrão ([https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19](https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19)).
#Because of user namespace sharing, the unprivileged user have access to the container filesystem, and so the created block special file pointing on /dev/sda
**`CAP_SETPCAP`** é uma capacidade do Linux que permite a um processo **modificar os conjuntos de capacidades de outro processo**. 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 permitidas**. Em outras palavras, um processo não pode conceder uma capacidade a outro processo se ele próprio 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**. Não permite mais que um processo modifique arbitrariamente os conjuntos de capacidades de outros processos. Em vez disso, **só permite que um processo reduza as capacidades em seu próprio conjunto de capacidades permitidas ou no conjunto de capacidades permitidas de seus descendentes**. Essa mudança foi introduzida para reduzir os riscos potenciais de segurança associados à capacidade.
Para usar `CAP_SETPCAP` de forma eficaz, você precisa ter a capacidade em seu conjunto de capacidades efetivas e as capacidades de destino em seu conjunto de capacidades permitidas. Você pode então usar a chamada do 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 ele próprio 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 permitidas ou no conjunto de capacidades permitidas de seus descendentes.
**A maioria desses exemplos foi retirada de alguns laboratórios de** [**https://attackdefense.pentesteracademy.com/**](https://attackdefense.pentesteracademy.com), então se você quiser praticar essas técnicas de privesc, recomendo esses laboratórios.
[**RootedCON**](https://www.rootedcon.com/) é o evento de cibersegurança mais relevante da **Espanha** e um dos mais importantes da **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.
* Você trabalha em uma **empresa de cibersegurança**? Quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
