I recently read on reddit.com about a 17 year old kid to discovered a cross site scripting attack (XSS) on the PayPal script. The XSS attacks takes advantage of a small amount of javascript to provide the exploit. The 17 year old German who discovered the exploit provided the exploit to PayPal as part of their bounty program however was denied because they are 17 and the minimum age to participate in the bounty program is 18. As a result the 0 day has been released to the public http://seclists.org/fulldisclosure/2013/May/163.
The purpose of this post is not specifically related to the 0 day but more of a ethical discussion on releasing exploits. I personally believe that it's perfectly acceptable for security researchers to release exploits they uncover through various security channels. However, I think that the most important part is that the organization who is affected by the 0 day is given an appropriate amount of time to fix the exploit before it's released. If for example doesn't want help as in the example of PayPal then the community has a responsibility to release the exploit so that the community is aware.
Monday, May 27, 2013
DDoS for Hire
I recently read on Krebsonsecurity.com about a new concept which is DDoS for hire services. These services allow users to purchase a DDoS on their enemies for a small fee. The small fee is generally paid via PayPal. These services generally cloke themselves as stress testing websites thus making their services sound legitimate.
Most of us who work in the security industry aren't surprised by DDoS attacks and how often they occur but you might be surprised that that activity is now being outsourced and that in some instances it might be legal. Even more surprising is that some of these providers may even be providing backdoors for the FBI to gain insight into the customers using these service providers.
These services usually are fairly inexpensive and often times are used to attack small sites or gaming sites. Many might see these services as a minor threat however these are truly a significant threat. What would happen if more and more groups decide to use large scale botnets to earn money by hosting DDoS attacks?
Most of us who work in the security industry aren't surprised by DDoS attacks and how often they occur but you might be surprised that that activity is now being outsourced and that in some instances it might be legal. Even more surprising is that some of these providers may even be providing backdoors for the FBI to gain insight into the customers using these service providers.
These services usually are fairly inexpensive and often times are used to attack small sites or gaming sites. Many might see these services as a minor threat however these are truly a significant threat. What would happen if more and more groups decide to use large scale botnets to earn money by hosting DDoS attacks?
Tuesday, May 21, 2013
Dumb Security Mistakes
I recently read a post on reddit.com regarding GCHQ. GCHQ stands for Government Communications Headquarters and is a British agency similiar to the US NSA. The poster of this article mentioned that they had utilized their site in the past however didn't remember their password. Upon using the password reset option on the site their password was emailed to them in plaintext. For those who don't understand this is a huge security risk. Anyone listening to your communication (i.e. man in the middle attack) could obtain your password with little effort. If your email account becomes compromised the attacker automatically gains access to this password as well.
It makes little sense to me that a British agency who is responsible for securing the cyber infrastructure of British citizens would let this slide even after being modified of this vulnerability. It just goes to show that no matter the agency, vulnerabilities will arise. It is however, imperative that weaknesses such as this be addressed quickly. How would you like to be an organization who loses a tremendous amount of personally identifiable information (PII) on your customers due to a dumb security mistake that is easily correctable?
It makes little sense to me that a British agency who is responsible for securing the cyber infrastructure of British citizens would let this slide even after being modified of this vulnerability. It just goes to show that no matter the agency, vulnerabilities will arise. It is however, imperative that weaknesses such as this be addressed quickly. How would you like to be an organization who loses a tremendous amount of personally identifiable information (PII) on your customers due to a dumb security mistake that is easily correctable?
Wednesday, May 8, 2013
Addressing Vulnerabilities
Is it necessary or even possible to address all vulnerabilities within your environment? I think that most experienced individuals with say the answer to this question is a resounding no. It is nearly impossible to address all vulnerabilities within your environment, unless of course you have an unlimited budget and resources but as we all know that isn't the case.
So what do you do with all these vulnerabilities? Thinking about all the things that can go wrong with your environment and the consequences of not addressing vulnerabilities may begin to make your head hurt a bit. The answer is to use an effective risk management approach to dealing with vulnerabilities. Using a risk management approach will allow you to place a value on your assets and determine the criticality of the vulnerabilities on your most important assets. Since you can't address all vulnerabilities you must use a risk management process to establish the risk associated with each vulnerability. This will allow you to focus on risks that are extremely detrimental to your environment and mitigate those while accepting a minimal risk for the others.
So what do you do with all these vulnerabilities? Thinking about all the things that can go wrong with your environment and the consequences of not addressing vulnerabilities may begin to make your head hurt a bit. The answer is to use an effective risk management approach to dealing with vulnerabilities. Using a risk management approach will allow you to place a value on your assets and determine the criticality of the vulnerabilities on your most important assets. Since you can't address all vulnerabilities you must use a risk management process to establish the risk associated with each vulnerability. This will allow you to focus on risks that are extremely detrimental to your environment and mitigate those while accepting a minimal risk for the others.
Secure Coding
Development is a passion of mine. I've been involved in the development world nearly all of my professional career. It wasn't until recently that I became aware of the topic of developing secure code. This seems like a topic that all developers should have at the forefront of their mind but I don't think that's the case. Most of the time developers develop to solve a task without taking into consideration secure development techniques. I think this is mostly due to lack of time or lack of knowledge.
When developing applications especially web applications it is imperative that developers are aware of security topics including cross site scripting, SQL injection, and buffer overflows and how the lack of secure development standards can open the door to allowing an attacker to exploit your software using one of those methods. Secure development techniques will become increasingly important as more and more applications move to cloud environments and are accessed by end users via the browser.
So the question becomes how do you protect yourself from attack by not introducing vulnerabilities into your environment? The simpliest answer is to become aware of sub par code. There are multiple methods of doing this and most utilize tools such as Fortify. Using automated build procedures such as a combination of Maven and Jenkins will allow development teams to seamlessly scan their code at build time. The result of these scans are reports identifying the weaknesses in your code. Another method of locating vulnerabilities is to TEST. Many times testing falls through the cracks but it's so incredibly important, not just for identifying logic errors within the code but also for locating vulnerabilities.
When developing applications especially web applications it is imperative that developers are aware of security topics including cross site scripting, SQL injection, and buffer overflows and how the lack of secure development standards can open the door to allowing an attacker to exploit your software using one of those methods. Secure development techniques will become increasingly important as more and more applications move to cloud environments and are accessed by end users via the browser.
So the question becomes how do you protect yourself from attack by not introducing vulnerabilities into your environment? The simpliest answer is to become aware of sub par code. There are multiple methods of doing this and most utilize tools such as Fortify. Using automated build procedures such as a combination of Maven and Jenkins will allow development teams to seamlessly scan their code at build time. The result of these scans are reports identifying the weaknesses in your code. Another method of locating vulnerabilities is to TEST. Many times testing falls through the cracks but it's so incredibly important, not just for identifying logic errors within the code but also for locating vulnerabilities.
Subscribe to:
Posts (Atom)