In previous blogposts on the “rom-0” bug in 2014 and earlier this year, I first explained its nature and gave instructions on its patching.
In the previous two blog posts about project Turris, we described how a telnet “minipot” helped us to uncover a possible botnet consisting mainly of home routers from ASUS (1, 2). In this article, we will describe one possible way how these devices might have been compromised.
Three weeks ago we published preliminary results of data analysis of the honeypot for the Telnet protocol, which we have launched in test mode. Today we will look at the situation change after we installed the tool on all the Turris routers.
In the next release of Turris OS, we would like to give our users the possibility to play a more active part in detection of network attacks. The first of the new functions is SSH honeypot which lures the attacker into a virtual environment where we can then observe his activity. This method will be more thoroughly described in a separate blog post planned for the near future. The second addition is less ambitious, but much simpler and still very useful. It is stripped down version of a honeypot which we internally call a “minipot”. In contrast to the normal honeypot which lets any attacker in with any password, our minipot just pretends that there is the possibility of logging in, and collects the supplied user names and passwords.
In a household, router is a central point through which a household is connected to the Internet. That is why the router is offered as a suitable place for various interesting analyses and statistics. The project Turris, that is true, offers a fairly big amount of analyses, statistics and tests, Majordomo, however, is the first tool which is intended purely for users and data are not sent from it for further processing.
Some time ago we started to redirect to SSH honeypots in the test mode the outer SSH port from Turrises of some volunteers from the development team. For the biggest number of attackers to “talk“ to us, we allowed in honeypot the login into root by random password; despite this most of bots will anyway do nothing and they will immediately disconnect themselves even after unsuccessful attempt.
In our Turris project, in addition to taking preventive measures that would protect users against various attacks from the outside, we also do other activities. Those include contacting clients from whose side we detect attempts to connect to IP addresses that are known to be botnets’ command and control centers, or blocking IP addresses that are used by websites to perform malicious attacks on users. During that time we have seen some curious incidents that I would like to briefly outline here.