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.
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.
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!
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?
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!
Thanks all, looks good
Thank you for publishing the unique QID, this is extremely helpful and the Dashboard is really great!
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.
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.
Honest question...where did this name come from?
Retrieving data ...