CTF Code : Javascript Code to Quickly Process Data on a Webpage

In quite a few Capture the Flag (CTF) exercises, I’ve seen this challenge – a coding one – which asks the participant to process some information on a webpage in less than X seconds, short enough so that no manual processing can be done. One way to do so is using Javascript.

Introduction

In quite a few Capture the Flag (CTF) exercises, I’ve seen this challenge – a coding one – which asks the participant to process some information on a webpage in less than X seconds, short enough so that no manual processing can be done. One way to do so is using Javascript. In one case, the participant is asked to crack a SHA1 encrypted word.

Method

By first doing manually searching for the hash using a search engine, the plaintext will be found and after doing it 2 or 3 times for different hash, a pattern will emerge in the random plaintext. In this case, random integers between 1000 and 9999 are generated. As such, to solve the challenge, one need to hash all integers from 1000 to 9999 and compare it with the one on the page. Once we have a match, we use the plaintext with a provided URL to get the flag. So in summary:

    1. Figure out the plaintext used to generate the hash. Use Google.
    2. Find a pattern in the plaintext, or boundaries [x,y] in the values used.
    3. Extract the SHA1 from the HTML
    4. Generate a SHA1 hash for each possible value in [x,y]
    5. Compare the 2 hashes. If they match, go to the flag retrieval page.

Code Explanation

Below is the code used for the particular CTF. I used Javascript to prevent managing all the cookies and session stuff. I also used CryptoJS for SHA1 encryption.

Then we iterate all integers between 1000 and 9999. For each, we calculate the SHA1 digest using the Crypto.SHA1() function. Once we find a match, we relocate to the flag retrieval URL.

Full Code

Conclusion

This code can be used with GreaseMonkey or simply by using the developers’ tool included in Google Chrome or Mozilla Firefox.

Removing Debugging Information from Visual C++/C# Projects

It’s often surprising how many malware programmers forget to do the simplest things. Mostly because many are so concerned with functionality, stealthiness and other production concerns, that details slip easily of their minds – a clear advantage to forensics. One of these details is the Program DataBase (PDB) information added by Visual Studio, which most malware authors used for Windows development. While it may seem innocuous, this string reveals a lot about the operating system used by the author, its user name and most notably, symbols that can be used by IDA and ease understanding of the disassembly.

Introduction

It’s often surprising how many malware programmers forget to do the simplest things. Mostly because many are so concerned with functionality, stealthiness and other production concerns, that details slip easily of their minds – a clear advantage to forensics. One of these details is the Program DataBase (PDB) information added by Visual Studio, which most malware authors used for Windows development. While it may seem innocuous, this string reveals a lot about the operating system used by the author, its user name and most notably, symbols that can be used by IDA and ease understanding of the disassembly. This information allows to link multiple pieces of malware together, by using the username for example. Of course, this also allows for the creation of signatures. Thus, removing this information will add a hurdle to the analysts.

Contents

The Program Database File

The Program Database (PDB) is a binary file used to store debugging information about DLL and EXE files. The PDB file is created when you build your project and stores a list of symbols  their addresses along with the name of the file and the line number on which the symbol was declared. PDB files is also used for services collecting crash data to send it to developers for resolution.

Debugging Information

In Visual Studio, you can select to build your project in Debug or Release mode. In Debug mode, VS will include debugging information with your executable. In Release mode, no debug information is included by default, but in some cases is enabled so that if the program crashes, information can be retrieved and sent to the author for fixing. However for some reasons, some developers don’t really bother to use the Release mode, and simply use the executable generated by the Debug mode. Generally, you don’t want that if you are making malware (or any program really!). If left within the executable, a path to the PDB file will be included and can be extracted:

Path to the PDB file
Path to the Program Database (PDB) file used by Visual Studio for debugging purposes, extracted using the “strings” program.

Within the strings, you can determine that:

  1. The program was developed on Windows 7+ (because of C:\Users folder),
  2. The username of the developer is SUPPORT_23e45RT
  3. The source, or part of it, can be found on Github
  4. The original name of the program is CaitSithTest

These indicators can be useful to link this specific program with others and provide a common link between multiple malware. Additionally, the username could potentially be used to conduct open source research and find linked accounts or forum posts. But wait, there’s more…

If you leave the debugging information, you may be able to restore all the original names of variables and functions of the source code using IDA. IDA will first detect debugging information and ask the analyst if he wants to retrieve it, either via Microsoft – http://msdl.microsoft.com/download/symbols (not browseable)- or by looking locally.

IDA detected that debugging information is available and ask if the user wishes to retrieve it.
IDA detected that debugging information is available and ask if the user wishes to retrieve it.

If for some reason, the user is able to retrieve the information, he will have access to the names of the original symbols, which will make reverse engineering much more easier.

Since symbol information is available, the original names of the variables are displayed.
Since symbol information is available, the original names of the variables are displayed.

Compare the information from the figure above to the figure below, in which debugging information has been stripped at build time:

IDA could not find any debugging information and thus used its own labelling system to identify variables.
IDA could not find any debugging information and thus used its own labelling system to identify variables.

You can see that the variables defined in the first figure, such as ClipboardData, isProcessElevated and isDebugged have been preserved. By keeping information about the symbols, reverse engineering is much more easier compared to figure 2, in which information about the code is lost.

Disabling Debugging Information

To prevent VC from including this information in your executable, right click on your project, go to Project Properties > Linker > Debugging configuration menu. Select No in the Generate Debug Info option.

Removing debugging information in Visual Studio.
Removing debugging information in Visual Studio.

After doing this, rebuild your project and rerun the string extraction program against your binary, the path to the PDB file should not be present in the executable anymore.

no_debug_info
The path to the PDB file is not included in the executable once debugging information has been omitted.

Doing so makes it a bit more difficult to fingerprint the malware and hides information about the author’s system.

Conclusion

This is a simple tactic that is often omitted not only by malware author, but penetration testers, which are often Google programmers, i.e. copy-pasting code snippets from Stack Overflow or googling functions 😉 If you attempt to hide your malware into the System32 folder, looking for this information in the EXE or DLL files will quickly tell you which files are bad, since legitimate files will rarely have this info, or have legitimate looking one. As such, if you want to make sure, create a legitimate-Microsoft-looking user (Bill.Gates) on your machine and put your code into a Microsoft-looking project and path (C:\users\Bill Gates\Documents\HTA\Release\).

Gears of (Cyber)War – C++ Code to Detect Version of Windows

A common structure in malware, and also in many legitimate software is to recognize what is the underlying operating system (OS). Depending on the version of it, the virus may want to take different route to execute its activities. This functionality can be reused across different programs and is therefore useful to create and optimize. In this post, we design a function to detect the version of the Windows OS on which the program is currently running.

Introduction

A common structure in malware, and also in many legitimate software is to recognize what is the underlying operating system (OS). Depending on the version of it, the virus may want to take different route to execute its activities. This functionality can be reused across different programs and is therefore useful to create and optimize. In this post, we coded a function to detect the version of the Windows OS on which the program is currently running.

Windows Versions

The Windows OS is known to have a confusing version system, which is often the result of marketing pressure. As such, while all software usually follow a version number specifying the major version, the minor version and the revision (and sometimes the build), Windows swings between years of release (ex. Windows 2000), fancy names (Windows Vista) or some designated number (Windows 7). However, in the underlying machinery of Windows are defined standard version numbers, ex. 5.1. Below is the correspondance between Windows operating systems and standard versions.

When programming in C/C++, the version number of Windows can be obtained via the OSVERSIONINFO structure (or OSVERSIONINFOEX) and the GetVersionEx Windows API function:

The version information described in the table above is stored in the dwVersionMajor and dwVersionMinor of the OSVERSIONINFO structure. All version of Windows in the table above will store the value VER_PLATFORM_WIN32_NT (0x2) in the variable dwPlatformId of the structure.

Branching C++ Code Based on Version

Based on the description above, we can create a reusable function to detect the version of the Windows OS:

Note that in many cases, we won’t know if the OS is the workstation version of Windows or the server version of it. Also, there is no details for other versions of Windows, i.e. Windows CE, Windows 95 (…should it still be used somewhere..). That’s where OSVERSIONINFOEX is useful. The wProductType variable will be set to VER_NT_WORKSTATION if the current OS is the workstation version. Furthermore, you can retrieve service packs numbers and edition information with wServicePackMajorwServicePackMinor and wSuiteMask. So if you need more details about the Windows OS, you can include these as well:

For a full version of the procedure, visit this GitHub page, you’ll find the C/C++ code.

Conclusion

Practically any malware at some point will need to check the version of the operating system being infected in order to enable specific functions or exploit certain vulnerability. Rarely will this check go as far as getting the suite, but Remote Access Tool (RAT) and bots will report the operating system, the version and the service pack. If you are a malware analyst, expeect this function to be present in whatever piece of code you’re analyzing.

Starting in Exploit Development – Day 02

Using Kali and Virtual Box Guest Additions

Hopeful that I’ll waste a lot less time than yesterday, I’ve setup a Kali virtual machine. I had one problem while installing: as soon as the actual installation started, I had a “The failing step is ‘Install the System'” error message. This was solved when I created a 15GB Virtual Hard Drive (VHD) rather than a 10GB Virtual Box Drive. I also had to setup Kali so it works with VirtualBox Guest Additions. You’ll first need to update the sources in /etc/apt/sources.list by including the second repositorty(http://http.kali.org);

Once done, update the package lists by running apt-get update and then install the the linux-headers for Kali:

Finally, install the guest additions as described in the Kali FAQ [1]….and realize it doesn’t work. According to the log file, 2 errors occured:

This can be solved by using the latest version of VirtualBox. Once I’ve upgraded to 4.3.8, I was able to compile the Guest additions with no trouble.

The Fun Finally Begins…Exploitin’

Continuing Part 2 of Fuzzy Security exploit tutorial. So now, I can finally use the pattern_create.rb script to find out at which position in the payload I need to put the return address in EIP. In the latest version of Metasploit, pattern_create.rb is in the following directory:

After creating the pattern and putting it in the python script, the EIP registers overflows with value 0x69413269, which correspond to offset 247 of the payload.  So far so good.

Metasploit Pattern in EIP
Metasploit Pattern in EIP
Offset Required to Overwrite EIP
Using Mona.py to find the offset of the Metasploit pattern required to overwrite EIP

Once confirmed, then we need to redirect the program’s execution flow to the ESP, the stack pointer, according to tutorial of Fuzzy Security. Good enough, but why ? Well the ESP always points to the top of the stack, which contains an address. If you look at the screenshot above, you’ll notice that the address contained in ESP, 0x00C7FC2C contains our “C”s, i.e. a value we control as well.

ESP Overwritten with "C"s
ESP Overwritten with “C”s, indicating we can place our shellcode at ESP

So if we replace those “C”s with our shellcode, our objective will be to find a way to jump to the address contained in ESP. To do so, we will find an “jmp esp” instruction in memory, and put the address of the instruction in EIP – the register that contains the address of the next instruction to execute.Use “mona jmp -r esp” to locate the JMP instruction. Once Mona is finished, select View -> Log to see the result.

Pointers to a "jmp esp" instruction
Results of the search for pointers to a “jmp esp” instruction

The results I have differs from the one of the tutorials. Shouldn’t be an issue, so I’ll take the one in “ntdll.dll” (0x7C91FCD8) as it seems to be a stable DLL. In little endian form, it becomes “\xD8\xFC\x91\x7C”. To test if it works, you’ll need a breakpoint at whatever address you are pointing, otherwise the execution flow will just land somewhere in memory. To add a breakpoint, right click in the CPU view, select “Go to” -> “Expression” and in the window, type your address (big endian). After you clicked OK, you should land on your address. Then press F2 to toggle the breakpoint at this location.

Following an address in memory using Immunity Debugger
Right click on the main CPU view, select “Go To”, “Expression” and type the address.

So we have verified it worked, we can now move on. I won’t fray to far from the tutorial and just generate a local shell bind payload on port 13373. To do, we’ll need the following Metasploit tool:

Basically what this command does is generate the shellcode for binding a shell on port 13373. It then encodes it in bytes without using bytes 00, 0A and 0C. “\x00” is a terminator value for strings. If included in the shellcode, it will break the code. The same goes with 0A and 0D, which are the “New Line” and “Carriage Return” values (i.e. chr(10), chr(13)). The “-t py” option specifies that the output will be formatted in Python. I thought I could almost conclude this session, but of course, I had to hit one more hiccup. After running the exploit, the debugger throw an “Illegal Instruction” exception at 0x00C7FC28, where the first byte of the shell code is.

I’ve wonder many minutes about this issue. I’ve decided to just plain follow the tutorial and choose the same port, 9988 and regenerate the shell code. To my astonishment, the new shell code worked! The first byte is different, but I’m still not sure why the new code works while the other don’t. More to follow…

In any case, the exploit worked and opened port 9988 on the target machine, which can be connected with netcat.

[1] “Kali Linux Virtual Box Guest.” Kali Linux Official Documentation. http://docs.kali.org/general-use/kali-linux-virtual-box-guest (accessed March 14, 2014).

Firefox Javascript Vulnerability

Once again, Javascript is the source of a new exploit that has been recently discovered on Firefox1. The vulnerability can be exploited by crafting malicious Javascript code on a Firefox 3.5 browser and leads to the execution of arbitrary code on the user’s machine. This is due to a vulnerability in the JIT engine of Firefox and affects machine running a x86, SPARC or arm architectures.

The vulnerability resolves around the return value of the escape function in the JIT engine. It’s exploited using the <font> tag. The code for the exploit is public and can be found at milw0rm. The exploit use a heap spraying technique to execute the shellcode.

A fix should be available soon, but the best solution is always to disable Javascript, although a lot of sites rely on it to operate. Another way is to use the NoScript plug-in, which let you enable and disable scripts easily according to a whitelist/blacklist system.

See also:

Mozilla Firefox Memory Corruption Vulnerability”, Secunia, July 14, 2009, http://secunia.com/advisories/35798/ accessed on 2009-07-15

Exploit 9137”, SBerry, July 13, 2009, http://milw0rm.com/exploits/9137 accessed on 2009-07-15

Stopgap Fix for Critical Firefox 3.5 Security Hole”, Brian Krebs, The Washington Post, July 14, 2009, http://voices.washingtonpost.com/securityfix/2009/07/stopgap_fix_for_critical_firef.html accessed on 2009-07-15

Critical JavaScript vulnerability in Firefox 3.5”, Mozilla Security Blog, July 14, 2009, http://blog.mozilla.com/security/2009/07/14/critical-javascript-vulnerability-in-firefox-35/ accessed on 2009-07-15


1 “Mozilla Foundation tackles Firefox bug”, Nick Farell, The Inquirer, Wednesday, 15, July, 2009, http://www.theinquirer.net/inquirer/news/1433480/mozilla-foundation-tackles-firefox-bug accessed on 2009-07-15