The Data You‘ve Left Behind – an Attacker‘s Perspective

Some of the data is data we presently work with, while some of the data amounts to our older projects – projects we have most likely reworked, buried, learned from, and projects that never saw the light of day. All of that data is very important – partly because we‘ve learned how to build more powerful applications, but it‘s also very valuable for an attacker that‘s interested in stealing everything we‘ve worked so hard for. In this blog, we will take you through the darker alley of your data – from an attacker‘s perspective.

What‘s Important For the Attacker?

No matter what kind of project you find yourself working on, always keep in mind that attackers are after a couple of things:

• The data related to the customers using the product – such data frequently consists of email addresses, usernames, and IP addresses. All of those data classes are vital to attackers because they can be used to mount identity theft attacks. Identity theft attacks usually lead to data breaches of other services as well and the cycle repeats.
• The data related to the product itself – such data includes data related to the intellectual property of the company: depending on the aim of the attacker, they might be interested in how the product is built, what kind of technology is in use, whether a website the product is based on is running outdated software, etc.
• Any data that should have been deleted, but hasn‘t – such data may include data from archives, backups, or other services related to the product that are easily accessible online (think CDNs, unsecured backup storage locations, etc.)

All attackers are interested in the data that the company owns, as well as the data that has been „left behind“, so to speak. That‘s why we should always strive not only to protect our application but protect our database from upcoming threats as well.

What‘s Important for Us?

Just as there are things that are vital for an attacker to focus on, there are things developers and data analysts should focus on as well. Some of the things we should focus on should obviously include the security of our application and databases, not storing unnecessary data inside of the databases, and, if deemed necessary, taking care of certifying the application with ISO 27001, HIPAA, or other certificates, depending on the industry that the product is operating in.

However, as time goes on we will probably notice that some things are of more importance than others – one of the most crucial things for us to focus on would be databases and the data within them.

The Data Left Behind in Your Databases

There‘s a good reason security and privacy experts advise us to follow security regulations like GDPR, ISO 27001 and the like – such security regulations put stringent requirements on how should a company deal with data and secure it and some of the regulations (especially GDPR) are especially strict about storing unnecessary data - the more unnecessary data we leave behind unattended, the easier it is for an attacker to cause harm to our systems.

There’s no need to worry, though - a little bit of knowledge about application security and knowing your way around SQL clients will come a long way. Proper SQL clients come with the following features to help us deal with data:

• They make it easy for us to import data into our database of choice.
• Most of them let us observe the tables, columns, events, and triggers related to a certain database. Some SQL clients also let us observe stored procedures and do other things. Here‘s how everything looks like when DbVisualizer is being used:

SQL clients provide us with everything necessary to ensure the availability, security, and performance of our database instances – no matter what kind of DBMS we‘re running, a good SQL client supports them all and then some. All good SQL clients will provide us with the ability to view the data types specific to our tables, and some will even let us edit the data within our tables like a spreadsheet.

We should be very careful with data, though – while on one front it can be useful for certain operations, we can rest assured that any data left behind in a database can be re-used to target another application once a data breach occurs. That‘s why unattended data left behind serves another purpose for an attacker – the more such data a company possesses, the bigger the possibility of a successful credential-stuffing attack.

Credential stuffing attacks are often a direct result of attackers abusing the data stolen from other systems – it‘s an attack where credentials stolen from one service are used to access another, often unrelated, service as well.

To avoid such attacks, make sure that an application you‘re working with follows stringent security standards, and if you find yourself using SQL clients like DbVisualizer, keep an eye out for their ability to provide you with other things that help you identify possible indicators of compromise or prevent a compromise from occurring altogether. These things might contain one or more of the following:

• A SQL history table – such tables depicting the history of various SQL queries are necessary to identify whether our database or application got breached – see any unknown, suspicious queries? Was any data added, modified, or deleted? Possible compromise right then and there. A SQL history table is a breach identification measure.

• The ability to view and change the privileges related to certain databases, tables, or their columns - as privileges are one of the cornerstones of the security of your database, ensuring that only specific privileges are assigned to a specific user or even a column goes a long way. In this case, we can see that all columns have the SELECT, INSERT, UPDATE, and REFERENCES privileges - refer to the documentation of your database management system of choice, figure out what the necessary privileges are used for, and assign them accordingly. The ability to observe privileges is a data breach prevention measure: it helps us employ the need-to-know principle which fends-off attacks when they are about to occur.

• The ability to securely connect to database instances – when we connect to a database in question without using SSH, we might be leaving our username and password open for everyone to see by observing the list of previously executed commands via the Terminal. If an attacker finds a way to access the server via the terminal, but he cannot see any of the previously executed commands some of which may be deemed sensitive, that‘s already a win. The option of setting up access via SSH is a data breach prevention measure.

• Finally, keep in mind that DbVisualizer also offers its users the ability to configure permissions for certain types of queries – DbVisualizer can allow us to run certain queries only in test environments, some in production environments, some in both, etc. DbVisualizer comes with a couple of available options:

• Configuring an „Allow“ option for any of the environments (Development, Test, or Production) lets the query roam without being disturbed.
• Configuring an „Ask“ option will ask the user whether to execute the SQL query in question before executing it and
• Configuring a „Deny“ option will deny the query execution process altogether. If you find yourself using DbVisualizer, keep this feature in mind - these options are a necessity to ensure the highest degree of security for our database instances because their configuration is the primer of the „must-know“ principle in security: people should only know the information that is absolutely required to fulfill their on-the-job duties, but no more than that.
  
  All options can also be configured for parts of the application: some of the permissions work within the realm of the SQL commander, some work within the table data editor, some work within the procedure editor, and some only work as far as the connection to databases is concerned. Each of them allow us to secure a part of our database: The permissions option can be used as a data breach prevention measure: however, be advised that the feature is only available within the realm of DbVisualizer.

If a certain type of query is set to „Ask“ or „Confirm“, DbVisualizer will ask for confirmation in the environment that was defined:

Combining these three options will help you defend from potential credential stuffing attacks – of course, simply using a SQL client will not cut the chase, so additionally, please make sure that your web application follows all of the necessary web security standards (GDPR, ISO 27001, HIPAA if the company you work at is in the healthcare business, etc.) and you should be good to go.

We hope that you‘ve learned something useful from this blog and that you will come back to the blog of DbVisualizer, and until next time!