ISSUE
  Several vulnerabilities in web interface of Fortigate firewall of which
the most serious one will under specific circumstances allow a remote
attacker to obtain a username and password of the Fortigate.
RELEASE
  pre 2.50 maintenance release 4
FIXED
  Issue 3           - Fortinet OS 2.50 MR4, available from FTP as of 29
Sept. 2003
  Issue 1 and 2  - Fortinet OS 2.50 MR5, available from FTP as of 05 Nov.
2003
RELEASE DATE
  12/Nov/2003
VENDOR FIRST NOTIFIED
  14/sept/2003
RELATED ADVISORIES
  Advisory posted on issue 3 a month ago.


DISCOVERED VULNERABILITIES
1. Improper input validation.
2. Username and MD5 hash of password are stored in cookie.
3. Web filter log parses unfiltered session details.

IMPROPER INPUT VALIDATION
=========================
The variables from several URL's are parsed in the HTML code of the
resulting web page. However, the variables are not sanitized before they are
used. Therefore, they can be used to inject code into the admin interface.

The examples below show you an simple alert box, but this could just as well
be used to:
-          Steel the cookie of the user that is logged in
-          Include (for instance) the Cisco homepage into the website that
is displayed after clicking the URL.
Besides, improper input validation is also a very good starting point for
other types of attacks.

https://172.16.1.254/firewall/policy/dlg?q=-1&fzone=t<script>alert('oops')</script>>&tzone=dmz
https://172.16.1.254/firewall/policy/policy?fzone=internal&tzone=dmz1<script>alert('oops')</script>
https://172.16.1.254/antispam/listdel?file=blacklist&name=b<script>alert('oops')</script>&startline=0
https://172.16.1.254/antispam/listdel?file=whitelist&name=a<script>alert('oops')</script>&startline=0(naturally)
https://172.16.1.254/theme1/selector?button=status,monitor,session"><script>alert('oops')</script>&button_url=/system/status/status,/system/status/moniter,/system/status/session
https://172.16.1.254/theme1/selector?button=status,monitor,session&button_url
=/system/status/status"><script>alert('oops')</script>,/system/status/monite
r,/system/status/session
https://172.16.1.254/theme1/selector?button=status,monitor,session&button_url=/system/status/status,/system/status/moniter"><script>alert('oops')</script>,/system/status/session
https://172.16.1.254/theme1/selector?button=status,monitor,session&button_url=/system/status/status,/system/status/moniter,/system/status/session"><script>alert('oops')</script>

USERNAME AND MD5 HASH OF PASSWORD ARE STORED IN COOKIE
========================================================
The username and MD5 hash of the password are stored in a cookie like the
one below. When combining this knowledge with the previously found XSS
vulnerabilities, a remote attacker can trick an administrator into revealing
his credentials.

cookie=APSCOOKIE=1063444738
%2615
%26FGT-602803043728
%26maarten
%26vsys0
%26$1$2a05ca7c$nU7W6SI.7L5ncc7tfZZ7D
The password hash is recognized as FreeBSD, MD5 (probably the base OS of the
firewall).

WEB FILTER LOG PARSES UNFILTERED SESSION DETAILS
===============================================
After the web filter has been enabled, the administrator has the ability to
review the web filter logs via the web interface. The web filter logs
contain the URL that has been denied by the filter. Because of the fact that
unwanted characters are not stripped from the denied URL, a remote attacker
is able to gain the username and MD5 hash of the password, as soon as the
administrator reviews the logs.

An example:
Pages with the keyword "mp3-download" are denied by the web filter. The page
https://192.168.5.11/maarten.html contains such a keyword. A remote attacker
could poison the log files by retrieving
https://192.168.5.11/maarten.html<script>alert('oops')</script>a

When altering the script a bit, the user credentials could easily be
forwarded to the attacker, who could then use these credentials to alter the
firewall if the administrator has not properly secured access to
HTTPS/SSH/TELNET/HTTP.

SOLUTION
=========
1. A basic rule in firewall administration is to only allow connections to
the firewall-administration-options from specific IP addresses (or
preferably, specific IP addresses connecting from a management  network to
the management interface of the firewall). When this best practise is
applyed, an attacker that manages to gain administration credentials as
described above, will not be able to abuse them too easily.
2. Manage your firewall from a dedicated workstation that has no connections
(directly OR through a proxy) to untrusted networks in order to avoid a
credential push as described above.
3. Upgrade FortiOS 2.50MR5, which (according to fortinet) does not contain
these problems.