Covert
Redirect is an application that takes a parameter and redirects a user
to the parameter value WITHOUT SUFFICIENT validation. This is often the
of result of a website’s overconfidence in its partners. In another
word, the Covert Redirect vulnerability exists because there is not
sufficient validation of the redirected URLs that belong to the domain
of the partners.
Two main validation methods that would lead to Covert Redirect Vulnerability:
(1) Validation using a matched domain-token pair
(2) Validation using a whitelist
(1) Validation using a matched domain-token pair
(2) Validation using a whitelist
Q&A
Why is it called Covert Redirect Vulnerability?
The name Covert Redirect is derived from and to contrast with the existing vulnerability Open Redirect. An Open Redirect is an application that takes a parameter and redirects a user to the parameter value WITHOUT ANY validation (OWASP). If a website is exposed to Open Redirect attack, it is often because of its own negligence.
A Covert Redirect resembles an Open Redirect however it is preceded by a normal redirect from the Website to a partner that is exposed to Open Redirect attacks. Covert Redirect vulnerability exists because of the Website’s overconfidence in its partners, consequently giving leeway to the attackers. The Website relies on its partners to provide a list of “trustworthy” domains and assumes all would be safe. However, without sufficient verification of the redirected URLs, no safety could be guaranteed.
The name Covert Redirect is derived from and to contrast with the existing vulnerability Open Redirect. An Open Redirect is an application that takes a parameter and redirects a user to the parameter value WITHOUT ANY validation (OWASP). If a website is exposed to Open Redirect attack, it is often because of its own negligence.
A Covert Redirect resembles an Open Redirect however it is preceded by a normal redirect from the Website to a partner that is exposed to Open Redirect attacks. Covert Redirect vulnerability exists because of the Website’s overconfidence in its partners, consequently giving leeway to the attackers. The Website relies on its partners to provide a list of “trustworthy” domains and assumes all would be safe. However, without sufficient verification of the redirected URLs, no safety could be guaranteed.
What is Covert Redirect based on validation using a matched domain-token pair?
The Website checks the domain name against the token (assigned to the partner as a means for verification) in the redirected URL. If the pair is on the approved list in its database, the Website would allow the redirection. However, if the URL belongs to a domain that has Open Redirect vulnerability, users could be redirected from the Website to the vulnerable site and then to a malicious site.
The Website checks the domain name against the token (assigned to the partner as a means for verification) in the redirected URL. If the pair is on the approved list in its database, the Website would allow the redirection. However, if the URL belongs to a domain that has Open Redirect vulnerability, users could be redirected from the Website to the vulnerable site and then to a malicious site.
Some Examples,
| Website | Company | Blog Detail | POC Video |
| amazon.com | Amazon | Blog | Youtube |
| nytimes.com | NYTimes | Blog | Youtube |
What is Covert Redirect based on validation using a whitelist?
The Website preserves a whitelist of domains to which they allow redirection. The whitelist usually comprises of well-known web giants, e.g. Google, Facebook and LinkedIn.
Before a user is redirected out of the Website, it will check whether the redirected URL belongs to the domains on its whitelist. If it does, the Website will authorize the redirection. However, if the URL belongs to a domain that has Open Redirect vulnerability, then the user could be redirected from the Website to the vulnerable site and then to a malicious site.
The Website preserves a whitelist of domains to which they allow redirection. The whitelist usually comprises of well-known web giants, e.g. Google, Facebook and LinkedIn.
Before a user is redirected out of the Website, it will check whether the redirected URL belongs to the domains on its whitelist. If it does, the Website will authorize the redirection. However, if the URL belongs to a domain that has Open Redirect vulnerability, then the user could be redirected from the Website to the vulnerable site and then to a malicious site.
Some Examples,
| Website | Company | Blog Detail | POC Video |
| ebay.com | eBay | Blog | Youtube |
| wordpress.com | WordPress | Blog | Youtube |
| odnoklassniki.ru | Odnoklassniki.ru | Blog | Youtube |
| godaddy.com | GoDaddy | Blog | Youtube |
| youku.com | Youku | Blog | Youtube |
The
validation system related to OAuth 2.0 and OpenID could be viewed as
using a semi-whitelist. The list is not specified by the Website
(provider) but rather by the partners (clients).
OAuth 2.0 and OpenID Covert Redirect
OAuth 2.0 and OpenID Covert Redirect
Who should be responsible for the vulnerability?
The vulnerability is in general due to the existing weakness in the partner websites; therefore, the Website might not feel it is responsible to patch up the vulnerability. To the partners, they may be unaware of the vulnerability or do not bother to fix it. In my view, the Website should be responsible for the vulnerability because attacks are mainly targeted at them.
The vulnerability is in general due to the existing weakness in the partner websites; therefore, the Website might not feel it is responsible to patch up the vulnerability. To the partners, they may be unaware of the vulnerability or do not bother to fix it. In my view, the Website should be responsible for the vulnerability because attacks are mainly targeted at them.
How widespread is the vulnerability?
Its sphere of influence is almost as wide as that of Open Redirect vulnerability.
Its sphere of influence is almost as wide as that of Open Redirect vulnerability.
Why is it a serious vulnerability?
▪ Enable Open Redirect Attacks
▪ Wide coverage (It could potentially affect as many websites as Open Redirect could do)
▪ Possibility of sensitive information leakage (such as Covert Redirect vulnerability related to OAuth 2.0 and OpenID)
▪ Enable Open Redirect Attacks
▪ Wide coverage (It could potentially affect as many websites as Open Redirect could do)
▪ Possibility of sensitive information leakage (such as Covert Redirect vulnerability related to OAuth 2.0 and OpenID)
How to patch the vulnerability?
The Website(s) need to carry out sufficient verification of the URLs for redirection.
The Website(s) need to carry out sufficient verification of the URLs for redirection.
What is the meaning of the logo?
The logo depicts the three parties involved in the attack: the website of interest (“the Website” hereafter; top-left), the partner (bottom) and the attacker (top-right).
Due to the loophole in the partnership, the attacker is able to attack the Website through the link between them. The partner therefore acts as a bridge between the Website and the attacker, albeit unintentionally.
The entire logo is made up of two hemispheres that look like mirror images of each other, except that the colors are different. The attack could be seen as a redirect from the partner but it is preceded or masked by a redirect from the Website to the partner. The blue background of the left hemisphere signifies the purview of the Website who is only aware of the first redirect and believes it to be safe. However, there is an attendant malicious redirect from the client to the attacker, which appears “invisible” to the Website. Thus, a white background is chosen for the right hemisphere to represent the space in which the second redirect occurs. To the attacker, the second redirect may be the real attack while the first one only a camouflage.
The logo depicts the three parties involved in the attack: the website of interest (“the Website” hereafter; top-left), the partner (bottom) and the attacker (top-right).
Due to the loophole in the partnership, the attacker is able to attack the Website through the link between them. The partner therefore acts as a bridge between the Website and the attacker, albeit unintentionally.
The entire logo is made up of two hemispheres that look like mirror images of each other, except that the colors are different. The attack could be seen as a redirect from the partner but it is preceded or masked by a redirect from the Website to the partner. The blue background of the left hemisphere signifies the purview of the Website who is only aware of the first redirect and believes it to be safe. However, there is an attendant malicious redirect from the client to the attacker, which appears “invisible” to the Website. Thus, a white background is chosen for the right hemisphere to represent the space in which the second redirect occurs. To the attacker, the second redirect may be the real attack while the first one only a camouflage.
Who found the Covert Redirect Vulnerability?
The vulnrability was found by WANG Jing, a PhD student in mathematics from Nanyang Technological University.
From:
No comments:
Post a Comment