Burp extension persistence

[h00die]

This PR creates a new persistence mechanism via Burp extension. Install the extension in burp and it gives you back a shell every burp start. Tested against windows and linux targets. You can either compile the java on your system (build action via gradle) or use the bytecode (precompiled). Instructions for creating the bytecode independently are included in the data/exploits/burp_extension folder.

#19592 persistence

Will need to be updated after #19815

Issues

Issue 1: Automating Install (not a blocker)

Currently installing the extension is manual due to several issues. As per my conversation with PortSwigger there are several candidates for automating the install which all fail:

1. create a user config file that contains the extension listed and enabled. Loading it via "Load from configuration file" during GUI startup, however that doesn't seem to load the extension.
2. create a user config file that contains the extension listed and enabled. apply it from the GUI after startup, this works but the user has to do it which defeats the purpose
3. Run headless and load the user config file, which loads the extension, but doesn't apply it to the "Default" config so that it loads on the next start. Possibly due to using kill/pkill to stop the headless instance
4. find some magical "default" config file and set the extension to load from there. I haven't been able to find this file.

PortSwigger said they haven't tested this, but will add it to their feature request list.

As a workaround, if the user specifies a user config file, it will be poisoned with our malicious burp extension.

Issue 2: Java Target

When attempting to use the Java target with a payload that seems right (payload/java/shell/reverse_tcp, payload/java/meterpreter/reverse_tcp) the following error is encountered:

[msf](Jobs:2 Agents:1) exploit(multi/local/burp_extension_persistence) > exploit
[-] Exploit failed: java/shell/reverse_tcp: All encoders failed to encode.
[*] Exploit completed, but no session was created.

No idea why. Either I can cut this target and shrink the java extension, or hopefully someone knows why this is happening

Verification

• get a shell on linux/windows
• use module
• it will write the extension to the writableDir
• load it manually via burp
• get a shell back

[jvoisin]

I think 25*60*60 would be a tad clearer

[h00die]

can/will be addressed in the persistence PR

[jvoisin]

Can't the errors and the output be explicitly set to ignore/null/… to ensure that weird logs won't show up in Burp?

[h00die]

The options are "Output to system console", "Save to file", and "Show in UI". I selected "Show in UI" as I've added text to be displayed to the user to make it seem like all is well.

Right now if you use a Java payload it outputs more with XXX stuff, once we decide how to either fix the Java payload implementation, or remove it, I'll clean that up.

[smcintyre-r7]

Instead of implementing this to obtain the username, why not just expand the HOME environment variable for the specific platform? That would have a few advantages including not running whoami on linux, and allowing the rest of the code to work when the user running burp is a service account. IIRC Burp can be run in a headless mode as part of a CI/CD pipeline in which case the operating account may not be a normal user with their home directory under /home.

[smcintyre-r7]

We should look to configure this module to run passively in the background so it's not just sleeping for 25 hours.

[h00die]

This is partially a chicken and egg problem. The past persistence modules I've written have all been:

        'Stance' => Msf::Exploit::Stance::Passive,
        'Passive' => true,

with 'WfsDelay' => 90_000,.

However, this will need to be synced with #19815 . Which will standardize a lot of this. Would prefer to leave it as is for consistence, then pick it up in the follow-up PR.