INTERNET STORM CENTER SPOTLIGHT
ISC provides a free analysis and warning service to thousands of Internet users and organizations, and is actively working with Internet Service Providers to fight back against the most malicious attackers. https://isc.sans.edu/about.html
Mapping Threats with DNSTwist and the Internet Storm Center [Guest Diary]
Published: 2024-08-20
Last Updated: 2024-08-21 00:17:41 UTC
by Guy Bruneau (Version: 1)
[This is a Guest Diary by Michael Tigges, an ISC intern as part of the SANS.edu BACS program]
On July 16, 2024, I received notification of a suspicious tunnel being opened via SSH in relation to the medical image viewing software "MicroDICOM". MicroDICOM is a medical imagery software and processing engine commonly used to examine x-ray’s, MRIs, and ultrasounds. This was atypical for this application-- while it contained the capabilities to perform network sharing, this application reused private keys and generally engaged in unsafe practices for a method that might connect to an organizational resource. Furthermore, all files were connecting back to the same IP address, 209.127.37.48. Upon investigation, we were able to determine that this application was not, in fact, the application it purported to be, but instead part of large phishing campaign that appeared to prey on a recent Common Vulnerability & Exploit (CVE) notification from the Cybersecurity & Infrastructure Security Agency (CISA).
On July 11, 2024, CISA released ICS Medical Advisory 'ICSMA-24-163-01'. This advisory raised two CVEs to public attention:
CVE-2024-33606 (CVSS 8.8) for the improper authorization for custom URL scheme.
CVE-2024-28877 (CVSS 8.8) for a stack buffer overflow.
The combination of these CVE's necessitates an immediate update to this application, and in fact, proper security due diligence would be to mitigate this as soon as possible with updating/patching. As such, a large portion of the MicroDICOM users were likely looking to update their software.
Behavioral Analysis
Armed with this context, we can focus on our binary analysis. I retrieved the payload from the host system that fired the alert. Our application, `MicroDicom-2024.2+2.exe` was much larger than the original application at 179 MB, versus the typical 10MB to 12.5MB that the original application is. Our first hint aside from the obvious non-matching file hash and size that we may be dealing with adversarial behavior came through the certificate utilized by this application, "Helping businesses Limited". (Bonus: This is a commonly abused signature! More on that at the end.)
Further examination of the application in a sandbox revealed the presence of several artifacts of interest inconsistent with the general behavior of this service. The first, `UpdaterSvc.exe` is a service registered on the target system upon installation of the suspicious MicroDICOM application. This service is quite simple, and process hierarchy reveals that this is responsible for the invocation of our second artifact of interest, 7655.bat. This, in turn, is responsible for the construction and execution of our SSH tunnel. Armed with this knowledge, we can begin enumeration in earnest to find some more information regarding potential attack vectors for our MicroDICOM application.
Read the full entry:
Where are we with CVE-2024-38063: Microsoft IPv6 Vulnerability
Published: 2024-08-20
Last Updated: 2024-08-20 14:06:39 UTC
by Johannes Ullrich (Version: 1)
I recorded a quick live stream with a quick update on CVE-2024-38063. The video focuses on determining the exploitability, particularly whether your systems are reachable by IPv6.
After recording this video, Stephen Sims pointed me to a thread on X published yesterday. It goes over some of the possible exploit paths. The main takeaway is that it will likely take multiple packets to successfully exploit this issue, and exploitation will likely not be reliable. Some of the discussion also reminds me of a recent IPv4 issue in FreeBSD.
The FreeBSD issue was caused by ICMP error messages sent in response to crafted ICMP requests. ICMP options included in the response caused a buffer overflow. Something similar may be happening here. If I read the X thread correctly, multiple queued errors are required in the case of CVE-2024-38063.
See this "Packet Tuesday" video about the FreeBSD issue: https://www.youtube.com/watch?v=Bgmfl17AQWA
Read the full entry:
https://isc.sans.edu/diary/Where+are+we+with+CVE202438063+Microsoft+IPv6+Vulnerability/31186/