In this Dark Arts series, we have taken a close look at the primary techniques the Luzsec hackers used to gain illegal access to servers. We’ve covered two them – SQL injection (SQLi) and cross-site scripting (XSS). In this article, we’ll go over the final technique called remote file inclusion (RFI).
DISCLAIMER: Fortunately, the surge of security-minded coding practices after the fall of Lulzsec has (for the most part) removed these vulnerabilities from the Internet as a whole. These techniques are very dated and will not work on any server that is maintained and/or behind a decent firewall, and your IP will probably get flagged and logged for trying them out. But feel free to set up a server at home and play around.
PHP, Yeah You Should Know Me Better Than That
RFI attacks are not as well-known as their SQLi and XSS counterparts. However, it’s a very effective way to get malicious code to run on a vulnerable target server. It works by including a remote file in an HTTP request. Its basic form is to append a URL to include a file from a remote server. For instance, say instead of typing http://ift.tt/2tRlnrf into the URL bar, you type in something like http://ift.tt/2vfJnYz?
If you get the Hackaday web page, then http://ift.tt/2tRlnrf is susceptible to an RFI attack. What you’ve done is run http://ift.tt/2vg6hit on the Arduino site server. There is nothing stopping you from doing something like http://ift.tt/2tRA1yn
The most prevalent reason this was possible was because web coders would often structure links to other pages within their site like this:
This way, the links in the index.php home page will simply call another .php file. To do this, they would use the include() function to call the sub-pages of uno, mega and due.php. Consider the slightly modified code we found on the web (written in 2011) from a hacker who went by [B.K.]:
I Love Arduino
Can you see where the problem is? When a link in the HTML block is clicked, it gets passed to the GET variable. The include() function will then resolve the URL to http://ift.tt/2tRhUZw if you click the ‘Uno’ link. There is nothing here to stop someone from including files from outside the domain. Nothing stops you from changing ?page=uno to whatever you want.
And that’s how a basic RFI attack works. There are variations of course. Let us know your favorite in the comments!
As you see, the attack is simple enough to construct a program that can look for pages that are susceptible to RFI, and then run code to extract information from the vulnerable server. And that’s exactly what happened in the early part of the decade. The graph below shows logged RFI attacks in 2010-2011. The spikes were largely do to a single user, suggesting an automated tool was at work.
Source via Imperva
Preventing RFI Attacks
Fortunately it is relatively trivial to stop RFI attacks. The absolute best way is to go into your php.ini file and set allow_url_fopen and allow_url_include to off. They should be off by default if you keep your server updated, but check anyway. Another way is to sanitize the inputs, much in the same you would to prevent SQLi. This can be done by making a whitelist of files that can be run on your server. And there’s always a good firewall that can stop these kind of attacks before they start.
Most importantly, we should always look at code through the eyes of the hacker probing for weaknesses, and of course patch up the holes as quickly as possible when a new one is discovered. With RFI, as with SQLi, the problem is opening up the system to arbitrary user input. This was a lesson the Internet learned the hard way. We hope.
Filed under: Featured, Interest, Original Art http://ift.tt/2vfPxrl http://ift.tt/2aM8QhC