Use glue instead

Amazingly, many companies offer software that is designed to prevent users from connecting USB and other external storage devices. Apparently, there’s demand for products creatively named DeviceWall, DeviceLock and Sanctuary Device Control. The problem they are trying to solve is described by Pointsec, a vendor of another such product:

Data leaks can be devastating
Moving digital files from a PC to a storage device is very easy, using a USB or Firewire connection, or wirelessly, using Bluetooth, Infrared or Wi-Fi connectivity. Users innocently plug personal storage devices into their work PC to upload music, or transmit digital photos, but the ability to also siphon off corporate data from a PC onto peripherals places organizations at considerable risk of undetected data leaks.

 
Now let’s analyse this. Users already have access to the information – it is stored on their computers. Often the computers are laptops that the users can take anywhere and connect to any network. The users can post forms to Web sites, send emails and (horrors!) encrypt information using likes of Winzip without telling password to anybody. If they want to siphon off the information, they can. And blocking USB ports won’t help. Use glue to fill the ports instead – it’s cheaper, and achieves similar outcomes.

 

The attack surface

Jabez Gan, a fellow MVP, did an interesting book review – that of Professional Windows Desktop and Server Hardening by Roger A. Grimes, published by Wrox. Jabez summarises his learnings from the book in 10 points:


1. To Linux fans out there: Whatever is Popular Gets Hacked. How true is this statement? You might be saying that Windows is full of exploits because it is unstable and vunerable. If it’s the days of Windows 9x/NT, I would agree with you that Windows isn’t that secure. However things have changed, thus vunerabilities have decreased tremendously.

If you think about Apache, you’ll notice that it has more vunerabilities than IIS. (Since Apache is more widely used).

2. Don’t Let End Users Make Security Decisions. Heck I don’t even trust end users myself, so why should we let them make security decisions? They will only increase our workload when they submit support tickets!

3. Security-by-Obscurity Works! Change to some random port for our RDP (remote desktop protocol) instead of the usual 3389. Change to some random port for our HTTP instead of the default port 80 (do this only for internal users, not external users).

4. Assume Firewalls and Antivirus Software Will Fail. I’ve been doing some consulting for a few companies, and this statement is true. Updated antivirus software with properly configured firewall isn’t enough. Malware nowadays comes through port 80 and Antivirus doesn’t work as great when it comes to detecting new viruses.

5. Minimize Potential Attack Vectors, Decrease Attack Space. Everybody knows this. Disable services or programs that you do not need. Close the ports you do not need. Use IPSec for communications between machines.

6. RunAs. Remember the long forgotten RunAs? Administrators should provide users (and themselves) with limited user accounts (LUA) and use the RunAs if they want to install applications. Also, I’ve learnt not to provide users with the permission to install new applications. It must be done by an administrator.

7. Keep Patches Updated. To cut things short, Keep Patches Updated. All of you know why.

8. Use a Host-Based Firewall. Who said Windows XP SP2’s firewall isn’t good? It is a host based firewall… Nah, it doesn’t provide Outgoing firewall monitoring. So use a 3rd party instead. ;)

9. Rename Admin and Highly Privileged Accounts. Scripts or hackers will try to hack through the system through the default administrator account. So on every installation of Windows (or any OS or applications), rename the default high privileged accounts.

10. Install High-Risk Software (IIS) to Non-Default Folders.  I know lots of you out there will just install everything to the default folder, but here’s a tip: Don’t! Take the hassle to reconfigure things if you have IIS installed to the default folder. I know it will break some web app (if you have any) but do you want to fix your web app or secure your server?


Interesting. Let’s analyse. The first thing that comes to mind is that renaming admin and highly-privileged accounts and installing software to non-default folders are variations of the security-through-obscurity approach – in addition to using non-default ports for IP services. Incidentally, that contradicts on of sys.admin’s principles that I follow – Use Defaults Whenever Possible. Using the defaults allows quicker problem resolution, which is good for security. Another note is about renaming high-privileged accounts – there are none by default, why then?


Minimize Potential Attack Vectors, Decrease Attack Space sounds like stating the obvious – besides, there’s at least one thing that is not so obvious here: security through obscurity leaves the attack surface intact, not cutting it even a tiniest bit. Proper systems management and access control are to shrink it.


Should we disallow end user installing software and making any security decisions? The proper question here is – are you ready to make all the decisions on the users’ behalf? A personal firewall is a good example. Controlling outbound communication sounds like a good security (so may denying all of it by default) – but are you ready to make the decisions for the users whereever they are? In any environment of scale, you won’t be able to cope – thus the users must have a level of freedom here. They are already trusted with business information that you’re trying to protect. A better rule is to disallow users making decisions that will impact other users.


And the final note is about the Whatever is Popular Gets Hacked. Reality gives it an interesting twist: whatever is not popular also get hacked – but most hardly notice and often don’t know. Obscure systems with zero known vulnerabilities should never be considered safe.

Integrating Java, JDBC and Kerberos

This notes are to help integrating Java applications into Kerberos environments (most likely Active Directory-based). It’s not a cookbook but gives few pointers that I find useful.


Background


I have integrated Windows Kerberos environment with alien platforms before. See, for example, my notes on Configuring Apache on Linux for Kerberos Authentication. So when I faced the need to configure Java environment to use Kerberos for Microsoft SQL Server authentication, I was excited. As it turns out, Java is as bad as Linux – if not worse [;)]


Problem


There’s a Windows-based Java environment and a Microsoft SQL Server database. The task is to configure Java to connect to SQL Server database using Kerberos authentication in the current user security context – that is, without specifying the account name or keytab file. Not changing Kerberos encryption types for the account in Active Directory highly desired.


Solution


For this particular solution I was using DataDirect JDBC driver for Microsoft SQL Server. Other options are OEM versions of the same (that are cut-down, with the cut including some authentication features), and Microsoft SQL Server JDBC driver (that does support integrated authentication but only on Microsoft Windows operating systems – I naturally want to go multiplatform). DataDirect provides two testing tools – WATest for basic Kerberos functionality testing and ConnTestWA for JDBC specifically , as well as testforjdbc utility included with the driver distribution set.


The steps of the solution include: installation of Java Virtual Machine, configuration of Kerberos, and configuration of login parameters for particular connection. On Windows you can choose not to use keytab files; on UNIX/Linux you have to.


The success criteria was successful run of testforjdbc, with Kerberos ticket for SQL Server service added to the local ticket cache. You can check the cache using Kerbtray GUI or klist.exe command line utility, from Windows Resource Kit utilities and support tools respectively. On UNIX and Linux, you have to run klist. If the connection works and uses Kerberos, a service ticket is added to the cache.


Caveat


Don’t take for granted that Kerberos authentication is available on the server, even if it comes from Microsoft and is using Windows integrated authentication. In case of SQL Server, you need to refer to Q319723 – How to use Kerberos authentication in SQL Server. Note that you need to use service account, and there are some specifics when you use cluster; also note that delegation settings are only required if there is an intermediary point in the communication (like IIS in the KB article scenario). IIS configuration for Kerberos has similar caveat(s).


Installing the JVM


Remember Wirite Once, Run Anywhere capability (see INDEPENDENT TESTS DEMONSTRATE WRITE ONCE RUN ANYWHERE CAPBILITIES OF JAVA)? Well, that doesn’t quite work any more. For that reason you have different constraints with each version of JVM. Pure Java (that is, without using native platform calls and only JVM in-built features) Kerberos failed for me using Sun’s JVM 1.4. With JVM 1.5, Windows default encryption types for Kerberos (namely, RC4-HMAC) are not yet supported, so you have to use DES encryption types for Kerberos (using AD Users and Computers GUI in the service acccount properties – and see  833708 for issue with Windows 2003 domain controllers). Only Java 1.6 comes with RC4-HMAC support. Use the latest version if you can.


Configuring Kerberos in Java


Just like in UNIX/Linux, java is using krb5.conf file and exactly same format. On Windows, the file is renamed to c:\winnt\krb5.ini (if c:\winnt\ directory doesn’t exist, you have to create it). Details about the location of the configuration file and search order please find here. here’s my configuration file:


[libdefaults]
 default_realm = EXAMPLE.COM
 default_tkt_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
 default_tgs_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
 permitted_enctypes = rc4-hmac arcfour-hmac-md5


[realms] 
 EXAMPLE.COM = {
  kdc = DC.EXAMPLE.COM
 }


Important: RC4-HMAC is not enabled by default, so it needs to be on the list.


Configuring login parameters


Kerberos requires configuration file for every connection using Kerberos login. The one for DataDirect JDBC driver is by default named JDBCDriveLogin.conf (akternative configuration file can be specified by changing java.security.auth.login.config Java environment variable), and should look like this:

JDBC_DRIVER_01 {
 com.sun.security.auth.module.Krb5LoginModule required debug=true useTicketCache=true doNotPrompt=true;
};

Explanations: debug=true is self-explanatory, and it’s essential during the configuration. The “useTicketCache=true doNotPrompt=true” pair chieves using Windows ticket cache (as opposed to useKeyTab, which is another option); it’s addressing a potential “No CallbackHandler available to garner authentication information from the user” error.


The rest


…is well documented in DataDirect KB article Setup of pure Java approach for Windows Authentication with DataDirect Connect for JDBC.


Point solutions


You can as well avoid the hassles of pure Java just by using Type 2 (Windows native) integration for DataDirect driver. All that ise required is connection string like jdbc:datadirect:sqlserver://yoursqlserver.example.com:1433;AuthenticationMethod=Type2 or jdbc:datadirect:sqlserver://yoursqlserver.example.com:1433;AuthenticationMethod=auto (as opposed to jdbc:datadirect:sqlserver://yoursqlserver.example.com:1433;AuthenticationMethod=Type4 or jdbc:datadirect:sqlserver://yoursqlserver.example.com:1433;AuthenticationMethod=Kerberos required for pure Java Kerberos authentication). Make sure that java.library.path includes path to DDJDBCAuth04.dll supplied with the driver. Or you can use Microsoft JDBC driver. Both will integrate with Windows.


Troubleshooting


1. Verify SPN in question. In AD, use ADSIedit to check the SPN. The LDAP attribure you are looking for is “servicePrincipalName”;
2. Enable Kerberos logging on the DCs (http://support.microsoft.com/kb/262177/) and look for relevant information in the logs;
3. Capture traffic on the client requesting Kerberos ticket and see Kerberos communications and error codes in the capture;
4. Review Q326985 (http://support.microsoft.com/kb/326985) -it’s about troubleshooting Kerberos with IIS but gives good idea about other services.
5. Did I mention enabling Java debugging where possible?
6. And if you use Java security policy, there’s a whole new world for stuff-ups.


Good luck with the integration, and don’t hesitate to post your own experiences on the Internet. Scenarios are plentiful, documentation scarce, and every piece of information helps.

Smart card logon error 0xC00000BB

When you implement smart card logon on a Windows domain, sometimes you may receive the following error message:


The system could not log you on. The server authenticating you reported an error (0xC00000BB). You can find further details in the event log. Please report this error to the system administrator.


There is a Microsoft KB article (891849) describing the issue. However, the sAMAccountName and userPrincipalName prefix mismatch aren’t always the cause.


Users receive same error when the domain controller doesn’t have a DC certificate installed. That can happen if a manual procedure or a 3rd-party CA are used for domain controller certificate enrollment – you can miss some of the DCs.


For information about domain controller certificates read Advanced Certificate Enrollment and Management on TechNet and MS Knowledgebase article 291010 – Requirements for Domain Controller Certificates from a Third-Party CA.

Pragmatism doesn’t always work

Asset classification is a popular concept among security specialists. Quoting from The Pragmatic CSO:


You can’t protect what you don’t know about, so the first step is to figure out what you have. Likewise, you don’t want to spend $50,000 protecting a $2,000 business system, so in Step 1 you talk to senior management and discern how important each system is to the operations of the business. Then you can figure out how much to invest in protecting it.


Here’s why it won’t work:


  • Senior management may not think of the business in terms of particular systems facilitating it. They will rely on you to provide that information;
  • In today’s interconnected world, a single system means nothing. Mainframes tend to be very important to the businesses using those -so should most resources be allocated to protecting mainframes? Not really, not just mainframes. Rather, their entire ecosystem – that included the mainframe, its storage system, administrative workstations, user workstations, network infrastructure linking all that, directory services that is used for authentication and authorisation to the infrastructure elements, identity management system, and supporting processes. So, what is not so important?
  • Underinvesting in protection of supposedly low-risk infrastructure is a big risk. Most of the multimillion dollar breaches happened through sub-$2000 systems that have had little visibility to technical staff, let alone senior management.

An alternative (yet also pragmatic) approach would be to protect everything. That requires knowing everything in the enterprise – and not allowing the unknowns.