Threat actors are always looking for ways to exploit vulnerabilities and steal sensitive information. One method of attack is hijacking browser communications through the Cross-Site Request Forgery (CSRF) process. Cross-Site Request Forgery is another way of saying that an external actor is communicating with an application on behalf of a legitimate user, without the user’s knowledge.
Granted, a user likely has many external agents communicating with their application at any given time. However, if one of those external agents is a malicious actor, that threat actor could perform a lasting action on behalf of the user without their consent, such as change the email address on a user’s account or make a funds transfer. These actions could lead to interference with confidentiality, integrity, and availability – three important facets of information security. Let’s look at how CSRF works, why organizations should pay closer attention to it, and how organizations can protect themselves.
Simply put, CSRF takes advantage of the natural functionality of a browser. When making a request to a webserver, the browser checks to see if you have any cookies for that domain. If you do, the browser bundles those cookies and sends them over in the request. This action sets the stage for CSRF as if you have a valid session cookie among those cookies. The valid session cookie is included in the request and the request is received as valid by the victim application.
How does a threat actor make the request? The threat actor has multiple ways to construct the attack, but we’ll start with the method that has the least chance of success.
The first method involves creating and hosting an impersonation site or special page that is specifically designed for the attack. It can be difficult to succeed with this method because the attacker needs to find ways to attract users of the victim site and get them to interact with the attacking site. The threat actor can’t guarantee that the attack will be a success or guarantee that a victim will visit their site. Therefore, the threat actor would prefer to host the attack on the victim application itself.
Storing the attack on the victim application greatly increases the chance of a successful attack, as the attack is already in close proximity to the victim. In this instance, the threat actor potentially has a couple of options:
If the victim application is large enough, it may have its own support forum where the threat actor could embed the attack.
If the attacker can self-register to the site and embed the attack within the actual site itself.
In both cases, the proximity and pool of users available for the attack has greatly increased the chance for success.
CSRF does most of its damage when chained with another vulnerability. Let us see how some Avertium situations affect our site and relate the effects to the three important facets mentioned earlier - confidentiality, integrity, and availability.
Our first scenario begins with an e-commerce platform. The e-commerce site has a CSRF vulnerability within the Product CRUD (Create,Read,Update,Delete) page. In the administration panel within the site, the page controls the product description which is a rich-text editor. As a bonus, the frontend display of the product description has a Stored Cross-Site Scripting (Stored XSS) vulnerability. The threat actor sets up an attack that makes a request to the vulnerable e-commerce product management page, which then delivers an XSS payload to harvest site sessions.
Image 1: CSRF Process
An unsuspecting e-commerce site staff user stumbles upon our threat actor’s attack, who unknowingly executes the attack and delivers the payload. The request triggers the product update and stores the XSS payload in the database for unsuspecting site users. Now, when a user accesses the product targeted in the CSRF attack, they will be subject to the stored XSS payload and have their session exfiltrated to the threat actor, which can result in a total account takeover.
Depending on what data our e-commerce platform stores, the threat actor could have access to credit cards, birthdays, social security numbers, addresses, and other sensitive information. Let’s break down how this impacts confidentiality, integrity, and availability:
Confidentiality has been ruined because several users could stumble upon the stored XSS payload. An even worse outcome would be if a site admin views the product with the stored XSS payload while we are dealing with a potential total application compromise.
Integrity of the data has taken a hit as well because unauthorized individuals are permanently changing that data. Now, we have lost control of the data integrity of our products, but the damage is generally contained there because the threat actor is not able to pivot outside the product data. However, if a site admin is victimized, we should be concerned with a total loss of integrity as the attacker will be able to assume the admin identity through the session harvest. Essentially, the attacker would be able to function as the admin.
Availability should be relatively unaffected because the threat actor would only be able to change the product description without disturbing other data points; unless a site admin was targeted and left our threat actor with total control of the application and rendered the data unusable.
The second case study is a little more under the radar compared to XSS. In this instance, our e-commerce site has a weak password change routine due to a user not being required to enter their current password when changing their password. Again, the threat actor has configured a payload that will change a user’s password to ‘MalicousPassword1!’
The same e-commerce staff member stumbles upon this attack and inadvertently changes their password. In this case, our threat actor has some extra leg work to do because they may not know the username associated with the victim. The leg work includes enumerating the usernames through OSINT or through a username enumeration vulnerability. The threat actor could also craft the attack to attempt to gather this information, such as creating the attack landing page to include the collection of an email address should the target application use an email for login.
As far as the affects to confidentiality, integrity, availability, this scenario is very similar to the first scenario. Our threat actor certainly has more legwork to do in figuring out which users they have modified the password for, but they are very likely to find those answers. Best case is the attack leads to a temporary Denial-of-Service until an affected user can reset their password. Worst case is total account takeover. If you would like to be reminded of the effects to confidentiality, integrity, and availability, see the first case study again.
For the third case study CSRF will not be chained to another vulnerability. Our e-commerce site also has a CSRF vulnerability in the retailer deletion routine. To keep a clean database, the developers have cascading foreign key deletions. Therefore, any records tied to a specific retailer’s primary key will be deleted. In this case, only products were related, so deletion of a retailer will also delete all its products.
The threat actor has concluded that a retailer ID can be determined by reading the product URL. The URL for the product is ecommerce.tld/brands/17/products/27. By analyzing the URL, the threat actor has determined that the ID of the retailer to be deleted is 17. The threat actor has crafted an attack that will delete the retailer with an ID of 17, and more importantly, all 123 products assigned to that retailer. The URL style is brands/retailer_id/products/product_id. This is how the attacker figured out that 17 was the retailer product ID.
Again, the unknowing e-commerce staff member has triggered this attack by clicking on the following malicious link (/admin/retailer/delete?id=17) embedded in a phishing email. Now, the retailer, including all the products, have been deleted. The e-commerce site logs administration functions and when those logs were checked, the staff member is blamed for deleting the products.
In this instance, our confidentiality is just fine. No user data or proprietary data was exfiltrated. Our integrity, on the other hand, is negatively impacted because the retailer and all its products were deleted. The attacker knows we have an incremental primary key; therefore, all the retailer data is in jeopardy. Fortunately, that is the only area affected, even if it is the e-commerce site’s core business.
Availability is also in question. While the site is up and running, the site is an e-commerce site. If they have no products, or have limited products, are they truly available? This leads to more questions, such as, how long does it take them to figure out why they are losing retailers and products before they realize they have a CSRF vulnerability? How much revenue did they lose?
A CSRF attack is not difficult to prevent. First, we are going to talk about things you should NOT do when attempting to prevent a CSRF attack:
Do not rely on ‘Origin’ and ‘Referer’ headers sent by a user. These are user supplied and controllable by proxy tools such as Burp Suite. Remember, the first rule of user supplied data is it is not trustworthy.
Do not implement your CSRF token as a cookie. This will mean the threat actor will have the ability to supply the CSRF token.
Remember, CSRF works because cookies are sent with an external CSRF request.
That leaves us with what you SHOULD do.
The most effective way to prevent CSRF is requiring a token be provided with each request that can modify data. You might recall earlier that the first rule of user supplied data is that it should not be trusted. While that rule still stands, this token is more of a challenge-answer token, like a captcha.
When a user makes a request to an application page with a form on it, the application should implant a unique token within the form that gets submitted - tying that token to a specific user and time range within the database. The token gets generated for the user each time the form is loaded. When the server receives the form submission request, it will take the token and compare it to the user and time relationships stored in the database.
If the token in the request does not match the expected user or datetime range, the application will reject the request with an error. This rejection will prevent threat actors from being able to take actions on other users’ behalf, as the threat actor has no ability to know what user is going to interact with their attack and what token has been assigned to them.
It’s important to note that that the threat actor does not know the token because they are not on the site, and they theoretically don’t have a way to acquire the token to submit it.
A successful CSRF attack could be devastating for users and businesses. These kinds of attacks could result in unauthorized fund transfers, lost client relationships, changed passwords and data theft. Usually, the attacks are the result of a successful phishing email campaign with embedded malicious links that trick victims into sending a forged request to a server.
Most developers and business owners, who do not have an information security team, may not recognize the importance of understanding CSRF. Because CSRF is not flashy, it flies under the radar as a potential attack vector. Alone, CSRF may not appear to be a major concern, but when chained with other vulnerabilities, it becomes a conduit for worse events. Developers and business owners need to become educated on how CSRF can be used to an attacker’s advantage and implement the best practices mentioned above.
Note: The author of this blog entry is Threat Labs Consultant, Eric Richardson, with editorial contributions by Emergent Threat Researcher, Portia Cole.
It’s important to get ahead of the curve by being proactive with protecting your organization, instead of waiting to put out a massive fire.
Avertium offers user awareness training through KnowBe4. The service also includes Incident Response Table-Top exercises (IR TTX) and Core Security Document development, as well as a comprehensive new-school approach that integrates baseline testing using mock attacks.
Avertium offers Zero Trust Network as a Service (ZTNaaS) for any organization that wants to control their attack surface. The zero-trust security model delivers exactly what the name promises: it is an IT security concept that specifies no access is allowed until the successful completion of authentication and authorization processes.
Avertium offers Vulnerability Management-as-a-Service (VMaaS) to provide a deeper understanding and control over organizational information security risks. If your enterprise is facing challenges with the scope, resources, or skills required to implement a vulnerability management program with your team, outsourced solutions can help you bridge the gap.
Fusion MXDR is the first MDR offering that fuses all aspects of security operations into a living, breathing, threat-resistant XDR solution. By fusing insights from threat intelligence, security assessments, and vulnerability management into our MDR approach, Fusion MXDR offers a more informed, robust, and cost-effective approach to cybersecurity – one that is greater than the sum of its parts.
This document and its contents do not constitute, and are not a substitute for, legal advice. The outcome of a Security Risk Assessment should be utilized to ensure that diligent measures are taken to lower the risk of potential weaknesses be exploited to compromise data.
Although the Services and this report may provide data that Client can use in its compliance efforts, Client (not Avertium) is ultimately responsible for assessing and meeting Client's own compliance responsibilities. This report does not constitute a guarantee or assurance of Client's compliance with any law, regulation or standard.
COPYRIGHT: Copyright © Avertium, LLC and/or Avertium Tennessee, Inc. | All rights reserved.