Showing posts with label Fortinet. Show all posts
Showing posts with label Fortinet. Show all posts

Monday, May 02, 2016

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

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


Posted on Monday, May 02, 2016 by Javier Nieto

No comments

Monday, September 09, 2013

In the last post, we talked about how to create some custom Application Control signatures with Fortinet Fortigate firewalls in order to detect a specific behavior to look for possible infected hosts inside our networks.

In this post, I will show you how to detect some tools which could be used to attack our infrastructure by creating custom IPS signatures. We will give three examples and then, you will be capable of creating your own signatures to detect similar tools.

Sqlmap

Sqlmap is "an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database server". Of course, the best way to avoid attackers from getting access to our databases is to develop securely, checking our security by performing regular pentesting projects and using a Web Application Firewall... But we always want to know when we are under attack and to be protected just in case we did a mistake in our security planning.

We are going to create a custom IPS signature to detect Sqlmap by looking at the User-Agent string. Some of these tools have the option of changing the User-Agent in order to try to keep a little bit more unnoticed.  Even knowing that Sqlmap has this option, it worths some of our time to detect attackers that don´t change the default User-Agent of their tools. There are a lot of them out there...

This is the default Sqlmap User-Agent (it depends on the installed version).

  • User-Agent: sqlmap/1.0-dev-nongit-20141210 (http://sqlmap.org)


We just need to add a pattern like that to detect the User-Agent used by Sqlmap.

  • --pattern \"User-Agent|3a 20|sqlmap\"

With this pattern we will match "User-Agent: sqlmapXXXXXXXXXXXXXXX"

Noticed that the characters bellow must be written as:

  • " ->|22|
  • ; -> |3B| or |3b|
  • \ -> |5C| or |5c|
  • | -> |7C| or |7c|
  • : -> |3A| or |3a|
  • space -> |20|

So ":" corresponds to |3a| and " " (space) corresponds to |20| so it should be |3a 20|


You can create the custom signature via CLI with the commands bellow.

config ips custom
    edit "Sqlmap.Web.Vulnerability.Scanner"
        set signature "F-SBID( --name \"Sqlmap.Web.Vulnerability.Scanner\"; --protocol tcp; --service HTTP;  --parsed_type HTTP_GET; --flow from_client; --pattern \"User-Agent|3a 20|sqlmap\"; --context header; )"
        set comment ''
    next
end

Nikto

Nikto "is an Open Source (GPL) web server scanner which performs comprehensive tests against web servers for multiple items, including over 6700 potentially dangerous files/programs, checks for outdated versions of over 1250 servers, and version specific problems on over 270 servers. It also checks for server configuration items such as the presence of multiple index files, HTTP server options, and will attempt to identify installed web servers and software."

Nikto has an User-Agent like that (it depends on the version):

  • User-Agent: Mozilla/4.75 (Nikto/2.1.4) (Evasions:None) (Test:Port Check)

As we did in our last post, we will use regular expression in order to try to detect all possible Nikto User-Agents used by diferent versions.

  • --pcre /User-Agent: Mozilla.[0-9]{1}.[0-9]{2}..Nikto/

The final rule is:

config ips custom
    edit "Nikto.Web.Vulnerability.Scanner"
        set signature "F-SBID( --name \"Nikto.Web.Vulnerability.Scanner\"; --protocol tcp; --service HTTP; --parsed_type HTTP_GET; --flow from_client; --pcre /User-Agent: Mozilla.[0-9]{1}.[0-9]{2}..Nikto/; --context header; )"
        set comment ''
    next
end

Skipfish

Skipfish "is an active web application security reconnaissance tool. It prepares an interactive sitemap for the targeted site by carrying out a recursive crawl and dictionary-based probes. The resulting map is then annotated with the output from a number of active (but hopefully non-disruptive) security checks."

As the previous ones, depending on the installed version, Skipfish has a different User-Agent. Here some examples.

  • User-Agent: "Mozilla/5.0 SF/1.01b"
  • User-Agent: "Mozilla/5.0 SF/2.10b"

By using pcre we will try to detect again all possible versions:

  • --pcre /User-Agent: Mozilla.[0-9]{1}.[0-9]{1}.SF.[0-9]{1}.[0-9]{2}[A-Za-z_]/

config ips custom
    edit "Skipfish.Web.Vulnerability.Scanner"
        set signature "F-SBID( --name \"Skipfish.Web.Vulnerability.Scanner\"; --protocol tcp; --service HTTP; --parsed_type HTTP_GET; --flow from_client; --pcre /User-Agent: Mozilla.[0-9]{1}.[0-9]{1}.SF.[0-9]{1}.[0-9]{2}[A-Za-z_]/; --context header; )"
        set comment ''
    next
end

Testing

We just need to add our custom IPS signatures to our IPS profile and set them to "Block". Then we will see how our IPS is dropping the sessions generated by those tools when they are used against our web servers.






Posted on Monday, September 09, 2013 by Javier Nieto

No comments

Sunday, September 01, 2013

In this blog post I would like to share some tricks to detect suspicious activities that could end with finding compromised hosts inside a network. I´ve noticed (I guess you too) that there are some malware out there and the first things they do, when a computer is infected, is to check the public IP address in order to let the malware developer know, where the infected host is located. We can see this behavior in a lot of malware like Cryptowall 2.0KriptovoZeroAccess and many more...

I use to work with Suricata as IDS (by the way, really happy with its performance) and Emerging Threats rules in order to detect computers trying to get its public IP address. You know... it´s weird that someone from the Human Resources department is interested in getting their computer´s public IP address...

You can find some free Suricata signatures here that are focused on that task. You can filter by "IP Check" or "External IP Lookup".

If you are using Suricata or Snort as IDS, they are good for starting an investigation when these alerts are triggered but I would like to go a little bit further without allowing the malware to get the public IP address, just to make things more difficult for the malware developer...

I´m not using Suricata as IPS but I do have an IPS and an Application Control with a Fortinet Fortigate firewall. There are many ways to achieve this goal, but this time I think my best bet is Fortinet App Control. Also, a NGFW allows us to perform a man in the middle "attack" and see what´s going on inside a SSL tunnel which makes our signatures more effective, just in case the connection goes to a SSL service...

Creating a custom App Control signature with Fortinet

I've decided to create custom signatures to detect if someone or something is trying to get the public IP address. I would like to share  three options that you could work with.

It is not a big deal to create custom signatures with Fortinet App Control to detect these connections, so for me, it worth some of my time to deal with them not only to detect them but drop them.

Example 1 - Easy mode

If we get access to checkip.dyndns.org we can see that the public IP address is returned.


If we look at the pcap capture we can see (obviously) that the host reached is checkip.dyndns.org. We can see the domain in the Host line in the HTTP header, so here is where we will look and it will be defined thanks to the signature Context.


If we want to detect if someone is getting access to checkip.dyndns.org we just need to create the rule bellow via CLI.

config application custom
    edit "External.IP.Lookup.-checkip.dyndns.org-.Custom"
        set comment ''
        set signature "F-SBID( --attack_id 4467; --name \"External.IP.Lookup.-checkip.dyndns.org-.Custom\"; --app_cat 25; --protocol tcp; --service HTTP; --parsed_type HTTP_GET; --flow from_client; --pattern \"checkip.dyndns.org\"; --context host; --no_case; )"
        set category 25
    next
end

You can find more APP controls example of rules in my Github account.

This rule doesn´t have a lot to explain, it´s really easy and "similar" to Snort/Suricata rules. This is a brief description of our rule:

  • -- attack_id 4467; if you don´t specify an attack_id, it will automatically assigned
  • --name; signature name
  • --app_cat 25; correspond to Web.Ohters category
  • --pattern; the string we are going to look for in the packet traffic
  • --parsed_type HTTP_GET; is the HTTP method used to retrieve the public IP address
  • --flow from_client; Match packets sent from the client to the server
  • --no_case; by default, patterns are case sensitive so --no_case makes the pattern matching case insensitive
  • --context host; context to match the pattern. There are several ones: HOST, URI, HEADER, BODY, BANNER...

Once the rules are created, you just need to add them to your AppControl sensor and set the Action.


When the changes are applied and we try to get access to checkip.dyndns.org again, the connection will be blocked and we will get that message: "Application Blocked". That is because "Replacement Messages for HTTP-based Applications" is checked.



If you don´t want to inform the users/malware you just need to unset "Replacement Messages for HTTP-based Applications"
















and there will not be any messages, the session will be just dropped.


Example 2 - Medium mode

Sometimes we need to specify not just the hostname we want to monitor/block but we also need to specify the HTTP URI. Imagine we need to block "ip-api.com/xml" but we want to let our users still to get access to "ip-api.com".

We will need to check two condition:
  1. Host: ip-api.com
  2. URI: xml
So we will need to set two patterns and two context:
  1. --pattern \"ip-api.com\"; --context host;
  2. --pattern \"xml\"; --context uri;
This is the rule we need to configure.

config application custom
    edit "External.IP.Lookup.-ip-api-.Custom"
        set comment ''
        set signature "F-SBID( --attack_id 5188; --name \"External.IP.Lookup.-ip-api-.Custom\"; --app_cat 25; --protocol tcp; --service HTTP; --parsed_type HTTP_GET; --flow from_client; --pattern \"ip-api.com\"; --context host; --no_case; --pattern \"xml\"; --context uri; --no_case; )"
        set category 25
    next
end

Example 3 - Paranoid mode

As you have noticed, if the malware retrieves the public IP address from a domain which has not been included in our signatures, we will not be aware of it and the session will not be monitored/dropped.

There is a possible solution. When the malware requests the public IP address from a web server, it responds with the IP address in the HTTP body.



What we can do is to look at the responses looking for our public IP addresses. Of course, we usually have more than one, in my case, a complete class B network. In order to check if our class B network (88.11.0.0/16) is included in the server response, we will use PCRE.

To achieve our goal, we need to set the following parameters:
  1. --flow from_server; Match packets sent from the server to the client
  2. --pcre /88.11.[0-9]{1,3}.[0-9]{1,3}/; That regular expression matches from 88.11.0.0 to 88.11.999.999
  3. --context body; we will look at the server response in the HTTP body
So that is the rule.

config application custom
    edit "External.IP.Lookup.Detected.Custom"
        set comment ''
        set signature "F-SBID( --name \"External.IP.Lookup.Detected.Custom\"; --app_cat 25; --protocol tcp; --service HTTP; --parsed_type HTTP_GET; --flow from_server; --pcre /88.11.[0-9]{1,3}.[0-9]{1,3}/; --context body; )"
        set category 25
    next

*** Think about possible false positives before setting this rule to Block. You should monitor before blocking because some web pages like glassdoor.com, returns your public IP address in the commented source code...

References

http://video.fortinet.com/uploads/documents/IPS%20Signature%20Syntax%20Guide.pdf



Posted on Sunday, September 01, 2013 by Javier Nieto

No comments

Saturday, August 10, 2013

Currently, we can check that many manufacturers of security appliances are writing books "for dummies".  You can get them for free and you can download them in this post.

Notice these books are free because they want to sell you their products, obviously... But many of them are really interesting because they show you how working the Next Generation Firewalls, how the Modern Malware is evolutioning, how we can avoid attacks like Distributed Denials of Firewalls, etc...

I've created a recopilation of many of them...

Click on the pictures to download the books.  If some links are broken, please tell me.

Definitive Guide to Next-Generation Threat Protection FireEye




Intrusion Prevention Systems For Dummies Sourcefire


Oficial link


Modern Malware for Dummies by PaloAlto Networks


Oficial link


Next Generation Firewalls for Dummies by Palo Alto  Networks


Oficial link


UTM for Dummies by Fortinet



DDOS for dummies by Corero


Oficial link


Network Security in Virtualized Data Centers by PaloAlto Networks


Oficial link

Posted on Saturday, August 10, 2013 by Javier Nieto

No comments

Tuesday, June 04, 2013

If you recently have upgraded your Fortigate Firewall to FortiOS 4.0 MR3 perhaps you have noticed an increase in the traffic log.

FortiOS 4.0 MR3 has the value of extended-traffic-log enabled by default instead of previous versions where this value was disabled by default.

If you want to disabled this new default option, here you have the commands:

  • config log [memory|disk|fortianalyzer|...] 
  • filter set extended-traffic-log [enable|disable]

What does the log filter setting "other-traffic" display?

Posted on Tuesday, June 04, 2013 by Javier Nieto

No comments

Monday, June 03, 2013

When you build a Firewall in High Availability you need to be sure if the cluster's members are totally synchronized.

I am going to give you some commands in order to change the CLI session between the members for checking your HA.

First of all you need to watch how many members there are. If you have an active-pasive cluster, you need to know who is the master member. For this, you need to execute: # get system ha status


Then you need to know the vdoms and all configuration hashes. For this, you can execute: # get system checksum status
 

You need to compare the hashes between the members. It's a requirement to be the same. You change to another members executing:   
# execute ha manage 1


Finnaly you compare the hashes: # get system checksum status


If the hashes are the same, your cluster is ok, if not, you need to solve the problem because one or more the cluster's members are misconfigured.




Posted on Monday, June 03, 2013 by Javier Nieto

No comments

Some times, firewall security administrators have told me... "I have a lot of policy rules on my firewall, how can I discover unused policy rules?" or "I just created a new policy rule, how can I know if this rule has been matching?

With Fortinet Firewalls is really easy to do.

First of all you need to add  a new column in Policy -> Policy section.


It's necessary to add Count option to the right field.

 

Finally, you will see if the rule was matched or not and how many packets and Megabytes cross through the policy rule.


The counters of all policy rules are set to "0 packets/0 B" when the firewall is rebooted. If the last time that you have rebooted your firewall was one year ago and you have policy rules with "0 packets/0 B", maybe this rules are unnecessary.

Also you can set to 0 the counter of a policy rule manually if you you right-click on the policy and select "Clear Counters".



Posted on Monday, June 03, 2013 by Javier Nieto

1 comment

Friday, May 31, 2013

Last week I had to configure a Fortigate with IPv6. Also the firewall was needed to works as DHCPv6 Server.

Within two weeks, we will have around 200-300 network administrators in a conference room connected by WIFI. We want this users only get IPv6 addresses. So, if the network administrators haven't just implemented the IPv6 in their remote networks, they will not be able to connect to them. We want they to keep in mind the importance of IPv6 in the near future.

The next configuration is running on the v5.0.2 Fortigate firmware version. This version is only recommended for testing propourses. I recommend you the v4.3.10 firmware version. In this case we want to test the last firmware version in an "production environment" too.




How to configure the external Interface:

config system interface
    edit "wan1"
        set alias "External"
            config ipv6
                set ip6-address xxxx:xxx:xxx:113::2/64
                set ip6-allowaccess ping
                set ip6-manage-flag enable
                set ip6-other-flag enable
            end
    next



How to configure the static6 route:
 
config router static6
    edit 1
        set device "wan1"
        set gateway xxxx:xxx:xxx:113::1
    next
end


Posted on Friday, May 31, 2013 by Javier Nieto

No comments

Tuesday, April 02, 2013

Some months ago, Fortinet published a new list of Botnets Applications supported.

Frequently, more and more infected hosts are including in Botnets Networks. Fortinet has developed a new application's signatures in order to trying to avoid that the infected PCs (called Zombies) contact with the Command & Control Server.

Today, this is the known botnet list by Fortigate:

Agobot.Phatbot, Asprox, BlackEnergy, Bredolab, CMultiLoader, Chapro, Citadel, Cridex, DHL, Danmec.Asprox, Darkness, Dexter, DirtJumper , DistTrack, Duqu, ET, Eleonore.Web.Exploit, FakeSkype, Festi, Flame, Gbot, Gootkit, Gozi, Gumblar, Hiloti, IRC, Illusion, Imrabot, Jeefosance , Katusha, Koobface, LOIC, LOIC.IRC, Lethic , LoL, MacOS.Flashback, MachBot, Mariposa, MoneyBack, Morto, Murofet.CC, Night.Dragon, Pbbot, Phatbot , Pushdo, Qakbot, Ramnit, SDBot , SSHDkit Botnet, Sasfis, Sisron, Smoke, SpyEye, Storm.Krackin, Storm.Worm, T3C4I3, Tedroo, Torpig.Mebroot, Ursnif, VBCF, VertexNet, Vilsel, Virut, Vundo, Waledac, Webwail.Audio.Captcha, Yahoo.Messenger.Worm, Zeroaccess, Zeus

How can we avoid that with Fortigate Firewalls?

First of all, you need to create an Application Sensor in UTM Profiles. We named the Sensor "Botnet":



Posted on Tuesday, April 02, 2013 by Javier Nieto

No comments