Corrected caps

docs/chapters/chapter2.tex

@@ -250,7 +250,7 @@ The following are the most relevant checks that the verifier performs in eBPF pr
 
 These checks are performed by two main algorithms:
 \begin{itemize}
-\item Build a graph representing the eBPF instructions (similar to the one shown in section \ref{subsection:analysis_bpf_filter_prog}. Check that it is in fact a direct acyclic graph (DAG), meaning that the verifier prevents loops and unreachable instructions.
+\item Build a graph representing the eBPF instructions (similar to the one shown in Section \ref{subsection:analysis_bpf_filter_prog}. Check that it is in fact a direct acyclic graph (DAG), meaning that the verifier prevents loops and unreachable instructions.
 \item Simulate execution flow by starting on the first instruction and following each possible path, observing at each instruction the state of every register and of the stack.
 \end{itemize}
 
@@ -267,7 +267,7 @@ Therefore, creating a map requires a struct with the fields shown in Table \ref{
 \textbf{FIELD} & \textbf{VALUE}\\
 \hline
 \hline
-type & Type of eBPF map. Described in table \ref{table:ebpf_map_types}\\
+type & Type of eBPF map. Described in Table \ref{table:ebpf_map_types}\\
 \hline
 key\_size & Size of the data structure to use as a key\\
 \hline
@@ -318,7 +318,7 @@ The main operations that can be issued are described in Table \ref{table:ebpf_sy
 \textbf{COMMAND} & \textbf{ATTRIBUTES} & \textbf{DESCRIPTION}\\
 \hline
 \hline
-BPF\_MAP\_CREATE & Struct with map info as defined in table \ref{table:ebpf_map_struct} & Create a new map\\
+BPF\_MAP\_CREATE & Struct with map info as defined in Table \ref{table:ebpf_map_struct} & Create a new map\\
 \hline
 BPF\_MAP\_LOOKUP\_ELEM & Map ID, and struct with key to search in the map & Get the element on the map with a specific key\\
 \hline
@@ -413,7 +413,7 @@ Figure \ref{fig:xdp_diag} shows how XDP is integrated in the network processing
 \begin{itemize}
 \item Analyse the data between the packet buffer bounds.
 \item Modify the packet contents, and modify the packet length.
-\item Decide between one of the actions displayed in table \ref{table:xdp_actions_av}.
+\item Decide between one of the actions displayed in Table \ref{table:xdp_actions_av}.
 \end{itemize}
 
 \begin{figure}[htbp]
@@ -617,7 +617,7 @@ Note that the BPF skeleton also offers further granularity at the time of dealin
 
 
 \section{Security features in eBPF} \label{section:ebpf_security}
-As we have shown in Section \ref{section:modern_ebpf}, eBPF has been an active part of the Linux kernel from its 3.18 version. However, as with many other components of the kernel, its availability to the user depends on the parameters with which the kernel has been compiled. Specifically, eBPF is only available to kernels compiled with the flags specified in table \ref{table:ebpf_kernel_flags}.
+As we have shown in Section \ref{section:modern_ebpf}, eBPF has been an active part of the Linux kernel from its 3.18 version. However, as with many other components of the kernel, its availability to the user depends on the parameters with which the kernel has been compiled. Specifically, eBPF is only available to kernels compiled with the flags specified in Table \ref{table:ebpf_kernel_flags}.
 
 \begin{table}[htbp]
 \begin{tabular}{|c|c|>{\centering\arraybackslash}p{7cm}|}
@@ -663,7 +663,7 @@ It must be noted that, similarly to kernel modules, loading an eBPF program requ
 \item \textbf{Unprivileged users} can only load and attach eBPF programs of type BPF\_PROG\_TYPE\_SOCKET\_FILTER \cite{evil_ebpf_p9}, offering the very limited functionality of filtering packets received on a socket.
 \end{itemize}
 
-More recently, in an effort to further granulate the permissions needed for loading, attaching and running eBPF programs, CAP\_SYS\_ADMIN has been substituted by more specific capabilities \cite{ebpf_caps_intro} \cite{ebpf_caps_lwn}. The current system is therefore described in table \ref{table:ebpf_caps_current}.
+More recently, in an effort to further granulate the permissions needed for loading, attaching and running eBPF programs, CAP\_SYS\_ADMIN has been substituted by more specific capabilities \cite{ebpf_caps_intro} \cite{ebpf_caps_lwn}. The current system is therefore described in Table \ref{table:ebpf_caps_current}.
 
 \begin{table}[htbp]
 \begin{tabular}{|>{\centering\arraybackslash}p{4cm}|>{\centering\arraybackslash}p{10cm}|}

docs/chapters/chapter3.tex

@@ -20,7 +20,7 @@ Map IDs are known by a program after creating the eBPF map, however, a program c
 Therefore, a malicious privileged eBPF program can access and modify other programs' maps, which can lead to:
 \begin{itemize}
 \item Modify data used for the program operation. This is the case for maps which mainly store data structures, such as BPF\_MAP\_TYPE\_HASH.
-\item Modify the program control flow, altering the instructions executed by an eBPF program. This can be achieved if a program is using the bpf\_tail\_call() helper (introduced in table \ref{table:ebpf_helpers}) which is taking data from a map storing eBPF programs (BPF\_MAP\_TYPE\_PROG\_ARRAY, introduced in Table \ref{table:ebpf_map_types}).
+\item Modify the program control flow, altering the instructions executed by an eBPF program. This can be achieved if a program is using the bpf\_tail\_call() helper (introduced in Table \ref{table:ebpf_helpers}) which is taking data from a map storing eBPF programs (BPF\_MAP\_TYPE\_PROG\_ARRAY, introduced in Table \ref{table:ebpf_map_types}).
 \end{itemize}
 
 
@@ -335,7 +335,7 @@ Having the previous restrictions in mind, we can find multiple possible maliciou
 \begin{itemize}
 \item \textbf{Monitor all network connections} in the system. An XDP or TC ingress program can read any packet from any interface, therefore achieving a comprehensive view on which are the running communications and opened ports (even if protocols with encryption are being used) and gathering transmitted data (if the connection is also in plaintext).
 \item \textbf{Hide arbitrary traffic} from the host. If an XDP program drops a packet, the kernel will not be able to know any packet was received in the first place. This can be used to hide malicious incoming traffic. However, as we will mention in Section \ref{section:c2}, malicious traffic may still be detected by other external devices, such as network-wide firewalls.
-\item \textbf{Modify incoming traffic} with XDP programs. Every packet can be modified (as we mentioned at the beginning of section \ref{section:abusing_networking}), and any modification will be unnoticeable to the kernel, meaning that we will have complete, invisible control over the packets received by the kernel.
+\item \textbf{Modify incoming traffic} with XDP programs. Every packet can be modified (as we mentioned at the beginning of Section \ref{section:abusing_networking}), and any modification will be unnoticeable to the kernel, meaning that we will have complete, invisible control over the packets received by the kernel.
 \item \textbf{Modify outgoing traffic} with TC egress programs. Since every packet can be modified at will, we will therefore have complete control over any packet sent by the host. This can be used to enable a malicious program to communicate over the network and exfiltrate data, since even if we cannot create a new connection from eBPF, we can still modify existing packets, writing any payload and headers on it (thus being able to, for instance, change the destination of the packet).
 
 Notice, however, that these modifications are not transparent to the kernel as with XDP, and thus an internal firewall may detect our malicious traffic.

docs/chapters/chapter4.tex

@@ -692,7 +692,7 @@ These triggers are one of the simplest but also the most easily detectable by an
 	\label{fig:keyword_trigger}
 \end{figure}
 
-Our rootkit is prepared to listen for keyword-based triggers, although it is a simple Proof of Concept (PoC) which does not take part in the main C2 functionality. In the case of the trigger shown in Figure \ref{fig:keyword_trigger}, the rootkit will analyse the packet and detect that the pre-defined keyword "XDP\_PoC\_0" has been inserted into the payload, thus learning that the packet has been sent by the attacker. In the PoC implemented in our rootkit, this triggers an overwrite action, in which the XDP program will proceed to modify the payload and the packet size, changing the contents of the packet. This PoC can be seen in action in section \ref{subsection:poc_evaluation}.
+Our rootkit is prepared to listen for keyword-based triggers, although it is a simple Proof of Concept (PoC) which does not take part in the main C2 functionality. In the case of the trigger shown in Figure \ref{fig:keyword_trigger}, the rootkit will analyse the packet and detect that the pre-defined keyword "XDP\_PoC\_0" has been inserted into the payload, thus learning that the packet has been sent by the attacker. In the PoC implemented in our rootkit, this triggers an overwrite action, in which the XDP program will proceed to modify the payload and the packet size, changing the contents of the packet. This PoC can be seen in action in Section \ref{subsection:poc_evaluation}.
 
 Note that this functionality of XDP, although it has not been integrated in our rootkit, enables a wide range of attacks related with the network, effectively working as Man-in-the-Middle. An example of this is HTTPS Downgrade attacks, where we would tamper with the traffic related to the cipher suite negotiation process so that it turns into a plaintext HTTP connection or an HTTPS connection with a less-secure cipher suite \cite{downgrade_attack}.
 
@@ -1431,7 +1431,7 @@ As we mentioned, we will overwrite the value of d\_reclen of the previous entry
 
 As we can observe in the figure, by modifying the value of d\_reclen, the user program will skip the entry of file "hideme", and therefore any process listing the available entries of the directory will not show this file.
 
-Apart from detecting entries by their name, we can also know whether an entry is a file, a directory or of some other type. For this, our rootkit uses the attribute d\_type of the linux\_dirent64 (see table \ref{table:linux_dirent64}), whose value determines the type of file. The most relevant values of the d\_type attribute are shown in Table \ref{table:dtype_values} \cite{dtype_dirent}.
+Apart from detecting entries by their name, we can also know whether an entry is a file, a directory or of some other type. For this, our rootkit uses the attribute d\_type of the linux\_dirent64 (see Table \ref{table:linux_dirent64}), whose value determines the type of file. The most relevant values of the d\_type attribute are shown in Table \ref{table:dtype_values} \cite{dtype_dirent}.
 
 \begin{table}[htbp]
 \begin{tabular}{|c|c|}

docs/chapters/chapter5.tex

@@ -696,7 +696,7 @@ After the rootkit is loaded, we can observe in Figure \ref{fig:sc_stealth_dir_af
 \end{figure}
 
 \textbf{Hiding persistence files}\\
-Hiding the \textit{ebpfbackdoor} files can be achieved using the configuration shown in table \ref{table:rootkit_stealth_config_file}.
+Hiding the \textit{ebpfbackdoor} files can be achieved using the configuration shown in Table \ref{table:rootkit_stealth_config_file}.
 
 \begin{table}[htbp]
 \begin{tabular}{|>{\centering\arraybackslash}p{3cm}|>{\centering\arraybackslash}p{4.5cm}|>{\centering\arraybackslash}p{6cm}|}

docs/chapters/chapter6.tex

@@ -178,7 +178,7 @@ advanced stealth and network functionalities. Some of its most relevant
 capabilities include:
 \begin{itemize}
 \item Hiding files, directories, processes and network connections related to the rootkit activity.
-\item A backdoor that is operated via port-knocking triggers (which we explained in section \ref{subsection:triggers}).
+\item A backdoor that is operated via port-knocking triggers (which we explained in Section \ref{subsection:triggers}).
 \item C2 capabilities via a custom shell (similar to the pseudo-shells of our rootkit).
 \end{itemize}
 
@@ -310,7 +310,7 @@ functionalities for eBPF rootkits, and TripleCross development has been
 greatly inspired by this past work. In particular, there exist the
 following similarities:
 \begin{itemize}
-\item The backdoor module and C2 capabilities are based on those presented by ebpfkit, since both rootkits use a combination of XDP and TC programs (for managing incoming and outgoing traffic respectively). The phantom shell of TripleCross is also based on the TCP retransmissions technique of ebpfkit. With respect to backdoor triggers, these were based on the Bvp47 and Hive rootkits, as we mentioned in section \ref{subsection:triggers}.
+\item The backdoor module and C2 capabilities are based on those presented by ebpfkit, since both rootkits use a combination of XDP and TC programs (for managing incoming and outgoing traffic respectively). The phantom shell of TripleCross is also based on the TCP retransmissions technique of ebpfkit. With respect to backdoor triggers, these were based on the Bvp47 and Hive rootkits, as we mentioned in Section \ref{subsection:triggers}.
 \item The privilege escalation module is based on the file sys\_read syscalls modification presented by Pat Hogan, which describes its possibilities for obtaining sudo privileges by modifying data read from the \textit{/etc/sudoers} file. Also, the execution hijacking process is based on the capability of modifying sys\_execve described by Hogan.
 \item The stack scanning technique used by the library injection module is based on that presented for the ROP attack by Jeff Dileo.
 \item The files and directories hiding technique is a common functionality incorporated at rootkits, although it was first discussed by Johann Rehberger \cite{embracethered_getdents}.