Welcome to the Interconnect-IT weblog. In this weblog we will comment and focus our attention on security-related information in the broadest sense of the word. Most of our effort will be put into cryptography (ancient and contemporary), interesting security documents and tools we spot on the web and security trends.

Sunday, 18 January, 2009
Smartcard Implementation

Some organizations prefer strong authentication for some or all of their employees. Strong authentication is a combination of something that you have -a smartcard-, something that you know -a pincode- and something that you are -biometrics- and is also called multi-factor authentication. It solves the problem of employees sharing passwords, which defeats things like accountability, least privilege (after all, why bother sharing passwords if you have an account with exactly the same privileges?) and and a slew of other security guidelines. Sometimes the introduction of smartcards is considered. There are a lot of issues that need to be taken care of in such an implementation. Some of the more operational issues that need to be answered, as opposed to design issues, as well as a handful of tips, are listed below. If you decide to go ahead with a smartcard implementation, be sure you have covered all of the items.

  • There are applications, which do not work in concert with smartcards. This could have several reasons, such as:
    1. The application is Active-Directory integrated and needs a username and password as authentication data. An example is Remote Desktop. Although the smartcard driver might automatically kick in when a remote desktop connection is set up, providing a prompt or window to provide the pincode, this is not always possible, e.g. when multiple authentication hops need to be crossed. This might occur when a supplier logs on to the extranet and from there accesses a machine on the internal network.
    2. The application executes batch jobs, which might freeze when the smartcard is removed from the smartcard reader.
    3. The platform simply doesn't support a smartcard infrastructure, such as Windows Mobile.
    All the applications which are not smartcard-compatible need to be accounted for, and decisions need to be made what to do with them. Should they be made smartcard-compatible? Should they be made smartcard-compatible when the next version is implemented? Should we leave the applications lone and accept the fact that the people working with these applications will be exempt from smartcard usage? Should a second user account be introduced for these applications with rights only for those specific applications?

  • When people are not required to use a smartcard for one of the above-mentioned reasons, how do you make sure that the smartcard exemption is reversed when they move to another department where all the software is smartcard-compatible? Periodically present management with a list of exemptions and have them verify and approve the list? Grant a 6-month exemption period and contact the end user when that period has passed (or have the end user contact you instead)? Remove all permissions when a person moves to another department, including the smartcard exemption? If you opt for the latter, what makes you believe that you can fight this authorization creep, while other companies are struggling just as hard to solve this issue?

  • When there are smartcard exemptions, one end user can log on using her username and password, while another end user can have her password scrambled without her knowing it. If a person switches from username and password authentication to smartcard authentication, the password field of that person should be scrambled, preferably using a script of some sort that runs every day or so. How do you make a distinction between smartcard users and non-smartcard users? (There are usually enough fields in a directory server for this, so this shouldn't be a problem.)

  • What should be the minimum length of the pincode? Should the code be changed periodically, or do you leave that up to the end user? Where is the software installed that can be used for pincode change? Should it be part of the operating system image? Is it stored on a network share? How are you going to communicate this to end users?

  • How secure are you going to build the infrastructure? How redundant are the supporting servers going to be? Is there a security policy which dictates the required measures? Is there a policy that describes the way in which certificates and cryptographic keys are handled? If not, what do you believe is the vulnerability landscape? What happens when servers go down, or when a root certificate is compromised, or when the status of revoked certificates is no longer propagated to all the requesting nodes? Is there a recovery plan? Is that plan tested periodically? Who approved these tests? To sum up: is there a plan when things get ugly?

  • Are different smartcard driver versions compatible with one another? Are you sure these different versions work flawlessly with one another, even in a heterogeneous environment with e.g. different Citrix software versions? If not, are you going to install a second Citrix farm?

  • Who should authorize a smartcard exemption for an end user? If this isn't handled correctly, you can be pretty sure that suddenly a lot of people seem to be using Remote Desktop.

  • New procedures need to be put in place and communicated to stakeholders, paying attention to issues like:
    1. Who is allowed to issue the smartcards?
    2. If the smartcard contains an image of the end user, is there a law that requires the employee to give a written consent to store this image in a computer system?
    3. How is the smartcard (and pincode) sent to a remote office, possibly in another country?
    4. How do we deal with broken smartcards and broken smartcard readers in case of emergencies? Do we allow a username and password fallback implementation? If not, is the risk of not meeting an SLA acceptable? Who is to decide about that?
    5. What should be done when smartcards are lost or forgotten? Do you have enough spare smartcards? How about enough spare smartcard readers?
    6. Should a supplier, who is allowed to access your network remotely using a smartcard and pincode, have access to the network when he feels like it, or when you feel like it? How do you make sure he doesn't access the network even if there are no calls or emergencies to solve? Is it a problem that he accesses the network that way?
    7. All the people responsible for software acquisition need to be aware that a new requirement must be met, i.e. smartcard support and backward compatibility for smartcard support.
    8. Periodically keep management up to date on how many smartcard exemptions have been granted, possibly defining a key performance indicator on the maximum number of exemptions.
    9. ...



posted by casper van eersel on 10:02PM

Sunday, 18 January, 2009

Every specialization, especially the field of information technology and related fields such as security, uses its own lingo. It speeds up the conversation between professionals, and as long as we all agree on the meaning of the words, everything proceeds as expected. Problems arise when people not familiar with the lingo need an explanation. That is when the following happens.




Now that we are discussing lingo, many of the networking people will know what the acronym "APSTNDP" stands for. It's used to remember the different OSI layers in the correct order: Application - Presentation - Session - Transport - Network - Datalink - Physical. To make the acronym easier to remember, the sentence "All People Seem To Need Data Processing" was introduced, where the first letter of each words gives you "APSTNDP". The problem with that line is its rather dull nature. Why not make things a little more interesting? From now on I would like to see the following line being taught in every networking course: "A Priest Saw Thirty Nuns Doing Pushups". Thanks for your help.


posted by casper van eersel on 00:55AM

Saturday, 17 January, 2009
Biometrics Evasion

In the very near future, more and more people within the EU will carry a passport which includes biometric features. The reason for this is because the European Commission have approved an amendment to regulation 2252/2004/EC, in which it addresses among other things the incorporation of two fingerprints and a facial scan in the passport. The amendment comes into force June 29th 2009. It will certainly have enormous security and privacy implications, made even more clear by the poor track record of all member states when it comes to protecting sensitive government information. But let's keep things light-hearted for the moment.


It is interesting to see how many criminals have tried to evade capture by trying to alter their fingerprints. A dated but interesting read is the article "Attempts to alter and obliterate finger-prints", which appeared in the Journal of the American Institute of Criminal Law and Criminology in the mid 1930's. Another interesting and more recent read is Altered Fingerprints, by Kajal Singh. This document contains some truly classic and equally dumb tried-and-tested methods (as well as some disturbing images!). Two of my favorites include:

  • John Dillinger, who was said to have applied acid to his finger tips. Unfortunately for John, the acid treatment should have been more thorough. Because he failed to treat the entire fingertips with acid and because the ridge pattern reappeared after a while, "sufficient ridge details [allowed] the identification positively under comparison with the prior prints on record."
  • Robert J. Philipps, a criminal who had his fingerprints replaced with skin grafted from the side of his chest. Unfortunately for him as well, the ridge patterns on the sides of his fingers and the second phalange allowed for a positive identification.

If you decide to change your career and fingerprints accordingly, be aware that not only your fingerprints need to be altered, but your palmprints as well, since they serve as good biometric identification mechanisms. Happy surgery!

posted by casper van eersel on 23:12PM

Saturday, 17 January, 2009
Setting Windows 2003 Eventlog Permissions

A situation might occur in which certain administrators need read access to event logs of Windows servers, notably the Security eventlog. Adding these administrators to the local or domain Administrators group probably violates the principle of least privilege; the same goes for granting these administrators the "Manage Auditing And Security Log" user right. The solution is to give the administrators only read access, but how to go about that?


What need to be done is changing the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\"eventlog name"\CustomSD (REG_SZ) registry value on the Windows servers in such a way as to grant read access to these administrators, where "eventlog name" is the name of the eventlog, such as Application or Security. How do we do this? The first thing to realise is that the information contained in the CustomSD registry value is expressed in an arcane language called the Security Descriptor Definition Language (SDDL). Mark Minasi's newsletter #44 contains an article entitled "Controlling Who Can Read a Log File in 2003", which contains an easy to follow explanation of SDDL. For the more formal minded people, the Microsoft MSDN site contains an overview of how an ACE string is constructed. To grant Read access using SDDL-ese, three pieces of information are necessary:

  • Know whether access is granted or denied. In this case, access is granted, denoted by the letter "A" (for ACCESS_GRANTED).
  • What type of access is granted. In this case, we grant Read access, which translates into "0x1", as mentioned in KB article Q323076. (Permission to write to the eventlog corresponds to "0x2", while clearing the eventlog corresponds to "0x4". Granting Read and Clear permissions would change "0x1" into "0x5".)
  • The SID of the security principle that is granted Read access. In this case, we might retrieve the SID of the Active Directory group called "Security Administrators" or so, which could be S-1-5-21-2000478354-706699826-682003330-131523. (This of course totally depends on your own environment, group names and the like.) As a sidenote:
    1. The SID of the security principle can be retrieved using user2sid.exe or the psgetsid.exe tool, which is part of Mark Russinovich' PsToolkit.
    2. Several Builtin groups have their SID abbreviated, as the Microsoft article on SID strings explains. For example, "AU" is used to denote the Authenticated Users group, while "EA" is used to denote the Enterprise Administrators.

Following the SDDL syntax, we would add "(A;;0x1;;;S-1-5-21-2000478354-706699826-682003330-131523)" to the CustomSD registry value in order to grant Read access to the members of the "Security Administrators" group.


Several tools have been created to translate the SDDL format into a human-readable string. Two of the more popular ones are SDDLtranslate.exe and SDDLparse.exe. To get some real-life SDDL strings from your own computer, fiddle around with the "sc sdshow" command. The service name that needs to be provided as a parameter can be retrieved using the command "sc query type= service | find "SERVICE_NAME"; the command "wmic service get Caption,Name" does the trick equally well if the WMI client is installed on your machine. (It's the string in the "Name" column that you need; the "Caption" column is only included to make it clearer which service is which.) To translate this particular SDDL gibberish, you can download and use SvcInfo.exe and compare the two formats.

posted by casper van eersel on 21:55PM