DDoS Takes Down Krebs’ Site

super-ddos-akamai-krebsonsecurityLate last week, one of the leading sources of cyber security news was shut down after getting hit by one of the largest DDoS attacks in history. The massive assault on KrebsOnSecurity.com came after the site’s owner, Brian Krebs, reported on the exploits and business operations of a company that offers DDoS attacks-for-hire services.

A couple of weeks prior to the attack, Krebs brought to light the activities of vDOS, a company that rendered services for people who wanted to subject certain organizations to a Distributed Denial-of-Service (DDoS) attack. This type of attack is designed to cripple servers by overwhelming them with a flood of network traffic.

vDOS is believed to be behind many of the larger DDoS attacks that have been carried out in the last couple of years. The group had been operating under the radar all this time and is estimated to have amassed no less than $600,000 USD.

In Krebs’ exposé, it was revealed that vDOS was operated by two Israeli teenagers who launched their attacks mainly through servers in Bulgaria. According to Kreb’s article, vDOS not only provided DDoS services to direct customers, they also provided “firepower” to other outfits who, like them, also offered booter services.

Krebs managed to acquire substantial information about vDOS through a source who was investigating another booter service provider called PoodleStresser. During the investigation, that source was able to acquire configuration data from PoodleStresser’s attack servers. Some of the configuration data pointed to vDOS. The source then managed to gain access to vDOS’ servers and acquire databases and configuration files, which in turn led to more disclosures.

The two alleged owners of vDOS were eventually arrested by the FBI (although it’s not known whether the arrest was fueled by Krebs’ revelations). The duo have since been released under a bond of USD $10,000, placed under a 10-day house arrest, and prohibited from using the Internet or telecommunications equipment for 30 days.

But that wasn’t the end of it. About two weeks later, KrebsOnSecurity.com was under a DDoS attack. It wasn’t the first for Krebs by any means, but it certainly was (by a very big margin) the largest. Akamai, which provides pro bono DDoS protection to KrebsOnSecurity.com, was able to withstand the assault at first, but at about 620 Gbps, the attack traffic began to take its toll on Akamai’s resources. To continue defending against the sustained assault meant Akamai had to deploy millions of dollars-worth of resources.

Eventually, Akamai had to throw in the towel and KrebsOnSecurity.com had to temporarily go offline. As of this writing, krebsonsecurity.com is back online. It’s now being secured by Project Shield, a free DDoS protection service owned by Google.

Later, analysis of the attack revealed that, unlike most large scale DDoS attacks, which relied on botnets of misconfigured DNS servers, this one seemed to be originating from hacked IoT-enabled consumer electronic devices like routers, digital cameras, smart firewalls, light bulbs, thermostats, espresso machines, and many others.

These events underline how serious the booter services menace has now become and has taught us a few important things:

  • The scale of this attack is alarming and causes everyone to re-evaluate their defences.
  • Attackers have added IoT devices (of which there are billions) to their real-world arsenal.
  • The criminal business model for DDoS has matured and become very lucrative.

It looks like the Internet of things is really growing up.

Now might be a good time to get a free network risk assessment.

HTML 5 Has Vulnerabilities Too


In our last post, we talked about the imminent demise of Flash and how it’s eventually going to be replaced by HTML 5. One of the reasons why Flash is getting axed is its propensity for vulnerabilities. But before you start letting your guard down, you should know that HTML 5 isn’t totally secure either. Today, we’ll talk about some of the HTML 5 vulnerabilities you need to be aware of.

PostMessage vulnerabilities

One of the major vulnerabilities found in HMTL 5 affects cross-origin communications. These types of vulnerabilities can enable hackers to carry out cross-site scripting attacks or lead to unintentional, unauthorized disclosures.

One problem lies in postMessage; an HTML 5 API that allows data to be exchanged between two pages even if they have different origins (i.e. they don’t use the same protocol, port, and hostname). Normally, cross-origin communications aren’t allowed by the web application security model’s Same Origin Policy (SOP). In theory, postMessage is supposed to provide a controlled way of circumventing the SOP. However, if not implemented properly, this API can expose web applications to critical vulnerabilities.

A web application can be exposed to cross-site scripting if the developer of the receiving page allows the page to receive data sent via the postMessage() method but fails to validate the origin of that message. If the message comes from a malicious source and the receiving page processes the message, the receiving page can be compromised.

On the other hand, unauthorized disclosures can happen if the developer of the sending page uses the postMessage() method but doesn’t specify a particular target/receiver for that message. That is, the developer might simply use the wildcard “*”, which, in effect, allows the message to be sent to any receiver regardless of origin. If the message contains sensitive information, that information could end up in a malicious receiving page.

CORS (Cross-Origin Resource Sharing) vulnerabilities

Another way to circumvent the Same-Origin Policy and enable cross-domain requests (i.e. between different origins) is through the use of CORS. CORS enables cross-domain requests (typically, XMLHttpRequest AJAX requests through JavaScript) in a controlled manner. It does this by employing the following headers, among others:

● Access-Control-Allow-Origin
● Access-Control-Allow-Credentials
● Access-Control-Allow-Methods

There are instances, however, when the Access-Control-Allow-Origin and Access-Control-Allow-Credentials headers are used insecurely.

The Access-Control-Allow-Origin header specifies which origins are allowed to make requests to and read responses from a CORS-enabled server. When that server receives a request, it checks the value of the request’s Origin header and then validates it against a list of allowed domains/origins.

The validation process can vary. Some processes look for a particular string, others use regular expressions, and so on. If the submitted Origin value passes the validation process, the server replies with an Access-Control-Allow-Origin header that contains the submitted value. This is where the problem lies. If the validation process is flawed, the server could end up unintentionally allowing access to a malicious domain.

Just like in the case of postMessage(), vulnerabilities can also occur if the server returns an asterisk (*) for the Access-Control-Allow-Origin header, which basically means the server allows all domains to read the response.

The Access-Control-Allow-Credentials header, on the other hand, defines whether cookies will be sent. Cookies will only be sent if this header’s value is set to True.

Almost all cases of CORS-based attacks require that the Access-Control-Allow-Credentials be set to True. That’s because attackers will need cookies to redirect sensitive information from legitimate sites to the sites they (the attackers) own.

Web Storage Vulnerabilities

HTML 5 supports a nifty performance-enhancing feature known as Web Storage. This feature, which also goes by the name “Local Storage” or “Offline Storage”, allows web applications to take advantage of a client-side database. The web application can, for example, use the database to (persistently) store and access often-used data in order to speed up certain processes. Unfortunately, this local storage, which is accessed via JavaScript, can be subjected to XSS or injection attacks.

For example, if a web application is vulnerable to XSS, like when entries in a text field are not properly sanitized, an attacker may inject malicious script through the text field and that script will be stored in web storage. That malicious code would then be executed each time the user loads the browser and accesses the same site.

What’s more, the contents of localStorage can always be viewed by anyone who has access the same browser. So if you’re using a shared computer, access to any sensitive data stored in localStorage will not be restricted to you.

Because of this vulnerability, it’s never safe to store sensitive information in these local storage databases. This includes login credentials (i.e. usernames and passwords), credit card information, personally identifiable information, and others. In other words, any type of information that you wouldn’t normally store or transmit in plaintext should never be stored in web storage.

WebSockets Vulnerabilities

HTML 5’s WebSocket protocol enables persistent, bidirectional (i.e. full duplex) connections between a client and a server. This capability allows developers to create applications that require real-time data exchanges between client and server. The usual applications include online games, live streaming, chat/messaging, and reporting systems.

Here’s one issue that’s been dubbed the Cross-Site WebSocket Hijacking (CSWSH) vulnerability. The WebSockets protocol doesn’t have any built-in capability for authentication and authorization during handshake. When a client requests a WebSocket connection, the server can carry out client authentication through typical HTTP authentication mechanisms, including cookies, HTTP authentication, or TLS authentication.

The problem is that WebSockets is not governed by the Same Origin Policy. So if an end user is logged in to a WebSockets-enabled application that’s running on the same web browser as a malicious site, that malicious site can potentially take advantage of the authentication credentials (e.g. a session cookie) and then send them along with a handshake request to the WebSocket URL of the application.

Once authenticated, the malicious site will have established a separate WebSocket connection with the same level of privileges as the original connection. Meaning, the malicious site could potentially have read/write capabilities.

Other areas in HTML 5 that are also afflicted with vulnerabilities include geolocation, web workers, sandboxed frames, and offline applications. Of course, most – if not all – of those vulnerabilities can be avoided through secure coding practices.

For instance, in the case of CORS and postMessage vulnerabilities, the developer simply has to be careful in crafting origin validation. But until all web developers are able to adhere to those practices, there will always be HTML 5 web sites that can be exploited.
The rise of HTML 5 as the de facto standard for multimedia and rich web applications is inevitable. Major browsers are starting to ditch programs like Flash and Silverlight in favor of it. The same reception is expected from end users and IT admins, who will no longer have to install and maintain crash-prone third party plug-ins.

As more and more developers write web applications in HTML 5, people must bear in mind that – like all other technologies – HTML 5 also has its fair share of vulnerabilities and that the bad guys are bound to exploit them whenever they can.