Hi openvas team，
Have you updated this rule recently, remote check?I want to write according to other people’s, but because of the limited level, I can’t write it with nasl.
Hi openvas team，
a remote/active VT for this specific RDP vulnerability is currently in the works and should arrive in the feed soon.
Haven’t updated yet?
I updated feed on sunday, and find information CVE-2019-0708, but i can’t scan our windows servers and don’t show any vulnerability about CVE-2019-0708 .
I 'm waiting the update. Thanks.
Thanks for your reply.But,where is the information about CVE-2019-0708?
Are you using the community or GSF feed ? It might only come up on the GSF, the GCE does not give you any SLA on timing or availability.
If you look at the SecInfo it´s already part of the GSF:
Last updated: Fri, May 24, 2019 10:29 PM
Sorry, i’ m not openvas team. CVE-2019-0708 can find on Secinfo->CVE and search.
I mean the remote check.
okay,The remote rdp check policy haven’t updated.
Scan Authenticated …
I scanned a few Windows hosts which I know are vulnerable to CVE-2019-0708; however, OpenVAS did not detect it.
I ran greenbone-nvt-sync without issues.
Can you assist?
Openvas detection CVE-2019-0708 method is authorized to scan
How can i check it?Thanks.
As already explained twice the VTs covering that specific CVE currently requires an authenticated scan. See the following documentation on how to configure such an authenticated scan:
An authenticated scan means you own the system you are scanning.
I work for an ISP, and often scan our subscribers’ systems for vulnerabilities, which we do not own or control.
I am able to detect the BlueKeep vulnerability using rdpscan, and also using Nexpose.
I am curious as to why this particular CVE requires an authenticated scan in OpenVAS.
I’m just curious. Why do you scan? As a service for your customers?
That is correct. Occasionally a subscriber will need some insight and we strive to provide that when it’s needed.
Just for the record, a Remote-Check for this CVE is available in the feed since quite some time:
Hi @cfi, it’s seems like this plugin has problem on processing TLS.
I use this plugin to scan a target and the target doesn’t response to the connect_initial_request packet - same as https://github.com/JSec1337/Scanner-CVE-2019-0708 when using with --notls option. But, with no --notls option, the python script detects the vulnerability on the target successfully.
Another case, when a target “Forcing RDP to use TLS Encryption”, it responses “TLS required by server” to the “Negotiate Request”, but this plugin does not processing this.