As has been said over and over, allow-all cross-domain policy files should never be used on domains, where users log on. This leaves the site open for CSRF attacks from flash clients on different domains, that can load pages from the target domain utilizing the user’s automated log-in and thus the flash load’s the pages, like the user himself would. This not only allows the flash file to (without the user knowing it) load all his private information from the target site, but potentially also post data to the site, which could include updating the user’s password, email, profile or in worse circumstances add/remove content or even make purchases, if the target site has any feature like that.

This has been done against large sites like Facebook, MySpace, Adobe and Youtube – the latter was ironically documented via a video on Vimeo by Jeremiah Grossman.

In Vimeo’s case, you can “only” upload videos, but an attacker could actually perform any action on the user’s behalf, that the user himself could – including changing the user’s bio, add/remove videos, comment on/like other videos etc. I made a small, seemingly innocent page, that included a hidden flash element, which first loaded the user’s info from vimeo.com/settings/personal and then re-posted this info back to the same page adding an extra line to the bio – namely “You have been bwned”, as it can seen on my vimeo profile.

Someone at vimeo has clearly seen this demo, (Julia Quinn has indeed) and now the cross-domain policy only allows *.vimeo.com (the new file is served with a Last-Modified timestamp of Thu, 11 Feb 2010 23:32:05 GMT, so the change is only an hour old). The strange thing is, that if you go back via the Wayback Machine from archive.org, you can see, that they had much better security back in 2007 and 2008 (html render fails, but view source), so I have no idea how such a relaxed policy suddenly appeared on their site. Google’s cache still show the allow-all policy as it dates back to January 20th (again, view source to see contents).

I found this while playing around attempting to load videos from Vimeo directly in a custom FLV-player on a different host than vimeo.com and found that this was actually possible, as all videos from their site are hosted from av.vimeo.com and this has an allow-all cross-domain policy. And this makes sense, as this domain is only used for serving videos and nothing else – no cookies or authentication info shared to this domain.

I haven’t heard from Vimeo yet – neither stating that they are looking at the issue nor that it has been fixed. I only post this after now seeing, that it has been fixed.

Related posts:

1. Sys-Con once again attacks Aral Balkan with stupidity and ignorance
2. Link sharing spam on Facebook
3. Re-Youtube – January 2010 Ideas

There are of course a lot of legal issues, and such a service should probably obey robots.txt. And there should be a very clear opt-out possibility for websites that have been targeted in user-contributed additions – maybe even moderation before the services are publicly available. It should not be seen as an attack vector, as a proxy method for illegal purposes or anything like that, but simply as a way of “helping” free information to be used freely.

Why?

A lot of data on the web is hidden in the so-called “deep web” behind forms or in inaccessible parts of websites. With a service like the above-mentioned, this would suddenly not only become visible and indexable, but even queryable.

What’s next?

Do with this idea whatever you like – expand, implement, trash or forget. Just remember, that if you use it in anyway make sure to attribute me according to the Creative Commons Attribution 3.0 License, that all these 365 Social Ideas are published under.

Related posts:

1. Coordinate-Proxy – January 2010 Ideas
2. Open Data – January 2010 Ideas
3. Social Subway – January 2010 Ideas

Okay, things are a bit technical, but there are 5 ways to store passwords. Let’s start with the least secure and move up from there (explanations given below for the curious):

1. Store a password in plain-text.
2. Store a password via regular (decryptable) encryption.
3. Store a password via one-way (non-decryptable) encryption with none or the same salt for all passwords.
4. Store a password via one-way encryption uniquely salted.
5. Don’t store passwords.

Salt?

Note: If you already know what encryption and salt is about, feel free to skip this section. Furthermore, if you don’t really care but just take my word for it, that the above 5 levels exist, feel free to skip further down as well.

How the password is stored in the database matters for two reasons. First of all, if you don’t trust the site owner completely, they should not have your password in a way, where they themselves can read it. Secondly, if their database is compromised and someone gets a hold of all the passwords (in whatever form they are stored) as well as corresponding usernames/emails, they could use this information to access a lot of other accounts in a lot of other websites used by the same users – because must users use the same passwords or the same few passwords for most services.

Whether the password is stored in plaintext or in a decryptable form (with the decryption keys most likely compromised along with the database) is actually the same, as the decryption (with keys available) is very straight-forward to do. The result is, that the attacker will easily obtain the plain-text passwords alongside the matching usernames/emails.

One-way encryption (commonly known as “hashing”) is a way to generate a value based on the original password, that does not directly reveal the original password. Imagine the original password as a set of numbers. If we add the numbers, we get the sum, and if we store this sum, then we could match against any password entered, and if the original password is entered, it would give the correct sum and thus allow access. But only knowing the sum does not reveal the actual password. Of course, simply adding the numbers is not good enough, as many easily testable sequences of numbers will give this sum but the idea is the same, just a lot more fine-grained and to date impossible to reverse for the best known such hashing-algorithms.

The only way to “reverse” a good hashing-algorithm is to brute-force it. E.g. if you know the sum of a set of numbers is supposed to be X, then try any combination of number to see if they give this sum. For hashing-algorithms it’s a bit more tricyk, but basically try all known words and see if the result of applying the hashing-algorithm is the expected sum. This does seem quite infeasible, but if you have maybe 200.000 users all with their passwords stored via the same direct hashing, you could start by trying the password “secret” and see how many of the 200.000 stored hashed values matches. I would guess at least 500 of them. And so on, you could try any dictionary word and each time learn more and more of the passwords.

But then we add salt. A salt is an extra known but unique string added to the password before hashing it. Imagine that we say, that for user U1, we add the salt S1 (a series of random letters) to the password and get the hash value X1, that we store along with the salt in the database. For user U2 we add the salt S2 (another series of random letters) to get X2 and store S2 and X2. Now, S1 and S2 are different, so even though user U1 and U2 might have the same password, X1 and X2 are different. Thus even though 500 users might use the password “secret”, we won’t know until we try each one with the unique salt. This makes brute-force attacks much less efficient, as we have to try every dictionary word once for every unique salt to know anything interesting – which would then take 200.000 times longer that if they all used no salt or the same salt.

Do you really need my password?

If I want to use some new service, that I don’t really know if I can trust, I know I shouldn’t trust them with a password, that I also use elsewhere in more important applications. But I can only remember so many passwords, so I will mostlike reuse some of my less secure passwords or built passwords according to some rule (like adding the website name to the password or something like that).

But this creates a new vulnerability for me, a new potential violation of my privacy. So I should really only give you my password or a slot in my limited password-memory, if you really, really need it. And today, any small online service could easily do without. Because any user who would user your service would most likely already have either a Twitter, Facebook or openID account. And it is technically quite easy to use any of these services to have you user securely log on to your service via any of these networks (without the user giving out his password to strangers) and this should provide any small service with more than enough user information. How to do this is quite simple and any worthwhile web developer can tell and show you in no time. Why to do this should be provided above – and summarized below.

Why?

Only give to people you trust completely your most private and most secure passwords. And for the lesser trusted people, give less secure passwords. And don’t ask for passwords, you don’t really need. Just because it seems like the user is more “your own” when he has his own password for your service, it is actually a bad thing. And if you really, really need my password, please promise me that you treat it with the utmost respect.

Oh, want some examples? Okay, here’s an easy one: TweetDeck. I have granted your application the privilege to post updates to both my Facebook and Twitter account, and yet that is not enough for you – you actually want me to invent a new password just for you to be able to synchronize my TweetDeck installations? How stupid are you? And that’s just to name the most obvious one, that I’ve come across…

What’s next?

Do with this idea whatever you like – expand, implement, trash or forget. Just remember, that if you use it in anyway make sure to attribute me according to the Creative Commons Attribution 3.0 License, that all these 365 Social Ideas are published under.

Related posts:

1. Coordinate-Proxy – January 2010 Ideas
2. Turn (Closed) Content Into an API – January 2010 Ideas
3. Social Subway – January 2010 Ideas

It is a “simple” case of “click-jacking” and the site tricks you to click a Facebook share button, but disguises this as some other button. Please read on for full description.

UPDATE 2009-12-2: “Press the button or dog dies”/”Push the button or this dog dies” (located at pressthebuttonordogdies.com, but don’t go there) is a new such site. The target website is “thisblogrules.com” and the measures used are a little different but all in all the same anyway.

Furthermore, I have used bit.ly for tracking how much these links have been used so far on Facebook – it is pretty inflicting: The “hot” girl has been shared almost 59,000 times and the poor dog has been shared 5,309 times as of this writing. You can see the direct stats from the Facebook link.getStats API here: Somthing Hot and Or Dog Dies

The original post looked like this (taken from my own feed):

Don't go to this page if you see this post

The page it linked to was http://3dvv.com/somethinghot/ (don’t go there, nothing to see) and looks like:

The page tricking you to share the link

When you press the “button” you actually press this (opacity on iframe set to 1 instead of 0):

The real button that you actually press kind of looks like a Facebook button, right?

The trick here is, that they have used the layout of this page about sharing the link (safe to go to, just don’t actually press the share button): http://www.facebook.com/share.php?u=http://3dvv.com/somethinghot/. Then, they included this page inside an iframe that was offset the right amount negatively to the left and to the top, to leave just the share button visible in the corner here (no need to visit): http://3dvv.com/somethinghot/ngr.php, which looks simply like:

How to only show the share button by iframing the share.php page

If we on this page remove the constraints, we can see the whole bottom corner of the page like this:

The rest of the share cutout with the button in the corner

Well, this is not all. In order not to have the page simply redirect to what facebook normally would after having shared a link, this page with only the share button visible is wrapped in another iframe, that steals the redirect Facebook creates and make their own redirect to the actual target (porn) site.

All in all, it is a very clever albeit strictly illegal way of using the Facebook sharing functionality for viral spamming purposes.

What can Facebook do about it? One thing would be to not allow share.php to be embedded in iframes via a simple javascript, but that might break desired functionality in other places. Otherwise, they could shift the placement of the sharebutton slightly of different page loads, but that could probably be circumvented by detecting the position of the button via script and isn’t a viable solution. Or they could require that the user had to type some captcha before being able to post links to new sites not posted before, but that creates a lot of other problems (and a good scammer could simply require the user to answer the captcha as well as click the button – users would do that). I’m sure Facebook can think of something, though.

What can you as a user do about it? Nothing really. Only click on “links” on foreign pages that you know for sure are legitimate and that you trust that your friends really did post on their own. But it is pretty hard to protect against. It really is Facebook’s job to make sure this doesn’t happen.

Please share this with everyone!

Update 2009-11-24: Several sites report this as an example of CSRF/XSRF (Cross-Site Request Forgery) and most use this AVG blog post as source. Not that it really matters, but it is not XSRF – it is clickjacking. There is a slight difference, the main difference being, that the countermeasures are very different.

Related posts:

1. I like Facebook
2. 100,000 spam comments fought off
3. Private Comment Sharing – January 2010 Ideas

SnapABug did the right thing, the only thing they could do. Untrusted (unsigned) code lives in a special sandbox and cannot use functions outside of this sandbox. The end user can change how much this sandbox has access to, but it is not trivial and the normal user would never touch that with a pitch fork. Trusted code lives in another sandbox with almost infinite possibilities. The end user can limit this sandbox too, but again almost no end user does that.

The problem? How is code deemed to be trusted code? Code is trusted, if the publisher is trusted, and the validity of the publisher is guaranteed through the digital signature. The signature is automatically verified by the Java client, and the end user is then asked to do the final step – the Java client asks the end user to trust the code:

We know this code has been written by this person (even though we don’t know what the code does). We know this person/company is, who (s)he says (s)he is. You can therefore safely trust the authenticity of this person. Do you trust that this person has written safe code?

First of all, this is a strange question to ask any end user. Secondly, that if the actual question was written as above, it would have been much better as it would assume that the person has written safe code, but would let the end user decide – instead the question is written in a form that almost suggests, that the end user tries to illegally gain access to your computer by asking:

An applet from “domain” is requesting unrestricted access to your computer

The SnapABug applet trust question

And below that in smaller letters is says that the digital signature has been verified (whatever that means to Average Joe). I am aware, that this might be the more specific question asked by my Java client/browser combination, as Sun seems to indicate, that the dialog looks different on other systems.

In any case: that question is stupid. Would the normal end user install programs, if the standard windows installation flow included the question:

When installing this application, the application could potentially install spamware, adware, take over your computer or copy your banking information. Do you wish to proceed?

Let’s just say that adoptions of small programs from small developers would be a lot lower (which might be a good thing to prevent all those installing spamware because they think they have a virus or silly things like that, but in the long run it would probably be a bad thing). Asking such a question is stupid. This question really should be re-phrased in a way to clearly indicate, that the user should assume that this is a safe, trusted application, but the user has the opportunity to deny access anyway.

Secondly, (trusted) applications should have a way of asking for access to only what they need. The digital signature is simply for verification of origin, but the actual access level needed should be separate from that. As I asked in my previous post: why should the SnapABug applet have access to files on my computer? And they don’t need it, in fact I’m pretty sure, that if they could avoid having that access, they would rather do that. But they can’t.

Thus SnapABug is not to blame – if anyone, Sun is.

Related posts:

1. How SnapABug works – and what they should do
2. If WordPress automatic update fails “silently”…
3. Password-friendly Website Certificate – January 2010 Ideas

Well, I delved into the application and found the answers – they could of course have done with a more restrictive permission.

First I found the JavaScript file. The interesting part here was to find, that they actually inserted a java-applet in the corner of the application (in the startWebCapture-function):

startWebCapture:function() {
    	document.getElementById('SnapABug_Applet').style.display = 'block';
    	document.getElementById('SnapABug_Applet').innerHTML = 
	    '<applet style="position:absolute;background-position-x:0px;background-position-y:0px;display:inline;font-size:2px;width:300px;height:2px;" name="SnapABug_Applet" code="webCaptureApplet.WebCaptureApplet.class" codebase="' + baseURL + '/" archive="sWebCaptureApplet.jar" width="200" height="2" mayscript>'
        + '<param name="h" value="' + this.getWindowHeight() + '">'
        + '<param name="w" value="' + this.getWindowWidth() + '">'
        + '<param name="c" value="' + caseId + '">'
        + '<param name="d" value="300">'
        + '</applet>';
    }

This applet (JAR file) is passed the viewport size and a case ID (used for sending the screenshot directly to the server). The source for this applet is easily accessible using e.g. JD.

The interesting part here is how they actually find the offset of the viewport. Getting a screenshot of all the available screen devices is quite easily managed through the GraphicsEnvironment class iterating through all screen GraphicsDevice‘s to make it work on multi-screen setups. But finding the browser-window on the screenshot bitmap is a bit tricky – the browser chrome can look in all different sorts of ways, the only thing that we can be sure of is, that the viewport is rectangular and has the size given to the applet by JavaScript. If we could find just one of the corners of the viewport… Well, they solve this in a very low-tech way by via the above JavaScript embedding the Java Applet in the top-left corner at 2*200px and then in the paint(Graphics g)-function of the applet draw a certain pattern in that area:

  ...
  BigInteger bi = new BigInteger("11010100110010110011", 2);
  ...
  public void paint(Graphics g)
  {
    System.out.println("paint: drawing corner");
    drawCornerCode(g);
  ...
  private void drawCornerCode(Graphics g)
  {
    g.clearRect(0, 0, 100, 10);
    for (int i = 0; i < 20; ++i) {
      if (this.bi.testBit(19 - i))
        g.setColor(Color.black);
      else {
        g.setColor(Color.white);
      }
      g.drawLine(i * 3, 0, i * 3, 10);
      g.drawLine(i * 3 + 1, 0, i * 3 + 1, 10);
      g.drawLine(i * 3 + 2, 0, i * 3 + 2, 10);
    }
  }

This draws a black and white striped pattern in the top left corner of the browser which functions somewhat like a bar code. Then, when JavaScript asks the applet to create a screenshot, the applet runs through every pixel of every screen and sees, if from that pixel the bar code follows:

      for (int j = 0; (j < devices.length) && (!(detected)); ++j) {
        GraphicsDevice device = devices[j];
        GraphicsConfiguration config = device.getDefaultConfiguration();
        Rectangle bounds = config.getBounds();
        ...
          screenshot = rbt.createScreenCapture(bounds);
        ...
        for (int y = 0; (y < screenshot.getHeight()) && (!(detected)); ++y) {
          for (int x = 0; (x < screenshot.getWidth() - 21) && (!(detected)); x += 2)
          {
            if (screenshot.getRGB(x, y) != Color.black.getRGB()) {
              continue;
            }
            for (int i = 0; i < 20; ++i) {
              if (((this.bi.testBit(19 - i)) && (screenshot.getRGB(x + i * 3, y) == Color.black.getRGB())) || (
                (!(this.bi.testBit(19 - i))) && (screenshot.getRGB(x + i * 3, y) == Color.white.getRGB())))
              {
                detected = true;
              } else {
                detected = false;
                break;
              }
            }
            if (detected) {
              System.out.println("detected x: " + x + " y: " + y);
              detectedX = x;
              detectedY = y;
            }
          }

This is actually quite brilliant, but of course not a revolution – just a smart simple way of using what’s available.

What is the problem then? Unrestricted access is the problem! I never allow unrestricted access to any applet unless I can’t do without it and trust the publisher. For this tool, neither criteria is fulfilled. After having checked the source code, I have allowed the applet, but not before – unrestricted access is simply way more than they should ever have. They need access for two things:

1. AWTPermission – access to the screens (which also gives access to create frameless windows and access to the visible state of all other programs running).
2. SocketPermission – access to cross-domain posting of the final image.

Of these permissions, only the first one is really necessary. The latter could be solved by requiring implementers to have a script locally on their own domain, that could process submitted images or simply forward them.

If the applet only asked permission to these two – or even better only AWTPermission – it would be way more trustworthy. As Sun says about the AllPermission:

java.security.AllPermission specifies all permissions in the system for all possible targets and actions. This permission should be used only during testing because it grants permission to run with all security restrictions disabled as if there were no security manager.

Only during testing! Never in deployed applets from an unknown company expecting major adoption across third-party websites. The permission, that I particularly don’t like any applet not needing it to have is FilePermission. They should not be able to read any files on my computer or write any – they don’t need it!

If it does get implemented on many sites, this jar file will then be very very interesting to phishers and scammers, as they could use this (if they replaced the file with their own) to infiltrate many computers with key-loggers, malware and anything else. This is not the case, as the applet is digitally signed, so modifying would require re-signing it, which would require re-authorizing it by end users.

But nevertheless – a very interesting feedback mechanism, that definitely has potential.

Source-code published under fair use. All rights belong to Timzon and only published here as-is without any warranty, obligations or any claims of copyright on my behalf.

Related posts:

1. Why signed applet trust is a stupid question (and why SnapABug is not to blame)
2. The iPhone developer boycott in the works
3. Why UK copyright law does extend copyright to the digitization of public domain works

Flash memory cheats have always been known to any good flash game hackers and ditto developer, but some still don’t know about them. Thus, as shoemoney recently posted a competition to get the best score in Desktop Tower Defence, “some guy” of course fired up Tsearch and throw a lot of points his way. The result was of course, that he won (even though he cheated), and afterwards he posted a simple guide to do it.

That is why should should always have a server telling you what to do when. More on this topic in the months to come – as I and a friend is developing a brand new game site including high-level security.

Related posts:

1. Announcing MXHR4AS3: Multipart/mixed-file download by Flash clients
2. Game of Life – January 2010 Ideas
3. Facebook Notes and Images for Competition Results – January 2010 Ideas