rdellimmagine, any idea on an eta for CVE-2019-0708?
This is part of our Patch Tuesday, May 2019 effort. So normally work would be under way already.
Awesome. So probably tomorrow?
I can see that QID 91529 covers the May patch release. I do have a couple of questions on this however.
CVE-2019-0708 only affects a subset of (older) O/Ss, whereas the May release as a whole applies to all. I could write a tag to look for a combination of 91529 alongside impacted O/Ss only, but that's more complicated and will be prone to errors. Also its notable that there are XP and 2003 patches, which are specific to this CVE and not part of the monthly release, so presumably not covered by this QID?
Ideally I think it would be good to see a specific QID for this CVE, given its potential impact and coverage.
I've not had a chance to see what its detecting so I guess we'll know more as we see data flowing in.
On a very high priority patch like this I would imagine, a unique QID for it alone would be preferable that touches only it and its OS's that are affected.
Completely agree John - I’m going to submit a request to that effect, as right now 91529 gives false positives and false negatives, that would be easy to eliminate with a dedicated QID.
I suggest others do likewise...
I am with you.
I put a new Support Case in laying out the issue, and am bringing my Technical Rep into it as well.
We are developing a separate QID for this that will be ready tonight. Details will be available when it's published.
Great to hear - many thanks!
Piling on here and also sent a request to my TAM and Support. We are treating this as an emergency here and need a separate QID to focus on just impacted systems. Yes, we could filter by impacted OS and/or Results data but that isn't very efficient especially when we are running an incident like this and answers are needed ASAP.
rdellimmagine Can you help us out here?
The response I received from support showed some confusion on their part - they don’t seem to be aware that this vulnerability affects 2003 and XP as well - they pointed me to this blog post:
The false negative gaps for 2003 and XP aren’t a huge concern, but the false positives covering out of scope O/Ss (Windows 10 etc) are. I’ve now submitted a comment to that post asking them to correct it. I’ve also gone back to support and asked them to escalate my ticket - any days wasted getting an effective QID created is unacceptable.
I’d suggest we share support ticket numbers as it can be useful to draw attention to a broader requirement - mine is 654844.
I've escalated this thread to Jimmy (blog post author) and the vulnerability signatures team, and they are working out a response.
Jimmy has responded to me and updated the blog - that’s a good step but doesn’t get us an effective QID. I have asked if he can help get this escalated, so we’ll see what happens.
Feedback from Jimmy:
”I'm seeing if we can build a new QID just for that CVE so we're not flagging it on Windows 10 and other non-impacted OSes.”
So looks like we’re on the right track now. I’m seeing if we can get the reference for this work so we can get updates through TAMs etc.
I'll also make sure the info gets posted here.
Good to hear.
This is a remote code execution vulnerabilty in RDP and I have to use authenticated discovery to detect the vulnerability with the current version of QID: 91534? A remote discovery option would be much more useful for environments that have vendor supported devices, devices that cannot join the domain, etc. Is there any word on getting a remote discovery detection?
We're working on it. We're evaluating posted "PoCs," and so far they are all fake. We're also working on researching the patch itself to determine if we can build our own PoC, or at least enough for a check. The fix doesn't seem to change how RDP works inherently, so it's not something we can quickly fingerprint with something like a remote version check. Also, it may take a bit to get a remote check that doesn't cause BSODs, once we do have a PoC. Either way, we'll have something as soon as we can get it out.
For now, auth scanning or Agent is the best way to detect. You can also search for openPorts:(port:3389 and protocol:TCP) in AssetView to find assets with RDP.
I see that QID 91534 is flagged with remote discovery in the KB despite the details stating "Discovery Method:Authenticated Only" - where can I track the changes to this QID and detection methodology?
Edit: Also tagging rdellimmagine
I'm forwarding the inconsistency you pointed out to the signatures team.
Here's a thread on tracking QID changes.
Additionally, fjimenez did some leg work for us and created a dashboard you can import and track with so we don;t have to: https://community.qualys.com/docs/DOC-6785-dashboard-toolbox-assetview-qid91534-cve-2019-0708
Appreciate it Felix!
Thank you for publishing the unique QID, this is extremely helpful and the Dashboard is really great!
We post the vuln even if the service is stopped, to be thorough, but you can add "and services:(name:TermService and status:running)" to the AssetView queries to filter those out.
You also might want to look at QID 90788 Microsoft Windows Network Level Authentication Disabled
Wait a second... you're saying that the QID will flag systems as vulnerable even if RDP is disabled? The AssetView trick doesn't help those of us who export the data to a third party system for tracking of vulnerabilities.
100% right and exactly why I opened a case to request the TermService status check. I can understand if simply not running but if explicitly disabled, I'd say that's proper mitigation. Perhaps flip it to Potential if RDP is disabled but the patch is not applied as a compromise?
AssetView is great for those of us deeply involved with VM activities for identifying risks and slicing up data quickly to get to that needle in a stack of needles but when managing a enterprise wide program and automating reports, tickets, etc. there is no time to manually intercept a process purposely built on automation. This includes interactions with other systems that trigger a response so flagging this vulnerability on a mitigated system leads to misdirected resources rather than focusing on truly exposed systems. We need the source (QID) to properly identify the risk as accurately as possible. In this case, I believe it should evaluate the service status.
We have to show the QID if it is vulnerable, despite mitigations in place. The service check was added as part of the detection, and we do allow for filtering out these kinds of mitigated hosts for reports and API. It's "Exclude non-running services" in the report template, and "arf_service_filter" in the API. This can be used in automation to filter those out if your security policy allows for mitigations to equate to remediation.
We are using Splunk for tracking metrics associated with BlueKeep in addition to NLA QIDs (QID=90788 OR QID=105501). These results aren't going to be as "real-time" as AssetView, but this allows us to put more information in a dashboard that is available to more people.
If your third party system allows logic, you might pull in QID=45381 (Status of Remote Desktop/Terminal Service) to show as a mitigation step (you'll have to |rex the status out - see example below) - though tracking remediation should certainly be done by QID=91534.
We are showing Mitigation status (NLA Enabled), Remediation status (QID 91534), Authentication health, Totals by OS, Patch Management status (QID=105334 (SCCM) OR QID=45235 OR QID=45236 (Tanium), thought your org may use different tools), as well as some additional Org-specific metrics - all of which is filterable for the various groups that may need to act on specific things.
Splunk Example for QID=45381:
index=qualys QID=45381| rex max_match=0 "TERMSERVICE\sIS\s(?P<SERVICE_STATUS>[\w]*)\s"| eval RDP_SERVICE_STATUS = case(like(SERVICE_STATUS,"%RUNNING%"), "Running", like(SERVICE_STATUS,"%STOPPED%"), "Stopped")| stats count by RDP_SERVICE_STATUS
Thanks all, looks good
Honest question...where did this name come from?
OK...that is. Too funny
I just had to include it.
Plus, names often help people get resources to patch things. It's hard to get anyone outside of infosec to care about something named CVE-2019-0708, because we're always throwing CVEs at them.
The amazing part is I was joking to people internally, that we (internal security) started a petition to get Qualys to name it so...and you did
just coincidental humor there....
Is Qualys detection logic taking into account the specific vulnerability and the provided protection mechanism of enforcing NLA?
Microsoft also mentions a partial mitigation on affected systems may be to have Network Level Authentication (NLA) enabled for the non-authenticated user part of an attack. However, affected systems would still be vulnerable if an attacker has valid credentials that can be used to successfully authenticate.
Regarding partial mitigation via NLA:
QID=90788 (Microsoft Windows Network Level Authentication Disabled) checks for these registry keys:
HKLM\SYSTEM\CURRENTCONTROLSET\CONTROL\TERMINAL SERVER\WINSTATIONS\EH-TCP EXISTSHKLM\SYSTEM\CURRENTCONTROLSET\CONTROL\TERMINAL SERVER\WINSTATIONS\EH-TCP USERAUTHENTICATION = 2HKLM\SYSTEM\CURRENTCONTROLSET\CONTROL\TERMINAL SERVER\WINSTATIONS\RDP-TCP EXISTSHKLM\SYSTEM\CURRENTCONTROLSET\CONTROL\TERMINAL SERVER\WINSTATIONS\RDP-TCP USERAUTHENTICATION = 0
And appears to fall off if this key is updated:
HKLM\SYSTEM\CURRENTCONTROLSET\CONTROL\TERMINAL SERVER\WINSTATIONS\RDP-TCP USERAUTHENTICATION = 1
However, this setting is one that end users can toggle - and is therefore not a valid mitigation. Rather, targeting the following key would be a better check from an organizational perspective (especially when related to BlueKeep), as it does not permit a user to edit the setting in the UI when deployed via GPO:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services USERAUTHENTICATION=1
In the absence of the Policy Compliance module, we had to push both via GPO so that we could measure the one validated in the QID.
jgrahamrdellimmagine, I wonder if it's possible to have another QID made to track the more permanent of the two solutions (or update the current QID to show the settings for both options)?
rdellimmagine jgraham - I see QID=45379 was created on 5/17 to track the inverse of QID=90788. Thanks for that, but the same question as above applies - can we get something that tracks the more permanent GPO configuration?
Thank you both!
Not sure if this is the right post to put this or not, but just a question about the new QID 91534. Once a new QID is published, how long does it normally take to populate through a subscription? All the way through AV, CA and VM?
The reason I ask is I found this behavior:
The new QID 91534 was published 05-15-2019 at 5:19pm Eastern
The next day, the QID showed up in Asset Search, but not in the AV module
It did not start showing in AV until 9am Eastern on 05-16-2019. The asset amounts kept updating all day yesterday.
There is something similar happening with their new QID=45379 - Microsoft Windows Network Level Authentication Enabled. Published on 5/17, but still not available in Asset View. I've added a mitigation widget to fjimenez's dashboard (posted above: Dashboard Toolbox - AssetView: QID:91534 - CVE-2019-0708), but it still hasn't populated this value - though I can search this QID in VM and see my status.
rdellimmagine can you route houseman's question to the correct SME as Qualys? Understanding the timing to sync across your Platform infrastructure would be great since we are leaning heavily on AV for intelligence during events like this. Thanks!
Thanks Robert. I have concerns that the AV module did not get populated for so long for such an important vulnerability. I really hope that support/engineering can figure out what is going on. I am also glad to hear we are not the only ones that have found this issue.
Could someone confirm if QID 91534 is working right for Windows XP SP3?
My Vulnerability Signature Version is 2.4.610-2 but the vulnerability is not being detected by Qualys VM in a Windows XP SP3 not patched and RDP enabled.
Update: A new scan to the same IP address with same scan profile 1 hour later and the vulnerability is being detected. I'm not sure what happened.
Retrieving data ...