Lisk Dynamic Forging Controller Launched by Lemii after 2 Community Security Bounties

At the end of August Lemii launched a Community Security Bounty, followed by a second round. They were focused on testing a security tool, recently launched with the name of Lisk Dynamic Forging Controller. This project was created with inspiration and advice from Stellardynamic.

Tool link: https://github.com/sidechain-solutions/lisk-dfc

The goal of the first contest was to bring down lemii’s forging delegate on testnet. If you succeeded in doing so, you were rewarded with 200 LSK. The goal of the test was to see if all measures that have been taken were working as intended.
The rules were as follows: the attack is considered to be successful when his delegate was forced to miss two blocks (or more) in a row; the attack must be targeted at his delegate specifically;  network wide attacks do no count; only one winner, first to cause the two missed blocks wins; the attack must be announced prior in chat to proof that it’s yours.

The goal of the second Community Security Bounty, launched in early September, was the same and the winner should have been rewarded with 150 LSK. This time the attacker had to force lemii’s delegate to miss 5 blocks (or more) in a row, or 10% of all blocks in the bounty time frame.
The blocks that his delegate misses can be tracked here: http://mbt.sidechainsolutions.io/ (Tony developed this tool)

Lisk Dynamic Forging Controller (Lisk DFC) has been developed to provide controller/monitoring services with the following features:

• Randomizes the node that your delegate will forge on

• Ensures that forging is enabled

• Mitigates the chance of having multiple forging services active at the same time

• Auto-corrects potential issues

• Sends alerts via email

• Comes with an additional toolset for manual toggling and verification

Lisk DFC is designed to manage an array of forger nodes: it verifies if the current node is still forging and in case of negative answer, it fixes it. It also verifies that none of the other nodes are also forging, and if required, corrects the issue.

As reported by Stellardynamic, in Round 1 of the contest they had an automatic switching array of 12 forging servers managed by the Lisk Dynamic Forging Controller. The performance of the tool was good, but due to the nature of the p2p network there was still an issue. It is in fact possible to deanonymize delegate servers and GYM exploited this security issue to track down all 12 IPs that were publishing blocks. The report continues with the following words: “With the IPs, he was able to issue an attack in Lisk Core that made Lemii miss the required two blocks. We are now able to confirm the traffic that caused that was delivered through port 7001, the Websockets port. This prompted me to see if forging with incoming denied to this port was possible. It is. Forging Nodes can stay in sync and submit blocks with ALL PORTS DENIED INCOMING INCLUDING THE LISK PORTS IF UNDER ATTACK. All you need to do is be up to sync when it’s time to push your block. Even though it’s a bit slower, you will still pull the blocks you need from your peers and remain in sync faster than the 10 second block window. We can confirm two full weeks of forging this way without a problems. This technique can be used effectively as a universal defense against some attacks in both Websockets and Core in general. Denying incoming via UFW is what caused GYM to adapt to a more creative and obscure attack that we cannot disclose at this time. We are however developing a defense for it and will release it publicly as soon as possible.”

———————————————-
Lisk Magazine is a project supported by Lisk Italian Group and EliteX.
Support our work, vote for Lisk Magazine.