9

For the purpose of learning about the complexities involved in writing PoC's (and gaining experience in) one could do patch diffing and have real world vulnerable examples to practice on. For now please disregard the idea of making your own vulnerable programs.

For patch diffing I see 3 states an OS can be in, let's take windows 7 as example:

  1. Plain state (no service packs, no patches)
  2. Partially patched (not updated to the latest released patches)
  3. Fully patched

Scenario

  • My vmware/vbox system is in state 3 (fully patched).
  • Next I go to the Microsoft Security Bulletin and pick a vulnerability (e.g. kernel).
  • Now I want to revert to a useful state...

Although it will likely work on the plain state(1), the diff results will be bigger/harder to spot the issue. Secondly, the bug to the latest vulnerability could have been introduced by a previous patch/service pack.

Therefore, how does one go from OS state 3 to state 2, where state 2 is a system patched up to just before the new patch that resolves the issue? Or if more convenient, from state 1 to state 2.

update

I realize my question isn't as clear as I thought it was in my head, hopefully this clarifies a bit

I'm aware of the snapshot features of vmware/vbox but that is not what I'm looking for. What I'm actually aiming for is

  1. How to get the old versions of the changed binaries?
  2. How to know to which version to revert? Is there some naming scheme in the files?

Example:

  • My system is fully up to date.
  • I find a KB-XXXXX at the Security bulletin, extract it and it gives me an updated .dll named abc_005.dll
  • Now I want to put my system in a state that I get the previous (vulnerable) version of the dll (e.g. abc_004.dll). <- How would I do this part?
  • If they are spreading Patches to unknown vulnerabilities over time, or bundle them up with other fixes, you will not catch them as easily. – Michael Anderson Mar 22 '13 at 12:07
3

I think there's a couple of approaches to get where you want. Given your scenario where you have the KB patch on your fully updated system. To get back to the previous version, uninstall that patch.

The Metasploit Unleashed class used (still does?) has this command for XP that uninstalls all the patches:

C:\>dir /a /b c:\windows\$ntuninstallkb* > kbs.txt && for /f %i in (kbs.txt) do cd c:\windows\%i\spuninst && spuninst.exe /passive /norestart && ping -n 15 localhost > nul

Another approach that I think gets you to the same, if not better, state is to install a completely unpatched version of the operating system (e.g. from a MSDN install with no service packs). From here, you can extract the base files. For the patched versions, MSFT provides an ISO every month with the patches. You can extract the patched executables from here. For example, here's the ISO from this month of security updates.

  • 1
    The first approach is useable forwards in time, but the last one is the killer answer! I checked and I can get these ISO's back to at least late 2009 (release date of win7) which is more then enough for my purposes – ixje Mar 25 '13 at 7:03
  • Sweet, I'm glad it helps. :) – mrduclaw Mar 25 '13 at 19:11
3

VMWare offers a very useful snapshot functionality which makes it extremely simple to switch beween different states of the same VM. You can automate the process with VIX.
I assume other VM solutions have something similar as well.

3

I'm not 100% sure I understand your question but I'll try to answer it.

First I would prepare VMs for the Windows versions you want to target. Every day you could create a snapshot which means that you can go back to that point in time at any future date. Snapshotting is something most VMs support. Then I would run Windows update on the VMs. This means that you will build a large catalog of versions of Microsoft DLLs over time. You could also pull the binaries and their PDBs from Microsoft Symbol servers but this requires knowing their hashes as far as I know.

Now you would follow the Microsoft Security Bulletins. Select the product you're interested in and select the most recent patches only. Study the security bulletin article. If a security bulletin is found to be interesting you'd go to the knowledge base article linked from the security bulletin. There you can study what files were patched. If it's still something you're interested in you'd download the patch from the security bulletin page.

Once you have the patch file need to extract using one of the following commands:

.exe

setup.exe /t:C:[dest_dir] /c

.msu

expand -F:* [update_filename.msu] C:[tmp_dest_dir]

cd [tmp_dest_dir]

expand -F:* [extracted_update_filename.cab] C:[final_dest_dir]

.msp

msix [update_filename.msp] /out C:[dest_dir]

.msi

msiexec /a [update_filename.msi] /qb TARGETDIR=C:[target_dir]

In the extracted folder you should find the files indicated in the knowledge base article. If you've been following the proper snapshot policy you should have an older version available in the snapshot created this morning. Pull that version out of the virtual machine and use BinDiff in order to explore the differences.

  • I realize my question isn't as clear as I thought it was in my head.<br> I'm am aware of the snapshot features of vmware/vbox but that is not what I'm looking for.<br> What I'm actually aiming for is 1) How to get the old verions of the changed binaries 2) How to know to which version to revert.<br> Your approach of daily snapshots works only forward in time, because as far as I can recall the moment we run windows update on a unpatched windows installation it will get all the latest versions and not the intermediate updates. Any ideas how to approach this going backwards in time? – ixje Mar 21 '13 at 15:28
  • Ah so you want to find binaries from before you started collecting them? Microsoft hosts all of them (not just the current one) on their symbol servers I believe. The problem is you need the MD5 hash of the version you want if I remember correctly. Igor probably knows how it works in detail as he works on IDA which I believe has symbol integration. – Peter Andersson Mar 21 '13 at 15:35
  • exactly! And then a way to revert back to those reliably (in case they have dependencies on other also older files) – ixje Mar 21 '13 at 16:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.