Skip to content

IHttpListener internal plugin

Federico Dotta edited this page Apr 14, 2020 · 2 revisions

A practical example of IHttpListener Brida plugin

To create our demo plugin, let's take as example the following simple iOS application that, when opened, shows a classical login form requesting a username and a password:

By inspecting the traffic using Burp Suite we can see that the password in encrypted/obfuscated somehow and then encoded in Base64+URL:

ihttplistener-plugin-2

Now, we really want to access to the data protected by this form login but we don't have the password. So, after verifying the absence of other issues, we want to execute a bruteforce attack or to scan the password field from Burp Suite (dangerous but we really want to enter and we are in a testing environment...). Long option: reverse the application in order to understand the employed encryption/obfuscation algorithm and implement the same algorithm in a Burp Suite plugin that encrypt/obfuscate the content of the password HTTP POST parameter before sending the requests that exit from the Repeater, Intruder and Scanner tools. Quick option: reverse the application just enough to find the encryption/obfuscation functions (without even the need to understand if it is an encryption function or an obfuscation one) and create a Brida custom plugin from the GUI that uses those functions to encrypt/obfuscate the content of the password HTTP POST parameter before sending the requests that exit from the Repeater, Intruder and Scanner tools. Obviously, we choose the second option...

After some reverse work with IDA Pro/Hopper/Ghidra/Radare2 (I will use Ghidra for this example) followed by the validation of our assumption with a Frida hook, we found that the password is encrypted with the + encryptPassword: function of LoginUtil class:

ihttplistener-plugin-3

Next step, we code a simple Frida JS exported function named encryptpassword that calls the + encryptPassword: function that we will use in our custom plugin:

ihttplistener-plugin-4

We can then try our exported function from the Debug export tab of Brida:

ihttplistener-plugin-5

Good! It seems to work! Now, it's time to create our custom plugin. A comfortable way could be to insert our attack vectors in plain text in the HTTP POST requests and let Brida encrypts them for us transparently when the requests leave Burp Suite. In this way we can manually test the password parameter with the Repeater tool of Burp Suite but we can also bruteforce with the Intruder or scan with the Active Scanner.

ihttplistener-plugin-0

And here is our plugin:

ihttplistener-plugin-6

  • Plugin name: BridaEncryptPassword
  • Plugin type: IHttpListener
  • Name of the Frida exported function: encryptpassword (the name of the JS function we defined in the previous steps. DO NOT USE UPPERCASE CHARACTERS IN THE EXPORTED FUNCTION NAMES)
  • Execute on: Requests (we are not interested in modifying the responses in our current plugin)
  • Burp Suite Tools: Repeater, Intruder and Scanner (in order to be able to manually test the password parameter, execute a bruteforce with the Intruder and scan with the Scanner)
  • Process only in-scope request/responses: Yes (in order to avoid encrypting not expected requests)
  • Execute: when request/response contains plaintext - POST /auth/login (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 login requests)
  • Parameters: Regex (with parenthesis) - password=(.*) (we can define a regex that can include an arbitrary number of parameters using regex groups. In our plugin we want to pass as parameter to the Frida exported function only the password 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 extracted parameters before sending them to the Frida exported function 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 function. 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 decode it in the plugin using this option. In our current example, the iOS function we are using for our plugin, + encryptPassword:, returns a Base64 output. The backend waits for an encrypted data encoded with the same function and consequently we don't need to decode it)
  • Plugin output: replace in request/response with regex (with parenthesis) - password=(.*) (we replace the encrypted value returned by Frida with his unencrypted form, inserted by us in the Repeater or by Burp in the Intruder/Scanner. As for the parameters, we use REGEX groups to choose the insertion point)
  • Plugin output encoding: URL (this menu allow us to encode Frida output 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)

And that's all! Now we can click on "Add plugin" to create our plugin and then to "ENABLE" to enable it:

ihttplistener-plugin-7

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 well, we can open the debug window and then repeat the login request supplying a clear-text user password:

ihttplistener-plugin-8

By looking into the debug window, we can see Brida transformation of the request, that is not visible in the Repeater tab:

ihttplistener-plugin-9

We can also check the final request using logging tools like Logger++ (NB the debugging window is more reliable because the final request could be not visible from tools like Logger++ if Brida executes the transformation after when the logging tool records the request):

ihttplistener-plugin-10

Now, we can try to execute our bruteforce in order to try to detect the admin password using Burp Suite Intruder (it is better to use only 1 thread in Intruder and Scanner when using Brida to transform requests/responses), grepping for the error message "Wrong username/password" in order to easy detect the correct password:

ihttplistener-plugin-11

... and game over!

Clone this wiki locally