Given the number of recent breaches in web sites, managers want to improve security. However, a manager ordering that all security problems be eliminated from a web site will have no more effect than King Canute ordering the rising tide to halt. You have to assume that things will break and then make sure that there are additional safeguards that will still prevent attackers from gaining control of the system after a single failure. You also have to seriously evaluate all possible attacks, even though this may make you seem slightly paranoid.
That is the true cause of the Equifax failure, which was caused by an unpatched flaw in the Struts software allowing malformed HTTP requests to cause the execution of code on the computer housing the web site.(Fox-Brewster, Newman) Lots of articles and white papers have been written describing the “true underlying cause” of the incident and how to stop it in the future.
- Providers of firewalls will tell you that their firewall will check for malformed requests and would have prevented the problem by rejecting the malicious requests.
- Other providers will check the versions of the software modules that you download from the internet and flag versions that have known problems.
- No matter what they sell, vendors will find some way of claiming that their product will prevent future attacks.
There are usually several problems with these claims.
- How do you know that the vulnerability will have been publicly reported before it is used to attack your system? Zero day defects are by definition not known to the public before they are used.
- Even if a patch is available, there is still a very real danger that installing the patch without testing will introduce other problems. Any administrator who hasn’t had problems installing patches hasn’t worked with computers very long.
- There are many avenues of attack upon a system. Some involve hacking from the outside and others involve gaining physical access and hacking from the inside.
- Purchasing these products without a full security review can provide a false sense of security.
Finally, you should remember the following.
- It’s not paranoia if people are out to get you.
- If you actually believe that the security on your system is good enough, it isn’t.
- Security done “on the cheap” is generally very poor security.
- Expensive security is not necessarily good security.
- For those who believe that security can be achieved by keeping facts secret, you should remember Benjamin Franklin’s comment on the subject: “Three can keep a secret, if two of them are dead”.(Gawalt) You have to assume that there is a good chance that attackers will learn your secrets and plan accordingly.
- You will have to consider how you will maintain security if attackers discover vulnerabilities that enable them to compromise parts of your system.
The following is a typical and very simple layout for web sites. From a security standpoint, it is very poor.
- The application appears to users as a web site with account name and password serving to gain access to the application.
- Administrators can also log on as a remote shell user using Telnet of SSH. Access is controlled by using the account names and passwords on the computer.
- An additional option is for administrators to log on to the database as a database administrator. This usually uses a special website that is part of the database. Access is controlled by using an account name and password that belongs to the database.
In this simple layout, the application server and database are located on the same computer, and security is completely based on knowing the account names and passwords. There are a number of reasons why this is not adequate.
1. The database contains information whose exposure could be disastrous the company, while the application server is subject to frequent changes that may have to be installed on short notice. Valuable information means that you have to have a robust testing regime involving both manual and automated steps. Frequent changes means that it has to done frequently, increasing expense.
2. There have been a number of remote execution exploits on web servers, application servers, and other pieces of software, and there will be more in the future. You have to assume that vulnerabilities exist that nobody knows about.
3. You also have to plan for the possibility that a malicious actor knows the administrative account names and passwords.
4. The application server sends SQL commands directly to the database. If the application server is compromised, the attacker can send any SQL commands to the database.
5. An attacker with operating system access with administrative privileges can do almost anything to the computer. He can also hide his actions.
Hardening the System
The military protect facilities with multiple lines of defense. If the enemy overcomes the first line of defense, they still have to go through additional lines of defense before they can do serious damage.One way of hardening the system is to divide it into subnets, with formal rules for passing information between the subnets.
Consider the construction of a bank building. It is divided into multiple regions: vaults, public areas, areas for meetings, and employee only areas.It helps to think of the computer systems as castles with multiple rings of protective walls with guarded doors in the walls for data passing through the rings. In order to prevent attacks from malicious actors, you are going to have to harden the system. In order to demonstrate the concept, I prepared a second figure showing a somewhat hardened configuration. In this case, the web site is divided between multiple subnets and various methods are used to prevent malicious actions.
- Administration of the system is carried out by members of an internal intranet which will be used for development, test, and configuration of the web site. For the purpose of later discussion, this will be designated as the IT intranet.
- The demilitarized zone (DMZ) subnet faces the public internet and generates the web pages seen by the users. Requests are evaluated by the application server and valid requests are then passed to the production subnet using a well-defined set of protocols. Sensitive information is not stored in this system.
- The production subnet contains the actual database and an aplication server that processes the requests from the DMZ. This application server then generates the SQL commands, executes them, and passes the information back to the DMZ.
By dividing the complete system into subnets with controlled interfaces, the subnets can be analyzed for security independently. Since each individual subnet is small and simpler, analysis can be carried out using formal proofs. So the next step is to consider the actual protection that can be applied to the individual computers and the effect that they will have in securing the system.
Access to the DMZ and production subnets will be controlled by routers using access control lists. This will insure that messages coming from a given subnet are actually coming from the specified subnet. This moves the authentication from “what you know” to “what you are”.
The firewall for the server in the DMZ is set up so that access to the operating system (Telnet, SSH, X-Windows, Remote Desktop Login, etc.) can only be obtained from the IT subnet. Even if attackers from the public internet know the account name and password, they will be unable to gain access.
Protection for the application server will involve the use of filters. Requests into the server can be checked for correct format so that attacks involving corrupted messages can be intercepted. Outgoing responses can also be examined so that unexpected error or warning messages can be intercepted.
The application server will not contain the administrative, user, or database account names and passwords. This means that an attacker who has taken over the server will be unable to insert SQL code. Since the damage from a vulnerability is limited, the software on this server is more suited to automated testing and DevOps environments. This is important because it is expected that the code on this node will be changed frequently.
Attempts to penetrate the node on the protection subnet using compromised machines on the DMZ subnet will normally require modification of files on the DMZ node. This means that comparison of the files on the DMZ node against a known “good” version of the files has a very good chance of detecting intrusions. This means that the amount of time that an attacker has to penetrate the production nodes is very limited.
The database is stored on the production server and contains the critical data that the attacker would be looking for. Therefore, this is the node that needs the most hardening and security review.
- Database accounts on MySQL can be set up so that the requests can only come from selected IP addresses. In this case, the accounts would be set up so that requests are only accepted from the production subnet. Different accounts would also be set up for each type of database transaction so that requests are made with minimal privileges.
- Nodes outside the production subnet would not have access to the production server at the operating system level. Updates and maintenance would be carried out by mechanisms such as the “software update” applications on Windows, Mac OS, and UNIX/Linux systems. This will require effort, but failure to do so makes it difficult to guarantee security.
- The application server on the production server will accept requests from the DMZ server and generate and execute the desired SQL commands. These requests will only be accepted from the DMZ server.
- The application server on the production server will also accept HTTP requests from workstations belonging to the IT subnet. These transactions will be used for administrative control of the system. All requests will be fully logged to enable tracing of any changes. Users will not be able to access the server with Telnet, SSH, remote login, or other means except when the system is taken down from maintenance. All housekeeping tasks will take place using the application server on the production subnet.
Changes on this system will occur infrequently, and changes will require a thorough security review. Although automated testing may be suitable for determining adherence to functional requirements, testing for security compliance will require a different type of review.
Impact of Exploits
Although the attacker may be able to take control of nodes on the DMZ system, he can’t start trying to penetrate the production system until he compromises the DMZ system. Furthermore, the firewalls prevent the attacker from obtaining shell, X-Windows, or remote desktop to the DMZ systems.
It should be noted that the purpose of a wall is not to stop attackers, but to stop them long enough for counter measures to be taken. That means that you must have a way of detecting the attacks.
This is just the start of the process of securing a site. Provisions need to be made for carrying out maintenance, development, testing, and backup in a secure manner. Users with administrative privileges should not be allowed to select their own passwords, and a host of other policies need to be established to develop and maintain good practices. However, these will be the subject for further posts.
- Thomas Fox-Brewster, “How Hackers Broke Equifax: Exploiting a Patchable Vulnerability”, Forbes, September 14, 2017, Retrieved from https://www.forbes.com/sites/thomasbrewster/2017/09/14/equifax-hack-the-result-of-patched-vulnerability/
- Lilly Hay Newman, “Equifax Officially Has No Excuse”, https://www.wired.com/story/equifax-breach-no-excuse/
- Gerard Gawalt, “In His Own Word: Library Exhibition Celebrates Tercentenary of Benjamin Franklin’s Birth”, https://www.loc.gov/loc/lcib/0601/franklin.html — This is a page from the Library of Congress web site discussing the life of Benjamin Franklin.