Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
When data breaches occur, is a database always involved?
In the case of databases being involved, do hackers figure out how the data is stored and read this or do they just figure out how to make queries to the database via the DBMS?
Is accessing the data files less of a mystery for open-source files and thus a possible weak point compared to closed-source databases?
No, a database is not always involved.
Let's come up with a random service that happens to be moderately popular. A fairly standard set of components includes:
Every single component can be the source of a data leak.
Here are some examples how (this is by no means comprehensive):
User-facing client / programmatic API:
Let's say there's an endpoint on the server to return a logged-in user's private profile (not normally publicly visible). The endpoint is just /getprofile?userid=12345 (where 12345 is my user ID).
Because the developers forgot their coffee that day, they figured they don't need to perform any checks on it; the user ID is generated by them, there's no reason for anyone out there to know what it is. So just return the profile for 12345 no matter who is asking.
Because they forgot their coffee on the day they were writing their schema, they also made those user ID monotonically increasing, as opposed to random.
The attacker can now start dumping the private profile of every single user in the system by hitting /getprofil?userid=1 and increasing by one until it starts telling me the user does not exist.
The same applies to a programmatic API that doesn't perform the correct authentication/authorization checks.
Database:
The under-caffeinated developers have some good friends: the sleep-deprived database admins. Because security is hard, they just deployed their database without secure communication (plaintext as opposed to TLS), and using either simple passwords for the admin users (because they're hard to remember), or even worse: the default username and password.
This database is also accessible to the world because some backends outside that datacenter need to access it. Any attacker can now connect to the database and try the default username and password. Once in, they can perform any query they like on the database.
Backups:
The database admins know problems sometimes occur, so they setup regular backups of the entire database. Because they found a neat script that does it for them, they save those backups to an S3 bucket.
But alas, they had a really late night and figure they'll worry about access permissions on the S3 buckets tomorrow, it'll just stay open for now, it's not like anyone is going to find that bucket.
Alas, the attacker has found the publicly-readable bucket with a convenient dump of the entire database. All they need to do is a quick copy of everything.
Third-parties:
Analytics is hard, it would be a lot better to export our entire database to a third-party that has really shiny dashboards and graphs. We'll just setup a pipeline to save all DB modifications straight to that third-party.
Oops, that third-party is just as red-eyed as our developers and database admins, they forgot proper security in their database, or backups. The attacker can now access our data due to someone else's carelessness.
Conclusion:
These are just some naive scenarios on some of the possible components, yet they happen constantly. You'll notice that none of them involve breaking through strong levels of security or require insider knowledge. They are all attacks that can be carried out by low level security threats.
Not all of them involve a database (eg: the API attacks don't care how the data is stored), and most of them never have to deal with the database software itself. When they do, it's a question of database configuration, not the software itself.
Data breaches do not always involve a database. For example, this high-profile breach was of a data dump on a CD.
However, as most important data is held in a database of some kind, most data breaches do involve databases.
There is little difference between open-source and proprietary databases for security.
When data breaches occur, is a database always involved?
A "database" in the traditional sense (i.e. SQL, noSQL etc) don't need to be involved. Still the information somehow needs to be accessed, but this might be just by a URL (like in example.com/id=1), filename, domain of S3 volume etc.
In the case of databases being involved, do hackers figure out how the data is stored and read this or do they just figure out how to make queries to the database via the DBMS?
Usually the database is accessed by the typical DB methods (i.e. query from DB client), since this requires less privileges and is thus an much easier attack. It can be done by directly accessing an exposed database, by SQL injection or by an RCE inside a web application. But in case the attacker compromises the whole machine they can also take the database files and extract the actual content later. And in some cases there is also no difference in necessary privileges for accessing data or database files (like with SQLite).
Is accessing the data files less of a mystery for open-source files and thus a possible weakpoint compared to closed-source databases?
The point is usually not closed source vs. open source but how good the database itself is secured, i.e. proper authentication, accessibility only from the local network etc. The database file formats are usually not that much of a secret either also with commercial database engines.
By its very definition of data breach, a database (as in a collection of data), is generally involved.
However, such database could be an expensive Oracle product, a bunch of excel files or a folder containing applicant's CV.
In the case of databases being involved, do hackers figure out how the data is stored and read this or do they just figure out how to make queries to the database via the DBMS?
They will usually make queries via the DBMS.
Is accessing the data files less of a mystery for open-source files and thus a possible weak point compared to closed-source databases?
No. Per Kerckhoffs's principle, you should consider that the enemy knows the system. And in practice, if they have to download the raw files, they will simply install the DBMS locally, no need to know the internal storage format. And before you think a closed-source DBMS could stop them they can easily steal the program with the data, plus commercial dbs usually have demo versions available for free, anyway.
The data is the vulnerability because it's where the value is. The database engine itself holds little value, unless the data stored in it is easy to read. Crooks aren't after the database... they are after the data.
The problem is that in most of the breaches you hear about, the data (passwords, user private data, etc.) was stored insecurely. In general terms, that means the data was stored in clear-text, an unsalted hash, or some other weak form. It's not so much about the application that stored the data (ie. DBMS) as much as it is about how the data was stored within that application.
Whether the data store is a database, flat-file, or other mechanism isn't overly relevant if the data within them is easy to read. So, even if your DBMS was vulnerable in some way, the damage is minimal if the data itself is still unusable. Lesson: encrypt the data before you store it.
Most data storage mechanisms have at least some basic authentication mechanism in place to try and protect the data (ie. username/password). Unfortunately, those mechanisms fail for the same reasons any other username/password based authentication system fails... user passwords are notoriously weak. Storing sensitive data and only protecting it with a password is just bad news all around.
This doesn't change with commercial software vs. open source.
Now, if you change your question to ask whether the application that receives the data is more vulnerable than the data, then things change a bit. Now we're talking about the component in the chain that takes the clear-text data and secures it (ie. encrypting).
A breach there is really bad because the crook would have access to the sensitive data at a point between where it's sent across the network encrypted and when it's encrypted again for local storage.
Is accessing the data files less of a mystery for open-source files and thus a possible weak point compared to closed-source databases?
To this specific point, if an attacker can access your raw database files you're pretty boned. Open vs closed-source won't make a difference, the attacker can simply load your data files with the appropriate database.
Encryption-at-rest will protect you if someone physically walks off with your drives. The attacker will be unable to mount the encrypted partitions without a key. But once the drives are mounted, encryption-at-rest offers no protection.
But there can be a last layer of protection: column-level encryption. Particularly sensitive data can be stored in the database encrypted. Even if the attacker has your data, they still cannot read it without also getting the key.
