Blockchain/ Distributed Ledger

------------------------------
Kurt Seifried
Chief Blockchain Officer and Director of Special Projects
Cloud Security Alliance
[email protected]
------------------------------

That was approach taken by CSA GCR for Cypto Exchange Security risks. They have come up with top 20 and then nail the list down to Top 10 risk.

A chinese version will be avalible soon once the review is finalized. 


------------------------------
Ken Huang Chair, Blockchain Security Working Group, CSA GCR
------------------------------

Original Message:
Sent: Sep 15, 2020 06:38:10 PM
From: Kurt Seifried
Subject: Thoughts on smart contracts vulnerabilities categorization and CWE (cwe.mitre.org)

So to recap: we have CWE (Common Weakness Enumeration Common Weakness Enumeration) which is an attempt to catalog and provide information about specific weaknesses in software, hardware and architecture to some degree. 

In short: you can't manage what you don't even have names for, or agreed meanings, e.g. "memory leak" - are we talking about a situation where the system accidentally exposes information in memory when the memory is released (and not cleared before release), or the situation where a system slowly uses up and never frees memory? 

CWE-401: Missing Release of Memory after Effective Lifetime

CWE-244: Improper Clearing of Heap Memory Before Release

As G.I. Joe says: "and knowing is half the battle".

So CWE is awesome, right? Well, not really, it suffers from the same problem that dictionaries and phone books (remember those?) have. It's a huge resource with almost 900 entries, and it's still nowhere complete (it has almost no Blockchain specific terms). It's hard to use and not overly actionable:

1) How do you find these weaknesses? Answer: Find a tool..? CWE is just the dictionary

2) How do you fix these vulnerabilities? Answer: err.. find language/framework/other specific documentation?

3) How do you educate people about these weaknesses so they stop creating vulnerabilities? Answer: Err.. get a comp sci degree and decide to devote your life to Information Security? I don't actually know. 

4) Which of these vulnerabilities matter most? Good news: there are a few views, e.g. the OWASP top 10 that try to help with this question.

I would suggest we focus on a subset of Blockchain and related weaknesses, even my list at 190+ is to big to be useful (https://docs.google.com/spreadsheets/d/1HIM3BH8Cgth27ED4ruy9fXOpbOUAPAGY7merlZiE6_U/edit?usp=drive_web&ouid=112969240696754954097).

One possible manner to do this is by using the list of DLT security incidents I started compiling to see which ones are actually being exploited (badly enough to make the news...) which is available at https://github.com/cloudsecurityalliance/DLT-Security-Framework/blob/master/DLT-Security-Incidents.csv

 

I would further suggest we try to winnow the list down to a top 10 or 20 that really matter and focussing on this initially (and also so we don't get stuck trying to make a comprehensive document that ends up being too big to be useful anyways).

 

Why and how these weaknesses get exploited, and why they matter (in other words how do you convince a Project Manager to allocate resources to dealing with them?) would be nice, when you're telling people "slow down on features so we can do X" you better be able to articulate why X is important.

I could also be wrong, so comments/feedback is welcome and appreciated. 

------------------------------
Kurt Seifried
Chief Blockchain Officer and Director of Special Projects
Cloud Security Alliance
[email protected]
------------------------------

For smart contract, on top of my head, the list could be

1) Re-entrence bug
2) Integer overflow
3) improper access control
4) misuse of modifier
5)unchecked return value
6) bad random number
7) front running
8)time manipulation...

------------------------------
Ken Huang Chair, Blockchain Security Working Group, CSA GCR
------------------------------

Original Message:
Sent: Sep 15, 2020 06:38:10 PM
From: Kurt Seifried
Subject: Thoughts on smart contracts vulnerabilities categorization and CWE (cwe.mitre.org)

So to recap: we have CWE (Common Weakness Enumeration Common Weakness Enumeration) which is an attempt to catalog and provide information about specific weaknesses in software, hardware and architecture to some degree. 

In short: you can't manage what you don't even have names for, or agreed meanings, e.g. "memory leak" - are we talking about a situation where the system accidentally exposes information in memory when the memory is released (and not cleared before release), or the situation where a system slowly uses up and never frees memory? 

CWE-401: Missing Release of Memory after Effective Lifetime

CWE-244: Improper Clearing of Heap Memory Before Release

As G.I. Joe says: "and knowing is half the battle".

So CWE is awesome, right? Well, not really, it suffers from the same problem that dictionaries and phone books (remember those?) have. It's a huge resource with almost 900 entries, and it's still nowhere complete (it has almost no Blockchain specific terms). It's hard to use and not overly actionable:

1) How do you find these weaknesses? Answer: Find a tool..? CWE is just the dictionary

2) How do you fix these vulnerabilities? Answer: err.. find language/framework/other specific documentation?

3) How do you educate people about these weaknesses so they stop creating vulnerabilities? Answer: Err.. get a comp sci degree and decide to devote your life to Information Security? I don't actually know. 

4) Which of these vulnerabilities matter most? Good news: there are a few views, e.g. the OWASP top 10 that try to help with this question.

I would suggest we focus on a subset of Blockchain and related weaknesses, even my list at 190+ is to big to be useful (https://docs.google.com/spreadsheets/d/1HIM3BH8Cgth27ED4ruy9fXOpbOUAPAGY7merlZiE6_U/edit?usp=drive_web&ouid=112969240696754954097).

One possible manner to do this is by using the list of DLT security incidents I started compiling to see which ones are actually being exploited (badly enough to make the news...) which is available at https://github.com/cloudsecurityalliance/DLT-Security-Framework/blob/master/DLT-Security-Incidents.csv

 

I would further suggest we try to winnow the list down to a top 10 or 20 that really matter and focussing on this initially (and also so we don't get stuck trying to make a comprehensive document that ends up being too big to be useful anyways).

 

Why and how these weaknesses get exploited, and why they matter (in other words how do you convince a Project Manager to allocate resources to dealing with them?) would be nice, when you're telling people "slow down on features so we can do X" you better be able to articulate why X is important.

I could also be wrong, so comments/feedback is welcome and appreciated. 

------------------------------
Kurt Seifried
Chief Blockchain Officer and Director of Special Projects
Cloud Security Alliance
[email protected]
------------------------------

Ok so I'm familiar with most but not all. #4 specifically:

4) misuse of modifer

This is referring to Ethereum Solidity "pure and view are built-in state modifiers." I assume? If so a bit of digging shows some interesting history:

Initially these are promises made by the function, but not enforced as per https://medium.com/coinmonks/ethernaut-lvl-11-elevator-walkthrough-how-to-abuse-solidity-interfaces-and-function-state-41005470121d

Starting in 0.5.0 this is now enforced

If the compiler's EVM target is Byzantium or newer (default) the opcode STATICCALL is used for view functions which enforces the state to stay unmodified as part of the EVM execution. For library view functions DELEGATECALL is used, because there is no combined DELEGATECALL and STATICCALL. This means library view functions do not have run-time checks that prevent state modifications. This should not impact security negatively because library code is usually known at compile-time and the static checker performs compile-time checks.

https://solidity.readthedocs.io/en/v0.5.0/contracts.html

And as of later it's explicit as well:

Prior to version 0.5.0, the compiler did not use the STATICCALL opcode for view functions. This enabled state modifications in view functions through the use of invalid explicit type conversions. By using STATICCALL for view functions, modifications to the state are prevented on the level of the EVM.

https://solidity.readthedocs.io/en/v0.6.0/contracts.html

So that's nice to see (they fixed the weakness). Are there a lot of older contracts locked to pre 0.5.0 versions of solidity that are vulnerable to this weakness?

If the above is n ot correct please let me know, thanks.



​

------------------------------
Kurt Seifried
Chief Blockchain Officer and Director of Special Projects
Cloud Security Alliance
[email protected]
------------------------------

Original Message:
Sent: Sep 15, 2020 07:22:02 PM
From: Ken Huang
Subject: Thoughts on smart contracts vulnerabilities categorization and CWE (cwe.mitre.org)

For smart contract, on top of my head, the list could be

1) Re-entrence bug
2) Integer overflow
3) improper access control
4) misuse of modifier
5)unchecked return value
6) bad random number
7) front running
8)time manipulation...

------------------------------
Ken Huang Chair, Blockchain Security Working Group, CSA GCR

Original Message:
Sent: Sep 15, 2020 06:38:10 PM
From: Kurt Seifried
Subject: Thoughts on smart contracts vulnerabilities categorization and CWE (cwe.mitre.org)

So to recap: we have CWE (Common Weakness Enumeration Common Weakness Enumeration) which is an attempt to catalog and provide information about specific weaknesses in software, hardware and architecture to some degree. 

In short: you can't manage what you don't even have names for, or agreed meanings, e.g. "memory leak" - are we talking about a situation where the system accidentally exposes information in memory when the memory is released (and not cleared before release), or the situation where a system slowly uses up and never frees memory? 

CWE-401: Missing Release of Memory after Effective Lifetime

CWE-244: Improper Clearing of Heap Memory Before Release

As G.I. Joe says: "and knowing is half the battle".

So CWE is awesome, right? Well, not really, it suffers from the same problem that dictionaries and phone books (remember those?) have. It's a huge resource with almost 900 entries, and it's still nowhere complete (it has almost no Blockchain specific terms). It's hard to use and not overly actionable:

1) How do you find these weaknesses? Answer: Find a tool..? CWE is just the dictionary

2) How do you fix these vulnerabilities? Answer: err.. find language/framework/other specific documentation?

3) How do you educate people about these weaknesses so they stop creating vulnerabilities? Answer: Err.. get a comp sci degree and decide to devote your life to Information Security? I don't actually know. 

4) Which of these vulnerabilities matter most? Good news: there are a few views, e.g. the OWASP top 10 that try to help with this question.

I would suggest we focus on a subset of Blockchain and related weaknesses, even my list at 190+ is to big to be useful (https://docs.google.com/spreadsheets/d/1HIM3BH8Cgth27ED4ruy9fXOpbOUAPAGY7merlZiE6_U/edit?usp=drive_web&ouid=112969240696754954097).

One possible manner to do this is by using the list of DLT security incidents I started compiling to see which ones are actually being exploited (badly enough to make the news...) which is available at https://github.com/cloudsecurityalliance/DLT-Security-Framework/blob/master/DLT-Security-Incidents.csv

 

I would further suggest we try to winnow the list down to a top 10 or 20 that really matter and focussing on this initially (and also so we don't get stuck trying to make a comprehensive document that ends up being too big to be useful anyways).

 

Why and how these weaknesses get exploited, and why they matter (in other words how do you convince a Project Manager to allocate resources to dealing with them?) would be nice, when you're telling people "slow down on features so we can do X" you better be able to articulate why X is important.

I could also be wrong, so comments/feedback is welcome and appreciated. 

------------------------------
Kurt Seifried
Chief Blockchain Officer and Director of Special Projects
Cloud Security Alliance
[email protected]
------------------------------

Hi, this effort has already been conducted multiple times across the industry. In specific for ethereum smart contract technology you have smart contract weakness classification https://swcregistry.io/ a reference well respected and known by the experts in the field. 



------------------------------
Chaddy Huussin Blockchain Security
------------------------------

Original Message:
Sent: Sep 15, 2020 06:38:10 PM
From: Kurt Seifried
Subject: Thoughts on smart contracts vulnerabilities categorization and CWE (cwe.mitre.org)

So to recap: we have CWE (Common Weakness Enumeration Common Weakness Enumeration) which is an attempt to catalog and provide information about specific weaknesses in software, hardware and architecture to some degree. 

In short: you can't manage what you don't even have names for, or agreed meanings, e.g. "memory leak" - are we talking about a situation where the system accidentally exposes information in memory when the memory is released (and not cleared before release), or the situation where a system slowly uses up and never frees memory? 

CWE-401: Missing Release of Memory after Effective Lifetime

CWE-244: Improper Clearing of Heap Memory Before Release

As G.I. Joe says: "and knowing is half the battle".

So CWE is awesome, right? Well, not really, it suffers from the same problem that dictionaries and phone books (remember those?) have. It's a huge resource with almost 900 entries, and it's still nowhere complete (it has almost no Blockchain specific terms). It's hard to use and not overly actionable:

1) How do you find these weaknesses? Answer: Find a tool..? CWE is just the dictionary

2) How do you fix these vulnerabilities? Answer: err.. find language/framework/other specific documentation?

3) How do you educate people about these weaknesses so they stop creating vulnerabilities? Answer: Err.. get a comp sci degree and decide to devote your life to Information Security? I don't actually know. 

4) Which of these vulnerabilities matter most? Good news: there are a few views, e.g. the OWASP top 10 that try to help with this question.

I would suggest we focus on a subset of Blockchain and related weaknesses, even my list at 190+ is to big to be useful (https://docs.google.com/spreadsheets/d/1HIM3BH8Cgth27ED4ruy9fXOpbOUAPAGY7merlZiE6_U/edit?usp=drive_web&ouid=112969240696754954097).

One possible manner to do this is by using the list of DLT security incidents I started compiling to see which ones are actually being exploited (badly enough to make the news...) which is available at https://github.com/cloudsecurityalliance/DLT-Security-Framework/blob/master/DLT-Security-Incidents.csv

 

I would further suggest we try to winnow the list down to a top 10 or 20 that really matter and focussing on this initially (and also so we don't get stuck trying to make a comprehensive document that ends up being too big to be useful anyways).

 

Why and how these weaknesses get exploited, and why they matter (in other words how do you convince a Project Manager to allocate resources to dealing with them?) would be nice, when you're telling people "slow down on features so we can do X" you better be able to articulate why X is important.

I could also be wrong, so comments/feedback is welcome and appreciated. 

------------------------------
Kurt Seifried
Chief Blockchain Officer and Director of Special Projects
Cloud Security Alliance
[email protected]
------------------------------

I've integrated that list into the master list already:

https://docs.google.com/spreadsheets/d/1HIM3BH8Cgth27ED4ruy9fXOpbOUAPAGY7merlZiE6_U

Long story short: we ultimately want both a more comprehensive list (long term) and the ones that actually really matter (short term). I've also reached out to them about coordination with CWE, but their discord chat was not active.

------------------------------
Kurt Seifried
Chief Blockchain Officer and Director of Special Projects
Cloud Security Alliance
[email protected]
------------------------------

Original Message:
Sent: Sep 16, 2020 01:40:11 PM
From: Chaddy Huussin
Subject: Thoughts on smart contracts vulnerabilities categorization and CWE (cwe.mitre.org)

Hi, this effort has already been conducted multiple times across the industry. In specific for ethereum smart contract technology you have smart contract weakness classification https://swcregistry.io/ a reference well respected and known by the experts in the field. 



------------------------------
Chaddy Huussin Blockchain Security

Original Message:
Sent: Sep 15, 2020 06:38:10 PM
From: Kurt Seifried
Subject: Thoughts on smart contracts vulnerabilities categorization and CWE (cwe.mitre.org)

So to recap: we have CWE (Common Weakness Enumeration Common Weakness Enumeration) which is an attempt to catalog and provide information about specific weaknesses in software, hardware and architecture to some degree. 

In short: you can't manage what you don't even have names for, or agreed meanings, e.g. "memory leak" - are we talking about a situation where the system accidentally exposes information in memory when the memory is released (and not cleared before release), or the situation where a system slowly uses up and never frees memory? 

CWE-401: Missing Release of Memory after Effective Lifetime

CWE-244: Improper Clearing of Heap Memory Before Release

As G.I. Joe says: "and knowing is half the battle".

So CWE is awesome, right? Well, not really, it suffers from the same problem that dictionaries and phone books (remember those?) have. It's a huge resource with almost 900 entries, and it's still nowhere complete (it has almost no Blockchain specific terms). It's hard to use and not overly actionable:

1) How do you find these weaknesses? Answer: Find a tool..? CWE is just the dictionary

2) How do you fix these vulnerabilities? Answer: err.. find language/framework/other specific documentation?

3) How do you educate people about these weaknesses so they stop creating vulnerabilities? Answer: Err.. get a comp sci degree and decide to devote your life to Information Security? I don't actually know. 

4) Which of these vulnerabilities matter most? Good news: there are a few views, e.g. the OWASP top 10 that try to help with this question.

I would suggest we focus on a subset of Blockchain and related weaknesses, even my list at 190+ is to big to be useful (https://docs.google.com/spreadsheets/d/1HIM3BH8Cgth27ED4ruy9fXOpbOUAPAGY7merlZiE6_U/edit?usp=drive_web&ouid=112969240696754954097).

One possible manner to do this is by using the list of DLT security incidents I started compiling to see which ones are actually being exploited (badly enough to make the news...) which is available at https://github.com/cloudsecurityalliance/DLT-Security-Framework/blob/master/DLT-Security-Incidents.csv

 

I would further suggest we try to winnow the list down to a top 10 or 20 that really matter and focussing on this initially (and also so we don't get stuck trying to make a comprehensive document that ends up being too big to be useful anyways).

 

Why and how these weaknesses get exploited, and why they matter (in other words how do you convince a Project Manager to allocate resources to dealing with them?) would be nice, when you're telling people "slow down on features so we can do X" you better be able to articulate why X is important.

I could also be wrong, so comments/feedback is welcome and appreciated. 

------------------------------
Kurt Seifried
Chief Blockchain Officer and Director of Special Projects
Cloud Security Alliance
[email protected]
------------------------------