Cross-Site Request Forgery (CSRF) is an attack targeting vulnerabilities in computer security, posing significant risks to user information and accounts. It manipulates the web browser to perform unwanted actions within an application, harming the user logged into the system. A successful attack can lead to unauthorized money transfers, data theft, password changes, and damage to customer relations.

Cross-Site Scripting

Cross-site scripting (XSS) is a Web security vulnerability that allows an attacker to compromise user interactions with an application by exploiting separate web sites. To avoid detection by the attacker, one should not rely solely on the same-origin policy.

Work Algorithm of CSRF

The CSRF (Cross-Site Request Forgery) attack exploits the trust that a web application has in a user’s browser. The aim is to deceive the browser into executing unwanted actions on a website where the user is currently authenticated. This section will break down how CSRF attacks are typically carried out in a step-by-step algorithm.

Step 1: Identifying the Target Application

The attacker first identifies a target web application that is vulnerable to CSRF. This typically involves an application that handles user requests without sufficient validation of their origin or authenticity.

Step 2: Crafting the Malicious Request

Once a vulnerable target is identified, the attacker crafts a malicious request that can perform an unwanted action on the application. This could be anything from changing user settings, transferring funds, posting data, or any action that the user is authorized to perform on the application. The request is designed to look like a legitimate request from the authenticated user.

Step 3: Delivering the Malicious Request

The crafted request is embedded in a place where the victim is likely to trigger it. Common methods include:

• Embedding the request in an image or script on a web page that the user is likely to visit.
• Sending the malicious link via email or social media where the user might click on it unknowingly.

Step 4: Executing the Request

When the user interacts with the malicious content (e.g., by visiting a malicious website, clicking on a deceptive link, or loading a compromised image), the malicious request is sent to the target application. Since the browser automatically includes credentials like session cookies with every request to the site, the application might process the request as legitimate.

Step 5: Action Performed

If the attack is successful, the application performs the action without the user’s conscious approval. The action is executed under the guise of the user’s authenticated session, leading to potentially damaging outcomes depending on what the malicious request was designed to do.

Step 6: Attack Detection and Response

Detection of CSRF attacks can be challenging as they originate from the trusted user’s authenticated environment. However, preventive measures such as implementing CSRF tokens, same-site cookies, or double submit cookies can effectively mitigate such attacks.

Cross-Site Request Forgery (CSRF)

CSRF attacks often rely on social engineering to succeed. The app cannot differentiate between legitimate requests and fraudulent ones since the user remains authenticated during the attack. For the attack to succeed, the attacker leverages three main keys, which we detail below:

• Relevant action: Any action that involves user data.
• Cookie-based session handling: This key involves sending one or more HTTP requests where the application identifies the user solely through cookies.
• No unpredictable request parameters: To prevent an attacker from discovering or guessing the value of a query, the query includes no parameters.

CSRF Example

Imagine a popular online forum where users can update their profile information, including their bio. The form to update the bio might look like this in normal use:

POST /updateProfile HTTP/1.1
Host: community-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 47
Cookie: session=3e5e4f3a8
bio=I+love+networking+and+cybersecurity!


This action is vulnerable to CSRF for several reasons:

• The action of updating a bio doesn’t require any secondary validation, making it a prime target for attackers looking to alter user data subtly.
• The application relies solely on session cookies to authenticate requests, with no CSRF tokens or other anti-CSRF mechanisms in place.
• Form data for this action is simple and predictable, allowing an attacker to easily forge a request.

An attacker could exploit this vulnerability by crafting a malicious webpage that includes an auto-submitting form, as follows:

<form action="https://community-sample-website.com/updateProfile" method="POST">
<input type="hidden" name="bio" value="Hacked by evil-user!" />
<input type="submit" value="Update" />
</form>
<script>
document.forms[0].submit();
</script>


Here’s what happens when a victim, who is logged into the forum, visits this malicious webpage:

1. The hidden form on the attacker’s page automatically submits a POST request to the forum’s server.
2. Since the victim is logged in, their browser includes their session cookie automatically with the request.
3. The forum processes the request as if it were a legitimate action initiated by the victim, thus changing the victim’s bio to “Hacked by evil-user!” without their consent.

This example highlights the importance of employing CSRF tokens or other verification methods that verify the user’s intent on sensitive actions within web applications. Without these protective measures, users are at risk of having their data altered or hijacked by attackers.

Cross-site scripting (XSS)

To execute this attack, the attacker proceeds in two stages:

• The attacker first looks for a way to insert malicious code into the web page that the user visits, before launching the malicious code into the victim’s browser.
• If the attacker targets a specific victim with malicious code, he does it through phishing or social engineering. Once he embeds the malicious code in the web browser, the victim must visit this infected website.

What is the Difference Between XSS and CSRF?

Now that we understand what XSS and CSRF entail and how they operate, let’s explore the differences between them:

Can CSRF tokens prevent XSS attacks?

Effective CSRF tokens can prevent XSS attacks. Assuming the server still validates the CSRF token correctly, the token can block an XSS vulnerability. Considering the term “intersite scripting”, we notice a hint that the intersite query can appear in reflected form. The application blocks the trivial use of an XSS vulnerability, thereby preventing an attacker from faking an intersite request. However, there are important caveats:

1. There may still be an exposed, tokenless XSS vulnerability within a function that can be exploited in the usual way.
2. Actions protected by a CSRF token can still be executed by the user, but if there is an XSS vulnerability elsewhere, it could be exploited. In such cases, an attacker’s script may request the corresponding page to obtain a valid token, which he can then use to perform any protected action.
3. If XSS vulnerabilities are already present, CSRF tokens cannot protect them. You can only use pages that are output points for the stored XSS vulnerability, protected by the CSRF token. When the user visits the page, the XSS payload will execute.

The post CSRF (Cross-Site Request Forgery) vs XSS appeared first on Gridinsoft Blog.

Attack Technique Exploits Microsoft Management Console Files

On June 6, 2024, Elastic reported about discovering a new attack technique that uses Microsoft Management Console to run malware. The technique, nicknamed GrimResource, allows attackers to execute arbitrary code locally with minimal detection, even before getting access to the system. This is achieved by exploiting an XSS vulnerability in the apds.dll library, that allows it to gain initial access. Hackers include the reference to one and effectively exploit it through a Microsoft Saved Console (MSC) file. The trick also plays with DotNetToJScript to execute arbitrary code.

According to the researchers, after Microsoft disabled macros in Office suite by default for documents from the Internet, the popularity of other infection vectors increased sharply. However, these other methods, are rather easy to detect, and are overall tracked a lot by antimalware vendors. That’s the reason why cybercriminals went seeking to use new and undisclosed infection vectors to gain access and bypass defenses. In several exploitation cases that analysts detected so far, adversaries used the flaw to deploy a Cobalt Strike beacon.

Technical Analysis

The GrimResource technique exploits an old cross-site scripting (XSS) vulnerability found in the library apds.dll. By including a reference to the vulnerable APDS resource in the appropriate StringTable section of a crafted Microsoft Management Console (MMC) file, attackers can execute arbitrary JavaScript. This execution occurs within the context of mmc.exe. This capability can be combined with DotNetToJScript, a method that enables attackers to execute arbitrary .NET code.

The infection chain starts with the use of the transformNode obfuscation technique. Threat actors used this method in unrelated macro samples, helping the malicious code evade ActiveX security warnings. The obfuscated VBScript embedded in the file sets the target payload within a series of environment variables.

Next, the VBScript uses the DotNetToJScript method to execute an embedded .NET loader known as PastaLoader. This loader retrieves the payload from the variables set by the VBScript. It then spawns a new instance of dllhost.exe.

Further, the loader injects malware into this process using the DirtyCLR technique. It involves function unhooking and using indirect system calls to maintain stealth. Throughout these attacks, as I’ve mentioned, analysts have seen adversaries deploying Cobalt Strike, a widely used tool for post-exploitation activities.

Unfixed Vulnerabilities

The vulnerability exploited in the GrimResource technique was reported to both Adobe and Microsoft in October 2018. While both companies investigated the issue, Microsoft determined that the vulnerability did not meet the criteria for an immediate fix. In short, companies just did not take it seriously.

By March 2019, the cross-site scripting (XSS) flaw remained unpatched. The status of whether it has been addressed since then remains unclear. This suggests that, at least as of early 2019, the vulnerability was still a potential risk for exploitation, making it an attractive target for attackers leveraging the GrimResource technique. And now, in 2024, especially after the massive fuss around this technique in newsletters, its exploitation will likely be just over the roof.

To keep your device secured against such vulnerabilities, keeping software up to date may not be enough. A reliable antivirus with regular database updates and a heuristic engine should be considered, too – just as a way to stop what the updates failed to prevent. GridinSoft Anti-Malware will give you this security, thanks to its multi-component detection system and hourly updates.

The post New GrimResource Attack Technique Targets MMC, DLL Flaw appeared first on Gridinsoft Blog.

Sierra AirLink Routers Have 21 Vulnerabilities

As Forescout Vedere researchers describe in their research, the AirLink lineup of devices contains 21 software vulnerabilities. Among them, only one issue got the CVSS score over 9, which is considered critical. RCE vulnerabilities and a couple of ones that may allow for unauthorized access are rated 8.1 to 8.8. Several other noteworthy issues, particularly ones that cause Denial of Service, are rated at CVSS 7.5.

Researchers did a detailed description of the potential exploitation cases for two of the most critical vulnerabilities. For CVE-2023-41101, a hacker can take over the router by overflowing the buffer in OpenNDS captive portal. Using the lack of length limitation in GET requests, it is possible to make the router execute arbitrary code. By controlling the router, adversaries can disrupt the operations related to the mentioned interface.

#2 in the list, CVE-2023-40463, requires an attacker to possess a router similar to the one it tries to attack. By digging through the device’s software elements and applying some hash cracking magic, it is possible to obtain the diagnostic shell password. Further, using a bit of social engineering, adversaries may connect to the actual router and enter its diagnostic interface using the password they’ve obtained earlier. With such access, it is possible to inject malware to the router, force it to malfunction, or execute your commands remotely.

Available Mitigations

Despite such a worrying amount of exploits, all of them allegedly receive a fix in the latest version of the firmware for AirLink devices. ALEOS 4.17.0 should address all the flaws, and, if some incompatibilities are in the way, customers may stick to version 4.9.9. The latter is not vulnerable to named vulnerabilities except for ones that touch OpenNDS captive portals.

Researchers who found all the issues also offer their own mitigation for the vulnerabilities that allow delaying the patch installation. Though, as it usually happens to all the stopgap solutions, they are not ideal and do not guarantee the effect.

1. Disable unused captive portals and related services, or put them under restricted access. This reduces the attack surface for vulnerabilities that target OpenNDS.
2. Use a web app firewall to filter the requests and block the packets of a suspicious source. This mitigation works against XSS and DoS vulnerabilities.
3. Change the default SSL certificates. Forescout recommends doing this to all the routers, not only to Sierra Wireless ones.
4. Implement an intrusion detection system that monitors IoT/OT devices as well. This allows for controlling both connections from outside the network and ones within it.

What are Sierra AirLink Routers?

Have you ever wondered, how does the Wi-Fi in a public transport function? Or how all the machinery in a huge workshop is connected and centrally managed even though it is not static? Well, Sierra’s devices are the answer. Their routers are industrial-grade wireless connectivity devices that are used in dozens of industries – starting from public transportation and all the way up to aerospace & defense.

What is particularly concerning for this story is the extensive use of AirLink routers in critical infrastructure. Factories, transportation – they are important, though not as continuously demanded as water treatment, emergency services and energy management. And since IoT more and more often attracts hackers’ attention, the actions should be taken immediately. Considering the extensive use of vulnerable AirLink devices in the US, it may be the perfect Achilles’ heel for cyberattacks that target critical infrastructure and even government.

The post Sierra AirLink Vulnerabilities Expose Critical Infrastructure appeared first on Gridinsoft Blog.

What is a Web Application Firewall (WAF)?

The WAF or web application firewall is a tool that helps protect web applications by filtering and monitoring HTTP traffic between a web application and the Internet. It can be cross-site scripting (XSS), cross-site spoofing, file inclusion, and SQL injections. WAF is a Layer 7 protection (in the OSI model) and is not designed to protect against all attacks. Instead, it is an attack mitigation method typically part of a set of tools that create a holistic defense against a range of attack vectors.

How Does Web Application Firewall Work?

WAF works using a set of rules, often called policies. These policies aim to protect against application vulnerabilities by filtering malicious traffic. The value of a WAF comes from the speed and ease of implementing policy modifications, which allows you to respond more quickly to different attack directions. So you can modify WAF policies during a DDoS attack and quickly implement rate limiting. In addition, it prevents incoming attacks by analyzing incoming network traffic to the web server/web application according to rules and policies. According to recommendations, WAF should be able to detect types of attacks on the OWASP list:

When a WAF is deploying in front of a web application, a screen is placed between the web application and the Internet, meaning the WAF acts as a reverse proxy server, protecting the application from unwanted requests before they reach the web application.

WAF deployment options

You can deploy WAF in some ways – it all depends on where your applications are deployed, what services you need, how you want to manage them, and the architectural flexibility and performance level you require. For example, do you want to work it yourself, or do you want to outsource that management? Is it better to have a cloud-based option, or do you want your WAF to be hosted locally? How you want to deploy will help determine which WAF suits you. Below are your choices, each with its advantages and disadvantages:

Network-based WAF

Network WAF is a hardware solution installed local network, so it has low latency. The network-based WAF has a WAF engine that handles traffic in proxy mode. All incoming (and outgoing) traffic goes through it and is inspected, and dangerous traffic is blocked. However, this option requires storage and maintenance of physical equipment despite its effectiveness. As a result, it is typically associated with high maintenance costs, making it one of the most expensive deployment options. But its flexibility and ability to control every element makes it attention-worthy.

Host-based WAF

Host-based WAF provides protection through software installed on the web server itself. Like the previous option, host-based WAFs are in place and thus minimize latency. However, host-based WAFs consume web server resources to perform their security function because they do not reside on a separate physical device, unlike the previous variant. Thus, host-based WAFs can also be costly because of the need to optimize the web server so that its performance is not degraded by deploying it on the server itself.

Cloud-based WAF

Cloud-based WAFs are the most affordable option and are very easy to implement. Companies that provide this service offer a turnkey installation that is as simple as changing DNS to redirect traffic. In addition, cloud WAFs have minimal upfront costs because the service is subscription-based, and users pay a monthly or annual security fee as a service. Cloud WAF security is continually updated to protect against the latest threats without any action or expense on the user’s part. The only disadvantage of a cloud WAF is that users delegate responsibility to a third party so that some WAF features can be a black box for them.

Types of web application firewalls

As described above, a WAF works according to a set of rules or policies defined by the network administrator. Each WAF policy or practice is designed to address a threat or known vulnerability at the application level. Together, these policies allow malicious traffic to be detected and isolated before it reaches the user or application. There are three types of security models used for Web application firewalls:

Positive Security Model

A positive security model identifies what is allowed and rejects everything else, moving away from the “blocked” end of the spectrum, following the “allow only what I know” methodology. The positive security model only trusts allowed requests or inputs and rejects the rest. In this case, an allowlist is created, permission statements are added to the firewall with packet filtering, and allowed inputs or requests are considered based on it.

Negative Security Model

The negative security model is the exact opposite of the positive security model and assumes that:

• Most web traffic is benign.
• Web traffic that is not benign can be identified.

The negative security model allows all HTTP/S requests by default. Requests are not rejected unless they are identified as hostile. The negative security model is sometimes called the “blacklist” model. This is because you need to blocklist unwanted traffic and define threat signatures and other means of identifying malicious traffic before that traffic can be blocked.

Mixed Security Model

As the name suggests, the mixed security model uses allowlists and blocklists. Since the model combines the advantages of both models, it is the most common. So, most modern firewalls use this model.

Difference Between Blocklist and Allowlist WAFs

The WAF, which operates on a blocklist, protects against known attacks. Let’s compare it to a club bouncer who denies entry to guests who don’t conform to the dress code. The WAF, based on an allowlist, in turn, allows only pre-approved traffic. It’s like a bouncer at an exclusive party who lets in only those on the guest list. Since both options have advantages and disadvantages, many WAFs offer a hybrid security model that implements both.

Why is it essential to use the web application firewall

Protecting corporate data and services is the first and most compelling reason to implement WAF. Thousands of businesses, from minor to giant corporations, make money using the Internet. If this income source is compromised, the company risks being hit hard. Here are the main risks:

Loss of Direct Revenue. Suppose the firm uses an Internet resource for online commerce, which has become unavailable. In this case, customers can not make purchases, and the firm loses a significant amount of money.

Loss of Customer Confidence. A good reputation is essential for a self-respecting company. Many customers pay attention to news about break-ins of specific companies and make a note to themselves so that they do not do business with this company in the future.

Loss of Sensitive Data. Unfortunately, cases where hackers have gained access to sensitive information, are not uncommon. After hacking websites, information such as names, addresses, credit card numbers, medical records, and social security numbers will most likely find their way into the Darknet (and sometimes into the public domain). In addition, private information, trade secrets, and even classified government data are tidbits for hackers. While the mere fact of being hacked is already a nuisance, the fines and disaster recovery/forensic costs can exceed any other financial impact.

The post Web Application Firewall: Difference Blocklist and Allowlist WAFs appeared first on Gridinsoft Blog.

In the past 12 months hackers have scammed more than $2.5 million from other cybercriminals on three separate hack forums alone (Exploit, XSS and BreachForums), according to Sophos researchers.

You might also be interested in reading All About Hacker Motivation: Why Do Hackers Hack?

Experts spoke about the results of studying darknet forums during a report at the Black Hat Europe conference, and then the study was published on the company’s blog.

Fraud on the three hack forums that were studied turned out to be so widespread that there are special “arbitrage rooms” on all resources.

For example, the Exploit forum has 2,500 scam messages and has a separate section for filing complaints, as well as a blacklist where cases of confirmed fraudulent activities are recorded.

In turn, 760 cases of fraud are reported on XSS, and the forum maintains a “list of rippers” with fraudulent sites.

Thus, Exploit’s “arbitration room” contains 211 complaints totaling $1,021,998, while the blacklist includes 236 incidents that cost other criminals $863,324. For example, in one case, an Exploit user filed a complaint trying to negotiate with the operators of the Conti ransomware to decrypt company data. However, forum administrators have closed this statement as ransomware is not allowed on Exploit.

The media also wrote that Neutrino Botnet Seizes Web Shells of Other Hackers.

Meanwhile, XSS, by comparison, has 120 complaints totaling $509,901, while BreachForums, which has only been in existence since April this year, already has 21 complaints worth $143,722.

Read also: 6 Popular Types of Hackers: Protection Tips in 2022.

While most of the scams that criminals complain about involve five- and six-figure amounts, some victims open claims for much smaller losses (there are cases where the amount of damage is as low as $2).

The report notes that such proceedings on hack forums often end in mutual insults and complete chaos, when the accuser accuses the defendant of fraud. In some cases, the intended victims themselves are blocked altogether.

While a ban is the most common punishment for cheating, BreachForums also practices doxing, posting the banned users’ email address, registration details, and the last IP address from which they accessed the forum.

Despite this, Sophos lists several cases “involving serial scammers” who were blocked from hack forums, but then simply created new profiles, paid a registration fee and continued to deceive their “colleagues”.

The post Hackers Stole over $2.5 million from Hackers appeared first on Gridinsoft Blog.

Unfortunately, the picture turned out to be depressing, for example, it turned out that 29% of critical errors in WordPress plugins did not receive patches at all. In addition, the number of reported vulnerabilities has increased by 150% over the past year.

The researchers write that all this is alarming, since WordPress is the most popular CMS in the world, which is used by 43.2% of all sites in the world.

Of all the bugs that experts reported in 2021, only 0.58% were related to the WordPress core, and the rest were related to different themes and plugins for the platform from different developers. At the same time, 91.38% of vulnerabilities were found in free plugins, while paid solutions for WordPress accounted for only 8.62% of the total number of problems, and this says a lot about the procedures for checking and testing code.

Patchstack experts have identified five critical vulnerabilities affecting 55 WordPress themes, with the most serious of these vulnerabilities related to file upload abuse.

As for plugins, 35 critical vulnerabilities were found in them, two of which affected 4,000,000 sites. Although plugin developers mostly fixed these vulnerabilities, nine plugins never received patches and were eventually removed from marketplaces altogether.

PatchStack also notes that XSS vulnerabilities top the list of the most common flaws in WordPress in 2021, followed by “mixed” vulnerabilities, CSRF, SQL injection and arbitrary file uploads.

Overall, in 2021, about 42% of WordPress sites, on average, contained at least one vulnerable component out of 18 installed. Although this number is less than the 23 plugins installed on average on websites in 2020, the problem is now complicated by the fact that 6 out of 18 are already out of date.

The most vulnerable outdated plugins in 2021 are OptinMonster, PublishPress Capabilities, Booster for WooCommerce, and Image Hover Effects Ultimate.

Let me remind you that we also wrote that Hackers create scam e-commerce sites over hacked WordPress sites, and also that KashmirBlack botnet is behind attacks on popular CMS including WordPress, Joomla and Drupal.

The post About 30% of critical vulnerabilities in WordPress plugins remain unpatched appeared first on Gridinsoft Blog.

Groups like REvil, LockBit, DarkSide, Netwalker, Nefilim, and so on have often used the forum to advertise new customer acquisition.

As a result, ransomware affiliate programs, renting such malware and selling lockers are now prohibited on XSS.

Shortly after this publication, representatives of a number of groups expressed their dissatisfaction with what was happening. For example, a LockBit spokesperson left a comment with just one word: “suddenly”.

The representative of REvil, in turn, writes that the group is leaving the forum altogether and moving to another hacker resource – Exploit[.]in.

I must say that a little earlier, the operators of REvil, which is currently one of the largest ransomware on the market, also announced the upcoming changes in their work. The hackers said they intend to stop advertising their RaaS platform and will continue to work privately, that is, with a small group of well-known and trusted persons.

If one of the clients nevertheless attacks a “forbidden” company or organization, the hackers intend to provide the victims with a free decryption key and then promise to stop working with such a “partner”.

Apparently, everything that happens is directly related to the attention of the special services, which has attracted the DarkSide ransomware, which last week attacked the largest pipeline operator in the United States, Colonial Pipeline. This high-profile incident received attention at the highest level: the other day, US President Joe Biden announced that the US authorities intend to interfere with the work of the hacking group.

As a result, representatives of DarkSide said that they had already lost access to their servers and multimillion-dollar ransoms (although the American authorities, it seems, have not yet taken any action) and announced the termination of work.

It seems that the XSS administration and the REvil operators do not want to be the object of the same scrutiny from law enforcement agencies, and are trying to act proactively.

Let me remind you that earlier I wrote that REvil spokesman boasts that hackers have access to ballistic missile launch systems.

The post Hacker XSS Forum Banned Ransomware Ads appeared first on Gridinsoft Blog.

The messages were published after the successful operation of Operation Ladybird, during which law enforcement agencies from several countries jointly eliminated one of the largest current botnets, Emotet.

The Netherlands Police, along with Ukrainian law enforcement officers, played key roles in the elimination of the botnet. The Netherlands authorities have shut down two of the three main C&C servers located in the country.

So, the authorities of the Netherlands seized two of the three Emotet control servers that were located in the country.

In their messages, law enforcement officers convince participants in hack forums that it is useless to abuse Netherlands hosting providers to host botnets and other criminal activities.

The police have promised that they will continue to seize the infrastructure of the criminals.

A message was posted on Raid in English, and on XSS, formerly known as DamageLab, in Russian. XSS is a Russian-language forum where cybercriminals can rent malware under a malware-as-a-service scheme. The site is currently very popular with ransomware operators.

Additionally, law enforcement officers attached an informational video to their messages:

It is interesting that the administration of RaidForums did not touch the post of law enforcement officers, although the forum members responded with insults and doubted its authenticity.

At the same time, the Russian-language XSS deleted the message, blocked the Dutch police account and posted a warning in the profile to prevent other forum members from trusting the user.

It should be noted that the Netherlands are really actively fighting cybercrime. For example, the country’s law enforcements are known for eliminating 15 DDoS services in a week; secured the closure of the hosting company KV Solutions BV, whose servers and backend infrastructure were used to host many IoT botnets; the encrypted mobile network Ennetcom has stopped working; and also cracked encrypted messages on a server confiscated from Ennetcom.

Let me also remind you that recently the Ukrainian cyber police arrested the author of uPanel phishing kit.

The post Netherlands police posted warnings on hacker forums appeared first on Gridinsoft Blog.