I am sure most of you wont believe the reasons for my hiatus for almost 4 months. Let me try and explain. I was involved in a theater production very dear to my heart, so my evenings would be lost in that. I am pursuing a heavy writing assignment, which has been uber-demanding on the small space of time I have left and I actually took my vacation in September, when I had been to beautiful South Africa. Great place! You guys must all visit.
Anyway, enough with the chatter. This piece was prompted by a talk I heard at the Business Technology Summita few days ago. Of course, I blabbed about web app sec and scared the pants off a few nervous developers and architects, but it was mostly fun. The conference mostly focused on SOA ang governance, but there were a few pure tech talks. There was one talk, which I was quite impressed with, by a fellow Java man, Eben Hewitt. He spoke on a topic entitled "10 Things Software Architects must know", which is based on a book similarly entitled, except that the '10' has been replaced with '97'. The talk was mostly about concepts which software architects should keep in mind in order to be successful. While the talk didnt really have a specific security-related context, I applied some of those theories to the way software development companies can deal with security for the apps they develop. These are just my two cents. I am sure some of you can add more to it.
I have heard of several instances where software development companies have been severely criticized for writing non-secure code. Undoubtedly so. Several software development companies dont really take secure coding to be an important practice. Time is not spent developing security in the application from the beginning, which subsequently results in a non-secure web app. The most common excuse that most of these entities give in terms of security or any other functionality not implemented is "This type of security functionality was not laid out in our Requirements Specification" or "There was nothing in RFC specifying these security requirements" and blame is thrown right back at the customers or the business users of the application for their lack of foresight. It is as if we believe that customers who will be using the application or who are functional stakeholders of a web application are actually extremely clear about their requirements. The truth is very simple. They are as clueless as you are. In most cases, they will never really know what they want even functionally, unless they are given several ideas, security is quite a mile away in these circumstances. I believe that it is upto the company or the team developing the application to incorporate a risk assessment process to ensure that they capture all the critical information assets that will be stored, processed and transmitted by the application, threats and the impact of an attack on the application and subsequently on business, and then draw out security controls for the same. I have highlighted a detailed methodology for risk assessment for web apps, in my book "Secure Java for Web Application Development".It is wrong to assume that customers or business stakeholders will be able to provide the razor sharp clarity necessary to build security into an application. Software Development companies need to rise to the occasion and use their expertise to suggest solutions and functionality for security at the beginning of the application development lifecycle.
Which brings me to my second point. People reading my first point are going, "Yeah, but isnt that going to be more expensive than a regular application development effort, without going Mother Teresa on my customer?" Yes it will be a longer, probably marginally more expensive process, but Quality is a Feature. We all try and sort out all problems all the time. Let us not try to do that and examine reality. Software development companies focussed on a greater level of quality of their products must make it explicit. You have various product and service offerings today, but it is important to realize that all services and products will not be of the same quality. A restaurant on the roadside, will not be as focused on quality than a snazzy five star restaurant. Its high time that we understood that about code as well. And its also high time that software development companies that are taking the first point seriously, start making it explicit and derive as much benefit as possible. There may be customers out there (despite the recession) that may be willing to pay better for a better service that is accentuated and re-iterated by processes like Risk assessment, effective understanding security functionality at the start of the lifecycle, vulnerability assessments, security code reviews and practices delving into security. Superior quality, in my opinion is a feature by itself, which needs to be advertised, and made explicit and should not be spoken about or practiced like its a part of the proverbial 'package'.
Let me know what you think of this....
Thursday, November 5, 2009
Saturday, July 18, 2009
PA-DSS 101
That blank feeling in my stomach, which was there for the past 2 weeks or so is slowly disappearing as I sit down to write this piece. My blog hasn't been impregnated in the past 2 weeks with my words and (sometimes meaningless) rants. I was unwell during the week and till yesterday I was at a Risk Assessment workshop on the OCTAVE methodology, where I spoke on Vulnerability Assessment and generally had some engagements which didnt allow me the time to sit down and pen something in the interest of security.
This piece is a result of an article I read in blogosphere somewhere today. It was something about Visa giving a great thrust to Software security through the PA-DSS program. Visa has indicated that Visa acquirers in all regions of the world must ensure that the merchants they newly sign must use PA-DSS Compliant Applications in their environments by the July 2010 and existing merchants should be transitioned to PA-DSS compliant Applications by the July 2012. I would see that as a welcome step in software/application security, and something that will be helpful to a huge extent in the application security quest. This is why:
What is the PA-DSS?
The PA-DSS is not as famous as its mother standard, which we all lovingly know as the PCI-DSS also known simply, as PCI. The PA-DSS is the Payment Application Data Security Standard. It is meant for commercial applications which come in contact with cardholder information either during the authorization or settlement function of the card payment transaction. PA-DSS is entirely meant for an application and consists of 14 requirements encompassing all aspects of security which a payment application will have to adhere to. This includes secure storage of cardholder information, logging, authentication&authorization, secure development and deployment, etc. The PA-DSS is a sub-set of the PCI-DSS, with the core focus on the application as opposed to the cardholder data environment in PCI-DSS. This is better explained with an example. For instance, a application developer "A" has developed an E-Commerce application which is to be sold to several merchants. Merchants all over the world are either thinking about, undergoing or have undergone PCI Compliance. If 'A' has to support his prospective customer's PCI Compliance effort, then it imperative that the application be validated as per the PA-DSS requirements. The PA-DSS is a certification for the application and not for the environment. So, if 'A' gets his application validated PA-DSS, then the application is readily designed to support the PCI requirements and merchant's PCI compliance effort wouldn't be hindered. The PA-DSS has been designed to ensure that the payment applications deployed in PCI environment must support PCI compliance, which is why the PA-DSS has come to be.
Why PA-DSS?
One of the greatest impediments for security are the applications. I have seen several environments, where the entire process of security compliance or practices comes to grinding halt because of applications being unsupportive of security requirements. Applications are the lifeblood of any entity in business today. An e-commerce merchant cannot do business without the e-commerce application and its related components. A payment processor will find it impossible to process millions of transactions a day without the financial switch and its related applications. Customers are wedded to the applications they purchase and any change is resented and sometimes not recommended as a 24x7 scenario is the need of the hour. Most of these applications fall short of basic and advanced security needs by a long shot. Several financial switch applications log the entire magnetic stripe information, including the Card number, CVV and other track elements in CLEAR TEXT, a strict no-no from the PCI standpoint as well as from a general security standpoint. Several E-commerce applications purchased and deployed by customers don't support hashing of passwords, encryption of cardholder information and not to mention web application security practices like input validation. Point of Sale applications used by merchants log the entire card number in the transaction logs and several of them dont support anything more than a 4 char password. This is a huge impediment in adhering to security requirements. Merchants and processors often struggle with security implementation because of the applications and even after the best workarounds, the risk of data being stolen, modified or destroyed still remains amply. The aim of the PA-DSS is to correct this situation by ensuring that application vendors creating commercial payment applications to be sold, must get their applications validated against the PA-DSS requirements.
Why not just PCI? Doesn't it cover Application Security?
Yes, PCI does cover application security in its requirements. In fact Requirement 6 is dedicated largely to application security practices and web application security practices, including a great deal of wisdom from the OWASP knowledge base, providing a much-needed boost to AppSec, but PCI addresses the applications which are custom developed or developed in-house. The focus of the PA-DSS is for payment applications which are to be sold, distributed or licensed to third parties. So the loop is pretty simple
Well, you do not. The PA-DSS is only applicable for applications which are part of the payment authorization and settlement cycle. So if you are a log management application, WAF, or any other application which is looking for a marketing boost from the PCI fever, you will not able to go the PA-DSS route as it is specifically for Payment Applications.
This piece is a result of an article I read in blogosphere somewhere today. It was something about Visa giving a great thrust to Software security through the PA-DSS program. Visa has indicated that Visa acquirers in all regions of the world must ensure that the merchants they newly sign must use PA-DSS Compliant Applications in their environments by the July 2010 and existing merchants should be transitioned to PA-DSS compliant Applications by the July 2012. I would see that as a welcome step in software/application security, and something that will be helpful to a huge extent in the application security quest. This is why:
What is the PA-DSS?
The PA-DSS is not as famous as its mother standard, which we all lovingly know as the PCI-DSS also known simply, as PCI. The PA-DSS is the Payment Application Data Security Standard. It is meant for commercial applications which come in contact with cardholder information either during the authorization or settlement function of the card payment transaction. PA-DSS is entirely meant for an application and consists of 14 requirements encompassing all aspects of security which a payment application will have to adhere to. This includes secure storage of cardholder information, logging, authentication&authorization, secure development and deployment, etc. The PA-DSS is a sub-set of the PCI-DSS, with the core focus on the application as opposed to the cardholder data environment in PCI-DSS. This is better explained with an example. For instance, a application developer "A" has developed an E-Commerce application which is to be sold to several merchants. Merchants all over the world are either thinking about, undergoing or have undergone PCI Compliance. If 'A' has to support his prospective customer's PCI Compliance effort, then it imperative that the application be validated as per the PA-DSS requirements. The PA-DSS is a certification for the application and not for the environment. So, if 'A' gets his application validated PA-DSS, then the application is readily designed to support the PCI requirements and merchant's PCI compliance effort wouldn't be hindered. The PA-DSS has been designed to ensure that the payment applications deployed in PCI environment must support PCI compliance, which is why the PA-DSS has come to be.
Why PA-DSS?
One of the greatest impediments for security are the applications. I have seen several environments, where the entire process of security compliance or practices comes to grinding halt because of applications being unsupportive of security requirements. Applications are the lifeblood of any entity in business today. An e-commerce merchant cannot do business without the e-commerce application and its related components. A payment processor will find it impossible to process millions of transactions a day without the financial switch and its related applications. Customers are wedded to the applications they purchase and any change is resented and sometimes not recommended as a 24x7 scenario is the need of the hour. Most of these applications fall short of basic and advanced security needs by a long shot. Several financial switch applications log the entire magnetic stripe information, including the Card number, CVV and other track elements in CLEAR TEXT, a strict no-no from the PCI standpoint as well as from a general security standpoint. Several E-commerce applications purchased and deployed by customers don't support hashing of passwords, encryption of cardholder information and not to mention web application security practices like input validation. Point of Sale applications used by merchants log the entire card number in the transaction logs and several of them dont support anything more than a 4 char password. This is a huge impediment in adhering to security requirements. Merchants and processors often struggle with security implementation because of the applications and even after the best workarounds, the risk of data being stolen, modified or destroyed still remains amply. The aim of the PA-DSS is to correct this situation by ensuring that application vendors creating commercial payment applications to be sold, must get their applications validated against the PA-DSS requirements.
Why not just PCI? Doesn't it cover Application Security?
Yes, PCI does cover application security in its requirements. In fact Requirement 6 is dedicated largely to application security practices and web application security practices, including a great deal of wisdom from the OWASP knowledge base, providing a much-needed boost to AppSec, but PCI addresses the applications which are custom developed or developed in-house. The focus of the PA-DSS is for payment applications which are to be sold, distributed or licensed to third parties. So the loop is pretty simple
if (inHouseApplication() || customCode()) {
validateAsPerPCIDSS();
} else {
validateAsPerPADSS();
}
Well, you do not. The PA-DSS is only applicable for applications which are part of the payment authorization and settlement cycle. So if you are a log management application, WAF, or any other application which is looking for a marketing boost from the PCI fever, you will not able to go the PA-DSS route as it is specifically for Payment Applications.
Saturday, June 27, 2009
Why attackers love your developers!
Kind Sir
My name is Developer A. I am having a problem with database connectivity to Oracle. I think I am doing everything right, but I am getting an HTTP 500 error with the following details:
(Full Stack trace follows)
The sample of the source code is given here.
(Source Code follows)
The error where it is occurring is at this URL (Organization's url follows)
Please help me out with this as soon as possible. I reeeallly need help!!!
Email me at developerA@organization.com
My advice to organizations to prevent against such ignominious disclosures are these:
- Instruct developers never to post in internet forums under their own name or with their company credentials like emails, etc.
- Encourage developers to first find help within the organization. I have seen that several greenhorns tend to be afraid of asking their seniors or project managers any doubts regarding the code, fearing a nasty remark or backlash. Build an environment of openness and encourage questions. Not doing so, would result in these juniors asking questions anyway, but to someone you are totally not aware of, not bound by confidentiality agreements, etc.
- If someone really has to post queries on the Internet, make sure that these are approved. Source code should not be posted. Stack trace should not be posted. Questions should be based on peripheral details and no sensitive information should be posted. Words like "Kind sir" should definitely be filtered out of posts ;)
- Have your risk folks scour the internet regularly checking for violations and take action against people violating these instructions.
Sunday, June 21, 2009
PCI Compliance: Hazards of the "Dull-Clarity" effect
It has been a while since I sat down to write a post for my blog. The monsoon season has just set in this part of the world. The days are hot and it rains heavily on occasion causing one to just enjoy the comfort of his bed a little more than usual.
This was a piece, which had been in the works for sometime now. I had planned to write it, close on the heels of the Savvis lawsuit (for the CardSystems breach), but I missed my cue. Anyway, here goes. This lawsuit has been abuzz in blogosphere because some of the banks that were processing their card transactions through CardSystems (which was involved with one of the largest credit card breaches in history), have decided to file a lawsuit against Savvis, the organization that attested to the compliance of CardSystems, with the Visa compliance requirement called CISP (Cardholder Information Security Program). The CISP was the predecessor to someone we all know lovingly as the PCI-DSS (Payment Card Industry Data Security Standard). A little background here. CardSystems was one of the largest credit card processors in the US, and they were involved in a breach which compromised over 40 million card numbers. Savvis was the company, which certified CardSystems as compliant with the standards. Now, four years later, Merrick Bank has filed a case against Savvis, alleging that it has been negligent in certifying CardSystems. Frankly, I am not aware of whether Savvis has been negligent or not, but blogosphere and online news portals have gone wild with the news. The Security gurus are quoting their same old lines of the inadequacy of PCI Compliance and are questioning the 'rigour' of the standard in the protection of cardholder information.
My intention with this piece is 1) To introduce the some people out there to the concepts of "Reasonable Assurance" and "as on date"; Two concepts which have been in lost in the rhetoric which several security folks have been dishing out relentlessly. 2) Drive home my point of Risk based compliance, another concept which has been dulled with wrong interpretations of the PCI Standards 3) and hope that a few organizations would actually understand the concept of PCI being risk-driven as opposed to a dull checklist, requiring their meek submissiveness.
The security world has much to learn from the Financial audit and assurance world. No auditor will be able to guarantee that an organization's financial statements are free from error or misstatement. The auditor has to do everything that a prudent person in his place would do and in the end, signs off on a report which states that a "reasonable assurance" can be provided with respect to the financial statements. The auditor is not god, and the laws are quite aware of that and have provided for a similar treatment. Moreover, the auditor does not have to look for fraud, another basic truth in the financial audit world. The auditor must perform a risk assessment and gain an understanding of Internal control, before he performs his audit tasks. Contrast this with the security world. Information Security assurance, being nascent as it is, has not promulgated such basic truths to its practicing professionals. It still (subtly) preaches the utopian ideals of "Perfect security" Furthermore, PCI as a standard still has a very hazy understanding of what assurance the QSA actually provides. Is it "Reasonable Assurance" or is it a guarantee, because if it is a guarantee, then QSAs should pack their bags and quit the business, because that is impossible to provide. When it comes to reasonable assurance, the only defense that an auditor should provide in his alleged negligence, is his working papers and evidence. So my advice to people who are QSAs, please keep your workpapers and evidence in perfect auditor, they are your only saving grace tomorrow when fingers are pointed at you.
Another important concept which people usually miss out with PCI Compliance is the "as on date" concept. When an assessor certifies an organization for PCI, the certification is done as on date and not for the "period ending". I have seen several companies take the proverbial snooze after their PCI Compliance. 8/10 organizations I have seen have serious issues with their applications, or their network configurations or their log management and review. They would have slipped into non-compliance several times during the year and would have remained so till the the recertification for PCI Compliance. An assessor cannot be held responsible for the negligent organization on a future date, unless he has wrongfully or negligently assessed the misgiving as compliant as on the date of certification. I would like to add, at this juncture that I am not aware of whether Savvis was actually negligent or not. Its negligence can only be established once its made to produce evidence of its assessment and its work papers in front of a court. My advise to assessors is to go ahead and fail organizations which have not demonstrated compliance throughout the year.
When it comes to Risk based compliance, my views have already been aired, but I would like reiterate some practical angles to the same. Several clients ask me, "Where does it say that this has to be done in the PCI Standards?" The greatest advantage of the PCI Standards is also its weakest point. Its clarity. Several organizations interpret PCI to be a checklist requirement set which they need to fulfill and be done with. The PCI has acquired a reputation of being a standard which prescribes exaclty what to do and how to do it and that it is inflexible in its approach. True, it is specific, which is why, when a recommendation outside its realm, but very much in the realm of specific risk is given, it is quickly shot down by an organization as not being specific in the requirement. I have several (often heated) arguments with clients who ask me questions like, "Where does PCI say that Internet access to these partiular set of users should be blocked?", My reply to them is that PCI is a baseline set of controls to be applied to any environment storing, processing or transmitting cardholder information. For such specific requirements, a risk assessment is in order, which narrows down certain risks which are specific to the environment. If the risk of individuals having access to cardholder information as well as the Internet (where cardholder information can be sent over email or over the internet in any way) is high, then it is only prudent that you mitigate the risk and not let it become your Achilles Heel. My advice to organizations. Dont look at PCI as a checklist for truly being secure. Treat PCI as a baseline and add to it controls for the risks which are specific to your environment.
I would like to conclude by stating this. PCI Compliance, like anything else in Information security, is at its growing phase. There are bound to be a few teething problems with respect to the standard and its expectations. An organization intent on pursuing PCI Compliance should not be misguided by the pure view of the 12 requirements of PCI, but to understand the risks before going into requirements.
This was a piece, which had been in the works for sometime now. I had planned to write it, close on the heels of the Savvis lawsuit (for the CardSystems breach), but I missed my cue. Anyway, here goes. This lawsuit has been abuzz in blogosphere because some of the banks that were processing their card transactions through CardSystems (which was involved with one of the largest credit card breaches in history), have decided to file a lawsuit against Savvis, the organization that attested to the compliance of CardSystems, with the Visa compliance requirement called CISP (Cardholder Information Security Program). The CISP was the predecessor to someone we all know lovingly as the PCI-DSS (Payment Card Industry Data Security Standard). A little background here. CardSystems was one of the largest credit card processors in the US, and they were involved in a breach which compromised over 40 million card numbers. Savvis was the company, which certified CardSystems as compliant with the standards. Now, four years later, Merrick Bank has filed a case against Savvis, alleging that it has been negligent in certifying CardSystems. Frankly, I am not aware of whether Savvis has been negligent or not, but blogosphere and online news portals have gone wild with the news. The Security gurus are quoting their same old lines of the inadequacy of PCI Compliance and are questioning the 'rigour' of the standard in the protection of cardholder information.
My intention with this piece is 1) To introduce the some people out there to the concepts of "Reasonable Assurance" and "as on date"; Two concepts which have been in lost in the rhetoric which several security folks have been dishing out relentlessly. 2) Drive home my point of Risk based compliance, another concept which has been dulled with wrong interpretations of the PCI Standards 3) and hope that a few organizations would actually understand the concept of PCI being risk-driven as opposed to a dull checklist, requiring their meek submissiveness.
The security world has much to learn from the Financial audit and assurance world. No auditor will be able to guarantee that an organization's financial statements are free from error or misstatement. The auditor has to do everything that a prudent person in his place would do and in the end, signs off on a report which states that a "reasonable assurance" can be provided with respect to the financial statements. The auditor is not god, and the laws are quite aware of that and have provided for a similar treatment. Moreover, the auditor does not have to look for fraud, another basic truth in the financial audit world. The auditor must perform a risk assessment and gain an understanding of Internal control, before he performs his audit tasks. Contrast this with the security world. Information Security assurance, being nascent as it is, has not promulgated such basic truths to its practicing professionals. It still (subtly) preaches the utopian ideals of "Perfect security" Furthermore, PCI as a standard still has a very hazy understanding of what assurance the QSA actually provides. Is it "Reasonable Assurance" or is it a guarantee, because if it is a guarantee, then QSAs should pack their bags and quit the business, because that is impossible to provide. When it comes to reasonable assurance, the only defense that an auditor should provide in his alleged negligence, is his working papers and evidence. So my advice to people who are QSAs, please keep your workpapers and evidence in perfect auditor, they are your only saving grace tomorrow when fingers are pointed at you.
Another important concept which people usually miss out with PCI Compliance is the "as on date" concept. When an assessor certifies an organization for PCI, the certification is done as on date and not for the "period ending". I have seen several companies take the proverbial snooze after their PCI Compliance. 8/10 organizations I have seen have serious issues with their applications, or their network configurations or their log management and review. They would have slipped into non-compliance several times during the year and would have remained so till the the recertification for PCI Compliance. An assessor cannot be held responsible for the negligent organization on a future date, unless he has wrongfully or negligently assessed the misgiving as compliant as on the date of certification. I would like to add, at this juncture that I am not aware of whether Savvis was actually negligent or not. Its negligence can only be established once its made to produce evidence of its assessment and its work papers in front of a court. My advise to assessors is to go ahead and fail organizations which have not demonstrated compliance throughout the year.
When it comes to Risk based compliance, my views have already been aired, but I would like reiterate some practical angles to the same. Several clients ask me, "Where does it say that this has to be done in the PCI Standards?" The greatest advantage of the PCI Standards is also its weakest point. Its clarity. Several organizations interpret PCI to be a checklist requirement set which they need to fulfill and be done with. The PCI has acquired a reputation of being a standard which prescribes exaclty what to do and how to do it and that it is inflexible in its approach. True, it is specific, which is why, when a recommendation outside its realm, but very much in the realm of specific risk is given, it is quickly shot down by an organization as not being specific in the requirement. I have several (often heated) arguments with clients who ask me questions like, "Where does PCI say that Internet access to these partiular set of users should be blocked?", My reply to them is that PCI is a baseline set of controls to be applied to any environment storing, processing or transmitting cardholder information. For such specific requirements, a risk assessment is in order, which narrows down certain risks which are specific to the environment. If the risk of individuals having access to cardholder information as well as the Internet (where cardholder information can be sent over email or over the internet in any way) is high, then it is only prudent that you mitigate the risk and not let it become your Achilles Heel. My advice to organizations. Dont look at PCI as a checklist for truly being secure. Treat PCI as a baseline and add to it controls for the risks which are specific to your environment.
I would like to conclude by stating this. PCI Compliance, like anything else in Information security, is at its growing phase. There are bound to be a few teething problems with respect to the standard and its expectations. An organization intent on pursuing PCI Compliance should not be misguided by the pure view of the 12 requirements of PCI, but to understand the risks before going into requirements.
Sunday, June 7, 2009
OWASP Membership
I became a member in the OWASP (Open Web Application Security Project) today. I am glad to support the great initiative for Web Application Security, which has been taken by OWASP.
For all reading this, please become OWASP members, it is a great initiative, which is completely free. We should do all we can to support it. It costs just $50 for the Individual membership for a year.
Please join up and make a difference
For all reading this, please become OWASP members, it is a great initiative, which is completely free. We should do all we can to support it. It costs just $50 for the Individual membership for a year.
Please join up and make a difference
OWASP Bangalore Chapter Meet: 7th June 2009
It was the first meeting of the OWASP Bangalore Chapter that I was attending. The meeting was scheduled at 9am at the India Coffee House on Church Street in Bangalore. Although, the location was not the most suitable, especially keeping in mind that that presentations on App Sec and other Info Sec related issues would be part of the meeting. Nevertheless, it was nice seeing some energy from this chapter.
Rajiv Vishwa's was the only presentation on using Firefox as the ultimate App Sec assessment tool. Rajiv demonstrated the use of several Mozilla Addons like Tamper Data, XSS-Me, SQL Inject-me demoed over Webgoat to a small group of dedicated OWASPers in Bangalore. It was an interesting presentation, which highlighted the fact, that there are several tools for performing AppSec assessments and a pen-tester would never really have to leave the comfort of the browser to perform security testing for applications. Mozilla provides several other addons like Firebug, FoxyProxy, etc, which allow the easy assessment of web applications. Although Rajiv had to leave early, I took over and we discussed talked more AppSec. I stressed on the use of exploit frameworks like Metasploit for Pentests and also discussed how Application development needs to be given the impetus, it so badly deserves from the security standpoint. We signed off on a positive note.
The Bangalore Chapter has some great energy going but needs a lot more to live up to the reputation of being the OWASP Chapter in the Silicon Valley of India. It would be great to see more Bangaloreans interested in AppSec and InfoSec attend the Chapter meets and play an active role in the development of this community. I will try and get in touch with the ISACA Chapter in Bangalore for some joint meetings and meeting space. Hopefully, things should go well on that front. I would request anyone part of the OWASP Bangalore Mailing list to actively participate and probably initiate some action on the location issue for the chapter. There is a nice quote which I would like to share with all of you, "I ask not for lighter burden, but for stronger shoulders".
Thanks
Rajiv Vishwa's was the only presentation on using Firefox as the ultimate App Sec assessment tool. Rajiv demonstrated the use of several Mozilla Addons like Tamper Data, XSS-Me, SQL Inject-me demoed over Webgoat to a small group of dedicated OWASPers in Bangalore. It was an interesting presentation, which highlighted the fact, that there are several tools for performing AppSec assessments and a pen-tester would never really have to leave the comfort of the browser to perform security testing for applications. Mozilla provides several other addons like Firebug, FoxyProxy, etc, which allow the easy assessment of web applications. Although Rajiv had to leave early, I took over and we discussed talked more AppSec. I stressed on the use of exploit frameworks like Metasploit for Pentests and also discussed how Application development needs to be given the impetus, it so badly deserves from the security standpoint. We signed off on a positive note.
The Bangalore Chapter has some great energy going but needs a lot more to live up to the reputation of being the OWASP Chapter in the Silicon Valley of India. It would be great to see more Bangaloreans interested in AppSec and InfoSec attend the Chapter meets and play an active role in the development of this community. I will try and get in touch with the ISACA Chapter in Bangalore for some joint meetings and meeting space. Hopefully, things should go well on that front. I would request anyone part of the OWASP Bangalore Mailing list to actively participate and probably initiate some action on the location issue for the chapter. There is a nice quote which I would like to share with all of you, "I ask not for lighter burden, but for stronger shoulders".
Thanks
Saturday, June 6, 2009
My brush with the Gumblar worm
Some of you might have heard of the new worm out there known as the Gumblar worm or the gumblar.cn worm. It is a worm which has been spreading rampantly across the internet. This worm has become the scourge of the internet after the conficker worm. The Gumblar worm has two ugly sides to it, both of which I have been exposed to.
This was way back in March, when we were performing a company's website assessment. The company had outsourced their website development activity to a organization that designs websites. The company had run into a few security issues including Directory traversal vulnerabilities and weak passwords which the web design company had caused. Once the website was up, I opened up the page to see my Avast Anti-virus light up like a Christmas tree, with a malware alert for a "JS:Redirect" worm. Needless to say upon exploring the source in the php and html files, I found that a large piece of javascript code, which had no apparent business being on the page, was there. It was obfuscated code, which obviously caused the worm to propogate. The Javascript code for Gumblar is given below:
I have removed the Gumblar worm code as some AV apps were throwing up alerts from their content filtering engines. Please check elsewhere for a copy of the code.
The gumblar worm infects the PC when the PC opens up the website which is infected the malicious javascript.
The execution of the malicious code results in a backdoor being installed which attaches itself to Internet Explorer and also manipulates Google searches. Furthermore the worm is also known to disable anti-virus software, install fake av applications and also sends out spam. This is the one facet of the Gumblar worm. The other facet of the Gumblar worm, is worse and is extremely worrisome for a security professional. Gumblar also steals FTP credentials and appends itself to pages hosted in the webserver, thereby wreaking havoc to a webserver. This means to say that Hosting providers and webservers hosted by organizations may well have already been seriously compromised. FTP credentials have been stolen several webpages hosted in webservers all ovetr the world have been affected by the gumblar worm. The number of attacks over the last week have grown by 188% and counting and has accounted for over 42% of the malware detected all over the world. The number of infected websites has jumped from 800 to over 3000 in a matter of a few weeks.
As you can see, the gumblar botnet really goes two different types of systems. One it goes after PCs, where the PC is infected and the Google searches, Internet Explorer and the vulnerabilities in Adobe Acrobat are exploited. The other system is the Webserver, where it goes after FTP passwords and then appends the code onto all the web pages in the webserver. I first experienced this worm in March of this year and the worm has now started surfacing in all its glory. So, for all of you, here are some tips to stay safe and keep your website safe:
1. Latest AV Definitions: The biggest issue has been that Antivirus vendors except, I think, Avast and Kaspersky have not woken up to this issue till recently. Please make sure that your AV definitions are up and functional against Gumblar's many variants.
2. FTP Credentials: This is a good time to run a thorough manual and automated scan of the webserver and change the FTP credentials for all users in the system. It would also make sense for organizations hosting their web content with hosting providers to talk to them and see how their dealing with the situation. Also, please make sure that the FTP passwords are stored securely and that there is adequate encryption or hashing which is used to protect the same.
3. NoScript: For ordinary users out there, please use NoScript with Mozilla Firefox, it goes the distance in protecting you from the malicious javascript in websites against executing and infecting your PC.
4. Hosting and Web Design organizations: Please make sure that your hosting providers also take the same precautionary measures. In case you are having your website being designed by others, please make sure you test it in a staging environment before deploying it over the Internet. You might be aiding in the propogation of the worm.
5. IPS signatures: I already know for a fact that ISS Proventia has signatures released for the Gumblar worm. I am sure others would have also done so. Please keep the IPS updated for the Gumblar sigs.
This was way back in March, when we were performing a company's website assessment. The company had outsourced their website development activity to a organization that designs websites. The company had run into a few security issues including Directory traversal vulnerabilities and weak passwords which the web design company had caused. Once the website was up, I opened up the page to see my Avast Anti-virus light up like a Christmas tree, with a malware alert for a "JS:Redirect" worm. Needless to say upon exploring the source in the php and html files, I found that a large piece of javascript code, which had no apparent business being on the page, was there. It was obfuscated code, which obviously caused the worm to propogate. The Javascript code for Gumblar is given below:
I have removed the Gumblar worm code as some AV apps were throwing up alerts from their content filtering engines. Please check elsewhere for a copy of the code.
The gumblar worm infects the PC when the PC opens up the website which is infected the malicious javascript.
The execution of the malicious code results in a backdoor being installed which attaches itself to Internet Explorer and also manipulates Google searches. Furthermore the worm is also known to disable anti-virus software, install fake av applications and also sends out spam. This is the one facet of the Gumblar worm. The other facet of the Gumblar worm, is worse and is extremely worrisome for a security professional. Gumblar also steals FTP credentials and appends itself to pages hosted in the webserver, thereby wreaking havoc to a webserver. This means to say that Hosting providers and webservers hosted by organizations may well have already been seriously compromised. FTP credentials have been stolen several webpages hosted in webservers all ovetr the world have been affected by the gumblar worm. The number of attacks over the last week have grown by 188% and counting and has accounted for over 42% of the malware detected all over the world. The number of infected websites has jumped from 800 to over 3000 in a matter of a few weeks.
As you can see, the gumblar botnet really goes two different types of systems. One it goes after PCs, where the PC is infected and the Google searches, Internet Explorer and the vulnerabilities in Adobe Acrobat are exploited. The other system is the Webserver, where it goes after FTP passwords and then appends the code onto all the web pages in the webserver. I first experienced this worm in March of this year and the worm has now started surfacing in all its glory. So, for all of you, here are some tips to stay safe and keep your website safe:
1. Latest AV Definitions: The biggest issue has been that Antivirus vendors except, I think, Avast and Kaspersky have not woken up to this issue till recently. Please make sure that your AV definitions are up and functional against Gumblar's many variants.
2. FTP Credentials: This is a good time to run a thorough manual and automated scan of the webserver and change the FTP credentials for all users in the system. It would also make sense for organizations hosting their web content with hosting providers to talk to them and see how their dealing with the situation. Also, please make sure that the FTP passwords are stored securely and that there is adequate encryption or hashing which is used to protect the same.
3. NoScript: For ordinary users out there, please use NoScript with Mozilla Firefox, it goes the distance in protecting you from the malicious javascript in websites against executing and infecting your PC.
4. Hosting and Web Design organizations: Please make sure that your hosting providers also take the same precautionary measures. In case you are having your website being designed by others, please make sure you test it in a staging environment before deploying it over the Internet. You might be aiding in the propogation of the worm.
5. IPS signatures: I already know for a fact that ISS Proventia has signatures released for the Gumblar worm. I am sure others would have also done so. Please keep the IPS updated for the Gumblar sigs.
Subscribe to:
Posts (Atom)