Hello.

I want to share one situational problem that arose during my stay at the international forum held in the Kaliningrad region and its solution in the style of a hungry IT.

The post will be about how to get around the limit of one serving, set in the dining room.

Foreword

Most recently, I once again visited the international forum, which takes place annually in Kaliningrad, on the Baltic Sea coast, as a participant.
')
The main task of our DevCamp stream was to develop and present the concept of an IT project during our stay.
However, in addition to working on the main project, there was a desire to digress a little ...

Problem: one serving is obviously not enough.

This year, there was an innovation on the territory of the forum’s dining room: it was possible to eat only once (once for breakfast, one for lunch and one for dinner).
The control was carried out at the entrance with the help of a specially trained person and MK with a reader to which you need to attach a personal badge with a rfid tag.

If the green LED lights up, they let in food, if the red one does not.


Figure 1 (Microcontroller responsible for the pass)

I wanted to influence this situation, and I did it.

Analysis of the decision making algorithm passes to food

The first thing I noticed is the patchcord that was leaving the MC. I walked a bit along the way.
This led me to the far corner of the dining room, where the router hung.


Fig.2 (Router in the corner of the dining room tent)

When the feeding time was over, and the dining room was free of people, I connected to the free port in the hope of getting a password from the WiFi network to continue my research without attracting too much attention - away from the dining room. It turned out that the router was reflashed in DD-WRT and the standard passwords in its admin panel were changed, for this reason I had to continue while sitting in the dining room.

Network scan

DHCP on the router was supposedly turned off, or there were filters, because my laptop address was not given. As it turned out, device addressing was standard.


Figure 3 (Network scan result)

It was not difficult to guess which addresses MK can have (there are two, one from the left and one from the right entrance to the dining room).
There were three candidates: 192.168.1. 130 , 192.168.1. 120 and 192.168.1. 112

Traffic analysis

Using ARP-Poisoning technology, I suppressed traffic between the gateway and the alleged MK through myself. And very quickly able to catch the right package.


Fig.4 (The original dialogue between the MK and the server)

As it turned out, the server erp.labadabadoo.ru is responsible for making the decision. MK sends HEAD request in the format / skud / meal /? Id = {rfid tag identifier} . In response, the server sends either the code “200” and the green LED lights up on the MC, or “403” - then the red one lights up.

We affect the situation

Apache was installed for this and a DNS-Spoofing attack was applied. Now the erp.labadabadoo.ru hostname was resolved as 192.168.1.99 (my laptop) and my local Apache always answered “200” .


Figure 5 (DNS-Spoofing in action)

The final result can be seen below. Sorry for the vertical video.

Disclaimer: not a single borscht was injured during research

I want to say thanks to Intercepter for the tool that will not allow the IT specialist to stay hungry.

During the study, excess food was not eaten , but morally I was full.