Author Topic: An attack on DevShares  (Read 22494 times)

0 Members and 1 Guest are viewing this topic.

Offline Come-from-Beyond

  • Full Member
  • ***
  • Posts: 113
    • View Profile
It would be difficult (or restrictive for end users) to implement such solution for bitshares.

This world is not ideal, it's full of trade-offs...

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
Right. Can you give an example?

EDIT: Reminds me when you look up 'beautiful' and the definition is 'full of beauty'

Offline Come-from-Beyond

  • Full Member
  • ***
  • Posts: 113
    • View Profile
What is an "anti-sybil solution"? I know what sybil attacks are.

Anti-sybil solution is something that mitigates sybil attacks.

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
What is an "anti-sybil solution"? I know what sybil attacks are.

It would be difficult (or restrictive for end users) to implement such solution for bitshares.
I'm not sure if there are plans for such anti-sybil solution. I cant remember it being discussed at all.

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
What is an "anti-sybil solution"? I know what sybil attacks are.

Offline Come-from-Beyond

  • Full Member
  • ***
  • Posts: 113
    • View Profile
Similar method to your next attack scenario is used to identify TOR nodes. It might work provided you have enough nodes and/or the "victim" is connected to one of them.

Ok, but it's easily fixable with an anti-Sybil solution. Just add it to the schedule if TITAN is vulnerable to such kind of attack.

Edit: Actually anti-Sybil protects against a lot of attacks, I need some time to devise something that doesn't use a Sybil attack as an opening move.
« Last Edit: February 10, 2015, 03:53:17 pm by Come-from-Beyond »

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
Delegates can easily avoid this by using relays in such a way that the delegate is connected only to relays. Relays will not forward invalid or duplicate transactions.
Valid transactions are OK provided they have sufficient trx fee. It is OK to flood the network with transactions. You'll pay the price.

However your method will reliably filter out unprepared delegates. That is a good exercise I was meaning to do for a long time.

So my attack was deflected. Ok, the next one:

Attack scenario

I flood the network with sybil nodes and start monitoring transaction flow. Using the same trick as I used for detecting the delegates, can I find the origin of TITAN-related transactions?

Dont be so quick to mark the attack as deflected. I think 80%+ of the delegates will fall for it. It should be attempted. It might show flaws that we've never thought about.

Similar method to your next attack scenario is used to identify TOR nodes. It might work provided you have enough nodes and/or the "victim" is connected to one of them.

Offline Come-from-Beyond

  • Full Member
  • ***
  • Posts: 113
    • View Profile
Delegates can easily avoid this by using relays in such a way that the delegate is connected only to relays. Relays will not forward invalid or duplicate transactions.
Valid transactions are OK provided they have sufficient trx fee. It is OK to flood the network with transactions. You'll pay the price.

However your method will reliably filter out unprepared delegates. That is a good exercise I was meaning to do for a long time.

So my attack was deflected. Ok, the next one:

Attack scenario

I flood the network with sybil nodes and start monitoring transaction flow. Using the same trick as I used for detecting the delegates, can I find the origin of TITAN-related transactions?

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
Attack scenario

1st phase is to find IP addresses of the delegates if they are not known:

1. Connect to as many nodes as possible.
2. Memorize time moments when nodes share a new block.
3. Analyze block travel graph trying to find its origin.

2nd phase is to check if anti-spam is used:

1. Prepare a list of already confirmed transactions.
2. Feed our own node with as many transactions as possible measuring CPU usage (signature validation, double-spending prevention, etc. require a lot of CPU cycles).

3rd phase is to disrupt unconfirmed transactions processing (if there is no anti-spam):

1. Feed the next delegate with as many transactions as possible.
2. Check if the generated block contains only a fraction of pending unconfirmed transactions.


This attack is easily counteracted with Hashcash-like spam prevention. If there is no anti-spam or it's not effective enough then the attack should be extended to DoS all delegates one by one.

So, what are odds that the attack will succeed to noticeable slow down inclusion of transactions into blocks?

Delegates can easily avoid this by using relays in such a way that the delegate is connected only to relays. Relays will not forward invalid or duplicate transactions.
Valid transactions are OK provided they have sufficient trx fee. It is OK to flood the network with transactions. You'll pay the price.

However your method will reliably filter out unprepared delegates. That is a good exercise I was meaning to do for a long time.
« Last Edit: February 10, 2015, 03:28:54 pm by emski »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I have disabled incoming connections for my delegate.  So cfb, you have one less avenue to attack.
Count me in ..

DDOSing seesnodes will just prevent new clients from finding seeds .. everyone can go on P2P style :)

Offline Come-from-Beyond

  • Full Member
  • ***
  • Posts: 113
    • View Profile
I have disabled incoming connections for my delegate.  So cfb, you have one less avenue to attack.

I was planning to use Sybil attack as part of deanonymization attack on TITAN, so I wouldn't feel myself comfortable even with disabled connections...

Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
I have disabled incoming connections for my delegate.  So cfb, you have one less avenue to attack.
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline Come-from-Beyond

  • Full Member
  • ***
  • Posts: 113
    • View Profile
Delegate nodes should not allow incoming connections.   There is a flag set to disable incoming connections just for this purpose.

Ok, then I'll flood the network with sybil identities and delegates will connect to my nodes in 9 of 10 cases.

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
Attack scenario
1st phase is to find IP addresses of the delegates if they are not known:

Delegate nodes should not allow incoming connections.   There is a flag set to disable incoming connections just for this purpose.

then I must make a proposal ...
when a delegate runs the command:
"wallet_delegate_set_block_production "
and he change it to "true"...
 the client could show a message that suggest the delegate to make exactly what you described... I assume the majority have not disabled incoming connections yet  :-[


PS
"Easily Configure a Host-Based Firewall on Ubuntu to Block Incoming Connections"
http://blog.nowherelan.com/2014/01/14/easily-configure-a-host-based-firewall-on-ubuntu-to-block-incoming-connections/

PSS what happens if somebody tries to attack all seed-nodes at once? (incoming connections must be enabled
 for them)
« Last Edit: February 10, 2015, 03:10:02 pm by liondani »

Offline bytemaster

Attack scenario
1st phase is to find IP addresses of the delegates if they are not known:

Delegate nodes should not allow incoming connections.   There is a flag set to disable incoming connections just for this purpose.   
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.