This advisory contains mitigations for a Missing Authentication for Critical Function, Use of Hard-coded Credentials, Insufficient Verification of Data Authenticity, and Use of a Broken or Risky Cryptographic Algorithm vulnerabilities in the Emerson DeltaV Distributed Control System software management platform.

Emerson DeltaV Distributed Control System

This advisory contains mitigations for Use of Hard-coded Cryptographic Key, Use of Hard-coded Credentials, and Insufficient Verification of Data Authenticity vulnerabilities in the Motorola Solutions ACE1000 remote terminal unit.

Motorola Solutions ACE1000

Use of hard-coded credentials vulnerability exists in STARDOM FCN Controller and FCJ Controller R4.10 to R4.31, which may allow an attacker with an administrative privilege to read/change configuration settings or update the controller with tampered firmware.

CVE-2022-30997

This advisory contains mitigations for Cleartext Transmission of Sensitive Information, and Use of Hard-coded Credentials vulnerabilities in the Yokogawa STARDOM network control system.

Yokogawa STARDOM

Low-code/no-code platforms allow users to embed their existing user identities within an application, increasing the risk of credentials leakage.

According to the "2022 Verizon Data Breach Investigations Report," stolen credentials were the top path leading to data breaches. More often than phishing or exploiting vulnerabilities, attackers gain direct access to credentials, letting them virtually walk into victim organizations using the front door.

Low-code/no-code platforms make it extremely easy for users to share their credentials and embed their credentials into applications, thus drastically increasing the risk that employee mistakes will result in credentials leakage. Unintentionally, low-code/no-code development makes the No. 1 resource for attackers easier to obtain.

**How Low-Code/No-Code Platforms Sacrifice Security For Productivity**

Getting the required permissions to do your job in an enterprise can be very frustrating. It's not uncommon for new employees to wait more than a month before they have the full scope of permissions they need to access business data, review KPI dashboards, or join an internal communication channel.

The same thing is true, maybe even worse, for setting up a new application in the enterprise. Permissions requests typically need to be approved by your direct manager, their manager, and the team who owns the data/service. Some of the approvers might be in another continent with a time zone difference. It's next to impossible to start building an application without the required access to data/services, and so you end up waiting.

After you manage to get the right access for your application, you are finally ready to start building. A few months go by. Suddenly, you get a notification that your application has failed. A quick analysis shows that its permissions have been revoked. Enterprises typically set up an automated process that revokes access every few months, unless permissions are explicitly asked for by the application maker. This process is necessary to comply with regulations and reduce over-permissions, but it has its downsides — namely a periodic manual process that could hinder productivity.

Low-code/no-code is an attempt to empower every employee, especially business professionals, to address their own issues with custom-built applications and automations. Vendors do this by systematically identifying and removing roadblocks for building applications. Is learning to code challenging or scary? A drag-and-drop interface can help lower the barrier to entry. Is integration difficult? A wide range of managed connectors will remove the need to know what an application programming interface (API) is or how to interact with it. Is asking for permissions slowing you down? Sharing identities and leveraging existing user access can provide a quick alternative.

To boost innovation, low-code/no-code platforms allow their users to leverage their existing user identity, embed it within an application, and by doing so circumvent the enterprise permissions model entirely. For an outside viewer in security or IT, the application doesn't exist, and everyone using it is actually running it on its maker's account.

**Wait, But How?**

If you're thinking that there are better solutions out there than letting the application impersonate its maker, you are partially right.

In recent years, OAuth has been the de-facto standard for granting application access. Any time you go to a software-as-a-service (SaaS) marketplace, pick up a third-party integration, and get prompted with a small login and consent pop-up, you're most likely using OAuth. OAuth has many different consent flows, all resulting in the familiar pop-up experience. A key distinction is whether consent is granted to the application directly or on behalf of its currently signed-in user. Although this might sound like a minor detail, it is actually the root cause of the low-code/no-code identity problem.

When an application is granted consent directly, it is issued its own identity, separate from that of the user who granted the consent. The application identity can be monitored for suspicious authentication or access patterns, and its permissions can be revoked at any time by a security or IT admin. Controls like IP restriction can be put in place to take advantage of the static nature of the infrastructure that the application runs on. Every application can have a separate identity, with separate access restrictions, and can be monitored and acted up--on separately. Another useful implication of application identity is admin control.

Granting consent on behalf of the currently signed-in application user, however, has very different implications. The application gains access to resources using its user's identity for the limited time when the user uses the app. On-behalf access means that the application is actually using its user's identity directly when querying external resources. Moreover, using multiple applications will result in all of them using the same identity: the user's identity. IT or security admins looking at logs will not be able to easily distinguish between the user or any application used by the user. Granting application access on behalf of users was originally designed to allow temporary access only while a user is actively using the application.

In many cases, services allow applications to gain access on behalf of users but deny applications direct access to service APIs. This raises an interesting question: If an application can only gain access to data on behalf of a user, how can it access data when no user is interacting with it? Creative engineers have come up with a solution. The application logs in as a user once, then records its authentication token and keeps on using it even after the user has logged off the application. In the case of low-code/no-code applications, that user is typically the application's creator. User authentication tokens are supposed to be short-lived in order to prevent this workaround. In practice, however, most services issue tokens that are valid for 12 months.

Let's say a business professional creates an application. Instead of having to wait for approval of an application identity or permissions, they use access on behalf of a user — in this case, their own. The application requires them to log in once (say to Salesforce or SharePoint), records their own private authentication token, and reuses it at will. Even if another user is using the application, it will still use its maker's identity.

There are ways to build low-code/no-code applications with dedicated identities — for example, by using service accounts. However, the methods are not very widely used.

Recall the positive properties of application identity stated above: The application can be monitored, its access to data can be controlled, and its privileges can be revoked. None of this is true when low-code/no-code platforms are embedded with their creator's identity. Every application a business professional makes might have their user identity built into it. Security and IT teams analyzing access logs will have no way to know that these applications even exist.

**Impersonation-as-a-Service**

Recording and replaying user authentication tokens as a way to grant applications access to resources has another implication: They open the door to simple and easy identity sharing among users. This manifests in a common low-code/no-code feature typically referred to as connections. Connections are how low-code/no-code applications gain access to resources like Slack, NetSuite, or BambooHR. They allow read operations, like reading employee HR data; write operations, like the ERP on recent sales; and delete operations, like permanently deleting a Slack channel. Connections are first-class objects, which means they can be created by one user and shared with another user, an entire team, or even an entire organization. Technically speaking, these are wrappers around user authentication tokens or hard-coded credentials.

When a user creates and shares a connection to Microsoft Office, for example, it is akin to them sharing their password. However, if a team of developers is collaborating on a project, they often need to be able to share an application identity with each other. Connection sharing enables working together in a team on a shared project, but unfortunately it can also enable users to share their identities with each other. Since many low-code/no-code applications are built with the creator's identity embedded within, identity sharing is a common risk low-code/no-code platforms introduce.

To make matters worse, credential sharing is just way too easy on many platforms. A single checkbox stands between you and sharing your identity — for example, your ServiceNow or Salesforce account — with your entire organization. In some cases, sharing an application with other users implicitly shares its underlying connections too.

This is a crucial point. Under certain circumstances, users who gain access to a business application will gain direct access to its underlying database implicitly, without direct consent or knowledge. Take an expense management application, for example. There's a big difference between letting people use the application to submit their expense reports and giving them access to the underlying database with everyone's expense reports within it.

Unintentionally, low-code/no-code applications make credentials — the No. 1 resource that attackers are after — easier to obtain.

**Where Do We Go From Here?**

As we've seen, low-code/no-code platforms had to overcome many challenges in making enterprise applications easy to build for everyone from professional to business developers. Sometimes, the solutions come at a cost. In the case of credentials, the ability to move fast is unfortunately coupled with the ability to break things — namely, the enterprise identity model.

It is important to mention here the immense value that low-code/no-code platforms create for the enterprise: reducing the time between idea and execution, lowering the bar for application development, and increasing business velocity.

Platforms cannot be expected to resolve security concerns on their own; it is a responsibility shared between the platform and its customers. To reduce the risk, security teams should familiarize themselves with the ways identities are treated as part of the low-code/no-code platforms their organizations use. Most platforms can be configured to reduce the level of credential sharing and turn off implicit sharing.

More importantly, security teams must realize that low-code/no-code platforms introduce an inherent new risk into the enterprise that cannot be mitigated by traditional monitoring approaches because of the confusion between application and user identities. Therefore, security teams should invest in guiding business developers, reviewing potentially risky applications, and taking action to mitigate risk.

Credential Sharing as a Service: The Hidden Risk of Low-Code/No-Code

This advisory contains mitigations for a Use of Hard-coded Credentials vulnerability in the Siemens Spectrum Power data modelling and monitoring system.

Siemens Spectrum Power Systems

This advisory contains mitigations for a Use of Hard-coded Credentials vulnerability in the Siemens Teamcenter product lifecycle management software.

Siemens Teamcenter

Rakuten Casa version AP_F_V1_4_1 or AP_F_V2_0_0 uses a hard-coded credential which may allow a remote unauthenticated attacker to log in with the root privilege and perform an arbitrary operation.

Published:2022/05/19  Last Updated:2022/05/19

**Overview**

Rakuten Casa provided by Rakuten Mobile, Inc. contains multiple vulnerabilities.

**Products Affected**

*   Rakuten Casa version AP\_F\_V1\_4\_1 or AP\_F\_V2\_0\_0

**Description**

Rakuten Casa provided by Rakuten Mobile, Inc. contains multiple vulnerabilities listed below.

*   **Use of Hard-coded Credentials (CWE-798)** - CVE-2022-29525
    
    CVSS v3
    
    CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
    
    **Base Score: 5.9**
    
    CVSS v2
    
    AV:N/AC:M/Au:N/C:C/I:N/A:N
    
    **Base Score: 7.1**
    
*   **Improper Access Control (CWE-284)** - CVE-2022-28704
    
    CVSS v3
    
    CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
    
    **Base Score: 7.5**
    
    CVSS v2
    
    V:N/AC:L/Au:N/C:C/I:N/A:N
    
    **Base Score: 7.8**
    
*   **Improper Access Control (CWE-284)** - CVE-2022-26834
    
    CVSS v3
    
    CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
    
    **Base Score: 7.5**
    
    CVSS v2
    
    AV:N/AC:L/Au:N/C:C/I:N/A:N
    
    **Base Score: 7.8**
    

**Impact**

*   An attacker who can obtain information about the product housing may log in with the root privileges and perform arbitrary operations - CVE-2022-29525
*   If the product is in its default settings in which is set to accept SSH connections from the WAN side, and is also connected to the Internet with the authentication information unchanged from the default settings, a remote attacker may log in with the root privileges and perform arbitrary operations - CVE-2022-28704
*   The information stored in the product may be obtained as the product is set to accept HTTP connections from the WAN side by default - CVE-2022-26834

**Solution**

**Update the software**  
According to the developer, the fixed software for these vulnerabilities has been released in August 2021, and in the case where the product housing is properly set in accordance with Terms of Installation, the update is applied automatically.

**Vendor Status**

**References**

**JPCERT/CC Addendum**

**Vulnerability Analysis by JPCERT/CC**

**Credit**

CVE-2022-29525  
Narumi Hirai of LAC Co., Ltd. reported this vulnerability to IPA.  
JPCERT/CC coordinated with the developer under Information Security Early Warning Partnership.

CVE-2022-28704  
Hiroki Oshiro and Tagawa, Masaki reported this vulnerability to IPA.  
JPCERT/CC coordinated with the developer under Information Security Early Warning Partnership.

CVE-2022-26834  
Tagawa, Masaki reported this vulnerability to IPA.  
JPCERT/CC coordinated with the developer under Information Security Early Warning Partnership.

**Other Information**

CVE-2022-29525: Multiple vulnerabilities in Rakuten Casa

After dragging their feet for months Owl Labs has released a patch for vulnerabilities that were publicly disclosed a week ago. The company denies the seriousness of the vulnerabilities.
The post Update now! Patch against vulnerabilities in Meeting Owl Pro and Whiteboard Owl devices appeared first on Malwarebytes Labs.

After a decent amount of pressure, Owl Labs has finally released updates for vulnerabilities in Meeting Owl, and Whiteboard Owl cameras. The vulnerabilities were reported to Owl Labs in January,

One of the vulnerabilities, CVE-2022-31460 has been added to the Known exploited vulnerabilities catalog by the Cybersecurity & Infrastructure Security Agency (CISA) and needs to be updated by June 22, 2022.

**Owl Labs**

Owl Labs makes 360-degree video conferencing equipment for classrooms and boardrooms. It produces several pieces of hardware, including the Meeting Owl Pro, a speaker fitted with cameras, microphones and an owl-like face, and a whiteboard camera for hybrid meetings.

**The research**

Researchers at modzero examined the Meeting Owl and found serious defects in the built-in security mechanisms.

And these vulnerabilities were not minor. By exploiting the vulnerabilities an attacker could find registered devices, their data, and owners from around the world. Attackers could also access confidential screenshots of whiteboards or use the Owl to get access to the owner’s network.

The researchers found the existence of at least four different ways to bypass the PIN protection (passcode), which protects the Owl from unauthorized use.

**The vulnerabilities**

The Common Vulnerabilities and Exposures (CVE) database is a list of publicly disclosed computer security flaws. Its goal is to make it easier to share data across separate vulnerability capabilities (tools, databases, and services). Below you will find the CVEs assigned to the vulnerabilities:

*   CVE-2022-31460: Owl Labs Meeting Owl 5.2.0.15 allows attackers to activate Tethering Mode with hard-coded credentials. The tethering mode turns the Owl into an access point (AP) by creating a new Wi-Fi network while staying connected to the existing Wi-Fi. This basically allows any authorized user to turn the Owl into a rogue access point. A rogue access point by definition constitutes a wireless access point installed on a secure network without explicit authorization from a local network administrator. Hard-coded credentials is where embedded authentication data, like user IDs and passwords, are included the source code of the device.

**Passcode bypasses**

*   CVE-2022-31463: Owl Labs Meeting Owl 5.2.0.15 does not require a password for Bluetooth commands, because only client-side authentication is used. To extend the range of devices and provide remote control by default Owl Labs uses the Bluetooth functionality. The vulnerability makes it possible for an attacker in proximity to control the devices to the extent that they can disable any set passcode.
*   CVE-2022-31462: Owl Labs Meeting Owl 5.2.0.15 allows attackers to control the device via a backdoor password which can be found in Bluetooth broadcast data. A hardcoded backdoor passcode exists which depends on the serial number of the device. This hardcoded passcode is the SHA-1 hash representation of the devices’ software serial number. The hash is broadcasted as the name of the Owl over Bluetooth Low Energy (BLE). So an attacker in close proximity can simply get hold of the hardcoded backdoor passcode. Also, it is possible to generate all existing serial numbers by a script.
*   CVE-2022-31461: Owl Labs Meeting Owl 5.2.0.15 allows attackers to deactivate the passcode protection mechanism via a certain message from the companion app. An attacker would have to be close enough to the Owl to communicate over BLE to exploit this vulnerability.
*   CVE-2022-31459: Owl Labs Meeting Owl 5.2.0.15 allows attackers to retrieve the SHA1 hash of the passcode over BLE. It is possible to brute-force the passcode from the hash in seconds since it consist only of digits. An attacker with knowledge of the BLE endpoint can use this knowledge to control any Meeting Owl in their proximity.

**What is Bluetooth Low Energy (BLE)?**

BLE is a Bluetooth protocol which launched in 2010, especially designed to achieve low power consumption and latency, while at the same time accommodating the widest possible interoperable range of devices. The BLE protocol also does not require paring between the sender and receiver and it can send authenticated unencrypted data.

For those interested, a full disclosure report by modzero is available online.

**Slow pokes**

Another worrying factor in the report is the timeline of disclosure which gives the impression of an uninterested attitude and unwillingness to fix on the part of Owl Labs. Given the seriousness of the vulnerabilities and the nature of Owl Labs’ clients one might have wished it was treated with more urgency.

The researchers shifted the time of disclosure several times until they were finally fed up with the unresponsiveness of Owl Labs. And only after the vulnerabilities had been disclosed Owl Labs came up with patches for the vulnerabilities. On June 6, 2022, Owl Labs stated that all high-security issues had been addressed, and said it was in the process of implementing a few additional updates. Earlier Owl Labs said that the likelihood that its customers were affected by these issues is low.

**Mitigation**

Meeting Owl Pro and Whiteboard Owl will automatically send over the air software updates to Owls that are connected to Wi-Fi and plugged into power over night.

To determine what version of software is on your Owl, follow these steps.

If your Owl’s software is out of date, please follow these instructions for how to update your Owl’s software.

We are pretty sure this owl will have a tail and will keep you updated about any developments here.

Update now! Patch against vulnerabilities in Meeting Owl Pro and Whiteboard Owl devices

USR IOT 4G LTE Industrial Cellular VPN Router v1.0.36 was discovered to contain hard-coded credentials for its highest privileged account. The credentials cannot be altered through normal operation of the device.

Title: USR IOT 4G LTE Industrial Cellular VPN Router 1.0.36 Remote Root Backdoor  
Advisory ID: ZSL-2022-5705  
Type: Local/Remote  
Impact: Exposure of Sensitive Information, Security Bypass, System Access, DoS  
Risk: (5/5)  
Release Date: 20.04.2022

**Summary**

USR-G806 is a industrial 4G wireless LTE router which provides a solution for users to connect own device to 4G network via WiFi interface or Ethernet interface. USR-G806 adopts high performance embedded CPU which can support 580MHz working frequency and can be widely used in Smart Grid, Smart Home, public bus and Vending machine for data transmission at high speed. USR-G806 supports various functions such as APN card, VPN, WIFIDOG, flow control and has many advantages including high reliability, simple operation, reasonable price. USR-G806 supports WAN interface, LAN interface, WLAN interface, 4G interface. USR-G806 provides various networking mode to help user establish own network.

**Description**

The USR IOT industrial router is vulnerable to hard-coded credentials within its Linux distribution image. These sets of credentials are never exposed to the end-user and cannot be changed through any normal operation of the device. The 'usr' account with password 'www.usr.cn' has the highest privileges on the device. The password is also the default WLAN password.

**Vendor**

Jinan USR IOT Technology Limited - https://www.pusr.com

**Affected Version**

1.0.36 (USR-G800V2, USR-G806, USR-G807, USR-G808)  
1.2.7 (USR-LG220-L)

**Tested On**

GNU/Linux 3.10.14 (mips)  
OpenWrt/Linaro GCC 4.8-2014.04  
Ralink SoC MT7628 PCIe RC mode  
BusyBox v1.22.1  
uhttpd  
Lua

**Vendor Status**

\[10.04.2022\] Vulnerability discovered.  
\[14.04.2022\] Vendor contacted.  
\[19.04.2022\] No response from the vendor.  
\[20.04.2022\] Public security advisory released.

**PoC**

usriot\_root.py

**Credits**

Vulnerability discovered by Gjoko Krstic - <gjoko@zeroscience.mk\>

**References**

\[1\] https://packetstormsecurity.com/files/166813/  
\[2\] https://cxsecurity.com/issue/WLB-2022040086  
\[3\] https://exchange.xforce.ibmcloud.com/vulnerabilities/224930  
\[4\] https://www.exploit-db.com/exploits/50894  
\[5\] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29730  
\[6\] https://nvd.nist.gov/vuln/detail/CVE-2022-29730

**Changelog**

\[20.04.2022\] - Initial release  
\[03.05.2022\] - Added reference \[1\], \[2\] and \[3\]  
\[13.05.2022\] - Added reference \[4\]  
\[29.05.2022\] - Added reference \[5\] and \[6\]

**Contact**

Zero Science Lab

Web: https://www.zeroscience.mk  
e-mail: lab@zeroscience.mk

Tag

#hard_coded_credentials