Nethammer—Exploiting DRAM Rowhammer Bug Through Network Requests

Last week, we reported about the first network-based remote Rowhammer attack, dubbed Throwhammer, which involves the exploitation a known vulnerability in DRAM through network cards using remote direct memory access (RDMA) channels.

However, a separate team of security researchers has now demonstrated a second network-based remote Rowhammer technique that can be used to attack systems using uncached memory or flush instruction while processing the network requests.

The research was carried out by researchers who discovered Meltdown and Spectre CPU vulnerabilities, which is independent of the Amsterdam researchers who presented a series of Rowhammer attacks, including Throwhammer published last week.

If you are unaware, Rowhammer is a critical issue with recent generation dynamic random access memory (DRAM) chips in which repeatedly accessing a row of memory can cause “bit flipping” in an adjacent row, allowing attackers to change the contents of the memory.

The issue has since been exploited in a number of ways to escalate an attacker’s privilege to kernel level and achieve remote code execution on the vulnerable systems, but the attacker needed access to the victim’s machine.

However, the new Rowhammer attack technique, dubbed Nethammer, can be used to execute arbitrary code on the targeted system by rapidly writing and rewriting memory used for packet processing, which would be possible only with a fast network connection between the attacker and victim.

This causes a high number of memory accesses to the same set of memory locations, which eventually induces disturbance errors in DRAM and causes memory corruption by unintentionally flipping the DRAM bit-value.

The resulting data corruption can then be manipulated by the attacker to gain control over the victim’s system.

“To mount a Rowhammer attack, memory accesses need to be directly served by the main memory. Thus, an attacker needs to make sure that the data is not stored in the cache,” the researcher paper [PDF] reads.

Since caching makes an attack difficult, the researchers developed ways that allowed them to bypass the cache and attack directly into the DRAM to cause the row conflicts in the memory cells required for the Rowhammer attack.

Researchers tested Nethammer for the three cache-bypass techniques:

  • A kernel driver that flushes (and reloads) an address whenever a packet is received.
  • Intel Xeon CPUs with Intel CAT for fast cache eviction
  • Uncached memory on an ARM-based mobile device.

All three scenarios are possible, researchers showed.

In their experimental setup, researchers were successfully able to induce a bit flip every 350 ms by sending a stream of UDP packets with up to 500 Mbit/s to the target system.

Since the Nethammer attack technique does not require any attack code in contrast to a regular Rowhammer attack, for example, no attacker-controlled code on the system, most countermeasures do not prevent this attack.

Since Rowhammer exploits a computer hardware weakness, no software patch can completely fix the issue. Researchers believe the Rowhammer threat is not only real but also has potential to cause real, severe damage.

For more in-depth details on the new attack technique, you can head on to this paper, titled “Nethammer: Inducing Rowhammer Faults through Network Requests,” published by the researchers earlier this week.

Go to Source

Red Hat Linux DHCP Client Found Vulnerable to Command Injection Attacks

A Google security researcher has discovered a critical remote command injection vulnerability in the DHCP client implementation of Red Hat Linux and its derivatives like Fedora operating system.

The vulnerability, tracked as CVE-2018-1111, could allow attackers to execute arbitrary commands with root privileges on targeted systems.

Whenever your system joins a network, it’s the DHCP client application which allows your system to automatically receive network configuration parameters, such as an IP address and DNS servers, from the DHCP (Dynamic Host Control Protocol) server.

The vulnerability resides in the NetworkManager integration script included in the DHCP client packages which is configured to obtain network configuration using the DHCP protocol.

Felix Wilhelm from the Google security team found that attackers with a malicious DHCP server, or connected to the same network as the victim, can exploit this flaw by spoofing DHCP responses, eventually allowing them to run arbitrary commands with root privileges on the victim’s system running vulnerable DHCP client.

Although full details of the vulnerability have not been released, Wilhelm claims his PoC exploit code is so short in length that it even can fit in a tweet.

Meanwhile, Barkın Kılıç, a security researcher from Turkey, has released a tweetable proof-of-concept exploit code for the Red Hat Linux DHCP client vulnerability on Twitter.


In its security advisory, Red Hat has confirmed that the vulnerability impacts Red Hat Enterprise Linux 6 and 7, and that all of its customers running affection versions of the dhclient package should update their packages to the newer versions as soon as they are available.

“Users have the option to remove or disable the vulnerable script, but this will prevent certain configuration parameters provided by the DHCP server from being configured on a local system, such as addresses of the local NTP or NIS servers,” Red Hat warns.

Fedora has also released new versions of DHCP packages containing fixes for Fedora 26, 27, and 28.

Other popular Linux distributions like OpenSUSE and Ubuntu do not appear to be impacted by the vulnerability, as their DHCP client implementation doesn’t have NetworkManager integration script by default.

Go to Source

Here’s How eFail Attack Against PGP and S/MIME Encrypted Emails Works

With a heavy heart, security researchers have early released the details of a set of vulnerabilities discovered in email clients for two widely used email encryption standards—PGP and S/MIME—after someone leaked their paper on the Internet, which was actually scheduled for tomorrow.

PGP and S/MIME are popular end-to-end encryption standards used to encrypt emails in a way that no one, not even the company, government, or cyber criminals, can spy on your communication.

Before explaining how the vulnerability works, it should be noted that the flaw doesn’t reside in the email encryption standards itself; instead, it affects a few email clients/plugins that incorrectly implemented the technologies.

Dubbed eFail by the researchers, the vulnerabilities, as described in our previous early-warning article, could allow potential attackers to decrypt the content of your end-to-end encrypted emails in plaintext, even for messages sent in the past.

According to the paper released by a team of European security researchers, the vulnerabilities exist in the way encrypted email clients handle HTML emails and external resources, like loading of images, styles from external URLs.

Here’s How the eFail Attack Works:


Email clients are usually configured to automatically decrypt the content of encrypted emails you receive, but if your client is also configured to load external resources automatically, attackers can abuse this behavior to steal messages in plaintext just by sending you a modified version of the same encrypted email content.

The attack vector requires injected plaintext into the encrypted mail, and then using the exploit, it will exfiltrate the originally encrypted data as soon as any recipient’s mail client accesses (or decrypts) the message

It should be noted that to perform an eFail attack, an attacker must have access to your encrypted emails, which is then modified in the following way and send back to you in order to trick your email client into revealing the secret message to the remote attacker without alerting you.

As described in the proof-of-concept attack released by the researchers, the attacker uses one of the encrypted messages you are supposed to receive or might have already received and then turns it into a multipart HTML email message, as well as forges the return address, so it appears to come from the original sender.

In the newly composed email, the attacker adds an unclosed image tag, like this <img src=” just before the encrypted content and ends it by adding the end of the image tag, like this: .jpg”>, as clearly shown in the screenshot.

When your vulnerable email client receives this message, it decrypts the encrypted part of the message given in the middle, and then automatically tries to render the HTML content, i.e., the image tag with all the decrypted text as the new name of the image, as shown below.


Since your email client will try to load the image from the attacker-controlled server, the attacker can capture this incoming request, where the filename contains the full content of the original encrypted email in plaintext.

Although PGP has been designed to show you a warning note if the integrity of your email is compromised, a few email clients do not display these warnings, allowing any potential attackers to perform eFail attacks successfully.

How To Prevent Against eFail Attacks


Generally, it is a very tough job for an advisory to even intercept your encrypted emails, but for people desperately using email encryption always attract well-resourced and sophisticated attackers.

Ditching the use of PGP or S/MIME to prevent eFail attacks would be stupid advice, as it is quite easy to mitigate the reported issues.

Users can switch to a good email client that always shows a warning when the integrity of the emails is compromised and doesn’t render HTML emails by default to prevent loading of external resources automatically.

Researchers also advise users to adopt an authenticated encryption algorithm for sensitive communication.

The research was conducted by a team of researchers, including Damian Poddebniak, Christian Dresen, Fabian Ising, and Sebastian Schinzel from Munster University of Applied Sciences; Jens Müller, Juraj Somorovsky, and Jörg Schwenk from Ruhr University Bochum; and Simon Friedberger from KU Leuven.

For more in-depth details on the attack technique, you can head on to this informational page about the eFail attack and the paper [PDF] titled, “Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels,” published by the researchers.

Go to Source

Severe Bug Discovered in Signal Messaging App for Windows and Linux

Security researchers have discovered a severe vulnerability in the popular end-to-end encrypted Signal messaging app for Windows and Linux desktops which could allow remote attackers to execute malicious code on recipients system just by sending a message—without requiring any user interaction.

Discovered by Alfredo Ortega, a software security consultant from Argentina, the vulnerability was announcedon Twitter just a few hours ago with a proof-of-concept video, demonstrating how a javascript payload sent over Signal for desktop app successfully got executed on the recipient’s system.

Although technical details of the vulnerability have not been revealed as of now, the issue appears to be a remote code execution vulnerability in Signal or at least something very close to persistent cross-site scripting (XSS) which eventually could allow attackers to inject malicious code onto targeted Windows and Linux systems.

“For the time being, we can only confirm the execution of javascript code. However we are tracking a heap corruption issue, and it’s very likely than the javascript execution could lead to native code execution with additional research.” Ortega told The Hacker News.

Ortega also confirms us that the exploitation of this issue requires chaining a couple of vulnerabilities found by two other security researchers from Argentina, Ivan and Juliano.

“I can confirm that this bug did not exist before and was last introduced because the devs forgot why there was a regex there to begin with. I would like to recommend a comment to this comment if it is not repeated again (TBD),” Ivan said.

At this moment, it is not clear if the primary vulnerability or other chained bugs reside only in the source code of Signal or also in the popular Electron web application framework, the technology on which Signal desktop applications are based.

If the flaw resides in the Electron framework, it might also impact other widely-used desktop applications as well, including Skype, WordPress, and Slack, which also use the same framework.

Moreover, the infosec community is also worried that if this flaw allows remote attackers to steal their secret encryption keys, it would be the worst nightmare for Signal users.

The good news is that the Open Whisper Systems has already addressed the issue and immediately released new versions of Signal app within a few hours after receiving the responsible vulnerability disclosure by the researcher.

The primary vulnerability that triggers the code execution has been patched in Signal stable release version 1.10.1 and pre-release version 1.11.0-beta.3. So, users are advised to update their Signal for desktop applications as soon as possible.

“At this time we are not sure they all [the vulnerabilities chained together] have been fixed” Ortega told The Hacker News.

The latest release also patched a recently disclosed vulnerability in Signal for desktop apps which was exposing disappearing messages in a user-readable database of macOS’s Notification Center, even if they are deleted from the app.

Go to Source

GLitch: New ‘Rowhammer’ Attack Can Remotely Hijack Android Phones

For the very first time, security researchers have discovered an effective way to exploit a four-year-old hacking technique called Rowhammer to hijack an Android phone remotely.

Dubbed GLitch, the proof-of-concept technique is a new addition to the Rowhammer attack series which leverages embedded graphics processing units (GPUs) to carry out a Rowhammer attack against Android smartphones.

Rowhammer is a problem with recent generation dynamic random access memory (DRAM) chips in which repeatedly accessing a row of memory can cause “bit flipping” in an adjacent row, allowing anyone to change the value of contents stored in computer memory.

Known since at least 2012, the issue was first exploited by Google’s Project Zero researchers in early 2015, when they pulled off remote Rowhammer attacks on computers running Windows and Linux.

Last year, a team of researchers in the VUSec Lab at Vrije Universiteit Amsterdam demonstrated that the Rowhammer technique could also work on Android smartphones, but with a major limitation of a malicious application being first installed on the target phone.

However, the same team of researchers has now shown how their proof-of-concept attack “GLitch,” can exploit the Rowhammer attack technique simply by hosting a website running malicious JavaScript code to remotely hack an Android smartphone under just 2 minutes, without relying on any software bug.

Since the malicious code runs only within the privileges of the web browser, it can spy on user’s browsing pattern or steal their credentials. However, the attacker cannot gain further access to user’s Android phone.

Here’s How GLitch Attack Works

GLitch is the first remote Rowhammer technique that exploits the graphics processing units (GPU), which is found in almost all mobile processors, instead of the CPU that was exploited in all previous theorized versions of the Rowhammer attack.

Since the ARM processors inside Android smartphones include a type of cache that makes it difficult to access targeted rows of memory, researchers make use of GPU, whose cache can be more easily controlled, allowing hackers to hammer targeted rows without any interference.

The technique is named GLitch with first two letters capitalized because it uses a widely used browser-based graphics code library known as WebGL for rendering graphics to trigger a known glitch in DDR3 and DDR4 memory chips.

Currently, GLitch targets smartphones running the Snapdragon 800 and 801 system on a chip—that includes both CPU and GPU—meaning the PoC works only on older Android phones like the LG Nexus 5, HTC One M8, or LG G2. The attack can be launched against Firefox and Chrome.

In a video demonstration, the researchers show their JavaScript-based GLitch attack on a Nexus 5 running over Mozilla’s Firefox browser to gain read/write privileges, giving them the ability to execute malicious code over the software.

“If you’re wondering if we can trigger bit flips on Chrome the answer is yes, we can. As a matter of fact, most of our research was carried out on Chrome,” the researchers said. “We then switched to Firefox for the exploit just because we had prior knowledge of the platform and found more documentation.”


No Software Patch Can Fully Fix the Rowhammer Issue

Since Rowhammer exploits a computer hardware weakness, no software patch can completely fix the issue. Researchers say the Rowhammer threat is not only real but also has the potential to cause some real, severe damage.

Although there’s no way to fully block an Android phone’s GPU from tampering with the DRAM, the team has been working with Google on ways to solve the problem.

For more in-depth details on the new attack technique, you can head on to this informational page about GLitch and this paper [PDF] published by the researchers.

Go to Source

Flaw in LinkedIn AutoFill Plugin Lets Third-Party Sites Steal Your Data

Not just Facebook, a new vulnerability discovered in Linkedin’s popular AutoFill functionality found leaking its users’ sensitive information to third party websites without the user even knowing about it.

LinkedIn provides an AutoFill plugin for a long time that other websites can use to let LinkedIn users quickly fill in profile data, including their full name, phone number, email address, ZIP code, company and job title, with a single click.

In general, the AutoFill button only works on specifically “whitelisted websites,” but 18-year-old security researcher Jack Cable of Lightning Security said it is not just the case.

Cable discovered that the feature was plagued with a simple yet important security vulnerability that potentially enabled any website (scrapers) secretly harvest user profile data and the user would not even realize of the event.

A legitimate website would likely place a AutoFill button near the fields the button can fill, but according to Cable, an attacker could secretly use the AutoFill feature on his website by changing its properties to spread the button across the entire web page and then make it invisible.

Since the AutoFill button is invisible, users clicking anywhere on the website would trigger AutoFill, eventually sending all of their public as well as private data requested to the malicious website, Cable explains.

Here’s How attackers can exploit the LinkedIn Flaw:

  • User visits the malicious website, which loads the LinkedIn AutoFill button iframe.
  • The iframe is styled in a way that it takes up the entire page and is invisible to the user.
  • The user then clicks anywhere on that page, and LinkedIn interprets this as the AutoFill button being pressed and sends the users’ data via postMessage to the malicious site.

Cable discovered the vulnerability on April 9th and immediately disclosed it to LinkedIn. The company issued a temporary fix the next day without informing the public of the issue.

The fix only restricted the use of LinkedIn’s AutoFill feature to whitelisted websites only who pay LinkedIn to host their advertisements, but Cable argued that the patch was incomplete and still left the feature open to abuse as whitelisted sites still could have collected user data.

Besides this, if any of the sites whitelisted by LinkedIn gets compromised, the AutoFill feature could be abused to send the collected data to malicious third-parties.

To demonstrate the issue, Cable also built a proof-of-concept test page, which shows how a website can grab your first and last name, email address, employer, and location.

Since a complete fix for the vulnerability was rolled out by LinkedIn on April 19, the above demo page might not work for you now.

“We immediately prevented unauthorized use of this feature, once we were made aware of the issue. We are now pushing another fix that will address potential additional abuse cases, and it will be in place shortly,” the company said in a statement.

“While we’ve seen no signs of abuse, we’re constantly working to ensure our members’ data stays protected. We appreciate the researcher responsible reporting this, and our security team will continue to stay in touch with them.”

Although the vulnerability is not at all a sophisticated or critical one, given the recent Cambridge Analytica scandal wherein data of over 87 million Facebook users was exposed, such security loopholes can pose a serious threat not only to the customers but also the company itself.

Go to Source

iOS Trustjacking – A Dangerous New iOS Vulnerability


An iPhone user’s worst nightmare is to have someone gain persistent control over his/her device, including the ability to record and control all activity without even needing to be in the same room. In this blog post, we present a new vulnerability called “Trustjacking”, which allows an attacker to do exactly that.

This vulnerability exploits an iOS feature called iTunes Wi-Fi sync, which allows a user to manage their iOS device without physically connecting it to their computer. A single tap by the iOS device owner when the two are connected to the same network allows an attacker to gain permanent control over the device. In addition, we will walk through past related vulnerabilities and show the changes that Apple has made in order to mitigate them, and why these are not enough to prevent similar attacks.

A recap of related past vulnerabilities / attacks

We saw several publications in the past that discuss leveraging unauthorized USB connections in order to get private information from mobile devices.

Prior to iOS 7, connecting an iOS device to a new computer didn’t require any authorization from the device owner. Juice jacking [1] [2] [3] uses this behavior and is able to steal sensitive information from devices and may install malware on the victim’s device. Apple solved this issue by adding the popup requesting the user to authorize new computers before allowing any sync operations.

Another publication discusses Videojacking, which utilizes the ability of Apple’s connector to be used as an HDMI connection and get a screen recording of iOS devices while connected to a malicious charger.

Both exploits allowed an attacker potential access to sensitive information, but their major limitation was that everything is possible only while the device is physically connected to the malicious hardware – disconnecting the device stops the attack flow.

Trustjacking allows an attacker to gain a more continuous and persistent hold of the device and retain the same abilities long after the device has been disconnected from the malicious hardware. To understand how this works, we first need to explain iTunes Wi-Fi sync.

What is iTunes Wi-Fi sync?

iTunes Wi-Fi sync is a very useful feature that allows iOS devices to be synced with iTunes without having to physically connect the iOS device to the computer.

Enabling this feature requires syncing the iOS device with iTunes first by connecting to a computer with a cable, then enabling the option to sync with the iOS device over Wi-Fi.

Trustjacking – how does it work?

Upon connecting an iOS device to a new computer, the users are being asked whether they trust the connected computer or not. Choosing to trust the computer allows it to communicate with the iOS device via the standard iTunes APIs.

This allows the computer to access the photos on the device, perform backup, install applications and much more, without requiring another confirmation from the user and without any noticeable indication. Furthermore, this allows activating the “iTunes Wi-Fi sync” feature, which makes it possible to continue this kind of communication with the device even after it has been disconnected from the computer, as long as the computer and the iOS device are connected to the same network. It is interesting to note that enabling “iTunes Wi-Fi sync” does not require the victim’s approval and can be conducted purely from the computer side.

Getting a live stream of the device’s screen can be done easily by repeatedly asking for screenshots and displaying or recording them remotely.

It is important to note that other than the initial single point of failure, authorizing the malicious computer, there is no other mechanism that prevents this continued access. In addition, there is nothing that notifies the users that by authorizing the computer they allow access to their device even after disconnecting the USB cable.


Imagine the following scenario: A victim connects his phone to a free charger in an airport; upon connecting his phone to the charger a popup message appears on his device, requesting him to approve the connected device. Approving this request might seem reasonable: the victim wants to charge his device, the service seems legitimate and it appears that nothing suspicious happens following the approval.

Demonstration Trustjacking

Attack Flow

From the user perspective, all he had to do is connect his device to a malicious charger / computer (might also be his own computer, as outlined later on) and choose to trust it.

Reading the text, the user is led to believe that this is only relevant while the device is physically connected to the computer, so assumes that disconnecting it will prevent any access to his private data. Even if the device is only connected for a very short period of time, it is enough for an attacker to execute the necessary steps to maintain visibility of all actions performed on the device after it is disconnected.

The attacker needs to take two steps:

  • Allow the device to connect to iTunes
  • Enable iTunes Wi-Fi sync

These steps can be automated by malicious software. They interestingly do not require any additional approval from the victim and don’t trigger any indication on the device that something is happening. Once these actions are completed, the device does not need to be physically connected to the attacking hardware anymore. Now the attacker can control the device remotely, as long as the victim and attacker are connected to the same network.

In order to be able to view the victim’s device screen, the attacker needs to install the developer image suitable for the victim’s device iOS version; then, he can take screenshots repeatedly and view the device’s screen in near real time. Installing the developer image can be conducted over Wi-Fi and does not require regaining physical access to the device. Although a restart may remove the developer image from the device, the hacker has continued access and can reinstall it easily.

Taking it to the next level

In addition to remotely viewing the victim’s device screen, Trustjacking also allows an attacker to do much more.

One of the features that an attacker can leverage is remote iTunes backup. By creating a backup of the device’s contents the attacker is able to get access to a lot of private information such as:

  •  Photos
  •  SMS / iMessage chats history
  •  App data

In order to get this information we had to parse the iTunes backup.

The backup consists of several metadata files and the backed up files themselves. Each file is stored in the path SHA1(“%domain%-%relativePath%”) and the directory with the name set to the first 2 hex digits of the hash.

For example, a photo with the path “Media/DCIM/100APPLE/IMG_0059.JPG” will be stored in the path “b1/b12bae0603700bdf7719c3a65b22ca2f12715d37” as “b12bae…” is the SHA1 hash of “CameraRollDomain-Media/DCIM/100APPLE/IMG_0059.JPG”.

All of the backed up files are listed on the “Manifest.db” file which is an SQLite3 DB and can be easily listed by querying it.

A simple query such as:

`SELECT * FROM Files WHERE relativePath like ‘%Media/DCIM%’ ORDER BY relativePath;` will list all of the pictures that have been backed up, including their hash.

Reading SMS / iMessage requires parsing another SQLite3 DB which can be found on the file “3d/3d0d7e5fb2ce288813306e4d4636395e047a3d28” (SHA1 equivalent of “HomeDomain-Library/SMS/sms.db”).

The two interesting tables are “chat” that lists all of the chats, and “message” that contains all of the messages for those chats, with “chat_message_join” to join them.

iOS Trustjacking – Backup and Restore Exploit

And there is more. An attacker can also use this access to the device to install malicious apps, and even replace existing apps with a modified wrapped version that looks exactly like the original app, but is able to spy on the user while using the app and even leverage private APIs to spy on other activities all the time. In the following video demonstration we demonstrate how they can identify the apps on the device and replace an app with a repackaged version of it. Notice the fraction of second in which the app is deleted and reinstalled.

iOS Trustjacking – Replace Apps Exploit

Is the attack confined to Wi-Fi only?

The attacks that we have described require the device and the attacking computer to be connected to the same network. Usually this means being in proximity to the victim’s device and connected to the same Wi-Fi, but this is not the only option.

By combining this attack with the malicious profile attack, we are able to connect the device to a VPN server and create a continuous connection between the victim’s device and the attacker’s computer and leverage this attack anytime and without the restriction of being in proximity with the device or connected to the same network.

iOS 11 – following our disclosure to Apple

Following our responsible disclosure process, Apple chose to add a mechanism that should make sure that only the real owner of the iOS device can choose to trust a connected new computer. This is done by requiring the user to enter his / her passcode when choosing to authorize and trust a computer.

As can be clearly seen in this screenshot, the user is still being told that this authorization is only relevant while the device is connected to the computer, making him believe that disconnecting his device guarantees that no one can access his private data.

While we appreciate the mitigation that Apple has taken, we’d like to highlight that it does not address Trustjacking in an holistic manner. Once the user has chosen to trust the compromised computer, the rest of the exploit continues to work as described above.

What if the attacker infects the victim’s computer rather than using a malicious charger?

A limitation of the malicious-charger attack flow is the potentially short period of time the victim and the iOS device are in the same proximity/network as the malicious computer. It would be far more devastating if the user’s own computer becomes the malicious actor. This powerful use-case of Trustjacking can happen when the device owner’s own PC or Mac has been compromised by malware. In this case, the attacker can utilize the relation of trust the victim has between his iOS device and his computer, along with the fact one’s own computer is usually in close proximity to the mobile phone (e.g. home, office, etc.) to achieve deep insight not only to the actions on the infected computer, but also to the victim’s mobile phone activity over time.


Unfortunately, there is no way to list all of the trusted computers and revoke access selectively. The best way to ensure that no unwanted computers are being trusted by your iOS device is to clean the trusted computers list by going to Settings > General > Reset > Reset Location & Privacy, now you will need to re-authorize all previously connected computers next time you are connecting your iOS device to each device.

In order to protect device backups and avoid attackers leveraging Trustjacking in order to get their hands on additional private information, enable encrypted backups in iTunes and choose a strong password.

Installing a Mobile Threat Defense solution such as SEP Mobile or Norton Mobile Security will help to protect your device from other implications of such attacks. SEP Mobile will identify and protect the end user against the installation of malicious profile, apps or attempts to compromise the device via this technique, and leveraging integrations with the SEP product line, customers have full visibility into both mobile and desktop operating systems.

For app developers – avoid including sensitive data in iTunes backup as this will reduce the risk on attackers leveraging Trustjacking in order to get such data by accessing your app’s backup.


We would like to thank Apple’s security team for their cooperation and continued commitment to the security of Apple’s user base.

Go to Source

Over 2 Million Users Installed Malicious Ad Blockers From Chrome Store

If you have installed any of the below-mentioned Ad blocker extension in your Chrome browser, you could have been hacked.

A security researcher has spotted five malicious ad blockers extension in the Google Chrome Store that had already been installed by at least 20 million users.

Unfortunately, malicious browser extensions are nothing new. They often have access to everything you do online and could allow its creators to steal any information victims enter into any website they visit, including passwords, web browsing history and credit card details.

Discovered by Andrey Meshkov, co-founder of Adguard, these five malicious extensions are copycat versions of some legitimate, well-known Ad Blockers.

Creators of these extensions also used popular keywords in their names and descriptions to rank top in the search results, increasing the possibility of getting more users to download them.

“All the extensions I’ve highlighted are simple rip-offs with a few lines of code and some analytics code added by the authors,” Meshkov says.


After Meshkov reported his findings to Google on Tuesday, the tech giant immediately removed all of the following mentioned malicious ad blockers extension from its Chrome Store:

  • AdRemover for Google Chrome™ (10 million+ users)
  • uBlock Plus (8 million+ users)
  • [Fake] Adblock Pro (2 million+ users)
  • HD for YouTube™ (400,000+ users)
  • Webutation (30,000+ users)
Meshkov downloaded the ‘AdRemover’ extension for Chrome, and after analyzing it, he discovered that malicious code hidden inside the modified version of jQuery, a well-known JavaScript library, sends information about some websites a user visits back to a remote server.

The malicious extension then receives commands from the remote server, which are executed in the extension ‘background page’ and can change your browser’s behavior in any way.

To avoid detection, these commands send by the remote server are hidden inside a harmless-looking image.

“These commands are scripts which are then executed in the privileged context (extension’s background page) and can change your browser behavior in any way,” Meshkov says.

“Basically, this is a botnet composed of browsers infected with the fake Adblock extensions,” Meshkov says. “The browser will do whatever the command center server owner orders it to do.”

The researcher also analyzed other extensions on the Chrome Store and found four more extensions using similar tactics.

Since browser extension takes permission to access to all the web pages you visit, it can do practically anything.

So, you are advised to install as few extensions as possible and only from companies you trust.

Go to Source

Another Critical Flaw Found In Drupal Core—Patch Your Sites Immediately

For the second time within a month, Drupal has been found vulnerable to another critical vulnerability that could allow remote attackers to pull off advanced attacks including cookie theft, keylogging, phishing and identity theft.

Discovered by the Drupal security team, the open source content management framework is vulnerable to cross-site scripting (XSS) vulnerability that resides in a third-party plugin CKEditor which comes pre-integrated in Drupal core to help site administrators and users create interactive content.

CKEditor is a popular JavaScript-based WYSIWYG rich text editor which is being used by many websites, as well as comes pre-installed with some popular web projects.

According to a security advisory released by CKEditor, the XSS vulnerability stems from the improper validation of “img” tag in Enhanced Image plugin for CKEditor 4.5.11 and later versions.


This could allow an attacker to execute arbitrary HTML and JavaScript code in the victim’s browser and gain access to sensitive information.

Enhanced Image plugin was introduced in CKEditor 4.3 and supports an advanced way of inserting images into the content using an editor.

“The vulnerability stemmed from the fact that it was possible to execute XSS inside CKEditor when using the image2 plugin (which Drupal 8 core also uses),” the Drupal security team said.

CKEditor has patched the vulnerability with the release of CKEditor version 4.9.2, which has also been patched in the CMS by the Drupal security team with the release of Drupal version 8.5.2 and Drupal 8.4.7.

Since CKEditor plugin in Drupal 7.x is configured to load from the CDN servers, it is not affected by the flaw.

However, if you have installed the CKEditor plugin manually, you are advised to download and upgrade your plugin to the latest version from its official website.

Drupal recently patched another critical vulnerability, dubbed Drupalgeddon2, a remote code execution bug that allows an unauthenticated, remote attacker to execute malicious code on default or common Drupal installations under the privileges of the user, affecting all versions of Drupal from 6 to 8.

However, due to people’s laziness of patching their systems and websites timely, the Drupalgeddon2 vulnerability has been found exploiting in the wild by hackers to deliver cryptocurrency miners, backdoors, and other malware.

Therefore, users are highly recommended always to take security advisories seriously and keep their systems and software up-to-date in order to avoid become victims of any cyber attack.

Go to Source