CNT4419-F23 Christopher M.

Ragland

Buffer Overflow Exploita3on in a 32-bit Environment: Lab 1 Report

Introduc)on
This laboratory exercise aims to showcase a proficient understanding of the buffer overflow
exploit within the context of a 32-bit server environment. Employing a virtual machine
configured for this purpose, we emulate a vulnerable system for pracJcal demonstraJon.

Task 1 – Ge3ng Familiar with the Shellcode

We have been tasked with adapJng the shellcode to enable file deleJon. As depicted in Figure
1, we replace the 'bin/{command}' with 'remove (rm).' In the Linux environment, this 'rm'
command facilitates the removal of files from a specified directory. The term 'fileToDelete.txt'
serves as a temporary placeholder for the aWacker (in this case, us) to subsJtute with the actual
file we intend to delete.
Figure 1. modified shellcode to be used to delete a file.

AXer execuJng shellcode_32.py, we successfully constructed the codefile_32 file. Subsequently,

a test file was generated within our local system, as illustrated in Figure 2.
CNT4419-F23 Christopher M. Ragland

Figure 2. Create a file that we will delete with our shellcode

Upon execuJng the a32.out binary, the shell code ran successfully. Following this, the file was
removed from our local system, as depicted in Figures 3A and 3B.

Figure 3-A. Call a32.out executable

Figure 3-B: Showing file has been removed from system

CNT4419-F23 Christopher M. Ragland

Task 2: Level-1 ABack

Upon compleJng the iniJal Docker container setup and necessary preparaJons for the lab
environment, our subsequent objecJve is to determine the locaJon of the Extended Base
Pointer (EBP) and the target buffer address for exploitaJon. This is achieved by echoing “hello”
from our aWack code directory and forwarding the results to the server at 10.9.0.5 on port
9090. As illustrated in Figure 4, the output reveals the EBP and buffer locaJons. The EBP
indicates the starJng point of the stack frame. Immediately succeeding the EBP address is the
buffer address. CalculaJng the difference between these two addresses can provide insight into
the buffer's size, allowing us to potenJally exploit it and induce a buffer overflow.

Figure 4. Location of frame pointer and buffer address

Upon gathering the required data, we integrated the provided shellcode into the 'shellcode'
variable within our Python exploit script. We also adjusted the 'start' variable to posiJon the
shellcode precisely, ensuring its correct execuJon. Lastly, we modified the 'ret' variable, which
will be used to modify the original program's return address. This alteraJon lets us redirect the
program's flow to our shellcode.

We executed the modified Python file. Post-execuJon, we relayed the "badfile" results to the
server using the "cat" command. Figure 5 presents a screenshot of the Docker terminal
displaying the output. Notably, the "Returned Properly" message indicates the program's
successful operaJon without any crashes, as per the lab guidelines.
CNT4419-F23 Christopher M. Ragland

Figure 5. Results of cat badfile | nc 10.9.0.5 9090 in docker terminal

With the Python exploit script verified, our focus shiXs from directory display and the "Hello 32"
output to iniJaJng a bash shell. This shell aims to connect to a specified IP address. As depicted
in Figure 6, we use "nc -lnv 9090" to listen on port 9090. Upon a successful connecJon, we gain
access to the targeted server.

Figure 6. Begin listening to port 9090

UJlizing commands from the preceding steps, we executed our updated exploit file, reflecJng
the recent modificaJons. Monitoring the terminal set to listen on port 9090, postscript
execuJon, we secured access to the root shell, as illustrated in Figure 7.

Figure 7. Gain access to root shell

Concluding our second task, we successfully accessed the root shell, posiJoning us to
potenJally execute further commands on the now-compromised server.
CNT4419-F23 Christopher M. Ragland

Task-3: Level-2 ABack

In this phase of our aWack strategy, our target is the server located at IP address 10.9.0.6, sJll
operaJng on port 9090. Notably, this server also runs on a 32-bit architecture, similar to our
previous target. Our iniJal step involves transmijng a benign message to ascertain the server's
acJve listening status. As depicted in Figure 8-A, we relayed a command via an echo to the
docker container. Subsequently, Figure 8-B provides a visual of the server's response post-
message delivery.

Figure 8-A Echo command used to send message to docker server

Figure 8-B The response at the server showing it returned properly.

In the latest phase of our aWack strategy, the response from the docker container provides
crucial informaJon: the buffer's address, denoted as 0xffffd068. However, a key disJncJon in
this aWack is the absence of the frame-pointer (EBP) address. If we had access to this, deducing
the buffer's size would simply require basic arithmeJc. Nevertheless, we are equipped with the
knowledge that the buffer size lies within the bracket of 100 to 300 bytes. Furthermore,
considering memory alignment intricacies, the value held within the frame pointer remains
consistently divisible by four.

Guided by this data, our approach will involve placing our malicious payload at the tail end of
our 'badfile', ensuring the return address is redirected to leap directly to our 'badfile'. It's
noteworthy that our pre-exisJng 'exploit.py' file embeds the shellcode within the payload. As
illustrated in Figure 9-A, we can observe the iniJal state of our 'exploit.py'. ContrasJngly, Figure
9-B highlights the modificaJons executed on the file, essenJal for reposiJoning our shellcode to
reside at the concluding segment of the 'badfile'.
CNT4419-F23 Christopher M. Ragland

Figure 9-A: StarPng state of exploit.py

Figure 9-B: Changes made to place shellcode at end of badfile

The modificaJons made to the exploit.py file, as depicted in Figure 9-B, primarily focus on
posiJoning the shellcode at the 'badfile's concluding segment. A pivotal aspect of our aWack
strategy is the determinaJon of the return address. This address corresponds to the buffer's
iniJal point combined with the specified range. This chosen approach of sprinkling our return
CNT4419-F23 Christopher M. Ragland

address ubiquitously throughout the buffer augments the probability of landing on our
designated return address.
Upon execuJng the tailored exploit file, a new 'badfile' is birthed (as illustrated in Figure 10). In
tandem, a disJnct terminal session is prepped, primed to listen on port 9090 for any
interacJons with the 10.9.0.6 server. This session's chief role is to process the output of our
'badfile'. Conclusively, as portrayed in Figure 11, the results demonstrate our successful venture,
granJng us unparalleled access to the server's root.

Figure 10. Run new exploit.py and create a new badfile

Figure 11. Listening to port 9090 on server 10.9.0.6 accessed root

Conclusion
This comprehensive lab report encapsulated a deep dive into the intricacies of cybersecurity
vulnerabiliJes, specifically focusing on the exploitaJon of buffer overflow vulnerabiliJes on a
32-bit Ubuntu Linux system. Throughout the three detailed tasks:
1. Shellcode Manipula3on: The iniJal task beckoned the adaptaJon of the shellcode. The
objecJve was to ensure that upon its execuJon, it would iniJate the deleJon of a
specific file. This task underscored the flexibility and potenJal perils of shellcode.
2. Buffer Overflow with Given Addresses: The second task illustrated a scenario where we
had been granted the addresses of both the start of the buffer and the frame pointer.
This knowledge facilitated the determinaJon of buffer size, allowing for the precise
placement of the payload. The culminaJon of this task was the successful execuJon of a
buffer overflow aWack, resulJng in unparalleled access to the server root.
3. Buffer Overflow without Frame Pointer: The final task introduced a heightened level of
complexity. Devoid of the frame pointer's locaJon, the direct arithmeJc approach to
discern the buffer size was rendered moot. To circumnavigate this challenge, the
CNT4419-F23 Christopher M. Ragland

shellcode was strategically posiJoned at the badfile's terminaJon. Ensuring that the
buffer was inundated with our shellcode's address, the precise buffer size was ulJmately
discerned to be 300 bytes. This meJculous approach culminated in a successful
infiltraJon, granJng access to the server root, as vividly captured in Figure 11.
In essence, this lab underscored the vulnerabiliJes present in compuJng systems and the
paramount importance of robust security measures. Through hands-on experience with these
vulnerabiliJes, one can beWer appreciate the significance of preventaJve cybersecurity
strategies.