Palisade identifies Wormable Cross-Site Scripting Vulnerability affecting Rarible’s NFT Marketplace
On April 14th, Palisade reported a cross-site scripting vulnerability and WAF bypass affecting the “rarible.com” domain. An attacker could inject arbitrary HTML and JavaScript on their profile page which persisted by “following the user around” as they navigated the website.
Summary
On April 14th, Palisade reported a cross-site scripting vulnerability and WAF bypass affecting the “rarible.com” domain. An attacker could inject arbitrary HTML and JavaScript on their profile page which persisted by “following the user around” as they navigated the website. The exploit would’ve allowed for an attacker to modify the smart contract interactions for every page accessed after loading the vulnerable page including changing the recipient address, item price, or granting token spend approval to the attacker. Additionally, an attacker could modify the Rarible metadata to display incorrect information including modified usernames, URLs, and verified collection status.
Since the vulnerability was stored cross-site scripting, the victims would have no easy or immediate way to tell that the page was tampered with. An attacker could share a seemingly normal profile URL for “rarible.com” that, once clicked, would persist across the victim’s browsing session and be capable of prompting the user to sign arbitrary messages, modify the data for any smart contract interaction, or leak/modify the user’s profile information. If the victim who clicked the link was signed into the Rarible website, the attacker could’ve automatically updated the victim’s profile to include the cross-site scripting payload, enabling it to spread across the Rarible website as a worm.
The payload used in the vulnerability report bypassed Rarible’s Cloudflare WAF, demonstrating full JavaScript execution on the core “rarible.com” domain.
Key Takeaways
Rarible, one of the largest NFT platforms with over 2 million users and 250 million dollars in revenue, was affected by a stored cross-site scripting vulnerability within the profile update functionality via the IPFS image URL parameter
An attacker could modify their profile page to include a wormable cross-site scripting payload that would infect the victim profile and modify any Rarible page that the victim navigated to
The attacker controlled payload would’ve been capable of modifying any content on any page, allowing an attacker to prompt the victim to sign a message using their Web3 wallet which would grant them full wallet access
Palisade responsibly disclosed the vulnerability to Rarible who patched it in 2 hours and additionally verified that it was never exploited in the wild
Technical Summary
While testing the profile functionality on the website, we observed that the profile “photo” parameter was not sanitized against cross-site scripting attacks when loading the data via the user’s profile slug.
An attacker could inject arbitrary HTML and JavaScript into the “photo” parameter via sending the following HTTP request after authenticating to the website:
Vulnerable HTTP Request
POST /marketplace/api/v4/users/WALLET_ADDRESS HTTP/2
Host: api-mainnet.rarible.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0
Accept: */*
Content-Type: application/json
X-Fingerprint: 318d54cb0530abefd668a5744a05f024
X-Visitor-Address: 0x25d226734c1979d7f8aeb624fa89cb7e0a66b7e4
Origin: https://rarible.com
Content-Length: 2345
{
"signature": "WALLET_SIGNATURE",
"publicKey": "WALLET_ADDRESS",
"photo": "VULNERABLE_PARAMETER"
}Since the website employed Cloudflare, the WAF blocked normal cross-site scripting attacks, but we were able to bypass the WAF by creating the following payload:
Cloudflare Bypass XSS Payload
“><iframe/style="display:none"/
src='javascript:&\u0023000000000000000000000000101;val(atob("YWxlcnQoMSk="))'
/></iframe><x/x=”1The above payload will load the iframe with the JavaScript URI source which will trigger the encoded “eval” payload. Within the eval payload, we’ve supplied the final payload which is a base64 encoded string for “alert(1)”. Since the Cloudflare WAF doesn’t analyze base64, we can modify the payload string to any arbitrary content, allowing us to fully execute arbitrary HTML.
To load the payload, you simply had to navigate to your publicly accessible profile slug via the following endpoint:
https://rarible.com/:attackersProfileSlug
The attacker controlled HTML was reflected within the DOM’s meta tags. This was useful to an attacker because the Rarible website is run via dynamic JavaScript and the XSS payload will persist across the entire website.
As an example, we wrote a payload that would modify the price of a Bored Ape to only 1 ETH and modify the function call to purchase it to setApprovalForAll on one of your NFTs after you navigated to the official “boredapeyachtclub” profile slug:
The above screenshot demonstrates an example scenario where the victim is attempting to buy the seemingly discounted Bored Ape Yacht Club NFT from the official verified Rarible page. The “Buy for 1 ETH” button will trigger a Metamask prompt which will instead run the “setApprovalForAll” with the attackers asset, allowing them to steal their cryptocurrency and NFTs through a seemingly trusted page.
Disclosure Timeline
04/14/22 20:40 GMT-5: Responsibly disclosed to Rarible team
04/14/22 22:30 GMT-5: Rarible team patches vulnerability
04/14/22 23:00 GMT-5: Palisade confirms Rarible’s fix
04/16/22 20:00 GMT-5: Pending bounty from Rarible team
04/16/22 20:00 GMT-5: $5,000 bounty rewarded by Rarible through their Bugcrowd bug bounty program
Credit
Identified by Sam Curry (sam <at> palisade.consulting) and Maik Robert (maik <at> palisade.consulting). Disclosure and blog assistance from Brett Buerhaus and Justin Rhinehart.
About Us
Palisade is a boutique security consultancy specializing in application security for Web3 and all-things crypto. Our team has 30 years combined security experience and prolific backgrounds in bug bounty and capture the flag competitions. We work with a number of the largest NFT platforms, custodial wallets, and crypto-powered applications, providing security auditing and ongoing consulting.
To contact us, please use the following email:
contact@palisade.consulting
Exploiting Vulnerabilities in a TLD Registrar to Takeover Tether, Google, and Amazon
On October 8th, 2021, it was possible to modify the nameservers of any domain under the “.to” TLD due to underlying vulnerabilities in the TLD service provider. On October 9th, after disclosing the vulnerabilities to Tonga Network Information Center, Palisade worked alongside the team to remediate the vulnerabilities and validate the fixes.
Since the report was immediately disclosed by Palisade and the DNS registrar was very responsive, the vulnerability was fixed in under 24 hours and there was no malicious exploitation of the vulnerability whatsoever.
The way in which an attacker could compromise any domain under the “.to” TLD would be to (1) exploit a SQL injection vulnerability on the registrar website to obtain the plaintext DNS master passwords for any customer using the “.to” TLD, (2) use the web portal to login to the management console using the compromised credentials, then (3) overwrite the nameservers to an attacker controlled DNS server.
By performing the above steps, an attacker could overwrite the DNS settings for domains under the “.to” TLD and route traffic normally intended for the victim website to their own website. An attacker could then perform the following attacks against the legitimate users of the domain:
Steal cookies and browser local storage to immediately access victim sessions (including HTTPonly and secure cookies)
Exploit domain-level authorization checks (e.g. taking over “google.to” and abusing the domain’s trust to leak authorization codes which give immediate access to Google accounts)
Display attacker-controlled content on the domain or any subdomains (e.g. taking over “amzn.to”, the official Amazon shortlink for all affiliate products, and displaying a login page which would be controlled by an attacker and logging all credentials)
Various related attacks, depending on how each domain is used (e.g. compromising an API and returning modified data to applications using the API)
Some websites potentially affected include:
The official Tether website used for purchasing and managing the Tether stablecoin. Users of this site can only make purchases in orders of $100,000 or more. Even if an attacker controlled this domain for a short period of time, they could likely steal a very large amount of money from Tether users.
When disclosing this vulnerability, we worked with Tether who immediately locked their DNS settings so that even if an attacker did compromise the password, they could not overwrite their nameservers.
Amazon’s official link shortening provider used for affiliate marketing. There are nearly 125,000,000 indexed entries on Google for people using this domain to sell products with affiliate codes. If an attacker were to compromise it, they could (albeit probably get noticed doing so) skim the affiliate links on Amazon similar to how Darlene hacked Postmates in Mr. Robot.
An official Google domain which is whitelisted for redirects and authorization flows for Google. If you want to see an example of this, open this URL while being authenticated for Google and observe you are redirected to “google.to”.
Since the Google.to domain is whitelisted under Google’s account OAuth flow, it would be possible to takeover the domain then send a crafted “accounts.google.com” link which would leak a token which could be used to authenticate to the victim’s Google account.
Uber’s shortlink provider. Used for hyperlinking resources on many of their blogs and the Uber app.
Verizon’s shortlink provider. Same usage as “ubr.to”.
Although the number isn’t known, there are nearly 513,000,000 results on Google for pages under the “.to” TLD. One trend among websites affected by this TLD takeover was that many were using the two-character TLD to shortlink things like resetting user passwords, affiliate marketing, and linking company resources.
Spotting Domains in the Wild
Commentary on TLD Security
Something I think about frequently with my background as a bug bounty hunter is how programs incentivize hackers to find vulnerabilities in different assets and how incredibly broad organizations dependencies are.
If an example company ACME is built using Apache as a web server and a bug bounty hunter is trying to find vulnerabilities for ACME to pay for, should ACME pay for vulnerabilities in Apache? Is it worth the hackers time to find vulnerabilities in Apache? This conversation gets super interesting when you think about bug bounty hunters trying to get the most “bang for their buck” in the terms of time spent hacking from the profit model of any contractor.
Most programs (in my opinion) are less willing to pay for vulnerabilities in dependencies that would result in mass-scale impact across different organizations (e.g. 0day vulnerabilities, TLD takeovers, etc.) if they are outside of their management and therefore there is less emphasis on finding these sorts of vulnerabilities for a very large portion of the people actively hunting for bugs.
In terms of the “hacker ecosystem”, if security researchers following the traditional model of bug bounty don’t feel that it’s productive to look for these bugs, they simply won’t.
This leaves a gap for things like TLD takeovers, dependency vulnerabilities, and vulnerabilities in services outside of an organizations control not really having an incentive model for bug bounty hunters. Those who do hunt for these bugs without expectation of payment from the vendor mostly seem to be either (a) people having fun, or (b) those being paid/coerced by someone other than the affected vendor to find those vulnerabilities (think Zerodium, governments).
Even if the TLD registrars, dependencies, or services do have bug bounty programs, can they really pay for what the vulnerability is worth? How much do you think Verisign would be willing to pay if you were able to compromise any “.com” website versus the impact of taking over a website like Google or Facebook?
When buying a domain with a TLD like “.to” you’ll normally do it through a vendor like Namecheap, but if you were to browse to the root domain you’ll often find very old 1990s and early 2000s manual registration pages running outdated technologies (see this website for an example).
If you were to compromise these sites, you could theoretically access the systems used to manage all domains under the TLD which would be very, very, very bad. As of now, I don’t feel that these TLDs are getting adequate attention and many other TLDs may suffer the same issues as the “.to” TLD.
There are some programs, however, which will honor simply the impact and payout for vulnerabilities in third-party assets or things like TLDs. Additionally, there are some platforms like HackerOne which offer “The Internet Bug Bounty” program which pays for vulnerabilities in projects like Nginx, Django, Ruby, and Rails, but these are a long shot from being able to satisfy the entire ecosystem.
The bottom line is that there are over 1,500 different TLDs with many having their own custom DNS registrar websites. Many do have bug bounty or vulnerability disclosure policies, but as a researcher trying to play by the rules, are the incentives really there to hack them and will they even let you?
Credit and Disclosure Timeline
This vulnerability and writeup was a collaboration between the following:
The vulnerability disclosure timeline was as follows:
October 8th, 20:00 CEST: Vulnerability discovered and reported
October 9th, 19:00 CEST: Contact with Tether and Tonic regarding bug
October 9th, 20:00 CEST: Vulnerability attempted fix #1 by Tonic
October 9th, 20:30 CEST: Vulnerability fixed by Tonic, confirmed fix