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

[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.