Archive for January 3, 2022

Lapsus$ Ransomware Gang Pwns Portugal’s Largest TV Channel

Posted in Commentary with tags on January 3, 2022 by itnerd

The Record is reporting that the Lapsus$ ransomware gang has hit SIC, Portugal’s largest TV channel:

The attack has taken place over the New Year holiday and has hit the company’s online IT server infrastructure. Websites for the Impressa group, Expresso, and all the SIC TV channels are currently offline.

National airwave and cable TV broadcasts are operating normally, but the attack has taken down SIC’s internet streaming capabilities.

The Lapsus$ group took credit for the attack by defacing all of Impressa’s sites with a ransom note (pictured at the top of this article). Besides a ransom request, the message claims that the group has gained access to Impresa’s Amazon Web Services account.

Impresa staff appeared to have regained control over this account earlier today when all the sites were put into maintenance mode, but the attackers immediately tweeted from Expresso’s verified Twitter account to show that they still had access to company resources.

The Impresa attack is one of the largest cybersecurity incidents in Portugal’s history. Impresa is, by far, the country’s largest media conglomerate.

This is clearly not a good look for SIC. Elizabeth Wharton who is the Vice President, Operations for SCYTHE had this to say:

“Being able to continuously validate people, processes, and technologies is always going to be a struggle. Ransomware gangs like Lasus$ may use the same tactics, techniques, and procedures (TTPs) to carry out their attacks, or they may reorder the TTPs to fly under the radar. Companies need to continuously test their controls using threat intelligence, like the news of this attack, to protect their business interests.”

Hopefully SIC gets control back from this gang. And more importantly, the rest of us use this as a case study as to how to defend yourself from getting pwned in this manner.

UPDATE: I got additional commentary from Dave Pasirstein, CPO & Head of Engineering, TruU:

Ransomware is not going away.  It’s a lucrative business that is nearly impossible to protect all risk vectors; however, it is made easy by enterprises failing to take enough precautionary steps.  Those steps must include: zero trust approaches, active patching, end-point and email protection, employee culture/training/testing, and very strong authentication such as modern MFA, ideally a password-less MFA that is not based on shared-secrets and thus, cannot easily be bypassed by a server compromise.

iOS Users Have To Worry About A HomeKit Vulnerability That Apple Doesn’t Seem Interested In Fixing…. WTF??

Posted in Commentary with tags on January 3, 2022 by itnerd

Now this is a concerning exploit for iOS users. A denial of service vulnerability that has been dubbed ‘doorLock’ has been discovered in Apple HomeKit, affecting iOS 14.7 through 15.2.

Trevor Spinolas discovered the bug which can be explained this way. If a HomeKit device name is changed to a “very long string,” set at 500,000 characters in testing, iOS and iPadOS devices that loads the string can be rebooted and made unusable. Furthermore, since the name is stored in iCloud and gets updated across all other iOS devices signed into the same account, the bug can reappear repeatedly.

I’ll let him explain how it can be exploited:

Using Apple’s HomeKit API, any iOS app with access to Home data may change the names of HomeKit devices. In iOS 15.1 (or possibly 15.0) a limit on the length of the name an app or the user can set was introduced. On iOS versions previous to these, an application can trigger the bug since this limit is not present. If the bug is triggered on a version of iOS without the limit and the device shares HomeKit data with a device on an iOS version with the limit, both will be still be affected. If a user does not have any Home devices added, the bug can still be triggered by accepting an invitation to a Home that contains a HomeKit device with a large string as its name, even on iOS 15.2. The bug can also be triggered on versions without the length limit by simply copying a large string of text and pasting it when manually renaming a Home device, although the Home app may crash when doing so.

The introduction of a local size limit on the renaming of HomeKit devices was a minor mitigation that ultimately fails to solve the core issue, which is the way that iOS handles the names of HomeKit devices. If an attacker were to exploit this vulnerability, they would be much more likely to use Home invitations rather than an application anyways, since invitations would not require the user to actually own a HomeKit device.

And here’s what happens if you get pwned:

If the device does not have Home devices enabled in Control Center:

The Home app will become completely unusable, crashing upon launch. Rebooting or updating the device does not resolve the problem. If the device is restored but then signs back into the previously used iCloud, the Home app will once again become unusable.

If the device does have Home devices enabled in Control Center (The default behavior when a user has access to Home devices):

iOS will become unresponsive. All input to the device is ignored or significantly delayed, and it will be unable to meaningfully communicate over USB. After around a minute, backboardd will be terminated by watchdog and reload, but the device will remain unresponsive. This cycle will repeat indefinitely with an occasional reboot. Rebooting, though, does not resolve the issue, nor does updating the device. Since USB communication will no longer function except from Recovery or DFU mode, at this point the user has effectively lost all local data as their device is unusable and cannot be backed up. Critically, if the user restores their device and signs back into the previously used iCloud linked to the data, the bug will once again be triggered with the exact same effects as before.

And here’s why you should care:

An attacker could use email addresses resembling Apple services or HomeKit products to trick less tech savvy users (or even those who are curious) into accepting the invitation and then demand payment via email in return for fixing the issue.

That makes this pretty dangerous. So what has Apple done about this? Apparently nothing:

This bug was initially reported on August 10th, and remains in iOS 15.2. Apple stated they planned to resolve the bug in a security update before 2022, but failed to introduce an actual fix. On December 8th, they revised their estimate to “early 2022.” I then informed them on December 9th that I planned to publicly disclose this information on January 1st, 2022. I believe this bug is being handled inappropriately as it poses a serious risk to users and many months have passed without a comprehensive fix. The public should be aware of this vulnerability and how to prevent it from being exploited, rather than being kept in the dark.

So quite clearly, Apple isn’t taking this seriously. Which makes Apple’s claims of being on top of the security game a #EpicFail. More on that in a minute. But because of Apple yet again dropping the ball, it means that you have to protect yourself. Don’t accept HomeKit invites that come out of the blue to your iDevice. Especially from unknown users. And that’s true if they pop up via a notification or via an email. If you’ve already been pwned, Spinolas has some remediation strategies in the link above.

This is the latest example of Apple not taking security researchers and security disclosures seriously. Apple seriously needs to get it’s head into the game as the more this sort of situation happens, the less that people will trust Apple.

UPDATE: Apparently embarrassing Apple gets results as this is now fixed in iOS 15.2.1 as per this: