Chronicles Pentester
Like several years ago, web applications are still the most attractive target for violators of all stripes. There is always enough space for sophisticated SEOs, and for those who want to carry their thoughts to the masses by changing the content of the pages, and, of course, web applications are the primary target for overcoming the external perimeter of companies, both in penetration testing and in a harsh life.
Everywhere, low security of web applications is due to many factors: from the quality of the developed code and the selected programming language to the configurations used on the web server side. The fact that the security of web applications is kept apart from the general security strategy adds oil to the fire. Managers of business units initiate business development processes, which in turn, one way or another, are based on web technologies. At the same time, the information security management service in an average company closes its eyes to the fact that the acquired solution may contain vulnerabilities. Moreover, from the experience of the work carried out, more than half of the information security departments in Russian companies do not even suspect who is responsible for the company's external, official website, not to mention who is involved in its security. Because web applications and hack on the stream.
Recently held pentest clearly confirms these arguments. When a group of pentesters using vulnerabilities of web applications reached the execution of commands of the operating system, (besides the joy of their own superiority)) there was a well-founded feeling that we were not alone here.
In one of the pentest on the customer's site, several critical vulnerabilities were found that in the future could allow to execute commands on the server. However, they could not be used for a long time. The seconds turned into minutes, the minutes took shape in hours, the goal was so close, but all efforts were unsuccessful. Looking around, it was noticed that before us is only one of the sites of a large hosting. Considering that the same malware was noticed on the pages of the site and its neighbors, it is logical to assume that the attacker before us would hardly have bothered with the vulnerabilities of our analyzed site. Surely he was walking along the path of least resistance and was filled with neighbors. But restrictions at pentest do not allow to repeat similar feats. Meanwhile, the efforts were not in vain, and using the cascade of vulnerabilities, the customer’s site surrendered its defense. Then, instead of the classical collection of information, it was necessary to find out how the malware hit the pages of this resource.
')
The following story reveals the use of zero-day vulnerabilities during pentest. Before us is another of. another customer's site on a completely secure content management system Joomla. When surfing the surface, a vulnerable module gets into the eyes of which vulnerability information has not yet managed to infiltrate the public. Information is also known that the other day a massive fill went through this module. And as it is not strange, we already had it in our hands :)) Further, as in Hollywood films. Enter target, launch, fill up, rejoice)) After that, you had to answer the question “who is here”? And the answer was not long in coming. As if shells with eval and base64 are very pale.
The last story I want to tell about today is no less revealing than the rest. It’s no joke, when on one of the external sites a well-known and beloved Russian bank has a backdoor installed in the language of our heavenly friends. Moreover, the dates showed that the backdoor was flooded over a year ago and went unnoticed throughout this time! The fact that the operating system on which the web server is located is part of the corporate Active Directory domain of the bank also adds sharpness to the entire history. As it turned out later, the IS management service of the bank itself, for the whole time only one request was recorded, which actually established the backdoor, i.e. just lucky this time. By the way, the backdoor (ala web shell) under Tomcat really turned out to be quite sophisticated (added to the piggy bank), and it was installed to the word through defaults in the Tomcat administration interface.
So how to protect against such threats?
First, if you plan to deploy your site on an external hosting, ask the hosting provider what actions he takes to protect the sites of his clients. On this subject, I recall another story. We analyzed somehow the site, located in one of the regions of our vast country. We fixed the SQL injection and began to unwind it, and, literally in half an hour, we see a message from the host in our address :) But the most remarkable thing in this story is that the hoster promptly provided a virtual patch for the vulnerability we found. On the other hand, when choosing a hoster, you probably should not expect too much from him, but he should provide fundamental security mechanisms when providing his services.
Second, use strong, unique passwords everywhere, especially on external web applications. Access to the administration interfaces of the site provide only a trusted list of IP addresses. By the way, these two simple rules, along with minimal privileges for a user who interacts with a database, helps to significantly reduce damage in the presence of a vulnerability such as the introduction of SQL statements.
And finally, when defending against zero-day attacks, remember that the more defenses you provide, the higher the likelihood that you will save your site from such an affliction. Probably from a targeted attack with stupid vulnerabilities in the application code will not work, but it is quite realistic to protect against mass attacks. And this is not enough!
So, what is required to protect the site from a zero-day attack while not resorting to analyzing its security with a fuzzing method or source code? In my vision, at least the following should be realized:
- strong passwords for the used identifiers in all interfaces (ftp, administration section, etc.).
- all administration interfaces should be accessible only to trusted IP addresses; optionally, the use of two-factor authentication wherever possible.
- minimization of privileges in all components.
- properly configured tables of access control (starting with the file system and ending with access control by means of the site management system, if it provides similar functionality).
- secure configurations of the web server and its environment (for example, secure PHP configurations).
- use of preventive control mechanisms (Web Application Firewall).
- restriction of network access from the web application to any other components of the network; hosting a web server in an isolated network environment (aka personalized DMZ).
By adhering to the listed approaches you will significantly increase the security of your web application. I wish you success in the constant battle of good with good on the other side :)
Everywhere, low security of web applications is due to many factors: from the quality of the developed code and the selected programming language to the configurations used on the web server side. The fact that the security of web applications is kept apart from the general security strategy adds oil to the fire. Managers of business units initiate business development processes, which in turn, one way or another, are based on web technologies. At the same time, the information security management service in an average company closes its eyes to the fact that the acquired solution may contain vulnerabilities. Moreover, from the experience of the work carried out, more than half of the information security departments in Russian companies do not even suspect who is responsible for the company's external, official website, not to mention who is involved in its security. Because web applications and hack on the stream.
Recently held pentest clearly confirms these arguments. When a group of pentesters using vulnerabilities of web applications reached the execution of commands of the operating system, (besides the joy of their own superiority)) there was a well-founded feeling that we were not alone here.
In one of the pentest on the customer's site, several critical vulnerabilities were found that in the future could allow to execute commands on the server. However, they could not be used for a long time. The seconds turned into minutes, the minutes took shape in hours, the goal was so close, but all efforts were unsuccessful. Looking around, it was noticed that before us is only one of the sites of a large hosting. Considering that the same malware was noticed on the pages of the site and its neighbors, it is logical to assume that the attacker before us would hardly have bothered with the vulnerabilities of our analyzed site. Surely he was walking along the path of least resistance and was filled with neighbors. But restrictions at pentest do not allow to repeat similar feats. Meanwhile, the efforts were not in vain, and using the cascade of vulnerabilities, the customer’s site surrendered its defense. Then, instead of the classical collection of information, it was necessary to find out how the malware hit the pages of this resource.
')
The following story reveals the use of zero-day vulnerabilities during pentest. Before us is another of. another customer's site on a completely secure content management system Joomla. When surfing the surface, a vulnerable module gets into the eyes of which vulnerability information has not yet managed to infiltrate the public. Information is also known that the other day a massive fill went through this module. And as it is not strange, we already had it in our hands :)) Further, as in Hollywood films. Enter target, launch, fill up, rejoice)) After that, you had to answer the question “who is here”? And the answer was not long in coming. As if shells with eval and base64 are very pale.
The last story I want to tell about today is no less revealing than the rest. It’s no joke, when on one of the external sites a well-known and beloved Russian bank has a backdoor installed in the language of our heavenly friends. Moreover, the dates showed that the backdoor was flooded over a year ago and went unnoticed throughout this time! The fact that the operating system on which the web server is located is part of the corporate Active Directory domain of the bank also adds sharpness to the entire history. As it turned out later, the IS management service of the bank itself, for the whole time only one request was recorded, which actually established the backdoor, i.e. just lucky this time. By the way, the backdoor (ala web shell) under Tomcat really turned out to be quite sophisticated (added to the piggy bank), and it was installed to the word through defaults in the Tomcat administration interface.
So how to protect against such threats?
First, if you plan to deploy your site on an external hosting, ask the hosting provider what actions he takes to protect the sites of his clients. On this subject, I recall another story. We analyzed somehow the site, located in one of the regions of our vast country. We fixed the SQL injection and began to unwind it, and, literally in half an hour, we see a message from the host in our address :) But the most remarkable thing in this story is that the hoster promptly provided a virtual patch for the vulnerability we found. On the other hand, when choosing a hoster, you probably should not expect too much from him, but he should provide fundamental security mechanisms when providing his services.
Second, use strong, unique passwords everywhere, especially on external web applications. Access to the administration interfaces of the site provide only a trusted list of IP addresses. By the way, these two simple rules, along with minimal privileges for a user who interacts with a database, helps to significantly reduce damage in the presence of a vulnerability such as the introduction of SQL statements.
And finally, when defending against zero-day attacks, remember that the more defenses you provide, the higher the likelihood that you will save your site from such an affliction. Probably from a targeted attack with stupid vulnerabilities in the application code will not work, but it is quite realistic to protect against mass attacks. And this is not enough!
So, what is required to protect the site from a zero-day attack while not resorting to analyzing its security with a fuzzing method or source code? In my vision, at least the following should be realized:
- strong passwords for the used identifiers in all interfaces (ftp, administration section, etc.).
- all administration interfaces should be accessible only to trusted IP addresses; optionally, the use of two-factor authentication wherever possible.
- minimization of privileges in all components.
- properly configured tables of access control (starting with the file system and ending with access control by means of the site management system, if it provides similar functionality).
- secure configurations of the web server and its environment (for example, secure PHP configurations).
- use of preventive control mechanisms (Web Application Firewall).
- restriction of network access from the web application to any other components of the network; hosting a web server in an isolated network environment (aka personalized DMZ).
By adhering to the listed approaches you will significantly increase the security of your web application. I wish you success in the constant battle of good with good on the other side :)
Source: https://habr.com/ru/post/128943/
All Articles