AWS - Bedrock Post Exploitation

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

AWS - Bedrock Agents Memory Poisoning (Indirect Prompt Injection)

Vue d’ensemble

Amazon Bedrock Agents with Memory peut conserver des résumés des sessions passées et les injecter dans les orchestration prompts futurs en tant que system instructions. Si la sortie d’un tool non fiable (par exemple, le contenu récupéré depuis des pages web externes, des fichiers ou des APIs tierces) est incorporée dans l’entrée de l’étape Memory Summarization sans sanitization, un attaquant peut poison la mémoire long terme via indirect prompt injection. La mémoire empoisonnée biaise ensuite la planification de l’agent à travers les sessions futures et peut conduire à des actions covert telles que l’exfiltration silencieuse de données.

Ce n’est pas une vulnérabilité de la plateforme Bedrock elle‑même ; c’est une classe de risque d’agent lorsque du contenu non fiable circule dans des prompts qui deviennent ensuite des system instructions à haute priorité.

Comment fonctionne Bedrock Agents Memory

• Quand Memory est activé, l’agent résume chaque session à la fin de session en utilisant un Memory Summarization prompt template et stocke ce résumé pour une durée configurable (jusqu’à 365 jours). Lors des sessions suivantes, ce résumé est injecté dans l’orchestration prompt en tant que system instructions, influençant fortement le comportement.
• Le Memory Summarization template par défaut inclut des blocs comme :
• <previous_summaries>$past_conversation_summary$</previous_summaries>
• <conversation>$conversation$</conversation>
• Les guidelines exigent un XML strict et bien formé et des sujets comme “user goals” et “assistant actions”.
• Si un tool récupère des données externes non fiables et que ce contenu brut est inséré dans $conversation$ (plus précisément dans le champ result du tool), le summarizer LLM peut être influencé par du markup et des instructions contrôlés par l’attaquant.

Surface d’attaque et préconditions

Un agent est exposé si toutes les conditions suivantes sont vraies :

• Memory est activé et les summaries sont réinjectés dans les orchestration prompts.
• L’agent possède un tool qui ingère du contenu non fiable (web browser/scraper, document loader, third‑party API, user‑generated content) et injecte le résultat brut dans le bloc <conversation> du summarization prompt.
• Des guardrails ou la sanitization des tokens ressemblant à des délimiteurs dans les outputs des tools ne sont pas appliqués.

Point d’injection et technique de boundary‑escape

• Point d’injection précis : le texte du result du tool qui est placé à l’intérieur du bloc <conversation> ... $conversation$ ... </conversation> du Memory Summarization prompt.
• Boundary escape : une payload en 3 parties utilise des délimiteurs XML forgés pour tromper le summarizer afin qu’il traite le contenu de l’attaquant comme s’il s’agissait d’instructions au niveau du template plutôt que de contenu de conversation.
• Partie 1 : Termine par un </conversation> forgé pour convaincre le LLM que le bloc conversation est terminé.
• Partie 2 : Placée « en dehors » de tout bloc <conversation> ; formatée pour ressembler à des template/system‑level instructions et contient les directives malveillantes susceptibles d’être copiées dans le résumé final sous un topic.
• Partie 3 : Rouvre avec un <conversation> forgé, en fabriquant éventuellement un bref échange user/assistant qui renforce la directive malveillante pour augmenter son inclusion dans le résumé.