This is page 2 of:
Fast Food Drive-Thrus Feature Network See-Thrus
Still, the chain said that it contacted its vendor and asked for an explanation and to have the glitch fixed, ideally making the system go blank when it restarts, rather than displaying the internal stats. Asked why it happened, the retailer reported that “their thought process is that it shouldn’t reboot during working hours.”
This is becoming a huge problem, especially with fast-food chains. There are three issues these chains are dealing with simultaneously. The first is that these are mostly cash businesses and cash-handling is very expensive. That means that the chains are going to try and get their customers to use more credit and debit cards, which in turn means that they’ll have a lot more sensitive data lying around.
The second issue is that many of these restaurants are owned by regional franchise groups, which means that the restaurant chain can’t dictate what technology and security mechanisms the stores will use. Well, they can certainly dictate, but the stores are out there on their own and they generally do whatever they want. (It’s akin to raising a chain of 12,000 adolescent daughters.)
McDonalds has been pushing an effort, for example, to try and segregate all of the payment in all of their stores , including their franchise locations.
The third issue is that, even though these stores (both owned and franchised) may be part of a multi-billion global restaurant chain, each store is comparable to an extremely small business. That means no IT staff and little facility security, other than video cameras.
Add it all up and you stores with little security, storing growing mountains of data and little way of regulating how they deal with it.
Lawhorn was not alone in his observations, with photos of machines in different regions—and with different chains—showing the error screens circulating.
But what Lawhorn did see—which is at the heart of most of these units—was far from comforting. “The information on the screen relayed enough information where I could get to the manufacturer. It provided an IP address and it told me the IP address was fixed. The reason that’s important is because I know their networking address scheme and I can introduce another host or node. I know exactly how many devices they can accept by that network address range. I can place a router in line between the sign and the restaurant. If they are wireless, I can sit in their lobby and try different things,” he said.
He also questioned the chain’s claim that the glitches are only momentary, making the risk from the data being displayed minor. At the location that he initially observed, he saw the system crash. “When that happens, you want to provide people with an error message, but not reveal too much information in that error message. If you provide too much information and leave it up on your display for days at a time while you’re waiting for a support call, you are just spreading that information around. This was up for a couple days. I went back two or three days later and it was working while I was in line but then it crashed again. So it was four or five different dates.”
The biggest problem, Lawhorn (who provided pictures of the machine he saw) said, was the perceived ease of physical access. “On the back of the display is a network jack. You could go up to it, unplug the cable and then plug it back into that sign. You could put in a wireless router inline, making all their internal network traffic wireless. So I can now run any tool I want to and sit in the parking lot and monitor what’s going on. The diagram offered by the place that provides these signs shows no instructions for setting up firewall rules. You connect it to a hub and we know that, with hubs, all the network traffic is broadcast across all the ports. So if a sign is part of the internal network, the POS is sending credit card transactions across that network. For the most part, it’s one big fat, happy network.”
-Marc
August 7th, 2009 at 10:58 am
Several of the article’s statements and assumptions are incorrect or misleading. I have clarified some of those below:
The article states that the OCB showed the “restaurant’s IP address”. That is incorrect. In fact, the display showed a default IP address that had no insight or connectivity into the restaurant network.
The article states that the “display told passersby that the order confirmation board (OCB) was quite completely connected to the store’s LAN and POS”. That’s quite an assumption. In fact, the OCB is connected via a peer-to-peer network to a protocol converter in the restaurant. The POS data is actually send to the converter serially and then converted to IP for transmission to the OCB. This peer-to-peer network has no connection or access to the restaurant’s network.
The article states there is “a relatively unprotected network connection plugged into the behind-the-store box”. In fact, the data cable is buried in an underground conduit that then enters the display unit inside the secured pedestal. The pedestal cabinet requires a security key to access to the interior.
The article states “’You still need to have physical access.’ But that may be easy to do with this system.” Wow, then again maybe it isn’t.
The article states, in regard to credit and debit card data, “they’ll (restaurants) have a lot more sensitive data lying around.” Yes, there is more data. However, credit card and debit data is required to be encrypted and is transmitted – not stored. The statement is misleading. Later, the article states “storing growing mountains of data”. Again, the PCI-related data is not stored in order to limit risk.
“Lawhorn was not alone in his observations, with photos of machines in different regions—and with different chains—showing the error screens circulating.” I have reviewed the photos and they are various solutions, from various vendors, and are indicative of a wide range of unrelated system errors. You cannot make a broad assumption about data security based on these unrelated photos.
Lawhorn was quoted as saying “It provided an IP address and it told me the IP address was fixed.” Again, the IP address displayed was a default address with absolutely no insight into the restaurant network or configuration. Mr. Lawhorn states he could get to the vendor but it is not mentioned that he has not contacted us. I have attempted to contact Mr. Lawhorn, without success, through the original article’s author.
The article states “I can place a router in line between the sign and the restaurant.” and then “If they are wireless…” The fact is that there is no wireless access at this site and there is no exposed data cable to place a router. To do this, a culprit would have to break into the restaurant or physically dismantle the OCB in the drive-thru. The statement “On the back of the display is a network jack. You could go up to it, unplug the cable and then plug it back into that sign.” is tremendously misleading at the network cable and jack is inside a secured cabinet.
August 7th, 2009 at 1:31 pm
the comments are generally disagreeing with what someone said in an interview.
Also, many facility set up their mechanisms in many different ways. Not all restaurants deploy systems in the exact manner suggested by the vendor and there are facilities that try and cut costs by going directly. The IP address comment is the position of the vendor that it’s likely the default address and not necessarily the address of that restaurant’s network. And the column explicitly stated that (“The information on there is not necessarily indicative of the current configuration of the unit itself.”)
But an IT manager with that chain–who didn’t want his name–indicated that the concerns of the consultant the column quoted were fair and accurate. We give the retail chain’s IT department a lot of credibility on such matters.