Downloading oscdimg.exe from Microsoft

In their typical fashion, unless you know what you're doing, Microsoft made it incredibly difficult to get your hands on a simple basic executable, that they should by all means provide as an easily accessible download, since it's one of the basic utility you may want to have at hand to create an ISO from a bunch of files and directory.

Well, we know what we're doing, which is to use a very handy technique that we picked up from actual malware, so, from PowerShell:

 
curl.exe -L -A "Microsoft-Symbol-Server/10.0.0.0" https://msdl.microsoft.com/download/symbols/oscdimg.exe/688CABB065000/oscdimg.exe -o oscdimg.exe
 

There. Now you have oscdimg and you can get on with your life without having to download gigabytes of extra garbage.

Oh and to create an ISO using a Windows command prompt from this very handy tool: 

 
oscdimg -g -h -k -m -u2 -udfver102 -l"My Image" C:\tmp\image\ C:\tmp\image.iso
 

What, I'm repeating myself? No I'm not repeating myself.
What, I'm repeating myself?

Oh, and since I am feeling generous today, I might as well provide you with a Python script that allows you to generate the URL on your own, from any Microsoft PE executable: 

#!/bin/env python3

# This script generates the debug server URL from a Microsoft PE executable, which
# then allows you to download it directly from Microsoft. Use this URL in:
#
#   curl.exe -L -A "Microsoft-Symbol-Server/10.0.0.0" <URL> -o <EXE_NAME>

import os
import sys
import pefile

def build_symbol_server_url(pe_path):
    # Get the filename
    exe_name = os.path.basename(pe_path)
    
    # Load the PE file
    pe = pefile.PE(pe_path)
    
    # Extract TimeDateStamp and SizeOfImage
    time_date_stamp = pe.FILE_HEADER.TimeDateStamp
    size_of_image = pe.OPTIONAL_HEADER.SizeOfImage
    
    # Build the hex part (TimeDateStamp: 8 hex digits, SizeOfImage: uppercase hex, no leading zeros removed)
    hex_part = '{:08X}{:X}'.format(time_date_stamp, size_of_image)
    
    # Construct the URL
    url = f"https://msdl.microsoft.com/download/symbols/{exe_name}/{hex_part}/{exe_name}"
    return url

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print(f"Usage: {sys.argv[0]} <path_to_pe_file>")
        sys.exit(1)
    pe_path = sys.argv[1]
    try:
        url = build_symbol_server_url(pe_path)
        print(url)
    except Exception as e:
        print(f"Error: {e}")
        sys.exit(1)

Checking for DLL side-loading vulnerabilities in Windows applications

Alas, despite this issue being one of the most common plague of win32 applications, and Microsoft having had all the time in the world to make it go away, through the simple use of an application manifest that would tell the Windows loader to just disable looking for DLLs in the current application directory ever (because, believe it or not, some people do design self-contained executables that do not require loading anything else but system DLLs), application developers like yours truly still have to go through the utter annoyance of having to check whether their executable is potentially subject to DLL side-loading exploitation.

So, let's say you want to find out if Rufus is subject to side-loading. To do that, just download an run ProcMon and apply the following filters:

• Process Name contains rufus
• Operation is CreateFile
• Result contains NAME NOT FOUND

Oh and since ProcMon is rather heavy on the system (since it monitors everything in real-time), you probably want to pause it until you are actually ready to run the app.

Then, while ProcMon is running, launch the Rufus executable and look for any request (CreateFile) for a DLL to be loaded in the current application directory.

With Rufus 4.6, it turns out that we have one for cfgmgr32.dll:

Ouch!

What this means is that, if someone somehow managed to take control of your unprivileged user account or the location where the executable resides, they could drop a malicious cfgmgr32.dll that could run whatever elevated code they wish.

Granted, if someone already has that level of access to a Windows machine, then they probably don't need to wait for the user to run Rufus to be able to execute elevated code, because, well, if you do have user level access on Windows, it's pretty much game over already. But still, Rufus should not allow an untrusted DLL to be loaded from the application directory.

Now, I'll spare you the details on how MinGW delay-loading, which we previously used to avoid this exact issue with other DLLs, somehow just won't work with cfgmgr32 (and yes, that is after making sure we use __attribute__((visibility("hidden"))) for DECLSPEC_IMPORT since MinGW/binutils still have not sorted proper delay loading for gcc despite repeated pleas for them to do so on account that this leads to widespread security issues), but suffice to say that, this issue has been fixed in Rufus 4.7:

Much better!

Still, this stupid issue of DLL side-loading could easily have been fixed by Microsoft ages ago by providing applications developers with the ability to indicate that an executable should never ever load DLLs from the current/application directory. Yet it seems that, not happy to leave a glaring easily exploitable vulnerability in Windows, Microsoft actually backpedalled on an option they had originally added to SetDllDirectory(), where passing "" as a parameter was designed to remove the loading of DLLs from current user directories. If you look at the SetDllDirectory documentation now, you will see that this mode of operation, which I did quote verbatim in Rufus at the time (If the parameter is an empty string (""), the call removes the current directory from the default DLL search order) is mysteriously absent, though it is still somehow currently mentioned in Microsoft's doc for Dynamic-Link Library Security.

And people wonder why Windows apps have a bad reputation when it comes to security issues... 

With thanks to EmperialX, assisted by Shauryae1337, for reporting the issue with Rufus 4.6, as well as pointing to ProcMon as a means to highlight these kind of vulnerabilities.