The End of Flash on Chrome

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 tyoutube flashhis 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.

A Closer Look at Apple’s Bug Bounty Program

apple bug bounty programAt 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

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

Maximum payout = $100,000

  1. Execution of arbitrary code with kernel privileges.

Maximum payout = $50,000

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

Maximum payout = $50,000

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

Understanding the Drive-By Download

Understanding the Drive-By DownloadMost 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.