{"id":3507,"date":"2024-07-30T14:16:18","date_gmt":"2024-07-30T12:16:18","guid":{"rendered":"https:\/\/security.humanativaspa.it\/?p=3507"},"modified":"2025-12-10T09:00:05","modified_gmt":"2025-12-10T09:00:05","slug":"extending-burp-suite-for-fun-and-profit-the-montoya-way-part-6","status":"publish","type":"post","link":"https:\/\/hnsecurity.it\/it\/blog\/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-6\/","title":{"rendered":"Extending Burp Suite for fun and profit – The Montoya way – Part 6"},"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<\/a><\/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<\/strong><\/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. … and much more!<\/li>\n<\/ol>\n

     <\/p>\n

    Hi there!<\/p>\n

    Today we will see how to develop an extension that will add custom active and passive checks to Burp Scanner<\/strong>, following the configurations with which the scanner itself has been run.<\/p>\n

    In this article, we will look at how to extend the scanner using the “classic method”, that is, by writing a plugin that uses the Montoya API<\/strong>. This method gives us the most possibilities, as we can write arbitrary Java code to implement our checks. On the other hand, it is also the most complex way to add a check to the scanner, since Burp Suite has recently integrated a new method that allows to add checks via text files with a format similar to YAML, called BCheck<\/strong>. The Burp Suite team is continuing to develop this new method to allow for checking for more and more issues, but it is still good to know how to develop a complete extension as it obviously allows for more articulated checks. Maybe we will also see in one of the upcoming articles how to extend the scanner using the BCheck method.<\/p>\n

    As usual, let’s start from a real scenario<\/strong>. This time we will use a Java application that I developed some time ago as a test case for developing an extension aimed at identifying Java deserialization issues, named Java Deserialization Scanner<\/a>. The test application, in WAR format, simply deserializes objects received in different ways and with different encodings, and it is easy to add vulnerable libraries to its package.<\/p>\n

    In order to exploit a Java serialization issue to achieve RCE<\/strong>, it is not sufficient to merely find an endpoint that deserializes user input. It is also necessary to find a serializable object known to the backend that, during deserialization, allows the execution of arbitrary commands or Java code. Such objects are not super easy to find and known ones are mainly offered by outdated external Java libraries. To delve deeper into this topic, I recommend the article that demonstrated the actual potential of this type of issue<\/a> by exploiting most Java application servers (Foxglove Security) and the original slides by the researchers who discovered the vulnerability<\/a>\u00a0(Gabriel Lawrence and Chris Frohoff).<\/p>\n

    Our target will therefore be a Java application that deserializes the input sent to it<\/strong>, packaged with a vulnerable version of the Apache Commons Collections 3 libraries, which offer one of these serializable objects that allow for the execution of arbitrary Java code once deserialized. The target application can be downloaded from my Github repository<\/a>. To deploy it, a Java application server is necessary. I used Apache Tomcat<\/strong>, which is easy to configure. Specifically, I used Tomcat 9, running with OpenJDK 17 (if you use a too old version of Java, the provided application might not function correctly as it may be compiled with a more recent version of Java). Details on how to configure and run Tomcat are beyond the scope of this article.<\/p>\n

    Let’s start from our test case. After the deployment of the test application, we can reach the homepage (in my deployment at http:\/\/localhost:8080\/sampleCommonsCollections3\/):<\/p>\n

    \"\"<\/p>\n

    The application is very simple. It offers some links that send a serialized Java object to the backend in different ways and with different encodings (and a backend that deserializes them). Let’s click on “Serialzied Java Object in parameter, encoded in Base64”.<\/p>\n

    \"\"<\/p>\n

    The sample application simply tells us to inspect the traffic from Burp, where we can see the request and response.<\/p>\n

    \"\"<\/p>\n

    But what will our extension do? Our extension will perform two tasks: it will add a passive check<\/strong> to the scanner to search for serialized objects in HTTP requests (useful for identifying potential vulnerable parameters), and it will add some active checks<\/strong> to the scanner to test if endpoints are actually exploitable, using specific attack vectors for Apache Commons Collections 3. Essentially, we will write a simplified version of the Java Deserialization Scanner using the Montoya API<\/strong>, which only executes payloads for a single vulnerable library (Commons Collection 3) and supports a single encoding (Base64), to keep the example simple.<\/p>\n

    Before we begin, a few words about Burp Suite’s passive and active scanners. The purpose of the passive scanner<\/strong> is to identify issues simply by passively inspecting the traffic that passes through the tool, without making any request<\/strong>. In contrast, the active scanner<\/strong> tries to actively identify the presence of issues by sending specific attack vectors to the application and analyzing the responses. As we will see shortly, we can actually write Java code to extend both the passive and active scanners. Therefore, unless something has changed recently, there is nothing preventing us from adding code to the passive scanner that performs active checks<\/strong>. However, it is good practice to avoid this approach, as the user who will use the plugin will expect behavior consistent with the type of plugin they are using.<\/p>\n

    As usual, we start from the Hello World plugin skeleton we wrote in part 1<\/a>\u00a0of the\u00a0series<\/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 ScanCheckExample 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 - Scan Check Example\");\r\n\r\n        \/\/ Print a message to the stdout\r\n        this.logging.logToOutput(\"*** Montoya API tutorial - Scan Check Example loaded ***\");\r\n\r\n        \/\/ Register our custom scan check\r\n        \/\/ TODO\r\n\r\n    }\r\n}\r\n<\/pre>\n
    We will need to register our custom scan check after the creation of the classes that will handle it.<\/p>\n
    The plugin we need is of type\u00a0ScanCheck <\/strong><\/em>and can be registered from the Scanner<\/a><\/em>\u00a0object that we can get from the usual\u00a0MontoyaApi<\/em><\/a>\u00a0(the object supplied as argument to the\u00a0initialize<\/em>\u00a0function of the plugin).<\/p>\n
    \"\"<\/p>\n
    To register our plugin we need to code an object that implements the interface\u00a0ScanCheck<\/em><\/a> and that will contain active and passive scan logic. The interface ScanCheck<\/em>\u00a0is documented as follows:<\/p>\n
    \"\"<\/p>\n
    As we can see, the ScanCheck<\/em> interface requires the implementation of the following three methods:<\/p>\n