Random Password Generator Tool

Sure, there are lots of random password generators out there, but how many of them are integrated with our very feature-rich open source code repository of tools that will help you to code against Active Directory, while also standing alone as a simple quick to use tool for a helpdesk?

Yeah, that's right, only 1 random password generator tool does that.  Get it and its open source code now: https://github.com/Securology/ActiveDirectoryServices/tree/master/PasswordGenerator

Coding for Active Directory: Quickly import Exchange Rooms or Resources

Do you have a copy of Visual Studio, a very rudimentary knowledge of C# .NET, and a need to import a list of Exchange Rooms or Resources into your Active Directory?

If so, check out a couple very simple example apps that can import .CSV files to knock out this frequent task:

https://github.com/Securology/ActiveDirectoryServices

Coding for Active Directory: Programmatically Get or Set Obscure Attribute Data in C#

If you are an organization of any size, chances are you have an Active Directory instance sitting around, and maybe some level of additional investment in Microsoft products beyond Windows on client machines and a couple servers.  And the more investment you have, the more value you will get from having relevant data in your Active Directory.  You may even have some developers on staff that write applications in C# or VB .NET.  Chances are, though, your developers won't understand or even want to understand Active Directory.

They may, however, be able and willing to code to a few random source code examples that float around on the web, but most examples are not very feature complete.  So it requires developers digging into the musty underbelly layers of Active Directory to learn how to get what they need.  Few will dig.

You could purchase an API, but the licenses may be expensive, and you may only want to read or set a couple of attributes on a user or group object that nobody else seems to have documented how to do well enough to satisfy your developers.

Or you could just send your developers to the new Securology GitHub repository to pull down a fully-functional, open source, non-restrictively licensed API to include in their projects to get up and going.

Maybe you just dealt with a large scale AD migration and you need to peel back the layers and extract user or group SIDs (Security Identifiers) or validate that SIDs from previous domains on imported objects are properly stored in the SID History?

Maybe you have a basic interface with your HR system, but don't want to shell out tons of cash to purchase a metadirectory tool like Identity Lifecycle Manager to move HR data like manager/reporting relationships around, but could really benefit from having that data in your Exchange, SharePoint or other application environments.

Maybe you need to set the user's employee number from your HR system on each AD user to identify the authoritative data source to satisfy an Active Directory Audit.

Maybe you just want to read or write the AD user's address, telephone, or even IP Phone number.

Maybe you have a mixed environment that also contains Unix servers and you need to set Unix attributes on the IT Unix Admin user accounts for a Unix SSO to AD product that you're using.

Maybe you'd like to programmatically setup Microsoft Exchange or Lync (Office Communicator) attributes?

Maybe you'd like a safer way to programmatically move or delete Active Directory objects?

Maybe you'd like an easier way to programmatically add or remove a user from an AD group?  Or maybe check if they already are in that group?

Maybe you'd like to populate your AD with Contact objects for business partners who don't need user accounts in your domain or forest, but so that they'll still show up in the Global Address List (GAL)?

Maybe you need a way to programmatically create an Organizational Unit (OU)?

Maybe you'd like to toggle an AD group from "Security" to "Distribution" and back again?  Or "domain local" to "universal"?  Or dump all of its members?  Or check if the AD group has no members?  Or set the "owner" of the group for audit/management purposes?

Maybe you'd like to prune back old computer objects?  Or build a report to show what Operating Systems are in your directory?  Or safely move or delete computer objects?

Maybe you'd like a way to expose the True Last Logon time of a user account without manually checking each Domain Controller and comparing times?  Or maybe you'd like a nice multi-threaded (and fast!) way of checking all Domain Controllers simultaneously?

If any of those are even remotely interesting to you, check out our extended version of Microsoft's System.DirectoryServices.AccountManagement namespace that we provide on GitHub.

Coding for Active Directory: Proxying Users into an AD-LDS Application Directory

In another IT Pro tip related to Active Directory, suppose an organization has an internal AD forest, but has a company policy that only paid personnel are to have accounts in that directory.  That's a fairly rational policy:

• If we pay you directly, then you're an employee, so you get an account
• If we pay you indirectly, then you're a contractor that we've hired, so you can also get an account
• If you pay us, whether directly as a consumer, retailer, or reseller, or indirectly as a consumer through a retailer or reseller, then you're a customer, so you probably should not have an account in our internal AD forest.

But suppose you have an application that needs to be built that will allow both employees/contractors, AND customers to access it, and you don't want to setup yet-another-provisioning process for granting and revoking access for employees and contractors?

Enter a common solution: Active Directory - Lightweight Directory Services (previously known as ADAM, AD Application Mode, a.k.a. an "application" directory).  This is a lightweight, LDAP only directory with less bells and whistles than AD has, but many Microsoft-centric applications can plumb right into it.

But to achieve a true Single Sign On for the internal AD users, the IT Admin must create either a UserProxy or a UserProxyFull object in the AD-LDS.  Both function nearly the same, but a UserProxyFull has additional schema data elements for storing additional contact data fields, which are generally handy for today's applications.

Under the hood, when an internal AD user connects to the application, an authentication request is passed to the AD-LDS, which looks up the UserID of the internal user, finds the User Proxy object, and then performs Kerberos authentication against the internal AD.  All other attributes, though, from contact data fields, to the group memberships that the UserProxy has, are separate from the internal AD forest.  In essence, nothing is automatically the same and it's yet-another-directory-to-manage.

Wouldn't it be nice if there was a way to build a service or application in C# .NET so that a configurable subsection of your organization's internal AD user community could automatically be provisioned and deprovisioned, complete with metadata updates, and maybe even rudimentary AD-LDS group memberships based on your AD data?  Why yes, yes that would be very nice.  

Wouldn't it be even nicer if the code was open source so we can take it, borrow it, and use it internally without a restrictive license?  Why yes, yes that would be very nice, too.

Wouldn't be even nicer still if this article linked straight to that source code?

Why yes, yes it sure would be nice.

Good thing we just did! 

Start synchronizing your Active Directory forest with your Lightweight Directory Services (AD-LDS) instance with this example solution in C#.

Active Directory Tip: Hitting Snooze on the Password Expiration Policy

The Active Directory Password Expiration Snooze Button

IT Administrators have certainly been in the tough scenario where a security policy mandates that passwords expire in X days, but there are constraints that make it really hard for the user account passwords to actually change.  For example:

• Dealing with service, application, or generic accounts and a strict constraint to not mark them as non-expiring (forever) passwords
• Dealing with rarely active human users who suddenly need to (on-demand) authenticate against an application, such as HR benefits open enrollment for employees who are not "information workers" (don't access computers).

There are a couple tricks for dealing with this without causing interruption.  Take note that these "tricks" may completely circumvent the letter and perhaps even the intent of the "policy".  But even with astute auditors, the intent of using these tricks will likely never get noticed. 

Or perhaps you are an auditor, and reading the details of these tricks will open up your mind to look for new events that signify lack of compliance.

Administrative Password Resets

If you know the password for the account in question, then simply perform a password reset with that password.  If you have never thought to do this before, this may at first seem counter-intuitive: after all, resetting a password with a password history rule turned on by policy will cause the password to change, right?

Wrong.  There are two ways an Active Directory password can change: 

1. The user initiates a password change event, in which they are required to supply the current password in addition to a new password.
2. The administrator with permissions on the UserAccountControl attribute of the AD user object can perform an administrative reset.

A reset by an administrator must support changing the password when the user is locked out and does not know the password, therefore, the administrator is not required to know the current password.

Also, a reset by an administrator does not enforce password history.  If it did, a rogue administrator could inadvertently learn the current password if the new password supplied by the administrator failed to reset due to password history requirements.  Sure, they just reset the password and could impersonate the user anyway, but that may not be the point: that user's password might be the same on a different (non-Active Directory integrated) application.

So, if you know the current password, perform a RESET and the password last set date attribute on the user account in the directory will update, effectively hitting the snooze button.

A More Clever Trick

But what if you don't know the current password for the account?  

In the scenario of a mostly-inactive end user community that suddenly need to hit an application (e.g. your company's HR system for annual benefits enrollment):

• there may be too many users to learn their passwords
• asking the user for their password is likely faux pas
• the user may not even know the password anyway (since it's been a year), and 
• resetting a large collection of users passwords to a standard/default that everyone shares is insecure
• and resetting individually unique passwords for an infrequent, on-demand access presents communication problems all of its own

So, what to do? 

You could disable or extend password expiration.  In Windows 2003 AD and earlier, this meant changing the policy for everybody, which may not be the intent at all.  This is especially true if there are both active and inactive users in the directory, since active users will not get the normal "your password is about to expire" warning X days before it's too late.  Reverting your password expiration policy setting back to the original value could result in a portion of your active users suddenly being locked out and calling for help.  In Windows 2008 and later, you can have multiple expiration policies within a domain, but your user objects may not be grouped to distinguish the inactive users of concern.  You could identify them and move them (and even script that step), but then you may have to move them back to many different OUs (Organizational Units) which could be just as much of a pain as the original problem.

Or you could follow this set of steps (which are scriptable!):

1. In Active Directory Users and Computers, locate the user with the expiring or expired password
2. Check the "force password change at next logon" box.
3. Click Apply.
4. Uncheck the "force password change at next logon" box.
5. Click Apply.

And VOILA!  That user's password expiration has just been snoozed-- effectively reset for another iteration, and with zero knowledge of the current password.  The password last set date will appear to be the moment you hit step 5.

How does this work?

Under the hood, the user attribute which stores the date/time when the password was last set is also dual purposed for the password must change flag.  The value is a really large integer which contains the number of ticks of seconds as a representation of time.  But when the force password change button is checked, the value of seconds of time is wiped out.  "Empty" is how the flag is stored.  The last date/time is wiped out.  So, when the administrator unchecks the force password change checkbox, AD Users & Computers has to put SOMETHING in that attribute, because NOTHING appears like it is flagged for change.  But the original value is gone forever!  So what does it store there?  The current date/time.  Hence, the user appears to have had its password reset without any actual (visible) changes to the user.

This can all be scripted out using the dsquery and dsmod commands the Microsoft ships with Active Directory.  PowerShell could also be used.  Or, an astute C# (or VB) .Net developer could simply take a look at the Securology GitHub repository, to see the example Password Snooze Button console app, to incorporate it into your organization's existing user management applications and services.

For the Auditor

To detect if an organization that you are auditing has been using the first option (administrative password resets to snooze the expiration), look for:

• Event log data for password resets of multiple accounts at roughly the same time, since this would likely be done "in mass" by the IT administrator
• Service accounts that all have roughly the same password last set date and time.  Manually resetting multiple passwords would have a period of time between each reset event, but a script would cause them all to be within a few seconds of each other
• User accounts that have been in existence for longer than the password expiration policy's time out, but that have one or few historical passwords stored in the directory (requires a very low level AD editing tool to discover), while still being active (lots of log on events)

To detect if an organization has been using the second option (password must change flag), look for:

• Lots of user accounts with nearly the same date/time value for the password last set attribute.
• Lots of user accounts that have not logged in since their password was last set.
• If event log data is available, look for lots events denoting the must change password flag was set or unset.

Even if long term historical event log data is available, the determined IT administrator could spread out these events to appear sporadic, random, or intentionally related to a user's call to a help desk.  A determined administrator could both keep the lights on and keep auditors at arms' length without detection of a policy violation.

Securology's Open Source Repository on GitHub

Securology now has open source code on GitHub!
https://github.com/Securology

This is something we have wanted to do for some time and finally are now able!  As our contributors find the time and freedom to contribute some of our intellectual property back to the greater community at large, we will add more repositories and content there.

Our first offering is a C# .NET wrapper that can do more to manage Microsoft Active Directory instances (including Active Directory Lightweight Directory Services, formerly known as ADAM, or Active Directory Application Mode) than any other open source project can do (which is why we wrote it in the first place).  Our open source Active Directory Services repo is available here:
https://github.com/Securology/ActiveDirectoryServices

In addition to shipping a core library that extends Microsoft's out-of-the-box functionality that ships with the .NET runtime (System.DirectoryServices.AccountManagement), we also have fully working example applications that are consumers of the library, so you can see how to use all of the features we have built.

Here's a list of just some of the features our consumer applications can do:

• Create, Edit, Update, and Delete Active Directory objects Users, Groups, Organizational Units (OUs), Contacts, etc.
• Create, Edit, Update, and Delete AD-LDS (ADAM) UserProxy and UserProxyFull objects.
• Sync AD Users into an AD-LDS (ADAM) instance as UserProxy or UserProxyFull objects.
• Create, Update, Delete, and generally manage/sync dynamic AD security/distribution groups based upon reporting relationships (if those are defined within Active Directory).
• Enable, set, and maintain Microsoft Exchange attributes to enable objects to become visible in the GAL (Global Address List), which also works for Microsoft's Exchange Online hosted service via DirSync.
• Import various rooms and resources from a .CSV file into Active Directory and enable their visibility in the Exchange GAL.
• Enable and Manage Office Communicator/Lync attributes to turn on/off access to your company's Lync/OCS server, setup default policies, including access to any internet-facing proxy servers as well as archive/logging per user.
• Generate random passwords for users.
• A nifty way of "snoozing" when a AD user's password expires while keeping the same password.
• And much more...

Eventually, we will share a working Provisioning Web Service that will be a great solution for limited budget organizations that want some of the functionality Microsoft's Identity Lifecycle Manager (ILM) includes, without the heftier license cost and infrastructure requirements.

More follow-up posts will follow.

Coping with Compromised Certificate Authorities

With the news containing stories of malware distributing via compromised Certificate Authorities, it makes sense that some IT Security blogs would address "what to do" if this happens to your CA.  This blog post gets it wrong, though:

What would you do if you found out that the Certificate Authority that provides Digital Certificates to your company was compromised, and Microsoft was adding the Certificate Authority’s public key to Windows un-trusted Root Store? Well if you have not got a contingency plan to implement then I can presume you will be in a panic to purchase new certificates from another Certificate Authority... It can take Certificate Authority’s (CA’s) a few days to validate domain ownership and company registration details... While all this is happening your customers are getting a message from Internet Explorer that your SSL certificate is not to be trusted.

What can you do?

• Do not rely on one Certificate Authority for all of your certificates. You should have a relationship with at least two well known Certificate Authority’s and the CA’s should have validated all of your domains. This will let you quickly order Digital Certificates from the second CA without having to go through the company validation process...
• If you cannot tolerate any downtime for a service you can take the extra step in which you create backup certificates for each service using your backup Certificate Authority. This will enable you to implement the backup certificates without having to contact the second CA and joining the queue of company’s looking for new certificates.

Keep in mind that the worst-case scenario described above would require the Root CA Certificate to be compromised.  Most Root CAs are offline certs, meaning the computers that house them are not powered on except during special circumstances when new intermediate CA certificates are generated, OR, they are online in an "air gap" (disconnected from the internet) network accessible only via sneakernet.  Exploiting an offline CA is a big deal, and if it occurs it won't be just your organization that is affected, but likely a large part of the entire internet.

So a much more plausible option:

• The CA will just create a new intermediate CA cert and re-issue client certs to all of its paying customers.

In other words: nothing to see here, please move along.

XKCD Password Strength

RSA SecurID Breach - Seed Record Threats

The following is a threat model that assumes the RSA SecurID seed records have been stolen by a sophisticated adversary, which is probably what happened.

But first, a word from our muse, Bruce Schneier, regarding what he titled back in 2005 as the "Failure of Two Factor Authentication":

Two-factor authentication isn't our savior. It won't defend against phishing. It's not going to prevent identity theft. It's not going to secure online accounts from fraudulent transactions. It solves the security problems we had ten years ago, not the security problems we have today.
[snip]
Here are two new active attacks we're starting to see:

• Man-in-the-Middle attack. An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank's real website. Done right, the user will never realize that he isn't at the bank's website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user's banking transactions while making his own transactions at the same time.
• Trojan attack. Attacker gets Trojan installed on user's computer. When user logs into his bank's website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.

See how two-factor authentication doesn't solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.
[Snip]
Two-factor authentication ... won't work for remote authentication over the Internet.

Bruce was absolutely right. We saw examples of that.

...

Now, let's put the pieces together-- the active MITM attacks that Bruce described, which could result in an offline/passive attack.

In both cases above, the adversary has to act immediately to essentially take over an authenticated session, using either the real-time MITM scenario, or the trojan scenario. But let's assume that the "good guys" have, by now, read Bruce's article [but in all reality, they probably haven't, hence they have an RSA SecurID investment] and have paid attention to the RSA jabber that says to watch for an increase in login attempts. In these examples Bruce describes, the adversary grabs the session and disconnects the valid user (possibly at the presentation layer, by taking over the session in malware that doesn't display what the actions are occurring in the authenticated session).

However, let's assume the adversary let's the user keep his authenticated session. The adversary just monitors the credentials that are entered:

1. The User ID, and
2. The one-time-passcode (token's readout, a.k.a. "tokencode", plus the user's PIN)

"Relax," says the security administrator. "That's what these RSA SecurID thingies are for-- to make it meaningless when a bad guy eavesdrops on credentials."

Well, except in the case where the "bad guy" has all of the seed records for all RSA SecurID tokens ever sold.

Quoting from our article from yesterday:

Assume an adversary has now in their possession, all of the seed records for all RSA SecurID tokens that are currently valid (which based on above and previous seems very plausible). Assume they have sufficient computing hardware to mass compute all of the tokencodes for all of the tokens represented by those seed records for a range of time (they obviously are well funded to get the "Advanced Persistent Threat" name). This would be the output of the RSA SecurID algorithm taking all the future units of time as input coupled with the serial number/token codes to generate all of the output "hashes" for each RSA SecurID token that RSA has ever made. These mass computed tokencodes for a given range of time would basically be one big rainbow table, a time computing trade-off not too unlike using rainbow tables to crack password hashes.
[Snip]
Since tokencodes are only 6 digits long, and RSA has sold millions of tokens, the chances of a collision of a token's output with another token's output at a random point in time is significant enough, but phish the same user repeatedly (like asking for "next tokencode") and the adversary now can significantly narrow down the possibilities of which tokens belong to which user because different tokens must appear random and not in sync with each other (otherwise RSA SecurID would have much bigger problems). Do this selectively over a period of time for a high valued asset, and chances are the adversary's presence will go undetected, but the adversary will be able to determine exactly which token (serial number, i.e. seed record) belongs to the victim user.

So, now that the adversary has these "rainbow tables" of RSA SecurID tokencodes, and now that the active attacks Bruce described have morphed into a passive attempt, all it will take is watching particular users create valid sessions-- maybe as little as a single attempt, depending upon the mathematics and randomness of the RSA SecurID token output, but probably more like watching a handful of attempts. At that point, the adversary can then impersonate the victim user at any point in the future.

So, if RSA SecurID seed records are compromised, there is really not much advantage in an RSA SecurID implementation. The threats are essentially the same as an adversary grabbing conventional passwords. The only difference is that a passive attack against compromised seed records may take multiple monitoring attempts, as opposed to a single event. But with simple malware, that won't be much more effort, especially for a high valued asset.

So given what we know, we can assume seed records were compromised. And given how little RSA is talking about it, we cannot really know how they are responding to it. Will they just distribute new tokens without compromised seed records, or will they do something much more significant? Based on what we know today, it makes more sense for an organization that is thinking about an RSA SecurID deployment to rely instead on conventional passwords (e.g. Microsoft Active Directory), and spend the extra money on monitoring for fraud and stronger identity validation for things like password resets.

More RSA SecurID Reactions

RSA Released a new Customer FAQ regarding the RSA SecurID breach. Let's break it down ...

Customer FAQ
Incident Overview

1. What happened?

Recently, our security systems identified an extremely sophisticated cyber attack in progress, targeting our RSA business unit. We took a variety of aggressive measures against the threat to protect our customers and our business including further hardening our IT infrastructure and working closely with appropriate authorities.

Glad to see they didn't use the words "Advanced Persistent Threat" there.

2. What information was lost?

Our investigation to date has revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is related to RSA SecurID authentication products.

Hmmm. Seed Records possibly?

3. Why can’t you provide more details about the information that was extracted related to RSA SecurID technology?

Our customers’ security is our number one priority. We continue to provide our customers with all the information they need to assess their risk and ensure they are protected. Providing additional specific information about the nature of the attack on RSA or about certain elements of RSA SecurID design could enable others to try to compromise our customers’ RSA SecurID implementations.
[Emphasis added by Securology]

Whoa! Pause right there. Obviously they have allowed somebody from a Public/Customer Relations background to write this. This is not coming from anybody who *knows security*.

Like we mentioned previously, Kerckhoff's Principle and Shannon's Maxim dictate that the DESIGN be open. These ideas are older than the Internet, and pretty much older than computing itself. So, disclosing the RSA SecurID DESIGN should have no adverse affect on customers with implementations unless the DESIGN is flawed to begin with.

Realistically, this is PR-speak for obfuscating details about what was stolen. All things point to seed records. Source code to on-premise implementations at customer sites shouldn't be affected, because those components aren't facing the Internet, and generally who cares about them? Yes, it's possible to hack the backend through things like XSS (think "Cross Site Printing"), but the state-of-the-art would be to compromise it from the outside using weaknesses found at RSA headquarters: seed records.

4. Does this event weaken my RSA SecurID solution against attacks?

RSA SecurID technology continues to be an effective authentication solution. To the best of our knowledge, whoever attacked RSA has certain information related to the RSA SecurID solution, but not enough to complete a successful attack without obtaining additional information that is only held by our customers. We have provided best practices so customers can strengthen the protection of the RSA SecurID information they hold. RSA SecurID technology is as effective as it was before against other attacks.
[Emphasis added by Securology.]

If it wasn't obvious that it's seed records yet, it should be screaming "SEED RECORDS" by this point. RSA SecurID is a two factor authentication system, meaning you can couple your RSA SecurID time synchronized tokencode with a PIN/Password. So, if the seed records are stolen, then the only way an adversary can impersonate you would be if he knew:

1. Which RSA SecurID token is assigned to you (i.e. the serial number stored in the RSA SecurID database on-site at a customer's site)
2. Your PIN/Passcode that is the second facto (i.e. another piece of information stored in the customer's site).

More evidence that the RSA breach was seed records: the serial number and seed records give the adversary half the information needed, but the rest is stored on-site.

5. What constitutes a direct attack on an RSA SecurID customer?

To compromise any RSA SecurID deployment, an attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful direct attack, someone would need to have possession of all this information.


6. What constitutes a broader attack on an RSA SecurID customer?

To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful direct attack, someone would need to have possession of all this information.

The broader attack we referenced most likely would be an indirect attack on a customer that uses a combination of technical and social engineering techniques to attempt to compromise all pieces of information about the token, the customer, the individual users and their PINs. Social engineering attacks typically target customers’ end users and help desks. Technical attacks typically target customers’ back end servers, networks and end user machines. Our prioritized remediation steps in the RSA SecurID Best Practices Guides are focused on strengthening your security against these potential broader attacks.
[Emphasis added by Securology]

This PR person is beginning to agree with us. Yes, the seed records are the hard part. If you are an RSA SecurID customer, assume the adversary has them, and now watch out for the pieces you control.

7. Have my SecurID token records been taken?
[Emphasis added by Securology.]

Yes, it's obvious they have.

For the security of our customers, we are not releasing any additional information about what was taken. It is more important to understand all the critical components of the RSA SecurID solution.

To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful attack, someone would need to have possession of all this information.

This is beginning to look like a broken record.

8. Has RSA stopped manufacturing and/or distributing RSA SecurID tokens or other products?

As part of our standard operating procedures, while we further harden our environment some operations are interrupted. We expect to resume distribution soon and will share information on this when available.

Of course manufacturing/distribution has stopped. Of course anyone worried about security would have an SOP that says "stop shipping the crypto devices when the seed records are compromised." This is just more evidence that the seed records were compromised.

[...snipped for brevity...]
13. How can I monitor my deployment for unusual authentication activity?

To detect unusual authentication activity, the Authentication Manager logs should be monitored for abnormally high rates of failed authentications and/or “Next Tokencode Required” events. If these types of activities are detected, your organization should be prepared to identify the access point being used and shut them down.

The Authentication Manager Log Monitoring Guidelines has detailed descriptions of several additional events that your organization should consider monitoring.
[Emphasis added by Securology]

Warning about failed authentication and next tokencode events further indicates the seed records were stolen, because this would indicate the adversaries are guessing valid tokencodes but invalid PINs, or guessing tokencodes in order to determine a specific user's serial number (to match stolen seed records with a particular user).

14. How do I protect users and help desks against Social Engineering attacks such as targeted phishing?

Educate your users on a regular basis about how to avoid phishing attacks. Be sure to follow best practices and guidelines from sources such as the Anti-Phishing Working Group (APWG) at http://education.apwg.org/r/en/index.htm.

In addition, make sure your end users know the following:

• They will never be asked for and should never provide their token serial numbers, tokencodes, PINs, passwords, etc.

Because giving that away is giving away the last parts of information that are "controlled only by the customer", i.e. the mapping of UserIDs to seed records via token serial numbers.

• Do not enter tokencodes into links that you clicked in an email. Instead, type in the URL of the reputable site to which you want to authenticate

Because a phishing attack that takes a tokencode could be all that is needed to guess which serial number a user has, since that moment in time could be recorded, and all seed records could be used in a parallel, offline attack to compute their token codes at that instance in time. Assume an adversary has now in their possession, all of the seed records for all RSA SecurID tokens that are currently valid (which based on above and previous seems very plausible). Assume they have sufficient computing hardware to mass compute all of the tokencodes for all of the tokens represented by those seed records for a range of time (they obviously are well funded to get the "Advanced Persistent Threat" name). This would be the output of the RSA SecurID algorithm taking all the future units of time as input coupled with the serial number/token codes to generate all of the output "hashes" for each RSA SecurID token that RSA has ever made. These mass computed tokencodes for a given range of time would basically be one big rainbow table, a time computing trade-off not too unlike using rainbow tables to crack password hashes. Then assume the adversaries can phish users into providing a tokencode into a false login prompt. Since tokencodes are only 6 digits long, and RSA has sold millions of tokens, the chances of a collision of a token's output with another token's output at a random point in time is significant enough, but phish the same user repeatedly (like asking for "next tokencode") and the adversary now can significantly narrow down the possibilities of which tokens belong to which user because different tokens must appear random and not in sync with each other (otherwise RSA SecurID would have much bigger problems). Do this selectively over a period of time for a high valued asset, and chances are the adversary's presence will go undetected, but the adversary will be able to determine exactly which token (serial number, i.e. seed record) belongs to the victim user. Or do it in mass quickly (think: social media) and it will harvest many userIDs to serial numbers (seed records) which would be valuable on the black market-- especially for e-commerce banking applications.

It is also critical that your Help Desk Administrators verify the end user’s identity before performing any Help Desk operations on their behalf. Recommended actions include:

· Call the end user back on a phone owned by the organization and on a number that is already stored in the system.

· Send the user an email to a company email address. If possible, use encrypted mail.

· Work with the employee’s manager to verify the user’s identity

· Verify the identity in person

· Use multiple open-ended questions from employee records (e.g., “Name one person in your group” or, “What is your badge number?”). Avoid yes/no questions

Important: Be wary of using mobile phones for identity confirmation, even if they are owned by the company, as mobile phone numbers are often stored in locations that are vulnerable to tampering or social engineering.
[...snipped for brevity...]

The above is very decent advice, not unlike what we posted recently.


So, in summary: yeah, yeah, yeah, seed records were stolen. Little to no doubt about that now.

RSA SecurID Breach - Initial Reactions

RSA, the security division of EMC, was breached by a sophisticated adversary who stole something of value pertaining to RSA SecurID two factor authentication implementations. That much we know for certain.


It's probably also safe to say that RSA SecurID will be knocked at least a notch down off their place of unreasonably high esteem.


And it wouldn't hurt to take this as a reminder that there is no such thing as a perfectly secure system. Complexity wins every time and the adversary has the advantage.


First, note that the original Securology article entitled "Soft tokens aren't tokens at all" is still very valid as the day it was published over 3 years ago. CNET is reporting that RSA has sold 40 million hardware tokens and 250 million software tokens. That means that 86% of all RSA SecurID "tokens" (which are of the "soft token" variety) are already wide open all of the problems that an endpoint device has-- and more importantly, that 86% of the "two factor authentication" products sold and licensed by RSA are not really "two factor authentication" in the first place.


Second, we should note the principles in economics, so eloquently described by your mother as: "don't put all your eggs in one basket", i.e. the principle of diversification. If your organization relies solely on RSA SecurID for security, you were on borrowed time to begin with. For those organizations, this event is just proof that "the emperor hath no clothes".


Third, the algorithm behind RSA SecurID is not publicly disclosed. This should be a red flag to anyone worth their salt in security. This is a direct violation of Kerckhoff's Principle and Shannon's Maxim, roughly that only the encryption keys should be secret and that we should always assume an enemy knows (or can reverse engineer) the algorithm. There have been attempts in the past to reverse engineer the RSA SecurID algorithm, but those attempts are old and not necessarily the way the current version operates.


Fourth, it's probably the seed records that were stolen. Since we know that the algorithm is essentially a black box, taking as input a "seed record" and the current time, then either disclosure of the "seed records" or disclosure of the algorithm could potentially be devastating to any system relying on RSA SecurID for authentication.

Hints that the "seed records" were stolen can be seen in this Network World article:

But there's already speculation that attackers gained some information about the "secret sauce" for RSA SecurID and its one-time password authentication mechanism, which could be tied to the serial numbers on tokens, says Phil Cox, principal consultant at Boston-based SystemExperts. RSA is emphasizing that customers make sure that anyone in their organizations using SecurID be careful in ensuring they don't give out serial numbers on secured tokens. RSA executives are busy today conducting mass briefings via dial-in for customers, says Cox. [emphasis added by Securology]

Suggesting to customers to keep serial numbers secret implies that seed records were indeed stolen.

When a customer deploys newly purchased tokens, the customer must import a file containing a digitally signed list of seed records associated with serial numbers of the device. From that point on, administrators assign a token by serial number, which is really just associating the seed record of the device with the user's future authentication attempts. Any time that user attempts to authenticate, the server takes the current time and the seed record and computes its own tokencode for comparison to the user input. In fact, one known troubleshooting problem happens when the server and token get out of time synchronization. NTP is usually the answer to that problem.

This further strengthens the theory that seed records were stolen by the "advanced persistent threat", since any customer with a copy of the server-side components essentially has the algorithm, through common reversing techniques of binaries. The server's CPU must be able to computer the tokencode via the algorithm, therefore monitoring instructions as they enter the CPU will divulge the algorithm. This is not a new threat, and certainly nothing worthy of a new moniker. The most common example of reversing binaries is for bypassing software licensing features-- it doesn't take a world-class threat to do that. What is much, much more likely is that RSA SecurID seed records were indeed stolen.

The only item of value that could be even more damaging might be the algorithm RSA uses to establish seed records and associate them with serial numbers. Assuming there is some repeatable process to that-- and it makes sense to believe there is since that would make production manufacturing of those devices more simple-- then stealing that algorithm is like stealing all seed records: past, present, and future.

Likewise, even if source code is the item that was stolen, it's unlikely that any of that will translate into real attacks since most RSA SecurID installations do not directly expose the RSA servers to the Internet. They're usually called upon by end-user-facing systems like VPNs or websites, and the Internet tier generally packages up the credentials and passes them along in a different protocol, like RADIUS. The only way a vulnerability in the stolen source code would become very valuable would be if there is an injection vulnerability found in it, such as passing a malicious input in a username and password challenge that resulted in the back-end RSA SecurID systems to fail open, much like a SQL injection attack. It's possible, but much more probable that seed records were the stolen item of value.


How to Respond to the News
Lots of advice has been shared for how to handle this bad news. Most of it is good, but a couple items need a reality check.


RSA filed with the SEC and in their filing there is a copy of their customer support note on the issue. At the bottom of the form, is a list of suggestions:

• We recommend customers increase their focus on security for social media applications and the use of those applications and websites by anyone with access to their critical networks.
• We recommend customers enforce strong password and pin policies.
• We recommend customers follow the rule of least privilege when assigning roles and responsibilities to security administrators.
• We recommend customers re-educate employees on the importance of avoiding suspicious emails, and remind them not to provide user names or other credentials to anyone ...
• We recommend customers pay special attention to security around their active directories, making full use of their SIEM products and also implementing two-factor authentication to control access to active directories.
• We recommend customers watch closely for changes in user privilege levels and access rights using security monitoring technologies such as SIEM, and consider adding more levels of manual approval for those changes.
• We recommend customers harden, closely monitor, and limit remote and physical access to infrastructure that is hosting critical security software.
• We recommend customers examine their help desk practices for information leakage that could help an attacker perform a social engineering attack.
• We recommend customers update their security products and the operating systems hosting them with the latest patches.

[emphasis added by Securology]

Unless RSA is sitting on some new way to shim into the Microsoft Active Directory (AD) authentication stacks (and they have not published it), there is no way to accomplish what they have stated there in bold. AD consists of mainly LDAP and Kerberos with a sprinkling in of a few other neat features (not going into those for brevity). LDAP/LDAPS (the secure SSL/TLS version) and Kerberos are both based on passwords as the secret to authentication. They cannot simply be upgraded into using two-factor authentication.

Assuming RSA is suggesting installing the RSA SecurID agent for Windows on each Domain Controller in an AD forest, that still does not prevent access to making changes inside of AD Users & Computers, because any client must be able to talk Kerberos and LDAP to at least a single Domain Controller for AD's basic interoperability to function-- those same firewall rules for those services will also allow authenticated and authorized users to browse and modify objects within the directory. What they're putting in there just doesn't seem to be possible and must have been written by somebody who doesn't understand the Microsoft Active Directory product line very well.


Securosis has a how-to-respond list on their blog:

Remember that SecurID is the second factor in a two-factor system… you aren’t stripped naked (unless you’re going through airport security). Assuming it’s completely useless now, here is what you can do:

1. Don’t panic. We know almost nothing at this point, and thus all we can do is speculate. Until we know the attacker, what was lost, how SecurID was compromised (if it is), and the vector of a potential attack we can’t make an informed risk assessment.
2. Talk to your RSA representative and pressure them for this information.
3. Assume SecureID is no longer effective. Review passwords tied to SecurID accounts and make sure they are strong (if possible).
4. If you are a high-value target, force a password change for any accounts with privileges that could be overly harmful (e.g. admins).
5. Consider disabling accounts that don’t use a password or PIN.
6. Set password attempt lockouts (3 tries to lock an account, or similar).

[Emphasis added by Securology]

To their first point, I think we can know what was lost: seed records. Without that, there would be no point in filing with the SEC and publicly disclosing that fact. Anybody can know their algorithm for computing one-time passwords by reversing the server side (see above). The only other component in the process is the current time, which is public information. The only private information is the seed record.

On point #4, if your organization is a high-valued asset type of a target, flagging RSA SecurID users to change their PINs or passwords associated with their user accounts may not be a good idea, because as the defense you have to assume this well articulated offensive adversary already has your seed records and therefore could respond to the challenge to reset passwords. A better solution, if your organization is small, is to physically meet with and reset credentials for high valued users. If you cannot do that because your organization is too large of a scale, then your only real option is to monitor user behavior for abnormalities-- which is where most of your true value should come from anyway.

This does tie well with their second suggestion-- pressuring your RSA contact for more information. In all likelihood, if our speculation that seed records were indeed stolen, then the only solution is to demand new RSA SecurID tokens from RSA to replace the ones you have currently. And if RSA is not quick to respond to that, it's for one of two reasons:

1. This is going to financially hurt them in a very significant way and it's not easy to just mass produce 40 million tokens overnight, OR,
2. RSA's algorithm for generating seed records and assigning them to token serial numbers is compromised, and they're going to need some R&D time to come up with a fix without breaking current customers who order new tokens under the new seed record generation scheme in the future.

UPDATED TO ADD: Since all things indicate the seed records were compromised, and since Art Coviello's message is that no RSA customers should have reduced security as a result of their breach, then that must mean RSA does not believe SecurID is worth the investment. After all, if RSA SecurID seed records were stolen, it effectively reduces any implementation to just a single factor: the PIN/passwords that are requested in addition to the tokencode. And who would buy all that infrastructure and handout worthless digital keychains when they can get a single factor password authentication for super cheap with Microsoft's Active Directory?

Verisign Turns Yellow

On the heels of turning PGP corp Yellow, now Verisign is turning Yellow, too. Symantec is acquiring Verisign, too.

These overpriced "security solutions" are going to go from bad to worse. I predict agile startups are going to crush them on their prices, since Symantec's goal is obviously to own the entire market with a one-size-fits-all approach, while some startups and smaller companies will probably better understand their customers' needs.

It's ironic how the PGP (distributed) model once fought strongly against the PKI (hierarchical, centralized) model. But now, thanks to deep pockets at Big Yellow, they'll be wearing the same uniform.

SSL and crypto are now commodities, so where are the commodity prices from PGP Corp, Verisign, and Symantec? Simple: they won't have them on their pricing lists.

I've ranted many times about both companies. PGP tries to sell you goods they admit won't solve the problems they're designed for (the "all bets are off when you lose physical control of the device" excuse). And Verisign tries to double-dip on premium "Extended Validation" SSL certs, ignoring their culpability in Certificate Authorities granting SSL certificates to frauds and phishers-- they want you to pay extra for their mistakes.

Do us all a favor and use open source or support their competitors who have true commodity prices.

RSA doesn't know Kerckhoff

I found this in RSA Security's guide for their Authentication Manager (a.k.a. RSA SecurID) application suite:

"This reference guide is meant only for security administrators and trusted personnel.
Do not make it available to the general user population."

So much for Kerckhoff's Principle from the world's leading cryptography vendor:

"[S]tated by Auguste Kerckhoffs in the 19th century: a cryptosystem should be secure even if everything about the system, except the key, is public knowledge."

Real-Time Keyloggers

I have discussed real-time keyloggers before, as a way to defeat some online banking applications, among other things, and that in general, one-time-password generator tokens offer complexity, but typically they do not add any real security.

Now, stealing one-time-passwords from RSA SecurID has made the NY Times as well. (Slashdot thread here.)

Authentication takes the back seat to malware. If you cannot guarantee a malware free end-point (and who can?), then you cannot guarantee an authenticated person on the other side of that end-point device.

Random Active Directory Quirkiness

Do you need to comply with some external regulations (think PCI) that require your Microsoft Active Directory (AD) passwords to be changed frequently, yet you have an account that, if the password is changed, you think applications may stop working?

I am obviously not encouraging anyone to use the following quirky feature of AD to be dishonest with an auditor, but it is always interesting to find "fake" security features or at least features that can be manipulated in unexpected ways.

If you check the "User must change password at next logon" box on an account in Active Directory Users & Computers, it does something very interesting under the hood-- it deletes the value of the "PwdLastSet" attribute. The "PwdLastSet" attribute is a date-time representation, but the semantic behavior of AD when that field is empty (or zeroed out) is the equivalent to the force password change check box you may have seen thousands of times before and previously believed to be stored in AD as a boolean true/false value or something similar.

The really interesting behavior occurs when you uncheck the box. BEFORE the box is checked, there was an actual date stored in the "PwdLastSet" attribute. When the box was checked and the changes applied to the account, that date in "PwdLastSet" was lost forever. So, if you uncheck the box BEFORE the user account logs on and is forced to change, then what can the AD Users & Computers tool do? It has forever forgotten the true date for when the account's password was last set. So, the AD U&C developers did what any good developer would do: improvise.

So, in the bizarre situation where the force password change box is checked, applied, then unchecked, AD Users & Computers writes the current date-time into the "PwdLastSet" attribute, which has the unintended consequence of making the account look like the password was just changed.

Happy password policy circumventing!

Banks, Malware, and More Failing Tokens

The Kaspersky folks have an interesting report on malware that targets the banking and financial markets that supports and echoes many of the things posted here over the last several months. For one, the banking industry is receiving targeted malware, which makes it more difficult for "signature" based anti-malware solutions to find the malware. For two, issues with second-factor authentication tokens don't solve the malware-in-the-browser problem.

"In order for a cyber criminal to be able to perform transactions when dynamic passwords are in place using phishing, s/he has to use a Man-in-the-Middle attack.... Setting up a MitM attack is inherently more difficult than setting up a standard phishing site; however, there are now MitM kits available, so cyber criminals can create attacks on popular banks with a minimum of effort."

Linux SSO to AD

This is a break from the traditional types of posts. It's more of an instructional howto, but I hope that it is valuable nonetheless.
...

Ah, the holy grail of Identity Management: Single Sign On. And in today's enterprise, that likely means Microsoft's Active Directory at the back end. While directions for bringing unix/linux boxes into the AD forest have been out there, they have been sticky at least, requiring random config changes to PAM, Kerberos, Samba, LDAP(S), etc.

Enter likewise-open, which is a great way to package all those up. It's a free software package that also comes with optional enterprise support, which anti-free-and-open-source companies tend to like.

Sure, there are tons of great examples out there that will tell you how to get likewise-open installed (which is a dream compared to the old days of manually configuring Kerberos, PAM, etc.). BUT, they leave you high and dry with any user in the whole domain (possibly the forest) being able to log into the computer, since they focus on "authentication" and not "authorization". Since when is that better than less passwords? They also don't properly show how to manage privileged access once logged in. So the following are some subtle configuration details and nuggets for which I have had to comb the web and anyone who really does enterprise SSO will appreciate.

This will assume you have likewise-open installed, which if you don't, on Ubuntu it's as simple as: sudo apt-get install likewise-open.

For that matter, this entire thing assumes Ubuntu, but would work elsewhere (paths may vary).

Joining to the domain is very easy, too: sudo domainjoin-cli join fully.qualified.domain.name UserID

Now, you probably want to limit who can log on to the shell to just admins. After all, it's Unix; it's not a toy. Use your favorite text editor (as root or sudo) and edit /etc/security/pam_lwidentity.conf. Uncomment this line require_membership_of and add an AD group containing those admins in the Domain\Group format.

Next you'll want to make sure those admins can use sudo otherwise you'll have a root password management problem (the whole point of SSO is to reduce the number of passwords to manage, right?). Edit the /etc/sudoers file by typing sudo visudo and add a line in this format: %DOMAIN\\Group ALL=(ALL) ALL (if you want to allow everything-- follow normal sudo permissions rules to restrict further).

Last, but not least, you'll probably want to get a psychological acceptance from administrators as a security design principle, right? In order to do that, let's get rid of that pesky Domain\UserID format and just use the UserID format. After all, who wants to type in ssh 'domain\userid'@computername when they can just type in ssh computername? This is the coup de grâce in favor of less passwords. Again, as root or sudo, edit /etc/samba/lwiauthd.conf and add winbind use default domain = yes to the end of the file. If you're in a multi-domain forest, you're up a creek (not to mention you probably have a less than simple environment anyway), and at a minimum your users in other domains will have to specify the domain\userid format. But users in the same domain can log in without the domain\ prefix.

One recipe for quick SSO to AD on Unix/Linux in a mere few minutes. Enjoy.

Breaking Cisco VPN Policy

I am surprised how often I hear an organization operate under the belief that they can really, truly can control what a remote client does under any situation. Here is today's lesson on how you can never know what computer is on the other end of the Cisco VPN tunnel or how it is behaving, thanks to more "opt-in security".


Step 1: Break the misconception that Cisco VPN concentrators authenticate which computer is on the other end of the tunnel.

Cisco VPNs authenticate people, not computers. When the connection is initiated from a client, sure the client passes a "group password" before the user specifies her credentials, but there's nothing that really restricts that group password to your organization's computers.

Consider this: any user who runs the Cisco VPN Client has to have at least read access to the VPN profile (the .pcf files stored in the Program Files --> Cisco Systems --> VPN --> Profiles folders on Windows systems). If the user has READ access, any malware unintentionally launched as that user could easily steal the contents of the file ... and the "encrypted" copy of the group password stored within it. Or, a Cisco VPN client can be downloaded from the web and the .pcf VPN profile can be imported into it. At that point, it's no longer certain that the connection is coming from one of your computers.


Step 2: Break the misconception that the client is even running the platform you expect.

So since any user has READ access to the .pcf VPN profiles, they can open up the text config file in a text editor like notepad, peruse the name-value pairs for the "enc_GroupPwd" value, copy everything after the equal sign ("="), and paste it into a Cisco VPN client password decoder script like this one. A novice, in less than a minute, can have everything she needs to not only make VPN connections from an unexpected device, but also from an unexpected platform. Not to mention the group password is not really all that secret.

Cisco VPN encrypted group passwords, like any encrypted data that an automated system (i.e. software) needs to unlock without interrogating user for a key value that only a human knows, must be stored in such a way that is readable for the software. Even though the name/value pair for group passwords in Cisco profiles is labeled as "encrypted" group password, the software needs to be able to decrypt it to use it when establishing VPN tunnels, which means the group password is also read-accessible for any reverse engineer (hence this source code in C). So it is now trivial to decode a Cisco group password. This is not an attack on crypto, this is an attack on key management coupled with a misunderstanding on how compiled programs work.

Now that a "decrypted" copy of the group password is known, the open source "vpnc" package can pretend to be the same as the commercial Cisco version. Here's how simple Ubuntu makes configuring vpnc to emulate a Cisco client:


A Cisco VPN concentrator (or any other server in a client-server relationship) cannot know for sure what the remote client's platform really is. Any changes Cisco makes to its client to differentiate a "Cisco" client by behavior from, say, a "vpnc" client, can be circumvented by doing a little reverse engineering and coding the emulation of the new behavior into the "vpnc" package. An important thing to keep present in one's mind is that compiled applications, although obscure, are not completely obfuscated beyond recognition. A binary of a program is not like a "ciphertext" in the crypto world. It has to be "plaintext" to the OS & CPU that execute it. If it was not readable, then the instructions could not be read and loaded into the CPU for execution. So, any controls based on compiled code are fruitless. Sure, there will be a window of time from when the changes are deployed in the official client to when they are emulated by a hacked client, but reverse engineering and debugging tools (such as bindiff and OllyDbg) are getting more and more sophisticated, reducing the time barrier.


Step 3: Break the misconception that you can remotely control a client's behavior.

A "client" is just that ... it's a "client". It's remote. You cannot physically touch it. Any commands you send to it have to be accepted by it before they are executed. Case in point with the Cisco VPN client is the notion that "network security" people try to perpetuate: "split-tunneling is bad, so let's disable it." Network security people don't like split tunnels or split routes because they view it as a way of bridging a remote client's local network and the organization's internal network. However, it's futile to get all worked up about it. If you trust clients to remote in, then you cannot control how they choose to route packets (though you can pretend that what I show below doesn't really exist, I guess.)


In the same Ubuntu screen shot above, there's a quick and easy way to implement split-tunnels. It's the "Only use VPN connection for these addresses" check box. Check the box and specify the IP ranges. Voila! You've got a split tunnel. Don't want to route the Internet through your company's slow network or cumbersome filters? Check the box. Want to access a local file share while connected to an app your organization refuses to web-enable? Check the box. You get the idea. This is an excellent example of how many "network security" people believe they can control a remote client, yet as you can see, the only way to continue the misconception is to ignore distributed computing principles.

Doing what I described above is certainly not "new" information-- clearly because there are now GUIs to do it (so it's obviously very mature). However, the principles are still not well known and we have vendors like Cisco continuing the notion that you can remotely control a client by upping the ante. Many organizations' network security people are considering the deployment of NAC ("network access control") with VPN. Microsoft has had an implementation of it (they call it NAP for "network access protection") for years. The problem is, it's based on this false sense of "opt-in security" just like split tunnels. Let's look at an analogy ...

Physical Security Guard: "Do you have any weapons?"
Visitor: [shoves 9mm handgun further into pants] "No, of course not."
Guard: "Are you on drugs?"
Visitor: [double-checks the dime bag hasn't fallen out of his jacket pocket] "No, I never touch the stuff."
Guard: "Do you have any ill intent?"
Visitor: [pats the "Goodbye cruel world" letter in his front pocket] "Absolutely not!"

How is that any different from this?

Server: "Are you running a platform I expect?"
Client: "Of course" (it says from the unexpected platform)
Server: "Are you patched?"
Client: "Of course" (why does that even matter if I'm on a different platform from the patches?)Server: "Are you running AV?"
Client: "Of course" (your AV doesn't even run on my platform)

The answer: it's not any different. Both are fundamentally flawed ideas.

So, to refute implementation specific objections, there are two key ways for a project, such as the vpnc project, to choose to not "opt-in" if so desired. They both involve lying to the server (VPN concentrator):

1. Take the "inspection" program the server provides the client to prove the client is "safe" and execute the inspection program in a spoofed or virtual environment. When the inspection program looks for evidence of Microsoft Windows + latest patches + AV, spoof the evidence they exist.
2. Reverse engineer the "everything is OK, let 'em on the network" message the inspection program sends the server, then don't even bother executing the inspection program, just cut to the chase and send the all-clear message by itself.

Sure, there may be some nuances that will make this slightly more difficult, such as adding some dynamic or more involved deterministic logic into the "inspection" program, but the more sophisticated the checks are, the more likely the whole process will break and generate false positives for legit users who are following the rules. The more false positives, the less likely customers will deploy the flawed technology.


...


So to recap: you cannot control a client or truly know anything about it. It's just not possible, so security practitioners should look to setting policies that include the fact that you cannot control a remote client. For a great in-depth review of all of these principles (with tons more examples), I suggest picking up a copy of Gary McGraw's and Greg Hoglund's "Exploiting Software: How to break code" book.

WiKID soft tokens

I promised Nick Owens at WiKID Systems a response and it is long overdue. Nick commented on my "soft tokens aren't tokens at all" post:

Greetings. I too have posted a response on my blog. It just points out that our software tokens use public key encryption and not a symmetric, seed-based system. This pushes the security to the initial validation/registration system where admins can make some choices about trade-offs.

Second, I submit that any device with malware on it that successfully connects to the network is bad. So you're better off saving money on tokens and spending it on anti-malware solutions, perhaps at the gateway, defense-in-depth and all.

Third, I point out that our PC tokens provide https mutual authentication, so if you are confident in your anti-malware systems, and are concerned about MITM attacks at the network, which are increasingly likely for a number of reasons, you should consider https mutual auth in your two-factor thinking.

Here's the whole thing:
On the security of software tokens for two-factor authentication
and thanks for stimulating some conversation!

Here is their whitepaper on their soft token authentication system.

Unfortunately, I would like to point out that WiKID is first and foremost vulnerable to the same sort of session stealing malware that Trojan.Silentbanker uses. It doesn't matter how strong your authentication system is when you have a large pile of untrustworthy software in between the user and the server-side application (e.g. browser, OS, third party applications, and all the malware that goes with it). I'll repeat the theme: it's time to start authenticating the transactions, not the user sessions. I went into a little of what that might look like.

Nick is aware of that, which is why he said point number two above. But here's the real problem: the web is designed for dynamic code to be pulled down side-by-side with general data, acquired from multiple sources and run in the same security/trust context. Since our browsers don't know which is information and which is instructions until runtime AND since the instructions are dynamic (meaning they may not be there for the next site visit), how is it NOT possible for malware to live in the browser? I submit that it is a wiser choice to NOT trust your clients' browsers, their input into your application, etc., than to trust that a one time password credential really did get input by the proper human on the other end of the software pile. I suggest that organizations should spend resources being able to detect and recover from security failures (out of band mechanisms come to mind-- a good old fashioned phone call to confirm that $5,000 transaction to a foreign national, perhaps?), rather than assuming the money they invested in some new one time password mechanism exempts them from any such problems.

Microsoft published a document titled "10 Immutable Laws of Security" (nevermind for now that they are neither laws, nor immutable, nor even concise) and point number one is entirely relevant: "Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore". How does javascript, a Turing Complete programming language, fall into that? If you completely disable script in your browser, most applications break. But if you allow it to run, behaviors you cannot control can run on your behalf. Taking Nick's advice, we should be spending all of your time and resources solving the code and data separation problem on the web, not implementing one time passwords (and I agree with him on that).



Second, I have a hard time calling WiKID a token-- not that it couldn't fit that definition-- it's just that it is a public key cryptography system. I never have referred to a PGP key pair as a token, nor have I heard anyone else. Likewise I don't really ever here anyone say "download this x509 token" ... instead they say "x509 certificate". Smart cards might be the saving grace example that allows me to stretch my mind around the vocabulary; generally speaking, a smart card is a physical "token" and smart card implementations can have a PKC key pair. So, I'll have to extend my personal schema, so to speak, but I guess I'll allow WiKID to fit into the "token" category (but just barely).

The x509 cert example is a great analogy, because under the hood that's basically how WiKID works. Just like an HTTPS session, it swaps public keys (which allows for the mutual authentication) and then a session key is created for challenge/response-- the readout of the "soft token" that the user places into the password form, for example.


There is one concerning issue with WiKID. It uses a relatively unknown public key encryption algorithm called NTRU. NTRU aims to run in low resource environments like mobile phones, which is undoubtedly why WiKID employs it. NTRU is also patented by NTRU Cryptosystems, INC (the patent may have some business/political ramifications similar to PGP's original IDEA algorithm). However, when choosing an encryption algorithm, it is best to use that which has withstood significant peer review. Otherwise, Kerckhoffs' Principle that we have come to know and love as "security by obscurity" will eat us alive when the first decent attack reduces our security to rubble. Googling for "NTRU cryptanalysis" returns around 3,000 hits. Googling for "RSA cryptanalysis" returns around 186,000-- two orders of magnitude higher. This is not the nail in WiKID's coffin, though, but it could be betting the company on Betamax. It is undoubtedly less popular than, say RSA or Eliptic Curve. In most aspects of life, supporting the underdog can result in a great time. Doing it in crypto, however, may not be a good idea.

Before somebody reads the above paragraph and goes in the extreme in either direction, please note my point: the workhorse of WiKID, the NTRU encryption algorithm, has an unknown security value. One could argue that RSA, likewise, has only a mostly known security value, but you decide: "mostly known" or "unknown"? There may not be any problems in NTRU and it may be perfectly safe and secure to use. Conversely it may be the worst decision ever to use it. That's what peer review helps us decide.


...
To sum up ... WiKID is cheap, open source, interesting, and ... still vulnerable to malware problems. And don't forget: you have to choose to use a less popular encryption algorithm.