Far to often organisations do all their security work on the few systems that are exposed to the internet. This might be acceptable when you begin the structured and ongoing work with security, but you should try to move on to defence in depth as soon as possible.
Defence in depth is where you do not leave security to one layer of an application (or solution), but instead validate the security every step of the way. A common example for this is that even if you have a network firewall you do not disable the firewall in the operating system. This can be transferred to software development as well. In a more complex system each component should get the same security controls. It should not only be the frontend API that validates the input, instead each component should validate the data as untrusted when it receives it from another component. By doing so the resilience of the solution as a whole is greatly improved, where a single issue have limited impact, and might not even be exploitable.
Example application and its vulnerabilities.
Let us look at a simple system to exemplify potential vulnerabilities. This system is simplified and super minimalistic, but still shows several ways to attack components on the internal network. The application is a web shop exposed to the internet through a firewall. The web shop fetches prices and products from a database. To manage the prices and products employees uses another administrative interface. The administrative interface connects to the same database to update the web shop. In this example, only the web shop is accessible from the internet, and the employee workstation is the only component with unrestricted access to the internet.
DatabaseDatabaseWebshopWebshopFirewallFirewallInternetInternet AdministrativeInterfaceAdministrative…EmployeeWorkstationEmployee…Viewer does not support full SVG 1.1
Let’s take a look at a couple of ways this architecture potentially could be exploited and how defence in depth could reduce the impact of these vulnerabilities.
Infecting the Workstation
The most obvious way into the network is to infect the employee workstation. This can for example be done by using trojans through emails or public exploits in the operating system. Regardless of how the initial attack is performed, the goal is the same, hijacking the employee workstation to get access to the internal network. To mitigate this it is important to include the workstations in the security policy of the organisation. For example the software on the workstation needs to be up to date with the latest security patches.
In addition to patches, using a good antivirus software will keep a lookout for malicious code on the computer, helping users to distinguish trojans from legitimate files and programs. As an added bonus, the antivirus will log incidents, ensuring that the organisation is aware of failed attacks, and can investigate suspicious activities.
These technical solutions might however not be enough. To circumvent patched software and antivirus the most dedicated attackers might hack the employee instead of the workstation. This can be done in multiple ways. Some examples include social engineering and bribery. Whatever the way the best way to protect the organisation against these attacks is through security awareness training. By getting the employees to be on the lookout for and report suspicious activities most of these attacks will fail.
Through the Web shop
Organisations are now getting quite good at securing their web applications against attacks that affect their corporate networks. However, there are a couple ways a vulnerable webserver can be abused to gain a foothold and enter the network. In my experience the two most common are components with known vulnerabilities, or administrative interfaces exposed to the internet. Note that these administrative interfaces might be anything from a WordPress admin interface to a SSH server. Neither of which is weak if configured correctly, but far to often they have accounts that can be bruteforced, allowing an attacker to try different credentials until they successfully sign in. The goal of this is to gain access to the solution and then get further access into the corporate network.
Another possibility is to circumvent the webserver and just attack the network directly. This can for example be done by using a SQL-injection or server-side request forgery. An SQL-injection would allow the attacker to execute database commands in the database through the web application, attacking it directly. A server-side request forgery is a vulnerability that abuses a server to make requests against other applications. This means that the attacker can attack any system that the server can connect to, including on the internal network.
Vulnerabilities in the Administrative Interface
There are multiple vulnerabilities that can occur in web applications that could be exploited from the internet, even though the application is not accessible. These vulnerabilities uses a legitimate user of the internal application to perform the attack. Attacks that can be exploited could be clickjacking or cross-site request forgery. Both of which rely on a legitimate authenticated user of the vulnerable system visiting a malicious webpage on the internet. While the user thinks they are visiting this webpage on the internet, the attacker is using their browser to send requests to the internal systems, signed in as the victim. The result of this attack can range from the attacker being able to perform actions as the victim, to them being able to exploit other vulnerabilities with an even greater impact.
There are ways to protect against these attacks, but since they exists it is important to not forget these internal systems in regards to security. They should not be allowed to ignore the security recommendations just because they are not exposed to the internet.
Conclusion
There are multiple ways for an attacker to gain access into the internal network of an organisation without them being accessible from nor have access to the internet. Therefore it is important to include all systems in the security work. No systems should be excused because they are not exposed to the internet, you never know how an attacker can gain access to them.
When looking at a more complex system than this, other and more complex attacks emerges, but the conclusion is the same. Do your due diligence for the security of the solution, not only focusing on the exposed parts, but also on the components behind it.