Security Ranch Security Ranch

February 15, 2021

A study of the cumulative effects of database attacks

Filed under: Uncategorized — Tags: — Ken @ 8:06 pm

Database Attacks:  A Study of the Cumulative Effects of Database Attacks

            One of the first large-scale data breaches occurred in 2005 by American Online, better known as AOL.  From that breach over 92 million records were stolen.  Since then, the news has been peppered with more and more stories about bigger and bigger data breaches.  In 2007, hackers stole 94 million records that contained the customer information from stores such as TJ Max, Marshalls, and Ross.  In 2009 76 million records were stolen from a laptop that had an unencrypted hard drive that belonged to the Department of Veterans Affairs.  More recently in 2014, Target was the target, no pun intended, of hacker that stole 70 million records.  In 2012 the U.S. CERT conducted an analysis of 47,000 incidents and 621 confirmed data breaches and found that finance (37%) and retail companies (15%) led the way in data breaches (Keanini, 2014).  Most recently the U.S Office of Personnel Management lost over 25 million records of individuals that had applied for security clearances over the last 20 years.  Obviously, data breaches are a large problem, and they are only getting worst.  Not worst in the sense in numbers but worst in the type of data that is being stolen.

Since businesses started using computers and mainly since they started conducting their affairs online, there has been an exponential increase of data being collected.  This data runs anywhere from car dealerships collecting the financial data and credit histories of car buyers, lawyers collecting information about cases, and the government collecting information about its employees.  The type of information being collected will usually help determine who the likely hacker’s motivations will be in trying to get that information.  For example if the government is collecting and storing all of the information gathers from an SF86 form, state-sponsored hackers would most likely be the ones trying to steal that information so that they can build dossiers on high-value targets to exploit.  Having past drug convictions or credit histories would be very helpful when attempting to turn an individual into a spy for that country.  Law firms that collect data and store notes about cases would be helpful for the other party to that they could build counter arguments during the trial.  Any of these reasons and more are likely motivations for hackers to steal information from businesses and offices.

One problem that is not being addressed is the cumulative effects that these breaches can have.  The government and most businesses seem to think that these breaches occur in a vacuum and have no other outside effect other than what can be gathered from that data breach.  The problem, however, is that the data collection is so prolific that the normal users use the same answers for security questions, the same passwords, and the same contact information.  Think about it, how many passwords could I reset if I knew a user’s name and just a little information like their mother’s maiden name?  Likely quite a few.  The problem can be even worse for the small to medium companies that don’t have enough money to hire proper information security employees.  If a user were to use the same information from an account with a small company as an account with a larger company thing could quickly get out of hand.  There have been more than a few cases of users having terrible security practices.  These individuals use the same passwords, same usernames, and easy to remember passwords for all of their accounts.  So, when one account is breached the hacker can quickly go to additional accounts and gain unauthorized access to those as well.  We are failing to understand the cumulative effects of the information released from database attacks.

The easiest way for hackers to gain access to the valuable information that companies collect are to attack its databases.  According to a white paper written by Imperva the top three types of attacks on databases for 2015, are excessive and unused privileges, privilege abuse, and input injections (Imperva, 2015).  Input injections replaced SQL injection in 2015 due to the increased use of “big data”, technologies that use NoSQL type technologies.  NoSQL languages like MongoDB (Imperva, 2015), are still susceptible to injection type attacks similar to SQL injection.

Excessive use and unused privileges are the number one vulnerability for databases.  The reasons for this are numerous.  Often, when an employee is hired, they are set up with a new employee account with the permissions that they need to do their job.  As their experience grows, and they get promoted they often keep their older permissions and acquire new permissions for their increased responsibilities.  After some years, these employees may end up having permissions and access to everything the company has.  This happens mostly because of a weak network security policies.  If that employee falls victim to malware and has their account compromised that hacker that has access to that account has access to everything that the employee has.  They may not even have to exploit a vulnerability.  On the other end of the spectrum, if an employee gets fired that employee still has access to everything specified in their permissions.  They may be encouraged to download or delete sensitive data belonging to the company on the databases.  The best practices to mitigate these problems are to routinely audit employee accounts to determine whether or not the employees have the correct permissions.  This would follow a common best practice of “least privilege” (Oriyano, 2010).

Privilege Abuse is the second highest vulnerability to databases.  This can be related to an employee stealing company information in an insider attack.  However, this is also because employees may know how to get around the company policies and abuse the privileges they have, or they can find a workaround to get the permissions they don’t have.  For example, if an employee has permissions to view files but no to overwrite them, they could find a workaround by accessing the file with a different type of program that allows them to change to the information.  This may not always be malicious, but it still can put the company’s assets in jeopardy if a hacker can exploit the same vulnerability.  The best way to mitigate this threat is to ensure that employees have to correct, and necessary rights granted to their accounts.  If employees need extra rights, they can have them granted with some limitations on the time those permissions are granted (Oriyano, 2010).

The third vulnerability to databases are injection attacks.  Better known as SQL injection attacks.  However, as stated previously injection attacks are no longer focused only on SQL database type languages anymore.  With the proliferation of “big data”, NoSQL type languages like MongoDB are now vulnerable to injection attacks.  One of the reasons databases are so vulnerable to injection attacks are that very little money is invested in making them secure.  In 2015, IDC reported that less than 5% of the $27 billion spent on security products directly addressed data center security (Imperva, 2015).  This either shows a lack of knowledge of how vulnerable databases are or that companies fail to assess risks appropriately and after having spent most of their money on development, have little left to devote to secure testing and development.  The best way to mitigate injection attacks are to keep networks and application updated with patches.  Constantly scan for vulnerabilities and if any are found patch them or sandbox them (Smith, 2013).  Malicious web request should be denied by properly configuring firewalls.  Intrusion detection systems (IDS) and intrusion prevention systems (IPS) should also be installed to monitor all database activity (Oriyano, 2010).  If any unusual activity is detected, account should be locked out or denied access until the IT department is notified.  This could stop many of the problems.

So why are databases so targeted by hackers?  Mostly, it is because of the information that is contained in them.  Depending on the hacker’s motivations, a company can understand a lot about the hacker’s motivation and intentions when they steal information from a company.  All of these attacks on company resources are usually to steal information.  If a hacker steals information about future projects, you could deduce that they want the information to sell to a company’s competitors.  Doxing is another recent phenomenon that hackers have started using.  Short for dropping, doxing is the collecting of private information about a company or individual and then releasing it to the public (C.S-W, 2014).  Doxing a target is used to shame them or to extort money from them.  A hacker group called Anonymous was famous for Doxing several companies or organizations (Zetter, 2014).  In fact, the recent attack on Sony Corporation in 2014 was a prime example of a doxing attack on a company.  North Korea decided to hack into Sony’s networks because of a movie that was to be released about the killing of their leader Kim Jong Un.  The hackers broke into Sony’s networks and stole hundreds of gigs of data and then release them onto the Internet.  This was an embarrassment to Sony because to the information that was released on emails.  These emails contained several negative remarks about actors and actresses on upcoming movies.  Amy Pascal, a Sony Co-chairman was fired because of the information released in this attack.

The recent data breach on the U.S. government’s Office of Personnel Management (OPM) found that over 25 million records were copied and stolen.  This information included all the information on the notorious SF86 form.  This is the form that someone needs to fill out that is used for background checks.  All drug histories, convictions, and citations, and employment history is included.  The U.S. government is pretty sure that the attack came from China.  Espionage, in this case, would probably be the motivation.  Almost any country would love to obtain this type of information so as to build dossiers on individuals to attempt to blackmail them for information or to turn them into spies (Austin, 2015).

The most common motivations for hackers to steal information on databases is identity theft.  Most identity theft if focused on stealing money.  If hackers steal health insurance information, it is likely to steal money by charging for false insurance claims.  If the hackers steal information from an e-commerce site, it likely is to make purchases with stolen identities.  In 2012, identity theft cost the U.S. 24.7 billion dollars (Rotter, 2014).

In 2015, the Internal Revenue Service (IRS), disclosed that they discovered that 104,000 transcripts were released of individuals that did not request them (Harney, 2015).  The IRS has since pulled the “Get transcript” button from their website.  It seems that the hackers were able to obtain the transcripts by following the normal procedure needed to get a transcript.  To get a transcript, an individual needs to have their Social Security Number (SSN), email address, and some other personal information.  None of this information would be difficult to get considering the millions of different records that have been stolen in recent years.  Even more information can be purchased online on the black market website that sell stolen information.  A document from Dell SecureWorks found that you could get reliable account information to include the account number of credit cards for as little as nine dollars each (Dell, 2014).  You could also buy Distributed Denial of Service (DDoS) attacks or Dox attacks for just as little (Dell, 2014).  The information could have also been stolen from mortgage companies by stealing a form called 4506-T from mortgage companies.  This form is what the mortgage companies’ use when going thru a third party vendor to have access to IRS transcripts via Income Verification Express Service (IVES).  The IRS was only able to discover this breach because over 35,000 account holders have already filed their taxes.  An attempt was made on over 200,000 accounts, but only 104,000 were successful (Warren, 2015).

This breach shows an easily exploitable weakness in the way website verify identity online.  Plus with almost every single website requiring someone to sign up or register for an account, users are having difficulties remembering their account passwords and usernames.  This leads to users recycling the same usernames and passwords over and over again.  Massive Data breaches do not leak data in isolation.  Each time personal data is leaked it makes users more vulnerable to these types of information theft.  The solutions to help mitigate these problems are two-fold.  On the user side, users need to learn and understand the threats and risks of how they operate online.  On the development side, developers need to learn and use secure coding practices to avoid injection attacks and other exploits.  System Administrators and network operators need to stay vigilant and constantly update and scan networks for vulnerabilities to patch anything that is discovered.  Most of these solutions do not cost much, are mostly knowledge based, and can make for a much more secure online environment.

References

Warren, Z. (2015). IRS a data breach victim, 104,000 taxpayers’ records stolen. Inside Counsel.      Breaking News, Retrieved from http://search.proquest.com/docview/1683739992?accountid=8289

Keanini, T. K. (2014). Security: Beyond Target and Neiman Marcus More of the Same Everywhere Else. Database and Network Journal, 44(2), 6.

C.S-W (2014). What doxing is, and why it matters: The Economist explains. London: The Economist Newspaper NA, Inc.

Rotter, Kimberly. (2014). The staggering cost of identity theft in America. Credit Sesame. Retrieved from http://www.creditsesame.com/blog/staggering-costs-of-identity-theft/

Dell Secureworks (2014). Underground Hacker Markets. Dell Secureworks. Retrieved from http://www.secureworks.com/assets/pdf-store/white-papers/wp-underground-hacking-report.pdf

Harney, Kenneth. (2015). IRS data breach may prove worrisome for those seeking a mortgage. The Washington Post. Retrieved from https://www.washingtonpost.com/realestate/irs-was-told-in-2011-that-its-security-and-privacy-controls-were-inadequate/2015/06/01/de42884a-0886-11e5-95fd-d580f1c5d44e_story.html

Zetter, Kim. (2014). Sony got hacked hard:  Here’s what we know and don’t know so far.  Wired.  Retrieved from http://www.wired.com/2014/12/sony-hack-what-we-know/

Oriyano, S. (2010). Hacker Techniques, Tools, and Incident Handling. Sudbury, MA: Jones & Bartlett Learning.

Smith, R. (2013). Elementary Information Security. Burlington, MA: Jones & Bartlett Learning.

Austin, Ernie. (2015). Stolen Security Clearance Information Has Potential for Blackmail. Rockaway: Advantage Business Media.

Database Security Best Practices

Filed under: Uncategorized — Tags: , — Ken @ 8:05 pm

Database Security Best Practices

            So far, in the year 2017, there has been a vast number of data breaches that have affected an astronomical number of user accounts.  A lot of the data exposed in these data breaches came from databases not being secured.  From Verizon, 14 million records of customers were exposed when they were left exposed on an Amazon S3 storage server (Wittaker, 2017) to the more recent Equifax data breach, a large number of these data breaches could have been prevented had the companies followed the current best practices on how to secure and harden databases.

Three of the most popular database applications used today are Oracle Database (Oracle), Microsoft SQL, and MySQL each have their ways to be secured against hackers.  The first database that will be covered is the Oracle database.  One of the first things that a database administrator (DBA) needs to do once the database is installed is to lock down the default accounts.  These default accounts have privileged access to defined preset values that are common knowledge to hackers and IT professionals.  The DBA can use the Oracle Database Configuration Assistant (DBCA) to automatically lock or expire the default accounts (Stark, 2012).  Updating and patching the Oracle DB is the next critical step in securing the database.  If the updates are not applied almost immediately the database will be exposed to well-known security vulnerabilities.  The next step is the reduce the attack surface by removing all unnecessary privileges from public roles.  There are specific functions that exist in Oracle that belong to a role called PUBLIC.  PUBLIC roles belong to every account user, and that is where the problem lies.  By eliminating services that belong in the PUBLIC roles, DBA can follow the principle of least privilege better by only allowing users the permissions they need to do their jobs.  Next, auditing should be enabled to allow Oracle to log SQL commands (Stark, 2012).  This is not enabled by default so if a security incident occurs, it will be more difficult to understand what happened.  Another good practice involves setting up database triggers that log and audit changes in the database schema.  A database schema in Oracle is the logical container for data structures.  Examples of schema objects are tables or indexes (Ashdown, 2010).  By setting up certain triggers, you can audit logs to find out who logged on and what changes were made to the schema.  This can be helpful for when a DBA makes changes that affect the functionality of the databases or when hackers make changes to the DB.  Password Management is another practice that should be enabled for all accounts.  The same password policies that you would use in Microsoft Active Directory could be applied here.  It is important to know that the default accounts do not have password management enabled on them (Stark, 2012).  The last best practice for securing Oracle databases is enabling encryption.  Oracle database supports the Federal Information Processing Standard (FIPS) encryption algorithm Advanced Encryption Standard (AES).  Enabling encryption ensures that the data sent from the database to the user is in the ciphertext and not plaintext (Huey, 2017).

The next major database used is MySQL.  One of the first things a DBA wants to do to secure the database server is to update and apply any security patches that are needed.  On top of that, the administrator should also update the Anti-virus and Anti-spam software as well as the OS itself that is running on the server.  Another consideration is remote access.  If remote access is not needed that feature should be disabled.  If remote access is needed you should configure the firewall only to allow that specific account and possibly computer to have remote access to the database.  To prevent unauthorized reading from local files, the DBA should disable the use of the command LOAD DATA LOCAL INFILE (Maman, 2015).  A one-way hacker can exploit this is by using the LOAD DATA LOCAL INFILE to read the /etc/passwd file into another table.  This would give the hacker access to all of the user accounts with passwords.  A fourth task for the DBA to do is to change the name of the administrator’s account.  By default, the account name is root and is well known as a common name for the admin account.  If the hacker gains access to the root account, they have access to the entire database.  If there are any old, anonymous, or obsolete accounts, those accounts should be removed and deleted.  By default, anonymous users accounts can exist without any passwords.  If this is left open, it would be easy to exploit.  The next thing that the DBA should implement is the principle of least privilege.  This reduces the attack surface for each account.  As with the Oracle database, the DBA should enable logging so that certain events can be monitored such as error logging.  Lastly, the database administrator should ensure that the data is encrypted.

The third major database application is Microsoft SQL.  Once the SQL server is installed, the DBA should begin hardening the server.  The administrator can use the SQL Server Configuration Manager tool to disable or remove any features or services that are not planned to be used.  This tool reduces the attacks surface and makes it less vulnerable to attacks.  Windows Authentication mode should be used over the built-in SQL authentication.  This is due to how the Windows authentication mode integrates with the Active Directory.  If the Windows Authentication mode is used, all of the security policies that are created within Active Directory can apply to the SQL server.   Otherwise, if SQL Authentication is used the DBA will have to create separate user accounts and recreate the account infrastructure.  This adds to the complexity of maintaining the user accounts so it should not be used.  The SA account should be disabled and renamed.  This will stop a hacker from searching for this account.  Instead, create new administrator accounts and use Role Based Access Controls (RBAC) to prevent anyone account from having access to everything (Ferraiolo Kuhn, 2017).  Security by obscurity is not an actual security control. However, it can make the hacker’s job more difficult.  So, the DBA should also consider changing the default ports used by the SQL server (Maman, 2015).  The administrators should also hide the SQL server instances or disable the SQL Server Browser service.

Securing and hardening the database will go a long way in securing the data that is used on the network but it is not the only thing that needs to be secured.  Using the concept of In-depth security the database can be secured even further.  There are several organizations that develop a list on how to secure the network.  SANS has a Top 20 Critical Security Controls list that is vendor neutral on how to secure computer systems.  SANS is a for-profit organization that develops cybersecurity and information security training and offers certifications for those courses.  SANS also created the Center for Internet Security where they created the SANS Top 20 Security Controls list.

The SANS Top 20 list is pretty though, and it is designed to be started on control number 1 and followed to control 20.  CSC 1 and 2 cover inventorying of all authorized and unauthorized devices and software on the network.  Because of the popularity of BYOD devices, it can become difficult for an administrator to know what is happening on their network.  If you do not know what is on your network, you can secure it.  CSC 3 deals with secure configuration for hardware and software on mobile devices, laptops, workstations, and servers.  After you understand what you have on your network, you can use the best-known security practices to harden those devices.  CSC 5 is the controlled use of administrative privileges.  This is also known as the principle of least privilege and needs to know.  By keeping the privileges in check and only giving those privileges to a small number of user accounts you can limit the exposure that the network has to vulnerabilities.  CSC 6 is maintenance, monitoring, and analysis of audit logs.  This control deals with how to setup and audit logs so that you can detect intrusions or security events if they happen.  CSC 7 establishes email and web browser protections.  Some of the actions in this control are to reduce the surface area of attacks by disabling or removing any services that you do not use.  CSC 8 is malware defenses.  Actions in this control are installing Anti-virus software, firewalls, and intrusion detection/ prevention systems.  CSC 9 is the limitation and control of network ports, protocols, and services.  Port security and management allows the network to turn off any unused ports so that no rouge devices can be installed.  Workstations and servers can also be assigned specific ports to use so that if they are moved, they will not have access.  CSC 10 deals with data recovery capability.  CSC 11 controls the secure configurations for network devices.  CSC 12 establishes controls for boundary defense.  This is where firewalls are configured, and DMZs are established.  CSC 13 deals with data protection.  This controls how encryption is used on the network.  CSC 14 controls access based on the need to know.  CSC 15 covers the use of wireless access points.  This is important today because of the use of cell phones and wireless printers.  CSC 16 establishes controls for account monitoring.  Security policies effective this control.  For Microsoft Server, it is easy to control and monitor accounts with Active Directory.  CSC 17 sets up security skills assessment and creates training for employees to fill in gaps in training and knowledge.  CSC 18 is application software security.  The OWASP Top ten list for application security can be used here.  CSC 19 established incident response and management.  Lastly, CSC 20 covers penetration testing and red team exercises.  As the IT security team works their way thru this list, their entire network will be more secure.  Not only the databases but the computers, networking devices, and the applications that access the data within the databases.

One of the trends of late has been that hackers have targeted databases.  Two reasons that hackers have target databases are that the databases have an enormous amount of data within them.  The other reason is that companies often overlook securing the databases because they are concentrating so much on application security and perimeter security.  System and database administrators are also sometimes reluctant to make any changes to the database because everything works and they do not want to make changes that could break the functionality.  From the Verizon 2010 Data Breach Investigations Report insiders are the cause of 46% of the data breaches.  The insiders do this by abusing their privileges (Barnes, n.d.).  By using the least privilege principle and continuously monitoring log files a company could prevent a lot of the insider threats.  It was also noted in the report that the stolen credentials were the second highest exploit used in the database breaches (Barnes, n.d.).  The first was SQL injection attacks.  SQL injection attacks have also been on the OWASP top ten list for the past several years.  Some other impressive statistics from the Verizon report were that 96% of the breaches in 2009 could have been prevented through the use of simple controls.  79% of organizations that had credit card data breaches in 2009 had failed their last PCI audit (Branes, n.d.).

Today, while we always hear about vulnerabilities like SQL injection, Cross-Site Scripting, and Distributed Denial of Service (DDoS) attacks, etc.  It is important to understand that most of those vulnerabilities are external to the databases themselves.  The risks that lie in the databases are more straightforward.  Poor password policies and practice, missing or unpatched databases, misconfigured databases, and excessive privileges are what the databases are exposed to.  Those vulnerabilities are neither complex nor are they difficult to fix.  By taking the time before the installation begins to understand the risks and vulnerabilities the IT administrators can implement policies and processes to mitigate those threats before they even begin.

References

Wittaker, Zack. (September 2017).  2017’s biggest hacks, leaks, and data breaches – so far.  Retrieved from http://www.zdnet.com/pictures/biggest-hacks-leaks-and-data-breaches-2017/3/

Stark, Chris.  (March 2012).  Top 10 Oracle Steps to a Secure Oracle Database Server.  Retrieved from http://blog.opensecurityresearch.com/2012/03/top-10-oracle-steps-to-secure-oracle.html

Ashdown, Lance. Kyle, Tom. (February 2010).  Oracle Database Concepts 11g Release 2 (11.2).  Retrieved from http://docs.oracle.com/cd/E29505_01/server.1111/e25789/tablecls.htm#CNCPT111

Huey, Patricia.  (April 2017).  Configuring Network Data Encryption and Integrity.  Retrieved from http://docs.oracle.com/database/122/DBSEG/configuring-network-data-encryption-and-integrity.htm#DBSEG9593

Maman, David.  (October 2015).  MySQL database – The world’s most popular open source database.  Retrieved from http://www.hexatier.com/mysql-database-security-best-practices/

Maman, David.  (October 2015).  Microsoft SQL Server Database Security Best Practices.  Retrieved from http://www.hexatier.com/microsoft-sql-server-database-security-best-practices/

Ferraiolo, David.  Kuhn, Rick.  (September 2017).  Role Based Access Control.  Retrieved from https://csrc.nist.gov/projects/role-based-access-control

Barnes, Rob. (n.d.).  Database Security and Auditing:  Leading Practises.  Retrieved from   http://www.bhamisaca.com/images/Database_Security_and_Auditing_Best_Practices.pdf

Powered by WordPress