Hacking Party Sopot
In October, thanks to an amazing coincidence and the support of Athens, a conference was held in Sopot. “Hacking Party”.
The speaker was Michał Sajdak. At the beginning he told the story of the conference – “Hacking party”, as the name implies, at the beginning it was held in a workshop style – all-day workshops in a group of 30-40 people. However, Michał wanted to impart more knowledge, and at the same time increase the number of participants, and so the” Hacking party ” turned into a conference. The second edition, which took place last year in Krakow, gathered more than 300 people.
This mini-conference, as if a prologue to this year’s edition in Krakow, was divided into two parts: “security tests-theory and practice” and “IoT hacking”. Both equally interesting.
Safety tests-theory and practice
It often happens that we configure the server for a given application, and then forget about it. Or we add different web interfaces (e.g. for database preview).
A potential person looking for holes in everything can use, for example, the Reverse IP search engine to check whether we actually have only one dedicated application on a particular machine, or if someone forgot something.
A potential security vulnerability can also be various remnants from functional tests of applications. Left test accounts (admin / admin), left directories .git/.SVN, or leave the annotated test data on production (. how I could hack internet bank accounts of Danish largest bank in a few minutes).
However, if we are creating an API, we should remember not only to check the correctness of the token, but also whether the client has access to the data that has been transferred. Otherwise, you may find yourself making a transfer from any bank account to your own.
Leaving the debugger to production makes life much easier for developers and allows you to test the application on real data and traffic. But this way can leak a lot of data (Patr Patreon in 2015 lost ~ 15 GB).
Finally-remember to turn off any unused services and extensions. Otherwise, we might have a hole that’s been open for … 18 years. Such an example is ➔ shellshock, where by cleverly set user-agent during the request it was possible to load a shell if only we used CGI.
In the case of extensions, perhaps the most common case is to leave the default settings for XML in our web server (e.g. JBoss / tomcat). For this reason, we open the gate to.xxe (XML external entities).
IoT (Internet of things) devices are becoming more and more, and all have access to the internet. They are often based on the Linux system with the appropriate administration console (routers, IP cameras, etc.).).
And the most common holes are the mentioned panels. The most common example is leaving the code used in production in the target device – Archer C2, which had a backdoor left in the httpd program, through which ➔ you could load any program (automatic wget, chmod +x, and execution). And it could be done without any authentication. In a few minutes it was possible to get access to shell, to which even the owner of the device does not have access.
On TP-Link devices, unfortunately, access to the administration panel was also protected incorrectly. Some requests were “signed” only with the Referrer header, instead of Basic-auth. In this way, it was possible to change the configuration of the device in several places, or run commands in the shell.
Competitive d-links are also not flawless. On the.DSP-W215 devices, you could easily exploit the buffer overflow error and gain power over the device.
Therefore, remember that during the production of the device or software to remember about the appropriate security of transmission, requests, good algorithms, as well as to inspect the disk drives to see if they contain residues from the manufacturing process. Otherwise, someone can hijack your jeep with your phone (time-based WiFi password + open, poorly designed services).
Wondering why secure your home devices? Or put more emphasis on software development? After all, who needs access to shell in our router. Because in a moment these devices can be used against you-for example, for large, massive DDoS attacks.
Recently, OVH struggled with such an attack, which “took” traffic from 145,607 cameras / DVRs from different parts of the world and IP addressing. Fortunately, the attacker did not use the full power of the attack, which was estimated by OVH > 1.5 Tbps.
Author: Speednet SP. z O. O.