Secure programming is a huge issue and it’s the lack of it that causes all the problems we have with vulnerabilities and the exploits associated with them. If everywhere developers followed secure programming practices we wouldn’t have buffer overflow issues or unsanitized parameters leading to SQL Injection.

The NSA (National Security Agency), working with MITRE, SANS, and dozens of industry experts from many other organizations, has published a valuable list of the top 25 most dangerous programming errors.

I hope more companies take notice of this and train their developers properly, rather than squeezing maximum efficiency and LOC out of them – teach them to code properly and securely too!

The 2009 CWE/SANS Top 25 Most Dangerous Programming Errors is a list of the most significant programming errors that can lead to serious software vulnerabilities. They occur frequently, are often easy to find, and easy to exploit. They are dangerous because they will frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all.

The list is the result of collaboration between the SANS Institute, MITRE, and many top software security experts in the US and Europe. It leverages experiences in the development of the SANS Top 20 attack vectors (http://www.sans.org/top20/) and MITRE’s Common Weakness Enumeration (CWE) (http://cwe.mitre.org/). MITRE maintains the CWE web site, with the support of the US Department of Homeland Security’s National Cyber Security Division, presenting detailed descriptions of the top 25 programming errors along with authoritative guidance for mitigating and avoiding them. The CWE site also contains data on more than 700 additional programming errors, design errors, and architecture errors that can lead to exploitable vulnerabilities.

The main goal for the Top 25 list is to stop vulnerabilities at the source by educating programmers on how to eliminate all-too-common mistakes before software is even shipped. The list will be a tool for education and awareness that will help programmers to prevent the kinds of vulnerabilities that plague the software industry. Software consumers could use the same list to help them to ask for more secure software. Finally, software managers and CIOs can use the Top 25 list as a measuring stick of progress in their efforts to secure their software.

It’s good to see such a comprehensive project being published on the Internet for free, the aim behind this is just to make more secure code. There’s no hidden commercial agenda or aim to sell services or software packages on the back of this.

If you know anyone in the development field I suggest you forward the list to them and tell them to send it to anyone involved in software development (same goes for commercial and non-commercial projects).

There’s no excuse for insecure code!

The Top 25 list was developed at the end of 2008. Approximately 40 software security experts provided feedback, including software developers, scanning tool vendors, security consultants, government representatives, and university professors. Representation was international. Several intermediate versions were created and resubmitted to the reviewers before the list was finalized. More details are provided in the Top 25 Process page

To help characterize and prioritize entries on the Top 25, a threat model was developed that identifies an attacker who has solid technical skills and is determined enough to invest some time into attacking an organization. More details are provided in Appendix B.

Weaknesses in the Top 25 were selected using two primary criteria:

• Weakness Prevalence: how often the weakness appears in software that was not developed with security integrated into the software development life cycle (SDLC).
• Consequences: the typical consequences of exploiting a weakness if it is present, such as unexpected code execution, data loss, or denial of service.

Prevalence was determined based on estimates from multiple contributors to the Top 25 list, since appropriate statistics are not readily available.

It’s assumed the attacker has some strong technical skills, is intent on data theft or theft of resources and is willing to spend an estimate 20 hours per software module. This is not realistic and in a blackhat situation you could bet they would be willing to spend much more than 20 hours.

Even if you aren’t directly involved in software development, it’s an interesting study and for people doing pen-tests/code audits and web application assessments it’s a goldmine of information to research further on.

If you get your techniques down on each of these 25 vulnerabilities you should be able to pretty much break anything open.

Source: CWE

A paper about cracking SHA-1 originally surfaced in 2005, from a fairly reputable scientific source in China, it was widely publicised nor talked about much.

But then recently, just last month China managed to make a wave out of it, almost 2 years after the initial ‘report’.

It was even Slashdotted on January 20th 2007, the article states the following:

These two main algorithms are currently the crucial technology that electronic signatures and many other password securities use throughout the international community. They are widely used in banking, securities, and e-commerce. SHA-1 has been recognized as the cornerstone for modern Internet security. According to the article, in the early stages of Wang’s research, there were other data encryption researchers who tried to crack it. However, none of them succeeded. This is why in 15 years Hash research had become the domain of hopeless research in many scientists’ minds.

Source: Epoch Times

Bruce Schneier wrote about this in 2005, February in fact, almost 2 full years ago.

SHA-1 Broken

Cryptanalysis of SHA-1

It’s not a major thing though and it’s far beyond anything most criminals could use to thwart national security…or even the security of things based on SHA-1 like OpenSSH.

There are however plenty of replacement algorithms if you are paranoid such as SHA-224, SHA-256, SHA-384, and SHA-512.

Check it out!

US President George W. Bush visited the NSA headquarters at Fort Meade in January 2006. A wall-sized status screen in the background displays the latest versions of Nmap and some of our other favorite open source tools. Pictures were printed in the February 6, 2006 edition of Newsweek (article) and the Jan 27 Washington Post (article). The page on the screen is the Talisker Radar. We don’t like the NSA tracking our phone calls and email, but they may track Nmap releases all they want.

Loading an external web site on their giant screen was risky.

Source: Insecure.org

The picture was printed in the Washington Post.

I imagine their normal NOC/SOC screen isn’t so interesting and they were like “Bush is coming, anything pretty to put on the projector?”