Using Frida to bypass SSL cert pinning on custom certificate pinning solution.

Recently when looking at an Android mobile application for a Bug Bounty program, I came across a custom certificate pinning solution, instead of using the normal X509TrustManager, this app decided to check the certs themselves with a function.

Now normally, cert pinning is automatically bypassed for me thanks to the amazing work here:

https://github.com/NVISO-BE/MagiskTrustUserCerts and https://github.com/ViRb3/TrustMeAlready

If you don’t already have Magisk and Xposed with these two modules, you should definitely look into these! NVISO also has an amazing blog with methods for intercepting SSL.

Intercepting HTTPS Traffic from Apps on Android 7+ using Magisk & Burp

 

But for this we need to go a little further since the application developers chose to do a custom integration for testing for cert pinning.

You’ll need the following prerequisites in order to use the methods here:

  • Rooted phone with MagiskSU or other su method.
  • Frida-server installed and running on the phone. See https://frida.re/docs/android/

After checking out the contents of the source of the app (Using JADX to decompile APK), I found the following function:

Do you see where this may be going? This function is a simple boolean that will return whether or not the cert is trusted.  Thanks to Frida, we can hook this function to make it always return true, therefore bypassing the cert pinning on the custom function.

Frida Code:

Now we launch the app with Frida using the command:

# frida -U --no-pause -f com.******.*** -l frida-func-override.js

Now when the app gets to a part where it uses a backend API call, we’re now able to see requests in Burp as the cert pinning has successfully been bypassed!

Spawned `com.******.***`. Resuming main thread!
[Google Pixel XL::com.******.***]-> validateHostnamePinning Method Called: ***.************.com
Output is:
true
validateHostnamePinning Method Called: ***.************.com
Output is:
true
validateHostnamePinning Method Called: ***.************.com
Output is:
true

Cheers!

Happy Bug Hunting 😊

 

 

CVE-2019-14216 – svg-vector-icon-plugin WordPress plugin vulnerable to CSRF and Arbitrary File Upload leading to Remote Code Execution

Plugin Homepage: https://wordpress.org/plugins/svg-vector-icon-plugin/

Endpoint: /wp-admin/admin.php?page=wp-svg-icons-custom-set

WP SVG Icons allows admins to upload “Custom Icon” sets within the plugin, however it fails to stop CSRF and subsequently leads to Arbitrary File Upload vulnerability, as the .zip package that gets uploaded has no content checks so a POC or shell can be put into the zip and will be unzipped into the /wp-content/uploads/wp-svg-icons/custom-pack directory.

The following POC is the CSRF with a zip file containing “test.php” which invokes phpinfo(). If successful, RCE will be confirmed here: /wp-content/uploads/wp-svg-icons/custom-pack/test.php

CVE-2019-12934 – wp-code-highlightjs WordPress Plugin CSRF leads to blog-wide injected script/HTML

An issue was discovered in the wp-code-highlightjs plugin through 0.6.2 for WordPress.

wp-admin/options-general.php?page=wp-code-highlight-js allows CSRF,  as demonstrated by an XSS payload in the hljs_additional_css parameter.

An attacker could leverage this CSRF to include a script-tag that will execute upon CSRF, coupled with a wordpress user-create payload could potentially lead to RCE.

Proof of Concept:

where poc.js could be a payload similar to:

https://github.com/hakluke/weaponised-XSS-payloads/blob/master/wordpress_create_admin_user.js

 

CVE-2019-12346 – miniOrange SAML SP Single Sign On WordPress Plugin XSS

miniOrange SAML SP Single Sign On WordPress Plugin version 4.8.72 and below are vulnerable to a Cross Site Scripting attack via a specially crafted SAMLReponse XML payload.

This exploit works by passing a crafted SAMLReponse and RelayState variable to https://victim.com/wp-login.php

It will then parse out the SAMLResponse message and in the event that the SAML is anything other than a “Success” the script will dump the contents of the expected parameter, so you can inject any HTML into this variable.

For example a SAMLResponse payload will look like this:

This payload will need to be Base64 encoded and sent as a “SAMLReponse” parameter along with RelayState=testValidate.

Proof of concept:

 

CVE-2019-11511 – Zoho ManageEngine ADSelfService Plus XSS

RestAPI/PasswordSelfServiceAPI in Zoho ManageEngine ADSelfService Plus version 5707 and below allows remote attackers to inject arbitrary web
script or HTML via the PSS_OPERATION parameter.

Example Proof of Concept:

Store XSS Payload:
https://example.com/RestAPI/PasswordSelfServiceAPI?operation=verifyUser&PRODUCT_NAME=ADSSP&PSS_OPERATION=%22%7D%3B%3Chtml%3E%3CIMG%20SRC=/%20onerror=alert(document.cookie)%3E%3C/img%3E

Payload Execution:
https://example.com/RestAPI/PasswordSelfServiceAPI?operation=passwordSelfService&PRODUCT_NAME=ADSSP

Google Dork:
inurl:”showlogin.cc”