HD DVD / Randomness... : Security

Updating Firefox as non-admin

ptorr — Sat, 15 Apr 2006 02:35:56 GMT

Firefox , like all web browsers, needs to be regularly updated to keep up with security patches. Version 1.5 has an auto-update feature built-in, but unfortunately if you're not running as a local Administrator (at least in Windows), it doesn't work.

In one way, this is no different than Windows Update; if you go to the WU site as a non-admin, you get a message telling you to try again as an admin. The difference though is that whilst Tools -> Windows Update still works in IE if you are a non-admin (it politely asks you to try again with admin privileges), Firefox will grey out the Help -> Check for Updates menu item in this case. The inability to check for updates may lead a user to believe there are no updates available for their machine, which is clearly a bad thing because they will remain vulnerable to attacks. So, if you are using Firefox and you are not an Administrator, make sure to manually check for updates (or to boot Firefox as admin from time to time) in order to stay protected.

Something else to be wary of is that using the built-in update feature of Firefox will prompt you to re-start the browser so that it can finish updating itself. Unfortunately, if your next boot of the browser is as a non-admin, the browser will not be updated, but you won't be notified that it hasn't been updated, either. You must boot again as an Administrator for the update to take place.

Of course, personally I recommend people upgrade to Internet Explorer 7 Beta 2, but that's just me :-). Also note that at the time of writing, IE 7 is still an unsupported beta -- not production code -- so you should not install on mission-critical machines and read the release notes first.

Note 1: Obviously if you have installed software as an Administrator and placed it in the Program Files directory, a non-admin user will not have permissions to update the files. But that's not a problem; the problem is that non-admin users are given the impression that updates are not available (or perhaps not needed), leaving them with a false sense of security.

Note 2: Automatic Updates will still keep IE up-to-date for you even if you are not logged in as a local Administrator, so you should be sure to turn it on.

When facts get in the way of a good argument

ptorr — Sat, 08 Apr 2006 06:26:24 GMT

I've wanted to write this blog for a long time, but never gotten around to it. It's a very simple observation, but one that too many people fail to make. Maybe something will come of it :-)

Oftentimes you will see something like the following on a web news site:

Headline: New security bug found in Windows

Poster A: Windows sucks!

Poster B: Windows is attacked more often because it has the highest market share

Poster C: If that were true, Apache would be attacked more often than IIS

Of course, C's unstated-but-obvious assumption is that Apache is not attacked more often than IIS, even though it has a higher market share.

If C is right, he has disproved B's assumed premise about market share based on a valid form of argument known as modus to l lens -- P implies Q, but Q is false, therefore P must be false.

The trouble though is that C is actually enforcing B's argument, since Apache is attacked far more often than IIS. Of course, C hasn't proved B's argument, he just hasn't disproved it either. (To assume that C had proved B's argument would be a logical fallacy known as affirming the consequent -- P implies Q, and Q is true, therefore P is true).

Note: For the purposes of this entry, I have ignored two things because they are not relevant to the discussion: The first is the debate about what web server market share numbers actually mean, the second is the question of why the sites were attacked (software bugs, 3rd party installs, poor administration, etc.). I merely wanted to show that C does not disprove B, not that B is necessarily correct.

Why not use hashes for the Anti-Phishing Filter?

ptorr — Tue, 13 Sep 2005 05:50:00 GMT

Several people have asked why Internet Explorer 7 will send "real" URLs instead of hashes to the AP (Anti-Phishing) server. That's a good question, and I know it's a good question because it's the same thing just about everybody at Microsoft (including me) says the first time they hear about the feature :-). Nevertheless, a fairly quick investigation into the issue shows that it buys very little in terms of privacy but comes at significant cost.

First we need to figure out what threats are mitigated by sending hashes instead of URLs. Next we need to figure out what additional threats surface if we send hashes instead of URLs. Finally we determine which is "better" using some subjective measurement.

There are two main threats that hashes would mitigate:

1) Attacker sniffs data travelling to the AP server over the internet and records a list of all URLs that a particular person is visiting, using the list for further phishing attacks, user profiling, stalking, sale to a marketing company, etc.

2) Attacker gains unauthorised access to client data once it reaches the AP server and uses it for similar actions as #1

Threat #1 is trivially mitigated by using SSL, and since the AP filter already does this nobody can sniff the traffic in transit. So hashes are not needed to mitigate threat #1.

Threat #2 is more interesting. I will start by assuming that Microsoft itself is not malicious and Microsoft's policies forbid unauthorised use of the AP filter data. You may choose to assume the opposite (ie, you might believe that Microsoft fully intends to use the AP data for profiling or marketing purposes), but in that case you should turn off the feature altogether. Sending hashes won't protect at all against a system intentionally designed to mine the data (we'll talk about why in a second).

Threat #2 boils down to an "insider" at Microsoft deliberately going against corporate policy to mine the data, or a malicious outsider gaining access to the server and doing the same, or some accidental disclosure of the information via recycling hard-drives that haven't been wiped, leaving print-outs in the garbage, etc. These things can (and do) happen, so it's not an unrealistic thing to be concerned about.

But what do hashes buy us? At first blush, they seem to buy us a lot. Now, instead of a list that says "User 12345 visited sites www.microsoft.com, www.slashdot.org, and www.apple.com" they now get a list that says something like "User 12345 visited sites A538E10D, 83B1E7C9, and 746C2B9A". Great! The bad guys don't know where I've been.

Or do they?

First things first: if Microsoft really was trying to track you then the server would simply have a database matching hashes-to-URLs, so it would be trivial to reverse every known hash back into its corresponding URL. That's why I said above that if you really believed we were going to be naughty then you should just turn off the feature.

The next thing to think about is what the attackers really want to know. Do they want a laundry-list of the hundred arbitrary web sites you visited last week, or do they just want to know if you visited a specific site such as www.citibank.com or www.their-competitor.com? In this case, the attacker can do the trivial reverse-match themselves, since they will have a database of URLs they care about along with the corresponding hashes.

At this point you may be asking yourself questions such as "I thought hashes were 1-way?" or "Can't you embed some kind of salt in the hash to make it irreversible?" or some other such questions. None of that helps. For the first objection, yes, hashes are 1-way but the same source text always hashes to the same value, so you can do reverse lookups if you know all the possible source texts and can pre-compute their hashes.

For the second objection, it just won't work. Imagine that each client request was hashed with a unique GUID so nobody could pre-compute the hash. Now how is the server-side filter going to work, since it has nothing to match the hash against (remember the whole point of AP is to match client requests with known-bad URLs and block them)? Even if you pass the GUID along with the hash in the request, the server would have to go and re-hash every known URL with the GUID on each request, which would be prohibitively expensive (and thus still require a database of all known URLs in plain text on the server... resulting in additional threats to the system). And obviously there can't be a "shared secret" hash that Microsoft adds on both the client and the server since the bad guys would simply reverse-engineer the "secret" out of the Internet Explorer binaries.

So the only thing that hashing really buys us is that it forces the attackers to keep their own database for matching URLs to hashes for reverse-lookup. Not much of a benefit if you ask me, especially since an enterprising businessperson could easily build and maintain such a database and sell it as a "legitimate" web service :-)

Now let's look at what new threats arise if we only send hashes to the server. Because hashes are 1-way functions (as noted above) there is no way to introspect on the hash to figure out what the original source text was (the only recourse being the known-source-text database lookup as noted above). Attackers can use this to their advantage:

1) Attacker appends random characters to their URL, resulting in unique hashes that are not in the AP database and thus bypassing the feature

In this attack, let's say that the AP server knows that www.evil.com/evil.htm is a known phishing page. It has a specific hash which is stored in the AP database. Now the attacker can simply send out e-mails such as www.evil.com/evil.htm.AAA to generate a completely different hash that is not in the database yet still sends the browser to the same page. (Of course they could also just rename evil.htm to evil2.htm, or use server-side 404 processing to respond to any random sequence of characters, etc.). Clearly a single hash for the entire URL is not good enough.

OK, so what about if we send separate hashes for the domain and the path, and now say "Anything from www.evil.com [with specific hash] is bad" and ignore the path portion. Well, now we have a different threat:

2) Attacker uses wildcard DNS to generate random host names, resulting in same outcome as above

In this attack, the attacker simply generates unique domain names like foo1.evil.com, foo2.evil.com, foo3.evil.com, and so on. They all point to the same server, but will hash to different values so again they will not appear in the AP database. OK, next solution is to hash each portion of the URL individually ("com", "evil", "foo1", etc.) and send all the hashes to the server. Just as with the path problem above, the server could have a rule such as "If you have 'evil' and 'com' as the top-level domain then ignore the subdomains and return it as a bad site." We still have a threat though:

3) Attacker hosts phishing site on a hosting server (such as www.geocities.com) and uses same URL obfuscation technique as above to avoid AP server

Using a hosting site means that the detection can't be based off the broken-up domain names, and can't be based on a hash of the entire path either. Instead, we have to perform the same break-up operation that was used for domains and split the entire path into its components (so, for example, in the URL www.my-hosting-company.com/path/to/phisher/evil.htm we would send seven distinct hashes for each of the following: "www", "my-hosting-company", "com", "path", "to", "phisher", and "evil.htm"). Now the server has to have rules that say "If you get the domain hashes for 'www', 'my-hosting-company' and 'com' and you get the path hashes for 'path', 'to', and 'phisher' in that order then return it as a bad site."

Now, not only are we sending orders of magnitude more data to the server (all those hashes are much bigger than the original source text) and increasing server-side processing dramatically, we still haven't solved the problem:

4) Attacker uses non-path-based resource identification, resulting in same outcome as above

An example of such identification can be found on this very web server, which will take a URL such as http://blogs.msdn.com/452453.aspx (note there is no path component) yet it still sends you to content that I control living under the /ptorr/ directory. (In this specific case, MSDN sends a re-direct which results in a navigation to the full URL including the path, but there is no reason why that has to be the case). Couple this with arbitrary query-string processing, custom server-based path parsers, URL re-writers, etc. and there's really no way to figure out where the content is going when all you have is an opaque hash. Fundamentally, you need to see the original source text of the URL to effectively mitigate these kinds of attacks on the server.

So is hashing really worth it? On the plus side, you put a trivial extra burden on the attackers who want to invade your privacy (they now need to maintain a URL-to-hash database for reverse lookups), and on the down side you significantly increase both the amount of data sent to the server and the time to process a request, and you introduce by-design loopholes for the attackers who want to phish you to bypass the feature. I'll let you decide which you think is the better approach...

It is important to note that I have only talked about the threats involved in both choices here; I have not touched on any potential benefits of sending the raw URLs (that's beyond the scope of this blog entry).

Also, I want to briefly touch on the query-string question -- why doesn't IE send the query string to the AP server along with the full URL? Won't the attackers simply use query strings to decide whether to respond with the real phishing page (for the people who click on the e-mail links including the query-string) or a "legitimate" page for the people processing request at the AP server (who click on links without the query-string)?

Just like hashes, this doesn't really help (and in fact makes things worse). If the attackers are going to dynamically return a "good" or "bad" page depending on whether it has a query-string or not, they can also do so depending on whether that particular query string has been visited before! The server processing is like this:

1) If no query string, return "legitimate" page

2) If query string exists but is not in database of valid query strings, return "404" page

3) If query string is in database of valid query strings, remove it from database and return phishing page

Now when the victim visits the site by clicking on an e-mail message, they send the query string victim=12345 and condition 3 is satisfied so the user gets the phishing page. They report it to the AP server (including the query string) and soon afterwards a URL researcher at Microsoft goes to visit the site to see if it really is a phishing site. But because victim=12345 has already been visited they satisfy condition 2 and they get the 404 page fooling them into thinking the site has already been taken down. So query strings don't really work. You could also do some trickery with cookies to ensure that the first victim always saw the phishing page even on subsequent visits, whilst the researcher always saw 404s.

Query strings also make things theoretically worse, because they are the most likely portion of the URL to contain personally-identifiable information (username, tracking GUID, etc.). So if there was ever a breach of security at the AP server then not only would the attacker know all the websites you visited, they might also know your username and / or password to each of them as well!

But do not fear! User feedback is not the only way that the AP researchers will get new entries to put into the database -- they get the very same phishing e-mails that you and I get, so they will still be able to detect the phishing sites even without IE sending the data and even if the phishing server employs the fancy query-string detection logic.

Blindly trusting detection tools

ptorr — Wed, 17 Aug 2005 09:02:11 GMT

Imagine I have a house cleaner that comes in once a week to clean the house. After a while I start to notice that my house smells "fishy", but my house cleaner has just the ticket -- the all-new FishBeGone (TM) cleaner & fragrance that gets rid of fishy smells for up to seven days at a stretch! Sign me up, this fish smell is unbearable!

After a while I hear a rumour that FishBeGone is actually paying house cleaners to store rotten fish in their customer's houses, thus driving demand for the cleaner and ensuring high profits. I also hear that the most common place that the rotten fish is stored is under the central heating unit, thus providing ideal environmental conditions for dispersing the delicious, summery smell of hot rotting fish throughout the house.

Aghast that such a thing could happen, I quickly run out and buy a FishBeGoneBeGone product that consists of a video camera and fish-smell detection unit. I install it in my laundry (where the central heating unit is) and sure enough, on the next visit from my cleaner I notice that he adds some more rotting fish to the ever-growing pile. I confront him with the evidence, fire him, and get the laundry completely cleaned up. So far, so good!

Now, I still need a house cleaner so I decide to contract one from a completely different agency -- one that has no known affiliation with FishBeGone whatsoever. And just to be sure, I keep the FishBeGoneBeGone system up and running for a few weeks but it never detects my new cleaner putting dead fish in my laundry.

Fantastic!

But after a few weeks, I start to detect that oh-so-sweet smell of rotting fish carcasses, and sure enough my new cleaner recommends that I purchase FishBeGone to get rid of the smell. Worried that maybe this new agency wasn't so up-front as I first thought, I fire up the trusty FishBeGoneBeGone system for a few weeks and check the records, but they're all totally clean.

Maybe I just have a "fishy smell" problem in my house after all?

Or maybe the new cleaning lady was just putting the rotting fish under my bed instead.

What is Microsoft doing for security?

ptorr — Wed, 17 Aug 2005 08:29:00 GMT

A recent comment on the IE Blog made it pretty apparent that not everybody is aware of Microsoft's efforts around security. Michael Howard has mentioned the Security Developme n t Lifecyle before, but in case you don't want to read the entire document on MSDN, here's a quick introduction on the basics of what happens:

Training

People need to be trained about security issues before they can effectively design, write, test, or document a software product. I am sure that some readers might chuckle to themselves here and make a snide remark about how "Everybody should know about buffer over-runs (BOs) by now!" but there are two things I want to say about that:

1) It's better to incorrectly assume your employees do not know about BOs and waste a few hours training them on it than it is to incorrectly assume they do know about BOs and have them write insecure code.

2) If you think BOs are the only kinds of security issues to be concerned about, you have a lot of learning ahead of you, young reader.

Training covers such things as poor use of cryptographic functions (or use of known-weak cryptographic functions), SQL injection, cross-site scripting (XSS), integer overflows, etc. and that's just the "basics" that everyone attends. Then we have advanced courses on topics such as fuzzing, threat modelling, and mitigation techniques that people can choose to "specialise" in.

Designing

Once you know about security issues and the kinds of threats that are "out there", you need to build secure architectures and use existing technology in a secure fashion to avoid introducing design-level flaws in your software. We do this by having high-level design reviews with subject matter experts (SMEs) for larger, riskier features; and by performing an in-depth threat modelling process (it's not just a threat model document!) for pretty much every component. (Clearly there is very little value to threat modelling the "Bold" toolbar button in Microsoft Word, so some things get by without a complete TM :-) ).

This is where I personally spend most of my time -- being an SME for technologies such as Internet Explorer hosting, ActiveX controls, managed code security, and so forth. I participate in a lot of design reviews for products all over Microsoft (pretty much everyone does something with a web browser these days :-) ) and in particular I spend a significant amount of time with the IE team doing threat analysis on features and making sure we've got all our bases covered with respect to security.

Building

We have well-trained architects, well-trained program managers, well-trained developers, well-trained testers, and some great analysis tools to help us avoid, detect, and remove common code-level security flaws such as BOs or the use of "bad" (hard-to-use-correctly) APIs. We also do code reviews, threat-model-driven testing, and perform other activities to prevent (or remove) security defects from the code before it is released to customers (or in some cases, before it is ever checked in). Run-time analysis tools such as AppVerifier also help to catch potentially "bad" API usage or point out least-privilege violations (for example, asking for KEY_ALL_ACCESS when you only need KEY _READ).

One little-know fact is that Microsoft has done a lot of work to help deprecate the "bad" APIs commonly found in C and C++ runtimes and to replace them with less "dangerous" versions that can help prevent certain classes of bugs. For example, there is the "Safe String" library in Windows that is used both internally and externally to replace unbounded string copies (eg, strcpy) with bounded copies (StringCchCopy). What's more, the Visual C++ team has new "security enhanced" versions of many common CRT functions, and Microsoft is working to make these new functions a part of the ANSI C standard.

Microsoft innovating in security and working with standards bodies and sharing technology with the world? Who would have thunk it? :-)

You can read more about the new libraries in MSDN Magazine.

Releasing

After we have designed, built, tested, documented, etc. the product, it gets released to customers. We try very hard to strike a balance between usability and security with our products -- the "Secure by Default" mantra -- and it's often a very hard thing to do. How do you make your product usable enough so that most customers can do what they want without getting frustrated or calling Product Support Services, yet still keep the less-used or higher-risk features turned off if they are not needed? IIS 6 in Windows 2003 was clearly a big step in one direction, and it's payed off big-ti m e. But such an approach wouldn't work with, say, MS N Messenger where it's pretty clear that if you install the product you need it to talk on the network and receive messages from your buddies.

Despite all our hard work, security issues are still found in released products and this is where the Microsoft Security Response Centre (MSRC) comes in. The MSRC team is dedicated to receiving and investigating reports of security issues in Microsoft products, and then working with product teams to find, fix, and release patches for them on our now-famous "Patch Tuesday". Patching on a predictable basis is something that Microsoft did because customers requested it, and whilst initially Microsoft got a lot of heat for "trying to make it look like we had fewer issues", many in the industry have come to realise that it's "the right thing to do" and at least one analyst expects others to follow suit (eventually).

So that's it, in a nutshell. We've said for a long time that "Security is an Industry Problem" and I would love it if every vendor took a long, hard look at their development process and adopted something similar to the SDL. There will always be customers who choose not to run Microsoft software, but we still want them to be as secure as possible on their platform of choice.

I did a brief search on Apache's official site, and they ask that patches have performance optimisations but there is no mention of having a security review or any minimum standards for security. That's not to say people aren't performing security reviews of Apache, but the "many eyes" don't help if they're (i) not looking at the important bits or (ii) don't know what to look for.

Microsoft has a publicly-documented process for designing, building, releasing, and supporting software "that needs to withstand malicious attack," and although software will always have bugs we're definitely showing improvements.

Does your software vendor of choice have such a process? Or only rhetoric?

HELLO? CAN YOU HEAR ME?!?

ptorr — Thu, 11 Aug 2005 06:58:00 GMT

As most of my friends know, I'm a pretty jumpy person. And, of course, most of those same friends like to exploit that fact for their own amusement from time to time (thanks to J e f f for almost running me over the other day). The fact that I lose 5 years of my life every time one of my friends wants a cheap laugh probably speaks more to my choice of friends than anything else, but I digress.

Today the fire alarm went off in our building. Now I lived through many fire alarms back in the Visual Studio building , but it was never this bad.

OH MY GAWD ARE THOSE THINGS LOUD!!!

I was walking down the hallway when the alarms went off. Additionally, because some people are hearing impaired (if not before the drill, then perhaps after it) there are bright flashing lights to provide a visual cue that something is wrong.

Unfortunately, I happened to be standing directly underneath one of the speakers and right next to one of the flashing lights when the alarm went off. Of course, I did what any rational human being would do when unexpectedly assaulted with blindingly bright lights flashing in their eyes and deafeningly loud sirens blasting in their ears.

I yelled "Ahhhh !@%&" at the top of my voice.

In hindsight, that probably wasn't the most dignified thing to have done. But at least it provided some amusement for my fellow corridor-dwellers...

To make this mildly work-related, here are two thoughts:

1) If you have a disaster recovery plan (DRP) or emergency response plan (ERP) in place then it's a good thing to test it once in a while. Better to inconvenience a few people at a time when you can afford it than to realise your plan is busted when you can't afford it.

2) If you don't have a DRP or ERP in place, whatcha gonna do when they come for you?

IE Blog

ptorr — Fri, 05 Aug 2005 10:21:21 GMT

For those of you who haven't already heard, the IE team has a blog and recently they've started to talk about some of the cool features to be found in IE 7 Beta 1 (or planned for RTM).

I've been working pretty closely with the IE team for some time now, but the nature of this job is such that if all goes well then you'll never hear about any of the work we've been doing together.

Rob & Co. will definitely be talking about some of the new features such as Protected Mode and the Anti-Phishing Filter, but remember that Security Features != Secure Features (or for the VB folks: Security Features <> Secure Features :-) ).

I hope to one day be able to share some of the work we have done behind-the-scenes, but now is not the time.

The Evil Problem

ptorr — Fri, 05 Aug 2005 10:08:31 GMT

Over on the IE Blog, a commenter made a very good point -- why is it that IE flags scripts as “potentially bad”? That’s very confusing to the average user, and they have no way of knowing whether or not the script really is bad or not (and therefore whether they should enable it or not).

Unfortunately, this is much harder to do than it sounds -- even for humans (let alone computers). If I told you about a program that deleted all the data off your hard disk, would you say that it was a “good” or a “bad” program? What if I told you the program was named “format.exe” and its only purpose in life was to wipe disks of all their data?

So it’s not easy :-(

By default, IE limits the capability of scripts running from internet web pages because it is highly unlikely that anyone trying to format your disk across the internet has good intentions. Nevertheless, if IE is asked to load a page from the local hard-drive, it might be the case that (eg) you have an HTML-based administration console for a locally-installed application, and you really do need to format a hard drive or perform some other potentially-dangerous operation. So in this case, instead of just outright blocking access to that functionality, IE disables it by default and uses the Information Bar (aka the "gold bar") to inform the user that if they want to run the script they can do so.

The idea here being that if the gold bar was unexpected, the user could simply ignore the notification / close the browser / navigate to another page / etc. and still be protected, but if the user was expecting "potentially bad things" to happen then they could click through the gold bar and still have access to the rich functionality of the administration application.

I entitled this post "The Evil Problem" because it's similar to "The Halting Problem", which is a famous problem in computer science that says it's not possible to algorithmically determine whether or not a particular program will halt (stop). The reason this is so is because if you assume such an algorithm exists, you write a program thusly:

while (DoesHaltingAlgorithmSayIWillHalt())

; // do nothing

Now if the algorithm says you will halt, you just loop forever (thus never halting). On the other hand, if the algorithm says you will never halt, you halt immediately. By this we see that such an algorithm can't exist. This mode of argument is called The Null Hypothesis and you could apply it to evil scripts thusly:

if (true == DoesEvilAlgorithmSayIAmEvil())

; // do nothing

else

DoSomethingEvil();

Malicious vs Spoofed Servers

ptorr — Sun, 24 Jul 2005 22:20:54 GMT

Curious Caroline writes:

Dear Peter ,

I have a friend who was talking to a security tester the other day, and apparently the tester said that having a "malicious server" is different than having a "spoofed" server. How is that so? My friend would really like to know, so I told her I'd ask you.

Yours,

Caroline

Dear Caroline,

Your friend has a good question.

The two terms are actually orthogonal -- you could have a spoofed-but-non-malicious server, a non-spoofed-but-malicious-server, and either of the other two combinations as well. When going through the threat modelling process, we're always on the lookout for both malicious entities and spoofed entities, and the difference between the two is really the kind of threat they possess (and thus the kind of mitigation we use to prevent it).

Spoofing threats occur when the server (or other entity) you are talking to is not the one you think you are talking to, and you have no way of verifying that this has occurred. For example, you think you have made a connection to www.amazon.com and are about to send over all your credit card details, but in reality you have connected to www.evil.com and it is about to steal all your information. Note that a spoof could be non-malicious and / or non-intentional. For example, imagine your Proxy server gets confused and when you try to visit www.microsoft.com in your web browser you actually get the content from www.google.com instead. The spoof here was unintentional and the "wrong" server (Google in this case) is not malicious at all. It's just a bit annoying.

Note also that there are spoofs against the software and spoofs against the user. If the DNS records for a particular server are wrong (for example), the software will be confused -- it asked for the IP address of www.microsoft.com, it received a IP address back from the DNS server, and it went to exactly that IP address. The software "believes" it is at the right place, even though it may be the real IP address of www.google.com.

Spoofs against the user are something we see a lot of these days with phishing attacks and the like. In this case, the browser asks for the IP address of www.evil.com, it gets the IP address, it goes there, and as far as the software is concerned you really are at www.evil.com. Trouble is that the content on www.evil.com is made to look just like www.citibank.com so the user is fooled into typing in their credentials. Sometimes browser bugs are used in this situation too -- address bar spoofs can be used to make the user think they are really at www.citibank.com even if they check the address bar, even though the browser still "knows" you are on www.evil.com

Of course, the best known way to mitigate all of these spoofing threats is to use a secure (SSL) connection. As long as you request a secure connection (and, in the case of the human spoofs, the user confirms that the certificate is issued to the intended company) then you will only be able to connect to the real server. A spoofed server (whether intentional or accidental) will not have the correct certificates needed to establish the secure connection. Of course SSL is more expensive than unsecured HTTP (in terms of network connection setup time, etc) so typically people only use it for high-value traffic, but realistically all traffic is high-value to someone. For example, imagine if someone spoofed blogs.ms d n.com and posted an entry by "Peter Torr" that said "You should turn your Internet Explorer security settings down to 'Low' for all zones!" Now anyone who read that sentence by "Peter Torr" would either (i) think I was a complete moron, or (ii) start using the internet in an insecure fashion based on some really bad "expert advice".

Enough about spoofing. A malicious server is just a server that wants to compromise your software in some fashion. It could be a spoofed server but it could be the "real" server that you intend to talk to; doesn't matter. For example, imagine that instead of spoofing your internal database server, a bad actually takes over the machine and installs his own hacked code on it. Or, if your application supports some kind of file-type or shortcut that can be e-mailed around, imagine someone evil convinces you to open a shortcut that points directly to her malicious server. Now SSL won't help you at all, because all your clients really are connecting to the "right" database server, it's just that the server is no longer trustworthy and could be spewing out all sorts of junk.

You can't get away from malicious servers just by using SSL. No, to protect against malicious servers you actually have to write secure software :-). And although malicious servers can represent all the typical STRIDE threats against your software, I would focus most on the remote servers trying to DoS or EoP the client machines (eg, go from owning a single database server to owning all the client machines in the network). I say this because you are unlikely to be able to protect against information disclosure or tampering threats when faced with an un-spoofed-but-malicious server. (You really are connecting to the database server, and it really does go over SSL, but once you've sent your sensitive data to the server you have no control over what it does with it next. Similarly, if you query it for some data and it returns a result that is within reasonable limits of what you expect back, you have no way of knowing whether the data is correct or if it has been spoofed / tampered with by the malicious server).

So to mitigate against malicious server scenarios, you need to ensure that your client code is rock-solid against malformed inputs sent from the server. Never assume the packets coming in are the right size, or that the internal structures are filled out correctly, or that the buffer lengths in the header match the real size of the payload, etc. In fact, never assume the data will arrive at all -- always have a reasonable timeout to detect misbehaving servers (or just bad network connectivity) so your client doesn't hang indefinitely.

Once you've validated that the packets are well-formed and syntactically correct, it's still not necessarily a good idea to blindly take action based on the information inside them. Is the data in the packet within a reasonable set of limits? Given the current state of the client, is the request a reasonable one to service? Does the data you got back make any sense at all? etc. And remember as you do this that "lists of known-good behaviour" (allow-lists) are much better than "lists of known-bad behaviour" (block-lists) because, well, you don't really know what all the bad behaviours are, so you are likely to miss some of them.

Although there's little else you can do to protect against "0wned" servers, you can do some other small things to help mitigate the attacker-fooled-you-into-connecting-to-the-wrong-server threat. For example, you could publish a list of "known good" servers in Active Directory and before connecting to any machines the client could ensure the server was on that list. Now if a bad guy tries top set up his desktop machine as a malicious server, he isn't going to get very far unless he can also get it listed in AD (which should be really hard to do!). You could also ask the user to confirm each server the first time they connect to it, in an attempt to catch unexpected server names.

And a bonus point: Remember that you always have the man-in-the-middle (MITM) threat unless your connections are suitably encrypted and digitally signed. Even then, sometimes the mere fact that Client A is talking to Server B is "interesting" to an attacker, but that's usually only for highly sensitive things like military operations. For most situations, you don't need to worry about that :-)

Adding URLs to an application securely

ptorr — Mon, 18 Jul 2005 01:10:13 GMT

An Anonymous Reader writes:

Dear Peter,

I am writing a desktop application that contains links to external websites inside the "Help" menu, as is common with many applications such as Internet Explorer and Microsoft Office. I want to make this list dynamic so that I can update it with cool new content over time. I want to do this by downloading a small XML file from my web server containing the text of the menu item and the URL to go to. How can I make sure that hackers don't insert a menu item to www.evil.com and exploit my customers?

Yours,

Anonymous Reader

Dear Anonymous,

I'm glad you asked that question. There are three main ways you can help prevent hackers from inserting menu items to www.evil.com in your situation. They are:

1) Download your XML file over an SSL connection. As long as you are connecting to https://www.example.com/ and verifying that the connection is secure, an attacker won't be able to tamper with the XML file in-transit to the user's computer. This doesn't help if an attacker compromises your web server though, as they could still insert malicious content to be "securely downloaded" to the client.

2) Sign the contents of your XML file and verify the signature on the user's computer. As long as the signature verifies correctly, you can be sure that no-one has tampered with the file either in transit or by compromising your web server (assuming you keep the private key physically separated from your web server). Note that it isn't sufficient to simply check that the file has a valid signature; you also need to check that it is signed by the correct publisher (ie, you!) and chains to the correct root. Otherwise the bad guys could just sign it with their own key-pair. You should also use an increasing version number in your digital signature's description so that you can detect attempts to "re-play" old, signed files.

3) Change the design to have less attack surface (risk). You don't actually need to send URLs to the client in the first place -- you only need to be able to uniquely identify the menu item that the user clicked on. A "safer" way to do this is to store all the URLs in a database on your server and assign each one a unique ID. This ID is sent to the desktop application along with the menu item text inside the XML file. When the user clicks on the menu item you simply construct a URL such as http://www.example.com/menu-redirector.aspx?id=ID_GOES_HERE and the server determines which URL to go to and does a redirect. This means the server is always in control of which URLs the client can be navigated to, and it can easily filter out invalid content. Even if an attacker compromises the XML file on the server (or in transit) the worst they can do is redirect your users to an un-intended (but still "good") site. Note that you should not build a redirect page that takes an arbitrary URL, as this can be abused in cross-domain attacks. Always build your redirect pages to take an opaque identifier that then maps back to a URL you control and know to be trustworthy.

And as a bonus tip, make sure you store the XML file in the user's profile, not inside the application folder under Program Files. This ensures that non-Administrative users can use the download-and-update feature.

Dear Diary...

ptorr — Sun, 17 Jul 2005 22:19:19 GMT

I haven't really blogged in a while, mostly because it's hard to blog about the kind of work I do right now (improving the security of unreleased products). But, I thought to myself, one way to share some of my experience with all you great folks would be to have a series of "Dear Diary" entries where (in the grandest tradition of trashy magazines) I will publish letters from "readers" who have sent me their security questions, and provide my answers or advice.

Some of these questions will come from real engagements I have had at Microsoft, some will come from questions I've had from external customers in the past, and (maybe) some will come from questions that you send in. Then I won't have to fake it any more! :-)

Anyway, we'll see how it goes... I'd love to hear your feedback.

So that's what happens...

ptorr — Wed, 15 Jun 2005 08:42:38 GMT

Today I did something I haven't done in a long time: I downloaded and installed some unsigned code while running as a local administrator on my home computer.

I had to stare at the Security Warning dialog from Windows for quite a few moments before I decided that I really wanted to install software from Unknown Publisher. I almost expected my machine to catch on fire as I clicked the Run button... but surprisingly enough the application seemed to install without incident (or so I hope!).

So why did I do it? Because realistically I had no other choice. It was either that or live without the software, and I wanted to use the software. Just like the other week when I had to install an unsigned driver for some hardware I purchased. The manual helpfully told me how to turn off driver signing (uh, thanks... I guess) but neglected to say I should turn it back on again afterwards! And it's not like I'm going to take my hardware back to the store and say "I don't want to use this cool device because the driver isn't signed."

Sometimes you just have to take calculated risks. Luckily for me I think I got by alright this time.

In other news, Alcazar's new single Alcastar is incredibly good -- especially the Soundfactory Starstruck Anthem. Buy it now! :-)

Mozilla now signs Firefox downloads

ptorr — Sun, 27 Mar 2005 04:52:00 GMT

A little bird recently told me some good news -- Mozilla Firefox is now digitally signed by "Mozilla Foundation." This means that Windows customers who want to download the self-installing executable with Internet Explorer can do so and be sure that what they downloaded was indeed Firefox and not some corrupt (or tampered with) download:

The cert was apparently issued just a couple of days after someone blogged about this issue... but maybe that's just a co-incidence ;-)

Guerrilla Threat Modelling (or 'Threat Modeling' if you're American)

ptorr — Wed, 23 Feb 2005 07:30:00 GMT

A crash-course in developing Data Flow Diagrams in support of software threat models...(read more)

High-Level Threat Modelling Process

ptorr — Tue, 08 Feb 2005 11:20:00 GMT

The following is a (slightly modified) version of a document I wrote for the VSTO team way back in the day. You might find it useful as you plan threat modelling for your product(s). You should of course read the Threat Modelling book from Microsoft Press if you want to go into great details about how to do a good job of threat modelling, but this might be enough to get you started on a plan.

One important thing that people often miss is that a good threat model is critical for enabling your test teams to attack the product from a hacker's perspective (and to really find those juicy security bugs that might otherwise go unnoticed). Anyone who thinks that threat modelling is purely a developer or PM responsibility needs a smack upside the head. QA must be involved so that they can understand the areas of weakness in the product and so that they can provide constructive input into the process as well (testers aren't just there to clean up your mess once it's coded, you know!). QA can provide critical insight into how a product performs under various unexpected situations, and thus they help to drive the enumeration of threats and gauge the effectiveness of the various mitigations employed, etc.

I also hope to post something much more useful than this soon; it's just taking a while to write (whereas posting old documents is dead easy ;-) ). Anyway, here it is:

Suggested Threat Modelling Process

This document outlines a suggested threat modelling process for product teams. It is designed to assist teams in building high-quality threat models without turning everyone into a "security expert" and without overly taxing the resources of existing "security experts" in the team.

The process consists of six (possibly repeated) steps, outlined below in more detail:

1. Preparation

2. Brainstorming

3. Drafting

4. Review

5. Verification

6. Closure

Note that any significant bug fixes or design changes that affect the component after the threat model has been completed will require this process to be revisited to some degree.

References to the "SWAT" team below refer to the assigned "security experts" in the product team, as well as any external security consultants that have been recruited for the process.

Preparation

The PM and development owners identify Entry Points, Trust Levels, and Access Categories for the component, and use these to build one or more Data Flow Diagrams (DFDs). They also identify all known consumers of the component and which entry points / access categories they utilise.

·This task should take around one hour for a reasonably-sized component. Larger components may need to be broken up into smaller components to make them more manageable.

·SWAT team members may be called on to help at this stage, but are not required for this process. The PM and dev should be able to identify the entry points into their component without the assistance of a security expert.

·Actual threats are not enumerated at this stage; only the ways in which external entities can interact with the component.

Brainstorming

In this phase, the component team works from the context diagrams and other deliverables from the Preparation Phase to perform STRIDE-based modelling against the component. This will identify the threats and against the component, and highlight any possible weaknesses or vulnerabilities that need to be addressed.

·This task should take around one to two hours for a reasonably-sized component. Additional meetings should be scheduled as appropriate if all avenues are not fully explored.

·The results of the Preparation phase (entry points, DFDs, etc.) should be made available to the brainstorming attendees at least 2 days before the session so that the meeting doesn't just become a walk-through of the DFDs.

·The existing documents (DFDs, access categories, etc.) may be updated during the brainstorming session if new information comes to light, or if a particular feature was overlooked.

·Core component team members (dev, test, PM) must be present, and at least one SWAT team member must be present at the brainstorming session to assist with the process, answer questions, and so on. If the component is particularly high-risk or is heavily based on technology provided by another team, external experts should be invited as appropriate.

·All reasonable threats are enumerated at this stage, even those that already have mitigating strategies or that have been explicitly designed for. The point is not to just identify security bugs, but to document all known threats the component must protect against, and how it does so.

Drafting

After the Brainstorming session, the PM owner takes all the ideas generated from the meeting and organises them into a Threat Model document as appropriate for the team. This document will contain the (potentially updated) DFDs, the entry points, trust levels, and access categories, and all identified threats along with their mitigating factors (if any)

·This task should take one to two hours, depending on the amount of data captured in the brainstorming session.

·SWAT team members may be called on to help at this stage (eg to provide guidance on technical terms), but the PM should be able to formalise the data without the help of an expert.

Review

After the threat model has been drafted, it is subjected to a normal review process like any other document. At this stage there may be minor (cosmetic) changes required to the document, or it may need to go back through a more thorough drafting phase. In the worst case, where a fundamental assumption is shown to be false or some other deep issue invalidates the work done so far, the process may need to go back to the preparation / brainstorming.

·This task should take one to two hours, similar to a normal spec review.

·The draft threat model must be made available at least 2 days before the meeting.

·The members of the Brainstorming session should be present, and the invitation should extend to any other interested parties (the whole PM / QA teams, management, etc.), and the SWAT team.

·Although the document may undergo cosmetic changes at this stage, it is not acceptable to merely patch it up if a serious hole is found in the document. The process must be re-started, although perhaps in a reduced capacity.

Verification

Once the threat model is reviewed, the QA team updates existing test plans and augments / writes new test cases to verify assumptions made in the brainstorming phase and to perform directed testing on identified weaknesses.

·This phase can actually start any time after the Brainstorming phase, but because of the possibility of changes during the review phase it has deferred to this position.

·If necessary, external teams may be called in to help with penetration testing or other attack strategies if the details of a particular threat are not well understood, or if the mitigation strategies are believed to be lacking.

Closure

Based on the Review, the PM owner makes final edits to the threat model and publishes it (including the context diagrams, etc.) to the appropriate team web site. The PM also logs bugs for investigating / fixing potential weaknesses identified both in the spec and the implementation (these will be followed-up on by dev and QA).

·This task should take one to two hours

·Remember that threat modelling is never really done! New classes of attacks are always being found, and bugs in dependencies or changes that invalidate assumptions may manifest themselves as new vulnerabilities in the component.