Great post to bookmark…this guy has a great list of sites out there that you can practice on.
http://securitythoughts.wordpress.com/2010/03/22/vulnerable-web-applications-for-learning/
Hack away.
I few weeks ago I received an American Express gift card at work and I set out to blow the money. I had been thinking about getting an ebook reader for a few months, but didn’t want to spend the money because I’m not really an early adopter. Since this was someone else’s money, I deciding to take the plunge. I spent a few weeks weighing the different ebook reader offerings. I looked at the Kindle 2, the Kindle DX, the Sony readers, and the Barnes and Noble Nook. Ultimately I ended up buying the Nook by Barnes and Noble, and here’s why.
I was attracted the the Kindle early on, but about the time I was looking was when they took a bunch of books out of their ebook store in a power play against Macmillion Publishers. I don’t like that kind of instability, so that was an instant con. B&N is a brick and mortar store with more leverage, so I don’t think this type of crap will happen with them. I also didn’t like the fact that you had to buy books from Amazon in their proprietary format. This Apple like behavior was a real turn off (notice the Ipad was not considered). B&N has more ebooks, so this decision was easy for me.
Pros
Cons
All in all, I love my Nook. I can download ebooks while on the road with the included AT&T wireless. I haven’t tried out the periodical subscriptions yet, but likely will soon. I still have some gift card money, so will be loading up the nook with more ebooks.
The recent news of the Predator UAV getting “hacked” highlights the importance of making the right decisions at design time. The article says “some” of the drones have this vulnerability; which leads me to believe that the ones affected are probably the first generation. I have to give General Atomics the benefit of the doubt that all of the Predator drones do not have this vulnerability. Even still, the thought of putting an aircraft into production without encrypting the video data link is just poor judgment.
As a result, people are wanting the cybersecurity czar position to be filled. There’s a really good reason why that position has not been filled…it’s a do-nothing position. How could a position with no budget and no statutory power have influenced a situation like this? Realistically the person would just be a fall guy waiting on the day for a huge breach that he had no ability to prevent. Again, another poor design decision.
If so, you can be absolved of your sins by buying bad code offsets! I’m not sure whether I should laugh at such a stupid idea or be envious because I didn’t think of it first. This is a phenomenal example of a stupid tax.
Here’s the group’s vision:
We envision a world where software runs cleanly and correctly as it simplifies, enhances and enriches our day to day work and home lives. Mitigating the scope and negative impact of bad code on our jobs, our lives and our world is our all–consuming passion. We foresee a time when bad coding practices and their rotten fruits have been eliminated from this earth and its server farms thereby heralding a new age of software brilliance and efficacy.
Nettlesome bugs and poorly written code have been constant impediments towards realizing our full potential as programmers and engineers. Bad Code Offsets provides the vehicle for balancing the scales of poor past practice while freeing us to pursue current excellence in code development. Until the dawn of the worldwide, bug free code base, each of us can take steps towards reducing our bad code footprint and remediate the bad code that we have each individually and collectively left behind on the desktops, servers and mainframes at school, at work and at home.
As much as I would like to think that we are progressing towards a time where software will ship bug free, reality says that it’s impossible. The best programmers in the world occasionally right bad code. We’ve all done it at some time in our lives. I recently opened some PHP code I wrote 5 years ago and was appalled.
I once worked with a group that was CMM-I level 5 certified. This group worked at least 2 years on a single project. Management dropped the project when they found out the group had written zero lines of code. They had a magnificent requirements document though! Moral of the story: bad code is a reality of life, get used to it.
To top the joke off, the group behind these offsets are donating the money to open source foundations who are “carrying the fight against bad code on a daily basis.” The key word there is fight, and it’s not just the FOSS groups that are fighting it…we all are. If these groups write such good code, why do we hear about buffer overflow vulnerabilities in Apache HTTP Server or cross-site scripting in Drupal (both on the donor list)? Yeah they fix them when they are notified, but so do most other developers.
If developers feel so bad, let’s donate to something that will actually benefit someone other than the people running the scam. For every $400 that’s donated, I’ll sponsor a poor child’s food, clothes, toys, and education for a year. Clothing a kid for a year sounds much more appealing to me than pouring money into FreeBSD. In return, I’ll email you a certificate saying your coding sins are absolved and the world’s now a better place.
So says an article over at networkworl.com. The crazy part is that number doesn’t include the attacks that go unnoticed. The DoD, as well as the rest of the world, is still behind the curve on detecting application attacks. I’m betting the numbers in this report should be much large.
This one is a rant, so if you don’t want to hear me whine about Delta exit stage left. So one week ago today, I was in Vegas waiting on a Delta flight. My flight the previous day was going to make me miss my connecting flight and I would have to stay overnight in Atlanta. Let’s see, overnight in Vegas or overnight in Atlanta? Ha, Vegas. Even though I’m missing billable time, I get another night in Vegas. Next day, flight’s delayed again and I get home 7 hours later from the altered flight, 24 hours from my original flight.
Fast forward 6 days, about to leave for the airport headed to Vegas again. Get an email from Delta that my flight was cancelled and I’m rebooked for the next day. So I’m out one night of hotel stay and I’m going to miss over half of DefCon. My buddies that I’m flying with get booked for an earlier flight and get upgraded to business class. I get a standby ticket and no business class. I call SkyMiles to complain, they say tough crap. I ask the girl why I should continue to fly Delta, her reply is “I don’t know”. She took the words right out of my mouth.
This morning get to airport 1 hour before flight and there’s one girl working the desk and there’s a huge line. Tried the kiosk, told me to see an agent. Plane leaves when I’m next in line.
Long story short, fool me once shame on you. Fool me 5 times, shame on me.
I’m sick and tired of not only getting screwed by Delta, but also the fake apologies. They don’t give a damn about any of us. Because I can’t get a reliable flight, I have to now drive 2.5 hours to Atlanta to fly. Does anyone know of a better airline? I’m on the market…
On the Daily Dave mailing list there’s an interesting discussion about the value of static analysis. For those unaware of what static analysis is, static analysis is analyzing source code to find potential vulnerabilities. Like every technology, static analysis has it’s pros and cons. I don’t actually subscribe to the mail list (I only use RSS), so I’m going to write a little about my views on static analysis.
Pros
In the security world, the big fight is between static versus dynamic analysis. By dynamic, most people talk about penetration testing. The results from automated penetration tools usually contain low amounts of false positives, but your test is dependant on the tests ran by the tool. Pen-testing tools can and do miss vulnerabilities. Static analysis on the other scans ALL code. If there are vulnerabilities in the corners of your application that are typically not used, then static analysis has a higher probability of finding these vulnerabilities. In addition to finding obscure vulnerabilities, static analysis can also find more categories of vulnerabilities. Automated pen-test tools are limited because they can only see http responses. Static analysis tools can apply rules that are more focused on your development platforms.
Cons
The biggest argument against static analysis is it produces too many false positives. The common misconception here is that the tool is not saying “this is vulnerable”, the tool is actually saying “this is potentially vulnerable and needs to be audited to be sure”. Yes this creates a lot of work, but this argument really only applies to first time scans. Most of the major static analysis applications are rule based and give better results over time. After the initial triage, you suppress false positives and create custom rules to make the scan more context specific. For example, on the mailing list someone referred to static analysis tools producing false positives on custom memory management libraries. This is true, out of the box most scanners are going to flag this because they don’t know what the library does and want human eyes to verify. If you’re using Fortify SCA, you can write a custom rule to eliminate those false positives in the future. Because I’m a Fortify consultant, I know that the more you tailor our static analysis software to your application the better your results set. Static analysis shouldn’t be a one shot scan, it should be used continually throughout development and testing.
Conclusion
In the end, it’s not static analysis versus dynamic analysis. In reality, you should be using BOTH. Static analysis is going to give you a sense of how secure you code is. Penetration testing is going to find easily exploitable vulnerabilities. If you are concerned about false positives with static analysis, check out Fortify Program Trace Analyzer (PTA). PTA does static analysis automatically as you are doing functional testing. The results are extremely conservative. If PTA finds a vulnerability, you can usually take it to the bank.
AP is reporting that the Treasury Department, Secret Service, and “other” agencies were the victim of a Denial of Service attack over the 4th of July weekend. The South Korean government was also attacked, fueling speculation that the attack came from North Korea.
Is North Korea getting smart? Even though they are making advances in their missile technology, they would still get spanked if they went to war with pretty much any of the major nations. In cyberspace though, they could rival the abilities of the major nations.
Even with a small group of hackers, North Korea could plan massive attacks against pretty much anyone they want. Imagine them developing or purchasing a botnet, then using this botnet to launch a Denial of Service attack. These attacks are nearly impossible to block and it would be difficult to trace the attack back to North Korea.
Given the success of this attack, I would expect to see more of this from North Korea in the future. This further underscores the importance of the DoD cyberspace initiatives.
Update: Plot Thickens
There’s more info out now that says this could be a botnet and that some South Koreans are being hit with a virus. The attack is also ongoing…this should be interesting.
I read an interesting question this morning concerning what to teach developers. Should organizations spend time teaching developers hacking techniques or writing secure software? If both, how should they mix it up?
I’m happy to hear questions like this because it’s putting the focus where it needs to be: on developers. For far too long security has been focused on the network. I can’t remember where the statistic came from, but I think ~75% of breaches last year were application based. Training developers to stop vulnerabilities early in the SDLC is the best way of shrinking that percentage.
Teaching developers about hacking techniques is important. I believe Sun Tzu said “know thy enemy” and that was hundreds of years ago. With that being said, developers do not need to know everything about hacking techniques. If an individual developer is interested in software security, encourage them to learn more. This type of developer is referred to as a “satellite” in Building Security In Maturity Model (BIMM). Satellites can be extremely useful in raising the awareness of software security and sharing ways to stop vulnerabilities. In BIMM, they are a crucial part of the success of the Software Security Group (SSG).
Every developer should have a crash course in software security covering the consequences of writing insecure software and the most common attacks. I think the focus should be on writing better software; specifically writing reusable software that emphasizes security. Keeping developers trained on writing secure software is difficult, so its better to take them out of the loop. Try to break your applications up into pieces and use secure frameworks to move information between the layers. This is a much better approach than relying on every developer to know how to prevent security vulnerabilities.
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!