From Order to Exploit: A Deep Dive into Restaurant Network Security

Restaurant ordering systems streamline operations, but they can also present significant security risks. Here’s how I discovered a vulnerability in one of these systems that allowed me to edit my orders, potentially eat for free and bypass charges by intercepting and manipulating HTTP traffic. This flaw could affect over 20,000 food establishments.

Disclaimer: This vulnerability was analyzed in a controlled environment to ensure no third-party data was compromised during the process. It was reported in September 2024 (I will talk about it later), The system is available for anyone to download and test. The use of this information is at the user’s own risk, I am not responsible for any misuse of the knowledge presented.

Understanding the Restaurant ordering system

This ordering system runs on an Intranet or Peer-to-Peer network where devices and servers communicate using internal IP addresses. Typically, the system is hosted on a Windows PC. As a result, it generates a website accessible through the internal IP, which displays a login page like this:

With the correct username and password, we gain access to the order and table management panel. Where it is possible to place orders, close tabs, settle the bill, access the order monitor, and use other applications:

Next to the IP address in the image there is a message showing that the connection between the browser and the website is not encrypted (Não Seguro). And to find the IP address of the network hosting the ordering system, you just need to identify the IP using port 8080.

This means that anyone can intercept the network traffic and view the content of the communication, including passwords, form data and, most importantly, cookies. In the case of the vulnerability discovered, Cookies will be essential. By capturing them, we can access the system without needing to know the username and password. Here’s the first point.

Wi-Fi Network

This ordering system operates on mobile phones or tablets used by the waiters, meaning it relies on a Wi-Fi network to comunicate with the order and table management panel. In some restaurants, the waiters use their own mobile phones, while in others, there are fixed terminals located at strategic points within the restaurant, like these:

The estimated number of these devices is around 3 to 4, meaning more than 3 IPs communicate with the Order Management System. This represents a significant opportunity and amount of traffic that can be intercepted from these devices.

We already know they communicate through a Wi-Fi network so to start the exploitation we would first need to access the Wi-Fi network. It usually has some kind of protection like WPA2 and to gain access we just need to capture a handshake and crack the password. An even easier way would be asking the waiter or any employee for the password using social engineering.

And I hope everyone reading this already knows that connecting to public Wi-Fi or the network of a public establishment isn’t exactly the smartest choice, fraga?

Evil Twin (Evil WPA)

In most Wi-Fi networks, especially those protected with WPA2 or WPA3, the traffic between devices and the access point is encrypted using unique keys for each connected device. This means simply connecting to the network isn’t enough to sniff the traffic. To bypass this, I’ll use an Evil Twin attack, which impersonates a legitimate WPA network. This method is also effective for capturing partial handshakes when the network password is unknown.

All of this is done using the WiFi Pineapple, as it is a dedicated tool for Wi-Fi auditing and highly portable. Here is an image explaining this in more detail:

This attack, depending on the restaurant’s security, is the best option to use as it allows us to intercept any and all information on the restaurant’s network from all devices. Later, I’ll show another method using an exploit I developed.

In the controlled environment I’m simulating, the restaurant’s order system panel is at IP 192.168.3.143, and the router’s IP is 192.168.3.1. By running a network scan with tools like Nmap or Fing, you can easily spot these addresses. To keep things stable, I set up my WiFi Pineapple to create a network starting with 192.168.3, ensuring the order system panel IP doesn’t change.

Once the Pineapple is up and running, a quick scan will reveal the target network and connected clients, as shown in the image:

What really matters in this scan are the MAC address, the WPA type, and the connected clients. To carry out the Evil Twin attack, which is the attack we’ll perform, we’ll rely on the Evil WPA function of the Pineapple, specifically designed for it:

We replicate everything exactly as the original network. Knowing the original network’s password is crucial, which is why we capture the handshake to discover the password. The main purpose of the Evil WPA function of the Pineapple is to create an identical network to the original one, allowing us to control all the traffic that passes through it.

To make our Evil Twin attack work even better, we connect the Pineapple to any network or tethering USB with internet access, preventing the “connected without internet” message from appearing.

We can now start redirecting the connected devices, forcing them to disconnect from the legitimate Wi-Fi network and connect to the Evil Twin instead. To do this, we use the classic deauth attack. When the devices can’t reconnect, they’ll automatically switch to the fake network, which looks like the original one. In the Pineapple’s scan panel, we can select the network or client to target:

One of the devices being targeted is a smartphone connected to the legitimate Wi-Fi network with access to the order management panel, simulating the waiter’s device. After being deauthenticated, it will automatically connect to our Evil WPA network.

Another way to redirect clients is by accessing the legitimate Wi-Fi router’s control panel, which often uses default credentials. With access, we could shut down the router and leave only our Evil Twin network available.

After executing the deauth attack or turning off the Wi-Fi, we can monitor if clients have connected to the Evil WPA network through another part of the Pineapple interface. It shows the devices’ MAC address, data usage, connection time, and assigned IP address.

One important detail to highlight is that the installation guide for this ordering system specifically recommends setting the panel’s IP address as static. This means the Pineapple won’t assign a new IP or cause any interference with it.

I noticed that when a device uses a static IP, that IP doesn’t appear on the list. Since the IP is static and will never change, the connected client (waiter) entering orders into the order management panel won’t experience any connection issues.

Within the Pineapple’s graphical interface, there’s the well-known TCPDump tool, which helps us capture all the network traffic generated by our clients. Since the network they are connected to is under my control, I can easily monitor the traffic. As mentioned earlier, the connection between the browser and the order management panel is not encrypted.

With the Evil Twin network interface (wlan-0–3) selected, we can begin capturing network traffic directly through the Pineapple. It’s also possible to apply filters, such as protocol type, source definition, adjust verbosity levels, and other options to refine packet capture. Later, we’ll manually filter the traffic using Wireshark.

While capturing traffic, we can wait for any activity on the order management panel, such as page updates, order placements, or bill completions. In a busy establishment, this usually happens in under five minutes, especially with multiple terminals accessing the panel. Since I was in a controlled environment, I simulated placing an order on table 5.

The capture will be saved in a .pcap file. Once opened in Wireshark, we can already observe some interesting details, such as the type of traffic, source, and destination. By using the search field above, we can filter by HTTP to display only the traffic related to the HTTP protocol:

We can observe a packet containing a POST method. In the controlled environment I set up, I simulated a login during the capture process. The captured HTML form reveals the username and password for the order management panel:

In a real-world scenario, it might not always be possible to capture login credentials during packet interception. This is why cookies serve as an alternative method to access the order management panel. In another packet, we can observe the moment I accessed table 5 to place an order in the controlled environment. In this packet and in all packets captured while someone is logged into the order management panel, the cookies are also included.

Each captured cookie value should be carefully organized and separated to ensure easy importation without causing confusion. Wireshark itself provides tools to assist with this organization. I will be using the Cookie Quick Manager extension in Firefox to manage the cookies:

Once the cookies are successfully imported, simply reloading the page grants permanent access to the order management panel. This allows me to view the table’s subtotal, add new orders, close the bill, monitor ongoing preparations, pay the bill, and much more:

ARP Spoofing

Another method to intercept the HTTP communication used by the order management system is ARP Spoofing. This technique allows me to directly target the legitimate network by falsifying ARP packets. By sending these fake packets, I can redirect traffic intended for a specific device to my own machine, enabling a Man-in-the-Middle (MITM) attack.

To do this, I created a Python exploit using Scapy, called PacketPlatter, to perform ARP spoofing, automate packet capture, and automatically save the captured traffic to a .pcap file once the capture is complete. Typically, ARP spoofing targets the client connected to the network and the gateway. However, this exploit targets two clients on the network. This is because the ordering system works directly between two clients and does not pass through the gateway

In the environment I’m simulating, the order panel’s IP is 192.168.3.61 and the connected client (waiter) has the IP 192.168.3.64. By sending fake ARP packets, the attacker’s machine convinces the client at 192.168.3.64 that it is 192.168.3.61, allowing traffic between the two to be intercepted.

The exploit prompts you to enter the IP and MAC addresses of the waiter’s device and the restaurant’s device, along with the name for the output .pcap file. Once the exploit is running, simply wait a few minutes to capture the traffic between the two IPs.

As mentioned earlier, actions like refreshing the page, placing an order, or finalizing a bill can happen within five minutes in a busy establishment. However, it’s important to note that with ARP spoofing, we are only intercepting the traffic of a single waiter’s terminal, which in this case is the device with IP 192.168.3.64.

Here, I simply refreshed and accessed table number 2. That’s enough to capture the cookies, granting access to us.

To add persistence, since we are able to perform ARP spoofing, we can log the user out, forcing them to re-enter their credentials. While the user does this, we run the exploit to capture the new login information. This way, we can gain access to the system without relying on cookies, ensuring continued access even if the session expires or cookies are cleared.

Mitigation

To mitigate these attacks, it’s crucial to use HTTPS for secure communication, ensuring that sensitive data like login credentials are encrypted. Implementing ARP spoofing detection tools and static ARP entries prevent manipulation of ARP tables, safeguarding against man-in-the-middle attacks.

Network segmentation should be a key part of any security strategy. For instance, restaurants should set up a dedicated Wi-Fi network exclusively for the ordering system, separate from the public network that customers connect to. This would minimize the risk of unauthorized access. Additionally, configure the Wi-Fi network with WPA3 and avoid relying on WPA2 to ensure stronger encryption. And training restaurant staff on security best practices is equally important to ensure they understand how to recognize and respond to security risks effectively.

Reporting

In September 2024, I reported this vulnerability. The thing is, this type of system isn’t unique, many others work similarly, meaning the flaw applies to several other establishments. I contacted the company, asked to speak with the security or development team, and they told me they would “pass it on.” I documented everything and sent it over, with all the details of the flaw, the risk, and how to exploit it.

AND GUESS WHAT HAPPENED? FULLY IGNORED! So, you know what? If a restaurant wants to protect itself, IT HAS TO DO IT ON ITS OWN, because the company behind the system DOESN’T CARE.