|
|
|
Sean Devenish
Posts: 78
Joined: 2015-11-30
|
Hi team,
We have had penetration testing performed on our add-in with good results, but on of the recommendations that have come back refer to vulnerable COM Objects.
In our case, two COM object registration entries originate from our addin, which error out with 'NAME NOT FOUND'.
HKCU\Software\Classes\Wow6432Node\CLSID\{80E92C65-0F44-465B-82D2-C4B368238E6B}\InprocServer32
HKCU\Software\Classes\Wow6432Node\CLSID\{9FC8E510-A27C-4B3B-B9A3-BF65F00256A8}\InprocServer32
Because these entries do not exist, an attacker can link an arbitrary resource that contains malicious code, and the penetration testers managed to demonstrate this.
Do you know if the requests for these entries originate from anywhere in the ADX codebase or registrator? |
|
|
Posted 11 Sep, 2019 03:07:58
|
|
Top
|
|
|
Sergey Grischenko
Add-in Express team
Posts: 7233
Joined: 2004-07-05
|
Hi Sean,
When the add-in is registered via adxregistrator.exe, it creates some registry entries in HKCU\Software\Classes to register the add-in module for COM Interop. The add-in will not work without the registration in the system registry.
Also, if you have any public classes in your add-in project, they will be registered as well.
I don't see values of the mentioned keys. So, I can't tell you what exactly is being registered. |
|
|
Posted 11 Sep, 2019 05:09:02
|
|
Top
|
|
|
Sean Devenish
Posts: 78
Joined: 2015-11-30
|
Hi Sergey,
thanks for that, the value of the first etnry, 80E92C65-0F44-465B-82D2-C4B368238E6B, is (file paths subbed with ...):
(Default) REG_SZ C:/.../adxloader.OurProject.Addin.dll
Assembly REG_SZ OurProject.Addin
Class REG_SZ OurProject.AddinModule
CodeBase REG_SZ file:///C:/.../OurProject.Addin.dll
RuntimeVersion REG_SZ v4.0.30319
ThreadModel REG_SZ Apartment |
|
|
Posted 11 Sep, 2019 17:51:55
|
|
Top
|
|
|
Sean Devenish
Posts: 78
Joined: 2015-11-30
|
In addition to the missing COM references, the penetration testers have also found that Excel.exe is trying to look for adxloader.dll and unable to find it.
In our case, our adxloaders are called adxloader.OurProject.dll, which I believe is necessary as we have both a COM and XLL addin (the XLL requires the assembly name built in to the dll?).
Can you shed any light on what code might be looking for the non-existent adxloader.dll? Again, the penetration testers were able to sub in a malicious dll and cause problems...
Kind regards,
Sean |
|
|
Posted 11 Sep, 2019 20:33:46
|
|
Top
|
|
|
Sergey Grischenko
Add-in Express team
Posts: 7233
Joined: 2004-07-05
|
Hi Sean,
Please check in the COM Add-Ins dialog if you have other add-ins installed in Excel. |
|
|
Posted 12 Sep, 2019 05:36:29
|
|
Top
|
|
|
Sean Devenish
Posts: 78
Joined: 2015-11-30
|
Hi Sergey,
apologies for the delay in responding, unfortunately, I don't know what other COM Add-ins the penetration testers may have had in their instance of Excel.
Given in this case the references are clearly to adxloader, and in the case of the registry entries, to our specially named loader (adxloader.OurProject.Addin.dll), will this make a difference?
To clarify from the above correspondence, we have two security issues:
1) COM object registrations in the registry that do not exist; and
2) The Excel.exe process looking for an adxloader.dll that doesn't exist
Kind regards,
Sean |
|
|
Posted 20 Sep, 2019 01:09:28
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18817
Joined: 2006-05-11
|
Hello Sean,
Sean Devenish writes:
two COM object registration entries originate from our addin, which error out with 'NAME NOT FOUND'.
Does installing the add-in on a clean machine produce the entries? Does unistalling your add-in removes them? Is it possible that your installer creates these keys explicitly?
Also, I'd like to understand whether the report says that these registry keys are missing or "NAME NOT FOUND" relates to something else?
Sean Devenish writes:
Can you shed any light on what code might be looking for the non-existent adxloader.dll?
This is our code. It looks for a loader file.
Sean Devenish writes:
Because these entries do not exist, an attacker can link an arbitrary resource that contains malicious code, and the penetration testers managed to demonstrate this.
Is your add-in digitally signed?
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 20 Sep, 2019 05:51:58
|
|
Top
|
|
|
Sean Devenish
Posts: 78
Joined: 2015-11-30
|
Hi Andrei,
sorry for the delay in responding. The testers installed the add-in on a clean machine to test the entries. Our installation code is run through innosetup, which you can see simply runs adxregistrator, as follows:
[Files]
Source: *.dll; DestDir: {app}; Flags: ignoreversion recursesubdirs
Source: *.bat; DestDir: {app}; Flags: ignoreversion recursesubdirs
Source: OurProject.Addin.dll.config; DestDir: {app}; Flags: ignoreversion; AfterInstall: UpdateConfig(ExpandConstant('{app}OurProject.Addin.dll.config'))
Source: adxloader.dll.manifest; DestDir: {app}; Flags: ignoreversion; AfterInstall: UpdateManifestPrivileges(ExpandConstant('{app}dxloader.dll.manifest'))
Source: adxloader.OurProject.Addin.dll; DestDir: {app}; Flags: ignoreversion sign;
Source: adxloader64.OurProject.Addin.dll; DestDir: {app}; Flags: ignoreversion sign;
Source: OurProject.Addin.dll; DestDir: {app}; Flags: ignoreversion sign;
Source: adxregistrator.exe; DestDir: {app}; Flags: ignoreversion sign;
[Registry]
Root: HKCU; Subkey: "{code:GetOfficeRegistryLocation}ExcelSecurityTrusted LocationsLocationOurProject"; Flags: uninsdeletekey
Root: HKCU; Subkey: "{code:GetOfficeRegistryLocation}ExcelSecurityTrusted LocationsLocationOurProject"; ValueType: dword; ValueName: "AllowSubFolders"; ValueData: "1"; Flags: uninsdeletekey
Root: HKCU; Subkey: "{code:GetOfficeRegistryLocation}ExcelSecurityTrusted LocationsLocationOurProject"; ValueType: string; ValueName: "Description"; ValueData: "OurProject"; Flags: uninsdeletekey
Root: HKCU; Subkey: "{code:GetOfficeRegistryLocation}ExcelSecurityTrusted LocationsLocationOurProject"; ValueType: string; ValueName: "Path"; ValueData: "{app}"; Flags: uninsdeletekey
[Run]
Filename: "{app}dxregistrator.exe"; Parameters: "/install=""OurProject.Addin.dll"" /privileges={code:InstallPrivileges} /logFileLocation=""{app}"""; Description: "Register the addin with Excel"
[UninstallRun]
Filename: "{app}dxregistrator.exe"; Parameters: "/uninstall=""OurProject.Addin.dll"" /privileges={code:InstallPrivileges}";
And yes we digitally sign the add-in.
Kind regards,
Sean |
|
|
Posted 13 Oct, 2019 23:00:14
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18817
Joined: 2006-05-11
|
Hello Sean,
Sean Devenish writes:
And yes we digitally sign the add-in.
In this case, for an attack to succeed, the attacker should create an adxloader.dll digitally signed by you. I assume this wasn't the case in your testing. Please confirm.
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 14 Oct, 2019 02:01:45
|
|
Top
|
|
Forums
Topics
Search
Help
Login
Register