The history of hacking one MLM company

All of you must have come across "successful people" from the Internet. These people broadcast their vision of life. Expose their wealth. They publish books on how to get out of the comfort zone, while they write these books from their mansion in some kind of sunny California. Do you know this?

I really just got tired of it. I cleaned out all the tapes of social networks from similar personalities. Personalities that broadcast about coaching, motivation and easy life. And you know what? It became really cool to stay up to date without this garbage! You go to social networks, and there are only cats and parrots.


But the story is not about that. One day I got burned and I thought - what if you take and look at the real incomes of these people who are so annoying?

So I thought and did it. More precisely at first did. But then he thought and stopped in time, so as not to break firewood. Remember and honor the 272 Criminal Code of the Russian Federation !

The story will be about one network company, which in our time is just a sea (prana, herbalife, oriflame, nl international, etc.)

The name of the company is intentionally hidden, and personalities are blocked because they did not want to publicize the incident. In principle, right. Who knows what else I missed ... Well, as a reader, in this example, you can understand what is not worth doing and what mistakes should not be made.

So let's go. Our goal is company and information about people who live happily and gloriously.
We start of course with social networks. You can’t imagine how many interesting things can be found in social networks.

We find out that we can get all the important information through one important site. This site is constantly featured in Instagram stories of those who show their income. In order for us to catch the “victim”, we must become this “victim”.

To do this, we register our account on which we will conduct experiments. It turned out to be successful and anonymous by finding a referral link to register.
After registration, we receive an e-mail with information about the login to the system and password. Yes, yes - the PASSWORD was also in the email.



Having received this letter, I immediately rememberedRU-Center password situations .

Okay It is, of course, bad that passwords are so easily scattered. But this will not help us in any way. Unless we hack into our victim’s email box.

We are going further. Got a couple login-password. Let's log in. And here we understand that this password does not require a forced change as a one-time one. Moreover, the password change menu does not imply the installation of some kind of “unique” password. And I’ll ask you to note the password from the numbers, and a clearly fixed amount. This combination is easily selected through a brute force attack.

Okay We try to use pens to check the login form for resistance to brute force password. And here it turns out that not everything is so simple. The account is completely blocked and you can’t log in even with the correct password after several unsuccessful attempts. Recording is blocked for several minutes. And this already creates a situation of impossibility to conduct a brute force attack.

And then I remember the most beloved in my work. About mobile apps. I’ve seen so many of them lately. And I found so much frank game. And hard-coded passwords, and the lack of distinctions and privileges between users. Well, I’m lucky and I found a couple of applications from this company. In one of the applications, it was possible to use the same pair of username and password.



Of course, the functionality of the application did not open to us endless possibilities. But the endpoint login has already been used completely different. Not the one that clearly blocked the account during the search.



Then I decided to check what would happen if I conduct a brute force attack on my account through the endpoint of this application. How fast can I find the password? How many threads can I do without server failure? How quickly will attentive system admins ban me?

The results, of course, turned out to be interesting!

Password guessing worked at an insane speed in several threads (dozens of options per second). Moreover, the server practically did not return me a 500 error from the increased load. And I was not banned. The attack was carried out for several hours. And I successfully picked up the password. Actually it was the same password that fell to my email inbox. In the system itself, a huge functionality of possibilities was revealed to me. And after all this, I just started assessing the risks for the company and then presenting them a security report. The more I went deeper, the more I understood the seriousness of the consequences of the success of my attack.

And so what could be done? ..

• Collect personal data of system users (name, phone, passport data, address).
• Collect all the financial activity of user data.
• Collect sensitive user information from personal correspondence within the system (private messages).
• Transfer funds between users. With the subsequent withdrawal of funds. Moreover, this could be done in a very fun format. If from one hacked account you can understand the amount of damage, find and roll back transactions, then through several hacked accounts it would be almost impossible to do this. In fact, a kind of money mixer. As a result, the financial losses of the company. And believe me, the money was there ...
• Reputational damage due to the disclosure of the financial activity of users.

I already feel your question - What are you terrifying? How do you know the login of other users?



And here is my answer to you - social networks! Everything is shared. And the login format is also quite trivial.

The most difficult thing was to find a person to whom you could send information about all this in order to eliminate it.

Found the most important thing in this office. It seems like he was considered a leader. But he was very reluctant to communicate. I threw off the email address to which I can send technical details. And never read my last posts. I didn’t reply to my e-mail either.



That so it did not care - I did not expect.

Through social networks, friends, friends, even some friends, I discovered a person who was once the developer of this company. He already told me another person who is responsible for the company's IT infrastructure.

By the way, when I reached this person, 2-3 days passed. The man reacted adequately. We talked very coolly about all the problems. He did not deny any of the points that I described.



It was also remarkable that due to the anomalous traffic that I intentionally created, it closed an existing loophole a few days ago. And this is awesome. It wouldn’t be cool if he hadn’t noticed anything at all.



The problem is closed. Everyone is happy. I got an interesting experience. The company received a valuable security report and life lesson.

And then you have a question about remuneration? I will answer with a quote from the great - "There is no money, but you hold on." In fact, the system administrator suggested that I transfer some money to my test account (TR 5, if my memory serves me right).



But in essence, I could not withdraw these virtual tools. Upon his suggestion, I simply kindly asked to transfer this “remuneration” to a friend who “works” in this company. He, in turn, was able to spend money on the company's sweet products. Well, then, at my request, the sweets went to the orphanage.

Conclusions:

• Do not go too deep when you find something “interesting.”
• Never forget about 272, and about the risk of getting in touch with a not-so-adequate person who may not be happy with your message about a “hack”. In a specific example, my interlocutor was funny.
  
  
• As a developer, never implement authorization / authentication functionality through different endpoint APIs. There must be community in your system. There should not be workaround solutions for this or that functional. Everything should work through a single endpoint with a single protection. Otherwise, you will get tired of looking from where the burglars came to you.
• Do not use simple passwords for users that you yourself generate. A good password should be set by the user himself.
• Always encrypt passwords, salt them, and do not store in plain text.
• Do not pass passwords from the system in an email when registering. If the user loses control over the electronic box, he will lose control over your system.
• Do not use the login generator on your system. Logins to the system must also be unique.
• When implementing authorization functionality, always lay in the protection against brute force functionality.

That's all. Comments and suggestions are welcome. I am also open to suggestions for testing something interesting.