The biggest malware infections are probably the ones that have yet to be uncovered. Earlier this month, security researchers revealed a massive malvertising-based exploit kit whose earliest variants may have been operating since 2014 and whose infected banner ads might have already been displayed to millions. How could it have remained hidden in plain sight for so long? Apparently, it evaded detection through a combination of fingerprinting/probing and steganography.

The folks at ESET, who recently carried out extensive research on this cyber attack, are attributing the infections to what they now call the Stegano exploit kit. The name comes from the way the exploit kit conceals its malicious code on banner ads, i.e., through steganography.

Steganography is a known technique (not always for malicious purposes) for concealing content inside another piece of content. In most cases, that “other piece of content” is an image. And in this particular case, that image is the one on the banner ad. The content being concealed here is a malicious script and some accompanying variables.

Stegano EK is believed to have reached millions of users. The reason is because it managed to serve its malicious ads on advertising networks whose content is displayed on high traffic news websites. The volume of visitors on these sites number in the millions … per day.

An overview of how the Stegano exploit kit works.

1. Initial environment check.

When a user arrives at an infected news site’s web page, the web page loads along with the malicious banner ad. But before loading the ad, Stegano does an initial check. It does this through a modified version of countly. Countly is a tool normally used for web analytics, so it doesn’t raise any red flags.

The modified tool then reports back to the attacker’s server, providing it with information that enables the server to determine whether to display a clean ad or a malicious ad.

2. Malicious ad is served

The malicious ad is almost identical to the clean ad, except that it has a slightly modified alpha channel. The alpha channel is that part of an RGBA (red green blue alpha) image that dictates a pixel’s degree of transparency. Because the change in the malicious image’s alpha channel is so minimal, the difference between the malicious ad and the clean ad is virtually imperceptible to the naked eye.

However, because a banner’s image consists of a large number of pixels, that difference is enough to conceal information. In this case, malicious script. That script then checks the user’s system for a vulnerability in Internet Explorer (CVE-2016-0162) which allows the exploit kit to determine whether any tools and applications normally used by security professionals are present in the system. If any packet capturing, sandboxing, virtualization and similar applications are found, the exploit kit promptly backs off.

3. Exploit stage

In the event the exploit kit determines the coast is clear, it then redirects the victim’s browser to the exploit landing page. The landing page then loads a Flash file, which in turn exploits any of three Flash-related vulnerabilities (CVE-2015-8651, CVE-2016-1019, CVE-2016-4117).

If the exploit succeeds, Stegano then drops its payload(s), which may range from keyloggers, trojans, to ransomware. Before downloading the payload, Stegano performs yet another check to determine the presence of security tools. It’s this highly cautious approach (coupled with steganography) that has allowed Stegano to avoid detection for so long.

Other malware that has used steganography

While the use of steganography is certainly a unique way of hiding malicious information, Stegano EK isn’t the only malware that has employed this technique. Here are some examples of malware that have also done it in the past.

ZeusVM

A variant of the notorious banking trojan Zeus/Zbot, ZeusVM is one of the more popular pieces of malware that has used steganography. Unlike Stegano though, ZeusVM didn’t hide malicious code in an image. Instead, it hid its configuration data in it. This data, which is equally vital to the malware’s functionality, included domains of banking and financial institutions which the malware targeted.

The configuration data was appended to the image and encrypted using Base64, RC4, and XOR to make it indecipherable to anyone who decided to inspect the image more closely. The ZeusVM toolkit, which included a builder that would enable the user to inject the malware’s config to any JPG file, was spread online, so several script kiddies were able to get their hands on it.

Gozi

Also known as VAWTRAK, Gozi is a banking trojan that steals personal information and credentials (usually through screen captures and keyloggers) that are then used by the attackers to carry out fraudulent transactions. Gozi leveraged steganography to hide a configuration file that contained a list of domain names that in turn corresponded to its Command and Control servers.

The configuration data was hidden in what is known as a favicon. This is a tiny icon (.ico) associated with a website that’s displayed on a web browser. So, for example, you have favicon for Wikipedia and a different favicon for, say, Yahoo. Because it’s normal for websites to be accompanied by a favicon, security solutions failed to flag the favicon downloads as threats.

Gozi more closely resembled Stegano in the manner by which it hid malicious information. Unlike ZeusVM, which simply appended malicious information to the image, Gozi (like Stegano) made very small changes to the image’s pixels. But while Stegano altered the alpha channel, Gozi altered the least significant bits (LSB) of the R, G, B, and A parameters of each pixel.

Lurk

Most malware that use steganography hide malicious information in visually appealing images like cats or sunsets. However, there is one that hid the information in what looked like plain white images but actually had very small alterations in its pixels.

The use of “white color” is actually very clever because the naked eye can’t differentiate between a pure white pixel (RGB = 255,255,255) and one that’s slightly grey (e.g. RGB = 254, 254, 254). Again, that difference, when spread across the pixels that comprise the entire image, is enough to contain malicious information.

This is the kind of image that Lurk used. Lurk is primarily a downloader. When it was discovered, Lurk’s usual payload was click-fraud malware. To retrieve the URL of the malware it was configured to download, Lurk first downloaded an image (the “white” image we discussed earlier), extracted the LSB from each pixel, performed some XOR operations to decode, and then used the retrieved URL to download the actual payload.

To illustrate how difficult it is to distinguish between pure white (RGB=255,255,255) and slightly greyish white with RGB = 254,254,254, try to compare the two images below. The top NEMESIS logo uses pure white, while the bottom logo uses slightly greyish white with RGB = 254,254,254.

Can you tell the difference?

Stegoloader

This is one piece of malware that has a couple of similarities with Stegano. Stegoloader is primarily an information stealer but consists of several modules. Its downloader module is the one that employs steganography.

Its use of steganography isn’t the only characteristic that makes Stegoloader similar to Stegano. First, like Stegano, Stegoloader initially inspects the target system to make sure it’s not running in an analysis environment or that any security tools are present. If it determines that the environment is not safe enough, it automatically aborts the attack. Secondly, unlike Gozi and Lurk, which simply hid URLs, Stegoloader (like Stegano) also hid code.

How to protect your system from Stegano

There are a couple of ways to protect yourself from a Stegano EK attack. There’s absolutely no way you can identify a malicious banner ad by simply looking at it, so you can forget about countering the steganography part of the attack.

First, you can simply avoid using Internet Explorer. The first vulnerability Stegano exploits, which allows it to detect any security monitoring software, is an IE vulnerability. So if you use Chrome, Firefox, or Safari, that could put Stegano off.

Second, you can either update your Adobe Flash installations, switch Flash off, or stop using Flash altogether. This month, Chrome will stop using Flash as the default enabler of web media. The makers of Firefox, Safari, and Edge (Microsoft’s replacement for IE) are also planning a similar move, so that’s something you might want to put into consideration when prescribing browsers to your end users.

Third, you can deploy advanced anti-malware solutions. Remember that, as part of Stegano’s (and Stegoloader’s) security avoidance techniques, it scans for security tools. If it finds one, it will back off.

While most ransomware incidents go unreported, the attack on San Francisco’s Municipal Transport Agency (locally known as Muni) last Black Friday was hard to keep under wraps. The conspicuous message on the screens at ticketing agents’ booths said it all: “You Hacked, ALL Data Encrypted, Contact For Key (cryptom27@yandex.com)ID:681,Enter Key.”

SFMTA, which operates fleets of buses, cable cars, historic streetcars, light railway vehicles (subway), trolley buses and a handful of other public transportations, is now part of a rapidly growing list of businesses that have been victimized by ransomware. For more about this highly disruptive menace of a malware, read our post “The Secrets Behind Ransomware’s Surging Notoriety”.

The disruption from the ransomware attack on Muni, which affected over 2,000 computers, began Friday night and continued the entire Saturday. Affected systems had their hard drives encrypted, forcing the SFMTA to switch off ticket machines at the subway stations. As a result, the commuters were able to get free rides that weekend.

People who communicated with the email address left by the hackers were told that the ransom amount was 100 bitcoins, roughly equivalent to $73,000. This is much bigger than another high-profile ransomware attack that happened earlier this year.

In that attack, the Hollywood Presbyterian Medical Center ended up paying the ransom of $17,000 worth of bitcoins. Although most attacks only cost about $600-$700, there have been reports of ransom demands reaching up to as high as $150,000.

According to the extortionist who replied at the Yandex email address, SFMTA was not a victim of a targeted attack. Rather, it was more likely that someone working at SFMTA unwittingly downloaded a trojan that actually contained the ransomware. The reason the malware was able to spread through the network was likely because the user might have been using a workstation with admin level privileges.

This is consistent with the common characteristics of ransomware. They’re usually designed to spread through non-targeted phishing attacks and exploit kits. Whomever accidentally downloads the malware becomes a victim. Not all ransomware has worm-like capabilities that allow it to propagate through the network, but sadly for SFMTA, this one did.

There has been no indication that SFMTA paid any ransom to get their systems back. In fact, it’s believed their IT folks managed to recover from backups. Backups are an effective way of recovering from a ransomware attack. However, you shouldn’t be over-dependent on them, as ransomware developers have started introducing features that enable their malware to spread to backup systems as well.

So, which particular ransomware was responsible for this attack? Apparently, that distinction goes to HDDCryptor. Upon infection, which is initiated through a downloaded executable, HDDCryptor drops several components in the Windows root folder and then runs a service known as DefragmentService. The service is responsible for maintaining the malware’s persistence in the infected system.

HDDCryptor is designed to identify currently mounted drives as well as previously connected drives and then encrypt all files. To encrypt, the malware relies on an open source disk encryption software known as DiskCryptor. DiskCryptor also enables HDDCryptor to overwrite the Master Boot Record and display the ransom message.

Because of the malware’s capability to scan the system for mounted drives and previously accessed network folders, it’s highly possible that backups (depending on how they were configured) were also infected.

This particular case brings to the fore the cyber threats faced by public transportation and utilities. While this attack fortunately did not result in any physical harm, future attacks might not be as harmless.

Botnets are responsible for many of the cyber attacks we encounter these days; from DDoS and spam attacks to keylogging and click fraud. In today’s post, we take a closer look at how a botnet attack works – how it gains a foothold into each botnet slave, how each slave communicates with the C&C servers, and how the entire botnet carries out nefarious acts.

Malware infection

All botnets are networks of enslaved devices known as “bots”. That’s really where the term “botnet” comes from. And so, before a botnet comes into existence, a large number of devices must first be infected with malware that turn these devices into unwitting bots (a.k.a. zombies).

So how do these devices get infected in the first place? Well, it depends on the type of device. In the case of desktops, laptops, phones, and tablets, these devices typically get infected when the people using them either:

1. Visit a malicious site and download malware without noticing it (a.k.a. drive-by-download) or
2. Consciously download a file through an email or website without knowing it’s actually malware (a.k.a. a trojan).

In the case of IoT devices, they usually get compromised after attackers actively break into them. For example, the attacks that ensnared IoT devices into the Mirai botnet and Mirai-wannabes, the attackers used automated tools that scanned networks for weak passwords, broke in through brute force, and installed the malware.

Once devices become infected and become bots, they then communicate with the command and control servers or C&Cs.

Botnet C&Cs

The C&Cs are the servers that deliver commands to the bots, directing them to targets and instructing them what to do. Traditionally, botnets operate under a client-server model, wherein the bots act as the botnet clients and the C&Cs act as the servers. There can be one or more Command and Control servers in a botnet.

Having multiple C&Cs provides redundancy and enables botnets to acquire high availability capabilities. Meaning, if one C&C goes down, the botnet clients can still receive commands from the other C&Cs. Nevertheless, having multiple C&Cs doesn’t make a client-server-type botnet indestructible. Its survival still relies heavily on the C&Cs. If the C&Cs are identified and eventually brought down, the entire botnet will be no more.

This is how massive botnets like Mariposa and Bredolab were dismantled. After their C&Cs were tracked down, the end of these malicious networks became imminent.

Today, many botnets follow a different architecture. To avoid total reliance on a group of C&Cs, these botnets now use a P2P model, wherein each botnet client also functions as a C&C. This type of botnet is much harder to take down.

Botnet Communications

Most bots communicate with their C&Cs using either one of two communications protocols – IRC (Internet Relay Chat) or HTTP (HyperText Transfer Protocol). Other botnets also employ other communication methods but these two are definitely the most commonly used.

IRC communications can be easily automated (using scripts). In addition, open source IRC servers are readily available. That’s why this protocol used to be a perfect fit for botnet creation and deployment. During infection, a typical botnet malware would install an IRC client, which in turn would then communicate with the IRC server on the C&C.

The characteristics of IRC, while a boon for botnet operations, has ironically also become many a botnet’s undoing. If you really think about it, Internet Relay Chat is no longer a common method of communication (most people now use Instant Messaging applications). And so, ever since IRC became associated with botnets, the presence of IRC packets has often raised red flags. Some system admins even started blocking IRC packets in their firewalls.

It is for this reason that malware writers have started to turn to a more firewall-friendly option as their botnet communication protocol of choice. And what network protocol can be more firewall-friendly than HTTP? All websites (including popular ones like Google, Facebook, and Amazon) all communicate via HTTP. So if a botnet uses HTTP, there’s a lower chance of it getting flagged down because, unlike IRC packets, HTTP packets don’t easily stand out.

Zeus, one of the most notorious botnets ever, communicated via HTTP. In fact, several exploit kits incorporate HTTP communications into their botnet malware payloads.

Botnet attacks

One of the most common botnet attacks is the DDoS or Distributed Denial of Service attack. In this type of attack, all bots send out requests to a target server with the purpose of overwhelming it and preventing legitimate requests from getting through or processed.

Another common botnet attack – in fact, arguably the most common cyber attack that employs botnets – is sending out tons of spam. In a typical spam attack, bots send out spam emails to target email addresses with the purpose of getting click-throughs and, ultimately, generating ad revenue.

Botnets can also be used to steal information from enslaved devices. Some bot clients operate as keyloggers that record end user keystrokes. Keyloggers can, for example, record the password characters an end user enters during login and then send this information to the bot herders.

Lastly, botnets can also be used for click fraud activities. Bot clients can click on ads and trick ad networks that the clicks came from legitimate end users.

Preventing botnet attacks

Botnet malware infections can be avoided by educating end-users about the risks and best practices of downloading email attachments and visiting web sites. Of course, this countermeasure has its limitations. Most end users find security practices too tedious and time consuming, and often disregard them. Further, some threats (like drive-by-downloads) are just too difficult to avoid.

The best way would is to employ advanced malware protection solutions. These solutions typically combine advanced network behaviour analysis and real time intelligence to detect even the most stealthy malware infections.

IoT botnets have been responsible for multiple record-breaking DDoS attacks that managed to cripple even some of the most resilient networks in the world.

So far, the largest attacks have been caused by one particular malware family – Mirai. Although the original botnet is probably on its way out, its offspring and competitors in the malware trade are on the rise.

Record breaking DDoS attacks

The Mirai’s claim to fame included massive attacks on the Krebs On Security site (620 Gbps), French web host OVH (1 Tbps), and DNS provider Dyn (1.2 Tbps). That attack on Dyn, the largest DDoS on record (for now), prevented users in Europe and North America from connecting to a large number of popular sites.

Twitter, Amazon, CNN, PayPal, Reddit, Visa, SoundCloud, and AirBnB were just some of the many high-profile sites that were affected by that single attack.

Mirai malware source code

There seemed to be a sliver of good news when a Hackforums user, whom some believed was the creator of Mirai, expressed intention of hanging up his/her cape. Going by the nickname of “Anna-senpai”, the user posted that when he/she first entered into the DDoS industry, he/she “wasn’t planning on staying in it long.”, adding that “I made my money, there’s lots of eyes looking at IOT now, so it’s time to GTFO”

But as it turned out, the entire announcement was really a portent of what could potentially be an even greater threat. The user continued the post saying, “So today, I have an amazing release for you…”. That release turned out to be the source code of the Mirai malware itself. The source code can now be found on Github.

So with the Mirai source code out in the open, what else could anyone expect? Naturally, it shouldn’t take long for other miscreants to develop their own versions of IoT botnet malware.

That’s probably what happened here…

Linux/IRCTelnet

Very recently, a botnet with similar characteristics as Mirai was discovered by researchers at white hat security research group MalwareMustDie.org. Dubbed Linux/IRCTelnet, this botnet snags IoT devices by taking advantage of the default passwords hard-coded in them. These passwords are usually weak (and hence easily broken by brute force attacks) or have already been disclosed in hacking forums (some, via the Mirai botnet).

The botnet clients receive commands from malicious C&C IRC servers through the Telnet protocol. To cripple targets, the Linux/IRCTelnet can carry out Denial-of-Service mechanisms like UDP flood, TCP flood, and several other attacks through both the IPv4 or IPv6 protocols.

Bashlite

Another IoT botnet we should be worried about is Bashlite. While Linux/IRCTelnet is still on the rise, Bashlite is already quite well established. Apparently, this malware family has already managed to infect a million endpoint devices, the majority of which are IoT devices, and has even been used to conduct DDoS attacks-for-hire.

Like the other two IoT botnets, Bashlite also exploits default usernames and passwords. It can launch TCP and UDP floods, and can even carry out HTTP attacks.

The malicious code used by these types of malware reside in memory. So, theoretically, they can be removed by simply restarting the compromised devices. However, the volume of scans conducted by these malware are so large, that they can also as easily re-infect the restarted devices.

The use of default or non-configurable login credentials is one of the vulnerabilities we outlined in our post “IoT Vulnerabilities – What Should You Secure?”. Unless this vulnerability, which exists in a large number of IoT devices out there, is addressed, IoT botnets like Linux/IRCTelnet and Mirai will continue to exploit it.

We’ve already seen what IoT vulnerabilities can lead to. The massive DDoS attacks on DYN, was easily one of the largest DDoS attack ever. As it turned out, that attack was launched not from the usual botnet of hijacked servers, but from a multitude of IoT devices.

It happened before. It can happen again.

Sadly, the use of IoT devices as an attack vector is just one of the myriad of security issues that now plague this nascent technological ecosystem. It’s important to grasp the implications of these developments and see if we can learn from what has happened in the past.

Not so long ago, we also saw the explosion of the Internet. During the early stages of its rapid growth, architects, engineers, and developers rolled out wave upon wave of technologies that, while equipped with great functionality, were seriously lacking in security. Protocols like FTP, HTTP, and Telnet are the first few examples that come to mind.

Many of these grossly insecure technologies, which even now are still used by many organizations, are putting people and businesses at risk. Attackers exploit their vulnerabilities to steal confidential information, infiltrate networks, or carry out a variety of nefarious acts.

Alarmingly, we seem to be experiencing deja vu with the Internet of Things. Stimulated by the almost unlimited supply of IP addresses through IPv6 along with technological advancements and cost reductions, we’re now seeing a market being flooded by a plethora of products. But close inspection of these products reveal that many of them were built with very little regard to security.

The Open Web Application Security Project has identified these ten (10) as the top vulnerabilities and security issues that afflict most IoT devices and their supporting systems.

1.   Insecure Web Interface

Most IoT devices are administered through a Web Interface. Unfortunately, many of these Web interfaces have weak security. For example, some of them simply accept login credentials in plaintext. Others don’t require the use of strong passwords. Still others don’t have provisions to lock out users who have made several failed login attempts (an indication of a brute force attack). If these weaknesses are not addressed, they can be exploited and subsequently result in data loss or even loss of control over the device.

2.   Insufficient Authentication/Authorization

When IoT is introduced into highly critical areas like energy, healthcare, manufacturing, transportation, and telecommunications, run-of-the-mill authentication/authorization systems are not enough. IoT systems deployed in mission-critical areas must be equipped with multi-factor authentication and granular access control mechanisms that can substantially reduce the risk of unauthorized access.

Without strong authentication/authorization systems, administrative user accounts can easily fall into the hands of impostors, who will then have the ability to execute commands or access other parts of the internal network. These malicious individuals can then wreak havoc and endanger lives and property.

3.   Insecure Network Services

IoT systems rely heavily on network communications. For this reason, these networks must be tightly secured. Otherwise, network services can be compromised through buffer overflows, fuzzing, DDoS, and other forms of attacks.

First, devices can be rendered unusable. Second, they can either be subjected to a denial of service attack or themselves used to launch such attacks. The DDoS attacks on KrebsOnSecurity.com and DYN are perfect examples of what can happen when IoT devices fall into the wrong hands.

4.   Lack of Transport Encryption/Integrity Verification

In an IoT environment, data transmissions are usually carried out between several endpoints. There may be data exchanges between:

• Mobile apps and front-end cloud services
• Web applications and front-end cloud services
• IoT devices and back-end cloud services
• Mobile apps and IoT devices
• IoT devices and other IoT devices

Ideally, these data exchanges should be transmitted through TLS-protected protocols or other secure channels. But if these communications are carried out over unencrypted protocols, transmitted data can be intercepted and acquired.

Depending on the kind of data that ends up compromised, attackers can do different things to it. If it were login credentials, those credentials could be used for gaining access to the system. Other pieces of data could be aggregated and then used to provide insightful information regarding certain behaviors of either the users or the system as a whole. Still others could be tampered with, thereby harming the integrity of the system.

5.   Privacy Concerns

Some IoT devices collect and store personal information such as the user’s birthday, phone number, home address, gender, or, worse, financial or health information. This can have huge repercussions from a privacy perspective, as personal information can be used to perform identity theft. Businesses that use these kinds of IoT devices are subject to the requirements of laws and regulations like HIPAA, PCI-DSS, SOX, GLBA, and several state data breach notification legislations.

Thus, if your business is operating in a highly regulated industry and you’re planning to deploy IoT devices in the workplace, you should make sure personal information is adequately protected.

6.   Insecure Cloud Interface

Cloud services are vital to IoT systems. They facilitate data exchanges between IoT devices and their respective web/mobile applications as well as data exchanges between IoT devices and other IoT devices. It’s also where the bulk of the data gathered by IoT endpoints are stored and processed. This data is used for analytics, control, integration with enterprise applications, and several other purposes.

It’s therefore imperative to ensure the security of cloud interfaces. Failure to do so may result in massive data loss as well as loss of control of all devices connected to the cloud platform. Worse, if these cloud services are also connected to enterprise applications, those applications can likewise be at risk of getting attacked. Poorly designed cloud interfaces usually suffer from weak authentication/authorization mechanisms, lack of data-in-motion encryption, and other access control deficiencies.

7.   Insecure Mobile Interface

There are usually two ways to administer/manage IoT devices. One is through a web interface, which we discussed earlier, another is through a mobile interface, i.e. through an app running on an iOS, Android, or Windows device. Like web interfaces, mobile interfaces need to be equipped with strong authentication/authorization mechanisms.

If an attacker manages to gain unauthorized access into an IoT device’s corresponding mobile app, that attacker will in turn be able to control the IoT device. In other words, he could, for example, open doors, manipulate processes, cut off power, or shut down support systems.

8.   Insufficient Security Configurability

Secure devices are usually equipped with configurable security features. You can, for example, choose the number and type of characters required for password authentication. It might be all right if the built-in security level is only high/strict. But this is seldom the case. Devices that have non-configurable security are usually set to low levels of security.

9.   Insecure Software/Firmware

Some IoT devices perform firmware updates (mostly during restarts or at regular time intervals) through insecure network protocols like TFTP. On its own, TFTP is neither encrypted nor is it equipped with strong authentication features. Hence, it is highly vulnerable to man-in-the-middle attacks.

Once an attacker is able to grab the firmware update as it traverses the network, he could modify it to serve his own purposes. After tampering with it, the attacker can then push the modified update to the device and subsequently gain control. If the device is a hub that communicates with other IoT devices, the attacker might then be able to take over those devices as well.

These man-in-the-middle attacks are typically carried out in the local network. However, it’s also possible to perform a malicious update through Internet-based attacks like DNS hijacking.

Equally important is the ability of the device to perform security updates. If the device is incapable of carrying out updates, it wouldn’t be able to patch security vulnerabilities.

10.       Poor Physical Security

The physical security of an IoT device, especially one used in a business setting, is as critical as the other technical security we mentioned earlier in this post. Imagine what could happen if a malicious individual gains physical access to a mission-critical device.

He could remove or break into the storage medium and extract whatever information is stored there. If the device is equipped with external ports like a USB port or an SD card slot, the intruder could gain access through those and attack the operating system or storage medium.

It might seem like a pretty long list but there’s really no way around it. IoT is poised to be tightly interwoven into the fabric of society. If IoT systems can be easily compromised, the potential damage to people (not just IT systems or infrastructure) can be catastrophic. It is therefore imperative that businesses carefully scrutinize what and how IoT systems are incorporated into the organization and ensure that more than just adequate security is enforced.

Learn how Defence Intelligence can improve your security posture http://defintel.com

Late 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.

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.

For those who haven’t seen the writing on the wall, it’s finally being read aloud for you. Google is removing Flash from Chrome, and they’ve laid out a timetable for doing it.

Timeline of the Flash Phase out

When Chrome 53 rolls out this September, it will start blocking tiny Flash-enabled content. This is what is responsible for things such as page analytics. Although running  in the background, Flash-based page analytics can drag down a web page’s load time and responsiveness while also draining precious battery life.

But that’s just a prelude to what will happen before the year ends. When Chrome 55 arrives in December, that iteration of the world’s most widely used web browser will feature HTML5 as the default enabler for all web media. When that happens, it will signal the end of Adobe Flash’s lengthy reign as the de facto platform for web animations, games, videos, and interactive content.

Many people saw this coming. Back in September 2015, Chrome 42 was released with a default setting that paused Flash-enabled animations that were smaller than 400 x 300 pixels. That default setting did not include content 5×5 pixels and below. The main reason? There was no other way to detect viewability then. With the introduction of Intersection Observer, that is no longer an issue

Chrome isn’t the only browser distancing itself from Flash. The makers of Edge, Firefox, and Safari have all announced similar plans. Like Google, they plan on starting with click-to-play settings before eventually blocking  Flash content by default.

Security Implications

Although what most people notice are the browser crashes, the battery drain, and the sluggish webpage responses, Flash has one more weakness that’s making it even more difficult for companies to justify supporting it. Flash has too many vulnerabilities. Adobe releases security updates quite often,yet the vulnerabilities just keep popping up.

This onslaught of vulnerabilities is the primary reason why Flash is a constant target of exploit kits and other attack packages that pave the way for ransomware, viruses, malware, rootkits, trojans, and a host of other malware. When malware infects systems through drive-by downloads, it’s usually through Flash plugin vulnerabilities.

Flash can put businesses at even greater risk when system admins and users fail to patch or when a zero day vulnerability emerges. A zero-day is a vulnerability that’s initially unknown to the vendor (in this case, Adobe). Until the vendor is informed of the vulnerability, and more importantly, releases a security update, that vulnerability can be exploited.

Because Flash is used in a wide range of Web elements, attackers can get quite creative in crafting an exploit. An attacker can gain access into a system by tricking users to:

• Launch a PDF
• Play a video
• Visit a website (drive-by downloads)
• Install the “Flash plugin”
• Or even install a “critical Flash update”

When the time comes for Flash to finally bow out, it will be taking along with it the security holes that attackers have long been taking advantage of.

So does that mean the Web will now be a safer place? Hopefully. HTML5, Flash’s designated successor for browser enhancement and rich internet applications, is considered to be more secure – at least for now. But to clarify, HTML5 is no panacea. It hasits own share of vulnerabilities (e.g. XHR, tag, fat client, and DOM vulnerabilities, to mention a few). We’ll talk about those HTML5 vulnerabilities in a later post. In the meantime, if you’re looking to enhance the security of your organization, give us a trial run today.

At the recently concluded BlackHat conference in Las Vegas, Apple announced that it was finally launching its own bug bounty program. The program will initially cover five categories.

According to Apple’s head of security engineering and architecture, Ivan Krstic, the bounty program will initially consist of the following five categories:

1. Vulnerabilities and proof-of-concept code in secure boot firmware components.

Maximum payout = $200,000

2. Extraction of confidential material protected by the Secure Enclave Processor.

Maximum payout = $100,000

3. Execution of arbitrary code with kernel privileges.

Maximum payout = $50,000

4. Unauthorized access to iCloud account data on Apple servers.

Maximum payout = $50,000

5. Access from a sandboxed process to user data outside that sandbox.

Maximum payout = $25,000

Clearly, Apple sees these 5 as critical areas and hence has given them top priority. Let’s take a closer look to understand why.

Vulnerabilities and proof-of-concept code in secure boot firmware components

iOS security starts the moment the device is switched on. In what is known as the secure boot chain or chain of trust, key components involved in the start-up process (which include bootloaders, kernel, kernel extensions, and baseband firmware) undergo a series of verification steps. Each step can only proceed to the next if certain components have been verified as having been digitally signed by Apple. The components involved, arranged in the order they are loaded, are: the BootROM → LLB (Low Level Boot) Loader → iBoot → Kernel.

This secure boot chain is supposed to ensure that iOS can only run on a valid “iDevice” and, conversely, an Apple mobile device can only boot into iOS. It also helps ensure that only trusted code and apps can run on an Apple device. However, as with all chains, if one link is broken, the rest of the chain will give way. Being the device’s first line of defense, it’s imperative that any vulnerabilities in it are be identified.

Extraction of confidential material protected by its Secure Enclave Processor

Secure Enclave is a coprocessor that’s been fabricated into Apple’s A-series processors since Apple A7. It’s best known as the place in an Apple device where Touch ID fingerprint information is processed and stored in encrypted form. In fact, it’s where all cryptographic operations for Data Protection key management take place.

Data Protection is a proprietary Apple technology responsible for encrypting user data for system apps like Messages, Mail, Contacts, Photos, and Health, as well as in third-party apps installed on the device. If confidential material protected by Secure Enclave can be extracted, the data in these apps can be compromised.

Execution of arbitrary code with kernel privileges

Arbitrary code execution refers to an attacker’s ability to execute commands in a computer system by exploiting vulnerabilities. Since the kernel is the heart of iOS (or any OS for that matter), any arbitrary code execution vulnerability in it can have serious repercussions. Some iOS kernel vulnerabilities that have been exploited in the past include arbitrary memory overwrites, uninitialized kernel variables, stack-based buffer overflows, and heap-based buffer overflows, to mention a few.

Unauthorized access to iCloud account data on Apple servers

I imagine you recall “Celebgate” or “The Fappening” iCloud photos leak involving celebrities like Jennifer Lawrence, Kate Upton, Kirsten Dunst, and many others. No further explanation needed.

Access from a sandboxed process to user data outside that sandbox

In iOS, all third-party apps are placed in a “sandbox” environment, which prevents them from gaining access to files stored by other apps or even making changes to the device. They’re also restricted from system files and resources. And although they are granted access to user information as well as to features like iCloud, their access privileges are highly controlled.

Unfortunately, like its other security features, iOS’ sandbox mechanism can still have vulnerabilities. Last year, for example, a vulnerability involving MDM (mobile device management) solutions put enterprise credentials at risk.

Security experts have long been urging Apple to offer a bug bounty program and Apple has long been ignoring them. The tech giant prides itself on having top notch security, and are well known for doing things their own way. It speaks to the general state of security and the sheer volume of threats that Apple has finally made this step.

If an organization with Apple’s expertise and resources needs help finding vulnerabilities, do you? Contact us to find what your other security tools may have missed.

Most malware infections now originate from the Web and the majority of those come from drive by downloads. Because it works in the background and doesn’t require human intervention, the drive-by download has become one of the most preferred methods for spreading malware.

With this method of infection, the victim need only visit a malicious website in order to get infected. You don’t even have to click anything to initiate the download. But how is this possible? Wouldn’t this mean no one can ever be safe on the Web? Well not really.

A drive-by download usually relies on what are known as exploit kits. These are installed on malicious sites and scan each visitor’s Web browser for vulnerabilities to exploit. Once a browser or browser plugin vulnerability is found, the download, which takes place in the background, commences.

Because exploit kits (which pave the way for drive-by downloads) work by exploiting vulnerabilities, you can counter them by addressing those vulnerabilities. How? By keeping browsers, Java and Adobe Flash installations, and other add-ons up-to-date. Software updates usually include security patches. The problem is, most users simply don’t take time to update. That’s why exploit kits and drive-by downloads are so prevalent.

Given that drive-by downloads are web-based, they can be used to attack any platform that connects to the Internet and has a Web browser. That means, it doesn’t matter if you’re using Windows, Linux or Mac OS X. The Flashback Trojan for example, managed to herd 600,000+ computers into a botnet, attacked Mac OS X.

Similarly, desktops and laptops aren’t the only devices at risk. Smartphones and tablets are at risk as well. Just last month (July 2016), millions of Android devices were infected with malware that allowed attackers to gain root access. Known as Hummingbad, it infected Android-powered mobile devices mainly through web pages that initiated drive-by downloads.

A web page that initiates a drive-by download is typically hosted on either a malicious site or a legitimate site that redirects to a malicious site. In order to redirect visitors, attackers insert malicious code in the legitimate website, i.e. through an insecure form or iframe.

These malicious items are rarely detected. Few organizations keep a close watch on their pages for threats, and even if they do, the attackers attempt to stay hidden using various obfuscation techniques. Obfuscation basically renders malicious code unreadable while preserving the code’s functionality. Most obfuscation techniques are applied to JavaScript (not related to Java). Not surprisingly, JavaScript is the most common type of script that’s processed by web browsers.

Attacks that take advantage of legitimate websites and domains (such as domain shadowing) are particularly hard to counter. Blacklisting and domain reputation solutions are problematic as you could end up blocking a reputable or business critical domain. For many, the trade-off is not worth the risk.

Drive-by download payloads can vary. Ransomware is the most popular of late, but they can also include rootkits, worms, viruses, spyware, trojans, keyloggers, and a host of others. Any of which can wreak havoc on your systems or your network.

So how do you protect your users from drive-by downloads? First and foremost, proper update and patching protocol. Secondly, user training and awareness is key. Lastly, you need a security solution that can block both malicious sites as well as the compromised components of legitimate sites.  Feel free to learn more about how our solution addresses drive-by downloads.