New web-based attack types and vectors are coming out every day, this is causing businesses, communities and individuals to take security seriously now more than they ever have in the past. This is a huge win for the World Wide Web and it’s a trend that is pushing technology further towards more robust and securely developed web applications.
The recent discovery of another vulnerability in SSL has led thought-leaders and developers to immediately phase out the weak aspect of the protocol. The implementation of SSLv3, and its exploitable nature, gained its marketable canine acronym POODLE for describing the ability to force users to downgrade their encryption to a breakable standard, revealing their sensitive data as if it were being passed in clear text.
These revelations teach everyone the importance of basic security concepts. While utilizing older methods of cryptography is obviously dangerous, the attacks that are making it into the news cycle are still falling back on old methods used by crackers since the dawn of network access. All software, old and new, follows the same concepts that made computers work decades prior to now. The only difference today is the number of complex layers that have been added to make the process seem confusing.
The only ones confused though, are the people for whom the complexity was implemented to protect in the first place: the users. The continuous pattern of cyber-assault on everything from banks to bakeries, and across the board from Target to Apple, is showing that this world requires users to break the expectation of confusion and understand how Internet instigators are really coming after us.
The motive behind online attacks are varied. You had stuff to steal, your site could be used to display propaganda or broadcast spam, or maybe you just forgot to update and your forgetfulness was able to satisfy the bored desires of a curious script-kiddie — one of those reasons is why you got hacked. Every site can serve a purpose: to hold sensitive data, or at the very least, provide usable resources to send spam or attack other targets. Know that your website has value.
In this post, we’ll look at a few vectors crackers look for and employ when attacking your website.
To someone wanting to break into your site, it’s imperative they find a point of entry they can exploit (this is known as an attack vector). These attack vectors come in a variety of forms, today you more often than not attribute these to two main categories:Access Control and Software Vulnerabilities.
Injection vulnerabilities are rated as the number one problem on the list of top 10 security issues put out by Open Web Application Security Project (OWASP) and continue to be a major source of concern for application and web developers looking to utilize the benefits of storing usable information in a local database. Due to the predictable nature of these types of applications, an attacker can craft a string using specific Structured Query Language (SQL) commands, and know it can be used to force the database to give up the goods. These strings can be entered in places like search boxes, login forms, and even directly into a url to negate simple client-side security measures on the page itself.
Why is this so dangerous? The database keeps the most important and lucrative space on a system, and can not only be coaxed to give up usernames, passwords, and credit card numbers, but can also be attacked in a way that can give an attacker a foothold to gain access to the entire system, and to every other database instance housed there for other websites and applications.
Often misunderstood, and even more often underestimated, XSS is a style of attack where the front of the website acts as a launching point for attacks on other users visiting the website. This happens when developers don’t properly test their code for the possibility of allowing scripts to be injected. The scripts can then be executed without the site’s original functionality intending them to be.
If an XSS vulnerability is present on a website, then an attacker can craft code that executes when other users open the same website. This causes the new users to interact with the malicious background entity created by the attacker. Once a connection has been initiated, usually via social-engineering tactics convincing a user to do something they shouldn’t, the attacker is able to infiltrate your website visitors’ computers.
As a result of insecure coding, malicious users can find functionality within a web application, and use the underlying mechanics to execute their code. The two variations of this action can be to either execute code already on the system, or execute code that is located off the system.
Local File Inclusion
By targeting ‘include’ parameters in PHP code, intruders can request an alternative file be used in the specified request instead of the file meant to go along with the program. This can lead to unintended access to internal files and logs. Where a script should work like this – http://site.com/web-app.php?nextStep=goodfile.php – a vulnerable application can be changed to target an sensitive system file, or worse, something that is infected – http://site.com/web-app.php?nextstep=/etc/passwd
Where this can get even messier is when dealing with a highly sophisticated intruder that knows how to manipulate internal files. By sending malicious payloads to the site, without intending for them to work, a hacker can load log files with their own code. By pointing a vulnerable include parameter to a code injected log file by using an LFI technique, a devastating attack can be launched.
Remote File Inclusion
A very sneaky method of running malicious software on a victim’s server is by simply asking it to go somewhere else on the Internet to find a dangerous script, and then run it from that location. This scary scenario is called a Remote File Inclusion (RFI) attack. An RFI can occur when functions are improperly crafted, allowing users to modify the URL parameters when web apps are launching components for their own purposes.
By changing the intended process in order to activate a far away malicious payload sitting on a public server, the attacker may be able to activate a piece of code that will give them a shell through a held connection between the victim site and the remote server that holds the designated file. Including a script in this way opens up a number of dangerous options that a hacker can use against you.
If you just want to get to the other side of a wall and don’t care how much noise you make, you can always use a machine gun to shoot bullets at it until there is nothing left, eventually the wall will fall and you can walk through unencumbered. That method is not unlike a Brute Force attack.
If there’s a form used to log in, then it’s possible to set up specialized scripts that continuously try different username and password combinations until a match is discovered, and the attacker gains access. This could be a brief attack, designed to check if the user has a weak password, and may only check the top 10 or top 100 most common passwords. It could also be a long-term targeted attack composed of lists of millions of passwords to try, and all the time in the world to wait for the right password to work.
More sophisticated Brute Force attacks compile password lists from keywords available on your website to test on your administrator login forms. The best way to protect yourself is by always using strong, unique passwords and supplementing your access control with Two Factor authentication.
While we accept and recognize that these are common risks and dangers of operating a website today, it’s important to continue to be vigilant and current with the latest threats. Security, is not a Do It Yourself (DIY) project for most website owners; if reading the above article felt foreign to you, then you’re likely in that category.
A few things to consider as a website owner: