Fast Food Drive-Thrus Feature Network See-Thrus
Written by Evan Schuman and Fred J. AunAugust 6th, 2009
When security consultant Rick Lawhorn recently drove through the drive-thru of a local Virginia quick-service restaurant, he was about to place an order when the screen stopped displaying his menu choices and chose to show an internal network screen. Instead of pricing for a burger and fries, it told anyone who happened to walk by the system's boot count, permanent run time, the restaurant's IP address, IP Mask, Gateway number and that DHCP was disabled, among other things.
But worst of all, from Lawhorn's perspective, the display told passersby that the order confirmation board (OCB) was quite completely connected to the store's LAN and POS, which is enough to tell someone that it's worth trying to hack into. And with a relatively unprotected network connection plugged into the behind-the-store box, that's not an especially daunting task.
This Story Is Only Available For Premium Subscribers. Click Or Login In Below To Read The Rest Of This Story.
Already a Subscriber? Login Here
Pages: 1 2
2 Comments | Read Fast Food Drive-Thrus Feature Network See-Thrus
Leave a Reply
Readers, specifically those who want to comment on a story:
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk.com? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk.com? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.
-Christine
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.