The CVE's They are A-Changing!
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
(ps the earworm is free!)
===============
Rob VandenBrink
rob@coherentsecurity.com
A Vuln is a Vuln, unless the CVE for it is after Feb 12, 2024
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!
=============== Addition ===============
One of our readers notes that the Feb 12 date corresponds closely to Kernel.org being added as a CNA (https://www.cve.org/Media/News/item/news/2024/02/13/kernel-org-Added-as-CNA), with (at the time) an anticipated floodlike rate of Linux CVEs being expected after that. If that's the case, this may just be NVD saying "stand by while we hire some new folks and get them plugged into our process", or it could also be "stand by while we negotiate with this new CNA about what constitutes a CVE".
If this pause is related to that CNA onboarding, hopefully we won't be standing by too much longer ...
===============
Rob VandenBrink
rob@coherentsecurity.com
Malicious PDF File Used As Delivery Mechanism
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
Comments