If you have not read the first part, it is recommended to start with it.
Nowadays every company and organization has cameras: someone steals cookies in the rest room, employee do not work properly at their workplaces and so on. This organization is no exception. I had the reason to check the size of folders and selectively archive web server folders in the first part. Two hosts turned out to be a storage of photos of tens of gigabytes. Everything is decent there, the only thing is that there are cameras with a built-in motion sensor, so recording only happens when there is someone in the room. One of the cameras is installed in the rest room – where there is coffee, food, TV. So, if you look at these photos at an accelerated pace (it’s like a video), you’ve got a surrealistic impression that people in this organization are constantly eating… A day passes like this: the sun rises, the first people come in and start drinking coffee, then they start to eat, then they leave and others are eating, then more people come and also eating, then these leave and others come with their food and eat again, and it repeats and repeats until the sunset comes… Then the next day – exactly the same, people eat, eat, eat, and that's about 100 Gigabytes…
And the web interface with a weak password to view all this ‘stuff’ is located on the subdomain of the site, accessible from the global network.
So, from the websites we have already shaken off everything that is possible – the source code, databases, user passwords.
Now let's take a look at the server itself – what we have access to, what settings are weak, what information we can get about the system, what users it had, what services are running there.
All this can be done manually by running utilities on the command line or using one of the automation programs. For example, I will apply LinEnum. The details of working with it are described in “Shared hosting security audit”.
And waiting for the results.
There is a lot of information. Information about the system and the kernel can be used to search for exploits that escalate privileges.
Information was received about the users (name, IP, last login date) who ever logged on to the system – their names can be used for brute-force SSH. And one of the users had a local address of 10.*.*.* - this gives us a hint about the structure of the local network.
It is shown which user is an administrator, as well as accounts, who recently used sudo (that is, who has the right to execute commands with elevated privileges — such accounts are of primary interest).
Information about network interfaces is collected, local IP is shown – you can scan the network for searching of other connected devices.
Showing the listening ports (those to which you can connect) – a lot of them. They are worth checking out as there may be interesting services.
Information about running processes indicates that the mail server, proxy, DNS server, IP camera service is working.
Collected version numbers of popular services – in case we will look for exploits.
Among the interesting files suddenly appeared nmap – I can scan the host right from itself – it will give super fast results.
On the server were found two users with administrator privileges, root and another one whose name I can not give.
Analysis of the source code of web interfaces for viewing photos saved from cameras gave another password – also of six digits. I noticed that the owner of the folders of the web server where the photos are located is not Apache (not www-data), but different users. It turned out that FTP credentials are provided for them, and I can also log in via SSH for them, and in both cases the administrator password is suitable, which is suitable for both MySQL root and the service on the site. Unfortunately, these users do not have permissions to execute commands with sudo. That is, I already have access to what they have access to (unless, in addition now I am able to edit site files which are owned by the users).
But, what is the saddest thing is that this administrator password does not fit the user of the Linux system, nor does it fit the root account. To be honest, at first I was even surprised – it works everywhere in the system, but for the main accounts of Linux it does not fit… Apparently, the passwords for these users were invented at an outsourcing…
We will proceed from the fact that the password is six digits length. Then generate it using maskprocessor:
maskprocessor ?d?d?d?d?d?d > dig.pass
For bruteforce, I prefer the patator.
I wanted to run password cracking right from the server itself. Python was installed there, but paramiko is absent, so I got an error:
ERROR: paramiko 184.108.40.206 (http://www.paramiko.org/) is required to run ssh_login.
As a result, I launched brute force in the old fashioned way:
patator ssh_login host=IP user=root password=FILE0 0=dig.pass -x ignore:mesg='Authentication failed.'
I no longer had a goal to get a password by all means – it has already been proven that the server is not secure. Therefore, I did not brute-force 24/7, sometimes I ran brute-forcing when I remembered about it. After 10 days, brute-force suddenly stalled:
ssh: connect to host IP port 22: Connection refused
At first, I thought that IP from which the requests were sent is banned. But it was not confirmed.
As it turned out, root logged to the server and changed the /etc/ssh/sshd_config file. I do not know if this is related to my activity or just the admin decided to “tighten the security”. I looked into the SSH configuration file:
The most important there is the directive:
That is, instead of port 22, now the SSH server is running on port 40022 – apparently, so that no one would guess.
To solve this problem, I need to specify a non-standard port in the patator:
patator ssh_login host=IP port=40022 user=root password=FILE0 0=dig.pass -x ignore:mesg='Authentication failed.'
If the brute-force is not completed, then at the end of the work the patator will display something like:
08:56:40 patator INFO - To resume execution, pass --resume 3591,3577,3564,3592,3572,3588,3588,3568,3584,3588
If you want to continue from the point where the stop was made, then at the next launch of the patator, add this line to the command, you will get something like this:
patator ssh_login host=IP port=40022 user=root password=FILE0 0=dig.pass -x ignore:mesg='Authentication failed.' --resume 3591,3577,3564,3592,3572,3588,3588,3568,3584,3588
Successful password brute-force of Linux users, such as root or a user who has the right to execute commands with sudo, means the most complete compromising of the server – complete hacking: any settings, any files, any actions on the server become available.
As I said, the nmap program was installed on the server, so I decided to examine the server's local network.
I looked at local IP:
I ran the scan, but found nothing:
nmap -sn 192.168.144.0/24
tracepath -n ya.ru
showed that the server is directly connected to the ISP – it should have been obvious – this is the server, they all have an white IP.
I scanned the ports:
nmap localhost -p-
and saw a lot of interesting things there.
As a result, I decided to collect service banners:
nmap localhost -p- -sV --script=banner
Among other things, there was information about Kerio Connect 9.2.1 and the open ssl/http Kerio MailServer http config. As I googled – this is a email service.
I already saw the mention of the email service in the information on one of the hosts (subdomains) – it was written there that now the email service moved to Yandex, so I quickly forgot about it.
But it turned out that if I enter the IP with the correct port number in the browser, the login form for the organization’s email opens. I tried several credentials (username and password) from those that were in the database – many of them work.
Including the admin password from the administrator's email.
The email has been used for several years, but has been abandoned for almost a year.
The importance of email hacking is hardly necessary to explain – information accumulated over the years, employee data (this is in addition to their photos, which were obtained a little earlier), opportunities for social engineering – so I thought at this point that it would probably suffice from this server.
You might think that this story is just a list of all the most childish and most ridiculous mistakes that only beginner schoolchild programmers and administrators can make. And in real life this would not happen. It happens… This is an absolutely real analysis of a real server.
Unfortunately, I can’t speak even in general terms about the context of this case. But the fact is that it is not private server, the server belongs to serious organization.
You may notice that I have used specialized utilities to a minimum. Almost all the “hacks” were that I knew where and what to watch and just watched it. Therefore, training in website security auditing (hacking websites) is not only in the study of specialized utilities. First of all, you need an understanding of what is happening. If we are talking about website, then there must be an understanding of how they function. I cannot imagine how you can do penetration testing of a website, if there are no skills in programming in PHP and at least some experience in creating websites and web applications (CMS, engines, etc.). If pentesting continues on the server, then there is simply nothing to do without such peaceful professional skills as:
hey bro… thank you …. but we want to see bug bounty topic… you are best.. you can write a new series..What are the programs and techniques we can use for bug bounty programs? we are following you… good night
Your email address will not be published.
Notify me of followup comments via e-mail. You can also subscribe without commenting.