Browse Source

add report base

master
nitowa 1 year ago
parent
commit
ee44cf9d85
4 changed files with 362 additions and 0 deletions
  1. 83
    0
      SemSEreport/exercise.bib
  2. 52
    0
      SemSEreport/exercises.bbl
  3. BIN
      SemSEreport/exercises.pdf
  4. 227
    0
      SemSEreport/exercises.tex

+ 83
- 0
SemSEreport/exercise.bib View File

@@ -0,0 +1,83 @@
1
+@INPROCEEDINGS{smartian,
2
+	author={Choi, Jaeseung and Kim, Doyeon and Kim, Soomin and Grieco, Gustavo and Groce, Alex and Cha, Sang Kil},
3
+	booktitle={2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE)},
4
+	title={SMARTIAN: Enhancing Smart Contract Fuzzing with Static and Dynamic Data-Flow Analyses},
5
+	year={2021},
6
+	volume={},
7
+	number={},
8
+	pages={227-239},
9
+	doi={10.1109/ASE51524.2021.9678888}}
10
+
11
+@inproceedings{fuzzdrivegen,
12
+	author = {Pani, Siddhasagar and Nallagonda, Harshita Vani and Vigneswaran and Medicherla, Raveendra Kumar and Rajan M},
13
+	title = {SmartFuzzDriverGen: Smart Contract Fuzzing Automation for Golang},
14
+	year = {2023},
15
+	isbn = {9798400700644},
16
+	publisher = {Association for Computing Machinery},
17
+	address = {New York, NY, USA},
18
+	url = {https://doi.org/10.1145/3578527.3578538},
19
+	doi = {10.1145/3578527.3578538},
20
+	abstract = {Greybox fuzzers require intermediate programs called fuzz drivers to test smart contract APIs. These fuzz drivers use the semi-random inputs (bytes) generated by fuzzers to prepare suitable inputs required to test APIs. Further, fuzz driver also uses this input to decide sequence in which APIs to be invoked and enables the fuzzer to execute the APIs in that sequence to find the vulnerabilities, if any. Manually writing such complex and intelligent fuzz drivers is laborious, requires deep technical skills, hence can be cumbersome and error prone. In this paper, we propose SmartFuzzDriverGen framework to automatically generate fuzz drivers which invoke smart contract APIs using different strategies: unit-level, sequence-based (random, user-defined), and heuristics based. We evaluate the proposed framework by testing a prototype implementation of it with Golang smart contracts (targeted for Hyperledger Fabric platform) and study the effectiveness of the generated fuzz drivers in terms of code coverage as well as bug finding abilities. We observed that fuzzing of APIs in random sequences performed better than the other methods.},
21
+	booktitle = {Proceedings of the 16th Innovations in Software Engineering Conference},
22
+	articleno = {14},
23
+	numpages = {11},
24
+	keywords = {smart contracts, vulnerability detection, automated driver generation, blockchain, fuzzing, sequencing},
25
+	location = {Allahabad, India},
26
+	series = {ISEC '23}
27
+}
28
+
29
+@inproceedings {teether,
30
+	author = {Johannes Krupp and Christian Rossow},
31
+	title = {{teEther}: Gnawing at Ethereum to Automatically Exploit Smart Contracts},
32
+	booktitle = {27th USENIX Security Symposium (USENIX Security 18)},
33
+	year = {2018},
34
+	isbn = {978-1-939133-04-5},
35
+	address = {Baltimore, MD},
36
+	pages = {1317--1333},
37
+	url = {https://www.usenix.org/conference/usenixsecurity18/presentation/krupp},
38
+	publisher = {USENIX Association},
39
+	month = aug
40
+}
41
+
42
+@inproceedings{securify,
43
+	author = {Tsankov, Petar and Dan, Andrei and Drachsler-Cohen, Dana and Gervais, Arthur and B\"{u}nzli, Florian and Vechev, Martin},
44
+	title = {Securify: Practical Security Analysis of Smart Contracts},
45
+	year = {2018},
46
+	isbn = {9781450356930},
47
+	publisher = {Association for Computing Machinery},
48
+	address = {New York, NY, USA},
49
+	url = {https://doi.org/10.1145/3243734.3243780},
50
+	doi = {10.1145/3243734.3243780},
51
+	abstract = {Permissionless blockchains allow the execution of arbitrary programs (called smart contracts), enabling mutually untrusted entities to interact without relying on trusted third parties. Despite their potential, repeated security concerns have shaken the trust in handling billions of USD by smart contracts. To address this problem, we present Securify, a security analyzer for Ethereum smart contracts that is scalable, fully automated, and able to prove contract behaviors as safe/unsafe with respect to a given property. Securify's analysis consists of two steps. First, it symbolically analyzes the contract's dependency graph to extract precise semantic information from the code. Then, it checks compliance and violation patterns that capture sufficient conditions for proving if a property holds or not. To enable extensibility, all patterns are specified in a designated domain-specific language. Securify is publicly released, it has analyzed >18K contracts submitted by its users, and is regularly used to conduct security audits by experts. We present an extensive evaluation of Securify over real-world Ethereum smart contracts and demonstrate that it can effectively prove the correctness of smart contracts and discover critical violations.},
52
+	booktitle = {Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security},
53
+	pages = {67–82},
54
+	numpages = {16},
55
+	keywords = {smart contracts, stratified datalog, verification, security analysis},
56
+	location = {Toronto, Canada},
57
+	series = {CCS '18}
58
+}
59
+
60
+@MISC{
61
+	doughoyte,
62
+	author = {doughoyte},
63
+	title = {MerdeToken: It's Some Hot Shit},
64
+	note = {\url{https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte} [Accessed: Oct. 27th 2023]}
65
+}
66
+
67
+@article{multilayer,
68
+author = {Duan, Li and Sun, Yangyang and Zhang, Ke-Jia and Ding, Yong},
69
+year = {2022},
70
+month = {02},
71
+pages = {},
72
+title = {Multiple-Layer Security Threats on the Ethereum Blockchain and Their Countermeasures},
73
+volume = {2022},
74
+journal = {Security and Communication Networks},
75
+doi = {10.1155/2022/5307697}
76
+}
77
+
78
+@inproceedings{Kalra2018ZEUSAS,
79
+  title={ZEUS: Analyzing Safety of Smart Contracts},
80
+  author={Sukrit Kalra and Seep Goel and Mohan Dhawan and Subodh Sharma},
81
+  booktitle={Network and Distributed System Security Symposium},
82
+  year={2018},
83
+}

+ 52
- 0
SemSEreport/exercises.bbl View File

@@ -0,0 +1,52 @@
1
+\begin{thebibliography}{1}
2
+
3
+\bibitem{smartian}
4
+Jaeseung Choi, Doyeon Kim, Soomin Kim, Gustavo Grieco, Alex Groce, and Sang~Kil
5
+  Cha.
6
+\newblock Smartian: Enhancing smart contract fuzzing with static and dynamic
7
+  data-flow analyses.
8
+\newblock In {\em 2021 36th IEEE/ACM International Conference on Automated
9
+  Software Engineering (ASE)}, pages 227--239, 2021.
10
+
11
+\bibitem{doughoyte}
12
+doughoyte.
13
+\newblock Merdetoken: It's some hot shit.
14
+\newblock
15
+  \url{https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte}
16
+  [Accessed: Oct. 27th 2023].
17
+
18
+\bibitem{multilayer}
19
+Li~Duan, Yangyang Sun, Ke-Jia Zhang, and Yong Ding.
20
+\newblock Multiple-layer security threats on the ethereum blockchain and their
21
+  countermeasures.
22
+\newblock {\em Security and Communication Networks}, 2022, 02 2022.
23
+
24
+\bibitem{Kalra2018ZEUSAS}
25
+Sukrit Kalra, Seep Goel, Mohan Dhawan, and Subodh Sharma.
26
+\newblock Zeus: Analyzing safety of smart contracts.
27
+\newblock In {\em Network and Distributed System Security Symposium}, 2018.
28
+
29
+\bibitem{teether}
30
+Johannes Krupp and Christian Rossow.
31
+\newblock {teEther}: Gnawing at ethereum to automatically exploit smart
32
+  contracts.
33
+\newblock In {\em 27th USENIX Security Symposium (USENIX Security 18)}, pages
34
+  1317--1333, Baltimore, MD, August 2018. USENIX Association.
35
+
36
+\bibitem{fuzzdrivegen}
37
+Siddhasagar Pani, Harshita~Vani Nallagonda, Vigneswaran, Raveendra~Kumar
38
+  Medicherla, and Rajan M.
39
+\newblock Smartfuzzdrivergen: Smart contract fuzzing automation for golang.
40
+\newblock In {\em Proceedings of the 16th Innovations in Software Engineering
41
+  Conference}, ISEC '23, New York, NY, USA, 2023. Association for Computing
42
+  Machinery.
43
+
44
+\bibitem{securify}
45
+Petar Tsankov, Andrei Dan, Dana Drachsler-Cohen, Arthur Gervais, Florian
46
+  B\"{u}nzli, and Martin Vechev.
47
+\newblock Securify: Practical security analysis of smart contracts.
48
+\newblock In {\em Proceedings of the 2018 ACM SIGSAC Conference on Computer and
49
+  Communications Security}, CCS '18, page 67–82, New York, NY, USA, 2018.
50
+  Association for Computing Machinery.
51
+
52
+\end{thebibliography}

BIN
SemSEreport/exercises.pdf View File


+ 227
- 0
SemSEreport/exercises.tex View File

@@ -0,0 +1,227 @@
1
+\documentclass [10pt]{article}
2
+
3
+
4
+\usepackage{latexsym}
5
+\usepackage{amssymb}
6
+\usepackage{epsfig}
7
+\usepackage{fullpage}
8
+\usepackage{enumerate}
9
+\usepackage{xspace}
10
+\usepackage{todonotes}
11
+\usepackage{listings}
12
+\usepackage{url}
13
+\usepackage[ruled,linesnumbered]{algorithm2e} % Enables the writing of pseudo code.
14
+\usepackage{float}% http://ctan.org/pkg/float
15
+
16
+\newcommand{\true}{true}
17
+\newcommand{\false}{false}
18
+\pagestyle{plain}
19
+\bibliographystyle{plain}
20
+
21
+
22
+\title{192.127 Seminar in Software Engineering (Smart Contracts) \\
23
+ SWC-124: Write to Arbitrary Storage Location \\
24
+ Report Exploits }
25
+\author{Exercises}
26
+
27
+\date{WT 2023/24}
28
+
29
+\author{\textbf{Ivanov, Ivaylo (11777707) \& Millauer, Peter (01350868)}}
30
+
31
+\newtheorem{theorem}{Theorem}
32
+\newtheorem{lemma}[theorem]{Lemma}
33
+\newtheorem{corollary}[theorem]{Corollary}
34
+\newtheorem{proposition}[theorem]{Proposition}
35
+\newtheorem{conjecture}[theorem]{Conjecture}
36
+\newtheorem{definition}[theorem]{Definition}
37
+\newtheorem{example}[theorem]{Example}
38
+\newtheorem{remark}[theorem]{Remark}
39
+\newtheorem{exercise}[theorem]{Exercise}
40
+
41
+
42
+\renewcommand{\labelenumi}{(\alph{enumi})}
43
+
44
+\usepackage{xcolor}
45
+
46
+\definecolor{codegreen}{rgb}{0,0.6,0}
47
+\definecolor{codegray}{rgb}{0.5,0.5,0.5}
48
+\definecolor{codepurple}{rgb}{0.58,0,0.82}
49
+\definecolor{backcolour}{rgb}{0.95,0.95,0.92}
50
+\definecolor{verylightgray}{rgb}{.97,.97,.97}
51
+
52
+\lstdefinelanguage{Solidity}{
53
+	keywords=[1]{anonymous, assembly, assert, balance, break, call, callcode, case, catch, class, constant, continue, constructor, contract, debugger, default, delegatecall, delete, do, else, emit, event, experimental, export, external, false, finally, for, function, gas, if, implements, import, in, indexed, instanceof, interface, internal, is, length, library, log0, log1, log2, log3, log4, memory, modifier, new, payable, pragma, private, protected, public, pure, push, require, return, returns, revert, selfdestruct, send, solidity, storage, struct, suicide, super, switch, then, this, throw, transfer, true, try, typeof, using, value, view, while, with, addmod, ecrecover, keccak256, mulmod, ripemd160, sha256, sha3}, % generic keywords including crypto operations
54
+	keywordstyle=[1]\color{blue}\bfseries,
55
+	keywords=[2]{address, bool, byte, bytes, bytes1, bytes2, bytes3, bytes4, bytes5, bytes6, bytes7, bytes8, bytes9, bytes10, bytes11, bytes12, bytes13, bytes14, bytes15, bytes16, bytes17, bytes18, bytes19, bytes20, bytes21, bytes22, bytes23, bytes24, bytes25, bytes26, bytes27, bytes28, bytes29, bytes30, bytes31, bytes32, enum, int, int8, int16, int24, int32, int40, int48, int56, int64, int72, int80, int88, int96, int104, int112, int120, int128, int136, int144, int152, int160, int168, int176, int184, int192, int200, int208, int216, int224, int232, int240, int248, int256, mapping, string, uint, uint8, uint16, uint24, uint32, uint40, uint48, uint56, uint64, uint72, uint80, uint88, uint96, uint104, uint112, uint120, uint128, uint136, uint144, uint152, uint160, uint168, uint176, uint184, uint192, uint200, uint208, uint216, uint224, uint232, uint240, uint248, uint256, var, void, ether, finney, szabo, wei, days, hours, minutes, seconds, weeks, years},	% types; money and time units
56
+	keywordstyle=[2]\color{teal}\bfseries,
57
+	keywords=[3]{block, blockhash, coinbase, difficulty, gaslimit, number, timestamp, msg, data, gas, sender, sig, value, now, tx, gasprice, origin},	% environment variables
58
+	keywordstyle=[3]\color{violet}\bfseries,
59
+	identifierstyle=\color{black},
60
+	sensitive=true,
61
+	comment=[l]{//},
62
+	morecomment=[s]{/*}{*/},
63
+	commentstyle=\color{gray}\ttfamily,
64
+	stringstyle=\color{red}\ttfamily,
65
+	morestring=[b]',
66
+	morestring=[b]"
67
+}
68
+
69
+\lstset{
70
+	language=Solidity,
71
+	backgroundcolor=\color{verylightgray},
72
+	extendedchars=true,
73
+	basicstyle=\footnotesize\ttfamily,
74
+	showstringspaces=false,
75
+	showspaces=false,
76
+	numbers=left,
77
+	numberstyle=\footnotesize,
78
+	numbersep=9pt,
79
+	tabsize=2,
80
+	breaklines=true,
81
+	showtabs=false,
82
+	captionpos=b
83
+}
84
+
85
+\lstdefinestyle{mystyle}{
86
+	backgroundcolor=\color{backcolour},
87
+	commentstyle=\color{codegreen},
88
+	keywordstyle=\color{magenta},
89
+	numberstyle=\tiny\color{codegray},
90
+	stringstyle=\color{codepurple},
91
+	basicstyle=\ttfamily\footnotesize,
92
+	breakatwhitespace=false,
93
+	breaklines=true,
94
+	captionpos=b,
95
+	keepspaces=true,
96
+	numbers=left,
97
+	numbersep=5pt,
98
+	showspaces=false,
99
+	showstringspaces=false,
100
+	showtabs=false,
101
+	tabsize=2
102
+}
103
+
104
+
105
+
106
+\begin{document}
107
+
108
+
109
+\maketitle
110
+
111
+
112
+%\begin{abstract}
113
+%	This paper outlines different forms of the common smart contract weakness with the SWC number 124, commonly referred to as "Write to Arbitrary Storage Location". While this paper focuses on applications within the context of Ethereum's EVM and higher-level language Solidity, we will also briefly touch on other research that deals with the Hyperledger Fabric environment. We will begin with a gentle introduction to the Solidity storage layout design that allows this weakness to occur, followed by common forms of exploit, alongside their associated consequences. Finally, we will outline the code characteristics that are detectable by automated tools as well as an exploit sketch.
114
+%\end{abstract}
115
+
116
+\section{Introduction}
117
+
118
+\subsection{Precautions}
119
+
120
+\subsection{Preprocessing}
121
+
122
+\subsection{Setup}
123
+
124
+We attempted to implement an automatic weakness detection pipeline by using a multitude of tools. The software used includes:
125
+
126
+\begin{itemize}
127
+	\item \textbf{solc}: Using \textbf{solc-select} we select the correct solc version and compile the associated *.sol file. This way we gather compiler hints and warnings.
128
+	\item \textbf{Mythril}: %TODO% Mythril also does something
129
+	\item \textbf{teEther}: A tool we found in the last research step of this seminar, teether is a dynamic analysis tool for smart contracts. It is unfortunately hardly documented and has been unmaintained for several years. We were unable to generate usable results with it.
130
+	\item \textbf{Slither}: A highly useful tool that offers a large static analysis toolkit for solidity, it not only allows the extraction of contract data like storage layouts but also automatic scanning for common weaknesses. Although it did not seem to be able to detect SWC-124, the storage layout functionality was used extensively by our team.
131
+\end{itemize}
132
+
133
+
134
+\section{Exploit Creation}
135
+
136
+\subsection{extra short recap of weakness definitions}
137
+
138
+SWC-124 attempts to use the underlying mechanisms that govern dynamic array allocation to deterministically overwrite arbitrary data in smart contracts. An analogous weakness can be created by employing unchecked assembly instructions, although this is a less common attack vector due to its unusual structure.
139
+
140
+\subsection{exploit idea(s)}
141
+
142
+The workflow of determining the vulnerability of a given contract is straight forward and follows the general approach of automatic detection mechanisms from our last paper. Since SWC-124 requires the presence of very specific code, it is relatively easy to exclude non-vulnerable contracts. Namely any contract without dynamic arrays or raw assembly including a SSTORE instruction can immediately be considered non-vulnerable. The presence of dynamic arrays can be determined using \textbf{slither --print variable-order}. A sample output looks as follows:
143
+
144
+\begin{verbatim}
145
+$slither cans.sol --print variable-order	
146
+	
147
+Cans:
148
++----------------------------+----------------------------------------------+------+--------+
149
+| Name                       |                                         Type | Slot | Offset |
150
++----------------------------+----------------------------------------------+------+--------+
151
+| ERC1155._balances          |                mapping(address => uint32[7]) |    0 |      0 |
152
+| ERC1155.tokens             |                                    uint256[] |    1 |      0 |
153
+| ERC1155._operatorApprovals | mapping(address => mapping(address => bool)) |    2 |      0 |
154
+| ERC1155._uri               |                                       string |    3 |      0 |
155
+| Ownable._owner             |                                      address |    4 |      0 |
156
+| Functional._reentryKey     |                                         bool |    4 |     20 |
157
+| Cans.START_TIME            |                                      uint256 |    5 |      0 |
158
+| Cans.END_TIME              |                                      uint256 |    6 |      0 |
159
+| Cans.amountClaimed         |                                  uint8[9998] |    7 |      0 |
160
+| Cans.CLAIM_ENABLED         |                                         bool |  320 |      0 |
161
+| Cans.soda                  |                                 SODAContract |  320 |      1 |
162
+| Cans.SODA_CONTRACT         |                                      address |  321 |      0 |
163
+| Cans.baseURI               |                                       string |  322 |      0 |
164
++----------------------------+----------------------------------------------+------+--------+
165
+	
166
+\end{verbatim}
167
+
168
+In this example the \textbf{ERC1155.tokens} array is the only potential weakess present. We would then look for the presence of what-where writes to this array in order to confirm the potential presence of SWC-124. What-where writes are of the form
169
+
170
+\begin{verbatim}
171
+	someArray[where] = what;
172
+\end{verbatim}
173
+
174
+\noindent and are a necessary code snippet for SWC-124. If such an instruction is present, we then attempt to reverse engineer a sequence of inputs to trigger the exploit, or formulate a reason why we believe this not to be possible.
175
+
176
+\section{Results}
177
+
178
+\subsection{vulnerable contracts}
179
+
180
+None.
181
+
182
+\subsection{non-exploitable contracts}
183
+
184
+\noindent Solidity files that contained no contracts:
185
+
186
+\begin{itemize}
187
+	\item AuctionLib.sol
188
+	\item LibRegion.sol
189
+	\item LToken.sol
190
+	
191
+\end{itemize}
192
+
193
+\noindent Contracts that were discarded due to the non-presence of dynamic arrays or assembly using SSTORE:
194
+
195
+\begin{itemize}
196
+	\item DCU.sol
197
+	\item ERC20\_Asset\_Pool.sol
198
+	\item FacelessNFT.sol
199
+	\item GElasticTokenManager.sol
200
+	\item GoldToken.sol
201
+	\item GovernmentAlpha.sol
202
+	\item HedgeSwap.sol
203
+	\item HermesImplementation.sol
204
+	\item IMETACoin223Token\_13.sol
205
+	\item UniswapV3PoolAdapter.sol
206
+	\item UserDeposit.sol
207
+	\item WPCMainnetBridge.sol
208
+\end{itemize}
209
+
210
+\subsection{undecidable contracts}
211
+
212
+\subsection{optionally fixes}
213
+
214
+\section{Discussion}
215
+
216
+\subsection{conclusions}
217
+
218
+\subsection{lessons learned: what works, what doesn't}
219
+
220
+\subsection{open challenges}
221
+
222
+
223
+\bibliography{exercise.bib}
224
+
225
+\end{document}
226
+
227
+

Loading…
Cancel
Save