Posted on

Spring4Shell : Explained With POC

Hello, aspiring Ethical Hackers. In this article you will learn about Spring4shell, a new zero-day vulnerability that has been discovered in Spring Framework. Spring Framework is an open-source application framework for Java and is normally deployed with Apache Tomcat servers.

Vulnerability & Impact

There are two vulnerabilities affecting Spring Framework, one is in Spring Core and second is in Spring Cloud. The Spring Core RCE vulnerability impacts Java class objects.  The vulnerability in Spring Core has been given name Spring4shell in the lines of Log4shell as both vulnerabilities affect a library. Although, it took its name from Log4shell, it is not as dangerous as its namesake.

This vulnerability affects all versions of Spring Core Framework running on JDK versions 9 and after. This vulnerability is tracked as CVE-2022-22965. There is another RCE in Spring Cloud Function versions <=3.1.6 and <=3.2.2.

Proof Of Concept

It’s time to see the exploitation of Spring4shell practically. Let’s create a new directory named spring4shell.

Clone the repository shown in the image below. This repository contains both vulnerable docker image and exploit.

Build the Docker image vulnerable to spring4shell as shown below.

You can check if the target is set or not by visiting the URL in browser.

If you get the above message, the target is ready. Run the exploit. The python exploit uploads a java web shell on the target after exploiting vulnerability.

The exploit completed successfully. The web shell can be accessed at above highlighted address.

The POC is succesful,

Posted on

Shellcode Injection into Windows Binaries

Hello aspiring Ethical Hackers. In this article, we will see how to perform Shellcode Injection into Windows executables. In hacking, Shellcode is a code usually written in machine language instructions that starts a command shell from which a hacker can control the compromised machine. Shellcode is normally used as a payload.

Windows  binaries are those binaries that are already present by default on a Windows system. Just imagine you are pen testing a Windows machine and you want to gain access to it without bringing any third party Malware to the target system. How about using the files already present on the target system to execute your payload. This is also known as file less malware.

Windows by default has some binaries for its own genuine functions. However these can be utilized by malicious actors to execute their own payload which is not benign. Examples of these binaries are regsrvr32.exe, notepad.exe, calc.exe and rundll32.exe etc. Rundll32.exe is a binary used in Windows to link library for other Windows applications. Of course, readers know about Notepad and Calculator.

In this article, we will see how to inject shellcode into these Windows executables. For this, we will be using a tool named CactusTorch. CactusTorch  is a shellcode launcher tool that can be used to launch 32 bit shellcode which can then be injected into any Windows binaries.

Let’s see how this tool works. CactusTorch can be cloned from GitHub as shown below from here.

Once the repository is cloned successfully, we need to create shellcode. Cactus torch is compatible with Metasploit and Cobalt strike. So let’s use msfvenom to create 32 bit shellcode.

The shellcode is successfully created and is stored in payload.bin file.

Next, encode this payload using base64 encoding as shown below.

This shellcode can be hosted in different formats as shown below. These formats are already provided by Cactustorch.

Let’s see the example of hta file. Open the cactustorch.hta file using any text editor.

We can specify the binary you want to inject this shellcode into. For example, here we want to inject shellcode into rundll32.exe. Copy the base64 encoded shellcode at  “Dim code”. Save the file. Start a Metasploit listener as shown below.

Next, all we have to do is make the user on target system execute the cactus torch.hta file. This can be done using social engineering. Now once someone clicks on it, we should get a successful meterpreter session as shown below.

Similarly, this shellcode can be hosted in JavaScript and also VB script and VBA files. That’s how shellcode injection can be performed in Windows binaries.

Posted on

Packet Sniffing : Part 1

Hello, aspiring Ethical hackers. In this article, you will learn about basics of packet sniffing. You should have observed that almost all the websites you have visited recently have a padlock sign and begin with HTTPS. Google started giving minor ranking boost to websites with HTTPS enabled since year 2014.There is a good security reason behind this. In this first article on Sniffing our readers will learn and understand about basic concepts about Sniffing and why plaintext protocols are considered bad from security perspective.

Plain text protocols are those protocols in which confidential information like usernames and passwords are passed to the server in complete plain text. This allows anyone in middle to sniff on these usernames and passwords. This attack is known as sniffing attack or Man in The Middle (MITM) attack or Janus attack.

 In ancient Roman mythology, Janus is a God who presided over both beginning and end. In a packet sniffing attack, as an attacker is in middle and can see the data going between server and client, this attack is also known as Janus attack. You are going to see how sniffing works on plaintext protocols in this article. In our present Issue, we will demonstrate the basic level of sniffing on plaintext protocols. For this, we will be using three virtual machines which are on the same network.

They are  Metasploitable 2 which acts as server, Ubuntu which acts as client and of course Kali as our Attacker system.  As you can see, the IP addresses of the three machines are

     Metasploitable2 – 192.168.64.128 (Server)

     Ubuntu – 192.168.64.132 (Client)

     Kali – 192.168.64.132 (Attacker system)

Let’s start Wireshark on the attacker machine (on interface eth0). It starts capturing packets on the network.

The reason why we are using Metasploitable 2 as our target is that it already has many services that we need for this tutorial preinstalled.  The first service we will be using is Telnet. It is a protocol that is used for remote access on another system. On most Linux systems, Telnet clients are installed by default.

So we Open a terminal and log into the Metasploitable 2 Telnet server with the credentials shown below.

The login is successful. Now on the Attacker system, we can observe the traffic being captured by the Wireshark sniffer. You can see data related to Telnet being transferred.

We can Right Click on that Telnet data stream and click on “Follow” as shown below.

In the sub menu that opens when we click on the only option “TCP stream” a new window opens that will show only the TCP stream.

In this window, you can see the credentials we just used to login into the target system. Telnet is a plain text protocol which transfers credentials and other sensitive data in plain text. This allows sniffing of data. That’s the reason it has been mostly replaced by Secure Shell (SSH) nowadays.   

Let’s see another protocol. File Transfer Protocol (FTP) is a protocol that is used to share files. It is another protocol that transfers data in plain text. From our client, we login into the FTP server with credentials “anonymous:anonymous”.

Anonymous account in FTP is used to share files to anyone without the need for them to know credentials.

On the Wireshark interface, you can see FTP data being transferred.

We can view the TCP stream

This once again shows credentials.

Instead of observing LIVE data transfer and following TCP stream from there, we can also just save the packet capture file and open the file later for analysis.

After opening the file, we can search for specific terms as shown below. 

Then following the TCP stream gives us the credentials.

Seeing the vulnerability due to sniffing, many protocols have been replaced with secure protocols which transfer data in encrypted form instead of plain text form. We will learn more about sniffing in our next Part.

Posted on

Buffer Overflow for Beginners : Part 2

Hello aspiring Ethical Hackers. In Part 2 of Buffer Overflow foe beginners, we will see how to write an exploit for a buffer overflow vulnerability. In Part 1 of this article, readers have learnt practically as to what buffer overflow is and how a buffer overflow vulnerability can be identified in a program using fuzzing. Our readers have also seen how we exploited it.
But manually fuzzing the program can be tiresome sometimes. In the example we have shown in the previous article, the buffer only needed 32 characters to be overflown but what if the buffer has a very large (let’s say 1000) size. Manual fuzzing in such cases becomes a tiresome process.

We need some automation and simplification. It’s time to introduce PEDA. PEDA is a Python Exploit Development Assistance for GNU Debugger. It enhances the functionality of the GNU Debugger by displaying disassembly codes, `registers and memory information during debugging. It also allows users to create a random pattern within the gdb console and also find the offset etc. We will learn more about the tool practically. This tool can be installed as shown below.

Now let’s go into our C lab and load the program “second” with GDB normally as shown below. This is the same program we have used in Part1 of this article. As the program loads, you will see that the interface now shows “gdb-peda” instead of just “gdb” as in the previous article.

Let us test this program once again for the buffer overflow vulnerability. Here’s the disassembled code of the program “second”.

Let’s create a string of random characters of a specific length, say 50. This can be done using the “pattern_create” command in peda. Copy the random string.

Now let’s run the program. When it prompts you the question, “Name which superhero you want to be”, paste the string we just copied and click on “Enter”. Gdb-peda gives us information about the memory registers as shown below.

It also shows us the code being executed but the most important thing it shows is the memory stack.

If you observe the stack of the program above, you can see that the string of random characters we provided as input is allocated into two memory areas. The highlighted part went into first buffer and the rest of the random characters went into the second memory area.

Instead of counting how many characters are in the first memory area, we can find the number of characters using “pattern_offset” command. We copy the random characters that went into the first buffer and use it as shown below to find the offset.

We call it as offset as we need to fill this area with random characters as no code will be executed in this offset area (as in the Part 1 of this article). The offset is 32. Well, since we no- w know the offset, let’s write an exploit for this vulnerable program. Open a new file and write the exploit as shown below.

This is a simple python exploit and the comments should explain you what it does. Let us give you more information about it. The first line of the code is basically telling the exploit to launch a python interpreter. In the second and third line, we are importing pwntools and OS modules respectively. The pwntools library has all the functions needed in penetration testing and OS module has operating system functions. In the next line we declare a variable named “path” and assign it a function os.getcwd() . This function gets the current working directory (If the OS module is not imported, this line will not work).

In the next line, another variable is declared with the name “program” and we assign it the program we want this exploit to target. As our target program is named “second” we give that name. In the next line, the “full_path” variable combines both the “path” and “program” variables to get the full working path of the program. Till this part of the code, we have reached the program we want to exploit.

Now the exploitation part. The “fill_buffer” variable fills the offset area with 32 iterations of “C” (It can be any character of your choice, but make sure its 32 for this program). In the next line we are specifying the command to be executed after the buffer is filled. Here its is “whoami”.

The exploit only works when the buffer is filled and then the command is executed. So we need to combine the “fill_buffer” and “cmd” results. The process() command start the target program while the p.sendline(bof) command sends the output of “bof” to the program already started. The p.interactive() gives the user the control after the exploit runs. Once coding is finished, save the exploit with any name you want. We named it bof1.py. Then run it as shown.

As you can see in the above image, after filling the buffer the exploit was successful in executing the command “whoami”. Now change the command to be executed and run the exploit again.

Once again it runs successfully and executes the command. This gives us a shell. This is how buffer overflow exploits are written.

When most of our readers ask as to which programming language to start learning with in the journey of ethical hacking or penetration testing, Our suggestion is always python and yo -u now know why? Python is very simple but still effective. It has a readable and easily maintainable code compared to other programming languages. Hence, it is very easy to learn. In just about ten lines, you have written the first buffer overflow exploit although its for a intentionally vulnerable program.

Posted on

Buffer Overflow for Beginners

Hello aspiring hackers. In this article, you will learn about buffer overflow for beginners. Do you remember the new directory named “C” we created in our previous article to demonstrate about the tool GNU Debugger. I want you to go again into that directory and code another C program as shown below. You can aptly name it second.c.

After you finish coding it, compile the second.c program as shown below.

The compilation should pop up many warnings. But as it is said, programmers worry about errors and not warnings. So for now just ignore the warnings. Now let me explain what this program does. This program is one of the popular programs used to demonstrate buffer overflow. We have introduced some modifications to it. Externally, it is a simple program which asks users as to which superhero they want to be and prints it back as shown below.

Now let me explain the internal code of this program line by line. Let’s jump to the 4th and 5th line directly in which we created two characters ‘sh_name’ and ‘command’ with a pointer. The asterisk symbol signifies a pointer to a char variable. We use this when we have no idea what length the string is going to be for the character. In the 6th and 7th line of the program, we have a C function named “malloc” which is used to allocate memory during runtime. As you can see, it allocates a memory of 10 and 128 bytes to ‘sh_name’ and ‘command’ respectively. To put simply, I have created two buffers here, one of 10 bytes and other of 128 bytes.


Seeing where we are getting to? In the 8th line, the program prints the text as to who your super hero is and collects user input using the “gets” command which reads input from the standard input and stores them as a C string. In the 9th line, it is printed back by prepending it with a “Hello” as we have already seen in the image above. The last line of the C program has the ‘system’ function which passes commands to command processor to be executed. I hope you understood the function of this program.
Now suppose a user ran the program and when prompted for his favorite super hero answered as shown below. Maybe he was a diehard (to the power of 7) fan of Captain America like me or he was an English language perfectionist who hated answering minimal answers.  Whatever the user was, the program responded as shown below. It printed out the answer but it also printed something else, ” he not found” with a ‘sh’ at the beginning.

“sh” is a command language interpreter that executes commands from the standard input. This is a BUG. Say it once again loudly “a BUG”. The program is sent to the testers to find out what the bug can do. The testers load the program using GNU Debugger about which our readers have learnt in our previous article.

Now, you are the tester. Check the assembly code of the program.

In the assembly code, you can see that there’s a command “gets” that collects data from standard input. Introduce a breakpoint at the point shown below and run the program . With the breakpoint, the program stops running exactly at the point where you give input to the program. After giving input, you can continue the program as shown below.

If you have observed in the above image, I have given 16 C’s as input. This process is known as fuzzing. Fuzzing is a process where we provide strings of varying length as input to find out where the buffer overflow occurs.
This strings of different lengths can be created in various ways. Here’s a method to create C’s of varied lengths using python.

We can also directly provide this random text created to the program as shown below instead of copying and pasting it.

Here is the program running in the debugger.

As an input of 35 characters is provided, a overflow occurred. Three C’s overflowed over their buffer onto the next buffer.

So the size of the first buffer is 35-3 = 32 characters. Anything that jumps over this 32 characters onto next buffer is being executed as a command due to “system” function there. So next, give 32 C’s and then append a command “ls” to it as shown below.

As you can see, the “ls” command got executed. If it is not a command, the program says “not found” .

Try some other commands as shown below.

You can even pop a raw shell to another machine as shown below.

That’s all for now. To add more fun, go to your “second.c” program and add some additional lines as highlighted below. These are print commands.

Compile again and now run the program. You should see something as shown below. Observed the difference?

That’s all in buffer overflow for beginners. Want to learn Ethical Hacking in Real World Scenarios? Subscribe to our monthly magazine now.