iOS and Chrome, Supply Chain and new Phishing attacks - This Week in Security - Aug 29 to Sept 4th

This Week in Security

August 29th to September 4th

"iOS and Chrome again, Supply Chain again and Phishing with telescopes"

Aaron back with you as editor this week and as always there is plenty to cover. Security news can be incredibly difficult to keep on top of, so I'm going to pick a few highlights from the last week or so (officially, this issue covers the week of August 29th to September 4th, but you know I often stray!). First, a brief snippet about a story from this week rather than last:

The Los Angeles Unified School District suffered a ransomware attack (https://www.latimes.com/california/story/2022-09-05/lausd-cyberattack-takes-down-la-unified-operations-schools-will-open-on-tuesday) over the weekend and I'm highlighting it here for two reasons: firstly, based on the news reports the response was swift and extremely effective, restoring full service within a couple of days and severely limiting the impact of the outage itself, and secondly so that I can remind you that keeping up with the news like this is important to the F5 SIRT, not only so that we can pass the news on to you, but also because it's important for us to keep up to date with the frequently changing behaviour of bad actors. Bad actors are a threat to your business, your reputation, your livelihood. That's why we take the security of your business seriously. When you're under attack, we'll work quickly to effectively mitigate attacks and vulnerabilities, and get you back up and running. So next time you are under security emergency please contact F5 SIRT.

Housekeeping out of the way, let's move on to the more interesting news!

iOS and Google Chrome updates

In the last issue I wrote, I talked about some Apple 0day vulnerabilities for which urgent patches were released and I urged everyone to update to iOS 15.6.1 (and macOS 12.5.1) noting that earlier versions of macOS, at least, did not appear to be affected. Well, Apple has now released patches[1] for one of those two vulnerabilities for earlier iOS versions to support older devices. If you have a device stuck on iOS 12, you should update to iOS 12.5.6 as soon as possible (covering iPhone 5s, 6, 6 Plus, iPad Air, iPad mini 2, 3 and 6th gen iPod touches).

I also urged Chrome (and Chromium based browser) users to upgrade to address a Critical vulnerability and, this week, I am going to tell you again to upgrade Chrome. This time, to avoid a known-to-be-exploited vulnerability affecting Mojo[2], a component used within Chrome to provide cross-platform inter-process communication mechanisms. Ensure you update to Chrome 105.0.5195.102 or later, as soon as possible - which should be as simple as restarting your browser in the case of Chrome itself. Handy, because you'll need to upgrade again soon to address a clipboard bug[3]

Like the Apple vulnerability above, these are both issues which can be exploited simply by tricking a user into visiting a maliciously crafted webpage - I've seen a few folks asking if WAFs like Advanced WAF could protect against this and, at least in my opinion, that's really asking the wrong question.. if you look at the problem that way around what you are actually asking is: "Can my WAF stop an attacker from injecting the required malicious code into my webserver?" and the answer there is quite likely "Yes, using just the configuration you already have in place". The exception to that would be websites that need to accept arbitrary user input (forums, guest books - remember those?, blog comments etc) and in that case the chances are any WAF configuration sufficient to block the malicious code is going to block legitimate user input as well. If you are trying to look after random visitors then I applaud you, but you are better spending your time in education (help your visitors keep their browser up to date) because your site is just one of many they will visit today. Meanwhile if you are looking after a corporate network, invest your time in client side detection and mitigation - mandate browser updates, have strong endpoint inspection tools and robust anomaly reporting.

Hard coding credentials is a bad thing in your supply chain

This shouldn't really need saying, but hard coding credentials into an application is a bad idea - especially when that application is going to be distributed to uncontrolled endpoints like mobile handsets. Symantec's researchers[1] recently conducted a survey of mobile applications and found over 1,800 applications that contained hard coded AWS credentials; 98% of those being iOS apps and just 2% being Android! Many of those credentials could be used to directly access private cloud services, including databases that should otherwise be secure, and could allow the exposure of user account details, logs, internal communications and so on depending on the app.

In three instances the hard-coded credentials actually existed within SDKs being used by multiple applications and exposed access to private customer data, potentially banking information and, in one particularly egregious example, an SDK which provided full admin access to the back-end infrastructure behind numerous sports betting platforms!

Considering that SDKs are often consumed by application developers, tasked with writing full featured applications extremely quickly, they are often used without in depth security audits and, indeed, may be partially closed-source or black-box in nature making audits particularly difficult. This is yet another example of the difficulty of securing the supply chain in modern software, as we have seen in earlier issues of TWIS with the typo-squatting Python and GitHub packages, or more recently where Python package maintainers fell victim to phishing campaigns to take control of legitimate packages[2].

The NSA, CISA and the ODNI have released a joint advisory detailing how they suggest developers secure the software supply chain[3] titled "Securing the Software Supply Chain, Recommended Practices Guide for Developers". Chapter 2.3 deals directly with the verification of third party components including a section on Software Bill of Materials with other chapters on developing secure code, hardening the build environment and delivering code securely to end users. Personally I think that, as an industry, we have come a long way in terms of building security mindset in development teams such that they can develop more secure code from the ground up (Chapter 2.2) and modern language development (e.g. Rust) further tries to address that by providing memory safe languages to develop in. I also think that hardened environments are pretty well understood at this point as is secure software delivery, leaving third party components as our biggest challenge right now.

Clearly it has a lot of focus, because we see issues like the ones I've discussed here disclosed with increasing regularity; indeed, Python seems to be a particular focus right now with Checkmarx[4] also noting that a third of Python packages execute code automatically when they are downloaded and installed via pip; when performed by a trusted package this is a useful feature allowing for dependencies to be automatically satisfied, but clearly could be easily mis-used to install malware or exfiltrate sensitive information from a target system. I think we are barely scratching the surface at this point, given the number of different package management systems across the numerous development environments and languages in use today, but it's great that we are at least starting. These efforts being encouraged both by US Government mandates as well as private enterprise like Google, who recently introduced a new bug bounty programme specifically aimed at improving supply chain security[5]

The latest phishing lure? Images of space!

Phishing is an ever-present threat and one that is probably best countered by user education and vigilance (of course email filtering helps, but the best crafted phish will always slip through) - often the lures are attachments purporting to be something relating to the targets job function - perhaps a fake PDF invoice asking for domain credentials to view or an Office document "sent" by a colleague with embedded macros - or something that a reader just couldn't resist clicking on (like an attachment "LOVE-LETTER-FOR-YOU"). Apparently, the latter category also includes "pictures of space taken with a shiny new telescope"[1].. actually, flippancy aside, the full attack chain goes something like this:

Phishing email with an attached Microsoft Office file (Word document, Excel sheet, etc)
Office document contains a malicious external entity reference (basically Follina, we've written about this before)
The malicious entity is downloaded and executed, which downloads a second stage JPG file
The JPG, which is an entirely valid JPG and will display as an image from the Webb telescope if you open it, is passed to certutil.exe and decodes to a binary executable

That last step should probably make you stop and go "say, what?". The image actually has a "certificate" included within it which is ignored for the purposes of displaying it as a picture. Certutil, however, will do its best to decode this certificate, which is actually a base64 encoded executable, and then write it out to disk. The resulting executable is malware written in Golang which will, upon execution, begin communicating with a C2 server via TXT DNS requests to an attacker controlled DNS server to both send and receive data.

Golang has been steadily rising in popularity over the last couple of years (most recently this, Agenda[2] and BianLian[3]) because it enables easy cross-platform development and simultaneously makes reverse engineering considerably more time consuming and difficult for researchers. Despite that difficulty however, Securonix[4] have a full write-up on their blog which I recommend reading if you'd like more details including indicators of compromise and detection rules; if you haven't the time to read through everything then I recommend at least skipping to the IoC section and onward. At a minimum, consider blocking DNS lookups for, and access to:

xmlschemeformat[.]com
updatesagent[.]com
apiregis[.]com
185[.]247.209.255
139[.]28.36.222

Updated Sep 09, 2022

Version 2.0

F5 SIRT

security

series-F5SIRT-this-week-in-security

TWIS