Podcast Detail

SANS Stormcast Monday, July 27th, 2026: ESAFENET CDG Scans; DNS Poisoning; macOS Gatekeeper bypass; GitHub and PyPi updates

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/10024.mp3

previous
Podcast Logo
ESAFENET CDG Scans; DNS Poisoning; macOS Gatekeeper bypass; GitHub and PyPi updates
00:00

My Next Class

Click HERE to learn more about classes Johannes is teaching for SANS

Podcast Transcript

 Hello and welcome to the Monday, July 27th, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida, but teaching online this week in
 London. And this episode is brought to you by the SANS.edu
 Undergraduate Certificate Program in Cybersecurity
 Fundamentals. This weekend, I noticed some scans for
 eSafeNet CDG3. This is not the first time we saw scans for
 this particular product. A couple of years ago, a cross
 -site scripting vulnerability was discovered in the product
 and we saw some scans around that time. There are really
 sort of three vulnerabilities that are commonly being quoted
 for this particular product. One is the cross-site
 scripting vulnerability. Then there's a SQL injection
 vulnerability. And the one that we see scans right now
 for is for hard-coded passwords. That's probably the
 most straightforward one to exploit when it comes to
 eSafeNet CDG. This is a product mainly focusing on the
 Chinese market. All their website and such is in
 Chinese. Now, the product itself builds itself as a
 secure document management, the leakage prevention system.
 The vulnerabilities, well, the fixed password stuff is pretty
 bad, but I think are sort of in line with what we typically
 see with these kinds of expensive products that are
 proposing to be more secure than others. But, well, still
 have some of the same vulnerabilities. And
 ReliaQuest has a good write-up of some recent attacks that
 supposedly were perpetrated by some Russian threat actors
 that targeted hospitality Wi -Fi gateways. So, they're
 going after the gateway, not the access point necessarily,
 unless sometimes they are the same thing. The goal here is
 to change DNS settings and then redirect DNS requests to
 a malicious DNS server that will return, well, bad
 responses. In particular, they appear to be going for Outlook
 365 credentials. Definitely make sure that your users are
 aware of bad TLS pop-ups and such and are taking them
 serious. Of course, often in sort of these public Wi-Fi
 networks, users may be a little bit accustomed to these
 bad TLS pop-ups because often the login pages and such for
 these captive portals are often presenting bad TLS
 certificates. So, that's certainly a problem. Last
 week, I wrote a little bit about how different operating
 systems recognize these captive portals and then do
 respective redirects. There's always a chance that these
 redirects are also hijacked and being redirected to a
 malicious sign-in page like for Outlook 365 that may trick
 a user into relinquishing their credentials. It's really
 time for some kind of phishing. Safe authentication,
 pass keys and the like come to mind again. And what typically
 is done, even with default Outlook 365, if you do have
 multi-factor authentication, isn't strictly speaking
 phishing safe. And Apple users, be aware there is an
 interesting technique that malicious actors could use to
 replace applications on your system without Apple's own
 gatekeeper system catching it. This was published by Talal
 Hosh Bakri and Tommy Misk. They reported to Apple, but
 Apple apparently has, after looking at it for about a
 month, closed the report and does not intend to fix it. The
 exploit here is pretty straightforward. It's possible
 to archive an application that the user installed and then
 replace it basically by restoring the archive. But,
 well, when restoring, you don't actually have to restore
 the same archive. You could replace the application. Now,
 Apple has this gatekeeper system that is sort of a basic
 antivirus that will check the executable assets being loaded
 the first time. But, well, it's only loaded, it's only
 executed on the first time. So, later on, gatekeeper is no
 longer involved. And that, of course, is being exploited
 here. That gatekeeper considers the application now
 safe and will no longer change it, even after the user has
 replaced it with the altered archive. Interesting
 vulnerability. And I think certainly something that Apple
 should probably address, but it only applies to
 applications that user installed. So, no applications
 that were installed via the App Store is affected by this
 particular issue. So, basically do some good
 controls, change controllers or file change control on your
 system to prevent this from happening. The attacker does
 need execution rights on the system. But, of course, if the
 attacker can trick you into installing another
 application, they may be able to rewrite an already
 installed application on the system. And we have some
 updates from GitHub as well as from PyPy regarding recent
 supply chain attacks. First of all, GitHub, of course, for
 quite a while now has its Dependabot feature where you
 can get automatically alerted of new updates to any packages
 that you're using. And also have them automatically
 applied in the term of pull requests that are
 automatically generated. Well, GitHub will now wait three
 days before it suggests some update in order to eliminate
 some of these sort of fairly fastly discovered and such
 supply chain attacks like the ones we had in the recent
 months and such. Now, PyPy, on the other hand, takes a little
 bit of different approach. PyPy, of course, manages
 Python packages and authors are only allowed to add new
 files to new releases of their Python package within 14 days.
 So, after 14 days, they have to label it as a new release,
 which, of course, could trigger then again some
 additional reviews. Well, and this is it for today. So,
 thanks for listening. Thanks for liking. Thanks for
 subscribing to this podcast. And talk to you again
 tomorrow. Bye.