Showing posts with label IPS/IDS. Show all posts
Showing posts with label IPS/IDS. Show all posts

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

Friday, July 05, 2013

Scalp is a log analyzer for the Apache web server written by Romain Gaucher. The goal of this tool is to search through the apache log files and detect the possible attacks that have been sent through HTTP/GET.

Scalp get the regular expression from the PHP-IDS and matches the lines from the acces.log file. This script is written in python and needs a XML which contains the rules to detect the attacks.

You can download Scalp here.

You can download the XML file here.

See below Scalp help. It's interesting run the script and only make searches for xss, sqli, dos.. . attacks.

$ ./scalp-0.4.py --help
Scalp the apache log! by Romain Gaucher - http://rgaucher.info
usage:  ./scalp.py [--log|-l log_file] [--filters|-f filter_file] [--period time-frame] [OPTIONS] [--attack a1,a2,..,an]
                   [--sample|-s 4.2]
   --log       |-l:  the apache log file './access_log' by default
   --filters   |-f:  the filter file     './default_filter.xml' by default
   --exhaustive|-e:  will report all type of attacks detected and not stop
                     at the first found
   --tough     |-u:  try to decode the potential attack vectors (may increase
                     the examination time)
   --period    |-p:  the period must be specified in the same format as in
                     the Apache logs using * as wild-card
                     ex: 04/Apr/2008:15:45;*/Mai/2008
                     if not specified at the end, the max or min are taken
   --html      |-h:  generate an HTML output
   --xml       |-x:  generate an XML output
   --text      |-t:  generate a simple text output (default)
   --except    |-c:  generate a file that contains the non examined logs due to the
                     main regular expression; ill-formed Apache log etc.
   --attack    |-a:  specify the list of attacks to look for
                     list: xss, sqli, csrf, dos, dt, spam, id, ref, lfi
                     the list of attacks should not contains spaces and comma separated
                     ex: xss,sqli,lfi,ref
   --output    |-o:  specifying the output directory; by default, scalp will try to write
                     in the same directory as the log file
   --sample    |-s:  use a random sample of the lines, the number (float in [0,100]) is
                     the percentage, ex: --sample 0.1 for 1/1000

We ran Nikto and some Metasploit modules against one of my own Apache web servers and then, I analyzed the access.log with Scalp.
python scalp-0.4.py -l /var/log/apache2/access.log -f default_filter.xml -o scalp-output/ --html

I've taken some pictures of the Scalp html report. You can see SQL Injection, Local File Inclusion and Cross Site Scripting attacks.




Posted on Friday, July 05, 2013 by Javier Nieto

2 comments