51–60 of 94 posts
If you just want a green light an easier way to get one is to flash the infrared strobe pattern that gives fire trucks green lights. Seems simpler.
Using one of these will get you 6 months in federal prison btw.
Earlier quoted context omitted.
Because of course a controller for a traffic light needs gigabit fiber internet connectivity....
That’s not the scary thing here. Better to future-proof it. Running presumably unencrypted SNMP over shared lines is sketchy.
Earlier quoted context omitted.
Could you help me understand what you are suggesting is done instead? To me, it seems like you're suggesting that vulnerabilities are just left in play until someone malicious comes along and decides to do some real damage. But that seems so silly that I must be missing some alternative that you're thinking about.
You've noticed an issue. You let the manufacturer know, and you let them decide for the next steps. No ultimatum to threaten to disclose to the public or to ruin their reputation, it's not your business. In the meantime, you keep it for yourself. You helped: no lawyers, no problems. If really there is a safety issue, after a reasonable period of time you can inform the regulators, as it is their job to assess safety.…
I found an authentication bypass in a door card access controller. Per the installer I was working with the units are regularly exposed directly to the Internet. (Heck, the installer was trying to cajole my Customer into doing it for "remote support" reasons.)
Given that there's an impact to the public-- albeit not necessarily directly safety-related-- I think this kind of vulnerability is still "my business".
If I owned one of these controllers and it was "protecting" my property I'd want to know.
(Fun aside: The installer went so far as to suggest that because their other Customers expose these units to the Internet-- particularly a small bank who is "audited" for "security"-- it would be okay if my Customer did it. Needless to say, my Customer did not. I let my Customer know about the auth. bypass and we kept the unit locked down in a VLAN w/ a restrictive ACL, but I never publicly disclosed... too afraid of hostile response from the vendor. Eventually a researcher did find it and disclose it publicly, at least...)
Earlier quoted context omitted.
I am aware of a municipality local to me that, as part of a franchise agreement for a new ISP entering the community, had the ISP run fiber to every traffic cabinet. They're connected back to the city network in a VLAN that's "behind the firewall". >sigh<
Because of course a controller for a traffic light needs gigabit fiber internet connectivity....
This is a great introduction to the mess that is traffic signal controllers! The reality is perhaps even worse than the article suggests. The majority of signal controllers support the NTCIP "standard" MIBs in addition to the "proprietary" MIBs that are provided through FreeTheMIBs. These "standard" MIBs are defined in standards like NTCIP 1202[1], which are freely available online through the NTCIP group. These stan…
> for any traffic controller you happen to find on a network But how would one get on such "a network" in the first place? I assume it would involve physically opening a (hopefully locked) cabinet in public near the road? So just a bit of cutting/picking reveals an ethernet port, you drop in a wireless bridge, close it back up, and then hack from a parked car?
A number of agencies put these controllers directly on the Internet (a search on Shodan for some telltale strings produces concerning numbers of hits).
Others will use one giant flat network across their entire city - so if you get access at once location, you have access to the entire network. This could mean accessing a "rural" or quiet location, but then actually attacking a much busier one.
Earlier quoted context omitted.
Generally no, this is something from fiction. I'm mostly familiar with North American traffic signal control, and in those traffic cabinets there is a device known as an "MMU" (Malfuction Management Unit) which acts as a safety monitor for the rest of the traffic cabinet. That device will catch so-called "conflicts" (two conflicting directions green at the same time) and put the intersection into a fail-safe state (u…
> I'm mostly familiar with North American traffic signal control, and in those traffic cabinets there is a device known as an "MMU" (Malfuction Management Unit) which acts as a safety monitor for the rest of the traffic cabinet. Presumably the logic for this MMU could be implemented in strictly electrical components (relays or such). That would give me the most comfort (since its functionality would be, literally har…
The majority of MMUs on the market that I have had a close look at implement safety-critical functionality on a microcontroller with updatable firmware. Some can even be updated over IP. I haven't had the opportunity to dig into if those firmware upgrades are signed or otherwise integrity-protected.
The standard unfortunately does not specify a functional safety standard or other measures to ensure absolute safety.
In theory it would be possible to implement it in discrete logic (or an FPGA or other formally-verifiable process), but as far as I know no manufacturer has done so (I'd love to be wrong!)
Earlier quoted context omitted.
> for any traffic controller you happen to find on a network But how would one get on such "a network" in the first place? I assume it would involve physically opening a (hopefully locked) cabinet in public near the road? So just a bit of cutting/picking reveals an ethernet port, you drop in a wireless bridge, close it back up, and then hack from a parked car?
I am aware of a municipality local to me that, as part of a franchise agreement for a new ISP entering the community, had the ISP run fiber to every traffic cabinet. They're connected back to the city network in a VLAN that's "behind the firewall". >sigh<
This is a great introduction to the mess that is traffic signal controllers! The reality is perhaps even worse than the article suggests. The majority of signal controllers support the NTCIP "standard" MIBs in addition to the "proprietary" MIBs that are provided through FreeTheMIBs. These "standard" MIBs are defined in standards like NTCIP 1202[1], which are freely available online through the NTCIP group. These stan…
Why wouldn't defcon allow this to be presented?
> my CFP wasn’t accepted Don't know their specific process, but this sounds like "we got a bunch of submissions and yours didn't make the cut." Honestly, rather than this being a nefarious "too dangerous even for defcon" like your wording suggests, I think the author knows why it didn't make the cut and snarkily addressed it: > I’d love to write a long detailed blog about getting a root shell via UART or extracting t…
The original author of the blog post was invited to speak at an ITSA.ORG conference, and present as through the eyes of an attacker. Thus, the perspective he posits.
There is nothing untoward in his observations but I can see why DefCon might hold off on letting him present his findings.
The ITSA is based in Washington D.C. and has a fairly large membership consisting of state's DOT's (primarily western U.S.), tech companies, car companies, engineering design companies, consulting firms, etc.
Their vision is a better future transformed by transportation technology and innovation. Safer. Greener. Smarter. For all.
A lot of automation is factored into that vision including the use of autonomous vehicles, high-speed inter-connected systems, their attendant technologies, and of course, cyber-security.
Personally, I'm dismayed the U.S. in only now awarding grants for these studies. Maybe the whole thing got sidetracked when our focus shifted to COVID, I don't know. But it does seem as though we're behind the private and governmental initiatives going on in Asia.
2: https://itsa.org/wp-content/uploads/2024/07/Cybersecurity-an...
3: https://itsa.org/wp-content/uploads/2023/01/2026-ITS-America...