Full Disclosure mailing list archives

[CVE-2014-3260] Crypto implementation flaws in Pacom GMS System


From: XPD Advisories Team <security-alert () xpd se>
Date: Wed, 09 Dec 2015 17:37:28 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

                      XPD - XPD Advisory
                        https://xpd.se

        Crypto implementation flaws in Pacom GMS System

Advisory ID: XPD-2015-001
CVE reference: CVE-2014-3260
Affected platforms: Pacom 1000 CCU ("Base Station") and Controllers (RTU)
Version: All versions are affected
Date: 2013-Oktober-10
Security risk: High
Vulnerability: Crypto implementation flaws in Pacom GMS System
Researcher: Joachim Strombergson, Fredrik Soderblom, Peter Norin
Vendor Status: Notified / Patch available
Vulnerability Disclosure Policy:
 https://xpd.se/advisories/xpd-disclosure-policy-01.txt
Permanent URL:
 https://xpd.se/advisories/XPD-2015-001.txt

=====================================================================

Summary:

The Pacom 1000 CCU and controllers (RTU) is used in security alarm
 installations all over the world. The flaws we have found can bypass
 the security of any unpatched installation.

"The purpose of a Pacom Controller is to control, monitor, and maintain
security for a remote site. It is located at the site itself and performs
 all alarm and door control functions."
 - http://www.pacom.com/field-controllers.php

"Pacom security solutions are installed in over twenty countries on seven
 continents." - http://www.pacom.com/our-customers.php

Detailed description:

The Pacom 1000 implementation have several serious implementation flaws.

These vulnerabilities could in a worst case scenario lead to a full
 compromise of the protocol between the controller and the base station,
 rendering an alarm system useless.

Potentially a large number of sites could be affected by the described flaws.

PRNG:

The PRNG used is of a type known as a Linear Congruential Generator.
 This type of generator are known to provide random numbers with less
 than perfect uniform distribution. The PRNG is a 16-bit generator.
 This means that the generator can only generate 2**16 numbers in a
 sequence before it must be reseeded. There is no information about
 how the generator is seeded from start nor how it is reseeded.

A simulation in Dieharder shows that the used algorithm fails every
 test except for one, where it receives the result 'Weak'.

The Linear Congruential Generator can be broken by observing values
 generated by consecutive iterations of the PRNG. The system creates
 32-bit random numbers by extracting 8-bits from four consecutive
 16-bit words numbers generated by the PRNG. This means that by
 observing a single 32-bit word, an attacker has in fact half the state
 information (8 out of 16 bits) from four iterations of the generator.

MAC:

A Message Authentication Code (MAC) is generated and added to each
 message sent between CCU and Controller. The MAC generator generator
 used is not based on any well-known secure MAC functionality such as
 HMAC or OMAC. Furthermore the generated MAC is only 32 bit.

Master Code:

There is a functionality for substitution detection. According to
 Pacom the functionality is based on a proprietary Pacom encryption
 method. Key to the functionality is a a 24-bit randomly generated
 value called Master Code. The Master Code is also used to generate
 the 128-bit AES key used with the substitution detection algorithm.
 Hence the effective strength of the key is not 128 bits, nor 104 bits
 (128 - 24) but 24 bits. A very short key with low security.

Unfortunately it appears that the aforementioned (16 bit only),
 less than optimal, PRNG is used to generate the Master Code, thus
 reducing it's effective strength to 16 bit.

The Master Code is distributed from CCU to CPU-cards and other CCUs
 as well as GMS units (for logging purposes) in clear text. This means
 that the code potentially is sent unprotected over private networks,
 corporate networks, public networks etc.

Substitution detection:

According to Pacom documentation the "substitution detection involves
 appending a 128-bit check code to the controller heartbeat response
 messages. The check code is calculated from a combination of a
 hard-coded constant value, the controllers master code, and the
 message data. In essence it is another type of MAC, but one that
 employs the master code."

The implementation of the substitution detection uses a "check code"
 which is said to be 128-bits long and is appended to response messages.
 However due to a design flaw, the code is only 64 bit.

In total the heartbeat response message is 5 bytes (40 bits) long:

 Byte 1: The message type (e.g. heartbeat response)
Byte 2: A value based on random numbers sent in the heartbeat command from the CCU
 Byte 3: The controller summary status
 Byte 4: The heartbeat sequence number (zero or one)
 Byte 5: Always zero

Of the five bytes in the heartbeat response message, two bytes (4 and 5)
 are either one or zero, or always zero. Byte 3 is a simple status. So,
of 40 bits, 32 bits are most likely predictable and the remaining 8 bits
 is probably choosen based on the weak PRNG. This means that a big part
 of the response  message can be guessed.

The so called "128-bit check code" is then calculated over these 5 bytes
 using the aforementioned flawed Master Code and a 2 byte address of the
controller, forming a 40 bit key, which is used with a hard coded constant
 to form an AES-128 key.

The resulting "128-bit check code" from the AES encryption is XOR:ed with its own cleartext. This means that there is a direct path from cleartext to
 ciphertext bypassing the AES encryption. This leaks information about
 the cleartext as well as opening up for chosen plaintext attacks.

Hard coded constants:

The security functionality uses several hard coded, secret constants for
 random number generation, MAC calculation, Substitution detection
 algorithm etc. Unfortunately, the way these constants are used,
 information about them are leaked through the very messages, which
 opens up for recovery of the constants. If the constants are recovered
 and thus system security is lost, the units must be reprogrammed in
 the field or even replaced.

=====================================================================
Conclusion:

We do not recommend relying on the security features in the system and
 the system should be viewed as an unprotected system.

If the system is to be used, separate communication security mechanism
 should be added.

However, the usage of hard coded constants in the units and the associated
 need for field service or replacement if a breach occurs, makes us
 recommend that the system needs severe redesign before it is ready for
 production use.

We questions if the system has been designed with any knowledge of what
has been known good security practices since at least 30 years, nor good
 engineering practice.

=====================================================================
Versions affected:

All versions of Pacom 1000 (CCU & RTU) - According to Pacom, this firmware
 will not be fixed. Customers are advised to switch to the EMCS
 platform instead.

All versions of EMCS (Pacom .is) prior to 1.3

The vendor reports that the following versions are patched:
 EMCS (Pacom .is) version 1.3 and above

=====================================================================
Credits

This vulnerability was discovered and researched by Joachim Strombergson
 from Assured AB, Fredrik Soderblom and Peter Norin from XPD AB.

=====================================================================
References

https://en.wikipedia.org/wiki/Linear_congruential_generator
https://en.wikipedia.org/wiki/Diehard_tests

=====================================================================
History

2013-10-10 Initial Discovery
2013-10-22 Initial attempt to contact the vendor
2013-11-12 Reply from Niscayah, case is assigned to internal resource
2014-05-07 CVE-2014-3260 is assigned
2014-06-05 Draft of the advisory sent to the vendor
2014-09-01 Pacom notifies us that fixed firmware (EMCS only) is ready
2015-12-08 Public disclosure

=====================================================================
About Assured

Assured AB is a privately held company with headquarters in Gothenburg,
 Sweden. Established in 2015, Assured is an independant security
 consultancy firm that provides expert knowledge, advisory and
 design of IT- security solutions.

http://assured.se

About XPD

XPD AB is a privately held company with Headquarters in Stockholm, Sweden.
 Established in 2002, XPD AB is an independent security consulting and
research firm, with a focus on security and perimeter security solutions.

https://xpd.se

=====================================================================
Disclaimer and Copyright

Copyright (c)2015 XPD AB and Assured AB. All rights reserved.
This advisory may be distributed as long as its distribution is
 free-of-charge and proper credit is given.

The information provided in this advisory is provided "as is" without
 warranty of any kind. XPD AB and Assured AB disclaims all warranties,
either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall XPD AB or Assured AB,
 or its suppliers be liable for any damages whatsoever including direct,
 indirect, incidental, consequential, loss of business profits or
special damages, even if XPD AB or Assured AB, or its suppliers have been
 advised of the possibility of such damages.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWYCTaAAoJEH47YPoA7U9kecIQAJP3eHCA6zdz3sq1bAPg4JOc
SBmq/auoraVpcucBzjVkGy8qtCF12mu0Gf2Kn6zwCtUcBmfjAo97HZYFx582ofOy
K0ZGkA06tfGWJthDZ1eyeotQq9yBRLl1un1hGmrM/CvyRMp7KDd2jUptBps6Ddrk
dl5a8+tMcQkedSV+dNDLwVpLWn8/hsDL8YjbZCeVomNtgceTb07hMv6zqrf3TgYZ
yyq7xlLNzEyQSXyF0qF+yKsQ0HQyAnzQyoyzzYjeSbBBhvjeb/6x0S8t0QuP2Hqy
cM+zNn/zzPoaubHFVUMi0tluhr/mqagrdmugmWG5cEfStmZYKJLkM/1EkFZDmlUF
fuWQ/YrIgYU8twBwqzO+9iUdMM6gqRNaKIO5nN+1ivlYwxoVJ5N+gYCUbEZCGQac
JDWGuYtHUpEzL/E2WrLq6iTpxutn1iAuyDM67/vsJaucLngLHJdW/iCIx4OVNdn4
caXMo4UZbJUzzu1OOCtCuYpUZHIbLuuVZkmb3ihj5UL/Z9OXyGKv4XpFed8xqydx
FnB+dsnaG1HKyKIfNUVl7uiODEe2qiPUdmdY7J/0UWksYmoAPq77rmqhfEIH9jaU
0nq3frmUk70XdEjPG9oIr1Mw02ugIS8cYPM7zn57TskNnBnrlnO2PkBzSBOGJy08
NzycvpVV7wdtvgKeZHum
=b7KM
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/


Current thread: