MY JOURNEY!!!! A RANT lol. (My Struggles & Inspirations) [Wed, March 9, 2022 : 14:00:16]

As much as I aspire to have this blog be a centralized space where people in the Infosec community can reference my work and learn from it, I also want to be transparent and document my struggles and the topics I find challenging to learn.

To date, I have successfully managed to teach myself the core fundamentals of Cybersecurity and how to be proficient in the different skill-sets required to be a cybersecurity professional, both with the knowledge of defensive and offensive techniques to incorporate within the real world. Overtime, my aspirations have broadened and deepened as I've come to see more advanced subjects within. At the core, I've always wanted to be able to find 0-day vulnerabilities within commonly used technologies as well as create programs that can be utilized within the Infosec community. However, I'd be lying when I say that the journey has been easy. In as much as I have created this blog for public and personal documentation, I study Cyber-security and Software Development professionally, so the struggles with coming to grasp with the topics literally follow me everywhere. But knowing me, I hardly give up. From the time I decided to learn hacking, I decided that I would be diving in uncharted territory, embracing the uncomfortability of the process. Sometimes, However, I ask myself why the hell I chose such a profession. But I find myself answering myself with the answer: PASSION. Its simply passion and vision that drives me to continue forward. One thing I can definitely iterate is: Hacking is definitely not the way it looks on the Hollywood screens. It takes alot of time and brain power. Its one of those professions that require creativity because that has been the very element that has been the driving force in the progression of Information Security. Seeing professionals thrive in this profession is definitely eye candy, seems cool and all, but once you see the process of what it takes to get there LOLLL. Crazy. I spend weeks and weeks trying to solve a particular problem, with dozens of files an books and notes I've taken overtime. The knowledge sometimes doesn't seem to stick. It gets real frustrating. Headaches on Headaches on Headaches. 

The topics I'm currently struggling with are:

1. The intermediate and advanced analysis of assembly language for Reverse Engineering and Exploit Development.

2. Analyzing intermediate level assembly code on the stack & C code and finding vulnerabilities like format string vulns etc. (especially within CTFs)

3. Understanding socket programming both in C & Python

4. Understanding kernel level security.

5. OWASP top 10 client and server side vulnerabilities (especially SSTI's, CSRF's and all...)

6. Understanding Cryptography & Reverse Engineering Cryptographic Algorithms (like RSA, Xor .etc)

Whats with the rant bruv?

As this blog is meant for documentation of my progress with CTF's, it is also meant to educate myself in the long-run, a means of reinforcing the knowledge acquired, drilling it into my brain so i don't forget lol. I intend on being transparent with the process of learning the craft I've dedicated myself to learn. Alot of security focused blogs out there are fantastic to learn from. Many of them actually inspired me to create my blog and share my work with the world. However, it helps to have rants like these because most of the time, the content focuses on the end result, which is in this instance, the demonstration of the knowledge acquired. Sometimes, It helps to see the struggles you face within a certain topic being faced by someone else. It confirms that you necessarily aren't the only one who struggles with learning that topic. So in my defense, the rant was necessary to load off all the frustration trapped within. Also to show the people that read this that... yeah... Hacking is not for the faint hearted. WILL an purpose MUST BE YOUR FRIENDS otherwise you'll hardly get through it all. Below is an episode of Pwny-racing, a hacker race whereby 4 challengers are given a problem, which in these terms either code or binaries which have hidden vulnerabilities. These vulnerabilities are to be found and exploited. Keep in mind that these are gamified to a certain degree. But a professional hacker or security analyst typically go exactly the same route in real life. Its content like these really keeps me on my toes and shows me just how security is a myth. Everything in software or hardware has a flaw. One just needs to have the knowledge to find it. 

With the little knowledge I've acquired, I'm definitely grateful to myself for pushing through and having a higher view of what I want to achieve within the Cybersecurity Industry. Secondly, many people within the Infosec industry who continue to release infosec content and writeups that help script kiddies like me to learn as easily as possible. Below are Youtubers that I appreciate and have helped me aside from practice and crazy amounts of reading.

JohnHammond

CryptoCat

LiveOverflow

Ippsec

Purple F0x Security (Blog)

KindredSec

I didnt wanna go all out. I just want this to serve as a reminder that one must pass in the fire to get to the fountain. Often we get discouraged in learning blocks but we have to persevere and be more resilient. If you're in Information Security, be sure to keep moving forward and work towards your goals. 

ELF x86 - Stack buffer overflow basic 2 | Pwn Challenge Documentation #3

Back again with another walkthrough from Root-Me Hacking & Information Security Platform. Straight into it. We're provided with the challenge source code as well as the binary protections.

Binary protections NX is enabled, immediately indicating that any code we put onto the stack won't be executed. Reading through, the source code is provided so we can analyze it.

The source code of the challenge gives 3 functions within the binary. The main function, which is the most important function in C programs, shows a integer variable called 'var', a function pointer pointing to the function 'sup' and interestingly, a character buffer of 128 bytes. From that alone, we can see that this challenge will be a classic buffer overflow challenge. the next line introduces the fgets function, which takes in 133 bytes in total from standard input (stdin) and passes it into the buf variable. 

executing this binary, will only execute the main function. We see from the source that there is a shell function which gives us a shell (/bin/bash) in order for us to get the flag. The goal will be to use a buffer overflow attack to overwrite the instruction pointer and write the memory address of where the shell function is located, essentially redirecting execution to get a shell. 

Note: The memory address of the shell function can be found by loading the binary into GDB and typing 'p shell' to leak the address

I copied the source code and compiled the binary on my local machine but alternatively, Root-Me provides the SSH credentials to access the remote server to connect to and complete the challenge. 

To exploit this binary to get a root shell, we can utilize python located on the remote server to write 128 bytes of junk to the binary, plus the address of where the shell function is in memory, we can then pipe the output of that into the binary to exploit the binary. The 'cat' at the end simply a means to prevent any errors once we get a shell and executes any commands.

Exploit Code: (python -c 'print "A"*128 + "\x16\x85\x04\x08"';cat) | ./ch15

Flag: B33r1sSoG00D4y0urBr4iN

Nmap For Network Reconnaissance

Most of the time, especially as a hacker, you have to have a means to identify and investigate the target network in which you have either been assigned with by a company or whether you operate in the shadows (which I recommend you don't lol). Aside from passively acquiring information from publicly accessible information from the internet, a method called passive reconnaissance, it is possible to actively gather quite useful information about a specific target or the target network, which is called active reconnaissance.

Nmap, A network auditing and reconnaissance tool, that can be utilized by network engineers or system administrators, can be used by hackers to essentially gain access to uncontrolled parts of the system. Nmap can essentially identify active running hosts on a target network, the open TCP ports, the various services running on the hosts, and even utilize NSE scripts Nmap provides within the suite to do more a detailed analysis of the target network. Nmap can be installed both on Windows and in majority of the Linux distributions, but comes pre-installed in Kali Linux, a penetration testing and information security linux distribution. To follow along, you can download Nmap here.

Basics of Networking (enough to get the point across)

A network is essentially a bunch of devices connected together with the ability to transfer information and/or data between them. However, for this to occur, these devices need to have a way to be identified, and this is done using IP Addresses. Every device, including the one you are using to view this, has been assigned with an IP Address from your Internet Service Provider. That IP Address is essentially your identifier on the internet. The Internet itself, which in full, is 'International Network' is a plethora of computers, servers and devices connected with each other, having the ability to transfer all this information. There is so much to networking but this is the surface level information you need to understand how useful Nmap is.

Consider the following:

Nmap "Aggressive Scan"

Above is an nmap scan, an "Aggressive" scan (indicated with the "-A" flag) was conducted against the target domain "scanme.nmap.org". This scan has uncovered alot of information about the remote target such as its IP Address (45.33.32.156) as well the open ports found on the respective IP Address/Domain. Within a target host, there are various services that are open in order to process information. For example, the service of file sharing (also known as FTP) is usually configured on port 21, the service of SSH, which is all about providing an encrypted remote access to a server or a computer is usually configured on port 22. So for every port, there is a respective service, which has software of some sort, that runs on that port. 

Above, we found the following:

PORT 22, which is SSH and the software version running on this port is OpenSSH 6.6.1p1 Ubuntu

PORT 80, which is HTTP and the software version running on this port is Apache httpd 2.4.7 (Ubuntu Web Server)

As well as other ports which would need more extensive research. Already from this Nmap scan, we have enumerated the open ports, the services running on those ports and the versions running on these ports, and even the operating system of the web server. This information can be VERY useful as a hacker can search for vulnerabilities within these services, exploit the vulnerabilities and gain remote access to the host or to the network. Aside from performing recon on a local network, you can also conduct recon on a remote network. 

The NSE scripts can perform more advanced reconnaissance, automate brute-force attacks, detect CVEs, detect Web-Application Firewalls that blocks malicious network traffic to and from the web server the firewall is protecting and many other useful tasks. Nmap has proven itself within the security industry, from malicious attackers, security researchers, system administrators, network engineers and ethical hackers to be a tool that provides effectiveness and accuracy in terms of its auditing and its fingerprinting of systems and networks. This posts has outlined the basics of the functionalities of nmap. In future posts, I will show off on how the NSE scripts can detect vulnerabilities, automate brute-force attacks and other useful reconnaissance techniques.

Executable Stack | 247CTF write-up [PWNED!!!]

 

In this walkthrough I go over the challenge I completed on 247CTF, a platform which offers hackers a chance to sharpen their hacking skills ranging from challenges such as Web Exploitation, Cryptography & Pwn challenges. The challenge I completed is from the pwn category, called "executable stack". Below is the challenge description. Reading this while playing CTFs help with regards to mentally browsing through how to take on the challenge and what route to go through.

Completing this challenge requires you to exploit a binary on a remote host. So in order to analyze this binary, the challenge supplies us with the same binary hosted on the remote host so we can inspect the binary, identify the vulnerability, craft the exploit and see if we get a shell for testing.

Information Gathering

Usually, for CTF challenges, binaries are usually compiled with security protections. For this challenge, NX is disabled. In a low-level security, if NX was enabled, that would prevent any code to be executed on the stack. But for this challenge, it is disabled, thus concluding that we might be able to execute code on the stack. This feature could possibly come in handy in exploiting this binary. I will go through other protections such as PIE (Also known as ASLR [Address Stack Layout Randomization]), RELRO and RWX in another blog post.

We now know the protections on this binary. We can now go further in executing the binary to see what it does exactly to get a better understanding of its general functions. 

When I run the binary, it shows me this simple text telling us there are no flag functions. It also goes ahead on informing me that "you can make your own". After this the binary expects some sort of user input. When I input "test", the binary exits without any errors. This immediately tells me that this is a buffer overflow attack. 

Buffer Overflow: Brief Overview

The buffer overflow vulnerability is when user input surpasses the number of bytes allocated for that specific input itself. If a program required your name and assigned a buffer of 10 bytes to the buffer 'name', if an attacker inserts a name or even random text that surpasses that buffer, the attacker can essentially access other parts of memory and insert arbitrary code and execute malicious code and redirect program execution. Since I'm the attacker, that's exactly what I am going to do to solve the challenge. 

For further investigation, we will use GDB, a debugger which will strip the binary so that we can see the low-level functions that are executed under the hood. We will specifically look at the "main" function as this function is typically the most common function that are run by C programs. Since this challenge does not have the PIE security feature enabled, this allows us to see the functions. If It was enabled, that would make the challenge much more harder to complete. Just a side note.

Above is the assembly code of the binary which is executed by the CPU, thus making it a very low-level language to understand. Hackers in the real world deal with this frequently to debug software and hunt for various vulnerabilities in order to exploit them. Above we see many function calls such as <puts@plt> and <chall>. What is interesting is that the main function calls the function <chall>. We might want to look into that. 

Looking into the <chall> function, we see that the function prepares memory for a buffer and <gets@plt> gets called, which is the same as the gets() function which essentially does not check how many bytes are inserted in it, thus making it vulnerable to buffer overflows. In order for us to successfully exploit this, we need to essentially overwrite EIP, which is the Instruction Pointer, a register in memory (like EAX, EBX, ECX, ESP etc.). Before we get into that, we need to insert more data into the binary so we ca cause it to crash. 

To do this, I will generate a cyclic pattern of 200 bytes, which will be used to test and see if we get a Segmentation Fault, which in more technical terms means the program has crashed.

The command above creates the cyclic pattern and redirects the output into a file called payload. After we do this we go back into GDB and insert this payload file into the binary to see if we cause a buffer overflow.

Segmentation Fault! Exactly what we wanted. Looking at the registers, we see the EIP, specifically being overwritten with 0x6261616b which is equivalent to 'kaab'. With this data we need to go on and calculate the exact offset of where the EIP was overwritten. Since the cyclic pattern generated to 200 bytes, we need to know exactly how many bytes it took to overwrite the EIP. 

Using python and the pwn module, which essentially a CTF framework to make binary exploitation easier, we find that it took exactly 140 bytes to overwrite EIP. From this point onward, we can go on to start crafting the payload. EIP is important because it essentially points to the next memory address where the next block of code will be executed. In this case, 0x6261616b is an invalid memory address. It is the hexademical representation of 'kaab' that we saw in the output of the Segmentation Fault. At this point onward, we can redirect the execution flow of the binary to what we want. 

Addtionally, looking at the functions, we should also get the JMP_ESP memory address as the code for us to get a shell on the remote target is located in the stack. Upon all the analysis and debugging of the binary, I have already written the final exploit which will essentially "hack" into the binary in the remote target via the buffer overflow vulnerability so we can capture the flag and complete the flag.

Final Exploit

Above is the final exploit. It imports the everything in the pwn module firstly, defines the target which are 'XXXXX.247ctf.com' and the TCP port 50339. Next it crafts the shellcode (/bin/bash shellcode) and stores it in the shellcode variable. The payload (in bytes) will create 140 'A's and appends the memory address of JMP_ESP(0x080484b3). After this it appends the shellcode crafted by the pwn module, stored in the shellcode variable. It then sends the payload to the remote target. Once the payload exploits the buffer overflow vulnerability, we can interact with it (using the target.interactive()). Now we run the exploit.

Upon running the exploit, WE GET A SHELL! We can now get the flag an submit. Challenge Completed!

FLAG: 247CTF{27886b9a498ed93685af9db0b1e304ec}

Wrapping Up

This challenge was a really basic introduction to binary exploitation and exploit development. I look forward to writing more walkthroughs like this and documenting my thought process on challenges like these.  Binary exploitation challenges get a lot more complex and complex, challenging hackers in their knowledge on how to bypass various protections. I look forward to documenting it all for you all to hjhave a look at how its done. Thanks for reading !

ELF x86 — Stack buffer overflow (basic) 1 CTF Writeup | PWN Challenge Documentation #1

This Capture the Flag challenge was taken from Root Me (http://root-me.org), which is a platform that offers various hacking challenges ranging from topics like Cryptoanalysis, Web Exploitation, Cracking, Programming, Network & Memory-Dump Forensics along with other challenges to improve hacking and computer security. This was a particularly interesting as it was definitely interesting to learn. As far as this documentation is concerned, It has alot to do with binary exploitation. Binary exploitation is a subset of hacking and computer security which has do with exploiting vulnerabilities in binary executables. Part of the "App-System" category is the Stack buffer overflow basic 1 CTF challenge which is intended to teach the basics of Binary exploitation. Upon doing this challenge you notice that the source code of the challenge as well as an ssh connection to a remote server that we can connect to and exploit the binary and grab the flag. First, we grab the source code and compile the code into a binary we can analyze on our attacker machine to find the vulnerability and exploit it locally so we can have a well crafted exploit to finally exploit the binary in the remote server and grab the flag.

Source Code Analysis

Looking at the source code, we see char  which means that a char (character) buffer is being declared to handle a maximum of 40 characters. The fgets() function takes in the input to place into buf[40], although the second parameter, 45, shows that the limit of the input the user can put in is 45, leaving an extra 5 characters we can put in, this makes it more interesting. 

Continuing further, 2 "if conditionals" come to play. The first "if conditional" basically checks if the variable "check" is either equal to 0x04030201 or 0xdeadbeef. If the variable "check" is not equal to either, then it prints out to the user "You are on the right way"...(which of course is false encouragement lol.)

The second "If condition" gives us a straight path of what we need to do. The goal of every CTF is to overcome the challenge and capture the flag. Looking further beyond this if conditional, the program tells me that "I've won...Opening my shell...". That is exactly what we want. We want to exploit this binary in order to get a /bin/bash shell in order to capture the flag and complete the challenge. So in order for that to happen, the variable "check" must equal "0xdeadbeef". From here onwards, we know exactly what we want to do.

We will use a buffer overflow attack on the program, specifically on the 'buf[40]' character array so we can overwrite it and insert 0xdeadbeef into the variable "check" and get the flag. Cool.

Exploitation

Now that we have a pathway to exploitation, we firstly have to connect to the SSH server where this challenge is being hosted.

SSH credentials: ssh -p 2222 app-systeme-ch13@challenge02.root-me.org:app-systeme-ch13

We finally login to the SSH server. The information parsed through while logging onto the server is a script are for additional server called checksec, which is a program used to check for the security mechanisms enabled in a given binary. The only protection enabled is NX, or Non-eXectuable, is a security mechanism that enables the stack in memory to be protected from any shellcode. So basically, if any code was injected into the stack, that code wouldn't be executed. 

I have crafted the exploit. Python is lightweight for exploit development for CTFs so I'll use it here. Firstly we need to overflow the buf[40] character array then afterward we add, 0xdeadbeef (represented in hex). As all this is being done, the exploit pipes its input into the vulnerable binary and we get this..."Yeah dude, you win". This is what we want. Initially we see the prompt hang, meaning that the /bin/bash shell has been opened in order for us to find the flag.

Flag: 1w4ntm0r3pr0np1s