{"id":2389,"date":"2023-08-30T12:12:20","date_gmt":"2023-08-30T10:12:20","guid":{"rendered":"https:\/\/security.humanativaspa.it\/?p=2389"},"modified":"2026-05-05T12:23:49","modified_gmt":"2026-05-05T12:23:49","slug":"extending-burp-suite-for-fun-and-profit-the-montoya-way-part-4","status":"publish","type":"post","link":"https:\/\/hnsecurity.it\/it\/blog\/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-4\/","title":{"rendered":"Extending Burp Suite for fun and profit – The Montoya way – Part 4"},"content":{"rendered":"
    \n
  1. Setting up the environment + Hello World<\/a><\/li>\n
  2. Inspecting and tampering HTTP requests and responses<\/a><\/li>\n
  3. Inspecting and tampering WebSocket messages<\/a><\/li>\n
  4. -> Creating new tabs for processing HTTP requests and responses<\/strong><\/li>\n
  5. Adding new functionalities to the context menu (accessible by right-clicking)<\/a><\/li>\n
  6. Adding new checks to Burp Suite Active and Passive Scanner<\/a><\/li>\n
  7. Using the Collaborator in Burp Suite plugins<\/a><\/li>\n
  8. BChecks – A quick way to extend Burp Suite Active and Passive Scanner<\/a><\/li>\n
  9. Custom scan checks – An improved quick way to extend Burp Suite Active and Passive Scanner<\/a><\/li>\n
  10. Burp AI<\/a><\/li>\n
  11. … and much more!<\/li>\n<\/ol>\n

     <\/p>\n

    Hi there!<\/p>\n

    Today we will see how to add components to the Burp Suite interface that are useful for conveniently managing different scenarios. In detail, we will focus on how to create new tabs for processing HTTP requests and responses.<\/strong><\/p>\n

    But as always, let’s start with a use case and explore some ways it can be handled. We are analyzing a mobile application that adds an encryption layer to the HTTP request and response bodies. The mobile application encrypts the body using AES before sending the request and decrypts the response body in the same way, as it is encrypted by the backend application. I mention mobile applications because this scenario is more common in the mobile world, but over the years, we have also seen web applications behaving in a similar manner, encrypting and decrypting in the browser using JavaScript libraries.<\/p>\n

    A simple Flask Python application that does this job is the following (encryption\/decryption stuff taken obviously from StackOverflow<\/a> – necessary Python packages: flask<\/em> and pycryptodome<\/em>):<\/p>\n

    import flask\r\nfrom flask import request\r\nimport base64\r\nfrom Crypto import Random\r\nfrom Crypto.Cipher import AES\r\n\r\napp = flask.Flask(__name__)\r\n\r\n# Encryption stuff from:\r\n# https:\/\/stackoverflow.com\/questions\/12524994\/encrypt-and-decrypt-using-pycrypto-aes-256\r\n\r\nbs = AES.block_size\r\nkey = bytes.fromhex(\"eeb27c55483270a92682dab01b85fdea\")\r\niv = bytes.fromhex(\"ecbc1312cfdc2a0e1027b1eaf577dce8\")\r\n\r\ndef encrypt(raw):\r\n    raw = _pad(raw)    \r\n    cipher = AES.new(key, AES.MODE_CBC, iv)\r\n    return base64.b64encode(cipher.encrypt(raw.encode()))\r\n\r\ndef decrypt(enc):\r\n    enc = base64.b64decode(enc)\r\n    cipher = AES.new(key, AES.MODE_CBC, iv)\r\n    return _unpad(cipher.decrypt(enc)).decode('utf-8')\r\n\r\ndef _pad(s):\r\n    return s + (bs - len(s) % bs) * chr(bs - len(s) % bs)\r\n\r\ndef _unpad(s):\r\n    return s[:-ord(s[len(s)-1:])]\r\n\r\n\r\n@app.route('\/', methods=['POST'])\r\ndef handle_request():\r\n\r\n    encrypted_body = request.get_data()\r\n    decrypted_body = decrypt(encrypted_body)\r\n\r\n    response = \"Your request was: \\\"\" + decrypted_body + \"\\\"\"\r\n    encrypted_response = encrypt(response)\r\n\r\n    return encrypted_response\r\n    \r\n\r\napp.run(host=\"127.0.0.1\", port=5000, debug=True)<\/pre>\n
    This simple application takes an input request with a body encrypted using AES\/CBC (fixed Key and IV) and encoded in Base64 (since the output of AES\/CBC is binary) and returns a similarly encrypted and encoded response that contains part of the input message. So, both request and response are encrypted and not easy to pentest without the help of a Burp Suite extension.<\/p>\n
    Creating a mini demo mobile application seems excessive, so we will simply forge an example HTTP request directly in the Burp Suite Repeater. We will use CyberChef<\/a> (a powerful web app for encryption, encoding, compression, data analysis) for the encryption of the body of our forged HTTP request (and for decryption of the related HTTP response). Once we have implemented our plugin, it will handle the encryption and decryption for us.<\/p>\n
    First, let’s encrypt a test sentence, taking fixed key and IV from the backend Python code:<\/p>\n
    \"\"<\/p>\n
    Then we send the encrypted content to the backend server with Burp Suite Repeater tool:<\/p>\n
    \"\"<\/p>\n
    And we decrypt the obtained response again using CyberChef:<\/p>\n
    \"\"<\/p>\n
    Well, our backend Python code works correctly.<\/p>\n
    Now that we have a working use case, let’s think about how to approach the problem. Our goal is to be able to analyze the application conveniently, without having to manually encrypt the request after entering each payload and decrypting the response to determine if the attack was successful.<\/p>\n
    One approach could be to implement an HttpHandler<\/strong> plugin (see part 2<\/a> of the series<\/a> for further details) to transparently decrypt the requests sent by the application upon entering Burp Suite and automatically re-encrypt them on the way out. This way, the traffic we see in Burp Suite will appear as if the encryption layer is not even present. This approach has the advantage that we can also seamlessly use Burp Suite Scanner. The scanner will see the requests in their decrypted form and can apply its payloads. Similarly, it will see the responses in their decrypted form and can analyze them to determine if the attack was successful.<\/p>\n
    Personally, I usually use a plugin of this type only for the Scanner and Intruder, but not for the Proxy and Repeater. The reason is that I want to keep the original traffic in Burp Suite’s history, rather than the traffic already processed by the plugin, in order to have a “clean” record. This can be helpful for later reference and analysis purposes.<\/p>\n
    Now let’s explore two alternative approaches that we can use in these cases: using a plugin of type HttpRequestEditor<\/strong>\/HttpResponseEditor<\/strong> (which is what I usually use) and a plugin of type ContextMenuItem<\/strong> (a bit less convenient, but useful in situations where there is a lot of variability in the request and\/or response format). Both plugins can be registered from the UserInterface<\/a><\/em> object that we can get from the usual MontoyaApi<\/em><\/a> (the object supplied as argument to the initialize<\/em> function of the plugin).<\/p>\n
    \"\"<\/p>\n
    In this article we will see how to implement a plugin of type HttpRequestEditor<\/strong>\/HttpResponseEditor<\/strong>. We will cover the ContextMenuItem<\/strong> in the next article of the series.\u00a0<\/strong>With a plugin of this type, we can add a tab to the section of the Burp Suite interface that displays requests and responses. Once clicked, our tab will decrypt the HTTP request and show the decrypted version (same for responses). If we are in a tool that allows request modification (e.g., Repeater or Intercept), we can also modify the decrypted content, and our plugin will automatically re-encrypt it before sending the request to the backend (same for responses but in the opposite direction). This way, we will keep the original traffic while being able to work comfortably as if the encryption layer was not there. The HttpRequestEditor<\/em>\/HttpResponseEditor<\/em> plugin looks as follows in Burp Suite:<\/p>\n
    \"\"<\/p>\n
    As usual, we start from the Hello World plugin skeleton we wrote in the part 1<\/a> of the series<\/a>.<\/p>\n
    package org.fd.montoyatutorial;\r\n\r\nimport burp.api.montoya.BurpExtension;\r\nimport burp.api.montoya.MontoyaApi;\r\nimport burp.api.montoya.logging.Logging;\r\n\r\npublic class HttpRequestResponseEditorExample implements BurpExtension {\r\n\r\n    MontoyaApi api;\r\n    Logging logging;\r\n\r\n    @Override\r\n    public void initialize(MontoyaApi api) {\r\n\r\n        \/\/ Save a reference to the MontoyaApi object\r\n        this.api = api;\r\n\r\n        \/\/ api.logging() returns an object that we can use to print messages to stdout and stderr\r\n        this.logging = api.logging();\r\n\r\n        \/\/ Set the name of the extension\r\n        api.extension().setName(\"Montoya API tutorial - HttpRequestResponseEditorExample\");\r\n\r\n        \/\/ Print a message to the stdout\r\n        this.logging.logToOutput(\"*** Montoya API tutorial - HttpRequestResponseEditorExample loaded ***\");\r\n\r\n        \/\/ TODO - Register our listeners\r\n\r\n    }\r\n}<\/pre>\n
    Here, our extension should register two different listeners, one for requests and one for responses, as we can see in the documentation:<\/p>\n
    \"\"<\/p>\n
    As in most Burp Suite extension, each listener requires a different object that implements a specific interface supplied as argument:<\/p>\n
    \"\"<\/p>\n
    \"\"<\/p>\n
    Since the two interfaces are very simple and require only one method each we will use a single Java class that implements both interfaces. However, if you prefer, you can use two separate classes, each implementing one of the interfaces.<\/p>\n
    package org.fd.montoyatutorial;\r\n\r\nimport burp.api.montoya.MontoyaApi;\r\nimport burp.api.montoya.ui.editor.extension.*;\r\n\r\npublic class CustomHttpRequestResponseEditor implements HttpRequestEditorProvider, HttpResponseEditorProvider {\r\n\r\n    MontoyaApi api;\r\n\r\n    public CustomHttpRequestResponseEditor(MontoyaApi api) {\r\n        this.api = api;\r\n    }\r\n\r\n    @Override\r\n    public ExtensionProvidedHttpRequestEditor provideHttpRequestEditor(EditorCreationContext creationContext) {\r\n        \/\/ TODO\r\n    }\r\n\r\n    @Override\r\n    public ExtensionProvidedHttpResponseEditor provideHttpResponseEditor(EditorCreationContext creationContext) {\r\n        \/\/ TODO\r\n    }\r\n}<\/pre>\n
    The two functions should return an object of type ExtensionProvidedHttpRequestEditor<\/em> and an object of type ExtensionProvidedHttpResponseEditor<\/em>, respectively. As we can guess from the name of the interfaces, these functions should create and return a new graphical tab for HTTP requests and for HTTP responses, respectively. Fortunately for us all, unless you have specific requirements, the Burp Suite APIs provide methods to create graphical tabs without the need to deal with Java’s graphic libraries (and that’s a goooood thing :D). All we need to do is to create those graphical tabs using a specific API of Burp Suite and implement our encryption\/decryption logic in there.<\/p>\n
    Let’s return to the provideHttpRequestEditor<\/em> and provideHttpResponseEditor<\/em> functions we have to implement. These two methods have the same argument, an object of type EditorCreationContext, <\/em>which contains information on the context of the current request\/response (which Burp Suite tool generated the request\/response and if it is editable or not):<\/em><\/p>\n
    \"\"<\/p>\n
    Let’s have a look of how we can create this ExtensionProvidedHttpRequestEditor <\/em>object (we will see in detail the process only for requests because it is exactly the same for responses; the plugin example on the GitHub repository<\/a> will have also the code to handle responses).<\/p>\n
    \"\"<\/p>\n
    We have to create a class that implements this interface, defining all the following functions:<\/p>\n