Labs Research

Kentico CMS 5.5 R2 Critical Vulnerability

The Obrela LABS Team — Mon, 08 Mar 2021 00:00:00 GMT

Anastasios Stasinopoulos from Obrela LABS team discovered a critical risk vulnerability that affects Kentico CMS, a popular ASP.NET web content management system that is used to build websites, online stores and Web 2.0 community sites.

More specifically, Kentico CMS 5.5 R2 build 5.5.3996 was found vulnerable to SQL injection attacks on a specific parameter, allowing a potential attacker – without requiring authentication – to interact with the backend Microsoft SQL server database.

Successful exploitation of this vulnerability allows unauthorized access/modification/deletion of the stored data in the backend database and if specific conditions are met can be also leveraged to complete compromise of the underlying operating system that hosts Kentico.

The software vendor has been informed by Obrela LABS prior to public disclosure of the vulnerability which was registered afterwards with a CVE record: CVE-2021-27581 .

According to software vendor response it is advised to update Kentico CMS to the latest version that is not vulnerable to this security flaw.

The vulnerability was exploited using the sqlmap tool:

Vulnerable parameter: tagname
Type: time-based blind sql injection
Sample payload: tagname=test’+(SELECT CHAR(118)+CHAR(103)+CHAR(85)+CHAR(89) WHERE 1718=1718 AND 6176=(SELECT COUNT(*) FROM sysusers AS sys1,sysusers AS sys2,sysusers AS sys3,sysusers AS sys4,sysusers AS sys5,sysusers AS sys6,sysusers AS sys7))+’&groupid=1

Discovery and public disclosure timeline

2021-02-22 – Discovery
2021-02-23 – Vendor Contact
2021-02-23 – Vendor Triaged Vulnerability
2021-02-23 – MITRE Assigned CVE

Client Side Penetration Testing – T&T Part 1

No Author — Fri, 12 Feb 2021 00:00:00 GMT

Most client-side attacks are based on delivering emails to the target, nevertheless by underestimating the need to build an adequate “trust level” towards the target, there’s a fair chance that the exercise will fail even at this early state. Below we will begin by listing some techniques, considerations, and tips on how to successfully deliver emails and establish this “trust level”.

SMTP in general

SMTP servers which are flagged as the MX for each domain, by design, accept connections by any system on the internet and relay the messages to their users. The term “system” does not imply mail servers, so the “system” does not have to be a mail server necessarily. Anyone may connect to this type of SMTP server at port 25 using a client (Outlook, Thunderbird or even telnet) and send a message directly to its domain(s) users. Unless this SMTP server is an open relay (very rare nowadays) messages can be relayed only to users of the domain(s) it serves, any other attempt to send messages to other domains will be rejected.

MX enumeration

As a first step the target’s MX server that is responsible for email relaying, has to be identified. This can be done easily by querying any DNS server for the target’s MX records:

$ host -t mx target.com target.com mail is handled by 20 mx2.target.com.

target.com mail is handled by 10 mx1.target.com.

Mail spoofing techniques

Obviously, the chances that an email will seem legitimate are increased dramatically if the sender email address is spoofed to an email address which belongs to the target’s domain. The sender address is declared in two fields.

The “MAIL FROM” SMTP command that is in fact used as “Bounce To” address in order to reach the sender in case of delivery failure
The message header “From: “ (e.g. From: “Spoofed” ) that defines the address that will shown as sender at target’s mail client

During usual email communication using clients like Outlook, Thunderbird, etc. the user cannot control these fields directly. Both are filled by the mail client with the email address that was defined upon user account creation.

MAIL FROM command

Below we describe how to detect errors and blocking mechanisms when using the MAIL FROM command in order to spoof the target’s email. Telnet or a similar program should be used in order to quickly and correctly identify such mechanisms. After target enumeration, the actual spoofed emails can be sent by any email client properly configured to send email directly to target’s MX server.

Since there are several mechanisms that will block the spoofed “MAIL FROM”, the most important part is to check if the email has reached the target.

The message can be relayed from any SMTP server to reach the target’s MX. The reason we choose directly the target’s MX to communicate with, is that we will have strong indications if our message is rejected (due to blocking technologies that are mentioned below) through error messages that would not otherwise be visible (if an intermediate SMTP was used to relay the message).

An example SMTP communication with target’s MX server with telnet is demonstrated below.

$ telnet mx1.target.com 25 Connected to mx1.target.com. Escape character is '^]'. 220 mx1.target.com ESMTP - Welcome HELO test 250 mx1.target.com says HELO to [xxx.xxx.xxx.xxx:xxxx] MAIL FROM: 250 2.1.0 Ok RCPT TO: 250 2.1.5 Ok DATA 354 continue. finished with "\r\n.\r\n" Date: Fri, 1 Aug 2014 11:12:29 +0300 From: Spoofed User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Target >> Target" Subject: Email subject Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Email message .

250 2.0.0 Ok: queued as XX/XX-XXXXX-XXXXXXXX

Observe for error responses. Below are some examples of rejected attempts:

Mail server rejects spoofed sender
```
Error msg: 
      
      
```

Sender IP blacklisted:

Error msg: 554 Client host [xxx.xxx.xx.xx.xx] blocked using spam.target.com=[xx.xx.xx.xx] Spamhaus PBL. Please visit http://www.spamhaus.org/lookup/ for more information on why this message could not be delivered

“From: ” header

If the above technique fails due to rejected MAIL FROM from a legitimate served domain email address (MX has no reason to accept messages from the domain users it serves, the latter should be done by another SMTP that uses authentication), then we may possibly trick the MX server with a MAIL FROM from a random email address e.g. me@gmail.com, but forge the “From:” header. Using the “From: “ header in order to spoof the sender addresses when sending an email might fail without producing any errors. Thus, it is proposed only if the previously described technique has failed. Below we demonstrate this technique using a telnet client. We may use command line email clients, which are easier to use, that will accept the data section of an email through a given file.

250 2.0.0 Ok: queued as XX/XX-XXXXX-XXXXXXXX

Blocking technologies

Sender Policy Framework (SPF)

Since SMTP itself does not have a way to verify that the address that is used in MAIL FROM command is the real one, SPF (ref. Wikipedia https://en.wikipedia.org/wiki/Sender_Policy_Framework) fills that gap but only for the MAIL FROM command and not the From header of message. The following demonstrates a domain that advertises SPF:

$ dig +short TXT target.com

"v=spf1 ip4:XXX.XXX.XXX.X/XX a mx ?all"

Note: It’s not in scope of this article to fully explain how to correctly setup SPF, but an important thing to remember is that the MX SMTP server must be configured to honor SPF records, even for the domain(s) it serves.

DomainKeys Identified Mail (DKIM)

As mentioned already, SPF does not verify message content. To overcome this limitation DKIM (ref. Wikipedia https://en.wikipedia.org/wiki/Dkim) is utilized that signs the message to confirm its origin.

MS Exchange reject spoofed domain emails

MS Exchange can be configured to prevent spoofed emails which target authoritative domain(s) by removing the “ms-exch-smtp-accept-authoritative-domain-sender” permission assigned to MX SMTP servers. For further information follow the link (the configuration is still the same for newer versions of MS Exchange, like 2010 and 2013)

Tips

Mail servers may reject messages from systems without a FQDN.
Messages from dynamic IPs will likely be rejected because there is common practice to include dynamic IP ranges to spam-lists to prevent spam.
Do not attach executables to emails because they will likely blocked
Many mail servers block password protected archives too for obvious reasons

OpenMediaVault Remote Code Execution (RCE) Vulnerability

Anastasios Stasinopoulous — Wed, 04 Nov 2020 00:00:00 GMT

Abstract

On this article we will be focused on the identification and exploitation of CVE-2020-26124 [1], a remote code execution (RCE) vulnerability affecting OpenMediaVault [2],on specific versions before 4.1.36 and 5.x before 5.5.12.

Introduction

OpenMediaVault is a free Linux distribution designed for Network-Attached Storage (NAS) that offers services like SSH, (S)FTP, SMB/CIFS, DAAP media server, RSync, BitTorrent client and many more. OpenMediaVault is based on the Debian operating system, and is licensed under the GNU General Public License v3 while project’s lead developer is Volker Theile, who instituted by the end of 2009.

Vulnerability Details

Our research began on 2020-09-26, when we initially installed the (latest till then) version 5.5.11-1 of OpenMediaVault, which is freely available for downloading though SourceForge [3], on a virtual machine in our lab. After the successful installation and setup of OpenMediaVault, we logged in to the web-based provisioning GUI, using the default administrative credentials (i.e. username:”admin” and password:“openmediavault”).

Trixbox CE RCE Vulnerability Case Study

Anastasios Stasinopoulos — Mon, 18 May 2020 00:00:00 GMT

1. Intro

The Asterisk PBX and more specifically the Asterisk web-based provisioning GUI interface often stands as a primary target during a Penetration Test, due to its promising potential in case of compromise.

During this case-study we will be focused on Trixbox CE which is the Community Edition of Trixbox (formerly Asterisk@Home), an easy to install VOIP phone system based on the Asterisk PBX. Trixbox CE is a completely free and open-source software available under a GPLv2 license with over two million downloads as of August 22, 2009.

It is important to note that in October 2012, Fonality announced that they would no longer support and/or update Trixbox CE, and would instead focus on Trixbox Pro, the commercial version of Trixbox.

2. Trixbox CE 2.8.0.4 Exploitation: From Zero to Herο

2.1 Installation and Lab Setup

In order to perform the assessment against Trixbox CE, we installed the latest version of Trixbox CE v2.8.0.4 ISO [1] on a virtual machine, which is available for downloading via SourceForge.

Trixbox CE’s core technologies include:

The Linux distribution on which Trixbox CE is built (i.e. CentOS).
Asterisk which provides the core PBX functionality.
FreePBX which provides a web-based provisioning GUI interface for managing and configuring Asterisk through a web browser.
Flash Operator Panel (FOP) which provides a graphical overview of current calls and provides controls to operators.

After the successful installation of the Trixbox CE v2.8.0.4 ISO on a virtual machine on our lab, we logged in to the Trixbox CE web-based provisioning GUI interface, using the default administrative credentials “maint:password”.

2.2 Identification and Exploitation of CVE-2020-7351

Through the main administrative menu, we navigated to a functionality (“PBX -> End Point Configuration”) which maps network devices on a user-defined subnet.

BadRabbit Ransomware Attack

The Obrela LABS Team — Wed, 13 Jun 2018 00:00:00 GMT

A new ransomware campaign by the name BadRabbit has targeted Russia, Turkey, Ukraine, Bulgaria, Japan and other countries.

Bypassing Insufficient Blacklisting

No Author — Fri, 23 Feb 2018 00:00:00 GMT

Bypassing insufficient blacklisting: Brief introduction

Operating system (OS) command injection attack is a variant of code injection attacks which are considered a major security threat that in fact, is classified as No. 1 on the 2013 OWASP top ten web security risks [1]. There are many types of code injection attacks including:

SQL injection [2]
Cross Site Scripting [3]
OS command injection [4]
XPath injection [5]
LDAP injection [6]

OS command injection attacks may occur in applications that accept user provided input and execute OS commands using as parameters the received input. They have been discovered in web applications hosted in web servers (Windows or Linux) as well as in web-based management interfaces of networking devices, such as home/office routers, IP cameras, IP PBX applications and network printers. Moreover, command injection vulnerabilities can be found in IoT devices. However, the injected OS commands are usually executed with the same permissions that the application possesses (i.e. root). OS command injection attacks are possible in most cases due to lack of correct input data validation, which can be manipulated by the attacker (web forms, cookies, HTTP headers etc.)

Detecting and exploiting command injection flaws

Due to the fact that there are not many tools to automate the process of detecting and exploiting command injection vulnerabilities, in this blog post Commix tool will be used. Commix (a short for [COMM]and [I]njection e[X]ploiter) is an automated tool aiming to facilitate web developers, penetration testers and security researchers to test web applications with the view to find bugs, errors or vulnerabilities related to command injection attacks. It is important to note that the module is capable of performing command injection not only in the HTTP GET / POST parameters, but also in HTTP parameters, such as HTTP cookie, HTTP user-agent and referrer header values. The tool is written in Python (version 2.6. or 2.7) and runs in both Unix/Linux and Windows operating systems. Commix is free to download through the GitHub repository [7]. It is worth mentioning that Commix comes preinstalled in many security-oriented OS’s including the well-known Kali Linux [8], while its capabilities have been presented in the BlackHat Europe 2015 Security Conference (Netherlands, Amsterdam) [9].

Attack scenarios and lab setup

The main objective of this article is to examine the detection and exploitation capabilities of Commix against blacklisting techniques. The general idea behind blacklisting is to check for malicious patterns before allowing the execution of users input. More specifically, in the case of OS command injection attack, a blacklist can strip out from the users’ input all “suspicious” characters (i.e. “;”,”|”,”&”, etc.). However, a basic disadvantage of blacklisting, which greatly limits its effectiveness, is that the attacker can discover a variation of the command injection attack vectors not included in the blacklist and, hence, he can launch the attack successfully. In order to be able to get a reliable sample of checks against the most common blacklisting techniques, the Damn Vulnerable Web Application (DVWA) v1.10 [10] was installed on a Debian Linux (3.16.0-4) operating system. DVWA is a free, open source PHP/MySQL web application that supports four different security levels, low, medium, high or impossible. The security level changes the vulnerability level of DVWA:

Low: This security level is completely vulnerable and has no security countermeasures at all. Its use is to be as an example of how web application vulnerabilities manifest through bad coding practices and to serve as a platform to teach or learn basic exploitation techniques.
Medium: This setting is mainly to give an example to the user of bad security practices, where the developer has tried but failed to secure an application. It also acts as a challenge to users to refine their exploitation techniques.
High: This option is an extension to the medium difficulty, with a mixture of harder or alternative bad practices to attempt to secure the code. The vulnerability may not allow the same extent of the exploitation, similar in various CTF competitions.
Impossible: This level should be secure against all vulnerabilities. It is used to compare the vulnerable source code to the secure source code. (Prior to DVWA v1.9, this level was known as ‘high’).

DVWA also comes with an outdated (v0.6) Web Application Firewall (WAF) called PHPIDS. PHPIDS (PHP-Intrusion Detection System) [11] is a security layer for PHP based web applications. PHPIDS works by filtering any user’s supplied input against a blacklist of potentially malicious code. It is used in DVWA to serve as a live example of how WAFs can help improve security and in some cases how WAFs can be circumvented. At this point it is worth noting that during this research, the latest stable version (v0.7) [12] of PHPIDS was installed in DVWA.

All the experiments were mainly conducted in two separate rounds of checks:

In the first round of security checks, attacks were attempted at all security levels of DVWA without the PHPIDS WAF being activated.
In the second round of security checks, exactly the same attacks were attempted as the first set of checks, but with the PHPIDS WAF enabled during the detection and exploitation procedure.

Detection and exploitation results

It is summarized below, the detection and exploitation results of the first and the second round of security checks that were conducted against the vulnerable “ip” POST parameter of “/vulnerabilities/exec/” in DVWA against all* supported security levels (from Low to Impossible).

* On both rounds of security checks, in the “Impossible” security level, Commix did not detect any vulnerability (as expected) because this level is not meant to be exploitable.

1^st Round of checks: PHPIDS 0.7 WAF disabled (Table 1):

Regarding the “Low” and “Medium” security levels, Commix successfully identified and exploited the command injection vulnerability with every supported exploitation technique.
Finally, in the “High” security level, although more strict security measures – in order to secure the code – were applied (i.e., better characters blacklisting) Commix successfully identified and exploited the command injection vulnerability using file-based exploitation technique.

	RESULTS-BASED	TIME-BASED	FILE-BASED	TEMPFILE-BASED
LOW	PASSED	PASSED	PASSED	PASSED
MEDIUM	PASSED	PASSED	PASSED	PASSED
HIGH	FAILED	FAILED	PASSED	FAILED
IMPOSSIBLE	FAILED	FAILED	FAILED	FAILED

Table 1: Succeeded command injection attacks with PHPIDS disabled.

2^nd Round of checks: PHPIDS 0.7 WAF enabled (Table 2):

Concerning the “Low” and “Medium” security levels, Commix successfully identified and exploited the command injection vulnerabilities using results-based and file-based exploitation techniques.
Also, in “High” security level, Commix successfully identified and exploited the OS command injection vulnerabilities using the file-based exploitation technique.

	RESULTS-BASED	TIME-BASED	FILE-BASED	TEMPFILE-BASED
LOW	PASSED	FAILED	PASSED	FAILED
MEDIUM	PASSED	FAILED	PASSED	FAILED
HIGH	FAILED	FAILED	PASSED	FAILED
IMPOSSIBLE	FAILED	FAILED	FAILED	FAILED

Table 2: Succeeded command injection attacks with the PHPIDS enabled.

Lastly it is worth mentioning that, even though the remote command execution protection filter that is used by the PHPIDS v0.7 to prevent remote OS command injection attacks seems quite weak (on this we will refer later) specific characters (i.e “$”, “{“,”}”,”))” etc) which are used in most payloads were detected. After further analysis on that issue it was identified that this happens due to overlays by other irrelevant WAF filters. In order to circumvent this restriction the “–backticks” switch (which uses the backtick (`) instead of the “$()” for command substitution [13]) was used.

Analyzing the weak filter of PHPIDS v0.7

As it has been already mentioned, PHPIDS 0.7 does not protect against OS command injection attacks. The filter that is used for protection against this type of attacks is included in the “default_filter.json” and “default_filter.xml” files. More specifically the filter with id “74” checks only for attempts to execute OS commands, such “ping -n 3 127.0.0.1 ”, ping localhost -n 3” etc as presented below:

ping(.*)[\-(.*)\w|\w(.*)\-]

Moreover, we came to the point to suggest an additional regular expression for the aforementioned filter in such way all the attempted payloads have failed due to all the symbols used for OS command injection attacks are now being detected and blocked by the newly proposed filter:

(?:[^|;|&|\||\<|\>|`|\$|\(|\)|\{|\}]\W*?\b)

Finally, the Table 3 below represents all the failed attempts to detect and exploit OS command injection vulnerabilities against the vulnerable “ip” POST parameter of “vulnerabilities/exec/”, after the new rule has been added.

	RESULTS-BASED	TIME-BASED	FILE-BASED	TEMPFILE-BASED
LOW	FAILED	FAILED	FAILED	FAILED
MEDIUM	FAILED	FAILED	FAILED	FAILED
HIGH	FAILED	FAILED	FAILED	FAILED
IMPOSSIBLE	FAILED	FAILED	FAILED	FAILED

Table 3: Failed command injection attacks after PHPIDS updated filter

Conclusions

Concluding all the above, this article was mainly focused on the weak blacklisting features, as provided by all security levels of DVWA, combined with the latest stable version of the PHPIDS WAF. Once it was identified that Commix was able to bypass the weak blacklisting filters on each security level (i.e. Low, Medium, and High) with the presence of the latest stable PHPIDS WAF, a new rule (that successfully blocks all the exploitation attempts) was proposed.

References

Undetectable Metasploit WAR

No Author — Tue, 04 Oct 2016 00:00:00 GMT

A possible attack path during a penetration test is having access to the administrative console of a JAVA Application Server (like WAS, JBOSS and Tomcat) installed on a Windows server with default or guessable (e.g. through brute-force) administrative credentials.

Vulnerability in Windows http.sys Could Allow DOS or Remote Code Execution

No Author — Tue, 14 Apr 2015 00:00:00 GMT

Yesterday Microsoft has patched a critical vulnerability in Windows HTTP stack (http.sys), which would have extreme consequences if an exploit is publicly disclosed.