Skype Leak

Skype has had its moments in security history over the past several years, like the allegations that governments of certain countries have backdoors (not substantiating or denying those here), but now it appears that if you know a Skype username, you can find out the IP address of the user.  Wow.

White Lies Affect Your Behavior

This is an interesting article about recent studies in the psychology of honesty and lies.  Turns out that it's possible for a clever person to determine lies based on predictive human behavior under certain social obligations.  In other words, the presence of the lie is leaked information, divulged by other events-- a great read for those curious of information flow theory as it implies to security.

Alex Halderman on Internet Voting

Computer Science Professor J. Alex Halderman is an upcoming academic star that we at Securology have been watching for awhile now, since some of the earliest days of all the great work put on at Princeton by Ed Felten and his Freedom to Tinker group (an excellent blog). Halderman, having completed his PhD (Bell Labs UNIX and C programming language creator Brian Kernighan was on his PhD committee!), has moved on to the University of Michigan as a member of the faculty and is continuing his excellent work at the intersection of technology and public policy, which always means security and privacy issues are in the spotlight.

Here is an excellent interview with Halderman (presumably shot at the 2012 RSA Conference) on how he and his students (legally) hacked the mock trial of Internet Voting put on by Washington D.C., and why Internet Voting should not be employed for a very long time.

In summary, there are two main reasons why Internet Voting is a horrible idea:

1. Getting the software perfectly correct is, for all intents and purposes, impossible.
2. Authenticating a voter eliminates the ability to anonymize the voter's vote (major privacy flaw).

Windows Vista Phones Home

OK. Perhaps not "phone home" in the sense that these people think, but it does in fact do it, at least on a minor scale.

A Windows Vista "feature" called Network Connectivity Status Indicator (NCSI) goes and fetches a file hosted on a Microsoft web server (a farm of servers, no doubt, once a widespread adoption is realized). It's a simple HTTP GET.

In fact, you can see for yourself. Fire up wireshark (or similar) while watching the traffic of a vista client. You'll notice a DNS query for www.msftncsi.com (Microsoft Network Connectivity Status Indicator) and you'll see the GET request for a file named ncsi.txt. Basically, if a client can fetch that file, Vista thinks the network interface has Internet access. Sounds simple, right? And of course, in true Microsoft style, disabling the feature will have negative effects on every application that calls the API that exposes whether or not that file could be fetched (think timeouts and bad coding habits).

What's interesting is the basic traffic analysis that can be performed just by watching clients fetch that file. In that HTTP GET request, the Vista client will pass the user agent string, not to mention it will initiate the TCP session from a randomly chosen high port. And of course, there's the source IP Address (which is likely behind a NAT in an enterprise). Without a degree of certainty, but with a degree of at least entertainment, one could see, say, how many Windows Vista installs existed behind a specific public IP Address. That might be interesting. Especially to somebody having a vested interest in, say, licensing compliance.

But that's not the biggest or most obvious problem. It's not necessarily the most preferred method of checking Internet "connectedness" for an enterprise. And since turning it off supposedly has negative effects (do your own Googling for that), there has to be a better way to configure this service.

And in fact there is ... Here is one option and some implementation choices: configure the service to connect to a different URL, perhaps one controlled by the enterprise in question, or perhaps just to another service. For complete irony, I'm choosing in this example to use the service of an organization that we all know (wink) to do no evil: Google.

Obviously there are going to be a few requirements about the URL you choose:
1) It has to small and lightweight, for performance reasons. You don't want 5000 machines checking for the existing of, say, an ISO CD image file every time the network interface's state changes.
2) It has to be mostly static, otherwise if the URL goes away then your clients (and apps) will think "the Internet needs rebooting".
3) It has to be a URL that is accessible from both inside of an Enterprise Network and outside at the local Starbucks. Remember, if you're an enterprise that authenticates every HTTP object request, this particular feature will run in the "LOCAL SYSTEM" security context inside of Windows, meaning that unless you grant "Domain Computers" or "Vista Computers" (the latter being a group you'd have to create) in your Active Directory forest to have Internet access, this process will fail. Yes ... it checks the NCSI even when a user has yet to log on.

Note that instead of a "ncsi.txt" file (a surprisingly small 34 bytes), I have chosen the ubiquitous "favicon.ico" URL, because it's static, it's prevalent, and because Google (a highly available service world wide) makes use of it, too, although it's a couple orders of magnitude higher at 1002 bytes (but it's ripe for caching). So, the astute readers will notice it meets the above three requirements.

Also note that the NCSI config requires a DNS server name and IP address. I'm choosing OpenDNS, since I've been so impressed with them recently (especially, in this case, their use of Anycast). It should work well for you as well.


Registry tweak.
A quick tweak to the registry is easy if it's just a handful of machines.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet]"EnableActiveProbing"=dword:00000001
"ActiveWebProbeHost"="www.google.com"
"ActiveWebProbePath"="favicon.ico"
"ActiveWebProbeContent"="OpenDNS"
"ActiveDnsProbeHost"="resolver1.opendns.com"
"ActiveDnsProbeContent"="208.67.222.222"

Group Policy ADM template.
A custom GPO that you can configure inside the Group Policy object editor to point to a URL of your own choosing. Oh, and you'll want to go through the View > Filtering options and uncheck the last box, as shown below, so that you can actually see the ADM template's setting options.



CLASS MACHINE
CATEGORY "Custom NCSI"
KEYNAME "SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet"

POLICY "EnableActiveProbing"
VALUENAME "EnableActiveProbing"
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END POLICY

POLICY "ActiveWebProbeHost"
PART "ActiveWebProbeHost" EDITTEXT
DEFAULT "www.google.com"
VALUENAME "ActiveWebProbeHost"
END PART
END POLICY

POLICY "ActiveWebProbePath"
PART "ActiveWebProbePath" EDITTEXT
VALUENAME "ActiveWebProbePath"
DEFAULT "favicon.ico"
END PART
END POLICY

POLICY "ActiveWebProbeContent"
PART "ActiveWebProbeContent" EDITTEXT
VALUENAME "ActiveWebProbeContent"
DEFAULT "OpenDNS"
END PART
END POLICY

POLICY "ActiveDnsProbeHost"
PART "ActiveDnsProbeHost" EDITTEXT
VALUENAME "ActiveDnsProbeHost"
DEFAULT "resolver1.opendns.com"
END PART
END POLICY

POLICY "ActiveDnsProbeContent"
PART "ActiveDnsProbeContent" EDITTEXT
VALUENAME "ActiveDnsProbeContent"
DEFAULT "208.67.222.222"
END PART
END POLICY

END CATEGORY



...
And of course, all of this is free for your use but without support or warranty of any kind. I am posting it here because I could not find these answers when I went looking for them.

Still More TOR

F-Secure's blog is discussing how there are more bad TOR nodes out there. I discussed awhile back how TOR's goal of anonymity is not possible. TOR ignores the rules of Trust relationships.

From F-Secure:

"Here's a node that only accepts HTTP traffic for Google and MySpace; it resides under Verizon:

AS | IP | AS Name — 19262 | 71.105.20.179 | VZGNI-TRANSIT - Verizon Internet Services Inc.

While curious and perhaps even suspicious, it isn't necessarily malicious. It could just be a Samaritan particularly concerned with anonymous searches and MySpace profiles for some reason. But there's no way to tell, so why use such a node if you don't have to?"

Or, maybe it's trying to capture credentials, like Google cookie stealing.

"But how about this one?

Now here's a node that was monitoring SSL traffic and was engaging in Man-in-the-Middle (MITM) attacks. Definitely bad.

AS | IP | CC | AS Name — 3320 | 217.233.212.114 | DE | DTAG Deutsche Telekom AG

Here's how the testing was done:

A test machine with a Web server and a real SSL certificate was configured.
A script was used to run through the current exit nodes in the directory cache.
Connections were made to the test machine.
A comparison of the certificates was made.

And the exit node at 217.233.212.114 provided a fake SSL certificate!

Now note, this was only one of about 400 plus nodes tested. But it only takes one."

TOR users: caveat.

UPDATED [11/21/2007]: Here are Heise Security's findings and there is now a Slashdot thread on the subject.

Zealots and Good Samaritans in the Case of Wikipedia

Dartmouth College researchers Denise Anthony and Sean W. Smith recently released a technical report of some very interesting research around trustworthy collaboration in an open (and even anonymous) environment: Wikipedia.

What is interesting in this research is the interdisciplinary approach between Sociology and Computer Science, analyzing the social aspects of human behavior and technical security controls within a system. Far too often are those overlapping fields ignored.

Also of interest, Wikipedia's primary security control is the ability to detect and correct security failures, not just prevent them (as so many security controls attempt to do). In an open, collaborative environment, correction is the best option. And since Wikipedia, in true wiki form, keeps every edit submitted by every user (anonymous or not), there is a wealth of information to mine regarding the patterns of (un)trustworthy input and human-scale validation systems.

The Woes of TOR

I predicted this a year or so ago (when I first heard of TOR), but as predictions go, they don't have value if they aren't published. Now there are issues in the news about how TOR doesn't provide the security that users expected.


The following is a picture from the EFF's website depicting how TOR supposedly provides anonymity for users' web browsing:


Just like perpetual motion is impossible, so is this idea of anonymity. In simplest terms, it comes down to understanding how trust works. A TOR user trusts (an action) the TOR client on her computer which trusts the TOR nodes to properly route her data without breaching confidentiality. The important little detail that is so often overlooked is that these TOR nodes are operated by ... that's right ... people. And people will ruin a security model every time, either deliberately (malice) or accidentally (ignorance). [Hanlon's Razor comes to mind: "Never attribute to malice that which can be adequately explained by stupidity."]

In the case of the embassy's pitfalls with TOR, users assumed (watch that!) that their traffic was not being monitored by the TOR network nodes, when in fact it was. This is not a pitfall of TOR's implementation, but of TOR's design. Since this is an anonymous network of nodes operated by people such that Adam does not know Eve, how can any user ever expect a trustworthy (not an action, but a state of assurance) network? Compare this to the "real world" ... would Jane expect that if she were to go to some special coffee shop and share her secrets with a total stranger that the secrets would stay safe with her? Regardless of whether Jane has that expectation, it would be prudent for you not to have that expectation yourself.

So, extrapolating upon this situation ... how long will it be until we have law enforcement regularly participating in TOR networks? The logical next step is either an arms race inside the TOR network or a total breakdown of the network altogether. Either we will see law enforcement participate and "security researchers" (terms used loosely) evaluating methods to evade untrustworthy--yet totally anonymous--TOR nodes, OR, we will see law enforcement agencies lobbying their respective governments to make TOR illegal. From where I sit, this looks like the former is the better option. And why not? After all, there are millions of ignorant people out there who will assume that total anonymity is actually possible-- actually achievable. But it's not. That's dictated by the physical laws of information security. And while they're out there using TOR, law enforcement has a new "beat to walk": the TOR networks.



Another perpetual motion attempt in InfoSec today is DRM which will be discussed in the future.