In part 1 of this feature, we discussed the process for obtaining and installing a server certificate for SSL enablement in IIS 6.0. This will provide confidentiality to HTTP sessions created between the server and its clients. To enable authentication of the users, however, you must enable mutual authentication. This will require the users of the system to have obtained digital signature credentials, or they will not be able to access the system!

• Start the Internet Services Manager by selecting Start -> Administrative Tools -> Internet Services Manager. (Note: in various versions of Windows, this shortcut may contain a slightly different path in the Start menu.)
• Right-click the web site node in the IIS manager, and open the Properties dialog.
• Select the Directory Security tab
• In the Secure Communications section, click the Edit… button
• In the Client Certificates section, select the radio button labeled Require client certificates

At this point, any client certificate that can be validated against a self-signed issuer certificate in the CAPI machine store can be used to access the web site. A copy of this certificate will be available to any server-side application, such as within ASP.NET code. If you want to restrict the allowed clients to those issued by a subset of the trust roots installed in CAPI, perform the following steps. Otherwise, Click OK to exit the configuration screen.

• Check the box labeled Enable Certificate Trust List
• Click the New… button under the Certificate Trust List drop-down list
• Complete the wizard by taking the following actions:
  • Click Next on the Welcome screen
  • Click Add from Store if the trusted issuer certificate is installed in the CAPI store. Otherwise, click Add from File
  • Select the trusted certificate, and click OK (or Open)
  • When all of the trusted issuers are present in the list, click Next
  • Enter a friendly name and description, and click Next
  • Review the summary, and click Finish
• Make sure the trust list you just created is selected in the Current CTL drop-down list, and click OK
• Click OK to exit the wizard

If set up correctly, the web site will now require you to present a digital signature certificate issued by a trusted authority when accessing the web site. During the SSL negotiation, the server will send a list of trusted issuers to the client browser. In many browsers, if only one usable credential is present, the negotiation may be completed automatically without prompting the user. If there are multiple available credentials, the user will be prompted to select one. Keep this in mind while testing – if the browser does not prompt you to select a certificate, it may indicate that you only have one certificate to use and the browser is selecting the certificate for you, not that the configuration is incorrect!

The register has an article about three London hospitals shutting down their computer systems due to a worm. However, except for transportation, all functions of the hospital seem to be continuing despite the lack of computer systems.

I took away three things from this article: computer systems are not essential for health care, someone wasn’t patching or following security policies, and the worm provides a back door for attackers. The doctors and the hospital are still providing medical care to patients. The computer systems certainly help them do this job more efficiently, but they’re not required. I think this points out the importance of security vs. convenience. The doctors just want to help their patients, and if they have to do that without computer systems, so be it. Most of the computerized equipment they really need should not be (and usually isn’t) connected to a network. If the computer systems become difficult to use because of security – the doctors will just not use them.

The second thing I noticed, but wasn’t mentioned directly in this story, was that the worm had to get on those systems in the first place. That was either over the network or brought in from a user. Either way, it tells me that patches weren’t applied and anti-virus was not running on access. Someone wasn’t following policy.

The final piece of information that was glossed over in the Register’s article is that the worm opens back doors on systems and contains spyware. Now, I’m sure the writers of the worm didn’t think that it would end up on a healthcare system, so they’re probably not looking for Personally Identifiable Information (PII), but that information is still there and likely accessed by the users of those systems. If a keylogger was installed, all of that is now “public” to the botnet’s users. I think the hospitals will have a larger job of cleaning up after this and determining what the worm did with that information than they do now in getting the systems back up and running.

Recovering from an “attack” is not as simple as restoring last known good configurations. You have to duplicate the drives, re-install the systems, then restore data (and hope you have good recent backups). If you want any chance of prosecuting the individual(s) responsible, duplicating the drives for forensic analysis is one of the most important steps. And until that’s done, these hospitals will be without computer systems.

For this week’s “Tutorial Tuesday” I would like to help those who may be asking a question I once found myself very curious about – “How can I learn Penetration Testing without having an entire lab setup at home?” – I can already hear some of you shouting “Virtual Machines!” – And you’re absolutely correct.

But instead of simply telling you how to setup a plethora of VMs, configuring them, then going into endless tutorials on how to secure and exploit those “fake” servers yourself, why not point you to a place where you can get pre-configured VMs and the tutorials and assignments for learning how to discover the vulnerabilities? The focus point I’m speaking of is De-Ice.net. More specifically their pre-configured PenTesting Disks (they are actually distributed as LiveCDs, but I like to simply run them in a VM instead of burning them to disc and running them). There are currently two levels to choose from and a grand following of users that are there to help answer your questions, and some well written tutorials to show you what to look for and provide some helpful tips for when you get stuck.

I thought this was a great resource especially if you’re someone who learns through doing instead of simply reading or listening to lectures. So don’t take my word for it, give them a try, and if you’re already an experienced PenTester, then let us know your thoughts or other resources for those wishing to learn some more.

De-Ice.net

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!

SQL injection attacks are in the news again this week. More web sites were found to be carrying hidden threats that originated from a “new, stealthier, and more closely guarded SQL injection toolkit.” You can take a look at the details of the attack here. Sites have been infected and re-infected as administrators have failed to address the root of the problem, poorly-written code.

Because of my belief that education is important to the elimination of bad habits, I thought it would be a good idea to point our readers to some resources that will help them understand SQL injection and how to avoid it. Read the rest of this entry »

This week’s tool, SimpleCAPI, is brought to you by Gemini Security Solutions. This is how it is described on the Gemini Security web site:

Our custom application, SimpleCapiUI provides the ability to quickly check the revocation status of certificates stored in CAPI, but it also provides drag-and-drop functionality so that a user can install certificates into CAPI by dragging a certificate, PKCS#12 key file, or PKCS #7 signature file onto the interface.

Additionally, an entire folder may be dropped into the application and SimpleCapiUI will scan the folder recursively to find certificates to install. By reducing the complexity of dealing with the Windows certificate store, SimpleCapiUI streamlines the process of testing PKI-enabled software.

This covers just about all of the features that the SimpleCAPI application implements, but the utility of these simple features saves quite a bit of time when testing PKI capabilities of applications.  The drag-and-drop feature that allows importing a folder of certificates into CAPI makes installing test PKIs a lot more efficient.

For example, on my development machine, I have a script that uses OpenSSL to create a two-tiered PKI with a root certificate, intermediate certification authority, end user, timestamp authority and OCSP certificates.  After running this script, I can drag the folder containing the script into the SimpleCAPI interface, and after entering the password common to all of the PKCS12 files, all of the certificates in the PKI are imported into CAPI with the appropriate trust settings.  This allows me to create and install an entire test PKI in a minute or two, without having to click through the certificate import wizard a dozen times.

If you have to perform a lot of PKI-based application testing, SimpleCAPI can make deployment of testing certificates a lot simpler.

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!

Oftentimes, web application developers are faced with the difficult challenge of writing code that directly interfaces with user-submitted data, yet doesn’t compromise the security of the application itself (either in processing the data or in displaying a response based on it). So to help, here are a few links that touch on the subject of identifying and securing possible security liabilities in web application code.

1) Google-caja project, Common Attack Vectors

This link gives an excellent breakdown of many methods by which a malicious user may try to break or exploit the page code. Information is given on both the JavaScript level and the DOM/environment/CSS level.

2) OWASP Application Security FAQ

The useful thing about the OWASP app. sec. FAQ is the way it’s written. The topics cover things that a web application developer might actually ask– “Should I really be concerned that my web server can be fingerprinted?” “What is Cross Site Tracing (XST)? How can it be prevented?”

In addition, the answers are informative without being too technical in nature. It’s almost as if the writers want to point you in the right direction and encourage independent research on the subjects… which is a very good thing.

3) Improving Web Application Security: Threats and Countermeasures

This MSDN Library document does an excellent job of outlining the *theory* behind web application security. From “best practices” to “threat modeling” this thing covers the multiple tiers and layers of web applications that are often targeted. Although a lot of focus is placed on .NET code, much of the stuff taught in this online document can generally be applied to other programming languages as well.

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!

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.

A while ago, I showed you how to get a free certificate from CACert.org. Now I’ll talk about getting that certificate out of Firefox, and importing it into OS X Keychain so that you can use it for secure e-mail. You might want to brush up on how Keychain works if you’ve never used it before.

The first step is removing the certificate from Firefox. Go to Firefox->Preferences and click the “advanced” logo at the top, then the “encryption” tab. Finally, click the “View Certificates” button. You should see a list of all the certificates you have. Unless you went through the trouble of getting your CACert certificate assured, it’ll just say “CACert WoT User”

Firefox Encryption Tab

List of Certificates

If you highlight the certificate and click the “Backup…” Button at the bottom, you’ll be asked for where to save the file. You’ll notice at the bottom that the Save As type is PKCS12. This is a common format for transferring both your public and private key between computer systems. You will be asked for a password to protect your private key – this is so that only you can open it when you’re ready. And you will now have a .p12 file wherever you saved it. Since I’m just importing into Keychain, I saved it to my desktop.

P12 export

All Done

Now, you’ve exported your certificate from Firefox, and it’s time to import it into OS X Keychain. This is as simple as double clicking on the file you just saved. The first window you’ll see is a confirmation that you want to import the certificates into your login keychain.

Import dialog

It will ask you for the password that protects the file.

Password dialog

Once you’ve typed in your password, the certificate is now part of OS X Keychain, and can be used by any application that uses Keychain.

Certificate in Keychain

Of course, this can be used to export certificates from Firefox into any application or framework that supports P12 files (most do).

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!

If you’ve ever wondered if your computer has a rootkit installed or if programs are doing things they shouldn’t, the RootKit Hook Analyzer might come in handy.

According to their website:

RootKit Hook Analyzer is a security tool which will check if there are any rootkits installed on your computer which hook the kernel system services. Kernel RootKit Hooks are installed modules which intercept the principal system services that all programs and the operating system rely on.

Rootkits often hook kernel services which enable them to do stealthy things like hide files and processes, passively log keystrokes, and examine network traffic. They typically do this by changing pointers in the system call lookup table so that foreign code is executed when a system call is requested. However, not all hooks are bad– most software firewalls and antivirus products utilize system call hooks as well in order to do sensitive low-level tasks.

The Hook Analyzer simply examines the system call lookup table to find system call module addresses pointing outside of the kernel memory area. This indicates that a service has been hooked. It also gives users some details about what foreign module/device driver is responsible for handling the system call. Used properly, this can help identify malicious rootkits.

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!