Open and Exposed Databases: Risks and Mitigation Techniques Explained
Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version. Databases are among the most important parts of a web application. Almost every action performed on your web application involves using a database in some form to determine what to perform next, to store a user's input, or to give a user information. These three user interactions form the most essential functions that a web application performs. Databases often contain tons of valuable information, including usernames, passwords, email, IDs, addresses, phone numbers, and much more. This treasure trove, however, also makes the database one of the most targeted parts of a web application. Looking at some of the largest database breaches in history further emphasizes just how valuable the information stored within your organization's database can be. And database hacks are not always sophisticated hacks that occur due to software code faults. Frequently, the simple yet fatal misconfiguration of a database's operation is the root cause of data breaches. Hello Elasticsearch Some of the most common database hacks include the use of Elasticsearch, a popular database that is highly efficient at storing large amounts of data as well as analyzing and visualizing the data it stores. This makes it super popular within organizations that have a lot of logging or other large data to be analyzed. Elasticsearch by default binds to localhost only, which is secure enough, but to make Elasticsearch usable in an organization, database administrators often make the mistake of binding Elasticsearch to the public network interface without firewalling it. While this may seem normal at first, keep in mind that Elasticsearch has no default user authentication setup on it. Manual configuration is required to enable the xpack module which then allows one to set up a password based authentication on Elasticsearch. The above misconfiguration allows attackers to simply enter, delete data, steal data, and exit. Again, there is simply no way to determine whether a user is a hacker or not. This simple flaw has caused a countless number of hacks within Elasticsearch over the years and continues to do so even today. Security breaches caused due to database compromises can lead to loss of data as well. At times, data is not only stolen but also destroyed by attackers. Read more about data loss prevention here. Now, let's take a closer look at how to identify open and exposed databases. Consequences of a database breach The consequences of a database breach are extensive and often seen as a critical cause of trust issues in any web application. Because databases often contain sensitive information like first and last names, home addresses, personal phone numbers, and other information that is shared in confidence, leaks of such data are perceived as negative and highly harmful, leading to trust issues and customer departures from compromised web applications. Another facet of database breaches is the threat of silent attacks. These involve attackers making minor changes to a database in order to gather or steal data over a long period of time and also to compromise targeted accounts. This was often seen in cryptocurrency exchanges in the past, wherein user accounts would get compromised and funds stolen, as well is as in advanced persistent threats (APT). With newer laws coming into place such as the GDPR (in Europe), ICO (in the UK) and various other regional laws, dealing with breaches can also involve legal consequences and financial fines. These laws require companies operating within those regions to report breaches within 24 hours or less. Failure to do so can incur larger fines and other legal consequences. However, beyond laws, legal consequences, and financial losses, your reputation is the most important aspect of your web application. It is essentially what drives users to your platform, makes them stay, and prompts them to recommend it ...