PayPal Stored XSS using XML file upload
Hey Guys,

Today I’m going to share one of my interesting Stored XSS vulnerability found on PayPal Site using XML file upload.

PayPal allows the users to create an invoice and send to the other users. Also allow attaching the file into invoice. So I started trying to upload file with different types of extensions and found that PayPal allows users to upload XML formatted file.

So the next steps I tried for XXE vulnerability but no luck which makes me happy. After couple of test cases I applied, but not found any interesting things to make this vulnerable.

I noticed that if we upload XML file with script tag, which is working perfectly.

<?xml version="1.0" encoding="UTF-8"?>
<Query>
   <SearchTerm>
      <script xmlns="
http://www.w3.org/1999/xhtml">
          alert(document.cookie);
      </script>
   </SearchTerm>
</Query>


Now next steps to exploit!

The exploitation of the bug is very easy. In order to does this attack, create an invoice with xml file and send to victim. When victim open the attached xml file, the script run into his/her browser.





I reported to PayPal security team and the bug was valid. After the fix PayPal team rewarded me with Bounty under PayPal BugBounty program.


Thanks.


Bypass Google Drive iOS App Passcode using runtime Analysis
Recently I was working on runtime analysis of iOS applications and found that there is way to bypass passcode by hooking into the application runtime, access & modify the instance variables, invoke the instance methods and override the existing methods.

So i started looking for bugs in google iOS applications soon I found that google drive uses a security passcode. once the passcode is set, whenever the app is launched it prompts for the passcode. So this passcode lock can be bypassed by manipulating the iOS runtime with cycript.

Before moving into runtime, I have quickly decrypted the app using clutch and obtained the class information using class-dump.

So now connected to the iPhone over SSH and Launch the Google Drive app and set passcode into Google Drive and also set as Always lock.



Attached Drive process to cycript and obtained the view controller instance.




The app should be sitting at the lock screen so finding out the controller that is current at the time as this is the one will want to manipulate.




The last line we now know the name of the lock screen view controller is “GDAPasscodeVC”. This is the one we will want to look into.

Looked at the class dump for GDAPasscodeVC interface for interesting methods/variables and noticed an interesting method userWasAuthenticated




I created a variable named testing to the current ViewController. This is just to make things easier for the future use. You can alternatively just type the following to get the current ViewController.

Cy#testing=UIApp.keyWindow.rootViewController.visibleViewController

Cy#[testing userWasAuthenticated]




When Invoking the userWasAuthenticated method directly from the the cycript prompt, its logged me into the app.

This is one thing we can do with runtime analysis. Typically we can manipulate the runtime to break logic checks, escalate privilege or steal information memory.

Video Demonstration :





Remediation : 
We can add an extra parameter to the function that might prevent it invoking from cycript but its not a fully mitigation to protect bypassing passcode reasoning behind this is that it's practically impossible to protect the application against the attacker who can run code within the process of that application (which is what we are doing by attaching a debugger).

The best way to prevent these types of attack is the server side validation. The server side validation is the proper way to protect users from these types of attack.


Powered by Blogger.