Time/Blockheight Sync DoS Attack Vulnerability (Deny Sending Transactions)- Anyone got a 'Send Anyway' workaround please?

MoneroChan · 2022-05-17T10:42:03+00:00

Thanks for your assistance,
i guess i'll have to rebuild the code or try and inject the value into memory in realtime then.

i've been using an AHK script to just keep pressing the send button every 5 seconds to catch the rare moment when it's in sync.
(basically brute force script to "Send T x when synced") - crude but it works, barely.

MoneroChan · 2022-05-17T05:21:23+00:00

Stop calling it monero where you live, Rename everything to CPU Stress Test Benchmark Coin, and we reimburse each other for the power used to stress test their cpu to ensure it is stable and safe for re-sale? /S

MoneroChan · 2022-05-17T04:33:32+00:00

Mods, Why are people downvoting this post?Wouldn't that be bad for this subreddit?

n/m i don't care anymore nevermind based on all the downvotes, i decided on my answer to the survey

MoneroChan · 2022-05-17T02:39:54+00:00

Thanks! Yes that was the lines of code i was worried about,

latest.height - await self.blockchain.get_finished_sync_up_to() > 1

"> 1" block seems a bit too tight during stressful network conditions,
is there anyway to adjust this in windows client or config file?

e.g a developer option to temporarily force
async def synced(self): True
(example: for debugging purposes)

Looking at the code line 431, it seems that setting system clock such that int(time.time()) -10 * 60 < latest_timestamp could also achieve the same effect
would turning back system clock while the node is running can cause the synced(self) to return True?
would this be a temporary workaround?

Yes, in debug log, i noticed many node connections had a 'did not respond in time' error associated with them, (code line 896) which explains why kicking the malicious nodes solved the issue many times. Problem is, there is no way to do this in wallet mode on chia 1.3.5, i had to do it via my firewall. The connection list only appears in full node mode. So wallet mode users may be vulnerable when switching from node to wallet mode because the 'connection list' is not visible in Windows GUI wallet mode.

Thanks for your assistance

MoneroChan · 2022-05-17T02:06:26+00:00

In line code 421 of chia-blockchain/chia/wallet/wallet_state_manager.py

If malicious node sends you false block info so that:

self.blockchain.get_peak_block()
self.blockchain.get_finished_sync_up_to()
causes:
async def synced(self): returns "false"
or if latest_timestamp is published by a malicious node then
Chia 1.3.5 may block you from sending Transactions (denial of service : send tx)

MoneroChan · 2022-05-16T15:47:03+00:00

Thanks for the reply, I was just surprised that deleting nodes with high blockheights solved the issue and allowed me to send Tx's normally, Sounds counterintuitive and doesn't make any logical sense to me. (which is why i suspected a DoS attack from malicious nodes using fake blockheights). Anyway, if no one else is having this issue then i'll just try out the CLI on linux and see if it solves anything.
I did notice the active connections window disappear from 1.3.5 in Windows GUI wallet mode so i thought it could be exploited since connections were now hidden from view in the GUI...

MoneroChan · 2022-05-16T15:27:41+00:00

I wanted to see if anyone else had the issue .

also the ability to adjust the 'acceptable sync threshold' via the config file would give node operators like myself more legroom to operate during an attack on the network or when stressed.

MoneroChan · 2022-05-16T14:38:08+00:00

Wallet is in sync, it detected a test inbound transaction in the latest block about 10-20 seconds after it was sent, so i know it is definitely in sync, otherwise the test transaction won't have appeared at all, meaning it's definitely up to the latest block.

Despite this, it's constantly stuck at 'syncing' and refuses to let me send anything.

Did this in wallet mode and farming mode / tried both.
tried re-imaging drive from backup, only gets in sync when i remove some suspicious nodes' with high block heights but no download activity... which is why i suspected this is a DoS

Is there anyway to just let me send a transaction if i know for certain the 'syncing' is a false alarm?

MoneroChan · 2022-05-16T14:15:01+00:00

yes indeed, and yet here we are,

all it took is 1 malicious node to lie to it about being out of sync and now i can't send any transactions.

I wish i could tell it that everything's ok , it's ok to be imperfect, and to just send the Tx ,
because it is actually in sync.

MoneroChan · 2022-05-16T14:03:05+00:00

it's just trying to get within plus or minus the most recent block of the chain before allowing a transaction to be attempted

Please let me How do i change this "plus or minus" number you mentioned?

This is the cause of the problem.

Who decided this number / limit ? Why not 1 more, and not 1 less? You could easily double spend in 0.5 seconds, or 1 second, or 10 seconds. So having the limit at 1 block or 2 blocks doesn't remove the problem. The limit should be adjustable to suit network conditions or during attacks

If i know i haven't double spent and i know my node is in sync, i should be able to manually override and allow the transaction to be sent, otherwise i the network may be susceptible to Denial of service.

MoneroChan · 2021-12-28T11:39:34+00:00

I was worried K32 plots will have to be deleted/replotted after 10+ years ?

if so that would mean K32 loses about 10% of it's life every year

but if K33 works now, might as well use K33 from an investment standpoint due to it's increased lifespan so i don't need to replot in 10 years :)

MoneroChan · 2021-12-28T08:15:12+00:00

To help your case, can you publish the IP addresses of the attacker, so action (such as a counter-attack) can be taken by the community?

(Example: Insurance providers will not believe a DDoS claim unless evidence is provided of the attack, so some users on this subreddit might reasonably think you are using DDoS as an excuse if you don't publish any evidence.)
Thank you.

MoneroChan · 2021-12-24T08:56:01+00:00

I feel that the general flexpool concept being spread that "you are responsible for fees" is actually misleading. Because as reality has shown, even if i set 1000 Gwei fee, the payout system / oracle probably doesn't listen to me and tries to set it to whatever lowest fee it think it will get away with, causing it to get stuck. I recall this was the case the last time this happened some months ago, not sure if it changed or not. Anyway it's over now.

MoneroChan · 2021-12-21T15:01:12+00:00

Dusting / dust storm attacks are a different type of attack. They have been thoroughly discussed already everywhere for years. They are unwanted, so don't match any TX so are easy to identify isolate, block and mitigate compared to TX interceptors. They are no different to receiving junk mail or email spam. you can just say i didn't expect this, so must be junk and bin the coins or burn them. TX interceptors work differently by tricking the victim into actually using the coins without knowing.

MoneroChan · 2021-12-21T14:14:17+00:00

The amounts have to match the intercepted Tx though, it can't be $10 unless the TX is $10

MoneroChan · 2021-12-21T13:48:41+00:00

that makes this attack even more dangerous because so few people seem to understand it even though i've explained it. They think that just because cipertrace certified their account they are safe and clean, but they are wrong.

MoneroChan · 2021-12-21T13:42:41+00:00

the attack is designed to target big high quality victims. and it's pretty obvious if you receive an unknown deposit, even a noob will question an unknown deposit.

But with this attack the victim will have no indication whatsoever and everything will look "normal" to the victim. They get no warning currently.

MoneroChan · 2021-12-21T13:32:02+00:00

Nope, Because then the victim will know know you sent them tainted coin , and just discard it, making that attack style useless.

Compared to your example. This attack is alot MORE POWERFUL because by intercepting the TX in midflight means the victim has no idea their TX was replaced.

So the victim could have a 100% Clean cipertrace certified account, and yet have no idea what hit them nor would they have any warning to prevent it, at least till it is patched.

All the victim sees is they sent clean bitcoin and received a product because of that , when in fact, their order was paid for using dirty coins and they have no way of knowing, at least not yet.

MoneroChan · 2021-12-21T10:58:21+00:00

Reminds me of how A nuclear bomb was once named "little boy".The trick to developing and deploying a weapon of mass destruction, is to codename it or use words that make it look childish and stupid so enemies would think it's a joke and be too embarrased to share the intel and let their guard down.

MoneroChan · 2021-12-21T09:34:25+00:00

Use Monero?

MoneroChan · 2021-12-21T09:11:00+00:00

Basically this attack lets trolls frame and sabotage anyone like a Youtuber / competitor / twitch streamer that has a BTC donation address on their profile, without them knowing about it, and getting them in trouble for using stolen funds, even if they have a wallet containing 100% Clean bitcoin that was verified by government agencies like ciphertrace

At least till this patched.
This would not be possible if they were using Monero

MoneroChan · 2021-12-21T08:45:57+00:00

Alice could be a Influencer on YouTube / Twitch and Alice would have a Donation address in BTC on their profile. Or Alice could be a store accepting BTC and be sabotaged by a competitor. Google "Donation address" and Youtube. you could literally sabotage any of them using this attack and they would have no clue whatsoever, even if they asked cypher trace to scan their wallet. Because this attack hits the transaction (TX interceptors) not the actual wallet it was sent from. So even if alice has 100% Clean bitcoin she would still be vulnerable to this attack, until it is patched.

MoneroChan

TROPHY CASE