TL;DR: How do you verify the digital signature of a COM interop assembly from VB6?
Full question: I have a legacy VB6 project which needs to call some .net code (these requirements are a must). We think the best way to do this is with COM interop. However we don't want any hackers switching out the COM assembly for a fake one. We think the best way to guard against this is to digitally sign the COM assembly. If this is the best way to go (please say if otherwise), how do I verfiy the digital signature of the COM assembly fromVB6?
I've tried googling but all I get is 3rd party libraries or implementations for verifying specific signing algorithms. Surely there must be a simpler way?
Thanks!
Related
I know I can read the CLSID from a COM class object in the registry from Classes\<CLASSNAME>\CLSID\#.
I suspect on a registered COM interface I can read up the IID from Classes\<CLASSNAME>\IID\# or Classes\CLSID\<CLSID>\IID.
I've read the article COM IDs & Registry keys in a nutshell and this question is still open to me. Unfortunately, I have no test case right now.
The registry was not meant to be a programming resource, registry entries are only there when the COM infrastructure needs them. The CLSID key for example is necessary to help COM find the executable file that implements a server, the programmer has to supply the CLSID guid.
He needs to know the IID as well, passes it to QueryInterface() to obtain the interface pointer. There might be an entry in HKLM\Software\Classes\Interface but it isn't terribly common. The COM infrastructure needs it when an interface needs to be marshaled from one apartment to another, the registry key contains the CLSID of the proxy that helps to get that job done. A quick look with Regedit.exe in that key ought to convince you that it isn't likely to be helpful at all, there is no connection whatsoever with the server itself. Only if you are very lucky might you find a Type library LIBID there.
There are two basic ways that the COM programmer supplies you with CLSID and IID values. The unfriendly way is an .idl or .h file, several Windows components (DirectX, Media Foundation, WASAPI, etc) are like that. Good enough to see the IIDs back.
The friendly way is a type library, a language-independent description of the implemented coclasses and interfaces that just about any compiler knows how to read. Sometimes supplied as separate .tlb or .olb file but usually embedded as a resource in the executable file. Best way to have a look at it is with the Oleview.exe SDK utility. Use File > View Typelib and select the .tlb or .dll file. It decompiles the type library back into IDL, the language that a COM author uses to describe his component. You'll have no trouble finding the IIDs back. Only thing you have to know is the name of the executable file.
Be sure to take advantage of the type library in your compiler, assuming you found one. You can now use friendly names instead of raw GUIDs, get syntax checking on your code and rarely have to do anything dramatic when the version changes and the author properly used new IIDs. Be sure to talk to the author if you can't find one, a small hint can save you an enormous amount of trouble.
This Stackoverflow question asked how to modify the version information in an existing binary (DLL or EXE). The answer was to use Visual Studio. I tried on a 3rd party DLL our PC supplier gave us to read system metrics (such as battery voltage or motherboard temperature). The supplier had neglected to add any version information to the DLL. This proved disturbingly easy to do and the version information when viewing file properties looks absolutely legitimate.
This Superuser question shows how to use a fantastic utility called Autoruns to see what is starting up and running on your computer. One of the high-rated answers suggested being suspicious of DLLs or EXEs where the Publisher was unknown or blank.
Now I ran Autoruns myself and identified a Java DLL not currently loaded into memory. The DLL was loaded into VS and the "Company Name" modified from "Oracle Corporation" to "HonkyTonks". Reloading Autoruns...and lo and behold, the "Publisher" now shows "HonkyTonks"! Holding the mouse over the DLL in Windows Explorer also shows version information with any modification I care to make.
So my questions are:
1) Is the suggestion to look for Company Name/Publisher useful (in terms of security)?
2) This looks to me like a security loophole because many otherwise competent computer users may see "Microsoft Corporation" or similar in the version information and assume the file is legit. Is this a known loophole and if so does it apply to all versions of Windows and possibly other OS? Am I just behind-the-times and one should never trust this information?
3) Can you programmatically detect whether the version information had been modified in this way?
4) Can you lock down the version information in our own binaries so that it cannot be modified so easily by someone else?
Thanks.
In terms of security, the version information is mostly unuseful. It
provides only the basic information about a publisher and as you
mentioned can be easily forged.
Yes, that's why in Microsoft's .Net Framework you can digitally sign assemblies and executables. In this case, even modification of a version information will lead to denying of execution or loading of a signed binary. And the only way to fake the assembly is to steal the private key used to sign this
assembly.
No. It's only possible if you have signed the executable or DLL. But in classic Windows (not MS .Net) it's almost impossible to do. Because you need to store the public part of the key used for verification in secure place. Otherwise, the hacker can replace public key with his own and your verification program will fail to detect the fake.
You can sign the binary and put the digital signature inside of it or a separate file. And validate the signature against the binary before loading it. And you must secure the public key storage.
Assuming you only have access to the final product (i.e. in form of the exe file), how would you go about finding out which libraries/components the developer used to create the application?
In my specific case the question is about an application developed in VC++ using a few third party components and I'm curious which those are.
But I think the question is generally valid, e.g. when it should be proven if a developer is in line with license requirements of a specific library.
So, what you're saying is that if I suspect that a binary is using a certain library, I could try to map the respective function calls and see if I get a result. But there is no shortcut to this and unless I am willing to try out hundreds of mappings or the dev left some information in some strings or other resources, I have little chance of finding this out. Yes?
There is small shortcut, here's what I'd do:
check executable for strings and constants, and try to find out what library is that.
IF used libraries are open-source, compile them on my own and create FLAIR signatures (IDA Pro).
Use generated flair signatures on target executable.
In some situations, that can really work like a charm and can let you distinguish actual code from used libraries.
The IDA Pro Book - Ch 12. Library Recognition Using FLIRT Signatures
I'm in a situation that I need to use AES-256, SHA1,2 and RSA, but these functions need to be loaded from an intrinsic windows dll file (something like cryptoAPI in advapi32.dll, which can be found in C:\Windows\system32).
I've found almost everything I need in advapi32.dll except RSA encryption. So,do you know any other crypto libraries from windows (XP2 should be supported)?
In the worst case, any free external crypto library in dll format is appreciated.
RSA encryption/decryption is supported by the CryptoAPI.
From http://en.wikipedia.org/wiki/Microsoft_CryptoAPI:
[...]It is a set of dynamically linked libraries that provides an abstraction layer which isolates programmers from the code used to encrypt the data.
So, advapi32.dll ≠ CryptoAPI. However, since it is an abstraction of the CryptoAPI functions, linking to that dll should expose whichever functionality you need, algorithm-agnostic.
To answer the question strictly, the CSP library file that handles RSA stuff is rsaenh.dll. However, I'm not sure why you should need to know that necessarily; like #SimonMourier (and I) stated, CryptoAPI handles linking to the appropriate CSP. Calling the appropriate functions from advapi32.dll should allow the use of a variety of algorithms, including RSA.
If you're really that averse to using the built-in Windows stuff then there's always Crypto++. It supports being compiled as a DLL afaik. http://www.cryptopp.com/
Without using .Net or a 3rd party component, I've found no reasonable solution for RSA in windows. So, about .Net, please see klugerama's last comment. About 3rd party component, I've found a great library for VB6 user, which will works in Windows XP without the installation of .NetFramework 2.0+. It's called VBCOrLib :
http://www.kellyethridge.com/vbcorlib/
Alternative solution for C++ users was Crypto++ as suggested by RaptorFactor.
Thanks for all your helps !
How do you call IFileOpenDialog and IFileSaveDialog from VBA?
According to Microsoft, applications written for Windows 7 and later should use IFileOpenDialog/IFileSaveDialog API calls instead of GetOpenFileName/GetSaveFileName (see Using the Common File Dialog). This is especially important for full Library support.
Short answer: it's probably not worth the effort.
Longer answer: the CFD interfaces don't extend IDispatch, which makes them impossible to call via late binding from VBA. That doesn't mean they can't be called from VBA, but it means they require a typelib to describe the "shape" of the IUnknown-based CFD interfaces. Unfortunately, Microsoft doesn't provide the CFD interface definitions in a typelib. You can roll your own typelib by reverse-engineering the header files (or try to find the original IDL in the SDK), but you'd then have to register that typelib on every machine you want to use it on (the tools for which are not shipped on the machine, unlike regsvr32 for COM stuff). Assuming you did all that, you could then reference the typelib from VBA, and conditionally call it on Vista or higher OSes. You could also shim through to a small .NET assembly that would create a System.Windows.Forms.FileDialog-derived type and marshal the results back to VBA- that would be much easier, but still more-or-less require that you register the assembly on every machine (or use C++/CLI or other hacks to export a managed DLL function), and it requires you to take a .NET dependency.
They sure didn't make it easy... :) Good luck!