Paolo PeregoFollowSpecialista di sicurezza applicativa e certificato OSCE e OSCP, amo spaccare e ricostruire il codice in maniera sicura. Sono cintura nera di taekwon-do, marito e papà. Ranger Caotico Neutrale, scrivo su @codiceinsicuro.
Assignment #3: An Egg Hunter journey
2190
parole - Lo leggerai in 12 minuti
The third assignment for SLAE certification is a study for an egg hunter
shellcode. Within this study a working proof of concept code it must be written
and it must support different payloads.
The assignment was written on an Ubuntu Linux 18.04, with a Linux kernel 4.15
version.
The basic idea is simple: you don’t have enough space where to store your evil
payload, so you have to brake it into two different stages:
the first stage is called the egg hunter and its purpose is to search the
memory for a specific identifier, the egg, and when it found it, to pass the
control to the second stage payload;
the second stage that it starts with the egg repeated two times, as a marker,
and then it contains the evil code to be executed.
I choose to implement the hunter based on the access(2) system call in its
revised version, mainly because I don’t want to rely on an executable EGG.
True to be told, 0xdeadbeef is my chosen default key.
The key idea is to scan the whole memory, using the access(2) system call that
it has the real purpose to check and see if the current process has the
specific access rights to a given file on disk.
The proof of concept
First of all, I’ll make very few modifications to our execve(“/bin/sh”)
shellcode. In fact, I’ll add only the EGG marker repeated twice.
After having compiled the assembler source file with compile.sh script shell, I
used scdump.sh script to dump the shellcode.
This will be our default payload to be executed when the EGG it has been found
in memory. Now, let’s have a look to our egg hunter implementation.
The basic idea here is to traverse memory using EBX register as pointer and
access() system call to check if we’re pointing a memory region we’re allowed
to read. In this case we are in one of our process memory page and than our
second stage can be found there.
Dumping the shellcode I obtained:
I added this shellcode into the same C program used in the first assignment to
test our shellcode and I executed it in order to check the payload is correct.
The configurator
The most interesting part here is to give the shellcode flexibility for the
second stage payload to be executed. The basic idea is to have three different
payloads:
execve(“/bin/sh”)
TCP Bind shell shellcode on port 4444
TCP Reverse shell shellcode on localhost port 4444
Here it is the python script I used to create different C programs containing
different payloads. Please note that I added also a function to change the EGG
value.
Code in action
In this video, you can see the very default payload executing /bin/sh after the
EGG being found in memory.
Here, the payload is a TCP bind shellcode on port 4444 on localhost, developed
for the first SLAE
assignment
This video shows the payload for a TCP reverse shell shellcode on localhost on
port 4444 developed for the second SLAE
assignment
And in the last video, I show the default payload but with a different EGG.
SLAE Exam Statement
This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification:
Se questo post ti è piaciuto, sono abbastanza sicuro che troverai questi contenuti altrettanto interessanti. Buona lettura.
Episodio 32: Quando l'EDR fa crock
Introduzione
Ciao caro lettore. Ero come al solito in ritardo nella creazione di questo
numero della newsletter di cybersecurity più aperiodica dell’universo, quando
Internet si è rotta ancora.
Eh già… in questi mesi ho dato anima e corpo al canale YouTube ed ho trascurato un po’ il mio blog. Questa però è una delle cose che voglio prima raccontare qui, nella mia versione digitale di un Bullet Journal.