When I started my programming journey at 42 London, I did not know what to expect. It was my first approach to real programming education, and I just knew, after doing the piscine, that it would be the low-level language of C. What I did not expect is that I would also have hands-on experience with networking concepts and servers, which make me see everyday technology in a different way.
One day, while waiting to take the bus, I noticed that the electronic display instead of showing arrival times for the buses, displayed an error message. To most people it looked like a harmless glitch. But to me, deeply interested in cybersecurity and contemplating it with my new programming-tech-driven filter, it raised some serious cybersecurity questions. Could this reveal TFL (Transfer for London) network vulnerabilities?
First, and using the knowledge of network structure and server setups, I started breaking the information down, just like when debugging my C code.
Breaking down the bus stop data
Networking structure
The stop number is 3257, and the System ID is 1376. This means there are at least another 3256 stops in the same network as this one. And each ID might represent multiple stops (approximately 2.37) but there are no half-stops, so we can say each ID represents 2 stops. Makes sense! Perhaps both directions of a route are under the same ID.
LAN IP & Network exposure
The LAN (Local Area Network) IP address is marked as XXX.XXX.XXX.200. This is a subnet mask (255.255.255.X) or (/24). This means that only the last octet is available. One octet can range from 1 to 255. However, the 1 and the 255 are not available, so there’s only 254 options. This
means that a single network segment can handle multiple bus stops. If an attacker finds its way into one single network, the attacker will have access to multiple bus stops at once.
“Authenticating” message. Is it important?
Lastly, the “Authenticating” message suggests that the system is currently struggling to connect but its publicly displaying it. Screaming “I am having a hard time doing what I am supposed to” it’s not the best thing you want to do when you are the size of TfL. It reveals internal IP structures that a real attacker could exploit, it gives hits on the network segmentation and authentication protocols that someone with a deeper knowledge could analyze further and possibly exploit.
Why does this matter?
Let’s not forget that last year, TfL faced a cyber attach that targeted customer data and backend systems that cost over 30 million pounds. Allegedly, done by a 17-year-old teenager. So, this concern was not that impossible. But what damage could someone cause controlling the bus stop display?
I can start listing simple things such as displaying a hate or racist comment on the displays of different bus stops, or even displaying false ETAs, creating confusion and disrupting an otherwise clean traffic system. But mostly what I want to share is that debugging skills go way beyond coding. I have spent countless hours debugging code (More than I would like to admit) tracing memory allocation issues, segmentation faults, learning about sockets, IP addresses. And this experience proved to me that debugging is not just code. It applies to everyday situations as well.
Takeaways
It’s important to always consider security, even in small, harmless-looking systems. A bus stop might look harmless, but like running a C program or a Makefile in verbose mode… you would not do that in production. It is not good practice. It can expose crucial, sensitive information to anyone watching or using the system.
I am passionate about cybersecurity. I am looking forward to continuing my studies at 42 London and specializing in cybersecurity in the future. Cybersecurity awareness is a skill that can be developed even before finishing my common core. It is not only about writing firewall rules or encryption algorithms (Although that sounds pretty nice) it starts noticing the small weaknesses before they turn into big problems.
My advice to anyone pursuing learning code or any tech field? Be and stay curious. If you see something usual or unusual, question it, debug it, analyze it. Sometimes a bus stop glitch, could teach you more than you think.