Widevine Trusted Application (TA) 5.0.0 through 5.1.1 has a drm_verify_keys total_len+file_name_len integer overflow and resultant buffer overflow.

CVE-2022-48334:

Buffer Overflow in Widevine Trustlet (drm\_verify\_keys @ 0x7370)

 

CVE:

CVE-2022-48334

Vendor:

Google

Device:

Nexus 6

Affected Component:

Widevine

Publication Date:

March 2023

Credits:

CyberIntel Team

Last edited: 11/04/23

**1\. Description**

This entry describes a vulnerability that we found in the Widevine Trusted Application (TA), which runs within Qualcomm’s Secure Execution Environment (QSEE). The vulnerability is an integer overflow that leads to a subsequent buffer overflow. This bug has been found using tools we have developed to assist in the security evaluation of TrustZone, including a debugger and a coverage-based fuzzer for QSEE TAs. Please, refer to this page for further information.

Qualcomm Secure Execution Environment is one of the most widespread commercial TEE solutions in the smartphone space, used by many different devices such as Xiaomi, Motorola and several devices of the Google Nexus and Pixel series.

Widevine is a Digital Rights Management (DRM) technology developed by Google to protect copyrighted content and to enable secure distribution and consumption of video and audio content. The technology involves encryption, licensing, and key management to ensure that content can only be decrypted and played back on authorized devices.

An attacker could potentially exploit the vulnerability in the Trusted Application by sending a command from the Normal World, causing the application to crash and possibly execute arbitrary code. This vulnerability could have potential consequences, such as elevating attacker’s privileges and exposing sensitive information.

This post is part of a series of related bugs affecting Widevine Trusted Application of Google Nexus 6:

> *   CVE-2022-48331
>     
> *   CVE-2022-48332
>     
> *   CVE-2022-48333
>     
> *   CVE-2022-48334
>     
> *   CVE-2022-48335
>     
> *   CVE-2022-48336
>     
> *   CVE-2015-6639
>     
> *   CVE-2015-6647
>     

**2\. Affected Versions**

Affected versions are: 5.0.0 (LRX21O), 5.0.1 (LRX22C), 5.1.0 (LMY47D), 5.1.0 (LMY47E), 5.1.0 (LMY47I), 5.1.0 (LMY47M), 5.1.1 (LMY47Z), 5.1.1 (LMY48I), 5.1.1 (LMY48M), 5.1.1 (LMY48T), 5.1.1 (LMY48W), 5.1.1 (LMY48X), 5.1.1 (LMY48Y), 5.1.1 (LVY48C), 5.1.1 (LVY48E), 5.1.1 (LVY48F), 5.1.1 (LVY48H), 5.1.1 (LVY48I), 5.1.1 (LYZ28E), 5.1.1 (LYZ28J), 5.1.1 (LYZ28K), 5.1.1 (LYZ28M) and 5.1.1 (LYZ28N).

**3\. Impact**

This vulnerability has the potential to compromise the security of the system in multiple ways.

An attacker with high priviledges in Normal World can exploit the vulnerability to compromise the Trusted Application running in the Secure World, eventually executing arbitrary code and reading and/or modifying information of critical files, compromising the confidentiality and integrity of the system.

On the other hand, the attacker is able to crash the Trusted Application, potentially resulting in a denial of service.

**4\. Vulnerability**

The bug is present in Widevine’s drm_verify_keys() command. This command closely resembles drm_save_keys(), which has been featured in other blog entries (refer to CVE-2022-48331 and CVE-2022-48332).

The following snippet shows a switch-case present in the TA’s command handler:

switch(\*req\_buf) {
case 0x50002: // drm\_verify\_keys() command
    if ((0x2a0f < req\_buf\_size) && (0x107 < resp\_buf\_size)) {
        drm\_verify\_keys(
            req\_buf + 4,    req\_buf\[1\], // feature\_name
            req\_buf + 0x44, req\_buf\[2\]  // file\_name
        );
        ...
    }
    break;
}

It takes the Command ID from the first word of the Request Buffer, which is sent by client applications in the Normal World. Thus, if the received command is 0x50002, it jumps to the drm_verify_keys() function.

The structure of the Request Buffer for this command is the following:

struct widevine\_drm\_save\_keys\_cmd {
    uint32\_t cmd\_id;
    uint32\_t feature\_name\_len;
    uint32\_t file\_name\_len;
    char feature\_name\[0x100\];
    char file\_name\[0x100\];
};

It contains two buffers (_i.e._, feature_name and file_name) and two integers indicating the effective length of each buffer. It is important to note that even though the maximum size of each buffer is 256 bytes, the client has control over the values of feature_name_len and file_name_len, since they are directly taken from the Request Buffer.

The main functionality of drm_verify_keys() is to verify the integrity of encryption keys or DRM-related data stored within the Widevine DRM system. It performs the following high-level tasks:

> *   Validate input parameters and check for any constraints that may prevent the verification process.
>     
> *   Construct a full file path using the provided feature name and file name.
>     
> *   Set the CRC (cyclic redundancy check) file path, which is used for verifying the integrity of the keys.
>     
> *   Verify the stored encryption keys or DRM-related data and check for any tampering or corruption.
>     

The bug is present in the validation of input parameters while constructing the SFS file path:

heap\_buf \= malloc(0x100);
...
memzero(heap\_buf, 0x80);
prefix\_len \= strncpy(heap\_buf, &persist\_prefix, 0x80);
total\_len \= prefix\_len + feature\_name\_len;
// ---- CVE-2022-48333 ---- //
if (total\_len < 0x100) {
    prefix\_len \= strlen(&persist\_prefix);
    memcpy(heap\_buf + prefix\_len, feature\_name, feature\_name\_len);
    // ----------------------- //
    \*(heap\_buf + total\_len) \= '/';
    if (total\_len + feature\_name\_len < 0xff) {
        memcpy(heap\_buf + total\_len + 1, feature\_name, feature\_name\_len);
        total\_len += (feature\_name\_len + 1);        \*(heap\_buf + total\_len) \= '/';
        // ---- CVE-2022-48334 ---- //
        if (total\_len + file\_name\_len < 0xff) {            memcpy(heap\_buf + total\_len + 1, file\_name, file\_name\_len);            ...
}

In this code snippet, a heap buffer is allocated and the persist_prefix string is copied into it using the strncpy() function. This string is initialized with the value "/persist/data/" by default, so that it’s length is 14. The buffer is then filled with the provided feature name, ensuring the total length does not exceed the specified limit. This is done using total_len by adding the length of the persist_prefix string and feature_name_len, which is directly specified by the client through the Request Buffer.

The first part corresponds to CVE-2022-48333, where the check if (total_len < 0x100) is performed using a signed integer and can cause a buffer overflow if feature_name_len takes any value from -14 (0xfffffff2) to -1 (0xffffffff).

To pass this first check without triggering the first bug, the value of feature_name_len must be within the inclusive range of 1 to 241. Then, the code appends the feature_name string two times to the temporary heap buffer. In the previous code snippet, there is a second check on feature_name_len that constraints its value to \[1, 120\]. Finally, there is a third if that checks the value of file_name_len. At this point, the result of the addition is treated as a signed integer, which leads to an incorrect check. Consequently, this third check is bypassed when the values for file_name_len are sufficiently large:

req.feature\_name\_len \= 120; // valid values are: \[1, 120\]
req.file\_name\_len \= \-(14 + (2 \* req.feature\_name\_len) + 1);

The code after the check calls the memcpy() function to copy the contents of the file_name string into the heap buffer, using the improperly checked file_name_len. Since this value can be large enough, it can cause a buffer overflow in this copy operation:

The user has full control over the **value** of file_name_len and the **contents** of the file_name buffer in the Request Buffer.

Since there are several specific and large file_name_len values that can cause the buffer to overflow, a memory copy operation with any of these values will exceed the bounds of the data segment, resulting in an invalid memory access and potentially causing the application to crash.

**5\. Exploitation**

This section shows a Proof of Concept (PoC) of how to trigger the vulnerability by sending a command to the Widevine trusted application running in the Secure World. Based on the command structure we have derived by reverse engineering, we can craft the command request to be sent to the trusted application:

req\->cmd\_id \= 0x50002;  // drm\_verify\_keys
req.feature\_name\_len \= 1;
req.file\_name\_len \= 0xffffffff;
...

The Commmand ID 0x50002 is specified to invoke drm_verify_keys(), and file_name_len is set to 0xffffffff so that the sum of total_len + file_name_len overflows producing a small value, bypassing the check and eventually calling memcpy() producing the buffer overflow. When this request is sent to Widevine, it ends up crashing.

<5>widevine: "drm\_verify\_keys: feature\_name 0xfff00010, feature\_name\_len 1, file\_name 0xfff00110,  file\_name\_len 4294967295"
\*\*\* crash \*\*\*

The Android log in normal world reports that qseecom_send_cmd has failed with error -22, which means APP\_FAULTED:

<4>QSEECOM: qseecom\_load\_app: App (widevine) does'nt exist, loading apps for first time
<4>QSEECOM: qseecom\_load\_app: App with id 3 (widevine) now loaded
<3>QSEECOM: \_\_qseecom\_send\_cmd: Response result -1 not supported
<3>QSEECOM: qseecom\_ioctl: failed qseecom\_send\_cmd: -22
<4>QSEECOM: qseecom\_unload\_app: App id 3 now unloaded

The reason it crashes is because the large memory copy ends up writing to unmapped memory due to exceeding the data segment.

CVE-2022-48334: Cyber Intelligence - Hardware and Software Security Assessments

The laola.redbull application through 5.1.9-R for Android exposes the exported activity at.redbullsalzburg.android.AppMode.Default.Splash.SplashActivity, which accepts a data: URI. The target of this URI is subsequently loaded into the application's webview, thus allowing the loading of arbitrary content into the context of the application. This can occur via the fcrbs schema or an explicit intent invocation.

CVE-2023-29459

Widevine Trusted Application (TA) 5.0.0 through 5.1.1 has a drm_save_keys integer overflow and resultant buffer overflow.

CVE-2022-48331:

Buffer Overflow in Widevine Trustlet (drm\_save\_keys @ 0x69b0)

 

CVE:

CVE-2022-48331

Vendor:

Google

Device:

Nexus 6

Affected Component:

Widevine

Publication Date:

March 2023

Credits:

CyberIntel Team

Last edited: 11/04/23

**1\. Description**

This entry describes a vulnerability that we found in the Widevine Trusted Application (TA), which runs within Qualcomm’s Secure Execution Environment (QSEE). The vulnerability is an integer overflow that leads to a subsequent buffer overflow. This bug has been found using tools we have developed to assist in the security evaluation of TrustZone, including a debugger and a coverage-based fuzzer for QSEE TAs. Please, refer to this page for further information.

Qualcomm Secure Execution Environment is one of the most widespread commercial TEE solutions in the smartphone space, used by many different devices such as Xiaomi, Motorola and several devices of the Google Nexus and Pixel series.

Widevine is a Digital Rights Management (DRM) technology developed by Google to protect copyrighted content and to enable secure distribution and consumption of video and audio content. The technology involves encryption, licensing, and key management to ensure that content can only be decrypted and played back on authorized devices.

An attacker could potentially exploit the vulnerability in the Trusted Application by sending a command from the Normal World, causing the application to crash and possibly execute arbitrary code. This vulnerability could have potential consequences, such as elevating attacker’s privileges and exposing sensitive information.

This post is part of a series of related bugs affecting Widevine Trusted Application of Google Nexus 6:

> *   CVE-2022-48331
>     
> *   CVE-2022-48332
>     
> *   CVE-2022-48333
>     
> *   CVE-2022-48334
>     
> *   CVE-2022-48335
>     
> *   CVE-2022-48336
>     
> *   CVE-2015-6639
>     
> *   CVE-2015-6647
>     

**2\. Affected Versions**

Affected versions are: 5.0.0 (LRX21O), 5.0.1 (LRX22C), 5.1.0 (LMY47D), 5.1.0 (LMY47E), 5.1.0 (LMY47I), 5.1.0 (LMY47M), 5.1.1 (LMY47Z), 5.1.1 (LMY48I), 5.1.1 (LMY48M), 5.1.1 (LMY48T), 5.1.1 (LMY48W), 5.1.1 (LMY48X), 5.1.1 (LMY48Y), 5.1.1 (LVY48C), 5.1.1 (LVY48E), 5.1.1 (LVY48F), 5.1.1 (LVY48H), 5.1.1 (LVY48I), 5.1.1 (LYZ28E), 5.1.1 (LYZ28J), 5.1.1 (LYZ28K), 5.1.1 (LYZ28M) and 5.1.1 (LYZ28N).

**3\. Impact**

This vulnerability has the potential to compromise the security of the system in multiple ways.

An attacker with high priviledges in Normal World can exploit the vulnerability to compromise the Trusted Application running in the Secure World, eventually executing arbitrary code and reading and/or modifying information of critical files, compromising the confidentiality and integrity of the system.

On the other hand, the attacker is able to crash the Trusted Application, potentially resulting in a denial of service.

**4\. Vulnerability**

The bug is present in Widevine’s drm_save_keys() command. This command closely resembles drm_verify_keys(), which has been featured in other blog entries (refer to CVE-2022-48333 and CVE-2022-48334).

The following snippet shows a switch-case present in the TA’s command handler:

switch(\*req\_buf) {
case 0x50001: // drm\_save\_keys() command
    if ((0x2a10 < req\_buf\_size) && (0x107 < resp\_buf\_size)) {
        ...
        drm\_save\_keys(
            req\_buf + 4,    req\_buf\[1\], // feature\_name
            req\_buf + 0x44, req\_buf\[2\], // file\_name
            req\_buf + 0x84, req\_buf\[3\], // msg
            resp\_buf + 4                // prt\_path (result)
        );
    }
    break;
}

It takes the Command ID from the first word of the Request Buffer, which is sent by client applications in the Normal World. Thus, if the received command is 0x50001, it jumps to the drm_save_keys() function.

The structure of the Request Buffer for this command is the following:

struct widevine\_drm\_save\_keys\_cmd {
    uint32\_t cmd\_id;
    uint32\_t feature\_name\_len;
    uint32\_t file\_name\_len;
    uint32\_t msg\_len;
    char feature\_name\[0x100\];
    char file\_name\[0x100\];
    char msg\_data\[0x100\];
};

It contains three buffers (_i.e._, feature_name, file_name and msg_data) and three integers indicating the effective length of each buffer. It is important to note that even though the maximum size of each buffer is 256 bytes, the client has control over the values of feature_name_len, file_name_len and msg_len, since they are directly taken from the Request Buffer.

The main functionality of drm_save_keys() is securely storing encryption keys or DRM-related data. It performs the following high-level tasks:

> *   Validate input parameters and check for any constraints that may prevent key storage.
>     
> *   Construct a file path using the provided feature name and file name.
>     
> *   Write the message data, which may contain encryption keys or DRM-related information, to a Secure File System (SFS).
>     
> *   Compute and store a CRC value for the written data to ensure data integrity and error detection.
>     

The bug is present in the validation of input parameters while constructing the SFS file path:

heap\_buf \= malloc(0x100);
...
memzero(heap\_buf, 0x80);
prefix\_len \= strncpy(heap\_buf, &persist\_prefix, 0x80);
total\_len \= prefix\_len + feature\_name\_len; // Signed int
if (total\_len < 0x100) {
    prefix\_len \= strlen(&persist\_prefix);
    memcpy(heap\_buf + prefix\_len, feature\_name, feature\_name\_len);    ...
}

In this code snippet, a heap buffer is allocated and the persist_prefix string is copied into it using the strncpy() function. This string is initialized with the value "/persist/data/" by default, so that it’s length is 14. The buffer is then filled with the provided feature name, ensuring the total length does not exceed the specified limit. This is done using total_len by adding the length of the persist_prefix string and feature_name_len, which is directly specified by the client through the Request Buffer.

The bug is present in this calculation. Since total_len is a signed integer, this calculation causes an integer overflow if the sum of prefix_len and feature_name_len is large enough, resulting in a negative value for total_len. As a result, the subsequent if statement passes even if the actual total length of the string is greater than the allocated buffer size.

Since the check is if (total_len < 0x100), for the condition 14 + feature_name_len < 0x100 to be triggered, the value of feature_name_len must be within the inclusive range of -14 to 241.

The code after the check calculates again the prefix_len and calls the memcpy() function to copy the contents of the feature_name string into the buffer, immediately following the persist_prefix, using feature_name_len. Since this value can be large enough, it can cause a buffer overflow in this copy operation:

The range of values for feature_name_len that can cause a buffer overflow extends from -14 (0xfffffff2) to -1 (0xffffffff).

The user has full control over the **value** of feature_name_len and the **contents** of the feature_name buffer in the Request Buffer.

Since there are 14 specific and large feature_name_len values that can cause the buffer to overflow, a memory copy operation with any of these values will exceed the bounds of the data segment, resulting in an invalid memory access and potentially causing the application to crash.

**5\. Exploitation**

This section shows a Proof of Concept (PoC) of how to trigger the vulnerability by sending a command to the Widevine trusted application running in the Secure World. Based on the command structure we have derived by reverse engineering, we can craft the command request to be sent to the trusted application:

req\->cmd\_id \= 0x50001;  // drm\_save\_keys;
req\->feature\_name\_len \= 0xffffffff;
req\->file\_name\_len \= 1;
req\->msg\_len \= 1;
...

The Commmand ID 0x50001 is specified to invoke drm_save_keys(), and feature_name_len is set to 0xffffffff so that the sum of prefix_len + feature_name_len overflows producing a small value, bypassing the check and eventually calling memcpy() producing the buffer overflow. When this request is sent to Widevine, it ends up crashing.

<5>widevine: "drm\_save\_keys: feature\_name 0xfff00010, feature\_name\_len 4294967295, file\_name 0xfff00110, file\_name\_len 1, msg\_data 0xfff00210
\*\*\* crash \*\*\*

The Android log in normal world reports that qseecom_send_cmd has failed with error -22, which means APP\_FAULTED:

<4>QSEECOM: qseecom\_load\_app: App (widevine) does'nt exist, loading apps for first time
<4>QSEECOM: qseecom\_load\_app: App with id 3 (widevine) now loaded
<3>QSEECOM: \_\_qseecom\_send\_cmd: Response result -1 not supported
<3>QSEECOM: qseecom\_ioctl: failed qseecom\_send\_cmd: -22
<4>QSEECOM: qseecom\_unload\_app: App id 3 now unloaded

The reason it crashes is because the large memory copy ends up writing to unmapped memory due to exceeding the data segment.

CVE-2022-48331: Cyber Intelligence - Hardware and Software Security Assessments

Categories: News
Tags: week

Tags:  security

A list of topics we covered in the week of June 19 to June 25 of 2023



(Read more...)




The post A week in security (June 19 - 25) appeared first on Malwarebytes Labs.

Cybersecurity info you can't do without

Want to stay informed on the latest news in cybersecurity? Sign up for our newsletter and learn how to protect your computer from threats.

Cyberprotection for every one.

FOR PERSONAL

Windows Antivirus

Mac Antivirus

iPhone Antivirus

Android Antivirus

Free Antivirus

VPN App (All Devices)

SEE ALL

COMPANY

About Us

Contact Us

Careers

News and Press

Blog

Scholarship

Forums

FOR BUSINESS

Small Businesses

Mid-size Businesses

Large Enterprise

Endpoint Protection

Endpoint Detection & Response

Managed Detection and Response (MDR)

FOR PARTNERS

Managed Service Provider (MSP) Program

Resellers

MY ACCOUNT

Sign In

SOLUTIONS

Free Rootkit Scanner

Free Trojan Scanner

Free Virus Scanner

Free Spyware Scanner

Anti Ransomware Protection

SEE ALL

ADDRESS

3979 Freedom Circle  
12th Floor  
Santa Clara, CA 95054

ADDRESS

One Albert Quay  
2nd Floor  
Cork T12 X8N6  
Ireland

LEARN

Malware

Hacking

Phishing

Ransomware

Computer Virus

Antivirus  

What is VPN?

COMPANY

About Us

Contact Us

Careers

News and Press

Blog

Scholarship

Forums

MY ACCOUNT

Sign In

ADDRESS

3979 Freedom Circle, 12th Floor  
Santa Clara, CA 95054

ADDRESS

One Albert Quay, 2nd Floor  
Cork T12 X8N6  
Ireland

A week in security (June 19 - 25)

Make sure your chats are kept as private as you want them to be.

The actual number of chat messages sent each day is hard to come by, but with WhatsApp alone accounting for billions of users, you can imagine the sheer volume of ongoing conversations.

Not all of those messages involve anything particularly sensitive or private, but a lot of them do—and you don’t want those chats to be seen by anyone other than the intended recipients.

Good messaging hygiene might involve changing apps or tweaking a setting, but it’s important that you don’t neglect it. These five recommendations can get you started.

Switch to End-to-End Encryption

When instant messenger chats are end-to-end encrypted, they’re essentially turned into impenetrable blocks of data. Only the devices of the person (or people) you’re chatting with have the codes to unlock that data, which ensures no one else can read your messages while they’re in transit.

Not even the developers behind the software you’re using can unlock that data, so if an unscrupulous employee wanted to take a peek at your chats, they wouldn’t be able to. If law enforcement requested copies of the conversations, there wouldn’t be anything useful to hand over to them.

Some instant messengers use end-to-end encryption, but not all of them do. End-to-end encryption is deployed by default for Signal, WhatsApp (for personal chats,) iMessage, and Google Messages (with RCS enabled.) It’s also available as an option on Facebook Messenger and Telegram. If you’re using anything else, check the provider’s policies and consider switching to something more secure.

Facebook Messenger lets you set messages to disappear.

Facebook via David Nield

Turn On Disappearing Messages

We mentioned that Facebook Messenger has the option of end-to-end encryption: To enable it, you need to make a conversation “secret” by tapping the info (“i”) button at the top of a chat in the mobile app, then choosing **Go to secret conversation**.

Once you’re in that secret conversation, another feature becomes available: Disappearing messages. Tap the info button again and pick **Disappearing messages**, then choose how long messages should stick around after being read. This way of tidying up after yourself protects you against someone reading through your chats if they gain access to them or physical access to your device.

Facebook Messenger isn’t the only app that offers this functionality: You can also find disappearing messages in WhatsApp, Signal, and Telegram, among others. On iPhones, you can delete older conversations in the Messages app after choosing **Messages** and **Keep Messages** from Settings.

Lock Individual Conversations

To avoid an unwelcome visitor gaining access to your phone and all of your chats, one of the best things you can do is lock some or all of those chats behind a passcode or other lock—like the protection on your phone’s lock screen.

WhatsApp makes this simple. You can lock the entire app via the **Privacy** menu in the app settings, or you can lock individual chats: Open the chat, tap the conversation name at the top of the screen, and then pick **Chat lock**. The options here will depend on the options on your phone (such as fingerprint lock and face recognition).

Other apps offer the ability to lock all of your chats, including Signal, Facebook Messenger, and Telegram, though for the moment the option to lock individual conversations is exclusive to WhatsApp.

Check Your Contact Options

Most instant messenger and social media apps let you control which other users are allowed to follow you, send friendship requests, communicate with you via direct messages, and so on. Tightening up these settings is another way to limit your exposure to the wider world and maximize the security of your chats.

Take Telegram, for example. Head to **Privacy and Security** in Settings, and you can control who is allowed to see your online status, your profile photo, the groups and channels you’re in, and more. Other apps have similar options, so make sure you know what they are and what they do.

Also, think about the temporary photo and video posts commonly known as stories if your app supports them (a lot now do). These stories have their own visibility settings and may well be public by default.

Setting visibility options in Telegram.

Telegram via David Nield

Know Where Your Chat Backups Are

You want to keep backups of some conversations, otherwise you risk losing all of those records, and all that history, if something should happen to your smartphone.

But it’s important to know what you’re backing up and where those backups live. Backups are another potential route for anyone trying to access your messages without authorization, so you should keep them as well protected and secure as anything that’s actually on your phone. Some apps back up your conversations locally, and few encrypt them, so make sure to check your favorite app’s settings.

As a final precaution, you also need to think about other devices and locations where you’re logged in—Gmail can lead to Google Chat, for example—as well as places any external backups might be stored and how these are protected (take WhatsApp on Android, which can save chat backups to Google Drive).

5 Ways to Make Your Instant Messaging More Secure

Directory traversal can occur in the Basecamp com.basecamp.bc3 application before 4.2.1 for Android, which may allow an attacker to write arbitrary files in the application's private directory. Additionally, by using a malicious intent, the attacker may redirect the server's responses (containing sensitive information) to third-party applications by using a custom-crafted deeplink scheme.

CVE-2023-36612

jcvi is a Python library to facilitate genome assembly, annotation, and comparative genomics. A configuration injection happens when user input is considered by the application in an unsanitized format and can reach the configuration file. A malicious user may craft a special payload that may lead to a command injection. The impact of a configuration injection may vary. Under some conditions, it may lead to command injection if there is for instance shell code execution from the configuration file values. This vulnerability does not currently have a fix.


CVE-2023-35932: jcvi/jcvi/apps/base.py at cede6c65c8e7603cb266bc3395ac8f915ea9eac7 · tanghaibao/jcvi

By ghostadmin
In this article, we’ll explore the best practices for building a customer-centric business with client portals and how…
This is a post from HackRead.com Read the original post: Enhancing Customer Engagement with Client Portals

In this article, we’ll explore the best practices for building a customer-centric business with client portals and how to master client experience management.

The customer experience has never been more important for businesses. In order to stay competitive in today’s rapidly changing marketplace, companies must do everything they can to provide the best possible customer service and client experience.

One powerful way to achieve this is by leveraging a client portal to create a more seamless, personalized customer journey. Client portals offer many benefits, from streamlined communication and data-driven insights to simplified transactions, but they must also be carefully managed if companies are to make the most of them.

In this article, we’ll explore the best practices for building a customer-centric business with client portals and how to master client experience management.

**Improved communication with customers**

One of the primary functions of client portals is to provide a secure, personalized environment for customers to interact with a business. This not only makes it easier for customers to find relevant information but also enables them to feel valued and heard.

By offering a one-stop solution for all their needs, businesses can reduce the need for customers to reach out through multiple channels, such as phone calls or emails. This, in turn, minimizes the chance of miscommunication and helps maintain a consistent flow of information between the customer and the business.

What’s more, client portals enable businesses to be more proactive in their communication with customers. Features like automated notifications, alerts, and reminders ensure that both parties are always on the same page regarding upcoming deadlines, pending tasks, or changes to the project.

This level of transparency not only keeps customers informed but also instils a sense of trust and reliability in the business.

**Increased customer satisfaction**

The main way that client portals increase customer satisfaction is by offering convenience. Customers appreciate having the ability to access their account information, submit requests, and track progress at any time and from anywhere.

Improved accessibility not only saves time but also empowers customers to take control of their interactions with the business, leading to a more satisfying experience. Moreover, when you reduce the need for customers to reach out through multiple channels, such as phone calls or emails, you help minimize frustration and streamline communication.

A second way in which client portals can improve customer satisfaction is through the personalized experience they provide. By tailoring the content and features of the portal based on individual customer needs, businesses can make their customers feel valued and understood.

This personal touch helps build trust and rapport between the customer and the business, ultimately leading to a stronger relationship and increased satisfaction.

**Automation of processes**

Client portals can help automate processes through the integration of various tools and applications. By connecting the client portal with other software solutions such as CRM, project management, and invoicing systems, businesses can automate data synchronization and ensure that all relevant information is up-to-date and accessible in one place.

This not only helps reduce the need for manual data entry but also helps eliminate inconsistencies and errors that could arise from managing data across multiple platforms.

Client portals can also help improve automation by setting up automated notifications, alerts, and reminders.

These features can keep both customers and the business informed about upcoming deadlines, pending tasks, or changes to the project. By automating these notifications, businesses can ensure that important updates are communicated promptly and consistently, without having to rely on manual intervention.

**Streamlined workflows**

Client portals are good at providing a unified, organized space for managing projects and tasks. By consolidating all project-related information, documents, and communications within the portal, businesses can ensure that team members and customers have access to the most up-to-date and relevant data.

This level of organization not only helps prevent miscommunication or errors due to outdated information but also makes it easier for teams to prioritize tasks and manage their workload more effectively.

Features such as automated notifications, alerts, and reminders can help keep both customers and team members informed about upcoming deadlines, pending tasks, or changes to the project. By automating these updates, businesses can ensure that important information is communicated promptly and consistently, allowing teams to stay on top of their tasks and maintain a smooth workflow.

**Easier data management**

One of the key ways client portals make data management easier is by providing a single, organized repository for storing and sharing documents, project updates, and other pertinent information.

Through the consolidation of data, businesses can ensure that all parties involved have access to the most recent version of a file, minimizing the risk of miscommunication or errors due to outdated information.

This allows businesses to maintain consistency while also saving time by reducing the need to search through multiple channels, such as emails or shared drives, to locate specific documents.

Data management is further improved through integration with other software solutions such as CRM, project management, and invoicing systems. This integration allows for seamless data synchronization and ensures that all relevant information is readily accessible in one place.

As a result, businesses can eliminate inconsistencies and errors that could arise from managing data across multiple platforms, leading to more accurate and efficient data management.

**Enhanced security measures**

Client portals enhance security measures by providing a secure environment for storing and sharing sensitive information. Robust encryption methods are employed to protect data both in transit and at rest, ensuring that customer data remains confidential and secure from unauthorized access.

This gives businesses and their customers peace of mind while at the same time helping maintain compliance with various data privacy regulations, such as GDPR and HIPAA.

Customer portals also incorporate strong authentication and access control mechanisms such as multi-factor authentication (MFA) and single sign-on (SSO) adding an extra layer of security by requiring users to verify their identity through multiple means before granting access to the portal.

You can also integrate role-based access control that allows businesses to define and manage user permissions, ensuring that each user has access only to the information and features relevant to their specific role. This granular control over access helps prevent unauthorized access and maintain the integrity of sensitive data.

**Conclusion**

Through the implementation of features such as automated notifications, streamlined workflows, and enhanced security measures, client portals can significantly improve customer experience management.

By providing customers with a personalized and secure environment for managing their projects and tasks, businesses can make it easier for them to interact with their service providers and ensure that their data remains confidential and secure.

Ultimately, these advantages lead to improved customer satisfaction and loyalty, helping businesses build stronger relationships with their customers.

**RELATED ARTICLES**

1.  How chat platforms are using ML for content moderation?
2.  How to Teach Your Child Coding: A Gift for Their Digital Future
3.  How to Create a Mobile Application for Android OS Step by Step?
4.  Incorporating machine learning in data mapping for improved results

Enhancing Customer Engagement with Client Portals

Under construction: The world's leading ransomware gang is workshopping ransomware for less obvious systems beyond Windows environments. Experts weigh in on how worried we should be.

The LockBit gang is building ransomware for new architectures, forgoing Windows and potentially posing entirely new problems for their victims along the way.

In a blog published June 22, researchers from Kaspersky describe having "stumbled on" a .ZIP file with a trove of LockBit malware samples inside. The samples appear to have derived from LockBit's previous encryptor variations targeting VMWare ESXi hypervisors.

The samples targeted FreeBSD and Linux — a growing trend among ransomware actors — plus various embedded technologies, including instruction set architecture (ISA) firmware for CPUs, like ARM, MIPS, ESA/390, and PowerPC, as well as Apple M1, an ARM-based system-on-chip (SoC) used in Mac and iPad devices.

The samples were clearly a work in progress, Kaspersky noted, since "for instance, the macOS sample was unsigned, so it could not be executed as is. Also, the string encryption method was simple: one-byte XOR."

Should they eventually make it to the wild, however, these new ransomware variants could prove useful to LockBit as it tries to stay relevant, says Jason Baker, threat intelligence analyst at GuidePoint Security. "In an increasingly crowded RaaS marketplace competing for talent and targets, this kind of differentiating behavior may ultimately benefit LockBit despite the additional costs and lower volume of targets."

**Can LockBit Deliver Embedded Ransomware?**

Especially after the breakup of Conti, LockBit arguably took up the mantle as the world's premier ransomware gang. Last month brought a notable decline in its activity, however. While the ransomware industry rose as a whole, LockBit claimed 30% fewer victims than the month prior.

Perhaps, in retrospect, it was dedicating extra time and resources to developing its new malware. Or, perhaps, the new malware is a response to its decline.

Either way, its new direction is a cause for concern for defenders. Security analysts already raised the alarm on Android SoCs in 2021, Apple M1 in 2022, and multiple vulnerabilities in popular AMI SoCs were revealed earlier this year.

"We're seeing increased reporting lately related to embedded devices being used for persistence," reports Adam Pennington, project leader for MITRE, though major attacks have not yet been demonstrated in the wild.

LockBit will face hurdles in breaking through this glass ceiling, explains Callie Guenther, cyber threat research senior manager at Critical Start. "Unlike traditional operating systems, embedded systems and IoT devices often have resource constraints, limited processing power, and specific hardware configurations. Ransomware designed for SoCs needs to be tailored to these limitations and adapted to the specialized environment," she points out.

"Furthermore," she continues, "SoCs often run specialized firmware or customized operating systems, which may require a different approach in terms of payload delivery, execution, and evasion techniques. Ransomware targeting SoCs may need to exploit specific vulnerabilities or weaknesses within the firmware or system architecture to gain control over the device and encrypt its data."

Baker speculates that the challenge may be part of the appeal for LockBit. "The most likely reason to target SoCs that are not being targeted by other groups, such as Apple silicon, is for the sake of brand strength and prestige. Larger, more advanced groups such as LockBit have the in-house expertise and resources to throw at this problem set, and developing a unique capability not available elsewhere would continue to highlight the group as a pioneer in the ransomware-as-a-service (RaaS) ecosystem," he says.

**Why Embedded Malware Is Difficult to Excise**

The reason to worry about ransomware for embedded technologies, Pennington explains, isn't merely that it's new and uncharted. It's also that these technologies are easier to overlook and sometimes harder to protect.

"Most enterprises heavily focus their security efforts on Windows, despite various other server and embedded operating systems occupying the exact same networks. Among other reasons, targeting these alternate platforms can be a really effective way to evade existing defenses," Pennington assesses.

He poses a scenario where "a ransomware or other actor infects a network, defenders clean up the type of systems where they have visibility and tools to see and manage systems, and then they discover months later that an implant has been left behind on something like a Linux-based security camera running on one of these other architectures."

To prevent attackers gaining this upper hand, Pennington says, "organizations need to consider a diverse set of operating systems and architectures when they secure themselves, and not just their Windows systems."

"Nearly everyone is running some number of systems with these types of OSs and chips," he emphasizes, "even if they don't realize it."

LockBit Developing Ransomware for Apple M1 Chips, Embedded Systems

The "nOAuth" attack allows cross-platform spoofing and full account takeovers, and enterprises need to remediate the issue immediately, researchers warn.

Organizations that have implemented the "Log in with Microsoft" feature in their Microsoft Azure Active Directory environments could potentially be vulnerable to an authentication bypass that opens the door to online and cloud account takeovers.

According to researchers at Descope, who dubbed the attack "nOAuth," the issue is an authentication implementation flaw that affects multitenant OAuth applications in Azure AD, Microsoft's cloud-based identity and access management service. A successful attack gives a bad actor full run of a victim's accounts, with the ability to establish persistence, exfiltrate data, explore if lateral movement is possible, and so on.

"OAuth and OpenID Connect are open, popular standards which millions of Web properties already use," says Omer Cohen, CISO at Descope. "If 'Log in with Microsoft' is improperly implemented, several of these apps could be vulnerable to account takeover. Small businesses with fewer developer resources could especially be impacted."

**Inside the nOAuth Cyberattack Threat**

By way of background, OAuth is an open, token-based authorization framework that allows users to log into applications automatically, based on previous authentication to another trusted app. This is familiar to most people from the "Log in with Facebook" or "Log in with Google" options available on many e-commerce websites.

In the Azure AD environment, OAuth is used to help manage user access to external resources, such as Microsoft 365, the Azure portal, and thousands of other SaaS applications using OAuth apps.

"Azure Active Directory also manages internal resources like apps on your corporate intranet and any cloud apps developed by your own organization by providing authentications via OAuth, OIDC, and other standard protocols," according to the Descope analysis. In other words, it holds the keys to a lot of important corporate data.

The weakness allows bad actors to perform cross-platform spoofing simply by using an unwitting victim's email address to impersonate them, according to Descope's analysis on the issue, released this week.

"In usual OAuth and OpenID Connect implementations, the user’s email address is used as the unique identifier by applications," explained researchers at Descope. "However, in Microsoft Azure AD, the 'email' claim returned is mutable and unverified, so it cannot be trusted."

That means that anyone with malicious intent and a decent amount of platform knowledge can simply set up an Azure AD account, and arbitrarily change the email attribute under "Contact Information" in that account to control the email authentication claim.

"\[This\] allows the attacker to use 'Log in with Microsoft' with the email address of any victim they want to impersonate," the researchers explained. "They can take over victims' accounts on any app that uses 'email' claim as the unique identifier for Microsoft OAuth and does not validate that email address, completely bypassing authentication."

The attack flow is unnervingly simple:

1.  The attackers accesses their Azure AD account as an administrator.
2.  The attackers change the "email" attribute of their account used for authentication to the victim’s email address.
3.  Since Microsoft does not require the email change to be validated on Azure AD, the system merges the two accounts and gives the attackers access to the victim's environment.

**A Far-Ranging Authentication Weakness**

To better understand the scope of the problem, the Descope researchers created a nOAuth proof-of-concept (PoC) exploit and tested it "with a white-hat attack on hundreds of websites and applications to check if any of them were vulnerable," they said. "We found that quite a few of them were."

Amid the sitting ducks were a design app with millions of monthly users, a publicly traded customer experience company, a leading multicloud consulting provider, as well as several SMBs and early-stage startups.

"We also informed two authentication platform providers that were merging user accounts when 'Log in with Microsoft' was used on an existing user account," according to the report. "In this instance, merging the attacker account with a legitimate user account would hand full control over the user account to the attacker. As a result, all of their customers using 'Log in with Microsoft' would have been vulnerable."

These findings, according to the researchers, "are a drop in the ocean of the Internet," and there are likely many, many thousands of other users that could be affected.

Microsoft has always issued general guidance to users to not to use an email address as a unique identifier for authentication, but after Descope informed Microsoft of the breadth of the issue, the computing giant has revamped its Azure AD OAuth implementation guidance to include two new claims to use, and dedicated sections on claim verification.

"If your app uses 'Log in with Microsoft' and you handle authentication in-house, it’s critical that you check if you use the email claim returned by Azure AD as the unique identifier," Cohen notes. "If so, remediation steps should be taken to ensure the claim used as the unique identifier for the user is the 'sub' (Subject) claim to avoid potential exploitation."

**Incorrect OAuth Implementations Plague Businesses**

Incorrect implementations of OAuth have been coming to light at big businesses lately, showcasing a need for organizations to lock down this potentially damaging attack vector.

In March, for instance, flaws in the authorization system of the Booking.com website came to light that could have allowed attackers to take over user accounts and gain full visibility into their personal or payment-card data, as well as log in to accounts on the website's sister platform, Kayak.com.

And in May, a bug tracked as CVE-2023-28131 was found in the OAuth implementation of Expo, an open source framework for developing native mobile apps for iOS, Android, and other Web platforms using a single codebase. The flaw threatened the accounts of any users that used various and social media accounts to log in to an online service that uses the framework.

Cohen underscores that the OAuth standard and others like it are trustworthy and strong authentication approaches but that businesses need to make sure to work with cybersecurity and authentication experts when building them in.

"These standards are extremely complicated to work with," he says. "Authentication isn’t something you can just add on and check a box. Implementing these standards correctly is critical to the security of the application."

He adds, "If businesses chose to implement these standards in-house, then they must have regular pen testing and review of the implementation, or they can use an authentication platform that is built by security experts."

He stresses that the importance of this can't be understated, given that cybercriminals are actively looking for these types of weaknesses.

"These are very typical attack vectors exploited," Cohen notes. "Attackers use these to cause widespread harm."

He adds, "With the increase of organizations adopting cloud technologies and SaaS applications, identity is the new firewall. If user authentication is not well-designed, it doesn’t matter how secure the application is itself as you will leave the front door open to cyberattacks."

Tag

#android