CVE-2016-3978 Open Redirect & XSS in FortiOS (Fortinet)

Introduction

Some months ago, I reported to the Fortinet PSIRT team two vulnerabilities which affect different Fortigate firmware versions. 

You probably know that "Fortinet is a leading provider of fast and secure cyber security solutions offers enterprise-level next generation firewalls and vast array of network security products."

As usual, I'm disclosing these vulnerabilities under responsible disclosure format which is (in my opinion) one of the best ways (in most cases) to publish technical details about a vulnerability.

You can find the Fortinet public advisory here.

I´d like to thank the spanish Fortinet team for helping me with the case by speeding it up.

Vulnerability Details

Affected version

• 5.0 branch: 5.0.12 or below
• 5.2 branch: 5.2.2 or below

*** 4.3 and lower branches are not affected

 Open Redirect

The Open Redirect is located in the Fortinet Fortigate web administration console.

Proof of concept:

• https://fortigate-management-ip-address/login?redir=http://evil-site

The parameter "redir" doesn't have implemented any kind of validation so I´m able to redirect the browser to any malicious web site from the Fortigate web login portal.

Case study example:

1. An attacker sends a phishing email to the firewall administrator with the link bellow https://fortigate-management-ip-address/login?redir=http://evil-site (Previously the attacker should figure out the firewall management IP address).
2. If the administrator clicks on the link, the real portal login will appear. The administrator is supposed to type the admin credentials.
3. When the user/pwd are typed, the browser is redirected to the attacker evil-site where there is a fake Fortigate login portal. Credentials are asked for again due to an alleged erroneous user/password.
4. The administrator retype the credencials, the evil-site receives the user/pwd and redirects the browser to the real firewall login portal.
5. The administrator would type the credentials again and would get access to the real firewall. Meanwhile, the attacker has stolen the user/password.

Cross Site Scripting

The Cross Site Scripting vulnerability is located in the Fortinet Fortigate web administration console.

Proof of concept:

• https://fortigate-management-ip-address/login?redir=javascript:alert(document.cookie)

The parameter "redir" doesn't have implemented any kind of validation so we are able to execute javascript code in the victim browser.

Solutions

Upgrade to one of the following FortiOS versions:

• 5.0 branch: 5.0.13 or above
• 5.2 branch: 5.2.3 or above
• 5.4 branch: 5.4.0 or above

More details: http://www.fortiguard.com/advisory/fortios-open-redirect-vulnerability

Conclusion

Every single device or appliance placed in your network, even the ones that are part of the security of your infrastructure, would be affected by some vulnerability. We have seen how other well known vendors like Juniper, FireEye, Cisco, etc... were affected by similar vulnerabilities as well. This should be always kept in mind.

The vulnerabilities mentioned above are hard to exploit because the firewall administrator is supposed not to click on a link that forwards to their own firewall... But who knows... ;)

References

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3978

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-3978

http://www.securitytracker.com/id/1035332

http://www.fortiguard.com/advisory/fortios-open-redirect-vulnerability

http://seclists.org/fulldisclosure/2016/Mar/68

Read More

XSS-game by Google exercises 4, 5 and 6.

In the previous post we talked about how to resolve the exercises 1, 2 and 3 of the XSS-game proposed by Google. Now, we are going to resolve the latest ones.

Exercise 4

This exercise is similar to the previous one (Exercise 3). The main difference is that now,  we have an input. 

It is expected that a number will be typed into the box, but... what will happen if we write a name instead of typing a number?

What happens is that our string has been included into the "img" tag...

So, if we use:  3');alert('Behindthefirewalls the result would be...

And the alert appears...

Exercise 5

I don't know what the reason for looking at "next=confirm" was at first because logic would dictate that the first attempt would be to try to exploit a XSS vulnerability in the input field...

But the first thing that I did was to replace "confirm" by "http://www.behindthefirewalls", reload the page, type my mail and click on "Next" and the result was that I was redirected to my blog...

https://xss-game.appspot.com/level5/frame/signup?next=http://www.behindthefirewalls.com

We have discovered another security issue but what we want to do is  locate a XSS vulnerability.

I was trying different options with no success so I decided to read the hints offered by Google. "If you want to make clicking a link execute Javascript (without using the onclick handler), how can you do it?"

So I tried to use:

next=javascript:alert("behindthefirewalls")

And the alert appeared.

Exercise 6 

The fourth hit says: "If you can't easily host your own evil JS file, see if google.com/jsapi?callback=foo will help you here."

If we change "foo" for "alert" www.google.com/jsapi?callback=alert will have included in its code:

So, if we use the link bellow, we can exploit the vulnerability.

frame#//www.google.com/jsapi?callback=alert 

I spent some time trying to solve this exercise in a different way. I tried a lot of possibilities to exploit a XSS vulnerability...

... until I remembered a post I read some months ago...

#data:text/javascript,alert('behindthefirewalls')

Read More

XSS-game by Google exercises 1, 2 and 3.

As Google say, "Cross-site scripting (XSS) bugs are one of the most common and dangerous types of vulnerabilities in Web applications. These nasty buggers can allow your enemies to steal or modify user data in your apps..."

So they have decided to help us to learn how to exploit these kinds of vulnerabilities by creating a vulnerable web site at:

https://xss-game.appspot.com/

There are 6 exercises to resolve. Before starting to resolve these issues... Why should I  know how to exploit a XSS vulnerability?

1. To be more qualified in the security field.
2. To make money.

Currently, Google is paying up to $7,500 for dangerous XSS bugs discovered in their most sensitive products.

But Google is not the only one who is paying a bounty for disclosing vulnerabilities. Others like Yahoo, Facebook or Paypal have the same  policy of rewards for discovering bugs.

In this post, we are going to resolve 3 issues proposed by Google. In the next post, we will resolve the latest ones.

Exercise 1

That is the easiest exercise. Our input will be directly included in the page without proper escaping.

By inserting the code below, we will be successful.

<script>alert('BehindTheFirewalls')</script>

Exercise 2

This exercise is an example of how to perform a persistent or stored Cross-Site Scripting attack in a simple way.

<img src=x onerror=alert('BehindTheFirewalls')>

Exercise3

This exercise is a little complex because the user doesn't have an input to try to exploit the XSS. 

But what happen if we rewrite the URI? If we change "#1" by "#11111"...

... we will see that "1111" has been added to the source code. 

So, if we add #11111'onerror=alert('BehindTheFirewalls')> at the end of the URL, the code will be:

<img src='/static/level3/cloud#11111'onerror=alert('BehindTheFirewalls')>'.jpg' />

And the alert will appear.

These are the three posible options to exploit this vulnerability.

/frame#1'onerror=alert('BehindTheFirewalls')>

/frame#1.jpg'onload=alert('BehindTheFirewalls')>

/frame#1jpg'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

Read More