Malware Final Report

Running head: ANALYZING MALWARE SAMPLES’ ASSEMBLY AND FUNCTION 1

The Microsoft Malware Protection Center Challenge: Analyzing Malware Samples’ Assembly

and Function

Zachary Adams

Our Lady of the Lake University

ANALYZING MALWARE SAMPLES’ ASSEMBLY AND FUNCTION 2

Abstract

The purpose of this paper is to analyze the first two samples of malware the Microsoft Malware

Protection Center (MMPC) provided for their malware analysis challenge. Microsoft provided

the first sample, but the instructions to get the second sample are hidden in the first sample.

Proper analysis is needed to retrieve the second sample. Analyzing the samples involve

disassembling the malware executables using IDA Pro and debugging them using OllyDbg.

Screenshots of the process will be provided for each malware sample to illustrate the analysis

process. For the first sample, there was little guidance on how to proceed. The analysis of the

first sample will follow my own process and how solving the first sample leads into the second

sample’s analysis. The second sample required answering some questions about the sample’s

functionality, which I will detail the process of how I discovered the answers.


Executive Summary

The first sample of malware was a login program that required a username and password.

The goal of the analysis of sample 1 is to gain access to the file that would give instructions on

how to obtain sample 2. I was able to find all the usernames in the strings of the file and crack all

but one of the passwords in the program, but I decided instead to patch the program to bypass the

password checking function. As a result, I was able to log into the program and view the key.txt

file that would give instructions on how to obtain sample 2.

Sample 2 appeared to be a pump controller program that could be behind the login screen

of sample 1. In sample 2, I was given five questions to answer about the sample:

1. What are the commands accepted by the program?

2. What is the logic of the loop in the program?

3. How does the temperature model in the program work?

4. What are the vulnerabilities in the program? Can you create a proof of concept and

exploit them? What is the impact?

I was able to answer each of the questions in my analysis, which I will detail in the following

pages of my report.


Analyzing Sample 1: Login Program

Figure 1 (Login Screen)

When first opening sample 1, I was greeted with a message to supply a username as seen

in Figure 1. Trying my own username, I discovered that I was not able to login. At this point, I

could take two approaches to bypassing this login: 1) Find the passwords and crack them, or 2)

create a patched version of the sample that would skip the password check function. First, I

looked into the strings of sample 1. I found several usernames and MD5 password hashes in

Table 1 on the next page. I was able to crack all but one of them during my analysis. Also in the

strings of the program was a filename called “key.txt.” This particular file is protected by a

permission that is only granted to certain users.


Username MD5 Hash Password

jroam e10adc3949ba59abbe56e057f20f883e 123456

todgrad 5f4dcc3b5aa765d61d8327deb882cf99 password

sammie eb31870669f13fd8444c2bc918375f09 heaven

wiltil 5dac4f26f11849cc71d129edcc55283b 1london

reamik 7ab41869306b693f2d9d4f5fa793f0f0 superman99

test1234 bd04dfaad15639a6aa4314d63ce02f9a [Unknown]

reagmc 73023d8e8351392686261f2afce5ebad abc541

carlti 5fcfd41e547a12215b173ff47fdd3739 trustno1

rogid 6081d0da1ee073e537b933674e66ea4a blah1blah

admin 1e88a70ee1ccb2a25f63c8e5b7761702 msftflag!#37

Table 1 (Login Credentials)

The most interesting credential of this list is the “admin.” Since the contents of the file are only

allowed to be viewed by certain users, “admin” must be the one to have the permission to view

key.txt. I could have used the “admin” login to access the file, but I decided to try and crack the

program so that the password checking function would be bypassed. Looking into the assembly

in IDA Pro, I was able to identify the function in Figure 2.

Figure 2 (Password checking function)

Figure 4 (New Jump Location)


I noticed that right before the program checks the entered password there is a conditional jump

into the code block. Using OllyDbg, I set a breakpoint at that location and changed the assembly

from a conditional jump to an unconditional jump that completely skipped the password

checking function. The edited code is shown in Figure 3 and the new jump location in Figure 4.

After completing the edit, the patch program granted me access to the file without a password, as

shown in Figure 5.

Figure 3 (Patched Code)


Figure 5 (Bypass successful)

Figure 6 (Key.txt)


Finally granted access, I was able to view the content of the key.txt file. Inside it were

instructions on how to obtain the second sample from Microsoft. Figure 6 shows the programs

output from the key.txt file.

Analyzing Sample 2: Pump Control Program


Figure 7 (Sample 2 Start)

Starting the program shows a short boot progress screen before showing a monitor

interface. The “Workload” and “Temperature” are constantly fluctuating with the temperature

increasing as the workload does, and depending on the temperature “Pump 1” and “Pump 2” are

turn on. When the pumps are on, the temperature drops as well until it is low enough to where

the pumps turn off. If the “Controller” is turned off, the pumps do not automatically turn on and

the temperature will rise to around 120 degrees Celsius.

The following sections of my analysis will attempt to answer the questions outline in the

Executive Summary:

Figure 8 (Commands)


1. What are the commands that the program accept?

The commands are stored in the program as strings in Figure 8. Looking into the strings, I

noticed several commands that I can use to manipulate three objects in the program: Pump 1,

Pump 2, and the Controller.

All of these strings are located in the same function, which I renamed to “cmd_commands” in

the rest of the following Figures. To confirm my findings, I entered a command to see if it

worked. The results are shown in Figure 9.


Figure 9 (Command Successful)

2. What is the logic of the loop in the program?


I discovered three loops that run concurrently when the program is started. These loops are infinite

and only stop when the program does, or have other special conditions which I will describe in the

following paragraphs.

Figure 10 (Loop 1)

Figure 11 (Loop 2)


Figure 12 (Loop 2 Continued)


Figure 13 (Loop 3)


Figure 14 (Loop 3 Continued)



These loops perform several functions for the program and I will describe them one by one.

In box 1.1 of Figure 10 on page 10, the function “generate_status_nums” is called. This function

will print the values shown in the Workload and Temperature fields, and the status of Pump 1,

Pump 2, and the Controller. The variables that define these fields are set in another loop. In box

1.2, the program calls the C function “_kbhit” which checks to see if a key was hit since the last

time the loop ran. If the “Enter” was hit, the program creates a buffer that is 1023 bytes large as

seen in box 2. This buffer is then taken to box 3 where it is passed into the “cmd_commands”

function so that the program will perform the command entered. This function does not stop until

the program ends, but there is a vulnerability that I will detail later.

The second loop in Figures 11 and 12 on pages 11 and 12 is a complex function that uses a

complicated math equation to calculate the ever changing numbers in the Workload and

Temperature fields of the program. While I cannot abstract the exact equation from the assembly,

I can describe what the function does. In box 1, the “temperature” variable is copied into the

“xmm0” so that the value can be manipulated by the equation later on in the function. Below

that, the memory address for the C function “rand” is passed into the ESI register for future calls

in the function. “Rand” returns a pseudo-random number to EAX. In Figure 12 in boxes 4

through 7, the value for “cpu_load” is calculated and so that it can be used to determine the value

for the “temperature” variable right after. In box 8, the value for “pump_status” is copied to

EAX. “Pump_status” can have either 0 for no pumps on, 1 for one pump on, or 2 for both pumps

on. This value is used in the equation to determine the “temperature” value, which is set in box 9.

3. How does the temperature model in the program work?

This loop answers question 3 as well as the last part of question 2. The last loop in Figures 13

and 14 on pages 13 and 14 monitors the “temperature” value and it turns the pumps on when the


value gets too high. In box 1.1, the function sets EBX to 40. Before continuing to box 1.2, the

program checks to see of the Controller is off. If not, the program continues onto box 1.2 where

“temperature” is compared to EBX, which still contains 40. If the temperature is higher than 40,

Pump 1 is turned on in box 1.3. Usually this is enough for the loop to run once and it restarts.

The next relevant section is boxes 3.1 and 3.2 where the temperature is compared to 30. If the

temperature is less than 30, Pump 1 is turned off. This process is repeated in boxes 4.1-2 and 5.1-

2 where the temperature is compared to 40. If the temperature is higher, Pump 2 is turn on, or if

lower than 40 is turned off. In box 6, the values for “temperature” and “pump_status” are saved

in the ESI and EDI registers for use in the second loop that generates “temperature” value.

4. What are the vulnerabilities in the program? Can you create a proof of concept and

exploit them? What is the impact?

I discovered two vulnerabilities in sample 2. The first involves exploiting the command

prompt history function provided by pressing the F7 key. By doing so, a dialog box appears on

the screen that contains all the strings that have been entered during the session as shown in

Figure 15 (F7 Command History)


Figure 15. This can include login credentials in plaintext. In this case, the command history

allows someone who is not familiar with the program to know what commands the program

accepts if they were entered in before. This particular vulnerability is not one that can be

mitigated because it is an issue with the OS. As far as I can tell, there is no way to disable the

command history in Windows.

Figure 16 (Buffer Overflow Opportunity)


The other vulnerability I discovered was the potential for a buffer overflow. This occurs

in the loop in Figure 10 that prints the text to the command prompt and monitors for “Enter”

keystrokes. As seen in Figure 16, after the “Enter” key is presses, a buffer is created to capture

the input. This buffer is 1023 bytes and there is no mechanism to check if the user entered more

than what the buffer can hold. As a result, I was able to break the loop without crashing the

program and no more commands can be entered without restarting. If this program were in use,

an attacker could issue the “Controller Off” command and break the loop with catastrophic

effect. With the Controller off, the pumps cannot turn on to reduce the temperature and it

skyrockets as seen in Figure 17. This is a rather crude way to use the exploit and I am aware that

it can be used for remote code execution. However, I do not have the expertise to exploit it

myself.

Figure 17 (Overflow Result: Overheating)

Date post:	22-Jan-2017
Category:	Documents
Upload:	zachary-adams
View:	179 times
Download:	0 times

Malware Final Report

Documents