New Bitcoin DDoS Technique(github.com)
github.com
New Bitcoin DDoS Technique
https://github.com/bitcoin/bitcoin/issues/26585
35 comments
i considered this and needed clarification. i didn't know whether the p2p connections remained open or made frequent disconnect/reconnects. what happens to sync'd nodes with active peers is yet to be seen. it's too early, at least for me, to know whether peers would drop a node under attack over timeouts, how bitcoind behaves with peers while tcp/8333 is experiencing stress, etc.
A large portion of a nodes connections live as long as possible given the uptime of the connected nodes. Care is taken it protect long working connections to provide as strong a protection against new and short lived attacks as possible-- a working network should stay working. A sustained attack can frustrate newly connecting/restarting hosts when the recipient is publicly reachable and known to the attacker, but I think that's essentially insoluble (if nothing else, a volumetric attack would guarantee it).
If you're going to be making announcements and whatever, you probably should have taken the time to characterize your observations completely! The failure to do so makes it kinda just look like more lamesauce attempts at market manipulation (not to lob an accusation, it's just what it looks like -- there is a long history of that kind of activity).
> it's too early, at least for me, to know whether peers would drop a node under attack over timeouts,
Do your homework! You're not the first person who ever thought of attacking a bitcoin node. While I'm sure there are areas for improvement, you're not likely to be able to make useful suggestions from a position of almost total ignorance.
If you're going to be making announcements and whatever, you probably should have taken the time to characterize your observations completely! The failure to do so makes it kinda just look like more lamesauce attempts at market manipulation (not to lob an accusation, it's just what it looks like -- there is a long history of that kind of activity).
> it's too early, at least for me, to know whether peers would drop a node under attack over timeouts,
Do your homework! You're not the first person who ever thought of attacking a bitcoin node. While I'm sure there are areas for improvement, you're not likely to be able to make useful suggestions from a position of almost total ignorance.
>Do your homework! You're not the first person who ever thought of attacking a bitcoin node. While I'm sure there are areas for improvement, you're not likely to be able to make useful suggestions from a position of almost total ignorance.
again, i've successfully found remote crashes and dos issues in 25 - 30 blockchains. i don't care if you're a biased developer who takes this to heart. i'm going to see to brutalizing bitcoind and making it clear to you what happens when i attack nodes. cocky academics like you motivate me. he who laughs last etc.
again, i've successfully found remote crashes and dos issues in 25 - 30 blockchains. i don't care if you're a biased developer who takes this to heart. i'm going to see to brutalizing bitcoind and making it clear to you what happens when i attack nodes. cocky academics like you motivate me. he who laughs last etc.
Fantastic, I'm sure the bitcoin developers will appreciate the free labor. But if you care you have any reputation as anything but a hotheaded fool-- you should probably tone the public announcements down until you've actually completed your work! Otherwise, even when you do carry work though until you find something interesting (and I'm sure you would if you work at it long enough)-- you'll still have earned a poor reputation regardless.
i don't guard my reputation. this isn't 48 laws of power. i'd never become a blockchain socialite to the extent of social climbing to become blockstream's cto. i answer to no one and don't try to mold how others perceive me. interesting insults though - though i can assure you wholeheartedly that you don't want to make it personal. just so you know where you stand, who i am and who pulls rank on who. i rce'd slack too. bitcoin is food now. there is a dos here regardless - but thanks for the motivation
Haha. Typical digitalgangster/aoler/irc kiddie behavior. You are no one. You have no power. Your obsession with vanity handles shows who you are and what you're about. Making an announcement on a non-bug when you don't know about slowloris style attacks or how a one-liner derails your entire existence is just sad.
This is a great opportunity to get your ego in check. If you're really interested in security, follow the right path. No one here is impressed that you RCE'd slack (likely using someone else's research, and exploit dev nonetheless). No one is impressed with your Twitter or livejournal handle. And btw fuck anti and rj2 and the rest of those spam/scammers.
You probably smell bad. Dork.
This is a great opportunity to get your ego in check. If you're really interested in security, follow the right path. No one here is impressed that you RCE'd slack (likely using someone else's research, and exploit dev nonetheless). No one is impressed with your Twitter or livejournal handle. And btw fuck anti and rj2 and the rest of those spam/scammers.
You probably smell bad. Dork.
There are many tools that will help you answer things like this i.e. Wireshark.
He's just DDoSing himself.
Unless there's been a significant regression these issues were fixed after I found the slowloris type attacks to be an issue in 2012.
Edit: Maybe he's attacking his own RPC port, which again doesn't matter since it's not open to the internet.
Unless there's been a significant regression these issues were fixed after I found the slowloris type attacks to be an issue in 2012.
Edit: Maybe he's attacking his own RPC port, which again doesn't matter since it's not open to the internet.
yes - testing his own node. that is how pen testing blockchain nodes works. from there you can make projections of scaled attacks.
it's not an rpc port - and the computer in the screen shot using telnet is an external machine that isn't participating in the attack.
it's not an rpc port - and the computer in the screen shot using telnet is an external machine that isn't participating in the attack.
Nah all that's happening is he's using connection slots.
The attacking node will have a very low score and get disconnected when other legitimate connections are made.
The attacking node will have a very low score and get disconnected when other legitimate connections are made.
50k sockets looping requests make the p2p port entirely inaccessible at times. with more attacking machines it is reasonable to suspect that the target node(s) could be held down in perpetuity.
edit: re: child comment / syn flood; sure. bitcoind needs ip associated throttling baked in. there is no rationale behind a single machine attempting 1k handshakes a second. the attack shouldn't work at all.
edit: re: child comment / syn flood; sure. bitcoind needs ip associated throttling baked in. there is no rationale behind a single machine attempting 1k handshakes a second. the attack shouldn't work at all.
You may as well just SYN flood at that point. None of this is really new, you can take down a lot of TCP based servers with the right combination of packets and volume.
It’s also reasonable to prevent this sort of abuse using a firewall or rate limiting load balancer..
Inaccessible from the machine doing the attack.
But is it preventing the node from communicating with the rest of the network?
That's a big doubt from me.
But is it preventing the node from communicating with the rest of the network?
That's a big doubt from me.
inaccessible to external machines that are not participating in the attack. it's yet to be seen what happens to a node that's sync'd with active peers and whether a node under attack is kicked out of the network for timeouts or how bitcoind behaves in general while tcp/8333 is under fire.
> it's yet to be seen
It's yet to be seen by you. But you are not the first person to have thought of characterizing this behavior in the last decade. Some other people have actually done so, including the person you're responding to! (who successfully discovered and fixed a number of vulnerabilities years ago)
I tested and existing connections continue to work fine w/ a connection exhausted peer, as expected. It sounds like you're saying that you haven't tested this. If you do and get a different result, I'm sure the bitcoin devs would like to hear about it.
It's yet to be seen by you. But you are not the first person to have thought of characterizing this behavior in the last decade. Some other people have actually done so, including the person you're responding to! (who successfully discovered and fixed a number of vulnerabilities years ago)
I tested and existing connections continue to work fine w/ a connection exhausted peer, as expected. It sounds like you're saying that you haven't tested this. If you do and get a different result, I'm sure the bitcoin devs would like to hear about it.
i've popped 25 - 30+ blockchains. from anecdotal experience i suspect that there could be something here and need to see it through with a sync'd node and more firepower. you seem overconfident.
> i've popped 25 - 30+ blockchains
Most "blockchains" are just garbage scams. Many are just whitelabled junk put out by scamcoin factories-- development sweatshops that bang out whatever features at least appear to fulfill some nonsense a non-engineer wrote in some marketing whitepaper, in exchange for some payment. Then they pay exchanges to list then, pay influencers to hype them, dump their premines on the suckers who bought in and then wash rinse repeat until they're either wealthy enough to quit or blow their bankroll on a pump that fails.
If any of those are secure from attack at all it's mostly by accident -- security is certainly not a goal for them, and a non-fatal attack would just be a bit of free marketing.
Even ones that are less intentionally scammy, spend much of their time essentially failed under their own weight due to a lack of any technical competence supporting them.
> i suspect that there could be something here
A fine starting point for research, not a reason to make a public announcement.
Not even knowing if connections are long lived or not really shows you haven't even bothered checking on the most basic stuff that you could easily find with a few minutes of reading.
Most "blockchains" are just garbage scams. Many are just whitelabled junk put out by scamcoin factories-- development sweatshops that bang out whatever features at least appear to fulfill some nonsense a non-engineer wrote in some marketing whitepaper, in exchange for some payment. Then they pay exchanges to list then, pay influencers to hype them, dump their premines on the suckers who bought in and then wash rinse repeat until they're either wealthy enough to quit or blow their bankroll on a pump that fails.
If any of those are secure from attack at all it's mostly by accident -- security is certainly not a goal for them, and a non-fatal attack would just be a bit of free marketing.
Even ones that are less intentionally scammy, spend much of their time essentially failed under their own weight due to a lack of any technical competence supporting them.
> i suspect that there could be something here
A fine starting point for research, not a reason to make a public announcement.
Not even knowing if connections are long lived or not really shows you haven't even bothered checking on the most basic stuff that you could easily find with a few minutes of reading.
[deleted]
you may be correct. the issue has been closed for further review. a scaled attack might only prevent new nodes from entering the network as existing connections would be spared even when the maximum limit of peers is reached.
however - and i mean this - you need to watch your mouth buddy. you've been unnecessarily rude. i have decided not to respond with force - so either stfu or press your luck
however - and i mean this - you need to watch your mouth buddy. you've been unnecessarily rude. i have decided not to respond with force - so either stfu or press your luck
Prove it. Setup a node and test this method on it. Otherwise this comment should be redacted.
Sending lots of junk connections to a service will degrade performance.
News at eleven.
News at eleven.
bitcoind not having ip associated throttling edit: BUILT IN* is questionable. this attack shouldn't work on out-of-the-box installs of bitcoin. as i mentioned earlier - there is no rationale behind a single machine making 1k handshake requests per second.
sudo iptables --append INPUT --source 123.123.123.123 --jump DROPnode operators can implement their own throttling - sure - but how many bitcoin node operators are doing that to deflect a p2p ddos attack? even if some are, most aren't - and finality in the network could potentially suffer as a result of a massively scaled botnet attack.
edit: interesting child comment here. not pushing a patch just leaves the bulk of the network vulnerable to being ddos'd by a botnet - potentially resulting in severely lagged finality at best. ip throttling can/should be implemented by being baked into bitcoind.
edit: interesting child comment here. not pushing a patch just leaves the bulk of the network vulnerable to being ddos'd by a botnet - potentially resulting in severely lagged finality at best. ip throttling can/should be implemented by being baked into bitcoind.
A one-liner, from a one-purpose-unix standard tool, 20 seconds fix is enough; what more do you want?
This is a not a bug / won't fix
This is a not a bug / won't fix
The attacker used multiple nodes. Read the GitHub issue again. You are going to need more than one line and at some point you are going to notice that you want a software solution.
it is slowloris [1] isn't it ?
[1] https://en.wikipedia.org/wiki/Slowloris_(computer_security)
[1] https://en.wikipedia.org/wiki/Slowloris_(computer_security)
[deleted]
Slightly more details here:
https://g.livejournal.com/14363.html
https://g.livejournal.com/14363.html
This doesn't appear to be new or interesting: If you exhaust a hosts incoming sockets it temporarily can't accept new connections.
Bitcoin itself already prioritizes existing and "good" connections to a substantial extent. Networks and IPs with multiple existing connections are prioritized for disconnection to handle new connections[1]. The result is that most existing connections are undisturbed, which makes it fairly ineffectual as an attack-- unless someone has broken something in the last couple years since I worked on it. A few years ago there were some periodic waves of people attempting attacks like this that went completely unnoticed in public due to their lack of meaningful effect.
It's annoying that new connections can be frustrated while an attack is ongoing, but since bitcoin connections are extremely long lived it doesn't have much of an impact, which is the security property the software is intended to uphold. The comment about 'finalization' suggests the author of the post isn't particularly familiar with how bitcoin works.
And at least if the attack is at a high enough rate, since the exhaustion will happen at the kernel before it gets to the bitcoin software, there isn't much for the bitcoin software to do. The host can implement firewall rules to mitigate, though even that can only work to the extent that the attack hasn't just effectively become volumetric.
It might be reasonable for the bitcoin authors to recommend some standard iptables rules that people should deploy as a best practice to protect their kernel's TCP stack (and avoid the issue that people will screw them up when coming up with their own).
[1] https://github.com/bitcoin/bitcoin/blob/master/src/node/evic...