Recently I changed my personal firewall software. I was using the default Windows7 Pro firewall, which is fine for basic stuff, but I found a deal on one of my favorite security suites, so I went ahead and sprung for it. One main befuddlement people have with additional firewall software is the amount of nagging it often does when it’s first installed. You open your email client – popup – “program X is trying to communicate on port Y would you like to allow this?” You click yes, and move on. You open your instant messaging client and again – popup – “program X is trying to communicate on port Y would you like to allow this?” This can be annoying but this is usually the training mode of the software, it’s trying to learn what software you use, and it’s relying on you to make educated decisions on whether that software is really what you’re trying to run.

Usually firewalls only do this when they are initially installed and are in their “learning” modes. I usually keep it in “learning mode” for about a week to ensure I cover the plethora of software that I’d typically use. Then I go into lock down mode – blocking all other outbound and inbound traffic. Most people will only resort to a middle ground where most of the known ports are allowed, and others are not.

But this “learning” time period can also be beneficial. It will ask you whenever any program tries to communicate in/outbound – so if you start getting warnings when you’re not actively trying to run a program, then pay close attention to what program is trying to communicate. If it’s not a Microsoft service (windows) or some other service from a trusted source, then most likely it’s malware that’s been residing on your system for some time and you probably didn’t even know.

Most of this is beneficial to you home users, but it can also help those in the IT departments as well. It’s a good learning tool to help those just starting out to realize that there’s a lot more going on than you might expect. There are a lot of underlying communications that can occur especially in the corporate environment. So use these “learning” sessions to help educate yourself, for home and work life; and those in IT should be making notes of what is trying to communicate, and compare those with the known services that your company is running. Once you’ve determined all the proper services and software – opt to block all other in/outbound communications. You should document this in a policy and keep records of this. The last thing you want happening is not knowing what could potentially be coming or going from your networks.

Back in January, Google announced they would pay between $500 and $1,337 for bugs in their Chromium web browser code, if the discoverer first reported it privately to them and followed certain conditions. Since then, the company has handed out quite a few bounties to security researchers who found problems.

Now, Google has expanded the program by offering similar bounties for vulnerabilities in their web-based applications. Hackers who find issues such as HTML injection or cross-site request forgery in important Google services can now report them and possibly qualify for rewards ranging from $500 to $3,133.70. As with the Chromium bounties, bug hunters have to follow a few rules and conditions, such as giving Google some time to fix the issue before public disclosure.

Given the success of the Chromium bounties, it’s likely this new experiment will be beneficial both for security researchers and Google’s users. It certainly adds an interesting new twist to the debate over how to handle outside bug discoveries – perhaps we’ll see more companies offering such compensation in the future.

AntiXSS is an open source .NET assembly available for download from Microsoft (source here).  This library provides much more flexible XSS protection in .NET applications than the built-in Server.HTMLEncode() approach, as it adds support for XML and LDAP filter encoding in addition to HTML encoding.  By allowing flexible and secure encoding and decoding of strings for these types of data, application developers can breathe a little easier when accepting data across trust boundaries.

Libraries such as AntiXSS that perform string processing are incredibly useful for developers, for several reasons.  First, they are maintained separately from your code base, so any updates to the string processing functions for emerging threats can be applied without much hassle.  Second, by using a code library with a wide user base and is regularly maintained with updates from the developers, the risk of a security hole from a bad implementation is much lower.  Finally, it’s free – and your time developing custom string processing code is not!

Once upon a time, the Web was filled with static pages of text, hyperlinks, and the occasional image. Security problems existed even back then, but the pages themselves were generally innocuous. As the years went by, however, the Web became a platform for all sorts of communications and services. In time, the mild-mannered web page became a delivery mechanism for large-scale, dynamic applications. Even mobile browsers now include engines for loading powerful object-oriented programs. As the capabilities of websites expanded, the problem of HTML injection, or cross-site scripting (XSS), became a significant threat. Check any recent research on web-based threats, and you’ll find that this type of vulnerability is widespread online. And if the past few weeks are any indication, we can expect more trouble in the future.

HTML injection itself is hardly a recent issue, but current trends make it more common and more dangerous. In particular, the rise of user-generated content and “mashups” has led to far more data being shared across security contexts in real-time. One example made headlines last week after a few Twitter users discovered they could manipulate the site’s system for parsing links within a post to add custom HTML. Several tweets crafted to exploit this issue spread virally, as an action as simple as moving your mouse could trigger code that would post the same tweet under the victim’s account. Twitter’s entire product relies on user-generated content, but a simple filtering problem led to the rapid spread of XSS worms. Fortunately, none of these cases appeared to be that malicious.

In the realm of mashups, many sites are adding code to integrate with Facebook, providing users a single sign-on experience. A few websites have access to “instant personalization,” a feature that lets the sites identify Facebook users when they first visit rather than after clicking a login button. Soon after Facebook announced this program, a security researcher discovered that one of the partners, restaurant review hub Yelp, had an HTML injection vulnerability. With the addition of Facebook’s code, Yelp’s hole could be exploited to let an attacker automatically identify Facebook users as well. More recently, two new partners were added to the program: Rotten Tomatoes and Scribd. Soon after the announcements, similar problems were found in each of these sites. Ironically, Rotten Tomatoes’ pages were generally secure against HTML injection, but a third-party widget loaded by the site introduced a vulnerability.

HTML injection on one site threatens information and actions available to users of that site. But with so many websites sharing data between users and other companies now, one vulnerability may allow access to multiple services. And the problems don’t stop with the browser – injected code can try exploiting other issues that lead to compromising a user’s operating system. Meanwhile, the spread of mashups shows no signs of slowing. In fact, this past week Facebook’s COO Sheryl Sandberg predicted that within a few years, nearly all websites will automatically adapt to a visitor’s interests. Yet that sort of functionality requires identifying a visitor’s interests somehow, and Facebook’s instant personalization is one example of how that’s possible.

Securing a Web with so much data getting passed around is not an easy task. Douglas Crockford, a leader in the JavaScript community, has recently advocated that browser makers stop work on HTML5 and instead focus on building a more secure framework for handling scripts. Yet it’s more likely we’ll see a universally personalized Web before we see such functionality become mainstream, meaning web developers need to keep paying close attention to possible HTML injection issues. Preventing such vulnerabilities in an application would require more than a simple blog post, but fortunately many resources exist online, and the team at Gemini is ready to help you secure your code. In the meantime, I hope that the buzz about Twitter’s worms and problems with instantly personalized sites help draw more attention to HTML injection as the Web continues to expand. Hopefully future developers will learn from these stories and reduce their frequency in the future.

A new problem has been uncovered that allows an attacker to obtain encrypted session cookies or other encrypted/protected data stored on any version of ASP.NET from Windows XP to Windows 7 and 2008 R2.  When properly exploited, the attacker gets full administrative rights to the application and gets access to files such as the web.config file which often stores sensitive information and passwords.  From ComputerWorld:

Hackers can exploit the vulnerability by force-feeding cipher text to an ASP.Net application and noting the error messages it returns. By repeating the process numerous times and analyzing the errors, criminals can learn enough to correctly guess the encryption key and thus decrypt the entire cipher text.

It will take some time for Microsoft to patch this problem across all platforms.  It is possible to update your application to be immune to this attack, and I recommend patching your application as soon as possible.  From Scott Guthrie of Microsoft:

A workaround you can use to prevent this vulnerability is to enable the <customErrors> feature of ASP.NET, and explicitly configure your applications to always return the same error page – regardless of the error encountered on the server…

Important: It is not enough to simply turn on CustomErrors or have it set to RemoteOnly. You also need to make sure that all errors are configured to return the same error page.  This requires you to explicitly set the “defaultRedirect” attribute on the <customErrors> section and ensure that no per-status codes are set.

This link has detailed instructions on how to protect against this attack in each platform. Happy patching.

OAuth is a protocol that lets applications request data or privileges you have on a remote service without you having to provide your credentials for that service. A classic use case for this “valet key” system is contact import – you can let a site load your address book from Gmail without giving that site your actual Gmail password. Twitter recently required that any third-party applications using their API must authenticate using OAuth.

Twitter’s implementation is based on OAuth 1.0, which was finalized in April but has been in development for several years and is already widely supported. But work on a new version is now under way, and Facebook has already implemented one variety of the draft specification for applications that connect to their service. OAuth 2.0 currently defines specific flows, or client profiles, for handling authentication: Web Server, User-Agent, Native Application, and Autonomous. The first two are most commonly used for web applications, and implementations of the third may end up being quite similar.

The process for most clients involves three broad parts. (Note that “client” in this context refers to the application seeking access, not the person using the application.) The first involves user authentication. For a web-based service, this will often mean ensuring the identified user is currently logged in and then asking for their permission to enable access if they have not previously granted it. Second, the client has to authenticate. In other words, the client making the request has to prove it is the same application that the user granted permissions to in the first step. If both of these steps complete without error, the client is given means to access the protected resources, typically with a temporary code known as an access token.

The specific details of how these steps happen depend on the client profile used. Facebook’s standard Graph API authentication is an example of the Web Server flow. When first requiring access to private user data, a third-party application will forward the user’s browser to Facebook’s authorization server. The request includes a public code identifying the application and a URI under the application’s control. Facebook prompts the user for the permissions and (if they are granted) redirects the browser to the provided URI, along with an authorization code. The client then makes a request directly to Facebook which includes this authorization code and a secret code identifying the client. Facebook then sends back an access token, which is used to authenticate specific access requests for the duration of the session.

The User-Agent profile differs in that it relies on a user-agent’s same-origin policy rather than a client secret for authenticating the client. This process provides OAuth capabilities for JavaScript-based applications that do not have a server-side component and thus cannot ensure identifying codes are kept secret.

Simplicity was a major factor in creating OAuth 2.0, and thus several parts of OAuth 1.0, such as signatures and nonces, no longer apply. However, OAuth 2.0 requires transport-layer security of TLS 1.2 at minimum (as of draft 7) for the interface used to request and receive access tokens. The spec also recommends that secure channels be used for other parts of the process. In Facebook’s implementation, all server interfaces are accessed via HTTPS addresses.

From a security perspective, OAuth is a good step in that it discourages the anti-pattern of one application requesting a user password for another application. It can also protect users in other ways; for instance, if someone intercepted the authorization code for a Facebook application, they would not be able to use it for data access without also obtaining the application’s client secret. However, OAuth only addresses particular issues with third-party access and should not be considered a silver bullet for security. As an example, access by Facebook applications vulnerable to cross-site scripting may still be hijacked once the application has been authorized.

While OAuth 2.0 is still in draft status, Facebook’s deployment makes it in wide use already, and we’ll likely see many more implementations in the months to come. The description above should help you understand the basics of how OAuth 2.0 works, but if you’re interested in further details, check out the full spec and Facebook’s specific authentication guide.

So you’ve been hearing lately about how some Android applications are going rogue and being used to steal users’ data and infiltrate their phones, to sit idly by only to wreak havoc when the user least expects it (ok, so maybe I exaggerated a little there). But there has been a lot of buzz lately about certain apps not playing by the rules, or including certain calls to leach user information. A lot of this buzz has been spun as backlash against Google for allowing these types of applications to exist (instead of having some asininely draconian filtering process like some ‘other’ phone provider).

Well, to help defend Google (which they’ve done a decent job of doing themselves), this one falls back on the users. If you’re an Android user, you’ve most definitely seen a screen similar to this.

This screen tells you exactly (mostly) [kinda] what the application you’re installing has access to, and how far it can reach. It’s your (the user’s) obligation to agree with this and install, or not agree, and cancel out. See those two buttons at the bottom? If you don’t agree and see something that has “Cost Money” in this section and you presumed it was a completely free (as in beer) app, then you’d better click the right (Cancel) button.

(more…)

A colleague lent me his most recent copy of IEEE’s Computer magazine.  Inside was an article entitled A Web 2.0 Model for Patient-Centered Health Informatics Applications (IEEE membership required to read).  Some possible benefits of their proposed approach were listed, including:

• Run deeper analytics across physicians groups and facilities, which can include relevant patient data…
• Provide a wide community of health professionals with feedback on the use and effectiveness of protocols…
• Share similar and alternative protocols and their analyses across many medical facilities and individual providers…

Anyone want to guess what’s completely missing from their approach?  You guessed it, any mention of security.  The commonly misunderstood (and frequently misspelled) HIPAA makes it pretty clear that the privacy and confidentiality of personal health information must be protected.  Even without HIPAA, it would just make good sense to be extra careful when sharing information and running data mining and analytics across large sets of health information.

The only mention of keeping information safe in the article is the fact that there is a division of data between the protocol, protocol modifications, and actual patient data – but it is very difficult to draw such bright, clear lines considering medical records and information.  How can you be sure the protocol modification a doctor submits won’t include information on the patient he tried it on?  Without even mentioning or considering the need for the protection of privacy, confidentiality, and data integrity within such a system, the authors of this article have done themselves and the software community a disservice.  Security requirements and threats must be considered at every phase of the life cycle, especially during the architecture phase.  As Kenneth Van Wyck and Mark Graff put it in their book Secure Coding: Principles and Practices,

As a general rule, the hardest vulnerabilities to fix are those resulting from architectural or design decisions. You may be surprised at how many of the vulnerabilities you have heard of we ascribe to errors at “pure think” time.

By developing an 8 page article published in a respected technical journal without any mention of the need for security controls in such a system, the authors of this article have once again helped me with my job security.  It is still difficult for me to foresee the day where security and risk management training programs won’t be necessary, and we won’t need an information security industry.

A few months ago, I described how the Firefox add-on HttpFox could be used for basic traffic monitoring. Another helpful add-on that complements nicely with HttpFox is called HackBar.

HackBar adds a toolbar underneath the main address bar that can be toggled on or off with the F9 key. When enabled, the toolbar provides a miniature console of sorts for various testing tasks. A resizable textbox gives you plenty of room for editing URIs, and you can also issue POST requests or spoof the referrer. Menus across the top of the bar provide common functions for working with different types of data, such as hash algorithms or encoding and decoding in Base64, URI format, and even hexadecimal.

Using HackBar has its limits, and for comprehensive penetration testing you’ll probably need better tools. But if you just want to poke around a web application or send a quick POST request, HackBar is pretty handy to have around. Combined with HttpFox, you may be surprised at how much testing you can accomplish right in your browser.

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!

PDF files have become commonplace on the Internet and in the business world, but they have also become favorite tools for attackers to deliver malicious payloads. While some problems may be mitigated by using an alternative PDF reader, many people have little choice but to use the standard Adobe Reader. In that situation, you can help protect yourself from many PDF-based attacks by following a few basic steps.

1. Make sure you have an up-to-date anti-malware program installed and running with automatic download of new virus definitions. Older tools may not scan for recent PDF-based threats.
2. Make sure you have the latest version of Adobe Reader. Enable automatic updates by opening Reader and choosing Edit > Preferences > Updater. Adobe regularly issues patches against new vulnerabilities.
3. Disable JavaScript in PDF files. This may affect certain features at times, such as PDF-based forms, but it’s better to enable JavaScript only when needed. In Reader, click Edit > Preferences > JavaScript and uncheck the box for “Enable Acrobat JavaScript.”
4. Disable Flash and multimedia in PDF files. Once again, this may prevent a few documents from loading some content, but embedded Flash is a common tool for exploiting Reader. Go to Edit > Preferences > Multimedia Trust (legacy) and either uncheck “Allow multimedia operations” or change the permissions on each listed player to “Prompt.” Be sure to check the settings for both trusted documents and other documents by changing the “Display Permissions for” option.
5. Disable attachments. Earlier this year, security researcher Didier Stevens uncovered a PDF behavior that could be used to launch commands outside of Reader. To avoid this problem, open Edit > Preferences > Trust Manager and uncheck the box marked “Allow opening of non-PDF file attachments with external applications.”
6. Configure your browser to show a download prompt for PDF files. The exact settings for this step will depend on your browser. Remove any plug-ins or add-ons for Adobe Reader, and check the settings for how your browser handles various file formats to check the behavior for PDF files. If you allow PDF files to open in the browser or open in Reader automatically, you may accidentally open a malicious file without realizing it.

These precautions are only a small part of keeping your computer protected against attack, but they will go a long way to help you avoid many threats involving PDF files.