SSRF attacks have gained momentum in recent years. They have been used as a break-in technique in significant attacks on organizations like Capital One and Microsoft. Because of the growing threat of SSRF attacks, the OWASP Top 10 document on web application security has listed them as a separate vulnerability category for the first time in its 2021 list (A10:2021).
Server Side Request Forgery (SSRF) attacks can pose a significant threat for organizations and unsuspecting users. Therefore, it is crucial to stay informed about these attacks and take necessary security measures.
What is Server Side Request Forgery (SSRF)?
It is a common break-in technique attackers use to breach email security systems. As the name suggests, SSRF attacks involve the forgery of a server request by an adversary. In a typical SSRF attack, the threat actors make the server connect back to itself, particularly to an internal resource, service, or cloud provider, and then make the manipulated URL perform malicious actions such as accessing and stealing confidential files, infecting devices with malware, etc. Through this unique approach, SSRF attacks evade ransomware protection systems with ease.
How is a Server Side Request Forgery (SSRF) Attack Launched?
The Server Side Request Forgery (SSRF) attacks go undetected because they use the following steps:
- To implement SSRF attacks, attackers look for applications with all or one of these functionalities – exporting data to a URL, importing data from a URL, or reading data from a URL one can alter.
- Once the adversaries find the ideal application, they attempt to manipulate the construction of the URL by using a URL different from the original.
- The manipulated URL sends a request to the server, which the server-side code then tries to read.
- As a result, adversaries can read data from internal services otherwise kept private.
What Leads to a Server-Side Request Forgery (SSRF) Attack?
SSRF attacks occur when there is an unpatched vulnerability in an application’s back-end server.
These attacks usually target internal systems that are inaccessible from the external network. Attackers also use SSRF to access services that one can access only through the exploited server’s loopback interface.
An attacker must have partial or complete control over the service URL to which the web application sends a request. A factor to note here is that SSRF attacks only occur when a web application fetches a remote resource without verifying or cross-checking the user-supplied URL (outbound SMTP). Such loopholes enable threat actors to send fake server requests to unexpected or eternal destinations without being detected by email security systems, VPNs, or firewalls.
Different Variants of Server-Side Request Forgery (SSRF) Attacks
Though SSRF exploits a particular category of vulnerability, the attacks can manifest in various ways. Some common variants of SSRF attacks are the following:
- Special Characters: URLs embedded with special characters such as ‘#,’ ‘?’ or ‘*’ can be quickly injected with malicious payloads. Threat actors often use this technique in SSRF attacks to direct URLs to resources that are considered safe.
- Application Server: Another common attack vector targets the application server with URLs asking that information be returned from localhost. Such attacks make servers reveal their confidential details, which the attackers can easily use for more pervasive attacks on email security.
- GET Requests: Once in control of URLs functionalities, attackers send GET requests to internet websites and server resources (localhost).
- Internal Resources: SSRF attacks are deployed to request internal network resources from web servers or run port scans on internal IPs. The information requested from internal sources could include databases containing sensitive client, customer, or employee data which adversaries can then use for spear phishing attacks.
- URL Schema: URLs usually begin with HTTP:// or HTTPS:// but the URL schema stores other lesser-known URLs that the attackers can use to access files on the internal network or local system.
Why Are SSRF Attacks a Threat to Email Security?
Web applications these days are all about making lives more straightforward for users, and therefore fetching URLs is a commonly found and used feature. However, with these advancements in web applications, the risk of Server Side Request Forgery attacks has also grown considerably. Cloud services and their complex architectures further aggravate the problem. The following are some reasons why SSRF attacks are a threat to your organization’s email security:
- Java RMI Services: Most Java installations come with Java RMI services (object-oriented Remote Procedure Call mechanism) which, unfortunately, are vulnerable to SSRF attacks. While the Java RMI service implementation ensures email security and resistance to SSRF attacks, some unsecured configurations are often employed, making the RMI service’s security vulnerable. This factor invites attacks on default RMI components like the DGC, the RMI registry, the Activation system, RMI endpoints including JMX, and custom remote objects.
- VMWare Authentication Software: Some versions of VMware authentication software are vulnerable to SSRF attacks, allowing attackers to access administrative JSON Web Tokens (JWT). The SSRF bug (dubbed CVE-2021-22056, with a severity score of 5.5) affects VMware Workspace ONE Access, which provides email security services like MFA, single sign-on, and conditional access to SaaS, web, and other mobile apps.
- Internal Systems: In SSRF attacks, the threat actors can use the target as a mediator in passing requests to a third system. Thus, SSRF attacks can be used by third-party attackers to access internal systems that are kept off the internet to conduct several malicious activities.
How to Detect an SSRF Attack in Your Email Security System?
Some tactics that you can use to detect SSRF attacks are:
- Since SSRF attacks exploit vulnerable applications, you must look for red flags in seemingly genuine URL requests from the host organization as they could cause reputational damage and legal liabilities.
- Always keep your eyes open to detect unauthorized access of sensitive configurations like open ports, server files, cloud provider metadata, etc., as SSRF attacks are launched with the intent of accessing and compromising these details.
- Look out for suspicious access to internal networks and activities (spam emails, BEC attacks, email forwarding, etc.) since SSRF attacks are characterized by the destructive feature of internal port scanning.
Ensuring Email Security And Preventing SSRF Attacks
Having analyzed the threats associated with Server Side Request Forgery attacks, here are a few mitigation measures:
Whitelisting and Blacklisting
An effective way to avoid SSRF attacks is to whitelist the DNS or hostnames that you need to access and blacklist the ones that seem suspicious. The strategy of blacklisting and whitelisting differs from application to application and is based on business requirements, but it is undoubtedly a robust mitigation measure.
Response Handling
You must verify all received responses. At no point should a raw response body request from a server reach a client unverified. Doing so ensures minimizing leakage of response data.
Discard Unused URL Schema
Since SSRF attackers are known for exploiting URL schema, the best preventive measure would be to disable unused URL schemas. The action ensures that attackers do not take advantage of the web application to make requests using risky schemas like dict://, ftp://, file:///, and gopher://.
Internal Service Authentication
Some services do not require authentication, which attackers know. They use SSRF attacks on these services very quickly. Therefore, it is essential to enable authentication for services, even on the local network.
Final Words
While Server-Side Request Forgery (SSRF) attacks are still not as severe a threat vector as phishing, they are gaining popularity as a break-in technique. The lack of awareness about this vulnerability in servers only makes things easier for the adversaries. Therefore, web applications must adopt essential preventive measures (like having MX backup, firewalls, updating servers regularly, etc.) to ensure email security against potential SSRF attacks.