Kerio Vpn Control

[Lyric Maro]

Thekeyid type of keystring and set-id in the kerio vpnsetup has to match. If you re-set the key-id, flush the phase1 on both appliances. On the Kerio side just disable the von-tunnel and re-enable after 1min or so.

The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.

Hello HP team! Please, Can you help me to solve my problem? During the installation kerio control OS in HP, Bios mode leagacy hard driver not founded. Please, give me advise, how can i install with Bios mode leagacy than hard driver will be found?

I have setup my first kerio control as a web filter for our office/lab and were testing it but i am having serious issues even if followed all details dozen times again and again something isnt functioning blocking the sites i wanted to block.

This blog post describes two different attacks which can be used to compromise companies which use Kerio Control in their network. Kerio Control is a hardware appliance which can be used as network firewall, router and VPN gateway. Both attacks spawn a reverse shell on Kerio Control. Since both attack payloads are delivered via CSRF (cross site request forgery) or XSS (cross site scripting) no ports must be open from the Internet.

Kerio Control implements weak protections against these types of attacks which can be bypassed easily. Multiple critical security vulnerabilities have been identified by Ren Freingruber and Raschin Tavakoli of SEC Consult, which are documented in our technical security advisory.

The first attack vector heavily abuses two PHP scripts, both scripts are not referenced by any other file in Kerio Control and contain two different(!) seemingly deliberate(?) CSRF check bypasses. These two scripts contain multiple vulnerabilities which attackers need for establishing reverse root shells into company networks: Remote code execution with root privileges, CSRF check bypasses (makes it exploitable from the Internet), XSS (could be used to defeat SOP), vulnerable code exploitable for heap spraying (to defeat ASLR). Moreover, one additional script can be used to defeat ASLR which leaks heap and stack pointers.

This step itself is not based on a vulnerability, however, it is a mandatory step during the overall attack. First, the attacker tricks a victim (from the internal network of the attacked company) to visit his malicious website. The website then performs the complete attack. For this the website must know the internal IP address of Kerio Control. Therefore, the first action is to somehow identify and obtain this IP address.

This can easily be done by adding images on the website which point to an image stored on Kerio Control. The perfect target for this is the logo stored at :4081/nonauth/gfx/kerio_logo.gif. The attacker can add JavaScript event listeners for onload and onerror on his evil website to detect if the image was loaded or not. If the image was loaded, the attacker knows that the scanned IP address hosts Kerio Control.

For such an attack the attacker must know the internal IP range. This information can be obtained via different techniques (e.g. WebRTC leak, e-mail headers, misconfigured DNS server, information disclosure vulnerabilities on the website, social engineering) or can just be brute-forced (but this would add an additional delay to the overall attack).

For the first attack scenario at least a session as standard user is required (the second attack scenario requires that the victim is an administrator). The reason for this is that the vulnerability resides in code which can only be executed by authenticated users. Three situations can occur:

Situation one and two are perfectly valid and can be used to obtain a reverse shell. Situation three is a problem because a valid session is mandatory for the attack. In such a case the attacker can start a remote brute-force attack via CSRF to identify weak credentials. This is even possible if no ports are open from the Internet because the complete attack is conducted via the web browser of the victim and the victim is connected to the internal network.

One solution is to just assume that the credentials are valid and continue the exploit. If the exploit works, the credentials were valid. However, with this approach the complete attack would take too long and the victim may close the website before the attack finished.

A better solution is to use a side channel which bypasses SOP, namely image loading combined with JavaScript event handlers. This is possible because the URL to the user image only returns a valid image if the user is logged in. That means that the attacker can send a login request and after that embed an image pointing to :4081/internal/photo with JavaScript event handlers installed for onloadand onerror. If the onerrorevent handler triggers, the credentials were wrong, if the onloadevent handler triggers, the credentials were valid.

In the case of the two scripts the CSRF protections must be bypassed, but it turns out, that this is trivial as well. The most common method is to use a XSS vulnerability, but for the first attack vector we will use another technique (the XSS technique will be described when discussing the second attack vector). Now we are going to directly exploit the vulnerable PHP code of Kerio Control.

The problem with the above code is, that the code is PHP code. Luckily for us, sadly for the programmer, the code is not JavaScript code which means that it has a completely different behavior than the programmer may have intended (except if it was deliberately backdoored). At line 2 the programmer wants to get either the GET or POST parameter k_securityHash, but is a logical operator in PHP. The result is therefore either the boolean value trueor false. At line 3 the programmer compares this result against the correct security hash (p_securityHash). The comparison is done by != , however, in PHP the operator != applies type juggling first (loose comparison). Correct would be a strict comparison via !==.

If we set k_securityHash to any value (either in GET or POST), we compare the boolean value truewith a string. PHP will then interpret the string as boolean which is always trueand then conclude that trueequals truewhich means the check will always be bypassed if we set k_securityHashto any value.

Until now everything works as expected. If we want to get the value 888 we have to update the reference to R:2, for 999 the reference R:3 must be used. But what happens if we use two times the same value?

We still have a problem with the above code. It only frees the ZVAL (=16 bytes of data describing the variable). We want to fully control this ZVAL, but for this the data is too small (if we for example allocate a string later, the string content will not be allocated over the freed data, instead the ZVAL of the string will be allocated over it). That means we have to free a variable which consumes more size than an integer. For this we have two possibilities: An array with additional elements or an object with member variables.

So the logical solution is to use objects instead. The hash of an object is calculated based on the object handle (a number incremented per object) and the object handler (a pointer to function pointers of the object).

The next step is to control the content of the ZVAL. For demonstration we changed the ZVAL type to a string (type 6) and let the string point to the image base of PHP where the ELF-magic value is stored:

The content of the string now describes the referenced ZVAL, the last bytes specify the type (0x06 = string), the first DWORD (0x08048001) is the base address of the string, the second DWORD is the length of the string (0x03), the third DWORD is the reference counter which is in this case 0x01.

This vulnerability can be used to read the complete memory space and therefore to bypass ASLR. However, in the case of Kerio Control the result of the unserialize function is not reflected back to the attacker (moreover, because of SOP we would not be able to read the output, an additional XSS vulnerability would be required for this).

The exploit must therefore be written fully blind (and a way to bypass ASLR is required). The code execution step is trivial; the data type must only be changed from string (0x06) to object (0x05) to control the object function pointers.

The last missing step is to bypass ASLR. A solution would be to turn the vulnerability into a write4 vulnerability (that means that we get the possibility to write 4 chosen bytes to a chosen memory location). Then we can for example overwrite the base address or length field of a string or overwrite a function pointer to point to another location (e.g. change the function address of a function called on the unserialize output to var_dump() to reflect the output back to the attacker).

In addition to the described attack vector above a second method exists to spawn a reverse root shell. This attack vector has the pre-condition that the attacked user is logged in as administrator. The likelihood for a successful attack is therefore low, but this attack works without exploitation of a memory corruption vulnerability and is therefore simpler.

The administrative interface contains functionality to upload an upgrade image. No checks are performed on the uploaded file. The included bash script will just be executed with root privileges. This vulnerability was already reported and published by Raschin Tavakoli on 2015-10-12 and is still unfixed (more information can be found in the original advisory at -db.com/exploits/38450/). Only the used XSS vulnerability was fixed by Kerio.

The upgrade functionality is protected by a CSRF check which is correctly implemented. A XSS vulnerability is therefore required to bypass the check. To demonstrate that the vulnerability still exists SEC Consult searched for two different XSS vulnerabilities to demonstrate the attack.

3a8082e126