If you work in the web application security or information security industry, for sure you have heard about the latest ebay hack attack. This article looks into what might have happened and highlights a few points that help you keep malicious hackers at bay.
It all started when ebay posted a message asking all of its users to change their passwords due to a data breach their corporate infrastructure has suffered. The data breach was from a database which contained sensitive information. Quoting ebay;
"The database which was compromised between late February and early March, included eBay customers’ name, encrypted password, email address, physical address, phone number and date of birth. However, the database did not contain financial information or other confidential personal information."
Definitely! Such attacks can always be avoided hence why we need to learn from them. To start off with, it could be debated whether two-factor authentication could have proven to lessen the impact caused by this security breach. But what if the malicious hacker managed to gain access to the two-factor authentication tokens as well, especially if the database server and web server resided on the same machine?
The company also stated that "Cyberattackers compromised a small number of employee log-in credentials, allowing unauthorized access to eBay's corporate network". There are lots of possibilities how employee's account might have been compromised; the attacker might have launched a social engineering attack against the employees by tricking them into executing a malicious file. Or possibly the attacker exploited a cross-site scripting attack to impersonate the employees.
It is also possible that the attacker compromised the database of a specific ebay application, which in return revealed the employees’ login credentials, which could be used to gain access to ebay's infrastructure.
Till now ebay have not disclosed technical information of how the malicious attackers managed to obtain employees credentials. Though as history has thought us most of the breaches start by a social engineering attack, or by exploiting web application vulnerabilities. A single vulnerable application within the infrastructure could lead to a full compromise of the web servers, database servers and all the infrastructure as happened some years ago when the Apache foundation servers were hacked. With that being said, here are some necessary steps you must take to secure your web servers, database servers and the whole web farm.
This is the first layer of security that should be applied. The operating system on which the web servers, database servers and all other network services run should be always updated with the latest security patches. Along with it, the actual software also needs to be updated.
This might be a common sense security best practise for many, but lots of security incidents and breaches that happen till this day still occur due to the use of unpatched software or operating systems.
Web servers typically reside in the DMZ (Demilitarized Zone), which is exposed to untrusted networks where anonymous users (a.k.a. website visitors) can interact with the web servers and send data to it, thus making it more prone to attacks. If your web server is compromised, and the database server is installed on the same server the chances of the attacker gaining access to the database are very high.
Hence having separate servers for different roles increases the security of your web farm and also improves damage limitations should one of the servers be hacked. Apart from just improving security, there are also performance and scalability factors your infrastructure can benefit from when running a database server and a web server on different boxes.
When installing a database server, web server or any other type of network service you should always follow the "Principle of Least Privilege". This means that your web server should only be granted the least possible privileges to access the database. It should not have any administrative rights to make changes to the database structure, such as drop table; most of the time the web server only needs read and write access.
Many make the mistakes of assigning more privileges than needed because “it always works”. In this case it is better to spend a few extra hours testing the setup rather than granting full access to a network service and being hacked. This also helps to limit the damage in case one of the servers has been hacked into.
Ideally all servers in the web farm, such as web servers and database servers should only be accessible from the local network; admin interfaces should not be accessible from the internet.
In case remote access is required make sure that only handful number of IP addresses should be able to access administrative interfaces by using whitelisting. Remote connections should be established by using a cryptographically secured mechanism such as SSH or virtual private networks.
Another handy tip that is typically overlooked, educate all employees to not use public computers connected to insecure wireless access points to connect to the corporate network and infrastructure.
By default a server operating system installation has a number of network services such as FTP, DNS, SMTP enabled. Shut down and if possible disable or uninstall any network services that won’t be used on the server. The more network services you have running on the server the more possible point of entries and exploitation a malicious attacker has.
While shared hosting might be the cheapest solution, if an attacker manages to gain access to another site on the same server, the attacker will have direct access to your web server or database server. Shared hosting is not for anyone who is serious about web security. For a more detailed explanation of all the disadvantages shared hosting has in terms of web application security read Shared Hosting and Web Application Security – The Opposites.
As mentioned before, most of the security breaches occur due to an exploitable web application vulnerability. With that being said, encourage everyone involved in the design, development and testing of web applications to use a web vulnerability scanner to automatically detect critical vulnerabilities such as SQL Injection and Cross Site Scripting vulnerabilities.
Ideally businesses should also have a staging server where new code and website changes are tested and scanned for vulnerabilities before they are uploaded to the live server.
Log files are not generated just to consume hard disk space. The use of log files is to frequently analyse them so you can identify any suspicious behaviour and potentially block an attack before it actually happens.
Ideally log files should be stored in a segregated area so malicious users cannot tamper with them in case there is an attack, hence allowing you to trace back all malicious activity to identify the problem and close down any security hole the attacker exploited.
Also, frequent auditing of systems and web applications is a must. What is secure today might not be secure tomorrow. New attack variants and exploits are discovered on a daily basis and only by using the latest tools and scanners you can ensure that your whole infrastructure is secure.
Last but not least, keep yourself informed! Tools are handy and they do help you securing down a web server farm and web applications, but staying informed keeps you a step ahead of the malicious attackers. The internet is full of web security articles and you should subscribe to security blogs and newsletters to keep yourself informed.
If a new type of attack is trending on the internet and you are well informed about it, you can check upfront if your web applications are vulnerable to such type of attack. Also, web applications and their security are evolving every day; hence by keeping yourself informed you are always well equipped with the knowledge needed to secure web applications and web farms.