Proactively Patch JsonWebToken Libraries; Most Software for Cars Is Riddled With Vulnerabilities; Take Advantage of Amazon S3 Encryption by Default

Interesting vulnerability, in particular as the library is very popular. However, I don't see a clear way to exploit this vulnerability to gain the claimed code execution. There are quite a few dependencies to make this work. So, in other words: Not an emergency, but get this patched before someone more creative in exploit writing figures out a way to exploit this.

JsonWebToken is a open source Javascript package that allows you to verify/sign JWTs, which are mostly used for authorization/authentication. In that context, getting the crypto right is critical. Specific to CVE-2022-23529, lack of data validation of the data type for the secrretOrPublicKey input, which is fixed in version 9.0.0. Two actions here: first, update to the newer version; second, take this to your developers to underscore the importance of input validation (and yes, I've been the guy who incorrectly stated "they would never do that" about data passed to my app....)

This is another example that calling something “cryptography-based” is easy, safely implementing cryptographic and key/secret management functions is NOT easy. This is especially true for efforts like JWT to implement using “URL-safe parts” in order to work in a browser/server through multiple firewalls path. Take special precautions anytime you are an early adopter of security approaches that claim to work in “constrained environments.”

Not "patched!" There is a gap between the availability and the application of patches. While necessary, availability is only part of a solution.

This write-up reads like car makers (or the app developers they hire) trying to play OAWASP Bingo by hitting all the OWASP Top 10 in their apps. Just because your app is new and cool doesn't mean you can forget about the basics.

A common thread here is customer service sites using weak single sign on implementations to make it easier for customers to access services via apps and web browsers. But really, you can find pretty much every one of the OWASP Top 10 vulnerabilities being found in just this one effort. Very obvious that no meaningful security testing has been done on many of the automotive sites before opening them to the public. If you work for an automotive company, use this to drive immediate attention to customer facing sites and apps. If you own one of those vehicles, if you have to use those apps at least use a unique password to reduce impact of an inevitable breach.

Back when we just had to worry about static vs. rolling code capture to impersonate the key-fob, this was less of a deal. Now that we have network connections, mobile apps, ties to services operated by the manufacturer, the cliche of the weakest link is in play. As consumers expect de-facto remote access/control of their vehicles, manufacturers are rolling out products faster than they can secure them. This is a case of compromise of the applications and infrastructure which can access the vehicle as opposed to compromising the vehicle itself, with attacks leveraging SQLi, flawed SSO, CMS issues and even scrutinizing publicly reachable code repositories. Note that the discovered flaws have been patched. Takeaway for you: make sure that you are checking externally produced components (such as an API interface) to make sure it's secure, address identified flaws immediately.

As manufacturers use more and more software in auto designs, the need for developers with a background in secure software development increases dramatically. Currently, that is a commodity in short supply, so they do the next best thing: leverage existing functionality across the industry. Software from third party suppliers has to be fully tested, as would in-house developed code. The outcome of this research is that secure software design and testing will become an increasingly important part of the automotive manufacturing process.

Nice move by Amazon. Compare this to full disk encryption on a laptop: It helps if the laptop gets stolen, but doesn't help if someone can guess your password. You still need to be careful who has access to your data. Client-side encryption should be preferred (and AWS has great tools for that), but it is more work, so only do it to customer data if you care about customer privacy.

The “crypto done right, good; crypto done poorly, bad” thread is pretty obvious in this issue of NewsBites. Amazon makes it easy but not trivial to do S3 stored data encryption right. Once you get it (and “it” includes authentication) right for new storage, you can also retroactively encrypt previously stored data.

Cloud services have made it increasingly easy to encrypt everything at rest, don't pass go, select your key management option, and enable it. You can verify the encryption status in the AWS CloudTrail event logs, and soon you'll have more information in other tools like the AWS Management Console, AWS S3 Inventory, etc. Best of all, there is no added cost for the default encryption on S3.

An easy change that will have dramatic cybersecurity results – moving from opt-in to opt-out by default results in encrypted S3 buckets. This change has the added benefit of automating one of the compliance checks required by cybersecurity audits.

This is a cool free tool, can run from wherever you drop it, no install required, and even has email support and instructions (see the No More Ransom link below.) BitDefender's decryptor will handle data encrypted by "LockerGoga" or "MegaCortex." It has options to scan a system automatically and make a backup of the encrypted files in case something goes wrong. If you have encrypted files that didn't previously decrypt properly, you could try again with this tool, assuming you've not already recreated the contents.

While certainly good news for some victims, it isn’t the long-term solution. As we have come to expect, criminal gangs will modify their ransomware in future releases to continue to exploit victims. The real solution has to focus on the root cause of successful ransomware attacks – human error, coupled with lack of configuration and patch management. The recently published ‘Blueprint for Ransomware Defense’ can serve as an action plan for ransomware mitigation, response, and recovery.

These ransomware decryptors are nice stop gaps, but let's be honest: this isn't a full solution for every piece of ransomware. It will eliminate one specific variant of the problem, and help shut this one down, but if there is a badly written software package the authors will learn and adjust. We really need to go back to basics to solve this problem which is the ugly truth.

Well done to all involved in this research and a reminder to those that become victims of ransomware that it may be worth retaining an infected device(s) as a decryptor tool may become available at a later date.

Lessons for the rest of us: Cryptography is harder than it looks. --Bruce Schneier Systems and implementations are at least as hard as codes and ciphers. --Brian Snow

The FCC regulatory efforts have long lagged behind advances in technology and threats. These issues were last addressed by the FCC in 2007 and this is just the first step in gathering feedback on proposed changes in breach reporting requirements and doesn’t even address more important issues like stopping cell phone number spoofing or “pretexting.”

This is the second of recent actions by the FCC to establish cybersecurity obligations on US telecommunication providers. The first NPRM, which recently concluded its initial comment period, deals with wireless emergency alerts and establishes a minimum set of cybersecurity requirements. This NPRM seeks to update data breach reporting requirements. It’s my opinion that both form the basis for a set of cybersecurity and reporting requirements that are easily achievable by all telecommunication providers.

In today’s environment, a mandatory seven-day waiting period before customer notification is too long. Your customers need as early a warning as possible once you've confirmed their data has been breached. The proposed change also includes required reporting top the FCC, FBI and U.S. Secret service, for breaches that meet the criteria of being reportable. The proposed rulemaking comment period goes for 30 days after, with replies due in 60 days.

This measure is so obvious that it should hardly require regulation. However, one may well prefer late and a light touch to early and heavy handed. That said, telecoms are infrastructure; safety regulation of infrastructure may not be essential, but it is a legitimate and useful role of government.

As with many tools, ChatGPT is neither good nor evil. In fact, OpenAI has terms of service which prohibit the use of its technology for illegal or harmful activities. The issue is that while it was expected that ChatGPT could be leveraged to develop malware, it was not expected how rapidly that would happen. The new malware is more convincing/realistic, making it harder to detect. Now we need our defenders (technology and human) to up their game a bit more rapidly than we would have otherwise expected.

We are not ready as a society for the implications of this technology. The current version of ChatGPT is one that currently provides specific answers to questions based on predictive M/L. It's gotten to the point where we can use it somewhat to solve software challenges. What's really going to be interesting is that this isn't the final version this is only the first version we have publicly seen. It's currently learning from our prompts. Maybe the silver lining is that defenders can use it to you also come up with solutions based on ChatGPT.

While this is interesting research, it highlights only one small part in the whole infrastructure that criminals need to manage and operate in order to support malware campaigns. Whether the malware is written by humans or an AI there is still a lot of work required by criminals to distribute and support that malware which hopefully also gives time for security researchers to identify counter measures against that malware.

This is huge. These are very expensive machines, and when needed, they are needed, often running 24x7 during peak seasons. As such, they need to be able to be repaired without waiting for a factory representative to be sent, let alone trying to purchase a replacement or borrow from a neighbor with as much need and time crunch as you have. This should also encourage in-field changes to help them better suit the needs in “the field.” Often these innovations/modifications (hacks) make their way back to mainstream production when discovered in the field. That said, be sure you know what you're doing before offering to alter a $1M combine.

Deere's policies have been a prime public example of those that have motivated the "right to repair" initiatives. The threat of legal redress may have been essential to this agreement. That said, such specific agreements may be preferable to broad legislation.

This is focused on physical security and monitoring of that security. Physical security can be hard, no pun intended, when you learn about not only bypass scenarios, but also common shortcuts such as using a standard lock plate which prevents lock plunger security from properly engaging or motion/heat sensing door releases which are placed so they can be bypassed from the outside. If you've not had a physical pen-test recently, it's not a bad idea to validate your assumptions. Don't roll your eyes at bypass options, instead look at how they can be mitigated and where your greatest risks lie.

Recent attacks on electrical substations in both NC and WA serve only to highlight the need for such a review. While the focus rightfully is on the physical security of substations, a review of cybersecurity guidelines should also be conducted. Increasingly we find that OT systems are being connected with IT systems creating a pathway for adversary access.

Is it too early to conclude from the experience in Ukraine that the power grid might be more resistant to attack from the network than to kinetic attack?

In 2019, SANS recognized Jefferson Gilkeson, Director of Information Technology Audit, U.S. Department of the Interior, with a SANS Difference Makers award and it is good to see DoI keeping up the good work in making Office of Inspector General audits include active testing rather than just be data call/review exercises. Not all the results were negative – the audit pointed out that 99% of DoI admin privileged accounts required MFA and the DoI says that is now 100%. Can you make the same claim?

Make sure that you're rolling out/requiring MFA wherever possible. You will likely still have places which still need reusable passwords. Users need all the help you can provide to select good passwords. You need policy, training, and technical measures to help them out. You can get services that integrate with your AD to check passwords against data breach notification; where the checks are made locally, they use a fraction of the password hash to collect possible matches from their database. Also, tools exist to help us configure password rules to modern (NIST 800-63-3) guidance. Trade-off long passphrases, which only have to be changed when breached, with shorter (weaker) passwords which require frequent update.