Key features

• Discover VPN services running
• Fingerprint based on vendor IDs (VID)
• Guess implementation basing on responses analysis (backoff)
• Enumerate supported transforms in Main Mode
• Check for Aggressive Mode
• Enumerate supported transforms in this Aggressive Mode
• Enumerate valid client/group IDs in Aggressive Mode
• Allow for rate limiting
• Analyse results to list actual issues
• Export results in 2 different formats
• Load IPs from command line or text files
• Determine support for IKEv2

Overview

iker scans and analyses the Internet Key Exchange (IKE) protocol, identifying common misconfigurations in VPN concentrators. It is based on ike-scan.

It discovers and try to fingerprint the VPNs in a first step. Later, it tries to enumerates valid transforms in Main Mode and in Aggressive Mode if it is supported. Finally, it will try to enumerate group IDs if a dictionary was provided.

iker implements two ways of enumerating valid group IDs:

• Cisco IPSec VPN Implementation Group Name Enumeration Vulnerability
• Responses analysis

Once all the tests have been launched, iker analyses the results and generates a report with the issues found.

Requirements

• ike-scan
• Python

In addition, the following Python packages are used (they usually are included with normal Python installations):

• subprocess
• argparse

Installation

Download iker from the link below and uncompress it.

Usage

$ sudo python iker.py -h

iker v. 1.0

The ike-scan based script which checks for security flaws in IPsec-based VPNs.

                               by Julio Gomez ( jgo@portcullis-security.com )

usage: iker.py [-h] [-v] [-d DELAY] [-i INPUT] [-o OUTPUT] [-x XML]
               [--encalgs ENCALGS] [--hashalgs HASHALGS]
               [--authmethods AUTHMETHODS] [--dhgroups DHGROUPS] [--fullalgs]
               [--ikepath IKEPATH] [-c CLIENTIDS]
               [target]

positional arguments:
  target                The IP address or the network (CIDR notation) to scan.

optional arguments:
  -h, --help            show this help message and exit
  -v, --verbose         Be verbose.
  -d DELAY, --delay DELAY
                        Delay between requests (in milliseconds). Default: 0
                        (No delay).
  -i INPUT, --input INPUT
                        An input file with an IP address/network per line.
  -o OUTPUT, --output OUTPUT
                        An output file to store the results.
  -x XML, --xml XML     An output file to store the results in XML format.
                        Default: output.xml
  --encalgs ENCALGS     The encryption algorithms to check. Default: DES,
                        3DES, AES/128, AES/192 and AES/256. Example:
                        --encalgs="1 5 7/128 7/192 7/256"
  --hashalgs HASHALGS   The hash algorithms to check. Default: MD5 and SHA1.
                        Example: --hashalgs="1 2"
  --authmethods AUTHMETHODS
                        The authorization methods to check. Default: Pre-
                        Shared Key, RSA Signatures, Hybrid Mode and XAUTH.
                        Example: --authmethods="1 3 64221 65001"
  --dhgroups DHGROUPS   The Diffie-Hellman groups to check. Default: MODP 768,
                        MODP 1024 and MODP 1536. Example: --dhgroups="1 2 5"
  --fullalgs            Equivalent to: --encalgs="1 2 3 4 5 6 7/128 7/192
                        7/256 8" --hashalgs="1 2 3 4 5 6" --authmethods="1 2 3
                        4 5 6 7 8 64221 64222 64223 64224 65001 65002 65003
                        65004 65005 65006 65007 65008 65009 65010"
                        --dhgroups="1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
                        18"
  --ikepath IKEPATH     The FULL ike-scan path if it is not in the PATH
                        variable and/or the name changed.
  -c CLIENTIDS, --clientids CLIENTIDS
                        A file (dictionary) with a client ID per line to
                        enumerate valid client IDs in Aggressive Mode.
                        Default: unset - This test is not launched by default.

Examples

Loading the hosts/ranges to scan from a text file and saving the results into a text and an XML file:

$ sudo python iker.py -i ips.txt -o output.txt -x output.xml -v

iker v. 1.0

The ike-scan based script which checks for security flaws in IPsec-based VPNs.

                               by Julio Gomez ( jgo@portcullis-security.com )

Starting iker (https://labs.portcullis.co.uk/tools/) at Mon, 20 Jan 2014 14:34:15 +0000
[*] Discovering IKE services, please wait...
10.0.0.2 Notify message 14 (NO-PROPOSAL-CHOSEN)
 HDR=(CKY-R=0000000000000000, msgid=f904f872)

[*] Trying to fingerprint the devices. This proccess is going to take a while (1-5 minutes per IP). Be patient...
[*] The device 10.0.0.2 could not been fingerprinted because no transform is known.

[*] Looking for accepted transforms at 10.0.0.2
[*] Transform found: Enc=3DES Hash=MD5 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080
[*] Vendor ID identified for IP 10.0.0.2 with transform Enc=3DES Hash=MD5 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080: Firewall-1 NGX

[*] Trying to fingerprint the devices (again). This proccess is going to take a while (1-5 minutes per IP). Be patient...
[*] Implementation guessed for IP 10.0.0.2: Firewall-1 4.1/NG/NGX
...

Specifying the encryption algorithms to check for supported transforms:

$ sudo python iker.py --encalgs "1 2 3 4 5 6 7/128 7/192 7/256 8" 10.0.2.2
[...]

Specifying that all the encryption algorithms, the hashing algorithms, the authentication methods and the DH groups must be checked:

$ sudo python iker.py --fullalgs 10.0.2.2
[...]

iker_v1.1.tar
July 17, 2014
Version: 1.1

40.0 KiB
MD5 hash: c255b6beffcf1e0a2026a9fd3faede8a
Details

Date:

July 17, 2014

The post iker appeared first on Portcullis Labs.

This point is also crucial for web applications because, computers and web browsers are frequently shared between people so it is important that this case cannot be exploited. Identifying when the user stops working with a web application and terminating the session reduces the window of opportunity that surrounds this type of attacks.

Although web applications should always include a “Log out” button, it is even naive to think that all the users are going to close their sessions when they finish to use a web application or before closing the tab/web browser where it was loaded.

Using JavaScript events

JavaScript allows to control an event which is fired at the moment of a browser window or a browser tab is closed. The name of this event is onbeforeunload. In fact, this event is fired before a page is unloaded, that includes: closing the tab, reloading the page, using the browser’s navigation buttons, click on a link…

The implementation of how the web browser acts when this event is launched depends on the web browser. In general, this event can be used to display a message box asking the user if he wants to close the current page. This message box contains two buttons to allow the user to choose between completing the action, closing the tab, or staying in the page.

So, in principle, it could be possible to detect when the user is closing the page and then send a request to the server with his confirmation. But the fact is that the majority of the web browsers do not return the control to the JavaScript interpreter before closing the tab; so it is not possible to send the request only in those cases that the user decides that he actually wants to close the tab (the event can always send a request before asking the user, but in few browsers will be able to do it after confirmation).

It was possible to check that Firefox returns the control to the JavaScript interpreter, but depending on the version, this only works when the page is reloaded, but not when a tab or the browser is closed (tested with versions 23 and 24). In the same way, Opera version 17 will send the logout request when the browser is closed, but not if the user closes is the tab. The rest of the tested browsers (Safari , IE and Chrome) did not send anything if the user confirmed the tab/browser closing.

The following code is an example about how to implement it:

<html>
<script src="http://code.jquery.com/jquery-1.10.2.min.js">

// Not using JQuery
/*
window.onbeforeunload = function () {
    return  "Are you sure want to LOGOUT the session ?";
};

// Used to logout the session , when browser window was closed
window.onunload = function () {
    $.get( "http://127.0.0.1/logout" );
};
*/

// Using JQuery
$(window).on('beforeunload', function() {
        return 'Are you sure want to LOGOUT the session ?';
});

$(window).unload(function() {
        $.get( "http://127.0.0.1/logout" );
});
</script>

<body>
  <h1><i>Unload</i> and <i>Beforeunload</i> example</h1>
  Please, reload, close this tab or close the browser to launch the test.
</body>
</html>

So, as you would be able to note, this is not a suitable solution to the original problem outlined at the start of this post.

Using AJAX ping

A better approach, because it should work in any web browser, is to reduce the session timeout configuration in the server to few minutes (2-5 minutes) and to ping the server regularly (15-30 seconds) with an AJAX request. The ping request will maintain the sessions life on the web server, preventing it from being timed out unintentionally. On the other hand, if the user closes the tab or the browser, the session will be terminated by the web server after the determined period.

The code below is a possible implementation of an AJAX ping using jQuery:

$(function() { window.setInterval("$.post('http://example.com/keepAlive');", 15000); });

This line should be included in every web page of the application, so it would be a good idea to create a file with it and include the file in the contents of every page served by the web serve.

With this solution, there are two problems:

• The server will need to be able to support the load of the ping requests which, depending on the number of users, could be thousands each minute. But an application which had that number of users should be able to support that load, so this is not a real problem.
• If the user leaves the application opened in a browser without supervision, the session will never time out.

The way to fix the second problem is to count the number of pings the server received without any other kind of request and to configure the application to close the session after the corresponding time (idle time). The time limit will need to be longer than the session timeout that has been configured, to avoid those cases of users who are using the application but staying in the same page for a while. For example:

Imagine that the session timeout was configured to 2 minutes and the delay between pings, 15 seconds. That means that after closing the browser, the session will remain live for 2 minutes maximum before being closed. That is a suitable period of time for the web server to wait before timing the session out because it will tolerate some network or connectivity problems which could in principal cause some of the pings to be lost (8 ping requests would have to be lost to close the session by mistake).

The major problem is the idle time, which will have to be configured depending on the kind of application. If the web application contains long articles, the idle time should be set to a longer period (5-10 minutes). If the application consists of small pages, then the idle time could be configured to the same as the session timeout (but never shorter).

By doing this, the application will cover:

• If the tab or web browser is closed, the session will be terminated after session time out (2 minutes in the example).
• If the users leaves the application unattended, the session will be closed after the idle time (at least as long as the session time out but no more than 10 minutes).
• While the user is working with the application, the session will be remain active.

A last improvement would be to use a variable time out. So it could be configured to the same period as the session time out in most cases but could also be increased for those pages which will take longer to read.

Editor’s note: If you enjoyed our two articles on how to improve session management, we’ve asked the author to put together a good practice guide detailing these and other practical steps that can be employed to help keep your users safe.

The post Improving the security in web sessions (part 2) appeared first on Portcullis Labs.

One way to complicate these types of attack, is for the web application to have the complete control of the user session. Typically web applications use a session token, normally in the form of a cookie, to identify sessions but they do not normally check anything else to verify the legitimacy of the session. So if an attacker can retrieve the token used by an authenticated user in some manner, usually the attacker can steal the victim’s session by sending the retrieved token within each request.

However, if the web application tightly controls the state of the user inside the application, it would be very difficult for an attacker to steal his session if the user is still interacting with it. Let me explain it with an example:

Imagine an application whose flow can be represented with the following diagram:

In the initial state, users would not be logged into the application and, until they do so, they will stay in that state. After a login to the application, they get access to the private area of the application where there are 3 different pages. From any of those pages, the user can finish their session by going to the logout page. Inside the private area, users only can browse the pages in the order: 1 -> 2 -> 3 -> 1 -> 2 … Any other interaction which is not represented by an arrow in the diagram would not be allowed (for example, going from 2 to 1).

In this context, each session could be represented by the usual session token and the state which the user is in. Doing that, if an attacker was able to retrieve the token in order to attempt to gain access to the application, they would try to access a random state which potentially wouldn’t correspond with any of the following valid states.

For example, if the legitimate user is in the state “Private Page 1″ at the moment of the attack, the only 2 possible next states are “Private Page 2″ and “Log out”. An attacker would need to know this and if they did not, the application could detect the attack and invalidate the session. It is true, that this can be done by exploiting other vulnerabilities, such as a Cross-site Scripting in the application, but if so, the application will store that the new user state is, for example “Private Page 2″. Therefore, when the legitimate user tries to get access to the next state (remember that they were actually in the “Private Page 1″ state), the application will detect the irregularity and will terminate the session.

Hence, although the attacker would be able to retrieve the token and to perform several requests by discovering the state of the user, the application will identify the problem if the user continues using the application and the states of the user and the attacker become desynchronised.

In this scenario, an attacker who successfully locates another suitable vulnerability in the web application (the XSS talked above) might be able to identify the state of the user, allowing them to retrieve the token and the state and to refresh the web browser of the user by changing the session token. By doing so, the attacker would be able to use the session but the user will detect that something weird happened as their session will likely be terminated.

To avoid this situation, the application should protect against the use of concurrent logins. So when the legitimate user logs in again, the application will detect the second session of the same user and will terminate both sessions.

A limitation of this solution is that legitimate users cannot have more than one tab in the same browser on the same application because each tab would be in different states causing the application to identify the scenario as a possible attack and terminate an otherwise legitimate session. Browsers’ navigation buttons (back and forward) would provoke the same eventualities because the user could change between states in the client side “bypassing” the control of the web application.

In order to implement this, the server side application would need to be designed like a state machine where all the relationships between the states are defined. The application will need, therefore, to store the current state of the user inside his session and to check that every request came from the current state and that it is addressed to any of the states which are accessible from the current.

The tokens used to mitigate Cross-site Request Forgery (CSRF) attacks could be used to check the state where the users come from. If the token received by the application with each request matches the token sent to the user previously, this means that the user is coming from a valid state. One of the problem with this approach is that all the requests will need to include the CSRF token (including GET requests) and most libraries do not allow this check for GET requests. Another problem of the usage of the CSRF token is that the solution implemented by many frameworks consists uses one unique token which is sent through all the application but which does not change between requests. In this instance, it would not be possible to differentiate between two different states.

A different approach could be to check the HTTP header “Referer” from each request. In this case, the state could be represented by the URL from where the user is navigating from (remember that this header cannot be trivially manipulated by using JavaScript – only the web browser has access to it). Alternatively, instead of the “Referer” header, an extra hidden field could be added in each form and link which saves the state and preserves it between requests.

Each approach has its benefits and its problems so probably a mixed solution would be better, using the CSRF to preserve the valid states between requests and checking the “Referer” HTTP header to check previous states.

So, summarising:

• Web session security can be improved by understanding web applications like a state machine and checking the state of each user in each request.
• Advantages: this approach prevents and/or complicate attacks to the session, such as session hijacking. Furthermore, it might complicate the usage of guessable/default accounts if another user is using it because concurrent sessions must be avoided.
• Disadvantages: users cannot use the application in different tabs and the interaction with it is limited to the actions offered in each page, rejecting the usage of web browsers navigation buttons.
• Two possible implementation consist of checking the “Referer” HTTP header and/or the CSRF token sent within each request.

In the next post, I will address another problem relating to web sessions management, how to identify when an user is no longer using the application, and how to close the session as soon as possible.

The post Improving the security in web sessions (part 1) appeared first on Portcullis Labs.