Honey, I forgot the database (shame the hackers didn't)

happygeek 1 379 Views

Over the weekend, software development and collaboration tools specialist Atlassian suffered a security breach to an internal system, potentially exposing customer passwords. The reason? It forgot about an old legacy database which had not been taken offline.

According to Atlassian spokesperson the company had migrated its customer database into a new one, where all customer password were encrypted, during July 2008. "However, the old database table was not taken offline or deleted" Cannon-Brookes says "and it is this database table that we believe could have been exposed during the breach". He agrees that this was "a big error" for which the company is extremely sorry, admitting "the legacy customer database, with passwords stored in plain text, was a liability. Even though it wasn't active, it should have been deleted. There's no logical explanation for why it wasn't, other than as we moved off one project, and on to the next one, we dropped the ball and screwed up"

Amichai Shulman, CTO with data security experts Imperva, says that examples of forgotten databases being left unprotected are happening more frequently than most would like to admit. "In this case" Shulman says "the database contained sensitive information, but once it wasn’t used as a production system it was forgotten. Unmanaged systems put sensitive data residing on them at a high risk - unmanaged systems are the top targeted systems".

If you have an Atlassian account from before July 2008 then you are advised to change your password and if it was also used for any other site change it there as well. Atlassian points out that no credit card or payment details were accessible during the breach.

Dani AI

Generated

Good point from — this isn’t just a tooling problem, it’s a process one. Forgotten or dormant database objects are part of the attack surface and need the same lifecycle controls as active systems. Below are practical, immediately actionable steps and a short checklist that supplement the thread without repeating the original incident details.

Immediate incident-control checklist:

  • Isolate the host and block external DB access at the firewall/NACL level.
  • Preserve evidence: take a forensic snapshot and export logs before making destructive changes.
  • Identify affected credentials and revoke/rotate them; force resets for accounts stored in reversible form.
  • Scan for other copies (backups, developer machines, archived dumps) and quarantine them.
  • Follow legal/notification obligations before deleting forensic artefacts.

Fast discovery queries and scans (run against read-only copies where possible):

-- MySQL: find likely password columns
SELECT table_schema, table_name, column_name
FROM information_schema.columns
WHERE LOWER(column_name) LIKE '%pass%' OR LOWER(column_name) LIKE '%pwd%' OR LOWER(column_name) LIKE '%secret%';
-- PostgreSQL: similar discovery
SELECT table_schema, table_name, column_name
FROM information_schema.columns
WHERE column_name ~* 'pass|pwd|secret|token';

And a simple filesystem search for dumps/backups containing credential keywords:

grep -RIn --exclude-dir={.git,node_modules} -e 'password' /var /srv /home || true

Longer-term prevention (governance + automation): maintain an authoritative inventory/CMDB with retirement state; require formal decommission tickets that revoke network rules, destroy backups, and update configs; schedule automated scans for sensitive columns and stale hosts; adopt least privilege and centralized secret management; store passwords only as salted one‑way hashes (bcrypt/argon2) rather than reversible storage.

Caution: don’t irreversibly delete systems until forensics and compliance sign-off. The real fix is repeatable process and automation — treats dormant assets as live risk.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview