Check for Signs of “Infamous Chisel-A” on Android Mobile Devices; Take Proactive Approach to Limit Unnecessary Data Exposure; Replace, Segregate, or Mitigate Vulnerable Windows 7 Legacy Systems

The CISA report notes “The Infamous Chisel components are low to medium sophistication and appear to have been developed with little regard to defense evasion or concealment of malicious activity.” Spillover potential may be low, but it is worth warning Android phone users and updating MDM checks.

Sandworm, we meet again. This time you're wielding Chisel, far less subtle and effective compared to NotPetya. Chisel is not intended to be subtle nor evade defenses, albeit the TOR backdoor is hidden, it's still possible to detect and block the activity. The report includes IOCs, and the NIST analysis includes downloadable YARA rules to aid hunting. Odds are you're going to want to do a factory reset or replacement of any impacted devices.

A minor example of a larger problem where data usage is frequently way more promiscuous than need be. Good to use this as justification for reviewing data exposure to avoid privacy fines or other regulatory actions.

The feature was created to allow users to track tap-and-go history (entry point) without having to create an OMNY account. That anyone could track history based on just having the correct credit card number, may sound like a low-risk scenario, the availability of stolen card numbers means that it's a lot easier than you may think to do that. Note that MTA was and continues to tokenize card numbers, clearly the same card number resulted in the same tokenized number and is evaluating other ways to more securely provide the history functions.

Privacy laws continue to drive fundamental changes in how data is collected and maintained by organizations. In this case the NY MTA quickly realized disabling the feature was the easiest solution until an identity and access management scheme can be introduced to protect access to the data.

This report is about the potential for the leakage of the data. The more fundamental questions are about its retention and its storage. Is retention necessary and legitimate? If so, is the data stored encrypted and access controlled? Only then does the question of the privileged access of the application arise.

We're all thinking weakest link right? In this case the Windows 7 system was characterized as rogue. For many OT/ICS systems it is a real possibility that you have legitimate Windows 7 devices which are, effectively, toasters, where patching and updating is achieved via expensive forklift replacement. Security for these is going to be dependent on network and physical security measures to limit access, in and out, as well as monitoring. Make sure you know where these older devices are, why they are there, and that you've got your hands around protecting and monitoring them.

This attack highlights two key facts: 1) every organization, in every sector, is a potential target for ransomware gangs, and 2) organizations need to plan for end-of-life software. For end-of-life software, the easy solution is to upgrade. That said, it isn’t always that simple for organizations. In that case the organization needs to perform a risk assessment and develop other mitigations to protect the enterprise.

While there are valid reasons for the continued use of archaic and unsupported software, such high risk uses should not be connected to both the public and enterprise networks.

This is not a technical attack exploiting a technical vulnerability, this is a highly advanced social engineering attack led by cyber attackers who are doing their research. There is nothing wrong with the super-user accounts that Okta has created, nor the federated capabilities its products support. There are many real world needs for this. What the cyber threat actors have learned is we have become so good at using technology (like Otka) to secure technology that cyber threat actors are now targeting the one operating system we have failed to secure, “the HumanOS.” Okta published five actionable steps organizations can take to help defend against them. https://sec.okta.com/articles/2023/07/social-engineering-getting-more-extreme-fixes-can-be-simple

Even if you're not an Okta customer, consider how a scenario like this could play out in your enterprise. Don't only think about your MFA protections, but also those "break-glass" emergency accounts - maybe the help desk can't be tricked into producing a hardware token, but if they can surrender those credentials - game over. The threat actors in this scenario already had compromised credentials, waiting only on the MFA token to finish the job. Make sure you're monitoring for compromised credentials, requiring them to be reset when discovered, particularly for privileged accounts, ideally for all accounts.

Social engineering has become the bread and butter for enabling attacks by cybercriminals. Couple that with most help desks being rated on response time and closing of user request tickets and you understand why Okta issued the warning. The warning also provides an opportunity for organizations to revisit their own response playbook when it comes to requests to change privileged accounts.

Support desk people are trained to be polite and helpful and measured on closing tickets. It should not surprise anyone that that makes them an exploitable vulnerability. Train for security first and measure accordingly.

Remember back in 2004 when the payment card industry first put out the PCI Data Security Standards? First comes resistance and lobbying, then comes claims of mitigation or draconian projections of how security will break everything, then movement to replace inventory that has finally aged out anyway with hopefully more secure products and processes. To shorten that cycle for medical devices, start working now with procurement and operations to let vendors know security will be a key evaluation criterion in all new procurements.

This ties back to the Consolidated Appropriations Act, 2023 (Omnibus) legislation passed last December, where Section 3305 - "Ensuring Cybersecurity of Medical Devices," which went into effect March 29, 2023. Come October 1st, the “refuse to accept” clauses go into play for devices which have not submitted sufficient cybersecurity details. Previously the FDA indicated they were not interested in broad use of the refuse-to-accept option; it will be interesting to see if there is an exemption or extension process. As much as medical and healthcare systems are targeted, I would not hold out for an easy or simple exception process.

It’s time for device manufacturers to read the ‘tea leaves.’ Government is using regulation to drive manufacturers to enable basic secure by design principles into their products. While some of the requirements don’t have a material effect on the end-user, they are basic building blocks of a secure by design approach. I would suggest that trade associations work with their respective government agencies to understand what an acceptable submission will be, so that it can be standardized within that sector.

One has the right to expect security by design in all applications and appliances. That said, while this is a high visibility application, it is not one that worries this observer more than others. Attacks do not scale.

In the SANS 2023 Threat Report (https://www.sans.org/white-papers/sans-2023-attack-threat-report/) SANS instructor Stephen Sims details how he was able to get generative AI to do all those bad things, as well as create simple malware.

You should be building a library of concerns and best practices for Generative AI. This capability isn't going away, and it will continue to evolve and train from provided datasets. Consider spinning up a team to do a deep dive on what it can do for, and against, you. Publish guidelines for staff to not only help them understand the new technology but also protect your information.

LLMs are powerful natural language user interfaces to the modern computer. They are a natural and expected application of cheap and powerful computers. As with any such interface we should ensure that the application not be contaminated by its use, that persistent changes to the application not be possible from the interface, and that user-to-user isolation is maintained.

Good to ask all code testing tool vendors if their products address the problem Sourcegraph noted: “Our internal control systems, including automated code analysis, failed to catch the access token being committed to the repository.”

There is excellent transparency in the security notice from Sourcegraph. Only about 20 license keys were exposed, and those have been rotated/updated. The rate-limiting is a temporary measure which only affects community (free) users while the investigation completes. In addition to rotating the identified licenses, and implementing temporary rate limits, the hijacked account access has been revoked, Sourcegraph has implemented new processes and tests to better detect and prevent future activity.

You should already be focusing on making TLS 1.3 your standard. Now is a good time to make sure you've disabled support for TLS 1.0 (1999) and 1.1 (2006) in your services. Microsoft's Tech Community alert includes a list of applications which are reliant on TLS 1.1 and are expected to be broken, many of which are old versions and should be updated.

Microsoft’s requirement for backwards compatibility has always been at odds with timely transition to newer, more secure versions of TLS. It’s understandable: customer needs (err, support calls) should always be a key consideration. Let’s hope 2023 is indeed the year that TLS 1.0 and 1.1 are finally excised from all Microsoft products.

The seven actions suggested by the Joint Commission are all steps that form the basis for an organization’s incident response plan. While specific to the healthcare sector, the actions can easily be applied to other critical sectors, especially those that have an operational technology (OT) component. Perhaps the most important action to take is to host regular training exercises on key steps of the plan.

These are practices we should all have worked out, regardless of being in the healthcare sector. Take a moment and compare what you have with the activities in the report. Beware, this is a different definition of the term HVA, but that shouldn't impact your analysis.