The Positive Hack Days 11 forum, which took place May 18–19, 2022, was truly epic. The bitterly fought ATM hacking contest featured no fewer than 49 participants. How cool is that? The winner of this year's prize fund of 50,000 rubles, with the handle Igor, was the first to hack the virtual machines. And they weren't even at the event! :)
Besides Igor, eight other participants picked up prizes this year for their VM-hacking skills. They were: drd0c, vient, vrazov, durcm, zxcvcxzas7, asg_krd, hundred303, and drink_more_water_dude. A big thank-you to everyone who took part, and for those who weren't at PHDays, here are the links to the virtual machines:
As for the tasks, they were identical for the two different virtual machines:
Kiosk bypass (solved 34 times)
Windows AppLocker bypass (solved 21 times)
Privilege escalation to the Administrator (solved 12 times)
On the C drive were three files: task_kiosk.exe, task_applocker.exe, and task_escalation.exe, which had to be run to make the task count. task_kiosk.exe could be run immediately after bypassing the kiosk; task_applocker.exe was blocked using AppLocker; task_escalation.exe required administrator privileges to run.
This year's architectural solutions allowed us to track the number of participants and solved tasks through a Telegram bot, thus providing more detailed statistics (Figure 2).
Task analysis
We should note that participants this year had much greater scope for activity, and each task on the virtual machine had a large number of solutions. Last year, it took participants a long time to bypass the kiosk, and some simply gave up before completion. This year's changes brought results, delivering some interesting solutions that were not envisioned in the original scenario.
Below is an overview of the solutions in general terms, without reference to specific virtual machines. It will be obvious to participants which solution fits which machine. This is to allow interested readers to solve the tasks for themselves, should they wish to.
Kiosk bypass. First method
Many had no idea how simple it was. To kiosk bypass in one of the virtual machines, they had to use the right mouse button. Surprisingly, participants did not notice that the right mouse button was working and, like last year, tried to find keyboard shortcuts to exit kiosk mode. The kiosk application was a web browser written in Delphi, so the complete kiosk bypass scenario was as follows: right-click → Print → Find Printer (Figure 3).
These actions made it possible to open explorer.exe and go to the C drive to run task_kiosk.exe.
Kiosk bypass. Second method
Things were a bit tricker in the other virtual machine because the right mouse button was disabled, as were the main keys. To exit kiosk mode, a network vector was laid out that required scanning of the ATM ports. After scanning the ports with Nmap, participants may have noticed some kind of service on port 80. The easiest way to find out what was running there was to follow the link http://<atm_adress>:80. There on port 80, it turned out to be a web server specially written for the contest. Every time a user connected to it, it threw an error and opened a browser help page on the virtual machine.
In this case, the ATM's IP was 192.168.56.102, and scanning Nmap showed that port 80 was open. After navigating to that address in the browser, an error appeared, whereupon clicking the OK button opened the Internet Explorer browser.
Exiting the browser is much the same as in the first scenario and can be done through the Internet Explorer Downloads page.
Bypassing AppLocker. First method
For unknown reasons, the scenario laid out in one of the virtual machines failed to work at the last moment, for which we apologize 😞. The fact is, however, we noticed it too late. Hence, participants were left searching for a non-existent AppLocker bypass and found many different scenarios instead. Some say that to bypass AppLocker suffice it to obtain administrator privileges, then disable it. This is indeed one way to bypass it, but it was originally conceived that the tasks would be completed in order and task_applocker.exe would be run without administrator privileges. The laid-out scenario involved the use of LOLBin and was originally described here.
wlrmdr.exe -s 3600 -f 0 -t Click me! -m To run calculator -a 10 -u C:\task_applocker.exe
The above command for bypassing AppLocker should have shown a notification which, when clicked, caused task_applocker.exe to start. But for some reason this did not happen, nor did the AppLocker warning appear.
Bypassing AppLocker. Second method
As for the second AppLocker bypass, everything worked fine. The hash of the EXE file was checked using the rules, making the bypass as simple as can be (solution suggested by hx0day).
We create the empty file 0.txt and execute the command copy /b task_applocker.exe+0.txt notepad.exe, giving us the notepad.exe file — essentially a copy of task_applocker.exe with a different hash. We run it and get a ready solution.
Privilege escalation. First method
Elevating privileges was easy enough in one of the virtual machines. The scenario envisioned searching the PowerShell history. Often, administrators who use this software forget to erase the history of entered commands. The PowerShell history, in turn, is available without administrator privileges, so information left there can be exploited by hackers. In our case, in one of the virtual machines, the history contained an administrator's username and password in cleartext. They could be found at the following path:
C:\Users\ATM\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt
Privilege escalation. Second method
Another (highly non-standard) way to elevate privileges was to use the runas command and look for a shortcut on the administrator's desktop to open the command-line interpreter with full privileges. This command makes it possible to run EXE files with administrator privileges. This is because some command arguments, such as /savecard, allow saving the administrator's username and password, so that applications can then be run without entering these credentials.
runas /user:Admin /savecard cmd.exe
Here, too, there are subtleties: the following command opens the console, which, as can be seen, is running as an administrator, but a closer inspection reveals that the necessary privileges are missing. At the same time, however, we are able to go to the administrator's desktop, where we need to run a shortcut.
We try to run task_escalation.exe and see the following error:
Next, we run the shortcut aministrator_cmd.lnk located at C:\Users\Admin\Desktop.
Once that is done, we can run task_escalation.exe with full administrator privileges to finally complete this task.
Additional tasks
Now let's take a look at the additional tasks. Recall that the ATM interface was a web page located at http://bank.paymentvillage.org. It is still up. The tasks are classified as additional because they are indirectly related to ATMs and involve searching for typical web vulnerabilities. For convenience and to make hacking easier, PHP errors are among the bugs.
Just a handful of participants tried to hack the ATM web interface, and we received reports of the scenarios laid out. The first vulnerability, found by participant vient, was Path Traversal. We happily gave them a T-shirt.
curl --path-as-is http://bank.paymentvillage.org/favicon.ico/../index.php
The above command had to be run to view the source code.
By the way, the error shown in Figure 16 pointed to another inherent vulnerability, but, unfortunately, none of the participants found it. The thing is that the Delphi-based ATM code constantly read the file С:\Atm\atmkey.txt. This file contained atmkey, a unique ATM identifier that enabled us to monitor task execution. Next, atmkey was inserted automatically into every request in the form of an ATM header, and was used for authorization in the ATM. This header is needed, among other things, for dispensing money at the relevant ATM (virtual machine). This made it possible to exploit self-xss by passing malicious JS code in the ATM header.
No one discovered the next vulnerability either, although they could have simply by changing the contents of the file C:\Atm\atmkey.txt. It was not even necessary to use tools for MITM attacks. Here's how it looks:
This year's scenarios also included ARP spoofing, which we will not analyze in depth, since an example of such an attack has already been described. Basically, participants had to fake the response http://bank.paymentvillage.org/payout?atmid=<your_atm_id> to get the application C:\Atm\payout.exe to run on the second virtual machine, simulating a cash withdrawal. The ATM queries this address every five seconds and waits for the response "true" before dispensing money.
There are, of course, vulnerabilities in the scenarios that are best kept secret so as not to kill the intrigue.
Conclusion
This year's scenarios turned out to be very simple for the participants. Many came well prepared.
We understand the need to strike the right balance as regards complexity, and have put together a set of takeaways for implementation next year. At the same time, many participants failed to grasp the true scale of the contest and completed only the main tasks.
Certificates were sent to the participants, and the first feedback is already in. We hope all prizes have been received by the time this post is published. One of the participants (thanks for the feedback, durcm!) agreed to let us publish a photo of their certificate.
Lastly, a huge thank-you goes out to all our international participants, in particular Boschko. For several years now, he has been sharing walkthroughs of our VMs with his readers:
Find more information about Payment Village in Telegram. See you soon! :)
Author: @yurasikhacker
