Patch Microsoft Exchange On-Premises Servers Faster or Change to Something Else; Update OpenEMR to Eliminate Vulnerabilities; The Surprise is That This Batch of BIND Vulnerabilities Only Enable DoS

As recent breaches have shown, mitigations are just buying you (a little bit) of time. Patch early, patch often is your best bet if you insist on running Exchange on premise.

One reason “attackers looking to exploit unpatched Exchange servers are not going to go away” is that there is a never ended stream of serious vulnerabilities in Microsoft Exchange software! For some enterprises, switching to Google Workspace or Zoho might be feasible, but for many who just can’t keep up with patching demands, moving to cloud-based or hosted/managed Exchange is way better than doing nothing.

Yes, this threat isn't going away. Make sure that you are doing three things: First, patch your exchange servers rigorously, whether or not they are Internet accessible. Second, make sure they are hardened to the current guidelines. Require justification for settings which differ. Third, make sure that you are actively hunting for IOCs relating to exploitation. You know I'm going to say this: move to hosted email, if not MS 365, another solution allowing you to focus more on the security of mission specific systems.

Microsoft’s advice focuses on three critical security controls: data protection [know where your sensitive data resides], secure configuration [harden the operating system to a known standard], and vulnerability management [scan and patch vulnerable systems]. Each of these controls is core to an effective cyber defense program. Be warned, it costs the adversary very little in time and money to target vulnerable servers.

Chris Patterson, one of our SANS.edu students, did a systematic code review of OpenEMR last year, also finding a few vulnerabilities. His research paper can be found here: https://www.sans.edu/cyber-research/how-secure-is-your-health-information-electronic-medical-record-vulnerability-discovery/

The flaws are fixed in OpenEMR 7-0-0-Patch-2. Be sure to cross check the files in the patch as it will overwrite these if you've customized them.

The fix is to update to the patched version of BIND 9 most closely related to the version. you're running. 9.16.37, 9.18.11 or 9.19.9. If you're not sure talk to your DNS team. While you can set the stale-answer-climate-timeout to 0, off or disabled to mitigate two of the vulnerabilities, to get all three you have to update. If you're still on BIND 9.11, read the alerts carefully to determine your risk.

Those of you who had January in the “First critical BIND vulnerability found” 2023 betting pool can collect your winnings! The good news is only denial of service impacts in this batch.

Many major incidents involve multiple mistakes – this one is a good example: user falls for phishing, but luckily can’t get malicious attachment to run; user asks Tech Liaison for help, TL thinks attachment looks suspicious, forwards to contractor security staff; contractor mistakenly opens the attachment on an “unsecured BCPS email network” (which doesn’t sound like a good idea to have, no matter what) and infects the network, enabling the ransomware attack to succeed. Great scenario for a tabletop exercise. I hope the Tech Liasion gets promoted!

A couple security observations: 1) tools and processes were in place to initially block the malware and they worked [secure configuration]; and, 2) the email with attachment was recognized as suspicious by adjunct IT staff [security awareness training]. Usually, both of these security procedures are enough to defend against a ransomware attack. Unfortunately, the breakdown occurred with the contracted security staff likely not following established procedures for handling suspected malware. A final comment: incident response and data recovery only work if you follow well established backup rules and regularly test the recovery process.

Part of the problem is that findings from earlier assessments were either not addressed, or inadequately implemented. While there are always two sides to a story, make sure that you're clearly documenting why you're not addressing findings from a security assessment, and be doubly cautious about terms like delayed response to malware, as was configured in this case. As email continues to be a huge attack vector, consider carefully allowing access to personal email from corporate systems, possibly restricting that access to sandboxed browsers if at all.

Think about that: more than two years and they still don't have all their services back. The question is how would you do in their situation? Yeah, you've got the isolated backups, but have you tried restoring key services -- e.g., rebuild AD from those backups? Restore and run a payroll? Open/close the financials? With all the services you've got in the cloud and/or outsourced, do you have a handle on all the ETL/API gateways you're now using? Any critical processes still running on a user workstation? Who can you call for help? Not trying to scare you, just want to make sure you're covering all your bases.

This is an important point to reiterate regarding ransomware attacks, the recovery from an attack, whether you pay the ransom or not, can take months if not years. Ransomware really is a case of where the prevention is better than the cure. Europol has excellent guidelines on how to prevent ransomware attacks https://www.nomoreransom.org/en/prevention-advice.html CISA have an excellent guide too at https://www.cisa.gov/stopransomware/ransomware-guide

Just as a quick reminder: Do not expose your network storage to the internet. No matter the brand. If you absolutely must: Maybe a well locked down ssh server. For everything else you got a VPN.

This is essentially a SQL Injection flaw. Use the QNAP product support status site to see what the latest update for your device is, if your device is EOL or legacy, it's time to replace it and decommission (not repurpose) the old one. While you're at it, make sure that only intended user accounts and applications are present. Last, but not least, make sure it's not directly exposed to the Internet.

We have an embedded chip vulnerability, which is dependent on updates from your vendor (D-Link, Netgear, LG, Belkin, Zytel, or Asus) for the fix. Make sure that you're running the latest firmware on these devices. Check the firmware version on the vendor's support site against your routers version if you've not seen an update in a while. If you can, use the IOCs to see if you're impacted.

The large number of exploit attempts is not surprising given the high CVSS score for this vulnerability. I mean, cybercriminals can read and they see that it’s a RCE vulnerability that affects a large number of manufacturers and devices. The simple solution is to patch the vulnerable device. Until the patch is in place, monitor your network for signs that the device has been compromised.

This is actually an example of the PKI certificate model working. Encrypted signing certs were exfiltrated, no signs that the encryption passwords were compromised. Revocation is being done purely as a preventative measure, meaning time to do updates using standard processes.

Good move from GitHub to revoke these certificates. But remember that you must update GitHub Desktop and Atom this week.

The Windows version of Desktop isn't impacted. Read the guidance carefully, you're updating Mac versions of Desktop to the latest, while downgrading your Atom installs to 1.60.0 as 1.63.1 and 1.63.0 will stop working. Have a KB article handy, with download links, for when the calls start coming in on Thursday/Friday (and Monday.)

Code signing is an important security protocol to verify that software is authentic and developed by the vendor. The loss of code signing certificates could allow an adversary to create and distribute malicious versions of the software, where end user organizations simply install the update. Revoking the affected code signing certificates is both prudent and necessary to protect end-users.

Certificates are public information about asymmetric key pairs. They cannot be "stolen;" they cannot be used to sign code. Code is signed using the private key of the pair resulting in a certificate, containing the public key, which can then be used to authenticate the code. Revoking a certificate is a statement that, for whatever reason, including compromise of the private key, code associated with the key pair may not be authentic and should not be trusted. Private code-signing keys should not be stored online when not in use.