Quite a bit of buzz has formed around a remotely exploitable buffer overflow in the RPC Server service of all modern versions of Microsoft Windows (2000, 2003, XP, Vista, 2008 and pre-beta 7). This vulnerability is the root cause a widespread worm, known as Conficker or Downadup, exploits to spread across Windows machines. This code has been a target time and time again for attackers seeking out remotely exploitable vulnerabilities in Microsoft systems.

As usual, the discussion in the community has been centered on the IT security response, often emphasizing identifying the worm on the network and cleaning infected machines. The justification for this emphasis is that now that Microsoft has found and fixed the bug, the biggest challenge is preventing unpatched machines from remaining or becoming infected. Clearly, this reactive approach is inadequate to protect users, roughly 10 million of whom are already infected with Conficker.

To draw a public health analogy, if Microsoft was better able to vaccinate its software against vulnerabilities like these from the outset, the patch/response cycle would become obsolete. Obviously, we cannot preemptively avoid every vulnerability; bugs in software are a fact of life. However, a strong software security assurance program that integrates security into software at every step in its development lifecycle can dramatically reduce the risk of serious vulnerabilities making their way into production software. Judicious application of the right security processes and technologies are the vaccine that will make worm outbreaks, like polio, a thing of the past. We've made a lot of progress over the last few years, but it's time for the security community and press to shift the balance to spend more time talking about prevention than about treatment.

Technorati Tags: conficker downadup worm security patch

Heartland Payment Systems said Tuesday that hackers had compromised its computer systems and gained access to customer information related to the roughly 100 million transactions the company processes each month. Although the number of customer records that was compromised hasn't been disclosed yet, this breach is likely to give TJX, who exposed more than 45 million customer credit card numbers to hackers beginning in 2005, a run for its money as the largest breach of credit card data to-date.

The breach, the early signs of which Visa and Mastercard may have identified back in late 2008, was perpetrated using what investigators describe as highly sophiscated malware that specifically targeted Heartland. Since the means by which cyber criminals mounted this attack remain to be seen, it will be interesting to find out if the person or persons responsible were insiders, specifically out to get Heartland, or whether they were working as part of a larger effort.

Although there's no evidence yet this was an inside job, insider threats always pose a serious risk. Never has this risk been more acute than under the current economic conditions. When large groups of employees are fearful about layoffs and other hardships, employers often need to take stock of how they might be exposed if an employee with an axe to grind decided to leave something behind when they leave the company.

A few months ago, the Fortify Security Research Group (SRG) developed a custom rulepack specifically designed to help code auditors look for insider threats in Java web applications. The rulepack is available through Fortify Exchange, which is part of the Premium Content area of the Fortify Customer Portal. Currently, we're testing the rulepack with a group of interested customers to fine tune its detection capabilities and target a broader range of potential attack vectors.

Technorati Tags: insider threat breach credit card data

In FreeBSD and UNIX, characters such as < and > are allowed in file names. As these characters are the main ingredients for a straight forward cross-site scripting (XSS) attack, it is not surprising that filenames can be used to exploit XSS vulnerabilities. An internal audit recently uncovered a vulnerability in the online photo album application Gallery, which allowed to use a specially crafted filename to exploit a XSS vulnerability. For example, uploading a picture with the name <script>alert('hi')</script>somefile.gif could exploit this vulnerability.

But the danger goes even further. Files can be archived in multiple ways, including ZIP, RAR, and other formats and some languages, such as PHP, provide functionality to display the contents of these archives. Therefore, even if it is impossible to upload a file with a malicious name directly, it may still be possible to upload an archive containing files, which in turn may serve as attack vectors. For example, the following zip file will lead to an XSS vulnerability when processed by the code below:

file.zip: (1) <script>alert('hi')</script>somefile.txt (2) ... 

example.php: <?php $zip = new ZipArchive; $name = $_GET['name']; echo "The used zip file is " ; echo $name; $res = $zip->open($name); if ($res == TRUE) {      echo "Name index 0 is ";      echo $zip->getNameIndex(0);      $zip->close(); } else {     echo 'failed, code:' . $res; } ?> 

This exploit is not restricted to Unix-based operating systems either, it suffices to create a valid zip archive containing these filenames. Malicious archives like the one above can be created on a Unix system and later be used to exploit a vulnerability on a different platform. Furthermore, malicious archives can also be created on non-Unix platforms by editing the internal filenames stored in the archive before it is distributed to potential victims.

The moral of the story is don't trust input. Even if a particular source of input has external constraints placed on it, such as the characters supported by a given file system, they might be altered or negated entirely.

When we published a report on voting back in October, our conclusion included the line:

Just as important, we must not forget about election systems until October 2012.

So, what has happened since then?

Well, November wasn't a huge disaster, which is good. It'll be awhile before people start putting out reports that can really tell us how things went but we have a result that no one can really dispute (at least in the presidential election - I'm just going to ignore Minnesota for now).

But since November, we've seen some interesting stuff. Everyone's favorite whipping boy, the-company-formerly-known-as-Diebold (Premier Election Solutions), has been in the news. The state of Maryland is suing the company for the $8.5 million they spent fixing security problems with the $65 million of touch-screen machines they bought in 2001. Meanwhile, controversy is brewing in California over tabulation software Diebold knew would randomly delete ballots.

I'm going to be an optimist for a moment and explain how these articles actually point to some positive steps:

• Maryland admits there are problems and has worked toward fixing them based on independent expert advice. One disturbing thing we found when we looked into the electronic voting security was that election officials tend to trust the voting manufacturers over security experts. I'm fully aware that this change of heart in Maryland is the result of a lot of bad publicity and lawsuits directed toward the state, but it's progress.
• Maryland is making Diebold pay for it's mistakes. This is the only way we will see these companies produce better products - by making it expensive and impractical to do otherwise.

In California:

• They figured out the ballots were missing because Humboldt County has implemented a public auditing program. All of the ballots included in the tally are scanned and posted online to allow anyone to do their own count. During this process, they discovered they had more scanned ballots then the system reported. This sounds like a pretty good rebuttal to those who keep insisting there is no need for a physical verification mechanism. It also sounds like a great program, I'd love to see this done more widely.

Of course, these articles also point to underlying screw-ups, but I'm going to focus on the possibility that these steps will lead to more steps and we'll be in a different place in October 2012.

Technorati Tags: electronic voting diebold security

When we published a report on voting back in October, our conclusion included the line:

"Just as important, we must not forget about election systems until October 2012."

So, what has happened since November? Everyone’s favorite whipping boy, the-company-formerly-known-as-Diebold (Premier Election Solutions), has been in the news. The State of Maryland is suing the company for $8.5 million spent fixing security problems with touch-screen machines they purchased in 2001 leading up to the 2008 election. Meanwhile, controversy is brewing in California over tabulation software that not only is known to randomly delete ballots, does not log such actions. However, I’m going to be an optimist for a moment and explain how these articles actually point to some positive steps: - Maryland admits there are problems and has worked toward fixing them based on independent expert advice. One of the overwhelming problems we found when we looked into the electronic voting security is the disturbing tendency for election officials to trust the voting manufacturers over security experts. I’m fully aware that this change of heart in Maryland is the result of bad publicity and lawsuits directed toward the state, but it’s progress. - Maryland is applying economic pressure. This is the only way we will see these companies produce better products, making it expensive and impractical to do otherwise. In California: - This problem was found because Humboldt County in California has implemented a public auditing program. All of the ballots included in the tally are scanned and posted online to allow anyone to do their own count. During this process, it was discovered the official count different from the number of scanned ballots. This sounds like a pretty good rebuttal to those who keep insisting there is no need for a physical verification mechanism. It also sounds like a great program, I’d love to see this done more widely. Of course, these articles also point to underlying screw-ups, but I’m going to focus on the possibility that these steps will lead to more steps and we’ll be in a different place in October 2012.

Over the last few months I have worked with a group of software security experts to develop the CWE/SANS Top 25 Most Dangerous Programming Errors. Working on this project has got me thinking about a key point that we make in Secure Programming with Static Analysis: Most of the people who build software are focused on things other than security (writing code, running test cases, deploying applications, and so on). These people are making security-critical decisions on a daily basis, but they can't afford to become security experts--they've got other things to worry about.

Security is a complicated field and we can't expect everyone to become experts. Software developers and architects, quality assurance testers, and operations engineers all have a wide range of responsibilities. As an industry, our best chance to develop secure software is to get non-experts making meaningful contributions.

We must enable non-experts to get security right. This means arming them with the right processes (building security into the software development lifecycle from the ground up), skills (teaching people to ask "What could go wrong?", not arcane security specifics), and tools (deploying static analysis in development, runtime analysis in QA testing, and active defenses in deployment).

The winds of change are blowing in the right direction. Top universities across the country are beginning to offer courses that either address or focus entirely on software security. Fortify currently works with over 50 universities by helping them incorporate software security into their course offerings and by granting them unrestricted academic licenses for classroom and research purposes. This offer is open to any college or university who wishes to participate.

Despite a sunny outlook, most people building software today have received no formal training on software security. Projects like the OWASP Top 10 and the CWE/SANS Top 25 focus attention on the problems that are causing the most pain, serve as fodder for training programs, and generally increase awareness among non-experts. Let's hope that projects like these continue to carry the banner for software security into the 21st century.

Masochist McGraw has gone and signed himself up for a second podcast: Reality Check. I was an early victim of his original Silver Bullet series: listen here. Reality Check is all about practitioners, and the first interview is with Steve Lipner. Steve runs the SDL group at Microsoft. A strong way to get started.

CNet talking to Steve Balmer:

CNET News: Obviously, Microsoft didn't necessarily get everything it might have hoped for in terms of the critical response for Vista. What are you guys planning to do differently with Windows 7?

Ballmer: Well, I think we made some choices in Vista to improve security at the kind of expense, if you will, of compatibility. ...

I get nervous when I hear someone say "Our product flopped because we put in too much security" especially when there's no way to know what kind of train wreck it would have been if they hadn't gotten serious about security. We often hold up the Gates memo as the Platonic ideal for executive buy-in, but "when we face a choice between adding features and resolving security issues, we need to choose security" is what got us Vista. Let's hope people understand that, had they chosen features, there wouldn't have been an XPSP2 either, and that would have been an even bigger world of hurt as people fled to other operating systems, or simply decided that computers weren't a reliable way to do business.

Technorati Tags: Vista Microsoft Balmer Gates

Ok, so Twitter may not be suffering as much as this poor guy, but Twitter should be equally embarrassed. Within the last 30 days, Twitter has had several high profile security incidents: an unintentional direct message leaks, an ongoing phishing attack, and now a hack of at least 33 high-profile accounts. Unfortunately neither Twitter or the reported perpetrators are giving specifics about how the hack was pulled off (I'll gripe about that at some later date), so we can't discuss ways to mitigate and prevent such attacks. However, we can expound on what we do know and why this compromise was potentially catastrophic for Twitter.

So, what happened?

By reading Twitter's own post, we can conclude that some of Twitter's admin functionality were compromised. The admin tool allowed the support team to edit an account's email address. This seems innocuous enough, right? In this age of multiple work, school, and personal email addresses, it's not surprising for a user to forget the address used during registration. Twitter's support tool was created just to handle such a scenario. Unfortunately for the Twitter team, though, they forgot to not only ensure that the admin tool was only accessible by their support staff but that the admin tools were designed with security in mind. Sadly, many companies don't realize that the administrative portions of their applications are prime targets for malicious users. In Twitter's case, the admin tool allowed a malicious user to change the targeted account's email address to an attacker controlled email address. The attacker could then use Twitter's "Forgot Password" link to have a new password emailed to the attacker controlled email address. Using a system's password reset functionality to compromise an account sounds pretty familiar to the Sarah Palin "hack" (and I use the term "hack" lightly) not too long ago.

So, why is this such a big deal?

Fundamentally, Twitter is a communication transport and as such, users not only expect data integrity ("Did what I write actually get communicated?", "Did I receive what was actually written?") but also data authenticity ("Did I receive this message from the real author?"). [Apologies to all the cryptographers out there for the over simplification] While Twitter is limited in their ability to verify the account owner's real-life identity, Twitter *is* responsible for the authenticity of the accounts on their system. Their current solution is the traditional username/password that we're all familiar with. However, if Twitter's administrative tools were compromised (as their own posting alludes to), Twitter failed to provide that authenticity since malicious users were able to change account passwords. While the attack was occurring, Twitter was unable to guaranty the authenticity of the messages being sent out to the millions of followers of the celebrities that were targeted. During those few hours, Twitter essentially ceased to be.

That is why getting security right is so important.

Driven by the adoption of several tech luminaries and jettisoned by the mainstream adoption of a group of high profile celebrities that even your mother would recognize, Twitter has had a meteoric rise within the social-networking field. Being a start-up, can Twitter really afford to be constantly putting out security fires? How do these incidents impact their ability to attract more users? Better yet, what will these incidents do to their user retention? Twitter's "microblogging" service isn't too different from Facebook's status messages. Most of the targeted accounts also have Facebook accounts, a switch of platform would be very low effort for them. Could Twitter go the way of their competitors because security vulnerabilities cause users to lose faith?

Java String objects are immutable, so you can't guarantee sensitive data is removed from memory if you put that sensitive data in a String object. Once data is in a String, it's up to the VM to deallocate the object and then put it back into play as something else, and that might happen sooner, later, or not at all.

That's why paranoid Java programmers don't put secrets (passwords, crypto keys) into String objects. Instead, they treat them as arrays of bytes or characters so they can manually zero out the juicy stuff. At first blush, it appears that Tomcat supports this level of paranoia in the org.apache.catalina.Realm interface:

    public Principal authenticate(String username, byte[] credentials) 

But the RealmBase class, the base class that everyone actually uses, just yanks the rug right out from under your feet:
org/apache/catalina/realm/RealmBase.java:

  342       public Principal authenticate(String username, byte[] credentials) {   343      344           return (authenticate(username, credentials.toString()));   345      346       } 

Yup, that's right, it converts your credentials (read: password) from a byte array into a String. It would be unthinking for Tomcat to provide no way to authenticate without using a String, but providing an interface and then intentionally subverting it seems like calculated cruelty.