From db1234593a9e8686cf4071b82d208475136b6ec6 Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 15 Nov 2025 16:37:33 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/pentesting-cloud-methodology.md', 'src --- ...2-header-malleability-null-cipher-abuse.md | 141 ++++++++++++++++++ .../pentesting-cloud-methodology.md | 86 +++++------ 2 files changed, 184 insertions(+), 43 deletions(-) create mode 100644 src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md diff --git a/src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md b/src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md new file mode 100644 index 000000000..c68a5312c --- /dev/null +++ b/src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md @@ -0,0 +1,141 @@ +# LUKS2 हेडर की मलेएबिलिटी और Confidential VMs में Null-Cipher दुरुपयोग + +{{#include ../../banners/hacktricks-training.md}} + +## सारांश + +- कई Linux-आधारित Confidential VMs (CVMs) जो AMD SEV-SNP या Intel TDX पर चलती हैं, persistent storage के लिए LUKS2 का उपयोग करती हैं। डिस्क पर मौजूद LUKS2 हेडर मलेएबल है और storage-adjacent attackers के खिलाफ integrity-protected नहीं है। +- यदि हेडर के डेटा सेगमेंट एन्क्रिप्शन को null cipher (जैसे "cipher_null-ecb") पर सेट किया गया है, तो cryptsetup इसे स्वीकार कर लेता है और guest पारदर्शी रूप से plaintext पढ़/लिख/पढ़ता/लिखता है जबकि वह मानता है कि डिस्क एन्क्रिप्टेड है। +- cryptsetup 2.8.0 तक (और इसे शामिल करते हुए), null ciphers keyslots के लिए उपयोग किए जा सकते थे; 2.8.1 के बाद non-empty passwords वाले keyslots के लिए इन्हें reject कर दिया गया है, पर null ciphers अभी भी volume segments के लिए अनुमति रहती है। +- Remote attestation आमतौर पर VM के code/config को measure करती है, न कि mutable external LUKS headers; explicit validation/measurement के बिना, disk write access वाला एक attacker plaintext I/O जबरदस्ती कर सकता है। + +## पृष्ठभूमि: LUKS2 on-disk फॉर्मेट (attackers के लिए क्या मायने रखता है) + +- एक LUKS2 डिवाइस एक हेडर के साथ शुरू होता है और उसके बाद encrypted data रहती है। +- हेडर में binary section की दो identical copies और एक JSON metadata section होता है, साथ ही एक या अधिक keyslots होते हैं। +- JSON metadata परिभाषित करता है: + - सक्षम keyslots और उनके wrapping KDF/cipher + - segments जो data area का वर्णन करते हैं (cipher/mode) + - digests (जैसे, volume key का hash जो passphrases को verify करने के लिए) +- आम तौर पर सुरक्षित मान: keyslot KDF argon2id; keyslot और data segment एन्क्रिप्शन aes-xts-plain64। + +तेज़ी से JSON से सीधे segment cipher का निरीक्षण करें: +```bash +# Read JSON metadata and print the configured data segment cipher +cryptsetup luksDump --type luks2 --dump-json-metadata /dev/VDISK \ +| jq -r '.segments["0"].encryption' +``` +## मूल कारण + +- LUKS2 headers स्टोरेज टेम्परिंग के खिलाफ प्रमाणीकृत नहीं हैं। एक host/storage attacker cryptsetup द्वारा स्वीकार किए गए JSON metadata को फिर से लिख सकता है। +- cryptsetup 2.8.0 से, ऐसे headers जिन्हें किसी segment की encryption cipher_null-ecb पर सेट करते हैं स्वीकार किए जाते हैं। null cipher keys को अनदेखा करता है और plaintext लौटाता है। +- 2.8.0 तक, null ciphers को keyslots के लिए भी उपयोग किया जा सकता था (keyslot किसी भी passphrase से खुल जाता था)। 2.8.1 के बाद, non-empty passwords वाले keyslots के लिए null ciphers अस्वीकार कर दिए जाते हैं, पर वे segments के लिए अभी भी अनुमति देते हैं। केवल segment cipher बदलने से भी 2.8.1 के बाद plaintext I/O मिलता है। + +## Threat model: क्यों attestation ने डिफ़ॉल्ट रूप से आपकी रक्षा नहीं की + +- CVMs का उद्देश्य untrusted host में confidentiality, integrity, और authenticity सुनिश्चित करना है। +- Remote attestation आमतौर पर VM image और launch configuration को मापता है, न कि untrusted storage पर मौजूद mutable LUKS header को। +- यदि आपका CVM किसी on-disk header को robust validation/measurement के बिना trust करता है, तो एक storage attacker उसे null cipher में बदल सकता है और आपका guest बिना त्रुटि के एक plaintext volume को mount कर लेगा। + +## Exploitation (storage write access required) + +पूर्व शर्तें: +- CVM के LUKS2-encrypted block device पर write access। +- Guest on-disk LUKS2 header को robust validation/attestation के बिना उपयोग करता है। + +चरण (उच्च-स्तर): +1) header JSON पढ़ें और data segment definition की पहचान करें। उदाहरण target field: segments["0"].encryption। +2) data segment encryption को null cipher पर सेट करें, उदाहरण के लिए cipher_null-ecb। keyslot parameters और digest structure को यथावत रखें ताकि guest का सामान्य passphrase अभी भी "काम" करे। +3) दोनों header copies और संबंधित header digests को अपडेट करें ताकि header self-consistent हो। +4) अगले बूट पर guest cryptsetup चलाता है, मौजूदा keyslot को अपने passphrase से सफलतापूर्वक unlock करता है, और volume को mount कर लेता है। चूँकि segment cipher null cipher है, सभी reads/writes plaintext होंगे। + +Variant (pre-2.8.1 keyslot abuse): अगर किसी keyslot का area.encryption null cipher है, तो वह किसी भी passphrase से खुल जाता है। इसे null segment cipher के साथ मिलाकर guest secret जाने बिना seamless plaintext access प्राप्त किया जा सकता है। + +## Robust mitigations (avoid TOCTOU with detached headers) + +हमेशा on-disk LUKS headers को untrusted input मानें। Use detached-header mode ताकि validation और opening एक ही trusted bytes from protected RAM का उपयोग करें: +```bash +# Copy header into protected memory (e.g., tmpfs) and open from there +cryptsetup luksHeaderBackup --header-backup-file /tmp/luks_header /dev/VDISK +cryptsetup open --type luks2 --header /tmp/luks_header /dev/VDISK --key-file=key.txt +``` +फिर इनमें से एक (या अधिक) लागू करें: + +1) MAC the full header +- पूरे हेडर पर MAC की गणना/सत्यापन करें इस्तेमाल से पहले। +- केवल तभी volume खोलें जब MAC सत्यापित हो। +- वास्तविक दुनिया में उदाहरण: Flashbots tdx-init और Fortanix Salmiac ने MAC-आधारित सत्यापन अपनाया। + +2) Strict JSON validation (backward compatible) +- JSON मेटाडेटा को dump करें और पैरामीटरों के एक कठोर allowlist को सत्यापित करें (KDF, ciphers, segment count/type, flags)। +```bash +#!/bin/bash +set -e +# Store header in confidential RAM fs +cryptsetup luksHeaderBackup --header-backup-file /tmp/luks_header $BLOCK_DEVICE +# Dump JSON metadata header to a file +cryptsetup luksDump --type luks2 --dump-json-metadata /tmp/luks_header > header.json +# Validate the header +python validate.py header.json +# Open the cryptfs using key.txt +cryptsetup open --type luks2 --header /tmp/luks_header $BLOCK_DEVICE --key-file=key.txt +``` +
+उदाहरण वैलिडेटर (सुरक्षित फ़ील्ड लागू करें) +```python +from json import load +import sys +with open(sys.argv[1], "r") as f: +header = load(f) +if len(header["keyslots"]) != 1: +raise ValueError("Expected 1 keyslot") +if header["keyslots"]["0"]["type"] != "luks2": +raise ValueError("Expected luks2 keyslot") +if header["keyslots"]["0"]["area"]["encryption"] != "aes-xts-plain64": +raise ValueError("Expected aes-xts-plain64 encryption") +if header["keyslots"]["0"]["kdf"]["type"] != "argon2id": +raise ValueError("Expected argon2id kdf") +if len(header["tokens"]) != 0: +raise ValueError("Expected 0 tokens") +if len(header["segments"]) != 1: +raise ValueError("Expected 1 segment") +if header["segments"]["0"]["type"] != "crypt": +raise ValueError("Expected crypt segment") +if header["segments"]["0"]["encryption"] != "aes-xts-plain64": +raise ValueError("Expected aes-xts-plain64 encryption") +if "flags" in header["segments"]["0"] and header["segments"]["0"]["flags"]: +raise ValueError("Segment contains unexpected flags") +``` +
+ +3) हेडर को मापें/attest करें +- रैंडम salts/digests हटाएँ और sanitized header को TPM/TDX/SEV PCRs या KMS policy state में मापें/attest करें। +- केवल तभी decryption keys जारी करें जब measured header किसी approved, safe profile से मेल खाता हो। + +Operational guidance: +- detached header + MAC या कड़ी validation लागू करें; on-disk headers पर कभी भी सीधे भरोसा न करें। +- attestation के उपभोक्ताओं को allow-lists में pre-patch framework versions को अस्वीकार करना चाहिए। + +## Notes on versions and maintainer position + +- cryptsetup के मेंटेनरों ने स्पष्ट किया कि इस सेटिंग में LUKS2 को storage tampering के खिलाफ integrity प्रदान करने के लिए डिज़ाइन नहीं किया गया था; backward compatibility के लिए null ciphers बरकरार रखे गए हैं। +- cryptsetup 2.8.1 (Oct 19, 2025) non-empty passwords वाले keyslots के लिए null ciphers को reject करता है लेकिन segments के लिए null ciphers अभी भी allow करता है। + +## त्वरित जांच और ट्रायज + +- जाँचें कि क्या किसी भी segment encryption को null cipher पर सेट किया गया है: +```bash +cryptsetup luksDump --type luks2 --dump-json-metadata /dev/VDISK \ +| jq -r '.segments | to_entries[] | "segment=" + .key + ", enc=" + .value.encryption' +``` +- वॉल्यूम खोलने से पहले keyslot और segment algorithms की जाँच करें। यदि आप MAC नहीं कर सकते, तो कठोर JSON मान्यकरण लागू करें और protected memory से detached header का उपयोग करके खोलें। + +## References + +- [Vulnerabilities in LUKS2 disk encryption for confidential VMs (Trail of Bits)](https://blog.trailofbits.com/2025/10/30/vulnerabilities-in-luks2-disk-encryption-for-confidential-vms/) +- [cryptsetup issue #954 (null cipher acceptance and integrity considerations)](https://gitlab.com/cryptsetup/cryptsetup/-/issues/954) +- [CVE-2025-59054](https://nvd.nist.gov/vuln/detail/CVE-2025-59054) +- [CVE-2025-58356](https://nvd.nist.gov/vuln/detail/CVE-2025-58356) +- [Related context: CVE-2021-4122 (auto-recovery path silently decrypting disks)](https://www.cve.org/CVERecord?id=CVE-2021-4122) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md index a510ee773..6b5b0e237 100644 --- a/src/pentesting-cloud/pentesting-cloud-methodology.md +++ b/src/pentesting-cloud/pentesting-cloud-methodology.md @@ -1,40 +1,40 @@ -# Pentesting क्लाउड कार्यप्रणाली +# Pentesting Cloud Methodology {{#include ../banners/hacktricks-training.md}}
-## बुनियादी कार्यप्रणाली +## Basic Methodology -प्रत्येक क्लाउड की अपनी विशेषताएँ होती हैं लेकिन सामान्यतः कुछ **सामान्य बातें हैं जो एक pentester को जांचनी चाहिए** जब क्लाउड पर्यावरण का परीक्षण कर रहा हो: +Each cloud has its own peculiarities but in general there are a few **common things a pentester should check** when testing a cloud environment: -- **बेंचमार्क चेक्स** -- यह आपकी मदद करेगा **पर्यावरण के आकार** और **उपयोग की जाने वाली सेवाओं** को समझने में -- यह आपको कुछ **त्वरित misconfigurations** खोजने में भी मदद करेगा क्योंकि आप इनमें से अधिकांश परीक्षण **automated tools** के साथ कर सकते हैं +- **Benchmark checks** +- यह आपको वातावरण का आकार और उपयोग की जाने वाली सेवाओं को समझने में मदद करेगा +- यह आपको कुछ त्वरित misconfigurations खोजने में भी सक्षम करेगा क्योंकि आप इन परीक्षणों में से अधिकांश **automated tools** के साथ कर सकते हैं - **Services Enumeration** -- यदि आपने बेंचमार्क टेस्ट सही तरीके से किए हैं तो यहाँ शायद ज्यादा misconfigurations नहीं मिलेंगे, पर कुछ ऐसे मिल सकते हैं जिन्हें बेंचमार्क टेस्ट में नहीं देखा गया था। -- यह आपको बताएगा कि क्लाउड env में **ठीक-ठीक क्या इस्तेमाल हो रहा है** +- यदि आपने सही तरीके से benchmark tests किए हैं तो आप शायद यहाँ ज्यादा misconfigurations नहीं पाएँगे, लेकिन ऐसे कुछ मिल सकते हैं जिनकी benchmark टेस्ट में तलाश नहीं की जा रही थी। +- इससे आपको पता चलेगा कि क्लाउड env में वास्तव में क्या इस्तेमाल हो रहा है - यह अगले चरणों में बहुत मदद करेगा - **Check exposed assets** -- यह पिछले सेक्शन के दौरान भी किया जा सकता है, आपको **हर उस चीज़ का पता लगाना होगा जो किसी न किसी तरह से Internet के लिए सम्भवतः exposed है** और उसे कैसे access किया जा सकता है। -- यहाँ मैं **मैनुअली एक्सपोज्ड infrastructure** की बात कर रहा हूँ जैसे instances जिनमें web pages या अन्य ports एक्सपोज़ हैं, और साथ ही उन अन्य **cloud managed services** के बारे में जो एक्सपोज़ होने के लिए configure की जा सकती हैं (जैसे DBs या buckets) -- फिर आपको चेक करना चाहिए **क्या वह resource एक्सपोज़ हो सकता है या नहीं** (गोपनीय जानकारी? vulnerabilities? exposed service में misconfigurations?) +- यह पिछले सेक्शन के दौरान किया जा सकता है, आपको यह पता लगाना होगा कि इंटरनेट के लिए किस चीज़ की संभावित रूप से एक्सपोज़र है और उसे कैसे एक्सेस किया जा सकता है। +- यहाँ मैं मैन्युअली एक्सपोज़ की गई infrastructure जैसे instances जिनमें web pages या अन्य पोर्ट एक्सपोज़ हैं, और साथ ही अन्य cloud managed services जिनको एक्सपोज़ होने के लिए configure किया जा सकता है (जैसे DBs या buckets) ले रहा हूँ +- फिर आपको यह जांचना चाहिए कि **क्या उस resource को एक्सपोज़ किया जा सकता है या नहीं** (गोपनीय जानकारी? vulnerabilities? exposed service में misconfigurations?) - **Check permissions** -- यहाँ आपको **क्लाउड के अंदर हर role/user की सभी permissions** पता करनी चाहिए और वे कैसे उपयोग हो रहे हैं -- बहुत सारे **highly privileged** (सब कुछ नियंत्रित करने वाले) accounts? Generated keys जो उपयोग नहीं हो रहे?... इनमें से अधिकांश चेक पहले से बेंचमार्क टेस्ट में किए जाने चाहिए थे -- यदि क्लाइंट OpenID या SAML या कोई अन्य **federation** उपयोग कर रहा है तो आपको उनसे और **जानकारी** माँगनी पड़ सकती है कि **प्रत्येक role कैसे assign किया जा रहा है** (यह एक जैसा नहीं है कि admin role 1 user को assign है या 100 को) -- यह सिर्फ यह पता लगाने के लिए पर्याप्त नहीं है कि किस user के पास **admin** permissions "\*:\*". हैं। बहुत सारी **अन्य permissions** भी हैं जो उपयोग की जाने वाली सेवाओं के आधार पर बहुत **संवेदनशील** हो सकती हैं। -- इसके अलावा, permissions का दुरुपयोग करके अनुसरण करने योग्य **potential privesc** तरीके भी होते हैं। इन सभी चीज़ों को ध्यान में रखा जाना चाहिए और जितना संभव हो उतने privesc paths रिपोर्ट किए जाने चाहिए। +- यहाँ आपको cloud के अंदर प्रत्येक role/user के सभी permissions और उनका उपयोग कैसे हो रहा है यह पता लगाना चाहिए +- बहुत सारे highly privileged (control everything) accounts? Generated keys का प्रयोग नहीं हो रहा?... इनमे से अधिकांश चेक पहले से benchmark tests में किए जा चुके होने चाहिए थे +- यदि client OpenID या SAML या कोई अन्य federation उपयोग कर रहा है तो आपको उनसे पूछना पड़ सकता है कि **प्रत्येक role कैसे assign किया जा रहा है** (यह एक ही नहीं है कि admin role 1 user को assign है या 100 को) +- यह सिर्फ यही जानना पर्याप्त नहीं है कि किस user के पास **admin** permissions "\*:\*". हैं। बहुत सारी अन्य permissions हैं जो उपयोग की जा रही सेवाओं के आधार पर बहुत **सेंसिटिव** हो सकती हैं। +- इसके अलावा, permissions का दुरुपयोग करके अनुसरण करने के लिए संभावित privesc तरीके होते हैं। इन सभी चीजों को ध्यान में रखना चाहिए और जितने संभव हों उतने privesc paths रिपोर्ट किए जाने चाहिए। - **Check Integrations** -- यह बहुत संभव है कि **अन्य क्लाउड्स या SaaS के साथ integrations** क्लाउड env के अंदर इस्तेमाल हो रहे हों। -- उस क्लाउड के लिए **जो आप ऑडिट कर रहे हैं** अन्य platform के साथ integrations के लिए आपको यह सूचित करना चाहिए **कि किसके पास उस integration का (ab)use करने का access है** और आपको पूछना चाहिए कि किया जा रहा action कितना **संवेदनशील** है।\ -उदाहरण के लिए, कौन AWS bucket में लिख सकता है जहाँ से GCP data ले रहा है (पूछें कि GCP में उस data का उपचार करते समय action कितना संवेदनशील है)। -- जिस क्लाउड को आप ऑडिट कर रहे हैं उसके अंदर से external platforms से होने वाले **integrations** के लिए, आपको पूछना चाहिए **बाहरी रूप से किसके पास उस integration का (ab)use करने का access है** और जाँचना चाहिए कि वह data कैसे उपयोग हो रहा है।\ -उदाहरण के लिए, यदि कोई service GCR में host किए गए Docker image का उपयोग कर रही है, तो आपको पूछना चाहिए कि किसके पास उसे modify करने का access है और वह image जब AWS क्लाउड के अंदर execute होगा तो उसे कौन-सी संवेदनशील जानकारी और access मिलेंगे। +- बहुत संभव है कि क्लाउड env के अंदर अन्य clouds या SaaS के साथ integrations इस्तेमाल किए जा रहे हों। +- जिस cloud की आप auditing कर रहे हैं उसकी **other platform** के साथ integrations के लिए आपको notify करना चाहिए कि **कौन उस integration को (ab)use करने का access रखता है** और आपको पूछना चाहिए कि की जा रही action कितनी **सेंसिटिव** है।\ +For example, who can write in an AWS bucket where GCP is getting data from (ask how sensitive is the action in GCP treating that data). +- जिन integrations का स्रोत external platforms हैं और जो cloud आप audit कर रहे हैं के अंदर उपयोग हो रहे हैं, उनके लिए आपको पूछना चाहिए कि **externally किसके पास उस integration को (ab)use करने का access है** और यह जाँचना चाहिए कि वह डेटा कैसे उपयोग किया जा रहा है।\ +For example, if a service is using a Docker image hosted in GCR, you should ask who has access to modify that and which sensitive info and access will get that image when executed inside an AWS cloud. ## Multi-Cloud tools -ऐसे कई tools हैं जिनका उपयोग विभिन्न क्लाउड environments को टेस्ट करने के लिए किया जा सकता है। इस सेक्शन में installation steps और links बताए जाएंगे। +There are several tools that can be used to test different cloud environments. The installation steps and links are going to be indicated in this section. ### [PurplePanda](https://github.com/carlospolop/purplepanda) @@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env ### [Prowler](https://github.com/prowler-cloud/prowler) -यह **AWS, GCP & Azure** को सपोर्ट करता है। प्रत्येक provider को कॉन्फ़िगर करने का तरीका देखें: [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) +यह **AWS, GCP & Azure** को सपोर्ट करता है। प्रत्येक प्रदाता को कॉन्फ़िगर करने का तरीका देखें: [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) ```bash # Install pip install prowler @@ -170,7 +170,7 @@ steampipe check all सभी प्रोजेक्ट्स की जाँच करें -सभी प्रोजेक्ट्स की जाँच करने के लिए आपको `gcp.spc` फ़ाइल जनरेट करनी होगी जिसमें उन सभी प्रोजेक्ट्स का उल्लेख हो जिन्हें टेस्ट करना है। आप नीचे दिए गए स्क्रिप्ट के निर्देशों का पालन कर सकते हैं। +सभी प्रोजेक्ट्स की जाँच करने के लिए आपको उन सभी प्रोजेक्ट्स को इंगित करने वाली `gcp.spc` फ़ाइल जनरेट करनी होगी जिन्हें टेस्ट करना है। आप निम्नलिखित स्क्रिप्ट में दिए निर्देशों का पालन कर सकते हैं। ```bash FILEPATH="/tmp/gcp.spc" rm -rf "$FILEPATH" 2>/dev/null @@ -194,11 +194,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate ``` -**अन्य GCP insights** (सेवाओं को enumerate करने के लिए उपयोगी) जाँचने के लिए उपयोग करें: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) +देखने के लिए **अन्य GCP insights** (सेवाओं को सूचीबद्ध करने के लिए उपयोगी) उपयोग करें: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) -Terraform GCP code जाँचने के लिए: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) +Terraform GCP code देखने के लिए: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) -Steampipe के अधिक GCP plugins: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp) +Steampipe के और GCP plugins: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp) {{#endtab }} {{#tab name="AWS" }} @@ -225,7 +225,7 @@ cd steampipe-mod-aws-compliance steampipe dashboard # To see results in browser steampipe check all --export=/tmp/output4.json ``` -Terraform AWS code देखने के लिए: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance) +Terraform AWS code की जाँच के लिए: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance) Steampipe के और AWS प्लगइन्स: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws) {{#endtab }} @@ -234,15 +234,15 @@ Steampipe के और AWS प्लगइन्स: [https://github.com/orgs/t ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite) AWS, GCP, Azure, DigitalOcean.\ -यह python2.7 की आवश्यकता रखता है और ऐसा लगता है कि इसे मेंटेन नहीं किया जा रहा है। +यह python2.7 की आवश्यकता रखता है और ऐसा लगता है कि यह मेंटेन नहीं किया जा रहा है। ### Nessus -Nessus में _**Audit Cloud Infrastructure**_ स्कैन है जो इनका समर्थन करता है: AWS, Azure, Office 365, Rackspace, Salesforce. एक **Client Id** प्राप्त करने के लिए **Azure** में कुछ अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता होती है। +Nessus में _**Audit Cloud Infrastructure**_ स्कैन है जो समर्थित है: AWS, Azure, Office 365, Rackspace, Salesforce. **Azure** में कुछ अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता होती है ताकि **Client Id** प्राप्त किया जा सके। ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist) -Cloudlist Cloud Providers से Assets (Hostnames, IP Addresses) प्राप्त करने के लिए एक **multi-cloud tool for getting Assets** है। +Cloudlist एक **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) है जो क्लाउड प्रदाताओं से जानकारी प्राप्त करता है। {{#tabs }} {{#tab name="Cloudlist" }} @@ -265,7 +265,7 @@ cloudlist -config ### [**cartography**](https://github.com/lyft/cartography) -Cartography एक Python टूल है जो इन्फ्रास्ट्रक्चर संसाधनों और उनके आपसी रिश्तों को Neo4j डेटाबेस द्वारा संचालित एक सहज ग्राफ़ दृश्य में समाहित करता है। +Cartography एक Python टूल है जो इन्फ्रास्ट्रक्चर संसाधन और उनके बीच के संबंधों को एक सहज ग्राफ़ दृश्य में समेकित करता है, जिसे Neo4j डेटाबेस संचालित करता है। {{#tabs }} {{#tab name="Install" }} @@ -302,7 +302,7 @@ ghcr.io/lyft/cartography \ ### [**starbase**](https://github.com/JupiterOne/starbase) -Starbase सेवाओं और प्रणालियों — जिनमें क्लाउड इन्फ्रास्ट्रक्चर, SaaS applications, सुरक्षा नियंत्रण और अन्य शामिल हैं — से संपत्तियाँ और संबंध इकट्ठा करता है और उन्हें Neo4j डेटाबेस द्वारा समर्थित एक सहज ग्राफ दृश्य में प्रस्तुत करता है। +Starbase क्लाउड इंफ्रास्ट्रक्चर, SaaS applications, security controls, और अन्य सेवाओं व सिस्टमों से assets और relationships इकट्ठा करके Neo4j database द्वारा समर्थित एक सहज ग्राफ़ व्यू में प्रस्तुत करता है। {{#tabs }} {{#tab name="Install" }} @@ -361,7 +361,7 @@ uri: bolt://localhost:7687 ### [**SkyArk**](https://github.com/cyberark/SkyArk) -स्कैन किए गए AWS या Azure environment में सबसे अधिक privileged users का पता लगाएं, जिनमें AWS Shadow Admins भी शामिल हैं। यह powershell का उपयोग करता है। +स्कैन किए गए AWS या Azure वातावरण में सबसे अधिक विशेषाधिकार प्राप्त उपयोगकर्ताओं का पता लगाएँ, जिसमें AWS Shadow Admins भी शामिल हैं। यह powershell का उपयोग करता है। ```bash Import-Module .\SkyArk.ps1 -force Start-AzureStealth @@ -372,13 +372,13 @@ Scan-AzureAdmins ``` ### [Cloud Brute](https://github.com/0xsha/CloudBrute) -एक टूल जो top cloud providers (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) पर किसी company (target) की infrastructure, files और apps खोजने के लिए है। +एक टूल जो कंपनी (target) की infrastructure, files और apps को शीर्ष क्लाउड प्रदाताओं (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) पर खोजने के लिए है। ### [CloudFox](https://github.com/BishopFox/cloudfox) -- CloudFox cloud infrastructure में exploitable attack paths खोजने के लिए एक टूल है (वर्तमान में केवल AWS & Azure समर्थित हैं, GCP जल्द जोड़ा जाएगा)। -- यह एक enumeration टूल है जो manual pentesting की पूरकता के लिए बनाया गया है। -- यह cloud environment के भीतर किसी भी डेटा को create या modify नहीं करता। +- CloudFox एक टूल है जो cloud infrastructure में exploitable attack paths खोजने के लिए है (वर्तमान में केवल AWS & Azure समर्थित हैं, GCP जल्द आ रहा है)। +- यह एक enumeration टूल है जो manual pentesting को complement करने के लिए बनाया गया है। +- यह क्लाउड environment के भीतर किसी भी डेटा को create या modify नहीं करता/करती। ### More lists of cloud security tools @@ -410,12 +410,12 @@ aws-security/ azure-security/ {{#endref}} -### Attack Graph +## सामान्य क्लाउड सुरक्षा विशेषताएँ -[**Stormspotter** ](https://github.com/Azure/Stormspotter) Azure subscription में resources का “attack graph” बनाता है। यह red teams और pentesters को tenant के भीतर attack surface और pivot अवसरों को दृश्य रूप से देखने में सक्षम बनाता है, और आपके defenders को incident response कार्यों को तेजी से व्यवस्थित और प्राथमिकता देने में बहुत मदद करता है। +### कन्फिडेंशियल कंप्यूटिंग -### Office365 - -आपको **Global Admin** या कम से कम **Global Admin Reader** की आवश्यकता है (ध्यान दें कि Global Admin Reader कुछ हद तक सीमित है)। हालाँकि, ये सीमाएँ कुछ PS modules में दिखाई देती हैं और इन्हें features को **via the web application** के माध्यम से एक्सेस करके बायपास किया जा सकता है। +{{#ref}} +confidential-computing/luks2-header-malleability-null-cipher-abuse.md +{{#endref}} {{#include ../banners/hacktricks-training.md}}