Monday, May 27, 2013

PayPal 0 Day

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.

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?

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?

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.

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.

Monday, April 22, 2013

Vulnerability Sites

Previously I mentioned several web sites which are useful for determining current vulnerabilities.  I firmly believe that leakedin.com and pastebin.com are useful for determining vulnerabilities however they are not the most useful for looking for information unless you're looking for something specific such as customer information.  Other sites are far better at performing the task of identifying vulnerabilities such as the US Cert site and Symantec.  The National Vulnerability Database provided by US Cert is likely one of the best sites for reviewing vulnerabilities.  This site contains virtually every known vulnerability and is easily searched.

Being tasked with finding vulnerabilities I would utilize the Symantec and US Cert sites in order far more often then others.  Having a good reliable source for locating vulnerabilities is likely one of the most important things a security professional will do.  Having a credible source with valuable and easy to find information is critical.  I believe that the US Cert and Symantec sites are likely some of the most credible sources available for vulnerability information.

Sunday, April 14, 2013

Security Modeling

Modeling is perhaps one of the most critical aspects of documentation especially in the security field.  Modeling can take multiple forms and can be simple or incredibly complex however the overall purpose is always the same.  In my mind the purpose of modeling is to tell a story via pictures.  This allows individuals viewing the model to gain an in depth level of understanding in relatively short amount of time.

Modeling is important because it allows the viewers to see how things are organized.  Network diagrams show how the environment is laid out.  Use case diagrams explain the logic of operations such as security rule and script logic.  These diagrams serve multiple purposes including helping the implementer lay things out before they proceed with an implementation as well as helping train new individuals on the team.

I realize that no one truly likes creating documentation however it's incredibly important especially in the IT world.  Without documentation especially modeling diagrams it is incredibly difficult to mange the systems down the road, train new workers on the systems in place, and gain an in depth understanding of the current implementation.