Although perimeter security controls are well publicized, there are many suppliers who can offer them in different countries and these devices can fit into all types of budgets, there are still security problems in custom applications developed within companies that are not so easily solved.

In the modern corporate world, the immediacy of business is a predominant feature. For people responsible for computer security is a challenge because we need to find a balance between the needs required by business, the solution time and the risks that the company can tolerate in information assets.

This week we were dealing with an incident relating to unauthorized access and information leakage of a web application. When we analyzed the logs of the IPS, we find the following:

This pattern is repeated continuously with a number of web pages that make up the application. All request were successfully served. I made the following questions:
 

• Where is the check for the tag "Referer"? Although this tag is very easy to spoof using any intermediate proxy used in vulnerability analysis, works enough to embarrass people that downloads the webpage on their computers, modify the HTML source to modify the parameters for the forms actions and from the page stored continue their transactions.
• Where is the session id issued by Tomcat for this HTTP request? I asked what happened to the Tomcat configuration for requesting sessions when different servlet invoked. Natural behavior that I expected to see was a redirect to the homepage to request username and password. Response received was that the functionality was not implemented because the business was waiting for an urgent application to come out with a public campaign and that this functionality would be covered once the campaign ended.
• The previous response I received made ​​me raise another question: Is session timeout implemented? I received the same answer: It was not implemented for the same reasons outlined above.

We found other repeated pattern of packets, which turned out to be the root cause of the incident:

Someone with interactive access to the server could upload a modified servlet, which the attacker invoked in the HTTP request and then it was possible to modify and retrieve information from the application.

The lessons learned from the case are as follows:

• Periodically review the information security baseline measures of security for computers that make up the IT infrastructure of your company and verify that all the devices have them in their own settings. In case any of them can not have it implemented, document and minimize the risk with another control.
• Do not skip the normal process of software development, especially those steps involving functional testing and security testing. Any error that presents in production will be far more costly than to discover and correct it before posting the application to users.
• According to the authentication means, the risks of information assets and security controls are in place at your company, define a security architecture for applications that include the method for input data validation, internal processing control, message integrity, validation of the output data, data encryption, file security and system audit logs.
• Although you may become victim of a gang of cyber criminals looking to commit the information and finance business, the vast majority of incidents are presented by vulnerabilities that are well documented, that common people are well-aware of and become materialized because carelessness when implementing IT solutions for business.
• It is clear that security measures can never be an obstacle to achieving business goals, but keep in mind that business goals can be seriously affected by the fault or negligence in the implementation of information security controls.

-- Manuel Humberto Santander Peláez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org