Shulou(Shulou.com)05/31 Report--

This article is about how to deeply analyze Citrix ADC remote code execution RCE vulnerability CVE-2019-19781. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article. Let's take a look at it.

At the end of 2019, Citrix ADC and Citrix Gateway were exposed to a high-risk vulnerability CVE-2019-19781 for remote code execution. The most attractive aspect of this vulnerability is that unauthorized attackers can use it to invade and control Citrix devices and achieve further access to intranet resources. Vulnerabilities are discovered and reported by security teams Positive Technologies and Paddy Power Betfair, but there are not too many ways to exploit vulnerabilities in the vulnerability announcement, so this is worthy of in-depth study.

Loophole analysis

Although the details of the exploit are not disclosed in the Citrix official vulnerability announcement, the relevant types of the vulnerability are revealed from the vulnerability mitigation measures:

From the above mitigation information, we determine that the possible path to the vulnerability is / vpns/, and that it may be a directory traversal vulnerability. With these clues, we began to look for the path / vpns definition method in the httpd.conf file, and then found that the NetScaler::Portal::Handler Perl Module (Handler.pm) module was responsible for generating some method definitions in the / vpn/portal/scripts/ directory.

Some script files are included under / vpn/portal/scripts/, and since we previously determined that the cause of the vulnerability was directory traversal, we focused our analysis on the code paths with file writing operations. After that, we found the following code in the UsersPrefs script in the perl module:

Sub csd {my $self = shift;my $skip_read = shift | | "; # Santity Checkmy $cgi = new CGI;print" Content-type: text/html\ n\ n "; / / Username variable initialized by the NSC_USER HTTP Headermy $username = Encode::decode ('utf8', $ENV {' HTTP_NSC_USER'}) | | errorpage (" Missing NSC_USER header. "); {username} = $username;...$self- > {session} =% session / / Constructing the path from the username.$self- > {filename} = NetScaler::Portal::Config::c- > {bookmark_dir}. Encode::encode ('utf8', $username). '.xml'; if ($skip_read eq 1) {return;}

In short, the above code is used to build a path from the user-related NSC_USER HTTP header, but there is no security check in the process, resulting in a directory traversal vulnerability that can be triggered with any script that calls the csd method. After analysis, it is found that all scripts under / vpn/portal/scripts/ will call the csd method function, but one of the script files, newbm.pl, is special:

My $cgi = new CGI;print "Content-type: text/html\ n\ n"; my $user = NetScaler::Portal::UserPrefs- > new (); my $doc = $user- > csd ();... my $newurl = Encode::decode ('utf8', $cgi- > param (' url')); my $newtitle = Encode::decode ('utf8', $cgi- > param (' title')); my $newdesc = Encode::decode ('utf8', $cgi- > param (' desc')) My $UI_inuse = Encode::decode ('utf8', $cgi- > param (' UI_inuse'));... my $newBM = {url = > $newurl,title = > $newtitle,descr = > $newdesc,UI_inuse = > $UI_inuse,};.

Newbm.pl first creates an array containing various parameter information, and then calls the filewrite method to write the information in the array to a XML file:

If ($newBM- > {url} = ~ / ^\ /) {push @ {$doc- > {filesystems}-> {filesystem}}, $newBM;} else {# bookmarkpush @ {$doc- > {bookmarks}-> {bookmark}, $newBM;} / / Writing XML file to disk$user- > filewrite ($doc)

In theory, we can control the file path or the contents of the XML by constructing some write commands, but nothing works here. After that, we read what you need to know about CVE-2019-19781 written by security researcher Craig Yong, which specifically mentions the use of Perl Template Toolkit template tools to exploit vulnerabilities.

After in-depth study, we found that we can insert some specific instructions in the XML file, and if these instructions are parsed by the template engine, the command execution can be triggered. The following is an example of command execution after the template engine parses test.xml:

To sum up, we now have Perl Template Toolkit as a way to insert instructions for file writing, but we also need a way for a script to force the template to parse. After that, we found that Handler.pm can be used to implement template parsing in the template reference code:

The variable $tmplfile is built from HTTP Request Path, and a new template is generated later to process the $tmplfile variable file. Now, put the test.xml test file we created earlier into the template directory and trigger the template parsing behavior to see:

In summary, the following steps are required for successful exploitation:

1. Discover the way to execute Perl code through the template mechanism (need to bypass)

2. Use directory traversal to insert a constructed XML file under the template directory.

3. Browse the placed XML file, trigger template parsing, and realize the code execution in XML.

The key point is that the arbitrary code execution in the last step, in the original default Citrix configuration, can not achieve code execution, only after a feature configuration can achieve Perl code execution. Previously, considering the number of Citrix devices affected by the vulnerability, and several teams have weaponized the vulnerability, we did not provide the exploit code for this vulnerability, but later, with the disclosure of the vulnerability and the disclosure of the exploit of multiple security researchers, we also chose to publish specific exploit methods.

First method: remote code execution that can be caused by template injection

There are two ways to implement code execution, the first of which is the BLOCK template injection method currently used in most public exploit. We found this bug submitted by other users in Perl Template Toolkit's GitHub, and it is this bug that can be exploited here:

The method of executing arbitrary perl code is introduced in the bug question. At present, it seems that this method is used in all public exploit to implement arbitrary command execution in the above vulnerabilities. Let's take a closer look at the specific implementation of this exploitation method in the vulnerability.

According to the document description of Perl Template Toolkit, the template variable is a special variable, and an object reference pointing to the main template is included in the call process. The object type here can be printed and displayed by the print method, which is Template::Document:

Once you have this object reference, you can call the method with controlled parameters. By studying the class-like code, we find that we can successfully call the new method by combining the above features:

# new (\% document) # # Creates a new self-contained Template::Document object which# encapsulates a compiled Perl sub-routine, $block, any additional# BLOCKs defined within the document ($defblocks Also Perl sub-routines) # and additional $metadata about the document.#----sub new {my ($class, $doc) = @ _ My ($block, $defblocks, $variables, $metadata) = @ $doc {qw (BLOCK DEFBLOCKS VARIABLES METADATA)}; $defblocks | | = {}; $metadata | | = {}; # evaluate Perl code in $block to create sub-routine reference if necessaryunless (ref $block) {local $SIG {_ _ WARN__} =\ & catch_warnings;$COMPERR ='; # DON'T LOOK NOW!-blindly untainting can make you go blindfolded blocks = each% {{$block = > undef}} if ${^ TAINT}; # untaint$block = eval $block;return $class- > error ($@) $unless defined }

The new method can get the parameters in the BLOCK template and call the eval method, thus achieving arbitrary perl code execution. In addition, we also find that the same attack effect can be achieved by using another method, component.

The second method: command injection in DATAFILE plug-in

In the method call security analysis of the source code, we found the following code in the DATAFILE plug-in:

Sub new {my ($class, $context, $filename, $params) = @ _; my ($delim, $line, @ fields, @ data, @ results); my $self = []; local * FD;local $/ = "\ n"; $params | = {}; $delim = $params- > {'delim'} | |':'; $delim = quotemeta ($delim); return $class- > fail ("No filename specified") unless $filename;open (FD, $filename) | return $class- > fail ("$filename: $!") # first line of file should contain field definitionswhile (! $line | | $line = ~ / ^ # /) {$line =; chomp $line;$line = ~ s /\ rpm;} sub new {my ($class, $context, $filename, $params) = @ _; my ($delim, $line, @ fields, @ data, @ results); my $self = []; local * FD;local $/ = "\ n"; $params | = {}; $delim = $params- > {'delim'} | |':'; $delim = quotemeta ($delim) Return $class- > fail ("No filename specified") unless $filename;open (FD, $filename) | | return $class- > fail ("$filename: $!"); # first line of file should contain field definitionswhile (! $line | | $line = ~ / ^ # /) {$line =; chomp $line;$line = ~ s /\ rimpulse;}

If you have experience in perl code auditing, you will understand that it is not safe to use the above open function with only two parameters to open a file for operation. If you add the pipe command |, the open function will interpret the rest of it as a command call, and since we can control the file name variable $filename, we can use this method to implement command execution.

By constructing a template file, after invoking the DATAFILE plug-in, you can cause arbitrary command execution, as follows:

You can see that the command in the construction file successfully created the expected / tmp/COMMAND_INJECTION/ directory:

A variety of exploit emerged after the vulnerability was discovered and disclosed, but as Craig Yong said in the article, "it is important to note that some Payload can cause Citrix NetScaler to overrecord errors until it fills up the / var partition." You can click here to get the Exploit exploit code.

Vulnerability repair

At present, Citrix has announced detailed vulnerability mitigation measures, including specific implementation steps, and we suggest that Citrix ADC users refer to this measure in time to fix it.

In addition, if an external POST request against a device involves a "/ vpns/" and "/.. /" style string followed by an GET request to the xml file, it can be directly judged as an exploit.

The above is how to in-depth analysis of Citrix ADC remote code execution RCE vulnerability CVE-2019-19781, the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.