The CVE's They are A-Changing!

    Published: 2024-04-17
    Last Updated: 2024-04-18 01:42:11 UTC
    by Rob VandenBrink (Version: 1)
    0 comment(s)

    The downloadable format of CVE's from Miter will be changing in June 2024, so if you are using CVE downloads to populate your scanner, SIEM or to feed a SOC process, now would be a good time to look at that.  If you are a vendor and use these downloads to populate your own feeds or product database, if you're not using the new format already you might be behind the eight ball!

    The old format (CVE JSON 4.0) is being replaced by CVE JSON 5.0, full details can be found here:
    https://www.cve.org/Media/News/item/blog/2023/03/29/CVE-Downloads-in-JSON-5-Format

    You can play with the actual files here: https://github.com/CVEProject/cvelistV5

    ===============
    Rob VandenBrink
    rob@coherentsecurity.com

    Keywords: CVE JSON
    0 comment(s)

    A Vuln is a Vuln, unless the CVE for it is after Feb 12, 2024

    Published: 2024-04-17
    Last Updated: 2024-04-18 01:40:59 UTC
    by Rob VandenBrink (Version: 1)
    0 comment(s)

    The NVD (National Vulnerability Database) announcement page (https://nvd.nist.gov/general/news/nvd-program-transition-announcement) indicates a growing backlog of vulnerabilities that are causing delays in their process.

    CVE's are issued by CNA's (CVE Numbering Authorities), and the "one version of the truth" for CVE's is at Mitre.org (the V5 list is here https://github.com/CVEProject/cvelistV5).  There are roughly 100 (and growing) CNA's that have blocks of numbers and can issue CVEs on their own recognizance, along with MITRE who is the "root CNA".  The CVE process seems to be alive and well (thanks for that MITRE!)

    In the past NVD typically researched each CVE as it came in, and the CVE would become a posted vulnerability, enriched with additional fields and information (ie metadata), within hours(ish).  This additional metadata makes for a MUCH more useful reference - the vuln now contains the original CVE, vendor links, possibly mitigations and workarounds, links to other references (CWE's for instance), sometimes PoC's.  The vulnerability entry also contains the CPE information, which makes for a great index if you use this data in a scanner, IPS or SIEM (or anything else for that matter).  For instance, compare the recent Palo Alto issue's CVE and NVD entries:

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3400

    https://nvd.nist.gov/vuln/detail/CVE-2024-3400

    This enrichment process has slowed significantly starting on Feb 12 - depending on the CVE this process may be effectively stopped entirely.  This means that if your scanner, SIEM or SOC process needs that additional metadata, a good chunk of the last 2 months worth of vulnerabilities essentially have not yet happened as far as the metadata goes.  You can see how this is a problem for lots of vendors that produce scanners, firewalls, Intrustion Prevention Systems and SIEMs - along with all of their customers (which is essentially all of us).

    Feb 12 coincidentally is just ahead of the new FedRAMP requirements (Rev 5) being released https://www.fedramp.gov/blog/2023-05-30-rev-5-baselines-have-been-approved-and-released/.  Does this match up mean that NIST perhaps had some advance notice, and they maybe have outsourcers that don't (yet) meet these FedRAMP requirements?  Or is NIST itself not yet in compliance with those regulations? The timing doesn't match for dev's running behind on the CVE Format change - that's not until June.  Lots of maybes, but nobody seems to know for sure what's going on here and why - if you have real information on this, please post in our comment form!  Enquiring minds (really) need to know!

    ===============
    Rob VandenBrink
    rob@coherentsecurity.com

    Keywords: CVE NVD
    0 comment(s)

    Malicious PDF File Used As Delivery Mechanism

    Published: 2024-04-17
    Last Updated: 2024-04-17 05:36:51 UTC
    by Xavier Mertens (Version: 1)
    0 comment(s)

    Billions of PDF files are exchanged daily and many people trust them because they think the file is "read-only" and contains just "a bunch of data". In the past, badly crafted PDF files could trigger nasty vulnerabilities in PDF viewers. All of them were affected at least once, especially Acrobat or FoxIt readers. A PDF file can also be pretty "dynamic" and embed JavaScript scripts, auto-open action to trigger the execution of a script (for example PowerShell on Windows, etc), or any other type of embedded data.

    Today it's slightly different: Most PDF files can be rendered and displayed directly by the operating system or in the web browser. Most dynamic features in PDF files do not work out of the box. Attackers had to find another way to use these trusted documents. The PDF file format is complex and supports many features. One of them is the "Annot" keyword which helps to link an object to a URL by defining a "clickable" zone. Here is an example:

    obj 19 0
     Type: /Annot
     Referencing: 
      <<
        /F 4
        /Subtype /Link
        /A
          <<
            /S /URI
            /Type /Action
            /URI (hxxps://firstviewautoservice[.]com//men/Prefer Quotation.zip)
          >>
        /Type /Annot
        /StructParent 100000
        /Border [0 0 0]
        /Rect [228.0958 225.9112 366.9041 265.6779]
      >>
    

    PDF files are based on "objects" used and objects are linked together to render the document. How to interpret this piece of code? A clickable zone ("/Rect") is defined and an annotation is created ("/Annot") to link the rectangle to a URI ("/SubType Link"). If the victim clicks on the rectangle, the application rendering the PDF file will open the default browser and visit the provided URL. That's what the user sees:

    The defined rectangle (the clickable zone) is created on top of the "PREVIEW FILE" button. Guess what will happen?

    The link will download a ZIP archive that contains a sample of AgentTesla communication through a C2 on Telegram:

    {
        "c2": [
            "hxxps://api[.]telegram[.]org/bot6455833672:AAEFwznYRFbwog3UBqp13FPbH7YVb236SRI/"
        ],
        "rule": "AgentTeslaV5",
        "family": "agenttesla"
    }

    I wrote a quick and dirty YARA rule to detect such types of PDF documents:

    rule PDF_with_annot {
        meta:
            description = "Detects the presence of a URL linked to a clickable object in a PDF"
            author = "Xavier Mertens"
        strings:
            $page = "/Type /Page\n"
            $annot= "/Type /Annot"
            $link = "/Subtype /Link"
            $action = "/Type /Action"
            $uri = "/URI ("
            $rect = "/Rect ["
            $pdf  = "%PDF-"
        condition:
            $pdf at 0 and #page == 1 and #annot < 3 and #link < 3 and $action and $uri and $rect
    }
    

    Malicious documents with an annotation remain simple and contain usually just one page with a limited amount of annotations (<3). The sample that I spotted has a low VT score (6/60 (SHA256:87455c255848e08c1e95370d6744c196a9d6ba793353312d929e43a4e2c006ea).

    Conclusion: a PDF file with a bit of social engineering remains a nice way to deliver malicious content to a user.

    [1] https://www.virustotal.com/gui/file/87455c255848e08c1e95370d6744c196a9d6ba793353312d929e43a4e2c006ea

    Xavier Mertens (@xme)
    Xameco
    Senior ISC Handler - Freelance Cyber Security Consultant
    PGP Key

    0 comment(s)
    ISC Stormcast For Wednesday, April 17th, 2024 https://isc.sans.edu/podcastdetail/8942

      Comments


      Diary Archives