IMessageEditorTab internal plugin
To create our demo plugin, let's take as example the following simple iOS application that, when opened, shows a classical search form and the results of the searched term:
By inspecting the traffic using Burp Suite we can see that the HTTP POST requests sent by the application contain a single parameter named content, whose content seems to be encrypted/obfuscated somehow and then encoded in Base64+URL. The same apply for the full body of the HTTP responses:
In order to check for the presence of server-side issues on the API contacted by that form, we need to get rid of this encryption/obfuscation layer. In fact, encrypting/obfuscating requests and responses absolutely don't protect against server-side issues and if the mobile application knows how to encrypt/obfuscate requests and to decrypt/de-obfuscate responses, we know it too! :) As a bonus, pentesters and hackers who already analyzed this functionality may have been blocked by this encryption/obfuscation layer, which makes this research form even more juicy! :) As for the IHttpListener example, in order to accomplish our task we have two options: one option is to completely reverse the code that implement the encryption/obfuscation layer and re-implement it in a Burp Suite plugin, but we prefer to speed-up the process and reverse just enough to find the encryption/obfuscation functions (without even the need to understand if they are encryption functions or obfuscation ones) and create a Brida custom plugin from the GUI that uses those functions to encrypt/obfuscate the requests and decrypt/de-obfuscate the responses.
After some reverse work with IDA Pro/Hopper/Ghidra/Radare2 (I will use Ghidra for this example) followed by a validation of our assumption with a Frida hook, we found that the content of the content parameter is encrypted with the + encryptRequest: function of Encryption class and the response is decrypted using the + decryptResponse: function of the same class. Furthermore, while the function names are encryptRequest and decryptResponse, those functions simply encrypt/decrypt data supplied in input, whether it comes from requests or responses. Consequently, in our plugin we can use the decryptResponse function to decrypt also our encrypted requests and if we want to edit a response with Burp Interceptor we can use the encryptRequest function also to encrypt the modified response:
Next step, we code two simple Frida JS exported function named encryptrequest and decryptresponse that call respectively the + encryptRequest: and + decryptResponse: functions, that we will use in our custom plugins. As we can see in the HTTP traffic, requests are encoded in Base64 and then special URL chars are URL-encoded. So in our exported function + decryptResponse: we will also execute a URL decoding initial step:
We can then try our exported functions from the Debug export tab of Brida:
Good! They seem to work! Now, it's time to create our custom plugins. A comfortable way could be to add a sub-tab to the Request/Response tab of Burp Suite that contains the decrypted/de-obfuscated version of our encrypted/obfuscated content. That tab if we are in an editable pane (for example the Request of the Repeater tool of Burp Suite) should be also editable and should re-encrypt/re-obfuscate edited content before sending it to the backend. With this plugin we can easily inspect all the traffic and verify the resilience of the backend APIs.
In order to simplify the explanation of this type of plugin, we will start from a first version of our plugin that handles only requests and that creates our sub-tab with the decrypted content only in view mode; consequently for the moment our plugin can be used only to inspect traffic but not to tamper it. The plugin is the following (edit only the fields circled in red without considering for now the others; pay only attention to select Discard (view only mode) in the Edited content location field):
- Plugin name: DecryptRequests
- Plugin type: IMessageEditorTab
- Name of the Frida exported function: decryptresponse (the name of the JS function we defined in the previous steps. As we said before, we named the exported function decryptresponse because it is the name of the called mobile function, but it can be used to decrypt both requests and responses. DO NOT USE UPPERCASE CHARACTERS IN THE EXPORTED FUNCTION NAMES)
- Execute on: Requests (this plugin will handle requests; we will then add another one to handle responses)
- Execute: when request/response contains plaintext - content= (we can give to the plugin a REGEX or a plain text string that is checked on all the requests/responses to choose if the plugin should be enabled, in order to be able to run our plugin only on specified requests/responses. In our situation, we are interested only in requests containing the string content=)
- Parameters: Regex (with parenthesis) - content=(.*) (we can define a regex that include an arbitrary number of parameters using regex groups. In our plugin we want to pass as parameter to Frida export only the content field and our regex accomplishes this task; Brida offers many different options to pass argument like full request/response, body, headers, dynamic feed with popup, ...)
- Encode function parameters: none (we can encode parameters before sending them to the mobile application but in this situation it is not necessary. This is very important with binary input: in these situations, it is better to encode parameters with ASCII-HEX or Base64 and decoding them in the Frida exported functions. All the encode/decode options of the Custom Plugins when clicked open a popup in which it is possible to choose one or more encoding/compression algorithm, like Base64, ASCII-HEX, URL, GZIP, ...)
- Decode function output: none (we can decode output returned by Frida. As for the parameters, if the output is in binary form it is better to encode it in the Frida exported function and then decode it in the plugin using this option. In our example, the iOS function we are using for our plugin, + decryptResponse:, returns the result of our search operation in an ASCII string and consequently we don't need to decode it)
- Plugin output: Print in Message Editor tab named - Decrypted (this is the name of the sub-tab that will be added to the Request/Response Burp Suite tabs)
- Plugin output encoding: none (this menu allows us to encode Frida output before inserting it in our Message Editor Tab)
Now to test our plugin we can click on "Add plugin" to create our plugin and then to "ENABLE" to enable it:
Now we can return to our Repeater tool (or in the Proxy one) and try our new Decrypted sub-tab:
Cool! But we're only halfway there! We want to be able to edit the content of the Decrypted sub-tab (for example to put an attack vector in it) and our plugin should handle transparently the encryption of them. What we want to do is the following:
So, let's return in the Custom Plugins tab of Brida and select Edit on our custom plugin:
The bottom part of the custom plugin configurations that we ignored in the first version of our plugin handles what Brida should do if the user changes the content of the plugin sub-tab. Let's add the missing items:
- Name of the Frida exported function for the edited content: encryptrequest (the name of the JS function we defined in the previous steps. DO NOT USE UPPERCASE CHARACTERS IN THE EXPORTED FUNCTION NAMES)
- Encode input passed to Frida function executed on edited content: none (we can encode our edited content before sending it to the mobile application but in this situation it is not necessary because the input is a simple ASCII string. All the encode/decode options of the Custom Plugins when clicked open a popup in which it is possible to choose one or more encoding/compression algorithm, like Base64, ASCII-HEX, URL, GZIP, ...)
- Decode output of Frida function executed on edited content: none (we can decode output returned by Frida also here. As for the parameters, if the output is in binary form it is better to encode it in the Frida exported function and decode it in the plugin using this option. In our example, the iOS function we are using for the edited content of our plugin, + encryptRequest:, returns a Base64 encoded output and we don't need to decode it because the backend expects for Base64 encoded parameters. In situations in which the decrypted value can contain binary data it is better to encode it someway in our Frida exported function and decode it in our plugin using this drop-down menu)
- Encode output of edited content function: URL (this menu allows us to encode the Frida output execute on the edited content function before inserting it in the request/response. In our example, Base64 output returned by Frida can have HTTP Body special chars like the = and consequently we have to apply URL encoding)
In order to check if the plugin is working correctly we can click on the Open debug windows button (the one next to the Enable one), that opens a detached debugging window (more comfortable when debugging plugins that work on other Burp Suite tools).
To check if the plugin is working, we can open the debug window and then try our custom sub-tab in the Repeater tool:
Now, we need only one more thing: a plugin very similar to the one we just created for the responses (in this situations we need only to view the decrypted content of the responses and we are not interested in tampering them):
And with our new powerful plugins we can easily exploit our backend APIs:
