Log in to create and rate content, and to follow, bookmark, and share content with other members. Not a member? Join Now!

AnsweredAssumed Answered

.NET Framework Service Packs - All of a Sudden

Question asked by Charles Hill on Jun 1, 2018
Latest reply on Jan 6, 2020 by Chalky_White

Like • Show 3 Likes3
Comment • 31

All of a sudden, in VM, I'm getting reports that .NET Framework 3.0 Service Pack 1 and .NET Framework 2.0 Service Pack 1 are not installed on all of my workstations (Agent-based reporting). Those are QIDs 90561 and 90559. The problem is, we have SP 2 confirmed as installed on everything, and Qualys knows it.

RESULTS: HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727 SP = 2

RESULTS: HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.0 SP = 2

Nothing has changed in older .NET configuration on my end since...forever. Is anyone else seeing this, and why is the QID looking for what I assume to be eq 1 as opposed to gte 1.

Charles

DMFezzaReed

Jun 25, 2018 6:12 PM

Correct Answer

This post has branched out to include a several QIDs now, it started with two (2) and now includes five (5): 90559, 90560, 90561, 91263, 91449.

Are 90559 and 90560 were updated 06/24/2018. Are they still reporting so prevalently?

The changelog has not yet loaded on all platforms, but the QID detection signature was modified in an effort to minimize false positives.

This vuln was created 05/08/2018 and has not been modified since it was added.

See the reply in context

1 person had this question

Outcomes

31 Replies

DMFezzaReed Jun 1, 2018 11:22 PM
Mark Correct
Correct Answer
Thank you for providing the QIDs. I have reviewed these QIDs in Vulnerability Signature Version:2.4.343-2 and noted that neither detection has been modified recently, and both require authentication for accurate detection.

Have you validated your scan authentication is completing successfully?

1 person found this helpful
Like • Show 0 Likes0
Actions
Shyam Raj Jun 1, 2018 10:48 PM
Mark Correct
Correct Answer
Charles, I concur with the earlier recommendation from Debra. Verify that the scan you performed was authenticated and also verify that auth was successful.

Report > Reports > New > Authentication Report

If auth was successful, Support will have to investigate this. Please open a ticket.

- Shyam
2 people found this helpful
Like • Show 1 Like1
Actions
- Charles Hill @ Shyam Raj on Jun 4, 2018 5:12 AM
  Mark Correct
  Correct Answer
  Authentication is not the issue. As I mentioned in my original post, these are Agent-based results and not from scans. We have not performed scans on workstations since they first had Agents installed, well over a year ago. Detections on these QIDs are new as of about a week or so ago. I've never seen them before in our environment.
  
  The agents are successfully reporting in, and the "Last Reported" timestamp reflect this, with it now showing 4:45 a.m. today with the same results. That result shows Qualys seeing SP 2 is installed, but that doesn't seem to satisfy the test for SP 1.
  
  RESULTS: HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727 SP = 2
  
  I will open a support ticket.
  
  Charles
  2 people found this helpful
  Like • Show 1 Like1
  Actions
Dan A Jun 5, 2018 8:26 AM
Mark Correct
Correct Answer
Charles, we're also seeing this and seeing some other QIDs that seem wrong as well that came up around the same time. Please post up if support is able to help.
2 people found this helpful
Like • Show 0 Likes0
Actions
brett.vonreyn Jun 5, 2018 12:12 PM
Mark Correct
Correct Answer
Hi all,

We have noticed the same situation and opened a support case (will post response if I get one before this thread is resolved).

I found that these .NET SP vulns started popping up after we patched for QID 91449 Microsoft .NET Framework Security Update May 2018.
2 people found this helpful
Like • Show 0 Likes0
Actions
- brett.vonreyn @ brett.vonreyn on Jun 14, 2018 6:39 AM
  Mark Correct
  Correct Answer
  Hi all,
  
  I received a response from support indicating the .NET SP vulns that popped up after applying the .NET May patch are indeed false positives - response posted below:
  
  Hello Brett,
  
  I am (support rep) from Qualys Support and I was going through this case. I see that QIDs 90559, 90560, 90561 are getting flagged on the agents even though higher patches are already installed.
  
  This is a genuine Agent FP and our teams are already working on this issue.
  I will let you know once we have a confirmation on the fix version.
  
  I will continue to post any updates I receive here - thanks!
  2 people found this helpful
  Like • Show 0 Likes0
  Actions
Antoin Currie Jun 8, 2018 6:35 AM
Mark Correct
Correct Answer
I too have the same issue. with these QIDs popping up for every machine. Despite not even having .net 2.0 or 3.0 installed on any of them! How can I install a service pack for software I don't even have? Obviously it's a false positive.
I have a sneaky suspicion this is causing other QIDs to pop up as well as a result.
Such as 91263.
91263 - Microsoft Graphics Component Remote Code Execution Vulnerabilities (MS16-097) now on all my machines, when I try to install the relevant patches as per Qualys' advice, I'm told by my server that 'the update is not applicable'. Anyone else get this too? There are also no results available to any of the instances that apparently have the vulnerability...
1 person found this helpful
Like • Show 2 Likes2
Actions
- brett.vonreyn @ Antoin Currie on Jun 8, 2018 6:42 AM
  Mark Correct
  Correct Answer
  Hi Antoin,
  
  I noticed the presence of MS16-097 as well. The same not applicable situation and nothing detected in the results field - I've got a case open regarding it and will post the result once I have a response.
  1 person found this helpful
  Like • Show 2 Likes2
  Actions
- Dan A @ Antoin Currie on Jun 8, 2018 7:44 AM
  Mark Correct
  Correct Answer
  We're seeing QID 91263 (MS16-097) too, I opened a ticket and this is their response:
  
  Hi Daniel,
  
  Thank you for sharing the Scan Reports.
  
  We have already notified our internal engineering team on this as there are multiple customers who reported the similar incident.
  I'll get back to you with an update shortly.
  
  Thank you,
  Mangesh Patange
  Technical Support Engineer
  Qualys, Inc. | Continuous Security | www.qualys.com
  
  1 person found this helpful
  Like • Show 2 Likes2
  Actions
Robert Dell'Immagine Jun 8, 2018 3:03 PM
Mark Correct
Correct Answer
I also pinged Support & Engineering on this thread.
1 person found this helpful
Like • Show 2 Likes2
Actions
- William Tulaba @ Robert Dell'Immagine on Jun 25, 2018 7:49 AM
  Mark Correct
  Correct Answer
  Was a response from Support ever given? I am seeing 91263 pop up on systems that are up to date.
  Like • Show 1 Like1
  Actions
DMFezzaReed Jun 25, 2018 6:12 PM
Unmark Correct
Correct Answer
This post has branched out to include a several QIDs now, it started with two (2) and now includes five (5): 90559, 90560, 90561, 91263, 91449.

Are 90559 and 90560 were updated 06/24/2018. Are they still reporting so prevalently?

The changelog has not yet loaded on all platforms, but the QID detection signature was modified in an effort to minimize false positives.

The changelog has not yet loaded on all platforms, but the QID detection signature was modified in an effort to minimize false positives.

This vuln was created 05/08/2018 and has not been modified since it was added.
1 person found this helpful
Like • Show 0 Likes0
Actions
- DMFezzaReed @ DMFezzaReed on Jul 13, 2018 11:00 PM
  Mark Correct
  Correct Answer
  For those of you concerned about these QIDs reporting within your environment, I recommend proceeding with a targeted rescan of Q90559 and Q90560, on only those assets that were previously reporting. To create a concise scan list of assets currently reporting the previously noted QIDs:
  
  Via AssetView, use query: vulnerabilities.vulnerability:((qid:90559 or qid:90560) and (not status: fixed)) and vulnerabilities.lastFound < now
  
  Via Asset Search, and you can create and create a new tag or asset group or launch your scan using a custom search list:
  
  Also, if you are participating in the Dashboard Toolbox - New Vulnerability Management (VM) Dashboard BETA , I have attached a zip file containing a dashboard focusing on these specific QIDs and their status:
  
  dashboard_toolbox
  dashboard_ideation
  vmdb_beta
  Attachments
  - 90559-90561_91263_91449-NEW,ACTIVE,REOPEN_NOW_dashboard.7z.zip4.2 KB
  1 person found this helpful
  Like • Show 0 Likes0
  Actions
- brett.vonreyn @ DMFezzaReed on Jun 26, 2018 4:40 AM
  Mark Correct
  Correct Answer
  I confirmed that I still have a large presence of QIDs 90559, 90560, 90561, 91263 on agent tracked hosts - most of which have last detected / check-in dates of early this morning (6/26).
  
  Thanks,
  -Brett
  3 people found this helpful
  Like • Show 1 Like1
  Actions
  - DMFezzaReed @ brett.vonreyn on Jun 26, 2018 11:33 AM
    Mark Correct
    Correct Answer
    Have you confirmed these are all false positives?
    Like • Show 0 Likes0
    Actions
    - brett.vonreyn @ DMFezzaReed on Jun 26, 2018 11:46 AM
      Mark Correct
      Correct Answer
      My host counts on these QIDs have started to drop slowly just since this morning - I will continue to monitor as agents check-in again and update.
      1 person found this helpful
      Like • Show 0 Likes0
      Actions
      - DMFezzaReed @ brett.vonreyn on Jun 26, 2018 12:35 PM
        Mark Correct
        Correct Answer
        Please keep me posted. As I have noted in my response to William below, if the numbers level off, we will want to get false positive evidence collected and submitted, which I can help with.
        Like • Show 0 Likes0
        Actions
        brett.vonreyn @ DMFezzaReed on Jun 27, 2018 4:17 AM
        Mark Correct
        Correct Answer
        My numbers continued to drop overnight to almost nothing this morning. I will keep an eye on them as agents continue to check-in and follow up if I have any stragglers that look like false positives.
        
        Thanks!
        -Brett
        1 person found this helpful
        Like • Show 2 Likes2
        Actions
        DMFezzaReed @ brett.vonreyn on Jun 27, 2018 9:54 AM
        Mark Correct
        Correct Answer
        Thank you for keeping this post updated. I appreciate the extra effort required to do so.
        Like • Show 0 Likes0
        Actions
William Tulaba Jun 26, 2018 6:16 AM
Mark Correct
Correct Answer
I also have agents on these detected systems and all detections are current.

2 people found this helpful
Like • Show 1 Like1
Actions
- DMFezzaReed @ William Tulaba on Jun 26, 2018 11:32 AM
  Mark Correct
  Correct Answer
  90559, 90560, 90561, 91263, 91449
  Have you determined the findings to be false positives?
  Like • Show 0 Likes0
  Actions
  - William Tulaba @ DMFezzaReed on Jun 26, 2018 11:51 AM
    Mark Correct
    Correct Answer
    I have for 91263 especially.
    Brett has stated his counts are going down, so I will keep an eye on them as well.
    1 person found this helpful
    Like • Show 0 Likes0
    Actions
    - DMFezzaReed @ William Tulaba on Jun 26, 2018 12:34 PM
      Mark Correct
      Correct Answer
      If the numbers stop dropping and level off, then would be the time to create a case for your false positive findings. I can assist if you need me.
      Like • Show 0 Likes0
      Actions
      - William Tulaba @ DMFezzaReed on Jun 27, 2018 6:39 AM
        Mark Correct
        Correct Answer
        My detections have dropped to the expected levels now.
        so, no more false positives.
        
        Thank you to everyone that reported in and everyone that helped resolve the issue.
        Wil
        1 person found this helpful
        Like • Show 1 Like1
        Actions
        DMFezzaReed @ William Tulaba on Jun 27, 2018 9:55 AM
        Mark Correct
        Correct Answer
        Thanks for the update. Thanks for making the effort to keep us posted.
        Like • Show 0 Likes0
        Actions
        DMFezzaReed @ DMFezzaReed on Aug 12, 2019 8:41 PM
        Mark Correct
        Correct Answer
        dashboard_vm, vmdashboard_json
        Like • Show 0 Likes0
        Actions
Dan A Jun 26, 2018 6:29 AM
Mark Correct
Correct Answer
I received this update to my ticket regarding QID 91263, I assume they're going to be updating their detection relevance.

Hi Daniel,

I hope you are doing good and really appreciate your patience on this.

The engineering team has identified the fix for this issue , which will be implemented in next release in coming days.
At this moment , there's no action required from your end.

We'll get back to you with next update shortly once the fix is implemented from our end

Thank you,
Mangesh Patange
Technical Support Engineer

3 people found this helpful
Like • Show 2 Likes2
Actions
Chalky_White Dec 2, 2019 6:09 AM
Mark Correct
Correct Answer
FYI, we're seeing instances of QID 91263 for MS16-097 back again this month. Checking fp situation, before raising ticket
Like • Show 0 Likes0
Actions
- DMFezzaReed @ Chalky_White on Dec 4, 2019 4:05 PM
  Mark Correct
  Correct Answer
  Tony,
  How closely are you connected with your windows engineering team? The fact that these older QIDs keep popping up in "waves" suggests the asset deployment may be being performed from an image that requires update. I would reach out to your IT team and check for a business process that is negatively impacting your VM process.
  Like • Show 1 Like1
  Actions
  - Chalky_White @ DMFezzaReed on Dec 6, 2019 4:56 AM
    Mark Correct
    Correct Answer
    Hi Debra, turns out that KB4525243 last month has superseded KB3178034 which is what the QID looks for. I wonder if the later KB has wiped out the expected reg setting?
    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Package_for_KB3178034~31bf3856ad364e35~amd64~~6.3.1.0 is missing
    Thanks!
    Like • Show 1 Like1
    Actions
    - Chalky_White @ Chalky_White on Jan 6, 2020 3:53 AM
      Mark Correct
      Correct Answer
      Greeeat! Now the QID 92163 for Microsoft Graphics Remote Code Exec vulns (MS16-097) is clashing with the later November 2019 Security roll-up, both QIDs are referring to the other as superseding causing a loop which is crashing the reporting mechanism, per ticket 753730 "reports in "Errors" state"
      Workaround is to disable both QIDs 91586 and 91263
      Hopefully the parameter that marks one as superseding another can be reverted quickly.
      Cheers, Tony
      1 person found this helpful
      Like • Show 0 Likes0
      Actions

.NET Framework Service Packs - All of a Sudden

Outcomes

Attachments

Related Content

Recommended Content

Incoming Links