Top 8 Vulnerabilities & Hacks of 2014

2014-in-review2014 was a huge year in terms of vulnerabilities, security breaches and malware. Here at Mandalorian, we’ve come up with our top 8 vulnerabilities and hacks…

  1. Sony Pictures Hack
  2. Celebrity Photo Leak
  3. Heartbleed
  4. Shellshock
  5. Backoff
  6. JPMorgan
  7. XEN Hypervisor

#1 Sony Hack

Who: Sony Pictures Entertainment, “Guardians of Peace”

What: Hack and subsequent leak of confidential and personal data.

When: November 24, 2014

On November 24, a group calling themselves the “Guardians of Peace” obtained and subsequently released confidential data (they claim 100 terabytes worth) from Sony Pictures Entertainment. The data included personal information about Sony Picture’s employees and their families, emails between employees, information about executive salaries at the company and copies of unreleased Sony films. Due to how recently this event has occurred it’s not yet clear how the attack was executed, but evidence certainly suggests that the intrusion had been ongoing for at least a year.

The hack received huge amounts of media attention due to the demands by the “Guardians of Peace”. For example, on December 16th, for the first time since the hack, the “Guardians of Peace” mentioned the then upcoming film ‘The Interview’ by name and threatened to take terrorist actions against the film’s New York City premiere at Sunshine Cinema on December 18, as well as on its American wide release date, set for December 25. Sony pulled the theatrical release the following day which drew scathing responses from prominent figures and was even discussed by President Obama. The fallout from the hack resulted in heated accusations between the United States and North Korea; another example of how Cyber incidents have very real consequences.

#2 Celebrity Photo Hack AKA Celebgate/The Fappening

Who: Numerous celebrities

What: Multiple personal data sets mainly belonging to female celebrities were stolen from Apple iCloud.

When: August 31, 2014

On August 31, a collection of almost 500 private pictures of various celebrities, mostly women, and with many containing nudity, were posted on the image board 4chan, IMGUR, Tumblr and Reddit. These images and movies had been taken by hackers who exploited a vulnerability in Apple’s cloud services suite iCloud, specifically in the ‘Find My iPhone’ application.

In order to exploit this vulnerability, the hackers needed to obtain a celebrity email address, which was reportedly obtained through forums which trade in celebrity details. Once they had done this, they then used a proof of concept piece of software from Github called ‘iBrute’ which allowed them to brute force the password to the iCloud account (using the supplied email address). Once they had successfully brute forced the password, they could login and download all the photos, videos and contacts. In some instances they also used Elcomsoft’s Phone Password Breaker, which is a Russian tool developed for law enforcement which “fools” iCloud into thinking that the actual device is connected. This then allowed attackers to take a full backup which also included previously deleted items.

The event became ‘viral’ online, and many celebrities spoke out condemning the hack. It was interesting because unlike major corporate breaches in which various data sets are obtained, this attack disclosed extremely personal and graphic images which were always considered to be safe and private. This, for many people crossed the line and truly made hacking a personal experience.

The celebrity backups compromised in the fappening no doubt contained work as well as personal data. If anything, the fappening tought us that the line between work and personal data <a href=”may be more blurred than we think.

#3 Heartbleed

What: Vulnerability in OpenSSL

When: April 2014

No doubt you’ll all have heard at least some of the media fallout from Heartbleed. It was heavily publicised as a “catastrophic” security bug, while Forbes columnist Joseph Steinberg wrote “Some might argue that Heartbleed is the worst vulnerability found since commercial traffic began to flow on the Internet”.

So what is Heartbleed? Heartbleed is a security vulnerability in the OpenSSL cryptography library, which is a widely used implementation of the Transport Layer Security (TLS) protocol. Heartbleed may be exploited regardless of whether the party using a vulnerable OpenSSL instance for TLS is a server or a client. It results from improper input validation (due to a missing bounds check) in the implementation of the TLS heartbeat extension, thus the bug’s name derives from “heartbeat”. The vulnerability is classified as a buffer over-read, situation where more data can be read than should be allowed.

A fixed version of OpenSSL was released on April 7, 2014. On the same day, Heartbleed was publicly disclosed. At the time of disclosure, some 17% (around half a million) of the Internet’s secure web servers certified by trusted authorities were believed to be vulnerable to the attack, allowing theft of the servers private keys and users session cookies and passwords. On the day of disclosure, the Tor Project advised anyone seeking “strong anonymity or privacy on the Internet” to “stay away from the Internet entirely for the next few days while things settle.” The full fallout from Heartbleed is not yet known, mainly due to how quickly the world reacted to the disclosure, and then in patching OpenSSL. However, there are still many vulnerable hosts on the internet which are still susceptible to Heartbleed.

#4 Shellshock

What: A bug in the Unix Bash shell

When: 12-27 September 2014

Mandalorian have already produced a thorough analysis of the Shellshock bug which you can read about here. The Shellshock Bash bug showed to have massively wide reaching implications due to the prevalence with which Bash is used within Unix and OS X systems.

The maintainer of Bash was warned about the initial discovery of the bug on 12 September 2014; a fix followed soon after however the vulnerability was not publicly disclosed until 24 September 2014 with CVE identifier CVE-2014-6271. Unfortunately it didn’t end there. Within an hour of the announcement of the Bash vulnerability, there were reports of machines being compromised by the bug.

By 25 September 2014, botnets with exploits based on the bug were being used by attackers for distributed denial-of-service (DDoS) attacks and vulnerability scanning. Kaspersky Labs reported that machines compromised in an attack (dubbed “Thanks-Rob”), were conducting DDoS attacks against three targets, which they did not identify. On 26 September 2014, a Shellshock-related botnet dubbed “wopbot” was reported which was being used for a DDoS attack against Akamai Technologies and to scan the United States Department of Defense. On the same day, the security firm Incapsula noted 17,400 attacks on more than 1,800 web domains, originating from 400 unique IP addresses in the previous 24 hours. 55% of the attacks were coming from China and the United States. By 30 September, the website performance firm CloudFlare said it was tracking approximately 1.5 million attacks and probes per day related to the bug.

On 26 September 2014, two open-source contributors, noted that there were additional issues, even after patching systems using the most recently available patches. In an email addressed to the oss-sec list and the bash bug list, Wheeler wrote: “This patch just continues the ‘whack-a-mole’ job of fixing parsing errors that began with the first patch. Bash’s parser is certain to have many many many other vulnerabilities”.

Then on 27 September 2014, Google Inc. announced the discovery of other Bash vulnerabilities, one based upon the fact that Bash is typically compiled without address space layout randomisation. Then finally on 1 October, Google released details of the final bugs and confirmed that a patch from Red Hat posted on 25 September does indeed prevent them.

On 6 October, it was widely reported that Yahoo! servers had been compromised in an attack related to the Shellshock issue, yet the next day, it was denied that it had been Shellshock that specifically had allowed these attacks.

#5 Backoff Malware

What: Backoff Point of Sale (Pos) Malware

Where: Various Point of Sales terminals around the world.

When: July 2014

Backoff is a family of PoS malware which was discovered in 2014. Researchers have identified three primary variants to the Backoff malware including 1.4, 1.55 (“backoff”, “goo”, “MAY”, “net”), and 1.56 (“LAST”). These variations have been seen as far back as October 2013 and were found to be in operation as of July 2014. A malicious stub is injected into explorer.exe and is responsible for persistence in the event the malicious executable crashes or is forcefully stopped. The malware is responsible for scraping memory from running processes on the victim machine and searching for track data. Keylogging functionality is also present in most recent variants of Backoff. Additionally, the malware has a Command and Control (C2) component that is responsible for uploading discovered data, updating the malware, downloading/executing further malware, and uninstalling the malware. The impact of a compromised PoS system affected customers and businesses by exposing customer data such as names, mailing addresses, credit/debit card numbers, phone numbers, and email addresses to attackers. Exactly how much was taken as a result of this malware is yet unclear and what was troubling was that for the majority of the time frame, anti virus did not pick up the malware at all.

#6 JPMorgan

What: JPMorgan Infrastructure Attack

When: June-August 2014

In July 2014 JPMorgan’s security team found a vulnerable server with indicators of compromise. They launched a full scale investigation over the following 2 months and it transpired that the attackers had unleashed malicious programs and zero day malware that had been specifically designed to penetrate their corporate network. The intruders then reached deep into the bank’s infrastructure, siphoning off gigabytes of information, including 76 million private and seven million business data sets over several weeks so as to avoid triggering any alarms, IDS or IPS.

What makes this attack embarrassingly impressive is that 2 months prior to the event being discovered, JPMorgan – the largest U.S. bank, had vowed to spend a quarter-billion dollars a year on Cybersecurity by the end of 2014, with 1,000 workers dedicated to the effort. By comparison, Google Inc. has around 400. JPMorgan takes security extremely seriously and already has one of the most well-funded security teams on Wall Street. That is what makes this attack so impressive.

Jason Healey, director of the Cyber Statecraft Initiative at the Atlantic Council, a Washington policy group said “These attackers have planned for this and they have committed the resources to this in order to defeat some of the strongest defenses and best defenders in the world, and the attack shows what a truly dedicated team of attackers can accomplish when they set their minds and their money to it.”

#7 XEN Hypervisor

What: A vulnerability in Xen Hypervisor

When: October 1, 2014

If you haven’t heard of Xen hypervisor, that’s understandable. Not everyone has. However, Xen Hypervisor happens to be THE proverbial lynchpin that holds the world’s major public cloud providers together. Amazon, Rackspace and IBM SoftLayer are just some of the examples affected by this vulnerability, and all of them had to reboot their servers to fix a flaw in Xen. Unlike the Heartbleed vulnerability in April and the Shellshock vulnerability that was first reported in September, the Xen project was able to keep details of the CVE-2014-7188 flaw private until the major public cloud providers could be patched. The Vulnerability was then publicly disclosed on October 1, 2014. The vulnerability is detailed in Xen Security Advisory XSA-108 and is also identified as CVE-2014-7188. The full vulnerability is titled “Improper MSR range used for x2APIC emulation,” which is a memory-related issue in Model Specific Registers (MSRs). The impact of the vulnerability was that an attacker could potentially crash the underlying host server and then potentially read data from other virtual machines on that system. So, the problem for public cloud providers, for example, is that the flaw could have enabled an attacker to potentially get access to other resources and data on the cloud.

Luckily, this is an example of a well disclosed vulnerability, allowing the vendors to provide a fix, and then disclose to their major customers. If the vulnerability had been publicly disclosed in the first instance, it could have been extremely bad news for the large-scale cloud hosting providers.


What: Vulnerability in OpenSSL3.0

When: September 2014

It’s been a rough year for SSL. First Heartbleed caused huge public awareness into the world of vulnerabilities and encryption and now POODLE. The POODLE (Padding Oracle On Downgraded Legacy Encryption) attack is a man-in-the-middle exploit which takes advantage of Internet and security software clients’ fallback to SSL 3.0. If attackers successfully exploit this vulnerability, on average, they only need to make 256 SSL 3.0 requests to reveal one byte of encrypted messages. Bodo Möller, Thai Duong and Krzysztof Kotowicz from the Google Security Team discovered this vulnerability; they disclosed it in September 2014.

Experts do not generally consider the POODLE attack as serious as the Heartbleed and Shellshock attacks. On December 8, 2014 a variation of the POODLE vulnerability that impacted TLS was also announced. This attack exploits implementation flaws of CBC mode ciphers in the TLS 1.0 – 1.2 protocols. Even though TLS specifications require servers to check the padding, some implementations fail to validate it properly, which makes some servers vulnerable to POODLE even if they disable SSL 3.0. SSL Pulse showed “about 10% of the servers are vulnerable to the POODLE attack against TLS” before this vulnerability is announced. Numerous vendors produced their own implementation errors because this is not a flaw in the protocol itself and is a flaw in the protocol’s implementation.

The POODLE attack against TLS was found to be easier to initiate than the initial POODLE attack against SSL as there is no need to downgrade clients to SSL 3.0, requiring less real-world scenarios to appear active.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s