I found this vulnerability thanks to the “March Madness” promotion by Yahoo!. Because I always thought that on sports.yahoo.com weren’t vulnerabilities.
It’s basic SQL injection, but it is my best finding on Yahoo!.
The parameter “year” on this URL was vulnerable to SQL injection: http://sports.yahoo.com/nfl/draft?year=2010&type=20&round=2
I had to use parenthesis to exploit it, because the response received from the server was more easy to understand. When using spaces the players weren’t shown, but with parenthesis the wrong players were shown (more useful for the test).
Proof of Concept
- This is the valid response
- With “—” to comment the query from “year”
- This is the reason why I didn’t use spaces
- Using parenthesis for the same last query
- Then I started with the funny test :D … I changed “and(1)” to “and(if(1=1,true,false))” that is the same, but is more useful. If you don’t understand, it means something like “if 1 is equal to 1, then put 1, else put 0”. 1 is equal to 1, then in the parenthesis will put “true”. I could have written “and(if(1=1,1,0))”, but I don’t remember why I used this
- As I learned, with the “IF” I can do more. For example, in this case I used the “IF” to know if the version of the DBMS is “5”. To know it, I added two functions to the injection: MID and VERSION. I won’t explain them, but you can follow the links if you don’t know about them. Look at the response
- Like what happened when using spaces… I couldn’t use characters directly. To do the same I added the function CHAR
- To be sure that the last query was right, I changed the value passed to “CHAR” for “52” and I received a wrong response which is what I was expecting
This is now patched. You can read the report to Yahoo! on HackerOne if you want. There is one more query using the same idea, but with the aim to know the first character of the database user which is making the query.
03-XX-2014: fixed (I can’t see on HackerOne the exact date and I have deleted the emails with the dates, sorry)
Some weeks ago Magento’s bug bounty program was launched. So I started looking for bugs in Prostores (http://prostores.com). While I was searching in the “Knowledge base” I noticed an article about Google Base (I don’t remember which is the article) that explains something about upload files via FTP to uploads.google.com. Immediately I visited http://base.google.com and created an account in Google Merchant Center…
This is my first bug reported to Google which is rewarded. I know that it’s not great like this, but it’s a bug anyway. :D
A user can create an account with a simple XSS vector as store name and if other user visits the “Data quality” section of this account the XSS is exploited.
Proof of Concept
You can see in the screen capture that the store name is printed in the page without sanitizing.
- Go to http://www.google.com/merchants/signup
- In the field “What’s the name of your store?” put something like <svg/onload=alert(document.domain)> (in the capture I used “> too, but it wasn’t necessary)
- Continue until finish the account creation
- In the “Dashboard” go to “Settings > Users”
- Click on “Add user account”
- Put the Email address of the victim and click “Add User”
- Now you have to wait 10-30 minutes for the next “data snapshot” where you will be noticed of the invalid store name. You can check if it’s done in “Data quality”
- When it’s done, the victim has to visit http://www.google.com/merchants/qualityfeedback to be affected by the vulnerability
This is now patched.
02-10-2014: acknowledgment of report
My first post is related to my first valid bug reported to Facebook. It was inspired on this but is not as good. :)
An user (A) can add/change the cover image of his friendship with other user (C). But being not friend with C. And if A adds/changes the cover, C will receive a notification about the change.
Because I don’t have screen captures or something like that, I will only post the reproduction steps that I sent as proof of concept.
Proof of Concept
A = you, B = a friend of you, C = not a friend of you. Follow the next steps intercepting the requests (I used Burp).
- Go to: https://www.facebook.com/profile.php?id=<A_id>&and=<B_id>
- Click “Change cover” (/ajax/timeline/friendship_cover/selector/). In Burp change the profile_id’s value to C’s id.
- 1. If you click on “Choose from photos”: from the params of the request to “/ajax/timeline/browse_photos_dialog/mutual” save for future use the the value of “friendship_id”.
2. If you click on “Upload photo”: from the params of the request to “/ajax/timeline/cover/upload/” save for future use the value of "profile_id".
- Press “Save changes” and change the value “profile_id” to the value that you saved in the previous step. Forward.
- Now check the Friendship’s profile with C and the photo is there. And C will have a notification “A changed the cover photo on your friendship page.”
The problem was that they couldn’t reproduce the behavior… so I verified the steps again with new test accounts and I noticed that, before follow all the steps, you have to “create the friendship”. Using as reference the “Proof of Concept”, you have to go to https://www.facebook.com/profile.php?id=<A_id>&and=<C_id>. Now the friendship exist and you can change the cover image.
This is now patched and you will receive an error when trying to do the same.
12-18-2013: acknowledgment of report