Dealing with responsible disclosure can be a time-consuming process for both parts, and can especially become a tedious task, if the software vendor in question, either ignores the inquiries or becomes hostile. Occasionally we still see software vendors go on the defense when we contact them about a security vulnerability in their product. They might insist that it’s not worth their time to fix the issue or even threaten with lawsuits, if we release our findings.
Just recently we had such an experience, wherein the software vendor unfortunately chose to first ignore our inquiry, only to attempt to fix the issues we found silently without informing us.
Responsible disclosure isn’t about exposing organizations for making bad or unsecure software. It’s about helping them make better software. When an organization receives a responsible disclosure inquiry about a vulnerability in their software, they have nothing to lose. Many security enthusiasts like myself do it as a hobby, because we find it fun and interesting and a by-product of that, is helping organizations keep their software secure, free of charge. Going on the defence will only make other security enthusiasts less inclined to look for vulnerabilities in that particular company’s software, potentially leaving critical vulnerabilities unnoticed, which could be found and exploited by malicious actors.
To avoid these scenarios, software vendors should have a responsible disclosure policy that states what types of vulnerabilities they would like to be informed about, the format of the inquiry and most importantly how to contact them, should you wish to send a responsible disclosure inquiry.
Responsible disclosure - SmartDraw 2020
CVE registered
CVE: CVE-2020-13386
On May 3rd I discovered that the SmartDraw 2020 software product by SmartDraw, LLC, is installed using weak folder permissions, giving low privileged users inherited write permissions on the installation path of the product. The product is installed under “C:\SmartDraw 2020” and the group “Authenticated Users” has written permissions on the folder, as seen below.
This enables any authenticated user to replace DLLs and executables in the installation path and can be abused in various ways. For example, it would be possible to place a keylogger in the path, masked as one of the already present DLLs or executables, which would run whenever a user starts up the SmartDraw 2020 software. Alternatively, you could replace a DLL or EXE with a specially crafted payload that attempt to create a new local user and add it to the local administrator’s group, effectively giving an attacker local administrative privileges. This would only work if the software is started by a user with administrative permissions on the machine.
This is not the only attack that can be performed though. When installing SmartDraw 2020, two scheduled tasks are created on the machine. The two tasks are named “SDMsgUpdate (Local)” and “SDMsgUpdate (TE)”, as seen below.
Both tasks run in the context of the user who performed the product installation, and both tasks attempt to run the same executable. The task runs once per day and only if the user is logged on.
Both tasks attempt to run “C:\SmartDraw 2020\Messages\SDNotify.exe”, which for some reason does not exist. It might be that the intention was to eventually create an automated update procedure.
Whether the “SDNotify.exe” file exists or not doesn’t matter, since the “Authenticated Users” group has modified permissions in the entire installation path. So, if the file had existed, it would be possible to replace it anyway.
For this attack to become a privilege escalation, the product must have been installed using a privileged account. The product can be installed just fine as a low privileged user, but many products require administrative permissions during the installation, which means that SmartDraw 2020 is probably installed using a privileged account in many organizations.
To perform a privileged action using the scheduled task, it is however necessary to overcome the hurdle of the task executing without the “Run with highest privileges” setting, which the two tasks do. Unfortunately, this is trivial since the web is splattered with User Account Control (UAC) bypasses, and in the example below, I used this UAC bypass.
The goal is to add a low privileged user to the local administrator’s group. The already present low privileged user in this example is “Henry”.
1. Download UAC bypass script and place it anywhere, for example C:\Users\Henry\uac-bypass.ps1
2. Modify UAC bypass script to run the following command:
cmd /c net localgroup administrators henry /add
3, Craft a C# binary that executes the UAC bypass script using the following command:
Powershell.exe -ExecutionPolicy Bypass -file "C:\Users\Henry\uac-bypass.ps1"
4. Place the C# binary under “C:\SmartDraw 2020\Messages” and name it “SDNotify.exe”.
5. Wait for the user who installed the product to log on. If all goes well and one of the scheduled task runs, Henry will be added to the local administrators group as seen below.
The user who installed the product might never log on to the machine, in which case the binary would never run, and privilege escalation would never occur.
Disclosure timeline
May 9th – 10:59 GMT+1 - Improsec contacts SmartDraw, LLC support via e-mail regarding the issue
May 10th – May 14th – No response
May 14th – 10:42 GMT+1 - Improsec contacts SmartDraw, LLC once again via e-mail asking for a response
May 15th – 10:39 GMT+1 - Improsec contacts SmartDraw, LLC via telephone and we are informed that it has been passed on internally, and that they will only reply to us if they are interested
May 15th – May 17th – No response
May 18th – 08:54 GMT+1 - Improsec contacts SmartDraw, LLC once again via e-mail asking for a response
May 18th – 18:57 GMT+1 – SmartDraw, LLC responds via e-mail that it has been passed on internally, and we were told to stop bothering them.
May 26th – 08:00 GMT+1 – Improsec discloses
Issue partially fixed
On May 19th I downloaded the SmartDraw 2020 product again, to check whether SmartDraw, LLC might have fixed the issue without telling us.
To my surprise, the product installation did not create the two scheduled tasks, effectively fixing the potential privilege escalation using this attack path. Installing the product on top of an already vulnerable installation does however not remove the already present scheduled tasks. You would need to first uninstall the product and then install it again using the new version. Furthermore the “Authenticated Users” group still has write-permissions to the product installation path, which maintains the possibility for installing a keylogger or performing privilege escalation, when someone uses the product.
There is no direct indication of the product being patched. The version number has not been incremented as seen below. The left side is the old, vulnerable version, the right is the new patched version. Both show version “27.0.0.0”.
However, when looking at the Digital Signature information, it is apparent that the new version was signed on May 11th, indicating that SmartDraw, LLC fixed the issue just two days after our initial contact.
It is of course great that SmartDraw, LLC partially fixed the issue, but the weak folder permissions are still present, and the way they handled the entire process is quite disappointing to say the least.