by May 1, 2012 0 comments



Apart from live-production systems, every organization has some test equipment. Such systems do not have any critical data and are at times most vulnerable to security breaches.

[image_library_tag 845/64845, border=”0″ align=”right” hspace=”4″ vspace=”4″ ,default]


A few years ago we were experimenting with a Wiki application software to meet the documentation requirements of an internal team. It was setup on an old server which was supposed to be offline (disconnected from the Internet). For some reason we abandoned the project. Since it was an offline server the Wiki setup was not wiped off from the system. A year later, the system was exposed to the Internet, as another production ready application was deployed on it. In this process, the redundant Wiki applicaion was completely forgotten. This version of the application had a backdoor of which we were unaware. While this had been fixed in subsequent versions, as we had never upgraded the software. Someone was able to discover the vulnerability and managed to inject code to setup a phishing website on this very server. The phishing website was designed to collect usernames and passwords from customers of a leading bank in the country.


Thankfully, this breach was brought to our notice by a vigilant anti-phishing organization, within a few hours. We immediately took the server offline and archived the application. A careful examination of the application directory showed some extraneous text files which we duly forwarded to this organization to assist them with their investigation.


Our learning and what has changed since then

[image_library_tag 846/64846, border=”0″ align=”right” hspace=”4″ vspace=”4″ ,default]


This incident had some hard learnings for us and it is now a matter of policy to ensure the following:

  • Deploy only what is essential. All experimental and test applications remain on an internal server which is behind a firewall and not accessible from the outside. Applications are fully tested, their documentation and security bulletins scanned to ensure there are no known vulnerabilities before being deployed on production servers.
  • Check for version updates. Most software vendors send out security bulletins as and when vulnerabilities are discovered and it is worth the while to check these and also change logs of new version releases.
  • Network traffic and access logs are monitored to highlight abnormal activity. We have deployed a suite of network and services monitoring tools to generate critical alerts and send periodic reports.
  • Servers and applications meant for internal purposes should not be accessible externally. We have ensured this by implementing stringent firewall rules.

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.

<