0
Common Database Issues: To Look At In Penetration Testing
13 October 2011
by Srinivasan Sundara Rajan
As companies look for more avenues to share and consolidate their capital and operational expenses, the benefits in costs also bring in associated security issues and the need for information security professionals who provide Penetration Testing as a Service.
In this context, testing for security issues at the database level assumes the utmost importance.
• Unlike HTTP or FTP connections between servers, which happen at that instance and don’t persist permanently, database storage is persistent
which means that a hacker has all the time in the world to compromise – not only the current transactions but historical transactions, too.
• In following the best principles of Business Intelligence and Data Management, typically databases store lots of metadata (intelligence about
the data itself), which means any unauthorized access into the database can yield more information for the hackers. For example, assume that
each customer’s credit card information is stored in a child table. By searching the metadata stored in the data dictionary, a hacker can
narrow the list of potential tables holding the credit card information and identify targets more quickly.
• Over the years, with data consolidation, data virtualization and other industry directions, databases serve as the hub of all organizational
information. The transition has meant removal of disparate storage of information and the consolidation at the database level, even collapsing
database servers into a single virtualized platform. While this gives greater control for the enterprise computing, they also add the risk of
exposing potential secrets in a single box for the hackers.
The above points highlight the fact that databases need to be fully guarded against attacks. In this context, the following common database issues give hackers lot of potential openings to gain unauthorized access to the database.
Proper penetration tests against the databases uncover these issues so that they can be remedied in the software development phase and before database systems go to production.
Exposing Internal Database Names / Metadata during Exception Handling : This is common issue even in systems developed with much investment and with an eye on security issues. Most times software developers assume good data conditions, but in practice bad data, locking and other unforeseen issues may provoke database exceptions. When exceptions happen, they may throw SQL error messages on to the front end screens. These messages disclose the internal database objects like table name, procedure name, view name, or even the database identification information. These messages are of no use to the typical end-user, however the hacker might note the vulnerability and use it to exploit the system or its underlying database.
This needs to be avoided, and the error messages should be masked with more user-friendly error messages while not allowing them to guess any further information about the database. In addition, validating the user's inputs ahead of time and preventing the exception when bad data is supplied by the client side will be a better option than allowing the databases to display SQL error messages to the user.
Unprotected Admin Access & Admin Passwords : While most systems build in security to protect unauthorized access from its applications, sometimes it is easy to get into a system with administrative privileges through non-interactive recurring jobs. Most of the admin level jobs run as shell scripts and cron jobs in the back end. These jobs typically run with the same privileges as a database administrator (DBA), which means that these jobs have highest authority on the database.
However these database user names and passwords may be exposed in parameter files as free text, which means if any hacker gains access to them, these databases can be accessed from anywhere. What's worse is that these user names have highest authority on the databases which means the entire security of the database can be compromised.
It is ideal to run the batch jobs and admin level jobs with a wallet security or operating system securities or the assumed security of scheduling tools. This ensures that no user name and password credentials are kept in parameter files and open to attack.
Too Much Exposure To Meta Data : Over the years, best practices in database development have promoted standard naming conventions, common data dictionaries, and comments about a column’s usage as part of the metadata.
While this is a good practice for developers, this also gives the hackers an easier way to figure out the data they wanted.
An example of this is a sensitive table named CREDIT_CARD with a column called CARD_NUMBER and the next column called PIN. While there could be other school of thoughts, avoiding obvious metadata about sensitive information and storing them elsewhere could be worthwhile in today’s security considerations.
Not Encrypting Sensitive Data : Most of the databases that store PII (Personally Identifiable Information) and financially sensitive information may not have encrypted these information and allow them to be seen as free text.
We should ensure as part of penetration testing that all sensitive information is encrypted with desired algorithms and the key for encryption and decryption is not easily guessable. There may be a small performance degradation due to encryption layering, but this is less bothersome than losing important information.
Not Having Fine-Grained Security : Fine-grained security is about ensuring that every user of the application can see only the data that the user is authorized to see. However in many a database query, especially reporting and ad-hoc tools, there are no controls to keep the user from querying the data outside of their boundaries. With the cloud platform and multi-tenancy architectures such as ASP gaining momentum, not preventing the user from accessing others' data will be one of the bigger threats to the database.
All the avenues to query the data outside of user’s authorization boundaries need to be identified and tested as part of penetration testing.
SQL Injection / Exposing Query Manipulation : This is a well-known problem of allowing the user's inputs collected during HTTP calls to be used directly in a SQL query. Due to this issue, a hacker familiar with all the techniques of how a database is queried can manipulate the inputs to change the behavior of the SQL and thereby hack the database.
My earlier article on SaaS & SQL Injection details how SQL Injection can be exploited in a multi-tenant database. No penetration tests would be complete without examining potential SQL injection attacks. The good news is that most of the automated penetration tests detect and report on SQL Injection.
Summary : As stressed earlier, database-related vulnerabilities constitute a major portion of the threats to the organization’s information assets. As evident some of the above type of attacks are common and they needed to be avoided in the run-time environment with better input checking, exception handling, and hiding specific messages that would disclose technical or business metadata. All the penetration tests should target these vulnerabilities so that the information assets of the enterprise are protected. Penetration testing plays a major support in that context.
About the author:
Srinivasan Sundara Rajan works at Hewlett Packard as a MASTER Solution Architect. His primary focus is on enabling SOA through Legacy Modernization for Manufacturing Industries. He has worked as a consultant for Compuware, Verizon and other organizations in the earlier parts of career. He has over 19 years of experience in Architecting multitiered applications for large enterprises. Srinivasan is actively contributing to the Cloud Community as an Evangelist by providing value proposition of cloud for large enterprises. Due to his writing on Cloud, he has been recognized as one of Top 100 bloggers about Cloud Computing and considered as for the Cloud Thought Leadership Series conducted by Robert Duffner (Windows Azure Product Director). Srinivasan also speaking about Cloud in various conferences.
All the views expressed are Srinivasan's independent analysis of industry and solutions and need not necessarily be of his current or past organizations. Srinivasan would like to thank everyone who augmented his Architectural skills with Analytical ideas.
As companies look for more avenues to share and consolidate their capital and operational expenses, the benefits in costs also bring in associated security issues and the need for information security professionals who provide Penetration Testing as a Service.
In this context, testing for security issues at the database level assumes the utmost importance.
• Unlike HTTP or FTP connections between servers, which happen at that instance and don’t persist permanently, database storage is persistent
which means that a hacker has all the time in the world to compromise – not only the current transactions but historical transactions, too.
• In following the best principles of Business Intelligence and Data Management, typically databases store lots of metadata (intelligence about
the data itself), which means any unauthorized access into the database can yield more information for the hackers. For example, assume that
each customer’s credit card information is stored in a child table. By searching the metadata stored in the data dictionary, a hacker can
narrow the list of potential tables holding the credit card information and identify targets more quickly.
• Over the years, with data consolidation, data virtualization and other industry directions, databases serve as the hub of all organizational
information. The transition has meant removal of disparate storage of information and the consolidation at the database level, even collapsing
database servers into a single virtualized platform. While this gives greater control for the enterprise computing, they also add the risk of
exposing potential secrets in a single box for the hackers.
The above points highlight the fact that databases need to be fully guarded against attacks. In this context, the following common database issues give hackers lot of potential openings to gain unauthorized access to the database.
Proper penetration tests against the databases uncover these issues so that they can be remedied in the software development phase and before database systems go to production.
Exposing Internal Database Names / Metadata during Exception Handling : This is common issue even in systems developed with much investment and with an eye on security issues. Most times software developers assume good data conditions, but in practice bad data, locking and other unforeseen issues may provoke database exceptions. When exceptions happen, they may throw SQL error messages on to the front end screens. These messages disclose the internal database objects like table name, procedure name, view name, or even the database identification information. These messages are of no use to the typical end-user, however the hacker might note the vulnerability and use it to exploit the system or its underlying database.
This needs to be avoided, and the error messages should be masked with more user-friendly error messages while not allowing them to guess any further information about the database. In addition, validating the user's inputs ahead of time and preventing the exception when bad data is supplied by the client side will be a better option than allowing the databases to display SQL error messages to the user.
Unprotected Admin Access & Admin Passwords : While most systems build in security to protect unauthorized access from its applications, sometimes it is easy to get into a system with administrative privileges through non-interactive recurring jobs. Most of the admin level jobs run as shell scripts and cron jobs in the back end. These jobs typically run with the same privileges as a database administrator (DBA), which means that these jobs have highest authority on the database.
However these database user names and passwords may be exposed in parameter files as free text, which means if any hacker gains access to them, these databases can be accessed from anywhere. What's worse is that these user names have highest authority on the databases which means the entire security of the database can be compromised.
It is ideal to run the batch jobs and admin level jobs with a wallet security or operating system securities or the assumed security of scheduling tools. This ensures that no user name and password credentials are kept in parameter files and open to attack.
Too Much Exposure To Meta Data : Over the years, best practices in database development have promoted standard naming conventions, common data dictionaries, and comments about a column’s usage as part of the metadata.
While this is a good practice for developers, this also gives the hackers an easier way to figure out the data they wanted.
An example of this is a sensitive table named CREDIT_CARD with a column called CARD_NUMBER and the next column called PIN. While there could be other school of thoughts, avoiding obvious metadata about sensitive information and storing them elsewhere could be worthwhile in today’s security considerations.
Not Encrypting Sensitive Data : Most of the databases that store PII (Personally Identifiable Information) and financially sensitive information may not have encrypted these information and allow them to be seen as free text.
We should ensure as part of penetration testing that all sensitive information is encrypted with desired algorithms and the key for encryption and decryption is not easily guessable. There may be a small performance degradation due to encryption layering, but this is less bothersome than losing important information.
Not Having Fine-Grained Security : Fine-grained security is about ensuring that every user of the application can see only the data that the user is authorized to see. However in many a database query, especially reporting and ad-hoc tools, there are no controls to keep the user from querying the data outside of their boundaries. With the cloud platform and multi-tenancy architectures such as ASP gaining momentum, not preventing the user from accessing others' data will be one of the bigger threats to the database.
All the avenues to query the data outside of user’s authorization boundaries need to be identified and tested as part of penetration testing.
SQL Injection / Exposing Query Manipulation : This is a well-known problem of allowing the user's inputs collected during HTTP calls to be used directly in a SQL query. Due to this issue, a hacker familiar with all the techniques of how a database is queried can manipulate the inputs to change the behavior of the SQL and thereby hack the database.
My earlier article on SaaS & SQL Injection details how SQL Injection can be exploited in a multi-tenant database. No penetration tests would be complete without examining potential SQL injection attacks. The good news is that most of the automated penetration tests detect and report on SQL Injection.
Summary : As stressed earlier, database-related vulnerabilities constitute a major portion of the threats to the organization’s information assets. As evident some of the above type of attacks are common and they needed to be avoided in the run-time environment with better input checking, exception handling, and hiding specific messages that would disclose technical or business metadata. All the penetration tests should target these vulnerabilities so that the information assets of the enterprise are protected. Penetration testing plays a major support in that context.
About the author:
Srinivasan Sundara Rajan works at Hewlett Packard as a MASTER Solution Architect. His primary focus is on enabling SOA through Legacy Modernization for Manufacturing Industries. He has worked as a consultant for Compuware, Verizon and other organizations in the earlier parts of career. He has over 19 years of experience in Architecting multitiered applications for large enterprises. Srinivasan is actively contributing to the Cloud Community as an Evangelist by providing value proposition of cloud for large enterprises. Due to his writing on Cloud, he has been recognized as one of Top 100 bloggers about Cloud Computing and considered as for the Cloud Thought Leadership Series conducted by Robert Duffner (Windows Azure Product Director). Srinivasan also speaking about Cloud in various conferences.
All the views expressed are Srinivasan's independent analysis of industry and solutions and need not necessarily be of his current or past organizations. Srinivasan would like to thank everyone who augmented his Architectural skills with Analytical ideas.
