Vuln: Buffer Overun
Locate the buffer overflow in the programs binary via reverse engineering techniques
Buffer over runs, commonly referred to as buffer overflows are by far one of the most common stack and heap based vulnerabilities and when working with system APIs, might also be one of the most common mistakes to make!
What is this objective/goal?
The objective of this task is to make sure we can analyze the binary in some shape or form to recognize security faults in the program on a muchhh more lower level. In this case, we will need to not only create a diagram for hunting these kind of security issues, but will also need to locate at least one of the buffer overflows that exist within this program.
To finish this goal we must:
Find the BOF and explain how it is an issue
Explain what we learned
Build a detailed graph explaining how we go about hunting 0days in binaries and why
Analyzing & Specialized Recon
In order to first understand what we are looking for and exactly how to go about it, we need to build out some sort of idea as to how we are going to be locating this. Sadly, there are not nearly enough binary scanning tools out there open to the public and even if they are- they are mostly trashy. Any 'good' software out there for binary auditing is wayyyy too pricy for us- so we are going old school and going to build out what I like to call - 'attack path'
Attack paths are ways to describe the sequence of steps or methods we can use to gain unauthorized access to a system, find vulnerabilities and exploit them- and more!
For now, lets define some important points.
What are we looking for?
Ideally, when looking for binary vulnerabilities which are like finding a needle in a haystack, we can actually define what specific vulnerability we are expecting the most. For example-
if we know the application is doing operation on data
If we know the application also allows for a ton of user input
If we know the application docs tell the user not to do something with inputs
Then we most likely can expect to find buffer overflows. For this section, I have provided a general template of questions and answers.
Area: User input
How often does the application ask for user input?
Are there specific restrictions to the user input?
Is the user input allowing for everything?
Is the application acting like a desktop app but is really a web app? (helpful for web based vulns)
Is the application manipulating or copying or saving the data anywhere?
Where is the user input going?
What data types are used for the user input?
Area: Memory Management
How is the application using system memory?
Do we see any Windows APIs for heap-based allocation?
Are exports like 'free' and 'malloc' used?
Just as a basic idea for you!
Our scenario
This GUI, if you spent time exploring it- uses user input quite frequently in both the application window itself and even the web server.
Since the developers made this web server clearly for admins, it means that the developers did not anticipate that the users would be reaching this server or even knowing it existed- we can assume that they might not care how the user input is handled.
Why do we not expect devs to handle input here?
Well if this is an admin only login- we can expect either devs on testing teams or admins who know how to use the software in and out are the only ones being thought of. If the development team does not expect a user to input anything- then they cross security or care off the list if they are hollow-headed enough or ignorant enough.
What are we looking for?
In this scenario, we are going to be looking for some form of buffer overflow or something for comparing data on the backend of the web application or manipulation for the admin-ID. This is because we expect the admin-ID to be encoded or hashed to compare a hash in a remote database or something where data will be moved, copied, or compared.
Our attack path - Text based
For our attack path- we are going to be looking over a few things.
Final Decision: What are we looking for
We know we are looking for a buffer overflow- specifically heap considering our scenario. So we can expect to look at calls like the following.
Routines that use 'malloc' around known user-input areas
Routines that use data manipulation functions like
strcatorsprintfevenstrcatRoutines that use 'calloc' or 'relloc'
Routines that use file operations like 'fopen' or 'fwrite' even 'fread' or Windows APIs that use file operations unsafely such as 'CreateFile'
And other calls alike that rely on buffers
Since we now know what we are looking for, we can demonstrate a sample path that defines what we are going to be looking for.
Answer: For this final thought, we are looking for any calls that revolve around memory management or string copying and management / manipulation around the user input section
Final Decision: Area of importance
Before building our attack path, we want to also select an area of importance which means what area is the most susceptible to this flaw.
Answer: For this final thought, assuming that the admin panel was most likely not thought of or cared for much (especially its limited use) we can assume that this is a good area of interest, a way or area to look at. The area subject is going to be user input since the server allows users to take in user input
Final thoughts: How data is being fed to the program
Since we know this is not happening in the CLI and is certainly not in the GUI- we can expect the server to be taking in a specific input via web requests.
This means that we want to specifically look in areas where the program uses 'recv' calls.
Answer: For this final thought, the data is coming into the program via web request specifically a post request to the API endpoint on the server.
To find out how to do this challenge, go to the next page!
Last updated