From the beginning of the Internet, sending of junk email has been prohibited. Gary Thuerk sent the first email Spam message in 1978 to 600 people. A few decades later the European Union came to regulate this issue permanently with EU Directive 2002/58/EC, 1 year after US Government did the same with CAN-SPAM Act of 2003. One main attribute of both regulations was the necessity to develop technologies, that will give users the option to stop receiving unwanted messages. In this article, we are going to explore how well protected these technologies are.
Analysis
We took a sample of the most used mailing list services as well as custom made mailing list applications developed in-house from various corporations in order to provide a marketing boost for their platforms.
During our analysis, we used a total sample of 100 unique URLs from different services; We conducted the following tests as using authenticated (valid subscription email) and unauthenticated context:
- Vulnerable Dependencies
- Header Misconfigurations
- Information Leakage
- Form Bruteforce
- Sensitive Data in GET Request
- Unauthenticated Unsubscribe
All scenarios were non-intrusive, as we avoided to perform any test that may cause any kind of disturbance in the affected services, such as and not limited to:
- SQL Injection
- Remote Code Execution
- Local/Remote File Inclusion
Overview
In the following graph, the percentage of the vulnerabilities identified is displayed.
The research indicates that the half of the URLs in scope (51%), present particular HTTP header misconfigurations which introduce HTTP security risks of low severity. Most of these security deviations include lack of particular HTTP response headers or have particular headers set to insecure values. In addition, there is a 14% of the URLs in scope that allow unauthenticated unsubscribe. Under these circumstances one may achieve to unsubscribe the victim by submitting the URL on behalf of the user. Equally, a 14% of the URLs allow form bruteforce to vulnerable landing pages. More specifically in the 14% of the unsubscribe links, there was no CAPTCHA or similar anti-bruteforce mechanism. Finally, the 7% of the URLs pose risks of different severity including vulnerable libraries, information leakage (user e-mails), and allow the presence of sensitive data in GET requests (e.g. track and/or sessionID, e-mail address etc.). Overall, it can be concluded that the majority of such URLs for unsubscribe services may introduce risks from low to medium severity.
1. Vulnerable Dependencies
While caring about security of your code is arguably important, it is not enough for building a secure product. Vulnerabilities might also arise from a 3rd party component. Handling of those vulnerable libraries is thus another essential aspect of building a secure product.
The goal of this test is to identify project dependencies and check if there are any known, publicly disclosed, vulnerabilities.
2. Header Misconfigurations
The affected applications lack the use of security related HTTP – Headers (strict-transport-security, content-security-policy, x-permitted-cross-domain-policies etc.)
In example, Content Security Policy Is an W3C specification offering the possibility to instruct the client browser from which location and/or which type of resources are allowed to be loaded. To define a loading behaviour, the CSP specification use “directive” where a directive defines a loading behavior for a target resource type.
3. Information Leakage
Information leakage happens whenever a system that is designed to be closed to an eavesdropper, reveals some information to unauthorized parties nonetheless.
The affected applications leak information either about user e-mails or about affected mailing lists.
4. Form Bruteforce
A brute-force attack consists of an attacker trying many combinations or pass-phrases with the hope of eventually guessing correctly. The attacker systematically checks all possible combinations or pass-phrases until the correct one is found.
The affected unsubscribe forms are completely unprotected to brute force attacks.
Note: A very effective anti brute-force technique is the use of Google CAPTCHA.
5. Sensitive Data in GET Request
At a minimum, attackers can gather information from query strings that can be utilized in escalating their method of attack, such as information about the internal workings of the application or database column names. Successful exploitation of query string parameter vulnerabilities could lead an attacker to impersonate a legitimate user, obtaining proprietary data, or simply executing actions not intended by the application developers.
The affected applications pass user sensitive information through GET requests. This can affect the confidentiality of the transactions due to the fact that affected data get stored in logging facilities.
6. Unauthenticated Unsubscribe
In the systems in scope, it has been identified that there is a severe lack of a thorough authentication process. More specifically, the affected applications give the allowance to anyone with the knowledge of stored emails to unsubscribe them from the list. To this end, a malicious actor could utilize the e-mail address of the victim and automate the process of unsubscribing in multiple hosts, without having further details (e.g. user credentials) on the victim’s account.
Business Continuity Attack kill-chain
From the summary of URLs, that we tested, many of them pointed to a mailing-list management platform.
During our analysis to that system we came by a combination of vulnerabilities allowing malicious users to disrupt business continuity of the affected parties. In detail the affected services is utilizing a `GET` request. The first part is a numeric (sequential) context identifier (for the affected party). That alone can give the attacker an extensive knowledge of the affected parties. The second vulnerability was the lack of anti-brute-force mechanisms (CAPTCHA) in the unsubscribe form. That can allow multiple automated requests without any user intervention.
Third and last in the chain was the ability to provide email to unsubscribe without any form of authentication.
Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.