Supply Chain Attack Theorized in Hezbollah Device Explosions; Human Rights Complaint Over Pegasus; Podcast: Pen Test Arrests, Five Years Later

Obviously, launching a physical supply compromise like this one takes a very sophisticated threat actor and long planning. Mailing explosive devices or poisoned/compromised USB sticks (or having them delivered) to key employees at your company does not. Use the publicity around this one to make sure mailroom security still exists and extends to how supplies are delivered to remote employees and board members Ð USPS Pub 166 (https://about.usps.com/publications/pub166.pdf) is a good starting point.

Supply chain attacks are difficult to detect and defeat. Although this one had a kinetic component, the same principle applies for software supply chain attacks Ð deny use or compromise communication of the device. As with most everything, supply chain attacks have a shelf-life before they are discovered or used.

It's not clear if the hardware was manipulated at the third-party manufacturer, or in transit to distribution center. What we can do is make sure that we've verified the integrity of our devices when received, to include the distribution channel, and make sure that our issuance process is secure, particularly when sending devices to remote workers or locations. When purchasing through a third-party, or low-bidder, VAR/DSB/etc., make sure you've had a conversation with them about supply chain security, and you understand and accept the risk of their processes. Even so, trust but verify. This is also a lesson in contingency planning. They moved from cell phones to pagers/walkie-talkies due to risk of compromise, what's plan C? RFC 1149 (IP over Avian Carriers)? Messengers with notes? Always have a plan C, D, E ready to go.

This attack exploited the target population's need for secure communication among its members and the attacker's total disregard for collateral damage. The conditions for its success are rare and the lessons so stark that it is not likely to be copied. The lessons include that the supply chain is long, opaque, and vulnerable.

There are many questions about how the interception happened, how the targeting happened, and why exactly this date was chosen. Now, what about fallout? Well, there will be heightened thoughts and scrutiny over physical devices. It is unclear how this would be done, given how many physical devices we all have, but the actual use case shows others how effective this can be.

One of the messages from Apple withdrawing their lawsuit against NSO/Pegasus was they are no longer the only game in town, and even with the increased security options for devices, we need to remember others have developed capabilities. I hope lawsuits like this serve to emphasize there are consequences for these attacks, and we still need to prepare our users travelling in areas where they can be targeted; e.g., current (hardware and software), fully updated burner devices with minimal data, in lockdown mode, checked for malware regularly.

The NSO business model is based upon the pretense that all their customers are legitimate and that software will not be copied. Government officials, journalists, and social activists are at particular risk and should take special precautions.

Fascinating discussion, highly recommend listing to the podcast. The law and its administration are a sight to behold. Bottomline, ensure contracts are in place before engaging in any work.

The Dark Reading interview brings out a lot of details which couldn't be shared five years ago, not only highlighting the importance of in-depth validation of permission for security testing, but the importance of support from all levels as well as the importance of politics and fully understanding not only who your stakeholders are but also who thinks (and will act like) they are.

If a building collapsed because a supplier sold a construction company scaffolding made of balsa wood but painted grey to look like metal, financial liability would easily flow to the offending supplier. Knowingly selling businesses software with balsawood-strength authentication should incur that same level of liability.

Two wrongs here. First the use of default credentials (administrator); and second, not limiting password attempts by timed lockout. For the first, the application should not ship with default passwords but rather require the user to create a password during setup. For the second, the software vendor should include a disabled feature for its application after a defined number of password attempts. Both techniques are well established secure design practices.

We should all get a wee bit disturbed when we see default credentials. FOUNDATION uses an Internet accessible MSSQL server, with default SA and DBA passwords. Rotate these passwords, make sure xp_cmdshell is disabled, and limit internet access to Foundation. While the mobile app requires access to the MSSQL server, consider requiring a per-app VPN rather than exposing the service to anyone.

The software comes with default settings intended to make installation as easy and smooth as possible. This is particularly true for software likely to be installed by those who do not do it often. Once the application is up and running, it is easy to forget or forego changing those settings. Developers can do a better job of ensuring that the application is secure when the installation process is complete.

In particular less "tech savvy" industries have a hard time securing their IT services. But it is important for them to realize that every industry is to some extent in the "IT Business" and relies on these systems to do their work effectively.

This one is interesting. Construction and home building are high-cost industries, and there is lots of money in this industry. The way this reads is that the mobile app connects directly to the MSSQL Database. I'm not sure if that is the case, but if it is, the app needs an architecture.

These vulnerabilities are both addressed with the same update. Make sure that you can login to your Broadcom support account to download the updates. If you haven't logged in since the acquisition, allow extra time. If you're still on vCenter 7 or Cloud Foundation 4.5, it's time to upgrade.

This is a nightmare. I have not heard of a glowing review of the acquisition, and one of the items that seems to have broken is the ability to download and gain access to software. If you use vCenter and the patches are fully available over vCenter, could you do so? Instead, you may have to call Broadcom, which has been less than great. One person told me that after hours on the phone trying to download a purchased copy of Fusion, the support person just emailed them a box link. Things are not going well, but donÕt let that dissuade you from patching. The good news is that we have patches to fix; the bad news is that this may have been in the works for months, and IÕm not exactly sure how many other patches we may be missing.

Just remember, free is not always free. At the end of the day, these social media companies are businesses, and they need a revenue model to stay satisfy their investors. The question becomes what 'rights' did users sign away as part of the account activation process. Bottomline, people like free services even with 'strings' attached.

The information on their practices was collected back in 2020 and is being released now as Congress is considering the Kids Online Safety Act (KOSA) and Children and Teens' Privacy and Protection Act (COPPA 2.0) to better regulate companies. The reality is that collecting, selling and leveraging this data is big business, and legislation plus user action is necessary to change these practices. It's not clear if consumers are willing to pay for a service which is free of both tracking and advertising, which will drive alternative means of monetizing user information for free services.

The patch updates libraries used to implement SAML.

Can we just all stop using SAML? It's like the NTLMv1/v2 of IdPs. Basic Auth would be the LANMAN of IdPs.

CVE-2024-45409, CVSS score 10.0, in the ruby-saml library could allow login as any arbitrary user. If you're using omniauth-saml, this flaw is fixed in 2.21. The GitLab fix update the dependencies for omniauth-saml to version 2.2.1 and ruby-saml to 1.17.0. Beyond updating your GitLab installation, consider GitLab's recommended mitigation to enable 2FA for all accounts and disallow the SAML two-factor bypass option.

Luckily, this flaw was patched "incidentally" with the September 10th update that patched other flaws. But remember that this was the last patch to be released for CSA 4.6. Upgrade to CSA 5 and please restrict access to CSA as much as possible to reduce your attack surface. There are likely more vulnerabilities to come given the history of the product.

Ivanti CSA remains in the vulnerability crosshairs. While this latest issue (CVE-2024-8963) was addressed in 4.6 patch 519, it's still best to move to 5.0 as 4.6 is unsupported at this time. Unlike prior versions which were delivered as an appliance with an older OS, 5.0 can be built on your standard/current Linux, to include your EDR and hardening settings. Even so, don't forget to limit access to the management console.