Security professionals spend a lot of time thinking about protecting their back end systems and the information contained therein. They think about the scariest and sneakiest vulnerabilities and what an exploit means in real terms: will this disrupt business operations? Will our company lose sensitive data? What are the potential financial consequences? Will I be fired?
What a lot of security teams don’t spend much time considering, however, are the vulnerabilities in plain sight, the ones that can be enacted by a moderately skilled hacker who found explicit instructions posted on Pastebin from another hacker about a similar vulnerability. While we’re not yet winning the war, security teams are getting better at finding and detecting the Big Ones. Some of the most subtle but more easily avoided vulnerabilities shouldn’t be overlooked. Like those that occur through our most public-facing and highly used interface: our websites.
This is not to say that website vulnerabilities can be eliminated, but the problems are compounded by the proliferation of easy-to-use content management systems (CMS) like WordPress, Joomla!, and Drupal. One needn’t be an experienced Web application developer to build a website today; these platforms often come with step-by-step instructions on not only how to build the site, but also third-party plugins and widgets, modules, and other add-ons that make sites more functional, attractive, and interactive. Coincidentally, when the site owner places blind trust in these objects, the same highly extensible and convenient features are what make them more vulnerable.
Security risks are greater on more advanced and interactive websites, which only adds to the constant struggle between usability and security. “Complexity is the enemy of security, and business teams’ responsibilities for Web server operations are often complex, which creates large scale opportunities for threat actors,” writes Levi Gundert, Vice President of Information Security Strategy at Recorded Future. For obvious reasons, competitive companies must provide a positive and functional user experience, but competitive companies also implement security programs to drive down risk.
What’s Old is…Old
Many websites are built on outdated versions of software and libraries, have old and insecure plugins, or are developed from neglected or poorly written code copied and altered from “view page source.”
Application firewalls, antivirus, and IDS/IPS can help, yet they can’t stop all the attacks, and certainly not if a bot finds the vulnerabilities before a patch is applied or if the attack is a zero-day. Any number of attacks—website or otherwise—are automated and rely on default settings. And security pros certainly know that default or easily guessed settings and passwords are rampant.
At the most basic level, patches and updates need to be automated to keep pace with attackers. Don’t wait until it’s convenient to update the latest software from Joomla! By then, someone will have found a vulnerability and shared it with his or her flagitious friend. Update software, systems, and add-ons as soon as the update becomes available. Run automated scans and set alerts that make clear when a new version is available, and make that a priority. It’s less of a hassle to wait ten minutes for an update than it is to wait three days until your site is back online after a breach.
It should go without saying, too, that Web servers should never be run with default admin passwords and credentials. Passwords should be changed immediately upon first use (the longer the better); be updated regularly; never be shared; and always be unique for individual sites, severs, and even segments within the network, if possible. Password managers are great tools to assist in this endeavor, especially for admins whose keys to the kingdom are highly sought by malfeasants.
What’s the Worst that can Happen?
Many IT departments think that large enterprises are the biggest targets of attack, and if they work for a smaller company, they’re less attractive to adversaries. Target or Neiman Marcus or the like collect and store more credit card data and personally identifiable information (PII) on a larger number of customers, but cyber thieves will also target small businesses because they know that, often, security is a lesser priority for a leaner organization. One of the problems is that development does not always include secure development practices; development goals, lifecycles, and priorities are different, and in many cases, developers have not been trained in security. This is not a bash on developers, rather, this section is meant to point out that there are inherent flaw in some development tools and methods for which compensating controls need to be implemented.
An insecure website can lead to the following types of vulnerabilities:
- Denial of Service
- Code execution
- Database access
- Client-side script execution
- Authentication bypass
- Directory traversal
The ability to gain information is the most well-known goal of a website attack: credit cards, user names and passwords, social security numbers, banking information—these are all desirable and profitable on the black market.
Web-based forms written without proper security controls are susceptible to cross-site scripting (XSS) or cross-site request forgery (XSRF), which means they are good methods of stealing information, due to vulnerabilities in JavaScript, a programming language used to build interactive sites. JavaScript interacts with the Web page Document Object Model (DOM) and can be used to execute malicious content or obtain unauthorized permissions.
Another popular exploit technique is SQL injection. As described by OWASP: A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases, issue commands to the operating system. In other words, if an attacker exploits a vulnerability and executes a SQL injection, he or she can dump the contents of your database, use them to further affect damage, and/or post the information on the deep or dark Web for use by anyone who stumbles across the data. Customers would not be comforted knowing that your site may be vulnerable to such an attack.
And you Thought Regular Advertising was Bad
Malvertising is growing in popularity among attackers because of the ease with which it is executed and the profits it reaps. While criminals don’t make haste posting revenues online, the Interactive Advertising Bureau and Ernst & Young recently published a report stating that “combating malware-related activities, which can expose Web users to unknown or potentially dangerous third parties,” costs advertisers $1.1 billion per year. One can’t exactly divide the number of companies advertising by the defense expenses and generate an amount it will cost to promote a safe online advertising campaign, but it should signal to enterprises that malvertising is a problem, it’s rising in popularity, and if your company has an online presence which allows third-party advertising, that presence is subject to tampering.
The main problems with malvertising (or “bad advertising,” derived from “mal” = “bad” or “malicious”) are that it’s indistinguishable from good, or non-malicious advertising, and anonymity is high because ad networks rotate on a continual basis what is displayed. Once a user clicks on a malicious ad, however, it can drop malware or executable code on a user’s machine, it can install spyware or key loggers, it can redirect traffic to malicious websites, and it can even copy login data that can be later used to steal more user information still to escalate an attack. Gundert explains, “Compromised Web servers have never been in more demand, primarily because their uptime and resources create a powerful platform for launching secondary attacks.”
Ad blocking can help identify malvertising, but it won’t necessarily stop it. Web browsers and plugins should be, as stated previously, updated and patched whenever and as soon as possible, and many security professionals will advocate disallowing Java and Flash, which have well-known vulnerabilities. Click-to-run or click-to-play for third-party content should also be enabled, since auto-play is an easy way for malvertizers to affect harm. And extensions, add-ons, and toolbars should be limited to known providers, and, whenever possible, check permissions and apply the principle of least privilege. There is no reason an emoji add-on needs access to your computer’s camera.
Say security strategy consultant, Mike Landeck, “Today’s websites routinely incorporate third-party content providers, analytic services, and active social media buttons into their pages. It is not uncommon to see ten or even twenty cross-domain scripts running in a user’s browser. Proper vetting of the third party, appropriate security controls within your code, and adequate contractual agreements need to be in place before allowing outside an organization's code to be included in your site.”
The Wrap Up
Websites are a critical element of any company’s business, but they can also introduce infiltration points for attackers. Security teams must take care to work with developers and architecture teams to ensure the builders and maintainers have the right tools and knowledge to harden the front and back ends of the site. While it’s easiest to outsource development and maintenance to a third-party provider, the data associated with your website are too valuable to set-and-forget. Don’t be blindsided by website vulnerabilities; make the time and put in the effort to update, patch, and follow sound security practices, including educating collaborators on how to take these extra, critical steps.
