Some may remember a while back NBC (television network) was all primed about showing reruns with the notion “If you haven’t seen it, it’s new to you.” – That’s pretty much what I’m shooting for here. Let’s face it; things in the security industry are always changing. There is always something new to be learning. Software is being updated, new vulnerabilities are being found. Even the cores of what we work with, the operating systems, are changing on a more frequent pace. Over the course of several posts I’m going to be highlighting some of the new features released in the Vista / Server 2008 (and soon to be released Windows 7) upgrades. Again, you might be thinking Vista has been out for a while now, and so has Server 2008. But how many of you are taking full advantage of these upgrades. How many are still holding on to XP or still running Server 2000/2003 boxes? (my point exactly)... So enough upgrade guilt – lets get on with the show.

Today I’m going to outline how the new Remote Desktop Connection (RDC) works, or at least what’s changed. From a security perspective, the original RDC’s design was actually backwards from what is considered good security.

Think about how you connect to a pre-Server 2008 Terminal Server. You enter the name of the server and a connection is initiated to its logon screen. Then, once you hit that logon screen you begin the process to authenticate. From a security perspective, this isn’t a good idea. By doing it in this manner, you’re actually accessing a server prior to authenticating to it. This is the reverse of how nearly all other network services provide authentication security.

Network Level Authentication (NLA) with RDC 6.0, reverses the order in which a client attempts to connect. If you’ve used the new client, you’ve probably noticed how it asks for your username and password before it takes you to the logon screen. If you’re attempting to connect to a pre-Server 2008 server, a failure in that initial logon will fail back to the old login process. But where this new feature shines is when connecting to Windows Vista and W2008 servers with NLA configured. Here, that fallback authentication can be prevented from ever occurring. This prevents the bad guys from gaining console access to your server without a successful authentication.

You can set up Network Level Authentication in Vista and Server 2008 by right clicking on Computer and choosing Properties, then selecting Remote Settings. Under Remote Desktop, ensure Allow connections only from computers running Remote Desktop with Network Level Authentication (more secure).

I’m still exploring Server 2008 as I don’t have a direct everyday use for it in my job, so as new features come to mind I’ll continue to share them and their importance.

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!

Hot on the heels of a Flash Player critical vulnerability, Adobe has released a security bulletin outlining a critical vulnerability in all Adobe Reader and Acrobat versions prior to version 8.1.3.

Critical vulnerabilities have been identified in Adobe Reader and Acrobat 8.1.2 and earlier versions. These vulnerabilities would cause the application to crash and could potentially allow an attacker to take control of the affected system.

Acrobat and Reader version 9 is not vulnerable to these particular flaws.  A few interesting things to note here. No patch for Acrobat/Reader 7 and earlier has been released. Additionally, the update is available only by moving to a new version of Acrobat/Reader, either version 8.1.3 or 9. This may cause significant pain and stress among organizations that have standardized on Acrobat or Reader, especially in FDA validated systems.  This is because Adobe has not made it possible to just apply a security update patch to the affected software.  Instead, organizations must deploy a new version, which may contain additional changes including a changed user interface, changed behavior, and changed compatibility.  Therefore, I expect some organizations may choose to live with the risk rather than move into a new version, and have to re-document and re-validate processes according to an updated version of Acrobat or Reader.

This from BetaNews (link opens in new window):

Giving a nod to developers who’ve apparently given a lot of feedback, as well as “certain commercials,” Microsoft’s platform chief Steven Sinofsky acknowledged that perhaps User Account Control in Windows Vista may have been…a little annoying. In turn, Windows 7 has additional UAC settings.

Fortunately for my own sanity, I haven’t had to jump through any hoops with UAC to get my code working, but that’s mostly because I deal with server-side code now.  While the developer perspective is interesting, it’s really the user perspective that’s important to me, as someone who is concerned with the overall state of desktop security.  Developers are not only in the minority, we also don’t have the option of just turning UAC off on client machines…we have to deal with it or simply not write software for Vista.  In the current incarnation of Vista, however, UAC is so obtrusive that many users opt to disable it entirely to get the warnings to stop.

Sinofsky said that with UAC, Microsoft had what he described as “the best intentions” in mind. But its attention to informing the user about what’s going on and getting consent “possibly went too far.”
...
For now, in the Pre-Beta version of Windows 7, there are now four settings for configuring how intrusive UAC will be: Never notify me, Only notify me when programs try to make changes, Always notify, and Notify and wait for my approval.

I think this is the right approach.  UAC doesn’t really bother me too much as an end user, but then again, I know what it means and what it’s actually doing.  I think that Microsoft took a big step in the right direction security-wise with UAC, but those pop up windows can be a real turn-off.  I’m glad to see that rather than abandoning the model and starting over from scratch, they’re trying to make the “security vs. usability” tradeoff for users less of an all-or-nothing proposition.

Bulletin MS08-067 has been released along with its fix, and it’s a doozy.  By releasing it outside of a “patch Tuesday” it is apparent that Microsoft wants to see this fixed as soon as possible.  It affects every version of Windows from 2000 on through the latest beta of Windows 7.

This is a remote code execution vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system remotely. On Microsoft Windows 2000, Windows XP, and Windows Server 2003 systems, an attacker could exploit this vulnerability over RPC without authentication to run arbitrary code. It is possible that this vulnerability could be used in the crafting of a wormable exploit. If successfully exploited, an attacker could then install programs or view, change, or delete data; or create new accounts with full user rights.

Get yourself over to Windows Update and patch it up as soon as possible. Or download the standalone update from knowledgebase article 958644.

Adobe has released an advisory about a series of critical vulnerabilities in flash player 9.0.124.0 and earlier.  The fix is to install the just-released flash player 10.0.12.36.  The interesting thing is that the architecture of some security related things has changed wholeheartedly with player 10 – so things that used to work with 9, may stop working with 10.

Potential vulnerabilities have been identified in Adobe Flash Player 9.0.124.0 and earlier that could allow an attacker who successfully exploits these potential vulnerabilities to bypass Flash Player security controls. Adobe recommends users update to the most current version of Flash Player available for their platform. Due to the possibility that these security enhancements and changes may impact existing content, customers are advised to review this Adobe Developer Center article to determine if their content will be impacted, and to begin implementing necessary changes immediately to help ensure a seamless transition.

The bulletin is here, and the updated player is here.  Happy patching!

If you ever find yourself in front of a public computer connected to the Internet and are concerned about the security of the path between you and a website you wish to visit, a SOCKS proxy can come in handy.

SOCKS proxies generally allow you to “bounce” a TCP connection off another server transparently—basically instructing another computer to make a connection on your behalf. When used in combination with Secure Shell (SSH), it can form an encrypted tunnel that insulates you from anyone attempting to grab traffic off the wire.

The following is a simple step-by-step tutorial about how to do this.

You will need:
-Putty SSH client: http://www.putty.org
-An account on an Internet-accessible server that accepts SSH connections and allows connection forwarding (enabled by default)
-A popular web browser or other software that supports SOCKS communications

Step 1:
Fire up Putty and navigate to the Session Category

Step 2:
Enter the hostname/IP address and port of the server on which you have an account.
(Note: The default SSH port is 22)

This tells Putty how to connect to the SSH server.

Step 3:
Under the SSH->Tunnels Category
Enter the following:
Source port: 8888 (or any port of your choosing. Just be sure to remember what it is)
Destination: hostname/IP address of the server on which you have an account

Also, select the “Dynamic” radio button.

This tells Putty that, upon a successful connection, a SOCKS tunnel should be opened from a port on the computer you are using to the SSH server.

Step 4:
Click “Add”
The forwarded port is now added to the connection settings.

Step 5:
Click “Open” to start the connection

Putty will ask for your login credentials. In most cases, this will be a username and password. (For extra security and bonus cool points, have your SSH server only accept certificates)

At this point, your Putty-enabled SOCKS proxy should be active. But how do we test it out? Keep reading…

Step 6:
Fire up your web browser and navigate to its proxy connection properties menu.

For Firefox 3, it is in Tools->Options->Advanced->Network(tab)->Connection, Settings

For IE6, it is Tools->Internet Options->Connections(tab)->LAN Settings(button)->Advanced(button)

Step 7:
Find the SOCKS settings text box and enter the following:
Proxy Address/Host: localhost OR 127.0.0.1
Port: 8888 (or whatever port you decided to use in Step 3)
Ensure SOCKS Version 4 is selected

Note: DO NOT enter any other proxy settings for other protocols (this includes the “use proxy server for all protocols” option. Don’t enable it. I’m serious. If you do, things might not work correctly.)

Step 8:
Click “OK” until you’re back to your browser.

Go to http://ipchicken.com and check your IP address. It should be different from the machine you’re on. In fact, it SHOULD be the IP address of the SSH server (or whatever machine is handling its connections).

Step 9:
Pat yourself on the back. Or have your buddies do it for you—they’ll no doubt be impressed by your newfound computer skills. Enjoy browsing the web using your own personal SSH proxy.

NOTE: Although this could be useful when using a public computer—it won’t protect you from local machine monitoring tools (keyloggers, screen captures, etc). Always exercise due diligence when using untrusted computers.

Each Tuesday, Security Musings features a topic to help educate our readers about security.  For more information about Gemini Security Solutions’ security education capabilities, contact us!

Your company creates a custom web application and deploys it live. I bet it went through some serious security testing, and even the development process had security in mind from the design stage right (it should have). So if all this effort is put into a custom web application, why isn’t the same being done for your company’s blog?

Blogs are nothing more than web applications. And unless you created your own blog engine from scratch, you are using some third party solution (Wordpress or TypePad). This means you’re trusting the software is free of any vulnerabilities and has been developed with secure coding techniques as well. It’s one thing to insist your developers use secure coding techniques but it’s a way different scenario when you’re dealing with third-party, Internet facing applications like blogs.

If you’re going to be using third party web applications that you cannot guarantee are secure (and you can’t) then you ought to be taking advantage of a web application firewall (WAF). A web application firewall can protect third-party applications just as easily as it can for custom developed applications, and in many cases it is actually a lot easier.

In a lot of companies blogs are the web face for the company (at least one could hope). It’s important to realize that thereare risks here, especially if it’s pulling the the most hits and getting the most attention. So stay protected – use a WAF!

Authoring web sites was a lot easier in the 90’s…write some static HTML, maybe some JavaScript, and you were done.  Need to update the site?  Just edit the HTML pages and upload.

In the past decade or so, web applications have made a lot of progress with interactivity and dynamic content.  Services hosted outside of the application container, such as third party web services and databases,  can provide a boatload of flexibility when designing and implementing a web site.  But, these services rarely, if ever, allow anonymous interaction…so we need to go back to our old friend, the password.

Passwords are usually stored in a configuration file along with a web application.  The configuration files are generally not made accessible with an application URL, but often connection information is stored unencrypted, which means vulnerability to security bugs that can trick the web app into displaying the configuration files.  Local access would also compromise the password, but local access almost always means that nothing is safe.

I’m in the process of authoring a new .NET app, and I’m feeling okay about the capability to encrypt sections of the web.config file (including service passwords).  This seems to be able to hide data from prying eyes using keys managed by the local security authority.  However, I haven’t yet figured out how to manage this in a deployment scenario.  Encrypting the section inherently makes it difficult to update the configuration – this now has to be done through code, because the security provider has to be invoked to decrypt and re-encrypt the configuration sections.  If the same authentication provider is used to authenticate administrators to perform these updates, then what if there is a problem with that authentication provider, and the administrators get locked out from fixing the configuration?

From a security standpoint, I have to make this work (and be usable)...I just haven’t yet figured out how.  If anyone in my legion of loyal readers has any tips, I’d be glad to hear them.

Many people will claim that the “openness” of open source software helps make it secure. With an entire community given access to all of the code, it makes sense that programming errors or security issues would be recognized often. And thanks to tools like Findbugs, many issues are found and fixed before, during, and after a product is released. Products that rely on security through obscurity or snake oil solutions generally fail to hold up in an open source environment… but I think this can be a double edged sword.

With the common perception of open source software as being “more secure” than their closed source counterparts, there also exists the possibility for people (and companies) to place too much faith in them.

According to this study (pdf) done by Fortify (which examined a number of OSS applications for potential security vulnerabilities):

...serious security threats stemming from numerous application vulnerabilities are a direct result of poor or nonexistent security processes. This follow-up survey found that security best practices are a low priority to the open source projects surveyed/community. Yet open source packages often claim enterprise-class capabilities but are not adopting — or even considering — industry best security practices.

Although some bias exists in the report (they only examined Java applications which they used to make some fairly broad generalizations), the data holds a lot of significance. As more and more companies embrace OSS as a component in their software solutions, they must be careful not to also embrace the perception of inherent security. Secure software depends on a lot more than the openness of its source code.

Many of you may have heard of the massive DNS patch release coordinated by Dan Kaminsky. What you may have also heard is that the details of the vulnerability and the patch would be released at Black Hat this year (two weeks from now).

This has been one of the few patch releases that had such widespread secrecy around it. Very few people knew about the patch until Windows (and OS X and Linux) asked them to update. Now that the patch is released, the code can be viewed, and compared to the old code and people can figure out what the problem is. It took a while, but several people have done just that.

There are some generally accepted “rules” to vulnerability disclosure that most security researchers follow, and agree not to disclose the vulnerability before a patch is released. However, the patch was released well before the vulnerability was disclosed (if not by the initial researcher). With the patch out there, smart people are going to be looking at it to see why things were patched. BIND, an open source DNS server was affected, and so the code is freely available. It was only a matter of time before someone (with more time than me) read the code to see what changed and what was wrong.

Reverse-engineering patches is more difficult, but not impossible, when you don’t have the source code, so it’s not reasonable to expect people to keep quiet.

In this particular case, there were a lot of politics going on about disclosure and giving a talk at Black Hat, but the fact remains the same, once the patch is released, the cat’s out of the bag, and it’ll be pretty hard to get back in.