Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

ITU anti-botnet paper draft

November 30, 2007

Link here - http://www.itu.int/ITU-D/cyb/cybersecurity/docs/itu-botnet-mitigation-toolkit-background.pdf. The paper is pretty long, but the second half is a technical analysis and a good introduction to anti-botnet technologies: authenticated email, reputation systems, DNS block lists and path authentication, whois, honeypots, darknets, and user-based feedback loops.

Also talks about two interesting techniques the bad guys use, including fast-flux DNS in which the advertised website and email source quickly cycle through geographic locations (and domain names). Thus, by the time the good guys try to take out a server or domain, it’s probably too late, and won’t matter in another minute anyway. Then there’s a so-called Rock Phish style proxy, in which a large number of proxy servers are used to protect a small number of critical botnet servers.

More information on RDC sample code bugs

November 25, 2007

I recently received some welcome feedback from an astute developer regarding bugs in the sample Remote Differential Compression managed code wrapper class for MSDN online. Previous links regarding that sample are here:

http://jwsecure.com/dan/2007/07/rdc_com_registration_error.html

http://blogs.msdn.com/onoj/archive/2007/05/10/windows-vista-sample-remote-differential-compression.aspx

The developer’s comments follow:

"I’ve noted some bugs that I believe fixed the crashes on the .NET interop. On some functions that take BOOL, you used MarshalAs.U1 instead of MarshalAs.Bool. On some enums, you used pad = 4 or 8; that in fact can be set to auto (0). These settings create problems on different processor platforms (x86 to x64). After fixing those I was able to create a simple console app with RDC features. I’m still having problems with the IComparator interface returning Win32 error and HRESULT == 0, but I reckon that it might be related to my recursion logic rather than the interop code."

Comments on the latest Microsoft Security Intelligence Report

Just read an article in this month’s TechNet magazine (not yet online) regarding the latest (1st half, 2007) Microsoft Security Intelligence Report.  A link to the latter is here.

The SIR is quite interesting; I recommend that the security conscious at least scan it.  Some comments (mostly on the key findings, which are also available in a much shorter separate document at the link above) follow:

First, the observation is made that security researchers are now targeting applications more than operating systems.  From my own perspective, this is borne out by the content at hacker cons over the past year:  on the client, research is primarily focused on the browser, plus applications such as iTunes.  Mobile devices are getting attention, as are infrastructure components such as VoIP.  Hackers are also looking at social networking sites such as Facebook and MySpace, since those represent high-profile targets, and their growth outpaces their ability to stay secure.

Second item: regarding another trend, rogue security software is one of the largest areas of malware growth.  This is referring to, for example, anti-malware utilities that are actually spyware.  Very devious, and something to keep in mind.  See p. 62 in the full report.

Third: there are a couple of juicy data points regarding running the latest and greatest software versions (Windows Vista; Office 2007). For one thing, there are various references to a (normalized) decrease in the number of malware infections on Vista, relative to previous versions of the operating system. While I don’t really doubt that will be the case, what’s missing from the report are the absolute installed-base numbers. I mean, is there a broad enough data set of users running Vista that we can make meaningful trend statements about it yet? And of those people running Vista, won’t a relatively high percentage of them be early-adopters, power-users, and the security conscious?

I did, however, have a bigger concern about a related recommendation cited in the report. The counter-measures section of Vulnerability Exploit Details (p. 19) says, “new products are at less risk to publicly available exploit code than products that have a longer time in market.” While the report doesn’t come right out and say, ‘immediately upgrade to our latest stuff and you won’t get owned’, the context of that statement is still a bit dicey! For one thing, the report states (p. 28) that one possible explanation of that trend is social changes among the exploit developer community. Therefore, this data doesn’t necessarily show that newer products are more secure.

Still, I can see why IT managers would consider upgrading if the data shows a decreased threat as a result (and it’s clearly in Microsoft’s best interest to push for this). Nevertheless, major product revisions almost always introduce two things: new features that haven’t been around long enough to prove their security, and incompatibilities with previous versions. Carefully consider the tradeoffs.

Fourth: I can understand why the report differentiates between code execution exploits and Denial of Service attacks (see p. 21). The former tend to be a much bigger concern. But I find it troubling that DoS-only exploits seem to have been entirely scrubbed from their dataset. Surely Microsoft is taking responsibility for all classes of threats against its products! De-prioritization of DoS risk, in comparison to other types of threats, is much too common in the software industry right now.

Fifth, and finally, from an anti-malware perspective, the report states that more than half of all real-time protection triggers are related to attempts to download and install ActiveX components (p. 62). I knew ActiveX was bad, but I didn’t realize it still dominated, from a malware propagation perspective, to that extent. Think twice before installing any ActiveX control.

Great post: Tor anonymisation network phished

November 23, 2007

It’s like a modernized James Bond novel:  Chinese spies, man-in-the-middle attacks, and naïve hackers.  Enjoy!

http://www.heise-security.co.uk/news/99333

More on Tor Directory Servers

November 21, 2007

I mentioned in my previous post (http://jwsecure.com/dan/2007/11/learning_about_tor.html) that I’ve been digging into Tor these days, and that I have a concern about control of the directory servers.  Wanted to add a bit to that.

The purpose of a Tor directory server is to advertise the list of available and trusted onion routers, that is, the nodes via which clients may build circuits for traffic.  There could be disagreement between the directory servers on the contents of that list, due for example to network latency or outage, or perhaps due to operator disagreement (more on that later).  Tor clients handle such disagreement via a threshold scheme. 

But there’s an interesting side note regarding thresholding.  See this Tor paper (http://www.torproject.org/svn/trunk/doc/design-paper/tor-design.pdf), which I referenced in the earlier post.  As the paper observes (see page 13, left column), directory operators must agree (although actually only to a certain extent – the wording of that section is confusing) on the list of directories to be published.  Now see the top of the right column, page 10:  the number of directory servers is currently three and may grow to nine.  Thus, to obtain a majority among the total number of deployed directory servers today requires only two operators!  Remember that those operators, in turn, decide which ORs to include in the network. 

How can the network as a whole be deemed trustworthy by a broad cross-section of users if it’s controlled by so few? 

Ok. Now look at that question another way.  Indeed, an anonymizing network is most useful if it includes as many nodes as possible.  I’d want the network, once it’s attained critical mass, to be robust against collusion among a coalition of private entities and/or governments. 

To that end, suppose a modified network is proposed in which there are many more directory servers, sprinkled around the globe.  Assume each directory server operator has his or her own agenda, reflecting local biases, and may be under either private or government control.  Assuming the Tor threshold requirement still applies, will a majority of directory operators be able to agree amongst themselves who to include? 

This is the piece I find most interesting.  On one hand, there are certain characteristics of an anonymous network that seem to be requirements for keeping it anonymous.  Absence of unilateral control comes to mind.  On the other hand, for a project like Tor, some single group must facilitate and be "in charge".  Otherwise, it’s impractical to even establish what the candidate list of directory servers is, among other things.  (Although, the former could perhaps get partially solved by some sort of "primary" election by the networks users.  But the users still must be able to trust the election and its results.)

At the surface, this problem strikes me as similar to that of deciding who controls the top-level internet DNS servers (interesting introduction to that issue is here - http://www.slate.com/id/2131182/).  But there are some fundamental differences.  For one thing, the whole point of an anonymizing network is anonymity – obvious, right?  Well, in contrast, the whole point of the internet is availability.  From the perspective of the private sector, as long as the majority of people who make money on the internet can continue to do so, I don’t think they really care who controls it. 

It seems to me that controlling entities are more likely to muck with the anonymity of a (theoretically) anonymous network than they are with the basic mechanisms – i.e. those that allow it to support reliable commerce – of the internet.  Why?  Well, for one thing, loss of anonymity is likely to be harder to detect.  For another, anonymous networks are still sufficiently fringe as to be outside of common public awareness.  Thus, compromise is unlikely to be met with much outrage until the user base increases.

Learning about Tor

November 20, 2007

Just been doing some reading about Tor (http://www.torproject.org/) – an open source anonymizing network implementation.  Anonymous in the sense that, for example, the identity (IP address, platform/version info) of a browser client on one end of the network could be hidden from a web server on the other end.  That information, as well as the association between the client and the resource requested, is also theoretically hidden from eavesdroppers. 

Tor is based on “onion routing” (http://en.wikipedia.org/wiki/Onion_routing) research funded (at least partially) by the US Navy.  More on the onion metaphor below.

Check out the Tor Usenix paper (http://www.torproject.org/svn/trunk/doc/design-paper/tor-design.pdf), especially if you’re a crypto weenie like me (although that’s not a requirement for appreciating the paper).  In summary, Tor is cool because it attempts to provide anonymity via the following mechanisms:

1.       A client application-layer proxy which strips identifying information from outbound requests.
2.       A list of nodes, or Onion Routers (OR), which are available to form dynamic circuits via which traffic is routed.  As each circuit is built (for example by a client that wishes to contact a web server), the client performs a key exchange with the included nodes, which are selected more or less randomly.  Once the circuit is established, it’s relatively short lived (say, a minute), and the client wraps each request (e.g. for the page from the web server) in a message, or “cell,” successively encrypted to each node in the circuit.  The inner-most message is encrypted to the last node in the circuit and the outer-most message is encrypted to the first node in the circuit.  Think of those encrypted, or wrapped, messages as layers of an onion …
3.       A list of trusted directory servers, which provides the list of ORs.

Admittedly, I’m not doing the whole system justice with such a short description; read the paper.

There are some concerns among the security community regarding such networks.  Overall, I’ve heard two main ones:

1.       The critical mass – in terms of number of OR nodes required in order to provide reasonable, practical anonymity – exceeds the current deployment.  Too few ORs means that one compromised node is more likely to be the entry or exit node in a given circuit.  This betrays the requester in the entry case, or the resource requested (as well as all of the data, if a separate application layer security solution, such as TLS, isn’t in use) in the exit case.  For more information, in the Usenix paper, see “Run a hostile OR,” 2nd colomn, page 12.
2.       The tradeoff of providing tools for the good guys is that the bad guys use them too.  This seem argument gets used against encrypted email and pentesting tools.  For Tor, OR exit policies are claimed to be one mitigation (in the Usenix paper, see the bottom of first colomn, page 10) – in other words, OR operators can elect whether to be an exit node at all, and if so, what resources are allowed to be requested through the node. 

Actually, my biggest concern is the question of control of the directory servers.  Again, the purpose of the directory servers is to list which ORs are available and trusted.  Supposing that the servers might disagree on that list, a threshold system has been implemented (in Tor).  That is, the directory list must be digitally signed and agreed-upon across a minimum number of servers.  But caching of that list is also a supported feature, and that raises questions about key revocation (and then time-stamping, etc).

Integrating Security and the Software Development Lifecycle

November 17, 2007

Just got a more permanant link (http://www.virtualteched.com/Videos/EU_DanGriffinMichaelHoward_WB.asx) to my shorter interview with Mike Howard at TechEd/Developers/Barcelona a week or so ago.  I say "shorter" because there was a longer version, as well as one that I taped solo earlier in the week, that should be posted to the above site in the next few months.

Wanted to leave a few follow-up points to what was discussed in that interview:

I actually had a few interesting discussions in Barcelona about addressing various application lifecycle pain points via integration with Visual Studio (specifically the Team System SKU, for the most part).  These discussions took place with folks in- and outside of Microsoft.  Because of my background, my bias is toward solving the security needs faced by application developers. 

The Fuzz Testing sample I did for MSDN Magazine is indeed representative of the opportunities available for security-aware integrators and service providers right now.  In other words, if your business is in working with developers in the Windows environment, and it centers around some external tool and/or process, consider integrating it into Visual Studio.  Security testing and all that entails (static code analysis, pentesting, fuzzing, run-time analysis) is ripe for this kind of integration.  The point is - your customers already know a given interface, and its one into which Microsoft continues to make big investments, so why not ride that wave?

Here’s the thing I didn’t mention in the interview, though.  From the perspective of the industry overall, and specifically all of the lines-of-business (LOB) and ISV devs out there, security testing isn’t the real problem.  The real problem - the Big Gap - is in integrating any sort of end-to-end security development best-practices into whatever methodology is currently in use. 

Microsoft’s Security Develpment Lifecycle is a notable example is something which has tremendous value, and yet has gained very little traction among the groups I mentioned above.

The problem is twofold:  one, everybody’s process is slightly different.  And two, accomplishing that sort of process integration requires the tender loving care of someone who not only really understands security, but is willing to invest the time and energy into understanding and adapting to a team’s existing process. Okay, there’s a third reason as well, but it’s more minor:  Microsoft has neglected thus far to integrate SDL into their own commercial lifecycle tools.  Why doesn’t Team Foundation Server force me to be aware of security best practices?

So, right now, the burden for addressing this SDL Gap should be borne by the methodology and application lifecycle management consultants.  I use the term consultant in an all-encompassing way - that applies to internal as well as external methodology experts.  My point is this - if you’re training devs, project managers, or testers on Agile, have you incorporated security best practices into all phases?  If so, please let me know, because you’re a hero and I want everyone to know your name. 

CardSpace anti-phishing question from TechEd

November 12, 2007

I always enjoy working at technical conference booths when I get the opportunity to talk about security with people who are dealing with day-to-day issues on the front lines. This week at TechEd Developers in Barcelona did not disappoint! In fact, a variety of interesting topics were brought up by attendees when visiting the Security Development Lifecycle booth on the exhibition floor.

The one that most stuck in my mind was regarding phishing and CardSpace. Frankly, CardSpace marketing materials have been making some pretty bold claims about how the technology combats phishing, and one TechEd attendee was expressing some healthy skepticism. His question was regarding the use of CardSpace authentication in the context of a client browser connection over the internet. There was also a question about combating man-in-the-middle (MITM) attacks in that context, but I’m going to save that for another post.

Before reading on, I do recommend the CardSpace/MSDN link above. It’s an excellent introduction to the technology from a down-to-earth security perspective.

And before I get to my concerns, I want to emphasize that I believe that replacing passwords is the true value of CardSpace, and that it’s an important goal.

However, I disagree with that article on three points, most of which are touched upon in the “Improved User Confidence in the Identity of Web Applications” section.

First, the author seems to believe that “high-value” EV (Extended Validation) SSL certificates are an intrinsic feature of CardSpace, which they’re not. EV certs are what cause the Internet Explorer address bar to turn green, as an attempt to differentiate sites that have undergone additional vetting – the theory being that if you care enough about your reputation to shell out big bucks for an HV cert, you’re not a phisher. However, those two technologies – CardSpace and EV certs – are independent of each other. I can easily deploy EV certs without CardSpace and vice-versa.

EV is certainly an anti-phishing technology; I’m debating its efficacy. As an introduction, a sample scenario is this: a user gets a phishing email with a link they click on telling them that their bank needs some piece of data from them. The user clicks, taking him to a site that looks exactly like his real bank, except that it’s not. But he doesn’t notice that, so he types in his password anyway. Then the fake site simply redirects him to the real bank site, storing the captured password for subsequent use.

EV attempts to combat that problem by turning the address bar green when the user surfs to a site considered to be of high integrity (which, in the above example, the first one wouldn’t be). I’m just not convinced how effective it is. For one thing, how many users notice things like the fact that the address bar isn’t green? I mean, the address bar is almost never green, and now regular users are supposed to notice that? For another thing, it’s not clear to me how many online entities are going to pay big bucks for an EV server cert. For example, my business’s bank, which is about the farthest thing from small, doesn’t currently use one.

As an aside, some phishing sites are lazy enough to avoid getting even a basic valid SSL cert. In those cases, IE7 turns the address bar red and re-confirms before rendering the page. All goodness. But a slightly less lazy attacker will get a valid server cert and matching site name (e.g. one closely resembling that of your bank).

So I definitely would push any major deployment of CardSpace to also use EV certs. But the added expense of the latter means that the former will often be deployed without it.

Second, regarding my concerns about the above article, CardSpace introduces a mandatory user dialog prompt each time a new “relying partner” is encountered. See Figure 6 on that page. What does that mean? Basically, every time that user encounters a new CardSpace server identity, he’s going to be prompted to ensure that he believes that server is who it says it is.

I come from the school of thought that requiring users to make this kind of security decision is a losing proposition. I mean, if we assume based on the previous argument that the phishing site has acquired a valid (non-EV) SSL cert from a trusted provider, then that’s what the “relying partner” prompt is going to say: “Here’s the server identity. It’s valid, but it’s not EV. What do you want to do?” And what are users going to do? I think they’ll click, “Let’s party.” So the actual anti-phishing value of that prompting is debatable.

Third, and finally, I miss the days when technical documentation was really boring and factual and didn’t include any marketing or hype. Especially when you’re talking about a security feature, and the issues involved are subtle.

Video of Michael Howard and I discussing security stuff at TechEd

November 9, 2007

New Software + Services Blueprints announced at the TechEd Keynote today

November 5, 2007

The link is here - http://channel9.msdn.com/wiki/default.aspx/Channel9.SoftwarePlusServicesBlueprints.  Why the buzz?  Well, Office integration (Visual Studio Tools for Office) has traditionally been a pretty frustrating experience for ISVs.  Not impossible certainly, but not exactly easy either, especially since the goal is almost always to extend the user interface in a way that looks seamless with the base product (ever tried to recreate a UI like Outlook?).  The purpose of the "Blueprints" is to provide complementary sample code, best practices, and documentation wrapped up into a single package to help developers do just that.  Very cool.

Search:

Archives

Recent Posts

• The NAP partner ecosystem grows
• SharePoint security deployment checklist
• Wanna sing the blues?
• See you at CONFidence next week!
• Housing/credit crisis - explained

RSS Feed

Blogroll

Security Focus: