Website Hacking: DrDOS Attacks & More

Website breaches can be devastating to your business. Hacking techniques evolve rapidly so keeping your finger on the pulse is essential for protecting your website. 

According to the most recent ranking of the top 10 vulnerabilities by the Open Web Application Security Project, the most common website threats include:

Injection

These occur when Web apps send user input and other untrusted data to an interpreter, such as a SQL database. Attackers like those working for Gonzalez find these bugs using scanners and can exploit them to steal password tables or other sensitive data. The flaws can also be milked to carry out denial of access attacks or even completely take over the underlying Web server. Individual vulnerabilities can be so numerous they're often akin to garden weeds that are hard to completely eradicate. The best way to prevent them is to rely on Web apps that sanitise user input before handing it off to a back-end server.

Cross-site scripting

Abbreviated as XSS, these flaws occur when Web apps send user-supplied data to a browser without properly validating or, if necessary, escaping it. Attackers exploit them to send JavaScript fragments that steal browser cookies used to authenticate an end user to an e-mail account or other restricted service. The flaws can also be exploited to deface websites, redirect users to other sites, or even use malware to hijack a user's browser. XSS bugs are avoided by ensuring that all user-supplied input returned to the browser is verified as safe or escaped so that it's no longer dangerous.

Broken authentication and session management

These errors reside in apps used to log users in to restricted parts of a site. Typically, they're found in custom-developed schemes that make some sort of critical error, such as requiring a session ID that is easy to guess or included in the URL. As their name implies, they result in such schemes not working the way they're supposed to, allowing attackers to take unauthorized control of user accounts and perform any action the valid user would, including deleting sensitive e-mail or data. The best way to keep clear of these vulnerabilities is to avoid custom-developed schemes in favor of one that has been well tested.

Insecure direct object references

These flaws stem from Web apps that use the actual name or key of an object in a URL when generating a page. In some cases, attackers can exploit these to gain powerful administrator privileges, simply by modifying some of the URL text. To prevent such errors, websites should use per-user or session indirect object references, which can't be manipulated.

Cross-site request forgery

CSRF exploits use fake websites to generate forged HTTP requests that attack end users of a vulnerable website. Attackers exploit these mistakes to force an end user to execute unwanted actions on a website she's already logged into. Exploits can force the victim to unwittingly delete e-mails or carry out any other authorized operation. Attacks can be especially devastating when the affected end user controls the administrator account. To prevent CSRF vulnerabilities, Web apps should employ unpredictable tokens in the body or URL of each HTTP request and should be unique per user session or per request.

Security misconfiguration

These bugs often give attackers unauthorized access to powerful system functionality or sensitive data. They result from misconfigurations to Web servers, apps, or custom code. They can be avoided by hardening Web environments, including keeping operating systems, apps, and all other software up to date, disabling or uninstalling unused services, and disabling any default accounts or account passwords.

Insecure cryptographic storage

This is a series of sins and omissions that some security experts have recently leveled at Kim Dotcom's Mega cloud storage service. Insecure cryptographic storage can take many forms, from failing to encrypt credit card data or other sensitive information, to using insecure cryptographic implementations that allow attackers to decrypt encrypted contents. Mega provided Web developers with an object lesson in cryptographic storage by failing to secure the key used in an algorithm in some of its crypto code. Another serious omission in this category is the failure to adequately protect databases of user passwords in the event that a site is compromised. While cryptographically hashing passwords is crucial, it's not enough. It's also important that the algorithm employed is designed specifically for password storage. Bcrypt, PBKDF2, or SHA512crypt are excellent choices. SHA1, SHA3, and MD5, not so much. Update: As several Ars readers have pointed out, another key defense is securely discarding credit card data and sensitive information if it's not mission critical.

Failure to restrict URL access

These errors happen when an application doesn't protect page requests properly. They allow unauthorized users to access restricted pages by manipulating the URL. Once exploited, these flaws allow an attacker to do anything the privileged user can do. There are a variety of approaches to fixing these problems, including using authorization components that are external to the Web application.

Insufficient transport layer protection

Secure sockets layer and its sister protocol, transport layer security, are the basis for virtually all encryption used to authenticate websites and to encrypt data traveling between them and end users. And yet it's surprising how sparingly and incorrectly they're often used. It was only in November, for instance, that Microsoft's Hotmail service allowed users to SSL-protect their entire Web mail sessions. Prior to that, users had no way of protecting their sessions from man-in-the-middle attacks once they proceeded past the login screen. But a lack of end-to-end SSL or TLS protection is only one example of insufficient transport layer protection. Browser cookies used for authentication and other sensitive purposes must contain a secure flag. And certificates should never be self-signed or allowed to expire. Most importantly, SSL and TLS implementations must be hardened to withstand several new attacks that have been developed over the past few years, including renegotiation attacks and anexploit known as Beast. Sadly, an estimated two-thirds of SSL-or TLS-enabled websites still aren't protected against Beast, according to SSL Pulse, a website that is sponsored by security firm Qualys and monitors the effectiveness of the 200,000 most popular websites that use SSL.

Unvalidated redirects and forwards

Bugs in this category cause visitors to be redirected to other parts of a site or to different sites altogether. They're frequently exploited by phishers or malware purveyors who lure would-be victims with a link to a trusted site like Google or Bank of America that then redirects to a malicious site.

Assume you’re vulnerable

With the growing complexity of Web servers and applications, readers should presume their sites are at-risk to at least some of the vulnerabilities described above. And that means your business' most precious assets could literally be a few clicks away from being downloaded by hardened criminals or script kiddies. If that sounds like an exaggeration, consider the cautionary tale of HBGary Federal, the firm that two years ago was ransacked by members of the Anonymous hacking collective.

Although the firm provided security services for Fortune 500 companies and government agencies, it never bothered to adequately secure its own website. Its content management system was vulnerable to a SQL injection attack that allowed an innocuous-looking link likehttp://www.hbgaryfederal.com/pages.php?pageNav=2&page=27 to inject an unauthorized query into the site's back-end database. As a result, the database spit out a list of usernames, e-mail addresses, and password hashes belonging to insiders of some of the world's most powerful organizations. The data breach probably wouldn't have been possible—or at least as devastating—had the CMS been audited for injection vulnerabilities.

To make matters worse, the retrieved passwords were cryptographically hashed using the MD5 algorithm, which security experts have long cautioned isn't suitable for password storage. That's because, as explained above, such algorithms are fast and computationally undemanding. That makes the task of cracking the hashes considerably easier.

The point isn't to shame the HB Gary admins. Rather, it's to show website sloppiness is the rule rather than the exception. If a firm dedicated to security can make these mistakes, imagine how bad things can be inside a startup in the e-commerce or mobile app industries.

In addition to putting trade secrets and other proprietary data at risk, website flaws also tarnish a company's reputation—and for good reason. Besides the damage an unsecured site can inflict on its visitors, it also poses a threat to untold numbers of Internet users who have never heard of your site. That's because vulnerable sites are frequently used in phishing, malware, and sundry other attacks.

Of course, the most important thing any Web admin can do to lock down a site is to keep the underlying operating system and all apps that run on it up to date. This means installing patches within 24 hours or sooner if possible. But given the complexity of most website platforms, patching isn't enough. It's important for admins to become conversant in website security. The Open Web Application Security Project is a good way to get started. Ultimately, regular audits by professional security firms is a must for any website that handles passwords, credit card data, and other sensitive data.

The Internet is awash with companies like HB Gary or Heartland Payment Systems. Plucking the myriad weeds that tripped them up isn't easy, but it's worth it. The good news is that, as attacks develop and become more sophisticated, so does technology.