Typical errors and not very
The story tells how a series of simple mistakes took shape and turned into tangible troubles for one company. However, the company traded fraud and spam, so maybe this is not bad.
Of course, all faces and events are fictional, but the author chose to remain anonymous from Tor :) The main character will be called the “author”.
It was an ordinary day. The author once again received an sms-message from some kind of money delivery service. We will call him Roskapital. Suddenly, the author realized that it was enough for him, and decided to repay the spammer with the same coin.
The author went to the site of the service, found a feedback form there and decided to provide there a flow of feedback requests. A script was written that regularly sent requests, substituting random names, phone names and phone numbers, and then launched into regular work through a large proxy pool (it so happened that the author had such a proxy pool at hand).
It is worth noting that when studying the site, the author realized that Roskapital is a typical financial pyramid.
')
After some time, the author decided to review the logs of his script for a change. Logs included server responses to sent feedback requests. In the logs, the author noticed that for some time the server returned an error. The essence of the error was the inability to access the Google document. The error was kindly attached to the call stack, in which the Google account login and password was visible. Obviously, RosCapital simply wrote down feedback requests in a Google document to which the account used was taken away or something like that.
Using this username and password (and of course Tor), the author logged into this account. The mail was mainly messages related to the work of the service - advertising orders, server payment, messages from the payment system. Messages from the payment system interested the author most of all.
On the website of the payment system, the author made a request for password recovery. Both the new password and the new payment password were successfully sent to the mail. That is, if the attacker gains access to the mail, then he gets both passwords and no two-factorness remains.
After that, the author successfully exchanged most of the funds from the account for bitcoins.
Soon the account owner changed the password.
This happened during the discovery of the Heartbleed vulnerability in OpenSSL. The author has already closed this vulnerability on the servers for which he was responsible, and decided to look for who has not yet closed it. The author, of course, came to the very same service.
Vulnerability was not closed there.
A script was written that regularly tugged the RosCapital server and fished 64 KB out of its memory, and then it was launched into regular work (again through a proxy).
After some time, an administrator session appeared in the logs.
Using this session and setting the appropriate useragent in the browser, the author freely got into the admin area. There he created a “deposit” for a large amount and immediately brought it into Bitcoins.
Soon the admin panel began returning an error code of 403, apparently it was denied access over IP.
Heartbleed vulnerability on that site was still not closed, and the script continued to collect data from server memory. In particular, a piece of the nginx config was obtained.
In the config it was clear that access to the admin panel is limited to a subnet of IP addresses. After a thorough search on the network, the author found out that there is a VPN service that uses several IPs from this subnet.
The author purchased access to this VPN and ... again got into the admin area and again brought some amount of money into Bitcoins.
After that, access to the admin panel was limited to one specific IP, and soon the Heartbleed vulnerability itself was closed.
The author could not stop and decided to just look for vulnerabilities in the service.
As a result, a URL resource was found that simply read and gave the contents of the file, the name of which was passed in the request to the resource.
The vulnerability was essentially blind, i.e. it was possible to find interesting files only at random.
But FreeBSD came to the rescue. On FreeBSD, you can read the directory as a file. At the same time, an entry about the directory from the file system is given - all files and subdirectories are visible there.
So the study of the file structure has become much more interesting. However, the author could not find anything tasty. Upload your files was not possible. Requisites of access to the database were found, but it was impossible to connect to the database. PHPMyAdmin was only on a separate subdomain that was password protected.
However, as a result, a control script (shell) was found on the server, the password to which was specified directly in its code in clear text.
The author, using this shell, immediately left his bookmarks in different places of the service code. The touch utility helped change the timestamps of changed files in order to make it more difficult to detect bookmarks.
Then there was the matter of technology. The access keys to the API of payment systems were retrieved from the database, from which all funds were then safely merged and transferred to bitcoins.
After that, the author, through the API, observed how all the funds received by the payment systems were transferred to other wallets every few minutes. Obviously, the owners of the service tried to save as much money as possible. In general, it was quite a popular financial pyramid, and incoming transfers went constantly. Soon, RosCapital stopped its work. In principle, this was in any case their goal, but the author clearly seriously reduced the amount of their funds. To understand the scale - the amount of stolen funds was about 140-150 BTC. Finding out the BTC course at that time is certainly not difficult for readers.
Since then, the fictional author of this fictional story has been tormented by the question: Is it good to steal from scammers, especially given that scammers eventually got money from people who are guilty only of believing in fairy tales?
Of course, all faces and events are fictional, but the author chose to remain anonymous from Tor :) The main character will be called the “author”.
Do not send spam. Especially sms spam
It was an ordinary day. The author once again received an sms-message from some kind of money delivery service. We will call him Roskapital. Suddenly, the author realized that it was enough for him, and decided to repay the spammer with the same coin.
The author went to the site of the service, found a feedback form there and decided to provide there a flow of feedback requests. A script was written that regularly sent requests, substituting random names, phone names and phone numbers, and then launched into regular work through a large proxy pool (it so happened that the author had such a proxy pool at hand).
It is worth noting that when studying the site, the author realized that Roskapital is a typical financial pyramid.
')
Disable error output in the public (production) version of your service.
After some time, the author decided to review the logs of his script for a change. Logs included server responses to sent feedback requests. In the logs, the author noticed that for some time the server returned an error. The essence of the error was the inability to access the Google document. The error was kindly attached to the call stack, in which the Google account login and password was visible. Obviously, RosCapital simply wrote down feedback requests in a Google document to which the account used was taken away or something like that.
If possible, use two-factor authentication for your accounts. Do not use important accounts for automated access to various resources.
Using this username and password (and of course Tor), the author logged into this account. The mail was mainly messages related to the work of the service - advertising orders, server payment, messages from the payment system. Messages from the payment system interested the author most of all.
Payment systems must provide full two-factor payment protection.
On the website of the payment system, the author made a request for password recovery. Both the new password and the new payment password were successfully sent to the mail. That is, if the attacker gains access to the mail, then he gets both passwords and no two-factorness remains.
After that, the author successfully exchanged most of the funds from the account for bitcoins.
Soon the account owner changed the password.
Install updates and patches on time. All your counterparties should do the same.
This happened during the discovery of the Heartbleed vulnerability in OpenSSL. The author has already closed this vulnerability on the servers for which he was responsible, and decided to look for who has not yet closed it. The author, of course, came to the very same service.
Vulnerability was not closed there.
A script was written that regularly tugged the RosCapital server and fished 64 KB out of its memory, and then it was launched into regular work (again through a proxy).
It is necessary to tie the session on the site to IP (although this may be other pitfalls)
After some time, an administrator session appeared in the logs.
Using this session and setting the appropriate useragent in the browser, the author freely got into the admin area. There he created a “deposit” for a large amount and immediately brought it into Bitcoins.
Soon the admin panel began returning an error code of 403, apparently it was denied access over IP.
It happens that VPN reduces security (!)
Heartbleed vulnerability on that site was still not closed, and the script continued to collect data from server memory. In particular, a piece of the nginx config was obtained.
In the config it was clear that access to the admin panel is limited to a subnet of IP addresses. After a thorough search on the network, the author found out that there is a VPN service that uses several IPs from this subnet.
The author purchased access to this VPN and ... again got into the admin area and again brought some amount of money into Bitcoins.
After that, access to the admin panel was limited to one specific IP, and soon the Heartbleed vulnerability itself was closed.
About banal: write a safe code
The author could not stop and decided to just look for vulnerabilities in the service.
As a result, a URL resource was found that simply read and gave the contents of the file, the name of which was passed in the request to the resource.
The vulnerability was essentially blind, i.e. it was possible to find interesting files only at random.
FreeBSD has a feature that potentially reduces its security compared to Linux (!)
But FreeBSD came to the rescue. On FreeBSD, you can read the directory as a file. At the same time, an entry about the directory from the file system is given - all files and subdirectories are visible there.
So the study of the file structure has become much more interesting. However, the author could not find anything tasty. Upload your files was not possible. Requisites of access to the database were found, but it was impossible to connect to the database. PHPMyAdmin was only on a separate subdomain that was password protected.
Clear text passwords are always evil
However, as a result, a control script (shell) was found on the server, the password to which was specified directly in its code in clear text.
The author, using this shell, immediately left his bookmarks in different places of the service code. The touch utility helped change the timestamps of changed files in order to make it more difficult to detect bookmarks.
Then there was the matter of technology. The access keys to the API of payment systems were retrieved from the database, from which all funds were then safely merged and transferred to bitcoins.
After that, the author, through the API, observed how all the funds received by the payment systems were transferred to other wallets every few minutes. Obviously, the owners of the service tried to save as much money as possible. In general, it was quite a popular financial pyramid, and incoming transfers went constantly. Soon, RosCapital stopped its work. In principle, this was in any case their goal, but the author clearly seriously reduced the amount of their funds. To understand the scale - the amount of stolen funds was about 140-150 BTC. Finding out the BTC course at that time is certainly not difficult for readers.
Since then, the fictional author of this fictional story has been tormented by the question: Is it good to steal from scammers, especially given that scammers eventually got money from people who are guilty only of believing in fairy tales?
Source: https://habr.com/ru/post/257877/
All Articles