Critical RCE Vulnerability in Palo Alto Networks GlobalProtect; Chirp Systems Silent on Chirp Access Hard-Coded Credentials

"Must patch" should be obvious for this vulnerability. Palo Alto Networks released guidance with workarounds, and patches, this weekend. But also do not forget to check for compromise. There is no widely available exploit at this time, but we have seen reports of scans for vulnerable devices over the weekend. Whoever has the exploit will likely try to make good use of it as fast as possible.

CVE-2024-3400, PAN-OS command injection vulnerability in GlobalProtect has a CVSS score of 10.0 and is in the NIST KEV catalog with a remediation due date of April 19th. Apply the hotfix, or Threat ID 95817 to mitigate. If you're still running PAN-OS 9 or 10.1, you're not affected; however, you need to delve into why you're not on the current PAN-OS. In addition to making sure your more important systems, such as boundary control devices, are top of the list for patching/updating, make sure that you're actively managing lifecycle, to include the resources to deploy/cutover new equipment as well as purchase it. You're going to want top-down support here.

This is a timely reminder that security devices are sadly just as vulnerable as any other device. This means we need to ensure that we treat the security devices we rely on, in particular those perimeter security devices, with extra care. The UK's National Cyber Security Centre (NCSC) has an excellent blog post on this topic that you should read: "Products on your perimeter considered harmful (until proven otherwise)" https://www.ncsc.gov.uk/blog-post/products-on-your-perimeter.

Get used to patching. Maybe after 20 years of SSL VPN, it's time to think about these systems as they are now increasingly targeted by attackers.

What is more worrying than the vulnerability is the fact that Chirp systems is not commenting on it. But from Chirp's perspective, this is the best thing for them to do. In two weeks, people will have forgotten, and locks will continue to be sold without having to worry about customers possibly bricking devices with firmware updates (if that is an option).

As Chirp systems is not yet responding to the issue, the best action is to make sure that your smart lock systems are isolated, not Internet accessible, and only authorized systems/users can access them. Also make sure you're monitoring for unwelcome advances.

Hardcoding passwords into software was a common practice a couple decades ago. Unfortunately, it's still common with ICS devices. Now that the proverbial cat is out of the bag with media attention and the potential for lawsuits, Chirp likely will be motivated to make the relatively straightforward fix. That said, that doesn't mean users will implement the software update.

This issue slipped in a bit under the radar at the same time people were busy dealing with the GlobalProtect vulnerability. The vulnerability puts your secrets and access to privileged accounts at risk. It also sounds like Delinea dodged a bullet. A security researchers informed Delinea of the vulnerability before someone with less honest motives was able to take advantage of it against Delinea's cloud.

If your Secret Server is exposed to the Internet, you need to either update to the current version, or follow the remediation guide until the patch for your version is released. Note you need to be on version 11.5.2 (11.5.000002) before you can upgrade to 11.7.1.

The leak of Duo customer phone numbers may lead to more targeted phishing ("smishing") attacks. As a Duo customer, you may consider asking your users to look out for such scams.

While the stolen credentials were immediately invalidated, the question remains of why the third-party wasn't using stronger authentication, say phishing / replay resistant credentials? When evaluating the security at your third-party providers, make sure that it is commensurate with the information handled.

Makes you wonder a few things here: What are the attackers after? Can they reverse engineer the OTP or gain other types of information? Who else has been compromised?

As organizations and people get better at detecting and stopping email phishing attacks, cyber criminals simply shift to smishing (text based) and vishing (voice based attacks). Smishing can be very effective as the messages are much shorter, with so little context it's harder to determine what is fake or real. In addition, texting is more informal; we are more likely to respond to it. Finally, most companies have little if any control or insight into employees phones. As for official government organizations, it would help greatly if they would stop registering their own personal .com domains and instead use official .gov domains, making it easier for people to determine which are legitimate URLs.

Strong authentication (at least two kinds of evidence, at least one of which is resistant to replay) will not prevent one's users from clicking on bait. It will prevent the reuse of compromised credentials.

This is one of those places where we need to have users slow down and validate using a known URL/process, not hit the "easy button" in that SMS message. This can be hard, as the immediate reaction is to deal with the issue right away. Consider advising users to filter out unknown senders, and then take extra caution when reviewing those messages with this attack in mind. If you or your users get one of these messages, file a complaint through the ic3.govweb site.

Never underestimate the craftiness of the cybercriminal. We're programmed to respond to text messages. Bottom line: fight the urge to respond; but do periodically check your toll transponder account and keep the card information current.

With so many companies getting breached and moving to MFA, at some point MFA will become the standard. As MFA usage goes up, expect to see an explosion in MFA targeted phishing attacks.

Statistics are hard to come by, but one trend is clear: services not requiring MFA are getting compromised by credential stuffing attacks and those using MFA are not. The best time to move to MFA is before the inevitable compromise of reusable passwords Ð which has been true for over 300 years when this phrase was coined: Don't wait until the horses are gone to lock the barn door.

When implementing their 2FA, you may be prompted to create a new, strong password. Their solution causes an email with a validation link to be sent to the email address associated with the Roku account. If you have a streaming device connected to your account, you can also use the last 5 characters of the device ID to complete the authentication which could be helpful when you cannot access a device with the email for the associated account. Users who cannot receive email on the address associated with the Roku account will need to contact customer support to assign a new email and password.