One of the biggest concerns shared by many organizations is that an external hacker will penetrate its internal network. Most organizations protect their internal network with a number of products meant for this purpose such as a firewall, IPS, anti-virus software and other similar solutions. They also create several demilitarized zones between the internet and their internal network such as DMZ, secure-DMZ, LAN, secure-LAN and so on.

So how is it possible that a hacker can bypass so many defenses and break through so many zones to penetrate the internal network?

Very easy!

Let’s think in terms of a military analogy. Can tanks protecting a country’s border also prevent the penetration of fighter jets?

Can fighter jets prevent submarine attacks?

Of course not!

Why not? The answer lies in the fact that they are in a different layers. Most of the defenses that organizations put in place are effective against infrastructure attacks but not against application attacks which are in a different layer. Application attacks can penetrate the firewall, IPS, the DMZ, S-DMZ and other layers deep down in the internal network.

Let’s see some examples:

Scenario No. 1: Everyone needs access to files

Everyone in the organization needs to be able to access files from the internet. For example, the HR team receives CVs in response to jobs advertised in the organization’s site. Candidates use a specific mechanism to upload their CVs which are transferred deep into the organization’s internal network to the computers of the HR teams. A hacker can upload a CV in a Word document that contains malicious script. When a member of the HR team clicks on the file containing that CV, script such as a ransomware virus will be executed that will lock sensitive data in the internal network.

Scenario No. 2: Data must be stored in a database

Organizations collect a lot of data. Some of it comes from external sites like banking applications, university student registration systems, e-commerce systems and many other applications. This data must be stored in a database. Because the database is very sensitive, it most likely will be housed in the internal network. The problem with that is the existence of attacks like SQL injection against databases. A hacker that uses an SQL injection attack can embed script like an SQL query into the data that the system collects from him. When the system tries to store the data in the database, it will execute script that may steal sensitive data from that database, take over the server and even attack other servers in the internal network.

Scenario No. 3: Logs help protect us (but also to attack us)

Logs and audit mechanisms help us not only to understand what registered users do in the system, but also what hackers are trying to do. The logs document a hacker’s attempts to attack the system; they help to follow him and prevent him from breaching the system. These attack attempts are usually stored in files or databases and are watched and analyzed by security teams using a monitoring system. But what if the hacker tries to attack the monitoring system? He can use malicious script that is stored in the log files or database which will execute when the security team retrieves it (called a log forging attack or log injection). The result is malicious script executed by the attacker in the internal network’s monitoring system.

Scenario No. 4: When an application needs access to the operating system

Sometimes applications need to perform commands on the host operating system like creating or deleting a file. But what if the name of the file comes from the user? That means that the system is vulnerable to a command injection attack which allows the hacker to inject code that will perform actions on the operating system. It also enables operations to be performed on other servers on the internal network that communicate with the same server.

Scenario No. 5: Wrong way! The servers need resources from the internet but the hackers navigate the external server to the internal one

From time to time, applications need external resources. Let’s look at a simple process like choosing the background of your company’s webpage. You can choose a ready-made background or select one from your site or another external site. For example, if you type in https://mysite.com/BG.jpg, the server will navigate to this site and implement the background on your page. While this may look straightforward, consider that a hacker might insert an internal address like https://192.168.1.2. The server will subsequently navigate to an internal server (instead of to an external one) that can even be behind a firewall in the internal network. There could even be some malicious script attached such as https://192.168.1.2./Sensetivepage.aspx?param1=<Hackers script>.There are some techniques on how to use this vulnerability to perform IP scanning and attack internal servers (called SSRF attacks).

Conclusions

You can’t prevent attacks from fighter jets with tanks, you can’t prevent attacks from submarines with fighter jets.

And you can’t stop application attacks with a defense that is supposed to stop infrastructure attacks.

The bottom line is to account for the fact that there are different layers. The best way to defend your system and your entire organization against application attacks is by using products like WAF (Web Application Firewall). In short, the most effective solution is to implement security mechanisms into the source code.