About the big nonsense of small companies
On duty, I periodically encounter various kinds of official inconsistencies.
For example, with technical support that does not know how a supported product works.
But everyone is familiar with such a person and will not surprise anyone. I'll tell you about a completely blatant case.
I will make a reservation right away: I know about the rules of good tone on the Internet and about the fact that you need to inform the owners of resources or hosting about the vulnerabilities found. In this case, I did NOT do this, due to the lack of vulnerability and the presence of obscene nonsense.
One fine morning I had the need to check how the site of one company would work on another site, in view of a possible move.
')
It turned out that the site is hosted by the company that promotes it. For management, use the DBedit program, which was already a problem to find on the company's website. Having successfully managed, I proceeded to connect the CMS to the site. I had a detailed manual created for people of completely different computer literacy. While reading this manuscript, my first doubts crept in on the adequacy of the hosting company.
The fact is that the site is stored on a server in the InterBase database. I am familiar with it not by hearsay and I know for sure that during installation a standard pair of login-password SYSDBA - masterkey is created, and it must ALWAYS be changed to any other. Client Login Password is issued in their original form. So in the manual about the need to change the password there is no word. Let me remind you that the manual is designed for a designer or a content manager who has no idea about standard passwords. Looking ahead, I note that you cannot change it through the DBedit interface, and the communication in support also yielded nothing. Password do not change!
"Well, okay," you say. "Surely there is another level of security restricting access to the content."
Can I upset you? - He is not. Fair. Well, really. Here is the proof:
You can simply say: “What about the connection parameters? The hacker doesn’t know them. ”
And he knows. Enough: buy their hosting / ask a friend who already has an account with them - and you will know the typical parameters. They are not complicated:
And that's all. That is all. For the vast majority of their clients, these parameters are the same.
You can go into the CMS, steer content, do what they like. Not forgetting to save changes.
Here was another surprise waiting for me - no changes made through the CMS on the site were displayed. But I had a textbook with a manual ...
You need to go to a special site, and enter there another (sic!) Login-password to apply the changes.
“Well, thank the gods! Here it is an obstacle for kulkhackers! ”- I thought, and I was mistaken.
Go to the special site, type:
You are asked for authentication.
Where Login is% your_domain%, and password is the first 4 characters from% your_domain%.
Well, is it not a miracle? This is true for most domains that are hosted by this company. Change this data is also not possible.
On a site you look through all made changes. Then follow the link
and everything All changes you make are submitted to production.
With the help of PING-a, I learned the IP of the server on which our site was located.
On the resource 2IP.RU I learned all the domains located on this IP.
And went through the list. Standard passwords came to almost all of the 84 sites at this address.
I checked the neighboring ip - there is the same situation.
I checked the connection to the CMS and whether the password is suitable for the preview-admin on the site.
By the most conservative estimates, passwords are the same at least one hundred sites.
Professionalism guys envy.
I will not name the office name for three reasons:
Thanks for attention.
For example, with technical support that does not know how a supported product works.
But everyone is familiar with such a person and will not surprise anyone. I'll tell you about a completely blatant case.
How I broke websites
I will make a reservation right away: I know about the rules of good tone on the Internet and about the fact that you need to inform the owners of resources or hosting about the vulnerabilities found. In this case, I did NOT do this, due to the lack of vulnerability and the presence of obscene nonsense.
One fine morning I had the need to check how the site of one company would work on another site, in view of a possible move.
')
It turned out that the site is hosted by the company that promotes it. For management, use the DBedit program, which was already a problem to find on the company's website. Having successfully managed, I proceeded to connect the CMS to the site. I had a detailed manual created for people of completely different computer literacy. While reading this manuscript, my first doubts crept in on the adequacy of the hosting company.
The fact is that the site is stored on a server in the InterBase database. I am familiar with it not by hearsay and I know for sure that during installation a standard pair of login-password SYSDBA - masterkey is created, and it must ALWAYS be changed to any other. Client Login Password is issued in their original form. So in the manual about the need to change the password there is no word. Let me remind you that the manual is designed for a designer or a content manager who has no idea about standard passwords. Looking ahead, I note that you cannot change it through the DBedit interface, and the communication in support also yielded nothing. Password do not change!
"Well, okay," you say. "Surely there is another level of security restricting access to the content."
Can I upset you? - He is not. Fair. Well, really. Here is the proof:
You can simply say: “What about the connection parameters? The hacker doesn’t know them. ”
And he knows. Enough: buy their hosting / ask a friend who already has an account with them - and you will know the typical parameters. They are not complicated:
%_____%._.ru: %_____%And that's all. That is all. For the vast majority of their clients, these parameters are the same.
You can go into the CMS, steer content, do what they like. Not forgetting to save changes.
Not so simple! Oh, no. Simply.
Here was another surprise waiting for me - no changes made through the CMS on the site were displayed. But I had a textbook with a manual ...
You need to go to a special site, and enter there another (sic!) Login-password to apply the changes.
“Well, thank the gods! Here it is an obstacle for kulkhackers! ”- I thought, and I was mistaken.
Go to the special site, type:
%_%.%_%.ruYou are asked for authentication.
Where Login is% your_domain%, and password is the first 4 characters from% your_domain%.
Well, is it not a miracle? This is true for most domains that are hosted by this company. Change this data is also not possible.
On a site you look through all made changes. Then follow the link
%_%.%_%.ru/genstartand everything All changes you make are submitted to production.
Recheck
With the help of PING-a, I learned the IP of the server on which our site was located.
On the resource 2IP.RU I learned all the domains located on this IP.
And went through the list. Standard passwords came to almost all of the 84 sites at this address.
I checked the neighboring ip - there is the same situation.
I checked the connection to the CMS and whether the password is suitable for the preview-admin on the site.
Afterword
By the most conservative estimates, passwords are the same at least one hundred sites.
Professionalism guys envy.
I will not name the office name for three reasons:
- Firms holding their sites with them are unlikely to be happy with the deface.
- There is no desire to learn to break blockheads into a quick break.
- According to the prompts in the text is very easy to find the unfortunate office.
Thanks for attention.
Source: https://habr.com/ru/post/133547/
All Articles