If You Haven’t Patched GoAnywhere MFT Yet, Start Incident Response; If It Has an Apple Logo On It, Patch IT ASAP; If You Don’t Patch On Premise Exchange, Microsoft May Keep You Out of the Exchange Online Pool

If you are still running vulnerable GoAnywhere MFT software, patching now isn't going to fix your problem. This vulnerability has been known, and publicly discussed, for a while now. If you are still not patched: Go straight to incident response and do not waste time patching first.

Johannes Ullrich

Many disclosures include notification that they are no-longer using the GoAnywhere file transfer service. If you are using GoAnywhere MFT software, make sure it's updated. File transfer services as well as API gateways have become increasingly prevalent with the increased use of cloud and outsourced services. Make sure that you know what services are used for these communications and that you've not only secured them, but watch for changes in that security.

Lee Neely

The underlying attack utilized a zero-day exploit. ‘Zero days’ are next to impossible to defend against until the vendor issues a patch, which it did within a week. Now it is up to users of the software to escalate remediation as part of their patch management process. It often comes down to a race between the evil-doer to exploit and, the target to protect themselves by patching.

Curtis Dukes

The GoAnywhere software we wrote about a few weeks ago is popping up again as more companies get hit with this vulnerability. We haven’t seen this system in use in many of the orgs we have tested, but then again, our view of the total install base would be fairly small. It is commercial software sold by Fortra, and you would imagine it would have been sold to several companies.

Moses Frost

I appreciate GitHub acting quickly to protect users from potential machine in the middle attacks. But this also highlights the need to have procedures in place to quickly swap out crypto keys as needed. Many scripts automating actions against GitHub broke as a result, and will likely be broken for a while until users get around to swapping the respective keys. In particular for SSH, rotating keys isn't quite as straight forward as for TLS.

Johannes Ullrich

Practitioner's note: If you're already using GitHub, this will require removing old host key lines from your known hosts file (in the .ssh/ folder, in your Linux or Windows home directory). Any git actions that use SSH will bring errors about which lines are passé. Once the old entries are deleted, the new host key will show up during your next git action. Accept the new key if it matches one in GitHub's list: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints

Christopher Elgee

SOP should be that when a private key is exposed, or otherwise compromised, you revoke and replace the keypair. The GitHub blog includes what you need to do to update your copies of their SSH public key, a useful reference for users when you change one of your SSH Host keys. This is a good time to make sure that you don't have any private keys stored in your repositories, particularly public facing ones.

Lee Neely

Encryption/digital signatures are worse than useless if private keys are not kept private, they provide a dangerous false sense of security. GitHub seems to have handled this well and found the “inadvertent publishing of private information” quickly, but it really means they just got lucky that the error wasn’t found first by bad actors. I hope they publish lessons learned on what they changed to greatly reduce chances of this happening again.

John Pescatore

The 2022 Verizon Data Breaches Investigations Report states that 82 percent of data breaches are caused by a human element; other reports claim upwards of 90 percent. GitHub’s actions are both prudent and reflect the potential severity of the risk.

Curtis Dukes

The remedy for the possible compromise of a private key is to replace the key pair. This includes revoking and replacing the corresponding public key. Revocation of key pairs should be routine and should not require "instructions for what users need to do."

William Hugh Murray