Alerts

JavaScript web apps and web servers are susceptible to a specific type of vulnerabilities/attacks known as regular expression (regex) denial of service (ReDoS).

 

These vulnerabilities take place when an attacker sends large and complex pieces of text to the open input of a JavaScript-based web server or app.

If the server component or an app library is not specifically designed to handle various edge cases, the attacker’s input can end up blocking the entire app or server for seconds or minutes at a time, while the server analyzes and pattern-matches the input.

Various programming languages and web server technologies have similar issues with the performance of pattern matching operations and ReDoS attacks, but they are vastly exaggerated in the case of JavaScript because of the single-threaded execution model of most JavaScript servers, where every request is handled by the same thread.

When a ReDoS attack hits, this ends up clogging the entire server, rather than slowing down one particular operation.

ReDoS attacks known since 2012, but gaining momentum

ReDoS attacks in the case of JavaScript servers were first detailed in a research paper published in 2012, but back then, JavaScript, and Node.js, in particular, weren’t the behemoth they are today on the web development scene, hence, this particular issue went largely ignored for another half of decade.

Subsequent research published in 2017 revealed that 5% of the total vulnerabilities found in Node.js libraries and applications were ReDoS vulnerabilities.

But according to research presented at a security conference last week, the ReDoS issue is gaining momentum in the JavaScript community because it has been left unaddressed for so many years.

Cristian-Alexandru Staicu and Michael Pradel, two academics from the Technical University in Darmstadt, Germany, say they’ve found 25 previously unknown vulnerabilities in popular Node.js modules.

The two said that an attacker could craft special exploit packages and attack websites/servers using any of these 25 libraries.

Sending an exploit packages causes any of the vulnerable websites to freeze between a few seconds to even minutes, as the server is trying to match the text contained within the exploit to a regular expression (regex) pattern in order to decide what to do with the input. Such regex filters on input fields are common, as they are the base of many XSS filters.

But while one attack is bad, sending repeated exploit packages to the same server can cause prolonged downtime periods.

Nearly 340 sites vulnerable to ReDoS attacks

Staicu and Pradel say the primary reason for these flaws is the lack of attention to the performance of regex matching, as most developers seem to be focused on accuracy, leaving big holes in their code that attackers can exploit using ReDoS attacks.

The two also took their research one step further. They devised a method of detecting these vulnerabilities on live websites without actually using the ReDoS exploit code.

They used this method to scan 2,846 popular Node.js-based sites, revealing that 339 —approximately 12%— were vulnerable to at least one ReDoS vulnerabilities.

“ReDoS poses a serious threat to the availability of these sites,” the research team said. “Our results are a call-to-arms for developing techniques to detect and mitigate ReDoS vulnerabilities in JavaScript.”

Some ReDoS issues were patched

The TU Darmstadt research team reported all the vulnerabilities to the respective module developers, some of who addressed the problems. This GitHub repo contains proof-of-concept exploits for testing the vulnerable libraries but also links to the appropriate fixes for the affected modules.

Besides JavaScript, Java is also known to be affected by ReDoS attacks. In 2017, researchers from the University of Texas at Austin created a tool named Rexploiter, which they used to find 41 ReDoS vulnerabilities in 150 Java programs collected from GitHub.

More details about ReDoS vulnerabilities affecting JavaScript are available in a whitepaper titled “Freezing the Web: A Study of ReDoS Vulnerabilities in JavaScript-based Web Servers.” The paper is available for download from here or here, and was also presented at the 27th Usenix Security Symposium held last week in Baltimore, USA.

 

The information contained in this website is for general information purposes only. The information is gathered from Bleeping Computer while we endeavour to keep the information up to date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability or availability with respect to the website or the information, products, services, or related graphics contained on the website for any purpose. Any reliance you place on such information is therefore strictly at your own risk.
Through this website, you are able to link to other websites which are not under the control of CSIRT-CY. We have no control over the nature, content and availability of those sites. The inclusion of any links does not necessarily imply a recommendation or endorse the views expressed within them.
Every effort is made to keep the website up and running smoothly. However, CSIRT-CY takes no responsibility for, and will not be liable for, the website being temporarily unavailable due to technical issues beyond our control.

A new Necurs botnet campaign targets thousands of banks with a malicious file dropping the FlawedAmmyy remote-access Trojan.

The Necurs botnet has resurfaced in a new phishing campaign targeting banks with malicious Microsoft Publisher and PDF files packed with the FlawedAmmyy remote-access Trojan.

Cofense researchers first detected the campaign early on August 15 and have confirmed 3,071 banking domains have been hit so far. Recipients range from small regional banks to some of the world’s largest financial institutions.

Necurs, a rootkit first discovered in 2012, became famous in 2016 when it was spotted delivering large volumes of Dridex and Locky ransomware. Now it’s resurfacing with new tactics as threat actors experiment with different strategies to see which are most effective.

“As far as this particular campaign, it is a change from what Necurs has been doing,” says Jason Meurer, senior research engineer at Cofense. He compared the attack with a marketing campaign, noting that “it felt like there was a little bit of A/B testing going on here.”

This campaign differed from Necurs’ usual strategy in several ways. For starters, it wasn’t your traditional spam — this was a phishing campaign specifically geared toward the banking industry, using malicious attachments to deliver a payload designed to enable remote access. It also leveraged Microsoft Publisher files, a shift from typical Word and Excel documents. A small subset of this campaign used PDF files, which shows the attackers are trying different tactics.

“It’s extremely rare” to see Publisher files in phishing attacks, says Cofense co-founder and CTO Aaron Higbee. While this type of file has been used in the past — after all, most employees are required to install Publisher as part of Office 365 — it’s not commonly seen in cybercrime.

Digging into the Details

Emails in this campaign are “fairly basic,” researchers report, with subject lines including “Request BOI” and “Payment Advice” with a random alphanumeric code tacked on the end. Higbee points out the phishing email was forged to appear as though it came from an employee at an Indian bank. A different Indian bank, Cosmos, recently lost 12 million euros in a cyberattack when hackers broke into its ATM server and stole customer information.

This campaign could potentially indicate a future ATM attack, says Higbee, and network access may be part of the actors’ motivation. The malicious .pub documents attached to phishing emails have embedded macros that, when executed, prompt a download from a remote host, explain Cofense’s Jason Meurer and Darrel Rendell in a blog post on the campaign.

The final payload is FlawedAmmyy, which is malware based on leaked source code for Ammyy Admin. It gives an attacker with full remote control of a compromised host, which can lead to file and credential theft and enable lateral movement within target organizations.

FlawedAmmyy had gone undocumented until early 2018, when Proofpoint research indicated the Trojan had been used in attacks as far back as January 2016 and as recently as March 2018. At that time, attackers began to use a new distribution method of combining ZIP files with the Server Message Block protocol to deliver FlawedAmmyy onto target systems.

The March campaign dropping FlawedAmmyy appeared to be the work of TA505, the same threat group associated with the Dridex, Locky, and GlobeImposter campaigns. While Cofense has not yet determined the motivation behind the latest Necurs campaign, Higbee says people who have been studying Necurs have linked the botnet to organized crime.

What’s Next for Necurs

Now that the campaign has come to a halt, Meurer anticipates the attackers are probably taking a look at their command-and-control infrastructure to gauge the effectiveness of their strategy. Did .pub files work, for example, or were PDF files more effective?

If there was little to no engagement, “they’ll go back to the drawing board and look for another file format they can use to deliver the next wave,” he says. “If we see Necurs do another phishing campaign using .pub files, it’s an indication people behind it were satisfied with the results.”

It’s a call for banking institutions to stay on their toes. Banks should make sure their perimeter security is in good shape and their email gateways are updated. “The second thing is to make sure banking employees are aware they’re targets of cybercriminals, just by the nature of the fact they work at a bank,” Meurer adds. “Any employee is a rich target for a cybercriminal.”

 

The information contained in this website is for general information purposes only. The information is gathered from Dark Reading while we endeavour to keep the information up to date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability or availability with respect to the website or the information, products, services, or related graphics contained on the website for any purpose. Any reliance you place on such information is therefore strictly at your own risk.
Through this website, you are able to link to other websites which are not under the control of CSIRT-CY. We have no control over the nature, content and availability of those sites. The inclusion of any links does not necessarily imply a recommendation or endorse the views expressed within them.
Every effort is made to keep the website up and running smoothly. However, CSIRT-CY takes no responsibility for, and will not be liable for, the website being temporarily unavailable due to technical issues beyond our control.

Researchers have discovered several security vulnerabilities in implementations of Wi-Fi Protected Access two (WPA2)’s 4-way handshake, which is used by nearly all protected Wi-Fi networks.

The discovery was the result of simulating cryptographic primitives during symbolic execution for the analysis of security protocol implementations, KU Leuven researchers Mathy Vanhoef and Frank Piessens explain in a recently published whitepaper (PDF).

By applying the technique on three client-side implementations of WPA2’s 4-way handshake, the researchers discovered timing side-channels when verifying authentication tags, a denial-of-service attack, a stack-based buffer overflow, and a non-trivial decryption oracle.

Through symbolic execution, the researchers claim, one aims to exhaustively explore all code paths of a program by running on symbolic inputs instead of concrete ones. For their experiments, the researchers implemented the techniques on top of the KLEE symbolic execution engine (they modified the engine to handle cryptographic primitives).

Of the three tested implementations, two were found susceptible to trivial timing side-channels, because they verify authentication tags using timing-unsafe memory compares.

The researchers found a denial of service in Intel’s iwd daemon (iNet wireless daemon) and a stack-based buffer overflow (in code that processes decrypted data) in MediaTek’s implementation, both of which can be triggered by malicious Access Point (AP). The AES unwrap algorithm was found to be incorrectly implemented in MediaTek’s code.

Furthermore, the wpa supplicant (a cross-platform supplicant with support for WEP, WPA and WPA2 (IEEE 802.11i)) was found vulnerable to a non-trivial decryption oracle caused by processing decrypted but unauthenticated data. Tracked as CVE-2018-14526, the bug can be exploited to recover sensitive information.

“This decryption oracle can be exploited when the victim connects to a WPA2 network using the old TKIP encryption algorithm. It can be abused to decrypt the group key transported in message 3 of the 4-way handshake,” the researchers note.

The attack, however, is only possible if WPA2 is used and if the client selects TKIP as the pairwise cipher, so that the RC4 stream cipher is used to encrypt the key data field (if CCMP is selected, AES is used to protect the key data field). Both conditions are met when the Wi-Fi network uses WPA2 and only supports TKIP (in 2016, 20% of protected Wi-Fi networks used this configuration).

The flaw allows an attacker to decrypt the group key transported in message 3 of WPA2’s 4-way handshake and use it to inject both broadcast and unicast traffic. Furthermore, the key could be used to decrypt unicast and broadcast traffic, the research paper claims.

“We successfully applied symbolic execution to client-side implementations of the 4-way handshake of WPA2, by simulating cryptographic primitives, and constraining parts of the symbolic input to prevent excessive state explosions. This revealed memory corruptions in code that processes decrypted data, uncovered insecure implementations of cryptographic primitives, and even revealed a decryption oracle,” the researchers note.

Earlier this week developers of the popular password cracking tool Hashcat identified a new method that can in some cases be used to obtain a network’s Wi-Fi Protected Access (WPA) or Wi-Fi Protected Access II (WPA2) password.

 

The information contained in this website is for general information purposes only. The information is gathered from Security Week while we endeavour to keep the information up to date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability or availability with respect to the website or the information, products, services, or related graphics contained on the website for any purpose. Any reliance you place on such information is therefore strictly at your own risk.
Through this website, you are able to link to other websites which are not under the control of CSIRT-CY. We have no control over the nature, content and availability of those sites. The inclusion of any links does not necessarily imply a recommendation or endorse the views expressed within them.
Every effort is made to keep the website up and running smoothly. However, CSIRT-CY takes no responsibility for, and will not be liable for, the website being temporarily unavailable due to technical issues beyond our control.