Give Me the Green Light Part 1: Hacking Traffic Control Systems
In this series of blog posts I’ll be discussing my finding dealing with traffic controllers and other traffic systems. I had hoped to present the information at DefCon but my CFP wasn’t accepted. This multi part series will start with my attempt at responsible disclosure, finding vulnerabilities in traffic controllers, sourcing hardware and getting it running in a lab, and just how broken and behind the technology curve the traffic industry is.
How this all started
I was invited to speak at the Intelligent Transportation Society of America Conference in Arizona on Traffic Systems through the eyes of an attacker. While I’ve had several engagements with government entities and Departments of Transportation, I had never been engaged where the scope was explicitly traffic control systems. Thanks to the generosity of one of our OT Partners, I was given access to their lab that included a fully working traffic cabinet and technical resources to bounce ideas off, I was able to learn how Traffic Control Systems worked in a safe environment.
After getting familiar with how Traffic Control Systems worked, I knew I needed to expand my research and so began my quest to purchase Controller Hardware. I’ll be detailing the steps of how to purchase used equipment and get it running in my next blog.
What does a Traffic Controller do
A traffic signal controller is a crucial component in the management of road traffic at intersections. Its primary function is to control the sequence of traffic lights (red, yellow, and green) to ensure the orderly and safe flow of vehicles and pedestrians. A technician configures the traffic controller with the sequence that determines how long a light stays green or red as well as who gets to go when. There are several other components that are also crucial for this system to work that will be covered in a later blog.
Finding a Vulnerability
The correct way to do this write-up would be to start from the boring and mundane parts of acquiring hardware and figuring out how to power it on and get it running, but sometimes it’s okay to eat your dessert before dinner and get to the good stuff first.
I’d love to write a long detailed blog about getting a root shell via UART or extracting the firmware via JTAG and then reversing it, but the honest truth is I found a vulnerability in the webapp in the first 15 minutes of having the unit online and it was the first thing I tried.
Vulnerability Details
It should come as no surprise that Critical National Infrastructure is exposed to the open internet without any protection, for this reason I wanted to start with a traffic controller that has a web interface. I started with the Intelight X-1 because it was the cheapest and most readily available controller I had access to.
After configuring the IP address information from the front panel of the controller I port scanned the IP and found the SSH, SNMP, and HTTP ports opened. I accessed the web interface via a browser and was surprised to find no authentication was configured. I began poking around the web interface trying to figure out how to enable it as my first goal was to find an authentication bypass.
Under the Administration tab I found the web security setting. I was shocked to see the default credentials in clear text. I hovered over the Web Security button and made note of the URL of the page http://192.168.1.215/cgi-bin/generateForm.cgi?formID=142. I enabled web security and refreshed the page and was greeted with a login prompt, I logged in with the credentials and once again began poking around the web interface. I opened a new private browser and navigated out to the URL for Web Security and to my surprise I was able to access it with no authentication. I checked to make sure I was in a private browser surely I missed something. I navigated to the base IP and was prompted for authentication, I pasted in the URL for the Web Security Page and was once again back with no authentication. I thought okay surely this is a fluke, I tried on another device and found the same behavior. I could access the URL but could I make any changes, on a new device that had never authenticated I changed the Web Security Setting to disabled and hit apply expecting nothing to happen. However, the setting now showed disabled. I navigated to the base URL and found I now had full access to the controller without needing to login. I re-enabled the setting and tested with a variety of devices and browsers all with the same result.
POC Video
Impact
A full list of attacks will be detailed in a later blog, but the main takeaway is once an attacker bypasses the authentication prompt they have full access to make any changes they want on the controller. An attacker can increase the duration of a specific phase, upload their own configuration, or throw the intersection into 4 way flash mode.
Responsible Disclosure
Having validated my findings and sharing them with my peers it was time to report my findings to the vendor. Q-Free began acquiring shares in Intelight starting in 2015, it’s unclear when they took over majority ownership and assimilated them under one brand. On the companies contact us form they have a section specifically for reporting vulnerabilities.
I sent an email fully expecting someone from the engineering team to reach out to me but no response just crickets. What I wasn’t expecting was the response I received 10 days later.
Response from the vendor
Instead of a response from the engineering team letting me know the product was end of life or requesting additional details I instead got a lengthy letter from the General Counsel. My first thought was you’ve got to be kidding. I’ve included the full response below but the TL:DR version of the letter was.
You “think” you found a vulnerability, and if you did well the product is end of life, and even if it’s still in use your findings don’t meet the criteria of our responsible disclosure so it’s not valid and its unsolicited, we don’t have the resources to analyze end of life software and we only accept vulnerabilities on products we currently sell, but confirm in writing you aren’t going to publish any information about this because it could impact critical national infrastructure. Also your email included no information how you obtained access to the controller and for that reason should you publish the information about your findings we’ll take “appropriate” action under the computer Fraud and Abuse Act, 18 USC 1030.
My Response
I thought long and hard about how I should respond to the letter. Should I pass it on to my attorney? Should I send them the screenshots of my eBay purchases? Should I notify US-CERT? Should I reply with the exact text of the CFA that includes a provision for Security Researchers acting in “Good Faith”. In the end I decided the best response was no response, as my report was unsolicited and the manufacturer clearly didn’t want to work with me there was no point in pushing the issue. While some will say disclosing an authentication bypass in an end-of-life controller is a risk to National Security, I’ll be honest and tell you that the majority of these traffic controllers exposed to the internet don’t even have authentication enabled.
I posted a redacted version of the vendors response on my LinkedIn and was blown away by the outpouring of support. Outside of 2 or 3 comments the overwhelming majority supported me and were equally appalled by the manufacturer’s response. This support encouraged me to keep pushing the issue and not let a big company attempt to silence me with legal threats.
I knew my next step would be to get a CVE for the issue. This is my first time submitting a CVE and it was interesting trying to navigate the process. After a lengthy back and forth with MITRE I received my first CVE “CVE-2024-38944”
That’s the end of this story. However, in the next series of blogs we’ll dive into how to acquire and setup your own traffic controllers at home and why authentication bypasses are completely irrelevant because of a little-known protocol NTC/IP.
