Sunday, January 1, 2017

Format String Vulnerability – Information Leakage

Format string vulnerability is one of those bugs which you may not even recognize that you are actually introducing a vulnerability by doing things “the easy way”. While I’m not a programmer by profession, I have made the mistake in code I’ve developed. Realistically compiling and running the program in most cases works just as well as if you were to do it the “correct way”.

While this post focuses on information leakage as a result of format string vulnerability and the other on overwriting memory, there are more that could be done to a program such as crashing a program.

Now that we’ve compiled the code, let’s run it.Figure 2: Code run and user input echoed.

Looking at figure 2, we see that when the word “SecurityNik” was entered this was echoed back to the user. So far so good, no harm done. However, what about if we were to enter “%s %s” as the input, what would happen? Let’s find out.Figure 3: Information leaked

What just happen there?Well what we did was to print the next two values on the stack. These values being 2 strings. “printf” expected its arguments to be represented via one or more format specifiers. As a result when we used “%s %s” specifiers the next two values on the stack were picked up. Look at it this way, if we had “%s” as in only one “%s”, we would have printed the next value on the stack.

Looking deeperTo get a better understanding of this let’s take a look at what the stack looks like at the time we called “printf”. Similar to the buffer overflow post, let’s load our code in GDB using “gdb ./fmtstr_info_leak.exe -q”. Once we “list” our code, let’s set a breakpoint at line 21.Figure 4: Code listing in GDB with breakpoint set at line 21.

Once we have our code listing and breakpoint set. Let’s go ahead and “run “%s%s” the program, take a step (“s) and take a look at the stack. Figure 5: Stack printed

Ok so what do we have above? Let’s break this down.1 – First up run our code with two format specifiers %s%s 2 – We then stepped once through the program3 – When we examined 8 hex words (x/8xw) on the stack from the perspective of the $esp register, we see those 8 hex words are printed. For the purpose of this post, the only ones that matter are the first 3 which are selected.

Let’s now analyze this.4 – In 4, we examined 1 string (x/1s) at memory location ‘0xffffd22d’. Note this value is the same as the first item highlighted in 3. What we see here is our “%s%s”. These are the format specifiers we provided to “printf”. This now means it will pickup the next two strings on the stack.5 – Here we pickup the next value on the stack which is at memory location “0x08048507”. When we examine that memory location – x/1s 0x08048507 - the value here points to our string “ Guess who's back again? \n”6 – Similarly, when we examine the memory location at “0x080484e0” – x/1s 0x080484e0, we see our next string.

So as we stated, “printf” expects to have format specifiers. Thus when we provided our two %s%s “printf” picked up the next values from the stack and presented it to us.

Alternatively, we could have printed the stack in hex using “./fmtstr_info_leak.exe "%x %x %x %x"”. This would have produced “8048507 80484e0 0 f7e1caf3”

Defenses – Protecting yourself from this vulnerabilityNow believe it or not, fixing this vulnerability is quite easy. Way too easy!! Our code above has “printf(argv[1])”. All we need to do to fix this is “printf("%s", argv[1])”. This would immediately invalidate any attempt to take advantage of this vulnerability.

Your turn! Fix the code and run it again. Post your output in the comments section after you run “./fmtstr_info_leak.exe %s%s” or “./fmtstr_info_leak.exe %x%x%x%x”.

Below is a list of threat intelligence websites that you can use. Cymon.io is an excellent one as it searches around 200 different sources. If you’re looking for a more exhaustive list of threat intel sites, check out https://github.com/rshipp/awesome-malware-analysis