Battling Parasoft DTP :: Default Creds to RCE

How we got there

Hello guys, Its me again this time with an RCE write-up. I found this bug on a private program, we will call it xboy as usual. So the scope was *, this round i was a little bored on the start, so what i did was just got to shodan and do a dork of ssl:"*". I usually use this when i want to find low hanging and easily to find bugs, like open admin panels or any internal panels on weird (non-conventional) ports.

Most of the details have be edited/redacted to ensure anonymity while give more indepth contexts

The Discovery

After running the dork i saw there were two indexed hosts with port 8443 open. I filtered shodan results to the 8443 ports and visited the two hosts i.e &&

The first instance returned a 403 and the second would redirect me to the login page i.e

This login had the parasoftLogo which gave me an idea what this was, upon further checks i noticed that the title of the page was Parasoft Development Testing Platform (DTP)


After i discovered the product in use i started googling and trying to learn as much as i could about it. I first googled for default creds, turns out it was just admin:admin. I didn't test this imediately, went on with recon and subs enumeration. While i did find more subdomains, most redirected to microsoft login as this was a Corp enviroment

After a while i decided to test the creds, as this host wasn't really redirecting to microsoft login. After entering the username and password, and waiting for a few seconds in suspense i got redirected to the Team Server dashboard


After this i made a report to the program and set the severity to 'undecided' as i didn't see any major impact with this, the panel wasn't that juicy at all.

PS :: Below Steps Should only Be taken with authorization from the program to escalate if you believe theres more, they have the right to accept or deny, its your job to convince them. If possible please set up a local instance of your targets product to test and show your escallation Steps.

  • I looked for more than 24hrs for anything DTP related, CVEs, Bugs, or anything that i could use. But i came up with nothing, nada.
  • I tried to get a local instance but this software was so corp like and i could't find any copy. The demo required a business registration on the website, its one of those products of contact sales.

The Quest for Web Shell

After getting logged in the application i was looking around as this program was intrested in RCEs that had impact on the CORP enviroment.

  • given my auth bypass bug had so little, i didn't think it would pass the high CVSS score.

  • I tested lfi on a certain endpoint that downloaded the file from server but nothing,

  • Tried uploading a jsp shell and nothing

  • Tried path traversal and nothing.

Triumph: Remote Code Execution => system

After checking around i found an endpoint to list and manage plugins, i saw that it needed war files, i searched for a sample plugin so i could try to replicate the structure but i couldn't come across anything in my search.

At this point i felt like i wasn't searching hard enough. I decided to just test a simple war file upload. since the manage plugins gave the path, i could try that.

  • I quickly spun up a docker tomcat web app locally that matched my target so as to craft and test my .war file
  1. Create a Dockerfile:
echo "FROM tomcat:8.5.3" >> Dockerfile 
  1. Build the Docker Image:
docker build -t my-tomcat .
  1. Run the Docker Container:
docker run -d -p 8080:8080 --name my-tomcat-container my-tomcat
  1. Make helloworld webapp:
mkdir helloworld
cd helloworld
  • Dir structure should be like:
ā”œā”€ā”€ WEB-INF
ā”‚   ā””ā”€ā”€ web.xml
ā””ā”€ā”€ index.jsp
  • index.jsp
<!DOCTYPE html>
    <title>Hello World</title>
    <h1>Hello, World!</h1>
  • WEB-INF/web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns=""
  • Package the helloworld directory into a WAR file:
jar -cvf helloworld.war *
  1. Now, you can deploy this WAR file to your Apache Tomcat Docker container by copying it into the webapps directory inside the container. For example, assuming your Tomcat container is named my-tomcat-container:
docker cp helloworld.war my-tomcat-container:/usr/local/tomcat/webapps/
  1. After copying the WAR file, Apache Tomcat will automatically deploy the application [beauty of tomcat, no restarting server], and you can access it at http://localhost:8080/helloworld.


  1. Uploaded the .war after testing it.
  2. After uploading i refreshed the plugins and my helloworld didn't show up in the plugins list so i figured it didn't really exist.
  3. After a while and some dirsearch i found that plugins could be accessed on the root i.e* and trying to access returned a 200 OK, now i knew i could upload any .war files with jsp files that would get executed.
  4. I made a Web Shell and first tested it locally, then uploaded it and it worked. I had achieved RCE.

Reproduction Steps To RCE

  1. visited webapp at which redirected me to a login


  1. After using the default creds admin:admin i was in.
  2. found to manage and upload [in war files] plugins


  1. Created a web shell via above steps
  2. uploaded a jsp web shell via war file upload. shell

Attacker could

`>- Own the instance and escalate to other internal corp networks and web apps.



After intial report and the added info i got;



@github @twitter @LinkedIn @Intigriti @hackerone_old

šŸ”„šŸ”„: 0

Previous Post


Next Post