Software and web developers, owners of the latest IOT gadgets and people who just like to surf the web at home have one thing in common, they are all protected by a firewall.
Businesses typically protect their networks with hardware, dedicated and robust firewalls, while home users usually have it built in their routers. Firewalls are essential for internet security, since they prevent anyone from the outside to access the internal network, and possibly sensitive data. However, firewalls are no panacea. In some cases, malicious hackers can still attack a vulnerable web application that is hosted behind a firewall.
In this blog post, we will explain the different methods attackers can use to access vulnerable web applications behind firewalls, and we will also explain what countermeasures can be taken to thwart such attempts.
Table of Content
A Typical Web Application Developer’s Test Setup
As a web application developer it is impossible to write code without having a proper testing environment. Fortunately, it is easy to install all the necessary pre-configured applications typically used for testing, so the majority of the developers run a web server on their machine.
![]()
For windows, there are popular applications such as XAMPP, which installs Apache, MySQL and PHP, a common combination for web development. On Linux, this can be easily done by installing the needed packages using a package manager. Both methods have the advantage that Apache is preconfigured to a certain degree. Though in order to prevent the Apache web server from being publicly accessible, developers have to configure it to listen on 127.0.0T.1:80 instead of 0.0.0.0:80, or else use a firewall to block incoming connections. But is this enough to block incoming connections and possible malicious attacks in a testing environment?.
Protected Test Web Server & Applications Are Still Vulnerable to Malicious Attacks
Unfortunately many assume that the security measures mentioned above are enough to prevent anyone from sending requests to the web applications running on the test Apache web server. It is assumed that this form of Eggshell Security, hardened from the outside but vulnerable on the inside, allows them to run vulnerable test applications.
People also often assume that they are safe, even if a vulnerable or compromised machine is in the same network as long as it does not contain personal data. However, it is still possible for an attacker to tamper with files or databases, some of which are typically later used in production environments. Attackers can also probe the internal network for weaknesses. In some cases, it is even possible to use methods like ARP-Spoofing to carry out Man-In-The-Middle (MITM) attacks.
But how can an attacker gain access to the development environment, when it is correctly configured to only listen on the loopback interface? Or even better, it is not even accessible from the outside because of a firewall, or because it only allows whitelisted access from within the internal network? The answer is simple: Through the developer’s web browser.
Attacking the Developer’s Vulnerable Test Setup Through the Web Browser
![Logo of Google Chrome]()
![Logo of Microsoft Edge]()
![Logo of Mozilla Firefox]()
![Logo of Safari]()
Web browsers are considered to be the biggest attack surface on personal computers; their codebase and functionality is steadily growing and through the years there have been some notoriouslyinsecure browsers and plugins. Attackers also tend to target browsers due to shortcomings in the design of some modern protocols and standards. Most of them have been built with a good intention, but can also lead to serious vulnerabilities and easy exploitation cross domain. For example, in some cases it is even possible to use the victim’s browser as a proxy and tunnel web request through it.
But new technologies are not the only problem with web browsers security. There are much older issues. For example one of the issues that has the biggest impact is the fact that every website is allowed to send data to any other accessible website. Contrary to popular belief, Same Origin Policy does not prevent the sending of data to a website. It only prevents browsers from retrieving the response. Therefore attacker.com can easily send requests to 127.0.0.1 and that is obviously a big problem.
In this article, we are going to explain how malicious attackers can execute a number of browser based attacks to retrieve data from the victim’s computer, which could be sitting behind a firewall or any other type of protection.
Vulnerable Test Websites on a Local Machine
The problem with Vulnerable Test Environments
![http://localhost/]()
Security researchers and developers typically run vulnerable applications on their machines. For example, developers typically have web applications that are still in development stage, and maybe the security mechanisms are not in place yet, such as the CSRF tokens or authentication.
Security researchers have the same type of applications running on their computers. It is their job to find security issues so they are typically testing vulnerable web applications, which make them an easy target for these kinds of exploits.
Since the Same Origin Policy (SOP) prevents the attacker from mapping the web application to search for vulnerabilities, he has two possibilities to attack the victim;
- Use a blind approach, during which the attacker has to brute force file and parameter names,
- Use a method with which he can actually view and explore the web application. This is where methods such as DNS rebinding come into play.
DNS Rebinding Attack
![Image for a DNS Rebinding Attack]()
This attack method is simple and allows attackers to easily retrieve information from the victim’s computer if it is running a webserver. During this attack the malicious hacker exploits the web browser’s DNS resolution mechanism to retrieve information from the /secret/ subdirectory on the server, as explained below:
- The attacker sets up a website on a live domain, for example, attacker.com that is hosted on the IP address 11.22.33.44.
- The attacker configures a very short DNS cache time (TTL, time to live) for the FQDN record.
- He serves a malicious script to the victim that when executed sends any data it finds back to the attacker controlled server every few minutes.
- The attacker changes the IP address of the FQDN attacker.com to 127.0.0.1.
- Since the TTL was set to a very short time, the browser tries to resolve the IP address of attacker.com again when executing the script that is trying to get the content from the /secret/ sub directory. This needs to be done with a delay of about one minute to let the browser's DNS cache expire.
- Since the script is now running and the IP address of attacker.com is now set to 127.0.0.1, the attacker’s script effectively queries the content of 127.0.0.1/secret instead of 11.22.33.44/secret, thus retrieving the data from the victim’s /secret/ sub directory.
It is very difficult for the victim to identify this type of attack since the domain name is still attacker.com. And since the malicious script runs on the same domain, it also partially bypasses the Same Origin Policy.
DNS Rebinding is a Preventable Attack
DNS Rebinding attacks can be prevented at web server level. We will talk more about prevention at the end of this article, but here is a little overview; as a developer, you should use FQDNs on your local web server such as local.com and whitelist those host headers, so any HTTP requests that do not have the host header in them can be rejected.
Shared hosting is prone to DNS Rebinding only to a certain degree. This is due to the fact that the web server determines which of the websites to server based on the host header. If the host header is not known to the web server it will return the default website. So in this scenario, only the default host is vulnerable to such attack.
Same Origin Policy is not completely bypassed
Since this is an entirely new domain that the user visited, and only the IP address matches, it is not possible for the attacker to steal session information. Cookies are tied to a specific hostname by the browser, not to an IP address. This means that a cookie for http://127.0.0.1 is not valid for http://attacker.com even though it points to 127.0.0.1.
However, in many cases, a valid cookie is not needed, for example when a security researcher has a web application that is vulnerable to command injection vulnerability and no authentication is required. In such a case, the attacker can either use DNS rebinding or simple CSRF (once he knows the vulnerable file and parameter) to issue system commands.
Do Not Run Unpatched Web Applications on Local Machines - It is Dangerous
It is worth mentioning that there are many reasons why even non-developer users tend to have outdated software on the local network. It could be either because they forgot to update the software, or they do not know that an update is available. Many others do not update their software to avoid having possible compatibility issues.
The method we will be describing now is convenient if there are known vulnerable web applications on the victim’s computer. We showed earlier how it is possible to identify and brute force WordPress instances in local networks using a technique called Cross Site History Manipulation, or XSHM. With XSHM it is possible to retrieve information about running applications and under some circumstances, one can even get feedback whether or not a CSRF attack has succeeded.
This method is too evident to be used for brute force attacks or to scan local networks since it requires a refreshing window or redirects. However, it can be done stealthily for short checks since multiple redirects are not strange to modern websites. Legitimate reasons for those are oauth implementations or ad networks that redirect users to different domains.
So it is possible to quickly identify which CMS or web application is running on a given host. If there are known vulnerabilities an attacker can use a known exploit and send the data back to himself, either by using javascript with DNS rebinding, Out Of Band methods, or other Same Origin Breaches.
SQL injection Vulnerabilities on Your Local Network
![Image for SQL injection vulnerabilities.]()
Imagine a Web Application is vulnerable to a SQL injection vulnerability in a SELECT statement that is only exploitable through a CSRF vulnerability, and the attacker knows that an ID parameter in the admin panel is vulnerable. The application runs with the least privileges needed to successfully retrieve data. An attacker cannot use an out of band method on MySQL without root privileges since stacked queries do not work in such setup. Also, the attacker cannot just insert an INSERT statement right behind the query.
However, he can use the sleep command, which forces the SQL database to wait for a given amount of seconds before it continues to execute the query when combined with a condition. So for example, the attacker issues a command such as the following:
if the first character of the admin password is “a” sleep for 2 seconds.
If the request above takes less than two seconds to complete, then the first character in the password is not an “a”. The attacker tries the same with the letter “b”. If the request takes two seconds or longer to complete, then the first character of the password is “b”. The attacker can use this method to guess the remaining characters of the password.
This type of attack is called time based blind SQL injection. However, in the above scenario, it does not seem like a useful attack because the attacker cannot issue the requests directly, but has to resort to CSRF. Also, the delay can only be detected in the user's browser with a different page loading time.
Exploiting SQL injection Vulnerabilities Cross-Domain
JavaScript can be used to determine whether a page finished loading or not by using the “onload” or the “onerror” event handler. Let’s say the attack is GET based (even though POST is also possible) and the vulnerable parameter is called ID. The attacker can:
1. Record the time it takes for a page to load.
2. Point an img tag to the vulnerable application, e.g.
<img src = “http://192.168.1.123/admin.php?page=users&id=1+AND+IF+(SUBSTRING(DATABASE(),1,1)+=+'b',sleep(2),0)” onerror = “pageLoaded()”>
3. Record the time after the page finishes loading with pageLoaded().
4. Compare the values from step 1 and 3.
If there are two or more seconds difference in loading time, it means that the attack was successful and the first letter of the database is a “b”. If not, the attacker proceeds with the letters “c”, “d”, “e” and so on until there is a measurable time delay. Due to this timing side channel it is possible to leak page loading times and therefore, in combination with an SQL injection, valuable data.
Strong Passwords Are a Must, Even if The Web Application Is Not Public
![Image for a password.]()
People tend to use weak passwords on web applications that are running on machines behind a firewall. Though that’s a wrong approach. Let’s say an attacker managed to compromise another computer in the same local network. If he notices a web application on another host he will try to brute-force the password for the admin panel. And if he guesses the credentials, since many modern web applications have upload functionality, the attacker can upload malicious files. Therefore an attacker is often able to plant a web shell on the server and issue commands on the machine hosting the web application.
But as mentioned above there does not need to be a compromise prior to the brute forcing. With DNS rebinding it is still possible to brute force the web application from a malicious website with a low latency, since the web application already runs on localhost and the requests do not need to go over the web.
Therefore it is important to always use strong passwords, no matter from where the application is accessible.
Insecure phpMyAdmin Instances Can Be Dangerous
![Logo for phpMyAdmin, a very popular MySQL manager.]()
phpMyAdmin, a very popular MySQL manager is often installed on developer’s machines, and unfortunately, most of them are not secure. For example, on some install scripts MySQL and phpMyAdmin do not use authentication or use a blank password by default. This means that it is very easy to exploit this through DNS rebinding as no prior knowledge of a password is required to issue MySQL commands.
What makes phpMyAdmin especially dangerous is that it often runs with the highest possible privileges - as the MySQL root user. This means that once an attacker gains access to it, he can:
- Extract data from all databases
- Read Files
- Write files
In some configurations of MySQL, the file privileges are only allowed inside a specific directory. However, more often than not this security measure is not applied, especially in older versions. Therefore an attacker can read files and write attacker controlled content into the web root, which means he can plant a web shell, or a small script that allows him to issue system commands. Once he manages to do that most probably he will be able to escalate his privileges and place malware on the system or exfiltrate sensitive data.
Typical Vulnerable Devices Found On a Network
Routers Need To Be Kept Up To Date
Web applications are not the only objects at risk on a network. Devices such as routers can also be targeted, mainly because they have a web interface which typically runs with root privileges. Routers tend to be a popular and easy target because:
- Web interfaces are poorly coded.
- They sometimes have backdoors or remote controlled interfaces with standard passwords that users never change.
- Since storage space is often tight on routers, manufacturers often use old and probably vulnerable versions of a software, as long as it serves the purpose.
In cases where routers’ admin web portal is not available from the outside, attackers can use DNS rebinding to log into the routers and hijack them. Such type of attacks are possible though they are not scalable, like the 2016 MIRAI malware infection. It infected thousands of home routers by using the default telnet password to gain admin access on the routers and add them to large botnets. Routers are typically hacked for a number of reasons, here are just a few:
- They can be used for Distributed Denial of Service (DDoS) attacks.
- Attackers can use them in a Man In The Middle attack (MITM) to intercept the traffic that passes through them.
- Attackers use them as a foothold to gain access to other machines on the router’s network, like what happened in the NotPetya ransomware in June 2017.
IOT Devices - Many of Which, Are Insecure
![IOT Devices - Many of Which, Are Insecure]()
MIRAI did not only target home routers. Other victims included IP cameras and digital video recorders. More often than not security does not play an important role in the design of Internet Of Things (IOT) devices. And we install such insecure products on our home and corporate networks.
And to make things worse, many people who do not have IT security experience, tend to disable all firewalls and other security services on them to make the IOT devices, such as an IP camera, available over the internet. These types of setups can have unpredictable outcomes for the security of the devices connected to our networks, and can be an open door invitation to attackers and allow them to target other parts of the systems.
Vulnerability NAS Servers
NAS servers have become very common nowadays. They are used to manage and share files across all the devices on a network. Almost like any other device, NAS servers can be configured via a web interface, from which users for example, are allowed to download files.
NAS servers are also an additional attack surface. Similar to what we explained above, the attacker can use CSRF or DNS rebinding attack to interact with the web interface. Since these web interfaces typically have root access to allow the user to change ports etc, once an attacker gains access he can easily fully compromise the server.
Vulnerable Services Typically Used By Developers
![Logo for MongoDB Services]()
On the rare occasion or a properly set up MongoDB instances to bind on localhost instead of 0.0.0.0, they can still be vulnerable to attacks through their REST API. The REST API is typically enabled because it is a useful feature for frontend developers. It allows them to have their own test datasets without having to rely on a finished backend. The data is returned in JSON format and can therefore be used with native JavaScript functions.
However this web interface has some serious flaws like CSRF vulnerabilities, that can lead to data theft as described in this proof of concept of a CSRF attack in the MongoDB REST API. In short, we used an OOB (Out of band) technique to exfiltrate the data over DNS queries. The API is marked as deprecated, however it was still present in the latest version we tested at the time we wrote the article.
DropBox information Disclosure
![Logo for DropBox]()
Another rather interesting vulnerability is the one we found in the dropbox client for Windows. In order to communicate with the client, the website dropbox.com was sending commands to a websocket server listening on localhost.
However, by default websockets allow anyone to send and receive data, even when the request originates from another website. Therefore to verify the origin, the Dropbox client uses a handshake that needs to be correct in order to verify the sender's origin.
It consisted of a check of a nonce, a string of characters only known to dropbox and the client. It was directly queried from the Dropbox server and there was probably a check for the origin header. This means that a connection can take place, but no data could be sent from localhost if the origin was not correct.
However, when any random website connects to the websocket server on localhost, the Dropbox client would prematurely send a handshake request. The handshake request included information such as the id of that particular request, which OS was in using, and the exact version of the dropbox application. Such information should not be leaked through such channel, especially since it could be read by any third party website just by starting a connection request to the server on localhost.
Note: The issue was responsibly reported to Dropbox via Hackerone. It was immediately triaged and awarded with an initial bounty as well as a bonus since the report helped them find another issue.
How Can You Prevent These Type of Attacks?
Simply put, to prevent DNS rebinding attacks at server level just block access and requests when the host header in the HTTP request does not match a white list. Below is an explanation of how you can do this on Apache and IIS web server.
Blocking DNS Rebinding Attacks on Apache Server
On apache you can block access if the host header does not match 127.0.0.1 with mod_authz_host, by adding these lines to your configuration:
<If "%{HTTP_HOST} != '127.0.0.1'">
Require all denied
</If>
Therefore, if someone tries to launch a DNS rebinding attack, the requests will be blocked and the server will return a HTTP 403 message.
Blocking DNS Rebinding Attacks on Windows IIS
It is very easy to block DNS rebinding attacks on the Microsoft IIS web server. All you need to do is add a rule of type “Request blocking” in the URL rewrite menu with the following options:
- The “Block access based on” field has to be set to “Host header”
- The “Block request that” field has to be set to “Does Not Match the Pattern”. As pattern one or more host headers can be used. (source).
Other Measures to Block Such Type of Attacks
Another good countermeasure is to block third party cookies in the browser, and to use the same-site attribute in cookies on the web application that is being developed.
Other than that, apply the same security measures on internal websites as if they are publicly available. The web application should not be vulnerable to CSRF, cross-site scripting, SQL injection and other types of web vulnerabilities to guarantee a safe testing environment.
As an additional security measure run the web application on a virtual machine. Even though this is often not necessary, and complicates matters, it can lessen the impact of a compromise. This setup is mostly recommended for security researchers that want to run vulnerable web applications on their machine.
![]()
The earlier in the development process a vulnerability is found, the easier and cheaper it is to fix. For example, imagine a vulnerability is found during a penetration test in four or 
For windows, there are popular applications such as XAMPP, which installs Apache, MySQL and PHP, a common combination for web development. On Linux, this can be easily done by installing the needed packages using a package manager. Both methods have the advantage that Apache is 
Who can tell it better than the customer himself? This is not the ordinary case study. This is an interview with Tom Mallory, 
Award-winning journalist Patrick Gray interviewed our CEO, Ferruh Mavituna, on how to find vulnerabilities in more than 1,000 web applications.
2016 was a great year for Netsparker! We were the first (and only) web application security scanner vendor to introduce a number of cutting-edge technologies that make it possible to scale up web scanning and easily scan 100s and 1000s of websites, without having to spend hours configuring complex tools and days verifying that the vulnerabilities the scanner has detected are not false positives.
The customer is always right, and we at Netsparker could not agree more to this statement. So what could be better than an interview with one of our web scanner’s users? This interview with Klemen Stirn, the project-lead, developer and support team for Hesk, explains why he found Netsparker to be a great tool for automating and scaling-up web application security, due to its ease of use and ample support.
