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. The second attack vector doesn’t use a memory corruption vulnerability, instead we use a publicly known vulnerability in Kerio Control which has not been fixed in the past 12 months (reported by Raschin Tavakoli, now employee at SEC Consult). The full exploit is publicly available on exploit-db ( ), only the used XSS (cross site scripting) vulnerability was fixed. To demonstrate that the issue still exists we searched for two other XSS vulnerabilities to turn the XSS vulnerabilities again to a remotely exploitable reverse root shell. However, this attack has the pre-condition that the attacked victim is currently logged in as administrator (or that we can obtain administrator credentials via the brute-force attack). Kerio’s response to this reported vulnerability (and to the vulnerability that the webserver is running with root privileges) was: “I do not consider this a vulnerability”. We have just discovered another XSS 0-day vulnerability which can again be used to obtain a reverse root shell on the most current Kerio Control system (version 9.1.3 build 1408). We have contacted the vendor again regarding this issue. It’s also important to note, that the first attack scenario was not fixed by updating the 6-year-old PHP binary, instead only the problem of unserialize was fixed superficially. Remote Identification Of Kerio Control Systems Kerio Control still uses PHP version 5.2.13. 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.Ī simple JavaScript scan script is shown below: for (i = 1 i :4081/internal/photo with JavaScript event handlers installed for onloadand onerror. The following HTML code demonstrates this: If the onerrorevent handler triggers, the credentials were wrong, if the onloadevent handler triggers, the credentials were valid.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |