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.
3. The attacker can only get infinite tokens by transferring tokens to themselves. Analysis by security companies misses this case and considers the token to have a constant total supply.
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.
😝 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 .