• Home
twitter instagram Email linkedin youtube

::: re:search + re:view + re:share :::

Basic in reverse engineering executable files

This article is a part of our program, #re:educate where we empowering
cybersecurity students and beginners to share their understanding
about anything related to offensive security. For more info, refer to
this link RE:HACK - #re:educate

Author: Wan Muhammad Khairuddin
University: Universiti Teknikal Malaysia Melaka

Hi readers! This is a step by step, in basic, on how to reverse engineer an executable files that is written in C language. Reverse engineering is simply a process of understanding how a program works. When we got the end product, we disassemble and poke it around to see the behaviour of the product and then get some idea how the program works in the background. But in our context, we disassemble a binary executable files, run it and do analysis to understand the behaviour of the executable files.

In this walkthrough, we will use some program that will help us to reverse engineer the executable files. Reverse engineering can be overwhelming for beginners but we will try our best to explain and share tips on how you can easily understand the flow of the program just by reading the assembly code (static analysis).

What is Reverse Engineering ?

Reverse engineering is a process or method through which one attempts to understand how an application works when we don’t have the source codes. We understand it by disassembling the application and look at each function’s implementation.

Prerequisite

The most important things that need to be understood before we can start reverse engineer an executable file are:

  • Assembly language
  • Registers

We would not be able to get the source code of an application written in C or C++ because it will be converted into assembly language once compiled. You don’t have to be a master or can write a program by using assembly language to do reverse engineering. The code can be understood simply by knowing a few basic instructions and keywords.

Register is one of a small set of data holding places that are part of the computer processor. A register may hold an instruction, a storage address, or any kind of data (such as a bit sequence or individual characters). Some instructions specify registers as part of the instruction. Register is like a variable that stores data. It is also used to perform mathematical calculations. You can learn about common registers here. We would not explain much about register in this article.

Reverse Engineer a Simple Program

Now we will start the main purpose of this article. We will reverse engineer this file from Crackmes. Let’s get started.

Tools needed (for Windows):

  • IDA Freeware - https://hex-rays.com/ida-free/
  • Git Bash - https://git-scm.com/downloads

First we need to know what file we are dealing with. I will use file command in git bash to find out the type of the file.

enter image description here

From the command, it says the file is a 32-bit PE executable file. Thus, we know that it is for Windows environment. We would not need a Linux machine in this case.

Next, we can try run the file through our terminal (cmd.exe).

1

What the program does above is, it asks the user to enter a password and then display a message if the entered password is wrong or correct. From this behaviour, we can conclude that our goal is to find out the correct password. So let’s disassemble this file and figure out how the password checking functionality works.

Open our IDA > Choose new > Drag our file into IDA.

2

3

Complete the importing process and then it will look like this.

4

It does look overwhelming, but rest assured, we will walk you through each process to reverse engineer this file and collect the correct password.

First let us look at the top section.

5

You’ll see a lot of instructions here. It is easy to understand what is happening in it by focusing at the most significant things which is the function.

First we look at the call instruction. This instruction calls a function ; printf, gets and strcmp.

printf is when the program is printing something on the screen. In the beginning, we noted that the program displays a welcome message. So now we know our position or which part of the program we are looking at.

6

Move on to the next function is printf again. But this time, it displays the password: before the program asks for the user input.

7

Next is gets function. As we know gets function takes user input so what this assembly instructions do is taking the user input.

8

The instruction above says that it takes the address of szPassword variable and store it inside $eax register. Then after gets function finishes, the user input is stored inside whatever address the $eax holds. In this case $eax holds address of szPassword. So the user input is stored inside szPassword variable.

Last function is strcmp. This function compares two strings and check if these two strings are equal or not.

8

As you see above, before strcmp was called, the instructions push something onto the stack. The first one is szPassword, which stores the user input and then the instructions push str1onto the stack. Then strcmp is called. These two strings, szPassword and str1 are compared by the strcmp function. So basically our input is being compared to str1.

Next, let’s take a look at what happen after our input being compared.

9

There are two paths here; the red path and the green path. If the strcmp return 0 (which means if our input is equal to str1), we will be following the red path. Otherwise, we will be following the green path. Since we are looking for a correct password, we must follow the red path (look at the final message shown in the printf)

10

Further digging the file, we can see there’s a value set at the str1 which is LiL2281337.

11

Let’s try if LiL2281337 is the correct password.

12

Success! It seems we have found the correct password!

Additional notes

Some may ask, how do I know that szPassword and str1 are the strings that are being compared by strcmp? Let me explain in-depth how function calls in assembly.

strcmp is a function that takes two parameters.

int strcmp (const char* str1, const char* str2);

In 32-bit assembly, before a function with parameters being called, the value of the parameters will be pushed onto the stack first. Then when the function is called, it will take whatever value from the top of the stack as its parameter value. Let’s take a look at this instructions again.

13

As you can see there are two push instructions, push ecx pushes our input onto the stack and push offset str1 pushes the correct password onto the stack. Now our input and the correct password are placed at the top of the stack.

14

Then strcmp is called, it will take two items from the top of the stack to fulfill its two empty parameters. That’s is how function with parameters being called in 32-bit assembly.

Similarly to the printf. printf takes string to be displayed as its parameter. So the string must be pushed onto the stack first before printf is called.

15

Conclusion

Reverse engineering is quite complex for a beginner but with the right mindset and methodology, anyone can understand the flow of the program even though they have only a little knowledge about assembly language. The most important thing is to find a suitable methodology and know what to look for.

To anyone who wants to explore reverse engineering, I suggest reading as many reverse engineering writeups, articles, and research papers as possible. We will be able to learn more about reverse engineering as a result of this.

Share
Tweet
Pin
Share
No comments
Configuring BurpSuite to capture requests from a proxy unaware thick client

What is a thick client application

Thick client applications generally installed on a user’s local desktop/laptop/workstation. They sometimes called as Desktop Application.

These applications can run own its own (independently) without need to be connected to the internet. Best examples are desktop chat applications such as Teams, Zoom, Slack, etc.

Types of thick client based on proxy configuration

There are two:

  1. Proxy aware: The type that have an option to configure the proxy settings in it so a user could monitor the outgoing and incoming communications through the proxy server/tool.

  2. Proxy unaware: The type that have no option to configure the proxy settings. To monitor the requests, the user needs to make changes on their own machine’s host file.

How to configure

We had a situation where we required to perform a security assessment against the proxy unaware type thick client. To ensure we were able to collect all the incoming and outgoing requests, we configured our machine as the following:

Initial process

After configuring

Steps

  1. Edit the /etc/hosts file as the following (you may need to be a superuser):
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
127.0.0.1       targetapi.io
  1. In BurpSuite, navigate to your Proxy setting and add configure the Proxy Listeners to bind to the actual targetapi.io port (in this case is 443 and set it as “Loopback only”


  1. In the Request Handling, add the actual IP address of the targetapi.io and port 443. Tick on “Force use of TLS” (if it communicates over TLS) and enable invisible proxying. You may need to play around with the invisible proxying sometimes.

That’s all. Now you should be able to capture the thick client’s upcoming and outgoing requests in your BurpSuite.
Worth noting that if you are using port below 1024 in Burp’s proxy setting, you may need to run it as a superuser.

Share
Tweet
Pin
Share
No comments
Bypassing the fixed reflected XSS on👨‍⚕️ website

After we noted about a vulnerability disclosure program from BadApe NFT website (see http://blog.rehack.xyz/2022/06/disclosure-dom-based-xss-on-badape-nft.html), our team decided to poke around and see if there is any other Malaysian-based company that has the similar program on it.

We found one :). While they have a vulnerability disclosure program, further a discussion with them, they agreed for us to publish this article but without mentioning their name. Fair enough.

By simply browsing their website, we noted an obvious Reflected XSS and one DOM-Based XSS.

DOM-Based XSS

The DOM-Based XSS was interesting. The injection point was only detected when the URL included with a page parameter. Without this parameter, the value will not be reflected in the DOM. We used Untrusted-Types Devtools plugin by @filedescriptor to detect this.


This was too straightforward. By inserting the XSS payload, the XSS was successfully executed.

Reflected XSS

The reflected XSS was also found on an obvious location. The page parameter on a different endpoint from the above was insufficiently sanitise the user input, thus it was possible for us to insert our XSS payload such as '"><img src=x onerror=alert(document.domain)>

We notified their security team and they immediately mitigated the issue. Once our team received their reply stating that the fix was done, we casually verified the fix and noted that it can be bypassed.

The initial fix was to allow page parameter to only accepted up to 4 characters. More than that will redirect us to a 404 error page. We were able to bypass that via Parameter Pollution technique, where the second page parameter appended on the request was still accepted and reflected in the response body. Thus, this allowed us to include the XSS payload again and successfully bypassed the initial fix.


Again, our team was happy with the quick response and their commitment to security. They immediately reviewed and corrected the problem. We reviewed and confirmed the fix was correctly implemented this time.

Thank you to their security team, and we hope more companies in Malaysia will accept vulnerability disclosures from outsiders.

Share
Tweet
Pin
Share
No comments
DOM-Based XSS on BadApe NFT website

Recently, one of our wizards came across BadApe NFT. The BadApe NFT project is a collection of 10,000 bad apes with proof of ownership stored on the Binance Smart Chain. Their collections look cool, however, our team members are not into cryptocurrency and NFT. Most importantly they are founded by local NFT enthusiasts and have been supported by a few famous figures such as Soloz and Joe Flizzow

While looking at their roadmap, contributions to the NFT community and other news, we noted that they have their Vulnerability Disclosure programme as stated here https://badape.io/vulnerability-disclosure-program/

We thought, “hah!..this is interesting”. Since this is our first time to see a Malaysian-based company having a vulnerability disclosure program! This shows that they are concerned about the security of their assets and want them to be properly secured.

Since we were just finished with our internal penetration testing engagement at that time, we spent some time testing their website.

We started with a domain enumeration using Subfinder by ProjectDiscovery. We found the following subdomains:

www.badape.io
store.badape.io
dimension.badape.io
staging.badape.io
hub.badape.io
ftp.badape.io

We then further investigate the technologies used by these websites using httpx and found that most of them are fronted by Cloudflare. We picked their main website, https://badape.io as at the time of the testing, we observed this website was run on an outdated WordPress version.

We ran WPScan to determine if any outdated plugin is in use. What a stroke of luck (for us), the scan showed that one of the plugins, Elementor was outdated and vulnerable to a DOM-based XSS.

Checking on available proof-of-concept, we learnt that this plugin is vulnerable because the following endpoint
#elementor-action:action=lightbox&settings=
will take base64 encoded JSON input and decode it, insecurely, to the users.

Thus, by crafting a simple payload such as:

{
"type":"null",
"html":"<script>alert('xss')</script>"
}

and encoded them to base64 format was sufficient enough to trigger an alert box as a POC.

https://badape.io/#elementor-action:action=lightbox&settings=eyJ0eXBlIjoibnVsbCIsImh0bWwiOiI8c2NyaXB0PmFsZXJ0KCd4c3MnKTwvc2NyaXB0PiJ9

We submitted the report and BadApe NFT team immediately responded to our email and mitigate the issue.

References:

  • https://rotem-bar.com/hacking-65-million-websites-greater-cve-2022-29455-elementor
  • https://www.jbelamor.com/xss-elementor-lightox.html

Timeline:

  • 20 June 2022: Discovered DOM-based XSS and reported to BadApe NFT team via [email protected]
  • 20 June 2022: Their team replied to us and informed a timeline to fix it.
  • 23 June 2022: BadApe NFT replied and told us the issue has been fixed and asked us to confirm.
  • 23 June 2022: REHACK confirmed the fix.
  • 24 June 2022: Disclosure
Share
Tweet
Pin
Share
No comments
Introduction to SQL Injection

Introduction to SQL Injection attacks

This article is a part of our program, #re:educate where we empowering cybersecurity students and beginners to share their understanding about anything related to offensive security. For more info, refer to this link RE:HACK - #re:educate

Author: Ahmed Amru a.k.a Ahmd
University: UOW Malaysia KDU

The purpose of this article is to give a brief introduction to SQL injection and the three main types of attacks that can be launched using it. SQL Injection however can sometimes lead to gaining a reverse shell and thus compromise a system completely. Therefore, SQL Injection attacks can be devastating, not only to the database but also to the entire IT infrastructure.

SQL databases

SQL databases have been the standard databases used across industries for decades. Although new database implementations like NoSQL have emerged, SQL databases still dominate the world of databases. Some examples of SQL databases include : MariaDB, MySQL & PostgreSQL.

Data retrieval and storage on SQL databases

As with any database, its primary purpose is to store data securely and retrieve it when needed with utmost efficiency. “Structured Query Language” (SQL) language is used to write different commands or statements, and these are executed against the database to either retrieve or store data.

For example, let’s say we have a database table called rehack_articles. The SQL query used to store and retrieve data will look similar to this :

SQL query to store data :

SQL query to retrieve data :

SQL injection

Preface :

The target in this example is an application that allows users to search for certain fruits in the inventory. Such an application can be found in warehouses whereby employees can search for items in stock. This application is intentionally designed in a way that is vulnerable to SQL injection.

Note : This demo application can grabbed from here : https://github.com/amhmdr/sqli-basics-rehack

Goals :

The following are the goals that we want to achieve during the SQL Injection attacks.

  1. Bypass login

  2. Dump data from other tables into users view

  3. Delete data from tables

Demonstration :

1. Bypassing the login

Now let’s get right into SQL injection. You have already seen some basic examples of SQL queries that can be used to store and retrieve data. In order to explain the concept of SQL injection, imagine an application authentication scenario. Where the user utilises the login portal by entering the username and password.

In the back-end, these values are compared with the data from the SQL database to see if they match. Users can log in if their credentials match. Otherwise, they are either asked to retype the password or sign up. Let’s review this scenario in more depth.

The back-end of the application has this code :

The comments on the code explain what is happening:

  1. At first, the user input is used to create a SQL statement to run a query. The uname and pword variables are used to store the username and password the user has input.

  2. A SQL statement is set by appending the variables to the statement. The statement is then run.

  3. The If statement checks whether any row is returned by the SELECT statement, if it does the home page is shown.

So what makes this vulnerable to SQL injection? As observed from the above steps, there is no validation done to the user input at any stage. Validation means, cleaning up user input received from the front-end before sending it to the back-end. An example of a popular tool used for sanitising user input is DOMpurify. This tool works to remove ‘dirty HTML’ which could be used in the lead up to another type of attack called Cross-site Scripting attacks.

Likewise, sanitising had to be done here to remove the malicious SQL code. The user should not be entering any SQL query statements in the input. Thus, the application’s creator could have written code to prevent users from entering such statements. However, that is not the case here. Instead, the user input is appended to the query, as shown in the above screenshot.

SQL injection is an attack that takes advantage of this fact and others to inject and execute SQL queries for malicious purposes. Because there is no sanitisation of user input, an attacker could inject SQL queries into the back-end to achieve this. The attacker can now use this security lapse to bypass authentication. This is demonstrated further below.

Under a normal circumstance of a user logging in the interface will show similar to the following:

If we attach a debugging point on Visual Studio we can see the SQL query that gets executed:

However in the picture below, we see that the attacker appended ‘-- to the username field.


(Note that the ‘ character before the comment sequence -- is used to close off the first ‘, and complete the SQL statement.)

Due to the injection by the attacker, the SQL statement now gets interpreted as:

As you can see, the injected SQL statement will cause whatever comes after the username to be commented out by the --, which in our case happens to be - the very important password.

Therefore, the modified SQL statement is now querying for only the username. As long as the username exists, the SELECT statement will succeed and the next screen will appear, allowing someone to log in using just the username because the password is no longer checked.

In the previous example, we assumed the attacker already knew the username (admin). What if the username is unknown? SQL Injection can still be carried out using the following payload : test' OR 1=1--

The resulting SQL statement will be :

What is happening here is that we have appended an OR statement into the query. An OR statement will always return true as long as one condition is true. The username is given as a test which does not exist (false). However, the no where clause, 1=1 , is always true, hence resulting in an overall true statement and allowing the user to login.

Both payloads that were discussed above would take the user to this screen :

This is the home screen that shows the fruits in stock. In the next step we will perform SQL Injection in this screen to retrieve data from the other tables.

2. Dump data from other tables

We have just seen how SQL injection can be used to bypass application logic and let an attacker into the application without knowing the password. Likewise, SQL injection also opens up the door for an attacker to retrieve data that they are not authorised to access.

In the home screen of our target has a feature to search for fruits. The code that handles the searching is shown below:

So if someone searches for “Apple”, the interface will be like this :

By placing a breakpoint, we are able to view the resulting SQL query which is:

In this example, we will assume that we know the name of another table in the database, the users table. So how do we use this knowledge to dump the users table into the application’s view which is actually only supposed to show fruits?

To do this we will perform a technique in SQL Injection attack that is called, union injection. UNION is a term in SQL which can be combined with SELECT to combine results from multiple SELECT statements. An example syntax for this is :

SELECT * from table1 UNION SELECT * from table2

In order for a UNION clause to work, the resulting data from both tables must be off the same type and also have the same count. However, since this is a basic demonstration of SQL Injection we will assume that the fruits table and users table both have the same datatype and count.

With this information, we can now insert this malicious SQL payload such as:

mango%' UNION SELECT * FROM users --

Note : the percentage % character used here is the LIKE symbol in SQL and is commonly used to wrap search terms, therefore we have wrapped the word using% and ended with ‘.

When the user clicks search, the malicious SQL query formed is:

Once this code is executed the users table containing the username admin and password password is displayed in the home screen :

We can use this same knowledge to dump data from another table called shipping. Once again, we assume that this table has the same data type and count as the other two tables.

Therefore, the payload will be:

mango%' UNION SELECT * FROM users UNION SELECT * FROM shipping--

The result will be :

As can be seen above, the contents of the users and shipping tables have been dumped.

3. Delete data from tables

Similarly, we can use SQL Injection to delete records of an entire table. For demonstration purpose, we will delete the entire fruits table so that when a user login to the system they will not be able to see any records.

To perform this attack we will use the semicolon ; character. The ; character denotes the end of one SQL statement, and will allow us to execute another SQL statement after it. An example is shown below:

SELECT * FROM table1; TRUNCATE TABLE table2

From this information we can use the following payload :

mango%’; TRUNCATE TABLE fruits; --

NOTE: The DROP command does not work during the testing. This was probably due to security limitations, however, TRUNCATE seems to work.

Once the search button is clicked the table will be wiped, and the next time user logs in there will be no fruits shown :

Thank you

Share
Tweet
Pin
Share
No comments
Older Posts

About Us

About Us

A Malaysian cybersecurity boutique company focusing on research and high quality services. We aim to provide top notch and honest services to the industry and community.

Subscribe Us

Follow Us

  • twitter
  • instagram
  • youtube
  • linkedin
  • facebook

recent posts

Blog Archive

  • July 2022 (3)
  • June 2022 (1)
  • March 2022 (1)
  • December 2021 (5)
  • November 2021 (2)
  • October 2021 (1)

Created with by ThemeXpose