😝 Here is the full disclosure of the Twitter XSS + CSRF vulnerability.
Clicking a crafted link or going to some crafted web pages would allow attackers to take over your account (posting, liking, updating your profile, deleting your account, etc.)
On 12/11, @rabbit_2333 posted details about an XSS on the Twitter subdomain .
This XSS seems to be nothing beyond alert popper because:
1). Twitter's cookies are HttpOnly, meaning reading them using Javascript is impossible.
2). There are CSRF tokens, so no CSRF attacks.
3). Strict same site policy on , so no CSRF attacks to it. twitter.com
However, I figured out some undocumented endpoints on also support using cookies to access. This means that any XSS on subdomains of Twitter can send requests to and impersonate the user. This solves problems 1 and 3. api.twitter.com api.twitter.com
Reverse engineering the JS code of , I found that the CSRF token is just a hash of csrf_id in the cookie. Surprisingly, the csrf_id is not HttpOnly cookie, meaning that subdomain XSS can read this csrf_id and create CSRF tokens. This solves problem 2. twitter.com
And we got the full JS exploit to chain with this XSS vulnerability!
It is highly irresponsible for Twitter to ignore these security issues and not pay the whitehats. The architecture and design patterns also need to be corrected.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
It is apparent that this bot is sandwiching @four_meme_ trades. @four_meme_ somehow became really popular on Thursday. A lot of people created and bought tokens.
Vulnerabilities: AllianceBlock upgraded one of its staking contracts to accept new tokens due to the Bonq DAO hack two years ago. Two storage variables were deleted in the new implementation, making the storage slot `initialized` (originally at 0x12, with value 1) aliased with a slot (0xf) holding an address. The value of `initialized` is important because it indicates whether the contract has been initialized. The contract is supposed to be only initialized once.
As an address is 160 bits, the leading 96 bits in the slot are all 0s. After aliasing, `initialized` is now at slot 0xf's 95th bit, which is 0, making the contract uninitialized.
Under the current state, an attacker can re-initialize the contract. In AllianceBlock's staking contract, re-initializing can reset the `rewardRate`, `rewardToken`, and `stakingToken`. To drain `rewardToken` in the contract, one can simply inflate the `rewardRate` such that by staking a very small amount of tokens, they can get an infinite amount of reward tokens back.
It becomes a bit tricky to steal `stakingToken`. One possible way would be resetting the `stakingToken` to a contract the attacker can control, and conduct a fake stake. As soon as the developer upgrades the contract again, the attacker can backrun the upgrade transaction to unstake real staking tokens, draining them without paying anything. There might be additional ways to exploit, as we did not dig too deep.
What happened: Our bot saw a tornado-cash-funded account interact with the staking contract, staking a tiny amount of tokens. To determine its intention, our bot submitted the contract for analysis to identify all possibilities to backrun that transaction so that we could drain funds from it. In less than 1ms, our bot derived the exploit that could drain all reward tokens in the contract.
The contract was then submitted for further analysis with fuzzer and symbolic execution tools. In ~4s, our engineers got a notification about all vulnerabilities and exploits to drain all tokens in the contract.
We notified the team, and luckily, they managed to fix the contract immediately.
Technical details on how we made $10k/hr by mining $ORE via @bloXrouteLabs @jito_sol and GPUs.
[1/8] 🧵
@bloXrouteLabs @jito_sol [2/8] WTF is $ORE
ORE is a token on Solana with a mining program. One can claim ORE from the mining program by sending correct nonces (calculated by trying hashes) to it.
A mining tx looks like this:
@bloXrouteLabs @jito_sol [3/8] Initial Attempt for Landing Tx
Due to the massive amount of miners clogging the Solana network, it is extremely tough to land any tx.
We initially tried a strategy MEV bots used: blindly sending millions of txs every second to every open RPC on the Internet.
1. The attacker uses "oowner" to define the owner so that analysis considers the contract has no owner -- really benign in the eye of static analysis! twitter.com/i/web/status/1…
@GoplusSecurity@Token_Sniffer 2. The code for rug pull is inside "transfer" and "Approve" functions, very unconventional.