Update Apache Superset ASAP; Google Authenticator Still Does Not Support End to End Encryption; Advanced Attackers Are Focusing on Application Update Installers; SANS Panel at RSA: Five Most Dangerous New Attack Techniques

[Ullrich] On the one hand, users should read the manual, but on the other hand, software should not assume they actually do. If you add a default cryptographic key (or password) to your software's configuration at least display an error message and do not allow the software to run unless the key is changed.

Let’s break this down: This was a lab in the Advanced Web Pen Testing Course I authored many years ago. The bug here stems from how cookies are securely wrapped within the application. Since the encryption key is well known, and the attacker understands the algorithm to unwrap the cookie, the encryption is rendered ineffective as it just requires someone to look. These bugs are nasty because it's more than just resetting a user’s password; it has to do with rotating the application secret, which is the crux of this issue. Does this impact more than Apache Superset? Potentially, this bug affected Python Flask (in this case, being the target) and Ruby Sinatra. The advice given to most “developers” is “choose a strong key”; however, most developers that are building Flask applications should have this defaulted to a randomly generated long string. I advise many developers in this setting that “opinionated frameworks” can set safe defaults, while these microservices frameworks may not. This is the risk model you must assume.

This is the challenge of a functional default configuration. Ideally, security items that you're supposed to provide your own value for should be commented out, with a note about setting a value. Not only does version 2.1 fix the bug, but also will not start if you're using one of the default keys. If you're using a default key, you will not only need to generate a new secure one, but also the information secured with the old one will need to be re-encrypted. Apache Superset CLI includes a tool for rotating secrets -see the Superset SECRET_KEY Rotation page. https://superset.apache.org/docs/installation/configuring-superset/#secret_key-rotation

Default configuration is a delicate balance between user experience and security. The vendor too often tips the scale to user experience. There exists a marketplace that offers secure configuration recommendations for a variety of vendor products (CIS Benchmarks, DISA STIGs). In this case, the only alternative is to update to the latest version. Here’s a gentle reminder to build into your cybersecurity program, secure configuration.

Google has done a great job popularizing one-time passwords with Google Authenticator. The inability to sync the secrets, or at least easily move them to another device, was an issue many have complained about in the past. But not providing end-to-end encryption makes this a dangerous feature. In recent years, many password managers, and a number of other tools, have implemented one-time passwords. Some of these tools support secure synchronization. Maybe it is time to retire the Google Authenticator for one of these more "modern" tools.

Let’s revisit the balance between user experience and security again, shall we. Two-factor authentication only works if you can protect both factors. E2EE tips the scale in the direction of security with minimal impact on user experience. Yes, government lawful intercept programs might complain but that’s an entirely different discussion for another day.

If you've still got TOTP keys, having a mechanism to transfer them is key. Recording then hand-entering the TOTP seed is a nuisance and can be error prone. Some TOTP apps, like Authy, already support sharing the secrets through a cloud service. Before using that type of service, including Google's option, make sure that sharing is secure. I'm inclined to wait for Google to implement E2EE, using their existing export/import function until then.

Here is my take on this. I’m happy people don’t have to go through days of resetting their MFA tokens whenever they change their phones. This is good. On the other hand, FIDO2 is an excellent standard. For most applications, enterprises should consider moving away from the TOTP MFA issue into FIDO2. Anyone that can get their hands on this Authenticator Backup will have as much power as those that had access to the LastPass vaults (potentially). Keep an eye out for the following technologies: SCIM and Verified IDs. This and FIDO2 would probably help us significantly avoid implementing MFA in the way we have. It’s served us well for over a decade but is the time for this coming to an end?

Another example of what happens when supply chain security is not emphasized. In this case, mostly smaller Non Government Agencies were impacted – smaller enterprises generally have the most difficulty establishing and maturing supply chain security programs.

This sort of attack is still fairly targeted, so your current efforts to ensure updates are legitimate, from the correct commit/supplier, you'll want to think about how you would incorporate processes to discover unintended behavior, via detonation chambers, dynamic and static code analysis or otherwise, planning to have that in place before you're a victim, targeted or otherwise.

This makes total sense, and it's an iterative attack based on things like EvilGrade. You have to “trust” someone at some level, but if the threat actor can abuse that trust, it’s easier to implant your backdoor.

Supply chain attacks are insidious by nature. NGO’s lack the cybersecurity resources to protect themselves from attack by nation states. Here’s where cybersecurity companies can step in to provide free tools to better protect these small organizations that are providing humanitarian assistance.

It seems clear that APT actors see suppliers as an efficient way to spread their control. Supplier risk is increasing. Suppliers must respond accordingly.

From an overall economic point of view, it makes sense to make sure product manufacturers can’t unfairly profit over needed repairs or upgrades to their products that include software. But, from a security perspective it means instead of one definitive source for updates, there will be many – which of course enables criminals to supply malicious updates/”features” that will turn a tractor into a brick until the ransom is paid. Supply chain security is hard enough; this enlarges the number of potential software suppliers. Security evaluation criteria will have to be in every procurement of third-party software updates and services. See this week’s item on Chinese attacks compromising legitimate software updates.

I’m of two minds on the ‘Right-to-Repair’ law. Yes, it’s a good thing purely from an economics viewpoint. It is also likely to reduce the monopoly on equipment repair that farm equipment vendors currently enjoy. However, from a security perspective, it opens up a raft of potential localized supply chain attacks by evil-doers. Given that many other states are considering similar bills, security guidance to shore up supply chains becomes increasingly important.

This bill initially applied to powered wheelchairs and was extended to include agricultural equipment. Given the duty cycle of that equipment, and the complexity - more like a jet plane than that tractor on Green Acres, being able to get parts and effect repairs is a 24x7 problem during peak seasons, such as harvest, and making repairs difficult can have a direct impact on consumers due to lost/ruined crops or excessive costs. Farmers will still have the choice to go to the OEM for repair services, and I am sure will run into less-than-ideal third-party options. On the cool side, this legitimizes hacks developed in the field. John Deere is known for incorporating these into future products after discovering them in the field.

My dad was a mechanic, and I grew up working on cars; it dumbfounds me that someone who purchased a piece of equipment here was treated as a software licensee. Please make no mistake; the automotive business was mostly about selling parts than it was about selling cars. I can’t imagine working on a car today; like Darth Vader, a car is more computer than mechanical. Unfortunately, the large machine agricultural market is almost a monopoly at this point, and if you are in that business, you are beholden to whom you can purchase a tractor. Unfortunately, you have even to have a law like this in the books, but this is where we are. Instead of this law, we saw small farms backdooring their machinery, which was less than ideal for repairing their machinery. Let’s hope that the manufacturers allow for fewer restrictions in the future. However, I think that since many of us are moving away from combustion engines into less “maintenance” and “less profitable parts sales” electric vehicles, we may also start to see more and more restrictions on our regular vehicles.

The IT market clearly prefers open systems. Only a few of us prefer the confidence that comes with closed systems. My iPhone and iPad rarely need repair and when they do I will continue to take them to the Apple Store. Not sure what I might do with a farmer's robot where the difference between the cost of "authorized" repairs and others might be material.

Now that we know what algorithms are in our future for post-quantum cryptography, this is how we get use cases and implementations to figure out how we get there from here. The new crypto is not necessarily a drop-in replacement, so we need to figure this out carefully to not wind up either breaking or otherwise making services unusable. NIST is looking for input by June 8 to develop practical guides to help us all make this transition. Comments can be submitted by email to applied-crypto-pqcnist.gov.

This document is only five pages, but I recommend reading it thoroughly and thinking about these challenges. How will we be able to support pre-quantum and post-quantum encryption? How slow in terms of bandwidth and CPU performance will these algorithms initially be from a crypto perspective? Will we face the same “CPU” challenges preventing us from fully encrypting websites like we used to have? How can we deprecate the older technologies? We still see many instances where the defaults will be SSL 2.0 or higher in environments. Many of the challenges outlined will be around how the algorithms based on current public key cryptography will be vulnerable to attack and rendered almost useless. The new algorithms will need to be selected by type of encryption request, which will make the selection challenging and will not be a drop-in replacement. How will VPNs be impacted? How will existing ephemeral key choices be impacted (such as PFS)? How will downgrade attacks look? Can you go from Post-Quantum Ciphers into Pre-Quantum Ciphers? How do endpoints look? Will Microsoft allow us to tune TLS ciphers without using a 3rd party app or hacking the registry? Will actors that have been collecting traffic for years suddenly be able to decrypt them? While no one has reached Quantum Supremacy, it’s good to realize that we must work on this now.

We likely have months to years to deal with this change. The earlier we start, the less costly it is likely to be. In any case, it is time to start planning. Good to see NIST addressing it now.

Google says they are working to not only hold criminal operators of malware accountable but also those who profit from its distribution. This is a win for Google, and with luck the CryptBot will be out of business, which is a win for the rest of us. If you're inclined to take down a malware operator, particularly one who impacted you, work with law enforcement and other agencies (FBI, CISA, etc.) rather than taking that on yourself.

Over the last few years precedence has been set whereby tech companies can obtain a court order to disrupt malware operations. Microsoft for one, has been particularly active in this domain (see SANS NewsBites Vol. 25, Num. 28). Kudos to Google for taking a page from that playbook to protect fellow netizens.

The fixes are for workstation 17 (17.0.2) and Fusion 13 (13.0.2), if you're running older versions, don't assume you're not impacted, get on current versions. The flaws, CVE-2023-20869, CVE-2023-20870, CVE-2023-20871, and CVE-2023-20872) the first of which has a CVSS score of 9.3, and while there is a workaround, apply the update, particularly as CVE-2023-20871 has _NO_ workaround. Take a pause, go over to VMware and hit the check for updates menu, then install them. Next, the hard part, go to your VM library and review what you're storing, either get rid of or archive old ones, particularly old/vulnerable systems which could be compromised easily.

A note for cybersecurity professionals: when you see the word ‘critical’ in a vulnerability announcement, you best pay attention. Prioritize that patch as part of your patch management process.

This is an old service discovery model, harkening back to when we were looking at CORBA (Common Object Request Broker Architecture) for application and service delivery. While the workaround is to block SLP (port 427) from the Internet, I'm thinking retiring SLP, if you're still using it (odds are you are not) is a better plan. Disable SLP where you find it.

I had to return to my memory to remember the last time I saw SLP on a network. It mainly was when I looked at internal network traffic on large enterprises. The “fix” for this amplification attack is to block a port on the egress firewall. I am not sure, however, how an attack remotely triggers this attack through the internet, as SLP port 427 is not a typical port you find on the internet. If you see this broadcast port in your data center traffic, I will suppose egress blocking specifically of this port is ideal. Then again, most enterprises I have seen barely block egress ports.

Essentially the permission management didn't restrict the capabilities related to the SQL database. There is no mitigation except to apply the update. Then go check your system integrity, particularly checking for unrecognized users. Before we throw PrestaShop under the bus, check your own work - if you missed a trick on permission management, clean that up.

If your e-commerce platform uses PrestaShop, I would pay particular attention to this nasty vulnerability. The vulnerability allows the evil-doer to modify or delete data affecting the integrity and availability of valuable business data. If that isn’t enough, it rates 9.9 on the CVSS scale. Patch now!