One leaked key emptied a charity CRM

· · Security Infrastructure

Somewhere in your business there is a password, an access key, or a token that unlocks something important. A login to a database. A key that lets one system talk to another. The credential for the payment provider. These are the keys to the building, and they tend to be handled far more casually than the building itself.

The uncomfortable part is where they end up. Not stolen by a clever attacker, but left somewhere the attacker did not have to be clever to find: a public file, a shared document, a page a search engine quietly indexed.

What happened

Beacon, a customer relationship management provider used by charities and nonprofits, was breached in late July. In an update on 12 August, the company said the likely cause was an Amazon Web Services access key "potentially exposed in public JavaScript build artifacts". In plainer terms: a key that unlocked its cloud storage was left inside files Beacon published to the open web when it built its software.

An access key is a long username-and-password pair for a cloud account. Whoever holds it can do whatever it is permitted to do, from anywhere, no further login required. This one was permitted to read the customer database.

Beacon's chief technology officer, David Simpson, confirmed the result plainly: "a copy of the database which holds all Beacon customer data, including attachment files, was made and likely downloaded in a readable format by the threat actor." The company has more than 1,500 customers. The attacker was inside for about an hour and 27 minutes in the early hours of 27 July, long enough to copy everything.

One detail deserves a pause. Beacon's data was encrypted at rest, the security measure everyone asks about first. It made no difference. Because the stolen key was a valid, authorised credential, the cloud platform decrypted the data on the way out, exactly as it would for the real owner. Encryption at rest protects you from someone who steals the hard drive. It does nothing against someone who holds a working key, because to that key the data is not encrypted at all.

The mistake is ordinary

This is easy to file under "someone else's incident" and move on. It is worth resisting that, because the specific error, a secret left somewhere public, is one of the most common ways small organisations get breached, and it rarely takes any skill to exploit.

The same week Beacon published its update, a separate story showed the pattern from the other end. A company brought in a contractor to help with some integrations. The contractor needed to keep track of the login credentials for a staging server across several devices, and, instead of using a password manager, put them in a Google Doc set to "anyone with the link". Google indexed the document. A colleague later typed the company's own domain into Google, and the search box helpfully autocompleted it with the hostname and the credential string sitting in that document.

Nobody was hacked in either case. In one, a build process baked a key into a public file. In the other, a person put a password somewhere they thought only they could see. Both are the same mistake wearing different clothes: a secret placed where the outside world can reach it, then forgotten.

What to do

The goal is to know where your secrets are and to make the exposed ones stop working. Neither needs a large budget.

  • Rotate first, hunt second, if you suspect exposure. A leaked key is only dangerous while it works. Changing it, what the trade calls rotating, is the one action that instantly ends the risk. If you ever think a credential has been seen, change it before you finish working out how it got out.
  • Do not put secrets in code, documents, or anything public. Passwords and keys should live in a password manager or a dedicated secrets store, not in a source-code file, a spreadsheet, a shared doc, or a message. If a developer or supplier builds software for you, ask them plainly how they keep keys out of what gets published.
  • Give each key only what it needs. Beacon's key could read the whole database. A key that could only do one narrow job would have leaked a far smaller problem. When someone sets up an integration, the right question is what the least it needs to work.
  • Search for what may already be out there. Free tools scan code repositories for exposed secrets, and a search engine will tell you a surprising amount about what of yours it has indexed. If your website or app is built by an outside firm, ask whether they check their published files for leaked keys before release. This is a normal part of a competent build.

The reassuring thing is that this class of breach is largely preventable with habits rather than products. The keys are the point. Treat them like it.

How Steelwise can help

Finding out where your business keeps its keys, which of them are exposed, and what each one could reach if it leaked, is a short, well-defined piece of security work. Get in touch if you would like a second pair of eyes on yours.

Further reading

← All filings

We use cookies to understand how visitors use this site. More information.