• If posting about a radio issue: Include the HOST, DSP and UCM/secure firmware versions, flashcode and CPS version you're using along with the operating system info. This is critical information.

MOTOTRBO - Restricted Access to System, security vulnerability

Status
OP
Mars

Mars

Prolific Contributor
CS Forums $upporter
Joined
Dec 21, 2011
Messages
4,993
It was explained to me (and noted in Motorola's response above) the DMR/TRBO format was designed to mimic analog mode operations. I understand that.

But when it comes to RAS, there should at least be an option in CPS so subscriber radios can be provisioned to accept "clear" voice/data on simplex (talkaround) mode, or only action voice/data which is encoded with the RAS key.

I believe this is something which is now being considered. It's more of an oversight than a "bug". RAS, as originally designed, is working as-advertised. It keeps unauthorized radios from accessing/using a system. But the radios themselves remain unprotected.
 
M

madden

Not Registered
A temp fix for this issue is to program your subscribers for Slot 2 only..as you can't send the correct codes to open the subscriber up then. Sure you lose out on a time slot, but at least it's secure again.

Also to NOTE: this type of "open" environment is also used in Capacity Plus and Digital Conventional (non RAS). Meaning you can talk/exploit a radio (while the rest slot is on Slot 1), in the same manner. Using the built in encryption helps with the removal of this.
 

com501

Prolific Contributor
CS Forums $upporter
Joined
Jan 18, 2013
Messages
2,847
A temp fix for this issue is to program your subscribers for Slot 2 only..as you can't send the correct codes to open the subscriber up then. Sure you lose out on a time slot, but at least it's secure again.

Also to NOTE: this type of "open" environment is also used in Capacity Plus and Digital Conventional (non RAS). Meaning you can talk/exploit a radio (while the rest slot is on Slot 1), in the same manner. Using the built in encryption helps with the removal of this.

Encryption has no effect. I tested that specifically also. Neither basic or enhanced encryption defeats the return messaging, as the signalling protocols ignore the data packets associated with voice privacy. I also verified with a dealer contact I have in the UK that AES encryption doesn't stop this exploit either.

Slot 2 would do it, though, although I am wondering about the two slot simplex sync protocol for Gen II radios, if that could be used to spoof Slot 2 on a Gen II radio.
 
OP
Mars

Mars

Prolific Contributor
CS Forums $upporter
Joined
Dec 21, 2011
Messages
4,993
Copy of letter sent to Motorola, per their request.


To: Motorola Solutions Inc. - MOTOTRBO Product Group
From: Mars; com501 (Names redacted from document)
Date: Dec. 10, 2014
Subject: MOTOTRBO product security concerns (MOL case: 24159837)

Recently, it was reported MOTOTRBO subscriber products operating on a system configured to utilize Restricted Access to System (RAS) functionality are not operating as expected, when queried in “talkaround” mode by outside radios not provisioned with the active RAS key.

It was determined by our group as well as Motorola, RAS is performing as-designed and the fault is not centered on an error in RAS design; it was erroneously assumed RAS functionality applied to subscriber radios.

The subscriber security concerns are unresolved. It is our collective opinion a significant security threat still exists by means of how subscriber equipment handles off-network voice and data queries from unauthorized/malicious entities.

Several scenarios were discussed during a telephone conversation with [redacted] from the TRBO Product Support Group. Examples of malicious actions are:

- A malicious entity can inhibit (disable) radios which are used in a critical operating environment, such as underground mining operations;

- A malicious entity can send “spoofed” text messages to workers handling cash, causing them to make deliveries at incorrect locations;

- A malicious entity can initiate a Private Call to a specific worker, causing them to relocate at an inopportune time;

- A malicious entity can send telemetry commands to a base radio programmed to control external circuits such as an overhead door and outside parties can gain unauthorized entry.

With information from third-party DMR air-interface decoders and data contained on hobbyist websites, subscribers’ radios can be disrupted and manipulated.

Customers (with RAS-enabled systems) are under the impression their infrastructure is secure and cannot be interrupted. Of particular concern is the malicious activation of Remote Monitor, which ties up the entire system. The simplex attack causes the target radio to activate the repeater, where unbeknownst to the subscriber, their mic is hot. The unauthorized third-party can monitor audio with third-party DMR applications or hardware. During the operation, system access is denied to all users.

Motorola can enhance the security of the MOTOTRBO product line by expanding upon the functionality of the RAS featureset. A recommendation is to require the presence of a valid RAS key before a subscriber radio actions any received transmissions. This can be a simple enhancement within CPS, where on a per-channel basis, reception of both types of communications (open/RAS or RAS-only) are selectable in a RAS-enabled channel. (Firmware changes are also required.)

Any enhancement(s) to the RAS functionality are most appreciated and indicative of Motorola’s awareness of product and customer security needs.
 
OP
Mars

Mars

Prolific Contributor
CS Forums $upporter
Joined
Dec 21, 2011
Messages
4,993
Reply received (today) from Motorola:

Thank you for your Feedback and suggestions on improving the RAS feature. - we value your suggestions and feedback on how we can make our products better for our customers.

The information you have provided has been forwarded on to the business team. Your suggestions will be reviewed and considered during our next portfolio planning and prioritization meeting, which take place quarterly. If at that time we determine that your request aligns with our overall product portfolio priorities and strategic objectives, it would then be fully scoped by our engineering teams and assigned to a future hardware/software release for implementation. You may be contacted by one of our product managers should we require additional information to complete this process.

While we review every request we receive, we cannot guarantee that every request will be pursued and/or that the implementation will take place in the timeframe you may desire to pursue an immediate business opportunity. We normally plan and allocate software releases approximately 12 - 15 months ahead of market availability. There is a longer timeframe for hardware related items.

We appreciate your business and your contributions to our new product planning and definition process.
 

com501

Prolific Contributor
CS Forums $upporter
Joined
Jan 18, 2013
Messages
2,847
Well, we brought it to their attention. Perhaps getting 'C' and the others involved will at least invoke some discussion at Plantation and elsewhere. I will have my crew followup at IWCE if we haven't heard anything by then.
 
OP
Mars

Mars

Prolific Contributor
CS Forums $upporter
Joined
Dec 21, 2011
Messages
4,993
Sounds good. I just hope it isn't passed up because it will not make them money. Sometimes it's not about money.
 

xpr8300

Prolific Contributor
CS Forums $upporter
Joined
Mar 1, 2012
Messages
636
As someone who has sat in on product roadmap meetings, I can assure you it IS all about the money.

Non roadmap patches are determined by existing customers (ie people who have spent lots of money already) or project/Rfp based (ie if we employment this feature, we will sell to this and other customers)

Sadly. I don't see this request as fitting in either, hence the boilerplate blow off letter
 

com501

Prolific Contributor
CS Forums $upporter
Joined
Jan 18, 2013
Messages
2,847
Fortunately, my company represents a couple of those customers that actively use these features and have spent 'a lot of money'. Unless multi-state systems are not a lot of money anymore. We are going to push ahead on this. A lot. Personally, the 20 plus repeater system I manage and built is also vulnerable, and I have a stake in making this work too.
 

Astro Spectra

T¹ ÆS Ø - Moderator, CS Forums $upporter
Staff member
CS Forums $upporter
Joined
Nov 22, 2012
Messages
1,062
As many of you may know there is an option in the P25 platforms to 'beep' on PTT when not secure, annoying as hell but very useful in some circumstances.

It would seem to me that a similar concept but in reverse could work here. In allowing an analogue of an analog system Motorola should warn users of possible impersonation. A warning beep when the squelch opens in direct mode would do that if the beep was generated in the receiving subscriber's radio based on missing infrastructure credentials.
 

xpr8300

Prolific Contributor
CS Forums $upporter
Joined
Mar 1, 2012
Messages
636
I guess my point was that in order for this to get fixed it's going to have to be tied to future revenue. The exact phrase I've heard in similar meetings was "okay I get it there complaining but is there anyone else? And this was on a statewide radio system. The only way we were able to get the feature fixed is we had to prove that multiple customers were going to spend money with a competitor if this feature was not implemented properly. Even then we had to prove it by having contacts from those multiple companies concur. I fully agree this is a bug that needs to get fixed I just feel like that if it's not going to generate revenue or if it will not push someone to a different product then they don't have a lot of incentive to dedicate engineering resources for it
 
OP
Mars

Mars

Prolific Contributor
CS Forums $upporter
Joined
Dec 21, 2011
Messages
4,993
XPR8300: Unfortunately, you are likely correct with your assessment of how it will be handled. I want to be optimistic about it, and will give them the opportunity (over the next two quarters) to consider and possibly implement any changes.

Hopefully, the information about how the bug works will not be used maliciously to attack customers/systems. I am responsible/accountable for posting the information here (publicly), and I did so because I feel customers have the right to know about what measures/training needs to be considered so users are aware the bug exists.

Some administrators may consider reprogramming subscriber radios so they cannot be disabled/inhibited, or "remotely monitored", until this matter is (potentially) corrected.
 

com501

Prolific Contributor
CS Forums $upporter
Joined
Jan 18, 2013
Messages
2,847
That is the tack we are taking at this point. Reprogram to inhibit malicious use.
 
Status